Mike Rothman

Mike Rothman Joins Securosis

By Adrian Lane

Technology start-ups are unique organisms that affect employees very differently than other types of companies. Tech start-ups are about bringing new ideas to market. They are about change, and often founded on an alternative perspective of how to conduct business. They are more likely to leverage new technologies, hire unique people, and try different approaches to marketing, sales, and solving business problems. People who work at start-ups put more of themselves into their jobs, work a little harder, and are more impassioned about achievement and success. The entire frenetic experience is accelerated to the point where you compress years into months, providing an intimate level of participation not available at larger firms -- the experience is addictive.

When technology start-ups don't succeed (the most common case), they take a lot out of their people. Failures result in layoffs or shutdown, and go from decision to unfortunate conclusion overnight. The technology and products employees have been pouring themselves into typically vanish. That's when you start thinking about what went right and what went wrong, what worked and what didn't. You think about what you would do differently next time. That process ultimately ends with some pent-up ideas and frustrations which -- if you let them eat at you -- eventually drive you back into the technology start-up arena. It took me 12 years and 5 start-ups to figure out that I was on a merry-go-round without end, unless I made the choice to step off and be comfortable with my decision. It took significant personal change to accept that no matter how good the vision, judgement, execution, and assembled team were, success was far from guaranteed.

Where am I going with this? As you have probably read by now, 18 months ago Rich Mogull, Mike Rothman, and I planned a new IT research firm. Within a few weeks we got the bad news: Mike was going to join a small security technology company to get back on the merry-go-round. From talking with Mike, I knew he had to join them for all the reasons I mentioned above. I could see it in his face, and in the same position I would have done exactly the same thing. Sure, Securosis is a technology start-up as well, but it's different. While hopeful Mike would be back in 24 months, I could not know for certain.

If you are a follower of the Securosis blog, you have witnessed the new site launch in early 2009 and seen our project work evolve dramatically. Much of this was part of the original vision. We kept most of our original plans, jettisoned a few, streamlined others, and moved forward. We found some of our ideas just did not work that well, and others required more resources. We have worked continuously to sharpen our vision of who we are and why we are different, but we have a ways to go.

I can say both Rich and I are ecstatic to have Mike formally join the team. It's not change in my mind, but rather empowerment. Mike brings skills neither of us possesses, and a renewed determination that will help us execute on our initial vision. We will be able to tackle larger projects, cover more technologies, and offer more services. Plus I am looking forward to working with Mike on a daily basis!

This is a pretty big day for us here, and thought it appropriate to share some of the thoughts, planning, and emotions behind this announcement.

–Adrian Lane

The Ranting Roundtable, PCI Edition

By Rich

Sometimes you just need to let it all out.

With all the recent events around breaches and PCI, I thought it might be cathartic to pull together a few of our favorite loudmouths and spend a little time in a no-rules roundtable. There's a little bad language, a bit of ranting, and a little more productive discussion than I intended.

Joining me were Mike Rothman, Alex Hutton, Nick Selby, and Josh Corman. It runs about 50 minutes, and we mostly focus on PCI.

The Ranting Roundtable, PCI.

Odds are we'll do more of these in the future. Even if you don't like them, they're fun for us.

No goats were harmed in the making of this podcast.

–Rich

SIEM, Today and Tomorrow

By Adrian Lane

Last week, Mike Rothman of eIQ wrote a thoughtful piece on the struggles of the SIEM industry. He starts the post by saying the Security Information and Event Management space has struggled over the last decade because the platforms were too expensive, too hard to implement, and (paraphrasing) did not scale well without investing a pound of flesh. All accurate points, but I think these items are secondary to the real issues that plagued the SIEM market.

