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

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

3. Types of System Failures n Missing Function – System does not perform function that it should n Additional Function – System performs function that it should not n 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 n Usually are the result of a design flaw, not a hardware or software malfunction n Controls to manage the occurrence of system failures – Audit Controls – Application Controls – Modeling Controls – Document Controls

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

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

7. Model Without Controls n Although security can be assumed, the security control points are not represented within the model Use r On- Line Accou nt

8. Model with Control Point n The authentication security control point is included; however, no functionality is specified On- Line Accou nt User Authentication Use r

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

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

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

12. The Systems Security Engineering Capability Maturity Model

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

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

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

16. 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’

18. Level 1 Initial or Informal n No required processes

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

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

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

22. Level 5 Optimizing n Develop change infrastructure n Evaluate and deploy improvements n 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. n 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. Maturity Level Objective of Security Engineering Process Maturity Security Engineering PAs 1n/aNone 2plan security aspects of projects- project planning - project management 3- coordinate security aspects with internal project groups (systems engineering, software engineering) and external groups (certification team, accreditation team) - Security coordination - Intergroup coordination - External coordination 4- establish quality metricsQuantitative Process Management - quantify process management 5Guarantee security aspects of system or product Defect Prevention Security Engineering PA Maturity Level Placement

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

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

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….. n More plans to implement ideas discussed in SSAM (System Security Appraisal Methodology) n Further developments and release of training packages n Continue to support other activities such as other CMMs, procurement, and life-cycle support

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