Introducing 3rd Party Tools and Services into the LMS

The process to introduce any 3rd party tool into the ASU ecosystem is a multi-stage process put in place to safeguard ASU student and other data.

While the technical process for integrating tools into the Learning Management System (LMS) is generally straightforward, we have security and contract review procedures in place to protect students, faculty, staff and the Institution.  A data breach, which puts either student data, or the entire LMS infrastructure at risk could result in tremendous damage to ASU through loss of productivity due to time spent restoring the service, large expenses associated with identity protection services for students whose data is compromised, loss of confidence in ASU’s ability to protect student and Institutional data, potential lawsuits resulting from misuse of stolen data, etc.

It is for these reasons that ASU requires an application risk assessment in the form of both a contract and security review before anything can be integrated into ASU’s LMS.  

Any product that is to be added to the LMS will need to undergo a full Security Review

A product that is being piloted with a limited number of students for a limited period of time could be added with a Limited Use Pilot review.  In this case ASU will assume full liability for any data loss.

The steps outlined below describe this process:

Security Review

Security reviews are conducted by the UTO Information Security Office (GPIS), formerly known as ISO).  A full description of the process is available on the GPIS GetProtected site > Services > Security Review

Security Review steps:

  1. Identify a person from your department/College to be the Project Manager (PM); this individual will be the project "owner."  The PM’s role is to coordinate and obtain the documents required to facilitate a security review by ISO.

  2. When you are ready to begin the security review process for a product that is to be integrated into the Learning Management System (LMS) the LMS Support team will assign a LMS Systems Administrator to work closely with your PM on the project to answer questions, sit in on the security review, and will be your contact person for installing and testing the LTI tool in our LMS environment.  To request a LMS liaison contact the ASU LMS team and request that a Canvas Sys Admin is assigned to work with you on integration.  

  3. While going through a security review, we can install the tool on our DEV instance of Canvas so that you can test the tool while going through the ISO review.  The DEV instance of Canvas does not have any FERPA data and can be used for testing purposes.

  4. Detailed steps for initiating and completing the security review process are available on ASU’s Get Protected website, but in general:

    1. PM will initiate the review process with ISO by submitting New Security Review  request under Information Security – Security Review – Step1

    2. PM will work with the vendor to gather security documentation, including architectural diagrams, security scans, penetration testing reports and PCI compliance if credit card purchases are an option through the application. The PM will also provide the supplier with a questionnaire to complete and follow through to make sure all questions are answered.   NOTE: the amount and detail of documentation required will depend on the sensitivity of data being passed from the LMS to the LTI application as well as what data is stored on servers not managed by ASU.

    3. PM will submit a Workday request to ASU Procurement to initiate the Purchase Order or contract between ASU and the vendor.  This needs to be done even if there is no cost. The PO/contract contains ASU’s security requirements and liability insurance requirements.

    4. All vendors will need to submit an annual SOC2 - or equivalent review - which will need to be reviewed by the PM to confirm that the vendor’s security profile is in good standing.  

      1. If the vendor is unable to provide a SOC2 or equivalent review, then the vendor will need to carry enough insurance that they can accept unlimited liability for data loss. And the integration will be flagged with an automatic "Medium" risk.

      2. With any Medium risks, an Accountable Administrator (usually the department head) will need to accept the risk (including fiscal costs) in case of data loss.

    5. Once all the documentation is complete, the PM will coordinate scheduling of the security review call between, an ASU GPIS security expert, the vendor, the LMS SysAdmin, and other parties as needed.  

    6. All integrations also require a contract between ASU Procurement and the vendor.  See below for more information on the contract.  

From our experience, the vendor documentation submission, and the penetration tests (which on many occasions have identified problems that must be resolved before they can pass the tests), have caused the longest delays.  Once all documentation is completed and received, the PM submits the documents to ISO and will schedule a security review call where ISO representative will ask follow-up questions to determine if the vendor has adequate protections in place. Same for Architecture and PCI reviews if needed. Depending on how well prepared the supplier is, the data gathering can take from a month to 6 months – or more.

The Information Security Office will issue a summary report outlining the risks that were identified.  With High and Medium risks, the project team should look for ways to implement compensating controls if possible.  Any remaining high and medium risks will need to be communicated and approval received from the Dean or Department head. Note: High risk issue waivers also require approval by the ASU CPO or CFO.

If proctoring assessments will be needed with any third party tool, please contact proctoring@asu.edu to have compatibility confirmed.

 

Contract Review

A contract or purchase agreement is required between ASU and the application supplier, even if the application is being used for a no-cost pilot project.  In some cases, a purchase order will be issued to the supplier, which will reference ASU’s Standard Terms and Conditions, which can be updated periodically. These terms and conditions can be found here. Alternatively, the ASU Standard Terms and Conditions may not be the proper contractual avenue based on the scope of services provided by the Supplier. In which case, Purchasing will draft an agreement that will properly address the scope of services.

Occasionally, a supplier will take exception to ASU’s Standard Terms and Conditions. Purchasing will coordinate with the supplier and department to negotiate and arrive to a final agreement. Note that there may be some exceptions to which Purchasing must seek approval from an authority other than the department; these authorities include, but are not limited to, Office of General Counsel, Risk & Emergency Management, and/or Human Resources. Purchasing will coordinate with these departments to obtain the proper approval and will reach out to the department for information, if needed.

Upon completion of the contract review, Purchasing will work with the supplier to obtain signature; Purchasing will execute the agreement on behalf of ASU and pursuant to ASU’s Contract Signature Authority policy, which can be found here.

The business manager in your department should initiate the contract review process with ASU Purchasing. Purchasing will coordinate their efforts with ISO and the UTO LMS support team.

 

Final steps

Upon completion of the security and contract review processes, UTO will reach out to the Project Manager who will provide technical contact information for the application vendor.  UTO will install the application in ASU’s LMS test environment and the customer requesting the installation will be asked to test it to ensure it meets their needs. Once the customer signs off on the test process, UTO will deploy the application in the LMS production environment where it will be immediately available for use within the customers course(s).

NOTE: If the pilot does NOT need LMS integration, then the LMS team would not need to be involved and the steps related to the LMS integration process need not be undertaken, but you would still need security and contract reviews to deploy the application in any form at ASU.  However, if you ever intend to integrate with the LMS, we would suggest including those LMS references in the initial security review documentation. Something along the lines of “future integration plans with LMS” and be sure to include the LMS connection in your architectural diagrams.  Doing that upfront will save you time later since we will need to re-do the security review if the initial review does not cover an LMS integration.

 

Limited Use Pilot of a New Product

If you wish to pilot a product with a small number of courses and students, over a limited timespan, there is a Pilot review process. In case of a pilot, as much security data is gathered but with Dean or Department Head approval, ASU may assume risks over and above what is already covered by the vendor.

  1. Visit the GetProtected > Security Review page and scroll down to the “What type of Security Review is needed?” table. Then estimate if the number of unique users  exceeds 10,000 - and if below 10K, then you only need an EndPoint Attestation. The Endpoint Attestation reviews  Endpoint Best Practices to confirm that these are in place. The requester should start the DocuSign form and list their Technical lead as the technical reviewer.  Step by step instructions for this process are included on GetProtected.

  2. Make a copy of this Pilot Security Review Google document and rename it to include the name of the product you wish to pilot. Then fill out this Pilot request to the best of your ability.

  3. Initiate a new Pilot review process with GPIS by submitting New Security Review  request and include the link to your copy of the Pilot Security Review document.