Transcript Smeal PhD Renewal Report - Information Systems and

Information System Security
Engineering and Management
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
INFORMATION SECURITY IN THE
SYSTEM ENGINEERING PROCESS
Dr. William Hery
[email protected]
Talk Outline
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
• Overview of Systems Engineering
• Overview of Systems Security
Engineering
• Application to POSA example
Systems Engineering
• Science
Determines what Is
• Component Engineering
Determines what Can Be
• Systems Engineering
Determines what Should Be
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
Systems Engineering--One View
•
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
Definition of Systems Engineering
(NASA SE Handbook)
 Systems Engineering is a robust approach to
the design, creation, and operation of systems.
•
Systems Engineering consists of
 Identification and quantification of system goals
 Creation of alternative system design concepts
 Performance of design trades
 Selection and implementation of the best design
(balanced and robust)
 Verification that the design is actually built and properly integrated in
accordance with specifications
 Assessment of how well the system meets the goals
Definition of Systems Security
Engineering
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
“The Art and Science of discovering
user’s security needs and designing and
making, with economy and elegance,
(information) systems so that they can
safely resist the forces to which they may
be subjected”
--IATF (Information Assurance Technical Forum)
What is a System?
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
• There is no standard definition.
• My vague definition from the systems engineer’s perspective:
 A system is a combination of interacting components operating within
an external logical and physical environment.
 Each component has attributes that describe what it does and how it
does it.
 Components have relationships with other components which describe
how the components interact to form a system.
 A system also interacts with other elements in its environment
 For the Systems Engineer (SE), a system is the part the SE has some
control over; the environment is what you have to take “as is.”
 A system has relationships with external components in its environment.
These are critical in the SE process
IT Systems
•
•
•
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
Components may include hardware (processors, memory, data links, I/O
devices, etc.), software (OS, application, network OS, etc.), firmware,
users, and administrators
Relationships include messages between software components, OS/HW
interface, network/CPU interfaces, user interfaces, etc.
The system/environment boundary depends on the system you are
designing. For example:
 If you are developing a database application system on top of an existing
database system, the database and OS are part of the environment.
 It your are developing everything from scratch, or are doing a complete system
re-design, then the OS & DBMS, platforms, etc. are part of your system
 If user and administrator processes and actions are part of what you are
designing, they are part of the system, otherwise they are part of the
environment.
 Understand the boundary of your system when you start
The “Vee” Model of
System Development
User Requirements
& Concept of
Operations
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
System
Demonstration &
Validation
System
Requirements &
Architecture
Systems
Engineering
Domain
System Integration
& Test
Component Design
Component
Integration & Test
Procure, Fabricate,
& Assemble Parts
Component
Engineering
Domain
What is Systems Engineering?
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
• Many different definitions
• All define a process of developing goals and requirements,
designing the system and development, verifying the requirements
are met at each step.
• All include successive refinements and iteration on the above
steps.
• In this talk, we will just use a generic systems engineering
philosophy (based on IATF), not a specific, detailed process--other
versions will look a bit different.
• This is a systems engineering process, not the systems
engineering process
• The important thing is that security analysis be integrated into
whatever systems engineering process you use.
Systems Engineering Iterative Loop
Requirements
Synthesis
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
Assessment
Next Phase
(Requirements
Synthesis
Assessment)
Information System Security
Engineering (ISSE)
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
• Part of overall systems engineering process
 In a simple sense, security is just another source of
requirements
• Iterates security requirements, architecture design, and
assessment through multiple levels of detail as part of
the systems engineering process
• We suggest where risk analysis, threat analysis,
vulnerability analysis, and policies fit into this process
Information System Security
Engineering (ISSE)
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
• Includes architecture, design, development, deployment
 System Architecture: where are the security functions performed?
Where are new external interfaces required to support security?
 System design includes selection of commercial products: platforms,
operating systems, DBMS, networks, etc., as well as design of custom
HW and SW
 Security requirements should be a part of all product selection criteria
(not just selection of security specific components such as firewalls
and crypto)
 Security design includes designing the management processes and
procedures for individuals that are required to maintain a secure
system throughout its life cycle
 For example, if a firewall is part of the system design, management
procedures for firewall configuration, updating (products and configuration)
to respond to new threats, firewall log reviews, exception response, etc.
should be designed as part of the system design
Information System Security
Engineering (continued)
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
• Risk analysis is a key part of the requirements prioritization--it lets
you know what you might be losing if you relax a security
requirement
• Security should be an integral element from the start
The Frameworks Quagmire
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
One Common SE Model: Waterfall
Model
•
•
•
•
•
•
•
•
•
Concepts
Requirements
Design
Implementation
Test
Installation and Checkout
Operation
Maintenance
Retirement
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
Another View: IATF Systems
(Security) Engineering Process
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
Primary SE and ISSE Phases in IATF
Model
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
Discover Needs
Discover Information Protection
Needs
Define System Requirements
Define System Security
Requirements
Design System Architecture
Design System Security
Architecture
Develop Detailed Design
Develop Detailed Security Design
Implement Systems
Implement Systems Security
Assess Effectiveness
Assess Information Protection
Effectiveness
SE: Discover Needs
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
• The first step is to get the “customer’s” view of what is
needed and how it will be used
 The customer is whoever is paying for the system design and
