Background and Purpose

Title III of the E-Government Act (Public Law 107-347) entitled Federal Information Security Management Act (FISMA) requires that all federal agencies develop and implement an agency-wide information security program designed to safeguard IT assets and data of the respective agency. FISMA is specific in its requirements and it stipulates that the information security program must include documentation and reports that clearly describe the following:

• Periodic risk assessments
• Information security policies and procedures
• An assessment of threats, including their likelihood and impact
• Policies and procedures for detecting security vulnerabilities
• Evaluation and periodic testing of how well security policies are working
• An inventory of software and hardware assets
• Security awareness training and expected rules of behavior for end-users
• An evaluation of the technical, management, and operational security controls
• Procedures for reporting and responding to security incidents
• A process for addressing any deficiencies reported
• Contingency plans to ensure continuity of operations in the face of a disaster

FISMA forces federal agencies to understand the security of their systems and holds them accountable for resolving deficiencies. The methodologies that have evolved to address FISMA stipulations are sound ones and, though only federal agencies are required to abide by them, it would behoove financial institutions to adopt these methodologies to assess the security of their own systems.

C&A Methodology

There are generally tthree methodologies used for C & A initiatives:

• DITSCAP/DIACAP
• NIACAP
• NIST

DITSCAP/DIACAP is an acronym for Defense Information Technology Systems Certification and Accreditation Process/Defense Information Assurance Certification Accreditation Program. It is based on a publication known as Defense Information Systems Certification and Accreditation regulation Department of Defense (DoD) 5200.40. DITSCAP/DIACAP is typically used only for defense agencies, although civilian agencies may opt to apply DITSCAP/DIACAP principles to their own customized C&A process.

NIACAP stands for National Information Assurance Certification and Accreditation Process. It is based on a process published by the National Security Telecommunications and Information System Security Instruction known as NSTISSI No. 1000.

NIST is the National Institute of Standards and Technology, and its C&A methodology is described in a document known as Special Publication 800-37. The main security controls are based upon NIST SP 800-53A and the System Security Plan (SSP) are based on NIST SP 800-18.  Under NIST it is important to mention that Risk Assessments are covered by NIST SP 800-30 and using the NIST Risk foundation gives you flexibility and direction in performing a thorough assessment.  Other publications that are pertinent under NIST are NIST SP 800-34 Contingency Planning, and NIST SP 800-60 a Guide for Mapping Types of Information and Information Systems to Security Objectives.  While many civilian agencies have traditionally used either the NIACAP or NIST methodologies, the current trend is that most agencies are moving away from NIACAP to embrace the new NIST methodology. One important mention is that every process within ITIL (Information Technology Infrastructure Library) can be mapped to a NIST document and NIST is the guidelines for building a secure infrastructure.

All three methodologies take into consideration the entire system, network, and application lifecycle from a security standpoint. In short, the C&A process is a manual audit of policies, procedures, controls, and contingency planning. While some information security reports can be obtained about systems and networks from an online penetration test, an online penetration test cannot tell you if an organization has security policies and procedures in place, and if they are following these policies and procedures. The C&A process is much more cumbersome than a network penetration test (sometimes referred to as a security scan or online vulnerability assessment).

Preparing for C&A

The outcome of the C&A process is to put together a collection of documents that describe the security posture of the systems, an evaluation of the risks, and recommendations for correcting deficiencies. It is what’s known as a Certification Package.

A typical Certification Package usually consists of specific documents (depending on agency), though more documentation may be required if the systems contain classified information or highly sensitive data. Each agency is responsible for defining their own C&A process and it must be well-documented in the form of a C&A Handbook. The C&A Handbook is based on one of the three well-known methodologies (NIST, DITSCAP/DIACAP, or NIACAP) with various customizations that are unique for each particular agency. Preparing the C&A package is sometimes referred to as a C&A Review.

