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

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.


P.G. Gartner GTP subscription required for access.

Others posts announcing document publication:


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:


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)


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:


Category: monitoring MSSP security     Tags:


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:


Category: incident response monitoring MSSP security     Tags:

Acting on MSSP Alerts

by Anton Chuvakin  |  October 16, 2014  |  6 Comments

Have you seen the funnel lately?



In any case, while you are contemplating the funnel, also ponder this:

what do you get from your MSSP, ALERTS or INCIDENTS [if you are getting LOGS from them, please reconsider paying any money for their services]

What’s the difference? Security incidents call for an immediate incident response (by definition), while alerts need to be reviewed via an alert triage process in order to decide whether they indicate an incident, a minor “trouble” to be resolved immediately, a false alarm or a cause to change the alerting rules in order to not see it ever again. Here is an example triage process:



Now, personally, I have an issue with a situation when an MSSP is tasked with declaring an incident for you. As you can learn from our incident response research, declaring a security incident is a big decision made by several stakeholders (see examples of incident definitions here). If your MSSP partner has a consistent history of sending you the alerts that always lead to incident declaration (!) and IR process activation – this is marvelous. However, I am willing to bet that such a “perfect” track record is achieved at a heavy cost of false negatives i.e. not being informed about many potential problems.

So, it is most likely that you get ALERTS. Now, a bonus question: whose job is it to triage the alerts to decide on the appropriate action?



Think harder – whose job is it to triage the alerts that MSSPs sends you?

After you figured out that it is indeed the job of the MSSP customer, how do you think they should go about it? Some of the data needed to triage the alert may be in the alert itself (such as a destination IP address), while some may be in other systems or data repositories. Some of said systems may be available to your MSSP for access (example: your Active Directory) and some are very unlikely to be (example: your HR automation platform). So, a good MSSP will actually triage the alerts coming from their technology platform to the best of their ability – they do have the analysts and some of the data, after all. So, think of MSSP alerts as of “half-triaged” alerts that requires further triage.

For example:

  • NIPS alerts + firewall log data showing all sessions between the IP pair + logs from an attack target + business role of a target (all of these may be available to the MSSP) = high-fidelity alert that arrives from the MSSP; it can probably be acted upon without much analysis
  • NIPS alerts + firewall log data (these are often available to the MSSP) = “half-triaged” alerts that often need additional work by the customer
  • NIPS alerts (occasionally these are the only data available) = study this Wikipedia entry on GIGO.

A revelation: MSSPs are in the business of … eh… business. So, MSSP analysts are expected to deliver on the promise of cost-effectiveness. Therefore, the quality of their triage will depend on the effectiveness of their technology platform, available data (that customers provide to them!), skills of a particular analyst and – yes! – expected effort/time to be spent on each alert (BTW, fast may mean effective, but it may also mean sloppy. Slow may mean the same…)

Another revelation: MSSP success with alert triage will heavily depend on the data available to their tools and analysts. As a funny aside, will you go into this business: I will send you my NIDS alerts only (and provide no other data about my IT, business, etc) and then offer to pay you a $1,000,000 if you only send me the alerts that I really care about and that justify an immediate action in my environment. Huh? No takers?

So, how would an MSSP customer triage those alerts? They need (surprise!):

  • People i.e. security analysts who are willing and capable of triaging alerts
  • Data i.e. logs, flows, system context data, business context, etc that can be used to understand the impact of the alerts.

The result may look like this:


Mind you that some of the systems that house the data useful for alert triage (and IR!) are the same systems you can use for monitoring – but you outsourced the monitoring to the MSSP. Eh… that can be a bit of problem :-) That is why many MSSP clients prefer to keep their own local log storage inside a cheap log management tool – not great for monitoring, but handy for IR.

Shockingly, I have personally heard about cases where MSSP clients were ignoring 100% of their MSSP alerts, had them sent to an unattended mailbox or hired an intern to delete them on a weekly basis (yup!). This may mean that their MSSP was no good, or that they didn’t give them enough data to do their job well… As a result, your choice is:

  • you can give more data to an MSSP and [if they are any good!] you will get better alerts that require less work on your behalf, or
  • you can give them the bare minimum and then complain about poor relevance of alerts (in this case, you will get no sympathy from me, BTW)

And finally, an extra credit question: if your MSSP offers incident response services that costs extra, will you call them when you have an incident that said MSSP failed to detect?! Ponder this one…

Blog posts related to this research on MSSP usage:


Category: monitoring MSSP security     Tags:

MSSP Client Responsibilities – What Are They?

by Anton Chuvakin  |  October 9, 2014  |  1 Comment

Let me tell you a secret: MSSP is not a box that you throw your money in, and security comes out screaming! Sadly, many would say that the only reason they went with a Managed Security Service partner is to avoid doing any security on their own. However, if you decided to go with an MSSP and not with an in-house capability (such as internally-staffed SOC with SIEM tool at the center) …


This post is an attempt to outline my thinking about such responsibilities and create a structured approach to analyzing them. Intuitively, there are some things that an enterprise MUST do to allow the MSSP to help them (e.g. deploy their sensors, give them credentials for device management, etc). Still, there are more responsibilities that allow the MSSP to help the client better.

In any case, think of this table NOT as a comprehensive list, but as a framework to organize examples:

Value | time –> During on-boarding / before service During MSSP service consumption
To enable service delivery (MUST) Deploy sensors, share network diagrams and access credentials, provide contacts, etc Notify on asset and network changes, access changes, contact info, etc
To enable maximum value from the MSSP
Refine & share a security policy, have IR plans, provide detailed asset and context info, etc Respond to alerts (!), remediate systems, declare incidents and run IR, jointly tune the alerts, communicate changing security priorities, etc

