me with picture of CAP notificaiton

How to get a certification

- ISC2 Certified Authorization Professional (ISC2 CAP)
- Risk Management Certification
- Passing Score 700 out of 1000 points (125 questions on the test *25 test questions not counted toward the results)
- Application Fee: $419
- Verify 2 years experience in this field
- Endorsement Form
- Answer questions to criminal history and background
- Other Info: its a CBT, 3 hours to test, based on NIST 800 series

How Hard is the CAP Exam

I just took the ISC2 Certified Authorization Professional test (CAP Exam). I just want to give others who are about to take this test some idea of what they are up against. I noticed there is not a lot of Security Professionals talking about it. I keep hearing that there are only *1000 CAP certified people on Earth (circa 2011). I don’t think its because of the difficulty level (lol.. i mean i would not call it an EASY test, but its no CISSP or CCIE.. btw CCIE has about 25,000 certified as of about 2010 individuals on early despite being around for since 1993… according to Cisco, “fewer than 3% of Cisco certified individuals attain CCIE certification”). I think there are so few CAP certified people because its not a well know certification and its in a specialized field. Perhaps the numbers of CAP certified individuals will always be low.

My overall impression is that it is much harder than Security+ but much easier than CISSP. If you have recent experience with DoD Information Assurance Certification & Accreditation Process (DIACAP) you should have an easy time grasping the National Institute of Standards & Technology (NIST) Special Publication 800 series concepts allowing you to pass the CAP exam. I would say the same about all the C&A frameworks, NIACAP, NISPOM, DCID 6/3, DITSCAP etc. If you know the certification & accreditation process well than you will pick up risk management framework fast. If you have been doing the NIST C&A and/or Risk Management Framework, the test should be a mere refresher course for you and a couple of weeks of reviewing NIST 800 regulations and OMBs you already know might be enough for you to pass the CAP Exam and get this certifications. You should know, however, that quite a bit has changed since 2009 in the certification & accreditation process of getting authorization.

The test is in the style of the CISSP in that you must choose what is MOST right in many cases. All questions are 4-multiple choice type questions.

Study Material for the Certified Authorization Professional

One of my biggest issues about the CAP material is that is has almost NO decent study material. There is “The CISSP and CAP prep guide” by Russell Dean & Ronald L. Krutz, this is the ONLY book I have found aside from one or two lame ebooks (as of 2011).

What I used to get a CAP Certification

The very first thing you should do is become a member of Isc2.org and download the ISC2 CAP Candidate Information Bulletin. The CAP Exam CIB breaks down all the objectives that you need to be knowledgeable in.

Read and/or be very familiar with the following NIST & OMB documents:
- NIST 800-37
- NIST 800-53
- NIST 800-53A
- NIST 800-64
- NIST 800-30
- NIST 800-100
- NIST 800-83
- NIST 800-53
OMB circular A-130
Privacy Act of 1974
FISMA Act of 2002
**The full list of documents & regs to be familiar with are located in CAP CIB

Another great resource is practice tests. Ucertify.com has GREAT content for the CAP, some of the best you will find for the Certified Authorization Professional.

Areas to Spend a LOT of time on:

I would definitely know and fully understand the Risk Management Framework (800-37). You need to know the tasks on each of the six steps of the Risk Management Framework (800-37). System Development Lifecycle is also HUGE on this test(800-64). I would know how Risk Management Framework lines up with SDLC and Risk Assessment process (800-37, 64, 30). Risk Assessment process, Risk Management Framework and SDLC are all interconnected. You should know how they work together. Tasks that are done at each stage and step in all those process and what role does each task is a need to know. Roles and Responsibilities should be fully understood and memorized. Although everyone of the steps in the Risk Management framework are covered pretty good, I feel like the following two steps were beaten to death: Continuous Monitoring & assessments (security control assessor)

The test is computer based and randomized so you might get a completely different set of subject areas. Your best bet is to study what is in the CAP-CIB and use a bunch of practice tests.

What I DID NOT see on the Exam:

I was surprised not to see anything on the NIACAP, DIACAP, FITSAP, DCID 6/3 and DITSCAP. I was fully expecting it and prepared for it. Many of the practice test go on and on about Project/Program Management subject areas. But the only question I recall on that had to do with knowing the role of a Program Manager… thats about it.

Pro & CON on the ISC2 CAP Cert

CONS: I feel like the CAP is currently (2011) not in great demand. If you do a search on any job database (monster, indeed, simplyhired) you see that there are not many employees listing it as a requirement. For example, a 2011 search on isc2 CAP anywhere in the US gives 49 results — http://jobsearch.monster.com/search/?q=isc2-cap
I also think that the certification is WAY over priced. Its $419 which I think is even more than the ISC2 CISSP concentrations.
There is almost no study material for it.

PROS: Covers very important risk management framework material. Its computer based, so the results are instant. Its good lead up and practice for the ISSEP. The ISSEP covers a lot of what is in the CAP. NIST will get increasingly more important as DoD, NSA and other national security system agencies take on the NIST.

*CAP Exam: CAP certified people in the world (circa 2011):
Canada 6
Germany 1
Korea, Republic of 2
Puerto Rico 2
United States 997
reference: https://www.isc2.org/member-counts.aspx#cap

**Certification Authorization Professional Candidate Information Bulletin is on ISC2.org. May have to be a member to get the document

Head of Agency
The Head of Agency is also known as the Chief Executive Officer. This role is the highest level executive senior officer within an organization. They have ultimate responsible for the providing information security protection. The level of protection must be at the same level as the importance of the information. The Department of Defense equivanent is a DoD Head of component (i.e. Secretary of the Army).

image of secretary army john mchugh

Risk Executive Function
The Risk Executive Function’s main focus is the overall risk to the entire organization. They create a risk strategy for the organization that guides mission/business process and system-level risk assessments. The Risk Executive Function is and important role for Tier 1 activities of managing risk of information systems IAW NIST SP 800-39.

CIO
Chief Information Officer is an organizational official responsible for (1) designating a senior information security officer; (2) developing and maintaining information security policies; (3) ensure that those with responsibilities in system security have proper training.

Information Owner/Steward
“The information owner/steward is an organizational official with statutory, management, or operational authority for specified information and the responsibility for establishing the policies and procedures governing its generation, collection, processing, dissemination, and disposal.” NIST SP 800-37 The Information Owner must coodinate with the Information System Owner (DoD PM equivalent) for decisions involving the overall system.

Senior Information Security Officer
The SISO is directly responsible to the CIO. They’re focus is the information security of the organization’s data. They act as a liaison between CIO and the Authorizing Official. The DoD equivalent (circa 2010) is known as the Senior Information Assurance Officer (SIAO).

Authorizing Official
AO formally accepts the risk of a system in the Implementation/Assessment phase of the System Development Lifecycle and Step 5, Authorization step of the Risk Management Framework.

Common Control Provider

“The common control provider is an individual, group, or organization responsible for the development, implementation, assessment, and monitoring of common controls.” NIST SP 800-37. A common control is a security controls that covers multiple information systems within and organization. Examples of common controls: Incident Response, Network boundary protection (firewalls, IDS/IPS).

Information System Owner
“The information system owner is an organizational official responsible for the procurement, development, integration, modification, operation, maintenance, and disposal of an information system.” NIST SP 800-37

Information System Security Engineer
“The information system security engineer is an individual, group, or organization responsible for conducting information system security engineering activities.” NIST SP 800-37 The ISSE implements security into the design of systems. The ISSE is often a consultant or Subject Matter Expert who focus is applying information assurance frameworks and regulations in an information system.

Information System Security Officer
This role is initiated at the Initial phase of the System Development Lifecycle (SDLC). “The information system security officer
is an individual responsible for ensuring that the appropriate operational security posture is maintained for an information system and as such, works in close collaboration with the information system owner” NIST SP 800-37. This role has been called and Information Assurance Officer (IAO) within the Department of Defense. Within the DoD this role is appointed by the Information Assurance Manager (IAM). Also known as the Information System Security Manager (ISSM). The ISSM is often responsible to over site and being a supervisor of ISSO positions.

Security Control Assessor
“The security control assessor is an individual, group, or organization responsible for conducting a comprehensive assessment of the management, operational, and technical security controls employed within or inherited by an information system to determine the overall effectiveness of the controls” NIST SP 800-37.

The NIST & DoD have very similar roles with different names:

NIST Special Publication 800-50, is a regulation dedicated to IA Awareness Training

NIST SP 800-5, Building an Information Technology Security Awareness & Training Program


The 800-50 includes guidance on development and sustainment of an awareness & training IT Security (aka information assurance training) program for all users, employees and supervisors within an organization. Having a training program is mandated by the Federal Information Security Act of 2002.

