Instituting Controls in Systems Development Gurpreet Dhillon Virginia

Instituting Controls in Systems Development Gurpreet Dhillon Virginia Commonwealth University

Types of Security Breaches n Unauthorized or Accidental Access – – – n Create Read Update Delete Execute (for Applications) All security breaches are the result of System Failures

Types of System Failures n Missing Function – n Additional Function – n System does not perform function that it should System performs function that it should not Incorrect Function – System performs a function that it should, but using incorrect process Brill, Alan E. Building Controls into Structured Systems.

System Failures and Controls n n Usually are the result of a design flaw, not a hardware or software malfunction Controls to manage the occurrence of system failures – – Audit Controls Application Controls Modeling Controls Document Controls

Audit Controls n Audit controls – – – n n Examine Verify Correct Provide a structured framework with which to perform the audit function Record information necessary to perform the audit function

Application Controls n System Requirements – – – n Accuracy Completeness Security Type of application controls – – – Input Processing Output

Model Without Controls Use r On. Line Accoun t n Although security can be assumed, the security control

Model with Control Point Use r User Authentication n On. Line Accoun t The authentication security control point is included; ho

Model with Full Control Included Use r User Authentication Process Failure On. Line Accoun t n Accoun t Locked ? Passed ? Locked Account Instructions The security control point is included, and all functionali

Documentation Controls n n Necessary for ALL stages of the development cycle Answers – – Who, what, when, how, and WHY

Process Improvement Software n n Automated Learning and Discovery Program Management Environments Change Tracking Requirements Tracking

The Systems Security Engineering Capability Maturity Model

SSE - CMM Background n n n n Early 1980 s - Watts Humphrey @ IBM 1993 - National Security Agency (NSA) 1995 - Working Committees 1996 - SSE-CMM v 1. 1 1999 - SSE-CMM v 2. 0 & ISSEA 2002 - ISO-21827 2003 - SSE-CMM v 3. 0

ISSEA Mission Statement n Promote and enhance SSE-CMM n Promote mature security capability to developers, vendors and agencies and ensure integral security in life cycles n Education and networking for community

n Constructed to guide process improvement in the practice of security engineering n Objective: created to advance security engineering as a defined, mature, and measurable discipline

A comparison of software & security engineering problems and their solutions… -schedule overruns -low quality results n Why assurance is important n What is ‘process assurance’

Level 1 Initial or Informal n No required processes

Level 2 Repeatable or Managed n n Assure policy compliance Manage requirements Plan and track projects Measure projects

Level 3 Well Defined n n n Establish improvement infrastructure Identify required processes Identify common processes Deploy and manage processes Collect process-level data Conduct organization-wide training

Level 4 Quantitatively Managed/Controlled n Manage processes quantitatively n Establish capability baselines

Level 5 Optimizing n n n Develop change infrastructure Evaluate and deploy improvements Eliminate causes of defects

SSE-CMM Performance Targets Source: Gartner Group

How processes play a part…. . process cabability: the range of expected results that can be achieved by following a process; a predictor of future project outcomes. process performance: measure of the actual results achieved by following a process maturity: the extent to which a specific process is explicitly defined, managed, measured, controlled, and effective

n The SSE-CMM defines eleven security-related process areas: ■ PA 01 – Administer Security Controls ■ PA 02 – Assess Impact ■ PA 03 – Access Security Risk ■ PA 04 – Access Threat ■ PA 05 – Access Vulnerability ■ PA 06 – Build Assurance Argument ■ PA 07 – Coordinate Security ■ PA 08 – Monitor Security Posture ■ PA 09 – Provide Security Input ■ PA 10 – Specify Security Needs ■ PA 11 – Verify and validate security

Security Engineering PA Maturity Level Placement Maturity Level Objective of Security Engineering Process Maturity Security Engineering PAs 1 n/a None 2 plan security aspects of projects - project planning - project management 3 - coordinate security aspects with internal - Security coordination project groups (systems engineering, - Intergroup software engineering) and external coordination groups (certification team, accreditation - External coordination team) 4 - establish quality metrics - quantify process management 5 Guarantee security aspects of system or product Quantitative Process Management Defect Prevention

Using the SSE-CMM Source Selection System Development HW Vendor Services Security Assessment SSE-CMM SW Vendor Operation and Maintenance

SSE-CMM Model Architecture Capability Domain Continuously Improving Organization Quantitatively Controlled Project Well Defined Planned & Tracked Security Engineering Process Areas Performed Informally Process Areas Initial Capability Levels Common Features Process Areas Common Features Base Generic Practices Base Practices 10/24/96 Base Practices Base Generic Practices

Some benefits…. . • logical approach which provides a foundation for future changes flexible approach which can be molded to fit security needs of any project • covers the entire life cycle of any project, from initial architecture decisions to monitoring of the O/S • along with confidence, all aspects of the security spectrum have been met • this model provides a clear roadmap for generating security requirements

The future of SSE-CMM…. . n n n More plans to implement ideas discussed in SSAM (System Security Appraisal Methodology) Further developments and release of training packages Continue to support other activities such as other CMMs, procurement, and life-cycle support

References n n n n n Brill, Alan E. Building Controls into Structured Systems. Ferraiolo, Karen, Williams, Jeffrey R. , Landoll, Douglas J. “A Capability Maturity Model for Security Engineering” Ferraiolo, Karen “Distinguishing Security Engineering Process Areas by Maturity Levels” Ferraiolo, Karen, Cheetham, Christina “The Systems Security Engineering Capability Maturity Model” http: //www. sse-cmm. org/index. html Gallagher, Lisa A. , Thompson, Victoria “An Update on the Security Engineering Capability Maturity Model Project” Hefner, Rick “System Security Engineering Capability Maturity Model” (1997 conference on software process Improvement Co. SPI) Menk, Charles “The SSE-CMM The Past, The Present and the Future”, October 1997 http: //www. sse-cmm. org/index. html Phillips, Mike “Using a Capability Maturity Model to Derive Security Requirements”, March 2003 http: //www. sans. org/rr/papers/8/1005. pdf “A Systems Engineering Capability Maturity Model, Version 1. 1”, CMU/SEI-95 -003, November 1995 “System Security Engineering – Capability Maturity Model Description Document, Version 2. 0”, April 1999 “System Security Engineering – Capability Maturity Model Description Document, Version 3. 0”, June 2003 “Describing the Capability Maturity Model”, The Gartner Group, September 2004 http: //www. sei. cmu. edu/cmm/ http: //www. sse-cmm. org/index. html