Over the past couple of weeks, both Macy’s and Timehop experienced breaches as a result of authentication weaknesses. On July 4, social media startup Timehop experienced a data breach that affected 21 million customers and included information such as names, emails, and phone numbers. According to a preliminary investigation conducted by the Timehop team, the attacker gained unauthorized access to the company’s cloud service provider using stolen administrative credentials back in December 2017. For months, the hacker conducted reconnaissance on the system before launching an attack against the company’s production database on the July 4 holiday.
Unfortunately, credential theft attacks like these happen all too often: According to the 2018 Verizon Data Breach Investigation Report, credential theft was the top cause of data breaches. Attackers can gain privileged access to a system using administrative credentials, remaining undetected (sometimes for months as in the Timehop incident) as they move laterally across a system, conducting reconnaissance, and waiting for the right opportunity to exfiltrate data.
Timehop’s breach is an example of the security risk that employees, both current and former, can pose to any organization that practices poor cloud security hygiene. Given the sheer scope of security incidents involving some form of credential theft, it’s important for IT staff and engineers to understand not only where data is stored but also who is accessing and exporting it.
Businesses issue thousands of credentials to employees and contractors, making it more important than ever for them to improve access management. Not doing so could cause an organization’s most sensitive data to be stolen.
Here are a few tips on where to start. Read more “Access Management Lessons From Timehop’s Cloud Security Breach”
As a security company, there’s a lot of pressure to keep our data secure while still moving fast and innovating on product development. I find the intersection of security and speed the most interesting challenge as an infrastructure security professional. The unique thing about Threat Stack is that our Security and Engineering teams have learned how to work together to automate security into our day-to-day processes — making them simultaneously more secure, efficient, and effective.
I’m a firm believer that an effective SecOps organization involves people, processes, and tools, in that order. The tools we’ve built in-house are meant to make people’s lives easier, and ease some of the processes that make security a natural part of the workflow if you’re trying to get a job done quickly.
We’ve open-sourced a lot of the tooling we’ve developed to make our operations more secure, and hope you’ll find this information useful when you’re thinking about automating security in your own organization.
In this post, I’ll describe three of the tools we’ve developed (and then open-sourced) at Threat Stack in order to integrate automated security processes into our workflow. (I’ve also included a description of a fourth tool that we developed — an automated SOC 2 compliance checking bot. We use it internally, but to date, it’s not available outside Threat Stack.) Read more “Three Homegrown SecOps Tools Used by the Threat Stack Team”
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”