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.

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.

As I mentioned in the (DevSec)Ops vs. Dev(SecOps) post, we’ve been traveling around to a couple of DevOpsDays conferences doing the Quick and Dirty DevSecOps talk. One of the things I tend to start with early in the talk is that like DevOps, DevSecOps is not a product. Or something you can deploy and forget. It’s a cultural change. It’s a process. It’s a journey.

Data security has long been the most challenging domain of information security, despite being the centerpiece of our entire practice. We only call it “data security” because “information security” was already taken. Data security must not impede use of the data itself. By contrast it’s easy to protect archival data (encrypt it and lock the keys up in a safe). But protecting unstructured data in active use by our organizations? Not so easy. That’s why we started this research by focusing on insider risks, including external attackers leveraging insider access. Recognizing someone performing an authorized action, but with malicious intent, is a nuance lost on most security tools.

How Data Guardrails and Data Behavioral Analytics are Different

Both data guardrails and data behavioral analytics strive to improve data security by combining content knowledge (classification) with context and usage. Data guardrails leverage this knowledge in deterministic models and processes to minimize the friction of security while still improving defenses. For example, if a user attempts to make a file in a sensitive repository public, a guardrail could require them to record a justification and then send a notification to Security to approve the request. Guardrails are rule sets that keep users “within the lines” of authorized activity, based on what they are doing.

Data behavioral analytics extends the analysis to include current and historical activity, and uses tools such as artificial intelligence/machine learning and social graphs to identify unusual patterns which bypass other data security controls. Analytics reduces these gaps by looking not only at content and simple context (as DLP might), but also adding in history of how that data, and data like it, has been used within the current context. A simple example is a user accessing an unusual volume of data in a short period, which could indicate malicious intent or a compromised account. A more complicated situation would identify sensitive intellectual property on an accounting team device, even though they do not need to collaborate with the engineering team. This higher order decision making requires an understanding of data usage and connections within your environment.

Central to these concepts is the reality of distributed data actively used widely by many employees. Security can’t effectively lock everything down with strict rules covering every use case without fundamentally breaking business processes. But with integrated views of data and its intersection with users, we can build data guardrails and informed data behavioral analytical models, to identify and reduce misuse without negatively impacting legitimate activity. Data guardrails enforce predictable rules aligned with authorized business processes, while data behavioral analytics look for edge cases and less predictable anomalies.

How Data Guardrails and Data Behavioral Analytics Work

The easiest way to understand the difference between data guardrails and data behavioral analytics is that guardrails rely on pre-built deterministic rules (which can be as simple as “if this then that”), while analytics rely on AI, machine learning, and other heuristic technologies which look at patterns and deviations.

To be effective both rely on the following foundational capabilities:

A centralized view of data. Both approaches assume a broad understanding of data and usage – without a central view you can’t build the rules or models.

Access to data context. Context includes multiple characteristics including location, size, data type (if available), tags, who has access, who created the data, and all available metadata.

The ability to monitor activity and enforce rules. Guardrails, by nature, are preventative controls which require enforcement capabilities. Data behavioral analytics can be used only for detection, but are far more effective at preventing data loss if they can block actions.

The two technologies then work differently while reinforcing each other:

Data guardrails are sets of rules which look for specific deviations from policy, then take action to restore compliance. To expand our earlier example:

A user shares a file located in cloud storage publicly. Let’s assume the user has the proper privileges to make files public. The file is in a cloud service so we also assume centralized monitoring/visibility, as well as the capability to enforce rules on that file.

The file is located in an engineering team’s repository (directory) for new plans and projects. Even without tagging, this location alone indicates a potentially sensitive file.

The system sees the request to make the file public, but because of the context (location or tag), it prompts the user to enter a justification to allow the action, which gets logged for the security team to review. Alternatively, the guardrail could require approval from a manager before allowing the action.

Guardrails are not blockers because the user can still share the file. Prompting for user justification both prevents mistakes and loops in security review for accountability, allowing the business to move fast while minimizing risk. You could also look for large file movements based on pre-determined thresholds. A guardrail would only kick in if the policy thresholds are violated, and then use enforcement actions aligned with business processes (such as approvals and notifications) rather than simply blocking activity and calling in the security goons.

Data behavioral analytics use historical information and activity (typically with training sets of known-good and known-bad activity), which produce artificial intelligence models to identify anomalies. We don’t want to be too narrow in our description, because there are a wide variety of approaches to building models.

Historical activity, ongoing monitoring, and ongoing modeling are all essential – no matter the mathematical details.

By definition we focus on the behavior of data as the core of these models, rather than user activity; this represents a subtle but critical distinction from User Behavioral Analytics (UBA). UBA tracks activity on a per-user basis. Data behavioral analytics (the acronym DBA is already taken, so we’ll skip making up a new TLA), instead looks at activity at the source of the data. How has that data been used? By which user populations? What types of activity happen using the data? When? We don’t ignore user activity, but we track usage of data.

For example we could ask, “Has a file of this type ever been made public by a user in this group?” UBA would ask “Has this particular user ever made a file public?” Focusing on the data offers a chance potential to catch a broader range of data usage anomalies.

At risk fo stating the obvious, the better the data, the better the model. As with most security-related data science, don’t assume more data inevitably produces better models. It’s about the quality of the data. For example social graphs of communication patterns among users could be a valuable feed to detect situations like files moving between teams who do not usually collaborate. That’s worth a look, even if you wouldn’t want to block the activity outright.

Data guardrails handle known risks, and are especially effective at reducing user error and identifying account abuse resulting from tricking authorized users into unauthorized actions. Guardrails may even help reduce account takeovers, because attackers cannot misuse data if their action violate a guardrail. Data behavioral analytics then supplements guardrails for unpredictable situations and those where a bad actor tries to circumvent guardrails, including malicious misuse and account takeovers.

Now you have a better understanding of the requirements and capabilities of data guardrails and data behavioral analytics. Our next post will focus on some quick wins to justify including these capabilities in your data security strategy.

As we begin our series on Multi-cloud logging, we start with reasons some traditional logging approaches don’t work. I don’t like to start with a negative tone, but we need to point out some challenges and pitfalls which often beset firms on first migration to cloud. That, and it helps frame our other recommendations later in this series. Let’s take a look at some common issues by category.

Tooling

Scale & Performance: Most log management and SIEM platforms were designed and first sold before anyone had heard of clouds, Kafka, or containers. They were architected for ‘hub-and-spoke’ deployments on flat networks, when ‘Scalability’ meant running on a bigger server. This is important because the infrastructure we now monitor is agile – designed to auto-scale up when we need processing power, and back down to reduce costs. The ability to scale up, down, and out is essential to the cloud, but often missing from older logging products which require manual setup, lacking full API enablement and auto-scale capability.

Data Sources: We mentioned in our introduction that some common network log sources are unavailable in the cloud. Contrawise, as automation and orchestration of cloud resources are via API calls, API logs become an important source. Data formats for these new log sources may change, as do the indicators used to group events or users within logs. For example servers in auto-scale groups may share a common IP address. But functions and other ‘serverless’ infrastructure are ephemeral, making it impossible to differentiate one instance from the next this way. So your tools need to ingest new types of logs, faster, and change their threat detection methods by source.

Identity: Understanding who did what requires understandings identity. An identity may be a person, service, or device. Regardless, the need to map it, and perhaps correlate it across sources, becomes even more important in hybrid and multi-cloud environments

Volume: When SIEM first began making the rounds, there were only so many security tools and they were pumping out only so many logs. Between new security niches and new regulations, the array of log sources sending unprecedented amounts of logs to collect and analyze grows every year. Moving from traditional AV to EPP, for example, brings with it a huge log volume increase. Add in EDR logs and you’re really into some serious volumes. On the server side, moving from network and server logs to add application layer and container logs brings a non-trivial increase in volume. There are only so many tools designed to handle modern event rates (X billio events per day) and volumes (Y terabytes per day) without buckling under the load, and more importantly, there are only so many people who know how to deploy and operate them in production. While storage is plentiful and cheap in the cloud, you still need to get those logs to the desired storage from various on-premise and cloud sources – perhaps across IaaS, PaaS, and SaaS. If you think that’s easy call your SaaS vendor and ask how to export all your logs from their cloud into your preferred log store (S3/ADLS/GCS/etc.). That old saw from Silicon Valley, “But does it scale?” is funny but really applies in some cases.

Bandwidth: While we’re on the topic of ridiculous volumes, let’s discuss bandwidth. Network bandwidth and transport layer security between on-premise and cloud and inter-cloud is non-trivial. There are financial costs, as well as engineering and operational considerations. If you don’t believe me ask your AWS or Azure sales person how to move, say, 10 terabytes a day between those two. In some cases architecture only allows a certain amount of bandwidth for log movement and transport, so consider this when planning migrations and add-ons.

Structure

Multi-account Multi-cloud Architectures: Cloud security facilitates things like micro-segmentation, multi-account strategies, closing down all unnecessary network access, and even running different workloads in different cloud environments. This sort of segmentation makes it much more difficult for attackers to pivot if they gain a foothold. It also means you will need to consider which cloud native logs are available, what you need to supplement with other tooling, and how you will stitch all these sources together. Expecting to dump all your events into a syslog style service and let it percolate back on-premise is unrealistic. You need new architectures for log capture, filtering, and analysis. Storage is the easy part.

Monitoring “up the Stack”: As cloud providers manage infrastructure, and possibly applications as well, your threat detection focus must shift from networks to applications. This is both because you lack visibility into network operations, but also because cloud network deployments are generally more secure, prompting attackers to shift focus. Even if you’re used to monitoring the app layer from a security perspective, for example with a big WAF in front of your on-premise servers, do you know whether you vendor has a viable cloud offering? If you’re lucky enough to have one that works in both places, and you can deploy in cloud as well, answer this (before you initiate the project): Where will those logs go, and how will you get them there?

Storage vs. Ingestion: Data storage in cloud services, especially object storage, is so cheap it is practically free. And long-term data archival cloud services offer huge cost advantages over older on-premise solutions. In essence we are encouraged to store more. But while storage is cheap, it’s not always cheap to ingest more data into the cloud because some logging and analytics services charge based upon volume (gigabytes) and event rates (number of events) ingested into the tool/service/platform. Example are Splunk, Azure Eventhubs, AWS Kinesis, and Google Stackdriver. Many log sources for the cloud are verbose – both number of events and amount of data generated from each. So you will need to architect your solution to be economically efficient, as well as negotiate with your vendors over ingestion of noisy sources such as DNS and proxies, for example.
A brief side note on ‘closed’ logging pipelines: Some vendors want to own your logging pipeline on top of your analytics toolset. This may sound convenient because it “just works” (mostly for their business model), but beware lock-in, both in terms of cost overruns from lack of ability to deduplicate or filter pre-ingestion (the meter catches every event), but also from the opportunity cost of lost analytical capabilities other tools could provide, but not if you can’t feed them a copy of your log stream. The fact that you can afford to move a bunch of logs from place to place doesn’t mean it’s easy. Some logging architectures are not conducive to sending logs to more than one place at a time, and once you are in their system, exporting all logs (not just alerts) to another analytical tool can be incredibly difficult and resource intensive, because events can be ‘cooked’ into their own proprietary format, which you then have to reverse during export to make sense for other analytical tools.

Process

What to Filter and When: Compliance, regulatory, and contractual commitments prompt organizations to log everything and store it all forever (OK, not quite, but just about). And not just in production, but pre-production, development, and test systems. Combine that with overly chatty cloud logging systems (What do you plan to do with logs of every single API call into and inside your entire cloud?), and you are quickly overloaded. This results in both slower processing and higher costs. Dealing with this problem combines deciding what must be kept vs. filtered; what needs to be analyzed vs. captured for posterity; what is relevant today for security analysis and model building, vs. irrelevant tomorrow. One of the decision points you’ll want to address earlier is what you data consider perishable/real-time vs. historical/latency-tolerant.

Speed: For several years there has been a movement away from batch processing, and moving to real-time analysis (footnote: batch can be very slow [days] or very fast [micro-batching within 1-2 second windows], so we use ‘batch’ to mean anything not real-time, more like daily or less frequent). Batch mode, as well as normalization and storage prior to analysis, is becoming antiquated. The use of stream processing infrastructure, machine learning, and “stateless security” enable and even facilitate analysis of events as they are received. Changing the process to analyze in real time is needed to keep pace with attackers and fully automated attacks.

Automated Response: Many large corporations and government agencies suffered tremendously in 2017 from fast-spreading ‘ransomworms’ (also called ‘nukeware’) such as Wannacry/NotPetya in 2017. Response models tuned for stealthy low-and-slow IP and PII exfiltration attacks need revisiting. Once fast-movers execute you cannot detect your way past the grenades they leave in your datacenter. They are very obvious and very loud. The good news is that the cloud model inherently enables micro-segmentation and automated response. The cloud also doesn’t rely on ancient identity and network protocols which enable lateral movement, and continue to plague even the best on-premise security shops. Don’t forget that bad practices in the cloud won’t save you from even untargeted shenanigans. Remember the MongoDB massacre of January 2017? Fast response to things that look wrong is key to dropping the net on the bad guys as they try to pwn you. Knowing exactly what you have, its known-good state, and how to leverage new cloud capabilities, are all advantages the blue team needs to leverage.

Again, our point is not to bash older products, but to point out that cloud environments demand you re-think how you use tools and revisit your deployment models. Most can work with re-engineered deployment. We generally prefer to deploy known technologies when appropriate, which helps reduce the skills gap facing most security and IT teams. But in some cases you will find new and different ways to supplement existing logging infrastructure, and likely run multiple analysis capabilities in parallel.

Catch me at a conference and the odds are you will overhear my saying “cloud security starts with architecture and ends with automation.” I quickly follow with how important it is to adopt a cloud native mindset, even when you’re bogged down with the realities of an ugly lift and shift before the data center contract ends and you turn the lights off. While that’s a nice quip, it doesn’t really capture anything about how I went from a meat and potatoes (firewall and patch management) kind of security pro to an architecture and automation and automation cloud native. Rather than preaching from the mount, I find it more useful to describe my personal journey and my technical realizations along the way. If you’re a security pro, or someone trying to up-skill a security pro for cloud, odds are you will end up on a very similar path.

I have concluded that nobody is using Database Activity Monitoring (DAM) in public Infrastructure or Platform as a Service. I never see it in any of the cloud migrations we assist with. Clients don’t ask about how to deploy it or if they need to close this gap. I do not hear stories, good or bad, about its usage. Not that DAM cannot be used in the cloud, but it is not.

There are certainly some reasons firms invest security time and resources elsewhere. What comes to mind are the following:

PaaS and use of Relational: There are a couple trends which I think come into play. First, while user installed and managed relational databases do happen, there is a definite trend towards adopting RDBMS as a Service. If customers do install their own relational platform, it’s MySQL or MariaDB, for which (so far as I know) there are few monitoring options. Second, for most new software projects, a relational database is a much less likely choice to back applications – more often it’s a NoSQL platform like Mongo (self-managed) or something like Dynamo. This has reduced the total relational footprint.

CI:CD: Automated build and security test pipelines – we see a lot more application and database security testing in development and quality assurance phases, prior to production deployment. Many potential code vulnerabilities and common SQL injection attacks are being spotted and addressed prior to applications being deployed. And there may not be a lot of reconfiguration in production if your installation is defined in software.

Network Security: Between segmentation, firewalls/security groups, and port management you can really lock down the (virtual) network so only the application can talk to the database. Difficult for anyone to end-run around if properly set up.

Database Ownership: Some people cling to the misconception that the database is owned and operated by the cloud provider, so they will take care of database security. Yes, the vendor handles lots of configuration security and patching for you. Certainly much of the value of a DAM platform, namely security assessment and detection of old database versions, is handled elsewhere.

Permission misuse is harder. Most IaaS clouds offer dynamic policy-driven IAM. You can set very fine-grained access controls on database access, so you can block many types of ad hoc and potentially malicious queries.

Maybe none of these reasons? Maybe all the above? I don’t really know. Regardless, DAM has not moved to the cloud. The lack of interest does not provide any real insights as to why, but it is very clear.

I do still want some of DAM’s monitoring functions for cloud migrations, specifically looking for SQL injection attacks – which are still your issue to deal with – as well as looking for credential misuse, such as detecting too much data transfer or scraping. Cloud providers log API access to the database installation, and there are cloud-native ways to perform assessment. But on the monitoring side there are few other options for watching SQL queries.

In Quick and Dirty: Building an S3 guardrail with Config we highlighted that one of the big problems with Config is you need to build it in all regions of all accounts separately. Now your best bet to make that manageable is to use infrastructure as code tools like CloudFormation to replicate your settings across environments. We have a lot more to say on scaling out baseline security and operations settings, but for this post I want to highlight how to aggregate Config into a unified dashboard.

I had been planning to post on the recent announcement of the planned merger between Hortonworks and Cloudera, as there are a number of trends I’ve been witnessing with the adoption of Hadoop clusters, and this merger reflects them in a nutshell. But catching up on my reading I ran across Mathew Lodge’s recent article in VentureBeat titled Cloudera and Hortonworks merger means Hadoop’s influence is declining. It’s a really good post. I can confirm we see the same lack of interest in deployment of Hadoop to the cloud, the same use of S3 as a storage medium when Hadoop is used atop Infrasrtucture as a Service (IaaS), and the same developer-driven selection of whatever platform is easiest to use and deploy on. All in all it’s an article I wish I’d written, as he did a great job capturing most of the areas I wanted to cover. And there are some humorous bits like “Ironically, there has been no Cloud Era for Cloudera.” Check it out – it’s worth your time.

But there are a couple other areas I still want to cover.

It is rare to see someone install Hadoop into a public IaaS account. Customers (now) choose a cloud native variant and let the vendor handle all the patching and hide much of the infrastructure pieces from them. And they gain the option of spinning down the cluster when not in use, making it much more efficient. Couple that with all the work to set up Hadoop yourself, and it’s an easy decision. I was somewhat surprised to learn that things like AWS’s Elastic Map Reduce (EMR) are not always chosen as repository, but Dynamo is surprisingly popular – which makes sense, given its powerful query features, indexing, and ability to offer the best of relational and big data capabilities. Most public IaaS vendors offer so many database variants that it is easy to mix and match multiple variants to support applications, further reducing demand for classic Hadoop installations.

One area continuing to drive Hadoop adoption is on-premise data collection and data lakes for logs. The most cited driver is the need to keep Splunk costs under control. It takes effort to divert some content to Hadoop instead of sending everything to the Splunk collectors – but data can be collected and held at drastically lower cost. And you need not sacrifice analytics. For organizations collecting every log entry, this is a win. We also see Hadoop adopted by Security Operations Centers, running side by side with other platforms. Part of the need is to fill gaps around what their SIEM keeps, part is to keep costs down, and part is to easily support deployment of custom security intelligence applications by non-developers.

Another aspect not covered in any of the articles I have found so far is that Cloudera and Hortonworks both have deep catalogs of security capabilities. Together they are dominant. As firms use large “data lakes” to hold all sorts of sensitive data inside Hadoop, this will be a win for firms running Hadoop in-house. Identity management, encryption, monitoring, and a whole bunch of other great stuff. Big data is not the security issue it was 5 years ago. Hortonworks and Cloudera have a lot to do with that; their combined capabilities and enterprise deployment experience make them a powerful choice to help firms manage and maintain existing infrastructure. That is all my way of saving that some of their negative press is unwarranted, given the profitable avenues ahead.

The idea that growth in the Hadoop segment appears to have been slowing is not new. AWS has been the largest seller of Hadoop-based data platforms, by revenue and by customer, for several years. The cloud is genuinely an existential threat to all the commercial Hadoop vendors – and comparable big data databases – if they continue to sell in the same way. The recent acceleration of cloud adoption simply makes it more apparent that Cloudera and Hortonworks are competing for a shrinking share of IT budgets. But it makes sense to band together and make the most of their expertise in enterprise Hadoop deployments, and should help with tooling and management software for cloud migrations. If Kubernetes is any indication, there are huge areas for improvement in tooling and services beyond what cloud vendors provide.

Logging and monitoring for cloud infrastructure has become the top topic we are asked about lately. Even general conversations about moving applications to the cloud always seem to end with clients asking how to ‘do’ logging and monitoring of cloud infrastructure. Logs are key to security and compliance, and moving into cloud services – where you do not actually control the infrastructure – makes logs even more important for operations, risk, and security teams. But these questions make perfect sense – logging in and across cloud infrastructure is complicated, offering technical challenges and huge potential cost overruns if implemented poorly.

The road to cloud is littered with the charred remains of many who have attempted to create multi-cloud logging for their respective employers. But cloud services are very different – structurally and operationally – than on-premise systems. The data is different; you do not necessarily have the same event sources, and the data is often different or incomplete, so existing reports and analytics may not work the same. Cloud services are ephemeral so you can’t count on a server “being there” when you go looking for it, and IP addresses are unreliable identifiers. Networks may appear to behave the same, but they are software defined, so you cannot tap into them the same way as on-premise, nor make sense of the packets even if you could. How you detect and respond to attacks differs, leveraging automation to be as agile as your infrastructure. Some logs capture every API call; while their granularity of information is great, the volume of information is substantial. And finally, the skills gap of people who understand cloud is absent at many companies, so they ‘lift and shift’ what they do today into their cloud service, and are then forced to refactor the deployment in the future.

One aspect that surprised all of us here at Securosis is the adoption of multi-cloud; we do not simply mean some Software as a Service (SaaS) along with a single Infrastructure as a Service (IaaS) provider – instead firms are choosing multiple IaaS vendors and deploying different applications to each. Sometimes this is a “best of breed” approach, but far more often the selection of multiple vendors is driven by fear of getting locked in with a single vendor. This makes logging and monitoring even more difficult, as collection across IaaS providers and on-premise all vary in capabilities, events, and integration points.

Further complicating the matter is the fact that existing Security Information and Event Management (SIEM) vendors, as well as some security analytics vendors, are behind the cloud adoption curve. Some because their cloud deployment models are no different than what they offer for on-premise, making integration with cloud services awkward. Some because their solutions rely on traditional network approaches which don’t work with software defined networks. Still others employ pricing models which, when hooked into highly verbose cloud log sources, cost customers small fortunes. We will demonstrate some of these pricing models later in this paper.

Here are some common questions:

What data or logs do I need? Server/network/container/app/API/storage/etc.?

How do I get them turned on? How do I move them off the sources?

How do I get data back to my SIEM? Can my existing SIEM handle these logs, in terms of both different schema and volume & rate?

Should I use log aggregators and send everything back to my analytics platform? At what point during my transition to cloud does this change?

How do I capture packets and where do I put them?

These questions, and many others, are telling because they come from trying to fit cloud events into existing/on-premise tools and processes. It’s not that they are wrong, but they highlight an effort to map new data into old and familiar systems. Instead you need to rethink your logging and monitoring approach.

The questions firms should be asking include:

What should my logging architecture look like now and how should it change?

How do I handle multiple accounts across multiple providers?

What cloud native sources should I leverage?

How do I keep my costs manageable? Storage can be incredibly cheap and plentiful in the cloud, but what is the pricing model for various services which ingest and analyze the data I’m sending them?

What should I send to my existing data analytics tools? My SIEM?

How do I adjust what I monitor for cloud security?

Batch or real-time streams? Or both?

How do I adjust analytics for cloud?

You need to take a fresh look at logging and monitoring, and adapt both IT and security workflows to fit cloud services – especially if you’re transitioning to cloud from an on-premise environment and will be running a hybrid environment during the transition… which may be several years from initial project kick-off.

Today we launch a new series on Building a Multi-cloud Logging Strategy. Over the next few weeks, Gal Shpantzer and I (Adrian Lane) will dig into the following topics to discuss what we see when helping firms migrate to cloud. And there is a lot to cover.

Our tentative outline is as follows:

Barriers to Success: This post will discuss some reasons traditional approaches do not work, and areas where you might lack visibility.

Cloud Logging Architectures: We discuss anti-patterns and more productive approaches to logging. We will offer recommendations on reference architectures to help with multi-cloud, as well as centralized management.

Native Logging Features: We’ll discuss what sorts of logs you can expect to receive from the various types of cloud services, what you may not receive in a shared responsibility service, the different data sources firms have come to expect, and how to get them. We will also provide practical notes on logging in GCP, Azure, and AWS. We will help you navigate their native offerings, as well as the capabilities of PaaS/SaaS vendors.

BYO Logging: Where and how to fill gaps with third-party tools, or building them into applications and service you deploy in the cloud.

Cloud or On-premise Management? We will discuss tradeoffs between moving log management into the cloud, keeping these activities on-premise, and using a hybrid model. This includes risks and benefits of connecting cloud workloads to on-premise networks.

Security Analytics: More and more firms are augmenting or replacing traditional SIEM with security analytics, data lakes, and ML/AI; so we will discuss some of these approaches along with various data sources for threat detection, compliance, and governance. This is the goal behind 1-5 above: facilitating the ability to collect, transform, and store – to gain real-time and historical insight.

As always, questions, comments, disagreements, and other constructive input are encouraged.

In How S3 Buckets Become Public, and the Fastest Way to Find Yours we reviewed the myriad ways S3 buckets become public and where to look for them. Today I’ll show the easiest way to continuously monitor for public buckets using AWS Config. The good news is this is pretty easy to set up; the bad news is you need to configure it separately in every region in every account.

After over 25 years of the modern IT security industry, breaches still happen at an alarming rate. Yes, that’s fairly obvious but still disappointing, given the billions spent every year in efforts to remedy the situation. Over the past decade the mainstays of security controls have undergone the next generation treatment – initially firewalls and more recently endpoint security. New analytical techniques have been mustered to examine infrastructure logs in more sophisticated fashion.

But the industry seems to keep missing the point. The objective of nearly every hacking campaign is (still) to steal data. So why focus on better infrastructure security controls and better analytics of said infrastructure? Mostly because data security is hard. The harder the task, the less likely overwhelmed organizations will have the fortitude to make necessary changes.

To be clear, we totally understand the need to live to fight another day. That’s the security person’s ethos, as it must be. There are devices to clean up, incidents to respond to, reports to write, and new architectures to figure out. The idea of tackling something nebulous like data security, with no obvious solution, can remain a bridge too far.

Or is it? The time has come to revisit data security, and to utilize many of the new techniques pioneered for infrastructure to address the insider threat where it appears: attacking data. So our new series, Protecting What Matters: Introducing Data Guardrails and Behavioral Analytics, will introduce some new practices and highlight new approaches to protecting data.

Before we get started, let’s send a shout-out to Box for agreeing to license this content when we finish up this series. Without clients like Box, who understand the need for forward-looking research to tell you where things are going, not reports telling you where they’ve been, we wouldn’t be able to produce research like this.

Understanding Insider Risk

While security professionals like to throw around the term “insider threat”, it’s often nebulously defined. In reality it includes multiple categories, including external threats which leverage insider access. We believe to truly address a risk you first need to understand it (call us crazy). To break down the first level of the insider threat, let’s consider its typical risk categories:

Accidental Misuse: In this scenario the insider doesn’t do anything malicious, but makes a mistake which results in data loss. For example a customer service rep could respond to an email sent by a customer which includes private account info. It’s not like the rep is trying to violate policy, but they didn’t take the time to look at the message and clear out any private data.

Tricked into Unwanted Actions: Employees are human, and can be duped into doing the wrong thing. Phishing is a great example. Or providing access to a folder based on a call from someone impersonating an employee. Again, this isn’t malicious, but it can still cause a breach.

Malicious Misuse: Sometimes you need to deal with the reality of a malicious insider intentionally stealing data. In the first two categories the person isn’t trying to mask their behavior. In this scenario they are deliberately obfuscating, which that means you need different tactics to detect and prevent the activity.

Account Takeover: This category reflects the fact that once an external adversary has presence on a device, they become an ‘insider’; with a compromised device and account, they have access to critical data.

We need to consider these categories in the context of adversaries so you can properly align your security architecture. So who are the main adversaries trying to access your stuff? Some coarse-grained categories follows: unsophisticated (using widely available tools), organized crime, competitors, state-sponsored, and finally actual insiders. Once you have figured out your most likely adversary and their typical tactics, you can design a set of controls to effectively protect your data.

For example an organized crime faction looks to access data related to banking or personal information for identity theft. But a competitor is more likely looking for product plans or pricing strategies. You can (and should) design your data protection strategy with these likely adversaries in mind, to help prioritize what to protect and how.

Now that you understand your adversaries and can infer their primary tactics, you have a better understanding of their mission. Then you can select a data security architecture to minimize risk, and optimally prevent any data loss. But that requires us to use different tactics than would normally be considered data security.

A New Way to Look at Data Security

If you surveyed security professionals and asked what data security means to them, they’d likely say either encryption or Data Loss Prevention (DLP). When all you have is a hammer, everything looks like a nail, and for a long time those two have been the hammers available to us. Of course the fact that we want to expand our perspective a bit doesn’t mean DLP and encryption no longer have any roles to play in data protection. Of course they do. But we can supplement them with some new tactics.

Data Guardrails: We have defined Guardrails as a means to enforce best practices without slowing down or impacting typical operations. Typically used within the context of cloud security (like, er, DisruptOps), a data guardrail enables data to be used in certain ways while blocking unauthorized usage. To bust out an old network security term, you can think of guardrails as like “default-deny” for data. You define the set of acceptable practices, and don’t allow anything else.

Data Behavioral Analytics: Many of you have heard of UBA (User Behavioral Analytics), where all user activity is profiled, and you then look for anomalous activities which could indicate one of the insider risk categories above. What if you turned UBA inside-out and focused on the data? Using similar analytics you could profile the usage of all the data in your environment, and then look for abnormal patterns which warrant investigation. We’ll call this DataBA because your database administrators might be a little peeved if we horned in on their job title.

Our next post will dig farther into these new concepts of Data Guardrails and DataBA, to illuminate both the approaches and their pitfalls.

In What Security Managers Need to Know About Amazon S3 Exposures we mentioned that one of the reasons finding public S3 buckets is so darn difficult is because there are multiple, overlapping mechanisms in place that determine the ultimate amount of S3 access. To be honest, there’s a chance I don’t even know all the edge cases but this list should cover the vast majority of situations.

If you see me speaking about cloud it’s pretty much guaranteed I’ll eventually say:

Cloud security starts with architecture and ends with automation.

I’m nothing if not repetitive. This isn’t just a quip, it’s based on working heavily in cloud for nearly a decade with organizations of all size. The one consistency I see over and over is that once organizations hit a certain scale they start automating their operations. And every year that line is earlier and earlier in their cloud journey.

I know it because first I lived it, then I watched every single organization I worked with, talked with, or generally glanced at, go down the same path.

I just got back from the Boston DevOps Days. I really enjoy hanging around DevOps and cloud people. The energy of these conferences is great, and they are genuinely excited about transforming how their organizations build and deploy applications. Many don’t have a negative perception of security folks, but they don’t really understand what security folks do either.

Our first Disrupt:Ops post discussed how exposure of S3 data becomes such a problem, with some details on how buckets become public in the first place. This post goes a bit deeper, before laying a foundation for how to manage S3 to avoid these mistakes yourself.

As we spin up Disrupt:OPS we are beginning to post cloud-specific content over there, mixing theory with practical how-to guidance. Not to worry! We have plenty of content still planned for Securosis. But we haven’t added any staff at Securosis so there is only so much we can write. In the meantime, linking to non-product posts from Securosis should help ensure you don’t lose sleep over missing even a single cloud-related blog entry.

The accidental (or deliberate) exposure of sensitive data on Amazon S3 is one of those deceptively complex issues. On the surface it seems entirely simple to avoid, yet despite wide awareness we see a constant stream of public exposures and embarrassments, combined with a healthy dollop of misunderstanding and victim blaming.

Did China manage to hardware hack the Apple and Amazon data centers? Or did Bloomberg get it wrong? And what the heck can you do about it anyway? This week we start with a discussion of today’s blockbuster security news, before shifting gears back to cloud. It turns out most organizations are having to lift and shift to cloud, even when that is not ideal. We talk about some of your options, even in the face of ridiculous management timelines.

Our last post explained Continuous Contextual Content as a means to optimize the effectiveness of a security awareness program. CCC acknowledges that users won’t get it, at least not initially. That means you need to reiterate your lessons over and over (and probably over) again. But when should you do that? Optimally when their receptivity is high – when they just made a mistake.

So you determine the relative risk of users, and watch for specific actions or alerts. When you see such behavior, deliver the training within the context of what they see then. But that’s not enough. You want to track the effectiveness of your training (and your security program) to get a sense of what works and what doesn’t. If you can’t close the loop on effectiveness, you have no idea whether your efforts are working, or how to continue improving your program.

To solidify the concepts, let’s go through a scenario which works through the process step by step. Let’s say you work for a large enterprise in the financial industry. Senior management increasingly worries about ransomware and data leakage. A recent penetration test showed that your general security controls are effective, but in their phishing simulation over half your employees clicked a fairly obvious phish. And it’s a good thing your CIO has a good sense of humor, because the pen tester gained full access to his machine via a well crafted drive-by attack which would have worked against the entire senior team.

So your mission, should you choose to accept it, is to implement security awareness training for the company. Let’s go!

Start with Urgency

As mentioned, your company has a well-established security program. So you can hit the ground running, using your existing baseline security data. Next identify the most significant risks and triage immediate action to start addressing them. Acting with urgency serves two purposes. It can give you a quick win, and we all know how important it is to show value immediately. As a secondary benefit you can start to work on training employees on a critical issue right away.

Your pen test showed that phishing poses the worst problems for your organization, so that’s where you should focus initial efforts. Given the high-level support for the program, you cajole your CEO into recording a video discussing the results of the phishing test and the importance of fixing the issue. A message like this helps everyone understand the urgency of addressing the problem and that the CEO will be watching.

Following that, every employee completes a series of five 3-5 minute training videos walking them through the basics of email security, with a required test at the end. Of course it’s hard to get 100% participation in anything, so you’ve already established consequences for those who choose not to complete the requirement. And the security team is available to help people who have a hard time passing.

It’s a balance between being overly heavy-handed against the importance of training users to defend themselves. You need to ensure employees know about the ongoing testing program, and that they’ll be testing periodically. That’s the continuous part of the approach – it’s not a one-time thing.

Introduce Contextual Training

As you execute on your initial phishing training effort, you also start to integrate your security awareness training platform with existing email, web, and DNS security services. This integration involves receiving an alert when an employee clicks a phishing message, automatically signing them up for training, and delivering a short (2-3 minute) refresher on email security. Of course contextual training requires flexibility, because an employee might be in the middle of a critical task. But you can establish an expectation that a vulnerable employee needs to complete training that day.

Similarly, if an employee navigates to a known malicious site, the web security service sends a trigger, and the web security refresher runs for that employee. The key is to make sure the interruption is both contextual and quick. The employee did this, so they need training immediately. Even a short delay will reduce the training’s effectiveness.

Additionally, you’ll be running ongoing training and simulations with employees. You’ll perform some analysis to pinpoint the employees who can’t seem to stop clicking things. These employees can get more intensive training, and escalation if they continue to violate corporate policies and put data at risk.

Overhaul Onboarding

After initial triage and integration with your security controls, you’ll work with HR to overhaul the training delivered during their onboarding process. You are now training employees continuously, so you don’t need to spend 3 hours teaching them about phishing and the hazards of clicking links.

Then onboarding can shift, to focus on establishing a culture of security from Day 1. This entails educating new employees on online and technology policies, and acceptable use expectations. You also have an opportunity to set expectations for security awareness training. Make clear that employees will be tested on an ongoing basis, and inform them who sees the results (their managers, etc.), along with the consequences of violating acceptable use policies.

Again, a fine line exists between being draconian and setting clear expectations. If the consequences have teeth (as they should), employees must know, and sign off on their understanding. We also recommend you test each new employee within a month of their start date to ensure they comprehend security expectations and retained their initial lessons.

Start a Competition

Once your program settles in over six months or so, it’s time to shake things up again. You can set up a competition, inviting the company to compete for the Chairperson’s Security Prize. Yes, you need to get the Chairperson on board for this, but that’s usually pretty easy because it helps the company. The prize needs to be impactful, and more than bragging rights. Maybe you can offer the winning department an extra day of holiday for the year. And a huge trophy. Teams love to compete for trophies they can display prominently in their area.

You’ll set the ground rules, including an internal red team and hunting team attacking each group. You’ll be tracking how many employees fall for the attacks and how many report the issues. Your teams can try physically breaching the facilities as well. You want the attacks to dovetail with ongoing security training and testing initiatives to reinforce security culture.

Run Another Simulation

You’ll also want to stage a widespread simulation a few months after the initial foray. Yes, you’ll be continuously testing employees as part of your continuous program. But getting a sense of company-wide results is also helpful. You should compare results from the initial test against the new results. Are fewer employees falling for the ruse? Are more reporting spammy and phishing emails to the central group? Ensuring the trend lines are moving in the right direction boosts the program and helps justify ongoing investment. You feed the results into the team scoring of the competition.

Lather, Rinse, Repeat

At some point, when another high-profile issue presents itself, you should take a similar approach. Let’s say your organization does a lot of business in Europe, so GDPR presents significant risk. You’ll want to train employees on how you define customer data and how to handle it.

Next determine whether you need special training for this issue, or whether you can integrate it into your more extensive bi-annual training for all employees. Every six months all employees sit for perhaps an hour, watching an update on both new hacker tactics and changes to corporate security policies.

Once that round of training completes, you will roll out new tests to highlight how customer data could be lost or stolen. Factor the new tests into your next competition as well, to keep focus on the changing nature of security and the ongoing contest.

Sustaining Impact

Once your program is humming along, we suggest you pick a new high priority topic every six months to make that the focus of your semi-annual scheduled training. As part of addressing this new topic, you’ll integrate with the relevant controls to enable ongoing contextual training and perform an initial test (to establish a baseline), and then track improvement over time.

You’ll also want a more comprehensive set of reports to track the effectiveness of your awareness training; deliver this information to senior management, and perhaps the audit committee. Maybe each quarter you’ll report on how much contextual training employees received, and how much or little they repeated mistakes after training. You’ll also want to report on the overall number of successful attacks, alongside trends of which attacks worked and which got blocked. Being able to map those results back to training topics makes an excellent case for ongoing investment.

At some point the competition will end and you’ll crown the winner. We suggest making a big deal of the winning team. Maybe you can record the award ceremony with the chairperson and memorialize their victory in the company newsletter. You want to make sure all employees understand security is essential and visible at the highest echelons of your organization.

It’s a journey, not a destination, so ensure consistency in your program. Add new focus topics to extend your employee knowledge, keep your content current and interesting, and hold your employees to a high standard – make sure they understand expectations and the consequences of violating corporate policies. Building a security culture requires patience, persistence, and accountability. Anchoring your security awareness training program with continuous, contextual content will go a long way to establishing such a security culture.

With that we wrap up this series on Making an Impact with Security Awareness Training. Thanks again to Mimecast for licensing this content, and we’ll have the assembled and edited paper available in our Research Library within a couple weeks.

As we discussed in the first post of our Making an Impact with Security Awareness Training series, organizations need to architect training programs around a clear definition of success, both to determine the most appropriate content to deliver, and also to manage management expectations. The definition of success for any security initiative is measurable risk reduction, and that applies just as much to security awareness training.

We also covered the limitations of existing training approaches – including weak generic content, and a lack of instrumentation & integration, to determine the extent of risk reduction. To overcome these limitations we introduced the concept of Continuous, Contextual Content (3C) as the cornerstone of the kind of training program which can achieve security initiatives.

We described 3C as:

“It’s giving employees the necessary training, understanding they won’t retain everything. Not the first time anyway. Learning requires repetition, but why repeat training to someone that already gets it? That’s a waste of time. Thus to follow up and focus on retention, you want to deliver appropriate content to the employee when they need it. That means refreshing the employee about phishing, not at a random time, but after they’ve clicked on a phishing message.”

Now we can dig in to understand how to move your training program toward 3C.

Start with Users

Any focus on risk reduction requires first identifying employees who present the most risk to the organization. Don’t overcomplicate your categorization process, or you won’t be able to keep it current. We suggest 4-6 groups categorized by their access to critical information.

Senior Management: These individuals have the proverbial keys to the kingdom, so they tend to be targeted by whaling and other adversary campaigns. They also tend to resist extensive training given their other responsibilities. That said, if you cannot get senior management to lead by example and receive extensive training, you have a low likelihood of success with the program overall.

Finance: This team has almost the same risk profile as senior management. They access financial reporting systems and the flow of money. Stealing money is the objective of many campaigns, so these folks need a bit more love to prepare for the inevitable attacks.

HR and Customer Service: Attackers target Human Resources and Customer Service frequently as well, mostly because they provide the easiest path into the organization; attackers then continue toward their ultimate goal. Interacting with the outside world makes up a significant part these groups’ job functions, so they need to be well-versed in email attacks and safe web browsing.

Everyone else: We could define another dozen categories, but that would quickly pass the point of diminishing returns. The key for this group is to ensure that everyone has a baseline understanding of security, which they can apply when they see attacks.

Once you have defined your categories you design a curriculum for each group. There will be a base level of knowledge, for the everyone else group. Then you extend the more advanced curricula to address the most significant risks to each specific group, by building a quick threat model and focusing training to address it. For example senior management needs a deep understanding of whaling tactics they are likely to face.

Keep in mind that the frequency of formal training varies by group. If the program calls for intensive training during on-boarding and semi-annual refreshers, you’ll want more frequent training for HR and Customer Service. Given how quickly attack tactics change, updating training for those groups every quarter seems reasonable to keep them current.

Continuous

Just as we finish saying you need to define the frequency for your different user groups, the first “C” is continuous. What gives? A security training program encompasses both formal training and ad-hoc lessons as needed. Attackers don’t seem to take days off, and the threat landscape changes almost daily. Your program needs to reflect the dynamic nature of security and implement triggers to initiate additional training.

You stay current by analyzing threat intelligence looking for significant new attacks that warrant additional training. Ransomware provides a timely example of this need. A few years ago when the first ransomware attack hit, most employees were not prepared to defend against the attack and they certainly didn’t know what to do once the ransomware locked their devices. For these new attack vectors, you may need to put together a quick video explaining the attack and what to do in the event the employee sees it. To be clear, speed matters here so don’t worry about your training video being perfect, just get something out there to prepare your employees for an imminent attack. Soon enough your security training vendor will update existing training and will introduce new material based on emerging attacks, so make sure you pay attention to available updates within the training platform.

Continuous training also involves evaluating not just potential attacks identified via threat intel but also changes in the risk profile of an employee. Keep on top of the employee’s risk profile, integrate with other security tools, including email security gateways, web security proxies and services, web/DNS security tools, DLP, and other content inspection technologies, security analytics including user behavior analytics (UBA), etc. These integrations set the stage for contextual training.

Contextual

If any of the integrated security monitors or controls detects an attack on a specific user, or determines a user did something which violates policy, it provides an opportunity to deliver ad hoc training on that particular attack. The best time to train an employee and have the knowledge stick remains when they are conscious of its relevance. People have different learning styles, and their receptivity varies, but they should be much more receptive right after making a mistake. Then their fresh experience which puts the training in context.

Similar to teaching a child not to touch a hot stove after they’ve burnt their hand, showing an employee how to detect a phishing message is more impactful right after they clicked on a phishing message. We’ll dig in with a detailed example in our next post.

To wrap up our earlier frequency discussion, you have a few different options for training delivery:

Scheduled: As described above, you provide materials during onboarding and as part of the ongoing training program. Periodic refreshers and updated training on new attacks are likely the bare minimum to meet your compliance requirements.

Preemptive: In this model you deliver training when triggered by threat intel or a change in risk profile, as determined by security analytics/UBA. The emergence of a new ransomware variant is an example of a likely trigger for preemptive training.

Reactive: This model triggers delivery of training when an employee makes a mistake. For example, train on how to protect customer data after the DLP system blocks an outgoing email with a customer’s social security number in the body.

Metrics

Assuming risk reduction is the overall objective of your security awareness training program, you need a way to assess its effectiveness. How can you measure your security training program? It starts by defining a baseline of security effectiveness. We all understand that assessing security goes well beyond training, but you need to understand your current security posture before starting a new training program.

That means tracking attacks against the organization, particularly the types of attacks most impacted by security training – including phishing, drive-by downloads, customer data leakage, etc. Obtain this information via integration with your email and web security tools and your SIEM or UBA system. If you cannot establish a baseline before the program starts, we recommend you initiate data collection immediately. It’s decidedly suboptimal, but you can trend improvement over time from the start of your program.

As far as metrics to track, you can use these buckets to get started:

Micro: Here you monitor employee-specific risk, such as how many times an employee clicks on a phishing simulation and how many times you’ve had to clean up the employee’s device after malware outbreaks.

Macro: These indicators include benchmark data from organizations of similar size and sector. You’ll want to know how many successful attacks hit your peers. Your training vendor likely has benchmark data you can use, and we increasingly see this kind of information in training dashboards and reports to provide insight into effectiveness.

Organizational: Based on micro and the macro data, how does your organization stack up? Here you’ll want to make an overall assessment of the organization, based on results from tests and other risk metrics/analytics.

Qualitative: You’ll also want to understand what employees think of your training program. We recommend organizations perform 360° evaluations via employee surveys to gauge the effectiveness of training content, and for a sense of their general understanding of security.

For each of these metrics/assessments, you should be able to access the data quickly and easily via both a dashboard and results. The dashboard should clear reflect both the micro and macro effectiveness of your efforts. Which employees need additional training because they make the same mistake over and over again? Which employees can’t seem to find the time to complete scheduled training? Are the number of bad clicks during phishing simulations trending in the right direction?

The documentation from the program will substantiate (or not) your training efforts, which will make the difference between expanding the program or sending it to the dustbin. We’ll wrap up this series in our next post, working through a detailed example of setting up the program – and, more importantly, adapting it as you learn what works and doesn’t.

Mike and Rich discuss the latest Wired piece in Notpetya and how advanced attacks, despite the hype, are very much still alive and well. These days you might be a victim not because you are targeted, but because you are a pivot to a target or share some underlying technology. As a new Apache Struts vulnerability rolls out, we thought it a good time to re-address some fundamentals and evaluate the real risks of both widespread and targeted attacks.

We have long been fans of security awareness training. As explained in our 2013 paper Security Awareness Training Evolution, employees remain the last line of defense, and in all too many cases those defenses fail. We pointed out many challenges facing security awareness programs, and have since seen modest improvement in some of those areas. But few organizations rave about their security awareness training, which means we still have work to do.

In our new series, Making an Impact with Security Awareness Training, we will put the changes of the last few years into proper context, and lay out our thoughts on how security awareness training needs to evolve to provide sustainable risk reduction.

First we need to thank our friends at Mimecast, who have agreed to potentially license the content at the end of the project. After 10 years, Securosis remains focused on producing objective research through transparent methodology. So we need security companies which understand the importance of our iterative process of posting content to the blog and letting you, our readers, poke holes in it. Sometimes our research takes unanticipated turns, and we appreciate our licensee’s willingness to allow us to write impactful research – not just stuff which covers their products.

Revisiting Security Awareness Training Evolution

Before we get going on making an impact, we need to revisit where we’re coming from. Back in 2013 we identified the challenges of security awareness training as:

Engaging students: Researchers have spent a lot of time discovering the most effective ways to structure content to teach information with the best retention. But most security awareness training materials seem to be stuck in the education dark ages, and don’t take advantage of these insights. So the first and most important issue is that training materials aren’t very good. For all training, content is king.

Unclear objectives: When training materials attempt to cover every possible attack vector they get diluted, and students retain very little of the material. Don’t try to boil the security ocean with an overly broad curriculum. Focus on specific real threats which are likely in your environment.

Incentives: Employees typically don’t have any reason to retain information past the completion of training, or to use it on a daily basis. If they click the wrong thing IT will come to clean up the mess, right? Without either positive or negative incentives, employees forget courses as soon as they finish.

Organizational headwinds: Political or organizational headwinds can sabotage your training efforts. There are countless reasons other groups within your organization might resist awareness training, but many of them come back to a lack of incentive – mostly because they don’t understand how important it is. And failure to make your case is your problem.

The industry has made minor progress in these areas, mostly in the area of engaging content. The short and entertaining content emerging from many awareness training companies does a better job of engaging employees. Compelling characters and a liberal sprinkling of humor help make their videos more impactful and less reminiscent of root canal.

But we can’t say a lot of the softer aspects, such as incentives and the politics of who controls training, have improved much. We believe improving attitudes toward security awareness training requires first defining success and getting buy-in for the program early and often. Most organizations haven’t done a great job selling their programs – instead defaulting to the typical reasons for security awareness training, such as a compliance mandate or a nebulous desire to having fewer employees click malicious links. Being clear about what success means as you design the program (or update an existing program) will pay significant dividends down the road.

Success by Design

If you want your organization to take security awareness training seriously, you need to plan for that. If you don’t know what success looks like you are unlikely to get there. To define success you need a firm understanding of why the organization needs it. Not just because it’s the right thing to do, or because your buddy found a cool vendor with hilarious content. We are talking about communicating business justification for security awareness training, and more importantly what results you expect from your organization’s investment of time and resources.

As mentioned above, many training programs are created to address a compliance requirement or a desire to control risk more effectively. Those reasons make sense, even to business people. But quantifying the desired outcomes presents challenges. We advise organizations to gather a baseline of issues to be addressed by training. How many employees click on phishing messages each week when you start? How many DLP alerts do you get indicating potential data leakage? These numbers enable you to define targets and work towards them.

We recommend caution – you need to manage expectations, avoiding assumptions of perfection. That means understanding which risks training can alleviate and which it cannot. If the attack involves clicking a link, training can help. If it’s preventing a drive-by download delivered by a compromised ad network, there’s not much employees can do.

Once you have managed expectations it’s time to figure out how to measure employee engagement. You might send out a survey to gain feedback on the content. Maybe you will set up a game where different business units can compete. Games and competition can provide effective incentives for participation. You don’t need to offer expensive prizes. Some groups put in herculean effort to win a trophy and bragging rights.

To be clear, employees might need to participate in the training to keep their jobs. Continued employment offers a powerful incentive to participate, but not necessarily to retain the material or have it impact day-to-day actions. So we need a better way to connect training to corporate results.

The True Measure: Risk Reduction

The most valuable outcome is to reduce risk, which gives security awareness training its impact on corporate results. It’s reasonable to expect awareness training to result in fewer successful attacks and less loss: risk reduction. Every other security control and investment needs to reduce risk, so why hasn’t security awareness training been held to the same standard? We don’t know either, but the time has come to start thinking about it.

What does risk reduction mean in the context of security awareness training? It’s giving employees the necessary training, while understanding they won’t retain everything. Not the first time anyway. Learning requires repetition, but why repeat training for someone who already gets it? That’s a waste of time. So to follow up and focus on retention, you want to deliver appropriate content to employee when they need it. That means refreshing employees about phishing – not after an arbitrary or random time, but after they clicked a phishing message.

Contextual training requires integration with applicable security controls. For example you need a trigger from the email security gateway when an employee clicks a dangerous link in an email. You can also get triggers when an employee navigates to a malicious site via DNS and web security gateways which track where they browse. Finally, integration with DLP offers opportunities to revisit training on protected content after making a mistake.

We’ll dig deeper into Continuous Contextual Content in our next post.

Content Remains Key

We can slice and dice it many different ways, but we can’t get around it. Without the right content any security awareness training program will fail. Here are five keys for engaging and effective awareness training content.

Behavioral modification: The training content needs to work. You should be managing to outcomes, and your desired result for security training is that employees learn what not to do (and subsequently don’t do it), so if behavior doesn’t change for a reasonable percentage of employees, that’s an indication of ineffective content.

Current: Security remains a dynamic environment; your security training curriculum must keep pace. Yes, you still need to tell employees about vintage 2015 attacks because they will still see them. But you also need to train them to defend against new attack vectors like ransomware which they are likely to see in the short term.

Comprehensive: Employees need to be prepared for the most likely situations. It is neither realistic nor feasible for security awareness training to turn regular employees into security professionals. But they can understand the major attack vectors and develop some sensitivity, to help them detect attacks in progress.

Compelling: Most employees don’t know what’s at stake, so they don’t take training seriously. Don’t try to scare employees or play Chicken Little, but they need to understand the consequences of attacks. It gets back to helping them understand the organizational risk of screwing up. You do this by integrating a few stories and anecdotes into the training materials, making attacks and losses real and tangible; and humanize attacks, so they feel personally relevant.

Fun: Boring content is boring. If employees don’t enjoy the training materials, they will shut down and do just enough to pass whatever meaningless test you put them through. They will forget what they learned as soon as they leave the room. As corny as it sounds, no fun generally means no retention.

Of course content is also subjective. What you like might not interest the rest of the organization. So we always recommend a broad testing/PoC process to ensure the content works for your organization. We’ll get into procurement later in this series.

Buy-In

Clearly you want employees to have fun and find the training entertaining. But that’s not the only thing you need for a successful security awareness training program. You need senior management to understand the importance of security awareness training and buy into your vision of success, as well as how you plan to quantify risk reduction and measure the impact of your program.

Many security professionals don’t have a lot of experience in getting this kind of buy-in, so let’s map out a few steps:

Get facetime: As with any program you need to sell the benefits, which means getting off your butt and talking to business leaders.

Sell the business value: As mentioned above, you need to communicate value and clearly define success.

Identify risks: Make sure they also comprehend the risks of not training successfully. They may involve system downtime, data loss or breaches, or compliance fines. It’s not about mindless fear – you need a realistic and pragmatic assessment of the downside.

What do they have to do: Finally, internal leaders need to understand the requirements on them and their teams. Are you asking for money from their budget? How much time will employees need to devote to the program?

Once you help the leadership team understand what’s in it for them, the risk, and what they need to do, you should be positioned to enlist their support. You don’t need senior management to push the program, especially if it’s required for compliance. But it certainly helps, so spend time to line up support before you launch.

Quantifying the effects of training on risk is key to successfully selling the program and getting employees engaged, so we will focus on that in our next post.

In this episode we review the lessons of this year’s Black Hat and DEF CON. In particular, we talk about how things have changed with the students we have in class, now that we’ve racked up over 5 years of running trainings on cloud security. then we delve into one of the biggest, and most confusing, trends… the mysteries of Artificial Intelligence and Machine Learning. Considering our opinions of natural intelligence, you might guess where this heads…