Instituting Controls in Systems Development

1. Instituting Controls in Systems Development Gurpreet Dhillon Virginia Commonwealth University

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

3. Types of System Failures • Missing Function • System does not perform function that it should • Additional Function • 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.

4. System Failures and Controls • 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

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

6. Application Controls • System Requirements • Accuracy • Completeness • Security • Type of application controls • Input • Processing • Output

7. Model Without Controls User On-Line Account • Although security can be assumed, the security control points are not represented within the model

8. Model with Control Point User User Authentication On-Line Account • The authentication security control point is included; however, no functionality is specified

9. Model with Full Control Included User Account Locked? User Authentication Process Failure Passed? • The security control point is included, and all functionality of the control point is modeled On-Line Account Locked Account Instructions

10. Documentation Controls • Necessary for ALL stages of the development cycle • Answers • Who, what, when, how, and • WHY

11. Process Improvement Software • Automated Learning and Discovery • Program Management Environments • Change Tracking • Requirements Tracking

12. The Systems Security Engineering Capability Maturity Model

13. SSE - CMM Background • Early 1980s - 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

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

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

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

18. Level 1Initial or Informal • No required processes

19. Level 2Repeatable or Managed • Assure policy compliance • Manage requirements • Plan and track projects • Measure projects

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

21. Level 4Quantitatively Managed/Controlled • Manage processes quantitatively • Establish capability baselines

22. Level 5Optimizing • Develop change infrastructure • Evaluate and deploy improvements • Eliminate causes of defects

23. SSE-CMM Performance Targets Source: Gartner Group

24. 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. process maturity: the extent to which a specific process is explicitly defined, managed, measured, controlled, and effective

25. The SSE-CMM defines eleven security-related process areas: ■ PA01 – Administer Security Controls ■ PA02 – Assess Impact ■ PA03 – Access Security Risk ■ PA04 – Access Threat ■ PA05 – Access Vulnerability ■ PA06 – Build Assurance Argument ■ PA07 – Coordinate Security ■ PA08 – Monitor Security Posture ■ PA09 – Provide Security Input ■ PA10 – Specify Security Needs ■ PA11 – Verify and validate security

26. Security Engineering PA Maturity Level Placement

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

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

29. 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

30. The future of SSE-CMM….. • 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

31. References • 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 CoSPI) • 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