Elamb Cybersecurity

Category: Assurance

  • Organizational Relationships Chart (OV-4)

    Organizational Relationships Chart

    Product Definition. The Organizational Relationships Chart illustrates the command structure or relationships (as opposed to relationships with respect to a business process flow) among human roles, organizations, or organization types that are the key pla yers in an architecture.

    Product Purpose. This product clarifies the various relationships that can exist between organizations and sub-organizations within the architecture and between internal and external organizations.

    Product Detailed Description. OV-4 illustrates the relationships among organizations or resources in an architecture. These relationships can include supervisory reporting, command and control relationships, and command-subordinate relationships. Another type of relationship is a coordination relationship between equals, where two organizations coordinate or collaborate without one having a supervisory or command relationship over the other. Others may be defined depending on the purpose of the architecture. Architects should feel free to define any kinds of relationships necessary and important within their architecture to support the goals of the architecture. For example, dynamic teams or task forces (i.e., new operational nodes) may be created in real time with only limited lifespans and assigned missions, and could have needlines assigned to them. The creating node and the created node have a unique relationship that should be documented. This relationship may not be one of lines of command or organizational hierarchies, as these do not necessarily map to the needlines of OV-2. In this product, the dynamic organizations represented by operational nodes in OV-2 have a limited lifespan and a temporary collaboration relationship.

    The product illustrates the relationships among organizations or organization types that are the key players in an architecture. These key players correspond to the operational nodes of an OV-2, which contains added detail on how the key players interact together in order to conduct their corresponding operational activities of OV-5.

    Human roles whose skills are needed to perform the operational activities or business processes described in the architecture may also be defined in OV-4. The corresponding operational activities should be decomposed to a degree that allows them to be correlated to specific human roles within organizations. In addition, and specifically in the case of target architectures, human roles that do not reflect a specific supervisory reporting, command and control, or coordination organizational structure may be used in OV-4. In this case, OV-4 may be developed using strictly human roles that are the key players in an architecture.

    Organizational relationships are important to depict in an OV (for a current architecture), because they can illustrate fundamental human roles (e.g., who or what type of skill is needed to conduct operational activities) as well as management relationships (e.g., command structure or relationship to other key players). Also, organizational relationships may influence how the operational nodes in an OV-2 are connected.

  • Operational Node Connectivity Description (OV-2)

    Operational Node Connectivity Description
    OV-2 Example

    Product Definition. The Operational Node Connectivity Description graphically depicts the operational nodes (or organizations) with needlines between those nodes that indicate a need to exchange information. The graphic includes internal operational nodes (internal to the architecture) as well as external nodes.

    Product Purpose. 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. OV-2 does not depict the connectivity between the nodes.

    Product Detailed Description. The main features of this product are the operational nodes and the needlines between them that indicate a need to exchange information. The product indicates the key players and the interactions necessary to conduct the corresponding operational activities of OV-5.

    Operational Nodes. An operational node is an element of the operational architecture that produces, consumes, or processes information. What constitutes an operational node can vary among architectures, including, but not limited to, representing an operational/human role (e.g., Air Operations Commander), an organization (e.g., Office of the Secretary of Defense) or organization type, i.e., a logical or functional grouping (e.g., Logistics Node, Intelligence Node), and so on. The notion of operational node will also vary depending on the level of detail addressed by the architecture effort.

    Needlines and Information Exchanges. A needline documents the requirement to exchange information between nodes. The needline does not indicate how the information transfer is implemented. For example, if information is produced at node A, is simply routed through node B, and is used at node C, then node B would not be shown on the OV-2 diagram – the needline would go from node A to node C. OV-2 is not a communications link or communications network diagram. The system implementation (or what systems nodes or systems are used to execute the transfer) is shown in the Systems Interface Description (SV-1). Furthermore, the needline systems equivalent is the interface line depicted in SV-1. The actual implementation of an interface may take more than one form and is documented in a Systems Communications Description (SV-2). Therefore, a single needline shown in the OV may translate into multiple interfaces in SV-1 and multiple physical links in SV-2.

    Needlines are represented by arrows (indicating the direction of information flow) and are annotated with a diagram- unique identifier and a phrase that is descriptive of the principal types of information exchanged. It is important to note that the arrows on the diagram represent needlines only. This means that each arrow indicates only that there is a need for some kind of information transfer between the two connected nodes.

    There is a one-to- many relationship from needlines to information exchanges (e.g., a single needline on OV-2 represents multiple individual information exchanges). The mapping of the information exchanges to the needlines of OV-2 occurs in the Operational Information Exchange Matrix (OV-3). For example, OV-2 may list Situational Awareness as a descriptive name for a needline between two operational nodes. In this example, the needline represents a number of information exchanges, consisting of various types of reports (information elements), and their attributes (such as periodicity and timeliness) that are associated with the Situational Awareness needline. The identity of the individual information elements and their attributes are documented in OV-3.

    OV-2 should also illustrate needs to exchange information between operational nodes and external nodes (i.e., operational nodes that are not strictly within the scope of the subject architecture but that act as important sources of information required by nodes within the architecture or important destinations for information provided by nodes within the architecture). Operational Activities. The operational activities (from the OV-5 Operational Activity Model) performed by a given node may be listed on the graphic, if space permits. OV-2, in effect, turns OV-5 inside out, focusing first-order on the operational nodes and second-order on the activities. OV-5, on the other hand, places first-order attention on operational activities and only second-order attention on nodes, which can be shown as annotations on the activities.

    Representation of the product. For complex architectures, OV-2 may consist of multiple graphics. There are at least two different ways to decompose OV-2. One method involves using multiple levels of abstraction and decomposing the nodes. Another method involves restricting the nodes and needlines on any given graphic to those associated with a subset of operational activities. Both of these methods are valid and can be used together.

    OVs usually avoid representing real physical facilities as operational nodes and focus on virtual or logical nodes that can be based on operational (human) roles or missions. Operational nodes are independent of materiel considerations; indeed, they exist to fulfill the missions of the enterprise and to perform its tasks and activities (business processes, procedures, and operational functions). Use of operational nodes supports analysis and design by separating business process modeling and information requirements from the materiel solutions that support them. Similarly, tasks and activities are organized, and communities of interest are defined to suit the mission and process requirements; the materiel is flexibly and automatically configurable to support the operational processes. However, an OV often has materiel constraints and requirements that must be addressed. Where appropriate, system or physical nodes that constitute the location of an operational node may augment the description of an operational node. These are often taken as recommendations or boundaries for further SV details.

  • DIACAP Activity #4 Maintain Authorization to Operate and Conduct Review

    Maintain Situational AwarenessIncluded in the IA controls assigned to all DoD ISs are IA controls related to configuration and vulnerability management, performance monitoring, and periodic independent evaluations (e.g., penetration testing). The IAM continuously monitors the system or information environment for security-relevant events and configuration changes that negatively impact IA posture and periodically assesses the quality of IA controls implementation against performance indicators such as security incidents, feedback from external inspection agencies (e.g., IG DoD, Government Accountability Office (GAO)), exercises, and operational evaluations. In addition the IAM may, independently or at the direction of the CA or DAA, schedule a revalidation of any or all IA controls at any time. Reference (a) requires revalidation of a select number of IA controls at least annually. (DoD 8510.01, 6.3.4.1)

    Knowing what is going on with the system is the job of the Information Assurance Manager (IAM). This can be delegated to the Information Assurance Officer (IAO) or the IAM and IAO may be the same person, but keep in mind that these permission require training, a technical and security certification (IAW DoD 8570).

    Maintain IA Posture

    Ensuring that there are no changes to the IA posture falls on the shoulders of the IAM.  This includes making sure that the establish baseline of the system has no signifigant changes.  Most patches (even involving security) will have a minimal impact on the system.  Applicable patches should always be tested before being put on a system.  Major patches are usually service packs that may actually change the IA posture.  The DIACAP Team should be involved with any major changes to the IA posture.  They will also decide which modifications, upgrades and additions should be considered changes to the IA posture of the system.  As a minimum, the Program Manager, IAM, subject matter experts (software/system security engineers) and information system owner/user representative should be appart of that decision. 

    What will likely be considered a change to the IA Posture:

    Adding IA products (firewalls, intrusion detection systems, ect)

    Some internetworking devices such as Routers and Switches

    New operating systems

    Major upgrades to software or operating systems (not including support applications)

    Newly discover major vulnerabilities

    *Basically any major changes that will affect the security, supportability, usability, and interoperability of the system.  It is important to have who, what when and where of sustainability, new risks, and usability requirements in writing.  Information Assurance includes all these things, not just security.

    What are usually not changes to the IA Posture: 

    Most NOTAM/IAVAS/TCNOs (such as Office patches, browser upgrades, ect)

    Re-positioning equipment within the office (as long as the IAM has readable documentation on the data connections)

    Adding passive periferal devices such as stand-alone printers, scanners and new monitors (devices with connectivity to external sources such as faxes, share external network printers should go before the DIACAP Team)

    Devices such as DVD, CD and hard drives with more capacity may not affect the IA Posture but it is best to have some formalized method of tracking upgrades to hardware  especially on mission systems as some changes could have some unpredictable affects

    Annual FISMA Reviews

    DIACAP includes the task of performing reviews annually on the system.  This is one of the key features of the Federal Information System Management Act of 2002.  What ever command or branch of the DoD you reside, your system has the potential of being audited annually to make sure it is in compliance with federal regulations.  The eMASS IT Portfolio management systems (EITDR, DITPR-DON, APMS) also has this feature intergrated into its key functions.  All data on each systems IA posture is collect annually.   This is done by the IAMs and/or the DIACAP Team.

    Additionally, each system must be re-accredited every three years:

    6.3.4.4. Initiate Reaccreditation. In accordance with OMB Circular A-130 (Reference (s)), an IS must be recertified and reaccredited once every 3 years. The results of an annual review or a major change in the IA posture at any time may also indicate the need for recertification and reaccreditation of the IS.  DoD 8510.01, 6.3.4.4

    From DoD 8510.01, DIACAP: 

    6.3.4.1.1. DoD ISs with a current ATO that are found to be operating in an unacceptable IA posture through GAO audits, IG DoD audits, or other reviews or events such as an annual security review or compliance validation shall have the newly identified weakness added to an existing or newly created IT Security POA&M.

    6.3.4.1.2. If a newly discovered CAT I weakness on a DoD IS operating with an ATO cannot be corrected within 30 days, the system can only continue operation under the terms prescribed in subparagraph 6.3.3.2.6.1.2.

    6.3.4.1.3. If a newly discovered CAT II weakness on a DoD IS operating with a current ATO cannot be corrected or satisfactorily mitigated within 90 days, the system can only continue operation under the terms prescribed in subparagraph 6.3.3.2.6.2.5.

    6.3.4.2. Maintain IA Posture. The IAM may recommend changes or improvement to the implementation of assigned IA controls, the assignment of additional IA controls, or changes or improvements to the design of the IS itself.

    6.3.4.3. Perform Reviews. The IAM shall annually provide a written or DoD PKI-certified digitally signed statement to the DAA and the CA that indicates the results of the security review of all IA controls and the testing of selected IA controls as required by Reference (a). The review will either confirm the effectiveness of assigned IA controls and their implementation, or it will recommend: changes such as those described in subparagraph 6.3.4.2.; a change in accreditation status (e.g., accreditation status is downgraded to IATO or DATO); or development of an IT Security POA&M. The CA and DAA shall review the IAM statement in light of mission and information environment indicators and determine a course of action that will be provided to the concerned CIO or SIAO for reporting requirements described in Reference (a). The date of the annual security review will be recorded in the SIP. A DAA may downgrade or revoke an accreditation decision at any time if risk conditions or concerns so warrant.

    6.3.4.4. Initiate Reaccreditation. In accordance with OMB Circular A-130 (Reference (s)), an IS must be recertified and reaccredited once every 3 years. The results of an annual review or a major change in the IA posture at any time may also indicate the need for recertification and reaccreditation of the IS.

  • Approved IA Products

    IA Control – DCAS-1, Acquisition Standards Security Design

    This does not apply to EVERY type of devices and/or applications only IA Products (firewalls, IDS, anti-virus ect) and IA-Enabled products (operating systems, Routers, DBMS ect). If the IA Enabled product lets say a router will be used as a dumb device like a hub in which it is just passing data between two stand alone computers (no connection to the Internet or major LAN) you probably don’t need to worry about most of this. All systems that are IA-Enabled or IA Products (defined below) that require the use of IA capabilities must match IA “protection profiles” for a particular technology. In other words, if you have a firewall (which is an IA Product) it has to have all of the security, cryptological and robust features detailed in the applicable NIAP firewall list of features better known as protection profiles. I wish it were that simple. But the firewall in the example above also has to comply with the evaluation and validation requirements of NSTISSP No. 11 which states that the firewall you bought must have a Common Criteria evaluation. Furthermore, each branch of the DoD has a list of products that they prefer that you purchase due to contractual arrangements. In the end your best bet is to only buy IA-Enabled and IA Products that have an IA capability (will protect data in some way) that are on this site http://www.niap-ccevs.org or have been accredited in accordance with the Common Criteria. If the device is not on the NIAP site you may able to find something close by googling “[YOUR PRODUCT Common Criteria]”. Also, keep in mind that all operating systems may have to have anti-virus applications that must also meettheir protection profiles.

    Protection Profiles: http://www.niap-ccevs.org/cc-scheme/pp/index.cfm

    Products used within the Department of Defense may be submitted for evaluation at evaluation assurance levels (EALs) 1-7 through the NIAP Common Criteria Evaluation and Validation Scheme (CCEVS). Alternatively, the United States recognizes products that have been evaluated under the sponsorship of other signatories and in accordance with the International Common Criteria E2.1.30.

    IA-Enabled Product. Product or technology whose primary role is not security, but which provides security services as an associated feature of its intended operating capabilities. Examples include such products as security-enabled web browsers, screening routers, trusted operating systems, and security-enabled messaging systems. E2.1.29.

    IA Product. Product or technology whose primary purpose is to provide security services (e.g., confidentiality, authentication, integrity, access control or non-repudiation of data); correct known vulnerabilities; and/or provide layered defense against various categories of non-authorized or malicious penetrations of information systems or networks. Examples include such products as data/network encryptors, firewalls, and intrusion detection devices. (DoDI 8500.2) http://www.niap-ccevs.org/cc-scheme/

    Product Specification and Evaluation

    (DoDI 8500.2) E3.2.5. Product Specification and Evaluation. At the enterprise level, implementation-independent specifications for IA and IA-enabled IT products are provided in the form of protection profiles. Protection profiles are developed in accordance with the Common Criteria (reference (j)) within the NIAP framework. Regardless of the mission assurance category or confidentiality level of the DoD information system, all incorporated IA products, and IA-enabled IT products that require use of the product’s IA capabilities, acquired under contracts executed after July 1, 2002, shall comply with the evaluation and validation requirements of NSTISSP No. 11 (reference (ah)), with the following qualifications: E3.2.5.1. If an approved U.S. Government protection profile exists for a particular technology area and there are validated products available for use that match the protection profile description, then acquisition is restricted to those products; or to products that vendors, prior to purchase, submit for evaluation and validation to a security target written against the approved protection profile. Products used within the Department of Defense may be submitted for evaluation at evaluation assurance levels (EALs) 1-7 through the NIAP Common Criteria Evaluation and Validation Scheme (CCEVS). Alternatively, the United States recognizes products that have been evaluated under the sponsorship of other signatories and in accordance with the International Common Criteria for Information Security Technology Evaluation Recognition Arrangement (CCRA) for EALs 1-4 only. E3.2.5.2. If an approved U.S. Government protection profile exists for a particular technology area, but no validated products that conform to the protection profile are available for use, the acquiring organization must require, prior to purchase, that vendors submit their products for evaluation and validation by a NIAP EVP or CCRA laboratory to a security target written against the approved protection profile or acquire other U.S.-recognized products that have been evaluated under the sponsorship of other signatories to the CCRA. E3.2.5.3. If no U.S. Government protection profile exists for a particular technology area and the acquiring organization chooses not to acquire products that have been evaluated by the NIAP CCEVS or CCRA laboratories, then the acquiring organization must require, prior to purchase, that vendors provide a security target that describes the security attributes of their products, and that vendors submit their products for evaluation and validation at a DAA-approved EAL. Robustness requirements, mission, and customer needs will together enable an experienced information systems security engineer to recommend a specific EAL for a particular product to the DAA.

    (edited: 29 August 2011. Fixed some text. Clarified some issues.)

  • DIACAP Activity #2 Implement and Validate Assigned IA Controls

    **28 Sept 2011– DIACAP is being changed to the DoD Risk Management Framework. 8510.01 is being changed to reflect the NIST SP 800-37, with security controls matching that of the NIST SP 800-53. This information is being released on the DIACAP Knowledge Service**

    This activity is marked by actually putting the IA Controls into action. This means not only coordinating with software and/or system developers and engineers, but testing the IA Controls once they have been implemented.

    Execute the DIACAP Implementation Plan

    Executing the DIACAP Implementation Plan is the most critical part of the DIACAP process because it focuses almost exclusively on the assigned security controls. Your system may very well get an authorization to operate but if it does not have the appropriate security controls it could be a detriment to an organization and anything its is attached to by being an enormous vulnerability that is easily hacked or, more likely, a wasteful product that is very difficult to support in the long term. If anything, it is more important to get the IA Controls implemented than it is to get the system approved although the process is such that you should not have one without the other.

    IA Controls are not just about security but include what the Air Force has called SISSU which stands for security, interoperability, sustainability, supportability and usability. All these features are checked annually under the DIACAP (activity #4).

    The time it takes to implement the system should factor in any additional time it might take to implement and test the IA Controls.

    Resistance to the Implementation of IA Controls

    Be prepared for panic and gnashing of teeth when you tell them what is needed. Implementing the security controls can be a challenge. The cost, time and energy it takes to accomplish all the IA Controls can be intimidating at first glance.

    Some engineers, program managers and system owners will resist the implementation of IA Controls, particularly if it is a legacy system that has operated just fine for years without any security controls. When dealing with reluctant customers the best thing you can do is come to meetings armed with federal regulations, operating instructions and mandates that have been issued by the DoD and signed by generals. You should be familiar enough to fully inform the customer of the risks associated with being non-compliant. Make sure that they are informed about how visible the system is in the eMASS database. Many times system owners will completely ignore regulations until they are absolutely forced to comply and by then they don’t have funding or time to comply.

    Methods of Implementing the IA Controls

    The technicians and/or engineers who are actually developing the system and installing the IA Controls should know about the tools that will make their job much easier.

    For Windows systems those implementing the IA Controls should know about the following:

    For Unix/Linux Systems:

    Implementing Windows IA Controls

    The quickest way to implement IA Controls on Windows systems is to use automated methods first to find and implement as many technical security features as possible and use STIGS and security guides for the remaining security controls that should be implemented. On a mission system, it is important to know that some security controls may break some critical functions. Some security controls can be ignored, some can be mitigated, some can have waivers and others absolutely must be complied with in some way, shape or form.

    Federal Standard Configuration Operating Systems (if applicable)
    Windows based systems with connections to the Global Information Grid may need to use a Federal Standard Configuration OS. This disk has various names. The USAF calls this disk the Standard Desktop Configuration (SDC) and Standard Server Configuration (SSC) for servers. Some federal organizations have Federal Desktop Common Configuration (FDCC), the Navy has NMCI systems and Army has Gold Master systems. These are locked down versions of Windows XP or Vista systems (depending on the version) that are only supposed to be altered under specialized circumstances.

    These standard configurations may pose as a serious technical issue for mission systems that are not standard. Sustainment/Supportability funding might also be an issue for mission systems as SDC is mostly designed for systems with basic computing needs in a base area networks that uses devices like Microsoft System Management Service (SMS) to conduct automated pushes from all systems on the network. Mission systems usually have to be tested separately in order make sure new upgrades and IAVA’s don’t negatively affect the mission. Your system may be able to attain a waiver for the standard configuration. This configuration may not be needed for Windows systems not connected to the GIG.

    DISA Gold DISK

    DISA has disk called the Gold Disk that can scan for Category 1, 2 and 3 vulnerabilities according the applicable Mission Assurance Level. It can also automatically fix these vulnerabilities for Windows NT/XP and Vista. This scan should also be run on the standard configuration systems. You’ll be surprise how many vulnerabilities will show up even on standard configurations such as USAF SDC.

    The challenges with the Gold Disk include the following: 1) there may be false positives. For example, Gold Disk may tell you that the Guest account should be removed. But Guest account is a built-in feature in Windows so it can only be disabled. 2) Some Category 1’s and 2’s may not be fixable on mission systems (especially legacy systems). In which case, it may have to be marked as non-compliant in the appropriate IA Controls. 3) Not all vulnerability Categories match up with the IA Controls so some of it will be up to your discretion. Also, the Cat 1, 2, or 3 results might not be applicable to your system. For example, you may have Internet Explorer vulnerabilities that pop-up on a system that will not actually use port 80 or the web at all.

    Gold Disk is automated but it still needs a fairly technical & security oriented person to interpret the data.

    Implementing UNIX/LINUX IA Controls

    Unlike Windows there is no standard configuration for any UNIX environment. Currently, there are no plans published to change this. UNIX does have an automated script called the Security Readiness Review (SRR). Running the script requires solid skills in the command line. SRR picks up a lot of false positives so the technician/engineer running the script really needs to know what is running on the system and what does not need to be running. UNIX knowledge is really a must to use the SRR effectively.

    The UNIX SRR Scripts are supported on the following platforms and versions:
    Solaris 2.5.1 through Solaris 10; HP-UX 11.0, HP-UX 11.11; Red Hat Enterprise Linux 3 and 4; and AIX 4.3. – http://iase.disa.mil/stigs/SRR/index.html

    STIGS and Security Guides

    IA Control ECSC-1, Security Configuration Compliance directs the use of security guides and STIGS. DISA and the National Security Agency have created lots of security guides for Windows and accompanying applications. Implementation of these guides will satisfy many of the other IA Controls.

    http://iase.disa.mil/stigs/stig/index.html

    IA Controls

    The IA Controls will likely be most of the work you do on any system. Even if you have a MAC III, Public, there are a lot of them. They require everything from developing and/or checking documentation, installing security features, ensuring proper network configurations to checking personnel and physical security at each site. The DIACAP Knowledge Service has several templates detailing each group of IA Controls according to Mission Assurance Levels.

    Continuity – COxx – IA Control
    The COxx series of the IA Controls deal with the continuity of the system. Developing a comprehensive continuity, disaster recovery, emergency management plan for the system will satisfy many of the COxx IA Controls. Your division, squadron, flight or company will usually have some sort of emergency management plans and disaster recovery instructions you can use. The old DITSCAP System Security Authorization Agreement had Appendix L, Contingency Plan. Many of the requested documents and process likely already exist so it maybe a matter of just finding them or re-packaging them.

    Security Design and Configuration – DCXX – IA Control
    The DCxx series deals with designing and maintaining a secure baseline. Dealing with these IA Controls will require and intimate knowledge of the systems software, hardware, and network configuration. If you don’t know the configuration of the system you should have a highly knowledgeable technician or engineer on hand who does. You will need to know the DoD policy to understand what is fully required or if the control is even applicable. Network and computer security policies such as AFI-33-202 for the USAF will be a good help. Systems that have been developed outside of the DoD and US services policies will have a real hard time with these IA Controls.

    Enclave Computing Environments – EVxx – IA Controls
    Enclave computing environments are IA Controls that deal with security features within the local area network or enclave. It will help to have some understanding of network security because some of the IA Controls address things like VPN and Remote Authentication.

    Identification & Authentication – IAxx – IA Controls
    Identification & Authentication address specific issues that deal with logon and passwords.

    Physical & Environment – PExx – IA Controls
    Physical & Environmental IA Controls deal with physical security of the sites, safety issues and environmental controls such as humidity systems.

    Personnel – PRxx – IA Controls
    These IA Controls deal with the training and access of each personnel with direct contact with the system.

    Vulnerability and Incident Management – Vixx – IA Controls
    The issues in these few IA Controls maybe addressed in the contingency plan. Elements within DITSCAP System Security Authorization Agreement had Appendix K, Incident Response may also be used for these IA Controls.


    POA&M: When Systems Can Not be Fix

    Some legacy systems can not comply with applicable IA Controls without spending millions of dollars that the program office and/or system owners don’t currently have. In these cases it’s important to have a “get well plan”. The document is called a Plan of Action & Milestone (POA&M). The POA&M details what IA Controls have not been met, when they will and how. The EITDR eMASS system can automatically create a POA&M document once all the IA Controls have been entered, Validated and Approved (others eMASS systems might be able to do this as well).

    Conduct Validation Activities

    Validation includes Certification Test & Evaluation (CT&E) and Security Test & Evaluation (ST&E). Certification Test & Evaluation is completed on a system on which IA Controls have been applied in a test environment. The CT&E is conducted to make sure all the IA Controls have been applied on a functional system. Once has been proven to work in a testing environment with all the applicable technical IA Controls applied the ST&E can be completed with a system in an operational environment.

    Techniques used in the CT&E and ST&E may include Gold Disk Scan, SRR (UNIX), penetration testing (black box, white box, gray box), network vulnerability scan, source code scan, web application scan, or simply a manual check of each of the security controls using the security guides. During and ST&E on the site it is also helpful to make sure there is proper contingency plans, physical & operational security.

  • EITDR – enterprise information technology data repository

    EITDR

    30 Aug 11 – Update *USAF Recently changed the functionality of EITDR

    To all System Security Engineers and Information Assurance Officers,

    Here is something you might need to know. The Air Force is conducting all MANY of its certification & accreditation through the EITDR database none of its C&A (soon Risk Management Framework) through EITDR. The USAF is moving to the eMASS. As of Aug 2011, the USAF is still using EITDR to do IT portfolio management (to remain compliant with FISMA). EITDR feeds into the DoD IT Portfolio Registry (DITPR) database. Each branch has its own methods IT registry: the Army’s has the Portfolio Management System (APMS), Navy/Marines have the DITPR-DON. All of these system are used to “record investment review and certification submission information, FISMA assessments, E-Authentication status, and Privacy Impact Assessment status” (office of the assistance sec of the navy).

    Each branch has an agency that controls these databases for example, the Air Force has the Air Force Communincations Agency (AFCA) AFNIC, the Army has the Installation Management Agency. These agencies moderate the certification & accreditation process. The IT Lean (aquisitions process) and the SISSU (security, interoperability, supportability, sustainability and usability) processes are integrated into the EITDR/DITPR-DON/APMS. Once you complete all the questions for you registered system, you will have accomplised complete SSAA, DIACAP, and even ISP packages.

    For more information search the public.afca.af.mil (USAF). Everything you need to know is there. Also call or email AFCA/EV to learn more.
    Army can go –>https://www.us.army.mil/suite/folder/4920492

  • Validated Product – IBM Red Hat Enterprise Linux Version 5

    I’m always happy to see Linux get on the Common Criteria validated products list. Red Hat is a good product and its good to see the industry picking up on it.

      Red Hat Enterprise Linux is a general purpose, multi-user, multi-tasking Linux based operating system. It provides a platform for a variety of applications in the governmental and commercial environment. Red Hat Enterprise Linux is available on a broad range of computer systems, ranging from departmental servers to multi-processor enterprise servers and small server type computer systems.

    It was given an Evaluation Assurance Level 4 (EAL 4).

    Good Article about it at Computer World

  • What is Information Assurance – The Video

    Information Assurance is not just information security. Information Assurance is managing the risk associated with the confidentiality, integrity and availability of information.

  • SISSU: USAF digesting the DIACAP

    I’m still learning but it looks like the Air Force is going to implement the DIACAP with its IT Lean/SISSU implementation.

    IT Lean is an initiative that is supposed to streamline the system aquisition process (more on IT Lean) by eventually getting rid of the Certificate to Operate (CTO)/Certificate of Networthiness (CON) process. SISSU stands for Security, Interoperability, Supportability, Sustainability and Usability process. All this will be possibly automated with something I am slowly begining to HATE called EITDR – Enterprise Information Technology Data Repository. The reason it rubs me the wrong way is the level of questions I have had to answer. Some of the questions are so high level I have not clue what they are even remotely talking about. And then when I ask the people who run the system to give me some hints on how to answer the questions they know even less than I do about it. So I ask, “can you give me the POC that put the question in the system?” They give me some contacts and lo and behold the contacts have no idea what the fuck I’m talking about.

    Just frustrating, thats all. Some of the questions are Zen like in that they have no answer and seemingly no questioner. They just ARE.

    ***20 April 2009 Update***********
    That actual DIACAP portion of the EITDR isn’t that bad. There are hundreds of questions in the EITDR but only some of those are necessary for a system when it starts the SISSU/IT Lean/DIACAP process.

    We used to answer ALL 500 questions in the EITDR most of which were very, very high level. Now the system is pretty specific and walks you through the DIACAP process.

  • DIACAP is READY

    What is scary, is that my blogs are on google above some of the most informative pages about DIACAP.  For this reason, the government should have secured blogs and or forum (.mil/.gov only) to allow faster access to this kind of extremily important information.  C & A, security engineering and IA officers get information much faster than the Gov’t can publish.  A security forum or secure blogs would allow some email that we get on the latest news on IA issues to be posted immediately without fear of giving out unauthorized data over the Internet.  Just one mans oppinion.

    DoD 8510.bb is signed and will supercedes DoDI 5200.40 and DoDI 8510.1-M.   

    The DIACAP Knowledge Service site is up and ready to go:

    https://diacap.iaportal.navy.mil. (.gov, .mil only)

    More information on the DIACAP – http://www.sdissa.org/downloads/Revised_DIACAP_KS_eMASS_Brief ISSA_10-28-05.ppt

    What I don’t get is how to get to eMASS. 

    Unless I have read wrong, the “Enterprise Mission Assurance
    Support System” (eMass)      is supposed to be the main feature for automating and streamlining the Certification and Accreditation process.  It seems that you have to get some sort of software to get access to eMass.  Not sure, I’m researching this while reading up on the new DIACAP documents.  

    Here is some contact information on how to get on eMass – https://diacap.iaportal.navy.mil/ks/links2/emass.aspx

    Â