20 CRITICAL SECURITY CONTROLS: CONTROL 17 – DATA LOSS PREVENTION Today’s post is all about Control 17 of the CSIS 20 Critical Security Controls – Data Loss Prevention (the last post pertained to Control 16). Here I’ll explore the (23) requirements I’ve parsed out of the control and offer my thoughts on what I’ve found [*]. KEY TAKE AWAYS 1. Start Small. I know the DLP vendors won’t like to hear this, but you can do quite a bit in terms of detection without a “DLP” system. Whatever you do, don’t implement DLP without first looking at how you can use proxies, audit logs, and your SIEM solution first. Leverage what you’ve got. 2. Grow Carefully. Be sure you’re measuring not only what this Control wants you to measure, but that you’re also measuring how effective the solution is overall for your organization. Are you catching tons of false positives and few true positives? Do you have ways of measuring false negatives? I’m not suggesting that DLP isn’t for you, but I wouldn’t recommend throwing caution to the wind here. POTENTIAL AREAS OF IMPROVEMENT 1. Last Time: Key Management Guidance – Please. The first requirement here calls for drive encryption software to be deployed on mobile devices. Not only is the term “mobile device” somewhat nebulous (it’s at least subject to interpretation), but there is a neglect of key management. I won’t mention this shortcoming again, because I don’t really want to sound like a broken record (by the way, if you want to feel old – you do, don’t you? – ask your kids if they know what that is). 2. Understand Your Business. Implementing a DLP-specific solution is not inexpensive. And, it’s not resource-free either. Know your business and implement DLP for what matters first. REQUESTING FEEDBACK ON Requirement 12 Requirement 15 REQUIREMENT LISTING 1. Description: Deploy approved hard drive encryption software to mobile devices and systems that hold sensitive data. Notes: Deploying approved software is one thing, but managing keys and operational security is another. This is hardly a quick win unless you want to accept the risk of losing information that is stored on these mobile devices permanently and possibly without backup (consider what happens when a user forgets the passphrase and they’ve been working on that M&A package). Also, be aware of USB Boot attacks on RAM that can spill the keys sitting in memory – have something in place to mitigate that. 2. Description: Deploy an automated tool on network perimeters that monitors for certain sensitive information (i.e., personally identifiable information), keywords, and other document characteristics to discover unauthorized attempts to exfiltrate data across network boundaries and block such transfers while alerting information security personnel. Notes: To me, they’re describing DLP. No matter what they’re describing this requirement is predicated by the need to know which of your data is ‘sensitive’ and which isn’t. 3. Description: Conduct periodic scans of server machines using automated tools to determine whether sensitive data (i.e., personally identifiable information, health, credit card, and classified information) is present on the system in clear text. Notes: This is a great idea, but it will probably take some manpower to get it done. What sensitive information is on your system, what format does it take, where might it reside (i.e. database, flat file, binary, etc.). At Tripwire, the Security Research Team has been looking into how to do this effectively for specific types of data. Nothing solid yet, but stay tuned for more information. 4. Description: Data should be moved between networks using secure, authenticated, and encrypted mechanisms. Notes: We’ve seen many requirements already for protecting data transiting networks, is this one really needed? Alternatively, why not just have this one? To me, providing confidentiality, integrity, and authentication over the network is inexpensive, and I’d do it for internal communications by default and unless a different business case were given. 5. Description: If there is no business need for supporting such devices, organizations should configure systems so that they will not write data to USB tokens or USB hard drives. Notes: Anymore, it’s diffiicult not to need USB devices. I believe this was covered in asset management (Control 1, IIRC), and this requirement needs you to have a good handle on the precise types of devices you’ll need to hook to USB. 6. Description: If such devices are required, enterprise software should be used that can configure systems to allow only specific USB devices (based on serial number or other unique property) to be accessed, and that can automatically encrypt all data placed on such devices. Notes: See comment above. This is absolutely an enterprise-specific type of requirement. Your vendors aren’t going to be able to do very much in the way of content here, but you can always ask for generic, manageable, and customizable content to lower your cost of implementation. 7. Description: An inventory of all authorized devices must be maintained. Notes: Again, this is a tie back to Control 1, and I’m not really sure that it’s warranted here. 8. Description: Use network-based DLP solutions to monitor and control the flow of data within the network. Notes: I also believe that DLP has been covered elsewhere. The difference here, however, is that it’s telling you that you ought to control the flow of data within the network – the ‘prevention’ part of DLP. 9. Description: Any anomalies that exceed the normal traffic patterns should be noted and appropriate action taken to address them. Notes: This is going to be resource intensive for a while. Whatever DLP solution you find, and there are more than a few out there, try to get one that will actually automate most of this process. Insist on a POC so that it can be demonstrated that the solution works. Let the Sales Engineers work their magic, but make sure that your people understand the tricks and that they provide feedback to you on what it might be like to maintain the solution. 10. Description: Monitor all traffic leaving the organization and detect any unauthorized use of encryption. Notes: Be sure to couple this detection with some common sense, though. HTTPS to known/approved/non-blacklisted sites should probably be ignored as covert channels. Ok, I’m trying (probably not very well) to be a bit snarky, because DLP isn’t perfect. Do the best you can do, but if you’re not getting out of it what you expect, then bail and try something else. 11. Description: Block access to known file transfer and e-mail exfiltration websites. Notes: Subscribe to a service that offers these lists. Ensure the tools you use understand how to import those lists. If they don’t, ask your vendors to help you out. If they won’t, suck it up and do it. A scheduled script ought to do the trick, and if it pings you when it’s done, you can validate the work before going live. 12. Description: The system must be capable of identifying unauthorized data leaving the organization, whether via network file transfers or removable media. Notes: Really, the system needs to detect unauthorized data transfer leaving the organization. The technical detection is probably easier than detecting removable media (really, are you going to search everyone for thumb drives on the way out?). Given that the incidence rate of insider problems seems to have dropped (read the 2013 Verizon DBIR), I’d definitely start with the technical. Also, I’m not sure this is really something that can be measured as stated. What data would you collect? 13. Description: Within one hour of a data exfiltration event or attempt, enterprise administrative personnel must be alerted by the appropriate monitoring system Notes: Here you’re going to want to try exfiltrating a variety of different types of data in a variety of different ways. You should be able to create tests that are fairly comprehensive. Categorize them, though, into low-hanging fruit, mildly difficult, and extremely difficult in terms of detection. If you know something will fail, don’t test it – it’s just a finding. For example, you know you don’t have metal detectors or security guards to deter physical removal of data from the premises, therefore that vector is wide open. 14. Description: Once the alert has been generated it must also note the system and location where the event or attempt occurred. Notes: See comment above. Otherwise, this is fairly straightforward. 15. Description: If the system is in the organization’s asset management database, the system owner must also be included in the generated alerts. Notes: If? If the system is not in the organization’s asset management database, I’d treat it as an incident. How are you going to know who the system owner is anyway? Maybe there’s something I’m missing? 16. Description: Every 24 hours after that point, the system must alert or send e-mail about the status of the systems until the source of the event has been identified and the risk mitigated. Notes: The obligatory nag. 17. Description: The evaluation team must attempt to move test data sets that trigger DLP systems but do not contain sensitive data outside of the trusted computing environment via both network file transfers and removable media. Notes: Normally I wouldn’t have notes for the test descriptions. This is one exception. I’m not sure how you would trigger the DLP unless you mark non-sensitive data as being sensitive and hope that it translates to actually sensitive data. It might be OK, but it seems odd from an experimental perspective (all of these tests are really just scientific experiments to some degree). 18. Description: Perform at least three times: Attempt to transfer large data sets across network boundaries from an internal system. Notes: None. 19. Description: Perform at least three times: Attempt to transfer test data sets of personally identifiable information (that trigger DLP systems but do not contain sensitive data) across network boundaries from an internal system (using multiple keywords specific to the business). Notes: None. 20. Description: Perform at least three times: Attempt to maintain a persistent network connection for at least 10 hours across network boundaries between an internal and external system, even though little data may be exchanged. Notes: None. 21. Description: Perform at least three times: Attempt to maintain a network connection across network boundaries using an anomalous service port number between an internal and external system. Notes: None. 22. Description: Perform at least three times: Insert a USB token into an organization system and attempt to transfer example test data to the USB device. Notes: None. 23. Description: Once each of these events has occurred, the time it takes for enterprise staff to respond to the event must be recorded.
Posted on: Wed, 09 Oct 2013 19:01:55 +0000
Trending Topics
Recently Viewed Topics
© 2015