Protecting Your Institutional Data: If You Don’t Do It, Who Will?

1. Protecting Your Institutional Data: If You Don’t Do It, Who Will?

2. Data and Application Issues • Processing, Storage and Transmission of Sensitive Data in Third Party Applications • Where is sensitive data being stored and accessed? • Who has access to it? • What controls are in place to manage and/or limit access? • Application Sprawl • Awareness • Regulatory Requirements

3. Questions to Ask Yourself • What data do we as an Institution deem as sensitive? • Where is sensitive data being stored, processed or transmitted? • Who has access to sensitive data? • What controls are in place to secure applications which have sensitive data? • Are we addressing all controls as required by the USM Security Guidelines and DOIT Security Policy? (including all controls in NIST 800-53) • What processes are in place to manage changes to applications that have sensitive data? • Are we doing enough?

4. A Scope of Work to Answer Those Questions and Address the Underlying Issues • Template Preparation • Develop data capture templates and assessment questions • Identify NIST Access Control Policy Categories and/or individual controls to include in application review • Confirm sensitivity level when controls are applicable • Application Review • Phase One: Data Capture • Review all applications, capture required data and determine application sensitivity level • Classify Information Types by Data Sensitivity Risk Level Designation • Phase Two: Control Review • Obtain detailed information on sensitive data, • Review controls for sensitive applications and verify through documentation or by demonstration • Develop Recommendations • Procedural Documentation • Develop onboarding documentation for all new applications • Develop easily understandable access control procedure documentation for all applications • Develop easily understandable change control procedures for all applications

5. Why NIST? Addresses security standards established by DOIT, interpreted in the context of USM. Framework developed using applicable guidelines in NIST. Only those controls designed to protect systems with a ‘moderate’ category level are included. Minimum information security requirements based on categorizations by FIPS 199 and 200

6. Use NIST Guidelines to Map Data to Sensitivity to Risk Policy Use the high water mark to determine the risk level of the individual information type AND the risk level of the application. Information Type 1: {(confidentiality, HIGH), (integrity, MODERATE), (availability, MODERATE)} = HIGH Information Type 2: {(confidentiality, MODERATE), (integrity, LOW), (availability, LOW)} = MODERATE The application is classified as a HIGH. Correlate this to Institution-defined risk levels. What is impact to the Institution if the confidentiality, integrity or availability of this data is compromised?

7. Who Should Determine Sensitivity? Possible Sources: • Data Stewards / Data Governance Committee • Application/Business Owners • Information Technology Owners • IT Security Team What We Found: • Impacts associated with integrity and Availability made sense at the department level • Confidentiality was applicable to the Institution as a whole • Confidentiality was always the driver for the risk level

8. Identify NIST Controls to include in Application Review • Control Families from FIPS-200: • Access Control (AC) • Awareness and Training (AT) • Audit and Accountability (AU) • Certification, Accreditation and Security Assessments (CA) • Configuration Management (CM) • Contingency Planning (CP) – Out of Scope • Identification and Authentication (IA) • Incident Response (IR) – Out of Scope • Maintenance (MA) – Out of Scope • Media Protection (MP) – Out of Scope • Physical and Environmental Protection (PE) • Planning (PL) • Personnel Security (PS) • Risk Assessment (RA) • System and Services Acquisition (SA) • System and Communications Protection (SC) • Systems and Information Security (SI) Start by segregating controls by Application, System or Organization

9. Confirm and tailor baselines for system level • Are all of the controls applicable to an application-level review? For example, boundary protection is not an application concern, it’s a network infrastructure concern. • Are any of the controls listed “Common Controls? That is, managed by an organization entity other than the information system owner.

10. Are all Controls Equal? • NIST identifies a priority associated with each control • May choose to develop internal priority based on other sources (ie USM) Chart removed

11. Control Segregation • 67 Application-level controls (42 Prioritized as higher) • 56 Organization-level controls • 65 System-level Controls • 21 Not Applicable *

12. Phase 1: Data Capture • Capture basic information on the application, including a description, user types and roles • Identify information types stored in the application • Assess impact of confidentiality, integrity and availability for each application • Identify integration points with other applications • Capture all “sensitive” data stored in the application or queried from other sources • Identify current procedures to gain access to the application

13. Data Classification • Consolidate data capture results • Review information types by application • Assign confidentiality impact across all information types • Categorize application risk level • Develop reports to illustrate risk levels by institution, department, # of occurrences, database type, application host, and use of specific PII (i.e. SSN and Credit Card Number) • Identify applications requiring control review.

14. Phase 2: Control Review • For each application deemed “sensitive”, review all applicable controls for the given sensitivity category • Verify selected controls through documentation or demonstration • Capture all instances of failed controls and document • Pass/fail the application

15. Making a Control Review Make Sense Develop questions and guidance for each control Chart removed

16. Final Report • Provide pass/fail statistics for each application and illustrate trending across all applications by control. • Develop action items for each application addressing areas where additional follow up is required. • Make recommendations associated with the appropriateness of process and procedures associated with the access and storage of data. • Make recommendations on subsequent security assessments.

17. Slide removed

18. Slide removed

19. Ongoing Assessment Program • Identification of compensating security controls and common controls, or where the baseline should be tailored given the environment at Towson • 6 month plan to address suggestions, including removal of unnecessary data storage, changes to user access rights, implementation of controls, etc. • Annual reassessment of applications with a risk level of High • Use the System-level controls to drive additional testing or projects • Use the Organization-level controls to develop institution-wide policies or procedures • Verification of adhoc controls through demonstration