Software Assurance for BusinessSystems Integrators

Dr. Sumeet Malhotra

Global Director of Advanced Research & StandardsStrategy, UNISYS

Member of Architecture Board, OMG

Sumeet.malhotra@unisys.com

Sumeet_malhotra@omg.org

Security Additions to CMMI and FAA-iCMM

Goal 1 – An infrastructure for safety and security is established and maintained.

• Ensure safety and security awareness, guidance, and competency.

• Establish and maintain a qualified work environment that meets safety and security needs.

• Ensure integrity of information by providing for its storage and protection and controlling access and distribution of information.

• Monitor, report, and analyze safety and security incidents and identify potential corrective actions.

• Plan and provide for continuity of activities with contingencies for threats and hazards to operations and the infrastructure.

Goal 2 – Safety and security risks are identified and managed.

• Identify risks and sources of risks attributable to vulnerabilities, security threats, and safety hazards.

• For each risk associated with safety or security, determine the causal factors, estimate the consequence and likelihood of anoccurrence, and determine relative priority.

• For each risk associated with safety or security, determine, implement, and monitor the risk mitigation plan to achieve anacceptable level of risk.

Goal 3 – Safety and security requirements are satisfied.

• Identify and document applicable regulatory requirements, laws, standards, policies, and acceptable levels of safety andsecurity.

• Establish and maintain safety and security requirements, including integrity levels, and design the product or service to meetthem.

• Objectively verify and validate work products and delivered products and services to assure safety and security requirementshave been achieved and fulfill intended use.

• Establish and maintain safety and security assurance arguments and supporting evidence throughout the life cycle.

Goal 4 – Activities and products are managed to achieve safety and security requirements and objectives.

• Establish and maintain independent reporting of safety and security status and issues.

• Establish and maintain a plan to achieve safety and security requirements and objectives.

• Select and manage products and suppliers using safety and security criteria.

• Measure, monitor, and review safety and security activities against plans, control products, take corrective action, and improveprocesses.

Vulnerability Removal Filters

Correctness by Construction methodologyof Praxis High Integrity Systems

Process for developing High Integrity Software

The seven key principles of Correctness by Construction are

1.Expect requirements to change.

2.Know why you're testing.

3.Eliminate errors before testing.

4.Write software that is easy to verify.

5.Develop incrementally.

6.Human Intelligence is critical – don’t rely on automation alone.

7.The executable software is only part of the picture. It is of no use without user

manuals, business processes, design documentation, well-commented

source code, and test cases. These should be produced as an intrinsic part

of the development, not added at the end.

Common Criteria (NIAP Labs)

Section 1 = History, concepts and principles of Security

Evaluation

Section 2 consists of Templates for creating Protection

Profiles (PP) and a Security Target (ST) document

• The Protection Profiles and the Security Target allow the following

process for evaluation:

- An organization that wants to acquire or develop a particular type of

security product defines their security needs using a Protection Profile.

The organization then has the PP evaluated, and publishes it.

- A product developer takes this Protection Profile, writes a Security Target

that is compliance with the PP, and has this Security Target evaluated.

- The product developer then builds a TOE (or uses an existing one) and

has this evaluated against the Security Target.

Common Criteria (cont)

Section 3 includes various methods of assuring that a product is

secure

The included 7 pre-defined sets of assurance requirements called

the Evaluation Assurance Levels (EALs) are:

• Evaluation assurance level 1 (EAL1) - functionally tested

• Evaluation assurance level 2 (EAL2) – structurally tested

• Evaluation assurance level 3 (EAL3) - methodically tested and checked

• Evaluation assurance level 4 (EAL4) - methodically designed, tested, and

reviewed

• Evaluation assurance level 5 (EAL5) – semi-formally designed and tested

• Evaluation assurance level 6 (EAL6) – semi-formally verified design and

tested

• Evaluation assurance level 7 (EAL7) - formally verified design and tested

http://niap.nist.gov/cc-scheme/vpl/vpl_type.html.

Artifacts used for Security Assurancewithin Agile Methods

Requirements

• Guidelines

• Specification Analysis

• Reviews

Design and Analysis

• Application of specific architecturalapproaches

• Use of secure design principles

• Formal validation

• Informal validation

• Internal review

• External review

Implementation

• Informal requirements traceability

• Requirements testing

• Informal validation

• Formal validation

• Security testing

• Vulnerability and penetration testing

• Test depth analysis

• Security static analysis

• High-level programming languages andtools

• Adherence to implementation standards

• Use of version control and change tracking

• Change authorization

• Integration procedures

• Use of product generation tools

• Internal review

• External review

• Security evaluation

An Overview of OMG Model DrivenArchitecture

An Architectural Style that recommends the use of Industry Standard

• Models (from different domains and perspectives),

• Metadata (in a standards based repository),

• Mappings (Patterns & Transformations),

• the relevant Middleware and

• Methodologies

for allowing developers and users to productively design, build, integrate andmanage applications throughout the software development lifecycle while

separating technology & business concerns.

Back to overview

MDAAn eclectic integration of best practices in Modeling ,Middleware, Metadata, Mapping and Software Architecture

Model Driven (UML, MOF, CWM…)

– Platform Independent Models (PIM)

– Platform Specific Models (PSM)

– Mappings : PIM <==> PSM

– Applies across the software life cycle

Key Benefits

• Ability to analyze for existence of vulnerabilities at all stages of SoftwareDevelopment via formal models

• Improved Productivity for Architects, Designers, Developers andAdministrators

• Lower cost of Application Development and Management

• Enhanced Portability and Interoperability

• Business Models and Technologies evolve at own pace on platform(s) ofchoice

MS Software Factories & OMG MDA Guidebased 3D-VE Vulnerability AnalysisBusiness Strategy Model

(Business Capability Model)

Business Rules &

Requirements Model

Business Swimlanes

or Activity Models

Business Entity Interactions \

Data Flow Diagrams

PSM Deployment Model

PIM Activity Diagram \

Seq Diagram \

Collaboration Diagram

UIP (Application

Blocks)

Software Architecture Patterns

PIM Class Model \ Object

Model

System Features Model

PSM Activity Diagram \

Seq Diagram \

Collaboration Diagram

PSM Class Model \ Object

Model

Code Tests

Build Scripts

UI

CO

NF

IGU

RA

TO

R f

or

TY

PE

OF

PIM

to

PS

M S

TE

RE

OT

YP

ING

COTS

Configurators

Seamless Integration:Forward and Reverse Traceable Engineering

Code Tests Build Scripts UICOTS Configurators

TEXTUAL REPRESENTATIONS

Models are represented by codepiecesand the code pieces are representedby the Models at the lowest levels ofabstraction

Specific Abstract Syntax Tree Metamodels

SASTM for

Java ver x.SASTM for

C# ver y.

SASTM for

SAP R3SASTMs have isomorphic one-to-onecorresponding modeled elements forthe in memory AST representation ofnormal code compilers

GASTM for

OO code

Generic Abstract Syntax Tree Metamodels

GASTM for

dBs (ERDs)GASTM for

SAP R3

Higher Level CIMs and PIMs

UNISYS 3D-VE

Tra

ceab

ilit

y

Skele

tal G

en

era

tio

n

Fu

ll A

sso

cia

tio

n

Fu

ll G

en

era

tio

n

Fu

ll A

sso

cia

tio

n

Higher the abstraction level of Models,higher is the Association basedgeneration (generation by usingexisting libraries of blueprints)

IMM BPML

Metrics

CWMKDM

Inter-Sys

CommSpecInter-Sys

CommSpecPlatform

spec

Inter-Sys

CommSpecInter-Sys

CommSpecSystem

Spec

Inter-Sys

CommSpecInter-Sys

CommSpecBusiness

Micro Rules

Inter-Sys

CommSpecInter-Sys

CommSpec

Security

Policy

Micro Rules

KDM

Inter-Sys

CommSpecInter-Sys

CommSpecBusiness

Micro Rules

Inter-Sys

CommSpecInter-Sys

CommSpec

Security

Policy

Micro Rules

SBVR

Inter-Sys

CommSpecInter-Sys

CommSpecBusiness

Rules

Inter-Sys

CommSpecInter-Sys

CommSpec

Security

Policy

Rules

Inter-Sys

CommSpecInter-Sys

CommSpec

System

Structure/

KDM

Inter-Sys

CommSpecInter-Sys

CommSpec

Security

Policy

Violations

Inter-Sys

CommSpecInter-Sys

CommSpecExtracted

Vulnerabilities

Inter-Sys

CommSpecInter-Sys

CommSpecExtracted

Asset Info

KDM

Inter-Sys

CommSpecInter-Sys

CommSpecBusiness

Violations

Software Assurance Ecosystem: Infrastructure with Tools

Trends, progress, Risk analysis

KPIs, Assessment, etc.Evidence Test CasesUML Models Source Code

Software System Artifacts Security/Business Specifications Software System Artifacts Security/Business Specifications Hardware PlatformsHardware Environment

Rule Analyzer

Rule Analyzer

Rule Miner

Architect

Conformance Analyzer Transform

Report Generators TestCase GeneratorsEvidence Generators Model Generators Source Generators

ExtractorParser Extractor ExtractorExtractorExtractor

Vulnerabilities can be in anywhere - Business Models down toany Infrastructure Artifacts

If you can’t model it you can’t fully understand or predict behavior

Business operations, Software and Infrastructure Operations areformally modelled in order to share and find vulnerabilities using aformal framework

Strategic Goal

Model, Measurement

Model

Process &

Organization Models

Information &

Component Models

Infrastructure &

Topology Models

Traceability is

the backbone

for maintaining

and managing

the analysis of

vulnerabilities at

any abstraction

level

Blueprints Artifact Traceability forVulnerability Impact Assessment

A2A1 A3 A4 A6A5

A8A7 A9 A10 A12A11

A14A13 A15 A16 A18A17

A20A19 A21 A22 A24A23

Exhaustively define at the repository level all possible traceability relationships

between Blueprint Artifacts at the Repository Level

Vulnerabilities can be deduced at all levels of abstraction

Blueprint Desktop

Repository

SL1

SL2

SL3

SL4

Tools

Eclipse

MDF

Standard

QVT

IMS

Real Time Enterprise for completeVulnerability Assessment

For Unisys, RTI is more than a set of technologies. It’s integral to a framework that

connects a model-based view of the business with IT and business process execution

to create a closed loop that drives continuous business optimization

• Shared resources

• Business-driven

resource allocation

• Automated service-

level optimization

BusinessPerformanceManagement

Real TimeInfrastructure

• KPI thresholds

• Real-time process

monitoring

• Process & IT event

management

• Strategy and

process models

• Industry-specific

blueprints

• Process simulation

BusinessModels

TechnicalModels

• Application and

infrastructure models

• Process – IT Service

correlation

• IT service governance

RTI becomes much more

powerful when combined with

BPM to drive the Real Time

Enterprise – an organization

that anticipates and capitalizes

on business opportunities and

threats before they happen

3D-VE Artifacts Allow Scenario, Simulation andImpact Analysis for vulnerability assessment

Impact analysis and scenario planningallows clients to rapidly build ROI modelsfor multiple scenarios using processsimulation and cost estimating capabilitiesof the 3D-VE toolsets

Agile Change Management – allows rapidchanges to business process andassessment of financial impacts of change

Accurate Measurement

You cannot improve what you cannot measure!

Management

Business Process

Applications

Infrastructure

Profit Efficiency

Geographic

Product

Customer

Utilization

Cycle TimeRisk

Performance

SLA levels

Capacity

Throughput

Transaction

Efficiency /

Effectiveness Avg transaction volume

Avg transaction value

Messages per sec/min/day

CPU cycles

Inventory

Cost Efficiency

Activity Based Costing

• Operations should be designed to meet Key Performance Indicators (KPIs).

• KPIs are derived from information in many levels of an operating enterprise

• Blueprints aligns these metrics.

VERTICAL INDUSTRYSOLUTIONS

TECHNOLOGYELEMENTS

TECHNOLOGY ROADMAPFOUNDATION

3D-VE Foundation For Secure Business – Vulnerability AnalysisContent at different abstraction levels

UNISYS BUSINESSBLUEPRINTS

References

ISO/IEC 15288 for System Life Cycle Processes,

available from http://www.iso.org

ISO/IEC 12207 for Software Life Cycle Processes,

available from http://www.iso.org

ISO/IEC 15026 for System and Software Integrity Levels,

available from http://www.iso.org

Cleanroom Software Engineering [Linger 94, Mills 87]

US-CERT BUILD SECURITY IN:

https://buildsecurityin.us-

cert.gov/daisy/bsi/articles/knowledge/sdlc/326.html

