What are the best practices for mitigating zero day attacks?

Question

What are best practices / recommendations / strategies for mitigating zero day threats/attacks from a software development perspective?

Answer 1

Holistic SDL.

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.