ESF: Endpoint Compliance Reporting
You didn’t think we could get through an 11-part series about anything without discussing compliance, did you? No matter what we do from a security context – whatever the catalyst, budget center, or end goal – we need to substantiate implemented controls. We can grind out teeth and curse the gods all we want, but security investments are contingent on some kind of compliance driver. So we need to focus on documentation and reporting for everything we do. Further, we discussed operational efficiencies in the security programs post, and the only way to get any kind of leverage from an endpoint security program is to automate the reporting. Document what? First we need to understand what needs to be documented from an endpoint perspective for the regulations/standards/guidance you deal with. You must be able to document the process/procedures of your endpoint program, as well as the data substantiating the controls. Process either exists or it doesn’t, so that documentation should be straightforward to produce. On the other hand, figuring out which data types corroborate which controls and apply to which standards requires a big matrix to handle all the permutations and combinations. There are two ways to do this: Buy it – Many of the IT GRC tools out there (and don’t get us started on the value of IT GRC tools) help to manage the workflow of a compliance program. The key capability here is the built-in map, which connects technical controls to regulations, ostensibly so you don’t have to. But these tools cost money and provide limited value. Build it – The other option involves going through your regulations and figuring out relevant controls. This is about as fun as a root canal, but it has to be done. More likely, you can start with something your buddies, auditor, or vendors have. Vendors have excellent motivation to figure out how their products – representing a variety of security controls – map to the various regulations their customers need to address. The data is out there – you just have to assemble it. Actually, there is a third option: to just license the content from an organization like the Unified Compliance Framework folks. They license a big-ass spreadsheet with the map, and their pricing is rather economical. Packaging Now that you know what you need to report on, how do you do it? This question is bigger than your endpoint security program, and applies to every security program you run. We recommend you think architecturally. You’ve got certain domains of controls – think network, endpoint, data center, applications, etc. You want to put together a few things for each domain to make the auditor happy: Control list – Go back to your control maps and make a big list of all the controls required for the auditor’s checklist (they all have checklists). Make sure the auditor buys into your list, and that you aren’t missing anything. Logical architecture – Show graphically (a picture is worth a thousand words) how your controls are implemented. Right – every control on the list should appear on the logical architecture. Data – You didn’t really think the auditor would just believe your architecture diagram, did you? Now you need the data from each of your systems (endpoint suite, configuration management, full disk encryption, etc.) to show that you’ve actually implemented the controls. Your vendor likely has a pre-built report for your regulation, so you shouldn’t have to do a lot of manual report generation. To be clear, one of the value propositions of IT GRC and other compliance automation products like log management/SIEM is to aggregate all this information (not just from the endpoint program, but from all your programs) and spit out an integrated report. For the most part, with a bit of angst in deployment, these tools can help reduce the burden of preparing for frequent audits across multiple regulations for global enterprises. The question to answer is whether the tool can pay for itself in terms of saved time and effort – is the ROI sufficient? Dealing with deficiencies One other thing to consider is the reality of an audit pointing out a specific deficiency in your endpoint security program. The auditor/assessor is there to find problems, and likely they will. But that doesn’t mean the auditor is right. Yes, we said it. Sometimes auditors take liberties and/or subjectively decide how to interpret a specific regulation. If there is a specific reason you decided to either bypass a control – or more likely, implement a compensating control – make your case. In the event (however unlikely) there is a legitimate deficiency, you need to fix it. Welcome, Captain Obvious! During the next audit, first go through the list of previous deficiencies and how you’ve remediated them. Make a big deal of addressing the deficiencies, which will get the audit off on the right foot. What’s next? We’ll cap off the Endpoint Security Fundamentals series by talking about incident response. Stay tuned for the exciting conclusion. 😉 Other posts in the Endpoint Security Fundamentals Series Introduction Prioritize: Finding the Leaky Buckets Triage: Fixing the Leaky Buckets Controls: Update and Patch Controls: Secure Configurations Controls: Anti-Malware Controls: Firewall, HIPS, and Device Control Controls: Full Disk Encryption Building the Endpoint Security Program Share:
