Information Risk Management January 2013

1. Information Risk ManagementJanuary 2013 Lisa Ho, IT Policy Manager Paul Rivers, System and Network Security

2. Today’s Goals Broad outline of Information Risk Management Key concepts, current work, future directions Highlight topics for future work Solicit feedback

3. Information Risk Management Strategy BUS-80 Cyber-Insurance? A net under the trapezeis not enough.

4. A cultivated landscape

5. A cultivated landscape A multi-faceted Information Risk Management Program focused on achieving a campus environment where information security and privacy are fundamentalelements of information management practices.  The program shall include campus policy, resources, processes and services to create a landscape that supports systematicand consistentdeploymentand maintenanceof secure and privacy-protecting campus information systems.

6. Not Johnny Appleseed Campus information systems require long-term care and maintenance.

7. Risk Confidentiality Information risk at UCB to date: • Driven by technical security concerns • Focus primarily on confidentiality Future information risk domains: • The rest of the CIA triad: Integrity, Availability • Privacy • Accessibility Technical security is the wrong driver: • At UCB, security has developed bottom-up • from monitoring the network towards a more comprehensive information security program • Data stewards must play an active role in setting risk tolerances and information handling requirements • Broad agreement at a senior leadership level on risk tolerance is required so that expectations of an information risk management program match both funding levels and the directing of campus priorities from the top down Integrity Availability

8. Roles and Responsibilities Critical topic, but not today’s focus Addressed today: • IT Policy • Campus Information Security (SNS) • Data proprietors • System proprietors • Resource custodians Future discussions: • Audit, Privacy

9. UCB Information Risk Management Program OCIO – Dec 5, 2012

10. UCB Information Risk Management Program OCIO – Dec 5, 2012

11. 1. Data Classification Standard New campus standard: https://security.berkeley.edu/data-classification Tieredby confidentiality risk From PL 0 (no impact) to PL 3 (extreme impact) • PL 1=Student FERPA data • PL 2=Notice triggering data (PII, PCI, HIPAA, etc) “Protection level” is a more precise term than the old “restricted data”

12. 2. Minimum Security Standards and Guidelines UC Berkeley security policies cover a variety of topics: • Departmental security contacts • NAT policy • Electronic Communications Security Standard (future?) • MSSND: Minimum Security Standards for Networked Devices • MSSEI: Minimum Security Standards for Electronic Information

13. MSS and Guidelines (2 of 4) MSSND vs MSSEI MSSND deals with connecting to the campus network MSSND applies equally to printers, PlayStations, washing machines, microscopes, student laptops, or a home system that connects via the VPN • If a device is connected to the campus network, MSSND applies • Contrast with the ATT WiFi network on campus MSSEI specifies the minimum set of controls that an information system must implement in order to mitigate confidentiality risk to a level acceptable per campus policy

14. MSS and Guidelines (3 of 4) Key MSSEI points: • Codifies decisions about risk tolerance • A collection of standards, one per protection level • Based on industry standards (SANS Top 20 Critical Controls) • A campusminimum; other standards may apply • Applies wherever the data is stored, processed or transmitted • Scope very different from MSSND: 3 broad categories of devices • Individual • Privileged • Institutional

15. MSS and Guidelines (4 of 4) Future directions Extend MSSEI controls and assessments to cloud/vendor environments (both SaaS and IaaS) • Work to begin in Q2 2013 • Major concern: consistency between local and external requirements UC IT Accessibility Policy • An example of a policy that applies to information systems that is not a security requirement but is related to risk • Current status: Academic Senate review • Requirements would include: • authority/responsibility, prioritization, • design process, procurement, • training, awareness campaign, • compliance monitoring, evaluation

16. 3. Data Registration Units on campus operate very independently, yet risk is institutional • Data registration is key for resolving this tension Without registration: • No institutional management of information risk is possible • Offering effective campus-level programs and services is challenging to impossible Registration only became a requirement with the new MSSEI in effect July 2013

17. Data Registration (2 of 3) After every significant breach on campus, data registration is a hot topic: • We know the data is out there, but often we don’t know where exactly • Breached notice-triggering information systems are often not registered or mis-registered

18. Data Registration (3 of 3) Registrationis not busywork. Things change as a result: • Incident response timelines • Vulnerability scanning schedules • Additional intrusion detection sensors • Additional analyst time spent analyzing security data related to that system • Packet capture for forensic purposes • Capacity planning and scheduling of more comprehensive security offerings • Additional reporting of relevant security and risk metrics Goldilocks principle: register the right amount • Failure to register means systems fly under the radar: • incomplete risk management picture for campus leadership • Over-registration wastes campus resources and skews planning efforts

19. 4. Campus Programs and Services Not all (or even most) controls are implemented by SNS • Resource custodians assume most of the responsibility Some controls can be and are best implemented at a campus level: • More cost effective • Provides capabilities not possible when implemented per-system or per-unit • Better governance, checks and balances (privacy) SNS programs and services align with the controls specified in our campus security standards

20. Programs and Services (2 of 2)

21. 5. Security Operations and Risk Assessments Security operations collects metrics and raises issues after systems are in production • Every system reviewed has had significant security issues • All systems would have benefited from an up-front review • In-house systems could have developed more realistic resourcing plans and a TCO picture • Purchased systems could have utilized knowledge of risk presented by the system in vendor negotiations prior to purchase

22. Sec Ops and Risk Assessments (2 of 4) Goal: table-top assessment of an Information Risk Management Planfor all protection level 1 or higher systems prior to purchase or implementation • Resource constraints limit hands-on assessments to protection level 2 and 3 systems • Current pilot of this starting with the Technology Project Office

23. Sec Ops and Risk Assessments (3 of 4) Possible future discussion Add a resource requirement to MSSEI so that funding is allocated to maintain the system and address risk as it is identified • To our knowledge, no one includes this as part of the operating costs for information systems and infrastructure • Compared to industry, as a percentage of IT budget we underspend on security, and the underspend happens largely here • Unless we address the funding problem head-on, we will be forever stuck, unable to act on serious risk issues we identify

24. Sec Ops and Risk Assessments (4 of 4) Risk assessments are required for reasons other than measuring compliance with campus standards • Regulatory compliance: HIPAA, PCI • InCommon Silver certification and CalNet proxy auth • Researchers must attest they meet standards to receive research data: California Health and Human Services CPHS requirements Future direction: As stated above, extend assessment methodologiesto cloud and vendor services

25. 6. Incident Management and the Exception Process Incident: detection of non-compliance with a required campus standard • An incident is not a breach • SNS security ticket revamp effort in 2013: make clear required action and time frame Failure to respond and resolve the incident in the specified time frame will escalate according to campus policy, ultimately resulting in termination of network access for the affected devices or systems If an incident cannot be resolved in the specified time frame, filing for a Minimum Security Standard Exception is required to avoid escalation

26. Incident Management and the Exception Process (2 of 3) An exception petition requires several items: • The specific devices and system in question • The protection level of the data processed by the devices in question • What standards are not met • What alternative steps have been taken to mitigate the risk presented by not meeting the required standards • The date by which the devices/system will be brought up to standard Most applications neglect #4. In some cases, simply accepting the risk may be acceptable, but this is not the default. • Either way, #4 must be explicitly addressed in the exception request

27. Incident Management and the Exception Process (3 of 3) Responsibility for evaluating exception requests has floated around the organization. • CISPC chair, IT Policy • Current plan is to move this to Security, with Policy as the first level of appeal Future discussion Should the ITLG be a second tier of escalation for registered non-public information systems and other significant cases?

28. 7. Metrics and Reporting Three levels of reporting today: • Monthly security metrics to security contacts • Application security testing results, risk assessments to resource custodians and proprietors • Annual security reports to campus leadership Ongoing development of what metrics we collect and how we report it. • This effort is in its infancy • Major reworking of backend systems has already happened and will continue in order to support this effort

29. 8. Regular Landscape Review Security standards can and will evolve • Today’s MSSEI recommendations are tomorrow’s requirements (really!) • Campus security programs will be re-evaluated and adjusted, added or dropped in response to changing security standards • Threats will evolve and drive our decision to push our view of risk past just confidentiality • Example: recent DDoS attacks against libraries

30. Conclusion If you remember six things from this, let them be these six: • It’s “data protection levels” not “restricted data” • Data stewards set risk tolerances; MSSEI sets protections to meet these tolerances (everywhere!) • MSSND is about connectingto the network; MSSEI is about protecting campus information assets • Registration is a critical step in the risk management effort • Security programs and services are aligned with our security standards • Information risk management must be built into the process from the start, and include the planning and budgeting stages

31. Feedback Yes, please. In addition to discussion here, Lisa and Paul can meet with you individually to discuss any topic in more depth.