Research

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

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:

(DevSec)Ops vs. Dev(SecOps) 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. 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:

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

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

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: