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
On-Line Account
User Authentication

• The authentication security control point is
  included however, no functionality is specified

9
Model with Full Control Included
User
Account Locked?
User Authentication
Passed?
Process Failure
On-Line Account
Locked Account Instructions

• The security control point is included, and all
  functionality of the control point is modeled

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 _at_ 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

17
(No Transcript)
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
Maturity Level Objective of Security Engineering Process Maturity Security Engineering PAs
1 n/a None
2 plan security aspects of projects -         project planning
2 plan security aspects of projects -         project management
3 - coordinate security aspects with internal project groups (systems engineering, software engineering) and external groups (certification team, accreditation team) -         Security coordination
3 - coordinate security aspects with internal project groups (systems engineering, software engineering) and external groups (certification team, accreditation team) -         Intergroup coordination
3 - coordinate security aspects with internal project groups (systems engineering, software engineering) and external groups (certification team, accreditation team) -         External coordination
4 -         establish quality metrics Quantitative Process Management
4 -         quantify process management Quantitative Process Management
5 Guarantee security aspects of system or product Defect Prevention
27
Using the SSE-CMM
28
(No Transcript)
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