Threat Modeling for Network Devices

A customer with thousands of on-premise switches, routers and storage arrays is preparing to use their Snowflake data warehouse for detecting threats targeting the network devices. After setting up syslog collectors to aggregate device activity logs into Snowflake, the customer’s network operations team is ready to kick off the security analytics. But what sort of questions will the data answer?

Actionable Detections

When setting up a new security analytics use case, start from the basis that analytics on their own won’t generate any value for the business. It is only when security analytics drive action that there’s payoff. The purpose of security analytics is to move people to harden configurations or remediate attacks.

The top way in which security analytics can drive action is through alerting. Alerts are pushed out to the team for review and investigation when new data matches predefined detection logic. That detection logic, represented as SQL queries when the security data is in Snowflake, is the result of preparation in the form of threat modeling.

Threat modeling

With actionable insights as our goal, we begin the exercise of threat modeling. In this case, what are the threats facing the customer’s network devices? How might network devices be targeted as part of an attack against the organization? This is where domain expertise plays the greatest role.

Two kinds of threats loom large for this customer and their network devices.

Threat #1: IoT Botnet

Consider Mirai, a type of self-replicating malware that made headlines in 2016. Mirai worked its way through millions of network devices to form a DDoS superweapon capable of breaking the internet faster than a Kardashian on a bender. Mirai’s methods of spreading included logging in through “factory default” credentials, installing its bot code and repeating the process across the network.

In this threat model, we can expect to see logins with unusual usernames (e.g. “admin1”), many failed login attempts at internet-exposed devices, and infected devices attempting to connect to many targets at once.

Threat #2: Rogue Administrator

IT administrators are usually very trustworthy and reliable. But in 2016, a network admin at Citibank got wind of his pending termination and resolved not to go down without a fight. He told a friend that “upper management need to see what they guys on the floor is capable of doing” and proceeded to erase the configurations of the core routers responsible for connecting Citibank’s nationwide branches. The banking network slowed to a crawl while the networking team scrambled to find out what happened.

In this threat model, we can expect to see simultaneous logins to a number of tightly controlled central devices. The insider might be working at odd hours to avoid scrutiny. And if our log data contains the commands being run, we might see a sequence of destructive actions being performed.

Threat Model Results

After considering the top threats that we need to detect for this use case, we’re ready to design the detections. Here is a solid first batch of alerts:

• Multiple failed logins at a network device
• Multiple failed logins at multiple network devices
• Login originating from network device
• Network device attempting to log into multiple network devices
• Device login attempt with username associated with Mirai botnet
• Device login with username not seen recently
• Login activity from public IP address
• User logged in simultaneously to key systems
• Device administration outside of business hours
• User performed destructive operations outside of business hours
• User performed destructive operations across multiple devices

The SQL code for these alerts will be published to the SnowAlert project after we apply these ideas to the customer’s data and can test for false positives over previously collected log data. If any of these alerts would have fired more than a few times a week in this customer’s network, the alert query will need to be refined or the detection itself might not be feasible.

At the end of the threat modeling exercise, the customer will have a broad set of reliable, high fidelity alerts giving them a shot at catching threats targeting their network devices.