Categorizing information systems based on the National Institute of Standards and Technology (NIST) Federal Information Processing Standard (FIPS) 199 is no easy task for even the most knowledgeable information security professional. After more than two years of being on the road and working with over 15 different organizations to prepare updated NIST-based information security documentation packages, we have found that categorizing information systems for an organization can be one of the most confusing exercises in the entire process. Once the system has been appropriately categorized, the selection of controls and other tasks that make up a complete, compliant documentation package seem to flow into place - but getting through categorization can be a painful and time consuming experience. The question is: Why does this have to be so hard? A Bit of History The E-Government Act of 2002 (P.L. 107-347) was signed by the President on December 17, 2002. That act required NIST "develop standards and guidelines, including minimum requirements, for information systems used or operated by an agency or by a contractor of an agency or other organization on behalf of an agency". As mandated by this act, NIST published FIPS 199, Standards for Security Categorization of Federal Information and Information Systems. This is the standard that must be used by most Federal organizations to categorize their systems. The standard is a total of 13 pages in length, with about six pages of useful information. The problem comes when you actually try to apply the standard to real world systems. We have found there is often a profound misunderstanding when applying the terms that deal with impact (limited, serious, and severe or catastrophic) to actual systems. NIST points you to Special Publication (SP) 800-60, Guide for Mapping Types of Information and Information Systems to Security Categories, to assist in clearing up the ambiguities. While this document provides a large number of system types and baseline categorization recommendations, the problem comes when you read the text to apply it to your system. NIST tried to cover many situations and left the categorization, in many cases, so wishy-washy that it could be interpreted in many different ways. Boots on the Ground Those in the field who are actually trying to implement an effective security program are supposed to be able to take the guidance and apply it to operational systems. The result has been, well let's just say, interesting. In general we find two things: First, in many cases, systems are categorized higher than appropriate. The primary causes for this include: System owners categorize the system with respect to themselves personally and not the enterprise. We have heard comments such as, "If this system goes away, I could lose my job - so the system is very important (to me) and therefore should be categorized as high". People need to be able to take an organizational, or 'big picture,' view of the system. They should ask, "How will the system loss affect the entire organization (and not just the local unit or organizational element)?" This is sometimes very difficult for system owners, as the system's importance is seen as impacting them on a very personal level. The lack of understanding of organizational mandates. For example, after numerous incidents around the loss or compromise of personally identifiable information (PII) in the Federal government, many agencies set a mandate that every system containing PII shall be categorized at least as moderate. The problem for most organizations is in identifying what is PII (and what isn't), and pinpointing where it exists on their network. This can get really daunting if the system owners take a good, hard look. PII is being stored in many, many unexpected places.fix it? First and foremost, there are two things that must be understood by those that are involved in categorizing an organization's systems. These are: (1) this is harder than expected and takes some time, but by all means take the time and do it right; and (2) once the initial categorization has been established it can be changed as more information comes to light during the process. If the controls associated with the category don't make sense, then change the category! Let's get started. Who Should Be Involved? To start the categorization the right people must be in the room. Of all of the activities in the certification and accreditation process, the impact of the FIPS-199 categorization is by far the greatest. Senior management often thinks this is something that should be relegated to the technical staff. In reality, categorization is frequently driven by politics as much as it is driven by "Gaming the system"is another motivation to over-categorize a system. With a higher security categorization comes the opportunity for more funding. Since reviews only occur every few years a system owner can get additional funding, feign putting in the needed controls, and then spend the money in other areas where they may be underfunded. (Then, if caught, beg forgiveness.) Senior management often relegates system categorization decisions to staff who may believe a certain category is appropriate, but they will 'boost' the categorization in the belief that no one will be fired for putting in place more security than necessary - while too little security can have very negative repercussions. Second, while much less prevalent, there are cases of systems being categorized too low for the information processed or stored on the system. In many cases we have found this is someone who "just doesn't want to play." They categorize the system as low as they can get away with to limit the number of controls that they have to implement (and maintain), and thereby limit the operational impact of providing information security. OK, now we understand the problem - but how do we operational constraints. If the local management is unwilling to participate, they may need some 'encouragement' from senior organizational management. I can almost guarantee that the Veteran's Affairs's Secretary, Jim Nicholson, wished that he had had senior managers involved in those decisions prior to the loss of the widely publicized and now infamous laptop with 26.5 million social security numbers on it. In many cases, it is only senior management who should be making the final risk decision related to the categorization of the systems. It is equally important to cultivate an open atmosphere where everyone involved is encouraged to speak and provide input. One of the ways we do this is by having everyone in the room at the same time. "Everyone" includes system owners, management, and senior support personnel as considered appropriate by the organization. They must take ownership of the security process to make sure everyone with a 'dog in this hunt' is included. It is much easier to get people behind a decision when they know how the decisions were made, and had a voice in making them. Developing Accreditation Boundaries While this subject could easily be another article on its own, in our experience most organizations did a pretty good job in establishing accreditations boundaries. The main problem we found was that larger organizations sometimes tried to throw too many disparate system types into the same accreditation boundary to limit the number of security plans that would have to be written. NIST SP 800-37, Guide for the Security Certification and Accreditation of Federal Information Systems, has done an excellent job in defining the criteria for an accreditation boundary. They include:
The next step in the process is the preliminary categorization once the initial grouping of systems has been completed,. Initially, we worked on each accreditation boundary until we thought we had an understanding of the information within it, categorized it, and then moved to the next boundary. We refined that process and found that getting each system owner to present an impromptu 3-5 minute discussion of their accreditation boundary and the type of processing taking place was extremely helpful and much more effective. Using a large table, similar to Table 1 (above), drawn on a white board, we have each system owner fill in the four right-most columns. The system owner describes the type of processing and the primary business functions accomplished within their accreditation boundary. They also describe the major types of systems, including operating systems, contained in the accreditation boundary. Then, the individual provides their initial categorization for confidentiality, integrity and availability. The individual facilitating the discussion should make no judgments but should try to illicit as much information as needed as to why the individual categorized the system at that level. This helps everyone in the group understand their thinking. Care must be taken to not make judgments on or ridicule the person making the case for categorization during this time. Next, take SP 800-60 and put in the recommended (or baseline) categorization for each system type. Use the samples and caveats as presented in SP 800-60 to gain consensus on the most likely categorization based upon NIST. We add this categorization to the table in a manner similar to that shown in Table 2 (below) in italics. The organization must make a final single categorization decision for each accreditation boundary for confidentiality, integrity, and availability (CIA) once we have collected all of the data. It must also be remembered that this is a 'system high' categorization, so any categorization within the accreditation boundary at a higher level forces all to be categorized at the higher level. NIST has not, and probably never will, designate individual controls as related to a specific FIPS categorization for confidentiality, integrity or availability. In many cases they cannot, as the control may address more than one area of the CIA triad. Some of the controls are obviously focused in only one area, but implementing those controls for a particular system may or may not make sense. The system owner needs to carefully assess the cost effectiveness of implementing each control to reduce the residual risk, and determine what makes sense for the organization. For example, many of the sites we worked with designated their LAN infrastructure as an accreditation boundary. We had about 50% of the organizations put their LAN infrastructure at moderate and 50% put it at low. The 50% that put it at moderate simply chose not to implement controls that were neither cost effective nor that did not make sense for their LAN. The 50% at low used the NIST recommendation for control augmentation, and added appropriate moderate level controls to reduce their residual risk in areas that were cost effective and operationally necessary. The question we often get is, "Which is the better way to go? Categorize the system high and document the unneeded controls, or go low and supplement the baseline?" Based upon the results of both agency inspector general reviews and system test and evaluations (ST&Es) done by independent organizations, we have found that both appear to be approved on an equal basis. The important thing is to adequately document how the categorization was accomplished, why controls are either included or excluded, and to make sure the designated approving authority (DAA) is fully aware of how the decisions were made and is in agreement with the conclusions. Systems with Special Designations Systems with designations such as Critical Infrastructure Protection (CIP), for example, must be very carefully assessed. In many cases, organizations simply designate these systems as "high." The obvious question is: Is the system high for confidentiality, integrity and availability? In many cases the CIP designation refers primarily to availability only, with the other areas being moderate. By carefully documenting this fact the system owner can then choose not to implement many of the high controls, as they do not support the high availability requirement nor reduce the residual risk. Since most of the control augmentations from moderate to high deal with automating specific control functions, this additional functionality can be very expensive and provide little to no additional risk reduction in the area of availability. In all cases, any control not implemented must be fully documented with the rationale for not implementing the control. Compensatory controls, if needed, must also be fully documented to include how they meet the system's FIPS-199 requirements. Conclusion Remember that system categorization is an iterative process. If at any time in the future the system owner feels that the information or information system is either not protected adequately or is being over protected, the controls implementation should be adjusted appropriately. If this is an accredited system the DAA will need to be included in this process, as the residual risk will likely change. The basis of NIST is to cost-effectively protect the information and information system. Especially in the early stages of establishing a program, do not be afraid to go back and modify either the accreditation boundaries or the categorization to more accurately reflect the mission and functions of the system. We generally found that we had to do this at least two or three times at each site as new information was obtained during the process. The FIPS-199 system categorization provides the basis for many of the control implementation decisions that are part of the C&A process, and can significantly impact the costs associated with the information security program. Management and operational staff need to understand the methodology that was used to provide them with the information they needed to move forward. Management must understand the impacts of major operational or system changes, and how they could impact the security posture. Operational staff should understand how the controls were selected and implemented, the expected impact of the control, and how changes made by the staff could negatively impact the security status of the system. By having everyone involved in the decision-making process the organization is in a much stronger position to protect their information and information systems going forward. And when everything is accomplished in a methodical manner, properly documented, and properly briefed, you'll find the auditors have difficulty in finding fault with the categorization of your information systems. |
 |
|
|
|