The issue with SIEM's struggles in my mind was twofold: fragmented offerings and disconnection with customer issues. It is clear that the data SIM, SEM, and log management vendors collected could be used to provide insights into many different security issues, compliance issues, data collection functions, or management functions -- but each vendor covered a subset. The fragmentation of this market, with some vendors doing one thing well but sucking at other important aspects, while claiming only their niche merited attention, was the primary reason the segment has struggled. They created a great deal of confusion through attempts to differentiate and get a leg up. Some did a good job at real-time analysis, some provide forensic analysis and compliance, and others excel at log collection and management. They targeted security, they targeted compliance, they targeted criminal forensics, and they targeted systems management -- but the customer need was always 'all of the above'.

Mike is dead on that the segment has struggled and it's their own fault due to piecemeal offerings that solved only a portion of the problems that needed solving. More attention was being paid to competitive positioning than actually solving customer problems. For example, the entire concept of aggregation (boiling all events into a single lowest common denominator format) was 'innovation' for the benefit of the vendor platform and was a detriment for solving customer problems. Sure, it reduced storage requirements and sped up reporting, but those were the vendor's problems more than customer problems.

The SIEM marketplace has gotten beyond this point, and it is no longer a segment struggling for an identity. The offerings have matured considerably in the last 3-4 years, and gone is the distinction between SIM, SEM and log management. Now you have all three or you don't compete. While you still see some vendors pushing to differentiate one core value proposition over another, most vendors recognize the convergence as a requirement, as evidenced by this excellent article from Dominique Levin at Loglogic on the Convergence of SIEM and log management, as well as this IANS interview with Chris Peterson of LogRhythm. The convergence is necessary if you are going to meet the requirements and customer expectations.

While I was more interested in some of the problems SIEM has faced over the years, I have to acknowledge the point Mike was making in his post: the SIEM market is being hurt as platforms are oversold. Are vendors over-promising, per Dark Reading? You bet they are, but when have you met a successful software salesperson who didn't oversell to some degree? A common example I used to see was some of the sales teams claiming they offered DLP equivalent value. While some of the vendors pay lip service to the ability to provide 'deep content inspection' and business analytics, we need to be clear that regular expression checks are not deep content analysis, and capturing network packets is a long way from providing transactional analysis for fraud detection or policy compliance. What gets oversold in any given week will vary, but any technology where the customer has limited understanding of the real day-to-day issues is a ripe target.

Conversely, I find customers I speak with being equally guilty as they promote the 'overselling' behavior. SIEM platforms are at the point where they can collect just about every meaningful piece of event data within the enterprise, and they will continue to evolve what is possible in analysis and applicability. Customers are not stupid -- they see what is possible with the platforms, and push vendor as hard as they can to get what they want for less. Think about it this way: If you are a customer looking for tools to assist with PCI-DSS, and the platform cannot a) provide the near-real time analysis, b) provide forensic analysis, and c) safely protect its transaction archives, you move onto the next vendor who can. The first vendor who can (or successfully lies about it) wins. Salesmen are incentivized to win, and telling the customer what they want to hear is a proven strategy. So while they are not stupid, customers do make mistakes, and they need to perform their due diligence and challenge vendor claims, or hire someone who can do it for them, to avoid this problem.

I am very interested to see how each vendor invests in technology advancement, and what they think the next important step in meeting business requirements will be. What I have seen so far indicates most will "cover more and do more", meaning more platform coverage and more analysis, which is a safe choice. Similarly, most continue to offer more policies, reports, and configurations that speed up deployment and reduce set-up costs. Some have the vision to 'move up the stack', and look at business processing; some will continue to push the potential of correlation; while others will provide meaningful content inspection of the data they already have. Given that there are a handful of leading vendors in this space on a pretty even footing, which advancement they choose, and how they spin that value, can very quickly alter who leads and who follows.

The value proposition provided by SIEM today is clearer than at any time in the segment's history, and perhaps more than anything else, SIEM platforms are being leveraged for multiple business requirements across multiple business units. And that is why we are seeing SIEM expand despite economic recession. Because many of the vendors are meeting revenue goals, we will both see new investments in the technology, and begin to see serious acquisitions.

–Adrian Lane

The Two Laws Of Rootkits

By Rich

I loved Mike Rothman's title to his take on the Cisco IOS rootkit (original article here).

What about "everything is vulnerable" didn't sink in?

Okay, technically a rootkit isn't a vulnerability, but we'll forgive Mike since I know he knows the difference, and he writes his Daily Incite first thing in the morning.

To simplify, here are the Two Laws of Rootkits:

1. You can create a rootkit for anything that runs software.
2. Everything runs software.

(If you don't get the sarcasm, I can't help you).

–Rich

React Faster, And Better, With The A B Cs

By Rich

I've had a bit of a weird week. As I mentioned on Monday, I was driving to physical therapy (physio for my Australian and European friends) when there was an accident in front of me and I stopped to help out. Wednesday night I was coming home from PT and there was another accident right as I was going through the intersection.

This one was far more serious. As soon as I heard the smash and saw the impact out of the corner of my eye, I pulled into the median, hit my hazard lights, and called 9-1-1. One of the advantages of working in the field for so long is that you learn an economy of words to describe a complex situation in just a sentence or two of the crucial information. My first call was:

I'm on-scene of an injury accident at the corner of [x and y]. Two vehicles, with an unconscious unresponsive patient with a compromised airway. Patient is entrapped in the passenger side of the vehicle with access through the driver's side door. I'm a former paramedic and need to go manage her airway

There was a bit more jargon, but not much. The patient was unrestrained in the car with the airbag deployed, which probably meant she hit her head on the passenger window or strut since it was a side impact. There were a bunch of other bystanders and one came out and identified himself as a flight nurse. Her head was slumped over, which caused her difficulty breathing. The nurse jumped in the back of the car, we tilted her head to a normal position and stabilized her neck (one of the few times you're allowed to move the neck after an accident). Her breathing got better, and she slowly started waking up, but clearly had a head injury, which we reported to 9-1-1. The fire department showed up a few minutes later, we got out of the way, and she was being loaded into the chopper as I drove off.

That might be one of the only times I've stopped to help at an accident where my assistance may have mattered. Truth is, unless you're on the ambulance or have advanced equipment with you, the most useful thing you can do is calm the patient and make sure there isn't any more damage. The kinds of injuries you sustain in a major accident are rarely something even a highly trained bystander can help with. I didn't even bother evaluating anything more than her breathing, since nothing else mattered. All you EMTs can skip that full survey if you're helping as a bystander in an urban area.

In this case her head position was keeping her from breathing well, making the situation worse. Just moving it so she could breathe more normally might have oxygenated her noggin a bit more and helped her wake up.

Why the heck am I talking about this on a security geek blog?

Because it's one of those times where there are direct lessons we can apply to our world, and often forget.

I'm a big fan of Rothman's philosophy of REACT FASTER. The idea is that it's more about how you respond to an incident than having the incident in the first place. Truth is in IT, as in life, bad stuff will happen no matter what you do. Systems will crash, hard drives will die, and hackers will break in. David Mortman is one of the other major proponents of this philosophy- incident response is just as important, if not more important, than incident prevention. That's why I'm adding REACT BETTER.

Emergency services are just like programming- a series of algorithms in a structured program flow. It all comes down to the A B Cs- Airway, Breathing, Circulation- in meat-space. Patient have any airway? Nope? Then nothing else matters until you fix that. Breathing? Check. Circulation okay? Then move on to spinal immobilization. It's a recognition that you can't jump from A to C and expect success. It's exactly what we did to help that girl in the car, rather than focusing on the blood or other distractions.

Don't just react- have a response plan with specific steps you don't jump over until they're complete. Take the most critical thing first, fix it, move to the next, and so on until you're done. Evaluate, prioritize, contain, fix, and clean. (You OODA fans should love this).

And always remember the loudest patient is rarely the most important. If they're screaming their head off, their airway is fine. It's the quiet ones you have to watch out for.

–Rich