We have Microsoft Tuesday, so how long until we have Indicator Wednesday?

Recently, Tenable's Research team created Nessus checks and log searches to look for indicators specified in the Mandiant APT1 report. Our response was not unlike a typical Microsoft Tuesday afternoon where our team writes active, credentialed, and passive checks for missing patches. There are a lot of other indicator sources and following the press surrounding the APT1 report, there will undoubtedly be more disclosures. When this steady stream of indicator disclosures starts, there will likely be an outcry from IT security professionals everywhere to align these releases to a certain day of the week for the same reasons we have Microsoft Tuesday.

With the exception of out-of-band emergency patch announcements, the Tuesday release cycle balances the timeliness of a patch release with the realistic expectation of getting patches deployed on a typical five-day work week. Releasing information about a patch on a Friday afternoon isn't good because it assumes an adversary will put in the long hours to exploit a target whereas it can't be assumed that every organization has the ability to surge a IT team over the weekend to deploy the patch.

So how similar are releasing indicators as compared to deploying patches? There are actually many similarities on the blocking and active monitoring side. I'm currently attending the RSA conference in San Francisco, where Tenable sponsored a reception with 50 CISOs. I asked many how they handled deployment of indicators (focused narrowly on lists of bad actor IP addresses) and what sort of operational impact there was. Turns out there is a lot.

Change Control

On a large network, whenever you make a change to a router ACL, a firewall, a NIDS configuration, etc. you have to open a ticket, document the change be able to roll back the change if things go bad. Adding lists of hundreds, even thousands of IP addresses, DNS names, etc. to network devices can be very tricky, especially if you are manually cutting and pasting from PDF reports or web pages.

Most modern security vendors can apply "hot" updates to their devices, but many organizations who deploy these tools still seem to want to schedule changes along with reboots.

Limitations of Equipment

Not every WAF, NIDS, SIEM or other device can support filters of 1000s of IP addresses (or domain names). Some can and some can't. Some support a long list but then their performance drops off. One CISO I spoke with had a team where the IP addresses being considered were prioritized and only the top 500 were pushed to their perimeter devices for filtering. Another had so many indicators, that their list of IPs was greater than 50,000.

False Positives and Local Hits

One CIO I spoke with subscribed to a variety of IOCs and early on had to modify their process of implementing blocking rules to make sure none of their IPs were on the list. If an IP address or network block from your network is on someone else's bad guy list, and you end up adding ACLs or IPS rules to stop access to it, you will cause a self inflicted denial of service address.

This type of analysis may be the most difficult because it requires a human to do some thinking. Keeping track of an organization's IP addresses is more complex then just seeing what is in a public registrar database. Modern organizations have home users that VPN in from networks that are often listed as being part of botnets. You may host a website at a hosting provider that has a botnet on a different subnet. Your network could also be so larger that you really don't have a great list of where all of your IP addresses are at a given moment.

List Attribution

Another CISO I spoke with expressed some frustration in being able to track which IP came from which indicator list. At the device level, there was no ability to push unique sets of IP addresses for blocking so when there was a block, the IP in question had to be looked up manually. In this case, the CISO was hoping to share indicator activity with government and other peers.

Historical Search Limitations

Earlier in the blog, I specifically mentioned that response to these indicators has impact for active monitoring. From a pure reporting point of view, searching last year's logs of network traffic for indicators only impacts the SIM or log solution and not network security policy. I feel this should be the first use case for analyzing indicators, but the vast majority of IT security professionals I talk with want to stop traffic on their network right now with IPS rules and firewall ACLs. This is even more true if the organization doesn't have a years' worth of DNS logs or network traffic to search. Long term attack pattern analysis is less time critical because you are really spinning up an effort to see if you need to organize an incident response team. Organizations that only focus on today's events and preventing today's attacks may miss the fact that they have been compromised for years.

In conclusion, I'm looking forward to reading more research and content from security firms like Mandiant and I encourage the community to be aware of the impact that sharing their research has on IT security staffs around the globe.