development, not necessarily the ultimate user of the system.
• The need is based on an interaction between customer
and design/development organization
• The output should be clearly and succinctly
documented and signed off on by both parties. (Called
the Mission Needs Statement in IATF)
ISSE: Discover Needs
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
• At this phase, the primary task is to understand the
major classes of potentially sensitive data and functions
used in the system. These are the IT Assets that will be
the starting point for the risk analysis.
POSA Mission Needs (System Concept)
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
• Mission Need: Put a device at each cash
register to allow a customer to swipe a credit or
debit card, and enter the PIN for a debit card.
The information will be sent to the Central
Facility for credit approval, with the response
sent to the register.
• Potentially sensitive data and functions:
 Credit/debit card information (confidentiality)
 Approval function (integrity and availability)
SE: Define System
Requirements
•
•
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
“It’s the requirements, stupid” (for those of you who remember the 1992
presidential election)
For any system, there are too many conflicting requirements, including
 Functionality: exactly what the system is supposed to do
 Non-functional requirements : reliability, security, maintainability, etc. They may
be invisible to users until something goes wrong
 Usability: The user’s ability to use the system efficiently and correctly
 Cost: Full life cycle cost, including design, implementation, unit costs for
components, annual maintenance costs, etc.
 Time to market
•
Requirements are not the mechanism used to satisfy them. Selecting the
mechanism is part of the design process
 e. g., not allowing file transfers initiated outside the corporate intranet may be a
derived requirement, but using a firewall is a design decision
Requirements (continued)
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
• Requirements are part of every iteration through detailed design,
not just the requirements phase
• At each iteration of the SE process loop, requirements are
allocated to elements of the architecture, design, etc.
 e. g., a confidentiality requirement may be allocated to a
network carrying the information to be kept confidential
• At each iteration, more specific requirements are
derived from the allocated requirements for an element
based on the design of that element
 e. g., an allocated confidentiality requirement on a network
may lead to a derived requirement for encryption
Requirements (continued)
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
• Requirements should be documented at every step,
including the allocation of requirements to system
elements and where derived requirements came from.
This is critical for later phases of a project,
requirements compliance table, requirements traceback
(more later), and as a starting point for system
modification in the future
• Major software packages (e. g., RDD-100) are used for
requirements capture, allocation, derivation, linking to
architectures, etc.
Requirements (continued)
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
• At the heart of the design process are the trade studies that help
prioritize requirements (what is the difference between a
requirements list and a set of goals???) so that changes in
requirements are made knowingly and rationally
• Many SE processes assume all requirements are known before
you start the system architecture. In practice, requirements often
change as you understand a system.
 Some initial high level requirements should not be removed (e. g.,
confidentiality for some classes of information)
 New requirements may be added even after a system id fielded (e. g.,
new security requirements in response to new threats)
 Initial requirements and changes in them must be agreed to by the
customer in writing.
CONOPS
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
• At the requirements stage, a high level view from the user’s
perspective of how the system will operate is also generated.
• This view is documented in the Preliminary Concept of Operations
(Preliminary CONOPS). This is used as a guide to how the system
will work to use as a basis for developing the high level
requirements.
• A very simple preliminary CONOPS for the POSA system is:
 A customer goes to the register with their purchases, which are rung
up by the clerk. The total is displayed on the POSA, and the customer
presents a credit/debit card swipes their own card, enters the PIN (if
it’s a debit card), and the information is sent to the CFAC for approval
or denial of credit.
 The initial POSA diagram is also essentially a statement of the
CONOPS
Security CONOPS
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
• Primarily about the system interfaces, since the architecture is not
yet known
• From the user view, not about technology
• Address inherent risks of running the system at all
ISSE: Security Requirements Definition
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
• Primarily about the critical data entering and leaving the system,
since system internals are not yet known.
• The primary source for security requirements is the Risk Analysis
 In the initial requirements phase, the IT assets at risk are inventoried
and valued, categorized, or prioritized
 Threats can are also identified at this stage
 Vulnerabilities in the system are typically not know at this point, since
there is not yet even a system architecture
 Some vulnerabilities through required external interfaces may be
