Integration of Information Assurance (IA) into DoDAF Architectures

1Copyright (c) 2004 Booz Allen Hamilton. All rights reserved

Integration of Information Assurance (IA) into DoDAF Architectures

Annual Computer Security Applications Conference(ACSAC ’04)

8 December 2004

Edward RodriguezBooz Allen Hamilton

2Copyright (c) 2004 Booz Allen Hamilton. All rights reserved 2

AgendaEnterprise Architecture Overview

Problem Statement & Solution Approach

Candidate Techniques to Integrate IA into DoDAF architectures

Final Thoughts


Architecture Defined

"An architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.”IEEE STD 1471-2000

ArchitectureArchitectureArchitecture == Structure ofComponentsStructure ofStructure ofComponentsComponents

RelationshipsRelationshipsRelationshipsPrinciples &Guidelines

Principles &Principles &GuidelinesGuidelines++ ++

Slide courtesy of The MITRE Corporation


Purpose of the Enterprise ArchitectureInformInform, guideguide, and constrainconstrain decisions for the enterprise

Specifically:– Capture facts in an understandable way to promote better planning and

decision making (IT investments)– Promote better communication (architectural views)– Improve consistency, accuracy, timeliness, integrity, quality of information– Achieve economies of scale, re-use, standardization, collaboration, shared

services– Expedite integration of legacy, transition, target systems– Ensure legal and regulatory compliance


These Frameworks Are Focused on the Commercial, DoD/IC, and Federal Domains

e.g., Data Design

Entity=Segment/RowRelationship=Pointer/

Key

List of LocationsImportant to Business

Node=Major Business Location

Data Function Network People Time MotivationList of Things

Important to Business

Entity=Class ofBusiness Thing

List of Processes theBusiness Performs

Function=Class of Business Process

List of OrganizationsImportant to Business

Agent=Major Org Unit

List of EventsSignificant to Business

Time=Major BusinessEvent

List of BusinessGoals/Strategies

End/Means=MajorBusiness Goal/CSF

e.g., EntityRelationship

Diagram

Ent=Business EntityRel=Business Rule

e.g., EntityRelationship

Diagram

Ent=Business EntityRel=Business Rule

e.g., Function FlowDiagram

Function=Business Process

e.g., Data Model

Entity=Data EntityRelationship= Data

Relationship

e.g., Structure Chart

Funct=Computer FunctArg=Screen/Device

Formats

e.g., System Architecture

Node=Hardware/System Software

Link=Line Specification

e.g., Logistics Network

Node=BusinessLocation

Link=BusinessLinkage

e.g., Program

Funct=Language StmtsArg=Control Blocks

e.g., NetworkArchitecture

Node=AddressesLink=Protocols

e.g., OrganizationChart

Agent=Org UnitWork=Work Product

e.g., Business Plan

End=BusinessObjectives

Means=BusinessStrategy

e.g., Human InterfaceArchitecture

Agent=RoleWork=Deliverable

e.g., Security Architecture

Agent=IdentityWork=Transaction

e.g., ProcessingStructure

Time=System EventCycle=Processing Cycle

e.g., Control Structure

Time=ExecuteCycle=Component Cycle

e.g., Timing Definition

Time=InterruptCycle=Machine Cycle

e.g., KnowledgeArchitecture

End=CriterionMeans=Option

e.g., Knowledge Design

End=ConditionMeans=Action

e.g., KnowledgeDefinition

End=SubconditionMeans=Step

e.g., Data DefinitionDescription

Ent=FieldsRel=Addresses

e.g., Data Flow Diagram

Funct=Appl FunctionArg=User Views

Analyst Engineer Secretary

e.g., Human/Technology Interface

Agent=UserWork=Job

Analyst Engineer

e.g., Master Schedule

Time= Business EventCycle=Business Cycle

e.g., DistributedSystem Architecture

Node=Info Sys FunctLink=Line Char

Secretary

Planner’sView

Owner’sView

Designer’sView

Builder’sView

Sub-Contractors

View

Technical Standards ForecastTV-2Technical

Technical Standards ProfileTV-1Technical

Physical SchemaSV-11Systems

Systems Functionality Sequence and Timing DescriptionsSV-10a, b, cSystems

Systems Technology ForecastSV-9Systems

Systems Evolution DescriptionSV-8Systems

Systems Performance Parameters MatrixSV-7Systems

Systems Data Exchange MatrixSV-6Systems

Operational Activity to Systems Function Traceability MatrixSV-5Systems

Systems Functionality DescriptionSV-4Systems

Systems-Systems MatrixSV-3Systems

Systems Communications DescriptionSV-2Systems

Systems Interface DescriptionSV-1Systems

Logical Data ModelOV-7Operational

Operational Activity Sequence and Timing DescriptionsOV-6a, b, cOperational

Operational Activity ModelOV-5Operational

Organizational Relationships ChartOV-4Operational

Operational Information Exchange MatrixOV-3Operational

Operational Node Connectivity DescriptionOV-2Operational

High-Level Operational Concept GraphicOV-1Operational

Integrated DictionaryAV-2All Views

Overview and Summary InformationAV-1All Views

Framework Product NameFramework ProductApplicable View















































Zachman Framework

DoD ArchitectureFramework (DoDAF)

Federal Enterprise ArchitectureFramework (FEAF)


DoDAF Overview

Oper

atio

nal System

s

Technical


DoDAF Architecture Views

• Functional (operational) requirements• Processes and relationships• Information needs (content, form,

protection)• User functions• Performance bounds

•• Functional (operational) requirementsFunctional (operational) requirements•• Processes and relationshipsProcesses and relationships•• Information needs (content, form, Information needs (content, form,

protection)protection)•• User functionsUser functions•• Performance boundsPerformance bounds

• System functional descriptions• System interfaces and connections• Operations-to system traceability

•• System functional descriptionsSystem functional descriptions•• System interfaces and connectionsSystem interfaces and connections•• OperationsOperations--to system traceabilityto system traceability

COTSProducts• ANSI X12 ICs

• EDIFACT• HL7• XML• HTML• Proprietary (rare)

StandardsTechnical ViewTechnical View

Systems ViewSystems View

CongressWarfighters

Large & SmallBusinesses

• Technical Architecture Profile• Standards and Technology

Forecast

•• Technical Architecture ProfileTechnical Architecture Profile•• Standards and Technology Standards and Technology

ForecastForecast

DOD

Services &Agencies

VPN

SmartCardFirewall

Perimeter SecurityMechanisms

DataRepositories

InfrastructureServices

Applications

EAI/ETL

JTA ITStandards

DIICOE

APIs

Operational ViewOperational View

GCSS-AF


Problem Statement

DoD System DevelopmentEfforts Require Development

Of DoDAF ArchitectureEarly in the Life Cycle

“Secure systems are developed most effectively

by considering & integrating security early in the

development life cycle”

+How do you integrate security architecture

guidance into C4ISR/DoDAF

architectural products?


Approach to Solving Problem

If “best practices” do not exist, develop candidate strategies for integrating IA into C4ISR/DoDAF

architectures.

What “best practices” exist that address the

integration of Information Assurance (IA) into

C4ISR/DoDAF architectures?

How do you integrate security architecture

guidance into C4ISR/DoDAF

architectural products?


Approach to Solving ProblemSearch for examples of efforts to integrate IA into C4ISR/DoDAF compliant architectures in public domain

Search for guidance from DoDAF and C4ISR architecture government documentation

Intra-company & community search for feedback on this topic

Draw from personal exposure to assignments related to C4ISR/DoDAF products


Initial Findings Very limited information found via Web searches– In some instances “IA is important…” but that was all

Search through DoDAF also yielded limited information/guidance – OV-2/3: Security/IA attributes included for needlines– TV-1: Inclusion of Security/IA standards– OV6b/c: Capture security activities & events


Initial Findings (cont.)One approach was to develop stand-alone narrative documents that describe the application of security services to the architecture and the identification of security oriented components– Not integrated into DoDAF framework

Another employed approach was to identify some security services(SV-4), some limited OV-5 activities, and some security components (SV-1/2)

One framework, TEAF (Treasury Enterprise Architecture Framework), includes some security constructs


So the question remains…

+ =?Technical Standards ForecastTV-2Technical






































































Proposed Practices for IA Integration into C4ISR/DoDAF Architectures

Inclusion of IA activities at the Context level for the OV-5

Extension of DoDAF to include a SV-12

Use of IA narrative documentation

System Functions

Operational Activities

“Security Overlay” System View

Definition of IA influenced SV-4 hierarchy

Standalone Documentation


IA Influenced SV-4 Hierarchy

SecurityManagement

FoundationalInformation

Assurance (IA)

MissionInformation

Assurance (IA)

The DoD Information Assurance Technical Framework (IATF) construct for Defense in Depth (DiD) used to organize the required functions

–Defend the Network & Infrastructure–Defend the Enclave Boundary–Defend the Computing Environment–Supporting Infrastructures


IA Influenced OV-5 ConstructInclusion of IA activities at the Context level

MajorActivity 1

MajorActivity 2

PerformIA

Influenced by the three major groups of users

– End user (focused on core mission)– Security manager– System manager / Privileged users

Candidate grouping of activities– Prevent Unauthorized Disclosure– Prevent Unauthorized Modifications– Manage User Access– Maintain Secure Operations


Extension of DoDAF to include a SV-12DoDAF allows the definition of additional views

SV-12, Security Overlay, is a supplemental view focused on IA specific characteristics of the system– Uses only data elements currently defined by existing System Views– Allow a security oriented view consistent with the rest of the DoDAF

architecture

Initially performed via “Powerpoint™ Engineering”– Not an integrated architecture approach– Therefore, arguably, not in compliance with DoD direction/guidance

regarding the development of “integrated architectures”


Notional SV-12 – User Login

SV-1 View provides a perspective associated with the physical dimension of the system

E-Business Public Node

Portal

Web Server

Application Server

E-Business Backend Node

Business Infrastructure

XYZ

Corporate Server




Portal

Web Server

Application Server



XYZ

Corporate Server

SV-4 functions used to accomplish a particular security related activity are overlay on the system elements where the functions are executed

For some security functionality, it matters where the function is performed

Authentication

Authorization

Data Store Access



SV-4 data flows specifically used by the selected functions to accomplish the particular security related activity are added

Where functions are fairly complex, it is important to define specific data flowsNote: sequencing information not included… Separate SV-10c diagram required


Portal

Web Server

Application Server



XYZ

Corporate Server

Authentication

Authorization

Data Store Access


SV-12 UsageUseful to create views for the various topics that Certification and Accreditation (C&A) staff require information and knowledge on– Authentication– Login for General Users– Login for Privileged Users– System auditing– Etc.

Powerful to discuss these topics with artifacts that are consistent and integrated with the overall architecture and underlying data models– Also helps to explain how the security requirements are to be met

Refinement of SV-12 concept likely as feedback from various stakeholders is received and lessons learned applied


Use of IA Narrative DocumentationNarrative documentation may still be required for those stakeholders that are uncomfortable with C4ISR/DoDAF views

May be required to support C&A documentation requirements– Nonetheless, opportunity to couple Security documents (e.g., Security

CONOPS) to key C4ISR artifacts


Final Thoughts

Historically, security awareness has lagged behind emphasis on functionality and performance

The importance / business value of security is not easily quantifiable– How do you calculate ROI?

Other possible hypotheses– Limited input by the security community in regards to what is important to

capture from an architectural perspective– Limited input by the security community in regards to how to capture what

is important within the existing architectural frameworks

Why hasn’t Security Been More IntegratedInto Enterprise Architecture Frameworks?


Final ThoughtsJust a few steps to hopefully move DoDAF community in a constructive direction in the area of integrating IA into C4ISR/DoDAF architectures

If security knowledgeable professionals don’t actively seek out opportunities to integrate the IA dimension into main stream system engineering processes then it won’t naturally happen

These ideas are not the product of any one individual, so thanks and acknowledgements are due:– Tom Vander Vlis– Barry Lewis– Frank Kroll


Thanks

Ed RodriguezSenior Associate

Booz | Allen | Hamilton

Tel (301) [email protected]

Ed RodriguezSenior Associate

Booz | Allen | Hamilton

Tel (301) [email protected]

Documents

Integration of Information Assurance (IA) into DoDAF Architectures