So I think this is the last time I'll ask you to move with me.... I hope it is anyway....
As of last week I've started a new venture. My company is named "Visible Risk". Visible Risk other than being a great name for a company, is my effort to help push information security forward over the next few years. I'll be working with certain organizations on integrating intelligence and security operations, and a huge area of focus for me will be providing "live" use-case based content for security products (like SIEM).
Additionally, I'm starting a new podcast and video/webcast under the Visible Risk brand over the next few weeks so please be on the look out for that as I'd love to involve you in it!
Visible Risk Blog RSS Feed: http://www.visiblerisk.com/blog/rss.xml
Thank you again to everyone who has helped me over the years to better understand my strengths and weaknesses and for always pushing me forward!
If you're not already following my new blog here are links to some of my recent postings:
1. A primer on starting a new company: http://www.visiblerisk.com/blog/2010/3/10/so-you-want-to-work-for-yourself.html or http://bit.ly/aX7WWB
2. RSA Recap - Round 1: http://www.visiblerisk.com/blog/2010/3/10/rsa-conference-2010-recap-round-1.html or http://bit.ly/aPA63z
Wednesday, March 10, 2010
Monday, February 15, 2010
Supporting Hackers For Charity
I realize there are multiple ways we all contribute to HFC (General Donations, Equipment, Software, Time/energy, Books, etc), but the donor cloud being empty worries me that maybe others have also let this go "out of site, out of mind" for them as well. So consider this message a small reminder!
Get Involved with Hackers For Charity!
Whatever you can do, buy shirts, donate via Paypal, donate equipment, join Informer - every little bit helps a great deal over there.
In case you didn't know Johnny Long and his family through HFC support a couple of incredible missions in East Africa
1. Food Program in Kenya (You can help via the Donor Cloud on his website).
2. Classroom Initiative where with AOET they have built three classrooms already to help empower the Ugandans to learn and do for themselves!
Since his first trip, Johnny has inspired me to be better and to do more wherever I can. His story is amazing. He gets energized by our (community) support! Personally, I've done what I can over the years to help and will continue to do the best I can, but it's never enough. I'm suggesting we all join in - with whatever you can. $20/Month - $25 one time donation, whatever you can do. To kick things off anew in 2010 - my family and I are planning on giving at least 50% of my first paycheck with whomever my new employer winds up being to HFC in March. How will you help with this effort?
Let's see how we can support his incredible mission!
You can follow Johnny Long on Facebook You can also find him on Twitter
Thursday, February 11, 2010
Getting More "Connected" in 2010
One of my goals in 2010 is to be more timely in my responses to everyone that takes the time to reach out to me. It seems that I'm pretty much the worst person on earth when it comes to responding to phone messages or emails older than 24 hours. I have a very small memory ring-buffer in my head.
As part of me working on fixing this issue - I'm opening up my entire "virtual" life to you all - If you want to reach out and talk (or collaborate on a project) about Security Operations, SIEM, Log Management, Security Monitoring and Analysis, Incident Response, etc - I've provided about every reasonable way I can think of to reach me and I'm committing to being as responsive as I can.
In addition to my blog - here are some of the best ways to reach me - or learn what I'm up to in 2010:
Twitter "@RockyD" DM me or at least "@rockyd" me and I'll probably see the message within a few minutes one my phone or desktop. I'm addicted to Twitter (seriously I think I might need to go to Twitter Rehab).
I'm almost always online via Skype either on my phone or at my desk. I'm willing to Video/Voice and Chat as necessary.
Linkedin Profile I use the Linkedin Groups feature to answer questions, though less so over the last few months. I do post there every few days and I use Linkedin in advance of every single professional conversation I have to help have an understanding of who I am talking with.
Google Wave "SecurityProfessional" I'm committing to trying this out for some projects I'm collaborating on and it is working great so far!
Google Buzz: Security Professional. My Information Security related "Buzz". Not committing 100% to Buzz yet, but I will try it out for a while and see how it goes. If you follow me on Buzz it does open up gmail and google chat as another communication opportunity.
Of course there is good old-fashioned email as well. If you can't figure out my gmail with everything else I've provided above, please get off the internet. If I don't respond to you within 24 hours - please feel free to ping me again.
Conferences: I will be attending RSA and B-SidesSF in March and perhaps BH/DC in July. Always happy to talk in person! My schedule fills up pretty quick, but I always leave evenings open!
If you can't reach me with any of the above methods I'm either in-person meeting with someone (I don't usually answer to machines if I'm face-to-face with someone - it just seems rude) on an airplane, or I'm dead and if I can I'll either get back with you or haunt you whichever is appropriate.
In all seriousness, I look forward to talking/collaborating with you in 2010 and beyond.
As part of me working on fixing this issue - I'm opening up my entire "virtual" life to you all - If you want to reach out and talk (or collaborate on a project) about Security Operations, SIEM, Log Management, Security Monitoring and Analysis, Incident Response, etc - I've provided about every reasonable way I can think of to reach me and I'm committing to being as responsive as I can.
In addition to my blog - here are some of the best ways to reach me - or learn what I'm up to in 2010:
Twitter "@RockyD" DM me or at least "@rockyd" me and I'll probably see the message within a few minutes one my phone or desktop. I'm addicted to Twitter (seriously I think I might need to go to Twitter Rehab). I'm almost always online via Skype either on my phone or at my desk. I'm willing to Video/Voice and Chat as necessary.
Linkedin Profile I use the Linkedin Groups feature to answer questions, though less so over the last few months. I do post there every few days and I use Linkedin in advance of every single professional conversation I have to help have an understanding of who I am talking with.
Google Wave "SecurityProfessional" I'm committing to trying this out for some projects I'm collaborating on and it is working great so far! 
Google Buzz: Security Professional. My Information Security related "Buzz". Not committing 100% to Buzz yet, but I will try it out for a while and see how it goes. If you follow me on Buzz it does open up gmail and google chat as another communication opportunity.
Conferences: I will be attending RSA and B-SidesSF in March and perhaps BH/DC in July. Always happy to talk in person! My schedule fills up pretty quick, but I always leave evenings open!
If you can't reach me with any of the above methods I'm either in-person meeting with someone (I don't usually answer to machines if I'm face-to-face with someone - it just seems rude) on an airplane, or I'm dead and if I can I'll either get back with you or haunt you whichever is appropriate.
In all seriousness, I look forward to talking/collaborating with you in 2010 and beyond.
Wednesday, February 10, 2010
Much Ado About Correlation
Mike Rothman at Securosis posted Network Security Fundamentals: Correlation yesterday and did a good job explaining some common issues SIEM and "Correlation". If you're in the market for SIEM you should read it and not just because it refers to some of my previous blogs :) (SIEM 101 and SIEM 201) but because is very accurate. You have to do the real work PRIOR to deploying the SIEM. It's all in the requirements. If you can't define how you will use the output of the SIEM - stick with Log Management until your organization can mature into using SIEM properly.
I really enjoyed Adrian's follow up Post Where he describes in detail why SIEM is not the end-all be-all of Security Monitoring. It's a good tool designed to do the best it can with what it is given. Simply put there is only so much you can do with crappy logs. Additional context is always required. For more on my thoughts about what works for Security Monitoring see Security Operations: Collection Post.
I really enjoyed Adrian's follow up Post Where he describes in detail why SIEM is not the end-all be-all of Security Monitoring. It's a good tool designed to do the best it can with what it is given. Simply put there is only so much you can do with crappy logs. Additional context is always required. For more on my thoughts about what works for Security Monitoring see Security Operations: Collection Post.
Thursday, February 4, 2010
NSA to Google wrt APT - "We're here to help"
The Washington Post reported that the NSA will be helping Google with the analysis of events related to the recent Chinese Espionage that affected Google and so many other US Companies.
Does this confirm the existence of APT, and that APT is a real danger? Duh, the world's scariest intelligence organization is focusing their talents on the problem - it IS a problem. Is this the best way to combat it? Well, we do need more exposure, information and collaboration so I can't really think of a better partnership of minds.
Sure the Privacy implications are huge. NSA does go to great lengths to protect privacy of US Citizens. The fact that this is public information does lend itself to more trust. They are both being fairly transparent and the goal is in our (US-centric) best interest.
Some questions I have - I wonder who is going to have oversight authority? I also wonder WHY this is public information? Is NSA going to offer the same level of collaboration to other companies affected by APT (or non APT espionage)? If so great news, if not then what is the threshold for involvement?
I also wonder if this was coordinated through our new Cyber Coordinator and if so, why wouldn't he take the opportunity to announce the partnership?
What do you think?
Thursday, January 21, 2010
Call to Arms
For the last several years I’ve been a position to help a number of organizations with their Incident Detection and Response programs. One thing that remains consistent across all of the organizations is that there is a very high rate of compromised systems. Whether these were compromised from the outside or popped by malware really doesn’t matter, what really matters is the rate at which information is leaving the organization is alarming and should be disturbing to everyone. It’s not just the big guys either – I’ve seen evidence of compromise and data extraction at nearly every organization I’ve encountered.
In this FUDSEC post one of the points I made was a call for leadership and action, because no one else is coming to save us – a point made even clearer by Mike Rothman in his FUDSEC post earlier this month. I’m tired of sitting on the sidelines and watching our systems being ravaged. This sense of frustration really hit me over the last month as I’ve taken a look at my career and what I’ve accomplished and what I want to do next. I’ve done a lot for the companies I’ve worked for and their customers, no question – but it isn’t nearly enough. I need to do more.
Watching the Google versus China situation and the apparent lack of response by our government combined with our utter futility in fighting these threats really has stirred a call for action within me. So much so, that I really believe if I was 10 years younger and 50 lbs lighter I’d re-enlist to go back and work at AFCERT or similar entity. Not as a contractor or consultant but as an Airman or Federal employee. I want to fight back or at least defend as vigorously as possible. I simply cannot and will not sit idle anymore. There is still some warrior left in me.
My question to you is this: Does anyone else feel nationalistic and have the urge to serve their country to fight in the information security arena, to protect our nation, or perhaps to strike back at those who seek to harm us? I do!
To my friends at DHS, The White House, NSA, USAF, DoD, Secret Service and/or the FBI - if you have a way of using a resource with my background to help defend this country I stand here in Austin, TX ready, willing and able!
In this FUDSEC post one of the points I made was a call for leadership and action, because no one else is coming to save us – a point made even clearer by Mike Rothman in his FUDSEC post earlier this month. I’m tired of sitting on the sidelines and watching our systems being ravaged. This sense of frustration really hit me over the last month as I’ve taken a look at my career and what I’ve accomplished and what I want to do next. I’ve done a lot for the companies I’ve worked for and their customers, no question – but it isn’t nearly enough. I need to do more.
Watching the Google versus China situation and the apparent lack of response by our government combined with our utter futility in fighting these threats really has stirred a call for action within me. So much so, that I really believe if I was 10 years younger and 50 lbs lighter I’d re-enlist to go back and work at AFCERT or similar entity. Not as a contractor or consultant but as an Airman or Federal employee. I want to fight back or at least defend as vigorously as possible. I simply cannot and will not sit idle anymore. There is still some warrior left in me.
My question to you is this: Does anyone else feel nationalistic and have the urge to serve their country to fight in the information security arena, to protect our nation, or perhaps to strike back at those who seek to harm us? I do!
To my friends at DHS, The White House, NSA, USAF, DoD, Secret Service and/or the FBI - if you have a way of using a resource with my background to help defend this country I stand here in Austin, TX ready, willing and able!
Tuesday, January 12, 2010
Google's New Approach to China - My Initial Reaction
RE: http://googleblog.blogspot.com/2010/01/new-approach-to-china.html
I love the fact that Google publicly disclosed this incident. I'm not going to comment on the human rights angle or the advertising angle or even the exact methods for exploitation other than to say - they are nothing more than variables in the equation.
We must acknowledge that even of the best security teams in the world are nearly irrelevant against those with time, motivation and expertise. At this point we can only hope to detect traces of this activity and begin the investigation from there. Given current IT environment we can not stop this but we sure as hell need to be aware these threats exists and they are being actively exploited everywhere.
What should our government do in response? Given the expertise at Google I'm willing to take the facts as presented in their blog at face value and say they are correct in their assumptions of the aggressors in this scenario. This isn't news on its own, we've always known that to be the case, but Google coming public with this information is amazing! This activity should force heated discourse with our industry leaders, our government leaders, our intelligence/military leaders, etc. We need to talk... then we need to Act.
What a platform for the new cybersecurity coordinator to stand on... If this situation doesn't give him the ears of Congress nothing will.
My Question of the day: What is the government going to do to protect our information, our companies and our people? It is apparent that we can not protect everything ourselves, there needs to be a real deterrent (legal, military, etc) and we need real assistance not just rhetoric.
Does it make sense yet? We can't sit idle anymore, we must take pro-active measures to protect our company's our data and our people. They are all being targeted for purposes you may not fully understand, but that doesn't mean you won't be compromised. We can't solve the whole problem, but we must take a more substantive approach to Information Security.
My congratulations to Google. I know of no other company in the world that would consider risking the largest market in the world. Prioritizing the "right thing" over financial gain is way beyond "do no evil".
I love the fact that Google publicly disclosed this incident. I'm not going to comment on the human rights angle or the advertising angle or even the exact methods for exploitation other than to say - they are nothing more than variables in the equation.
We must acknowledge that even of the best security teams in the world are nearly irrelevant against those with time, motivation and expertise. At this point we can only hope to detect traces of this activity and begin the investigation from there. Given current IT environment we can not stop this but we sure as hell need to be aware these threats exists and they are being actively exploited everywhere.
What should our government do in response? Given the expertise at Google I'm willing to take the facts as presented in their blog at face value and say they are correct in their assumptions of the aggressors in this scenario. This isn't news on its own, we've always known that to be the case, but Google coming public with this information is amazing! This activity should force heated discourse with our industry leaders, our government leaders, our intelligence/military leaders, etc. We need to talk... then we need to Act.
What a platform for the new cybersecurity coordinator to stand on... If this situation doesn't give him the ears of Congress nothing will.
My Question of the day: What is the government going to do to protect our information, our companies and our people? It is apparent that we can not protect everything ourselves, there needs to be a real deterrent (legal, military, etc) and we need real assistance not just rhetoric.
Does it make sense yet? We can't sit idle anymore, we must take pro-active measures to protect our company's our data and our people. They are all being targeted for purposes you may not fully understand, but that doesn't mean you won't be compromised. We can't solve the whole problem, but we must take a more substantive approach to Information Security.
My congratulations to Google. I know of no other company in the world that would consider risking the largest market in the world. Prioritizing the "right thing" over financial gain is way beyond "do no evil".
The 2010 SIEM Winter Olympics Preview
A "point in time" snapshot of how I think 2010-2012 looks in the SIEM Market. A much more detailed analysis will be available soon (on request).
Some highlights of the preview:
1. Many companies are focused on rationalizing recent acquisitions or focusing on making their current product scalable and/or bullet-proof. I think that this is absolutely crucial for these organizations but it does create an opportunity for ArcSight to further separate from the pack in 2010.
2. Formally "niche" players are taking the lead in 2010. Q1, Tenable, Nitro all have a legitimate change to overtake their peers in terms of functionality and more importantly marketplace. Each has their own approach, all are led by very capable teams - I'm interested to watch and see what the market does with these three.
3. I don't expect all of these SIEM players to survive to the 2012 Winter Olympics. In fact, I'd guess at least three of them will be consumed or fail completely. Many have other products that have helped them sustain, but not necessarily grow when compared to SIEM competition.
4. Most of the larger organizations have had serious setbacks with their acquisitions in this space. Based on functionality limitations and these organizations losing significant market share I expect some of these organizations to take a serious look at replacing those products (or portions of the products) with more competitive options in the market today.
5. SIEM will certainly grow into interesting areas in the next 24 months as vendors look toward cloud based solutions, supporting virtualized systems and networks, and as more mature users push these products to solve problems other than the basic Security Operations and Compliance based Use-Cases.
6. I do expect the larger picture to come in focus around SIEM soon. RSA's acquisition of Archer is indicative of things to come. The larger companies are focused on presenting Enterprise Risk to the business and not just speeds and feeds anymore. Certainly better reporting, integration with enterprise apps and usage of other technologies will continue to evolve but I believe it will finally be centered on the user's functional purposes and not just marketing hype.
7. SIEM also needs to evolve downward as well. Yes positioning relevant information upward in the business is the ultimate goal, but we can't forget the analyst. The SIEM must continue to support the analytical needs of its core user base. Deeper integration with other analytical tools and resources (Content Inspection, CMDB, Custom DB's, etc) and facility that interaction intuitively.
Some highlights of the preview:
1. Many companies are focused on rationalizing recent acquisitions or focusing on making their current product scalable and/or bullet-proof. I think that this is absolutely crucial for these organizations but it does create an opportunity for ArcSight to further separate from the pack in 2010.
2. Formally "niche" players are taking the lead in 2010. Q1, Tenable, Nitro all have a legitimate change to overtake their peers in terms of functionality and more importantly marketplace. Each has their own approach, all are led by very capable teams - I'm interested to watch and see what the market does with these three.
3. I don't expect all of these SIEM players to survive to the 2012 Winter Olympics. In fact, I'd guess at least three of them will be consumed or fail completely. Many have other products that have helped them sustain, but not necessarily grow when compared to SIEM competition.
4. Most of the larger organizations have had serious setbacks with their acquisitions in this space. Based on functionality limitations and these organizations losing significant market share I expect some of these organizations to take a serious look at replacing those products (or portions of the products) with more competitive options in the market today.
5. SIEM will certainly grow into interesting areas in the next 24 months as vendors look toward cloud based solutions, supporting virtualized systems and networks, and as more mature users push these products to solve problems other than the basic Security Operations and Compliance based Use-Cases.
6. I do expect the larger picture to come in focus around SIEM soon. RSA's acquisition of Archer is indicative of things to come. The larger companies are focused on presenting Enterprise Risk to the business and not just speeds and feeds anymore. Certainly better reporting, integration with enterprise apps and usage of other technologies will continue to evolve but I believe it will finally be centered on the user's functional purposes and not just marketing hype.
7. SIEM also needs to evolve downward as well. Yes positioning relevant information upward in the business is the ultimate goal, but we can't forget the analyst. The SIEM must continue to support the analytical needs of its core user base. Deeper integration with other analytical tools and resources (Content Inspection, CMDB, Custom DB's, etc) and facility that interaction intuitively.
Thursday, January 7, 2010
A week in and 2010 already has been a year of significant changes
Personally, I'll count 2009 as the year of lessons learned. I'm happy to start 2010 and begin anew. Many of you have reached out to me in twitter (@rockyd) or email, FB, etc and asked about my status, personally and professionally - for which I'm very thankful. It is awesome to see some many people and organizations genuinely care about me - I'm humbled. We did make some changes late in 2009 that for all intents and purposes brought an end to Decurity as it was known. The full plan never quite panned out the way we all hoped it would. I joined EMC/RSA for a while and worked alongside some fantastic people over there, but in the end it just wasn't the right place for me. I resigned my position at RSA and took some time off to focus on my family, my health and to renew myself so that I could focus fully in 2010 and beyond.
Personally: I had let myself get way out of shape (mentally, spiritually and physically) and let my blood sugar reach levels that truly frightened everyone. I thought I was just more sweet, but when doctors start wondering why you're not in a coma it's time to pay attention. I joke about it a lot but I've learned to pay much closer attention now. Eventually, I hope to make it to P90X type workouts but for now I'm happy to be able to walk a few miles, a few times a week. It sucks when there is no one else to blame but yourself, but then again I know I can change my habits easier than trying to make many orgs think clearly about how to handle security risks.
Professionally: I'm currently in the midst of considering some fantastic opportunities from various organizations that have reached out to me. I can't tell you how lucky I feel to have so many believe in me. I'm delaying making a final decision until I'm a little healthier (should only be a few days). I want to ensure that whichever route I take it makes sense for me, the company, their user-base and the segment of the security industry I can influence. I'll let everyone know where I wind up once things settle down.
Another Note: I'm moving my personal blogging efforts over to securityoperations.blogspot.com. I'll probably dual post for a while as Decurity's blog has much more critical mass, but I'd imagine I'll keep up with securityoperations.blogspot.com more often from now on.
Personally: I had let myself get way out of shape (mentally, spiritually and physically) and let my blood sugar reach levels that truly frightened everyone. I thought I was just more sweet, but when doctors start wondering why you're not in a coma it's time to pay attention. I joke about it a lot but I've learned to pay much closer attention now. Eventually, I hope to make it to P90X type workouts but for now I'm happy to be able to walk a few miles, a few times a week. It sucks when there is no one else to blame but yourself, but then again I know I can change my habits easier than trying to make many orgs think clearly about how to handle security risks.
Professionally: I'm currently in the midst of considering some fantastic opportunities from various organizations that have reached out to me. I can't tell you how lucky I feel to have so many believe in me. I'm delaying making a final decision until I'm a little healthier (should only be a few days). I want to ensure that whichever route I take it makes sense for me, the company, their user-base and the segment of the security industry I can influence. I'll let everyone know where I wind up once things settle down.
Another Note: I'm moving my personal blogging efforts over to securityoperations.blogspot.com. I'll probably dual post for a while as Decurity's blog has much more critical mass, but I'd imagine I'll keep up with securityoperations.blogspot.com more often from now on.
Friday, December 4, 2009
FUDSEC Guest Post
I was asked to provide a guest post for the FUDSEC Blog. After reading so many of the other guest posts I felt a little overwhelmed to put my ramblings alongside those gems. I'm thrilled Craig allowed me the opportunity and look forward to hearing your input. Please enjoy ripping my thoughts into pieces, chewing on them and then letting me know how you really feel!
FUDSEC: Liberate Yourself: Change The Game To Suit Your Needs
Comments are encouraged directly on FUDSEC or you can reach me on Twitter (@rockyd) or reach me on this Blog any way you chose to reach out I'd love to hear your input.
ORIGINAL TEXT FROM FUDSEC.COM POST FOLLOWS:
December 4, 2009
Liberate Yourself: Change The Game To Suit Your Needs
I'm very pleased to have Rocky as this weeks "Fudsec Friday" guest. I've had the pleasure of meeting Rocky in a business context. I quickly came to appreciate he is one of the minority: an information security professional providing true insight and solutions based on real world experience of what works. To put it simply, Rocky "gets it". If you read just one blog post today, read this one. Thanks Rocky!
By Rocky DeStefano
Recently, I was fortunate enough to have the opportunity to listen in on a speech from General Hayden (former Director of the NSA and CIA, in addition to his service as a four star general in the US Air Force). This man has executed at a level most of use only see through fiction writers and movies and he has done so for 30 + years. I provide that backdrop only to say that when General Hayden speaks, I not only listen, I listen intently and replay his words and overall sentiment in my head very carefully. What he said at this event was encapsulated very well by Richard Bejtlich in this blog post so I won’t go into all the areas described in this post. In short, General Hayden’s speech sparked some long-dormant thought in my feeble brain. His thoughts energized me to refocus my thoughts and actions to go beyond the day-to-day struggles we constantly fight. I was stuck in a rut and didn’t even realize it.
In order to navigate our world and interact with it and one another, we as humans had to learn to fly, we had to learn to navigate the oceans, and we had to learn to overcome distances and difficult terrain, by creating solutions to work with the landscape. We’ve done something quite unique though, we created a new terrain and new domain. The domain we’ve created is fundamentally different while at the same time it is every bit as tangible as the natural domains we exist in. The difference is that this information domain is of human ingenuity and therefore in addition to building tools to work within the landscape, we can actually alter the landscape as we see it. This information domain also exists separately as its own entity and as such evolves at a rate much different than the physical domains. Perhaps most importantly this information domain evolves, dies or otherwise is influenced based on our human interactions. It is moldable. Sure I can agree that humans might affect the temperature of the planet every few thousand years by a fraction of a degree, but we can fundamentally change our information domain on a daily basis if we chose to. Think about it, we all know that, it isn’t new, but at the same time it’s quite liberating to think about the fact that we can change the entire game to suit our needs, versus playing by rules we can’t change or worse yet play in an environment that highlights the strengths of our adversary.
As this domain has evolved we have set in motion a series of evolutionary steps based on tactical requirements without really having a strategic plan for where it should be headed. We made decisions along the way that were necessary to get us past a hurdle, but without much rational thought about the impact. To put it simply there is no city planning going on. We’re continually developing “solutions” to meet short term needs. Granted these are real needs, no question, but who is providing the strategic vision of how our decisions will affect how we interact in the future? For far too long we have applied “fixes” that fit the bounds of the information domain as it exists today. It is time to start looking at how we can transform the domain itself to more appropriately suit our needs moving forward. I’m convinced we are in the very earliest of stages in the evolution (perhaps on the doorstep of revolution) with regard to this domain, but unlike evolution on the natural plain this domain can’t and won’t change itself, we must act to influence it to better meet our needs.
Much to my own amusement I see this domain much like a scene from a kids movie - when Jafar turns is transformed into genie in Disney’s Aladdin and he boasts something like “The Power, The absolute Power, The universe is mine to command, to control, to create” and we get it without the constraint of living in a bottle. The constraints that apply only exist in our minds and actions. We need to get out of the mindset of applying protection techniques based on physical realms and focus on evolving the entire environment to better suit our needs moving forward.
I’m certain as we start this dialogue that more fundamental aspects will arise – which is exactly what I hope to elicit from this dialogue but here his where my current thought process has lead me to consider with regards to how to step out of our box and move our eyes towards the horizon. I’ve bundled my thoughts into a few categories, leadership, research and information sharing. I’m sure your thoughts will help us all to refine this into much more!
Leadership: I’ve come to realize that there is no one coming to save us from ourselves here. No government czar, compliance initiative, nor vendor product suite is going to pave the way. Homeland Security, NSA, Military, Congress, The White House – they’ll all continue to play their part, but let’s be honest here they have not and should not drive the overall thought process here. We must all define how we chose to exist in this domain.
Certainly we should encourage government and legal involvement along the way so that they can contribute as appropriate. In the end the government should be involved to enable us to succeed in this domain, not to define how it should be crafted – at least not without our agreement. Yet we wait the announcement of the all mighty czar… it’s crazy. I believe that we can lead from right here, wherever here happens to be. There are dozens of examples, but I chose just a few to highlight some of the decisions we’ve made and how we can start making better ones moving forward.
1. Information Security Leadership. We need to start pushing back at all levels here. It’s my opinion that business’s need to care much less about being compliant and more about being fundamentally secure – or if you prefer having better visibility into real risk. Risk to the mission, risk to the business not the risk to an asset. We continue to create irrelevant measurements – irrelevant because they are point in time, against a less-than secure model and on a playing field that is skewed towards the success of our adversary.
As information security professionals how on earth did we let the primary financial driver for security spending be compliance initiatives? We sold our souls because we lacked the knowledge of the business and how to apply what we do in a meaningful way to the business. We let compliance initiatives that promised “measurable” results have their way because we thought we could tag along for the ride and implement best possible solutions given the situation. As I see it we are no better off for this and now our teams have either competing agendas or more work to drive us away from protecting our organizations. Sure we’ve created some “building codes” but do “point in time” snapshots matter anymore when the attacker can mold his approach on a whim?
Partners, Vendors play a critical role in helping us reach our goals; they should also play a role in the thought leadership moving forward. Product and solution vendors have done a great job in developing solutions to meet our defined needs along the way as we’ve evolved in our usage of information systems. We’ve all witnessed some seriously cool steps forward over the last 15-20 years, but recently many of those solutions have been evolutionary in nature, not necessarily innovative, but more and more they are band-aid fixes for problems we’ve encountered or realized.
Don’t get me wrong it is a very necessary evolution, but we’ve hit a point that we need to start thinking about long-term health and welfare of how we interact as humans. We need to find ways to encourage that vendor thought leadership onto a larger more strategic problem-set. I would encourage those customer facing people with consulting and/or vendor organizations to take a very basic consultative approach on a daily basis: listen to your customer’s actual needs, not always what they state as a need (PCI Compliance, etc) but to the goals they are really trying to solve and communicate those findings inwardly to your organization (and in general terms externally to the community). The more inputs for this information stream the more refined the thought process can be. You can’t imagine the amount of information that some of these folks have in their heads they just haven’t been heard appropriately.
To those that manage consultants - please encourage your staff to listen and enable meaningful communications, in fact I would challenge you to incentive your staff to provide this input. Give them the opportunity to buy in to more than just a single technology, but into solving a much greater problem. This may mean some major internal change in thought about how to approach management of teams, customer engagements, support, product development, etc – that’s exactly the point – we need to learn to listen better to the larger picture and not the point in time snapshot.
Those were two very basic examples of how we can lead from wherever we sit in the organization there are literally thousands of other examples out there. I hope you can see that I’m suggesting leadership by example – you can still enable business using these techniques, you just have to get past “the way its been done”.
2. A key component in moving forward has to be a dedicated focus on Research and Development. I mean significant investment in R&D on a national and international scale, information sharing about current and proposed strategies across industries, etc. We need to be pushing our employers, VC’s, governments into broader research initiatives. We need an innovation revolution at this point, not just evolutionary point solutions.
There are some very recent initiatives that show promise, like the announcements by Northrop Grumman that NG is sponsoring information research in conjunction with Carnegie Mellon, The Massachusetts Institute of Technology and Purdue University.
If you will, think of these research opportunities as form of health care for our future, I don’t care how it’s justified but we need to act in support of efforts like this in every way we can, perhaps by offering state or federal tax credits? Certainly I can agree that we need to watch spending and as such we should have to pay for performance, but we need to encourage strategic innovation versus tactical evolution (band-aids). The investment in long-term strategy has been anemic at the federal level. We’ll spend millions on watching the effect of gnat bites on mouse nuts, but we haven’t found the necessary stomach to pay for the ability to effectively comprehend where we’re headed as a species as it relates to communications, business and everyday life.
3. Perhaps the most immediate thing we can influence is better Information Sharing. We need to start thinking about how we can change the IT Domain into something that allows for a level playing field. The old adage “The enemy of my enemy is my friend” applies very well here. It’s ridiculous to think that our teams are better off not talking with industry competition about defensive strategies. The other side is free to share, adapt and overcome as they see fit, yet we tie our own hands and ask for beatings – and hope they don’t hurt too much. I’m really not into S&M. I’d rather retake control – how about you?
A few good examples to learn from already exist, the Defense Industrial Base (DIB) has an information sharing related to APT (Advanced Persistent Threat) detection profiles, and workshops like SANS “What Works” or IANS Summits are a great beginning to this conversation, but in reality they are very limited in reach and only relevant at a point in time. We need to develop more daily interaction at a deeper level.
Summary: I’m in no way suggesting I’m intelligent enough to have all the answers, or to have even fully described the problems, I’m simply stating that we need to elevate our thinking and we must invest in the thought process and commit to the information sharing required to make the decisions necessary so that we may shape our own destiny. As I see it we must all act on the relevant fronts (Leadership, Research, Information Sharing, others?) to better comprehend the changes and position ourselves to be able to make the changes necessary in the future. That’s my starting point, how will you enhance the conversation?
Disclaimer:
The opinions expressed here are my personal opinions. My views and opinions are subject to change based on the input I consume and the analysis I apply to those inputs. Content published here is neither read nor approved in advance by my employer and does not necessarily reflect the views and opinions of my employer.
FUDSEC: Liberate Yourself: Change The Game To Suit Your Needs
Comments are encouraged directly on FUDSEC or you can reach me on Twitter (@rockyd) or reach me on this Blog any way you chose to reach out I'd love to hear your input.
ORIGINAL TEXT FROM FUDSEC.COM POST FOLLOWS:
December 4, 2009
Liberate Yourself: Change The Game To Suit Your Needs
I'm very pleased to have Rocky as this weeks "Fudsec Friday" guest. I've had the pleasure of meeting Rocky in a business context. I quickly came to appreciate he is one of the minority: an information security professional providing true insight and solutions based on real world experience of what works. To put it simply, Rocky "gets it". If you read just one blog post today, read this one. Thanks Rocky!
By Rocky DeStefano
Recently, I was fortunate enough to have the opportunity to listen in on a speech from General Hayden (former Director of the NSA and CIA, in addition to his service as a four star general in the US Air Force). This man has executed at a level most of use only see through fiction writers and movies and he has done so for 30 + years. I provide that backdrop only to say that when General Hayden speaks, I not only listen, I listen intently and replay his words and overall sentiment in my head very carefully. What he said at this event was encapsulated very well by Richard Bejtlich in this blog post so I won’t go into all the areas described in this post. In short, General Hayden’s speech sparked some long-dormant thought in my feeble brain. His thoughts energized me to refocus my thoughts and actions to go beyond the day-to-day struggles we constantly fight. I was stuck in a rut and didn’t even realize it.
In order to navigate our world and interact with it and one another, we as humans had to learn to fly, we had to learn to navigate the oceans, and we had to learn to overcome distances and difficult terrain, by creating solutions to work with the landscape. We’ve done something quite unique though, we created a new terrain and new domain. The domain we’ve created is fundamentally different while at the same time it is every bit as tangible as the natural domains we exist in. The difference is that this information domain is of human ingenuity and therefore in addition to building tools to work within the landscape, we can actually alter the landscape as we see it. This information domain also exists separately as its own entity and as such evolves at a rate much different than the physical domains. Perhaps most importantly this information domain evolves, dies or otherwise is influenced based on our human interactions. It is moldable. Sure I can agree that humans might affect the temperature of the planet every few thousand years by a fraction of a degree, but we can fundamentally change our information domain on a daily basis if we chose to. Think about it, we all know that, it isn’t new, but at the same time it’s quite liberating to think about the fact that we can change the entire game to suit our needs, versus playing by rules we can’t change or worse yet play in an environment that highlights the strengths of our adversary.
As this domain has evolved we have set in motion a series of evolutionary steps based on tactical requirements without really having a strategic plan for where it should be headed. We made decisions along the way that were necessary to get us past a hurdle, but without much rational thought about the impact. To put it simply there is no city planning going on. We’re continually developing “solutions” to meet short term needs. Granted these are real needs, no question, but who is providing the strategic vision of how our decisions will affect how we interact in the future? For far too long we have applied “fixes” that fit the bounds of the information domain as it exists today. It is time to start looking at how we can transform the domain itself to more appropriately suit our needs moving forward. I’m convinced we are in the very earliest of stages in the evolution (perhaps on the doorstep of revolution) with regard to this domain, but unlike evolution on the natural plain this domain can’t and won’t change itself, we must act to influence it to better meet our needs.
Much to my own amusement I see this domain much like a scene from a kids movie - when Jafar turns is transformed into genie in Disney’s Aladdin and he boasts something like “The Power, The absolute Power, The universe is mine to command, to control, to create” and we get it without the constraint of living in a bottle. The constraints that apply only exist in our minds and actions. We need to get out of the mindset of applying protection techniques based on physical realms and focus on evolving the entire environment to better suit our needs moving forward.
I’m certain as we start this dialogue that more fundamental aspects will arise – which is exactly what I hope to elicit from this dialogue but here his where my current thought process has lead me to consider with regards to how to step out of our box and move our eyes towards the horizon. I’ve bundled my thoughts into a few categories, leadership, research and information sharing. I’m sure your thoughts will help us all to refine this into much more!
Leadership: I’ve come to realize that there is no one coming to save us from ourselves here. No government czar, compliance initiative, nor vendor product suite is going to pave the way. Homeland Security, NSA, Military, Congress, The White House – they’ll all continue to play their part, but let’s be honest here they have not and should not drive the overall thought process here. We must all define how we chose to exist in this domain.
Certainly we should encourage government and legal involvement along the way so that they can contribute as appropriate. In the end the government should be involved to enable us to succeed in this domain, not to define how it should be crafted – at least not without our agreement. Yet we wait the announcement of the all mighty czar… it’s crazy. I believe that we can lead from right here, wherever here happens to be. There are dozens of examples, but I chose just a few to highlight some of the decisions we’ve made and how we can start making better ones moving forward.
1. Information Security Leadership. We need to start pushing back at all levels here. It’s my opinion that business’s need to care much less about being compliant and more about being fundamentally secure – or if you prefer having better visibility into real risk. Risk to the mission, risk to the business not the risk to an asset. We continue to create irrelevant measurements – irrelevant because they are point in time, against a less-than secure model and on a playing field that is skewed towards the success of our adversary.
As information security professionals how on earth did we let the primary financial driver for security spending be compliance initiatives? We sold our souls because we lacked the knowledge of the business and how to apply what we do in a meaningful way to the business. We let compliance initiatives that promised “measurable” results have their way because we thought we could tag along for the ride and implement best possible solutions given the situation. As I see it we are no better off for this and now our teams have either competing agendas or more work to drive us away from protecting our organizations. Sure we’ve created some “building codes” but do “point in time” snapshots matter anymore when the attacker can mold his approach on a whim?
Partners, Vendors play a critical role in helping us reach our goals; they should also play a role in the thought leadership moving forward. Product and solution vendors have done a great job in developing solutions to meet our defined needs along the way as we’ve evolved in our usage of information systems. We’ve all witnessed some seriously cool steps forward over the last 15-20 years, but recently many of those solutions have been evolutionary in nature, not necessarily innovative, but more and more they are band-aid fixes for problems we’ve encountered or realized.
Don’t get me wrong it is a very necessary evolution, but we’ve hit a point that we need to start thinking about long-term health and welfare of how we interact as humans. We need to find ways to encourage that vendor thought leadership onto a larger more strategic problem-set. I would encourage those customer facing people with consulting and/or vendor organizations to take a very basic consultative approach on a daily basis: listen to your customer’s actual needs, not always what they state as a need (PCI Compliance, etc) but to the goals they are really trying to solve and communicate those findings inwardly to your organization (and in general terms externally to the community). The more inputs for this information stream the more refined the thought process can be. You can’t imagine the amount of information that some of these folks have in their heads they just haven’t been heard appropriately.
To those that manage consultants - please encourage your staff to listen and enable meaningful communications, in fact I would challenge you to incentive your staff to provide this input. Give them the opportunity to buy in to more than just a single technology, but into solving a much greater problem. This may mean some major internal change in thought about how to approach management of teams, customer engagements, support, product development, etc – that’s exactly the point – we need to learn to listen better to the larger picture and not the point in time snapshot.
Those were two very basic examples of how we can lead from wherever we sit in the organization there are literally thousands of other examples out there. I hope you can see that I’m suggesting leadership by example – you can still enable business using these techniques, you just have to get past “the way its been done”.
2. A key component in moving forward has to be a dedicated focus on Research and Development. I mean significant investment in R&D on a national and international scale, information sharing about current and proposed strategies across industries, etc. We need to be pushing our employers, VC’s, governments into broader research initiatives. We need an innovation revolution at this point, not just evolutionary point solutions.
There are some very recent initiatives that show promise, like the announcements by Northrop Grumman that NG is sponsoring information research in conjunction with Carnegie Mellon, The Massachusetts Institute of Technology and Purdue University.
If you will, think of these research opportunities as form of health care for our future, I don’t care how it’s justified but we need to act in support of efforts like this in every way we can, perhaps by offering state or federal tax credits? Certainly I can agree that we need to watch spending and as such we should have to pay for performance, but we need to encourage strategic innovation versus tactical evolution (band-aids). The investment in long-term strategy has been anemic at the federal level. We’ll spend millions on watching the effect of gnat bites on mouse nuts, but we haven’t found the necessary stomach to pay for the ability to effectively comprehend where we’re headed as a species as it relates to communications, business and everyday life.
3. Perhaps the most immediate thing we can influence is better Information Sharing. We need to start thinking about how we can change the IT Domain into something that allows for a level playing field. The old adage “The enemy of my enemy is my friend” applies very well here. It’s ridiculous to think that our teams are better off not talking with industry competition about defensive strategies. The other side is free to share, adapt and overcome as they see fit, yet we tie our own hands and ask for beatings – and hope they don’t hurt too much. I’m really not into S&M. I’d rather retake control – how about you?
A few good examples to learn from already exist, the Defense Industrial Base (DIB) has an information sharing related to APT (Advanced Persistent Threat) detection profiles, and workshops like SANS “What Works” or IANS Summits are a great beginning to this conversation, but in reality they are very limited in reach and only relevant at a point in time. We need to develop more daily interaction at a deeper level.
Summary: I’m in no way suggesting I’m intelligent enough to have all the answers, or to have even fully described the problems, I’m simply stating that we need to elevate our thinking and we must invest in the thought process and commit to the information sharing required to make the decisions necessary so that we may shape our own destiny. As I see it we must all act on the relevant fronts (Leadership, Research, Information Sharing, others?) to better comprehend the changes and position ourselves to be able to make the changes necessary in the future. That’s my starting point, how will you enhance the conversation?
Disclaimer:
The opinions expressed here are my personal opinions. My views and opinions are subject to change based on the input I consume and the analysis I apply to those inputs. Content published here is neither read nor approved in advance by my employer and does not necessarily reflect the views and opinions of my employer.
Tuesday, October 27, 2009
Low Level Information Collection
This morning as my wife was leaving for work she noticed a extended cab pickup truck parked out in front of our neighbor's house. As she began to pull out of the driveway she noted that the driver got out and was beginning to go through the neighbors trash. My wife parked at the end of the street and then called me. I dismissed it at first but as I observed for a few moments I was amazed at how thoroughly this gentleman was going through each bag. His urgency and purpose was like he was looking for a lost wedding ring.
Needing something to do today I walked up to him and inquired about what he was doing. Obviously and physically taken aback by me confronting him, he produced a toy out of his pocket and told me he "wasn't doing anything" that he was just looking for toys and gave me a sheepish grin. My kids do a much better job of acting.
Given the nature of the truck (at 50K+ it was probably either his employer's or stolen), the fact their was no car seat was in it, his "look-out", and his overall demeanor I pressed a little harder. I asked him about the pile of papers he was so carefully gathering. Of course all of the sudden his knowledge of the english language ceased to exist and he was in a hurry to leave. In spanish he yelled to his wife to get ready to go and that he didn't like the situation. So I switched to spanish and surprised him even further. I was able to retrieve the papers from him before he ran into his truck that his wife was starting to drive away in. Damn, I was just starting to have fun with him, well at least the cops should be able to retrieve the stolen truck pretty quickly.
I'm fully cognizant of the fact that financially times are hard right now and people need to do what they can to survive. I'm not against him looking for toys or taking broken household equipment to repair or any number of other things that people quickly retrieve from others discarded household items. I'm very leery of how organized and thorough this team was. 1. The vehicle fit into it surroundings, except we live on a cul-de-sac with very low traffic. 2. He had an obvious "look-out" who was intently watching my wife 3. He dissected every bag, quickly and efficiently 4. Timing - he hit the garbage in the two hour window it sits outside.
Yes I'm probably paranoid but I can almost guarantee that this team worked as part of a larger organization paid by the pound of paper they collect or otherwise compensated for what they found. It's highly lucrative, insulates upper layers and incredibly simple to execute. It could have been a precursor to a physical intrusion, but honestly that's not going to nearly as lucrative as the identify theft angle.
Recommendations:
1. Be aware of your surroundings. If it seems out of place - find out why. At a minimum observe and report to your local police department.
2. Shred everything, no matter how "insignificant" it is. If I'm honest with myself 've been horrible about this at home. I have a shredder two feet from me that is going to be fed well today!
3. Carefully screen who you let in your home. Technicians, Cleaners, Painters. There are so many ways to extend this type of collection activity it isn't even funny.
4. Talk with your neighbors. It's much easier if everyone is fully aware of what is going on and can help observe and act as necessary. You can also get trusted recommendations for service help. Plus the holidays are coming - just go out and be nice.
5. Check your credit report from all three major players every month. The odds are that your identity or at a minimum your credit/bank account will be compromised at least once. The quicker you can identify it the easier the mess is to clean up.
Needing something to do today I walked up to him and inquired about what he was doing. Obviously and physically taken aback by me confronting him, he produced a toy out of his pocket and told me he "wasn't doing anything" that he was just looking for toys and gave me a sheepish grin. My kids do a much better job of acting.
Given the nature of the truck (at 50K+ it was probably either his employer's or stolen), the fact their was no car seat was in it, his "look-out", and his overall demeanor I pressed a little harder. I asked him about the pile of papers he was so carefully gathering. Of course all of the sudden his knowledge of the english language ceased to exist and he was in a hurry to leave. In spanish he yelled to his wife to get ready to go and that he didn't like the situation. So I switched to spanish and surprised him even further. I was able to retrieve the papers from him before he ran into his truck that his wife was starting to drive away in. Damn, I was just starting to have fun with him, well at least the cops should be able to retrieve the stolen truck pretty quickly.
I'm fully cognizant of the fact that financially times are hard right now and people need to do what they can to survive. I'm not against him looking for toys or taking broken household equipment to repair or any number of other things that people quickly retrieve from others discarded household items. I'm very leery of how organized and thorough this team was. 1. The vehicle fit into it surroundings, except we live on a cul-de-sac with very low traffic. 2. He had an obvious "look-out" who was intently watching my wife 3. He dissected every bag, quickly and efficiently 4. Timing - he hit the garbage in the two hour window it sits outside.
Yes I'm probably paranoid but I can almost guarantee that this team worked as part of a larger organization paid by the pound of paper they collect or otherwise compensated for what they found. It's highly lucrative, insulates upper layers and incredibly simple to execute. It could have been a precursor to a physical intrusion, but honestly that's not going to nearly as lucrative as the identify theft angle.
Recommendations:
1. Be aware of your surroundings. If it seems out of place - find out why. At a minimum observe and report to your local police department.
2. Shred everything, no matter how "insignificant" it is. If I'm honest with myself 've been horrible about this at home. I have a shredder two feet from me that is going to be fed well today!
3. Carefully screen who you let in your home. Technicians, Cleaners, Painters. There are so many ways to extend this type of collection activity it isn't even funny.
4. Talk with your neighbors. It's much easier if everyone is fully aware of what is going on and can help observe and act as necessary. You can also get trusted recommendations for service help. Plus the holidays are coming - just go out and be nice.
5. Check your credit report from all three major players every month. The odds are that your identity or at a minimum your credit/bank account will be compromised at least once. The quicker you can identify it the easier the mess is to clean up.
Sunday, August 30, 2009
SIEM 201 Use Case Overview
Part 2 of Decurity's "Back to School" Series: SIEM 201: SIEM Use Case Definition
Course Prerequisites: A while back I published a diagram and associated text illustrating the benefits of a combined SIEM and Log Management architecture. This diagram/post did a good job of explaining the features and functionality of Log Management and SIEM at a very high level. If you haven't seen that post or if you haven’t read Decurity's SIEM 101 previously I would encourage you to go back and take a look. Basic concepts from those resources will help in understanding of Use-Cases and how they apply to SIEM .
Introduction:
In my experience I’ve noticed that SIEM customers use something like 30% of less of the functionality of the tool they bought. That number is actually probably pretty high when you consider the fact that a very high percentage of customers are only using the default content that came pre-installed or was "customized" during a professional services engagement. There are some very advanced users out there, no doubt and this post will help them as well, but it is really focused on providing a framework to advance the majority of SIEM users so they can gain better appreciation for how to maximize the value of their SIEM investment.
The process (and diagram) that follows, outlines how Decurity looks at use-cases related to SIEM. We are providing this information in the hopes that you'll internalize it as part of your SIEM operations. Decurity will also be announcing in the very near future an online solution using this methodology so that you can track/update/share your use-cases/solutions - contact us if you're interested in learning more about that solution.
Use-Case Requirement:
The most simplistic advice I can give is that you should try to focus on the output first. What is the point of the work effort? What is the problem we are trying to solve? What is the intended action/output? Who benefits from this and more importantly why do they benefit from this solution? Then you can move into questions like - what information is required to solve the problem?
The information provided in this article will help to guide you through the process. Implementing solutions in your SIEM in an ad-hoc manner will result in failure or at best very temporary and minimalistic gains. If you don’t believe me you can ask any of the hundreds of organizations who tried it before you.
Use-Case Illustration:
General:
This is the most basic logistical information related to the use-case and related solution. It provides a documentation framework.
• Author: Who was involved in the creation/authoring of the solution?
• ID, Version and Date: What is the current version and ID and last date of update.
• Objects, Artifacts: Link to objects (externalized or within solution) used within the solution for example, the configuration objects like report, rules, dashboards, etc.
• Solution Description: Quick reference to the solution, using categorization that makes sense for your organization.
• References: Corporate or External documents that act as reference material for your use-case and/or solution.
Business Justification: This is the problem being addressed from a corporate perspective. One or more Business problems may apply, but each should be documented in some fashion.
• Business Problem Description: What are the specific problems that need to be addressed?
• Business Owner(s): Who owns the actions for output of the system? Who owns relevant Systems, Applications and Data? Who is requesting Assistance?
• Business Perspective: Security, Compliance, Risk, Audit, Fraud, Legal, HR, Other?
• Current Solution: Today how is this problem addressed? How can it be improved?
• Expectations: What is it that the business owners expect from the solution?
• Priority: What is the value of solving this issue, or conversely what is the cost of not solving this issue?
Technical Requirements:
• Need: Active Statements – “The system shall”, “We have to” *(DO SOMETHING)* Define that something.
• Action: Action(s) and/or Output(s) required from the system.
• Actor: Relative to a *(PERSON/TEAM)*
• Event: Specific scenario(s) to be evaluated.
• Context: Relevant environmental conditions. How does our knowledge of this environment affect how we can refine the analysis and output? Some examples of context that should be considered are: Organizational Structure, Business Units, Application and/or Data Categorizations, Network Segmentation, System Configurations, Users, “Hot Lists”, Vulnerability Data, Data/System/User Criticality, other environment specific information.
• Timing: Within, before, at, during, after.
• Logic: Boolean Logic Statements (T/F) using AND, OR, IF, THEN, NOT as conditions.
Collection:
• Data Source(s): What data sources would provide the best context? What information do we have already available?
• Data Accessibility: Are there physical, logical, business, technical or political barriers to having the relevant data?
• Data Format: is the data readily comprehended by our solution, is customization of the data necessary or possible? Do we need to update logging standards?
• Data Relevance:
o Content: What elements of the data provide us the necessary context? Which exact fields are relevant?
o Timing: Do we receive it often enough to be relevant to our proposed solution?
• Data Location: Does the data reside in a centralized, easily accessed location? Is it already aggregated, normalized or filtered in a way that would adversely affect our proposed solution?
Note: You can and should use these questions and related answers as justification for your enterprise visibility project. Logging Standards, Data Access and reliable access to the information are very often the proverbial “long pole”.
Proposed Solution:
• Technology/Process: Does SIEM make sense to solve this problem, given the data we have, our environment and the proposed solution? Can we solve this using other technology or processes in a more efficient/effective manner? SIEM is great, but not always the answer.
• Configuration: What SIEM configuration(s) provide us with the most efficient and effective solution. Is it simply a report or do we need to leverage advanced meta-correlation? Does Statistical evaluation help? Describe possibilities and known variables/obstacles. Know the capabilities of your product will help you to understand how to configure it. Advanced Use-Cases, Custom Applications, Fraud Detection, etc require a non-traditional data set and logic approach - well at least non-traditional from the security administrator perspective. Having the flexibility to "compare" against user-defined fields is key to solving those use-cases. If you find yourself unable to solve a number of “Core” use-cases then it might be time to consider training, external advice or as a last resort a new solution.
• Expected Outcome: What is it that we expect to see from the system? For example (Within “n” Minutes, we should see “x” when “y” occurs.)
• Known False Positive: How are false positives differentiated from known bad activities and how can we tune our systems/data/environment to reduce the number of valid activities we respond to?
• Known Gaps: Relative to the problem-set described what do we expect that this solution will miss? How can we close those gaps?
• Alternative Methods: Within the SIEM or external to SIEM what are alternative ways to address some subset of this problem? Do related solutions already exist?
QA:
• Performance: is the solution Efficient? Does it cause significant system degradation? Have you built “content” to monitor for efficiency?
• Functionality: Is this providing an acceptable solution for the users and owners? Are refinements required?
• Measurements: Technical effectiveness, Resource Utilization Measurements.
• Lab Validation: Were Lab tests meaningful and successful?
Note: You might get the sense from my wording that QA is an ongoing activity, you’d be correct. If you lab has irrelevant data/systems your tests are meaningless. Testing new correlation scenarios against existing data set is invaluable. Knowing how the system is going to respond before you implement into production saves time, effort and headaches.
Operations:
• Feedback: You need a periodic feedback loop to ensure you are in touch with their needs and updating/planning around upcoming requirements.
• Monitor: Changes are inevitable, from process, people, environment to threats and data sets you will need to stay in touch with how your SIEM is supporting the evolving requirements.
• Refine: simple refinements may be applied daily/weekly/monthly.
• Enhance: Do we need to add more/better data sets? Is there better Logic that can be applied? Do new or related use-cases offer better insight?
• Validations: What is the “normal” operation look of this use-case look like and how would you know abnormal behavior of your solution?
Course Summary:
So it should be clear by now that we think SIEM is a great tool, with tons of potential to identify new activities you couldn’t previously consider and to automate “definable” activities and facilitate workflow. It should also be obvious that SIEM requires planning, testing and ongoing operational support to be most effective for you and your organization. This guide and related articles/posts will go a long way to assist you with your efforts. If not, reach out and we’ll find other ways to help you!
Remember that SIEM is a process not just a tool. If you aren't making changes to your SIEM on a daily basis (or having someone make changes for you) you are not getting the most from your SIEM. Threats constantly evolve, your networks/systems/data/users are always being modified, your understanding of your environment is always changing, shouldn’t your detection techniques also be enhanced on a daily basis? The more time you spend on use-cases as identified in this post the more value you'll receive out of your SIEM.
Disclaimer: Not every vendor solves problems in the same manner. Due to technological differences, wildly varying skills of consultants and comprehension of actual problem and/or data you mileage will vary. That said the approach we are documenting here will work with any SIEM and should be used every time you think about solving new problems using your SIEM. It does mean effort has to be applied, but it also means you will have objective measurements of success when it comes to the value your SIEM is providing.
Course Prerequisites: A while back I published a diagram and associated text illustrating the benefits of a combined SIEM and Log Management architecture. This diagram/post did a good job of explaining the features and functionality of Log Management and SIEM at a very high level. If you haven't seen that post or if you haven’t read Decurity's SIEM 101 previously I would encourage you to go back and take a look. Basic concepts from those resources will help in understanding of Use-Cases and how they apply to SIEM .
Introduction:
In my experience I’ve noticed that SIEM customers use something like 30% of less of the functionality of the tool they bought. That number is actually probably pretty high when you consider the fact that a very high percentage of customers are only using the default content that came pre-installed or was "customized" during a professional services engagement. There are some very advanced users out there, no doubt and this post will help them as well, but it is really focused on providing a framework to advance the majority of SIEM users so they can gain better appreciation for how to maximize the value of their SIEM investment.
The process (and diagram) that follows, outlines how Decurity looks at use-cases related to SIEM. We are providing this information in the hopes that you'll internalize it as part of your SIEM operations. Decurity will also be announcing in the very near future an online solution using this methodology so that you can track/update/share your use-cases/solutions - contact us if you're interested in learning more about that solution.
Use-Case Requirement:
The most simplistic advice I can give is that you should try to focus on the output first. What is the point of the work effort? What is the problem we are trying to solve? What is the intended action/output? Who benefits from this and more importantly why do they benefit from this solution? Then you can move into questions like - what information is required to solve the problem?
The information provided in this article will help to guide you through the process. Implementing solutions in your SIEM in an ad-hoc manner will result in failure or at best very temporary and minimalistic gains. If you don’t believe me you can ask any of the hundreds of organizations who tried it before you.
Use-Case Illustration:
General:
This is the most basic logistical information related to the use-case and related solution. It provides a documentation framework.
• Author: Who was involved in the creation/authoring of the solution?
• ID, Version and Date: What is the current version and ID and last date of update.
• Objects, Artifacts: Link to objects (externalized or within solution) used within the solution for example, the configuration objects like report, rules, dashboards, etc.
• Solution Description: Quick reference to the solution, using categorization that makes sense for your organization.
• References: Corporate or External documents that act as reference material for your use-case and/or solution.
Business Justification: This is the problem being addressed from a corporate perspective. One or more Business problems may apply, but each should be documented in some fashion.
• Business Problem Description: What are the specific problems that need to be addressed?
• Business Owner(s): Who owns the actions for output of the system? Who owns relevant Systems, Applications and Data? Who is requesting Assistance?
• Business Perspective: Security, Compliance, Risk, Audit, Fraud, Legal, HR, Other?
• Current Solution: Today how is this problem addressed? How can it be improved?
• Expectations: What is it that the business owners expect from the solution?
• Priority: What is the value of solving this issue, or conversely what is the cost of not solving this issue?
Technical Requirements:
• Need: Active Statements – “The system shall”, “We have to” *(DO SOMETHING)* Define that something.
• Action: Action(s) and/or Output(s) required from the system.
• Actor: Relative to a *(PERSON/TEAM)*
• Event: Specific scenario(s) to be evaluated.
• Context: Relevant environmental conditions. How does our knowledge of this environment affect how we can refine the analysis and output? Some examples of context that should be considered are: Organizational Structure, Business Units, Application and/or Data Categorizations, Network Segmentation, System Configurations, Users, “Hot Lists”, Vulnerability Data, Data/System/User Criticality, other environment specific information.
• Timing: Within, before, at, during, after.
• Logic: Boolean Logic Statements (T/F) using AND, OR, IF, THEN, NOT as conditions.
Collection:
• Data Source(s): What data sources would provide the best context? What information do we have already available?
• Data Accessibility: Are there physical, logical, business, technical or political barriers to having the relevant data?
• Data Format: is the data readily comprehended by our solution, is customization of the data necessary or possible? Do we need to update logging standards?
• Data Relevance:
o Content: What elements of the data provide us the necessary context? Which exact fields are relevant?
o Timing: Do we receive it often enough to be relevant to our proposed solution?
• Data Location: Does the data reside in a centralized, easily accessed location? Is it already aggregated, normalized or filtered in a way that would adversely affect our proposed solution?
Note: You can and should use these questions and related answers as justification for your enterprise visibility project. Logging Standards, Data Access and reliable access to the information are very often the proverbial “long pole”.
Proposed Solution:
• Technology/Process: Does SIEM make sense to solve this problem, given the data we have, our environment and the proposed solution? Can we solve this using other technology or processes in a more efficient/effective manner? SIEM is great, but not always the answer.
• Configuration: What SIEM configuration(s) provide us with the most efficient and effective solution. Is it simply a report or do we need to leverage advanced meta-correlation? Does Statistical evaluation help? Describe possibilities and known variables/obstacles. Know the capabilities of your product will help you to understand how to configure it. Advanced Use-Cases, Custom Applications, Fraud Detection, etc require a non-traditional data set and logic approach - well at least non-traditional from the security administrator perspective. Having the flexibility to "compare" against user-defined fields is key to solving those use-cases. If you find yourself unable to solve a number of “Core” use-cases then it might be time to consider training, external advice or as a last resort a new solution.
• Expected Outcome: What is it that we expect to see from the system? For example (Within “n” Minutes, we should see “x” when “y” occurs.)
• Known False Positive: How are false positives differentiated from known bad activities and how can we tune our systems/data/environment to reduce the number of valid activities we respond to?
• Known Gaps: Relative to the problem-set described what do we expect that this solution will miss? How can we close those gaps?
• Alternative Methods: Within the SIEM or external to SIEM what are alternative ways to address some subset of this problem? Do related solutions already exist?
QA:
• Performance: is the solution Efficient? Does it cause significant system degradation? Have you built “content” to monitor for efficiency?
• Functionality: Is this providing an acceptable solution for the users and owners? Are refinements required?
• Measurements: Technical effectiveness, Resource Utilization Measurements.
• Lab Validation: Were Lab tests meaningful and successful?
Note: You might get the sense from my wording that QA is an ongoing activity, you’d be correct. If you lab has irrelevant data/systems your tests are meaningless. Testing new correlation scenarios against existing data set is invaluable. Knowing how the system is going to respond before you implement into production saves time, effort and headaches.
Operations:
• Feedback: You need a periodic feedback loop to ensure you are in touch with their needs and updating/planning around upcoming requirements.
• Monitor: Changes are inevitable, from process, people, environment to threats and data sets you will need to stay in touch with how your SIEM is supporting the evolving requirements.
• Refine: simple refinements may be applied daily/weekly/monthly.
• Enhance: Do we need to add more/better data sets? Is there better Logic that can be applied? Do new or related use-cases offer better insight?
• Validations: What is the “normal” operation look of this use-case look like and how would you know abnormal behavior of your solution?
Course Summary:
So it should be clear by now that we think SIEM is a great tool, with tons of potential to identify new activities you couldn’t previously consider and to automate “definable” activities and facilitate workflow. It should also be obvious that SIEM requires planning, testing and ongoing operational support to be most effective for you and your organization. This guide and related articles/posts will go a long way to assist you with your efforts. If not, reach out and we’ll find other ways to help you!
Remember that SIEM is a process not just a tool. If you aren't making changes to your SIEM on a daily basis (or having someone make changes for you) you are not getting the most from your SIEM. Threats constantly evolve, your networks/systems/data/users are always being modified, your understanding of your environment is always changing, shouldn’t your detection techniques also be enhanced on a daily basis? The more time you spend on use-cases as identified in this post the more value you'll receive out of your SIEM.
Disclaimer: Not every vendor solves problems in the same manner. Due to technological differences, wildly varying skills of consultants and comprehension of actual problem and/or data you mileage will vary. That said the approach we are documenting here will work with any SIEM and should be used every time you think about solving new problems using your SIEM. It does mean effort has to be applied, but it also means you will have objective measurements of success when it comes to the value your SIEM is providing.
Monday, August 24, 2009
SIEM 101: an introduction to SIEM functionality
Just in time for "Back to School" Decurity presents "SIEM 101": An introduction into SIEM functionality. What is SIEM correlation? What does it deliver? What is the value to a business or organization? What is aggregation, normalization, prioritization and how do they differ or enable correlation scenarios?
Every SIEM Vendor seems to have a different definition and marketing spiel about the functionality of SIEM “correlation”. Some times correlation is described in a manner that evokes thoughts of a magic trick, other times it is simply labeled as “too confusing” and therefore not relevant. Obviously, this causes confusion and an inconsistent expectations, or should I say anticipation, of the results that correlation will (or won’t) deliver. This results in the prospective customer ending up with a skewed perspective and, in all likelihood dissatisfaction. On the other hand it may also result in the customer not knowing the full extent of the power the solution makes available to them. Neither situation benefits anyone involved. The purpose of this posting is to help describe common SIEM functionality so that current and prospective users of SIEM can effectively compare the capabilities of different vendors purporting to support or deliver “correlation”.
Some Basic SIEM Terminology. Let's start by outlining some basic terminology and functionality included in most SIEM solutions to provide some context. After that, we will be able to dive deeper into what is correlation and its related functionality.
Collection: Collection refers to the process of obtaining the logged information from various event sources. The “battle” of agent versus agent-less is meaningless should just be ignored as marketing fluff. Things like network architecture, Network speed/latency, event source platforms, security, compliance and your environment variables all drive the decision of where is the best place to locate an agent/collector to collect information. It is simply a matter of your use-cases and environment that drive your deployment architecture decisions.
Event Sources: These are the devices/systems that generate events for consideration. Inclusion of the "right" event sources, logging in the "right" way is absolutely critical to the success of your SIEM. The SIEM can't consider information that does not exist or is not contextually relevant with other information in the system. I'll spend more time on this topic in an upcoming "SIEM 201" blog post.
Normalization: This is the process, at either the collector (agent) or SIEM engine that makes sense of the event data being input into the system. The normalization process tries to map the different log event data formats into a common structure, or taxonomy, or in some cases indices, so that things common fields like names, activity type, timestamps and IP addresses, etc can be quickly compared using a simple taxonomy. Usually this means that the data is more accessible and efficiently stored for the SIEM solution. Each vendor performs this process differently in the background and the level of functionality, intelligence and capabilities associated with the process varies for each vendor, some do it well, some don’t. Some vendor solutions don’t index/normalize on input into the system, they accomplish this task when the user requests output from the system.
Aggregation: This process summaries (counts) event data, based on (hopefully) flexible pre-defined fields. The purpose of this process is to reduce the event data load, either in terms of network traffic, data storage and/or SIEM engine efficiency.
A typical example of this process can happen if the following situation is detected:
1. "N" number of events
2. That contain the same event characteristics
3. For a given timeframe
In this situation the aggregation process could send one event record with a count inside it, instead of sending all of the individual event records. A flexible SIEM solution should allow you to decide which fields are leveraged in the aggregation process, allow you to specify the event field characteristics that must be similar, and what information should be included in the summarized event record. The downside to aggregation, if it is incorrectly configured or designed, is loss of important information (i.e. it could cause more Aggravation then Aggregation.).
Thresholding: Some consider thresholding to be correlation. I consider thresholding to be aggregation with alerting. “N” events occurred in a sliding time window, then let someone know. An example of this could be the popular “number of failed logins over a fixed period of time”.
Filtering: This is the ability to ignore, suppress or block certain event records or messages from being processed or displayed. Some consideration is required if you decide to start suppressing messages or event records. It can be a great way to reduce “noise”, but it is also a very good way to lose very important context from “previously unknown” activities.
Intelligent Filtering is the process by which you forward events from a Log Management device to a SIEM on a per Use-Case basis. Ensuring the full data set is fully searchable and easily available within the overall solution, without overloading the SIEM. Keeps costs down, increases efficiency and enhances solution value.
Simple Prioritization: This is the process of mapping of the message priority, assigned by a particular event source vendor, for an event record to the SIEM's message priority.
For example, IDS vendor "X" assigns an event with a priority of "1a". The mapping process takes this value and translates it to the SIEM Vendor's priority field and assigns a value of "10" which indicates that the priority is "High/Critical". All similar events will always have similar priority. This functionality is typically mapped at the agent/collector, but can also be accomplished at the engine depending on the Vendor.
Advanced Prioritization: This is similar to simple prioritization, with the addition of context from the environment or from how SIEM has been configured. This offers more dynamic prioritization model for similar type events. An example is a priority schema that takes into account, current Vulnerability information for a targeted asset. If the target has a relevant vulnerability and a corresponding IDS Event is received, then the priority of the alerts is raised (it is relevant). On the other hand, if the vulnerability (or system) does not exist, then the priority is reduced to "Informational", for this particular event. This functionality is typically performed at the SIEM Engine. This is one way to highlight known-bad activity and help prioritize workflow. Advanced prioritization might be considered a form of very basic correlation by some.
Ok with that in mind, what is Correlation?
As I see it correlation included the evaluation of collected data by using one or more of the following methods:
(1) Pre-defined pattern matching
(2) Statistical analysis (anomaly detection)
(3) Basic conditional Boolean logic statements
(4) Contextually relevant and/or enhanced data set + Boolean logic
Correlation output: the goal of event correlation is to produce a meaningful ”event of interest” that is intended to create output for use by either other correlation criteria, or to influence and/or directly enable workflow creating actionable output (potential incident identification).
Meaning either
(1) You have a higher degree of confidence that something bad has happened or,
(2) You now know something that you did not or could not know previously.
Additional functions used within Correlation:
Comparison List/Capability: IP, Subnet, ASN, Domain Names, File Names, MAC Address, User names, Event IDs, Custom Attributes, etc. Being able to dynamically update and/or query these lists with or without Boolean logic allows your correlation scenarios to include "fresh" information all the time. Linking lists allows for even more flexibility in prioritization of events. Events can move between lists based on thresholding or other learned context. Move from suspicious to malicious or from malicious to normal based on how correlation scenarios are defined. Decurity’s Threat Intelligence Offering keeps these current for you!
SIEM Boolean Logic: True/False and the use of IF, THEN, AND/OR, NOT variables. This is the process where you articulate your logic statements. More on this in the “201” blog post coming soon.
Statistical Evaluation: In my mind this is by far the most underutilized component of some SIEM solutions. Anomaly detection, Thresholding and even comparison can be accomplished in a very scalable and in most cases a low overhead manner using the correct set of statistical evaluations. The output of these evaluations can also be "events" for comparison is advanced correlation scenarios. Expert usage only.
Contextual Comparison: Vulnerability Info, System (Computer or Network Node) Information, Application Information, User Information, or other categorized attributes describing how the network, systems, users, applications or data are used and/or organized. The more context added to each correlation scenario the more refined (and meaningful) the output will be. In most cases, if accomplished correctly it also means the most efficient use of system resources. A Simple example could be defining assets with PCI, PII relevance.
Meta Correlation: Using SIEM enhanced data from previously/currently correlated events to form new correlation scenarios. This can also use the output of Statistical evaluations. The meta-correlation can be between previous correlated events and new event stream data or multiple previous correlated events. This is also how many systems handle basic scalability or higher tier deployment scenarios. A baseline of content is deployed at lower tiers and matching events are forwarded upward for inclusion in “enterprise-wide” correlation scenarios.
Summary:
Correlation is a very powerful SIEM functions that can help you refine the identification of anomalous or malicious activity. If your (the customer) can articulate your use-cases clearly, then most vendors can find a way to solve the defined problem using existing functionality within their product set. It is my hope that you will be able to use this blog post as a way to map the various solution offerings to a common and understandable taxonomy so you can fully comprehend what you are getting with each solution.
In the next post in this "Back to School" series (SIEM Correlation 201) we’ll talk about Use Case Definitions, Event Sources, Performance Impact, Flexibility and Scalability.
"ring, ring" class dismissed until next week.
-Rocky
Every SIEM Vendor seems to have a different definition and marketing spiel about the functionality of SIEM “correlation”. Some times correlation is described in a manner that evokes thoughts of a magic trick, other times it is simply labeled as “too confusing” and therefore not relevant. Obviously, this causes confusion and an inconsistent expectations, or should I say anticipation, of the results that correlation will (or won’t) deliver. This results in the prospective customer ending up with a skewed perspective and, in all likelihood dissatisfaction. On the other hand it may also result in the customer not knowing the full extent of the power the solution makes available to them. Neither situation benefits anyone involved. The purpose of this posting is to help describe common SIEM functionality so that current and prospective users of SIEM can effectively compare the capabilities of different vendors purporting to support or deliver “correlation”.
Some Basic SIEM Terminology. Let's start by outlining some basic terminology and functionality included in most SIEM solutions to provide some context. After that, we will be able to dive deeper into what is correlation and its related functionality.
Collection: Collection refers to the process of obtaining the logged information from various event sources. The “battle” of agent versus agent-less is meaningless should just be ignored as marketing fluff. Things like network architecture, Network speed/latency, event source platforms, security, compliance and your environment variables all drive the decision of where is the best place to locate an agent/collector to collect information. It is simply a matter of your use-cases and environment that drive your deployment architecture decisions.
Event Sources: These are the devices/systems that generate events for consideration. Inclusion of the "right" event sources, logging in the "right" way is absolutely critical to the success of your SIEM. The SIEM can't consider information that does not exist or is not contextually relevant with other information in the system. I'll spend more time on this topic in an upcoming "SIEM 201" blog post.
Normalization: This is the process, at either the collector (agent) or SIEM engine that makes sense of the event data being input into the system. The normalization process tries to map the different log event data formats into a common structure, or taxonomy, or in some cases indices, so that things common fields like names, activity type, timestamps and IP addresses, etc can be quickly compared using a simple taxonomy. Usually this means that the data is more accessible and efficiently stored for the SIEM solution. Each vendor performs this process differently in the background and the level of functionality, intelligence and capabilities associated with the process varies for each vendor, some do it well, some don’t. Some vendor solutions don’t index/normalize on input into the system, they accomplish this task when the user requests output from the system.
Aggregation: This process summaries (counts) event data, based on (hopefully) flexible pre-defined fields. The purpose of this process is to reduce the event data load, either in terms of network traffic, data storage and/or SIEM engine efficiency.
A typical example of this process can happen if the following situation is detected:
1. "N" number of events
2. That contain the same event characteristics
3. For a given timeframe
In this situation the aggregation process could send one event record with a count inside it, instead of sending all of the individual event records. A flexible SIEM solution should allow you to decide which fields are leveraged in the aggregation process, allow you to specify the event field characteristics that must be similar, and what information should be included in the summarized event record. The downside to aggregation, if it is incorrectly configured or designed, is loss of important information (i.e. it could cause more Aggravation then Aggregation.).
Thresholding: Some consider thresholding to be correlation. I consider thresholding to be aggregation with alerting. “N” events occurred in a sliding time window, then let someone know. An example of this could be the popular “number of failed logins over a fixed period of time”.
Filtering: This is the ability to ignore, suppress or block certain event records or messages from being processed or displayed. Some consideration is required if you decide to start suppressing messages or event records. It can be a great way to reduce “noise”, but it is also a very good way to lose very important context from “previously unknown” activities.
Intelligent Filtering is the process by which you forward events from a Log Management device to a SIEM on a per Use-Case basis. Ensuring the full data set is fully searchable and easily available within the overall solution, without overloading the SIEM. Keeps costs down, increases efficiency and enhances solution value.
Simple Prioritization: This is the process of mapping of the message priority, assigned by a particular event source vendor, for an event record to the SIEM's message priority.
For example, IDS vendor "X" assigns an event with a priority of "1a". The mapping process takes this value and translates it to the SIEM Vendor's priority field and assigns a value of "10" which indicates that the priority is "High/Critical". All similar events will always have similar priority. This functionality is typically mapped at the agent/collector, but can also be accomplished at the engine depending on the Vendor.
Advanced Prioritization: This is similar to simple prioritization, with the addition of context from the environment or from how SIEM has been configured. This offers more dynamic prioritization model for similar type events. An example is a priority schema that takes into account, current Vulnerability information for a targeted asset. If the target has a relevant vulnerability and a corresponding IDS Event is received, then the priority of the alerts is raised (it is relevant). On the other hand, if the vulnerability (or system) does not exist, then the priority is reduced to "Informational", for this particular event. This functionality is typically performed at the SIEM Engine. This is one way to highlight known-bad activity and help prioritize workflow. Advanced prioritization might be considered a form of very basic correlation by some.
Ok with that in mind, what is Correlation?
As I see it correlation included the evaluation of collected data by using one or more of the following methods:
(1) Pre-defined pattern matching
(2) Statistical analysis (anomaly detection)
(3) Basic conditional Boolean logic statements
(4) Contextually relevant and/or enhanced data set + Boolean logic
Correlation output: the goal of event correlation is to produce a meaningful ”event of interest” that is intended to create output for use by either other correlation criteria, or to influence and/or directly enable workflow creating actionable output (potential incident identification).
Meaning either
(1) You have a higher degree of confidence that something bad has happened or,
(2) You now know something that you did not or could not know previously.
Additional functions used within Correlation:
Comparison List/Capability: IP, Subnet, ASN, Domain Names, File Names, MAC Address, User names, Event IDs, Custom Attributes, etc. Being able to dynamically update and/or query these lists with or without Boolean logic allows your correlation scenarios to include "fresh" information all the time. Linking lists allows for even more flexibility in prioritization of events. Events can move between lists based on thresholding or other learned context. Move from suspicious to malicious or from malicious to normal based on how correlation scenarios are defined. Decurity’s Threat Intelligence Offering keeps these current for you!
SIEM Boolean Logic: True/False and the use of IF, THEN, AND/OR, NOT variables. This is the process where you articulate your logic statements. More on this in the “201” blog post coming soon.
Statistical Evaluation: In my mind this is by far the most underutilized component of some SIEM solutions. Anomaly detection, Thresholding and even comparison can be accomplished in a very scalable and in most cases a low overhead manner using the correct set of statistical evaluations. The output of these evaluations can also be "events" for comparison is advanced correlation scenarios. Expert usage only.
Contextual Comparison: Vulnerability Info, System (Computer or Network Node) Information, Application Information, User Information, or other categorized attributes describing how the network, systems, users, applications or data are used and/or organized. The more context added to each correlation scenario the more refined (and meaningful) the output will be. In most cases, if accomplished correctly it also means the most efficient use of system resources. A Simple example could be defining assets with PCI, PII relevance.
Meta Correlation: Using SIEM enhanced data from previously/currently correlated events to form new correlation scenarios. This can also use the output of Statistical evaluations. The meta-correlation can be between previous correlated events and new event stream data or multiple previous correlated events. This is also how many systems handle basic scalability or higher tier deployment scenarios. A baseline of content is deployed at lower tiers and matching events are forwarded upward for inclusion in “enterprise-wide” correlation scenarios.
Summary:
Correlation is a very powerful SIEM functions that can help you refine the identification of anomalous or malicious activity. If your (the customer) can articulate your use-cases clearly, then most vendors can find a way to solve the defined problem using existing functionality within their product set. It is my hope that you will be able to use this blog post as a way to map the various solution offerings to a common and understandable taxonomy so you can fully comprehend what you are getting with each solution.
In the next post in this "Back to School" series (SIEM Correlation 201) we’ll talk about Use Case Definitions, Event Sources, Performance Impact, Flexibility and Scalability.
"ring, ring" class dismissed until next week.
-Rocky
Monday, July 27, 2009
Collection: Complete network awareness is finally an emerging market.
Recent vendor press releases by NitroSecurity and NetWitness highlight the evolving requirement for full network packet collection, indexing and reconstruction for analysis. These products and others (including Solera Networks) illustrate an emerging market in total network awareness. Working in conjunction with Log Management (LogLogic, Splunk, ArcSight Logger, etc) and SIEM tools (RSA, EiQNetworks and of course ArcSight ESM) these tools provide invaluable insight into your network's behavior (not to mention the behavior of individual users and applications over the network). NitroSecurity updated their capabilities to include what they term as "content aware SIEM" and NetWitness announced a milestone of 15,000 active users. Both press releases highlighted quotes from Decurity, which we appreciate, but more important to us, the emergence and rapid growth of this market segment add further credibility to Security Professionals having all of the right tools and information available. Recent news about DHS Einstein and NSA Tutelage technologies also point towards an increased trend in better, more capable Collection tools.
Security Operations and Incident Response capabilities can't continue to function in the dark and be expected to adequately protect the enterprise. We need to make all of the applicable information available and apply intelligent analytical techniques against the data set so that we can more rapidly and accurately identify risks to the enterprise. These tools when used properly can reduce analytical time required to identify incidents into time segments measured in seconds and can help understand the scope of the incident much more rapidly. You can review the artifacts (documents, files, audio, video, web, email, chat, as well as interactive sessions (ftp, telnet, ssh, etc)) instantly and determine the legitimacy of the session. You can extract information and search log management/SIEM for related events and set up alerts and workflow along the way. All in a matter of clicks. Of course you can accomplish the reverse and search for anomalies identified in SIEM/Log Management or IDS/IPS in your Network Awareness tool and understand quickly what occurred. With this level of information available to you, the limitations of the they of analysis have more to do with the level of expertise of the user/analyst than the information.
These use of these tools in the right hands allow for much more than just security "alerts" and incident identification. They lend themselves to true security convergence concepts and overall enterprise intelligence and security operations. More on those concepts over the next few months.
References:
NetWitness "July 27, 2009 | Security Experts Worldwide Rely Upon NetWitness® Investigator " Link: http://www.netwitness.com/resources/pressreleases/Jul272009.aspx
NitroSecurity "NitroSecurity Heightens Enterprise Security Information Management with Real-Time Application Content and Protocol Analysis" Link: http://www.nitrosecurity.com/information/news/pr/2009/20090722.psp
Decurity Blog: Dec 2008: http://blog.decurity.com/index.php/dec_template/more/netwitness_investigator_summary_1/
Security Operations and Incident Response capabilities can't continue to function in the dark and be expected to adequately protect the enterprise. We need to make all of the applicable information available and apply intelligent analytical techniques against the data set so that we can more rapidly and accurately identify risks to the enterprise. These tools when used properly can reduce analytical time required to identify incidents into time segments measured in seconds and can help understand the scope of the incident much more rapidly. You can review the artifacts (documents, files, audio, video, web, email, chat, as well as interactive sessions (ftp, telnet, ssh, etc)) instantly and determine the legitimacy of the session. You can extract information and search log management/SIEM for related events and set up alerts and workflow along the way. All in a matter of clicks. Of course you can accomplish the reverse and search for anomalies identified in SIEM/Log Management or IDS/IPS in your Network Awareness tool and understand quickly what occurred. With this level of information available to you, the limitations of the they of analysis have more to do with the level of expertise of the user/analyst than the information.
These use of these tools in the right hands allow for much more than just security "alerts" and incident identification. They lend themselves to true security convergence concepts and overall enterprise intelligence and security operations. More on those concepts over the next few months.
References:
NetWitness "July 27, 2009 | Security Experts Worldwide Rely Upon NetWitness® Investigator " Link: http://www.netwitness.com/resources/pressreleases/Jul272009.aspx
NitroSecurity "NitroSecurity Heightens Enterprise Security Information Management with Real-Time Application Content and Protocol Analysis" Link: http://www.nitrosecurity.com/information/news/pr/2009/20090722.psp
Decurity Blog: Dec 2008: http://blog.decurity.com/index.php/dec_template/more/netwitness_investigator_summary_1/
Thursday, July 2, 2009
NSA, USCERT, EINSTEIN, TIC, Telecom Providers and the Future of Government Information Security
Today Ellen Nakashima of The Washington Post published an article about DHS USCERT, NSA and Telecommunications providers collaborating to monitor Civilian Agency Internet traffic using DHS's planned Einstein 3 tool to help defend these civilian government entities. The article correctly illustrates that NSA has the expertise and tools like Tutelage to know more about the context of the attacks. It also states that DHS has the authorization to monitor using Einstein (enforced by the TIC program). If you'll remember a while back I talked about Trusted Internet Connection (TIC) and its role in consolidating Internet points of presence and providing chokepoints to monitor and defend for the government.
For reference see: http://blog.decurity.com/index.php/dec_template/more/dhs_einstein_tic_overview/ and http://blog.decurity.com/index.php/dec_template/more/dhs_blog_round_table/
In short, TIC mandated government agencies to meet very stringent requirements in order to become a TICAP (provider) or use pre-approved TICAP's (Telecom or other Agency) for all Internet traffic. The monitoring capabilities of these TIC's is referenced in my earlier posts, but let's just say its EVERYTHING. Not that I'm complaining, from a capabilities perspective I think NSA and Cyber Command should be making the most out of this information to help protect the government and as Richard Bejtlich speculates eventually ".com" . NSA has the expertise and intelligence data while DHS has the authorization to monitor, the framework to force everyone to play (TIC) and a toolset that is evolving (Einstein v2 is still being rolled out, v3 is in development) On a side note, I do have to wonder why the government isn't using more capable tools like NetWitness or Solera in conjunction with NSA tools and building a META SIEM to incorporate Intelligence feeds, but that's a topic for a later post.
My biggest question is this.... I wonder how US-CERT and NSA are going to collaborate more effectively - Is Einstein raw data going to be handled by NSA, if so what's the point of US-CERT in the future?
Should be interesting to see what happens once the cyber czar is appointed, from what I can tell his/her kingdom has already layed a very clear path forward, the czar may simply be along for the ride while NSA drives over everyone else.
Update 1: (3 July 2009; 0930 EDT) SIOBHAN GORMAN of The Wall Street Journal also has an article on this topic "Troubles Plague Cyberspy Defense" . In this article takes more conservative approach in describing what is happening across government with regards to consolidated monitoring. According to the article Einstein v3 will be updated/rebuilt to more closely align with NSA Tutelage and is at least 18 months out. The idea is that it would start to develop full packet inspection capabilities (Like NetWitness, Solera and a few others).
My Notes: If this perspective is more accurate it seems US-CERT would monitor using technology enabled by NSA, instead of NSA accomplishing the monitoring. IMHO - From what I've seen certain executive layers at DHS have not enabled the US-CERT to be effective enough to actually function as a true analytical center, even though USCERT has some very good people capable of executing on that misson. In fact, I'd go as far as to say DHS is at risk of losing key staff if they don't figure out a better way to enable their team. The place is known as a revolving door for a reason, the people they hire are very capable and motivated, the organization itself may not be best suited for that expertise and vision.
For reference see: http://blog.decurity.com/index.php/dec_template/more/dhs_einstein_tic_overview/ and http://blog.decurity.com/index.php/dec_template/more/dhs_blog_round_table/
In short, TIC mandated government agencies to meet very stringent requirements in order to become a TICAP (provider) or use pre-approved TICAP's (Telecom or other Agency) for all Internet traffic. The monitoring capabilities of these TIC's is referenced in my earlier posts, but let's just say its EVERYTHING. Not that I'm complaining, from a capabilities perspective I think NSA and Cyber Command should be making the most out of this information to help protect the government and as Richard Bejtlich speculates eventually ".com" . NSA has the expertise and intelligence data while DHS has the authorization to monitor, the framework to force everyone to play (TIC) and a toolset that is evolving (Einstein v2 is still being rolled out, v3 is in development) On a side note, I do have to wonder why the government isn't using more capable tools like NetWitness or Solera in conjunction with NSA tools and building a META SIEM to incorporate Intelligence feeds, but that's a topic for a later post.
My biggest question is this.... I wonder how US-CERT and NSA are going to collaborate more effectively - Is Einstein raw data going to be handled by NSA, if so what's the point of US-CERT in the future?
Should be interesting to see what happens once the cyber czar is appointed, from what I can tell his/her kingdom has already layed a very clear path forward, the czar may simply be along for the ride while NSA drives over everyone else.
Update 1: (3 July 2009; 0930 EDT) SIOBHAN GORMAN of The Wall Street Journal also has an article on this topic "Troubles Plague Cyberspy Defense" . In this article takes more conservative approach in describing what is happening across government with regards to consolidated monitoring. According to the article Einstein v3 will be updated/rebuilt to more closely align with NSA Tutelage and is at least 18 months out. The idea is that it would start to develop full packet inspection capabilities (Like NetWitness, Solera and a few others).
My Notes: If this perspective is more accurate it seems US-CERT would monitor using technology enabled by NSA, instead of NSA accomplishing the monitoring. IMHO - From what I've seen certain executive layers at DHS have not enabled the US-CERT to be effective enough to actually function as a true analytical center, even though USCERT has some very good people capable of executing on that misson. In fact, I'd go as far as to say DHS is at risk of losing key staff if they don't figure out a better way to enable their team. The place is known as a revolving door for a reason, the people they hire are very capable and motivated, the organization itself may not be best suited for that expertise and vision.
Sunday, June 7, 2009
Incident Response: A walk in the park
So if you follow me on Facebook or Twitter you may have heard our family had a bit of excitement over the weekend. My wife and two youngest children (2 and 7) got stuck at the top of a ride at Busch Gardens due to a "technical malfunction". I know that mechanical and/or technical failures happen all the time at theme parks, but when it's your family up there and you're on the ground, it sucks.
Busch Gardens did everything right, they quickly informed everyone on the ride of the malfunction, asked them to stay calm and at the same time sent emergency responders up to the top of the ride to help get everyone off safely. No running around crazy, no unnecessary escalations, no waiting on approvals, no idle hands... Everyone played their role. It got me thinking about the obvious parallels in incident response (well parts of it at least)
The ride was designed with safety mechanisms including emergency exit and communication mechanisms. The "owners" had procedures that were extremely well tested, communicated and executed by the "administrators". Everyone had their role, understood it and was authorized to just "do it" and it worked out. Once completed, they accomplished the repair, tested the ride, re-tested it from another perspective and then once approved by management they put the ride back into production for the park visitors ("users"). Sure the visitors had to wait a few minutes, but everyone was understanding once they had the right information made available to them. Certainly, I'd prefer this sort of thing to never happen, but that's unrealistic given all variables in place at a Theme park in Florida with millions of visitors. I'm just happy everyone was safe and we were able to enjoy the rest of the day. and then just when you think it's over...
Not more than 20 minutes later we saw another ride fail. The sky-ride (gondola) got stuck mid-ride for over 10 Minutes. Luckily, we were not on that ride. I'd have gotten a bit suspicious at that point :).
Actually, at that time we were on a train ride enjoying a peaceful ride through the park, pointing out animals to my two year old, when a grumpy Rhino tried to prove to the train that he was in control and decided to give it a little shove to encourage the train to keep moving along. I'm not sure if it was a full moon, an everyday occurrence for the park or Murphy's Law that caused all the excitement.
It just goes to show you that you can't predict what's going to go wrong, just that something will go wrong - it always does. We must prepare for as many types of Incidents as we can and enable our teams to react effectively, and expect that they will. Obviously, a lot of pre-planning, risk assessment, exercise activities, documentation and training goes into the equation. Everyone has to become involved, if a barely over minimum wage them park worker can be trained to play a role during an emergency, certainly we can figure out how to more effectively involve our "owners", "administrators", and management in our incident response activities.
Ok, enough excitement for one evening I'm off to bed, I can't wait for next week's cruise and the lessons that will bring..
Busch Gardens did everything right, they quickly informed everyone on the ride of the malfunction, asked them to stay calm and at the same time sent emergency responders up to the top of the ride to help get everyone off safely. No running around crazy, no unnecessary escalations, no waiting on approvals, no idle hands... Everyone played their role. It got me thinking about the obvious parallels in incident response (well parts of it at least)
The ride was designed with safety mechanisms including emergency exit and communication mechanisms. The "owners" had procedures that were extremely well tested, communicated and executed by the "administrators". Everyone had their role, understood it and was authorized to just "do it" and it worked out. Once completed, they accomplished the repair, tested the ride, re-tested it from another perspective and then once approved by management they put the ride back into production for the park visitors ("users"). Sure the visitors had to wait a few minutes, but everyone was understanding once they had the right information made available to them. Certainly, I'd prefer this sort of thing to never happen, but that's unrealistic given all variables in place at a Theme park in Florida with millions of visitors. I'm just happy everyone was safe and we were able to enjoy the rest of the day. and then just when you think it's over...
Not more than 20 minutes later we saw another ride fail. The sky-ride (gondola) got stuck mid-ride for over 10 Minutes. Luckily, we were not on that ride. I'd have gotten a bit suspicious at that point :).
Actually, at that time we were on a train ride enjoying a peaceful ride through the park, pointing out animals to my two year old, when a grumpy Rhino tried to prove to the train that he was in control and decided to give it a little shove to encourage the train to keep moving along. I'm not sure if it was a full moon, an everyday occurrence for the park or Murphy's Law that caused all the excitement.
It just goes to show you that you can't predict what's going to go wrong, just that something will go wrong - it always does. We must prepare for as many types of Incidents as we can and enable our teams to react effectively, and expect that they will. Obviously, a lot of pre-planning, risk assessment, exercise activities, documentation and training goes into the equation. Everyone has to become involved, if a barely over minimum wage them park worker can be trained to play a role during an emergency, certainly we can figure out how to more effectively involve our "owners", "administrators", and management in our incident response activities.
Ok, enough excitement for one evening I'm off to bed, I can't wait for next week's cruise and the lessons that will bring..
Wednesday, May 13, 2009
Sara Peters at Information Week recently posted an article titled “SIEM Case Study: Israeli e-government ISP” In this article, Assaf Keren, information security manager at the Israeli e-government ISP Project (called “Tehila”) calls our attention to some very important details to consider when Implementing a SIEM. Keren’s advice is that a successful SIEM implementation requires:
1. Detailed planning,
2. Fastidious attention to detail,
3. Superb communication between concerned parties
4. Attentive oversight of vendor activity.
Another Key Point from Mr. Keren - don’t outsource this “theory phase.”
Note: I agree with Mr. Keren that the SIEM requirements have to be driven from within your organization. However, I believe that expert external entities can and should help drive discussions and help extract and refine requirements from your team. Obviously, the expert external entity MUST NOT be from a Vendor or reseller of any SIEM Products.
Looking back over hundreds of SIEM deployments and seeing so many consistent decisions (or indecisions) that adversely affected the success of the SIEM I felt compelled to add a bit more context to augment the lessons Mr. Keren shared.
Overview:
1. It takes a village, building planners, city inspectors, etc: Probably, the most important takeaway from this post is that you should take the necessary time to fully comprehend and vet your requirements, as well as decide on your service delivery model, gain consensus on that approach and have realistic expectations along the way. SIEM failures are more often the fault of poor planning, moving tactically while ignoring the strategic nature of the project, or simply misaligned expectations rather than a pure technology failure.
2. Know what you are going to do with the Output before you make it Input: It is tough to make sense (and therefore derive any value) out of billons of events by adding even more events to be evaluated into the mix. Intelligent Collection, Analysis, Escalation and Remediation and workflow efforts defined before you start (and refined along the way) means that you’ll have a better idea what to do with the information your presented and a much higher chance for success in both end-user usage of the system and aligning that usage of the SIEM with the needs of your organization’s security or compliance program.
3. Purchase the “right” technology, but do it incrementally: Quite candidly some SIEM products should be avoided at all costs, however it should be noted that most of them can at least be used to help you meet some very basic requirements. Consider your business and technical requirements over a 24-month period, but only purchase what is necessary to deliver based on the next 6 months of work you expect to get accomplished. The system needs to be flexible to support all of those upcoming needs, but there is no need to spend money today to support tasks you won’t even consider touching for over 12 months.
A successful SIEM tool supporting your organization’s Security and/or Compliance needs really boils down to some very simple concepts:
Define Success
Have a strategic vision about how you want your Security Operation and/or Compliance Program to run and use that to help define requirements for how the SIEM (and Log Management) tools will provide input or drive workflow related to that Program. Involve all the stakeholders early and keep them engaged along the way!
• If your rationale for buying a SIEM is PCI Compliance, STOP.
• If your rationale for investing in SIEM is to provide “x”,”y” and “z” data sets to business unit “a” and “b” and initiating workflow for your SOC; and you understand the event sources necessary/business logic to compile the data sets for each customer; and you fully understand how they intend to use that information the you are much closer to being ready to work with a SIEM.
Related Resources:
• SIEM: Basic Implementation Success Criteria
• SIEM: Before you Buy
Plan Accordingly
SIEM is not an overnight project, and yes even an Appliance-based SIEM’s require significant attention to work to their maximum potential for your organization.
• Gather requirements from all “stakeholders” Compliance, Legal, IT, Business Units, Security, Executive, everyone that will help you get information into the SIEM or receive information from the SIEM (or your service offering that leverages SIEM).
• Define Event Sources based on end-user needs: Security, IT Operations and Compliance teams all have distinct needs and therefore may require different event source information. At a minimum they may require different “views” of similar information set available in the SIEM or Log Management Tool. Ensure you have the proper information sets, logging at the right levels and the information is available in a logical and meaningful manner.
• End-User Requirements are the most valuable. The more your team understands how your “customers” value the data and service offering the more you can benefit from the functionality of the SIEM.
• Analytical and Workflow Requirements. Security Analysts need to be able to quickly identify, analyze, prioritize and escalate the data with context in order for the SIEM to meet its most basic functions. This functionality is not as common as you would think across different SIEM’s. Be sure that the SIEM integrates with your workflow systems in an acceptable fashion.
Related Resources:
• SIEM: Best Practices in Collection
Vendor Selection
Now that you have your requirements documented and prioritized compare them against SIEM: Evaluation Criteria and refine them even further…
• Either partner with an expert that can tell you exactly why certain Vendors can not meet your needs (today/tomorrow) and compare those answers a n honest discussion with the vendor or invest in a Pilot in an effort to prove out ALL of your requirements (not just the top three.)
• Make sure you have data either directly from production event sources or a reasonably similar source. If you use combined Log Management and SIEM architecture, make sure you can configure outbound events in a format the SIEM can comprehend for more than just Syslog events. If the SIEM can natively handle ODBC but your architecture requires Log Management to be the Collection Tier and forward events to the SIEM – How does the LM reformat those events and how does the SIEM handle that data?
• Customer Referrals are nice, but be careful. I’ve seen this scenario too many times. Victim asks a SIEM Reference Client about a key area of concern, say scalability and the reference client dutifully answers the questions with a resounding “Yes, the $VENDOR scales to meet my global organization’s amazing needs” in all the excitement it was overlooked that it takes 100+ systems to get there and oh yeah, by the way none of these SIEM systems can cross correlate information. As your requirements are defined, build out testing plans if the requirement is that critical and test it prior to purchasing.
• Maximize your dollar. Ensure the vendor is prepared to partner with you for the long haul, you both have a vested interest in the success of the program – make sure they are going to be there for you
• Find out the vendor’s fiscal period and plan your purchase accordingly. Fiscal Quarter end and Fiscal Year end are great times to make deals (especially enterprise deals) with vendors.
• Purchase what you need not what you want. If you don’t have a documented requirement that you can reasonably achieve in the next 6 months don’t buy it yet. Conversely, don’t skimp on things you absolutely do need. If you have a requirement to store 8 Billon events a day over a 10-year period and you expect to do that with local storage or even DAS, NAS. Stop and rethink things a bit.
Focused Effort:
Ensure that you have dedicated enough time and energy to the success of your SIEM Effort. If you are a large enterprise this is at least 2 FTE’s or an Expert Partner
Seriously, Requirements Gathering, Vendor Selection, Pilot, Implementation, Initial Operating Capability, Operational Refinements, Final Operating Capability (Formal Service Delivery), On-going Enhancements, Patches, Upgrades, Lab Testing, Additional Content Tuning, Expansion and the related Coordination, Planning, Execution, Oversight and Measurements is enough to keep an entire team busy. Doing all of that within the framework of your overall Strategic Security Program and not just tactically solving issues as the “pop-up” on a daily basis is the key to success with SIEM and ultimately your entire security and/or compliance program.
Having the wrong team or not listening to the right team is about the same as not having resources at all. Spend the time to ensure your SIEM team is baked into your Security/Compliance Program(s) so they can help you plan for today and tomorrow and save a lot of headaches in new hardware, storage or even total SIEM replacement. If your not ready to dedicate the right Resources/Partner’s then you may be better off waiting and then introducing SIEM into your organization when the requirements, proposed solution and funding are more in line.
Lifecycle Planning
This goes way beyond simple O&M tasks. SIEM is part of your overall Security Program and as such need to stay in step with that Program. Your SIEM Team (Partner) needs to be involved along the way to help ensure compatibility and/or flexibility as you evolve. Service Delivery, Technology, Business and Compliance requirement changes and/or reprioritizations can all have a significant impact on the success or failure of the overall program. The tighter the team is with the thought process around those upcoming changes the more likely your SIEM Program will meet your needs.
1. Detailed planning,
2. Fastidious attention to detail,
3. Superb communication between concerned parties
4. Attentive oversight of vendor activity.
Another Key Point from Mr. Keren - don’t outsource this “theory phase.”
Note: I agree with Mr. Keren that the SIEM requirements have to be driven from within your organization. However, I believe that expert external entities can and should help drive discussions and help extract and refine requirements from your team. Obviously, the expert external entity MUST NOT be from a Vendor or reseller of any SIEM Products.
Looking back over hundreds of SIEM deployments and seeing so many consistent decisions (or indecisions) that adversely affected the success of the SIEM I felt compelled to add a bit more context to augment the lessons Mr. Keren shared.
Overview:
1. It takes a village, building planners, city inspectors, etc: Probably, the most important takeaway from this post is that you should take the necessary time to fully comprehend and vet your requirements, as well as decide on your service delivery model, gain consensus on that approach and have realistic expectations along the way. SIEM failures are more often the fault of poor planning, moving tactically while ignoring the strategic nature of the project, or simply misaligned expectations rather than a pure technology failure.
2. Know what you are going to do with the Output before you make it Input: It is tough to make sense (and therefore derive any value) out of billons of events by adding even more events to be evaluated into the mix. Intelligent Collection, Analysis, Escalation and Remediation and workflow efforts defined before you start (and refined along the way) means that you’ll have a better idea what to do with the information your presented and a much higher chance for success in both end-user usage of the system and aligning that usage of the SIEM with the needs of your organization’s security or compliance program.
3. Purchase the “right” technology, but do it incrementally: Quite candidly some SIEM products should be avoided at all costs, however it should be noted that most of them can at least be used to help you meet some very basic requirements. Consider your business and technical requirements over a 24-month period, but only purchase what is necessary to deliver based on the next 6 months of work you expect to get accomplished. The system needs to be flexible to support all of those upcoming needs, but there is no need to spend money today to support tasks you won’t even consider touching for over 12 months.
A successful SIEM tool supporting your organization’s Security and/or Compliance needs really boils down to some very simple concepts:
Define Success
Have a strategic vision about how you want your Security Operation and/or Compliance Program to run and use that to help define requirements for how the SIEM (and Log Management) tools will provide input or drive workflow related to that Program. Involve all the stakeholders early and keep them engaged along the way!
• If your rationale for buying a SIEM is PCI Compliance, STOP.
• If your rationale for investing in SIEM is to provide “x”,”y” and “z” data sets to business unit “a” and “b” and initiating workflow for your SOC; and you understand the event sources necessary/business logic to compile the data sets for each customer; and you fully understand how they intend to use that information the you are much closer to being ready to work with a SIEM.
Related Resources:
• SIEM: Basic Implementation Success Criteria
• SIEM: Before you Buy
Plan Accordingly
SIEM is not an overnight project, and yes even an Appliance-based SIEM’s require significant attention to work to their maximum potential for your organization.
• Gather requirements from all “stakeholders” Compliance, Legal, IT, Business Units, Security, Executive, everyone that will help you get information into the SIEM or receive information from the SIEM (or your service offering that leverages SIEM).
• Define Event Sources based on end-user needs: Security, IT Operations and Compliance teams all have distinct needs and therefore may require different event source information. At a minimum they may require different “views” of similar information set available in the SIEM or Log Management Tool. Ensure you have the proper information sets, logging at the right levels and the information is available in a logical and meaningful manner.
• End-User Requirements are the most valuable. The more your team understands how your “customers” value the data and service offering the more you can benefit from the functionality of the SIEM.
• Analytical and Workflow Requirements. Security Analysts need to be able to quickly identify, analyze, prioritize and escalate the data with context in order for the SIEM to meet its most basic functions. This functionality is not as common as you would think across different SIEM’s. Be sure that the SIEM integrates with your workflow systems in an acceptable fashion.
Related Resources:
• SIEM: Best Practices in Collection
Vendor Selection
Now that you have your requirements documented and prioritized compare them against SIEM: Evaluation Criteria and refine them even further…
• Either partner with an expert that can tell you exactly why certain Vendors can not meet your needs (today/tomorrow) and compare those answers a n honest discussion with the vendor or invest in a Pilot in an effort to prove out ALL of your requirements (not just the top three.)
• Make sure you have data either directly from production event sources or a reasonably similar source. If you use combined Log Management and SIEM architecture, make sure you can configure outbound events in a format the SIEM can comprehend for more than just Syslog events. If the SIEM can natively handle ODBC but your architecture requires Log Management to be the Collection Tier and forward events to the SIEM – How does the LM reformat those events and how does the SIEM handle that data?
• Customer Referrals are nice, but be careful. I’ve seen this scenario too many times. Victim asks a SIEM Reference Client about a key area of concern, say scalability and the reference client dutifully answers the questions with a resounding “Yes, the $VENDOR scales to meet my global organization’s amazing needs” in all the excitement it was overlooked that it takes 100+ systems to get there and oh yeah, by the way none of these SIEM systems can cross correlate information. As your requirements are defined, build out testing plans if the requirement is that critical and test it prior to purchasing.
• Maximize your dollar. Ensure the vendor is prepared to partner with you for the long haul, you both have a vested interest in the success of the program – make sure they are going to be there for you
• Find out the vendor’s fiscal period and plan your purchase accordingly. Fiscal Quarter end and Fiscal Year end are great times to make deals (especially enterprise deals) with vendors.
• Purchase what you need not what you want. If you don’t have a documented requirement that you can reasonably achieve in the next 6 months don’t buy it yet. Conversely, don’t skimp on things you absolutely do need. If you have a requirement to store 8 Billon events a day over a 10-year period and you expect to do that with local storage or even DAS, NAS. Stop and rethink things a bit.
Focused Effort:
Ensure that you have dedicated enough time and energy to the success of your SIEM Effort. If you are a large enterprise this is at least 2 FTE’s or an Expert Partner
Seriously, Requirements Gathering, Vendor Selection, Pilot, Implementation, Initial Operating Capability, Operational Refinements, Final Operating Capability (Formal Service Delivery), On-going Enhancements, Patches, Upgrades, Lab Testing, Additional Content Tuning, Expansion and the related Coordination, Planning, Execution, Oversight and Measurements is enough to keep an entire team busy. Doing all of that within the framework of your overall Strategic Security Program and not just tactically solving issues as the “pop-up” on a daily basis is the key to success with SIEM and ultimately your entire security and/or compliance program.
Having the wrong team or not listening to the right team is about the same as not having resources at all. Spend the time to ensure your SIEM team is baked into your Security/Compliance Program(s) so they can help you plan for today and tomorrow and save a lot of headaches in new hardware, storage or even total SIEM replacement. If your not ready to dedicate the right Resources/Partner’s then you may be better off waiting and then introducing SIEM into your organization when the requirements, proposed solution and funding are more in line.
Lifecycle Planning
This goes way beyond simple O&M tasks. SIEM is part of your overall Security Program and as such need to stay in step with that Program. Your SIEM Team (Partner) needs to be involved along the way to help ensure compatibility and/or flexibility as you evolve. Service Delivery, Technology, Business and Compliance requirement changes and/or reprioritizations can all have a significant impact on the success or failure of the overall program. The tighter the team is with the thought process around those upcoming changes the more likely your SIEM Program will meet your needs.
Thursday, April 16, 2009
Latest Verizon Business Data Breach Report
I just wanted to let everyone know that Verizon Business has published the 2009 Data Breach Report. The breadth and depth of these reports are invaluable. Since there are very few solid sources of this type of information the release of this report dominates the availability of the few brain cells I have remaining.
Press Release Here: http://www.verizonbusiness.com/products/security/risk/databreach/
Actual Report Here: http://www.verizonbusiness.com/resources/security/reports/2009_databreach_rp.pdf
Look for updates/comments from the authors/team at http://securityblog.verizonbusiness.com
From my first 5 minute glance at the report here are some of my favorite things:
Figure 31. Time Span of breach event by percent of breaches. This may be the best metric we as security professionals can look to improve. Seeking to reduce the time to Incident Identification and Mitigation
Figure 32. Breach Discovery methods by percent of breaches. Interesting observations about how things are detected, nearly 70% by third parties, only 7% by “active” internal teams.
Figure 34. Detective Controls by percent of breach victims. System and Application Logs are KEY (don’t just rely on security devices).
Many of the recommendations seem brain dead simple so I won’t cover them here, nor will I go into the pseudo risk calculations or PCI “Compliance” at this time. All in all a ton of food for thought in this report. I’m going to wait to post more comprehensive notes on this report to allow it all to sink in a bit more. Verizon obviously puts a lot of thought and effort into this report and I find myself spending hours dissecting it every time. To my friends over at Verizon Business - Thanks again for the information! Everyone else - I encourage you to take the time to review it thoroughly.
Originally published on blog.decurity.com on 14 April 2009.
Press Release Here: http://www.verizonbusiness.com/products/security/risk/databreach/
Actual Report Here: http://www.verizonbusiness.com/resources/security/reports/2009_databreach_rp.pdf
Look for updates/comments from the authors/team at http://securityblog.verizonbusiness.com
From my first 5 minute glance at the report here are some of my favorite things:
Figure 31. Time Span of breach event by percent of breaches. This may be the best metric we as security professionals can look to improve. Seeking to reduce the time to Incident Identification and Mitigation
Figure 32. Breach Discovery methods by percent of breaches. Interesting observations about how things are detected, nearly 70% by third parties, only 7% by “active” internal teams.
Figure 34. Detective Controls by percent of breach victims. System and Application Logs are KEY (don’t just rely on security devices).
Many of the recommendations seem brain dead simple so I won’t cover them here, nor will I go into the pseudo risk calculations or PCI “Compliance” at this time. All in all a ton of food for thought in this report. I’m going to wait to post more comprehensive notes on this report to allow it all to sink in a bit more. Verizon obviously puts a lot of thought and effort into this report and I find myself spending hours dissecting it every time. To my friends over at Verizon Business - Thanks again for the information! Everyone else - I encourage you to take the time to review it thoroughly.
Originally published on blog.decurity.com on 14 April 2009.
Hackers for Charity
Hackers for Charity is Johnny Long’s new website and mission in life. Saying that I applaud him on this effort is the biggest understatement I can make. On a personal level I am very moved by his passion and commitment to server others, here and everywhere. Johnny has taken his talents and applied them in ways that help so many people across the world. Just thinking about what he is accomplishing motivates me to seek better out of myself. Please do pop over to his site and find a way to help Johnny and his family on their upcoming year-long efforts in Uganda. Equipment, Advise, Money - anything you can provide will help Johnny, his family and so many others in Uganda and across the world!
Rocky
Rocky
Friday, March 20, 2009
More SIEM Vendor Leap Frog
Network World's recent article provides additional evidence that Log Management and SIEM Vendors are still trying to evolve.
Dominique Levin (EVP of Strategy/Marketing at Log Logic writes in this Network World article posted last night (03/19/2009) about the development and convergence of SIEM and Log Management. I'm glad that Log Logic finally understands the model and is trying to address a broader market opportunity by incorporating SIEM into their offering. If you didn't already know, last month Log Logic partnered with ExaProtect to be able to provide a more native (to Log Logic) SIEM solution. As a side note, it has been my experience that you can make other SIEM's work in conjunction with Log Logic (at least in an unidirectional manner) by forwarding events to a SIEM from the Log Management platform. I hope that Log Logic (and other vendors) continue to read my SIEM Vendor Leap Frog post and take some of the challenges in current technologies to heart. Bi-directional search between Log Management and SIEM, shared user authorization and authentication techniques, more robust shared management options - all of which really need to evolve from these types of offerings. I hope they and the other vendors look at this as an opportunity to truly merge the products into a solution versus the current "bolt-on" approach some in the market have taken. It is not enough to just have the technology available, the vendors must understand how the customers will use this in the field and make it more simple to deploy, manage and ultimately actually use these products. ArcSight, RSA and other key players are working on this very diligently and have made great strides to making this vision a reality. It's still nowhere near perfect but I think it will get much more emphasis over the next 12-18 months or so as more people demand better integrated solutions during their acquisition or renewal cycles.
Another side note: At the recent IANS DC forum and again at SOURCE Boston Peter Kuper noted that security vendors are going to have to make more of an effort to partner with their customers to really thrive in this market. Peter also made the point that customers have to demand more value from their vendors in order to show value to their own management. I think everyone should take that message to heart!
The information presented in the Network World article further validates some of the positions I presented in my SIEM Vendor Leap Frog post earlier this week. For that matter so does a recent "tweet" from NitroSecurity (Twitter: @nitrosecurity) as well as, a "tweet" from RSA's SIEM Solutions Evangelist Paul Stamp (Twitter: @tknsecurityguy) and a recent post Paul Stamp in his personal blog.
The idea of combining Log Management and SIEM isn't novel (in fact it is several years old) but only recently has it become the "standard" for gaining "Enterprise Visibility" and then moving towards making security operations work more fluidly through the use of a SIEM. The combining of Log Management and SIEM is not trivial to accomplish but can be done quite well and adds huge value, if architected correctly.
The article explains the evolution of SIEM through the years, beginning with Perimeter Security "Use-Cases", moving through certain "Internal Monitoring" Use-cases and then describes how SIEM gained critical mass through "Compliance" Use-Cases. I will not debate the relevance of SIEM in each of these situations other than to say - Both the Log Management and SIEM's product sets are nothing more than tools. They can be a powerful resource in the right hands and have a great many potential applications, but the team wielding that power has to know how to apply it and when (and when not to). While it is true that some SIEM platforms are flexible enough to move beyond simple network security based use-cases, the complexity involved in making those transitions requires expert touch. Let's get these systems working correctly in security first then we can think about expansion into other areas (business intelligence, etc). There is no magic fairy dust here. It is hard work at each and every step, but there is a payoff. You can automate many labor intensive tasks including identification and escalation of alerts, which should free up some analytical cycles to find new and more complex activities that they can turn into "events of interest" for future correlation. BTW I didn't mean to dismiss the value of Log Management and SIEM outside the context of Security - it is possible (it requires great flexibility in the vendor solution but I know many organizations that have made interesting solutions work in very unique ways) I'm simply saying there is a lot more work we can do to get the actual security focused portion of these solutions to work better before we try and show value (and over exert our reach/resources) in other areas.
Let's keep working together to encourage the right partnership and evolution from our vendors! They are doing the best they can, but it is up to the community at large to focus them in the right direction.
Dominique Levin (EVP of Strategy/Marketing at Log Logic writes in this Network World article posted last night (03/19/2009) about the development and convergence of SIEM and Log Management. I'm glad that Log Logic finally understands the model and is trying to address a broader market opportunity by incorporating SIEM into their offering. If you didn't already know, last month Log Logic partnered with ExaProtect to be able to provide a more native (to Log Logic) SIEM solution. As a side note, it has been my experience that you can make other SIEM's work in conjunction with Log Logic (at least in an unidirectional manner) by forwarding events to a SIEM from the Log Management platform. I hope that Log Logic (and other vendors) continue to read my SIEM Vendor Leap Frog post and take some of the challenges in current technologies to heart. Bi-directional search between Log Management and SIEM, shared user authorization and authentication techniques, more robust shared management options - all of which really need to evolve from these types of offerings. I hope they and the other vendors look at this as an opportunity to truly merge the products into a solution versus the current "bolt-on" approach some in the market have taken. It is not enough to just have the technology available, the vendors must understand how the customers will use this in the field and make it more simple to deploy, manage and ultimately actually use these products. ArcSight, RSA and other key players are working on this very diligently and have made great strides to making this vision a reality. It's still nowhere near perfect but I think it will get much more emphasis over the next 12-18 months or so as more people demand better integrated solutions during their acquisition or renewal cycles.
Another side note: At the recent IANS DC forum and again at SOURCE Boston Peter Kuper noted that security vendors are going to have to make more of an effort to partner with their customers to really thrive in this market. Peter also made the point that customers have to demand more value from their vendors in order to show value to their own management. I think everyone should take that message to heart!
The information presented in the Network World article further validates some of the positions I presented in my SIEM Vendor Leap Frog post earlier this week. For that matter so does a recent "tweet" from NitroSecurity (Twitter: @nitrosecurity) as well as, a "tweet" from RSA's SIEM Solutions Evangelist Paul Stamp (Twitter: @tknsecurityguy) and a recent post Paul Stamp in his personal blog.
The idea of combining Log Management and SIEM isn't novel (in fact it is several years old) but only recently has it become the "standard" for gaining "Enterprise Visibility" and then moving towards making security operations work more fluidly through the use of a SIEM. The combining of Log Management and SIEM is not trivial to accomplish but can be done quite well and adds huge value, if architected correctly.
The article explains the evolution of SIEM through the years, beginning with Perimeter Security "Use-Cases", moving through certain "Internal Monitoring" Use-cases and then describes how SIEM gained critical mass through "Compliance" Use-Cases. I will not debate the relevance of SIEM in each of these situations other than to say - Both the Log Management and SIEM's product sets are nothing more than tools. They can be a powerful resource in the right hands and have a great many potential applications, but the team wielding that power has to know how to apply it and when (and when not to). While it is true that some SIEM platforms are flexible enough to move beyond simple network security based use-cases, the complexity involved in making those transitions requires expert touch. Let's get these systems working correctly in security first then we can think about expansion into other areas (business intelligence, etc). There is no magic fairy dust here. It is hard work at each and every step, but there is a payoff. You can automate many labor intensive tasks including identification and escalation of alerts, which should free up some analytical cycles to find new and more complex activities that they can turn into "events of interest" for future correlation. BTW I didn't mean to dismiss the value of Log Management and SIEM outside the context of Security - it is possible (it requires great flexibility in the vendor solution but I know many organizations that have made interesting solutions work in very unique ways) I'm simply saying there is a lot more work we can do to get the actual security focused portion of these solutions to work better before we try and show value (and over exert our reach/resources) in other areas.
Let's keep working together to encourage the right partnership and evolution from our vendors! They are doing the best they can, but it is up to the community at large to focus them in the right direction.
Wednesday, March 18, 2009
SIEM Vendor Leapfrog
Recently, Log Management and SIEM vendors have spent a lot of time updating/fixing their products. Over the past few months some vendors have quietly passed over other solutions in terms of market relevance and certainly the door has been opened to a whole bunch of upstarts trying to make a name for themselves. While the majority of Log Management and SIEM business (and therefore product direction) is driven by compliance activities, I appreciate the forward movement towards enterprise security that many in the field are trying to make. The initial execution on that product vision I'm seeing from many of the vendors this year is very welcome. IMHO the entire space had gotten very stale with the big guys mainly focusing on compliance appliances or playing feature catch-up with one another. Here's my summary of what's going on in SIEM and Log Management so far in 2009.
My observations about recent SIEM and Log Management Vendor announcements and my thoughts about what is still needed to make it more effective for most customers.
1. Log Management appliance based solutions continue to rule the land. See ArcSight's last quarterly results announcement and extract from that the fact that something like 46% of product revenue was based on their appliances or talk with Intellitactics about their recent growth in SAFE Logging Appliance sales if you don't believe me. Splunk may be exception to that appliance rule as they continue to gain ground on everyone but the fact remains if you don't have a solid Log Management offering you're toast in 2009. Conversely, pure Log Management solutions have seen the importance of having a SIEM offering available to be able to effectively compete on larger accounts (see the link below about Log Logic partnership with ExaProtect as one example).
2. Some vendors are still playing feature catch-up adding things like Trouble Ticket Integration of Vulnerability Assessment Tool Integration. It is amazing to me that these are "new feature sets" in several products, but progress is progress and I'll take it. I'm still not thrilled with most vendors idea of integration being unidirectional SMTP based updates but it's a start. The idea of Vulnerability Management and then furthering that by full CMDB integration is awesome in theory but in many cases it is very hard to scale. This has made significant stride forward but in my mind much more is left to be accomplished.
3. Database Activity Monitoring seems to be catching on. Interesting given how difficult this really is to accomplish in an enterprise - Admin level monitoring is easy enough but field level and/or transaction level auditing like Oracle FGA is a non-trivial task to accomplish. Most vendors have approached this solution set through 3rd party product support (Imperva, Guardium, etc) but at least a couple have tackled this directly through development or acquisition.
4. Enterprise Visibility is a growing trend. I've previously stated my appreciation for having proper visibility across the enterprise. When NetWitness announced their free version of Investigator I posted my comments and review of the technology. Last year in my "Best Practices in Security Operations: Collection" post I expressed my thoughts on what it takes to really do Enterprise Security Operations correctly and that the foundation of the entire process is Collection. Part of that collection is filling in the gaps missed by other products and Full Packet Capture is an awfully powerful tool to have in your arsenal. Several vendors have announces partnerships with 3rd party providers and/or announced network capture/replay as an internal capability through development or acquisition (see NitroSecurity).
5. Hard stuff is still hard - Windows Event Logs, Custom Applications, CMDB Integration, Database Monitoring are all hard problems to tackle. No vendor has this perfect (how could we expect them to) but several have started to think about ways to make this easier, rather than just saying "start with critical systems" they are developing more reliable/scalable/flexible solutions. I'm interested to see how far the vendors get with the more complex logs and more meaningful IT operations integrations in 2009.
6. Relevant content is king. The default content (Correlation, Reports, etc) from most of the vendors is not going to work in your enterprise. Sure some of it works at least some of the time but seriously on average how could 1500+ reports ever apply to your environment. Content Tuning is the #1 area vendors can make these solutions more relevant and easier for customers. I believe this so much that Decurity has re-focused much of its energy to address this issue head on hey, it's my blog and I'll pimp if I want to.
7. Consolidation/Contraction. I do expect to see more industry consolidation. High Tower won't be the last failure and some of the big boys need to revamp their overall integrated solutions. The Log Management side may be commodity ready but SIEM is not (yet). I expect at least 2 more acquisitions/failures to occur in the space in the coming months and not necessarily because of bad technology. A great technology in the wrong hands or begin put against the wrong goals is no better than a crappy technology.
Additional Thoughts:
SIEM: The Fortune 100 seems to be saturated with products/solutions (a lot have failed and some are actually working) and they have plenty of war stories that hey are more than willing to share. The overall take-away is simple - you need to be ready to invest in success if you jump into SIEM, product flexibility, product expertise, documented internal requirements and perhaps most importantly internal processes/procedures for making it work.
Fortune 200-2000: I'm happy to see that many organizations are now starting to push-back on vendors (and their own management) after learning from the mistakes of others. I think they will take a more reasonable approach of making Log Management work first before moving to SIEM and when they get to SIEM I'm encouraged by the increasing trend of documenting actual use-cases and requirements.
Channel: Nearly all the of vendors are trying enabling better global channel programs and at least in Log Management these are very successful programs helping them gain foreign market share and SMB market in the US.
SIEM: Some idea's for improvement:
1. Most of the SIEM products require significant expertise to deploy, manage and maintain effectively. There is a good business there for the right partnerships and companies should leverage that expertise. Today the number of VAR's and Consulting organizations that really can be considered "expert" in this area can be counted on one hand. I still think the vendors are going to have to do better to make their SIEM products more user-friendly and that will require a true partnership with their customers.
2. If your SIEM can't correlate events (Raw or Meta events) between engines you should be pushing your Vendor towards making that work in 2009. Linear scalability is irrelevant you are going to need flexibility in the future. Even if your organization is not mature enough to use that functionality today, you will eventually get there, make sure your vendors are partnered with you to help you achieve your long-term goals.
LOG MANAGEMENT: Log Management will continue to grow across all market segments, no question. The overall channel effectiveness seems to be growing as the acceptance of appliance based solutions grows. Compliance is an easy driver for sales in Log MGMT but at some point the big customers will have to step up and require better and more scalable solutions from the vendors.
Log Management: Some idea's for improvement:
1.) Log Management solutions that attach to an in-house SAN is a great idea - but only if the SAN carve out is unlimited or at least sufficient enough that they aren't required to purchase additional appliances to scale to the enterprise.
2.) Better bi-directional support between Log Management and SIEM solutions is absolutely required. You have to be able to search one/both from a single location for these to gain better traction as combined offerings.
3.) Flexibility is going to be key moving forward. Splunk is gaining ground for a reason (and it is more than marketing). Integration of new event sources will continue to be a key issue.
4.) Content is also an issue on the Log Management end. Some vendors do a fantastic job and others need better partnerships or a renewed internal focus on relevant security content.
Recent Log Management and SIEM Product Update News and Links:
March 2009
Nitro Security Acquires Chronicle Solutions .
EMC RSA RSA releases enVision v4.0 And now Paul Stamp is over there helping them move the product further along!
NetForensics NetForensics releases NFX v4.1 .
Feb 2009
TenableTenable releases Database Auditing Capability
Q1Labs QRadar 6.2 was released. .
LogLogic partners with exaprotect
NetForensics HighTower was gobbled up by NetForensics. I'm reserving judgment for now.
Jan 2009
Nitro Security integrates Database Activity Monitoring (DAM) into SIEM.
eIQnetworks announces a new round of funding and management additions A lot of "buzz" around eIQ right now but I have yet to have the opportunity to see them in action in a global enterprise. I hear good things about their approach, but I'm always cautious.
Late 2008 News:
Symantec SIM v4.6 released" .
Trigeo seeks HighTower's customers Trigeo offered a competitive upgrade to former HighTower customers.
LogRhythm Version 4.1 Released
Sensage version 4.0 Released
Splunk v3.4.6 released I hear rumors of Splunk 4.0 coming this summer!
ArcSight Announces ESM 4.0 SP2 and ArcSight Logger 3.0 ArcSight Logger 3.0 was a VAST improvement over previous versions in terms of speed and capability.
Q1 Labs QRadar product was OEM'ed into Juniper STRM Products. An interesting play, very similar to what Protego did a few years ago (now Cisco MARS).
My observations about recent SIEM and Log Management Vendor announcements and my thoughts about what is still needed to make it more effective for most customers.
1. Log Management appliance based solutions continue to rule the land. See ArcSight's last quarterly results announcement and extract from that the fact that something like 46% of product revenue was based on their appliances or talk with Intellitactics about their recent growth in SAFE Logging Appliance sales if you don't believe me. Splunk may be exception to that appliance rule as they continue to gain ground on everyone but the fact remains if you don't have a solid Log Management offering you're toast in 2009. Conversely, pure Log Management solutions have seen the importance of having a SIEM offering available to be able to effectively compete on larger accounts (see the link below about Log Logic partnership with ExaProtect as one example).
2. Some vendors are still playing feature catch-up adding things like Trouble Ticket Integration of Vulnerability Assessment Tool Integration. It is amazing to me that these are "new feature sets" in several products, but progress is progress and I'll take it. I'm still not thrilled with most vendors idea of integration being unidirectional SMTP based updates but it's a start. The idea of Vulnerability Management and then furthering that by full CMDB integration is awesome in theory but in many cases it is very hard to scale. This has made significant stride forward but in my mind much more is left to be accomplished.
3. Database Activity Monitoring seems to be catching on. Interesting given how difficult this really is to accomplish in an enterprise - Admin level monitoring is easy enough but field level and/or transaction level auditing like Oracle FGA is a non-trivial task to accomplish. Most vendors have approached this solution set through 3rd party product support (Imperva, Guardium, etc) but at least a couple have tackled this directly through development or acquisition.
4. Enterprise Visibility is a growing trend. I've previously stated my appreciation for having proper visibility across the enterprise. When NetWitness announced their free version of Investigator I posted my comments and review of the technology. Last year in my "Best Practices in Security Operations: Collection" post I expressed my thoughts on what it takes to really do Enterprise Security Operations correctly and that the foundation of the entire process is Collection. Part of that collection is filling in the gaps missed by other products and Full Packet Capture is an awfully powerful tool to have in your arsenal. Several vendors have announces partnerships with 3rd party providers and/or announced network capture/replay as an internal capability through development or acquisition (see NitroSecurity).
5. Hard stuff is still hard - Windows Event Logs, Custom Applications, CMDB Integration, Database Monitoring are all hard problems to tackle. No vendor has this perfect (how could we expect them to) but several have started to think about ways to make this easier, rather than just saying "start with critical systems" they are developing more reliable/scalable/flexible solutions. I'm interested to see how far the vendors get with the more complex logs and more meaningful IT operations integrations in 2009.
6. Relevant content is king. The default content (Correlation, Reports, etc) from most of the vendors is not going to work in your enterprise. Sure some of it works at least some of the time but seriously on average how could 1500+ reports ever apply to your environment. Content Tuning is the #1 area vendors can make these solutions more relevant and easier for customers. I believe this so much that Decurity has re-focused much of its energy to address this issue head on hey, it's my blog and I'll pimp if I want to.
7. Consolidation/Contraction. I do expect to see more industry consolidation. High Tower won't be the last failure and some of the big boys need to revamp their overall integrated solutions. The Log Management side may be commodity ready but SIEM is not (yet). I expect at least 2 more acquisitions/failures to occur in the space in the coming months and not necessarily because of bad technology. A great technology in the wrong hands or begin put against the wrong goals is no better than a crappy technology.
Additional Thoughts:
SIEM: The Fortune 100 seems to be saturated with products/solutions (a lot have failed and some are actually working) and they have plenty of war stories that hey are more than willing to share. The overall take-away is simple - you need to be ready to invest in success if you jump into SIEM, product flexibility, product expertise, documented internal requirements and perhaps most importantly internal processes/procedures for making it work.
Fortune 200-2000: I'm happy to see that many organizations are now starting to push-back on vendors (and their own management) after learning from the mistakes of others. I think they will take a more reasonable approach of making Log Management work first before moving to SIEM and when they get to SIEM I'm encouraged by the increasing trend of documenting actual use-cases and requirements.
Channel: Nearly all the of vendors are trying enabling better global channel programs and at least in Log Management these are very successful programs helping them gain foreign market share and SMB market in the US.
SIEM: Some idea's for improvement:
1. Most of the SIEM products require significant expertise to deploy, manage and maintain effectively. There is a good business there for the right partnerships and companies should leverage that expertise. Today the number of VAR's and Consulting organizations that really can be considered "expert" in this area can be counted on one hand. I still think the vendors are going to have to do better to make their SIEM products more user-friendly and that will require a true partnership with their customers.
2. If your SIEM can't correlate events (Raw or Meta events) between engines you should be pushing your Vendor towards making that work in 2009. Linear scalability is irrelevant you are going to need flexibility in the future. Even if your organization is not mature enough to use that functionality today, you will eventually get there, make sure your vendors are partnered with you to help you achieve your long-term goals.
LOG MANAGEMENT: Log Management will continue to grow across all market segments, no question. The overall channel effectiveness seems to be growing as the acceptance of appliance based solutions grows. Compliance is an easy driver for sales in Log MGMT but at some point the big customers will have to step up and require better and more scalable solutions from the vendors.
Log Management: Some idea's for improvement:
1.) Log Management solutions that attach to an in-house SAN is a great idea - but only if the SAN carve out is unlimited or at least sufficient enough that they aren't required to purchase additional appliances to scale to the enterprise.
2.) Better bi-directional support between Log Management and SIEM solutions is absolutely required. You have to be able to search one/both from a single location for these to gain better traction as combined offerings.
3.) Flexibility is going to be key moving forward. Splunk is gaining ground for a reason (and it is more than marketing). Integration of new event sources will continue to be a key issue.
4.) Content is also an issue on the Log Management end. Some vendors do a fantastic job and others need better partnerships or a renewed internal focus on relevant security content.
Recent Log Management and SIEM Product Update News and Links:
March 2009
Nitro Security Acquires Chronicle Solutions .
EMC RSA RSA releases enVision v4.0 And now Paul Stamp is over there helping them move the product further along!
NetForensics NetForensics releases NFX v4.1 .
Feb 2009
TenableTenable releases Database Auditing Capability
Q1Labs QRadar 6.2 was released. .
LogLogic partners with exaprotect
NetForensics HighTower was gobbled up by NetForensics. I'm reserving judgment for now.
Jan 2009
Nitro Security integrates Database Activity Monitoring (DAM) into SIEM.
eIQnetworks announces a new round of funding and management additions A lot of "buzz" around eIQ right now but I have yet to have the opportunity to see them in action in a global enterprise. I hear good things about their approach, but I'm always cautious.
Late 2008 News:
Symantec SIM v4.6 released" .
Trigeo seeks HighTower's customers Trigeo offered a competitive upgrade to former HighTower customers.
LogRhythm Version 4.1 Released
Sensage version 4.0 Released
Splunk v3.4.6 released I hear rumors of Splunk 4.0 coming this summer!
ArcSight Announces ESM 4.0 SP2 and ArcSight Logger 3.0 ArcSight Logger 3.0 was a VAST improvement over previous versions in terms of speed and capability.
Q1 Labs QRadar product was OEM'ed into Juniper STRM Products. An interesting play, very similar to what Protego did a few years ago (now Cisco MARS).
Subscribe to:
Posts (Atom)
Posts
