More companies are moving to the cloud than ever before. Amazon Web Services (AWS) is one of the most popular cloud platforms, and for good reason: AWS provides a robust set of features and services that give it broad appeal among businesses of all sizes. But when it comes to security, many companies continue to fall short, putting their sensitive data at risk. In a recent Threat Stack study, for example, we discovered that 73% of companies have at least one critical AWS security misconfiguration that enables an attacker to gain access directly to private services or the AWS console, or that could be used to mask criminal activity from monitoring technologies.
To gain some insight into the biggest (and potentially most devastating) mistakes companies are making related to AWS security as well as tips and strategies for avoiding them, we reached out to a panel of InfoSec pros and AWS experts and asked them to answer this question:
“What’s the number one mistake companies make when it comes to AWS security (and how can they avoid it)?”
Read more “21 InfoSec and AWS Experts Reveal the #1 Mistake Companies Make When It Comes to AWS Security (and How to Avoid It)”
No matter where you sit in your organization, you should know what happens when you sacrifice security for speed. Threat Stack recently surveyed DevOps and security pros and found that more than half (52%) of companies make this very sacrifice, cutting back on security measures to meet a business deadline or objective. Additionally, 62% of security professionals surveyed stated that their Operations teams push back when asked to deploy secure technology — often because Ops fears it will slow things down.
This might not seem like a large problem until you consider what actually happens when you sacrifice security for speed. By putting speed above security best practices, you open your organization up to breaches and attacks. But ironically, contrary to the belief of some operations professionals, applying security best practices doesn’t necessarily require you to slow down forever.
In this post, the fourth in our SecOps survey series, we’re sharing what happens when you sacrifice security for speed, as well as some best practices your organization should apply in all circumstances. Read more “What Happens When You Sacrifice Security for Speed (And Common Ways Security Gets Sacrificed)”
Even organizations that understand the importance of cybersecurity in theory often stumble when it comes to marrying security initiatives with their development and operations processes.
We recently surveyed a group of development, operations, and security professionals, compiling our findings in this report: Bridging the Gap Between SecOps Intent and Reality. We found a huge gap between intent and reality when it comes to implementing and practicing SecOps — a term that — properly understood — refers to the integration and alignment of security with DevOps practices.
Most organizations agree that everyone should be responsible for security, but this principle is not being upheld on a day-to-day basis in many organizations. And that’s bad news for everyone.
Today, we’re examining why the vision for SecOps hasn’t become a reality at most organizations. We’re exploring specific obstacles and attitudes to spotlight what is standing in the way, even at organizations where a stronger security posture is an explicitly stated goal. Read more “The 5 Biggest Obstacles to SecOps Success”
SOC 2, which was developed by the American Institute of CPAs (AICPA), is specifically designed for service providers storing customer data in the cloud, which means that it applies to nearly every SaaS company operating today.
So, what is SOC 2 exactly? While the framework is a technical audit, it goes above and beyond this to require that companies establish and follow strict information security policies and procedures. The criteria for developing these policies and procedures is based on five “trust service principles” to ensure:
- Processing integrity
- Privacy of customer data
Compliance can be evaluated by independent auditors who assess a company’s ability to comply with these five principles.
SOC 2 is one of the more common requirements that SaaS companies must meet, but that doesn’t make compliance any simpler or dealing with an audit any less exacting. In this post we have laid out the most important requirements and the steps you should take to become compliant quickly in order to stay out of trouble with auditors and compete in a crowded SaaS market. Read more “How to Get Your SaaS Company SOC 2 Compliant With Minimal Headaches”
There’s a lot of talk in the business world — especially the software-driven side of it — about achieving and maintaining velocity. The ability to continuously release new code can be the difference between winning and losing.
But as Threat Stack’s CSO, Sam Bisbee, recently pointed out in InfoSecurity magazine, “The market’s investment in services and tools to automate business processes without incurring heavy maintenance costs has outpaced investment in the methods to secure them.” Sometimes we forget that, if security can’t keep up, it won’t matter how fast you get that new app out there. You’ll eventually be faced with a mountain of security-related headaches — or at least the stress of increased risk. Read more “Velocity and Security: 5 Posts to Help You Get Security Up to Speed”
In an earlier post, we talked about how we implemented centralized authentication at Threat Stack. This project initially allowed us to create clearer access control for our servers. A side benefit of this work has allowed us to write tooling around common authentication processes.
One thing we’ve wanted to do is create an alert when folks are using a VPN to connect to one of our environments. In the event of a stolen laptop and stolen credentials, a user could be alerted to someone logging in with their credentials. With OpenVPN, performing actions on a client connect is possible using a client-connect script, so in the tradition of writing small Go applications to improve visibility, we did just that.
For the last few months our Slack bot VPN Notifier has been letting our engineers know when they connect into a Threat Stack environment. We’ve now done the work to open source the tool so that others can use and improve on it. We specifically mention improve, because our tool has limitations: The current version does extremely basic environment checking, and extremely basic alert suppression. Our hope is that we can collaborate with others who want to take this tool the extra mile. Read more “VPNNotify: A VPN Notification bot for Slack”
Authkeys, Threat Stack’s new open source tool, performs LDAP lookups of SSH keys without the need for using scripts or other interpreted code.
You may recall from an earlier post that we’ve set up centralized authentication here at Threat Stack. Our motivation for doing so centered on the desire to achieve clearer access control for the servers that power our platform. By doing this, we no longer need to use Chef to deploy the majority of users to servers. Rather, we can use an internal application to add, lock, and update users and their associated metadata.
Read more “Authkeys: Making Key-Based LDAP Authentication Faster”
Threat Stack, like many other Software-as-a-Service providers, has an on-call rotation. During any week, two members of our engineering organization are tasked with responding to alerts across the platform they build and maintain. These two engineers are also responsible for a myriad of other services as well that provide support to the infrastructure: services that provide metrics and monitoring, log capture and collection, authentication, etc.
This presents a security issue with regard to access control: should all staff have access to all servers all the time? In early start-up life this is unavoidable. But as an organization matures and grows, it becomes a bigger risk. Administrator and similarly scoped credential theft is a goldmine for attackers, so we wanted to improve our story around internal access control.
Unwrapping who needs access to what is always an evolving task, but we put in the work to figure out who goes where and why, and then created groups to control that access. Since we already use groups as a way to control who can log into specific machines, and we use PagerDuty to assign on-call rotations, it seemed like we could create a tool that would query PagerDuty and update our on-call group. So we did! And as a gift to you, we’ve open sourced it.
Read more “Balancing Security and Your On-Call Rotation Using Deputize”
One way organizations can improve their security and operational ability is to collect logs in a central location. Centralized logging allows engineers across the entire organization to have a “common view” of the system under load, and can provide vital shared context when things go wrong.
Over the last few months, we at Threat Stack have been reworking how we handle all aspects of our logging system. This project encompasses everything, from the content of our log data to the infrastructure that collects it. In this post you’ll learn about how our internal applications send log data, where they send it to, and the trade offs we considered in making our collection system reliable. Read more “Reliable UNIX Log Collection in the Cloud”
I’m a big fan of the YubiKey 4.
The YubiKey is a security device that originally outputted a 44-character “one time password” that could be decoded and mathematically verified and used as a second factor for authentication. Over the last few years, improvements to the devices mean that they can also perform other important functions, such as storing:
- Identity, Signature, and Encryption Certificates
- U2F data for websites (GitHub and GMail, among others, support this)
- GPG Keys
If you’re looking to set this up on your own, read on to learn how this extra functionality helps your security game, and how you can configure services to use it. Read more “Securing User Credentials With the YubiKey 4”