WannaCry Response

WannaCry hit. There are a million excellent write-ups on the malware. How about one about how to respond if it isn’t via a help desk ticket notifying you of the malware?

Initial reports started coming out in the morning of Friday May 12th that NHS was experiencing a significant outage due to ransomware. I didn’t think anything of it. Ransomware is common enough. It wasn’t until it was specifically given a name and a mention that the method of spread was via MS17-010.

  • In previous incidents, email was the attack vector. Everyone seemed to initially assume there was an email.
  • Windows XP was assumed to be the weakness, instead it is looking like Windows 7 was the weak link for most organizations.
  • Given SMB was the attack vector, how does an organization respond? Most rapid responses for WannaCry seem high risk.
    • I suspect an organization with SMB open at the edge could block it with minimal impact. Throwing up ACL blocks to segment the network or disabling SMBv1 under stress seems like an extremely high risk change.
    • Endpoint vendors (ex: McAfeeSymantec, and Trend Micro) released guides for customers. These seem like lower risk mitigations.
    • Given the attack was on a Friday, ‘malware Monday’ was my real concern. A device leaves a secure network missing a patch, spends the weekend on the open internet, then comes back. Even one device is an issue, let alone any file system it can access or internal movement as it spreads. ACL blocks are high risk, private VLAN’ing would be an absurd to implement as an emergency change.

PS: Splunk finally started releasing dashboards around major security incidents. I’ve been asking for dashboards from them for years. The dashboard seems really well done. It has use cases and an export (with the Splunk logo) suitable for leadership. If I weren’t sure what to do, this is a great start and a great advertisement for the benefit of Splunk come renewal time.

Finish Or Start New?

What’s better for security: finishing the deployment of a functional product or start fresh with the modern product? It seems like it really depends on circumstances.

I had an alright MSSP. There were some problems though. Picking a new MSSP allowed me to fix some configuration issues I couldn’t resolve due to organizational inertia.

On the other hand, I had hardware for network segmentation and additional hardware would have been pretty affordable. My issue was a lack of FTE’s. When leadership buy-in was available, we had to use a hot new product and start over. I’m not sure we were any better off after the replacement. The new product wasn’t really doing anything that much better. It had the potential, but we lacked the FTE’s to make it happen.

Similarly, I went from an integrated IDS/IPS that wasn’t managed to a newer modern profiling stand-alone IDS/IPS. Given the previous product was integrated, I’d argue we’d clearly lost effectiveness since the FTE cost was higher with this stand-alone product.

On to Monitoring.

I’ve got a SIEM type product. It’s not fully deployed, but who can say their SIEM is really fully deployed and tuned? I’m looking at UEBA and analytics platforms, but I suspect my time would be better spent focused on a well tuned SIEM than 3 partially deployed platforms. The vendors mostly agree/admit that the platforms all have steep FTE requirements for success.

Microsoft ATA is extremely affordable and claims to be a UEBA type product. It’s ignoring the non-Microsoft user realms, but can an attacker get in and get data out of an environment without touching anything Active Directory?

I couldn’t begin to write anything close to comparable to Anton Chuvakin’s blog post on the subject of security analytics.

It seems like money and FTE effort would be better devoted to furthering a SIEM deployment completeness / maturity.