How to Cut Time-to-Security-Incident-Detection on AWS

Time-to-detection is everything these days. If you don’t find a breach yourself, chances are someone else will. A recent study points out that up to 27% of breaches are discovered by third parties. This includes vendors or partners you work with, auditors, and probably most damaging of all — your customers.

The problem most companies are grappling with today is how to cut time-to-detection to ensure that they are the first ones to know about an issue, and in a way that won’t put a resource drain on the team. Last Thursday, Chris Gervais, Threat Stack’s VP of engineering, sat down with George Vauter, a senior software security engineer for Genesys, Jarrod Sexton, the lead information security manager for Genesys, and Scott Ward, the solutions architect at Amazon Web Services (AWS), to have a frank discussion about this in a webinar format.

Genesys is a leader in omnichannel customer experience and customer engagement software, with both on-premise and cloud-based offerings. PureCloud, their cloud-native microservice platform, is run on AWS, so the team has extensive experience launching and scaling in the cloud, as well as building a “secure-by-design” platform.

In our conversation, Genesys outlined several important steps that all companies should be implementing to reduce their time-to-detection, which we wanted to further highlight in today’s post. Read more “How to Cut Time-to-Security-Incident-Detection on AWS”

Whose Fault is That? How NOT to Be a Cloud Security Statistic

Gartner predicts that 95% of cloud security failures from now until 2020 will be the customer’s fault. That means when something goes wrong, it’s probably not AWS or Azure’s fault. Chances are, you have to point the finger at your organization.

Or — better yet — you could take the necessary and proactive steps to minimize the likelihood that you’ll become one of the cloud security failures. The good news is that it’s pretty easy to find out what you need to do. Below we’ll outline the steps to make sure that you stay out of the headlines and out of the statistics. Read more “Whose Fault is That? How NOT to Be a Cloud Security Statistic”

Not Ready for Cloud Security? Here Are 5 Things You Can Do in the Meantime

If you are currently running an on-premise or hybrid environment with an eye to eventually making a complete transition to the cloud, you may be feeling a bit overwhelmed by everything that needs to change in order for your security posture to be appropriate for this new environment. In this post, we’re going to explain how you can start where you are, take small but meaningful steps, and still make important progress toward where you want to be — operating securely in the cloud.

Without trying to boil the ocean, here are five key steps you can take to gently kickstart your transition toward a fully secure, all-cloud environment, no matter where you are today. Read more “Not Ready for Cloud Security? Here Are 5 Things You Can Do in the Meantime”

How to Use Automation to Decrease Mean Time To Know

Mean Time To Know (or MTTK for short) is one of the most important metrics in security operations. It measures how efficient the security team is at detecting real threats. The shorter it is, the sooner you will catch an attack in progress and be able to put a stop to it, reducing the negative consequences for your organization. 

But the reality is, it’s not so easy to reduce MTTK. For starters, security teams are barraged with alerts on a daily basis, requiring manual work to sift through the noise to find a signal that indicates a real issue. Add on all the other tasks that need to be done aside from alert investigations, and it’s seemingly impossible to get ahead.

This is where automation comes in. Automation not only eliminates the need to manually handle tedious tasks (like alert response). It also helps you to optimize your existing resources, empowering them to actually focus on MTTK and get it under control.

In this post, we’ll take a closer look at what MTTK is (and isn’t) and how you can leverage automation to effectively decrease it. Read more “How to Use Automation to Decrease Mean Time To Know”

The RNC Data Exposure: Learnings and Actions to Take

Recently, headlines were hyping the largest ever exposure of voter information, involving some 9.5 billion data points related to 198 million U.S. voters. 

Attention-getting stuff. And since the story involved the Republican National Committee (RNC), the hype was intensified. Somewhat imprecisely, many articles characterized the incident as a data “leak”, “breach”, or “compromise” — again, adding to the intensity, but not the accuracy of what actually happened.

I’m not trying to minimize the seriousness of the issue — the potential damage was enormous as were the implications regarding security and privacy. But now that some of the dust has settled, it’s time to back away from the headlines and explore what actually happened.

So let’s see what we can learn from the RNC data exposure — and more importantly — what we can and must do to better protect our data and systems going forward. Read more “The RNC Data Exposure: Learnings and Actions to Take”

Vulnerable vs. Exploitable: Why These are Different & Why it Matters

Pop quiz: What’s the difference between vulnerable and exploitable?

As we’ve written before, a vulnerability is a weakness in a software system. And an exploit is an attack that leverages that vulnerability. So while vulnerable means there is theoretically a way to exploit something (i.e., a vulnerability exists), exploitable means that there is a definite path to doing so in the wild. Naturally, attackers want to find weaknesses that are actually exploitable. As a defender, being vulnerable isn’t great, but you should be especially worried about being exploitable.

There are a few main reasons why something that is theoretically vulnerable is not actually exploitable:

  1. There may be insufficient public information to enable attackers to exploit the vulnerability.
  2. Doing so may require prior authentication or local system access that the attacker does not have.
  3. Existing security controls may make it hard to attack.

 Below, we’ll explain why this matters and how you can use it to improve your security posture. Read more “Vulnerable vs. Exploitable: Why These are Different & Why it Matters”

10 Best Practices for Securing Your Workloads on AWS

Achieving optimal security in a cloud environment can seem like a moving target. New security threats are constantly popping up along with security implementations meant to fight them off. To help you achieve optimal security in this environment, this post highlights the top 10 best practices for AWS security. Read more “10 Best Practices for Securing Your Workloads on AWS”

The Real Implications of The Shared Security Model

Gone are the days when the majority of businesses could point to the cloud warily and say, “I think my data’s safer on-prem.” Organizations today are far less worried about how secure the cloud is in general, and this change in attitude has sped up cloud adoption to a great degree.

What has led to this more relaxed embrace of the cloud? In part, providers like AWS have gone to great lengths to codify and transparently communicate a Shared Responsibility Model that has expressly defined the scope and boundaries of responsibility. Increasingly, customers recognize that Amazon and its brethren have all-star teams that have a security focus ingrained in them. There’s a certain level of comfort that comes with knowing you are in good, experienced hands.

But, even as the cloud is proven to be quite secure and as confidence in it increases, Security and DevOps teams still have to be vigilant about their own workloads. Organizations have to pick up their end of the shared responsibility bargain — and in some cases, even take it a step further than what is required.

With that in mind, here’s what today’s organizations need to know in order to do that successfully and continue to benefit from all that the cloud has to offer without major security concerns stymying progress. Read more “The Real Implications of The Shared Security Model”

Eyes on the Ground: Why You Need Security Agents

A post based on the talk I just gave at SOURCE Boston 2017

If you answer Yes to one or more of the following questions, you probably have agent fatigue! Do not worry, I’m here to help and we can work through this.

  • Do you often find yourself booting into safe mode?
  • Do you regularly look for programs in the taskbar to kill?
  • Do you look for reasons why your computer seems so sluggish after IT did something to it?
  • Do you wonder why you even pay for that thing on your computer?
  • Do you have employees who complain about installed software?
  • Do you look for ways to meet compliance requirements in software?
  • Do you care about security?

Read more “Eyes on the Ground: Why You Need Security Agents”

Why Automated Security Threats are Proliferating and How to Fight Back

We’ve written before about the importance of looking inward, rather than out, when it comes to evaluating what types of cyberattacks are the biggest threat to your unique organization. A large part of the attack landscape today includes automated threats. Rarely do we come across handcrafted attacks targeting specific organizations. A far cry from bespoke and laser-targeted, the vast majority of today’s cyberattacks are built for volume and trolling for the weakest point of entry.

So, what exactly are automated security threats and how can you best protect your organization from them? Read more “Why Automated Security Threats are Proliferating and How to Fight Back”