SynapseIndia Feedback on Security Quality of

Infrastructure Software Part 1

Outline
Motivation
Proposed strategy
Detailed actions
Conclusion

Theme Life Cycle Threats

There is not a means for automated

testing of large software, both static and

mobile code, to detect, identify
malicious code, sleeper codes, and
exploitable vulnerabilities and to
determine and understand the potential
impact on the life-cycle of the codes.
Current testing approaches are largely
manual rather than automated.
CSIIR Workshop Themes document

A Recommended Strategy
Software security vulnerabilities are often caused by

defective specification, design, and implementation.

require that software be designed with security at
the very heart of the design process
Establish a security verification and validation
program to evaluate different software development
processes and practices for effectiveness in
producing secure software.
Certify those processes demonstrated to be effective
for producing secure software.
Security Across the Software Development Lifecycle Task Force

Recommended Practices
Statistical testing - Usage based testing permits

valid statistical estimation of quality with respect to

all the executions not tested and tends to find any
remaining high-failure-rate defects early.
Production testing - Two strategies are testing
security functionality with standard functional testing
techniques, and risk-based security testing based on
attack patterns and threat models. A good security
test plan (with traceability back to requirements)
uses both strategies.
Process models - organizations can use the goals
and attributes defined in process models as highlevel guides for defining and improving their
management and engineering processes in the ways
they feel are most appropriate for them.
Security Across the Software Development Lifecycle Task Force

SEI
The security of a software-intensive system is
directly related to the quality of its software1.
Over 90% of software security incidents are

caused by attackers exploiting known software

defects.
Analysis of 45 e-business applications showed
that 70% of security defects were design defects.
Experienced and capable software engineers
inject, on average, one defect every nine lines of
code.
A one million line of code systems typically
contains 1,000-5,000 defects when shipped.

A Final Source
One of the key things that developers can do to

help secure their systems is to write code that can

withstand attack and use security features
properly.

Defend Your Code with Top Ten Security Tips Every

Developer Must Know

8 out of 10 tips are directly programming issues

Basic Assumptions

Testing early is cheaper than testing later.

System test of a system with j modules and k

experiments (iterations or different implementations

for a given interface) results in the following cost of
testing
j
t

T ( j , k ) [(k 1) 1]c

Where ct is the cost per test.

Module-level tests with j modules and k experiments results in

T ( j , k ) jkct
Baldwin and Clark. Design Rules The Power of Modularity,
volume 1, MIT Press, 2000.

Basic assumptions - 2
Though estimates vary, the cost of removing defect increases
dramatically later in the life cycle.
Design

IBM

Boehm

Remus

Design
Inspection

Code

Development
Test

1.5

60
15 to 40

20

Acceptance Production

100
30 to 70

40 to
1000

82

Ackerman

2 to 10

Russell

2 to 4

30

Premise
Our premise is that poorly written software

will contain more vulnerabilities than well

written software where the security quality
attribute is a design driver.
Current views of security often take a
defensive approach. Some of the security
infrastructure even adds to the security risk
due to the complexity it adds to the product.
We propose an offensive approach in which
security is a key design driver and a priority
throughout the development process.

Context
A chain of

Domain
Expert

User:
Frequency:
See Also:

Use Case Modeling

Systems
Engineering

Class Name
Responsibility

Super Class
Collaborator

Requirements
model inspection
Domain
Analysis

Client
Analysis
model inspection

Incremental
Integration
and
System Testing

Class Specification

Application
Analysis
Class
Design

Class
Derivation

Class
Reuse

Use Case Name:

Use:
User:
Frequency:
See Also:

Implementation

Architectural
Design

ntr

olle
r

Application Use Cases

Analysis model inspection

Co

quality should
be threaded
through the
entire process
so that
validation is
most effective
and efficient.

Use Case Name:

Use:

Requirements

Refinement

Model
Testing
Class Delivery

Architecture
inspection
View

Class
Development

Cluster
design inspection

A Proposed Strategy
Develop method engineering tactics and guidelines

that enhance the security quality of the software

through improved processes.
Structure architecture evaluation techniques to focus
on security by searching for static security patterns.
Discover and capture test patterns that correspond to
dynamic security patterns.
Develop focused test techniques to effectively explore
security test patterns while reducing the test suite
size.
Create a defect model for security that can be used to
predict types and number of security vulnerabilities in
scientific codes.

Action Develop method engineering techniques

Method engineers create custom-made processes to

help a project achieve specific goals.

The goal of being secure needs to be
operationalized so that these engineers can assemble
methods in ways that enhance the security of the
software product built using their processes.
This task would involve extending the Software
Process Engineering MetaModel1 (SPEM) standard to
define security-specific constructs. The model would
be automated using existing tools such as MetaEdit+.
1

Software Process Engineering Metamodel, version 1.1,

Object Management Group (OMG), 2005.

Action Develop method engineering techniques

-2
The security-oriented method fragments

would be suitable to integrate into

processes defined in the context of the
SPEM.
Process audits could evaluate the strength
of the security aspect of the process, once it
is explicitly embedded in the process, just
as other qualities are validated.
Deliverables: A process definition guide that
would show how to design security-centric
development process fragments, an
assembly guide, and an example process.

Action Create architecture security analysis

Architects have techniques that they apply to an architecture in order

to improve the behavior of the architecture with respect to classes of

security threats1.
Assuring system survivability requires showing that the system
architecture is adequately resilient to likely patterns of attack 2.
One approach to architecture design is to identify quality attributes
for the architecture and make design decisions that enhance the
desirable qualities and degrade the less desirable ones.
Architecture evaluation techniques such as the architecture trade-off
analysis method (ATAM) can be used to focus architecture evaluations
on the security quality through security-specific scenarios.
One aspect of this task would be to develop a set of architecture-level
security scenarios that would guide the evaluation of an architecture
for the security quality.

Security and Survivability Reasoning Frameworks and Architectural

Design Tactics. CMU/SEI-2004-TN-022
Architectural Refinement for the Design of Survivable Systems
CMU/SEI-2001-TN-008

Action Create architecture security analysis - 2

This evaluation can be automated if the architects use

a formal architecture description language (ADL).

Our current implementation uses the Architectural
Analysis and Design Language (AADL) from the Society
of Automotive Engineers (SAE) and Eclipse plug-ins.
A second part of the task could be to identify standard
mechanisms for representing security in an
architecture description so that security patterns could
be automatically recognized.
Deliverables: A set of validation scenarios and specific
architecture tactics for recognizing security
vulnerabilities at the architecture level

Current implementation as Eclipse plug-in for

AADL