Security Extensions to the DOD Architecture Framework

1. Security Extensions to the DOD Architecture Framework Kevin Richardson Information Assurance Lab Auburn University Computer Science and Software Engineering

2. What is the DODAF? • The DODAF is an architectural framework that must be followed by any organization doing government work or government contract work. • The DODAF provides information about the structure of the systems involved in an organization for many levels of abstraction.

3. DODAF Overview • The DODAF consists of four views • Operational Views (OV) • Systems Views (SV) • Technical Views (TV) • All Views (AV) • All Views provide aspects that apply to all three of the other views.

4. Operational Views (OV) • Operational views are descriptions of the tasks and activities, operational elements, and information flows required to accomplish or support an operation. [DODAF] • These descriptions are often graphical. • Operational views are doctrinal templates that illustrate which units communicate which data to which other units via which systems. [Hamilton]

5. Systems Views (SV) • Systems views are descriptions of systems and interconnections providing for, or supporting, actions. For a domain, the systems views show how multiple systems link and interoperate, and may describe the internal construction and operations of particular systems within the architecture. [DODAF] • The systems views answer the “how” questions in response to the “why” from the operational views. The systems views component of the DODAF is close – but not identical to – what a computer systems engineer would consider as an “architecture.” [Hamilton]

6. Technical Views (TV) • The technical view is the minimal set of rules governing the arrangement, interaction, and interdependence of the system parts or elements, whose purpose is to ensure that a conformant compliant system satisfies a specified set of requirements. [DODAF] • The technical view includes a collection of the technical standards, conventions, rules and criteria organized into profile(s) that govern system services, interfaces, and relationships for particular systems views and that relate to particular operational views. [Hamilton]

7. OV-2: Node Connectivity Description • The Operational Node Connectivity Description graphically depicts the operational nodes (or organizations) with need lines between those nodes that indicate a need to exchange information. [Hamilton] • The OV-2 is intended to track the need to exchange information from specific operational nodes (that play a key role in the architecture) to others. [Hamilton]

8. SV-1: Systems Interface Description • The Systems Interface Description depicts system nodes and the systems resident at these nodes to support organizations/human roles represented by operational nodes of the Operational Node Connectivity Description (OV-2). [Hamilton] • The SV-1 identifies system nodes and systems that support operational nodes. [Hamilton] • Interfaces that cross organizational boundaries (key interfaces) can also be identified. [Hamilton]

9. The SV-1 Links the OVs and SVs • By depicting the assignments of systems and system nodes (and their associated interfaces) to the operational nodes (and their associated need lines) described in the OV-2. [Hamilton] • The OV-2 depicts the operational nodes representing organizations, organization types, and/or human roles, while the SV-1 depicts the system nodes that house operational nodes and the corresponding systems resident at these system nodes which support the operational nodes. [Hamilton]

10. Proposed Security Extensions • Operational View Extensions • OV-8: Operational Node Security Table • Security Views • SECV-1: User Roles • SECV-2: Authentication Schema • SECV-3: Software Protection • SECV-4: Network Level Protection

11. OV-8: Operational Node Security Table • The OV-8 lists all of the security requirements of the nodes and need lines identified in the OV-2 Operational Node Connectivity Diagram. • These security requirements can cover any number of areas from software security to hardware and network security to Tempest countermeasures. • They should form the basis of policy for the system being described. • The listed requirements in this product will be the basis for the Security Views which document implementation of these policies at a system level.

12. SECV-1: User Roles • The idea behind this extension is that all users of a system are not the same. Each user has different needs and should be limited to only what they need to do. • This view is a guide on how to document users and user roles. • Roles are defined according to policy (OV-8) and aspects of the system that need to be accessed.

13. SECV-2: Authentication Schema • This document describes an implementation of a network wide authentication system. • A simple diagram of software that needs to authenticate against these different systems should be shown here. • This would be more explicit that what would be explained in an OV-1 or SV-2. • Roles could also be associated with different authentication databases.

14. SECV-3: Software Protection • Security View 3 contains information regarding the software protection scheme required on each machine. • Included in this are version control methods, encryption used on software artifacts, and specifications of software firewalls.

15. SECV-4: Network Level Protection • Security View 4 contains information regarding the network level protection required. • This view includes information on the specifications and placement of network firewalls, network wide anti-virus measures, encryption used in network communications, and physical security requirements for the network.

16. Future Work • We plan on connecting the Security Views to one of the Systems Views or creating a new Systems View to accomplish this task. • We are also looking at the possibility of creating an XML based DODAF Architecture Tool. • This software would be open source and provide plug-in capability so that XML based extensions could be added later.

17. References • DOD Architecture Framework Version 1.0 Volume II, 9 February 2004, Washington D.C. • Hamilton, Drew, DOD Architecture Framework Seminar, 9-10 September 2004, Washington D.C.