Tag Archives: red team

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).

the art of not thinking about elephants

We have been quite busy here at Security Art in the last few weeks (as the blog posting frequency suggests), but I figured I would provide a quick preview of some of the elements we have been working on in terms of risk management.

Now, I suppose you have read Yoram’s earlier post about risk informed decision making, so I won’t elaborate on this for too long, nevertheless, we are often posed with the question “so how does this apply to my organization”. this usually comes form someone who did spend a lot of time and resources on the technical aspects of their network security. The answer is usually “let’s take a look at how you do your business”, which is what we usually do anyways…

Having that in mind, we set off to investigate in a few recent engagements how would some of our clients actually fare against an informed and skilled attacker that has been commissioned to break into the organization. These engagements have been prompted by a few incidents in which the organization in questions was basically left in the dark as they were basing their forensics on the tools that commercial security vendors provided them with, and nothing much more than that (remember the ever expressive “generic” detection from your AV vendor… Ever wonder what it really means?).

With that in mind, and a network to steal data from as a target we accepted the challenge. The only caveat is that the network was disconnected. For real. No Internets…

But (and there’s always a “but”), there was a voice network that went out through PSTN to provide the office with telephony connectivity. Bingo. Ever seen a complete separation of the VOIP network and the internal network? yeah, neither have I. To make a long story short, we managed to get the data in the most old fashioned way possible… we beeped it away (actually transmitted over a VOIP connection using a custom written simulated trojan that encoded the data into audible voice signals and left them as a message on one of our voice mailboxes). Done deal. (and the PoC code can be found here if you’d like to play with some of the conecpts).

Bottom line – always remember that when you think of solutions, you should not be “blinded” by what’s available out there and the accompanying marketing materials. That’s basically the “pink elephant” that vendors tell you not to think about when pitching their solutions. You usually end up thinking about it (and buying the product thinking that you’ll never see that elephant again as you just bought the best “anti-elephant” solutions…).

Always challenge the way you think of networks and processes (we did have to get the code INTO the network somehow… but that’s for another post ๐Ÿ™‚ ), and ALWAYS test your assumptions and protections. You’d be surprised how easy it mat be to out-compartmentalize you just because you were boxed in to take care of just a single aspect of the security 9and yes – that even applies to CIO’s, CISO’s, etc…).