Information Technology Security and Compliance Statement

Topic: Information Technology Solution Provider Security Statement

Overview

A solution provider, software solution provider, or vendor, hereafter called "Solution Provider", will receive this document if Oakland University (“University” or “the University”):

· Intends to purchase or contract outsourced, hosted, software as a service, web site service, application service provider application, on-premises software solution, or similar service from a vendor; or

· Intends to transmit or relocate data currently and actively resident in an on-premises information technology resource to a Solution Provider or between software solutions; or

· Intends to have a Solution Provider or vendor collect or capture data on behalf of the University or for subsequent use by the University.

The document defines the minimum security and operational criteria that the Solution Provider must provide to engage in business with the University. Solution Provider must comply with or submit materials in compliance with those statements for which a particular standard or security protocol is identified. Such compliance shall continue for the duration of the agreement, purchase order, or contract (“Agreement”).

Security Statement

1.0 Audit and Compliance

Security Documentation Request

As part of the procurement process University Technology Services (UTS) requests various types of documentation to aid in evaluating the security of a product or solution. The following documents typically provide UTS with the vast majority of information required for an assessment and are the most efficient way to initiate a review.

  • Higher Education Community Vendor Assessment Toolkit (HECVAT) Full

  • Service Organization Control (SOC) Type II Report
  • Software Bill of Materials (SBoM)

  • OU E-MAIL SECURITY QUESTIONNAIRE

As not all parties involved with a purchase may be familiar with these documents and their importance we would like to address some commonly asked questions below:

  • What is the Higher Education Community Vendor Assessment Toolkit (HECVAT) Full?

    • The HECVAT is a questionnaire framework specifically designed for higher education to measure vendor risk. There are two versions of this document, the "Lite" and the more comprehensive "Full" version. Completing the HECVAT Full allows an institution to evaluate that the information, data, and cybersecurity policies are in place to protect our sensitive institutional information and constituents' PII.


  • What is a Service Organization Control (SOC) 2 Type II Report?

    • SOC compliance and audits are intended for organizations that provide services to other organizations and involve a third-party auditor validating the service provider's controls and systems to ensure that it can provide the desired services.


  • What is a Software Bill of Materials?
    • The Software Bill of Materials (SBOM) lists all component parts and software dependencies used in application development and theory.



  • What is the OU E-MAIL SECURITY QUESTIONNAIRE?

    • The OU E-MAIL SECURITY QUESTIONNAIRE is applicable to vendors and services that utilize email to communicate with OU constituents. The purpose of the questionnair is to gather information to ensure that email is configured in accordance with OU standards and minimizing potential delivery issues, for example e-mail being marked as junk or phishing.


  • Why are these documents requested?
    • To some extent all purchases require an ongoing partnership between OU and the vendor. This relationship can be limited in scope (for example from local usernames and passwords) to complex integrations that involve interconnecting applications and networks together. In order to ensure that university policies are legal and contractual obligations are being met UTS must thoroughly vet each proposed solution to ensure it meets minimum requirements and any risks are communicated, documented, and accepted.


  • Are these documents required?
    • At this time these documents are strongly desired but not required for all purchases. However, as the HECVAT can be completed as a self-assessment, UTS suggests that all vendors complete this document as it demonstrates a commitment to security awareness and best practices.

1.1 UTS Commonly Requested Vendor Documentation

The below are documents commonly requested by University Technology Services

When possible, the official document's name has been used; otherwise common terminology has been used.

Not all documents are required; especially as some documents may have overlapping functions.

  1. Service Organization Control (SOC) Type II
  2. Service Organization Control Bridge Letters
  3. Higher Education Community Vendor Assessment Toolkit (HECVAT) Full
  4. Reference Architecture
    • Technical Architecture; Sizing Guide; OS Requirements, etc.
  5. Communication Requirements / Firewall Implementation Guide
    • Communication requirements including port, protocol, and IP.
  6. National Institute of Standards and Technology (NIST) assessments
    • Assessments such as, but not limited to, the 800 series of documents
  7. International Organization for Standardization (ISO) Certification
    • ISO certifications such as, but not limited to, 27001

  8. Higher Education Cloud Vendor Assessment Tool Required for cloud solution

  9. PCI (Payment Card Industry) Documents reflecting Payment Card Industry Data Security Standards - Required for Solution Provider solutions that involve payment card processing. Specific contract language may be required. Please review Payment Card PCI Compliance documentation if payment (credit) card processing is involved.

    • Specify if you are a TouchNet Ready Partner or are willing to become a TouchNet Ready Partner.

    • Annually provide the following documentation: (More information can be found here.)

      • PCI (Payment Card Industry) DSS Approved Service Provider SAQ (Self-Assessment Questionnaire)
      • AoC (Attestation of Compliance)
      • PCI Certification Document
      • An AOC for SAQ-D
      • Quarterly ASV (Approved Scanning Vendor) Scan Results
      • An executive Summary from annual penetration testing

      • Specify if your equipment is P2PE (Point-to-Point Encryption)certified.

      • Specify if your PIN transaction system is PCI PTS (Pin Transaction Security)compliant

      • Specify contactless payment processing supported
      • Specify your ability to provide a dedicated customer support personal knowledgeable in PCI compliance requirements

  10. Certification of the product by Common Criteria - Optional.

  11. Cloud Security Alliance Star Certification.

  12. Statement from auditor for compliance with ISO/IEC 27001:2013 or later.

  13. Statement from auditor for compliance with SSAE 18.

  14. Statement from auditor for compliance with Health Insurance Portability and Accountability Act (HIPAA/HiTech) regulations; required for HIPAA related processing.

  15. The University is committed to enabling equally effective, integrated, and independent access to information through information technologies, databases, services and resources to all constituents with disabilities as described in University Policy. Solution Provider must submit statement of accessibility compliance. Solution Providers are required to demonstrate that the proposed solution conforms to or addresses each of the W3C's Web Content Accessibility Guidelines (WCAG) Level AA (including Level A). Solution Providers may submit a Voluntary Product Accessibility Template (VPAT) 2.0 based on WCAG 2.0 Level AA. The VPAT 2.0 template is available from the Information Technology Council. Alternatively, the Solution Provider may submit an independent third party evaluation from a qualified accessibility consultancy.

  16. The University aggressively protects copyrighted material, and all University logos, emblems, and images must be used only with University approval. Solution Provider must destroy all related University material at the end of the Agreement.

  17. Solution Provider must present evidence insurance according to University Risk Management standards, Information Technology Services.

  18. Solution Provider must demonstrate compliance with relevant data privacy laws and regulations. Compliance with the Family Educational Rights and Privacy Act (FERPA), if student records are involved in the process. Solution Provider must provide information about compliance with the General Data Privacy Regulation, if personally identifiable data are involved in the process. If medical records are involved, Solution Provider must provide statements of compliance to medical records laws or HIPAA, as appropriate.

  19. Statement describing compliance with the EU General Data Protection Regulation (GDPR) if processing Personal Data; include a copy of GDPR Privacy Statement.

  20. Solution Provider must demonstrate ability to comply with E-Evidence legal preservation at the request of the university.

2.0 Data Controls

  1. A data integration plan must be discussed. What data elements are being sent by the university to the vendor and what data elements are being sent from the vendor to the university?
  2. If ERP integration is planned, describe data integration for Ellucian Banner Release 9. Include description for how Ellucian APIs are used. Describe both initial data load and ongoing data integration.
  3. Solution Provider will store University data only in data centers located within the United States, meeting or exceeding network, host, and physical security standards commonly found acceptable by regulatory agencies or organizations (i.e., PCI -DSS 3.2 or later).
  4. Solution Provider agrees to keep University information and data private and confidential, and to treat information and data confidentially except as specifically provided for in the Agreement. Data cannot be shared with or sold to third parties.
  5. Solution Provider will use data encryption standards commonly found acceptable in by regulatory agencies or organizations (i.e., PCI -DSS 3.2 or later) for the protection of University data matching the State of Michigan law for Personally Identifiable Information.
  6. Solution Provider will provide capabilities for storing and processing full Legal Name and Preferred First Name if any name service (student name, employee name, etc.) is included in the solution.
  7. Solution Provider will provide data in response to University request in a preservation standard consistent with industry best practices for forensic retrieval, for review and use in connection with law enforcement, human resource management, litigation, or contested matters in all forums, audits and for the University’s own use.
  8. Solution Provider will notify the University contact assigned for this engagement in the event of accidental data exposure, access of data by unauthorized parties or individuals, request for data by law enforcement, or any other third-party access to University data, within 48 hours of request or discovery.
  9. Standards for data quality are established by the University and enforced by the Solution Provider. The Solution Provider must meet the University standards for the quality and integrity of data. The University retains the right to approve the quality of data displayed on web sites; the Solution Provider will remove any University data from any web site based on the University noting a lack of quality. Processes that gather, edit, modify, calculate or otherwise manipulate data must meet University standards for data quality. The University must approve the sources of data and the data maintenance method.

3.0 Identity Access and Accounts Management

  1. The University and the Solution Provider will determine a secure access identity infrastructure process for the solution, including a unique login identity and password that is encrypted in storage and at rest for account users. The University and Solution Provider will determine the best practices for issuing login accounts, password attributes, password resets, and other access identity management processes using standard industry practices for security and privacy, with the University solely responsible for the final solution decision.

  2. The University requires that the proposed solution meet University identity access management standards. Login processes can authenticate using Single Sign On for InCommon Federation, Shibboleth IDP Version 4.1.x or higher, (SAML 2.0 or CAS protocol 2.0 or higher), Red Hat Directory Server 11 or higher, and Microsoft Active Directory within the University Identity Access Management Environment. ADFS is not an option at this time. Solution Provider must indicate whether the firm is a member of InCommon Federation. If not a member of InCommon, describe the login management process using Shibboleth Version IDP 4.1.x or higher, (SAML 2.0 or CAS protocol 2.0 or higher), or openLDAP/RedHat Directory Server 10.6 or higher. Authentication Standards.

  3. All communication occurs using approved encryption methods for administrative user and data in transit (e.g. TLS 1.2 or higher).
  4. If none of the preferred processes are usable, please describe the process. If the Solution Provider is providing identity access accounts for the solution, will provide a unique login identity and password that is encrypted in storage and at rest. Solution Provider will manage issuing login accounts, password attributes, password resets, minimum password length, password generation guidelines, password expiration, and other access identity management processes using standard industry practices for security and privacy. Describe in detail the following processes:
    • Creating new accounts
    • Suspending accounts for temporary security reasons
    • Terminating accounts
    • Password resets
    • Password security protocols
    • Name changes
  5. Solution Provider changes system default and system administration passwords on implementation and regularly thereafter following standard security best practices.
  6. When possible the following notification should be displayed prior (preferred) or immediately after the point of authentication.

    "This system is for use by authorized users only. By using this system, you agree to comply with Oakland University's policies, practices and procedures relating to the use of the system (“University Policies”), including without limitations policies relating to acceptable use of the system, and consent to monitoring, recording, and auditing of your use of the system as set forth in the University Policies (collectively, “Monitoring and Recording”).

    You should discontinue use of the system immediately if you do not agree to comply with the University Policies and/or do not consent to Monitoring and Recording.

    Unauthorized use of this system is prohibited and subject to discipline, sanctions and/or prosecution.

    Some systems that include social media and/or online collaboration capabilities may potentially allow certain elements of your profile, such as group membership, connections, profile details, and posts, to be viewed by others. We encourage you to review any privacy settings available to you in the system prior to use."

4.0 Technical and Network Architecture

  1. Solution Provider must supply any specific firewall rules, custom domain names, email configurations, messaging integration, or other configurations required for successful network and communications connectivity to the Solution Provider solution. Solution Provider should supply a full network architecture diagram that details traffic flows and communication requirements, such as network ports, protocols, and applications. Costs and project delays associated with missing or incomplete documentation will be the sole responsibility of the Solution Provider.
  2. If proposing an on-premises solution, provide high-level diagrams and a description of the proposed architecture.
  3. Solution Provider will provide a test environment available to the University for upgrades and ongoing product testing and verification.
  4. Describe how technology upgrades are handled and university control of the timing of upgrades. If proposing a cloud or software-as-a-service solution, provide a cadence for planned outages including time zone considerations for Eastern Time Zone.
  5. Mobile architectures implemented with Responsive Web Design are preferred.
  6. Describe storage limits or record limits associated with the proposed solution. Describe when additional storage or record purchases are necessary. If proposing a cloud or software-as-a-service solution, describe any limitations for storage and archival of data. Are there any capacity limitations on the number of years or amount of data? Number of students? Number of faculty? Number of courses?

5.0 Host Security and Service Health

  1. Solution Provider will maintain the security of hosts (Linux, Windows, etc.) comprising the University application and server infrastructure will be hardened against attack.
  2. Solution Provider will meet minimum service level agreement of 99.9% uptime. Service up time is guaranteed to 99.9% (Consider: 365 days a year, 24 hours a day = 8,760 hours x 99.9% up time = 8,751.24 hours. That means that there would be roughly 1 full business day of system unavailability every year.)
  3. If the Solution Provider proposes an Agreement that provides that the University is responsible for notifying or providing evidence to the Solution Provider that the service being utilized was degraded or unavailable, then the Solution Provider shall maintain an online, customer-facing, near real-time service health dashboard. The dashboard shall be provided to University for review on an ongoing basis and will include a history of application and service health for the last calendar quarter (as a minimum). Examples of service health that provide models include:

6.0 Email Communications

  1. Describe any email notifications process, the types of emails that are system-generated, and the actions that trigger these emails.
  2. Describe the ability to customize both the SMTP envelope and the email header in order to avoid generating email that appears as illegitimate.
  3. Preference is given to systems where individuals can set personal email preferences.
  4. The application administrator must be able to disable specific email messages.
  5. Describe the ability to customize email message content.
  6. If messages contain hyperlinks, what will the recipient see when hovering and what will the recipient obtain by clicking on the hyperlink?
  7. Describe all domains used for sending email; does the solution send mail for multiple domains from the same server?

  8. Solutions must comply with the requirements of Google Workspace Mail stated in this article: Prevent mail to Gmail users from being blocked or sent to spam

  9. Email must stay within the single user limits outlined here: Gmail sending limits in Google Workspace.

  10. The University will whitelist nothing related to email. The University will not add values to its SPF records. Solutions that require either of the former will be rejected. Solutions must do the following and maintain them for the duration of the contract:
    • publish DKIM keys
    • authenticate all email messages
    • only send from and receive to valid email accounts
    • have consistent values in both the SMTP envelope and the email header
  11. Solutions must describe the modifications, such as either adding DKIM keys to DNS or creating subdomains, to the University architecture so that the delivery of messages may be successful.
  12. Identify FROM addresses for email and whether the REPLY-TO is the same as the FROM address.
  13. Services are required to have a valid MX, A, and PTR record for email servers.
  14. Preferences is given to a solution that authenticates with Google Workspace Mail as part of SMTP.

  15. In general, compliance with Common Internet Message Headers is expected.

  16. To ensure compliance with the above requirements we suggest providing information requested in the OU E-MAIL SECURITY QUESTIONNAIRE.

For further help, please email <<MailTo([email protected])>>.

January 2024