This document discusses five critical conditions for maximizing security intelligence investments. It begins by noting the proliferation of innovative technologies and connected devices that have changed the threat landscape. It then discusses how attacks continue to evolve in sophistication. The document emphasizes that targeted attacks remain a top concern and lists several high-profile attacks. It notes that security solutions alone are not enough and that security intelligence is needed. The document provides five key points: 1) what you don't know can hurt you, 2) force multipliers are key to winning the battle, 3) reduce incident investigations with more available data, 4) further reduce blind spots using non-traditional event sources, and 5) 'big data' adds more structured and unstructured data
In todays high tech, highly mobile, everything connected , data is everywhere world we need to look at security very differently than we did just a few years ago In the good ole days good strong perimeter defense and some end point protection was pretty much all that was needed to protect a companies digital environment. There are however many indicators highlighting the fact we need to do something different.
History however has taught us s we change tactics the threat doesn’t stand still, they continue to become increasingly more sophisticated. And they can do so unhindered by budget and procurement processes which enables them to be much more nimble than most organizations. We have also seen the motivations that drive them have become all the more complex. It’s gone from mere nuisance or curiosity, script kiddies to very specific targeted attacks and even arguably, state sponsored attacks against companies and government organizations
All you have to do is turn on the TV, pick up a newspaper or magazine to see how well we are doing in our efforts to counter these more sophisticated threats. Hardly a day goes by where there isn't some new headline indicating new security breach. Chances are most people on this call have been effected or no someone that has been effected by some sort of security breach
If we take a look at the number and relative or estimated cost of breaches this is also increasing at an alarming rate. Now as a caveat I do acknowledge there is some subjectivity here as we have seen in most reports of these types. I think as more and more organization's are feeling the pain the are more willing to talk about it than they have been in the past. I also think just the shear number makes them more public. That said if we compare 2011 to the half year point of 2013 we see there is a significant increase in the number of attacks, the cross section of organizations being targeted and of course the relative costs associated with attacks is going up. But the real takeaway from this is the number of attacks being classified as unknown. This is important (next slide)
Because in spite of having all kinds of technology trying to counter the threat from almost every angle there is huge number of attacks falling into the unknown category. And yes, there are probably some showing up in this category that are known they just didn’t want to identify the actual type of attack for whatever reason. Might be it was an insider attack and they don’t want it to get out or maybe just human error and again it is not something they want exposed, but none the less there are a lot of attacks where the outcome is known, but how they got there is a mystery. This is where true Security Intelligence comes into play
Several years ago, we introduced the term “Security Intelligence” to describe the value organizations can gain from their security data and the term has caught on.
We’re seeing this term being used more and more by customers, vendors, pundits and industry experts - but what’s interesting is how no one seems to be describing the same concept.
In a recent discussion I had with around 20 analysts in in the security and networking space I found no one has really defined the term.
To set the record straight, we are explicitly stating our own definition as:
Security Intelligence (SI) is A methodology of analyzing millions and billions of security, network and application records across the organizations entire network in order to gain insight into what is actually happening in the organizations digital world.
We further define Security intelligence as : Combining internal, locally collected security intelligence, with external intelligence feeds for the application of correlation rules that reduce huge volumes of data into a handful of high probability ‘offense’ records requiring immediate investigation.
So keeping the Security Intelligence definition in mind, lets take at how this actually plays out technologically. If we take a look at the Security Intelligence time line, most organizations are going about their day to day business and as long as there are no indicators of anything going wrong they proceed in doing what it is they do day in and day out. Then an alarm goes off, the alarm might be an alarm triggered by some technology, or as is often the case a sudden wave of customer complaints. Let’s assume for the sake of argument the alert is triggered by a highly tuned highly effective SIEM solution taking in information from all of the usual suspects. What becomes clear is this does not really meet our definition of security intelligence. It really falls more under the definition of Forensics. A crime has been committed and now the effort is focused on finding out what happened with the intent to prevent it from happening again. The problem with this is the bad guys are always in the lead. To get ahead of the threat requires a different approach. You cannot rely on forensics only if you want to get ahead of the threat. To do that, you have to close some of the information gaps found in traditional SIEM and log management solutions. Much of the activity and data feeds listed on the pre-exploit side are challenges for traditional SIEM solutions that are focused in forensics. Keep in mind here, technology is critically important but does not remove the human requirement, but does to a certain extent, change their focus as we will talk about here in a few minutes.
As I mentioned at the start of this presentation there are a lot of security products out there all trying to focus in on trying to prevent bad things from happening in an organizations network. None of the individual point solutions give full visibility into what is happening in the network and they don’t claim to. The full view however is what the security and network professional need in order to quickly identify and prevent the threat from having an impact on the organization. Time here is on the side of the bad guys. The longer something goes un-noticed the more likely it is to have a critical impact on the business and at the very least require more resources to extract and make the network whole again. One bewildering observation I have made over the past several years is organizations purchase best of breed point solutions based on how well they defend within their area of expertise. This same sort of thinking doesn’t seem to always carry over when they are looking at SiEM or Security Intelligence solutions. Many organizations, for whatever reason buy into a framework they have to tune to meeting their specific needs thinking their requirements are so much different than others in their space.
The impact of this can be shown graphically. The longer it takes to identify and resolve an incident the more impact, translate cost, to the organization. The longer you don’t know about it the more expensive it gets. So I am an instant gratification kind of guy. I will pay a bit extra to go to the store to buy my toys, whatever they may, so I can go home and start playing with them rather than save a few dollars or euros to order them on line and have to wait a week for them to be delivered. I am always a bit amazed when organizations go the framework approach where they deploy a solution knowing it will most likely be months before they get to the point where the output is useful.
Another way of looking at this is SIEM technology tends to really focus on the tip of the iceberg. Though there are some that dabble a bit deeper including Identity and flows, albeit more for show rather than function. Flows for instance cannot be correlated in the same was as an event. Flows need to be looked at as a session to add true intelligence value. So in the interest of time, I want to point out one toward the bottom of the iceburg, that is Business Process. This really reflects the changes that need to take place in order to get ahead of the threat. It is becoming more and more critical that the security practitioner understand the organizations business process in order to tune the security environment and effect appropriate response. This again begs the question should the security team be spending time tuning the tool or securing the network. Obviously both can be done with an unlimited budget.
Assuming a best case scenario, there is a lot of information being thrown at the security team. All of this information has to be correlated in real time because as I mentioned earlier, time is not on the side of the good guys. Again, I want to point out the security team needs to be focusing higher up the stack looking for activity that might indicate something undesirable is about to happen. Even if all the correlation is spot on, significant improvements can be made when including data from external intelligence sources. This data coupled with the business related data incorporated by the security team has a significant impact on overall security posture.
Since there is not IT Security organization yet I have talked to that says they don’t have enough to do, incorporating external threat data that is already weaved into the inner workings of the solution serves as a force multiplier. With more than 6,000 researchers, developers and subject matter experts engaged in security initiatives, IBM operates one of the world’s broadest enterprise security research, development and delivery organizations. This powerful combination of expertise is made up of the award-winning X-Force research and development team—with one of the largest vulnerability databases in the industry—and includes nine security operations centers, nine IBM Research centers, 14 software security development labs and the IBM Institute for Advanced Security with chapters in the United States, Europe and the Asia Pacific region. Not a bad addition to add to your security team.
________________________
Security Operations Centers: Atlanta, Georgia; Detroit, Michigan; Boulder, Colorado; Toronto, Canada; Brussels, Belgium; Tokyo, Japan; Brisbane, Australia; Hortolandia, Brazil; Bangalore, India; Wroclaw, Poland
Security Research Centers: Yorktown Heights, NY; Atlanta, GA; Almaden, CA; Ottawa, Canada; Zurich, CH; Kassel, DE; Herzliya, IL; Haifa, IL; New Delhi, IN; Tokyo, JP
Security Development Labs: Littleton, MA; Raleigh, NC; Atlanta, GA; Austin, TX; Costa Mesa, CA; Fredericton, Canada; Toronto, CAN; Ottowa, CAN; Belfast, NIR; Delft, NL; Pune, IN; Bangalore, IN, Taipei, TW; Singapore, SG; Gold Coast, AU
Note: IBM patent search performed by Paul Landsberg, IBM IP Office
Automatically including this up to date threat intelligence has many benefits. It can take some of the important, but lower level everyday tasks, like looking for BoT C&C, top targeted port and known hostile networks off the plate of the security team again allowing them to focus on those tasks that must be done internally?
Another key area where a fully integrated Security Solution can help significantly reduce pressure on the security team over a Framework solution is in the day to day care and feeding of the solution. In many cases a fully integrated intelligent Security intelligence solution can help take care of itself. Parsers, rules, device and event mappings are easily updated. This again reduces the time spent tuning the security solution allowing more time solving security issues.
While log events are critical, they leave gaps in visibility. Many of our competitors openly state they believe there is no value in flow, We vehemently disagree. A great example, the first thing an attacker will do when they compromise a system is to turn off logging and erase their tracks. Traditional SIEMs are blind at this point. However, the attacker can’t turn off the network or they cut themselves off as well.
In addition to filling in the visibility picture, network activity can also be used to passively build up an asset database and profile your assets. A machine that has received and responded to a connection on port 53 UDP is obviously a DNS server. Or a machine that’s accepted connections on 139 or 445 TCP is a Windows server. Adding application detection can confirm this not only at a port level, but the application data level.
A great example of where flows fill in the gap. A user logs in successfully to a system and creates a new user account. They then elevate the rights on that account and logon to another system. All of this activity is clearly visible to any Security Intelligence, SIEM and even pure log management solutions.
Most of these systems can generate an alert when the user logins in with the elevated privileges. But lets assume the individual wants to do something and doesn’t want anyone to know about it so disables logging. Again, most systems have the ability to alert if a system stops sending events. At this point event based SIEM solutions are blind. By including session based flow monitoring to the Security Intelligence exposes activity others can’t see. Though the individual can turn off events they can’t turn off flow.
I like to equate event information to still photography. An event is a mere snapshot of the activity going on. For example and IPS inspects a packet, sees nothing wrong with it so just drops it. If it does see something in it, and event gets generated and sent on to the console and or SI, SIEM or LM system if one is being used. All it knows is what is contained in that event. Yes it can correlate information from other devices which may tell a different story. But what about devices that don’t log or if for whatever reason an event is not generated. Looking at flow data is more like looking at video tape. When you include flow data in to your Security Intelligence your forensic work becomes much easier and faster because you can see everything they have touched with some level of understanding of what they were doing. You can’t hide from flows!
In starting out this presentation I suggested that the old method of protecting an organizations digital self is not working. There needs to be a new approach. I put for the argument the role of the security expert is changing. They have to better understand the business and what normal is so even the slightest change raises an eyebrow and is investigated, Having the ability to incorporate this into the Security intelligence solution across all attack vectors is essential. The days of hoping the bad guys won’t find a vulnerability are gone. You have to ensure you have all aspects of the digital world covered. Visibility into this world simplifies your life which then makes it easier for you to make the bad guys life much harder.
Through out this presentation I have acknowledged the IT teams are over extended. There is every chance that at the end of the day they are not going to get to resolve every issue that comes their way. It is however important they focus on the issues that are critical to the business. By including Vulnerability data into the solution the security team can do just that. IBM Security’s QRadar Vulnerability Manager delivers exceptional insight to guide the proactive efforts of IT security teams helping them fortify their defenses against persistent adversaries. It presents vulnerability scanning results within the context of an enterprise SIEM, and produces an actionable plan for addressing the largest risks. It can be triggered to immediately scan whenever abnormal behavior is detected or a new asset is seen on the network, giving security teams near real-time visibility of weaknesses that could otherwise remain hidden for some time.
Another buzz phrase in the Security space is Big Data. This is another area that may hold yet undiscovered clues as to what may be at the root of network issues. Traditional security solutions rely primarily on structured data. We however recognize the value of analyzing this data for many reasons security being one of them. This by the way works both ways. Remember looking for a potential security indicator this could be a couple of packets worth of data out of millions and millions of records. These types of indicators could be easily missed if the event information has to be filtered in order for the security solution can keep up. Integrating security enriched data into the Big data warehouse ensures all data is probably analyzed without compromising security.
Protect and track user activities
Provide effective administrative access control
Track suspicious role changes, unauthorized user actions, failed and potentially harmful logins
User activities on the VMs or ESX server like create, delete or move VMs or physical servers
Meet audit and compliance requirements
Generate reports (daily, weekly, monthly) for VMs, hypervisors activities per organization
Meet Industry specific compliance – PCI, HIPAA, ISO27002, FISMA – for virtualization layer
Comply with security advisories for virtual infrastructure and address platform hardening
Improve visibility
Ability to correlate events from VMware components e.g., storage, routers, firewall, switches
Track issues such as duplicate IPs, virtual machine connectivity
Track security and statistics as virtual machines are migrated / moved
This is the core of the value that QRM provides from a configuration perspective. To get to these views, you can either right-click on a device from topology and select ‘view configuration’ (I suggest you view the ‘datacenter’ firewall to show rules with events and the ‘QA’ firewall under the multi-context device to view shadowed rules).
Be sure to show that the user can hover over the shadowed rule indicators to get a pop-up that indicates which rule(s) are doing the overshadowing. Also be sure to mention that it is possible to generate firewall configuration reports, like shadowed rule reports, most/least used rule reports, etc., for one firewall for groups of firewalls. QRM uses the standard QRadar reporting mechanism, so if the customer is interested, you can show the reporting capabilities.
One key QRM differentiator should be noted here when you’re discussing rule counting. The way that QRM counts firewall rule activity is by correlating the actual firewall events, which are received by QRadar (assuming the customer has pointed the device logs at QRadar). QRM automatically maps these log sources, and then correlates the firewall rule accept/deny events with the specific rules. This is different than most competitive products, which typically rely on the ACL counters in the firewall. ACL counters are unreliable as they can be reset if the device is rebooted, updated, etc. QRM, on the other hand, keeps a historical record from the time that rule counting is initially enabled onward.
No matter how many QRadar products/applications are leveraged, or how many appliances constitute a customer deployment, all capabilities are leveraged through a single console – with all the associated benefits that a common interface delivers in terms of speed of operation, transference of skills, ease of adoption and a universal learning curve. The industry has accepted that Log Management and SIEM are not separate problems, and IBM Security QRadar Platform was designed from scratch with this in mind. This is a different approach than offering disparate products by a vendor.
Before now if you wanted intelligence, a standalone SIEM was the answer, but there were significant scaling concerns which limited log management functions. Log Mangers can scale, but deliver little intelligence, so volumes of useless events continue to be generated. QRadar provides a solution that, no matter what the scale requirement, offers a common platform and User Interface for all security intelligence tasks from searching and filtering, to reporting and response. Logs are stored once, and correlated in real-time; the customer does not have to selectively forward logs to the analytics engine. Bi-directional flows are also analyzed in real-time and stored to the database as a single entry—rather than an outbound record and an in-bound record—for pairs of IP addresses along with cumulative bandwidth usage totals, protocols in-use, and other helpful statistics.
This integration delivers security operations teams and administrators value they see every day as they create searches and perform forensics and run reports.
Mandatory Thank You Slide (available in English only).