Preparing for a FISMA Security Audit
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Audits and auditors—no one really likes to see them coming, but they're a fact of life. Believe it or not, they are the good guys. That's difficult to remember when they announce their annual Federal Information Security Management Act (FISMA) grades. The FISMA reports have become the de facto standard measurement for how government agencies are performing in the security arena. Unfortunately, there's a lot of misunderstanding about these grades. FISMA does not measure the security posture or preparedness of any agency. Instead, it measures how well the agency complies with federal regulations and public law, and how well it manages its own security program.
Regulations and guidance have changed over the years. The laws have become more specific, and the guidance has taken on greater and greater challenges, providing ever more technical guidance on how to achieve security goals. Unfortunately, the reporting methodology and the proper understanding of the results and grades are not generally well understood. The actually criteria for FISMA reporting is basically the same, but each year the Office of Management and Budget (OMB) changes focus to another area of interest, and this "hot topic" gets some additional weight in the overall scoring process. Regardless of all this, it is still fairly easy to be well prepared for a FISMA Audit
Prepare in Advance of an Audit
Audits tend to be performed on a schedule, so it should be easy to be prepared in advance. Your auditors will certainly wish to see your most current security documents (you do have a Security Plan, right?). What about your security policy, rules of behavior, business continuity, disaster recovery, incident response, change control, security test and evaluation, etc.? Do you have standard build documentation for your servers? What about a high-level design? Network diagrams? Have all of this ready for the initial meeting with the auditors, before they take a look at your system:
- Documentation should include proper labeling (such as "For Official Use Only"), whether it's provided in hardcopy or electronic format. Do you have policies on how this information should be handled? Will you allow the auditors to keep the documentation after the audit is completed, or must it be returned? Do you require a signature to release the information? Make sure you follow all your own policies.
- Do you have all your security controls implemented? Probably not, but that's okay...as long as you have documented all your deficiencies. It may not be possible to have all security controls in place, or to know about all your vulnerabilities. If this is the case, you need to document what is not done. For example, if you plan to implement a new log management tool but haven't gotten around to it, document the goal in a Plan of Action and Milestones (POAM). This shows that you're not only aware of the weakness, but you have a plan to address it. Too many times, the response is "we know about it, but haven't gotten around to it yet." That buys nothing with an auditor. Documenting the POAM shows that you know your environment and you have documented proof.
- Make sure all key people attend the initial meeting with the auditors. Frequently there's no one person who knows everything about a given system. Have everyone present who may be necessary (within reason) to answer key questions by the auditors.
Cooperate During the Audit
Wherever possible, cooperate with the auditors. Provide whatever they need and perform whatever tasks they request, as long as it doesn't violate any existing policies. While an auditor won't generally try to trick you into violating policies, he won't hesitate to call you on it if you do. If there is a request that you feel violates some given policy, the request should be brought to the appropriate person to determine how it should be handled. Most people on staff only have the authority to say "No." Somewhere in the chain of command is a person with the authority to say "Yes." Make sure that person gets the request.