What do programmers at security firms do?

Question

I have heard of security firms who consult on the security of a clients systems. All of the people I know in this field are network engineers, but I know programmers get involved in security as well. What do security programmers who perform audits/consulting actually do? Do they literally go through the codebase looking for every vulnerability in people’s legacy systems? I have always assumed that is what they did, but it seems like this would be highly unreliable and not do much more than providing a false sense of security. Note: I’m not talking about programmers who write encryption algorithms or anything like that, only those concerned with software security audits/consulting.

Answer 1

Frankly we try not to go through your codebase, we try to write tools to do that for us.

First, the theory. Security is a requirement of a software system, so like other requirements (functionality, usability, accessibility, performance etc) it should be considered at every stage of the software engineering workflow from requirements gathering to deployment and maintenance. Indeed, this is possible, and guidance exists to help software project teams do that. Even though I mainly work with iOS developers, my favourite description of "the secure development lifecycle" is from Microsoft Press.

In this model, application security begins when we're trying to elicit requirements from our users. We need to discover their security and privacy concerns, which is not easy because we are the experts, not the users, and where they do understand their security requirements they might find it hard to express them. We also need to discover what risks the software will be exposed to in deployment, and what level of risk is acceptable.

We design our application with fulfilling those requirements in mind. We write the code with an eye to satisfying those requirements, and avoiding additional risks associated with code-level security mistakes. We test the software to ensure that our model of its security is consistent with what we really built, then we deploy the software in a fashion that matches the assumptions we made about the environment when we designed the thing. Finally, we provide support and maintenance that helps the user operate the software in a way consistent with their security requirements, and which allows them (and us) to react to novel changes in the risks presented.

Ok, so much for theory. In practice, for reasons that are explained very well (albeit in a nontechnical fashion) in Geekonomics and which are mainly due to they way software companies are motivated, most of the above stuff doesn't happen. Instead, we get this. Developers will:

• hire a security guy or gal to be present when they're bidding for a contract, to show that they "get" security.
• write software.
• hire a security guy or gal to validate the software before release, fixing many problems that arose in step 2.
• patch everything else after deployment.

So what most app security people are really doing is, as you say, finding bugs. This is really a glorified code review but it's a highly focussed code review carried out by people who are experts at the sorts of bugs this review is looking for, so there still is value in getting external help in doing that. That's a general rule of teting, of course: always get someone else to test who wasn't involved with making the thing.

If we accept the above as true then it follows that people making purchasing decisions are likely to equate "capable security guy" with "finds lots of bugs". Those who get computers to do the work for them will find more bugs than those who don't, so of course they rely heavily on static analysis tools and will aim to spend more time extending the tools than coding for specific issues for specific clients. Then we conclude that app security people are more likely to write tools to read code than to read code.

** Warning: what remains is personal opinion and speculation **

Reality is broken. You will notice that the theory of software security was all about identifying and responding to the risk of relying on a software system, while the practice was about finding as many bugs as possible. Sure, that will still reduce risk, but only as a side-effect. The point of the game has become less important than "winning" the game, so the rules are changed to make it easier to win.

What can you as a software developer do about that? Play the game by its original rules. Find someone on your team (preferably actually on your team, rather than a contractor, so that they are motivated to provide long-term results rather than a quick win) who understands the importance of security and train the bejeezus out of them. Give that person the responsibility to direct the team in providing the end-to-end security described at the beginning of my answer.

Also, give that person the authority to follow through. If a design doesn't express the security requirements, it must be revised. If the implementation does not meet the security requirements, it must not be released. Your security person can make the judgement call, but must be permitted to act on that judgement. I realise this might sound like the security guy saying "OMFG security is the most important thing", but that's not what I mean. If your product doesn't meet the functionality, usability or performance requirements either, you also shouldn't release that thing.

Why would you want to do that? It ought to be cheaper: we've all seen (and probably quoted for a cheap +10 rep) the Code Complete table where defects get more expensive the later you fix them, right? Well security defects are defects too. I the real-world rules of the game, most of them are problems in the requirements that are fixed in maintenance. Is that cheap?

Ok, now what can I as a security gun for hire do about that? Well it turns out that I can refuse to play by the amended rules, too. I can tell developers that it's all about reducing risk, that this can be done at every stage, and then I can help them do that.

Answer 2

From 15 years of running security assurance programs against small and extremely large apps, environments, systems etc I would say there is a bit of everything. In my teams I have always had a few who are hardcore coders.

At the detailed level, some of it comes down to very in depth code review - as an example I am currently working on a multi-million line codebase, using tools to narrow down the possible issues, and then looking at each and every one to categorise.

(Admittedly I then hand over to developers to remediate or to explain to me why the issue does not pose a risk)

But this is a specific engagement for which the risk profile makes sense to carry out this sort of resource intensive work.

Far more standard, and much more cost effective is trying to understand the risk profile of the organisation and focus on the risks top-down, eg:

• Risk Appetite - impact to the business, threat modeling
• Governance - regulatory compliance, reporting etc
• Policies - definitions to ensure governance framework is effective
• Processes - technical and human
• Standards - definitions for each security control
• Implementation - the How To

The programming side really only comes into the last two, with code review and custom penetration testing. For some organisations it is of very low importance, for example if you have layered security controls which have already been peer reviewed extensively (various encryption types, say) then while you may check your implementation, you aren't usually going to recheck all the code as that has been done before.

Answer 3

I have never encountered any that go much further than discussing architecture/best practices in a vague manner during design and/or running attack/fritzing/exception testing suites against finished projects.

In almost all cases I can even tell what tools they use by the attack vectors they try and the manner in which the attack is carried out after one of the audit passes on an existing system.

I imagine that there are a few that actually take the time to examine code and do some review/whitebox testing, but I have yet to encounter them in real life.