Considering Operational Security Risks During System Development
Pittsburgh, PA 15213-3890 Considering Operational Security Risks During System Development Christopher Alberts Audrey Dorofee Carol Woody Sponsored by the U.S. Department of Defense © 2003 by Carnegie Mellon University page 1 OCTAVE® Operationally Critical Threat, Asset, and Vulnerability EvaluationSM ® OCTAVE is registered with the U.S. Patent and Trademark Office by Carnegie Mellon University SM Operationally Critical Threat, Asset, and Vulnerability Evaluation is a service mark of Carnegie Mellon University. © 2003 by Carnegie Mellon University page 2 Operational Focus PreDevelopment Activities RFP concept Development Activities design requirements Post Development Activities testing build integration acceptance operation OCTAVE was developed for managing security risks in the operational environment. © 2003 by Carnegie Mellon University page 3 A Complex Domain Threats • people inside your organization • people outside your organization • system problems • other problems © 2003 by Carnegie Mellon University Security Practices • organizational practices • technical practices People Involved • information technology (IT) staff • general staff • managers • contractors • service providers • partners and collaborators page 4 Organizational Gap © 2003 by Carnegie Mellon University page 5 OCTAVE Approach - 1 © 2003 by Carnegie Mellon University page 6 OCTAVE Approach - 2 OCTAVE is at the center of a risk management approach to information security. © 2003 by Carnegie Mellon University page 7 What Is OCTAVE? OCTAVE is a risk-based strategic assessment and planning technique for security. • It leverages people’s knowledge of their organization’s security-related practices and processes to capture the current state of security practice within the organization. • Risks to the most critical assets are used to prioritize areas of improvement and set the security strategy for the organization. © 2003 by Carnegie Mellon University page 8 OCTAVE Phases OCTAVE is divided into the following three phases: • Phase 1: Build Asset-Based Threat Profiles • Phase 2: Identify Infrastructure Vulnerabilities • Phase 3: Develop Security Strategy and Plans © 2003 by Carnegie Mellon University page 9 © 2003 by Carnegie Mellon University page 10 OCTAVE Analysis Team • An interdisciplinary team – consisting of - business or mission-related staff - information technology staff © 2003 by Carnegie Mellon University page 11 Key Questions Can some operational risks be reduced by addressing them during development? Can the OCTAVE approach be expanded to address operational risks during development? © 2003 by Carnegie Mellon University page 12 The Value in Addressing Risks Earlier Lower cost to mitigate security risks More stable solutions can be implemented Solutions carry forward with future upgrades Builds on existing operational planning activities Builds a consistent vocabulary between customers, developers, users, and maintainers © 2003 by Carnegie Mellon University page 13 Challenges in Addressing Risks Earlier Only a subset of operational security risks can be addressed early in the lifecycle. Solutions implemented early in the lifecycle may affect security-related activities during operation and maintenance. © 2003 by Carnegie Mellon University page 14 Addressing Security Issues Earlier in the Lifecycle PreDevelopment Activities RFP concept Development Activities design requirements Post Development Activities testing build integration acceptance operation The focus for managing some operational security risks can be shifted earlier in the lifecycle. © 2003 by Carnegie Mellon University page 15 Security Risk Management Activities Component protection Define target system Determine security attributes Identify threats Identify risks Develop protection plan Procedural protection © 2003 by Carnegie Mellon University page 16 Define Target System Component protection Define target system Determine security attributes Identify threats Identify risks Develop protection plan Procedural protection © 2003 by Carnegie Mellon University page 17 Target System What components are part of the target system? • software applications (interface modules, database modules, etc.) • hardware • operating environment • COTS What critical information is stored, processed, and transmitted by the target system? © 2003 by Carnegie Mellon University page 18 Determine Security Attributes Component protection Define target system Determine security attributes Identify threats Identify risks Develop protection plan Procedural protection © 2003 by Carnegie Mellon University page 19 Security Attributes What is important about the critical information on the target system? • Who will be authorized to view it? (confidentiality) • To what extent should the information be accurate and complete? Who will be authorized to modify it? (integrity) • How often must the information be available? (availability) © 2003 by Carnegie Mellon University page 20 Identify Threats - 1 Component protection Define target system Determine security attributes Identify threats Identify risks Develop protection plan Procedural protection © 2003 by Carnegie Mellon University page 21 Threats Who or what could threaten the target system? How could security attributes be affected? Are system components interfaced such that a compromise of one puts others at risk? © 2003 by Carnegie Mellon University page 22 Network Attacks - 1 Consider how deliberate/malicious network-based attacks could affect the target system. How could system components be compromised by these attacks? How could security attributes be affected as a result? • Can information be disclosed to unauthorized people? • Can information be modified by unauthorized people? • Can information be destroyed? • Can access to information be interrupted? © 2003 by Carnegie Mellon University page 23 Network Attacks - 2 Consider how accidental/non-malicious network-based events could affect the target system. How could system components be compromised by these events? How could security attributes be affected as a result? • Can information be disclosed to unauthorized people? • Can information be modified by unauthorized people? • Can information be destroyed? • Can access to information be interrupted? © 2003 by Carnegie Mellon University page 24 Network Attacks - 3 Consider how viruses and other malicious code could affect the target system. How could system components be compromised by these events? How could security attributes be affected as a result? • Can information be disclosed to unauthorized people? • Can information be modified by unauthorized people? • Can information be destroyed? • Can access to information be interrupted? © 2003 by Carnegie Mellon University page 25 Identify Risks Component protection Define target system Determine security attributes Identify threats Identify risks Develop protection plan Procedural protection © 2003 by Carnegie Mellon University page 26 Risk Identification What is the potential impact on the organization resulting from each threat? Consider what might happen to the operational environment (organization, system users, etc.) if the target system is compromised and critical information is • disclosed • modified • destroyed • inaccessible Risk = Threat + Impact © 2003 by Carnegie Mellon University page 27 Potential Impacts on the Operational Environment Lost revenue Increased operational costs Reputation damage Fines and penalties Safety and health of users Others © 2003 by Carnegie Mellon University page 28 Develop Protection Plan - 1 Component protection Define target system Determine security attributes Identify threats Identify risks Develop protection plan Procedural protection © 2003 by Carnegie Mellon University page 29 What is a Protection Plan? A plan to reduce operational security risks Actions in the plan primarily mitigate threats to system components. © 2003 by Carnegie Mellon University page 30 Protection Plan - 1 Who needs to be involved in developing the protection plan? • users • operational staff • 3rd parties • people responsible for other components • developers • customers • others © 2003 by Carnegie Mellon University page 31 Protection Plan - 2 What is the overall protection plan for the target system? Component Protection • software applications • hardware • operating environment (operating system, I/O management, networks) • COTS Procedural Protection • transition from development to operational environment • operational contingency plans • access control management © 2003 by Carnegie Mellon University page 32 Component Protection - 1 Software Applications What technological measures should be used to restrict user access to software applications? What technological measures should be used to authenticate users to software applications? What degree of authentication is required? Should encryption be employed to protect information while in storage and during transmission? © 2003 by Carnegie Mellon University page 33 Component Protection – 2 Software Applications (cont.) How can the software architecture be designed to recognize, resist, and recover from network-based threats? How might these options affect other quality attributes? What monitoring capabilities are required to recognize threats to the software applications as they are occurring? © 2003 by Carnegie Mellon University page 34 Component Protection – 3 Hardware What expectations do you have for hardware security? Who is responsible for implementing them? Are these expectations sufficient? How will they be verified? By whom? © 2003 by Carnegie Mellon University page 35 Component Protection – 4 Operating Environment What expectations do you have for operating environment security? Who is responsible for implementing them? Are these expectations sufficient? How will they be verified? By whom? © 2003 by Carnegie Mellon University page 36 Component Protection - 5 COTS What expectations do you have for COTS security? Who is responsible for implementing them? Are these expectations sufficient? How will they be verified? By whom? © 2003 by Carnegie Mellon University page 37 Procedural Protection - 1 Transition from Development to Operational Environment How should hardware and software components be locked down during the transition? What procedures should be in place for maintaining the target system (especially validating the integrity of production software) during the transition? What helpdesk support procedures should be in place during the transition? © 2003 by Carnegie Mellon University page 38 Procedural Protection - 2 Operational Contingency Plans How should operational backup procedures be modified or updated to accommodate the security attributes of the target system? How should operational contingency plans be modified or updated to accommodate the security attributes of the target system? © 2003 by Carnegie Mellon University page 39 Procedural Protection - 3 Access Control Management Who is monitoring and managing access control to the target system? What are the requirements for access control? How should the access of contractors and vendors with support contracts be controlled? What training and support will users need for accessing and using the target system? © 2003 by Carnegie Mellon University page 40 Complicating Factors Incomplete and/or poorly defined operational security standards and requirements Lack of consideration of security within contracts for outsourced development, COTS software, and/or operational support Lack of operational expertise within the development life cycle Significant unknowns with respect to the operational environment during development © 2003 by Carnegie Mellon University page 41 Summary - 1 Development Activities Residual Risk Start Uncertainty Finish Perfect System Certainty At the end of development, some degree of uncertainty remains with respect to the target operational environment. This uncertainty translates into the residual risk that must be managed during operations and maintenance. © 2003 by Carnegie Mellon University page 42 Summary - 2 Residual Risk Development Activities Start Uncertainty Certainty New Start By addressing some operational security risks during development, the residual risk that must be managed during operations and maintenance is reduced. © 2003 by Carnegie Mellon University Perfect System Finish New Finish Reduced Residual Risk page 43 Questions? © 2003 by Carnegie Mellon University page 44 For Additional Information Telephone 412 / 268-5800 Fax 412 / 268-5758 Internet [email protected] (for general information) [email protected] (for licensing inquiries) WWW http://www.cert.org/octave U.S. mail Customer Relations Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 © 2003 by Carnegie Mellon University page 45
![Type-Directed, Whitespace-Delimited Parsing for Embedded DSLs [GlobalDSL13] School of Computer Science](http://cdn1.abcdocz.com/store/data/000388456_1-6d784f7b9826425b340259b5ba9be575-250x500.png)
© Copyright 2024