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 any more. 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 some 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 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 your other security controls and tools. For instance, you’ll want to integrate with:

SIEM: The SIEM tends to be the system of record to aggregate alerts and provide reporting for the security team. So you should be able to send it alerts.

Work Management: Hand in hand with SIEM integration is the ability to send and receive tickets to and from your work management/operations platform. For example, if your email security service detects a device sending reconnaissance email internally, it should automatically start a ticket/case within your operations platform for a Tier 1 analyst to check out.

SOAR Platform: Even more operationally sophisticated is integration with a Security Orchestration, Automation and Response (SOAR) platform. Detection of a phishing email would automatically trigger a response playbook in the email security service to delete the message, block the phishing web sit in the web gateway, and check whether any other employees received the phish.

Adjacent Services

As we wrap up this discussion of features and capabilities of enterprise email security, it’s worth mentioning adjacent capabilities your vendor can provide.

Security Awareness Training: Consolidation has begun: email security companies have acquired or partnered to provide security awareness training. The leverage is clear: it’s more effective to train an employee right after they clicked the wrong message or included private data in an email. For more information on awareness training check out our recent research (Making an Impact with Security Awareness Training).

Web Security: Outbound content is content, right? There should be an opportunity to leverage email content analysis against what goes out via port 80 or 443. It’s not quite that simple – there are substantial differences in terms of latency, decryption, and email versus web exfiltration. So far there we have seen limited benefit from getting outbound web filtering from an email security vendor, but we expect email and web security vendors to continue encroaching on each other’s territory.

Archiving and eDiscovery: This is less about security and more about convenience. Your email security gateway sees every message going in and out of the enterprise, so storing those messages is straightforward. That minimizes the very real technical challenges of storing potentially billions of messages at a reasonable cost and maintaining chain of custody. An email archive also provides a good platform for eDiscovery, which is all about granular searches through high volumes of messages quickly and accurately, and then providing useful reports. If you pursue this, ensure you can manage archive cost by moving messages to less expensive (and less accessible) storage over time.

That covers the capabilities and features of an enterprise email security platform. Next, we’ll work through the finer points of evaluating and procuring products and services to wrap up this series.

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 having an MTA or egress filter inspect messages on their way out.

Optimally you should detect and block every malicious email, but in the real world the ability to take action after the fact provides more flexibility to protect users.

Sharing Threat Intelligence

One last critical capability to evaluate is how threat intel from your email security vendor can make other security controls more effective. To the degree that sender reputation or attack patterns are enumerated in machine data, other security devices and services can consume that intelligence directly. For instance email threat intel could be loaded into your SIEM to look for network traffic to known spam or phishing domains. Likewise, those addresses could be used to block outbound traffic within your egress filters.

As discussed we have made progress in detecting recent email attacks. But evaluating potential vendors against modern techniques increases your ability to protect your organization’s email effectively. In our next post we’ll dig into how to scale email security to your enterprise, including considering a service versus an on-premise gateway (or both), direct integration with other enterprise security controls, and complimentary services, which can improve your entire security posture when used together.

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.

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.

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.

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? 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. 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.

As always the breakfast will be Thursday morning of RSA Week (March 7) from 8-11 at Tabletop Tap House 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.

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.

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 ocean and implement every conceivable guardrail on Day 1. Focus on the most sensitive data and establish and refine the exception handling process. Then systematically add more guardrails as the process matures and you learn what has the most impact on reducing attack surface.

Refining Data Behavioral Analytics

Once the guardrails are in place, you have a low bar of data security implemented. You can be confident scads of data won’t be extracted and copied, or unauthorized groups won’t access data they shouldn’t. By establishing authorized activities, and stopping things that aren’t specifically authorized, a large part of the attack surface is eliminated.

That being said, authorized users can create a lot of damage either maliciously or accidentally. Behavioral analytics steps in where guardrails end by reducing the risks of negative activities that fall outside of the pre-defined rules. Thus, we want to pair data guardrails with an analysis of data usage to identify patterns of typical use and then look for non-normal data usage and behavior. This requires telemetry, analysis and tuning. Let’s use unstructured data as the means to describe the approach.

Getting back to our pharma example, the cloud storage provider tracks who does what to every bit of data in their environment. This telemetry becomes the basis of their Data Behavioral Analytics program. In order to accurately train the analytics model, they need data on not just known-good activity, but also activity that they know violates the policies. Keep in mind the importance of data quality, as opposed to mere data quantity. When building your own program make sure to gather data on user context and entitlements, so you can track how the data has been used, when and by which user populations.

Of course, you could just look for anomalous patterns on all of the telemetry, but that can create a lot of noise. So we recommend you start by identifying a type of behavior you want to detect. For instance, mass exfiltration of clinical trial data. So you’d identify which specific files/folders have that data, and look at the different patterns of activity. A quick analysis shows that a group of researchers in Asia have been accessing those folders, but at non-working hours in their local geography. That raises an alarm and causes you to investigate. It turns out that one of the researchers collaborates with another team in Europe, and thus has been working non-standard hours, resulting in the anomalous data access. In this case it’s legitimate, but this approach both alerts you to potential misuse, and also sends the message that the security team looks for this kind of activity as a bit of a deterrent.

If you use an off the shelf product much of this may be defined for you as starting points. Clusters of user activity based on groups, social graphs, hours and locations, and similar pattern feeds tend to be useful in a wide range of behavioral analytics use cases. You will likely still want to tune these over time to more refined use cases that reflect your own organization’s needs and patterns.

As with any analytical technique, there will be tuning required over time as things change in your environment that necessarily impact the accuracy and relevance of the analytics. So we’ll reiterate again the importance of sufficiently staffing your program to manage the alerts and ensure the thresholds walk that fine line between signal and noise.

Between the data guardrails to handle known risks and enforce authorized use policies and the data behavioral analytics to detect situations you couldn’t have predicted or malicious activity, leveraging these new approaches brings data security into the modern age.

As always, we’ll be factoring in comments and feedback on the blog series, so if you see something you don’t like or don’t agree with, let us know. We’ll be refining the content and packaging it up into a white paper, which will appear in the research library within a couple of weeks.

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.