Test

Policy Statement

The diagram below shows the key elements of the configuration management process.  These same steps apply to management of the overall environment, and to individual Configuration Items.

Having a known baseline configuration allows more rapid detection of system compromise, and speeds restoration to a known state in the event of either a security event or a system failure.

The rest of this policy defines expectations for each phase of this process.

Identify and Record Baseline Configuration

There are two key elements to this:

• Maintaining a configuration database that is an inventory of all hardware components, the software running on them, and their configuration.
• Defining standardized configurations and images for servers, workstations, and network components that are used as the starting point when building out new systems. When possible, National Institute of Standards and Technology (NIST) hardening guidelines should be followed when creating standardized configurations and images. 

This excludes equipment attached to the public wireless network, and equipment brought in by event coordinators and attached to the event network.

[CI] will maintain a consolidated inventory of all [CI] owned hardware and the software running on them, leveraging software tools as they are available. This inventory will include all systems either on the [CI] network or at [CI] data centers, and will also include software as a service (SaaS) systems that are integrated with [CI] systems.  For SaaS systems, the focus will be on the system business purpose its integrations.  Details of the SaaS application infrastructure

Definitions

This policy outlines security expectations and responsibilities for 3^rd party partners and providers.  It applies to any companies or individuals who provide or support Marywood University (“MU”) systems and applications, or who manage MU data.  It also provides guidance to MU faculty & staff who contract these services.

Responsibilities

Policy

This policy is derived from the general IT Security framework outlined in IT Security and Governance, and the specific IT controls defined in IT Security for IT Professionals.  It defines what should minimally be included when selecting and contracting 3^rd party services, and how compliance should be monitored ongoing.  Note, 3^rd party contractors who provide IT maintenance services to MU hosted systems and applications must comply with IT Security for IT Professionals.  For the purpose of this policy, a 3^rd party partner or provider is defined as an organization that provides, hosts, or manages a system or application that performs business processes for MU and/or handles MU Internal or Confidential data.

Selecting and Contracting for 3^rd Party Services

MU faculty & staff who select and contract for 3^rd Party Services must use good faith efforts to work with the IT team to do the following as part of the selection process:

• Identify the type and classification of the MU data to be carried by the 3^rd party provider, as defined in IT Security Framework.
• Define the Confidentiality, Integrity and Availability level for the system, as defined in IT Security Framework.
• Ensure the 3^rd party system meets or exceeds the controls outlined in IT Security for IT and Data Professionals based on that definition.
• Evaluate the risk of outsourcing the business process, and the overall security maturity of the 3^rd party provider. An IT Team member shall be engaged to assist in this evaluation and perform technical due diligence.

Once the system has been selected, MU faculty & staff must use good faith efforts to work with the IT team to ensure the contract includes language that:

• Clearly defines the MU information that is to be exchanged with, stored on, or processed by the 3^rd party provider.
• Requires compliance with MU If the 3^rd party is handling payment card information, this must include a requirement to be PCI compliant. Do we want to make it standard procedure to ask for the AOC (Attestation of Compliance) (MTP)
• Defines minimum service level expectations in terms of availability, and outlines the consequences.
• Allows MU to monitor 3^rd party compliance as necessary. (Do we want to make it standard procedure to ask for their HECVAT and SOC 2 report from the 3^rd party) (MTP)
• Addresses non-disclosure of MU Internal or Confidential data.
• If the 3^rd party is handling payment card information, requires the 3^rd party provider to provide evidence that security incident response procedures are in place.
• Addresses the return or destruction of data in the event of contract termination, including what happens in the event of a business failure of the 3^rd This should include return or destruction of data when no longer required to support the outsourced activity.
• Explicit protection for MU Intellectual Property, including preservation of copyright and patent, as applicable.
• A Source Code Escrow shall be required for all systems that are essential to MU’s business. This requirement can be waived depending on the relative importance of the system.
• If the 3^rd party is handling payment card information, requires the 3^rd party provider to provide evidence that IT configuration management and change control procedures are in place.
• If the service provided is a multi-tenant service (the system is used by multiple customers, not just MU), there should be particular language and controls defined for protecting MU information from being exposed to other customers.
• For service providers that handle payment card data, the contract should clearly define which PCI DSS requirements are managed by the service provider, and which by MU. Note:  This is PCI Requirement 12.8.5.

In addition, if the 3^rd party provider is handling payment card information (credit card/debit card information), they must have implemented a process for the timely detection and reporting of failures of critical security control systems, including but not limited to failure of:

• Firewalls
• IDS/IPS
• Identity Management
• Anti-virus
• Physical access controls
• Logical access controls
• Audit logging mechanisms
• Segmentation controls (if used)

The IT team will review service providers who handle cardholder data’s compliance at least annually.  Service providers will be required to provide a current Letter of Attestation and supporting evidence (a PCI Self-Assessment Questionnaire or 3^rd party audit summary).

Contracted IT Systems that provide web-based interfaces for prospective or current students must also meet the standards outlined in Web Accessibility.

All contracts should be reviewed by Legal prior to execution.  The table below is a matrix that shows the required controls based on the confidentiality, integrity and availability level of the system.  Exhibit A contains draft contract language for use in 3^rd party contracts.

***How to get compliance from existing contractors?

References

This section contains any 3^rd party standards, guidelines, or other policies referenced by this policy.

1. IT Security Framework, IT Framework and Governance
2. IT Security for IT and Data Professionals, IT Security for IT Professionals
3. IT Configuration Management
4. IT Security Incident Response
5. SANS Institute InfoSec Reading Room, A Security Guide for Acquiring Outsourced Service, https://www.sans.org/reading-room/whitepapers/services/security-guide-acquiring-outsourced-service-1241
6. Payment Card Industry (PCI) Data Security Standard, v3.2
7. Cloud Standards Customer Council, Public Cloud Service Agreements: What to Expect and What to Negotiate Version 2.0.1, http://www.cloud-council.org/deliverables/CSCC-Public-Cloud-Service-Agreements-What-to-Expect-and-What-to-Negotiate.pdf
8. Lexis Practice Advisor Journal, Drafting and Negotiating Effective Cloud Computing Agreements, 11-30-2015, https://www.lexisnexis.com/lexis-practice-advisor/the-journal/b/lpa/archive/2015/11/30/drafting-and-negotiating-effective-cloud-computing-agreements.aspx

Procedures

Data Classification

The confidentiality and integrity categorization of each system is, in turn, driven by the classification of the data maintained in each system.  The table below defines the different classes of MU data.    

The confidentiality and integrity categorization of a system carrying only public or internal data will be Low, while the confidentiality and integrity categorization of a system carrying Confidential information will be Moderate.

System Categorization

The matrix below shows how different types of MU systems are categorized, and should be used as a guideline by management, IT professionals and 3^rd party service providers in defining the specific controls required for a system, based on the guidance in NIST 800-53 Rev 4, Security and Privacy Controls for Federal Information Systems and Organizations and NIST 800-171, Protecting Controlled Unclassified Information in Nonfederal Information Systems and Organizations.  NIST 800-53.4 is pending withdrawl. It is being replaced with NIST 800-53.5 (MTP) If a system doesn’t fit neatly into one of these definitions, the definitions of system categorization and data classification should be used to determine the appropriate categorization for the system.  MU will also categorize systems not controlled by MU that reside on the MU network (e.g. Ticketmaster and NBA), and work with the owners of those systems to evaluate their controls and assess the level of risk to compromise of MU systems and data.

Did this chart come from NIST or another source? For systems that contain any data classified as confidential such as PII, PCI do we want to change the confidential and integrity from Medium to High? (MTP) The logic is if there is a breach and we follow the incident plan we may have to take systems offline which could result in an outage and the university not being able to provide core functions.

Exceptions to Policy

Exceptions to any of the security policies, e.g. because a specific technology cannot support it or it would be prohibitive to implement the control, will be evaluated based on risk, and must be approved by the Chief Information Technology Officer.  Documentation of these exceptions and their rationale will be captured using Exhibit A of IT Security for IT and Data Professionals, “Approval of IT Security Exception”.

PCI Compliance

The MU IT Security Policies also addresses Payment Card Industry (PCI) Compliance.  The table below provides a cross-reference between the PCI Data Security Standard (DSS) Requirements and the specific sections of the MU IT Security policies where they are addressed.

HIPAA and HITECH Compliance

HIPAA outlines privacy and security safeguards required for covered entities and business associates to protect individual’s identifiable health information, including demographic data and information that relates to the individual’s past, present, or future physical or mental health condition, or related to the provision or payment for healthcare for an individual.  This information is collectively called Protected Health Information (PHI), and when stored electronically, ePHI.  The Health Information Technology for Economic and Clinical Health Act (HITECH) added specific incentives (and enforcement) of the general HIPAA guidelines, including an increase of the civil penalties for willful neglect, and extended certain conditions of HIPAA’s civil and criminal penalties to business associates of healthcare providers.

Most of the information handled by Marywood University is explicitly excluded from HIPAA, such as employment records or student information protected by FERPA.  As a result, most or all information carried by University systems will not store, process or access ePHI. However, because of the relationships between the university and community health care organizations, it is possible that ePHI for non-students could be processed, stored or accessed using University systems or by University staff.  In those situations, those systems must follow HIPAA and HITECH rules for protecting ePHI.  The table below provides a cross-reference between the HIPAA and HITECH requirements and the specific sections of the MU IT Security policies where they are addressed.

Policy Review

The IT Security policies should be reviewed at least annually and updated when business objectives or the risk environment change.

Note:  This addresses PCI requirement 12.11.

References and Related Policies

This section contains any 3^rd party standards, guidelines, or other policies referenced by this policy.

1. NIST Special Publication 800-37 Revision 1, Guide for Applying the Risk Management Framework to Federal Information Systems, National Institute of Standards and Technology, http://csrc.nist.gov/publications/nistpubs/800-37-rev1/sp800-37-rev1-final.pdf
2. FIPS PUB 199, Standards for Security Categorization of Federal Information and Information Systems, Federal Information Processing Standards Publication, Computer Security Division, National Institute of Standards and Technology, http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf
3. NIST Special Publication 800-53 Revision 4, Security and Privacy Controls for Federal Information Systems and Organizations,  National Institute of Standards and Technology, http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf
4. NIST Special Publication 800-171, Protecting Controlled Unclassified Information in Nonfederal Information Systems and Organizations, National Institute of Standards and Technology, http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171.pdf
5. Payment Card Industry (PCI) Data Security Standard, v3.2
6. PCI DSS Quick Reference Guide, Understanding the Payment Card Industry Data Security Standard version 2.0, https://www.pcisecuritystandards.org/documents/PCI%20SSC%20Quick%20Reference%20Guide.pdf
7. Family Educational Rights and Privacy Act, 1974 (FERPA), https://ed.gov/policy/gen/guid/fpco/ferpa/index.html
8. Health Insurance Portability and Privacy Act of 1996 (HIPAA), https://aspe.hhs.gov/report/health-insurance-portability-and-accountability-act-1996
9. HIPAA for Professionals, https://www.hhs.gov/hipaa/for-professionals/index.html
10. HITECH Act Enforcement Interim Final Rule, https://www.hhs.gov/hipaa/for-professionals/special-topics/HITECH-act-enforcement-interim-final-rule/index.html

Related Policies

Related Committees

History

Web Accessibility Test:

Responsibilities