This article discusses how the Navy organization, the Deputy Assistant Secretary of the Navy for Acquisition Management, DASN (ACQ), successfully achieved certification and accreditation for the One Source website built by Automation Technologies Inc. (ATI). The site is deployed on the Pentagon's network infrastructure (called the Unclassified but Sensitive Internet Protocol Router Network (NIPRNet)) hosted by the United States Army Information Technology Agency (USAITA). The NIPRNet was formerly referred to as the "Non-secure Internet Protocol Router Network".
The DASN (ACQ) One Source web site is a system comprising open-source software that is based on eZ Systems' eZ publish (http://ez.no) software, which is internationally known as a robust, highly customizable content management framework.
Automation Technologies Inc. (ATI) has been under contract to support the Navy organization DASN (ACQ) since July 2003. ATI was tasked by the DASN (ACQ) client, Mr. Page Glennie, to complete the certification and accreditation activities of DITSCAP and ensure that the DON Acquisition One Source website fully complied with all DOD information assurance regulations.
While the One Source website has been fully operational and publicly available since November of 2003, ATI began initial DITSCAP tasks in November of 2005 and completed their final activities nine months later in August of 2006.
The potential benefit of this article to others is to help establish proper expectations concerning personnel, money and time needed to conduct the DITSCAP. The article also offers valuable recommendations for successful completion for those who find themselves involved in DITSCAP activities. The article is geared towards DOD organizations, companies or consultants who may currently be supporting or plan to support information technology systems within the United States Department of Defense.
There are four phases to the DITSCAP process: Definition, Verification, Validation and Post-Accreditation. Within each phase, there are a number of activities and associated tasks and deliverables that must be completed and validated prior to advancing to the next phase. See the following diagram for an overview of the phases (click to enlarge).
Phase I - Definition: In the Definition phase, three main activities are completed: preparation, registration, and negotiation. There are multiple tasks that must be completed to support each of these activities. The deliverable of the Definition phase is a preliminary System Security Authorization Agreement (SSAA).
The SSAA document is crucial to the DITSCAP. It defines all system specifications including the system mission, target environment, target architecture, security requirements and applicable access policies. The SSAA also describes the applicable planning and certification actions, resources and documentation required to support the certification and accreditation. In essence, the SSAA is the vehicle that guides the implementation of information security. The SSAA is updated and revised during each of the four phases.
Phase II - Verification: The Verification phase involves activities and tasks that verify the compliance of the evolving system with the agreed-upon security requirements negotiated in Phase I. In addition, recommendations for changes to the system are tendered. The resulting deliverable is a refined SSAA.
Phase III - Validation: During the Validation phase, the SSAA is reviewed and the fully integrated system is validated for compliance with the security requirements. Vulnerability and penetration tests are performed to check for security vulnerabilities and risks. The resulting deliverable is a certification package containing the final SSAA.
Upon review of the certification package, a system receives one of three designations:
- Approval to Operate (ATO) - (full accreditation)
- Interim Approval to Operate (IATO) - (three months allowed to achieve full accreditation)
- Withhold Accreditation
Phase IV - Post-Accreditation: The Post-Accreditation phase includes activities that continue to monitor and manage the system so it will maintain an acceptable level of risk. In this phase, ongoing maintenance of the SSAA, system operations, security operations, configuration management and compliance validation occur.
See the following diagram for more information on the activities, tasks and deliverables in each phase (click to enlarge).
System Background
The DASN (ACQ) One Source ( www.acquisition.navy.mil) website was successfully launched in November of 2003 and is considered the authoritative acquisition policy resource for the Department of the Navy Acquisition workforce.
For nearly three years, the DASN (ACQ) One Source website had resided on the Department of the Navy Headquarters' Network (DNHN). However, due to planned server room renovations and the impending deadline of the DNHN to become decommissioned, the DASN (ACQ) One Source was relocated to another server room within the Pentagon and moved off of the Navy network and on to a network operated and maintained by the Army.
The Army network is the Unclassified but Sensitive Internet Protocol Router Network (formerly called the "Non-secure Internet Protocol Router Network"), and is hosted by the United States Army Information Technology Agency (USAITA).
In addition to logistical planning for these events, the DASN (ACQ) One Source website needed to comply with Department of Defense Information Assurance policies and regulations. Prior to attaining an Approval to Connect (ATC) to the Army network, the DASN (ACQ) One Source website had to go through the DITSCAP process. An approved System Security Authorization Agreement (SSAA) was necessary to continue operations.
After the SSAA was signed and accepted, the DASN (ACQ) One Source system was granted an Authority to Operate (ATO), valid for a period of three years. Based on being granted an ATO, the USAITA also granted an Approval To Connect (ATC), valid for a period of one year. This will need to be renewed annually in order to be allowed to connect to the Pentagon's network infrastructure (NIPRNet).
DASN (ACQ) One Source system platform
The DASN (ACQ) One Source website utilizes Norwegian-based eZ Systems' eZ publish software, which provides a framework for content management, sharing and role-based business rules that control the addition and modification of site content. The system operates on an open-source platform utilizing an Apache web server and accesses a MySQL database. The site is based on the PHP (PHP Hypertext Preprocessor) language, HTML (Hyper Text Markup Language), and JavaScript,
The actual technology specifications that support the DASN (ACQ) One Source website can be obtained from the author of the article.
The following information is a summary of activities that ATI conducted that enabled DASN (ACQ) One Source to achieve certification and accreditation.
System certification level
One of the first steps to beginning the DITSCAP process was for ATI to define the system's security certification level. This determines the type of activities and tasks that must be completed during the DITSCAP. If the system is rated as Certification Level 2, 3, or 4, the analysis and tasks required for compliance will be much more robust than a Level 1 system.
The DASN (ACQ) One Source is designated as "Unclassified (Public)" and does not include any sensitive business data or classified information. All information and content residing on DASN (ACQ) One Source is publicly available. The DASN (ACQ) One Source Security Certification is a Level 1 system and requires that the Minimum Security Checklists be completed to fulfill DITSCAP requirements.
DOD Information Assurance guidance, regulations and policies
The ATI consultants needed to conduct research and become knowledgeable about all the DOD and Navy information assurance guidance, policy and regulation documentation. It was important to understand which regulations and policies specifically pertained to the One Source system. After making a thorough review of the documentation, ATI gained an understanding of what activities needed to be completed to ensure that the system was in compliance.
Plan for information assurance initiatives early
Early planning is best when trying to achieve successful certification and accreditation. As soon as an information system project is kicked off, it is wise to consider most of your decisions with information assurance in mind. It is also recommended that you have a program strategy to design, develop and deploy your system, and that you plan for information assurance activities and certification and accreditation tasks throughout the project life cycle.
Level 1 documentation
| Points of Contact for Team
|
Security Policy Plan
|
| System Description and Summary
|
Security Test Plan
|
| System Architecture (Infrastructure Diagrams)
|
Incident Response and Reporting Plan
|
| Hardware Specifications and Inventory
|
Incident Handling Forms
|
| Software Inventory
|
Contingency Plan
|
| Software Licensing paperwork (as needed)
|
Continuity of Operations Plan (COOP)
|
| Concept of Operations (CONOPS)
|
Risk Assessment Analysis
|
| Project Design Documents
|
Risk Assessment Results
|
| Operational and Functional Requirements
|
Risk Management Plan
|
| Use and Test Cases
|
Security Education, Training and Awareness Plan
|
| System Rules of Behavior for Users
|
User Role Training Materials
|
| Signed Acknowledgment Forms
|
Tracking Logs (patches and updates)
|
| System User Manual
|
Configuration Management Plan
|
| Change Request Forms
|
Audit and Monitoring Logs
|
For a system designated at a Level 2 or higher, documentation requirements may be more detailed.
Schedule appropriate time, plan for project costs and resources
A proper expectation needs to be set to ensure that the schedule for the project includes enough time to conduct all the DITSCAP phases and time for accreditation and certification activities.
Most United States federal agencies do not leave enough time to perform certification and accreditation activities. A medium-sized effort requires a minimum time frame of six months for an experienced team. If the project team is new to certification and accreditation activities, expect the process to take much longer.
For DOD agencies, expect that the systems will be shut down if it doesn't pass the accreditation process. Therefore, if you don't have in-house resources you may want to consider outsourcing the project to expert consultants.
The DASN (ACQ) timeline for ATI to conduct the process from start to finish was a total of nine months.
Incorporate Security Technical Implementation Guides and Security Configuration Guides
The ATI consultants relied heavily on Security Technical Implementation Guides (STIGs) and Security Configuration Guides provided by the Information Assurance Support Environment (IASE) and National Security Agency (NSA). STIGs and Security Configuration Guides are the configuration standards for DOD information assurance and information assurance-enabled devices and systems.
It is highly recommended that you carefully review the STIGs and Security Configuration Guides that apply to your system's configuration and technology platform. Ensure your system has proper configuration settings to verify compliance to a baseline level of security.
The configuration settings will undergo a review and will be analyzed during vulnerability testing. Vulnerability testing is discussed later in this article.
A complete list of STIGs can be found at the following URL: http://iase.disa.mil/stigs/stig/index.html
The NSA security configuration guides ( http://www.nsa.gov/snac/) include information for applications, database servers, operating systems, routers, web servers, browsers and much more.
As part of the DITSCAP, a Certifying Authority will conduct at minimum a four-hour interview to determine that all security assurance measures, planning, procedures and documentation are available to support the system. This interview includes a line-by-line check of the SSAA's Requirements Traceability Matrix (RTM) and the Minimum Security Activity Checklists.
Requirements Traceability Matrix (RTM)
The RTM is a traceability matrix with information assurance directives and security requisites (national directives, OMB circulars, DOD / Navy / Agency directives) that are used to create a list of system security requirements. The DASN (ACQ) One Source RTM was 35 pages long.
Minimum Security Activity Checklists
The Minimum Security Activity Checklists are used for the Certification Test and Evaluation Plan and Procedures. The Certifier uses these checklists to formally record the security activities and tasks associated with the system to ensure proper completion.
The Minimum Security Activity checklists are categorized into the following areas:
- System Architecture Analysis
- Software, Hardware, Firmware design Analysis
- Network Connection Rule Compliance Analysis
- Integrity Analysis of Integrated Products
- Life Cycle Management Analysis
- Vulnerability Assessment
- Security Test and Evaluation
- Penetration Testing
- System Management Analysis
- Site Accreditation Survey
- Contingency Plan Evaluation
- Risk Management Review
If Sensitive or Classified information resides on the system then the following checklists also apply:
- TEMPEST and RED/BLACK Verification
- COMSEC Compliance Verification
Certifier interview
The Certifier conducting the interview will need to determine whether the system complies with each RTM item. The Certifier will designate a Material Review Category based on materials, responses and information shared during the interview process. The categories include Observation (Certifier observation), Document Review (existence of supporting documentation), Interview (responses during interview), or Testing Technique (Certifier was able to test). For each item the interview will designate any or all of the categories.
For the Minimal Security Activity checklists, the Certifier will simply check "Yes", "No" or "Not Applicable".
The Certifier will use the information gathered in the interview to make a decision on whether or not you are prepared to continue to the next phase.
How to ensure a successful certification interview
To help ensure a successful certification interview, it is strongly recommended that you conduct an internal review of the entire RTM and the Minimum Security Activity Checklists prior to the interview. Conduct the internal review with the pertinent members of your system's project team.
The ATI team took the necessary time to review and evaluate / test each associated security requirement within the RTM and made a determination whether or not the system met the requirement. If we found any security requirements that our system did not meet, we made the changes that were needed to comply before the scheduled interview. In addition, for each item we made sure we had supporting proof of concurrence.
Wherever possible, ATI ensured standard operating procedures, formal processes, documentation, system administration logs, forms, etc, were available to support the items. (See the list in the section "Level 1 Documenation" for examples.) The Certifier will want to see some form of proof for the compliance.
A DOD-authorized network security services evaluator will execute an aggressive Network Vulnerability Security scan using Eye Retina Security Scanner or other evaluation tools on your system in order to identify vulnerabilities or security risks. The risk items will be categorized in a report as High, Medium, Low or Information risk levels. There will also be an overall level associated with the security risk of your system based on the scan results.
Each High and Medium risk item must be rectified within a 48-hour time period. You must submit a remediation report that explains how each risk item was rectified. If a High or Medium risk item cannot be rectified within 48 hours, a written explanation and a schedule of completion must be included with the remediation report.
A second vulnerability scan is performed to find out if the remediation activities have alleviated the risks previously found, and if remediation activities introduced new risks.
If the system was configured according to the appropriate STIGs and Security Configuration Guides prior to the vulnerability scan, the results should be a minimal number of High and Medium risk items. With the One Source system, the initial vulnerability assessment of the DASN (ACQ) One Source website revealed one High risk, one Medium risk and four Low risk items. Each of the risk items was easily rectified via changing simple configuration settings to minimize the vulnerability. The DASN (ACQ) One Source's initial vulnerability risk level overall was rated as LOW.
There were a variety of Information Items that do not necessarily pose risks or threats but rather instill best practices. These items were also modified and a re-scan was conducted. The rescan results for the DASN (ACQ) One Source's final vulnerability risk level overall was rated as NONE.
Risk analysis and assessment
The information from the certifier interview, the SSAA, and the results of the vulnerability scan are used to conduct a security risk analysis on the system. The outcome of the analysis is a risk assessment report. These items become part of the certification and accreditation package.
The certification and accreditation package is forwarded to the designated approving authority and is used to decide whether or not the system operates with a low enough security risk to be granted an Authority to Operate.
To manage security risks, it is advisable to have a risk management plan that includes strategies and techniques that you can use to mitigate any security risks that are discovered during the risk assessment.
Certification package
A typical certification package usually consists of a minimum of six documents, although more documentation may be required if the system contains classified information or highly sensitive data. The package is a collection of documents that describes the security posture of the system, an evaluation of the risks, and recommendations for correcting any deficiencies.
Once a certification package has been prepared, appropriate auditors review the package and then make decisions on whether or not the system should be accredited according to the proposed recommendation. All DOD agencies must obtain an Authority to Operate (ATO) before their system can be used for production purposes.
If the certification package does not contain the right information, or if the information reported in the package is considered unacceptable (for example, if there are unacceptable risks cited with insufficient safeguards to mitigate the risks) the agency may be given an Interim Authority to Operation (IATO), which allows them to operate their systems for (usually) three months while they correct the system's deficiencies.
DASN (ACQ) One Source received their ATO on August 14, 2006.
The following list summarizes the tips that you are recommended to apply to your system's certification and accreditation activities.
- Become very familiar with DOD Information Assurance guidelines, regulations, and policies.
- Plan for information assurance initiatives from the beginning of any project and throughout the system's life cycle.
- Ensure that you have proper documentation.
- Ensure that you have scheduled appropriate time, money and resources to support certification efforts.
- Review the Security Technical Implementation Guides and Security Configuration Guides for technologies used to support your system ahead of time, and be prepared for your interview with the Certifying Authority.
- Make sure the Certification Package is complete and correctly prepared.
- Public Law 100-235, "Computer Security Act of 1987", January 8, 1988
- Office of Management and Budget Circular No. A-130, "Management of Federal Information Resources", February 8, 1996
- Office of Management and Budget Circular No. A-123, "Management Accountability and Control", June 21, 1995
- DOD Directive 5000.1, "Defense Acquisition", March 15, 1996
- DOD Regulation 5000.2-R, "Mandatory Procedures for Major Defense Programs (MDAPS) and Major Automated Information System (MAIS) Acquisition Programs", November 4, 1996
- DOD Directive C-5200.5, "Communications Security (COMSEC)", Oct 6 1981
- DOD Instruction 5200.40 "DOD Information Technology Security Certification and Accreditation (C&A) Process (DITSCAP)", 30 December 1997
- DOD Directive 5220.22, "Industrial Security Program", November 1, 1986
- DOD Directive 8500.1, "Information Assurance", 24 October 2002
- DOD Directive 8500.2, "Information Assurance (IA) Implementation", 6 Feb October 2003
- DOD Manual 8510.1-M, "Department of Defense Information Technology Security Certification and Accreditation (C&A) Process (DITSCAP) Application Manual", 31 July 2000
- Federal Information Processing Standards (FIPS), Publication 31 "Guidelines for Automatic Data Processing Physical and Risk Management", June 1974
- Federal Information Processing Standards (FIPS), Publication 41 "Computer Security Guidelines for Implementing the Privacy Act of 1974", May 30, 1975
- Federal Information Processing Standards Publication 65, "Guideline for Automatic Data Processing Risk Analysis", August 1, 1993
- National Computer Security Center (NCSC) Technical Guide 031 (NCSC-TG-031), "The Certification and Accreditation Process Handbook for Certifiers", NCSC-TG-031, 1996
- National Computer Security Center (NCSC) Technical Guide 032 (NCSC-TG-032) "Accreditor Guideline", July 1972
- National Institute of Standards and Technology (NIST) Special Publication 800-6, "Automated Tools for Testing Computer System Vulnerability", December 1992
- National Institute of Standards and Technology (NIST) Publication 800-12, "An Introduction to Computer Security", October 1995
- National Security Administration (NSA) Manual DS-80, "INFOSEC Software Engineering Standards and Practices Manual", January 9, 1991
- National Security Telecommunications and Information Systems Security Instruction (NSTISSI) 4009, National Information Systems Security (INFOSEC) Glossary, August 1997
- Secretary of the Navy Instruction (SECNAVINST) 5239.3A, "Department of the Navy Information Security (INFOSEC) Program", 20 Dec 2004
- SECNAVINST 5510.30A (SECNAVINST 5510.30A), "Department of the Navy Personal Security Program", 10 Mar 1999
- SECNAVINST 5510.36 (SECNAVINST 5510.36), "Department of the Navy Information Security Program (ISP) Regulation", 17 Mar 1999
- Subsection 552a of Title 5, United States Code