Five SEIM's and a Side of Fries
Organizations buy security products for the strangest of reasons. I recently sat down with a group that had purchased five different SEIM solutions over the course of several years. They were quite transparent in admitting that the decision to purchase and deploy those solutions were not carried out well.
You're Not an Investor
The core issue that led to poor purchasing decisions was the organization did not focus on the business problems they had and what could solve those problems. Vendors came in with technology that sounded very helpful. They could see how those products could make IT better. They saw merit in the technology and decided to invest in it.
Remember the Business Problems
If the organization had listed out it's business problems then subsequently determined how they would address these problems through security technologies, they would have saved a lot of money, time and actually solved their problems. Here is an example of listing the business problems and possible technologies to address them:
- Detect Known Virus Infections -> Acme Endpoint Antivirus, Acme Email Antivirus, Beta Gateway Antivirus,Omega SEIM
- Detect Emerging Virus Infections -> Delta Network Behavior Anomaly, Gamma Malware Sandbox, Omega SEIM
- Stop Known Attacks Against Web Services -> Acme Intrusion Prevention System, Beta Firewall
- etc...
Analysts Focus on Products
Exasperating the problem, analysts tend to categorize security products by features. A better service to organizations would be reports focusing on the business problems themselves. Reports on "Security Products that Detect Targeted Attacks" would be very helpful to organizations trying to address that actual issue. Instead analysts give broad characterizations of product type capabilities then list the products that fit into those buckets.
The Wrong Shopping List
When decision makers are told they need products from a list of categories (SEIM, Firewall, Antivirus, etc.) they start looking at the available products in each bucket. Cost, compatibility, partnerships and company profiles all get weighed in picking a solution (or five) from each bucket. The problem with this approach is the collective architecture might not actually address the problems facing the organizations (it often doesn't.)
The Abridged List
Instead of focusing on a list of technologies, build a list of business problems. Architects, particularly should be evaluating how a security architecture can collectively address these challenges:
- Identify"known" malware infections on endpoints
- Stop "known" malware from infecting endpoints
- Identify anomalous behavior from endpoints
- Stop policy internal policy violations
- Identify policy violations
- Stop Data Loss
- Detect Data Anomalies
- Detect Spear Phishing
- Reduce Spear Phishing
- Detect DDoS
- Respond to DDoS
- Detect Service Exploitation
- Reduce Service Exploitation
- Detect Regulatory failures
- Reduce Regulatory failures
- Create Audit Logs for Forensics
This is not an exhaustive list, but a quick review of it reveals that no vendor product comes close to doing all of these things. Solving these problems require Hiring a Security Team as well as selecting a combination of products that when put together actually solve the business issues above. Take a deep breath, a step back and map "solutions" to problems and not vice versa.
Wrap Up
If you're a vendor, explain what problems your "solution" solves to the prospect. If you're an analyst, write reports that enable organizations to address their business problems instead of explaining the merits of different security "toys." If you're an organization, don't lose sight of the problems you need to address. Build an infrastructure that will meet your needs, not just satisfy an ill-advised checklist.
