This article covers some ways I’ve gotten security bugs fixed inside a company.
Finding bugs is a technical problem, fixing them is a human problem.
Finding bugs: Exciting.
Fixing those bugs: Not exciting.
The thing is, the finish line for our job in security is getting bugs fixed¹, not just found and filed. Doing this effectively is not a technology problem. It is a communications, organizational² and psychology problem.
A decade ago on the Microsoft vista pentest we³ found some bugs. Then as we worked to get those bugs fixed we got a lot of excuses back: “but…
It appears the Equifax breach hinged on an unupdated Apache Struts vulnerability. Lots of security people are talking about lots of different dimensions of this breach but one portion is the (in)secure use of 3rd party code. The security of 3rd party code is an area of application security that doesn’t get much attention so I want to highlight it.
Reasonable engineers rely on the work of others. This work comes from other parts of the company, the open source community or a commercial product. …
A concept sometimes used in Silicon Valley to describe an engineer that is 10x more productive than an average engineer although the 10x metric is figurative.
10x or not there are definitely patterns in how strong engineers approach their work and career. Generalizing these patterns into lessons illuminates how to be a better engineer, and employee.
This draws from my experience as an programmer, team lead, manager and manager of managers.
This is the bedrock of you as an employee. Be careful when you say…
I’ve worked in three big areas in my career: building software, securing software and leadership.
Each area has a different sized feedback loop.
Building software has a very tight and immediate feedback loop. Get an idea, try to build the idea, fix/tweak/improve then finally ship. At the micro level its write feature, fix bug, get it worked, commit the diff and go home for the day. This all feels fantastic!
Security is essentially about understanding how software and systems work together better than the creators so you can find, and fix, security weaknesses in the aggregate system. The work here…
A reasonable mission for an application security team is to find and fix security bugs in a codebase. I held this view at one point and I now think this is subtly wrong and instead we actually care about outcomes, not bugs.
A bug is a discrete flaw in software.
An outcome is a bug + how it was used. How did the story of the bug end? Did it lead to a breach or was it snuffed out early in development. …
A while back I changed from an engineer to a manager.
With that came a whole new set of manager-y words that I had previously nodded along with but not deeply understood. This article is my definition of these concepts in a way engineer-Collin would understand.
Engineers build¹ a $thing. Managers build the team that builds a $thing.
Everything revolves around each groups respective focus, including the vocabulary.
Conversation around software engineering is rooted in detail: scale, design, trade-offs. The manager-side equivalent are more abstract but revolve around: team direction, health, output, etc.
As an engineer I remember hearing these…
There are these two young fish swimming along and they happen to meet an older fish swimming the other way who nods at them and says “morning boys, hows the water?”
And the two young fish swim on for a bit and eventually one of them looks over at the other and goes, “what the hell is water?”
David Foster Wallace, 2005
In security, risk is that stuff all around us whether we realize it or not. This article is my take on how businesses think about risk and how that affects our domain of information security.
On day 1…
Because software has inherent vulnerabilities, smart security teams build protections inside and outside their code to help prevent exploits. The goal is not only to limit the impact of an unknown vulnerability, but to prevent future vulnerabilities from ever being written into code. To do this effectively, security must be present and involved throughout the entire development process. This is the purpose of the product security team at Uber.
We see security as a subset of quality. Alongside performance, usability, maintainability, correctness and cleanliness, security should be a quantitative consideration when writing software. …
Working in software security for a while I’ve recognized a few core ideas that have helped guide the efforts of a product security team. I want to share these primitives and the opinions built upon them as essentially how I think about product security.
All of these ideas are seen through the lens of product/application security but may apply to other aspects of information security as well.
Taking a simplified view companies hire a security team to prevent them from being hacked. Product security is responsible for the portion of that goal surrounding the security of the codebase. …
When software security flaws can fetch over a million dollars it is useful to examine why building secure software is so difficult.
All our work in security rests on these difficulties and this article aims to collect the specifics inherent in application security so followup articles can offer solutions. It is not meant to be defeatist.
Securing software is hard but even writing it somewhat correctly is difficult. Finding security bugs in a subcategory of finding bugs in software.