What are best practices / recommendations / strategies for mitigating zero day threats/attacks from a software development perspective?
Are you a software engineer trying to deal with attacks against software you produce, or a user defending against software which others designed that you just use, or an IT organization, or something else?– nealmcbFeb 11, 2012 at 22:41
Hi nealmcb, I am mostly asking the question from the perspective of a software engineer trying to deal with attacks against the software that is produced. Besides following best practices...I was look for any other strategies (that are unknown to myself) to follow during the software development process.– Eric WarrinerFeb 15, 2012 at 15:56
By definition, you can't defend against a specific attack that you don't know about beforehand.
However, if you implemented a complete, Secure Development Lifecycle through all the phases, including appropriate Threat Modeling, and you mitigate the threats (not the attacks) - then you should be relatively okay.
The most common software vulnerability is well known to be buffer errors that allow buffer overrun attacks (i.e. code injection). Apr 9, 2016 at 0:00
2@BrentKirkpatrick, I'm not quite sure what your point is here? (And btw, BO has not been the most common in quite a few years... And code injection != buffer overflow...)– AviD ♦Apr 10, 2016 at 8:30
The point is that you can defend against attacks that you do not know about before hand. If you can find a way to defend against buffer overruns, you defend against a large majority of the attacks out there. I am agreeing with your main point: SDL. Apr 10, 2016 at 12:55
Sure, there are other ways to do code injection, besides buffer overruns. Such as user input that is evaluated as code. Apr 10, 2016 at 12:57
The best way to mitigate zero day exploits is to prevent zero day exploit writers from writing zero day exploits.
The best way to prevent zero day exploit writers from writing zero day exploits is to encourage them to find other ways of making money or gaining fame, which would require making data exfiltration less easy and less profitable, as well as making identify theft and the concept of "hacking" less fun.
In order to make data exfiltration and identify theft less easy/profitable, we must somehow change the game i.e. get rid of payment card data and government issued identification such as social security numbers. We may have to change the way that we use names and numbers, especially together.
In order to make hacking less fun, we need to make it boring and useless, possibly by making a more novel activity more exciting than hacking, and somehow make hacking less exciting than say, underwater basket weaving or underwater accounting.
If the above methods fail, then perhaps it would be best to discourage criminal use of zero day exploits by criminal rehabilitation, imprisonment, fines, and other forms of punishment. However, in order to exact punishment, first we must catch criminals using zero day exploits. Some pseudo-criminal use of zero day exploits is "above the law" much like espionage is at the nation-state level (e.g. the fictional character James Bond has a "license to kill" and there are perhaps some hackers that have "licenses to use zero day exploits").
Assuming that also fails, then we must make it too expensive for zero day writers to write zero day exploits. I believe this is the strategy Microsoft has taken with regards to some of their products. This exists outside of the SDL, and it typically involves exploitation countermeasures such as DEP, ASLR, and the use of techniques found in tools such as EMET.
Some Linux contributors have taken this route by inventing ASLR and implementing other concepts in their grsecurity kernel patches. However, neither Microsoft or the grsecurity developers can forsee non-traditional exploits, such as web application based ones, kernel exploits, race conditions, and other esoteric or design based flaws.
Technology-wise, it is much more difficult to solve the zero day exploit problem. This is why I have mostly provided a laundry list of human solutions to the zero day exploit problem, which I believe will have more impact. I am not an expert at solving these human social problems -- if I were, I'd be using these magical powers to fight hunger, disease, or other issues that are much more profound than zero day exploits.
Maybe it's best to just let zero day exploits happen. You can't stop them from being released. One thing you can do that is sure to help your organization become less of a target of zero day exploits is to run on infrastructure that has never (or much rarely) been targeted by zero day exploits, but this can lead to security by obscurity. As an example of this failed strategy, AOL used Stratus fault-tolerant equipment, but this did not prevent them from being hacked.
One of the best known methods to date is to leverage honeypots, file/kernel/memory/process integrity monitoring (e.g. BitLocker with TPM, Tripwire, etc), and subterfuge to provide levels of defense, and then to follow with a swift and merciless offense, much like modern warfare. Again, this involves mostly working at the human layer without a lot of heavy technology lifting. Some of these methods can be combined using business intelligence techniques, and this is what some SIEM products (and the OSSIM open-source SIEM tool) attempt to do, but these are still in early stages of maturity and progress, so they should not be relied upon by themselves, but part of a larger methodology and counter zero day exploit management program.
1Do you think internet security will catch up with the real world (i.e. get aggressive and neutralize threats?) Did you say you want to hack our servers? Sure, let me mention a good friend from the Русская мафия may stop by to say Hello! Nov 15, 2010 at 0:05
@Tate: Yes, but I think we have a 100-year war ahead of us. It has been over 130 years fighting the American Mafia and they still make $90B/year.– atdreNov 15, 2010 at 1:24
Atred, I like your point about our habits. That kind of movement is intrinsically connected to what the World Wide Web is becoming, mainly when talking about collective intelligence, reasoning, semantics and so on. We can't expect easy ways to do things when we are fighting against ourselves. I know, this is somewhat a utopia.– user4610Sep 20, 2011 at 5:18
EMET link is broken. Could you, please, if possible, fix it? Dec 21, 2012 at 17:34
If your talking about Zero Day attacks against any application within your network. I would suggest:
Using Ingress filtering at the network firewall and also use Egress filtering so to limit what traffic can travel outbound from your system meaning that if a machine was to be affected by a Zero Day exploit hopefully it would not be able to communicate outbound.
Using an IDS / IPS to detect unusual traffic patterns may also prove to be effective.
One point not quite mentioned by Avi or Mark is the old mantra of "defence in depth." It may be a very hackneyed phrase, but with multiple layers of security an attacker needs to use more than one zero-day to gain access, and every layer can provide more opportunity to spot the attack (through IDS etc) or to respond.
Definitely develop the SDL, and use IDS, IPS and other tools, but build a secure architecture and it will improve your security measurably.
that mantra is a good one, but only of many that would be included in an SDL. A secure architecture is one of the many results of a SDL, and SDL is really the only way to ensure it.– AviD ♦Nov 29, 2010 at 5:56
If you mean protecting yourself from a known vulnerability in an application that has no official patch yet, here are some ways:
If it's open source software, there are usually unofficial patches available very quickly. Otherwise, you can even try to patch it yourself if you have the resources.
Vulnerabilities oftentimes depend on specific configurations/set-ups. Try and see if you can set up a configuration that would not be vulnerable (i.e. disabling an extension).
Nothing else I can think of apart from the usual security methods that are not specific to the question.
2Zero day means that it is an unknown vulnerability that is being exploited, does it not?– MagnusNov 12, 2010 at 0:01
1@jaffachief, correct but that is fundementally hard to plan for, Olivier is dealing with the specific case after the vulnerbility is known but before it is patched. Nov 17, 2010 at 2:51