Instituting Controls in Systems Development

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