An expanded version of this type of a visual should become your shared responsibility matrix, that will actually enable you to benefit the most from your MSSP relationship. BTW, one MSSP succinctly states in their policies: “The Customer is responsible for all remediation activities.” What about compliance, you may ask? An excellent question – to be handled in the next post :-)

P.S. Of course, there will be people who will insist that “if you want it done well, do it yourself” (that may be true, but it does not mean this route is always the most cost-effective). On the other hand, there will be people who will say “… but security is not our core competence” (eh.. as if locking the doors is)

Blog posts related to this research on MSSP usage:

1 Comment »

Category: monitoring MSSP security     Tags:

Critical Vulnerability Kills Again!!!

by Anton Chuvakin  |  October 6, 2014  |  2 Comments

A killer vulnerability KILLS AGAIN!!! Another “branded vulnerability” – Shellshock – is heeeeere! Run for the hills, escape the planet, switch to a “secure OS” (Windows 3.1 fits the bill), stop the cyber, etc, etc, etc.

<insert all the obligatory World War I references to shell shock and jokes about being bashed by bash> :-)

However, this post is not about Shellshock with a “perfect 10.0” in CVSS Base – at least not directly.

Sure, if you have not patched yet – stop reading this now. Deploy a patch to bash – focus the remediation on the Internet-visible servers first (some of our clients set a reasonable 1 hour patching timeline for this one – as in “patch all exposed systems within 1 hour of patch release.” Eat this, folks that take 90 days to patch!). Scan your servers for the vulnerability to know how exposed you are (if at all), and do not limit the scanning to the Internet-visible sites since having this issue on the internal servers makes the attacker’s job easier. Note that an authenticated scan will show that you are vulnerable on all Unix/Linux servers, but will NOT show where you are exploitable, while an unauthenticated scan will not show all the exploitation avenues (a great case study for the limits of modern VA technology). Some people have temporarily changed shells (tcsh is still alive!), thus breaking many scripts, and deployed NIPS and WAF rules tactically. Do all that, sure. Others have used this as an opportunity to remove the – frankly, idiotic! – shell scripts from public /cgi-bin directories and do other tightening of their infrastructure.

All in all, I think Shellshock is not even in the ballpark of Heartbleed (others disagree): with that baby, pretty much the entire SSL-using Internet was vulnerable and exploitable. Here with Shellshock we have a relatively small population of remotely exploitable systems (early evidence pointed at exploitable sites numbering in thousands, not millions). Sure, the impact (easy remote access by an attacker) is worse, but much fewer sites are exploitable.

But did I say this post is not about Shellshock? Ah, thanks for paying attention! It is not…

When I started being involved with infosec (which feels like a moment or an eternity ago, depending on the situation) by helping out with some Linux boxes at a small ISP, a wise mentor told me: Anton, don’t be stupid, don’t make your security solely dependent on not having any exploitable holes. Back then, IIS had dozens of exploitable remotes, while Apache was considered “secure” – and this is what we used. Still, the infrastructure was set-up in such a way that a remote exploit in Apache that gives you shell as “nobody” combined with one of many locals that escalates you to “root” meant “GAME OVER.” The attacker would have been able to destroy the entire business in about 20 minutes, for good [there were no offline backups – this is 1999 we are talking about]. So, that led to some major rethinking…


So, as a reminder for most and as news for some: do not make your security architecture solely reliant on patching. Big vulnerabilities will happen and so will zero-days, so make sure that your entire security architecture does not crumble if there is one critical vulnerability: do defense in depth, layers, “least privilege”, controls not reliant on updates, monitoring, deception, etc. The fact that they have a 10.0 remote should NOT mean that you automatically lose everything!!

Miscellaneous fun posts:


Category: patching philosophy security vulnerability management     Tags:

Security Planning Guide for 2015

by Anton Chuvakin  |  October 3, 2014  |  Comments Off

Our team has just released our annual security planning guide: “2015 Planning Guide for Security and Risk Management.” Every GTP customer should go and read it!

Its abstract states: “In planning for security and risk management projects for 2015, organizations must scale and adjust their risk management and security practices to satisfy current and future IT and business needs.”

Here are a few fun quotes:

  • “Risk management programs often haven’t scaled, which increased reliance on traditional security patterns — so which should change first? In other words, if security and compliance are indeed falling farther behind, with compliance in particular remaining deeply entrenched in tradition, how can we even begin to adopt new security patterns?”
  • “Use threat assessment and attack models as part of risk assessment and mitigation to determine which controls should be considered. The attack model helps identify what set of controls is necessary to cover various attack stages, channels and target assets. ”
  • “Architect for microperimeterization where the network security boundary shrinks to the host level or smaller. Because perimeters will have to become more dynamic, security will need to be split among the moving parts and pieces.” (perimeter is NOT dead, it is just different…)
  • “Loss of control and visibility will continue in the Nexus of Forces, with mobility and cloud leading the way. But with compliance still often equating security to having control, this leads to challenges in adoption of these now not-so-new technologies.”
  • “Logging and monitoring of privileged activity is also key when the lines are blurred between compute, storage, network and security administration. At a minimum, monitoring must enable reporting and post hoc investigations of events; this paves the way for adding real-time analytics, alerting and enforcement later on.”

Much of the stuff in our doc is, of course, not new, but has been highlighted as important by recent events. Also, some things – while not truly new – may be new to some organizations that are just waking up to the needs of information security (or “cyber“, if you have to call it that)

Past guides from GTP SRMS team (i.e. us):

Comments Off

Category: announcement security     Tags: