Here at Threat Stack we really like Yubikeys — and they’re a critical part of our security program. Many folks know Yubikeys for their ability to generate one-time codes for use as a second factor. Did you also know you can store certificates on them and use them in your operating system? I’ve written about using the Personal Identity Verification applet on the Yubikey in the past, but now I’d like to take that one step further and use it to identify yourself to a web application. We’ll cover how to do this with a Mac OS X Mojave client — which works nicely with the OpenSC library and an HAProxy reverse proxy. Read more “Protecting Infrastructure With TLS Client Authentication”
Trash Taxi: A Lifecycle Management Tool for
Superuser Discovery & Cleanup
Our Motto is: Threat Modeling: The sooner the better, but never too late. — OWASP
The practice of creating a threat model can help teams proactively understand and develop a strategy for managing the possible vulnerabilities their organization faces, instead of waiting until after an incident occurs. OWASP defines threat modeling as “a procedure for optimizing security by identifying objectives and vulnerabilities, and then defining countermeasures to prevent, or mitigate the effects of, threats to the system.”
SecOps teams can benefit from creating a threat model for cloud infrastructure, and defining an approach to operationalizing, hardening, and automating security throughout the software development lifecycle. While it’s best to build security into the design of your systems at the outset, remember the motto: “Threat Modeling: The sooner the better, but never too late.”
Let’s walk through how to get started. Read more “How to Create a Threat Model for Cloud Infrastructure Security”
If the headlines are any indication, hackers continue to exploit vulnerabilities in cloud infrastructure platforms, with targeted AWS attacks becoming very common. Many attacks follow similar patterns: Actors are typically looking opportunistically for AWS keys, which are either accidentally posted to open source code websites like GitHub or stolen from employee laptops using malware. Once the actor has gained access to the AWS account, they often look for fairly direct paths to sensitive data or valuable resources, such as an open S3 bucket or access to launch a new EC2 instance to mine cryptocurrency.
Many developers use AWS access keys that have not been changed in months or years. Although keeping these keys the same makes things easy for the developers, it’s not very good security hygiene. Many organizations aren’t aware that their stagnant AWS keys could be causing major vulnerabilities. Read more “How to Avoid Targeted AWS Attacks With Secure AWS Keys”
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)?”
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”