3 Security Best Practices We Used to Build a Strong Foundation at Threat Stack

As a security company, Threat Stack prioritized the implementation of security best practices from day one. To share our experience, this post focuses on three basic best practices our engineering team implemented when we first started out. They’re quick to set up and can produce measurable improvements right out of the gate — and for that reason, we believe they’re table stakes for anyone building a technology business in the cloud.

AWS Builder Community Hub

1. Use VPNs to Access Secure Systems

In the early days of EC2, every host had an externally routable IP address, and it was only the security group (and maybe the host-based firewall if you had one) that kept out attackers. AWS gives you virtual private networks to keep your infrastructure safe in secured subnets. Since systems are no longer directly accessible, engineers will create Bastion hosts to serve as a primary access point, which limits the number of access points to your systems and therefore increases security.

Our strategy? Put Bastion hosts behind VPNs as well to reduce your attack surface early on. For the more advanced technical teams out there, consider reviewing some of the recent research on zero trust networking and abandon VPNs entirely.

2. Implement Two-Factor Authentication

At Threat Stack, we use Duo for two-factor authentication (2FA). We have integrated it not only for system access, but for access to many other internal tools that we have built here. Getting 2FA set up from the very beginning made it easy to scale as we added more users to our environment and as our environment became more complex. It’s a step that’s so easy and inexpensive that there is just no reason to not use it at your company. (Best Practice: Make sure it’s enabled on all services by default, not by user choice.)

3. Use SSL Certs on Everything (and Monitor Them Too!)

We also made it a policy to obtain an SSL cert for any site that we made available to our users externally or internally. Secure Sockets Layer (SSL) certificates enable encrypted communications between a web server and browser. This protects sensitive data such as credit card information from being stolen or tampered with.

SSL certificates are issued by Certificate Authorities (CAs), which are organizations that are trusted to verify both the identity and the legitimacy of the entities requesting the certificate. Part of the importance of SSL certificates is creating a layer of user trust in your website. When users enter a website that has an expired SSL certificate or no certificate at all, their browsers could (and should) alert them that the website may not be safe. Obtaining certs is inexpensive (or free!) and simple.

However, remember that more important than trying to secure “all the things” (Mission: Impossible) is monitoring them for when they are not secure. Not only do we monitor our certificates for expiration (you do this also, right?), but we also monitor our certificates with tools like SSL Labs Server Test to make sure the certificates and sites are set up correctly.

Getting Your Security Ducks in a Row

When it comes to security, we believe in continuous improvement. There’s no such thing as perfect security, so the key is to prioritize your security to-do list. One great way to do this is to conduct a security audit so you can create a baseline of where you stand right now, determine where you need to make improvements, and make a plan for how you can strengthen your security posture.

To achieve this, we recommend that organizations build a shared security framework. With the help of the new Threat Stack® Cloud SecOps Maturity Framework, benchmarking your security maturity can be a straightforward process of evaluating your strengths and weaknesses, which in turn, will empower you to develop a clear and actionable plan to move forward.

One great place to start?

Take our Cloud SecOps Maturity Assessment and find out exactly where you stand today so you can start making immediate and measurable improvements.

*** This is a Security Bloggers Network syndicated blog from Blog – Threat Stack authored by Pete Cheslock. Read the original post at: