Pentesting isn't enough - "Part 3"

My friend Serg over @ SecuritySoup.com recently made these two posts about pentesting and I must admit it gladdens me immensely to see posts like this. I won't divulge too much about Serg in the interests of maintaining his privacy but I will say he is an experienced penetration tester and security consultant and in short, knows what he's talking about. Before I begin this post, you really need to read what he's written first.

I think I'd learned this lesson several years ago in my last job - and I know he has too but I think for Serg had the points hammered home to him over the past two years in particular on the basis of some of the clients and types of engagements he was working with. It's one thing to know something but another entirely to have the point really hammered home to you or see it demonstrated time and time again.

One of the things I am convinced you become aware of the longer you work in technical security space, the more you realise that the governance and management aspects play a critical factor in ensuring the success of a security program. Having said that, there's a world of difference between wanting to be a security manager and recognising the need for security management.

I have no desire to be a manager myself but I've seen first hand why non-technical skills are absolutely critical to ensuring the success and I'll give you an example:

I was a security lead on a very large project (large iconic brand shall we say?) and the one project was going to bulldoze ahead to go live without a critical security feature which was absolutely necessary to ensuring success. Without it, I am talking front page news headlines, loss of consumer trust, irrepairable brand damage, basically a post-apocalyptic security nightmare.  At this point in my career I had come mostly from a tech background and I had flipped out that this was going on. I realised that the Project Managers, Business Analysts, Programmers, etc. -- NO-ONE cared about security.
I couldn't understand why.


I had to learn (this job was a real baptism by fire let me tell you) how to convince people. I had to relate these risks back into business terms that they could relate to and why they needed to.

Pretty soon, nobody saw the problem I pointed out as a "security problem" it became "a problem" that each project member saw in their own way. The Marketing head saw it as being "detrimental to the end user experience". The Governance board envisioned "irrepairable brand damage". The Head of IT imagined his entire online presence having to be rebuilt and his Application Support team working overtime for the next six months. I eventually got funding to do the work that was needed and divert resources to develop the necessary controls to prevent this from happening.

Now if you are just a pentester and all you know is how to break stuff, then I suspect you would find it highly challenging having the above conversations. Infact, I know plenty that have no interest in having those conversations either - and that's fine. It takes all sorts of people to make this world go around and it would be horribly boring if we were all the same.

But to be a consultant you do need to be able to have these discussions with a variety of people. You have to understand what motivates people and speak to that motivation. Tony Robbins is often quoted as saying that people will do more to avoid pain than to gain pleasure - and this is certainly true in a business context.


Serg's point is that too many people lack these skills and it is these skills are most important. With the increase of technical jobs going overseas, the critical differentiator becomes the understanding of the client's business and how security fits into that. This is the lifecycle he's referring to. These are the sorts of questions such a consultant might find himself asking:

• How does penetrationt testing fit into your application development process?
• How much of that testing is handled by other test teams before a security specialists does?
• Are you doing code analysis, threat modelling, architecture reviews prior to development?
• Post launch, who is monitoring your applications, infrastructure and your data and how?
  

By no means is this list comprehensive but demonstrates the point.Technical skills are important. But to work in today's world as a consultant, you need more than that. I've worked with some brilliant technical minds (and I mean brilliant, not just skilled) but could also understand clients and their businesses. They can pentest anything you put infront of them (and I mean anything). It is certainly possible to have a good mix of both. The question is whether you want that mix of skills? If you want to remain a consultant in today's market, you have to have a service differentiator.


Now if you're relying on technical excellence as the only factor, you may be in for a very rough time. The basic law of economics dictates that people seek alternatives. If they can get the same service from someone overseas for a fraction of the price for equal skill (or even lesser skill) then a lot of people will make the trade-off if they perceive it to be of value. I'm not saying this is right or wrong, but that's the way it is. There are ways of dealing with this but we - as an industry - cannot continue to do what we always used to, never change and expect things to function as they used to. Times are changing and so too must we.

I guess the crux of the post is this -


It's one set of skills to be a hacker. It's another set of skills entirely to be a security consultant. Being one doesn't automatically make you the other. Serious hackers laugh at guys like me with their CISSP. That's fine. I laugh at guys like them who wouldn't last a week in a corporate enterprise environment dealing with the baggage I've had to. Like I said before, it takes all sorts to make this world go 'round.

I read Serg's post is a wakeup call to the pentesting community. If all you know is how to pentest, then times are looking grim. If you cannot properly engage the business, understand their language and communicate in their terms, think in abstract terms of principles and concepts and not just lines of code, then you better start learning or otherwise re-evaluate your day job. Your job is going to go to India or the nearest CompSci grad with a CEH who will undercut your daily rate.

If you don't believe me, then you better open your eyes. It's already happening.



- J.