FISMA: Compliance vs. Security
- Security Controls
- Problems with FISMA
- Need for a Risk-Based Approach
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
FISMA provides a set of specific guidelines for federal agencies on how to plan for, budget, implement, and maintain secure systems. These new, stricter security guidelines replaced an expired set of rules under the Government Information Security Reform Act (GISRA).
Each federal agency must develop, document, and implement a program to provide security for the data and IT systems that support its operations and assets—including both its own systems as well as those belonging to other agencies, contractors, and others supporting its mission. To achieve FISMA compliance, your agency must do the following:
- Plan for security
- Ensure that appropriate officials are assigned security responsibility
- Periodically review IT security controls
- Authorize system processing prior to operations and periodically, thereafter
A great deal of effort has been spent by the National Institute of Standards and Technology (NIST) developing security standards and guidance in support of FISMA and the security of Federal systems as a whole.
NIST has several security programs in place with this goal in mind, such as the following:
- Federal Information Security Management Act (FISMA) Implementation Project
- National Vulnerability Database
- Federal Desktop Core Configuration (FDCC)
- The Information Security Automation Program and The Security Content Automation Protocol
Each of these NIST initiatives takes on the task of developing guidance and standards for another area of Information Security management. The FISMA encompasses multiple such standards and guidance geared completely toward supporting FISMA reporting requirements.
The key aspects of this program are as follows:
- Standards for categorizing information and information systems by mission impact
- Standards for minimum security requirements for information and information systems
- Guidance for selecting appropriate security controls for information systems
- Guidance for assessing security controls in information systems and determining security control effectiveness
- Guidance for certifying and accrediting information systems
There are several critical documents that anyone involved with security in the Federal Government should be acquainted with. These publications include the following:
- FIPS Publication 199: Standards for Security Categorization of Federal Information and Information System
- FIPS Publication 200: Minimum Security Requirements for Federal Information and Federal Information Systems
- NIST Special Publication 800-30: Revision 1, Risk Assessment Guideline
- NIST Special Publication 800-37: Guide for the Security Certification and Accreditation of Federal Information Systems
- NIST Special Publication 800-53 Revision 2: Recommended Security Controls for Federal Information Systems
- NIST Special Publication 800-53A: Guide for Assessing the Security Controls in Federal Information Systems (Completion March 2008)
There are many more documents, but these provide the core of the FISMA program. SP 800-37 is a mature document outlining the C&A methodology employed by government agencies.
Newer guidance, such as SP 800-53, has been declared "completed," but there are unfortunately several gaping holes in this guidance that weaken the overall program.
Security Controls
SP 800-53 defines recommended security controls for IT systems based on the criticality of that system. Categorized as low, moderate, or high, SP 800-53 provides tighter controls for each level. A "high" system requires the addition of automated controls for security processes.
These predefined security controls are a wonderful idea and provide standards of performance and behavior that can easily be measured by auditors. The main problem with these controls is not what’s "in" them; it’s what isn’t. SP 800-53 does a good job of defining the required policies and procedures. It provides some excellent Operational and Management controls within its framework. In my opinion, it’s the technical controls that are lacking.
Windows-centric or Data-centric
SP 800-53 provides excellent guidance for technical controls to be applied to Windows-based systems. It is also highly focused on the handling of data or information. The problem is that many systems do not run on Windows or do not handle data or information in the conventional sense.
The first major shortcoming is the lack of any guidance for network infrastructure in the form of routers, switches, and firewalls. If the core of our network infrastructure is vulnerable or our perimeter can be compromised, then we are in a sorry state.
Along with infrastructure, I would identify the lack of control recommendations for operating systems other than Windows.
In this list of operating systems I would include the following:
- Unix/Linux, AIX
- Macintosh
- Cisco IOS
- Mainframe/legacy system (IBM O/S 360, VAX/MVS)
- Minicomputers (AS/400 or other RISC-based systems)
Finally, I would point out the lack of consideration for voice and video systems. I’ve had to personally deal with each of these issues in various environments, with both Inspector General (IG) teams and auditors from various other government agencies.