Anton Chuvakin

A member of the Gartner Blog Network

Anton Chuvakin
Research VP
2+ years with Gartner
14 years IT industry

Anton Chuvakin is a research VP at Gartner's GTP Security and Risk Management group. Before Mr. Chuvakin joined Gartner, his job responsibilities included security product management, evangelist… Read Full Bio

Should I Use “SIEM X” or “MSSP Y”?

by Anton Chuvakin  |  December 16, 2014  |  4 Comments

Lately I’ve been surprised by some organizational decision-making as they think about their sourcing choices for security monitoring. Specifically, some organizations want to decide between “SIEM Brand X” and “MSSP Brand Y” before they decide on the model – staffed in-house, managed, co-managed, outsourced, etc. While on some level this makes sense (specifically, on a level of “spend $$$ – get a capability” whether from a vendor tool run by employees/consultants or from a service provider), it still irks me for some reason.

Let’s psychoanalyze this! IMHO, in real-life nobody decides between “BART or Kia” or “Uber or BMW” – people think first about “should I buy a car or use public transportation?” then decide on a vehicle or the most convenient mode of transportation. In one case, your money is used to buy a tool, piece of dead code that won’t do anything on its own and requires skilled personnel to run. In another case, you are essentially renting a tool from somebody and paying for their analysts time. As a sidenote, occasionally, I see a request for something that looks and behaves as BOTH a SIEM and a MSSP, such as a request for managed SIEM contract (“If you write an RFP for a car AND for a bus pass as one document, you’d get an RFP for a chauffeured limo, with that price” as some anonymous, but unquestionably wise CSO has said)

So, to me, deciding whether to own a tool or to rent time from others is The Decision, but which brand of tool or MSSP to procure is secondary.

  1. PICK THE MODEL SIEM, MSSP, hybrid (such as staff augmentation, co-managed, or even both SIEM and MSSP)
  2. PICK THE BRAND(S) to shortlist.

Admittedly, some hybrid models are fairly mixed (“MSSP for perimeter, but Tier 3 alert triage in-house; internal network monitoring with a SIEM staffed by consultants, and internal user monitoring by FTEs” is a real example, BTW) and you may not have 100% certainty if going for a hybrid. Still, clarity on the degree of externalization is a must.

Otherwise, IMHO, you end up with a lot of wasted time evaluating choices that simply cannot work for you, for example:

  • If you know you cannot hire, don’t look at SIEM [SIEM needs people!]
  • If you cannot move your data outside the organization, don’t look at MSSPs
  • If you cannot hire AND cannot move data out, go with the “managed SIEM”

Therefore, I think it helps to narrow down the options using the coarse-grained model filter and then go sort out the providers/vendors.

Am I wrong here? Can you intelligently choose between a bunch of SIEM vendors, MSSPs and consulting firms doing managed SIEM if you don’t first settle on the model?

P.S. If you call us at Gartner with another “What is better, MSSP X or SIEM Y?” question, we will undoubtedly help you regardless of the above. Still, I think model for monitoring/management should precede the brand…

Blog posts related to this research on MSSP usage:

4 Comments »

Category: monitoring MSSP security SIEM     Tags:

How To Exit an MSSP Relationship?

by Anton Chuvakin  |  December 12, 2014  |  1 Comment

Let me touch a painful question: when to leave your managed security services provider? While we have the research on cloud exit criteria (see “Devising a Cloud Exit Strategy: Proper Planning Prevents Poor Performance”), wouldn’t be nice to have a clear, agreed-upon list of factors for when to leave your MSSP?

For example, our cloud exit document has such gems as “change of internal leadership, strategy or corporate direction”, “lack of support”, “repeated or prolonged outages” and even “data, security or privacy breach” – do you think these apply to MSSP relationships as well?

And then there is that elephant in the room…

elephant

(source)

FAILURE TO DETECT AN INTRUSION. Or, an extra-idiotic version of the same: failure to detect a basic, noisy pentest that uses commodity tools and no pretenses of stealth?

[BTW, this is only an MSSP failure if the MSSP was given access to necessary log data; if not, it is a client failure]

Not enough? How about systematically failing to detect attacks before the in-house team (that… ahem …outsourced attack detection to said MSSP) actually sees them?

Still not enough? How about gross failures on system change SLA (e.g. days instead of hours), failure to detect attacks, failure to refine rules leading to excessive alerting and failure to keep client’s regulated data safe?

In any case, when signing a contract, think “how can you terminate?” When onboarding a provider, think “how can you off-board?” A detailed departure plan is a must for any provider relationship, but MSSP case also has unique twists…

Any thoughts? Have you left your MSSP in the dust over these or other reasons? Have your switched providers or brought the processes in-house? What would it take you to leave?

Blog posts related to this research on MSSP usage:

1 Comment »

Category: MSSP security     Tags:

DLP Without DLP!?

by Anton Chuvakin  |  December 3, 2014  |  11 Comments

“Titanic” was a big ship (it also was compliant) and it was probably prestigious to be seen on its deck. However, if somebody were to tell you that it would sink soon, you would rapidly develop a need to part ways with it…. Now I am NOT saying that data loss prevention (DLP) market is the “Titanic” – far from it. Our market measurements, done elsewhere at Gartner, still show projected growth (although, this states that “DLP segment growth rates have been reduced by 9.7% and 9.9% for 2014 and 2015, respectively” due to issues like “complexity in deploying companywide DLP initiatives, value proposition realization failures and high costs”).

As we are updating GTP DLP research, I think I noticed a disturbing trend – organizations planning what is essentially a data loss prevention project without utilizing DLP technology.

Think about it! In some cases, the sequence of events is truly ridiculous and goes like this:

  1. DLP technology is purchased and deployed
  2. The organization is breached and data stolen
  3. Anti-data breach project is initiated.

Say what?! Has Anton lost his mind while vacationing in Siberia?

I assure you that this seemingly idiotic sequence of events is real at some organizations. At others, I observed that a project to “detect exfiltration”, “gain network visibility” or even directly “stop data losses” is initiated and DLP technology is not considered central to it or even involved. In essence, they do DLP without DLP! This seemingly caught some vendors between the desire to be present in the DLP market and the readiness to jump off (such as towards an adjacent market or even into the blue ocean of new market creation) upon seen the first signs of an iceberg…

How does a DLP-less data loss project look like? As mentioned above, it may focus on exfiltration detection, network forensics/visibility (with focus on outbound data transfers) or other network-centric security analysis. Indeed, if Sony really did lose 11TB of valuable data, the challenge is not with fancy content inspection, but with basic network awareness. Even a good SIEM consuming outbound firewall logs and an analyst watching the console will be very useful for this and will allow one to detect massive data losses – and sometimes in time to stop the damage…

Thoughts? Have you seen any “DLP without DLP” lately?

Posts related to DLP research in 2013:

11 Comments »

Category: DLP philosophy security     Tags:

My Top 7 Popular Gartner Blog Posts for November

by Anton Chuvakin  |  December 1, 2014  |  Comments Off

Most popular blog posts from my Gartner blog during the past month are:

  1. On Comparing Threat Intelligence Feeds (threat intelligence research)
  2. Detailed SIEM Use Case Example (SIEM research)
  3. MSSP: Integrate, NOT Outsource! (MSSP research)
  4. SIEM Magic Quadrant 2014 Is Out! (announcements)
  5. Popular SIEM Starter Use Cases (SIEM research)
  6. MSSP Client Onboarding – A Critical Process! (MSSP research)
  7. Named: Endpoint Threat Detection & Response (ETDR research)

Enjoy!

Past top posts:

Comments Off

Category: popular security     Tags:

Our DDoS Papers Publish

by Anton Chuvakin  |  November 19, 2014  |  2 Comments

