Research

As we continue down the road of Selecting Enterprise Email Security, let’s hone in on the ‘E’ word: Enterprise. Email is a universal application, and scaling up protection to the enterprise level is all about managing email security in a consistent way. So this post will dig into selecting the security platform, integrating with other enterprise security controls, and finally some adjacent services which can improve the security of your email and so should be considered as part of broad protection. Platform The first choice is which platform you will build your email security on. Before you can compare one vendor against another you need to determine where the platform will run: in the cloud or on-premise. Although it’s not really much of a decision anymore. Certain industries and use cases favor one over the other. But overall, email security is clearly moving to the cloud. The cloud is compelling for email security because it removes some problematic aspects of managing the platform from your responsibility. When you get hit with a spam flood, if your platform is in the cloud, upgrading devices to handle the load is not your problem. When the underlying product needs to be updated, patching it is not your problem. You don’t need to make sure detections are updated. The cloud provider takes care of all that, which means you can focus on other stuff. Leveraging cloud security shifts a whole bunch of problems onto your provider. Bravo! Another essential aspect of enterprise email security is the ability to recover and keep business running in case of a mail system outage. Your email security platform can provide resilience/continuity for your email system by sending and receiving messages, even if your primary email system is down or shaky. If you’ve ever had a widespread email outage and lived to tell the tale, it’s a no-brainer – ensuring the uninterrupted flow of messages tends to be Job #1, #2 and #3 for the IT group. So in what use cases or industries does an on-premise email security gateway make sense? In highly sensitive environments where email absolutely, positively, cannot run through a service provider’s network. Email encryption enables you to protect mail even as it passes through the cloud, but that adds a lot of overhead and complexity. Some industries and verticals – think national security – find the cloud simply unacceptable. Or perhaps we should say isn’t acceptable yet because at some point we expect you to look back nostalgically at your data center – a bit like how you think fondly about wired telephones today. To avoid any ambiguity, aside from those kinds of high-security environments, we believe email security platforms should reside in the cloud. Content Protection Blocking malicious email is the top requirement of an email security platform, but a close second is advanced content protection. This could involve DLP-like scanning of messages and encrypting messages and/or attachments, depending on message content and enterprise policies. Most email security offerings offer content analysis, and typically built-in encryption as well. In terms of content analysis, you’ll want sophisticated analysis to be a core feature. That means “DLP-light,” which we described years ago (Intro, Technologies, Process). It’s not full DLP but provides sufficient content analysis to detect sensitive data, and enough customization to handle your particular data and requirements. The platform should be able to fingerprint sensitive data types and use built-in, industry-specific, and customizable dictionaries to pinpoint sensitive content. Once a potential violation is identified you’ll want sufficient policy granularity to enable different actions depending on message content, destination, attachment, etc. The more involved the employee can be in handling those issues (with reporting and oversight, of course), the less your central Security team will get bogged down dealing with DLP alerts – a huge issue for full DLP solutions. Speaking of actions, depending on content analysis and policy, the message in question could be blocked or automatically encrypted. The most prevalent means of email encryption is the secure delivery server, which provides control over encrypted files (messages) by encrypting and sending them to a secure messaging service/server. The recipient gets a link to the secure message, and with proper authentication can access it via the service. Having sensitive data in a place you control enables you to set policies regarding expiration, printing, replying and forwarding, etc. based on the sensitivity of the content. Integration The base email security platform scans your inbound email, drops spam, analyzes and explodes attachments, rewrites URLs, identifies imposter attacks, looks for sensitive content, and may encrypt a subset of messages which cannot leave your environment in the clear. But to scale email security to your enterprise, you’ll want to integrate it with other enterprise controls. Email Platform The integration point that rises above all others is your email platform, especially if it is in the cloud (most often Office 365 or G Suite). It’s trivial to route your inbound email to a security platform, which then passes clean email to your server. Integration with the platform enables you to protect outbound email, and also to scan internal email as discussed in our last post. You have options to integrate your security platform with your email server whether email runs in the cloud or not, and whether security runs in the cloud or not. Just be wary of the complexity of managing dozens of email routing rules and ensuring that outbound email from a specific group is sent through the proper gateway or service on the way out. Again, this isn’t overly complicated, but it requires diligence (particularly at scale) because if you miss a route, mail can be unprotected. Keep in mind that integration for internal email scanning is constrained by the capabilities of the email provider’s API. The big email service providers have robust APIs which provide sufficient access; but for any provider, see exactly what’s available. Management An enterprise email security gateway is a key part of your security infrastructure, so it should be tightly integrated into

As we covered in the introduction to our Selecting Enterprise Email Security series, even after over a decade of trying to address the issue, email-borne attacks are still a scourge on pretty much every enterprise. That doesn’t mean the industry hasn’t made progress – it’s just that between new attacker tactics and the eternal fallibility of humans clicking on things, we’re arguably in about the same place we’ve been all along. As you are considering upgrading technologies to address these email threats, let’s focus on detection – the cornerstone of any email security strategy. To improve detection we need to address issues on multiple fronts. First we’ll look at threat research, which is critical to identify attacker tactics and maintain information sources of known malicious activity. Then you need to ensure detection will scale to your needs, as well as implement some attack specific detection in case of phishing and Business Email Compromise (BEC). Finally we’ll evaluate use of internal email analysis as another mechanism to identify malicious activity within the environment. Threat Research: the Foundation of Detection The general tactics used to detect email attacks, such as behavioral analysis and file-based antivirus, are commoditized. There is little value in these tactics themselves, but many detection techniques working together can be highly effective. It’s a bit like mixing a cocktail. You can have five different liquors, but knowing the proportions of each liquor to use lets you concoct tasty cocktails. Modern detection is largely about knowing what tactics and techniques to use, and even more about being able to adapt their composition and mixture because attacks always change. So threat research is contingent on a mature and robust analytics capability. It’s about blending sources like multiple AV engines, malicious URL databases, and sender reputation databases to determine the optimal mix and weighting of each input. It’s necessary to have a sufficiently large corpus of both good and bad email to identify common components and patterns of malicious email, which then filters back into the detection cocktail. Threat research requires analytics infrastructure and data scientists to run it effectively. During the courting process with potential vendors it’s helpful to understand their threat research capability in terms of resourcing/investment, skills, and output. Sure, having a research team find a new and innovative attack and getting tons of press is laudable, but it doesn’t help you detect malicious email. We recommend you focus on meat and potatoes activity, like how often detections are changed, and how long it takes a new finding to be rolled out to protect all customers. Applied Threat Research Once you are comfortable with a potential provider’s threat research foundation, the next area to evaluate is how that information is put to use within a gateway or service. For instance, how do behavioral detections work within the gateway or service? You’ll want to know how the offering protects URLs. You learned about their URL database above, but what happens when a URL is not in the database? Do they render it in a sandbox? Do they use techniques like URL rewriting and stripping malicious domains from email to protect users from attacks? Then focus on finding malicious attachments. How are inbound files analyzed? Does the provider have a sandbox service to perform analysis? What is the latency entailed in analyzing a file, and in the meantime is the message held or sent to the user, while the sandbox runs in the background? Will the service convert files to a safe format and deliver that, while maintaining availability of the original? What about impersonation attacks (often called Business Email Compromise [BEC]), where attackers try to convince employees that a message is legitimate, and to take some unauthorized action (like wiring a ton of money to their bank account)? This is another form of social engineering, but these attacks can be detected by looking for header anomalies and watching for sender spoofing approaches (such as changing the display name and using lookalike domains). Even something simple like marking messages that come from outside your domain can trigger employees to scrutinize messages a bit more carefully before clicking a link or taking action. And let’s not forget about phishing. Does the provider have a means of tracking phishing campaigns across their customer base? Can they identify phishing sites and help have them taken down? Phishing is old news, but like many email attacks, seems to have a half-life measured in decades. Finally, how easy is it to categorize users and build appropriate policies for the group? For example some groups have legitimate business requirements to get files from external sources (including HR for resumes, Finance for invoices, etc.). But some employee groups shouldn’t get many email attachments at all, or are likely to click links to compromised sites. So managing these policies at enterprise scale makes a big difference in the effectiveness of detection. We’ll discuss this more in our next post. Internal Analysis to Detect Proliferation Historically email security happened upon receipt of email. Once it was deemed legitimate, a message went on its way to the user, and if the gateway missed an attack you hoped to detect it using another control. Over the past few years more enterprises have started evaluating internal email traffic to detect missed attacks (those dreaded false negatives). For example you can identify lateral movement of an attack campaign by tracking the same email to multiple employees. The ability to monitor and even remove malicious emails from a user’s mailbox can offer a measure of retrospective protection, addressing the fact that you will miss some attacks. But once you identify a message as bad, you can find out which users received it, how many opened it, and whether they clicked the link – and remove it from their inboxes before more damage occurs. Another advantage of integrating security with internal email servers is outbound protection. You can check email for sensitive data and malicious attachments before it is sent, providing an earlier chance to stop an attack than

It’s 2019, and we’re revisiting email security. Wait; what? Did we step out of a time machine and end up in 2006? Don’t worry – you didn’t lose the past 13 years in a cloud of malware (see what we did there?). But before we discuss the current state of email security, we thought we should revisit what we wrote in our 2012 RSA Guide about email security. We thought we were long past the anti-spam discussion, isn’t that problem solved already? Apparently not. Spam still exists, that’s for sure, but any given vendor’s efficiency varies from 98% to 99.9% effective on any given week. Just ask them. Being firm believers in Mr. Market, clearly there is enough of an opportunity to displace incumbents, as we’ve seen new vendors emerge to provide new solutions, and established vendors to blend their detection techniques to improve effectiveness. There is a lot of money spent specifically for spam protection, and it’s a visceral issue that remains high profile when it breaks, thus it’s easy to get budget. Couple that with some public breaches from targeted phishing attacks or malware infections through email, and anti-spam takes on a new focus. Again To be clear, that was seven years ago. The more things change, the more they stay the same. We, as an industry, still struggle with protecting email – which remains the number one attack vector. That’s some staying power! We can be a little tongue-in-cheek here, but it underlies a continued problem that seems to defy a solution – employees. Email users remain the weakest link, clicking all sorts of stuff they shouldn’t. Over and over again. You’ve probably increased your investment in security awareness training, as it seems most enterprises are moving in that direction. We recently wrote a paper on Making an Impact with Security Awareness Training to cover that very topic. So check that out. In this series, Selecting Enterprise Email Security, we’re going to hit on the technologies and how to evaluate them to protect your email. Before we get into that, let’s first thank our initial licensee, Mimecast, who has graciously agreed to potentially license this report at the end of the project. Remember, you benefit by gaining access to our research, gratis, because folks like Mimecast understand the importance of educating the industry. Steady Progress We can joke a bit about the Groundhog Day nature of email security, but let’s acknowledge that the industry’s made progress. Email providers (including Microsoft and Google) take security far more seriously, bundling detection capabilities into their base email SaaS offerings. Although not the best (we’ll dig into that later in this series), but we prefer even mediocre security built-in to none at all. The arms race of detecting email-borne threats continues, with security vendors making significant investments in complementary technologies (such as malware analysis and security awareness training), purpose-built phishing solutions emerging, and a focus on threat intelligence to help the industry learn from common attacks. As in many other aspects of security, the emergence of better and more accurate analytics has improved detection. Security vendors have access to billions and billions of both good and bad emails to train machine learning engines, and they have. All the major companies hire as many data scientists as they can find to continually refine detection. We’ll dig into how to figure out which detection capabilities make an impact (and which don’t) in our next post. New Attacks Unfortunately it turns out adversaries aren’t standing still either. They continue to advance phishing techniques, especially for campaigns which last hours rather than days. They hit fast and hard, and then their phishing sites are taken down. Financial fraudsters have automated many of their processes and packaged them up into easily accessible phishing kits to keep overwhelming defenders. We also see new attacks, like BEC (Business Email Compromise), where attackers spoof an internal email address to impersonate a senior executive (perhaps the CFO) requesting a lower-level employee transfer money to a random bank account. And unfortunately far too many employees fall for the ruse, assuming what looks like an internal email is legit. And that’s not all. We see continued innovation in both defeating endpoint defenses (even fancy new next-generation AV products) and preying on the gullibility of employees with social engineering attacks. So your email system is still a major delivery vehicle for attacks, whether you run it in your data center or someone else’s. That means we need to make sure your email security platform can protect your environment. We’ll go through the latest technological advancements, and define selection criteria to drive your evaluation of enterprise email security solutions. We’ll start by digging into the latest and greatest detection techniques, then walk through enterprise features needed to scale up email security. Finally we’ll wrap up by providing perspective on procurement, including how to most effectively test email security services. Again, thanks to Mimecast for licensing this content so you can be brought up to date on the latest and greatest in email security. Share:

Cloud Security CoE Organizational Models In the first post of our Cloud Security Center of Excellence series we covered the two critical aspects of being successful at cloud security: accountability and empowerment. Without accepting accountability to secure all the organization’s cloud assets, and being empowered to make changes to the environment in the name of improved security, it’s hard to enforce a consistent baseline of security practices that can dramatically reduce an organization’s attack surface. Read the full post at DisruptOps Share:

Forming the Cloud Security Center of Excellence We spend a lot of time talking to cloud security professionals, basically trying to figure out the best ways to get their jobs done in largely uncharted territory. Cloud technology is evolving at an unprecedented rate, empowering line of business users to move fast and not ask permission from IT or Security. Of course this can result in an unmanaged environment, with many traditional governance models rendered useless by the accessibility and ease of using the cloud. This is what we call cloud chaos. Read the full post at DisruptOps Share:

Things have been good in security. Really good. For a really long time. We can remember when there were a couple hundred people that showed up for the RSA Conference. Then a couple thousand. Now **over 40,000 people** descend on San Francisco to check out this security thing. There are hundreds of companies talking cyber. VC money has flowed for years, funding pretty much anything cyber. Cyber cyber cyber. But alas, being middle-aged fellows, we know that all good things come to an end. OK, maybe not an end, but certainly a hiccup or two. Is 2019 the year we see the security market slow a bit? Is there a reckoning upon us, as [we hypothesized on a recent Firestarter](https://securosis.com/blog/firestarter-2019-insert-winter-is-coming-meme-here)? Will we finally be able to get a room at any of the hotels in SF during RSA week? We at Securosis tend to be a lot better at figuring out market direction than timing. But we aren’t taking any chances. So our plan is to party it up while we still can. And that means hosting the Disaster Recovery Breakfast once again. We can’t promise that Brutus will make an appearance, but Rich, Adrian, and Mike will certainly be there. And you’ll also be able to check out the progress we’ve made at [DisruptOps](https://disruptops.com/). It’s pretty astounding if we do say so ourselves. It seems scaling cloud security and operations continues to be challenging for folks. Shocker!   We remain grateful that so many of our friends, clients, and colleagues enjoy a couple hours away from the insanity that is the RSAC. By Thursday it’s very nice to have a place to kick back, have some quiet conversations, and grab a nice breakfast. Or don’t talk to anyone at all and embrace your introvert – we get that too. The DRB happens only because of the support of our long-time supporters [CHEN PR](http://www.chenpr.com/), [LaunchTech](http://golaunchtech.com/), [CyberEdge Group](https://cyber-edge.com/), and our media partner [Security Boulevard](https://securityboulevard.com/). We’re excited to welcome [Guyer Group](http://guyergroup.com/) and [Babel PR](https://babelpr.com/) to the family as well. Please make sure to say hello and thank them for helping support your recovery. As always the breakfast will be Thursday morning of RSA Week (**March 7**) from 8-11 at [Tabletop Tap House](https://www.tabletopsf.com/) in the Metreon (fka Jillian’s). It’s an open door – come and leave as you want. We will have food, beverages, and assorted non-prescription recovery items to ease your day. Yes, the bar will be open. Mike has officially become an old guy and can only drink decaf coffee (high blood pressure, sigh), but you can be sure there will be a little something-something in his Joe. Please remember what the DR Breakfast is all about. No spin, no magicians and Rich will not be in his Star Wars costume (we think) -– it’s just a quiet place to relax and have muddled conversations with folks you know, or maybe even go out on a limb and meet someone new. We are confident you will enjoy the DRB as much as we do. To help us estimate numbers, please RSVP to rsvp (at) securosis (dot) com. Share:

In this year-end/start firestarter the gang jumps into our expectations for the coming year. Spoiler alert- the odds are some consolidation and contraction in security markets are impending… and not just because the Chinese are buying fewer iPhones. Watch or listen: Share:

This is the third (and final) post in our series on Protecting What Matters: Introducing Data Guardrails and Behavioral Analytics. Our first post, Introducing Data Guardrails and Behavioral Analytics: Understand the Mission we introduced the concepts and outlined the major categories of insider risk. In the second post we delved into and defined the terms. And as we wrap up the series, we’ll bring it together via a scenario showing how these concepts would work in practice As we wrap up the Data Guardrails and Behavioral Analytics series, let’s go through a quick scenario to provide a perspective on how these concepts apply to a simplistic example. Our example company is a small pharmaceutical company. As with all pharma companies, much of their value lies in intellectual property, which makes that the most significant target for attackers. Thanks to fast growth and a highly competitive market, the business isn’t waiting for perfect infrastructure and controls before launching products and doing partnerships. Being a new company without legacy infrastructure (or mindset), a majority of the infrastructure has been built in the cloud and they take a cloud-first approach. In fact, the CEO has been recognized for their innovative use of cloud-based analytics to accelerate the process of identifying new drugs. As excited as the CEO is about these new computing models, the board is very concerned about both external attacks and insider threats as their proprietary data resides in dozens of service providers. So, the security team feels pressure to do something to address the issue. The CISO is very experienced, but is still coming to grips with the changes in mindset, controls and operational motions inherent to a cloud-first approach. Defaulting to the standard data security playbook represents the path of least resistance, but she’s savvy enough to know that would create significant gaps in both visibility and control of the company’s critical intellectual property. The approach of using Data Guardrails and Data Behavioral Analytics presents an opportunity to both define a hard set of policies for data usage and protection, as well as watch for anomalous behaviors potentially indicating malicious intent. So let’s see how she would lead her organization thru a process to define Data Guardrails and Behavioral Analytics. Finding the Data As we mentioned in the previous post, what’s unique about data guardrails and behavioral analytics is combining content knowledge (classification) with context and usage. Thus, the first steps we’ll take is classifying the sensitive data within the enterprise. This involves undertaking an internal discovery of data resources. The technology to do this is mature and well understood, although they need to ensure discovery extends to cloud-based resources. Additionally, they need to talk to the senior leaders of the business to make sure they understand how business strategy impacts application architecture and therefore the location of sensitive data. Internal private research data and clinical trials make up most of the company’s intellectual property. This data can be both structured and unstructured, complicating the discovery process. This is somewhat eased as the organization has embraced cloud storage to centralize the unstructured data and embrace SaaS wherever possible for front office functions. A lot of the emerging analytics use cases continue to provide a challenge to protect, given the relatively immature operational processes in their cloud environments. As with everything else security, visibility comes before control, and this discovery and classification process needs to be the first thing done to get the data security process moving. To be clear, having a lot of the data in a cloud service addressable via an API doesn’t help keep the classification data current. This remains one of the bigger challenges to data security, and as such requires specific activities (and the associated resources allocated) to keep the classification up to date as the process rolls into production. Defining Data Guardrails As we’ve mentioned previously, guardrails are rule sets that keep users within the lines of authorized activity. Thus, the CISO starts by defining the authorized actions and then enforcing those policies where the data resides. For simplicity’s sake, we’ll break the guardrails into three main categories: Access: These guardrails have to do with enforcing access to the data. For instance, files relating to recruiting participants in a clinical trial need to be heavily restricted to the group tasked with recruitment. If someone were to open up access to a broader group, or perhaps tag the folder as public, the guardrail would remove that access and restrict it to the proper group. Action: She will also want to define guardrails on who can do what with the data. It’s important to prevent someone from deleting data or copying it out of the analytics application, thus these guardrails ensure the integrity of the data by preventing misuse, whether intentional/malicious or accidental. Operational: The final category of guardrails controls the operational integrity and resilience of the data. Enterprising data scientists can load up new analytics environments quickly and easily, but may not take the necessary precautions to ensure data back up or required logging/monitoring happens. Guardrails to implement automatic back-ups and monitoring can be set up as part of every new analytics environment. The key in designing guardrails is to think of them as enablers, not blockers. The effectiveness of exception handling typically is the difference between a success and failure in implementing guardrails. To illuminate this, let’s consider a joint venture the organization has with a smaller biotech company. A guardrail exists to restrict access to the data related to this product to a group of 10 internal researchers. Yet clearly researchers from the joint venture partner need access as well, so you’ll need to expand the access rules of the guardrail. But you also may want to enforce multi-factor authentication on those external users or possibly implement a location guardrail to restrict external access to only IP addresses within the partner’s network. As you can see, you have a lot of granularity in how you deploy the guardrails. But stay focused on getting quick wins up front, so don’t try to boil the

It’s that time of year again. The time when Amazon takes over our lives. No, not the holiday shopping season but the annual re:Invent conference where Amazon Web Services takes over Las Vegas (really, all of it) and dumps a firehouse of updates on the world. Listen in to hear our take on new services like Transit Hub, Security Hub, and Control Tower. Watch or listen: Share:

Something You Probably Should Include When Building Your Next Threat Models We are working on our threat modeling here at DisruptOps and I decided to refresh my knowledge of different approaches. One thing that quickly stood out is that nearly none of the threat modeling documentation or tools I’ve seen cover the CI/CD pipeline. Read the full post at DisruptOps Share: