Novell Bought–What Happens in SIEM?

After I came back from my vacation in Egypt, I started looking through all the noise related to Novell acquisition by Attachmate. Everybody whines about Microsoft, Linux, VMware, patents, open-source, unknown “IP bundle”,  etc – but what about SIEM? Novell has Sentinel SIEM and NetIQ, the previous Attachmate victim purchase, has their own toy “SIEM” – Security Manager.

Now, we can all joke about how sad that NetIQ SIEM really is, how it doesn’t scale and how nobody uses it – and culminate with quotes from Gartner’s Mark Nicolett about it (see “Magic Quadrant for Security Information and Event Management, 2010”): “not very visible in competitive evaluations” and “not growing with the market.” Seriously, if your product team fails to impress Mark with a few no-you-cannot-call-them-fake happy customer references and the final SIEM MQ report goes out with the above quotes, you should look into what seppuku really means to you

So, what can become the future “Attachmate SIEM”?

1. Is it NetIQ SM, coming back as a lumbering zombie to SIEM playground to be slaughtered in competitive deals?
2. Is it Novell Sentinel, which is now improving both its technology and market position by leaps and bounds?
3. Is it both but with some magic differentiation positioning? [ahem…like Tweedledum and Tweedledee of SIEM: IBM TCIM and IBM TSOM perhaps?]
4. Is it some future integrated version of both?

While I don’t claim to possess any deep inside information on the deal, I think one can envision the last option actually working out OK over the long term for all involved – as well as for customers?   For example, combine NetIQ SM strength on Windows (and servers/desktops in general) with Novell cross-platform correlation, UIs, new log manager, etc. Reuse their FDCC-focused pieces too maybe. Also,  integrate NetIQ system management tools with Sentinel.

So, if I were them (and here is my unsolicited product strategy tip), I‘d salvage NetIQ “SIEM” for parts and use them to bulk up Novell Sentinel where such parts can be plugged in with minimum effort. Salvage some useful Windows correlation rules they used to have and port them into Sentinel. At the same time, integrate more functional NetIQ products with Sentinel to improve “IT and security management” story for Novell/Attachmate. In the short term, just make most NetIQ Security Manager customers happy by upgrading them to Novell Sentinel.

“So, What Should I Want?” or How NOT to Pick a SIEM-III?

“So, what should I want?” – the allure of asking that question is truly irresistible when dealing with somebody who – presumably – knows more than you do about a particular subject. Lately, I experienced its force first hand when dealing with various contractors on swimming pool, flooring, A/C, remodeling – all new to me due to purchase of our first house. These insane words just roll off your tongue after a contractor explains 57 floor board options or 4 types of swimming pool heaters.

In light of this, I am not shocked when a SIEM prospect asks that question of a vendor sales guy or – slightly better – a field engineer. Have you ever caught yourself asking  questions like:

• What log data I should collect first?
• What are the best reports I should run?
• Which correlation rules I should enable?
• What data I should search for?
• What is the best access control policy for my SIEM implementation?

That stuff happens out there every day! Despite all the evangelizing about “business requirements”, “use cases”, “focus on problems solved” and other words and phrases of wisdom, a lot of SIEM is purchased as described above.

Dear vendor, tell me what should I want?!

And you know what? If your organization is truly committed to the cause of furthering world’s idiocy, that may work! Asking the vendor is BETTER than just choosing at random (as I discovered with some of my house-related chores). Yes, on average, you’d get suggestions towards more expensive stuff (surprise!!), but vendor research + vendor opinion (IMHO) are better than no research + random choice.

And of course! The above point about that working (occasionally, somewhat…) does NOT remove the simple fact that:

THE RIGHT WAY TO PROCURE A SIEM IS STILL …

… THINKING ABOUT YOUR REQUIREMENTS AND THEN YOUR USE CASES. And then choosing a product.

Still, evil allure of “please tell me what I want?” is very hard to resist when looking for SIEM and log management tools.

BTW, On Choosing SIEM  has the “less wrong” way described in more details.

Possibly related posts:

• On Choosing SIEM
• I Want to Buy Correlation” or How NOT to Pick a SIEM?
• The Myth of SIEM as "An Analyst-in-the-box" or How NOT to Pick a SIEM-II?
• Logging, Log Management and Log Review Maturity
• Log Management + SIEM = ?
• On SIEM Complexity
• SIEM Bloggables: SIEM Use Cases
• Whitepaper with detailed SIEM use cases (using a particular SIEM as an example)
• Log Management / SIEM Users: "Minimalist" vs "Analyst"
• All posts labeled SIEM

Compliance Mega-Epiphany!

After spending a week at an amazing Project Honeynet 2010 Annual “Get-together” in Mexico City, I realized that the workshop environment was missing one big thing: nobody ever mentioned COMPLIANCE (!!!). Yes, the pink elephant in the room was …not in the room – no trace of it, not even a whiff of compliant elephant dung.

The discussions covered malware (mostly bots, but also Conficker, of course), malware reversing, attacker behavior, distributed data analysis, intelligence gathering, log analysis (see the class that I gave there) – but not compliance. As a result, my brain got completely drained of all compliancy (and, no, the fact that I had to then fly to give my PCI DSS keynote didn’t stop it from draining).

And then I had A COMPLIANCE EPIPHANY.

You see, compliance has no value. [this would be a good moment to say that this gets a Captain Obvious 2010 award :-)] None! If somebody offers you “ROI for compliance,” just smile and kick them in the nuts. Hard! Then smile again. And if you are feeling generous, do it again! Again!!

Let me rephrase it: regulatory compliance has no intrinsic value. Just as a seatbelt law that fines you $30 for not wearing a seatbelt has no value – in fact, it has a negative value (of -$30) to those fined.

However, the epiphany continues: does the above mean that all the recent “comply-mancing” is in vain?

No, I think that is is needed more than ever!

Imagine the Universe where we, security professionals, possess detailed information on the threats that we face AND on the countermeasures we have – complete with how efficient each countermeasure is against each threat. In this case, doing “risk management” will be trivial: run a list of threats your organization faces, get the desired degree of security (or, “risk”, if you must call it that), then pick the countermeasures which will get you there, starting from the least expensive. Bingo! You are done. If you run out of budget in the process, then go back and reassess the desired degree of security/”risk”. Or negotiate the lower price with the countermeasures provider.

As you are reading the above, you are quickly coming to a realization that such description truly has nothing to do with the world we live in (sorry for NLP mind tricks…)

N-O-T-H-I-N-G!

In our world, threats are of unknown frequency and damage (ALE my ass!), countermeasures are of unknown efficiency and random cost – plus both change all the time. And we don’t even have the formula to plug the unknown and changing numbers in. And we can’t reliably value assets and losses. And we don’t know what is our desired level of security – that was icing on a security cake…yummmm.

So, what are the choices a majority of organizations take? Do nothing. Or do something random. Or do “something cheap.” Securosis folks once called it a market failure in security. Rich’s recent presentation at Secure 360 conference also spoke about the same.

The result? Massive 0wnage, fraud, losses, breaches and other cyber-freaking-war.

Here is where compliance comes in. Compliance is a blunt instrument (a sledgehammer, as I say here) to compel people to do security, auditability, transparency, even responsibility for the losses of others and sometimes even for their own losses, etc.

We live in an intensely interconnected world and if a merchant does not protect the data belonging to an issuer (taking an example from PCI land), we all suffer. If people don’t protect [or remove] such data, we’d have no ecommerce as electronic payment system will eventually crash. No electricity as SCADA systems will [eventually] be hacked. And no healthcare as eventually reliance on computers in healthcare will lead to  people being KilledBySoftware (also see Security Predictions 2020)

Can we mandate that people do a good job? No. “Good job” by definition comes from the heart, not from the whip. Is it still worth it? Yes, I think so. In other words, the current onslaught of compliance is a sign that information security is pretty much mainstream. In the future, compliance efforts will help establish a new, higher baseline level will be established – and security battle will shit to levels above it.

Finally, is there any other way to sell security? Yup, FUD. Arghh!!!! You are sooo getting owned if you don’t buy our stuff!!! I happen to think compliance is a better choice than that.

 

To conclude this passionate epiphany, I have to say, thrice:

If you are “doing compliance” and gain no value of security, you are probably an idiot. Please stop!

If you are “doing compliance” and gain no value of security, you are probably an idiot. Please stop!!

If you are “doing compliance” and gain no value of security, you are probably an idiot. Please stop!!!

Possibly related posts:

• Risk vs Risk
• My Best PCI DSS Presentation EVER!
• Source Boston 2010 Conference Notes and our PCI DSS presentation.

Log Management / SIEM Users: “Minimalist” vs “Analyst”

Just a random piece of some research project I did at some random point :-) In discussions at RSA 2010 conference, somebody mentioned that SIEM, log management and other monitoring/detection security product users are split into two major categories: one actually uses the product while the other “buys it for compliance” and then eventually uses … as a doorstop, for example.

And I actually had  an old presentation about this that was offered as strategic guidance to my consulting client (a vendor).

Here is that picture and text: two types of SIEM/log managements users that your solution has to make happy:

“Minimalist” SIEM/LM User

•Still evolves from “logs are dirt” to raw collection of log data

•Pure compliance focus – “deliver me from evil… eh… auditors” (or assessors, in case of PCI DSS)

•Collecting logs is the primary “activity”; not even thinking about log review yet

•Checkbox mentality is rampant among that type of user (sometimes, “correlation” is one of the checkboxes, sadly)

•Less mature; needs more hand-holding when deploying the product (might not want any help though…)

“Analyst” SIEM/LM User

•Evolved to “so we have them collected – now what?”; stuck now and not sure how to use “all that data”

•“Compliance+” or even pure security/operational focus; for example, SOC operation

•Using logs – review, analysis, at the very least investigations

•Explore and use logs mentality, focuses on getting the value of the data and solving problems

•More mature; needs more “cool tools”

So, before you plan/design/build your solution, think what is the primary user type… but keep in kind that to be truly successful you might need to entice both.

Enjoy!

Possibly related posts:

• SIEM Bloggables
• The Myth of SIEM as "An Analyst-in-the-box" or How NOT to Pick a SIEM-II?
• Log Management + SIEM = ?

 

Open Source CLOUD SIEM, Anybody?

"It's too bad I am not building an open-source SIEM … but if I would" (extra credit: guess the inspiration for this line), I would actually not build a software security information and event management (SIEM) product.

If I were doing it (and I am not!),  I’d built an open-source-based “cloud SIEM” with a default option to have it hosted by the vendor (that is you) as well as with a possibility to have it hosted by the customer (that is, old school on-premise model). The latter option would give you a classic open source “product.”

Think about it! If you are a new company, you cannot afford to be in the appliance business. That leaves two choices: software and SaaS. If you want to sell software, you are probably insane, go lock yourself up :-) If you want to give away software and sell services, you are OK. But won’t SaaS be better? And you can combine it with on-prem model, if some folks insist.  My recent employment made me quite SaaS-obsessed, since I had a chance to observe an excellent SaaS operation from the inside. It was amazing how easy it is to provision trials as well deploy the service in production, track usage and improve customer experience.

But let’s take a step back first! A lot of folks try to understand the relationship between “open source” and “cloud everything” (discussions about their relationship here, here, here and obviously here). The main idea here is the following: if people have “trust issues” with cloud providers, what is a better “mistrust breaker” than showing the source code for your solution? “Wonna audit?” - “Knock yourself out!” Moreover, if people have “hidden costs issues” with open source software, what is a better way to mitigate  it but to offer to run it for them? No hidden costs, not even electricity…

So, if you are possessed by SIEM aspirations (and I am not!), head to the clouds. For starters, your tool will be easier to deploy and update. But what is much more important, you’d take a fare shot at solving scalability problems without being a database tuning uber-guru. Unlike early software SIEM vendors (FAIL!), you won’t have to sheepishly point in the direction of mammoth Sun boxes, you’d just fire up another EC2 instance (or a thousand).  Moreover, on the scalability front, you’d have a fare shot against established SIEM vendors: I often hear rumors that even today, in the age of “cheap hardware”, some large organizations with loads of log data simply cannot architect a SIEM to handle all their security log data. And cloud computing leads to affordable scalability!

Solving these performance problems will let you use the CPU resources for log data parsing, correlation, stored data analysis and all sorts of other fun stuff. Storage, whether raw text or parsed data, will be even easier. Bandwidth will be a bit tricky, but I am leaving it out of this piece for a particular reason … don’t want to spill too much (I am leaving “the collection challenge” out as well).

Finally, as cloud applications [as well as web applications, in general] grow in importance, the whole idea of “SIEM in the cloud for the cloud” won’t be as naive. As we know,  the need for auditing comes last (here), but when it does come, it will come in force and both SMBs and F2000s will have this problem.  And it never hurts to be better prepared for the death of on-prem apps, if we are to believe certain visionaries.

So, throw together some EC2 magic, some database code and a sleek, well-designed UI to delight the users – and you are ready to do battle with foes 10x your size…

Any thoughts?

Possibly related posts:

• Why No Open Source SIEM, EVER?
• “On Open Source in SIEM and Log Management”
• Various SIEM posts.

Obligatory “added everywhere” posts :-)

• I am not at Qualys anymore and looking for the next big security idea to work on! Meanwhile, I might be available for fun consulting projects related to PCI, log management or other fun security things.

Dumb Luck IS a Strategy!

While still at GOVCERT.NL, I've attended a fun little presentation, describing a penetration test (I cannot provide any more details as it was a "No Press" presentation - this post is not about it, but rather was inspired by it!)

In any case, if you do pentests, think about all the RECENT cases where you break in to a major corporation through:

• a Solaris system with Internet-exposed telnet with a guessable password OR a telnet vulnerability (circa 1994!)
• an exposed VPN appliance with a manufacturer's administrator password
• a router with default "enable" password
• or, something else entirely - but something that rivals the above example in its unparalleled, unbelievable, abysmal, deep idiocy.

Indeed, many of my pentesting friends still report plenty of such cases (one was also featured in the presentation mentioned above). Whenever I hear about it from a pentester, I always ask:

Do you think "somebody bad" had already passed through the hole you just discovered?

Maybe an hour ago, a day ago - or a year ago?!

I cannot see how the answer can be "no."

Even though pentesters usually don't focus on forensics (no time for this), it is not uncommon to notice "your predecessor's" intrusion traces while you break through systems, "plant flags", change screen backgrounds [for the admins to notice that you've been there...], etc.

Let's think what this situation really means? Here are the choices I see:

1. Nobody discovered the hole - a law of large  numbers (aka "dumb luck") have "shielded" the company from an incident. Yes, Virginia, dumb luck IS a security strategy for some companies... AND it works for them.
2. It was discovered, but not used/abused by the attacker - maybe he was busy hacking other systems, or saved this for later and never came back due to his ADD. Congratulation, you win! The immense power of dumb luck wrapped you in a protective "security" blanket ... again :-)
3. It was discovered; the attacker went in, looked around and compromised a few others systems, but found nothing of interest (no low hanging fruits)  - and he was not a bot herder. Again, you win. Next time you are in Vegas, bet on "00."
4. It was discovered; the attacker went in and deployed a bot on "your" system - given how many botnets are there, this situation is clearly acceptable to many organizations. In this case, dumb luck strategy, apparently, still work: so they use your box to spam and phish somebody else ... big deal!
5. It was discovered; the attacker went in and stole all your credit card information (it is now for sale) - even in this case, the user of "the dumb luck strategy" still "wins" (in some perverse sense)! Unless and until the stolen information IS tracked back to you OR a friendly neighborhood PCI auditor come and jams a broomstick up your ..., you can still continue to be stupid at your leisure and ignore basic security practices.
6. It was discovered; the attacker went in and stole your CEO's Inbox, including the email related to his affair (it is now on CNN) - now, in this case, you lose AND it is time to stop being stupid! Welcome to the "0wned world." Time to launch (relaunch?) your security program and get serious.

What does this teach us about RISK? The lesson here is important:

• For a security professional, an Internet-exposed system with "root/root" is an obvious HUGE risk!
• For your boss's boss's boss, it is NOT!

This is exactly why I think that the most critical problem in security today is METRICS. Metrics that a) work AND mean something to decision makers and b) can be clearly communicated to said decision makers [BTW, a) and b) are two separate problems.] Metrics that cover not only threats and vulnerabilities we face, but also the effectiveness of security countermeasures we deploy. Metrics you can act on - and ones your boss (and his boss) will act on. Metrics that lead to correct decisions about which risks to accept, which to  mitigate (all while knowing with what efficiency such mitigation occurs) and which to transfer.

Until that time, the dreaded "C-word" (compliance) will trump "the other C-word" (common sense) as a driver for security ... and we will continue to live in the "0wned world."

Possibly related posts:

• Risk vs Risk 

To All Strategists!

Penelope wonders "Do you think you’re a strategist? You’re probably wrong."

Required reading to those of my colleagues who just coined new strategist titles for themselves...

Fun quote: "Most people I have managed have told me, at one point or another, that their strength is strategy. For the most part, I hear this as “I don’t know how to execute what you’re asking me to execute.” "

Speaking at SANS (October 4th, 2006)

Just a heads up that I will be speaking at SANS, this time as a vendor though. The talk is largely about choosing your approach to log management: should you build, buy, or outsource (or combine the above)?

Last time I gave this preso I was told that I managed my inherent "vendor bias" pretty well, so the talk was truly useful for many folks in attendance.

Come on in: October 4th, 12:30PM-1:15PM, Caesars Palace, Las Vegas, NV