Tag Archives: penetration test

Defense through Offense, and how APT fits there

I’m guessing that having “APT” in anything that goes outside for public consumption these days is mandatory, but this post actually has a good reason to do so. If you look back just one post in the past, we were discussing the new initiative to define “Penetration Testing”. The post, and the proposed standard itself really take a good look at what organizations need, and how to address such needs from a practical point of view, rather than from a compliance or a “check-box ticking” perspective.

For me this is one of the things that the security industry has done a great disservice to. It is exactly why companies are announcing that for every time they get breached, it was an advanced attack. An attack so sophisticated, that managed to stay persistent in their network and exfiltrate lots of sensitive information, that no reasonable control could have prevented or detected it. The all dreaded “APT”.

However, if you take a look at how organizations prepare themselves for such attacks you may find yourself staring at a blank page. Since regulatory compliance dictates a very basic “box checking” methodology for a very narrow and specific aspect of information security, and the product vendors on the other hand provide solutions that are “compliance oriented”, organizations are left with a very weak defense mechanisms. This is without even mentioning the biggest security gap in most organizations – the employees.

The lack of self-testing, of a real-world simulation of what an attack would look like, and how the organization would cope with, hinders most organizations from putting reasonable defenses in place. The lack of proper training, awareness campaigns, and exercises that stress out the human factor as well are leading us to a situation where even simple attacks that utilize off-the-shelf (and even FREE) attack tools, manage to go through an organizations control mechanisms with aggravating ease.

I’m looking back at what the penetration testing execution standard defines for its basic testing methodology, and I can clearly see how every element of the recent “APT” attacks would have been simulated, and probably in a more rigorous scenario. Such a test would have clearly left the tested organization with a roadmap that would bring it to a much higher security standard. And that’s the power of testing – of understanding the adversary’s techniques and strategies, and running exercises that reflect them in order to identify security gaps and close them as efficiently as possible. And yes – that also (and perhaps mainly) applies to human related processes and policies rather than just to technology.

So to sum things up – you may be compliant, but do not think for a moment that this compliance has anything to do with the security of your information. Until regulatory compliance does not mandate proper security testing in order to protect the data in question, such compliance is only going to hinder your “security vision”. Get proper testing, set up an internal team that would be responsible for understanding the threat communities you are dealing with (or hire an external one ), and make sure you set yourself a goal to have an unbiased understanding of what your gaps are and how well you can face a standard attack (yes – the same standard attack that you are going to call an “APT” if it would hit you unprepared).

Defining Penetration Testing

I have been fortunate enough to be working with a group of peers from the security industry over the past few months (since November 2010) on finally creating a solid definition of what a penetration testing is.

It has been a topic that has been abused, cannibalized, and lowered to a level where we (as in people in the industry) could not relate to it anymore. It was time to get the fake stuff out, and focus on content. We were all getting tired of “penetration tests” that were nothing more than a Nessus scan printed out and slapped on with the “security consultancy” logo.

Enter – the Penetration Testing Execution Standard.

This is our attempt to define what a penetration test should include – both from the tester side (vendors) as well as from the client side (the business/organization being tested).

It is the fruit of a huge collaborative effort from people who I consider to be some of the best in the industry. Getting together people who on their day-jobs often compete with each other, and come from different areas of the industry, all together and working on something as big as this has been a humbling experience. For that – you guys all ROCK!

Onwards to the content – remember that this is pre-alpha, and is aimed mainly to get feedback from everyone. A lot of branches do not appear in their full glory there, and some will surely not make it to the final edition. We welcome everyone to take a close look at this, contribute, criticize, assist, comment and generally get involved. Some of you may have been watching this and thinking we are holding back – could not have been further from the truth… In order to get to something as big as this we had to cap the number of participants in this revision in order to keep things somewhat organized, so this is a chance to get back in and offer your assistance – we promise to keep this as open as possible.

This is really exciting – for me at least. Hope some of you will be able to share this enthusiasm and weed out the industry from the bad form we got into.

Learning from stux, and connecting more dots in infosec

So everyone has been fully focused on Stuxnet – trying to figure out (again) what 0-days were involved, how were networks crossed, which command-and-control channels are utilized and how the systems were compromised.

Great.

I’m really hoping that the technical analysis would help us get a better grip on what kind of risk a persistent and well-funded attacker poses to a target. Nevertheless, it’s almost as we have not really learned a lot from past events – and yes, I’m talking about connecting the dots again. This time not in the sense of linking between crime and nation-state, but more in the sense of understanding that the technological attacks are usually coupled with kinetic ones – especially when talking about the more advanced activities.

For starters – stuxnet could not have gotten to where it did without the “human factor”. Someone needed to carry the infected USB thumbdribve and stick it into some system that was in the separate network. Call it a hostile agent, call it a paid off internal agent, or a 3rd party provider that was recruited to provide slightly modified equipment. It had to be done.

Now that we established that the “matrix” could not have just jumped across networks, let’s see what else can we learn from such an incident. As in learn whether this could affect us, and how. Which brings me to the second point:

We got nothing. Nothing in the sense of actual protection. And no, your claims that “our production control and monitoring network is physically disconnected from other networks” does not hold water anymore. It didn’t before either, but now it’s easier to point out how wrong you were.
Not only we got nothing, we keep listening to vendors that are too cheap/lazy to implement proper controls (from proper secure development, to taking into account that security measures would need to live on the systems), and completely lose focus when something proprietary comes along the way. When we should have been kicking vendors in the round ones and making sure that we make ourselves experts in the “proprietary” protocols thrown at us. Time to taste a bit of what we’ve been cooking.

Because stuxnet is not going to be hitting us soon. It’s going to be something much more appropriate for our culture and more targeted towards our soft spots. If delaying a nuclear development plan was on the top of the objective list when the operation that included stuxnet was planned, the counter-plans we would have to defend from would be different.
Think more in the lines of altering the way we perceive reality. Seriously. What if someone would be able to change what the newspapers printed tomorrow morning? What if they could change/affect what we see on TV? And no, this is not science fiction (check out what happened during Cast Led where Israel hacked the palestinian TV station, and how a retaliation effort was mounted and almost succeeded).
Such actions can be pulled out more easily than you’d think. The fact the everyone is focused on the pure technical aspects of defense left us pretty much open on any front that combined both human/social, physical and technical efforts.
Thinks furthermore on how the economy would hurt if the stock exchanges would be provided with false information (remember what happened when computers were involved in making decisions back in May 2010?).

And there’s more. Out travel, insurance and a lot of our financial systems are running on technology that was created back in the time when “strong authentication” means that you had to guess a really cryptic username. That’s right – not even a password is needed. And we are running billions of dollars on these things. They are protected of course – by separation. But network separation is not enough as we have just seen.

So back to connecting the dots. Remember my last rant? (you better!) – that’s exactly where the dots connect. Think critically of the business as a whole. Not in a system by system, or network by network scheme, but in the “how does this business work” scheme. How does the paper get printed at the end of the day? It may be easier to hack into the printing press facility control system than to the editor’s or the publisher’s network. Same goes for financial institutions, hospitals, airports, manufacturers, etc… Identify the weak spots in your industry, not in your office or your network.
And don’t blame me from giving the bad people ideas. They should be considered at least as smart as all of us are (smarter than me for sure 🙂 ). The anger that you are feeling right now reading this, is coming from the pain of sticking your neck out of the sand your head was buried in, and the uncomfortable feeling of getting a grip on reality…
Thanks for taking the red pill, and welcome to the matrix.

Now go and change things.

Pentesters and businessman are doing it wrong

Following my last post on the realistic cost of a pen-test (which as I mentioned was derived from long conversations on the topic with a couple of friends from the industry), I’d like to review one of the best presentations I have seen lately – Chris Nickerson’s Brucon talk.

I’ve had the opportunity to see this talk shape up to be what it ended up like in the week or so that we have been hanging out together. And let me tell you – it was one hell of a week. There were some reactions to the talk (no wonder – Chris was on stage) and I’d like to put things in perspective (at least mine, if you want more go talk to Chris…).

The first point which is directly derived from the talk is that we, as an industry, have been doing the wrong thing for a long time. Pentesting has become a glorified minion work, and we just kept it behind for such a long time. What the talk tries to say is open your mind, and DO YOUR HOMEWORK. Chris calls it “do work”, but I’m saying that before we do work we need to do homework. Learn. Inspect. Absorb. See beyond the technical aspects of a pentest. Understand what is the environment in which the business operates, who are the key players, partners and customers. How does the business make money? What would hurt the business the most? Only then, we can approach the pentest with a clear goal in mind (and no – it’s not getting root/shell on a box).

The second point that I’d like this talk to provoke is that we are not the only ones at fault. It’s also the customers (yeah – I said that the customer is wrong. Sue me). They have been trained to ask for technicalities. Be it a pentest, a product or even a service. Most of the times they can’t really explain the methodology behind what they are asking for and the business relevance of it. Instead of asking for a pentest for a new web application, they should be asking for a security assessment of what makes their business “tick” which may be related to the web application. Small difference in wording, HUGE difference in scope and ROI from such an engagement. And yes, this all comes back to us as we have been offering “off the shelf” pentests that have no actual relevance to the business side, and have “technofied” our services and products to fit checkboxes of some obscure regulatory compliance. We need to retrain our customers (i.e. the industry) and get ourselves trained on the business aspects as well.

This topic is just one of many more that were conceived during the security-on-steroids-week which was Source Barcelona and Brucon. I’d rather post these side-effect ideas that were generated from discussions around the talks than the actual talk contents (you should be able to download these anyway in the near future from the conference websites anyway).

The realistic cost of a web application pen-test

So I was having some really interesting conversations over the last couple of days with some of the best people I know in the security industry (yeah, I’m looking at you guys…), and one topic came up on which we all agreed and shared mutual frustrations about: the ability to evaluate the quality of a “standard” web application pen-test (web app pen test was taken just as an example for one of the many security assessments and management services we all provide).

It started off from a benign question of how much would you say that an average engagement would cost? After making sure we all had about the same numbers in place, we started comparing notes on quotes that we have seen in the field – which ranged from the ridiculous low to the obscenely high. What makes these really absurd is that on both ends you usually find the lowest quality of deliverables.

For a lack of proper time to discuss this I’m going to leave this open and post a followup quick rant on what to actually look for from your security provider and how to gauge them in terms of efficiency, quality of deliverables and overall value.