Home > Articles > Security > Network Security

FISMA: Compliance vs. Security

  • Print
  • + Share This
  • 💬 Discuss
Security awareness within government agencies has risen sharply over the past few years, thanks to a more aggressive view taken by OMB. The requirements to maintain a security Certification & Accreditation (C&A) program have been around for many years, along with much guidance and supporting documentation. Unfortunately, it wasn't until the Government Information Security Reform Act (GISRA) and the Federal Information Security Management Act (FISMA) were put into place that agencies started to take these Federal Regulations more seriously. Randy Nash asks this question: Does FISMA make our agencies any more secure?

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:

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:

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.

  • + Share This
  • 🔖 Save To Your Account

Discussions

comments powered by Disqus