IA Awareness Training – Roles & Responsibilities

Agency heads – must ensure that high priority is given to effective security awareness and training for employees. Appoint a CIO
CIO – Establish overall strategy, funding, tracking and report is in place for the IT security awareness and training program
IT Security Program Manager – tactical deployment, development and maintenance of the IT security & awareness program.
Managers – responsible for complying with IT security awareness program. Work with CIO and IT Security Program Managers to share responsibility. Ensure all users are trained to fulfill their security roles before access is giving. Promote professional development and certification of the IT staff.
Users – largest audience in any organization and are the single most important group of people who can help to reduce unintentional errors.


800-50 calls learning a “continuum”. The continuum of learning starts awareness and builds into education.
Awareness – awareness is not training. Awareness focuses on security concerns to ensure users are mindful of basic rules and issues in a given environment.


Awareness is not training. The purpose of awareness presentations is simply to focus attention on security. Awareness presentations are intended to allow individuals to recognize IT security concerns and respond accordingly. – 800-50

Training – is a formal focused method to develop a skill for job performance.
Training strives to produce relevant and needed security skills and competencies – 800-50

Education – combines multidisciplinary areas into a common body of knowledge.

Education integrates all of the security skills and competencies of the various functional specialties into a common body of knowledge . . . and strives to produce IT security specialists and professionals capable of vision and pro-active response. –800-50

The concept of management of information security risks across an enterprise is discussed in 800-39. An organization takes a multitier approach to the risk management at the organizational, mission, and system levels. Risk management framework is a process that is broken down in NIST 800-37, Risk Management Framework. The CAP addresses the following:

Distinguish between applying risk management principles and satisfying compliance requirements
Identify and maintain information systems inventory
Understand the criticality of securing information
Understand organizational operations

Distinguish between applying risk management principles and satisfying compliance
Risk management includes satisfying compliance. Even though some controls may not be able to be made fully compliant due to limited resources, residual risk to the organization can still be mitigated and managed. – Concepts of NIST SP 800-37, Guide of RMF

Identifying and maintaining information system (IS) inventory is addressed in NIST 800-37, Risk Management Framework, 800-18, System Security Plan & 800-64, System Development Life Cycle. 800-37 addresses inventory of the IS in RMF Step 1 – Categorization of IS. Of the tasks of categorization includes information system registration which begins with by identifying the information system in the system inventory. This is documented in the security plan. NIST SP 800-18 discusses how the inventory is documents, and logically separates the system authorization boundary. That inventory is maintained and monitored throughout the life cycle of the IS (from imitation to disposal and from categorization to monitoring of the system).

A CAP candidate can understand the criticality of security information from reading FIPS 199, categorization of federal information systems.

Understanding the organizational operations of the system is imperative to a CAP candidate for the purpose of scope guidance described in NIST SP 800-53.

Risk Assessments and Risk Management will apply to National Security Systems (NSS).

What is a Risk Assessment?

A risk assessment is the results/process to determine the likelihood that a threat will exploit a weakness. Risk assessment is a part of the risk management.

What is risk management?

Risk Management is the on-going process of determining assessing, identifying and prioritizing of risks.

Is My System a National Security System?

NIST SP 800-59, Guidance for Identifying an information system as an NSS. 800-39 is a 17 page document developed in conjunction with the Department of Defense, including the National Security Agency, for identifying an information system as a national security system. It is basised on the Federal Information Security Management Act of 2002 (FISMA).

Who determines if you have an NSS?

The head of each agency is responsible for designating an agency information security official to determine which, if any, agency systems are national security systems.

Tools to determine if you have a NSS system:

National Security System Identification Checklist (NIST SP 800-59, Appendix A). The NSS ID Checklist asks (6) questions. Answering yes to any of these questions qualifies your system as an NSS:
• Does the function, operation, or use of the system involve intelligence activities?
• Does the function, operation, or use of the system involve cryptologic activities related to national security?
• Does the function, operation, or use of the system involve command and control of military forces?
• Does the function, operation, or use of the system involve equipment that is an integral part of a weapon or weapons system?
• Is the system critical to the direct fulfillment of military or intelligence missions?
• Does the system store, process, or communicate classified information?

NSS RMF
The guidance of CNSSI 1253 is the result of NIST collaborated with the Intelligence Community (IC), Department of Defense (DoD), and the Committee on National Security Systems (CNSS) to ensure NIST SP 800-53 contains security controls to meet the requirements of National Security Systems (NSS).

KEY DIFFERENCES BETWEEN CNSS INSTRUCTION NO. 1253 AND NIST PUBLICATIONS

The key differences between CNSSI 1253 and the rest of the NIST publications is that NSS systems do not follow “high-water mark”, NSS maybe tailored through risk-based adjustment, control profiles, and a method that allows organization to practice reciprocity.

NSS and High Water Mark
Both FIPS 200 and NIST 800-53 apply the concept of a high-water mark (HWM) when categorizing information systems according to the worst-case potential impact of a loss of confidentiality, integrity, or availability of information or an information system. This Instruction does not adopt this HWM usage. In the National Security Community, the potential impact levels determined for confidentiality, integrity, and availability are retained, meaning there are 27 possible three-value combinations for NSI or NSS, as opposed to the three possible single-value categorizations obtained using the guidelines in FIPS 200. – CNSSI 1253

Risk-Based Adjustment
Potential impact-based security categorizations for NSS may be tailored through the use of a risk-based adjustment. This adjustment takes into consideration the physical and personnel security measures already employed throughout the National Security Community and factors such as aggregation of information.

Control Profile
Method by which organizations may designate sets of controls for NSS based on their enterprise-wide risk assessment and taking into account business objectives, system risks, and mission needs.

NSS Reciprocity
It is the policy of the National Security Community that member organizations practice reciprocity with respect to the certification of systems and system components to the greatest extent practicable. Reciprocity of certification reduces the cost and time to implement systems and system components.

A risk assessment is the results/process to determine the likelihood that a threat will exploit a weakness. Risk assessment is a part of the risk management.

What is risk management?

Risk Management is the on-going process of determining assessing, identifying and prioritizing of risks.

STEP of a RISK ASSESSMENT

This is a synopsis of NIST Special Publication 800-30. These are steps that should be a part of an IT risk management plan

Step 1 System Characterization

An organization must know all the parts of a new information system before the threats, vulnerabilities can be identified and impact (or harm) to the organization can be analyzed. System characterization includes the a list of the hardware, software, firmware and network diagram. System characterization also includes the operational environment that the system is in, any management, operational, technical controls implemented.

Additional features and methods of system characterization are described in 3.1 of NIST SP 800-30. The output looks a lot like a System Security Plan. NIST 800-18, Guide for Developing Security Plans for Federal Information Systems characterizes system in section 2.-System Boundary Analysis & Security Controls and section 3.- Plan Development.

Output from Step 1-Characterization of the IT system assessed, a good picture of the IT system environment, and delineation of system boundary

Step 2 Threat Identification

A threat is “the potential for a threat-source to exercise (accidentally trigger or intentionally exploit) a specific vulnerability.” A threat-source is “Either (1) intent and method targeted at the intentional exploitation of a vulnerability or (2) a situation and method that may accidentally trigger a vulnerability.” an adverse action or event that could exploit or trigger vulnerability. NIST identifies three “common threat-sources” Natural, Environmental, Human.

Common Threat-Sources
- Natural Threats—Floods, earthquakes, tornadoes,
landslides, avalanches, electrical storms, and other such
events.
- Human Threats—Events that are either enabled by or
caused by human beings, such as unintentional acts
(inadvertent data entry) or deliberate actions (network
based attacks, malicious software upload, unauthorized
access to confidential information).
- Environmental Threats—Long-term power failure,
pollution, chemicals, liquid leakage.

Sources of information include, but are not limited to, the following:
• Intelligence agencies (for example, the Federal Bureau of Investigation’s National Infrastructure Protection Center)
• Federal Computer Incident Response Center (FedCIRC)
• Mass media, particularly Web-based resources such as SecurityFocus.com, SecurityWatch.com, SecurityPortal.com, and SANS.org. – NIST 800-30

By addressing the motivation behind a potential attack, the capability of the event to occur, and the available resource of a potential attacker, an organization can have a better idea of the likelihood of real threat-sources.

Output from Step 2 – A threat statement containing a list of threat-sources that could exploit
system vulnerabilities

Step 3 Vulnerability Identification

A vulnerability is a weakness in a systems design, architecture, configuration etc that could be exploited. There are many ways to find vulnerabilities on a system. Federal systems have the Vulnerability Management System (VMS) and National Vulnerability Database which are databases with a breakdown of operating system, network, application vulnerabilities that can allow an organization to track vulnerabilities. Network vulnerability scans, security test & evaluations, interviews, questionnaires, POA&Ms, penetration tests and previous assessments are other methods of identifying vulnerabilities.

Step 4 Control Analysis

Control analysis consist of listing all controls that are planned and implemented. Actions to identify planned and implemented controls could include examining previous POA&Ms & system security plans on existing systems. On new systems the organization could examine nontechnical and technical controls to be implemented by using network scanners, scripts. For nontechnical controls, the organization could observe documentation addressing business/mission procedures and organization policies.

http://nvd.nist.gov/scap/docs/2008-conf-presentations/day2/mgt-80037-transformation-ross-092408.pdf

Step 5 Likelihood Determination
Likelihood determination is based on threat-source motivations, capability, and resources available combined with the nature of system vulnerabilities.

The organization creates likelihood levels and definitions for the development of qualitative determination.

Step 6 Impact Analysis
Impact analysis takes determination of the system mission, the system and data criticality/sensitivity. The organization should determine the adverse impacts of the loss of integrity, confidentiality, or availability.

The organization can give examples of quantitative assessments by introducing real profit loss as a result of impacts. The magnitude of impact/impact definition is represents a qualitative matrix above.

Output from Step 6-Magnitude of impact (High, Medium, or Low)

Step 7 Risk Determination
The risk determination consists of the likelihood of a given threat and the magnitude of the impact should a vulnerability be exploited/engaged by a threat-source. The output of this step is a Risk-Level Matrix. Threat likelihood and potential impacts are given a rating system.

Step 8 Control Recommendations
The goal of the control recommendation is to determine how the mitigate identified vulnerabilities to reduce risk to the system.
• Effectiveness of recommended options (e.g., system compatibility)
• Legislation and regulation
• Organizational policy
• Operational impact
• Safety and reliability

Step 9 Document findings
All the results of the risk assessment methodology must be documented. A Security Assessment Report (SAR) or risk assessment report captures data that will allow decision makers to make an inform decision on cost benefit for implementing controls.

NIST SP 800-53 controls
Change focus from C&A to Risk Management
Definition of how to bridge between DoD systems and NIST defined system (subsystems & Platform IT for example)
DIARMF will look more like NIST 800-37 rev 1

It is unknown how DIARMF authorization packages will look. Currently, the DIACAP consist of DIACAP packages (DIP, SIP, scorecard, POA&M with artifacts) and NIST 800-37 rev 1 consists of a Security Authorization Package (System Security Plan, Security Assessment Report & POA&M). Also, the roles between the NIST Risk Management Framework and the DoD 8500 series are different. So far, the DON CIO and ASD (NII) have come up with mapping between the roles and the 800-53 controls.

The DIARMF will hopefully cover all of the gaps between the DoD C&A process and the new NIST 800-37, Risk Management Framework.

If the transition is anything like their move to from DoD Information Technology Security Certification & Accreditation Process (DITSCAP) to the DIACAP then they will give about 2 years for the DoD to transition. As of Mar. 2011, there is no policy on this. It is serious because its on the DIACAP KS and the Department of Navy CIO has been releasing information on it since 2009. The DON CIO & the ASD (NII) have been working on the project to transition from DIACAP to some sort of DoD Risk Management Framework. So far, they have mapped the DoDI 8500.2 IA controls to the NIST SP 800-53 Controls: Certification and Accreditation Transformation: Security Control Mapping. Here is a May 2010 update to the NIST to DIACAP mapping. 800-53 to DoD IA contols map also includes the Director of Central Intelligence Directive (DCID) 6/3 controls. This is very telling. The plan seems to be to have one standard for all Federal Information System.

Since DoD 8510.01, DIACAP & NIST SP 800-37, Risk Management Framework (RMF) cover so much of the same ground, I think the only real benefit is that reciprocity between Federal agency will be easier if all departments have one standard of risk management and one security control set.

The DON uses the certification and accreditation (C&A) process to assess and understand the residual risk associated with operating information systems (IS) and information technology (IT). The DON is participating with the DoD, the IC, and the rest of the Federal government in C&A transformation. One goal of transformation is to achieve common security controls enabling the DON, the DoD, the IC, and the rest of the Federal government to develop systems to the same protection standards.

The recently released National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53, revision 3 provides recommended consolidated security controls in an effort to achieve common security controls across the Federal government.

The DON will continue to use the DoDI 8500.2 as the authoritative source for security controls until otherwise specified. However, understanding the changes represented in NIST SP 800-53r3 will be essential as DoD and the DON begin transitioning to this new set of security controls. To support the transition, the DON CIO developed this security control mapping document to demonstrate how existing DoD and IC security controls map to the security controls recommended by the NIST SP 800-53r3 publication.

–Security Control Mapping Document Aids Transition, DON CIO Site

We are not talking about the obvious:
-3 year expiration
-completely new version and/or overhaul of a system

We are talking about a single client on within an Information System getting an upgraded operating systems, or a firewall being upgraded or the addition of 4 Cisco internetworking devices and a VLAN change.

How do we know what is a basic sustaiment change, a configuration management changed (approved by the Configuration Board members) or a full blown 100,000 dollar re-accreditation.

You would think there was some kind of matrix that could match up modifications to a DoD IS with what actions must be performed. If there is one, I have not seen it.

All we have is high level regs that tell us IA Workforce peons (who must deal with details, schedules and limited funds) almost nothing we don’t already know.

Assessing the IA Impact & Maintaining Situational Awareness:
DoD 8500.2, Information Assurance gives us IA Controls such as
DCII-1, dealing with IA Impact Assessment. Its states, “Changes to the DoD information system are assessed for IA and accreditation impact prior to implementation.” The DoD instruction also tells us the we are supposed conduct comprehensive annual reviews of our systems process, procedures and IA Control status.

How are we supposed to monitor “Changes to the DoD information system?

We know that we are supposed monitor all DoD IS’s to keep track of the baseline. And according to the regs, we are supposed to do this by a configuration management process (DCPR-1, CM Process). That configuration management process is supposed to have a “configuration control board that implements procedures to ensure a security review and approval of all proposed DoD information system changes, to include interconnections to other DoD information systems.”

So Configuration Management gives us oversight on changes to DoD IS but who within the CM process determines whether changes to a system should have a re-accreditation?
IA Control DCCB-2, Control Board tells us that” all information systems are under the control of a chartered Configuration Control Board that meets regularly according to DCPR-1.” Is also tells us that the Information Assurance Manager (IAM) is a member of the CCB.

From my interpretation of these high level statements, the IAM is the subject matter expert who has a lot of say so on the IA impact of modifications to a given DoD IS.

But the question remains.. HOW DO WE KNOW WHAT NECESSITATES A RE-ACCREDITATION?

I did not find anything for that in 8500.2 so I moved on to CJCSI 6510.01, but it only says the same things that 8500.2 says (Configuration Management, CCB, having a baseline). But it did say this:

“Ensure a configuration management (CM) process is implemented and establish appropriate levels of configuration management to maintain the accredited security posture. The security impact of each change or modification to an information system or site configuration will be assessed against the security requirements and the accreditation conditions issued by the DAA..”

Still pretty high level, but we are getting closer since the instruction is telling us: “..security impact of each change or modification to an information system or site configuration will be assessed against the security requirements and the accreditation conditions issued by the DAA“.

I thought that the only way to get more insight is to look at the lower level regulations within specific branches. Air Force’s Certification & Accreditation Program, 33-210, for example talks specifically about reaccreditation. It states, Information system owner (ISO) “Alerts AFNetOps of any changes to the topology or software affecting the security posture of the enclave boundaries so that the gateway package can be reaccredited if necessary. (3.8.6.6.4.)” And in table 3.2. it states “PM/SM/ISO will enter information in EITDR, host an initial stakeholder meeting, and initial security review to determine if a new version is to be created.” It mentions different reaccreditation actions for Networked and Standalone systems. Its goes on say that “if changes will not affect the security posture of the IS, the PM/SM/ISO will annotate the outcome of the meeting and make necessary edits to the C&A package.”

The Army’s AR 25-2, Information Assurance regulation, has an entire section on Accrediation & Reaccreditation (5-5), but offers still no specifics. The Army does have AR 380-19, AIS Information System Security and it is pretty specific (see excerpt below).. but it is now OBSOLETE and replaced by AR 25-5.

All regulation and instructions are inline as far as the need to reaccredit if there is an IA IMPACT, but no specifics on what constitues an “IA Impact”. 8510, DIACAP mentions that the IA posture of an IS must remain acceptable, in order to retain its Authorization to Operate (ATO). If I were the IAM for a day.. I would hang my hat of this important statement.

We have to work with what we have!!
Based on what we have:
Changes in a DoD IS’s IA Controls determine whether or not a system will need a reaccrediation. There is no specifics on what can force a reaccrediation. So we must conclude that there is no “magic bullet” that will instantly create the need for a reaccreditation. In other words, no modifications to a certain hardware or software or certain subsystems or even the changes to network architecture will be the reason for reaccreditation every single time.

Significant changes to IA Controls are the only thing we can really put our finger on.

So lets say that IA Control, DCCS-2, Configuration Specification was changed on an Information System. This IA Control deals with making sure the all IA Enabled and IA Products have the DISA Security Technical Implementation Guides (or equivalent) applied. Maybe an example will help us understand the process of determining reaccreditation: A DoD Information System Owner requests the addition of four new storage devices to the system enclave. Lets say, that these storage devices will have an adverse affect on the security posture of the overall system because they are not in compliance with DCAS-2, Acquisition Standards… so the storage devices have not gone through NSA/Common Criteria. Additionally the storage devices will not be compliant with DCCS which means they will not have security in accordance with DISA/NSA checklists and guidance.

Prior to being implemented or even tested the request for this change should go through the configuration management process where the IAM will tell the Program Manager and System Owner (or is representative) the security impact to the over all system. He or she would have to explain to them that the change may affect the current ATO, because they will now be non-compliant on two (possibly more controls) that were previously compliant. The IAM would also be wise to get in contact with other subject matter experts such as the system administrator and/or IAO would be in charge of implementing and testing the system. The IAM might also contact the Certifying Authority (or representative) to determine if such a change would create the need for a reaccreditation.

One thing the IAM does NOT want to do is simply sign the Program Managers and System Owners up for some changes to the system that would jeapordise the Authorization to Operate. The IAM should do their homework and present the real risk of the modifications to the system owner. CYA is paramount.

Once the IAM determine the impact, and the modification are made:
According to DoD 8500.2, 5.8.5. “ensure that IA-related events or configuration changes that may impact accreditation are reported to affected parties, such as Information Owners and DAAs of interconnected DoD information systems.”

Some older regulations are more specific. AR 380-19, AIS System Security for example:
3-6. Reaccreditation

a. All AIS, except those designated as nonsensitive, will be formally reaccredited within 3 months after any of the following occurs:

(1) Addition or replacement of a mainframe or significant part of a major system.

(2) A change in sensitivity designation (para 2-2a).

(3) A change in security mode of operation (para 2-2b).

(4) A significant change to the operating system or executive software.

(5) A breach of security, violation of system integrity, or unusual situation that appears to invalidate the accreditation.

(6) A significant change to the physical structure housing the AIS that affects the physical security described in the accreditation.

(7) Three years has elapsed since the effective date of the existing accreditation.

b. Reaccreditation will include the same steps accomplished for the original accreditation; however, those portions of the documentation that are still valid need not be redone.

AR 380-19 has been replaced with AR 25-5 which is pretty high level.

Systems, applications, Products (SAP) is a security auditing program that checks a computer systems data integrity and overall security. This application is accompanied by a user interface that is highly flexible. SAP security audit programs were introduced in the 1980s and provides the best audit resources for major companies and industry leaders.

In SAP, audit security is the foremost requirement enabling access control and separation of duties. These two areas are very important for the integration of control mechanisms. A company must plan prior to implementing SAP to obtain better access and a clear understanding of the system. This includes proper design of profile and removal of surplus IDs. Security audit programs includes many audit procedures that are designed to efficiently access a variety of transactions.

The main administrative function of SAP security Audit Programs includes automatic scheduling of jobs according to different user IDs, monitoring errors, administering backdrop session and access to proper management functionality. As far as security settings are concerned, SAP system audit program helps to execute online programs using different procedures and maintenance of different tables. This allows access to maintain different profile parameters including password and security of default user IDs. SAP system audit programs also allow locking of sensitive codes of transactions and execution of OS commands externally.

The SAP system audit program contains different audit procedures showing steps to extract useful information from a system. Some system audit program resources are highly beneficial and include audit programs for financial accounting, audit programs for basic security, audit programs for Fixed Asset, audit programs for expenditures, audit programs for treasury, audit programs for inventory management, audit programs for HR & payroll and audit programs for revenue. Companies using SAP applications can create different software packages to meet their key objectives. This application is assembled in such a way that allows each department of an organization to get integrated.