Last updated at Tue, 19 Dec 2023 21:22:13 GMT

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.

Learn more about the CIS Top 18 Critical Security Controls Solutions

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, Controls 2 and Controls 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.

Like what you see? Check out our next post in this series, “The CIS Critical Controls Explained, Part 8: Malware Defenses.”