Research

This is the second 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, introduced the concepts and outlined the major categories of insider risk. This post defines the concepts. 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. Access to user context, including privileges (entitlements), groups, roles, business unit, etc. 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

A Security Pro’s Cloud Automation Journey 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. Read the full post at DisruptOps Share:

Disrupt:Ops: Consolidating Config Guardrails with Aggregators 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. Read the full post at DisruptOps Share:

Disrupt:Ops: Quick and Dirty: Building an S3 Guardrail with Config 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. Read the full post at DisruptOps Share:

How S3 Buckets Become Public, and the Fastest Way to Find Yours 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. Read the full post at DisruptOps Share:

Why Everyone Automates in Cloud 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. Read the full post at DisruptOps Share:

What Security Managers Need to Know About Amazon S3 Exposures (2/2) 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. Read the full post at DisruptOps Share:

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. So here’s #1 from the Disrupt:Ops hit parade! What Security Managers Need to Know About Amazon S3 Exposures (1/2) 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. Read the full post at DisruptOps Share:

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. Watch or listen: Share:

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. **Watch or listen:** —- Share: