JOB: SIEM Architect at RSA

As a favor to yet another friend, I am posting yet another SIEM-related job. IMHO, it is an ideal position for a good architect looking to jump ship from a failing or “non-performing” SIEM vendor:

The RSA Security’s fast-growing  Security Management group is looking for the best technical minds to develop the next generation of Security Information and Event Management (SIEM) software.  We are building a great organization with talented employees with the highest ethical and professional standards who deliver a portfolio of products to enable our customers to protect their information assets.

Ideal candidate will have broad knowledge of IT security with proven ability to architect and build complex enterprise systems.  You must enjoy working in a rapidly-changing, high-pressure environment spanning multiple geo locations. As a lead architect, you will exert significant influence over the technical strategy and the architectural definition of the next generation of RSA’s Security Management products.  Practical experience in one of the following areas is required: large-scale database systems, real-time design, network monitoring and analysis.

This position is full-time, based in Bedford, MA. If you are interested in joining the Security Management group in RSA, please send your inquiry or resume to Lauren Day at  lauren.day@emc.com or 978-686-2234.

… and somebody now owes me beer at RSA 

Possibly related posts:

• SIEM-related Job: Principal SIEM Consultant 
• SIEM-related Product Management Job: Atlanta, GA
• All jobs posts on my blog

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.

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 = ?

 

When “Solutions Before Problems” Approach is OK?

So, they say that dumb overeager salespeople push “what they have” no matter “what the customer needs” – and, more often  than not, end up with BOTH an annoyed customer and some damage to their employer’s brand (yes, it might be all about his/her personal sleaziness, but it DOES damage the employer’s brand!) On the other hand, it is said that a smart salesperson will always inquire about “what problem does the customer have?” and then position/describe his wares accordingly, IF they are indeed a fit for his needs.

I happen to agree with this and think that problems should be visible before solutions are unpacked. Other people mention it as well (recent example from Andy’s blog and its continuation, and then here and again here; read it – its fun!)

However,  what happens when a customer insists: “tell me what ya have!”  There are, curiously, many versions of that, when a customer confronts you with something like this:

• “You guys are experts; tell me what I need to be doing ‘to be OK’”
• “Please tell me which options I should enable”
• “Just give me a document explaining how I can “be secure” using your product”
• “You tell me which one is the best!”

(all above examples are fictitious, but “inspired by true stories”)

I can fight it (and I did fight it on a few occasions in the past, actually, insisting on problem description), but it creates a bizarre paradox:

“Customer is always right” + “problems before solutions” + “customer wants to hear about solutions first” = ?

Just sharing an observation… 

Dedicated to All PMs Out There

A must read on product management... funny as life :-)

"You Might be a PM if…

· … someone asks about your weekend plans and your answer consists of a list of Pri ones, twos, and threes.

· … you’ve ever ended a relationship using a PowerPoint presentation."

(more)