170 likes | 609 Views
Security Extensions to the DOD Architecture Framework. Kevin Richardson Information Assurance Lab Auburn University Computer Science and Software Engineering. What is the DODAF?.
E N D
Security Extensions to the DOD Architecture Framework Kevin Richardson Information Assurance Lab Auburn University Computer Science and Software Engineering
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.
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.
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]
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]
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]
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]
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]
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]
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
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.
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.
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.
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.
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.
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.
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.