Our papers on Denial of Service (DoS/DDoS) protection have just published. Together with Patrick Hevesi, our newest team member, we have updated and expanded our DDoS coverage.

  • “DDoS: A Comparison of Defense Approaches” is our flagship DDoS document that states that “distributed denial of service attacks have risen in complexity, bandwidth and number of occurrences targeting enterprises. Organizations must architect their defenses with both cloud and on-premises defenses along with integrating DDoS responses into the current incident response process.” Now the document features much more vendor/provider coverage and updated architecture guidance, as well as more content on modern attacks and defenses.
  • “Blueprint for Mitigating DDoS Attacks and Protecting Data Centers and Hybrid Cloud” is a quick document that “defines a DDoS defense architecture for enterprises with a mission-critical website or e-commerce site and that have multiple ISPs connected into their data centers and corporate centers, and that use public IaaS.” This document features a sample DDoS defense architecture using cloud and on-premise components.

Enjoy!

P.G. Gartner GTP subscription required for access.

Others posts announcing document publication:

2 Comments »

Category: Denial of Service security     Tags:

MSSP Client Onboarding – A Critical Process!

by Anton Chuvakin  |  November 14, 2014  |  Comments Off

Many MSSP relationships are doomed at the on-boarding stage when the organization first becomes a customer. Given how critical the first 2-8 weeks of your MSSP partnership are, let’s explore it a bit.

Here are a few focus areas to note (this, BTW, assumes that both sides are in full agreement about the scope of services and can quote from the SOW if woken up at 3AM):

  • Technology deployment: unless MSSP sensors are deployed and are able to capture logs, flows, packets, etc, you don’t yet have a monitoring capability. Making sure that your devices log – and sending logs to the MSSP sensor – is central to this (this also implies that you are in agreement on what log messages they need for their analysis – yes, I am talking about you, authentication success messages :-))
  • Access methods and credential sharing: extra-critical for device management contracts, no amount of SLA negotiation will help your partner apply changes faster if they do not have the passwords (this also implies that you log all remote access events by the MSSP personnel and then send these logs to …. oops!)
  • Context information transfer: lists of assets (and, especially, assets considered critical by the customer), security devices (whether managed by the MSSP or not), network diagrams, etc all make a nice information bundle to share with the MSSP partner
  • Contacts and escalation trees: critical alerts are great, but not if the only person whose phone number was given to the MSSP is on a 3 week Caribbean vacation… Escalation and multiple current contacts are a must.
  • Process synchronization: now for the fun part: your risk assessment (maybe) and incident response (likely) processes may now be “jointly run” with your MSSP, but have you clarified the touch points, dependencies and information handoffs?

If you, the MSSP client, fail to follow through with these, the chance of success is severely diminished. Now, as my research on MSSP progresses, the amount of sad hilarity I am encountering piles on – and you don’t want to be part of that! For example, an MSSP asks a client: “To improve our alert triage, can we please get the list of your most critical assets?” The client response? “Damn, we’d like to know that too!” When asked for their incident response plan, another client sheepishly responded that they don’t have it yet, but can we please create it together – that is, only if it doesn’t cost extra…. BTW, if your MSSP never asked you about your IR plans during on-boarding, run, run, run (it is much better to actually walk thru an incident scenario together with your MSSP at this stage).

In another case, a client asked an MSSP “to monitor for policy violations.” When asked for a copy of their most recent security policy, the client responded that it has not been created yet. On the other hand, a sneaky client once scheduled a pentest of their network during the MSSP onboarding period – but after their sensors were already operational. You can easily imagine the painful conversations that transpired when the MSSP failed to alert them…. Note that all of the above examples and quotes are fictitious, NOT based on real clients and are entirely made up (which is the same as fictitious anyway, right? Just wanted to make sure!)

Overall, our recent poll of MSSP clients indicated that most wished they’d spent more time on-boarding their MSSPs. Expect things to be very much in flux for at least several weeks – your MSSP should ask a lot of questions, and so should you! While your boss may be tempted by the promises of fast service implementation, longer on-boarding often means better service for the next year. Of course, not every MSSP engagement starts with a 12-week hardcore consulting project involving 4 “top shelf” consultants, but such timeline for a large, complex monitoring and management effort is not at all offensive. In fact, one quality MSSP told me that they can deploy the service much faster than it takes their clients to actually fulfill their end of the bargain (share asset info, contacts, deploy sensors, tweak the existing processes, etc).

Blog posts related to this research on MSSP usage:

Comments Off

Category: MSSP security     Tags:

MSSP: Integrate, NOT Outsource!

by Anton Chuvakin  |  November 5, 2014  |  4 Comments

Security outsourcing! While the concept makes many managers happy (“Phew… no need to do security anymore” — yeah, right!), I have noticed that some smart MSSP leaders avoid the “O word.” If we are to believe Wikipedia, “outsourcing” implies “contracting out of a business process to another party.” On the surface, it sounds like “security monitoring” and “security device management” are perfectly fine business processes.

However, where does your security monitoring process end? If you think that it ends with some alert being triggered, then you have indeed been outsourcing the entire process. On the other hand, if you consider what happens after that alert is produced by an MSSP security analyst to also be part of your monitoring, then you ultimately INTEGRATE the processes (yours and MSSPs) rather than OUTSOURCE yours to an MSSP.

My early research conversations with both MSSP customers and providers themselves reveal the theme: those who think “integrate, NOT outsource” usually get much more value out of the MSSP relationship. In a dramatic break from my personal “policy” of not linking to vendor content from my Gartner blog (motivated by my utter lack of desire to waste time fighting idiotic accusations of ‘vendor favoritism’), here is a great example of integrated security operations with an MSSP:

Are you maximizing the value from your managed security services provider (MSSP) relationship?

(source: IBM via this blog)

Vendor-produced or not, I can recognize awesomeness when I see it. Thanks to  @mikebsanders for an excellent resource.

Now, what does it all mean?

This means that for the MSSP to work well for you, process integration must be carefully planned. Here we talked about the alert response integration (and here about the SLAs), but the same applies to device management (integrate with your change management and reporting), incident response (integrate with your IR) and many other processes.

This also means that this focus on integration allows you to vary the degree of security ‘outsourcing’ or externalization. If your plan – monitor – triage – respond – refine chain is well planned, you can almost painlessly engage external resources (MSSP, consultants, etc) at whatever stage: need more help with cleaning the mess? Call that IR consultant. Want to shift some perimeter monitoring duties outside? Go get that MSSP. Want to bring specific application security monitoring tasks in-house? Do exactly that. Some process chunks will externalize well, some poorly [and some not at all], but at least you will have a predictable map of what goes where and who does what…

Blog posts related to this research on MSSP usage:

4 Comments »

Category: monitoring MSSP security     Tags:

My Top 7 Popular Gartner Blog Posts for October

by Anton Chuvakin  |  November 3, 2014  |  Comments Off

Most popular blog posts from my Gartner blog during the past month are:

  1. SIEM Magic Quadrant 2014 Is Out! (announcements)
  2. Security Planning Guide for 2015 (announcements)
  3. On Comparing Threat Intelligence Feeds (threat intelligence research)
  4. Detailed SIEM Use Case Example (SIEM research)
  5. Named: Endpoint Threat Detection & Response (ETDR research)
  6. Popular SIEM Starter Use Cases (SIEM research)
  7. Acting on MSSP Alerts (MSSP research)

Enjoy!

Past top posts:

Comments Off

Category: popular security     Tags:

On MSSP Personnel

by Anton Chuvakin  |  October 28, 2014  |  4 Comments

Unlike with an on-premise SIEM or even still-mostly-mythical SaaS/cloud SIEM, with an MSSP contract you are paying for people and not just for the tools. This obvious fact – that “S” in MSSP stands for “services” and service implies people – somehow escapes some organizations. Let’s explore this a bit here. If you pick an MSSP partner with an amazing technology platform and unskilled, frequently-churning, lazy, perversely-motivated (tickets closed per hour, anybody?) personnel with questionable ethics and lack of proficiency in your language of choice, do you think your security monitoring capability will…

  1. … succeed brilliantly
  2. fail EPICally
  3. … would be no worse than now
  4. … can go whatever way.

I think you get an idea :-) Now, some of you may, in good faith, choose option 3). Frankly, I was thinking of coming up with some joke about it – but became sad instead …

