What You Need to Know About the Apache Struts Vulnerability – Updated

Post updated by:
Christian Lappin,
Threat Stack Senior Security Engineer & David Weinstein, Threat Stack Senior Security Engineer

Four months ago we wrote the following:

The Apache Struts “vulnerability is . . . extra-concerning because exploiting it is trivial. Hackers can easily spot vulnerable systems, the Struts exploits are publicly available, and the attack is easy to carry out and repeat. Attackers need to modify just one line of code to trick servers into downloading malicious binary from the internet.”

We warned about the Apache Struts vulnerability before the massive cyber attack that Equifax Inc. experienced — or at least before Equifax announced the breach to the public. Read more “What You Need to Know About the Apache Struts Vulnerability – Updated”

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”

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”

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”

5 Things All Security Teams Should Be Doing (But Many Aren’t)

Security teams are expected to do a lot these days. From properly configuring the cloud environment, to protecting the organization from today’s latest threats, to answering tough questions from the board and customers, there’s more than enough to be done, but how do you know you’re doing the right things?

In this post, we’ll dive into the five biggest areas of security that all teams should be paying attention to. Addressing these will protect you from a large majority of security threats today, and will also create a solid security foundation that you can incrementally build on as your organization grows and your needs become more complex. Read more “5 Things All Security Teams Should Be Doing (But Many Aren’t)”

The 5 Questions Your Security Team Should Be Able to Answer

In a time when security consciousness is high and stories about security breaches are all too frequently in the headlines, your security team needs to be ready for questions it’s bound to receive from customers, auditors, employees, board members, and other affected parties.

We’ve covered a lot of topics in this blog, including cloud security strategies, basic security hygiene, best practices, and how to mature your security posture. But to make it easy for your security team, we’re going to use this post to address five fundamental questions that any security team must be able to answer and give tips on how you can prepare to answer them. Read more “The 5 Questions Your Security Team Should Be Able to Answer”

Considerations For Creating Secure User Groups on AWS Using IAM

A big difference in the way on-premise infrastructures and cloud infrastructures are implemented centers on the way that user permissions are assigned. As you move towards software-defined everything, where data and systems are far more connected (generally a good thing), you need to pay special attention to the roles and permissions you grant to ensure that users are only given as much access as they absolutely need. No more, no less. Read more “Considerations For Creating Secure User Groups on AWS Using IAM”

How to Verify That Compliance Controls and Processes are Being Met

Compliance is a complex, ongoing process. Between deciphering requirements into relatable terms, allocating a budget, and  assembling a team for your compliance audit — all while trying to stay focused on running your business — there’s a lot to think about and do. And after all of this, there is still more that needs to be managed.

From regular maintenance of the processes, controls, and technology you implemented, to questions from customers about your level of compliance, you’ll quickly realize that compliance is a continuous process that needs to be managed, not a one-and-done activity.

Having said that, what are you doing, or going to do, to make your compliance plan accessible so team members — from Security to IT to Sales — can quickly verify a control or process?

Read more “How to Verify That Compliance Controls and Processes are Being Met”

The Ultimate Compliance Cheat Sheet: A Wrap Up of Threat Stack’s Cloud Compliance Series

We write about compliance (and talk to customers about it) pretty regularly, and if you’ve been following our blog over the last two months, then you know we also just did a full series on the topic. In addition, we released the The Threat Stack Compliance Playbook that’s full of practical information you can use to help your company achieve compliance without losing your sanity.

Read more “The Ultimate Compliance Cheat Sheet: A Wrap Up of Threat Stack’s Cloud Compliance Series”

Allocating Resources for a Compliance Audit: A Practical Framework

When companies prepare to meet compliance, whether it’s PCI DSS, HIPAA, or SOC 2, one thing that can be estimated inaccurately is the stakeholders who need to be involved — who they are, what departments they come from within your organization, what their roles are, what knowledge and skill sets they require, how long they’ll be needed, etc. This post is intended as a practical guide to help you develop a thorough and realistic resource plan for your next compliance audit.

Read more “Allocating Resources for a Compliance Audit: A Practical Framework”