0

I'm new here, and sorry if my english is a little bit broken it's not my main language.

I'm trying to put together a document/ppt for my startup with a Zero Day policy structure.

But I'm not finding real implemented flows, information, or something I can base this from (anything is helpfull)

What I found on my research mainly focus on specific discussing how heartbleed or the cve work.

I want to put something very straightforward but would love different point of views or examples if there are like:

  • We will be suscribed to receive every update automatically from the different applications, OS that we own
  • Critical updates will be reviewed, researched and implemented at top on 48 hours on all the servers
  • Medium/Urgent updates will be reviewed, researched and implemented at top on 1 week on all servers
  • Low Updates will be reviewed and implemented at most on the same month
  • A Team will monitor the audits logs of ports that are reporting status that are receiving suspected activity once a week on a internal meeting and define if new meassures have to be implemented
  • ETC
Saikios
  • 103
  • 2
  • 4
    The problem with zero-days is that you have no idea what they're going to be ahead of time. The only real "policy" you can apply to any zero-day is "pay extra attention, patch ASAP, pull everything offline if you have especially critical data", but that doesn't help at all when you're one of thirty sysadmins trying to figure out what you're supposed to be doing. – Nic Jul 11 '19 at 00:37

1 Answers1

0

The point of zero-day attacks is that they use vulnerabilities which are not known at the time they get exploited. You can thus not create a policy specifically for zero-days. But hardening the security in general also reduces the risk or at least the impact of a zero-day. Because the zero-day exploit is just the way the attacker enters the network or takes over a system or account. The actual harm against the network is not done by the exploit itself, but by the attacker using other tools and methods from its achieved privileges on the computer and in the network for espionage, sabotage, ransom etc.

Therefore the protection you add must be based on the assumption that the attacker has already successfully entered your network using the zero-day exploit, i.e. that he is actually inside your network and that you need to reduce the harm he can do there.

This means of course being up-to-date with patching since otherwise you likely have problems already with the way more common known attacks than just with the uncommon zero-day attacks. This means monitoring your infrastructure for suspicious activity, which of course means that you know what should be normal and what is suspicious in the first place. Strict and narrow separation and segmentation at network and application level and proper user permissions can help a lot to restrict the harm a successful attacker could do in your network - no matter if he came in by using a zero-day or not. And for the harm you could not prevent you need recovery strategies, like having a backup with a working restore.

In other words: know what should happen in your network and implement techniques (like microsegmentation, zero-trust, ...) to enforce and monitor the expected behavior. Expect some harm and be able to recover from it. The better you understand what should happen and the better you enforce it, the less harm an attacker can do in your network even if he has successfully infiltrated some computer/user in the network. It is not that firewalls, IDS, antivirus, SIEM etc don't help - but these are tools to enforce and monitor expected behavior and not magic wands you just need to wave. Don't expect to successfully fight zero-days by adding security on top of a chaotic network you don't understand or which behaves differently than you believe.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424