‘Challenge [defenders] to take a penetration testing or exploit development class.' Andreas Lindh
Copyright © 2014 Virus Bulletin
Defence is hard. From a defender’s point of view, it only takes one slip-up, one misconfiguration or one unpatched machine for an attacker to gain access and capitalize with potentially disastrous consequences. Not only that, but it is also very difficult to know if or how well your defences are working. Sure, you can measure it to a degree, but only for the events that you and your security products can actually see. For an attacker, it is pretty much the other way around; they usually know if what they are doing is working or not.
One of the major problems for those tasked with defending networks is a lack of knowledge about what they are supposed to be protecting against, on a technical level. A lot of defenders are former network or firewall administrators who are great at TCP/IP and routing, but seriously lacking when it comes to understanding how exploits work or how security products can be bypassed. This, coupled with the way some vendors are marketing their products (basically as self-playing pianos) has in many cases led to investments in and reliance on automated security products instead of competence and personnel development. I believe that this is a dangerous road to travel as attackers will always be able to subvert security products that are run in out-of-the-box mode.
There are few areas where such a lack of knowledge becomes more painfully visible than in Security Information and Event Management, or SIEM. While, for example, an IPS or anti-virus product will still do some level of good if you do no more than install it on your network and make sure it gets updated occasionally, a SIEM will not do anything except generate a (huge) bill. Although most vendors will include a set of default correlation rules, being welcomed by 12,000 so-called ‘security events’ the first time you log into the management interface is an overwhelming experience for anyone. The point is, if you don’t know what you are looking for, a SIEM is only likely to cause you pain.
So what can be done? Well, for a start, defenders need to be allowed to develop their offensive skill set. Instead of routinely sending security staff to some vendor supplied or defensive training, challenge them to take a penetration testing or exploit development class. By knowing and understanding offensive techniques, defenders will be able to start thinking like attackers and defend accordingly. If you don’t understand what post exploitation is or how it works, how are you supposed to be able to spot it going on in your network? And how are you going to be able to detect an SQL injection attack on your web application if you don’t know anything about attacking web applications? The challenge here is to make sure that defenders get offensive training that actually reflects current, real world attacks, and not outdated techniques that are only used by penetration testers.
Another area defenders need to be more proficient in is threat intelligence. Although most vendors have some kind of offering in this area, they seldom offer anything that does not relate directly to their own product(s). While these offerings can certainly be of some use, a more vendor-agnostic approach is needed. The point of threat intelligence is to be able to make informed decisions on defensive prioritizations by studying actual attacks and trends. This is an area in which defenders in general could get more involved by doing their own research and contributing their own conclusions to the security community as a whole. (It should be noted that to be able to do this, a whole different skill set from configuring a firewall is needed.)
To conclude: it is time for defenders to go on the offence. It is time to stop defending based on gut feeling and outdated best practices. It is time to start making informed decisions based on real attacking knowledge and intelligence. After all, a defender who knows nothing about offence is effectively no more than a system administrator who happens to manage a security product.
And there is no reason why defenders cannot be hackers too. I know I am.