Secure Systems Engineering

Secure Svstems
Lngineering
Shahriar Chowdhury
Corey Grimes
Svstems Lngineering
Definition: A robust approach to the design,
creation, and operation of systems.
Principles: Nothing is more inefficient than
solving the wrong problem and building the
wrong system
Keep the problem and solution spaces separate
The problem space is defined by the customer´s mission
or business needs
The SE/ISSE define the solution space, driven by the
problem space
1he Vee` Model oí
Svstem De·elopment
User Requirements
& Concept of
Operations
System
Requirements &
Architecture
Component Design
Procure, Fabricate,
& Assemble Parts
Component
Integration & Test
System Integration
& Test
System
Demonstration &
Validation
Component
Engineering
Domain
Systems
Engineering
Domain
1he lrameworks Ouagmire
Svstems Lngineering O·er·iew
General Systems Engineering Process
Discover Needs
Define System Requirements
Design System Architecture
Develop Detailed Design
Implementation & Testing
Operations & Maintenance
Disco·er Needs
Develop an understanding of the
customer´s mission or business
Help the customer determine what
information management is needed
Document the results as a basis for
defining information systems that will
satisfy the customer´s needs: Mission
Needs Statement (MNS)
Deíine Svstem Requirements
Allocate identified needs to appropriate
controls
Specify capabilities to be provided by
system
Describe operational aspects of the
candidate system: preliminary system
Concept of Operations (CONOPS)
Design Svstem Architecture
Decompose higher-level functions
identified in requirements
Performance requirements associated
with the higher level are allocated to
lower level functions.
Includes analysis of candidate system
architectures, function and process,
interfaces (internal and external),
components, information transfers,
environments, and users/accesses.
Deíining Svstem Architecture
(ontrast
Figures a and b
illustrate the contrast
between Define
System
Requirements treats
the target system as
a "black box¨ and
Design System
Architecture creates
the structure within
the system.
lunctional analvsis
Functional analysis and allocation allow:
a better understanding of what the system has to do
the ways in which it can do it
and to some extent, the priorities and conflicts
associated with lower level functions.
provides information essential to optimizing physical
solutions.
Key tools in functional analysis and allocation are
Functional Flow Block Diagrams, Timeline
Analysis, and the Requirements Allocation Sheet.
De·elop Detailed Design
Analyze trade-offs/design constraints
Consider life-cycle support
Trace all requirements to system elements
Detailed component and interface
specifications
Identify candidate commercial off-the-
shelf (COTS)/government off-the-shelf
(GOTS) products
Implement Svstem
Move system from specifications to the
tangible
Acquisition
Integration
Configuration
Testing (Component/Integrated)
Documentation
Training
Svstem Securitv Lngineering
Definition: The art and science of
discovering users security needs and
designing and making, with economy and
elegance, systems so that they can safely
resist the forces to which they may be
subjected
System Security Engineering should be an
integral and parallel part of the overall
system engineering process
(orresponding SL and ISSL Acti·ities
Assess Information Protection
Effectiveness
Assess Effectiveness
Implement Systems Security Implement Systems
Develop Detailed Security
Design
Develop Detailed Design
Design System Security
Architecture
Design System Architecture
Define System Security
Requirements
Define System Requirements
Discover Information
Protection Needs
Discover Needs
Disco·er Iníormation Protection Needs
Information Management Needs
Underlie customer´s mission or business
Develop model identifying processes,
information, and users
Decompose user roles, processes, and information
in system
Apply "least privilege¨ rules
Information Management Model (IMM)
Disco·er Iníormation Protection Needs
Inherent or implied security needs may
exist that are not explicitly acknowledged
or specified by the customer
Help customer understand the information
protection needs that support the mission
or business
Information Protection Policy
Disco·er Iníormation Protection Needs
• Asset Sensitivity Assessment
• Threat Analysis
• Countermeasures
• Information Protection Policy
• Information Management Policy
´ecvrity ^eea. Detivitiov Matri·
Risk Analvsis
Concerned with sensitivity of system and
information processed by the system
Each information domain is assigned metrics for
harm to information (HTI) and potentially harmful
events (PHE)
HTI considers value of information and degree of
harm if C,I,A is breached
PHE considers existence/types of adversaries and
potential for accidents
HTI/PHE assigned to each information domain for
disclosure, modification, destruction and
unavailability
1hreat 1ree Analvsis
A tree is constructed whose root is
undesired behavior and whose successive
nodes are its possible causes
Consider entire life cycle of system
1hreat 1ree Analvsis
Example of threat tree over life cycle of system
1he Ad·ersarv Model
Characterize adversaries in terms of
Resources & Access (what they can do)
Risk tolerance (what they are willing to do)
Objectives (what they want to do)
Adversary may be classified as hacker,
malicious insider, organized crime,
industrial competitor, terrorist, or national
intelligence organization
Different adversaries value attack goals
differently
(ountermeasures
Define security services and strengths of
service using information threat as
guideline for setting priority
Apply confidentiality, integrity, availability,
access control, identification &
authentication, nonrepudiation and
security management services as
appropriate
Strengths of services proportional to
information threat metrics
Iníormation Protection Policv
Document
Information threats
Security services
Strengths and priorities
Roles and responsibilities
Obtain customer concurrence in
establishing security services and
identifying their relative importance
Iníormation Management Policv
Includes IPP when customer concurrence
is obtained
IMP is the basis for assessing the
effectiveness of the information protection
throughout the remainder of the process
activities
Deíine Svstem Securitv Requirements
Allocate information protection needs to
systems
Specify what the system must do without
specifying design or implementation
Preliminary system security CONOPS
Baseline security requirements developed
Svstem Securitv Requirements
Security Context
Sets the system boundary and identifies
external interfaces to the system
Preliminary security CONOPS
Describes from a user perspective what
information management and protection
functions the system will perform but falls
short of step-by-step procedures
Defines reliance of mission or business needs
on other systems and the products & services
they deliver
Address inherent risk in operating the system
Requirements Analvsis
Clarify and define function requirements
and design constraints
Ensure that all needs discovered have
been allocated to the solution set (the
target system and external systems)
Ensure target system describes all
external interfaces and flows
Ensure projected security risks are
acceptable to the customer
lunctional Analvsis´ Allocation
lunctional Analvsis´ Allocation
This matrix assists the system engineer in
specifying what actions must be taken in
order to assure the security requirements.
It enables a functional distribution of
requirements to elements of the system.
By answering these questions, the system
engineer is able to identify alternatives as
well.
Design Svstem Securitv Architecture
During this task, the ISSE works with the
systems engineers to ensure that security
requirements flow properly to the architecture
and that architecture decisions do not impede
security.
Security requirements are allocated to the target
and external systems and it´s ensured that
external systems identified can support what is
allocated to them. This is particularly important
for security, since services such as key
management are often allocated to external
systems.
Design Svstem Securitv Architecture
High-level security mechanisms are identified during this
task (e.g., encryption, digital signature). This is necessary
so that dependencies, such as key management for
encryption, can be addressed and allocated.
Mechanisms are matched to security service strength, apply
design constraints, analyze and document shortfalls,
perform interdependency analysis, ascertain the feasibility
of mechanisms, and assess any residual risk associated
with the mechanisms.
Risk Analvsis in Designing Svstem
Securitv Architecture
Specific implementations of the security mechanisms are
not identified in the architecture
detailed vulnerability and attack information is not
available to support the formal risk analysis process.
However, an experienced information systems security
engineer can describe the expected vulnerabilities in
potential components and can develop attack scenarios
to use in the risk analysis process.
Risk Analvsis in Design Svstem
Architecture`
The risk analysis process:
Ensures that the selected security mechanisms
provide the required security services
Helps explain to the customer how the security
architecture meets the security requirements.
The effectiveness of the architecture in
meeting these requirements is based on the
results of the risk analysis and whether the
customer concurs with the recommended
course of action at this stage of development.
Develop Detailed Security Design
It´s iterative, involving interactions between the SE and
ISSE teams and between systems and component
engineers within the teams.
Continuous assessments by the ISSE team to compare the
expected risk with the system security requirements.
The system security requirements set priorities for
protection that the ISSE team applies accordingly.
The ISSE team produces the design documentation to
enable independent evaluation by risk analysts who then
provide feedback on vulnerabilities.
Detailed Security Design
The ISSE will ensure compliance with the security
architecture, perform trade-off studies, and
define system security design elements,
including-
Allocating security mechanisms to system security
design elements.
Identifying candidate commercial off-the-shelf
(COTS)/government off-the-shelf (GOTS) security
products.
Identifying custom security products.
Qualifying element and system interfaces (internal
and external).
Developing specifications (e.g., Common Criteria
protection profiles).
Detailed Security Design
Components include both technical and nontechnical
mechanisms (e.g., doctrine)
Design must satisfy customer-specified design constraints.
Trade-offs must consider priorities, cost, schedule,
performance, and residual security risks.
Risk analysis must consider the interdependency of
security mechanisms.
Design documents should be under strong configuration
control.
Failures to satisfy security requirements must be reported
to C&A authorities.
Design should be traceable to the security requirements.
Design should project the schedule and cost of long-lead
items and life-cycle support.
Design should include a revised security CONOPS.
Detailed Security Design
The information protection design specifies the
system and its components, but does not decide
on specific components or vendors (part of
Implement System activity)
ISSE reviews how well the mechanisms counter
the identified threats by performing an
interdependency analysis to compare desired to
effective security service strengths.
Once completed, the risk assessment results,
particularly any identified mitigation needs and residual
risk, are documented and shared with the customer to
obtain concurrence.
Alternati·e Analvsis´ L·aluation
Carry out a comprehensive analysis and
evaluation of the alternatives that result in
a preferred system architecture.
It´s not enough to simply select a preferred
architecture, it has to give clear demonstration
of its superiority in relation to alternatives.
Value of information (concept of cost)
should be kept in mind as part of overall
cost of the architecture alternative
1he Vee` Model oí
Svstem De·elopment
User Requirements
& Concept of
Operations
System
Requirements &
Architecture
Component Design
Procure, Fabricate,
& Assemble Parts
Component
Integration & Test
System Integration
& Test
System
Demonstration &
Validation
Component
Engineering
Domain
Systems
Engineering
Domain
SL´ISSL Acti·ities írom Requirements
to Design
Ouestions and answers