There will be a lot of ink spilled on this topic. My only goal with this simple write up is to provide actionable objectives. As such we’re going to start out with a few things to start out the conversation. I have already heard people thinking that this breach means that their technology stack from FireEye is now exposed. We may find that this is the case in the future but currently that is not in play. If you get an email from a customer as their vendor asking what whether you have FireEye tools be patient with them. If you read anything further read the next four paragraphs.
If you have a dedicated security operations team you should harvest the HX and SNORT/Yara rules from the FireEye Github repository. Though the information around the alert logic is sparse you should still put the alerts into your intrusion detection/protection infrastructure. Even if you don’t have a particular class of device the fact a detection fires will give you early indicators and warnings of adversary activity. Some adversaries just fire off a bunch of new tools. Don’t expect nation state level sophistication from adversaries, but it would be negative to get breached when you could have detected it. Your goal with detections is NOT ONLY to detect an attack against specific infrastructure but to ALSO detect adversaries in your enterprise. You’ve just been given a significant level of detail of possible exposures and adversary thinking. Use it.
If you are a CISO or security person you really should have a playbook for this kind of situation. This pattern of tools suddenly entering the public sphere is mundane. Events like new tools being exposed happens fairly frequently. Consider taking the IOCs and applying them to the MITRE ATT&CK framework or your favorite framework. This allows you to refine your detection logic uniquely to your environment and look for attack chains that might need to occur. It also allows you to have a better conversation with leadership about why they should or should not be worried.
If you are CISO understand just because a nation state adversary is attributed to having done the FireEye breach and theft of the tools does not mean the only people who will see those tools are nation states. The detection logic and rules themselves will give threat researchers the clues to recreate the tools in the wild. The mere existence of an idea on a tool is highly correlated with future exploitation behaviors. The tools will be exposed that the detections are written to find. The tools are likely based on open-source tools with modifications by FireEye. The exposures may generate new tool development too.
Strategic imperatives:
- Create and deploy the provided detection logic within your enterprise
- Adapt the detection/protections logic to your unique enterprise environment using some framework to analyze
- Expect the tools to change over time and get better so your detection and protection logic will have to adapt
- You should create a playbook or incident response process to handle this scenario
Perceptions:
There is a pattern to these kinds of events as seen with the Snowden disclosures and the Vault 7 tool exposures. To be succinct this exact scenario plays out every year when DEFCON and the various hacker conventions convene. You should have a playbook and standard operating procedure for how your enterprise will respond to these events. We’re all in this together like it or not. Somebody else’s breach can result in your breach. If you see a high-profile event like a security vendor being breached. You should at least warm up your incident response process. If it is your vendor (security or not) you should start your incident response process at least moving through triage and threat identification.
There will be a lot of victim blaming. How could a security company get hacked? No different than the RSA breach we don’t know all the details and may never know all the details of this event. Until we have a full timeline, a chain of events, and the associated work factors required to accomplish the exploitation we won’t have any evidence to base assessments of opinions on.
The pattern of these exploits (and all exploits) develops further. There will be new reports with basically hysterical finger pointing. Pundits will pronounce the efficacy or lack of efficacy towards FireEye. The detections will have been put in place by forward leaning parties in the enterprise space or added by vendors automagically to their products (this is not good). Some number of current detections may already be in place based on the possible nature of the FireEye tools being open source hacking tools.
Some number of false positives and true positives will be detected based on the alert logic thus kicking off more punditry. After time more enterprises and likely approaching 60 to 80 percent will have the rules and actual adversarial use will be seen. Media reporting will suggest that the tool use is morphing, and new more effective versions of the tools are being deployed. At some point the narrative will shift and an entity will be hacked using these tools (or accused of being hacked by these tools) and the question will be “If they were out for so long why did you not protect against them?”
Looking at the nature of the tools there are going to be some very hard questions asked about enterprise owners and integrated security tools. The FireEye tool sets look to exploit commodity infrastructures, common seams in those infrastructures and then allow for some level of leverage on the infrastructure. It will become a strategic discussion on heterogenous or homogenous infrastructure but once you’ve picked one or the other the protection mechanisms also have a pattern. You want to pick the correct pattern for protection based on the current pattern of your enterprise solutions. That though is a topic for another day.