jack holleran information assurance for systems engineers

ISSA meeting April 25, 2012

1

Jack Holleran

1

[email protected]

2

Information Assurance for

Systems Engineers

Information Assurance

Revision 4.0

30 September 2009

Define roles and responsibilities of Information Systems

Security Engineers (ISSE) as they relate to Systems

Engineering (SE)

Describe how Information Assurance (IA) integrates with the

SE Process

Define the pillars of information assurance

3

Objectives

4

Systems Engineering

Disciplines and Relationships

Logistics

Risk

Configuration Management

Schedule

Requirements Procurement

Test

Integration Transformation System Thinking

Lean Thinking Change

Management

Governance

Stakeholders

Customer

Performance/Build

Performance appraisals Mentoring

Training Political Pressure

Unrelated Meetings

Unresolved Issues

Congressional Oversight

Staffing Problem DoD 5000 policy

Multiple Policies

Program for the Record

Internal funding Issues

90 Day Spins

Contract Issues

Mission Change

Contractor Problems

Legal

5

Systems Thinking – “The Big Picture”

The Big Picture

I’m the ISSE.

How do I make a product successful?

6


2

Mapping C&A through Acquisition, SDLC, and Risk Management Framework

7

Ehlers, S. (2007). Certification and Accreditation Transformation Overview. Briefing to the Annual Computer Security Applications Conference: Office of the Director

of National Intelligence.

Define the role of an Information Systems Security Engineer

(ISSE)

Identify the security requirements addressed by Director of

Central Intelligence (DCID) 6/3 (replaced by ICD 503)

Identify corresponding SE and ISSE activities

Identify the pillars of Information Assurance

8

Goals

So… what is an ISSE?

A Security specialist who

applies system security principles

and practices to Information Systems

(IS)

uses regulations, policies and

procedures to assist with the security

evaluation of an IS1

9

1 IAD ISSE within DOD’s Current AF and JCIDS

Process

and… what does an ISSE do?

Captures and refines information

engineering protection

requirements

Ensures that the requirements are

integrated into IT acquisition

processes through purposeful

security design or configuration2

Ensures teams are appropriately

certified IAW DoD8570.01-M

10

2 CNSS Instruction No. 4009 Revised May 2003

How does an ISSE do it?

By applying controls (confidentiality,

integrity, availability) and security

management services appropriate to each

information threat 3

11

C-I-A Triad

3 IATF Release 3.1 September 2002

DCID 6/3 (replaced by ICD 503) Guidance for adequate protection of intelligence information

stored or processed on an information system

Establishes the minimum set of security requirements defined

by the Director of Central Intelligence Directive

DCID 6/3 requirements are standardized and reinforce the

C-I-A Triad

Chapter 4: Confidentiality

Chapter 5: Integrity

Chapter 6: Availability

12

Systems may require more, but never fewer requirements!


3

Corresponding SE and ISSE Activities

SE Activities ISSE Activities

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 System Implement System Security

Assess Effectiveness Assess Information Protection

Effectiveness

13

Four Model Methodologies

Waterfall Model Systems Engineering V Model Spiral Model Agile

14

Waterfall Model

15

Systems Security Requirements (DCID

6/3, DoD 8500, NSAM 130-1, etc.)

Security testing

Integrate requirements into architecture

& design

Authority to operate (ATO) –

Configuration controlled

Ensure secure products [COTS &

GOTS] meet compliance needs

such as NIAP, acquisition security,

etc.

Certification testing

Carr, J. (2000). Requirements engineering and management: the key to designing quality complex systems. The TQM Magazine,

12(6), 400-407.

16

$$$ Perspective of Waterfall Model $$$

The importance of “early

detection” is evident in

many areas of system

development…information

security/assurance is no

different.

Carr, J. (2000). Requirements engineering and management: the key to designing quality complex systems. The TQM Magazine,

12(6), 400-407.

Another

perspective

3.5 days to almost

7 man-years JCH

Systems Engineering V model Stage 1: Concept of Operations — The manner in

which the system will be used is defined.

Stage 2: Requirements — High level and detailed requirements define what the system will do.

Stage 3: Design — High-level and detailed specifications define how the system will meet the requirements.

Stage 4: Implementation — The components are built or deployed.

Stage 5: Integration & Testing — As each component of the system is completed, it is integrated into the overall system and tested to ensure that the specifications are satisfied.

Stage 6: System Verification — Also called acceptance testing, this step ensures that the overall system is consistent with the design, and that it meets the requirements.

Stage 7: Operations & Maintenance — This stage represents the ongoing process of using the system in the manner in which it was intended (and validating that it can be used in this way) and maintaining the system.

17

Retrieved from: http:www.standards.its.dot.gov - Research Innovative Technology Administration (RITA), U.S. Department of

Transportation (US DOT). 18

Spiral Model

Wahl, T. (2009). Course Lecture Material for COMP 491/492. Dickinson College. Retrieved from:

http://users.dickinson.edu/~wahlst/491/lectures/lec02.html


4

Agile Development

19

Pearce, J. (2008). Course material for Object-oriented methodology (OOM). Course Material from San Jose Statue University.

http://www.cs.sjsu.edu/faculty/pearce/oom/se/agile.htm

Minimizes:

•formal

requirements

•acceptance test

Agile Development

20

Pearce, J. (2008). Course material for Object-oriented methodology (OOM). Course Material from San Jose Statue University.

http://www.cs.sjsu.edu/faculty/pearce/oom/se/agile.htm

Significant

difference in agile

implementation


21

DoD 5000.2-R SE Process

System Engineering Process Inputs:

• Customer needs/

objectives/requirements

• Technology base

• Output requirements from prior

development effort

• Program decision requirements

• Requirements applied through

specifications and standards

ISSE Process

Discover Information Protection Needs:

• Analyze organization’s mission

• Identify legal and regulatory requirements

• Identify classes of threats

• Determine impacts

• Identify security services

• Document the information protection needs

• Identify design constraints

Source: Appendix J IATF Release 3.1 Sept 2002


22


Requirements Analysis:

• Analyze missions and environments

• Identify functional requirements

• Define or refine performance and

design constraint requirements

ISSE Process

Define System Security Requirements:

• Develop system security context

• Develop security CONOPS

• Develop system security

requirements baseline

• Review design constraints



23


Functional Analysis/Allocation:

• Decompose to lower-level functions

• Allocate performance and other

limiting requirements to all

functional levels

• Define or refine functional

interfaces (internal and external)

• Define/refine/integrate functional

architecture

ISSE Process

Design System Security Architecture:

• Analyze candidate systems

architectures

• Allocate security services to

architecture

• Select mechanism types

• Submit security architecture(s) for

evaluation

• Revise security architecture(s)

• Select security architecture



24


Requirements Loop:

• Reconsider Requirements Analysis

to establish traceability of functions

to requirements

ISSE Process

Assess Information Protection

Effectiveness:

• Provide/present security context,

security CONOPS, and system

security requirements to the

customer

Support System C&A:

• Identify DAA/Accreditor

• Identify Certification

Authority/Certifier



5


25


Synthesis:

• Transform architectures (functional

to physical)

• Define alternative system concepts,

configuration items, and system

elements

• Select preferred product and

process solutions

• Define or refine physical interfaces

(internal and external)

ISSE Process

Develop Detailed Security Design:

• Ensure compliance with security

architecture

• Perform trade-off studies

• Define system security design

elements

• Develop specifications



26


Design Loop:

• Revisiting the functional

architecture to verify that the

physical design synthesized the

required functions at the required

level of performance

ISSE Process Assess Information

Protection Effectiveness:

• Conduct design risk analysis

• Ensure that the selected security

design provides the required

security services

Support System C&A:

• Prepare and submit detailed design

documentation for risk analysis



27

DoD 5000.2-R SE Process Process Output:

• Development Level Dependent Decision database

System and configuration item

architecture

Specifications and baselines

ISSE Process Implement System Security:

• Support security implementation

and integration

• Support test and evaluation



28

DoD 5000.2-R SE Process Verification:

• Comparison of the solution to the

requirements

ISSE Process Assess Information Protection Effectiveness:

• Monitor to ensure that the security design is implemented correctly

• Conduct or update risk analysis Support System C&A:

• Ensure the completeness of the required C&A documentation with the customer and the customer’s Certifiers and Accreditors



29

IEEE 1220-1998 SE Process Requirements Analysis:

• Define customer expectations • Define project, enterprise and

external constraints • Define operational scenarios • Define measures of effectiveness • Define system boundaries • Define interfaces • Define utilization environments • Define life-cycle process concepts • Define functional requirements

ISSE Process Discover Information Protection Needs:

• Analyze organization’s mission

• Determine relationship and importance

of information to mission

• Identify classes of threat

• Determine impacts

• Develop system security context

• Develop security CONOPS

• Develop system security requirements

baseline



30

IEEE 1220-1998 SE Process Requirements Verification and Validation:

• Compare to customer expectations

• Compare to enterprise and project

constraints

• Compare to external constraints

• Identify variances and conflicts

• Establish validated requirements

baseline


• Present documented information protection needs to the customer

• Obtain concurrence from the customer

Support System C&A:

• Identify DAA/Accreditor • Ensure Accreditor & Certifier's

concurrence Security CONOPS System security requirements



6


31

IEEE 1220-1998 SE Process Functional Analysis:

• Functional context analysis

• Functional decomposition

• Establish functional architecture

ISSE Process Design System Security

Architecture:

• Analyze candidate systems

architectures

• Allocate security services to

architecture

• Select mechanism types

• Submit security architectures(s) for

evaluation



32

IEEE 1220-1998 SE Process Functional Verification:

• Define verification procedures

• Conduct verification evaluation

• Identify variances and conflicts

• Verified functional architecture


• Ensure that the selected security mechanisms provide the required security services

• Perform risk analysis Support System C&A:

• Prepare and submit final architecture documentation for risk analysis

• Coordinate results with Accreditor & Certifier



33

IEEE 1220-1998 SE Process Synthesis:

• Group and allocate functions

• Identify design solution alternatives

• Assess safety and environmental

hazards

• Assess life-cycle quality factors

• Assess technology requirements

• Define design and performance

characteristics

ISSE Process Develop Detailed Security Design:

• Ensure compliance with security

architecture

• Perform trade-off studies

• Define system security design

elements



34

IEEE 1220-1998 SE Process Design Verification:

• Select verification approach

• Identify variance and conflicts

• Verified design architecture

• Verified design architectures of life-

cycle processes

• Verified system architecture

• Establish specifications and

configuration baselines

• Develop product breakdown

structures

ISSE Process Assess Information

Protection Effectiveness:

• Conduct design risk analysis

• Ensure that the selected security

design provides the required

security services

Support System C&A:

• Prepare and submit detailed design

documentation for risk analysis



35

IEEE 1220-1998 SE Process System Analysis:

• Assess requirement conflicts • Assess functional alternatives • Assess design alternatives • Identify risk factors • Define trade study scope / conduct

trade study • Analyze life-cycle costs, system and

cost-effectiveness • Quantify risk factors and select

handling options

ISSE Process Support System C&A:

• System analysis is part of the risk

assessment process, which also is

part of the analysis performed in

each activity. Therefore, the specific

tasks are cited in the elative SEP

sub-processes.



36

IEEE 1220-1998 SE Process System Analysis:

• The IEEE standard defines systems

engineering as the total

development effort and does not

address implementation that would

be addressed by manufacturing and

test processes

ISSE Process Implement System Security:

• Support security implementation and integration

Assess Information Protection Effectiveness:

• Monitor to ensure that the security design is implemented correctly

Support C&A: • Provide documentation and analysis

as required for the C&A process



7


37

IEEE 1220-1998 SE Process Control:

• Technical management • Track system analysis, and

verification and test data • Track requirements and design

changes • Track performance against project

plans • Track performance against technical

plans • Track product and process metrics • Update specifications and

configuration baselines

ISSE Process Plan Technical Effort:

• Estimate project scope

• Identify resources and availability

• Identify roles and responsibilities

Manage Technical Effort:

• Direct technical effort

• Track project resources

• Track technical parameters


Mapping C&A through Acquisition, SDLC, and Risk Management Framework

38



39

Pillars of Information Assurance

Systems Thinking ties it all Together!

Co

nfi

de

nti

ali

ty

Inte

gri

ty

Ava

ila

bil

ity

Au

the

nti

ca

tio

n

Au

tho

riza

tio

n

No

n-R

ep

ud

iati

on

Committee on National Security System (CNSS) Corporate Initiatives – Policies - Committees

Confidentiality

How?

Ensuring that only authorized parties

can access data

Example:

An unauthorized individual “shoulder-

surfing” the computer screen of an

authorized user

40

Protection Against Unauthorized Disclosure

Corporate Initiatives – Policies - Committees

Committee on National Security System

Co

nfi

den

tiality

Inte

gri

ty

Availab

ilit

y

Au

then

ticati

on

Au

tho

rizati

on

No

n-r

ep

ud

iati

on

Information Assurance Services

Integrity

How?

Verifying that data has not been altered

Example:

A student who breaks into a system to

change his grades; “poisoning” of a

database; or a virus that deletes specific

files

41

Protection Against Unauthorized Data Modification



Co

nfi

den

tiality

Inte

gri

ty

Availab

ilit

y

Au

then

ticati

on

Au

tho

rizati

on

No

n-r

ep

ud

iati

on


Availability

How?

Ensuring that systems or data can be

accessed when needed

Example:

“Flooding” a network with bogus traffic

so legitimate network traffic cannot

reach its destination

42

Protection Against Denial of Service



Co

nfi

den

tiality

Inte

gri

ty

Availab

ilit

y

Au

then

ticati

on

Au

tho

rizati

on

No

n-r

ep

ud

iati

on



8

Authentication

How?

Validating the identity of the sender

and/or receiver

Examples:

The process of validating a subject’s

identity through a password, token,

etc.

Tokens or certificates in the Public

Key Infrastructure (PKI)

43

Protection Against Spoofing/Forgery



Co

nfi

den

tiality

Inte

gri

ty

Availab

ilit

y

Au

then

ticati

on

Au

tho

rizati

on

No

n-r

ep

ud

iati

on


Authorization

How?

Granting or denying a subject’s access to an object based on authentication

Examples:

Compares the credentials to its access control list (ACL)

Authorizes or denies access based on the ACL

Corporate Authorization Service (CASPort)

44

Protect User, Program, or Process Access



Co

nfi

den

tiality

Inte

gri

ty

Availab

ilit

y

Au

then

ticati

on

Au

tho

rizati

on

No

n-r

ep

ud

iati

on


Non-Repudiation

How?

Validating that communications have

come from a user and that the data has

not been altered in transit

Example:

Only the sender knows their private

key and can encrypt using that private

key

45

Protection Against Denial of Transaction Participation



Co

nfi

den

tiality

Inte

gri

ty

Availab

ilit

y

Au

then

ticati

on

Au

tho

rizati

on

No

n-r

ep

ud

iati

on


Some additional Slides with

references

46

Relationships, Policy, & Standards

External

Standards

Organization

Agency

Partner

Advocate

Agency

Customer

Advocate

Oversight

Enterprise Needs

Analysis & Req. Gen.

Standards Selection

Standards Review

Support Standards

Usage

Program Management

& Development

Awareness

Assess

Effectiveness

Standards

Implementation

Lead (SIL)

Program

Manager

User

Compliance

Enforcer

Federal Agency Information

Assurance Policy Drivers

OMB A-130, Appendix III, Security of Federal Automated

Information Resources

Federal Information Security Management Act (FISMA)

NIST 800-37. Certification & Accreditation

NIST 800-30, Risk Management Guide for Information

NIST 800-12, The NIST Handbook to Computer Security

NIST 800-14, Generally Accepted Principles and Practice for

Securing Information Technology Systems

48


9

DoD Information Assurance Policy

Drivers

OMB A-130, Appendix III, Security of Federal Automated Information Resources

DoD 8500.1 Information Assurance Directive

DoD 8500.2 Information Assurance Implementation

NSTISSP No. 6, National Policy on Certification and Accreditation of National

Security Telecommunications and Information Systems

NSTISSI No.1000, National Information Assurance Certification and Accreditation

Process (NIACAP)

DoD 8510.1 Manual: Department of Defense Information Assurance Certification

& Accreditation Process (DIACAP)

49

Information Assurance Policy Drivers

DoD Drivers…plus the following: Manual 130-1, Operational Information Assurance Manual

Not all-encompassing

Implementation “assistant”

DCID 6/3, Protecting Sensitive Compartmented Information within Information

Systems (now obsolete, but some systems are still accredited by this)

ICD 503 – Intelligence Community Information Technology Systems Security Risk

Management, Certification and Accreditation

Information System Certification and Accreditation Process Guide (NISCAP)

Comprehensive evaluation of tech and non-tech security features

Map methodology of designed safeguards to ensure compliance of design and security

requirements

50

National Information Assurance

Partnership

National Information Assurance Partnership (NIAP)

Created to meet the security testing needs of both information technology (IT)

consumers and producers

Goals:

Promote development and use of evaluated IT products & systems

Champion the development & use of national & international standards for IT security

Foster R&D in IT security requirements definition, test methods, tools, techniques, and

assurance metrics

Support a framework for international recognition and acceptance of IT security testing

and evaluation and results

51

A Unified Framework

52



jack holleran information assurance for systems engineers

Documents