Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Handling a Finding
No matter how hard you work, no matter how hard you try, no matter how large a staff at your disposal, no matter how large your budget, there will almost positively be some "findings" by the auditors. There is no such thing as perfect security, and most organizations don't have the time and manpower to meet all the changing requirements and to keep up with the security administration of their systems completely. So, once the auditors present their findings, what do you do now?
It's important to understand exactly what a finding is. A finding is not necessarily a vulnerability or a risk. Many times it's generally an area of concern. As such, a finding doesn't necessarily represent something that needs to be "fixed." First, and foremost, the finding must be evaluated or assessed. The finding should be reviewed in the context of your system and its operational environment to determine what risk, if any, it presents. You should never provide a knee-jerk response and promise that the issue will be fixed until it's been properly reviewed. Here are some real life examples to give you some context:
- Finding: Auditors identified several unrelated systems within an agency that were using clear-text authorization for web-based applications. The concern was the risk of eavesdropping that this presented.
- Knee-jerk reaction: The knee-jerk reaction, given without any thought or review, was to "encrypt the entire network" so the problem would go away.
- Problem: There are multiple problems with this approach. First, there was no understanding of what risk, if any, this really represented to the environment. If there's no known risk, then what are you mitigating? Next, encrypting the entire network for this agency (or most agencies) represented a monumental task in terms of scope, budget, and manpower, not to mention the impact it would have had on the network performance. Finally, encrypting the entire network makes the job of management and monitoring more difficult (not impossible, but definitely more difficult).
- Better response: Assess the impact of this finding on the environment. First, each system owner must perform a data-sensitivity analysis on his system. At the time there was no understanding of the types of data being processed. It may have presented no risk at all to continue operating in the current fashion, or it may have presented tremendous risk to the entire network if critical password information were being processed in the clear. It may also have been exposing sensitive personnel information or privacy data. Until that is known, no further steps should be taken. Once this issue is resolved, the system owner then has the responsibility of protecting the data appropriately.
The response to the auditor should be in the form of a Plan of Action & Milestones (POAM) outlining the steps taken, the responsible parties, and the projected timeline for completion. This may still be a finding on your audit report, but the impact will be lessened due to the corrective action that is planned. If, however, you can quickly determine that there is no risk, then the finding may be removed from the final report.
You Can't Just "Accept the Risk"
I've heard many people tell the auditors, "Yes, we know about that, but we accept the risk." One situation involved outdated routers and switches that were still being managed via telnet. The administrator told me, "That finding will never go away. We've been telling them for years we're aware of it and that we accept the risk, but they still make it a finding." I wrote up a three-page risk analysis that discussed various mitigating factors in the environment. The residual risk was actually very small. I presented this to the system owner, explaining the risk. He agreed that it was acceptable and signed off on the report. He also explained that they had a two-year plan to replace all the equipment, upgrading it so that ssh could be supported. I presented this to the auditors, they agreed with our assessment, and the finding was removed. Paperwork really does pay off!
The main reason the finding had persisted was that the risk had never been quantified. You can't accept what you haven't identified.
It's About the Process
Bruce Schneier is known for saying, "Security is a process, not a product." You may have implemented all your security controls and have excellent policy and procedures, but if your security program or manage process is not effective, that can hurt you as well. This will especially be called into question if your documentation is inaccurate. If there are discrepancies in any of your system documents, it could be inferred that you:
- Don't know your environment.
- You're just "checking the box" to complete the documentation.
- You're reporting inaccurately to try and hide the fact that things are not completed.
Whatever the case, it means that your process isn't working. Either you're not doing the work, you don't know what you're doing, or no one is validating your work. At this point, all your work may be called into question, and the last thing you want is for the auditors to take an even harder look at your systems!
Don't Take It Personally
I know this sounds obvious, and we're all supposed to be professionals, but I've seen too many people get angry, frustrated, and defensive when arguing with the auditors over a finding. No matter what findings are produced, don't take it personally. Getting upset with the auditors will not make the findings go away. Sometimes a finding is produced that is inaccurate or due to a misunderstanding of the environment. Perhaps it's completely wrong, but it's always best to handle these things as professionally as possible. It's also good to realize that, right or wrong, you may not win the argument.
Summary
While I've almost never seen an audit that didn't produce some sort of findings, it is possible to reduce the impact of findings by making sure you're as prepared as possible. Completed documentation is your best preparation for an audit. It's also important to remember that compliance doesn't equal security. Getting a FISMA grade of A doesn't mean your system won't get compromised. It simply means you've somehow managed to keep up with all the federal requirements. While that's a good thing, in the long run it's not enough.