Skip to content ↓ | Skip to navigation ↓

Today’s post is all about Control 5 of the CSIS 20 Critical Security Controls – Continuous Vulnerability Assessment and Remediation (the last post pertained to Control 4).  Here I’ll explore the (51) 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 [*].

Before getting started with the Key Take Aways, a couple of housekeeping notes.  First, I’m going to go out on a limb and assert that each control will have some set of requirements you should be taking to your security tool vendors.  And, when you do, don’t just take their word for it when they say they “meet 20 CSC requirements” – really dig in and prove it.

I am also adding a new listing of requirements where I’m asking for your input.  Interpretation is just that, and I (and other readers) could use your help in a couple of areas.  This listing is found after the Potential Areas of Improvement section.  Additionally, listed requirements will be italicized and shown in a different color.  Another change to the requirement section is that I’m only going to be covering applicable requirements from the “Procedures and Tools” section of the framework (sometimes that section is filled with requirements, and other times, not so much).

Finally, you may have noticed in the Control 4 post that I added a section of links to all controls covered so far near the bottom of this post.

Key Take Aways

  1. Automation is your friend. I don’t think this is a secret when it comes to anti-malware, but automation is the only way to play the game.  Be sure that the tools you use can be configured to automatically update signatures, to automatically “learn” behavioral analysis, and to automatically interoperate with other tools in the system (see the next take away).  Of course, because we’ve covered Control 3 (Secure Configurations for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers), ensure that your anti-malware systems are covered by your Configuration Assessment tools as well.
  2. Don’t be that guy. Many of the recommendations made in this Control, if implemented, would cause an uproar in many organizations.  Consider blocking personal e-mail, instant messaging, and social networks in your environment not from the perspective of a security manager, but from the perspective of your average user.  Let’s face it, most people don’t love their jobs and need some outlet during the day to break up the monotony.  If you cut off their connection to the outside world without justification – that is, without supporting data – you’re going to be “that security guy” who is nothing more than a blocker.  Don’t be that guy.
  3. Start with the most common vectors. If I were starting from scratch, then I would start with the most common attack vector, which I consider to be e-mail and Web traffic.  You most certainly won’t catch everything – anti-malware, like most other security tools, is not perfect.  Once e-mail and Web traffic is covered, I’d start looking at detachable media, but be careful when it comes to relying on configuration settings in your Operating System.  Windows, for example, is not as straightforward as it might seem, so ensure that you’ve got someone who knows what they’re doing (or use Tripwire’s Cybercrime Controls).

Potential Areas Of Improvement

  • Consider different perspectives. This is in direct relation to the second Key Take Away.  Most Control Frameworks, and this one is no exception, consider only the “security perspective.”  I think security managers would be better served by Frameworks if they looked at the world a bit more pragmatically.  Do I know how this would be done?  Not really.  But, I do have the strong sense that most Frameworks are concerned with only one thing – security.  They pay no attention to the real-world goals, aspirations, and problems that security managers face today.  Such a perspective may be passable in certain environments (the Government, Finance, and Energy verticals come to mind), but not in most.
  • General clean-up.  There are a few requirements I would prefer to see rewritten, so that they are clearer to the reader.  There are some undefined and/or uncommon terms used in the requirements, which can make the “letter of the law” difficult to understand (the spirit is there, but try telling your auditor about the spirit vs. the letter).
  • Add some personnel warnings.  That may not be the best way to phrase this, but the truth is that many of the processes and tools mentioned or alluded to in this Control require very specific, skilled expertise.  I would not rely on certifications alone when hiring personnel for these positions – there is plenty of uncertified, but brilliant, talent out there.  When it comes to understanding IP flow, detecting and reverse engineering malware, and things of that nature, you’ll be better served to hire well, which will take longer.  If you don’t feel comfortable hiring on your own, you can probably find some very qualified people to help you – not your typical “headhunter” outfit.  If anyone has advice for other readers out there, talk about it in the comments or contact me directly and I’ll take and share some notes.

Requesting Feedback On

  • Requirement 33 – looking for comments on “reputation-based” systems
  • Requirement 35 – looking for comments on external proxy services
  • Requirement 36 – looking for comments on honeypot/net implementation experience

Requirement Listing

  1. Description: Employ automated tools to continuously monitor workstations, servers, and mobile devices for active, up-to-date anti-malware protection with anti-virus, anti- spyware, personal firewalls, and host-based IPS functionality.
    • Notes: Here anit-malware includes, but may not be limited to (I assume) anti-virus, anti-spyware, personal firewalls, and host-based IPS functionality. Straight away we see the plural – tools. Keep that in mind moving forward.
  2. Description: All malware detection events should be sent to enterprise anti-malware administration tools.
    • Notes: The plural,”tools,” is again used here. This tells me that you have an option to use as many tools as you’d like as long as they meet the needs of the previous requirement and are administered on an eterprise basis. Of course, you’d be better off having one or two vendors in place that give you enough coverage so that you don’t have a plethora of tools to manage. It’s likely that the more tools you have to manage, the more dollars you’re wasting on administration.
  3. Description: All malware detection events should be sent to enterprise event log servers.
    • Notes: This is a clear requirement. Except that the two previous requirements describe two categories of software that can create log entries – the automated monitor and the enterprise administration tool. If it were me, I would take the event coming in to the administration tool and log that. It seems that having the same event come from multiple sources (the sensor and the admin tool) would add unnecessary complication to correlation rules.
  4. Description: The endpoint security solution should include zero-day protection such as network behavioral heuristics.
    • Notes: Here “solution” is expressed in singular form, which tells me that this requirement ought to apply to each category of anti-malware tool expressed in the first requirement. Note also that “network behavioral heuristics” is only an example – other technical solutions might exist, and it’s up to you to figure out which ones provide the most value for the cost.
  5. Description: Employ anti-malware software and signature auto-update features or have administrators manually push updates to all machines on a daily basis.
    • Notes: This is a requirement to update anti-malware as they can be updated on a daily basis. Again, this applies to each category of anti-malware tool described in requirement one. If you have purchased solutions that require manual updates, try to upgrade, because this cost will accumulate quickly.
  6. Description: After applying an update, automated systems should verify that each system has received its signature update.
    • Notes: Your configuration assessment tools can help you with this. They should be able to verify that the update has been received, provided your anti-malware tool doesn’t perform that validation inherently. Even if it does, setting up your configuration assessment tool to check for this automatically is a fairly low-cost check and balance.
  7. Description: Configure laptops, workstations, and servers so that they will not auto-run content from USB tokens (i.e., “thumb drives”), USB hard drives, CDs/DVDs, Firewire devices, external serial advanced technology attachment devices, mounted network shares, or other removable media.
    • Notes: I would say configure all capable computing devices (borrowing the term from the Asset Identification specification) such that they do not auto-run any content on any external media device. This would include USB, FireWire, Thunderbolt, eSATA, mounted network shares, and so on.
  8. Description: If the devices are not required for business use, they should be disabled.
    • Notes: In most cases, disabling these external sources of media will be difficult, or they will cost you in unanticipated ways. Many keyboards and mice work with USB, for example, and unless you go all wireless (batteries cost money too), you won’t really be able to disable USB across the board. Determining the business need needs to come with an analysis of the risks. There may be a process optimization in a very secure environment that uses a USB media device, but what would the risk of exfiltration from an insider be under those circumstances? Is the cost savings due to the process optimization worth the potential loss? Maybe. Maybe not.
  9. Description: Configure systems so that they conduct an automated anti-malware scan of removable media when it is inserted.
    • Notes: I believe most anti-malware capabilities have this type of configuration. I further believe that, if they are all configured this way, it doesn’t matter if the external connection is disabled (i.e. that disabling won’t hinder anti-malware performance in any way), which makes this reasonable. Otherwise, this implies that you need to know your business processes down to the level of understanding the types of removable media you have to use and on exactly which machines, which assumes a degree of maturity that I’m not sure most organizations have today.
  10. Description: All e-mail attachments entering the organization’s e-mail gateway should be scanned prior to being placed in the recipients’ inbox.
    • Notes: I really took this one apart and rewrote it. It’s simply not that clear and I may have crossed a line, but oh well. The requirement now spans this one and the following five requirements represent the fifth “quick win” in the document. This first requirement simply says, “scan incoming e-mail at the gateway.” Reasonable enough.
  11. Description: E-mail attachments should be blocked before they are placed in the recipients’ inbox if they contain malicious code or file types unneeded for the organization’s business.
    • Notes: Your scanning solution needs to do some deep inspection on the attachments to determine whether it contains anything malicious. I’m going to assume that this scanner is included in the buckets mentioned in the first two or three requirements, and further assume that whatever you use for scanning e-mail should be updated on a daily basis as well.
  12. Description: All e-mail content entering the organization’s e-mail gateway should be scanned prior to being placed in the recipients’ inbox.
    • Notes: This requirement is making the distinction between the e-mail body and any attachments. Your scanner solution needs to handle both, and both should be done at the gateway and before they have any opportunity to be opened by the recipient.
  13. Description: E-mail containing malicous content should be blocked before being placed in the recipients’ inbox.
    • Notes: When something is discovered, don’t allow the recipient to open it – quarantine the content instead.
  14. Description: All Web content entering the organization’s Web Proxy (or perimeter if no such proxy exists) should be scanned for malicious content before being delivered to the user agent.
    • Notes: Don’t blow by the term “user agent” without considering what that means. If you were inclined to consider browsers, think again. A user agent can be any software interacting with the Web, and the Web is typically HTTP/S. This brings to mind the complication that many of these scanning tools may have when SSL is in use between the user agent and the server, or when e-mail is sent encrypted (no inspection is possible).
  15. Description: Web content containing malicious content should be blocked from delivery to the user agent.
    • Notes: Whatever solution you have available should be able to block Web-based content as needed.
  16. Description: Apply anti-virus scanning at the Web Proxy gateway.
    • Notes: Self-explanatory.
  17. Description: Content filtering for file-types should be applied at the perimeter.
    • Notes: Whatever solution you use for this requirement should be capable of determining unauthorized file types by inspection of meta-data and/or content rather than by extension.
  18. Description: Deploy features and toolkits such as Data Execution Prevention (DEP) and Enhanced Mitigation Experience Toolkit (EMET), products that provide sandboxing (e.g., run browsers in a VM), and other techniques that prevent malware exploitation.
    • Notes: I didn’t break this apart, because the real requirement is: Deploy features and toolkits that prevent malware exploitation. The rest is exemplary and best handled by a prescriptive benchmark. DEP, for example, is covered by CIS in their Windows benchmarks, and could be associated with this control requirement. On some platforms, you might start enumerating the applications you use and require vendors to use sandboxing when availalble (I’m thinking OS X).
  19. Description: Limit use of external devices to those that have business need. Monitor for use and attempted use of external devices.
    • Notes: Not really sure what they mean by “external devices.” I would guess BYOD, but they explicitly use BYOD elsewhere. As an alternative, they may mean that they want you to monitor use of external devices in the USB/Firewire/Share/Thunderbolt sense and simply be restating the business need requirement.
  20. Description: Block access to external e-mail systems
    • Notes: E-mail is still a very prevalent attack vector, and personal e-mail is perceived (probably rightly) as being a big problem. I can witness to the benefits of restricting access to external e-mail systems from many years ago, which is the problem with such witnessing! However, it does stand to reason that less “junk” flows through corporate e-mail than through personal e-mail. How well that argument stands up requires some real data. Then, there is also the real business need to consider morale and employee happiness. Personal e-mail access throughout the day can be freeing and be a real moral booster, which can increase productivity. Weigh the costs and benefits appropriately.
  21. Description: Block access to external instant messaging services.
    • Notes: All of the above regarding e-mail access applies to instant messaging as well.
  22. Description: Block access to other external social media tools
    • Notes: Again, all of the above regarding e-mail access applies to social media tools as well. However, I think this blockage would cause more “outrage” from employees today than would e-mail. Of course, consider how many of your employees can access this same information using their personal iPhone or Android device.
  23. Description: Automated monitoring tools should use behavior-based anomaly detection to complement and enhance traditional signature-based detection.
    • Notes: This is exactly like the anti-malware requirement that your solutions not rely solely on signatures but that they use some thing else – I wouldn’t say “behavior-based” necessarily, because that may be limiting technology options.
  24. Description: Utilize network-based anti-malware tools to analyze all inbound traffic and filter out malicious content before it arrives at the endpoint.
    • Notes: This is an additional category of anti-malware tool, and it seems that many of the other requirements should apply to it. This, in effect, is a layer. If something gets past this, then it should be caught at the endpoint.
  25. Description: Continuous monitoring should be performed on all inbound and outbound traffic.
    • Notes: Forgive me if I’m being obtuse, but monitoring network traffic seems to be inherently continuous. I suppose an enterprise might monitor at particular times of the day, but I don’t see much value there other than potential cost savings (which, I admit, may be substantial). I wouldn’t recommend anything other than continuously monitoring network traffic at your boundary.
  26. Description: Any large transfers of data should be flagged for validation.
    • Notes: This requirement is essentially saying that you need some DLP solution. I suppose you could create something a little easier, such as creating a correlation rule flagging large transfers for later inspection. But, by then the data is gone. I think the implicaiton here is that the transfer should be held until validated – I may be out of bounds in my interpretation.
  27. Description: Any unauthorized traffic should be flagged for validation.
    • Notes: This doesn’t make sense at all. If the traffic is unauthorized, then there should be NO validation whatsoever. At least in theory. I suppose the validation could be to find false positives.
  28. Description: Large transfers of data validated as malicious should result in the computer being moved to an isolated VLAN.
    • Notes: This is an excellent opportunity for NAC integration. If your detection capability can direct your NAC capability, this migration to an isolated VLAN can be automatic, which is a good thing.
  29. Description: Unauthorized traffice validated as malicious should result in the computer being moved to an isolated VLAN.
    • Notes: Again, this doesn’t make much sense to me from the perspective that unauthorized traffic is, by definition, bad (though potentially not malicious). And, again, if you have the ability for your monitoring system to direct your NAC capability, then you’re in business to automate this migration.
  30. Description: Implement an incident response process that allows their IT Support Organization to supply their Security Team with samples of malware running undetected on corporate systems.
    • Notes: For some reason, when I first read this sentence it felt odd. Maybe I wasn’t awake, but it makes more sense now. It’s explicitly calling for IT operations to provide discovered malware to the Security Team. This, of course, means that you 1) have a Security Team that can analyze (or contract to analyze) the malware, and 2) that your IT ops people are trained well enough to a) know malware when they see it, and b) understand how to handle it. Another implication is that your IT ops guys should let the Security Team take it from there – don’t pass go, as it were. If it were me, I would simply require IT operations to image the machine in question and hand that image over to the Security Team with as much supporting information as possible.
  31. Description: Samples should be provided to the security vendor for “out-of- band” signature creation and deployed to the enterprise by system administrators.
    • Notes: I’m going to guess that “security vendor” is representative and inclusive of your set of anti-malware vendors. Given the wording of this requirement, I would leave it at that, because I just don’t know what object they’re referring to in the deployment. I could assume “signature,” but the way it’s worded is easily construed as the sample – bad. Either way, I think the intent of this requirement is to work in cooperation with the security vendor in the development of signatures by applying them (why else would an administrator be needed when they’re automation?).
  32. Description: Utilize network-based flow analysis tools to analyze inbound and outbound traffic looking for anomalies, indicators of malware, and compromised systems.
    • Notes: This is an increasingly important concern from my perspective. I once read a paper in, “Botnet Detection: Countering the Largest Security Threat,” describing a technique for new botnet detection using only flow information and that did not require more than a few days of packet information – no deep inspection required. Additionally, this method detected botnets that were not even part of the local network! Network flow information can come from a lot of sources, so communicating that information between tools is important, and that’s where interoperability standards come in. The IETF has a Working Group in the Security Area called “IP Flow Information Export” or (ipfix). You should start badgering appropriate vendors to support this work.
  33. Description: Deploy “reputation-based technologies” on all endpoint devices to cover the gap of signature based technologies.
    • Notes: Use of endpoint reputation is something that – to me, at least – is relatively new (not necessarily the concept, but the application). So, I don’t have much to say about this, other than that it’s certainly worth looking into. This may be especially useful if the reputation is composite, such that systems composed of many endpoints and devices can have reputations. Note that I threw devices in there, because they deserve reputations as well. Eventually, if we can get to some standard representation/interpretation of reputation in the IT world, it would be great to see this extended to humans as well. Does anyone have any experience to share about reptuation-based technology?
  34. Description: Enable domain name system (DNS) query logging to detect hostname lookup for known malicious C2 domains.
    • Notes: I guess I’ve been out of the weeds for a while, because this requirement is written as though it’s a common feature across DNS servers. If it is, great! Enable the feature to detect command and control (C2 – again, a glossary would be helpful for many) lookups. If it’s not a common feature, then get on the horn with your DNS server vendor and badger them for it.
  35. Description: Apply proxy technology to all communication between internal network and the Internet.
    • Notes: This sounds good, but, as it is an advanced requirement (and costs money not only in terms of capital but in terms of ongoing maintenance) you need to consider this one carefully. Now, some of the other requirements implying proxies as optional make a bit more sense. There could be a legitimate proxy service provider out there, which would transform your capital expense to an operational expense – somewhat more cost effective year-over-year – but I don’t know of any off hand. Maybe you do?
  36. Description: Some enterprises deploy free or commercial honeypot and tarpit tools to identify attackers in their environment.
    • Notes: This isn’t a strict requirement, but it’s a really great idea for those organizations with the spare cash to do it. I’ll warn you, though, that getting legal buy-in will be difficult. I’d like to ask the community of readers to offer advice in this respect – if you’ve set up a honeypot/net above the radar with legal/organizational support we’d love to hear about it. If you’re worried about disclosing that your organization has done this, feel free to contact me directly with confidence.
  37. Description: The system must identify any malicious software installed on a computer system within one hour.
    • Notes: Self-explanatory, but definitely a source for configuration assessment rules and/or vendor requirements.
  38. Description: The system must identify any malicious software attempted to be installed on a computer system within one hour.
    • Notes: Self-explanatory, but definitely a source for configuration assessment rules and/or vendor requirements.
  39. Description: The system must identify any malicious software executed on a computer system within one hour.
    • Notes: Self-explanatory, but definitely a source for configuration assessment rules and/or vendor requirements.
  40. Description: The system must identify any malicious software attempted to be executed on a computer system within one hour.
    • Notes: Self-explanatory, but definitely a source for configuration assessment rules and/or vendor requirements.
  41. Description: The system must alert or e-mail notification to a list of enterprise personnel via their centralized anti-malware console or event log system.
    • Notes: Self-explanatory, but definitely a source for configuration assessment rules and/or vendor requirements.
  42. Description: Systems must block installation, prevent execution, or quarantine malicious software within one hour.
    • Notes: Self-explanatory, but definitely a source for configuration assessment rules and/or vendor requirements.
  43. Description: Systems must alert or e-mail when such blocking, prevention, or quarantine has taken place.
    • Notes: Self-explanatory, but definitely a source for configuration assessment rules and/or vendor requirements.
  44. Description: Every 24 hours after that point, the system must alert or send e-mail about the status of the malicious code until such time as the threat has been completely mitigated on that system.
    • Notes: Self-explanatory, but definitely a source for configuration assessment rules and/or vendor requirements.
  45. Description: To evaluate the implementation of Control 5 on a periodic basis, the evaluation team must move a benign software test program that appears to be malware (such as an EICAR file or benign hacker tools) but that is not included in the official authorized software list to 10 systems on the network via a network share.
    • Notes: None.
  46. Description: The selection of these systems must be as random as possible and include a cross-section of the organization’s systems and locations.
    • Notes: None.
  47. Description: The evaluation team must then verify that the systems generate an alert or e-mail notice regarding the benign malware within one hour.
    • Notes: None.
  48. Description: The team must also verify that the alert or e-mail indicating that the software has been blocked or quarantined is received within one hour.
    • Notes: None.
  49. Description: The evaluation team must verify that the system provides details of the location of each machine with this new test file, including information about the asset owner.
    • Notes: None.
  50. Description: The team must then verify that the file is blocked by attempting to execute or open it and verifying that it is not allowed to be accessed.
    • Notes: None.
  51. Description: Once this test has been performed transferring the files to organization systems via removable media, the same test must be repeated, but this time transferring the benign malware to 10 systems via e-mail instead. The organization must expect the same notification results as noted with the removable media test.
    • Notes: None.

Other Controls Reviewed In This Series

 

Footnotes

A method and format explanation can be found at the beginning of Control 1.

Editor’s Note: This article was written by a former contributor to The State of Security who now resides with a non-profit group with an excellent reputation. We thank him for his opinions and perspective, and wish we could acknowledge him directly for his outstanding efforts on this series.