As a SaaS provider, securing your environment from known threats is one thing, but how about the unknown? That’s a different story altogether, and it’s exactly why the security community is so worked up over Meltdown and Spectre. With so much to learn about the newly discovered vulnerabilities and the threats they pose, many have been sent into a bit of a tailspin. But, before you give in to the panic, we’ve laid out specific steps below that can help you mitigate the risks in order to keep your data and that of your customers secure. Read more “Meltdown & Spectre: How to Secure Your SaaS Environment From Unknown Threats”
This post discusses the Meltdown and Spectre vulnerabilities, provides some proactive actions that can be taken to mitigate them, and also discusses the use of behavior-based analysis to detect attacks that take advantage of these or similar vulnerabilities, regardless of their signature. Read more “Meltdown & Spectre: What You Need to Know”
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”
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:
- There may be insufficient public information to enable attackers to exploit the vulnerability.
- Doing so may require prior authentication or local system access that the attacker does not have.
- 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”
Exploits feed on vulnerabilities. Vulnerabilities, in turn, pave the way for exploits. These closely related security concepts are often confused, but it’s key to understand the difference and how they each play out to make sure your systems are as airtight as they can possibly be. Read more “Vulnerabilities and Exploits: What You Need to Know”
Recently, I had the opportunity to help build out our vulnerability detection feature here at Threat Stack. I stepped into this project as I had many others; trying to understand the problem, thinking about the scale, how to break up the problem, etc. This problem is something developers rarely think about: the operating system. Sure, we have all done our fair share of apt and yum, but have you ever really taken a look into what gets installed on your computer? Have you ever noticed that when you do a dpkg -l, what you see is actually some strange take on semantic versioning that doesn’t seem to line up with what you see when you look at the version of that program using its version command? Me either, and let me tell you, it was not what I was expecting.
You know that feeling you sometimes get after you’ve left the house for the day and suddenly fear you didn’t lock the door? You have two options: Turn back around to check, ensuring your home will be safe and secure while you’re gone, or leave it to chance, hoping you locked the door, but worrying all day that you didn’t…
The same situation presents itself when it comes to vulnerabilities within software-defined environments. The options? Embrace a “trust but verify” mindset by proactively monitoring for vulnerabilities, or do nothing, leaving to chance the security of company data, customer data and, as a result, the very existence of your business. Read more “Introducing Vulnerability Management at the Workload Layer”
Recently, a security firm reported what they claimed to be a flaw with a major impact on organizations running Linux. (And apparently since all the rage these days is to give bugs code names, they pre-seeded the market with this timely one: “grinch”).
Linux software bugs have been huge this year, leaving administrators reeling to patch themselves from Shellshock, Heartbleed, POODLE, etc. With claims that this vulnerability could have an impact similar to Shellshock, I really wanted to dive into what the “grinch” bug means in order to separate the fact from the FUD.
The internet is yet again feeling the aftereffects of another “net shattering” vulnerability: a bug in the shell ‘/bin/bash’ that widely affects Linux distributions and is trivial to exploit. The vulnerability exposes a weakness in bash that allows users to execute code set in environment variables, and in certain cases allows unauthenticated remote code execution.
Possible vectors for attack include: