Tackling security, DevOps-style
Expanding DevOps to include Security isn’t easy, but it’s well worth the effort.
Keys (source: Pixabay)
DevOps, at its core, is about communication and shared responsibility. Working together makes both teams, Dev & Ops, better, and helps the company and community thrive. We now need to broaden the scope of DevOps and embrace another responsibility – Security.
Web Security is fundamentally broken right now, operating from the outside and vastly understaffed. The only way to improve it is to bring it into the core.
Learn faster. Dig deeper. See farther.
It’s not a simple feat, but DevOps has shown us how valuable it can be when achieved.
Security today ~= Ops before DevOps
Security teams have much in common with how Ops teams were (and often still are) before DevOps kicked in: they’re small (or non-existent) and are vastly outnumbered by developers; they’re seen as a blocker, always saying no, and therefore are often circumvented; they’re separate from the application team, but are ultimately dependent on the code.
In Security as in Ops, it’s easy to spot failure and hard to highlight success. When things go well, nobody gives much thought to either, but when a failure occurs, people are quick to lay blame. As a result, most conversations about security or ops are negative, painting the space in a bad light and leading to higher burnout.
Lastly, security is similar to Ops in how management perceives it. An investment in either is seen as insurance, meant to reduce the risk of a failure, such as outage or a breach. Risk mitigation is really hard to quantify, making business cases in these fields tricky and very subjective.
DevOpsSec?
The rise of DevOps helps address many of these problems. Talking more and sharing responsibility helps one team understand and fix the other’s challenges – instead of adding more. Case studies from one company help another build their own business case, and blameless post-mortems help the community evolve its best practices.
In all of this, Security is left outside – and we need to bring it in. We need Dev teams to learn more about security, invest in building security controls, and proactively protect their code. We need Ops teams to better balance microservices agility with the greater attack surface it presents, and include security tests in their continuous deployments. And we need Security teams to evolve better continuous security solutions, drop the jargon and scare tactics, and care more about delivering software.
Where to start?
Embracing security isn’t something you do overnight. A good place to start is by reviewing things you’re already doing – and trying to make them more secure. Here are three concrete steps you can take.
HTTPS
Threats begin when your system interacts with the outside world, which often means HTTP. As is, HTTP is painfully insecure. Information can easily be stolen, content you present can be changed without much effort, and malicious players can pretend to be you, abusing the trust your users put in you.
Using HTTPS is becoming easier and cheaper. You can get free and easy TLS delivery from Cloudflare (be sure to use “Full SSL”!); since December 3rd you are now able to get a free certificate from Let’s Encrypt; and you can test how well your TLS is set up using SSLTest. Other vendors and platforms are rapidly simplifying and reducing the cost of their HTTPS offering, as demand and importance grows.
Moving to HTTPS also holds rewards, like being able to use HTTP2 and ServiceWorker, as well as getting ranked higher on Google. For more details on why you should make the switch, check out this post, slides, and video.
Two factor authentication
The most sensitive data is usually stored behind a login, and the authentication process is the main gate in front of this data. Making this process secure includes many aspects, including using HTTPS when accepting credentials, having a strong password policy, never storing a password and more.
All of these are important, but the best single way to boost your authentication security is to introduce two-factor authentication (2FA). Adding 2FA usually means users need an additional one-time code when logging in, which they get via SMS or a mobile app (e.g. Google Authenticator). This code is extremely hard for a remote attacker to guess, thus vastly reducing the risk a leaked or easily guessed password presents.
The typical algorithm for 2FA is based on an IETF standard called TOTP, and isn’t that hard to implement. Twilio wrote a great post outlining how to add 2FA, modules like speakeasy make it even easier, and you can use the open source Google Authenticator to bootstrap your own app. If you don’t want to build it yourself, you can purchase Two/Multi Factor Auth services from a vendor such as DuoSecurity, Auth0, Clef, Hypr or others.
You can also choose to offload your entire authentication process and use an OAuth-based federated login. Many companies offer this today, including Facebook, Google, Twitter, GitHub and many others. These bigger players tend to do authentication well and support 2FA, but you should consider what data you’re sharing with them in the process.
Tracking known vulnerabilities
Most of the code in a modern application was actually written by third parties, pulled into your app as frameworks, modules, and libraries. While using these components makes us much more productive, along with their functionality we also adopt their security flaws. To make things worse, some of these flaws are well-advertised vulnerabilities, making it easy for hackers to leverage them in an attack.
This is a real problem, which impacts practically every platform. Over 6% of Java modules downloaded from Maven had a known severe security issue, the typical Java applications holding 24 flaws. Roughly 14% of Node.js npm packages carry a known vulnerability, and over 60% of dev shops find vulnerabilities in their code. 30% of Docker Hub containers include a high priority known security hole, and 60% of the top 100,000 websites use client-side libraries with known security gaps.
To find known security issues, take stock of your dependencies and match them against language-specific lists such as rubysec for Ruby, victims-db for Python, OWASP’s Dependency Check for Java and Snyk’s vulnerability DB for Node.js. Once found, you can fix most issues by upgrading the component in question, though that may be tricky for indirect dependencies.
The Snyk team, which I’m a part of, is working on making this workflow easier, and recently launched a tool that helps you find & fix known vulnerabilities in your dependencies (currently only for Node.js). The tool includes a ‘wizard‘ that will help you find and fix these issues through guided upgrades and patches, and adding its ‘test‘ to your CI/CD will help you stay secure as your code evolves.
Note that newly disclosed vulnerabilities usually impact old code – the one you’re running in production. This means you have to stay alert when new vulnerabilities get disclosed, so you can fix them before attackers can exploit them. You can do so by subscribing to vulnerability lists like US-CERT, OSVDB and NVD. Snyk’s monitor will proactively let you know about new disclosures relevant to your code, but only for Node.js for now.
A culture of security
Using HTTPS, enabling Two Factor Authentication, and fixing known vulnerabilities are significant steps in building security at your core. As you implement them, remember that these are just a few steps in a longer journey. The end goal is to embrace security as an aspect of quality, and to make the security team a part of the application core.
To get there, security should become a part of your regular course of business. Include security in your agile user stories (“As a user, I want my data to always be encrypted on the wire”); Demo security audits in your sprint reviews; Add security tests to your CI/CD flows; And add attack attempts counters to your DevOps dashboard. Look at what you’re doing to ensure a high quality, and consider how to expand that to include security as well.
Beyond process and tools, embracing security is also about people. Invite the security team to be stakeholders in your demo, and to participate in sprint planning. There aren’t enough security people to add one to each scrum team, but having a Security person occasionally join a sprint can greatly help their understanding of Dev. Similarly, having a developer spend a week supporting InfoSec is guaranteed to be enlightening.
Expanding DevOps to include Security isn’t easy, but it’s well worth the effort. For our business, like we’ve seen happen with Ops, collaborating on security will make us more secure while lowering costs and accelerating output. For the community, repeating with Security what we’ve done with Ops will be a massive step towards making the web safe.