ReferencesAgile Alliance. Manifesto for Agile Software Development (2005).

Beznosov, Konstantin. “Extreme Security Engineering: On Employing XP Practices to Achieve ‘Good Enough Security’ without Defining It.” First ACM Workshop onBusiness Driven Security Engineering (BizSec). Fairfax, VA, Oct. 31, 2003.

Beznosov, Konstantin & Kruchten,, Phillipe. “Towards Agile Security Assurance,” 47–54. Proceedings of the 2004 Workshop on New Security Paradigms. White PointBeach Resort, Nova Scotia, Canada, September 20-23, 2004. New York, NY: Association for Computing Machinery, 2005.

The Common Criteria Portal (2005).

University of Wisconsin Madison. Fuzz Testing of Application Reliability (2006).

Goldenson, D. & Gibson, D. Demonstrating the Impact and Benefits of CMMI: An Update and Preliminary Results (CMU/SEI-2003-SR-009, ADA418491). Pittsburgh, PA:Software Engineering Institute, Carnegie Mellon University, 2003.

Hall, Anthony & Chapman, Roderick. “Correctness by Construction: Developing a Commercial Secure System.” IEEE Software 19, 1 (Jan./Feb. 2002): 18-25.

Herbsleb, J.; Carleton, A.; Rozum, J.; Siegel, J.; & Zubrow, D. Benefits of CMM-Based Software Process Improvement: Initial Results (CMU/SEI-94-TR-013, ADA283848).Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1994.

IEEE Standards Coordinating Committee. IEEE Standard Glossary of Software Engineering Terminology (IEEE Std 610.12-1990). Los Alamitos, CA: IEEE ComputerSociety, 1990 (ISBN 0738103918 ).

Kitson, David H. "A Tailoring of the CMM for the Trusted Software Domain." Proceedings of the Seventh Annual Software Technology Conference. Salt Lake City, Utah,April 9-14, 1995.

Linger, R. C. “Cleanroom Process Model.” IEEE Software 11, 2 (March 1994): 50-58.

Lipner, Steve & Howard, Michael. The Trustworthy Computing Security Development Lifecycle (2005).

Michael, C. C. & Radosevich, Will. Black Box Security Testing Tools (2005).

Microsoft. Microsoft Security Advisories (2006).

Mills, H.; Dyer, M.; & Linger, R. C. “Cleanroom Software Engineering.” IEEE Software 4, 5 (September 1987): 19-25.

The MITRE Corporation. Common Vulnerabilities and Exposures.[NASA]NASA Software Assurance Technology Center. Software Assurance Guidebook, NASA-GB-A201.

Paulk, M.; Curtis, B.; Chrissis, M.; & Weber, C. Capability Maturity Model for Software (Version 1.1) (CMU/SEI-93-TR-024, ADA263403). Pittsburgh, PA: SoftwareEngineering Institute, Carnegie Mellon University, 1993.

Poppendieck, M. & Morsicato, R. “Using XP for Safety-Critical Software.” Cutter IT Journal 15, 9 (2002): 12-16.

Redwine, S. T. & Davis, N., eds. “Processes to Produce Secure Software.” Improving Security Across the Software Development Lifecycle (National CybersecurityPartnership Taskforce Report), Appendix B. http://www.cyberpartnership.org/init-soft.html (2004).

Ross, Philip E. “The Exterminators: A Small British Firm Shows That Software Bugs Aren’t Inevitable.” IEEE Spectrum 42, 9 (September 2005): 36-41.

The SANS Institute. The Twenty Most Critical Internet Security Vulnerabilities (Updated) – The Experts Consensus (2005).

Software Engineering Institute. Maturity Profile. http://www.sei.cmu.edu/appraisal-program/profile/profile.html (2005).

Unites States Computer Emergency Readiness Team. Technical Cyber Security Alerts (2005).

Wäyrynen, J.; Bodén, M.; & Boström, G. “Security Engineering and eXtreme Programming: an Impossible Marriage?” Extreme Programming and Agile Methods - XP/AgileUniverse 2004: 4th Conference on Extreme Programming and Agile Methods. Calgary, Canada, August 15-18, 2004. Berlin, Germany: Springer-Verlag, 2004 (ISBN 3-540-22839-X).

How We Do It. 3D Blueprinting

What We Do.

What We Deliver.