Rapid7 Blog

Caspian Kilkelly  

AUTHOR STATS:

4

The CIS Critical Controls Explained- Control 8: Malware Defenses

This is a continuation of our CIS critical security controls blog series. Workstations form the biggest threat surface in any organization. The CIS Critical Security Controls include workstation and user-focused endpoint security in several of the controls, but Control 8 (Malware Defenses) is the only…

This is a continuation of our CIS critical security controls blog series. Workstations form the biggest threat surface in any organization. The CIS Critical Security Controls include workstation and user-focused endpoint security in several of the controls, but Control 8 (Malware Defenses) is the only control to strictly focus on antivirus and malware across the organization. It's pretty important, too: Malware networks are often run by organized criminals who profit from both the stolen identities of end users and access to the extensive computing and network resources that malware is designed to exploit. To a lesser extent, malware is also used for corporate and nation-state espionage, acts of vandalism, strategic attacks on infrastructure, and just about any circumstance where an attacker wants to compromise multiple hosts with minimal effort. Simply put: Malware is a big problem, and it puts everyone at risk. Much like disease prevention, malware prevention relies on a combination of "computing hygiene" and herd immunity; if it's done right, we all have a part in reducing the impact of malware and the risks associated with it. What this control covers Control 8 covers malware and antivirus protection at system, network, and organizational levels. It isn't limited to workstations, since even servers that don't run Windows are regularly targeted (and affected) by malware. Control 8 should be used to asses infrastructure, IoT, mobile devices, and anything else that can become a target for malicious software—not just endpoints. This control has been specifically included in version 6 of the CIS Critical Controls in a way that focuses on preventing the spread of worms and other self-propagating malicious code, but it's important to note that the Malware Defenses control is actually just a small subset of a good malware protection program. Following Control 8 will significantly improve any kind of incident response program you're developing, and it'll also help with the "top five" CIS controls, since it's dependent on them for effective implementation. Antivirus not dead, sun still rises: a note on terminology The term “malware” can be a little misleading, because it's often used to only describe viruses, or a specific subset of all of the malicious software used to attack information systems. The generally accepted definition of malware includes viruses, worms, ransomware, and anything that is purpose-built to be malicious software; that is what I'm going to stick with here. The nice part of this, though, is that many of the controls and mitigation techniques for viruses also cover typical malware. Another added bonus is that any decent antivirus software still scans for most malware signatures and malicious behavior. Despite claims to the contrary, antivirus is not dead; it just grew up. How To Implement it Centralize, automate, and configure The first step is a pretty big one, but the good news is that it's also fairly easy if you've even partially implemented “big five” critical controls. Asset configuration and management tools, as well as continual patching and careful system configuration, can go a long way in stopping most malware infections. This includes ransomware like CryptoLocker, WannaCrypt, and others, since they rely on poorly-configured or unpatched systems to spread. Simply put: You probably already have a good start if you're using any centrally managed antivirus service and managing your workstation and endpoint configuration. Central management of antivirus and antimalware clients is pretty important, since the logs generated by these systems can be used to aid in the incident detection process and generally help with cleanup and response. It's also important for the obvious reasons: Antivirus still protects against viruses, and centrally managed ones mean you can control precisely how. Log your incidents, and track them over time As Cindy Jones discussed in an earlier post on logging, tracking and reporting incident information at a log level is pretty important. It also acts as a good indicator of network health and security. Enterprise-level antivirus and antimalware solutions usually have some form of logging facility, and this—in concert with other logs from firewalls, network instruments, and critical systems—will give the security team a clear picture of what's going on inside the network. Logging both detection and response information from your antivirus is a good way to help color in that picture. Aside from detection statistics, it is critical to log what has been done with it when it's detected, and where it came from. Unfortunately, relying on individual incidents can be like drinking from a water cannon, so rather than relying on alerts for every incident, track the rate of change and the types of infection until you need to look at individual alerts or systems. If you don't already have one, you will need to build a service that can monitor the number of infected and damaged machines in order to give you a clear picture of where the malware is. Antimalware everything, all the time As I mentioned at the top of this post, network devices and other "non-computer" elements of your organization's information systems are vulnerable to malware. At an organization and policy level, you should be making it clear that everything on your network needs to have an antivirus installed, and anything that is run by your IT team should have an enterprise antivirus client that reports back to you. This is helpful for a few reasons: you will have visibility into the systems with the antivirus or endpoint protection client running, and you also can ensure that you're not granting network access to devices that may be carrying malware. While it may be tempting to ignore some systems, and some vendors don't make clients for some OSes, it's a good idea to aim for as much antivirus/antimalware coverage as possible. OS-level malware, removable media, installation and tampering detection Malware can show up from nearly anywhere, and removable media is a major source of infection. It's critical that you set up your antivirus policy to scan removable media before it's allowed on anything, and limit who can install software. Removing root privileges also removes the risk of user-installed software or malware attacking critical system objects, or exploiting access to administrator rights and privileged system objects. I've personally responded to ransomware cases where the only thing that limited the damage to the organization (and the end user) was the lack of local administrative privilege on the system that got infected. While this isn't mentioned in Control 8, it's brought up in Controls 14 and 5. Watch your edges Network-level scanning is definitely helpful, especially if you have the capacity to spot command and control traffic, malicious DNS and URL requests, and other stuff. It's less helpful if you're just replicating the work that your antivirus clients are already doing. In this case, IDS and logging are also going to play a huge role—specifically, log session lengths, DNS requests, and traffic patterns to look for access with Command and Control networks used by known malware. Session length logging can also give hints about data exfiltration, and looking at things like failed attempts to authenticate on services may also act as a virus or worm attack indicator. Looking at inbound and outbound network traffic from unusual IP addresses, or known bad actor addresses, will also help in identifying malware patterns as they emerge and localizing any response activities. One last word on malware prevention While the CIS doesn't include this in the top five controls, I think Control 8 isstill one of the most important. Good malware prevention actually does as much to help other people as it does for you and your network; you're cutting down the rate of transmission and infection and helping reduce the threat created by the people who use malware to commit crimes. Robust malware prevention techniques and programs actively reduce the threat to legacy systems and "high risk" networks that can't patch their systems for one reason or another. Fighting malware requires that we treat it like measles or smallpox: vaccinate against it, clean up infections, and monitor populations at risk. While it's often inconvenient or difficult, the end result is safer computing for everyone. Photos: Banner photo courtesy of the author- Safety notice from Angus Railyards (now a grocery store), Montreal. Flu virus TEM image from Wikimedia Commons courtesy of the CDC's fantactic Public Health Image Library (PHIL) Forestry Swing machine (and logs) in Kaibab National Forest, AZ also from Wikimedia commons. Inoculation picture courtesy of The University of Victoria's Flickr feed, originally from The Montreal Star.

The CIS Critical Controls Explained - Control 7: Email and Web browser protection

This blog is a continuation of our blog post series around the CIS Critical Controls. The biggest threat surface in any organization is its workstations. This is the reason so many of the CIS Critical Security Controls relate to workstation and user-focused endpoint security. It…

This blog is a continuation of our blog post series around the CIS Critical Controls. The biggest threat surface in any organization is its workstations. This is the reason so many of the CIS Critical Security Controls relate to workstation and user-focused endpoint security. It is also the reason that workstation security is a multibillion-dollar industry. For the next two posts, I'll be covering the specifics of Controls 7 and 8, which focus on the biggest weak points in Information Security: web browsers, email, and malware. This set of posts is intended to help you understand how to properly control the threat surface without limiting usability. Email and web access are critical for most day-to-day operations in any organization, but they're also a significant source of attacks and incidents. Properly securing email servers, web browsers, and mail clients can go an extremely long way in limiting incidents that routinely make news headlines. Good configuration and control of email and web browsers is also going to significantly reduce the number of low-level incidents your organization will encounter on a monthly basis. What the CIS Critical Control 7 covers Critical Control 7 has eight sections that cover the basics of browser and email client safety, secure configuration and mail handling at the server level. The control pays specific attention to concepts like scripting and active component limiting in browsers and email clients, attachment handling, configuration, URL logging, filtering and whitelisting. The premise of the control is fairly straightforward: browser and email client security are critically important for low-level risk mitigation. If your browsers and email aren't secure, your users and your network aren't either. It's worth noting that this control as well as Controls 1, 2 and 8 are often directly connected, and tie into quite a few of the other 20 pretty easily. As I mentioned in the posts for Controls 1 and 2, properly implemented browser and email security will improve any organizations security posture with regards to the other controls. How To Implement it Since this control touches on a number of typically different IT functions, it's important to have the people who run the various systems implicated on board when working with it. Personally, I love dealing with controls like this, as they have the potential to unify an IT or IT/IS department in terms of strategy and process, which always helps improve security awareness and capacity. Start with filtering Successful implementations of Control 7 usually work from two sides: the server/network side and the endpoint configuration/application side. Networking and email server teams should start by limiting how attachments are handled and forwarded from the mail server to clients, and implement content filtering first. In many cases, this is already set up on mail servers for purposes of space management or security, but it's worthwhile to go a step further and ensure that potentially malicious content is being filtered before it reaches any user's inboxes. Implement SPF, or something similar At the same time, implementing Sender Policy Framework at a DNS level and on the mail servers should cut down on the amount of spam and malicious traffic that is coming in to the system. It should be noted that while SPF is not an anti-spam measure, it's effective as a control for malicious mail traffic. It's important that the SPF records and implementation include receiver-side verification (this is actually directly mentioned in sub-control7.7). Typically, this section of Control 7 is overlooked, as it's a high-effort measure, but it's worthwhile for a number of reasons, including SMTP traffic reduction, better junk mail sorting, compatibility with other services, and a general reduction in those "I didn't send a message to this person, but I'm being notified that I did" conversations with your colleagues. It's also worth noting that there are a few pitfalls in implementing it. OpenSPF.org has a good overview of SPF best practices, which should serve as a good starting point. While the CIS recommends SPF, there are alternative systems and strategies. I'd suggest looking into DKIM and DMARC, since they work well in combination with SPF although they're not directly mentioned in the CIS Critical Control 7. If you're using a third-party provider for e-mail, it's assessing this with their personnel; they may have extra expertise on hand, or have done it already. Configure all the things! By far, the hardest part of this control is managing the browsers and clients on your network. It's inevitable that there will be roadblocks, but the good news is that there are a number of good ways to handle browser configuration that should both enable your users, and limit the risks from malicious code in websites (and any attachments that do get through your already iron-clad email server). Typically, Rapid7 recommends that workstations have a “2 browser” system- one should be well secured, and seriously limit access for third-party scripting, ads, and any software that hasn't been reviewed by the security team. The second should be used for general Internet access, and anything that is considered remotely risky. The other configuration should usually be less secure, but limited in use to internal or organization specific services. Usually, this means script based applications or software that require old, out of date or insecure code and components. For example, if your corporate intranet relies on Flash and ActiveX scripts to manage employee benefits, it's probably a good idea to set up a browser so that your users access the intranet with a specially configured browser for that task. This can be as simple as putting a link or batch file on workstation desktops with specific startup info for the browser, or leaving the homepage set to the specific resource in question. I've seen more complex configurations that rely on secure jumphosts, Citrix, or remote desktop and network limitations, but these are often cumbersome for most users, and not recommended. One last bit of advice The simple axiom to follow when implementing this control is: You need to make it simple for the users, or they will find a way around it. It's important to consider this when applying controls 7 and 8, because increasing complexity or the effort your users have to put in often leads to privilege misuse or other workarounds to defeat the controls. In this context, it's worth remembering that human error is still the major source of most breaches and incidents. This includes phishing and clickjacking campaigns, which often foil the best of us, despite well configured systems. A note on URL requests, privacy and security Subcontrol 7.4 specifically identifies URL request logging as a necessity for the identification of potentially compromised systems. This subcontrol actually overlaps with Critical Control 6, which Cindy Jones discussed in an earlier post. While it's important to have this data for incident response and awareness purposes, it's worth considering how long it's kept, and how it's managed; it's extremely important that the request logs are considered private or limited-access data, and aren't being shared in a way that could put users of your network at risk. This also applies to any TLS or encrypted traffic monitoring that you may be undertaking. SPF diagram courtesy of Alessandro Vesely via Wikimedia Commons "Double Fail" image courtesy of Dmitry Baranovskiy via Flickr Arapahoe Basin and ski poles banner courtesy of the author. As with security, proper configuration is often what makes or breaks good skiing. Related Blog Posts: Control 1: Inventory of Authorized and Unauthorized Devices Explained Control 2: Inventory of Authorized and Unauthorized Software Explained Control 3: Secure Configurations for Hardware & Software Explained Control 4: Continuous Vulnerability Assessment & Remediation Explained Control 5: Controlled Use of Administrative Privilege Explained Control 6: Maintenance, Monitoring and Analysis of Audit Logs Explained

The CIS Critical Security Controls Explained - Control 1: Inventory of Authorized and Unauthorized Devices

The Rapid7 Security Advisory Service relies heavily on the CIS top 20 critical controls as a framework for security program analysis because they are universally applicable to information security and IT governance. Correct implementation of all 20 of the critical controls greatly reduces security risk,…

The Rapid7 Security Advisory Service relies heavily on the CIS top 20 critical controls as a framework for security program analysis because they are universally applicable to information security and IT governance. Correct implementation of all 20 of the critical controls greatly reduces security risk, lowers operational costs, and significantly improves any organization's defensive posture. The 20 critical controls are divided into System, Network, and Application families, and each control can be subdivided into sections in order to facilitate implementation and analysis. The first of the 20 controls, “Inventory of Authorized and Unauthorized Devices” is split into 6 focused sections relating to network access control, automation and asset management. The control specifically addresses the need for awareness of what's connected to your network (Tip: Don't forget to scan your network for IoT devices), as well as the need for proper internal inventory management and management automation. Implementing inventory control is probably the least glamorous way to improve a security program, but if it's done right it reduces insider threat and loss risks, cleans up the IT environment and improves the other 19 controls. What it is: The Inventory of Authorized and Unauthorized Devices is part of the “systems” group of the CIS top 20 critical security controls. It specifically addresses the need for awareness of what is on your network, as well as awareness of what shouldn't be. Sections 1.1, 1.3 and 1.4 address the need for automated tracking and inventory, while 1.2, 1.5 and 1.6 are related to device-level network access control and management. The theme of the control is fairly simple; You should be able to see what is on your network, know which systems belong to whom, and use this information to prevent unauthorized users from connecting to the network. High maturity organizations often address the automation and management sections of this control well, but Rapid7 often sees gaps around network access control based on inventory due to the perceived complexity of implementing NAC. How to implement it: There are numerous effective ways to implement the Inventory of Authorized and Unauthorized Devices control. Many of them will also significantly improve the implementation of other controls relating to network access, asset configuration, and system management. Successful implementations often focus on bridging existing system inventory or configuration management services and device-based network access control. The inventory management portion is usually based on software or endpoint management services such as SCCM, while access control can leverage existing network technology to limit device access to networks. Robust implementation of DHCP logging and management will effectively address sections 1.1, 1.2, and 1.4 of Critical Control #1. Deploying DHCP logging and using the outputs to establish awareness of what is currently connected to the network is an extremely good first step to full implementation. Tracking DHCP activity has an additional impact on the IT support and management side of the organization, as well; it serves as a sort of “early warning” system for network misconfiguration and management issues. For organizations with a SIEM solution or centralized audit repository, ingested DHCP logs can allow correlation with other security and network events. Correlating the logs against additional system information from tools like SCCM or event monitoring services can also assist with inventory tracking and automated inventory management, which has added benefits on the financial and operations management side of the shop, as well. Admin Tips: For DHCP-enabled network segments that have lower change rates (non-workstation segments) consider adding a detective control such as a notification of a new DHCP lease. Backup, VOIP, or network device management networks are often effective conduits for an attacker's lateral movement efforts, and usually don't have a high amount of device churn, so increasing detective controls there may create little administrative overhead and increase the possibility of detecting indicators of compromise. The Inventory of Authorized and Unauthorized Devices control also recommends the use of automated inventory tools that scan the network to discover new systems or devices, as well as tracking the changes made to existing systems. While DHCP logging is an effective basic measure, tools such as SCCM, KACE, Munki, and SolarWinds effectively lower the effort and time surrounding inventory management, asset configuration, and system management.  Many customers with existing Microsoft Enterprise Agreements may already have licenses available for SCCM. When combined with Certificate Authorities, Group Policies, and some creativity with Powershell, a handful of Administrators can maintain awareness and control of authorized devices to address many aspects of this foundational critical control. If you're a Nexpose customer, thank you, and Nexpose will let you import your DHCP logs into your deployment to perform dynamic scans of new assets joining your network. Even if you don't use SCCM or Nexpose, most agent-based system discovery and configuration management will allow organizations to address this control and other governance requirements. Effective implementation of inventory based access control will let the organization see and manage what is connecting to their network, which is critical for any good security program. While management tools often require time and effort to deploy, the cost benefit is significant; it allows smaller IT teams to have a major impact on their network quickly, and assists with patching, situational awareness, and malware defense. Hat tip and thanks to Jason Beatty and Magen Wu for application-specific info and editorial suggestions. Related: The CIS Critical Security Controls Explained – Control 2: Inventory of Authorized and Unauthorized Software

The CIS Critical Security Controls Explained - Control 2: Inventory of Authorized and Unauthorized Software

As I mentioned in our last post, the 20 critical controls are divided into System, Network, and Application families in order to simplify analysis and implementation. This also allows partial implementation of the controls by security program developers who aren't building a program from scratch,…

As I mentioned in our last post, the 20 critical controls are divided into System, Network, and Application families in order to simplify analysis and implementation. This also allows partial implementation of the controls by security program developers who aren't building a program from scratch, but want to apply all 20 of the controls. The first two controls of the Center for Internet Security's (CIS) Critical Controls are based around inventory; in my experience, they're also often overlooked by most security teams at the level that the CIS and NIST address them. Knowledge and control of inventory is an essential security architecture need - done properly, it gives the security team very strong awareness of the organization's network and personnel environment, and significantly improves detection and response aspects of any security program. The second control, “Inventory of Authorized and Unauthorized Software” is split into 4 sections, each dealing with a different aspect of software management. Much like Control 1, “Inventory of Authorized and Unauthorized Devices”, this control addresses the need for awareness of what's running on your systems and network, as well as the need for proper internal inventory management. The CIS placed these controls as the "top 2" in much the same way that the NIST Cybersecurity Framework addresses them as "priority 1" controls on the 800-53 framework; inventory and endpoint-level network awareness is critical to decent incident response, protection and defense. What it is:The Inventory of Authorized and Unauthorized Software is part of the “systems” group of the 20 critical controls. The theme of the control is fairly simple: You should be able to see what software is on your systems, who installed it, and what it does. You should be able use this information to prevent unauthorized software from being installed on endpoints. The control is well outlined in NIST Special Publication 800-167, and relates back to NIST 800-53 and Cybersecurity Framework recommendations. High-maturity organizations often address the automation and management sections of this control well, but Rapid7 sees gaps around software configuration control based on inventory due to the perceived complexity of implementing software inventory management systems, or endpoint management clients. How to implement it:Many of the methods used to implement the inventory of authorized and unauthorized software will also significantly improve the implementation of other controls relating to network access, asset configuration, and system management (Controls 1,6,10, 14, 15, 17 and 19). Specifically, Local Administrator access and install rights should not be granted for most users. This limitation also assists with other critical controls that deal with access and authentication. Limiting who can install software also limits who can click “ok” on installations that include malware, adware and other unwanted code. The added bonus to successful removal of admin rights is the lowering of the shadow IT footprint in most organizations, contributing to better internal communication and security awareness. Once installation rights have been limited, any whitelisting or blacklisting processes should be done in stages, typically starting with a list of unauthorized applications (a blacklist), and finishing with a list of authorized applications that make up the whitelist. This can be rolled out as an authorized software policy first, and followed up with scanning, removal and then, central inventory control. Successful implementations of software inventory control often focus on bridging system configuration management services and software blacklisting and whitelisting. The inventory management portion is usually based on a software inventory tool or endpoint management services such as SCCM, Footprints, or GPO and local policy controls on windows. Beyond administrator and installation rights limiting, and blacklisting, some form of integrity checking and management should be set up. This is possible using only OS-based tools in most cases, and Microsoft includes integrity management tools in Windows 10. Typically, OS level integrity management tools rely on limiting installation based on a list of trusted actors (Installers, sources, etc). In more comprehensive cases, such as some endpoint protection services, there are heuristic and behavior based tools that monitor critical application libraries and paths for change. Since integrity management is intrinsically tied to malware prevention and data protection, implementing this section of the control actually assists with Controls 8,9 and 14: Browser and e-mail configuration, Malware Defenses and Data Protection. Admin Tips:Aside from AppLocker, Microsoft allows GPO based whitelisting for supported versions of Windows. These can be edited locally using “secpol.msc” on everything but the “Home” versions of Windows. Organizations with domain controllers or centrally managed Group Policy Objects can use the same process by accessing “software restriction policies” and adjusting the “designated file types” object to include authorized software. This method is effective for workstations with limited software needs, and single-purpose systems such as application servers or virtual machines that run dedicated software. Apple's OSX and most flavors of Linux have similar features, although they may be a little harder to access.Most endpoint protection suites have some form of integrity protection included as an add-on. Your milage may vary with this, since it can be tricky to tune the alerts from these services, but they're a helpful addition to the software integrity side of things, and can be used as a primary means of integrity control in cases where there's already a good inventory in place.  For more general-purpose workstations, a number of client based solutions exist, ranging from antivirus and endpoint protection suites that limit software from a central console to tools like Carbon Black, Power Broker, and the Authority Management Suite integrated into Dell's KACE. Software inventory management is an important enough topic in security that The National Institute of Standards and Technology has published a guide to implementing software whitelisting which covers most of Control 2. It's part of their cybersecurity series, and is available for free on the NIST website as a PDF or by searching the site for publication 800-167. As I mentioned above, this control, and the device inventory control are critical to having a  responsive security program; getting the inventory side of the office in order will cut down on the amount of work needed when an incident arises, and will make policy development and enforcement far easier.

Featured Research

National Exposure Index 2017

The National Exposure Index is an exploration of data derived from Project Sonar, Rapid7's security research project that gains insights into global exposure to common vulnerabilities through internet-wide surveys.

Learn More

Toolkit

Make Your SIEM Project a Success with Rapid7

In this toolkit, get access to Gartner's report “Overcoming Common Causes for SIEM Solution Deployment Failures,” which details why organizations are struggling to unify their data and find answers from it. Also get the Rapid7 companion guide with helpful recommendations on approaching your SIEM needs.

Download Now

Podcast

Security Nation

Security Nation is a podcast dedicated to covering all things infosec – from what's making headlines to practical tips for organizations looking to improve their own security programs. Host Kyle Flaherty has been knee–deep in the security sector for nearly two decades. At Rapid7 he leads a solutions-focused team with the mission of helping security professionals do their jobs.

Listen Now