Designing a Defensible Network

2017 has been an eventful year so far in the information security works, with the return of the network worm used in apparent nation-state attacks.  With the most recent attack, alternatively known as Petya an NotPatya, among other names, the focus among many in the industry, particularly early on, was that it spread via EternalBlue, and whether or not an infection in a company indicated bad patch hygiene.  Much debate continues to rage over the initial method of infection, with some reliable sources indicating that the malware was seeded into Ukrainian companies through an update to the ME Doc tax application, and others indicating that it was delivered via a malicious email attachment.

These debates seem to miss the larger point.  While it’s interesting to know how a particular threat like WannaCry or [Not]Petya initially entered a network and the means by which it propagated between systems, there are many possible ways for the next threat to enter, and many ways for it to propagate.  Implementing tactical changes to defend against yesterday’s threat may not be the best plan.

On the Defensive Security Podcast, we poke fun at the blinky box market place, and I particularly rail on Active Directory.  I believe the WannaCry and [Not]Petya outbreaks exemplify the core concerns that we are trying to convey: as an industry, we seem to have gotten away from core principles, like least privilege, and are looking to stack supplementary security technology on top of ill-designed IT systems.  Our security technology mainstays, like antivirus and IPS, are constantly chasing the threats.   Those technologies are wholly ineffective against broadly and rapidly propagating worms, though.  Hopefully, these recent events cause a rethink in fundamental security strategies, rather than a search for the next technology that promises to deliver us from the perils of worms.

Having said that, here are a few fundamental, completely unsexy, things we can do to mitigate these types of attacks in the future:

1. Use unique local administrator passwords on every endpoint.
2. Disable network logins for local administrators on every endpoint.
3. Implement properly designed, limited, and segmented Active Directory permissions.
4. Implement the secure administrator workstation concept.
5. Implement network port isolation.
6. Block connections to Windows services for all systems to and from the Internet.
7. Disable unused protocols, including SMBv1 (and continue to monitor for newly deprecated protocols).
8. Apply patches quickly.
9. Remove local administrator permissions.
10. Implement application whitelisting.

All recommendations like these have a shelf life.  That is why we need smart people who monitor the threat landscape.  If we do a good job of preventing the basic tactics, the adversary will inevitably move to more complex methods.