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”
Test-driven security is the implementation of tests into the development process, and Chef InSpec is one tool that will help you get started with this process. These security tests are intended to define the security features required for a system to be production ready.
In this post, we will walk through the process of using test-driven security, with proscriptive security tests, using Chef InSpec. Read more “Test-Driven Security With Chef InSpec”
You’re an Ops person who’s ready to take a dip into AWS Lambda and this whole serverless thing. But where do you start? You’ve gone from deploying a monolith to deploying microservices. Now how do you go from deploying a microservice to deploying functions?
We want to take something that was originally written to run on an EC2 instance and run it on Lambda. How do we get there? In this post, we’ll explore this question by looking at the threatstack-to-s3 service that we’ve discussed in other blog posts. Read more “Considerations for Moving Services to AWS Lambda”
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”
Implementing AWS security best practices into your Terraform design is an excellent way of ensuring that you have a streamlined way to achieve your security goals and manage your infrastructure.
In this post, we will talk about the following three areas of AWS security best practices and how to implement them with Terraform:
- Environment segregation by AWS account
- CloudTrail logging
- Traffic and system access controls
Just to be clear, this post is not an introduction to Terraform: It’s an introduction to incorporating AWS security best practices into Terraform code. Read more “Incorporating AWS Security Best Practices Into Terraform Design”
Note: In light of the AWS S3 outage in us-east-1 on February 28, 2017, let’s discuss a few things. Amazon’s S3 has exemplary availability. Compare that with the time and cost of maintaining package distribution yourself. It’s easy to look at S3’s outage and conclude that it is better to handle the responsibility yourself. In the same way, it’s easy to see news of a plane crash and conclude that driving is more reliable. The feeling of control doesn’t always lead to the most reliable outcome. Aptly does provide the ability to serve a repository on its own. See how to front Aptly with nginx in an emergency like the one on Tuesday February 28.
It is an unfortunate fact that many organizations do not routinely perform comprehensive software patching. At Threat Stack, we have confirmed this with our own analysis of how frequently systems are updated, and Verizon’s DIBR shows us that the most commonly exploited vulnerabilities are months or years old.
But patching is one area where following the status quo is a very bad idea. As a best practice, your organization needs a patching strategy to make sure it remains secure, and with that in mind, this post explains how you can adopt a patching strategy that suits your organization’s needs and values. Read more “OS Updates and Package Management: Ubuntu Repo Management With Aptly and AWS S3”
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”
In Part 1 of this post we explained how you can find all the secrets in your environment. In Part 2 we will discuss effective ways to store and manage secrets — to keep them from leaking to unauthorized people. Read more “Cloud Security Best Practices: Finding, Securing, & Managing Secrets, Part 2”
One of the challenges of building open source tools is figuring out how to package and distribute them. This is particularly true with web services. To make building, deploying, and running web services easier, Chef created Habitat.
When building open source web services for Threat Stack, one of our concerns is how to package these Python Flask applications so they run in the widest array of environments with low adoption friction. Using Habitat, the process is quick and easy.
For this post, we’re going to focus on the specifics of packaging a Python Flask application and the particular needs of that stack. Read more “Chef Habitat For Packaging Python Flask Web Services”