As a community, we need to break down silos and allow for open communication about finding and fixing bugs. Security cannot sit on the sidelines and say no every time an employee or part of your organization asks for a new service or way to help them be more productive. We need to partner with our teams to provide secure defaults and guardrails for applications and infrastructure. We need to engage users where they are working, whether it is in meetings or in pull requests. We are only as secure as our users allow us to be and we need to engage them in our shared goals.
Security, in whatever authority it may be, cannot exist in a vacuum without oversight and transparency. Security must work directly with all of their teams as a service organization to make sure that we all have a shared goal. I’ve worked with teams across the spectrum, whether they are Devs, QA, DevOps, finance, IT or marketing teams to put these ideals in practice.
InfraOps: Your First Line of Defense
Security really is a core component of both DevOps and IT, so why not deputize both into security proper. At the basic level bringing security first principles into IT, system administration, network administration and eventually what we all know as DevOps. DevSecOps seems to be the most well known mashup of these ideas but it doesn’t go far enough. IT needs to be part of this conversation as well. ITOps is at least starting to become more prevalent yet still I’ve barely seen ITSecOps broach the conversation. The real goals of any of these ideas though is collaboration and realigning across common goals and a common language. I can guarantee you that there is not one DevOps engineer that wants to spend part of their day rebuilding a portion of production or working on taking it down for forensics because a service was taken over. Similarly, I very much doubt anyone in tech support really wants to spend their weekend rebuilding an entire fleet because of ransomware. Neither may think that they are part of the security team, but they are your first line of defense so we formalized it. I talked about infrastructure and building roads before we can go to the moon so much that my team bought a cardboard cutout of President Eisenhower that would sit with them in our NY office.
If InfraOps can expand security into the core infrastructure of DevOps and IT, what if we now expand this out at the application level and bring in QA?
We’re All Looking for Bugs
If we really take a step back, the fact is we’re all hunting for bugs, whether it’s Grace Hopper and the moth, finding cockroaches in your milkshake, scurrying across the kitchen floor or whatever other bugs you may find when you turn the lights on. If you shine a light on your code base as a whole, what do you see? Ultimately, it’s up to both QA and Security to find bugs before your users do.
I personally have worked with QA teams to bring them into the Security team fold. If you’re constantly shouting about security bugs, both from a finding and fixing perspective, you’ve drawn your line in the sand, you’ve helped to create a false dichotomy that will keep your bugs isolated. If only security can find security bugs, does that mean only security can fix those bugs as well? Is your team a mix of builders and breakers? Or are you still waiting for your security ninja that will be able to find, fix, prevent, monitor and alert for all of the things? If you are that person, do you sleep? Are you sure you have your eyes on all of the things or is there something not quite in your purview?
For your users a bug is a bug, whether it’s at the application level, in the user experience or what would be classified as a security bug. There are real world costs to all of these bugs. A bug bounty report may be the cheapest of them all when compared to potential churn for paying customers, missed opportunities on engagement, fewer ad views or upsells to premium versions. If you’re small enough, that security bug that you worry most about could sink you, but so can shipping a constantly buggy product. If on the other hand you’re big enough, a security bug may turn out to be nothing more than a Q4 writedown, but on the other hand inconsistency opens you up to your competitors. Why as a user should I stick with the incumbent if you have fewer features and are just as buggy as that newer site with better design, responsiveness and overall better experience?
The Wizard Behind the Curtain
The real core concept of DevOps was moving away from the BOFH mindset, revealing the wizard behind the curtain. Infrastructure both as code and an elastic commodity are what powered the DevOps movement. Removing these gates was scary for many in the system admin mindset but became hugely transformational and opened up whole new exciting ways of doing things instead of the same repetitive apt-get install command that you may or may not have run against all 300 servers across multiple regions. Believe it or not, there were not nearly as many fork bombs or servers running out of inodes as companies transitioned to DevOps as some predicted.
Security should follow the lead of DevOps and the ideals of Everything as Code by embracing Security as Code concepts. By committing to a Security as Code framework early, often and continuously, we find problems sooner so they can be addressed before others find them. Undertake this approach for all sorts of add-on benefits, but ultimately we’re all in this together to better secure the data we all care about.
#togetherwehitharder right? We’ve all touted the effects of this on the offensive side. Well, I’m saying today, #togetherwedefendbetter.
