Instituting Controls in Systems Development Gurpreet Dhillon Virginia Commonwealth University.
-
Upload
myra-blair -
Category
Documents
-
view
219 -
download
0
Transcript of Instituting Controls in Systems Development Gurpreet Dhillon Virginia Commonwealth University.
Instituting Controls in Systems Development
Gurpreet Dhillon
Virginia Commonwealth University
Types of Security Breaches
Unauthorized or Accidental Access– Create– Read– Update– Delete– Execute (for Applications)
All security breaches are the result of System Failures
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.
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
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
Application Controls
System Requirements– Accuracy– Completeness– Security
Type of application controls– Input– Processing– Output
Model Without Controls
Although security can be assumed, the security control points are not represented within the model
User
On-Line Account
Model with Control Point
The authentication security control point is included; however, no functionality is specified
On-Line Account
User Authentication
User
Model with Full Control Included
The security control point is included, and all functionality of the control point is modeled
On-Line Account
User Authentication
User Accou
nt Locked?
Passed?
Process Failure
Locked Account Instructions
Documentation Controls
Necessary for ALL stages of the development cycle
Answers– Who, what, when, how, and– WHY
Process Improvement Software
Automated Learning and Discovery Program Management Environments Change Tracking Requirements Tracking
The Systems Security Engineering Capability Maturity Model
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
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
Constructed to guide process improvement in the practice of security engineering
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
Why assurance is important
What is ‘process assurance’
Level 1Initial or Informal No required processes
Level 2Repeatable or Managed Assure policy compliance Manage requirements Plan and track projects Measure projects
Level 3Well Defined Establish improvement infrastructure Identify required processes Identify common processes Deploy and manage processes Collect process-level data Conduct organization-wide training
Level 4Quantitatively Managed/Controlled
Manage processes quantitatively
Establish capability baselines
Level 5Optimizing
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.process maturity: the extent to which a specific process is
explicitly defined, managed, measured, controlled, and effective
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
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 project groups (systems engineering, software engineering) and external groups (certification team, accreditation team)
- Security coordination
- Intergroup coordination
- External coordination
4 - establish quality metrics Quantitative Process Management
- quantify process management
5 Guarantee security aspects of system or product
Defect Prevention
Security Engineering PA Maturity Level Placement
Using the SSE-CMM
Source Selection
Security Assessment SW Vendor
Services
HW Vendor
System Development
Operation and MaintenanceSSE-CMM
10/24/96
ProcessAreas
CommonFeatures
BasePracticesGeneric
Practices
BasePractices
GenericPractices
CommonFeatures
BasePracticesBase
Practices
ProcessAreas
BasePractices
Continuously Improving
Planned & Tracked
Performed Informally
BasePractices
SSE-CMM Model Architecture
Security EngineeringProcess Areas
Organization
Project
InitialCapability Levels
Well Defined
Quantitatively Controlled
ProcessAreas
CapabilityDomain
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…..
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 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