A wise CSO once told me that in order to outsource a security process (such as security monitoring or device management) and achieve a great result, you have to know precisely how a great process of that kind looks like. Indeed, how would you know that your MSSP runs a great SOC, if you have never even seen one? The same applies to people. So, if you never hired and managed great security analysts, how would you know that your MSSP partner actually employs them? Sure, when you buy products you can rely on our research, the views of your peers or whatever other factors, but such methods are much harder for people and process aspects of your future MSSP relationship. So, I am sorry to break the news here, but thinking is involved!

One quality MSSP provider told me that his favorite MSSP client is one that knows exactly how an excellent security operations capability looks like (such as from his previous job, etc), but also knows that he cannot get one (no chance to hire, needs it faster than his can grow, etc, etc). This makes perfect sense: it is easier to conceptualize and understand a mature security monitoring operation than to actually have one materialize in your organization. Thus, if you know how one looks, you may be able to get that from that MSSP partner.

But back to people – in essence, you need to spend time learning:

a) how does a great security analyst look like?

b) whether your chosen MSSP partner has them?

c) whether they will be assigned to your account?

Otherwise, that MSSP may be cheap – rather than cost-effective. You want economies of scale in monitoring, not cheap crap in monitoring. And it is also your responsibility to understand the difference! So, learn about the security skill sets and relevant certifications, and then about whether the MSSP has them, and also whether their people have real experience fighting threats [and winning, at least occasionally :-)] and then continue checking whether that is still true as your relationship continues…

Finally, how was your experience with MSSP personnel?

Blog posts related to this research on MSSP usage:

4 Comments »

Category: monitoring MSSP security     Tags:

On MSSP SLAs

by Anton Chuvakin  |  October 23, 2014  |  5 Comments

Is 15 minutes a mere instant or an eternity? Is getting an alert 15 minutes after it was first generated fast enough? And the opposite question: is 15 minutes of MSSP-side alert triage enough to make sure that the alert is relevant, high-priority and high-fidelity? Indeed, spending too little time leads to poor quality alerts, but spending too much time on quality alerts leads to the attacker achieving their goals before the alert arrives and is acted upon.

So, yes, I did speak with one MSSP client who said that “15 minutes is too late for us” and another who said that “an MSSP cannot do a good job qualifying an alert in a mere 15 minutes” (both quotes fictional, but both “inspired by a real story”).

The answer to this – frankly not overly puzzling – question is again security operations maturity. On one end of the spectrum we have folks who just “don’t do detection” and rely on luck, law enforcement and unrelated third parties for detection (see this for reference). On the other, we have those with ever-vigilant analysts, solid threat intel and hunting activities for discovering the attackers’ traces before the alerts even come in.

As we learned before, security chasm is very strong in this area.

Therefore, a meaningful MSSP SLA discussion cannot happen without the context of your state of security operations.

For example, if you …

  1. … have no operation to speak of and plan to hire an intern to delete alerts? You can accept any alert SLA, [SAVE MONEY!!! GET YOUR ALERTS BY SNAIL MAIL! CARRIER PIGEON OK TOO! :-)] whether it is at the end of the day, or even a week. If you have no plan to ever act on a signal, a discussion of the timing of action is senseless.
  2. … can act on alerts when really needed, and will probably scramble a response if something significant happens? Look for a few hours or similar timing, and limit alerts to truly critical, “incident-ready” ones.
  3. … have a defined security monitoring/response function that is equipped to handle alerts fast? Aim at up to an hour for significant alerts and others maybe at the end of the day.
  4. … possess a cutting-edge security response operation? Push your MSSP partner to 15 minutes or less – for the best chance to stop the attacker in his tracks. Set up a process to review and process alerts as they come, and refine the rules on the fly. Respond, rinse, repeat, WIN!

The key message is: you don’t want to pay for speed that you won’t be able [or don’t plan] to benefit from. If security alerts will sit in inboxes for hours, you don’t need them delivered in minutes.

Now, what about the SLAs for various management services, such as changing NIDS rules and managing firewalls? SLAs play a role here as well, and – you guessed it – what you need here also depends on the maturity of your change management processes… Some people complain that an MSSP is too slow with updates to their security devices, while others know that MSSP does it faster than they can ever do it.

Blog posts related to this research on MSSP usage:

5 Comments »

Category: incident response monitoring MSSP security     Tags: