If you think that your company’s SIEM is a reasonably good solution for detecting intrusions, your probably less safe than you think. SIEMs rely largely on logs from appliances that don’t detect most targeted attacks.
Although you may agree that you can’t be completely safe, we still have to constantly strive to try to be on guard for the next exfiltration event. Based on our recent survey titled “Preparing for Malware Response”, I fear that too many companies are still relying on antivirus, next generation firewalls and checking logs with the SIEM. At some companies, this cocktail looks to be thought of as the best defense against electronic intrusions.
Gartner Recommended SIEM
According to Gartner: “SIEM technology aggregates event data produced by security devices, network infrastructures, systems and applications. The primary data source is log data, but SIEM technology can also process other forms of data, such as NetFlow and packet capture.” source
I have never seen a SIEM, report on flows well due to their lack of filtering, reporting options or ability to archive flows overtime.
Gartner goes on to state that “The SIEM market is defined by the customer’s need to analyze security event data in real time for internal and external threat management, and to collect, store, analyze, and report on log data for incident response, forensics, and regulatory compliance.” Later, the document goes on to state that “In this year’s SIEM vendor evaluation, we have placed greater weight on capabilities that aid in targeted attack detection, including support for data access, user activity, application activity monitoring, profiling and anomaly detection, threat intelligence, and effective analytics.”
Keeping the above in mind, we should remember that SIEMs look at logs generated by appliances that many targeted attacks get past without any trouble. Although SIEMs may claim that they look at flow and packet data, it is really only a tertiary function. In other words, they only do it so much as to investigate something they unearth with the logs.
Best SIEM Solution
A SIEM can only perform its functions using flow data converted to logs from a security appliance and like anything else, they won’t uncover all thefts. To monitor for thefts, most security vendors are starting to understand that it must be done over time which can’t be done with most of the Best SIEM solutions. Garter stated that a SIEM should “Provide predefined functions that can be lightly customized to meet company-specific requirements.” What Gartner says here is key and is close to what I try to point out to customers. Customization is KEY but, I’m not sure if I agree with ‘lightly’ …. although ‘simple’ would be nice.
- Q: What will detect a targeted attack?
- A: Nothing
The only defense against a targeted attack is to watch for the signs that something is being actively stolen. Shop lifters walk into stores every day. How does security identify them? They don’t know if they are a crook until they try to steal something. If they see someone suspicious, they put a watch on the person. They go back in the video footage and when they positively identify the person walking out of the store with unpaid merchandise, they nab them. In network security, we need the same type of surveillance. How do you get it?
Network Surveillance™
We have to monitor for behaviors that trigger events. If a host triggers excessive events, the Threat Index(TM) or electronic profile starts to build. This process raises awareness amongst the slew of end systems and gets the security teams attention. Flow data (I.e. NetFlow and IPFIX) are what we need to monitor and capture the traffic patterns of an advanced targeted attack. Only by monitoring behaviors with constant network surveillance can we uncover activities which expose the signs of data theft.
Flow Intrusion Detection™
Flow intrusion detection is a process whereby, simple to configure custom monitors are setup to watch for seemingly normal behaviors that begin to expose patterns indicative of unwanted exfiltration or lateral movements.
The basis for an intrusion detection method that needs modification per customer is shown below.
Above, a core switch n1-vlan-0-1 has been selected.
Hosts from the source subnet 10.0.0.0/8 will be under constant surveillance (i.e. monitored) however, if the traffic is destined for a host in the 10.0.0.0/8 subnet, it will be excluded as indicated in the filters shown above. In other words, the customer only cares if the traffic is headed to the internet. Notice that two hosts (10.1.4.5 and 10.1.5.1) where excluded as they knew these end systems would trigger false positives.
Next, a threshold of greater than or equal to 20 Megs in a 5 minute window was configured per row (i.e. per host) shown in the table below. Although everyday, end systems will violate this threshold due to the normal business process, most people wouldn’t violate it very often during the day.
The next step is very important. They edited the policy and configured a rate threshold of 8 violations in a 24 hour period which is 1440 minutes. In other words, if the host uploads greater than 20 megs greater than 8 times during the day, the notification would be triggered. Again, most companies need to customize a surveillance method like this but, the basic premise behind using flow data as a form of intrusion detection is clear. We need to look for the theft and then intervene as even the best firewall won’t block most targeted exfiltrations of your companies confidential information. See the post “Security vendors teaching bad actors how to get past firewalls.”
If you need help setting this up, give our team a call.