A Ph.D Proposal By:
Sarah Pramanik
Computer Science Department
University of Colorado, Colorado Springs
Presented On:
06/17/2011
Presentation Outline
 Problem Background
 Related Research
 Approach
 Tasks
 Path Forward
2
3
What is a Security Architecture?
 According to NIST [85] a Security Architecture should:
 Acknowledge current security services, tools and
expertise, outline forecasted business needs and
requirements
 Clearly articulate an implementation plan
 Supplement with an integrated schedule of tasks ,
establish project timelines, provide estimates of
resource requirements, and identify key project
dependencies
 Focusing on protecting confidentiality, integrity, and
availability
4
Architecture Development Issues
 Scope of architecture, or size of program, may be
different than currently available expertise
 Level of acceptable risk is subjective (no industry
standard)
 Inclusion of security architecture as an embedded
element
5
Why Security Architecture
 Working as a Security Architect
 Very large program, limited time and budget
 How do I know I have done my job?
 Currently assessing risk and architecture is subjective
 DoD Information Assurance Certification and
Accreditation Plan (DIACAP)
 Real World Issue
 Severe consequences if security is not correct
6
A Comprehensive Security
Architecture
 Why does there need to be a Security Architecture
Methodology?
 What does the methodology need to encompass?
 How can a Security Architecture be evaluated?
7
Why a Security Architecture
Methodology
 Security must satisfy a variety of laws, policies and
regulations
 Security can get lost in complex systems
 Need to avoid bolting on at the end
 Need to mitigate program risk
 The Security Architecture is not just one document
8
Encompassing Methodology
 A methodology must step the architect through each
aspect of securing the system
 Identification of elements to complete during each
phase of the system engineering lifecycle
 Identification of cost effective and low risk system
protections
 Continuous review of the system with a security
architect’s mindset
9
Security Architecture Evaluation
 Quantifiable method for assessing a security
architecture
 Method for evaluating risk to a system

Based on the protections put in place and any residual
vulnerabilities
 Automated way of looking at the architecture before the
system is implemented
10
11
Information Assurance
 Information Assurance (IA) is the practice of
managing risks related to information
 IA primarily deals with the Confidentiality, Integrity,
and Availability of information
 Part of a Security Architecture is the application of
layered IA defenses into a system
12
Information Assurance
Layers of Information Assurance [97]
13
IA Requirements
 DoD programs follow different sets of IA
requirements, depending on the type of system
 DoDI 8500.2, JAFAN 6/9, DCID 6/9

All are very similar, with only a few minute differences
 There is a move (in the Navy at least) to consolidate to
the NIST SP 800-53

This may also require a move from DIACAP to NIST SP 800-37
14
IA in System Engineering Lifecycle
 Information Assurance or Information System Security
Engineering should not be isolated into one piece of
the system
 Systems Engineering typically considers security to
just be a specialization that it should be done in
parallel with the systems lifecycle [5].
 Security engineers must be incorporated into each IPT,
knowing only system level information is not sufficient
15
System Engineering Lifecycle
 Systems engineers perform such tasks as requirements
decomposition, interface definition and functional
decomposition of the system[5]
 Each aspect of a task can potentially affect the overall
security posture of the system
16
Existing Architecture Frameworks
 Zachman Framework [99]
 Department of Defense Architecture Framework
(DoDAF) [97]
 Sherwood Applied Business Security Architecture
(SABSA) [92]
 Information Assurance Technical Framework (IATF)
[75]
17
Zachman Framework
 The Zachman framework is the predecessor to various
frameworks used for system architectures.
 A formal and structured look at an enterprise and it is a
taxonomy
 It is not a methodology
18
DoDAF
 Shows the system through the lens of specific




stakeholder concerns
It is organized into multiple views
It is a requirement on most major DoD programs
It provides a functional view of the system
Useful in describing the operational view
19
SABSA
20
Existing Evaluation Methods
 “There is no common framework in any current
evaluation scheme or criteria that directly supports
measuring the combined security effectiveness of
products.” [87], [97]
 The National Information Assurance Partnership
(NIAP) and Common Criteria (CC) both provide
evaluations on specific products
21
22
Theory vs. Real World
 This research is being applied in real-time
 Initially followed SABSA to integrate into a DoDAF
model
 DoDAF was too high-level
 Needed a systematic approach to:
 Explain what needs to occur to the IPTs and security
team
 Identify risks, cost and schedule issues due to security
23
Continued Application
 Trial and error
 Organization is key to success
 Requirements decomposition
 Different interpretations
 Evaluation
 Subjective and unquantifiable
24
A Systematic Approach
 Inclusion in overall system life-cycle
 Systematic Methodology
 A road map for the IPTs
 Assurance of completeness
 Security Architecture Evaluation
 Quantifiable
 Programmatic Risk Reduction
25
26
Task #1
 Integration of Security into System Engineering
Lifecycle
 Follow the formalized Systems Engineering
Methodology as presented in[5] and show how security
should be integrated
 Compare with how it is currently done on most large
programs
27
Task #2
 Creation of Security Architecture Methodology
 Create a methodology that encompasses many of the
attributes focused on in the frameworks, but gives an
architect a step-by-step process to follow
 The architect will be able to adequately gauge where
they are in the process, which will allow for more
effective budget and schedule management
28
Task #3
 Creation of Automated Architecture Evaluation Tool
 Create a program that brings in the most critical aspects
of a system design to provide an assessment of the
security posture before the system is built
 This will allow for changes in the design early on, which
reduces risk
29
Task #4
 Coding Standards
 Complete a secure coding standard and software
assurance plan that provide developers an
understanding of how they contribute to the overall
security posture
 Currently in the process of being implemented as a
sector standard, and being used for other programs
30
Task #5
 Program Effects
 As part of the look at the Systems Engineering
Methodology, review any known statistics of
incorporating IA, and provide an estimate, based on
time and schedule reduction of risk reduction, and
potential cost savings
31
32
Timeline
Aug-09
Feb-10
Sep-10
Mar-11
Oct-11
Apr-12
Software Security Research
Software Security Application
Security Architecture Methodology
Vulnerability Analysis and Architecture Tool Development
Experimentation and fine tuning of tool
Duration
Application of Tool for Real System
Changes to system due to tool results
Analysis of Data from Penetration Testing
Enhanced Systems Engineering Lifecycle Methodology
33
Evaluation Plan
 Application of security architecture methodology on
current program and on a mock system
 Application of enhanced system engineering
methodology on a mock system
 Comparison of systematic security architecture
methodology to methods used on other programs
34
Success Criteria
 Demonstrate a program that can help assess the
security architecture for vulnerabilities
 Provide a system security architecture methodology,
that covers all aspects of creating a useful security
architecture, and show that it can be used in other
programs and on a variety of complex systems
 Provide a process and method for incorporating
security into the overall systems engineering
methodology and show that it can be used in other
programs and on a variety of complex systems
35
Potential Contributions
 New methodology for the creation of security
architectures on large complex systems
 New methodology for the incorporation of security
into the overall systems engineering lifecycle
 New tool to assess the vulnerabilities in a system,
based on a model before a system is built
36
Questions/ Comments?
37
References
 [5] Alexander Kossiakoff and William N. Sweet, Systems
Engineering Principles and Practice, 2003 © John Wiley
and Sons Inc.
 [8] Birgit Pfitzmann,” Multi-layer Audit of Access Rights,”
W. Jonker and M. Petkovi´c (Eds.): SDM 2007, LNCS 4721,
pp. 18–32, 2007.
 [13] Committee on National Security Systems Instruction
No. 1253, 2009 October“Security Categorization and
Control Selection for National Security Systems, Version 1,”
Committee on National Security Systems.
 [20] Department of the Navy (DoN), “Security Control
Mapping,” SECNAV DON CIO, 1000 Navy Pentagon,
Washington, DC.
38
References
 [34] Heru Susanto, Fahad bin Muhaya, “Multimedia Information
Security Architecture Framework,” 2010 © IEEE.
 [40] Karen Goertzel, “Software Security Assurance: A State of the
Art Report,” IATAC, Defense Technical Information Center.
 [71] National Institute of Standards and Technology Special
Publication 800-53 Revision 3, 2009 August 2009, includes
updates as of 05-01-2010” Recommended Security Controls for
Federal Information Systems and Organizations,” NIST,
Gaithersburg, MD.
 [75] National Security Agency Information Assurance Solutions
Technical Directors, “Information Assurance Technical
Framework,” Release 3.0, September 2000.
39
References
 [80] North American Electric Reliability Council, 2004,
“NERC Cyber Security Activities,” Available:
http://www.nerc.com.
 [85] Richard Kissel et al, National Institute of Standards
and Technology Special Publication 800- 64, Revision 2,
2008 October, “Security Considerations in the System
Development Life Cycle,” NIST, Gaithersburg, MD.
 [87] Richard S. Hall, 2005 May 13, “Oscar Security” Release
version: 1.0.5 Available: http://oscar.ow2.org/security.html
 [92] SABSA Ltd. 2010 ©SABSA, “The SABSA Method,”
Available: http://www.sabsa-institute.org/[96]
40
References
 [97] Wikipedia 2010 December 14, “Department of
Defense Architecture Framework,” Available:
http://en.wikipedia.org/wiki/Department_of_Defense
_Architecture_Framework
 [98] Wikipedia 2010 December 10, “Information
Assurance,” Available:
http://en.wikipedia.org/wiki/Information_assurance
 [99] Wikipedia 2010 December 10, “Zachman
Framework,” Available:
http://en.wikipedia.org/wiki/Zachman_Framework
41
42
Publication/Conference
 Northrop Grumman Software Symposium
 Presented a talk on “Software Security Architectures:
Principles in Application,” Baltimore MD, 2010.
 Northrop Grumman Software Center Of Excellence
 “Spotlight on Information Assurance in the Real World,”
Issue 3, June 2010.
43
Security
Architecture
Security
Services
Security Tools
Implementation
Plan
Requirements
Business
Needs
Primary Information
Schedule of
Tasks
Expected
Outcomes
Timeline
Resource
Requirements
Project
Dependencies
Supplemental
Information
Implementatio
n Plan
Ports,
Protocols,
Services
Component
Design
Physical
baseline w/
PPSM over IP
Networks
Component
Trace
Vulnerability
Assessments
Security
Services
Interoperability
Issues
Physical
baseline w/
services
Requirements
Component
Level
Requirements
Vulnerability
Assessments
STIGs
System Life-cycle Models
[5]
Concept and Technology Development
DoD
5000
phases
Mission need
Determination
ISO/IEC
15288
stages
NSPE
stages
Component
Exploration
Concept
Technical
Feasibility
Concept Development
Needs
Analysis
Concept
exploration
System
Integration
System
Demonstration
Development
Conceptual
Systems
Engineering
Stages
Systems
Engineering
Phases
Component
advanced
development
Concept Exploration
Concept
Definition
Development
Production
Production
preparation
Engineering Development
Advanced
Development
Engineering
Design
Production
&
Deployment
Integration
& evaluation
Full-scale
production
Operation &
support
Utilizat
ion
Support
Product support
Post Development
Production
Operation &
support
System Security
Engineering
Methodology
1
Concept
Development
Needs
Concept
Analysis Exploration
Concept
Definition
2
3
Engineering
Development
Advanced
Devel
Engineering
Design
Integration
&
Evaluation
Post
Development
Production
Operations
& Support
Phase Out
& Disposal
Operational
Deficiencies
Unacceptable
Residual Risk
System Functional
Specifications
Functional
Security Elements
Concept
Development
Security
Architecture
Concept
Technological
Opportunities
New
Vulnerabilities
and protection
mechanisms
Production
Specifications
Security Architecture
and Configuration
Engineering
Development
Integration of
Security
Concepts into
System
Defined System
Concept
Defined
Security
Concept
Operation &
maintenance
IAVMs
Post
Development
Sanitization,
Destruction
Production
System
Baked-in-IA
Installed
Operational
System
Integrated
Security
Operational
Deficiencies
Unacceptable
Residual Risk
System
Operational
Requirements
8500.2 (or 800-57)
Decomposition
Needs
Analysis
Concept
Exploration
System studies
Best integration of
security
Technological
assessment
New
vulnerabilities/risks?
Operational analysis
Interoperability Security
Technological
Opportunities
New
Vulnerabilities
and protection
mechanisms
System
performance
requirements
Secondary Decomp
Concept
Definition
Concept synthesis
Does synthesis have
security?
Feasibility experiments
Does Security Inhibit Fn?
Requirements definition
Security Requirements
System Studies
Cryptography
and CDS
System
Functional
Specifications
Technical reqs
Candidate
System
Concepts
Do they meet
security
constraints?
Trade-off analysis
Crypto design, boundary
defense, CDS
Functional Architecture
Security Views –
beginning of Security
Architecture
Subsystem definition
Security definition
Defined System
Concept
Incorporated
Security Concept
System
Functional
specifications
Technical reqs
System Design
Specifications
Security Design
Specifications
Test & Evaluation
Plan
Ensure Security Test
Advanced
Development
Engineering
Design
Risk Abatement
Gov. Schedule
Subsystem demonstration
Subsystem security
Component design
reqmts
Component security req
Component Engineering
Security implementation
Component Test
Security test
Reliability Engineering
Unacceptable Security
Defined System
Concept
Incorporated
Security
Concept
Validated
Development
Model
High-level
Security
Architecture
Engineered
Prototype
Secure Code
Production
Specifications
Security
Specifications
Integration
and
Evaluation
System Integration
STIGs, C&A
Prototype Test
Software security
Operational Evaluation
C&A
Production
System
Integrated
Security
Production
Specifications
Integrated
Security
Operational
Documentation
Security Manual
Production
Operation
and Support
Tooling & Test Eqpt
Pentesting, Vuln
Assessments
Production & Accept
Gov. Acceptance
System Delivery
Contractor Docs.
Production
System
Integrated
Security
Disposal Plan
Destruction
Plan
Disposal
Sanitization,
Destruction
Component Engineering
Vuln assessments
Component Test
Security changes
Reliability Engineering
Delivered
System
Obsolete
System
Commercial
Federal
DoD
BS 7799
NIACAP
DITSCAP
NISCAP
DIACAP
DoDIIS
ISO 27001
JAFAN 6/3
SP 800-37
SP 800-37
Contractor
NISPOM
IC
NRO
NGA