While participating in a security conference, I was asked a very important question: "How do we protect ourselves from Zero Days?". My answer: "There is no such thing as zero days". Crazy right? How can that be true? People report "zero days" everyday, so how can that statement be true? And how does that answer solve the problem? Fear not fair reader, all will be revealed! Lets dig a little deeper and find why there may not really be "zero day" vulnerabilities and why protecting against them isn't as hard you may think.
|
|
Note: Details in this article, such as methods, dates, times, IP addresses, code, and elements of the attack have been modified, deleted or altered to protect sensitive aspects of this case.
More often than not, we expect attackers to follow a path that reflects a preconceived notion of how we think they will behave. As mammals, we tend to fear what we can see, and with cyber security, it is difficult to visualize or even imagine what an attacker can do or even how patient or sophisticated they can be. Furthermore, we may dismiss what could be deemed as too complicated and/or implausible. For example, when the Internet became commonplace 15 years ago, SQL injection attacks were unknown, before that buffer overflows attacks were also unknown, before that wardialing way unknown. We now take them for granted, but then we either didn't imagine they could occur, or we dismissed them as not credible.
With cyber attacks, the issue of imagination is especially important when considering how to better protect information, personnel and assets. If it is possible, not just plausible, then the attack can happen when an attacker has the resources, time, knowledge, and motivation. Approximately five years ago, we were tasked with responding to an incident involving the compromise of a high value trusted asset by a very clever group of attackers. The methods the attackers used were outside the realm of what the victims expected, and they were compromised as a result.
|
Mon 30 Jun 2008 |
Written by Casey Priester
|
| |
Penetration Testing has been a part of information security since the early 1990’s, yet it is still a very much misunderstood practice – many consider it something of a ‘black art’. Many CIOs and ISOs get excited at the thought of hiring a firm to perform a penetration test, because they imagine the very act of commissioning one somehow validates the idea that they and their organization are serious about security. This notion, combined with a lack of understanding of the realities of penetration testing and misconceptions about what penetration testing entails, tends to distort expectations about the penetration testing process, means and results.
In practice, there are a number of very real, very important considerations concerning scope, risk and goals which must be carefully evaluated by any organization who wishes to commission, engage in or conduct ‘penetration testing’.
|
The dreaded patching treadmill
In today's IT shops, patching systems to mitigate security vulnerabilities is a regular ongoing activity, fraught with the dual risk of installing either a bad patch or the system becoming compromised because a patch has not been installed. The calculation of whether to patch or not , is governed by the trade off between the risk of a installing a bad patch, versus the risk of a penetration, which pits two equally important issues against each other. Patching a critical system may break it and failing to to do so may leave it open to a security vulnerability. We are therefore forced to choose between two bad outcomes we do not want.
For example, let's say you have a critical production system that must be patched due to a security problem. You find yourself unable to install the security patch for any number of reasons, such as needing more time to test it to make sure it will not break your system, needing to wait for a maintenance window to install it, or simply not having any patch to install because it doesn't exist yet. Imagine another scenario where you receive a warning from your security guys telling you how serious the vulnerability is and your operations personnel's concern that the patch is going to break your critical system.
|
|
|
|
|
|
|
|