FISMA OVERVIEW AND APPLICATION

Working with governmental assets is perhaps the most rewarding and the most challenging of data situations. While these contracts give a sense of purpose and are often quite lucrative, they come with their own wide set of considerations and limitations, and as such, need to be treated differently from other contracts.

FISMA, or the Federal Information Security Act, was designed specifically for this purpose. Today, we’re going to talk about FISMA, what it is, and what it does. We’ll look at the nine general steps to implementing the FISMA framework, and give some suggestions on how to handle the resultant data.

What is FISMA?

The FISMA, or Federal Information Security Act, is a piece of legislation in the United States of America that defines and outlines a comprehensive data management and security architecture framework meant to protect assets, information, operations, and data involved in government against natural or man-made threats. The legislation was finalized in 2002 and was signed into law that year as well.

FISMA itself is a regulation as much as it is legislation. It lays out a framework of responsibilities to agencies for data security and outlines a general approach for non-agency data managers to follow to ensure the governmental assets are kept secure.

Within this regulation is a set of auditing schedule guidelines, review standards, and acceptable levels of security. Generally speaking, the legislation is meant directly for governmental agencies, but as a general rule of thumb, is applicable to any organization dealing in government data.

The legislation, in short, demands that data be properly encrypted and secured so as to limit Confidentiality, Integrity, and Access faults, and to permit only access to authorized personnel for authorized purposes. The balance between usability and security will be addressed below, but the general balance should be the minimum amount of usability/access needed in order to properly bolster the security of your system as an overall ecosystem.

Nine Steps To Compliance

The National Institute of Standards and Technology has outlined nine general steps towards compliance with FISMA. This is incredibly helpful, as FISMA itself doesn’t necessarily lay out compliance in such a strict way – adoption can sometimes be tricky for this very reason.

Let’s take a look at these steps towards compliance, and see what specifically needs to be done.

1 – Categorize Information

First and foremost, when dealing with governmental data, you need to start by categorizing the data you’ll be controlling. This means a variety of things, but principally, it entails sorting data by security level broadly speaking, as well as origination.

This step is hugely important – knowing that you’re working with the right set of data can do wonders for the later steps, and can ensure you’re catching everything that you need to catch. While everything after this is almost self-checking in that each step internally checks itself due to its pure mechanics, this first step needs to be manually checked and rechecked before moving forward. This is principally because a failure at this step can be catastrophic to the overall health of the process in general.

2 – Establish Controls

Once you’ve categorized your data, you need to establish basic security controls. Generally speaking, this data control can span from encryption to server security, but specifically, you need to scale your solution to the type of data in question.

Some data is obviously going to need different types of security, whereas other data will necessitate other controls. This will be refined later, though the general approach must be solidified at this stage.

3 – Refine Controls, Assess Risk Management

Now that you have a general security plan, you need to refine them. You should have already started this step in its earliest stages in step 2, but here we refine even further. Special data needs to be handled in a more stringent fashion, obviously, but this step also includes unique types of data such as sound, video, etc., and the unique schemes to secure them.

4 – Document Controls

Now that we have all of our controls ready to implement, they must be effectively documented. This is so that later on, should we have an issue, we can go straight to the heart of the issue and fix it where it lies, rather than address the system as a whole for a singular problem.

During this stage, you should also lay out who will be responsible for the data, where the data came from, and the process for establishing an auditable trail.

5 – Implement Security Controls Appropriately

With our controls prepared and documented, roll them out to the appropriate servers and systems.

6 – Assess Effectiveness

This is where our solution proves itself. Now that we’re actively interfaced with the data, we need to test its effectiveness and see whether the data is being properly sorted and protected. Penetration testing can occur during this stage, and should all of our data destruction solutions.

A quick note – data destruction should properly adhere to the steps in this process as well. A solution like ClaraWipe can do exactly that, matching all major industry-standard data destruction processes and methodologies. If we don’t properly manage data destruction, none of the FISMA processes really matters, as our data loses most of its protection at that point.

7 – Determine Risk/Benefit

In this stage, you need to take a look at your processes and identify whether or not the risk to benefit ratio is correct. This basically means that your process should allow for functionality with other needed solutions, should be set up for maximum usability, but still be secure enough to pass FISMA regulations.

This is fundamentally a balancing act. The idea here is to balance access to security. A bank without any doors or safes would be the most accessible in the world. Welding all the money in a box with no entrance would be the most secure, but the least usable.

The same applies here. You want data to be incredibly secure, but also usable.

8 – Authorize Processing

Now that we have everything figured out, we need to authorize the processing of these systems and establish a long-term data security plan. This isn’t just saying “ok” and hoping for the best – adherence to the security plan and ensuring compliance is a huge part of this step, and cannot be overlooked.

9 – Monitor Controls

Once we have our controls in place, we need to test the actual real-life results. During this stage, we need to look at what our controls are actually doing in a measurable way, and whether or not they align with our data plan. If they do, great – we’ve effectively followed the plan! If not, return to step one, and ensure we’re doing it right this time around.

Conclusion

We hope this guide to FISMA has been helpful. FISMA is a complex piece of legislation that is almost impossible to summarize in short form – thankfully, the steps to incorporate FISMA compliance into your systems are not as complex! With a few simple steps, FISMA compliance is relatively easy to incorporate.

As a side note, adhering to these rules are part of compliance with FISMA, but are also a generally good guideline for data in general. While the regulations are strict, they are perhaps the best modern take on data regulation and security and should be looked at by all data providers as a possible ethos to adopt.