In our recent blog, we looked at using Deception solutions to satisfy compliance regulations, in particular controls which are intended to promote active discovery of anomalous behavior. In this blog we’re switching gears and looking at a different aspect of compliance: how Deception should co-exist with compliance audits.
The fundamental concern to be addressed is that Deception deliberately places decoys and disinformation within the in-scope environment that appear to be out of compliance. These apparent violations (potentially leading to findings) can include the following:
- Inventory Omission: Deception assets are generally not registered in asset tracking databases. The auditor might consider this a finding when scans report the existence of systems that are not registered in the database.
- Vulnerabilities: Deception assets often present known vulnerabilities, mimicking an unpatched system.
- Weak Configuration: Deception presents systems that appear to be misconfigured, for example weak passwords, unnecessary services, exposed shares, etc.
Understanding the Audit Process
Deciding how to handle this apparent conundrum involves first understanding the audit process within the organization. The starting point must be knowing what the audit process actually involves: Is this a paper exercise of reviewing control activity processes, or is it a more active “red teaming” exercise where the team probes for issues that can be exploited? What actual tests, scans, process reviews and the like are going to be done? How long will the audit last? And perhaps most importantly, is Deception part of a control activity that should be operating during the audit?
The answers to these questions will then inform these two decision points:
- Do you tell the auditors that the Deception system exists, so that they know in advance that they might run into artifacts of the solution? This seems like an obvious step, but the downside is that it will be impossible to evaluate the efficacy of the solution to detect audit activity, and hence to detect malicious activity.
- Do you de-activate the solution during the audit, so that it doesn’t trigger findings? Also simple enough, but this means you’re unprotected during the audit, which may take weeks. It’s also problematic if the Deception supports a control activity that helps you meets one or more compliance objectives.
Acalvio Recommendations
How to proceed depends on your situation, but we at Acalvio make the following recommendations:
- Use Deception for compliance whenever possible: It’s the most operationally efficient approach to meeting control objectives related to detecting anomalous activity on the internal (in-scope) network.
- Inform the auditors about the Deception solution: It will make for a smoother audit and is the only realistic choice if the solution is being used to meet control objectives. For better or worse, the reality is that most audits are not red-team exercises, so it’s unlikely you’re giving up an opportunity to test the solution in action during the audit.
- Clearly document the impact of Deception on the environment: This will make it easy to correlate audit observations with Deception artifacts.
- Don’t turn off Deception during the audit. You’ll stay protected and won’t have to worry about how long the audit will last. Just be ready with your documentation! On the other hand, if you do decide to disable it, make sure your Deception solution allows you to “disable” and “re-enable” it quickly and with minimal overhead.
In summary, Deception by its very nature creates the potential for misunderstandings during an audit, but it’s relatively easy to avoid them with a little advance planning. Communication and a bit of coordination is all that’s required to pass the audit, and at the same time demonstrate that your organization is taking intranet security very seriously.
Authors
