20 Critical Security Controls: Control 8 – Data Recovery Capability
Senior Manager, Corporate Communications
Today’s post is all about Control 8 of the CSIS 20 Critical Security Controls – Data Recovery Capability (the last post pertained to Control 7). Here I’ll explore the (13) requirements I’ve parsed out of the control (I used the PDF version, but the online version is here) and offer my thoughts on what I’ve found [*].
Key Take Aways
- Be aware of process dependency. The case in point is in requirement 6, which implies that your incident response team ought to be trained in backup and recovery. It makes some sense, but this is an example of a character flaw I see across most frameworks: They merely allude to some of the most important relationships between your controls and your business.
- Encrypt wisely. This Control recommends encryption of backup data in transit and when stored offsite. The devil in these details is key management, which is something that might be mentioned by some Control Frameworks, but is a subject about which most steer clear. If you’re doing encryption on your backups, be sure you’re generating keys for the right purpose – long-lived confidentiality and integrity. NIST has some documentation (PDF) you can read through on cryptographic key management – it’s good stuff. The basic thing to remember is that keys are generated for different purposes and not all key generation methods are suitable for all purposes. It’s complicated.
- Oh, right… Backup your data. This Control can’t be understated. If you don’t like it when Word crashes and hasn’t saved your work for the past hour, imagine how much you’ll dislike losing your organization’s systems that run the business.
Potential Areas Of Improvement
- Make allusions explicit. Don’t make it more difficult than it already is for us in the profession. The more complicated and ambiguous a control framework is, the less likely it is that we’re going to get it right. Not only are we likely more vulnerable, we are also wasting valuable resources.
- Be prescriptive only when necessary. There’s a requirement (the first one, in fact) that says you need to ensure that each system is backed up on at least a weekly basis. That may not be true, as per my notes on the matter. In my opinion, a prescription should be provided only when it can be generalized well, and I don’t believe this requirement carries that property. Instead, I would have characterized the requirement in a manner that ensures backups happen when significant or materiel change occurs. Of course, this would assume that you’re forwarding daily information (i.e. audit logs) to a central place (see what I mean about process dependency?).
- Acknowledge the extreme importance of good key management. I’m picking on this subject primarily because I called it out as part of the second Key Take Away, but it’s an area of improvement for this Control Framework (and others) overall. Key management is hard and takes resources. A lot depends on key management, not just encrypted backups. Consider SSH, HTTPS, POP-S, and the countless other protocols relying on public or private key systems. We have keys everywhere, and mostly in places we don’t know and almost certainly under no real management. This could be an area of Control in its own right, and would be one I’d argue belongs in any Top 20.
- Add a Metrics section. So far, all the Controls being examined have a Metrics section. Why not this one? At least cite measurements that would substantiate a claim that 1) you’re doing backups appropriately, 2) they’re secured appropriately, and 3) you’re validating restoration capability appropriately.
Requesting Feedback On
- Description: Ensure that each system is automatically backed up on at least a weekly basis, and more often for systems storing sensitive information.
- Notes: If you follow this guidance verbatim you might find yourself doing some unnecessary work. Your frequency of backup should be predicated not only on data sensitivity, but also on frequency of change. It makes no sense to backup a reporting database more frequently than weekly, for example, if it only ETLs once a week. Know your systems well enough to characterize the data they store, process, and/or transmit so that you understand how to apply availability/recovery controls such as performing routine backups.
- Description: To help ensure the ability to rapidly restore a system from backup, the operating system, application software, and data on a machine should each be included in the overall backup procedure.
- Notes: This is great advice. It’s one thing to backup your data, but it’s another to recover in a timely manner if you need to go through the install process all over again. This requirement ought to be tied back to Controls 1 & 2, and 3, which cover asset management and configuration management of endpoints respectively. If you’ve got a gold image that’s up-to-date, you can probably drop the OS/SW inclusion in the backup.
- Description: All backup policies should be compliant with any regulatory or official requirements.
- Notes: A checklist will serve you well here, assuming you understand your regulatory/contractual burdens. I added contractual to cover the PCI angle, which is, strictly speaking, not regulatory. It will also help to understand which systems and data are covered by each of these regulatory/contractual requirements. Don’t have to store and protect data longer than you need to.
- Description: Data on backup media should be tested on a regular basis by performing a data restoration process to ensure that the backup is properly working.
- Notes: This is a particularly important requirement that dovetails with your DR/BCP planning. If you’ve got requirements to be back up and running within a specific timeframe, and you’re not testing this, then I would say you’re not faithfully living up to your end of the deal – ensure your backups are working.
- Description: Key personal [sic] should be trained on both the backup and restoration processes.
- Notes: This may be something covered in your DR/BCP plan, but if it’s not or you simply don’t have that plan, identify specific individuals to be held accountable for backups. I would identify at least two – a primary with a backup – and rotate their responsibilities around time off. It wouldn’t be good if both of your resources were out of town when you need them. Which does bring up another point – document every step in these processes. It’s one of the most boring and important things you can do in your overall information security management program.
- Description: To be ready in case a major incident occurs, alternative personnel should also be trained on the restoration process just in case the primary IT point of contact is not available.
- Notes: This sounds a lot like a requirement to train your incident response team alongside your backup personnel. Given the previous requirement, this seems to make a case for your IR people to have access to your backup and restoration procedures as appropriate.
- Description: Ensure that backups are properly protected via physical security or encryption when they are stored.
- Notes: This is tricky, but I’d rather protect and manage cryptographic keys than pay for a secured off-site provider. The key here is to balance your real availability needs against overkill on the security side. Your regulatory and contractual obligations may also affect your decision on backup encryption. Either way, do your homework and plan to protect the backup data appropriately – it’s not necessarily a one-size-fits-all solution.
- Description: Ensure that backups are properly protected via physical security or encryption when they are moved across the network.
- Notes: I don’t like the wording of this requirement, primarily because it seems to ask for physical security over your network as an acceptable replacement for encryption while your data traverses that network. I don’t know about you, but I’d much rather just encrypt the data and worry less about the physical security of the network – which is expensive to continuously assess.
- Description: This includes remote backups and cloud services.
- Notes: If your enterprise is using outsource providers for remote backup and/or cloud services, you need to determine whether their Information Security Program aligns with yours in this respect. This is not a technical problem inasmuch as it is an administrative one – you’re going to have to spend some resources to validate, which should always be included in cost of ongoing operations when considering such services.
- Description: Backup media, such as hard drives and tapes, should be stored in physically secure, locked facilities.
- Notes: To me physically secured, implies locked, but we’ll go with it anyway (hey, it’s possible an armed guard rotation is in play). This seems like a no brainer. You ought to have this type of thing set up and now.
- Description: End-of-life backup media should be securely erased/destroyed.
- Notes: There’s some talk about complications with respect to SSD media, which is not yet inexpensive enough to physically destroy.
- Description: Once per quarter (or whenever new backup equipment is purchased), a testing team should evaluate a random sample of system backups by attempting to restore them on a test bed environment.
- Notes: I don’t know where else to mention this, but this is a requirement specifying a metric that is not otherwise specified. There’s typically a Control X Metrics section for each Control, but Control 8 does not have one. Here you’re going to want to validate your backups are working on a quarterly basis and at installation, which I hope is self-explanatory
- Description: The restored systems should be verified to ensure that the operating system, application, and data from the backup are all intact and functional.
- Notes: Here’s more opportunity for measurement. Take the number of restored systems that go back to their expected state over the number of restored systems multiplied by 100 to get the percentage of restored, operational systems.
Esta noticia ha sido vista por