identified
Other sources of initial requirements
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
• Legal requirements (a later topic)
• Broad government or corporate policies; these may be derived
from other risk analyses; e. g., the PA security policy cited in the
risks lecture provides a requirement to any application system
developed for the State.
• Image preservation, avoiding embarrassment, etc. (really a form of
subjective risk analysis)
• FUD (Fear, Uncertainty, and Doubt) by management--this is an ill
informed version of risk aversion that should be replaced by a risk
analysis
Sample POSA Security Requirements
•
•
•
•
Confidentiality of credit/debit card information
Integrity of approval function
Availability of approval function
…
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
SE: Design System Architecture
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
• This is a high level view of the major functional components of the
system--what they do, but not how they do it in detail
• Interactions between functions are a key part of the architecture
• Specific technologies are usually not yet included
• Essentially breaking the overall system function into sub-functions
and showing how to tie then together.
• Functional block diagrams are used
• Designing the architecture is an art, evaluating it is a science
System Requirements vs.
System Architecture
What the system has to do
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
How components fit
together to do it
Design System Architecture
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
• Decompose higher-level functions
identified in requirements
• 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, etc.
ISSE: Design System Architecture
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
• Allocation of security functions to system
components
• May result in new system components (e. g. a
firewall)
• External interfaces are critical
 Many threats attack through external interfaces
 New external interfaces may be required, e.g.,
access to an existing PKI
• Potential vulnerabilities are now added to the
risk analysis, e.g., networks sniffing once a
network is added to the architecture
POSA Architecture
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
CFAC
Store Network
POSA
Register link
Register
User
Interface
USER
Note: this is simpler than usual,
since we have identified no internal
POSA node functions--usually that is
a major part of the architecture
POSA Security
Requirements Allocation
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
• Confidentiality of credit/debit card information:
 Store network
 POSA
 Register link
• Integrity of approval process:




Store network
POSA
Register link
Clerk (assuming we include clerk’s actions in the system)
• Availability of approval process:




Store network
POSA
Register link
Clerk (assuming we include clerk’s actions in the system)
Note: all get the same allocation because this system is so simple
SE: Develop Detailed
Design
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
• Analyze trade-offs/design constraints
 The trade studies are at heart of the design process
 Trade studies should reflect all applicable requirements, functional and
non-functional
 Performance models, reliability models, etc. are used to ensure
requirements are met
• Detailed component and interface specifications
• Process may be iterated several times adding greater detail
• Identify candidate commercial off-the-shelf (COTS)/government offthe-shelf (GOTS) products for buy vs. build trade-offs
• Consider life-cycle support
• Map all requirements to system elements (Compliance Matrix)
• Map all system elements back to requirements (Requirements
Traceback)
ISSE: Develop Detailed Security
Design
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
• ISSE and SE teams iterate designs
• ISSE team allocates security requirements to system elements or
new security specific elements
• ISSE determines new external interfaces for security (e. g.,
interface to PKI or automated security update system)
• ISSE develops vulnerability analysis for overall design (you need
to know something about the to assess vulnerabilities
 Use asset and threat models to get risk profile
 Identify countermeasures
 Provide risk reduction and countermeasure cost information to overall
trade studies
 Evaluations are relative to risk requirements
Sample POSA Trade Study:
Store Network
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
Internal
Ethernet
WiFi
Power Line
Net
Install.
Cost
High
Low
Low
HW/SW/config.
Maint. cost
Low
Moderate
Low
Performance
Meets rqmts with
room for growth
Meets rqmts with
room for growth
Meets rqmts with no
room for growth
Security
Moderate
Low
Low
Future support
High
High
Moderate
Development
Schedule risk
Minimal
Minimal
Minimal
…
Security in the System Engineering
Process (Generic)
Assets at
Risk
Legal
Rqmnts
Other
Rqmts
Mission Need
CONOPS
Threat
Analysis
Functional
Rqmts
Prelim. Risk
Analysis
Primary
Sec Rqmts
Corp/Org
Policy
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
System
Arch.
Assess
Security
Arch
Derived
Sec Rqmts
Risk
Analysis
Vulner.
Analysis
Security
Design
System
Design
Assess
Other “Anti-SE” Design Models and
Security
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
• Design philosophies, such as rapid prototyping, agile
programming, and extreme programming do not fit into
the SE model at all.
• Although these are somewhat different methods, they
do not start with detailed requirements, but instead
build and use pieces out from a small core, adding
capabilities, defining interfaces,etc. based on
experience gained by using the system, essentially
getting requirements and designing from the inside out,
not top down.
• They focus on functionality, not other non-functional
requirements
How do these relate to the ISSE model
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
• Since the ISSE model presented is based on
the requirements driven analysis methods of
SE, there is no direct mapping
• But, these techniques are usually applied to
application level software, not more complete
systems
• They are often applied to applications running
in an established infrastructure (OS, DBMS,
networks, etc.) which may have been
developed more formally
What Might We do?
Quick Time™ an d a TIFF ( Un compr ess ed ) de co mpr es sor are ne ede d to se e this picture .
• Many security requirements are based on the sensitive information
already used by the infrastructure (have ISSE methods been used
there???)
• When the new applications use any of the sensitive data classes,
the existing risk analysis should be applied to derive security
requirements for the new application
• If new sensitive data classes are being used in the new application,
a new risk analysis needs to be performed, and new security
requirements developed
• The new security requirements are then allocated to elements of
the system, and the design and implementation completed.
• How do we ensure that the new application does not introduce new
system level vulnerabilities?
• This is an interesting area to explore…