During the last several years we have observed dramatic changes in the identity of attackers, their goals, and methods. Today’s most dangerous attackers are cyber criminals and nation-states who are stealing money and intellectual property. Their primary attack vector is no longer the traditional “outside-in” method of directly penetrating the enterprise at the network level through open ports and exploiting operating system vulnerabilities.
The new dominant attack vector is at the application level. It starts with baiting the end-user via phishing or some other social engineering technique to click on a link which takes the unsuspecting user to a malware-laden web page. The malware is downloaded to the user’s personal device, steals the person’s credentials, establishes a back-channel out to a controlling server, and, using the person’s credentials, steals money from corporate bank accounts, credit card information, and/or intellectual property. We call this the “Inside-Out” attack vector.
Here are my recommendations for mitigating these modern malware risks:
Reduce the enterprise’s attack surface by limiting the web-based applications to only those that are necessary to the enterprise and controlling who has access to those applications. This requires an application-based Positive Control Model at the firewall.
Deploy heuristic analysis coupled with sandbox technology to block the user from downloading malware.
Leverage web site reputation services and blacklists.
Deploy effective Intrusion Prevention functionality which is rapidly updated with new signatures.
Segment the enterprise’s internal network to:
Control users’ access to internal applications and data
Deny unknown applications
Limit the damage when a user or system is compromised
Provide remote and mobile users with the same control and protection as itemized above
Monitor the network security devices’ logs in real-time on a 24x7x365 basis
Full disclosure: For the last four years my company Cymbel has partnered with Palo Alto Networks to provide much of this functionality. For the real-time 24x7x365 log monitoring, we partner with Solutionary.
BTW, in my experience, I have seen the total cost of a SIEM project (hard + soft) range from 10% of SIEM license costs (for shelfware SIEM “deployments”) to a mind-boggling 20x of license cost.
I would like to comment on RSA’s use of the term Advanced Persistent Threat (APT) in their Open Letter to RSA Customers. From my perspective, any company’s trade secrets are subject to APTs from someone. There is always some competitor or government that can benefit from your trade secrets. All APT means is that someone is willing to focus on your organization with resources of approximately the value of a penetration test plus the cost of acquiring a 0-day attack.
This means that you must assume that you are or will be compromised and therefore you must invest in “detection controls.” In other words, your security portfolio must include detection as well as prevention controls. Important detection controls include intrusion detection, behavior anomaly detection, botnet command & control communications detection, and Security Information & Event Management (SIEM). If you don’t have the resources to administer and monitor these controls then you need to hire a managed security services provider (MSSP).
Furthermore, organizations must take a close look at their internal access control systems. Are they operationally and cost effective? Are you compromising effectiveness due to budget constraints? Are you suffering from “role explosion?” A three thousand person company with 800 Active Directory Groups is difficult to manage, to say the least. Does your access control system impede your responsiveness to changes in business requirements? Have you effectively implemented Separation of Duties? Can you cost effectively audit authorization?
Dark Reading recently published an article about the problems that plague Security Information and Event Management deployments, Five Reasons SIEM Deployments Fail. First, I would say that you could use these five reasons to explain why almost any “enterprise” information technology project fails. Having said that, I would like to address each of the five points individually:
1. SIEM is too hard to use.
The nut of it really comes down to the fact that SIEM is not an easy technology to use. Part of that rests squarely at the feet of SIEM vendors, who still have not done enough to simplify their products — particularly for small and midsize enterprises, says Mike Rothman, analyst and president of Securosis.
There is no doubt that some SIEM products are harder than others to use. Ease-of-use must surely be one of the criteria you use when evaluating SIEM solutions. On the other hand, too hard to use may be code for not having the resources needed to deploy and operate a SIEM solution. For those organizations, there is an alternative to buying a SIEM solution. Use a Managed Security Service Provider (MSSP) to provide the service. This is a particularly appropriate approach for small and midsize enterprises.
“I think that we need to see more of a set of deployment models [that] make it easier for folks that aren’t necessarily experts on this stuff to use it. In order for this market to continue to grow and to continue to drive value to customers, it has to be easier to use, and it has to be much more applicable to the midmarket customer,” Rothman says. “Right now the technology is still way too complicated for that.”
There is an alternate deployment model which Mike seems to be ignoring. Incident detection and response is complicated. If you don’t have skilled resources or the budget to hire and train people, you need to go with a MSSP. A good MSSP will have multiple deployment models to support different customer needs.
A more correct statement might be that an organization has to decide whether it has the resources to select, deploy, and operate a SIEM.
2. Log management lacks standardization.
In order to truly automate the collection of data from different devices and automate the parsing of all that data, organizations need standardization within their logged events, says Scott Crawford, analyst for Enterprise Management Associates. “This is one of the biggest issues of event management,” Crawford says. “A whole range of point products can produce a very wide variety of ways to characterize events.”
There is no doubt that there is no standardization in logs. That’s like saying there is no standardization in operating systems, firewalls, or any of the other products for which you need to collect logs. Even if there were to be a standard, there would still be ways for manufacturers to differentiate themselves. Just take a look at SNMP. It represents one of the most used industry standards. Yet manufacturers always add proprietary functions for which systems management products must account. So logs may get somewhat more standardized if, for example, Mitre’s CEE were to become a standard. But the SIEM manufacturers and MSSPs will always be dealing with integrating custom logs.
3. IT can’t rise above organizational power struggles.
“One of the key challenges our customers face is really getting all parts of the company to work together to actually make the connections to get the right scope of monitoring,” says Joe Gottlieb, president and CEO of SenSage. “And the things you want to monitor sit in different places within the organization and are controlled by different parts of the organization.”
Yes, by definition SIEM cuts across departmental lines when the goal is to provide organization-wide security posture and incident visibility. As with most “enterprise” solutions, you need senior management support in order to have any hope of success.
4. Security managers see SIEM as magic.
SIEM expectations frequently don’t jibe with reality because many IT managers believe SIEM is about as powerful as Merlin’s wand.
“A lot of people look at SIEM like it’s this magical box — I get a SIEM and it’s going to do all my work for me,” says Eric Knapp, vice president of technology marketing for NitroSecurity. “SIEM has different levels of ease of use, but they all come back to looking at information and drawing conclusions. Unless you’re looking at it in the correct context for your specific environment, it’s not going to help you as much as it should.”
SIEM has been around for ten years now. Is it really possible that SIEM still has some kind of magical mystique about it? SIEM vendors that let their sales people sell this way don’t last because the resources the vendor has to commit to alleviate customer dissatisfaction is huge and profit-sapping. On the other hand, caveat emptor. Any organization buying SIEM without understanding how it works and what resources they need to make it successful, have only themselves to blame. Again, if you are not sure what you are getting yourself into, consider a MSSP as an alternative buying a SIEM solution.
5. Scalability nightmares continue to reign.
There is no doubt that scalability is a particularly important attribute of a SIEM solution. And there are SIEM products out there that do not scale well. If the vendor tells you, (1) We store log data in a traditional relational database, or (2) You only need to save the “relevant” logs, RUN. These statements are sure signs of lack of scalability. On the other hand, you do need to know or estimate how many events per second and per day you will actually generate in order to configure the underlying hardware to get reasonable performance.
There are SIEM solutions that do scale well. They don’t use traditional relational databases to store log data. As to which log events are unimportant? It’s practically impossible to determine. If you are in doubt, there is no doubt. Collect them.
