I’ve said it before: The No. 1 problem with computer security is poor root-cause analysis, where security pros fail to identify and track the ways an environment was exploited, be it malware or human attack.
Common root causes include social engineering, password guessing/cracking, unpatched software, misconfiguration, denial of service, and physical attacks.
If defenders worried about the right root causes, they’d concentrate as much about adware finding its way onto a computer as they would a terribly malicious Trojan. Both require equal effort to defend against. Figuring out how to stop break-ins is the ultimate objective of any defender, and understanding root causes goes a long way toward that goal.
To find out what malware did, all you have to do is disassemble its code: It can only do what its instructions told it to do. Determining how it got in is a lot harder. You can often follow a hacker’s movement around a network using event logs. But it’s more difficult to find the root exploit used to breach your defenses -- particularly when management is screaming in your ear to stop such and such critical asset from going out the door.
Here are some ways to do better root-cause analysis:
1. Training
Make sure every defender -- maybe every employee -- in your organization understands the importance of root causes. It needs to be top of mind for everyone and built into as many tools as possible. Don’t skimp on the tools and instrumentation (or upgrade/adjust existing ones) to help you determine root causes.
2. Forensics
Whenever anyone performs forensic analysis on a device, tell them their primary task is to determine the root cause of the initial exploit. Many forensic investigators don’t look anymore -- or if they can’t figure it out right away, they don’t even try. Change their mind-set. Tell them even if they can’t figure it out with 100 percent confidence to take their best guess. I’ll take a forensic analyst’s best guess over a zero in that box any day.
3. Malware identification
Many malware programs can be spread only a certain way: some via mobile devices, others through drive shares. Others infect using Java, social media, or centralized file drop locations. You’ll always have your Confickers (such as malware with multiple, built-in methods of spreading), but a large percentage of malware spreads in exactly a single path (social engineering, drive share password guessing, and so on). If you can’t narrow it down to one item, take your best guess.
4. Gang affiliation
Many malware and hacker gangs excel at one specialty. For example, the Syrian Electronic Army phishes companies whose users share the same passwords among their corporate accounts and social media. Some cyber gangs prefer to abuse weak DNS configurations or love to compromise PKI certification authorities. Others shine at breaking in at the network level or hacking wireless airwaves. Knowing who is involved can give you a clue about how they got in.
5. User conversations
I’m a big fan of asking users how they thought they got compromised. Granted, users aren’t trained forensic investigators, but often they have some idea of how they were infected. Part of the problem is we often don’t ask. For example, think about how many malware programs your antimalware scanners find on a daily basis on your users’ computers. In the process of cleaning them, how many times have a few questions determined how the malware got there? If you get an answer, make sure you save it in a root-cause database somewhere.
6. Sampling
You don’t have to know every root-cause event to get useful information. A little bit of sampling can give you insight into real problems. If you want to be a little more professional, break out your statistics program and calculate how big your sample size has to be to accurately measure the larger population. Using statistics and math will help you make better guesses.
7. Risk by inventory
Calculating risk by inventory is a great method for backing into root causes. Take a software and hardware inventory -- then track specific configurations to the percentages of compromises. For example, how many computers get infected when they are running Microsoft Edge, Internet Explorer, Chrome, Firefox, Mozilla, or Safari? How many exploited computers were running unpatched Java versus patched Java? How many were 32-bit versus 64-bit? How many were in the accounting department versus IT department? How many were managed versus unmanaged? Many times you’ll see distinct advantages to running specific configurations, software, and hardware.
Reaping the benefits
Ultimately, you want to capture root-cause metrics and track them over time. You want a chart or report that lists the various ways badness broke into your environment and figure totals and percentages. You want to know how much each root cause happens in your environment, then tie those methods to damages and losses in the organization.
Congratulations! Once you do that, you have a risk assessment you can really work with.