Okay folks, let’s talk about SolarWinds.

For those not familiar with it, SolarWinds is a network management system (NMS). It’s probably the most ubiquitous NMS out there, so we shouldn’t jump to conclusions that FireEye and Treasury were both breached by an SolarWinds vuln. 1/

That would be an illusory correlation. If you’re jumping to that conclusion (or that FireEye and Treasury use a common MSP), at least be clear that you’re guessing.

It’s a lot like the DC Sniper case where we focused on white vans. SolarWinds (like white vans) is everywhere 2/

NMS are excellent targets. They have access to most (often all) systems on the network, so outbound IP ACLs are not a useful control. Netflow usually doesn’t help either since the NMS not only has access to everything, but it’s also talking A LOT. 3/

NMS are usually used to monitor network devices and critical servers. If you’ve ever seen a network map with devices shown as green/yellow/red, that was probably built by an NMS.

How does the NMS generate the map? Sometimes it’s as simple as a ping command. 4/

More often, the NMS uses SNMP (network management protocol) or an installed agent to learn the status of remote devices.

Now they’re called network MANAGEMENT systems for a reason: in addition to status, they can modify configuration, restart services, etc. 5/

Not all NMS are able to change anything, and those that can don’t always allow it for all systems on the network.

The bad news is that the most critical systems are also those most likely to have change access through NMS configured. This isn’t a failure in security modeling. 6/

Recall that security also includes availability (CIA triad). The more critical the system, the more likely it is that you want to ensure the availability of it.

NMS ensures availability by monitoring for things like services becoming unresponsive and restarting them. 7/

This all happens before an admin even notices the service had an issue.

Even when the NMS is in monitor-only mode, it can still be used to read configurations, which often include enough information for attackers to laterally move to those systems. 8/

So suppose you have a SolarWinds NMS installed. Should you pull it offline? Not at all.

What should you do? Check log retention and archive whatever you have. I expect we’ll see specific IOCs for SW within a few weeks. You want data for eventual threat hunting. 9/

Regardless of which NMS you use, you should absolutely lock down access to the admin interfaces using access control lists.

Consider monitoring and alerting on any attempted access to the admin interface as well. 10/

If you have East/West netflow, consider doing some analysis of NMS traffic and looking for outliers. That won’t be easy in most cases.

I’ll close by reiterating that hitting an NMS like SolarWinds often gives attackers keys to the kingdom. It’s like domain admin++. 11/

But that doesn’t mean you get rid of your NMS. You just need to threat model routes to target your NMS and monitor the heck out of those.

You should probably also revisit the systems managed by the NMS and model whether the juice is worth the squeeze (it usually is). 12/

However, in most orgs the NMS is configured by ops (who maximize availability) vs security (who usually maximize confidentiality). Do some threat modeling.

TL;DR - Don’t throw out the baby with the bathwater or you’ll likely be flapping in the (Solar)Wind... /FIN

This thread brought to you by Cypher, who was a good boi and let me type this on our night walk.