Once a Certification Package has been prepared, Mission Assurance auditors review the package and then make decisions on whether or not the systems should be accredited according to the proposed recommendation. All federal agencies must obtain an Authority to Operation (ATO) before their systems can be legitimately and legally used for production purposes.

If the Certification Package does not appear to contain the right information, or if the information reported in the package is considered unacceptable (for example, if there are unacceptable risks cited with inappropriate 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 their deficiencies.
In preparing a C & A package, the documents that are typically required (according to the NIST methodology) include the following:

• System Categorization Statement
• System Description with System Boundaries Noted
• Network Diagram and Data Flows
• Software and Hardware Inventory
• Business Risk Assessment
• System Risk Assessment
• Contingency Plan

• Self-Assessment
• System Security Plan

Depending on the requirements of the particular agency, other documents or variations of these particular documents may also be required. NIST publishes an excellent collection of documents that provide guidance for the C&A review that will explain what sort of information should be reported in each of the required documents.

Levels of Certification and Starting the Review

There are typically four levels of accreditation for a system. At the beginning of a C&A project, the C&A review team makes a decision on the appropriate accreditation level that it is going to seek, and drafts a memorandum that justifies this decision. The four levels of accreditation are tightly mapped to the sensitivity of the systems being certified, and the severity of the impact that a disaster would have on the systems or information. How to categorize the software and hardware assets appropriately is described in the following documents:

FIPS Publication 199 Standards for Security Categorization of Federal Information and Information Systems
http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf

Special Publication 800-60 Guide for Mapping Types of Information and Information Systems to Security Categories
http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf

Special Publication 800-60 Guide for Mapping Types of Information and Information Systems to Security Categories
http://csrc.nist.gov/publications/nistpubs/800-60/SP800-60V2-final.pdf Volume II

The most sensitive systems, those that have lives depending on them, typically seek accreditation at the highest level, Level 4. Systems that are not sensitive seek accreditation at the lowest level, Level 1. Moderately sensitive systems typically undergo a Level 2 or Level 3 C&A review.

It is important to understand the appropriate level of accreditation required for the systems undergoing the C&A review as the auditors will not accredit a system that has been incorrectly categorized. However, it is up to the system owners to understand the levels of certification and their implications. Differing amounts of information are required in the documentation that must be provided to the Mission Assurance auditors depending on the level of accreditation that is sought. Determining the appropriate level of certification and accreditation to seek out is the first step in getting your C&A project off the ground.

Contractor Support

It’s often the case that federal agencies elect to outsource their C&A Review when their own resources are fatigued trying to meet other operational deadlines. There are a number of companies that specialize in assisting U.S. federal agencies with their C & A Review. If an agency is considering outsourcing the C&A Review, they should interview all potential consultancies and ask for references for other C&A initiatives the consultancy has previously completed. If a consultancy has successfully assisted agencies in obtaining full accreditation of their systems, this is a positive sign that they have a reputable track record.

Most U.S. federal agencies do not leave enough time to prepare a comprehensive C&A package. A medium-sized C&A effort requires six months for a team of three consultants who know what they are doing. If your project team is new at C & A, you can expect the process to take much longer. If you are the CIO of a U.S. federal agency, your systems will likely be shut down if they don’t pass the accreditation process, which could become career limiting. Therefore, if you don’t have enough in-house resources to get the job done, this is one particular case where you will definitely want to outsource the project to some expert consultants.

For additional information or assistance with building a secure infrastructure contact Computer Security Consulting, Inc (CSCI).

Implement - At this stage, security controls are implemented. This requires taking all of the information in the previous steps and applying them in a practical manner to the information systems. For example, if a system was given a security of categorization of Low from the Categorize step, the Low set of controls from NIST 800-53 would be implemented. In addition, any supplemental controls that management deemed necessary, would also be implemented.

Again, NIST provides guidance for a variety of controls though their special publications series (NIST 800 SP). Some of NIST’s documents provide for detailed control measures such as securing wireless or implementing PKI. Those responsible for security are also able to use industry best practice and vendor guidelines for securely implemented systems.

Assess - Once controls have been put into place. They need to be assessed to determine their effectiveness. This is usually done by an outside consultant (like CSCI), to minimize any conflicts of interest on part of the staff (separation of duties is generally a control which is implemented). If the initial documentation was written by one contractor, ideally a second contractor would be brought in to confirm the documentation for the same reasons. In fact, the USDA had this as part of their C&A policy.

The assessors will utilize NIST SP 800-53a (a companion document to NIST 800-53r2) to determine the state of the controls. This is usually part of a Security Test and Evaluation (ST&E) process and documentation. In addition, the assessors will review, update, and edit the System Security Plan, the Risk Assessment (using the new information), and Contingency Plan. Other minor documents such as System Features User Guide (SFUG) and Trusted Facility Manual (TFM) may be updated during this process as well.

Authorize - Once the information system has been assessed, it needs an Authorization to Operate (ATO) or an Interim Authorization to Operate (IATO). This is performed by the Designated Approving Authority (DAA). This is the person who basically assumes the risk of the information system to operate as described. This is usually someone in upper management of the agency.

All of the system documentation is packaged up and delivered to the DAA. It is up to the DAA to review and trust the documentation is valid. They must then decide that it is ok for the system to operated as described by granting it an ATO. If the DAA decides not to grant an ATO, there are two other options. One is to flat out deny the ability of the information system to operate. This would require the documentation and/or the information system to be better shape. Or, they could grant an IATO. This allow the information system to operate only for a fixed time, say 3 months. It is accompanied with a line item of requirements with deadlines. These requirements must be in place by their deadlines for the DAA to grant an ATO. These requirements are called a Plan of Action and Milestones (POAM). If the information system does not meet the POAM requirements, the DAA may decide to shut down the information system.

Monitor - This step is essentially what it says. You monitor the information system and adjust as you go along. Generally, when changes happen to the system, the security documentation needs to be updated. For instance, if the data center where the system sits receives a more power UPS, than it should be reflected in the documentation that it was upgraded. This could have been a POAM item and may be marked off that list and also removed from the Risk Assessment. For major changes, it might kickstart the entire process over again. For instance if web application was a Microsoft .NET application and it was rewritten in JAVA, this would be a major change that has huge security impacts to the security posture of the information system. This would require a rework of all documentation to ensure that it is still applicable. The DAA would then need to reaccredit the system for operation.

FISMA essentially tasks the National Institute of Standards and Technology (NIST) with developing the framework and controls for the security methodology. NIST Special Publications 800 Series provides the guidance for FISMA. This methodology follow 8 steps:

1. Categorize
2. Select
3. Supplement
4. Document
5. Implement
6. Assess
7. Authorize
8. Monitor

Categorize - Using risk based methodology, an Information System is assigned one of three levels of risk.  They are Low (L), Moderate (M), or High (H).  NIST provides several documents for guidance on the categorization of risk levels.  They are Draft SP 800-60r1 Guide for Mapping Types of Information and Information Systems to Security Categories: (2 Volumes) - Volume 1: Guide for Mapping Types of Information and Information Systems to Security Categories Volume 2: Appendices and FIPS 199 Standards for Security Categorization of Federal Information and Information Systems.

Select - This step selects which controls are to be implemented on an information system.  The controls are selected based up on the security categorization selected above.  In addition, the depth of the control is influenced by the security categorization.  NIST SP 800-53r2 Recommended Security Controls for Federal Information Systems is the most important document that NIST has written with regards to security controls.

In NIST 800-53, security controls are broken down into functional families.  There are 17 functional families.  Those families of controls are further broken down into three categories.  The three categories are Managerial, Operational, and Technical.  These groupings are an ordered logical set of groupings.  Again, the controls listed in 800-53 are recommendations based up on the security categorization of the Information System.  One particular control may be applied to all L, M, or H systems.  Another control may only be applied to an H system.  And yet one control may be applied to a M system but in not as much detail as a H system.

Supplement - This step supplements the previous step.  In this step, the agency needs to determine if their are any overriding factors that may impact the system from a risk management standpoint.  An example in this case may be a L system in a M level enclave.  At this point, the agency may decide that all systems in the enclave need to meet the enclave’s risk level categorization vs. the individual information system.  Another example may be a system that sits in a high risk area such as hurricane risk areas or flood plains.  In this case, there may be supplemental controls that need to be applied to the information system to further protect the system.

Document - This is a key step in the risk management approach.  NIST SP 800-18r1 Guide for Developing Security Plans for Federal Information Systems provides guidance for developing a System Security Plan (SSP).  This document is important in describing the system.  This includes, but is not limited to, identification, risk categorization, people responsible for, purpose, description, architecture, applicable laws and regulations, and connection information.  In addition, the second part of the SSP lists the controls that are decided upon in the two previous steps.  This document gives the reader a broad overview of the system and its risk management stance.

This concludes part I of what FISMA provides for US Agencies.

• Certification - The Certification Phase consists of two tasks:

1. security control assessment; and
   
2. security certification documentation. The purpose of this phase is to determine the extent to which the security controls in the information system are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system.

• Accreditation - The Security Accreditation Phase consists of two tasks:

1. security accreditation decision; and
   
2. security accreditation documentation. The purpose of this phase is to determine if the remaining known vulnerabilities in the information system (after the implementation of an agreed-upon set of security controls) pose an acceptable level of risk to agency operations, agency assets, or individuals.

Each of the above mentioned topic areas will be covered within the coming months to assist people in identifying with the mandated requirements of infrastructure security and the application of “Due Care” and “Due Diligence”.

In terms of Information Security, there are three groupings of AC. One is physical, like the example above. One is processes and procedures such as password policies and background checks. The third is technical. The technical controls are usually enforcing the policies and procedures within a computer system.

Access controls are based on three concepts, Authentication, Authorization, and Accountability. Authentication and Authorization are often confused. Authentication determines who can enter the system. Authorization deals with what a person can do in the system once they are authenticated. Accountability deals with identifying the actions of a person once they are in the system.

A traditional UNIX system login shows how this process works. First, a user presents his user name to the system. The system then prompts him to authenticate himself. The user then types his password. He is now authenticated. This is a one factor authentication. The user presented something he knows, his password. Now, that the user is in the system, he only has access to certain areas. Typically this would be full read, write, and execute permission in his home directory, some read and write access to the /tmp filesystem, and some read and execute permissions to system binaries such as ls or more. He would not be able to get into other users’ home directories, system directories, or execute more important system binaries. This takes care of Authentication and Authorization. Accountability comes into play from the system side. The system logs that the user logged in. Depending on the audit capability of the system, everything the user does may be logged. Now the user can be tracked.

So, what was that one factor that was mentioned earlier? Factors of authentication are broken down into three categories. They are: one, what do you know; two, what do you have; and three, what you are. Things that you know are usually passwords, pin numbers, mother’s maiden names, etc. Things that you have are ATM cards, credit cards, smart cards, real ID tokens, etc. Things that you are, are biometrics, retina scans, finger prints, voice, palm layouts, etc. One factor authentication uses one of the three, two factor authentication uses two of the three, three factor authentication uses all of them. In movies you will see three factor authentication quite a bit where someone will swipe a card, punch in a number on a keypad, and then have a retina scan. A common two factor authentication happens at the ATM where you supply your card (what you have) with a pin number (what you know).

This article should give you a brief introduction into what Access Controls are and what they do. For more information please see: http://en.wikipedia.org/wiki/Access_control, ISC2, and CCCure.org.