Information System Security Engineering and Management

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.Information System Security Engineering and Management

INFORMATION SECURITY IN THESYSTEM ENGINEERING PROCESS

Dr. William [email protected]

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.

Talk Outline

• 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

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.Systems Engineering--One View

• 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

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.Definition of Systems Security Engineering

“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)

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.What is a System?

• 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

• 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

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.The “Vee” Model of System Development

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


What is Systems Engineering?

• 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 Assessment

Next Phase(Requirements

SynthesisAssessment)

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.Information System Security Engineering (ISSE)

• 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

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.Information System Security Engineering (ISSE)

• 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

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.Information System Security Engineering (continued)

• 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

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.One Common SE Model: Waterfall Model

• Concepts• Requirements• Design• Implementation• Test• Installation and Checkout• Operation• Maintenance• Retirement

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.Another View: IATF Systems (Security) Engineering Process

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.Primary SE and ISSE Phases in IATF Model

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

• 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

• 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.

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.POSA Mission Needs (System Concept)

• 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)


• “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

SE: Define System Requirements


• 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)


• 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.




• 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.

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.CONOPS

• 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

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.Security CONOPS

• 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

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.ISSE: Security Requirements Definition

• 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


• 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

Other sources of initial requirements

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.Sample POSA Security Requirements

• Confidentiality of credit/debit card information• Integrity of approval function• Availability of approval function• …

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.SE: Design System Architecture

• 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

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.System Requirements vs. System Architecture

What the system has to do How components fit together to do it


Design System Architecture

• 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.

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.ISSE: Design System Architecture

• 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

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.POSA Architecture

POSA

CFAC

USER

Register

Store Network

UserInterface

Register link

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

• 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

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.SE: Develop Detailed Design

• 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 off-the-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)

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.ISSE: Develop Detailed Security Design

• 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

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.Sample POSA Trade Study: Store Network

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

…


Mission NeedCONOPS

SystemArch.

PrimarySec Rqmts

LegalRqmnts

Assets atRisk

Corp/OrgPolicy

SecurityArch

ThreatAnalysis

Vulner.Analysis

SystemDesign

SecurityDesign

DerivedSec Rqmts

OtherRqmts

Security in the System Engineering Process (Generic)

Prelim. RiskAnalysis

FunctionalRqmts

RiskAnalysis

Assess

Assess

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.Other “Anti-SE” Design Models and Security

• 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

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.How do these relate to the ISSE model

• 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?

• 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…

Date post:	08-Jan-2016
Category:	Documents
Upload:	sal
View:	27 times
Download:	2 times

Information System Security Engineering and Management

Documents