Anton Chuvakin
Research Director
1 year with Gartner
7 years IT industry
Anton Chuvakin is a research director at Gartner's IT1 Security and Risk Management group. Before Mr. Chuvakin joined Gartner, his job responsibilities included security product management, evangelist… Read Full Bio
by Anton Chuvakin | February 16, 2012 | Submit a Comment
I’m tired of hearing quotes like “cloud is completely different from traditional IT” as well as those that say “cloud is just like outsourcing, mainframes, etc.” Those who like the former quote will sometimes add that organizations should scrap all the tools they use for traditional IT and buy new tools for the cloud. Those who like the latter quote would say that organizations just need to continue doing what they’re doing, with the same tools.
At this point, it should be clear to most of my enlightened readers that the truth is somewhere in between. Some tools and approaches will continue to work; some tools and approaches will not work while others will work depending upon the circumstances – such as what is being migrated to the cloud, how it is being migrated, etc.
Let’s review some of the things, which are known to be different in various public cloud models:
- Transient assets that appear and disappear, go up and down, etc (for IaaS)
- IP address means less for tracking of those transient assets
- There are layers of the computing stack that are NOT under enterprise control
- Remote environments, sometimes accessed via links of limited bandwidth
- For SaaS and PaaS, lack of ANY traditional “IT infrastructure” such as OS
- “Alien” operations model (sometimes) dissimilar from traditional data center management models
What does it mean for security monitoring? It means that the approach you take will not only depend upon the technical considerations, provider platform choice, application logs, security agents, etc. However, it would also depend on how the organization is moving IT capabilities to the cloud.
- For a “forklift scenario," new applications or even “cloud-only” organizations, these differences will play A BIGGER ROLE in the choice of monitoring approaches, architectures and technologies.
- For a “trickle scenario”, legacy application and “barely cloudy” organizations, these differences will play A SMALLER ROLE in the same choice.
Thus, you might not need any new tools for security monitoring of your cloud environment: your current SIEM, DAM/DAP, DLP, even NIPS (for virtual private cloud with sole route through your network) will work more or less fine.
Or, on the other hand, you might discover that most of your security tools that have to be replaced or at least augmented by tools that are optimized and tested in public cloud environments. New approaches (some mentioned here) such as cloud gateways, detailed application logs or hypervisor telemetry (provided by the CSP) will have to be used.
Thus, we have an ultimate triumph of “it depends” here!
Previous cloud security monitoring related posts are:
Category: cloud monitoring security Tags: cloud security, security, security monitoring
by Anton Chuvakin | February 7, 2012 | 42 Comments
As you learned from my previous posts related to security monitoring of public cloud assets, there are challenges related to monitoring data availability as well as data interpretation.
IaaS environments – such as the well-known ecommerce-retailer-turned-cloud-provider as well as other cloud service providers (CSPs) – offer an interesting challenge that I call “IaaS conundrum.” To remind, when procuring IaaS resources, the organization essentially buys an ability to deploy their own virtual machines on a public provider network. That means that the cloud customer controls everything from the OS up (and usually has no way of affecting the lower layers) while the cloud provider controls everything under the OS down (and usually does not mess with upper layers).
Herein lies the conundrum: as the cloud customer wishing to monitor the security of your IT assets, do you really NEED access to below-OS layers of the cloud stack?
Two possible answers are:
YES: in physical environments, the enterprise controls the data center, the hardware management and physical access control. The only people who can affect the server at the “below the OS” layers are essentially trusted system administrators. Public cloud deployments create an opaque layer that is not controlled (by definition) and thus MUST be monitored by the cloud customers. In addition, a new cast of characters with “superpowers” – CSP administrators – can affect your environment at the lower layers. These “superheroes” do not serve you – they serve their CSP masters.
NO: just as most security monitoring of physical assets starts at OS (think syslog, anti-malware, access control, application security monitoring), it is OK to accept that monitoring will start at the OS layer. Most of the monitoring tools – as well as security tools in general – have not yet grown to understand virtual and cloud environments, thus notions like “hypervisor security” or “cloud stack introspection” are essentially alien science to them. On top of this, it is challenging, if not impossible for a provider to de-multiplex security monitoring data from shared environments.
What do you think?
If you move anything important to the public cloud, would you require that your provider enable such access for ongoing monitoring?
Alternatively, would you prefer that the provider accept the responsibility for security monitoring of your assets?
Maybe, you have another party – think MSSP – that can take over such security monitoring responsibilities?
Previous cloud security monitoring related posts are:
Category: cloud monitoring security Tags: cloud security, security, security monitoring
by Anton Chuvakin | February 2, 2012 | 20 Comments
Everybody knows what “network security monitoring” actually is (even if not everybody is DOING it…). There is a whole book on the subject. In addition, there is a shared understanding in security community about it. Specifically, NSM includes various logs/alerts, packets, flows, session captures, etc.
However, what is “application security monitoring” (ASM)? As I am pursuing my second research project this quarter – one related to SIEM technology futures – I am coming across people attaching the “ASM” label to various technologies and processes. Specifically, these are:
- “We have a web application firewall (WAF) – thus we do ASM” (if “firewall” = “monitoring” and “web applications” = “applications,", then maybe it is indeed ASM)
- “We collect application logs” (which, in reality, means “some application logs” that often nobody understands; also notice the word “collect” contrary to “analyze” here. And what about application context?)
- “We have a tool that analyzes application transactions for fraud” (this sounds like one specific use case of security monitoring inside the application, but what about others?)
- “We decode network traffic up to an application layer” (which likely means that you do NSM right, in contrast to doing application security monitoring)
- “We have a DAM” (which means that requests that the application makes to its database can be looked at; such requests do not constitute the entire pool of security-relevant application activity)
- “We convinced our developers to implement application telemetry useful for security” (this sounds like it will enable application security monitoring; however, what happens with that data after it is generated?)
- “The tool we have can monitor all system calls and API calls made by the running application” (same question: is there any capability, in that tool or another, that helps make sense of the information deluge?)
In your opinion, do any of the above constitute application security monitoring on their own?
Personally, I doubt it. At best, ASM might mean “all of the above” or “many of the above," but I think a few components needed to achieve ongoing visibility of all security-relevant activities inside off-the-shelf and custom applications have not even emerged yet. It may be that security has to outgrow its network roots first and get some application DNA implanted.
The theme that also seems to emerge in my research is that unlike with NSM, answering “what happened?” (example: “error 945842 on application XYZ”) is comparatively less important than answering “what it means?” (example: “security control failed to prevent malicious activity at application XYZ that is important for our business”). Thus, we need to both collect more telemetry AND context, as well as build tools to make sense of that data!
Thus, both enterprises and vendors have work to do in the coming years!
Category: application monitoring security Tags: application security, security, security monitoring
by Anton Chuvakin | January 21, 2012 | 1 Comment
My journey deep into cloud security monitoring continues, with a brief detour into “faith-based monitoring” (as in “we believe our cloud provider takes care of monitoring“).
In any case, let’s try to review what types of data we can leverage for security monitoring of resources deployed in each of the cloud service provider (CSP) types: SaaS, PaaS and IaaS.
| Cloud model |
Security monitoring data |
| IaaS |
· Logs: OS, database, applications, etc
· Network monitoring: local host traffic only, no promiscuous sniffing
· Host / endpoint activity: HIPS logs, antimalware logs, other agent, etc
· (if lucky and your CSP likes you) Some data from lower layers of the infrastructure such as hypervisor logs, change logs, etc
· (if all access to cloud is through such) Proxy/gateway data
|
| PaaS |
· Logs: applications (if written by you – then as long as you engineered and enabled logging)
· Some logs from lower layers of the infrastructure such as select platform logs, error logs, etc
· (if all access to cloud is through such) Proxy/gateway data
|
| SaaS |
· (if CSP provides this) Application logs such as access (often), changes (sometimes), etc
· (if all access to cloud is through such) Proxy/gateway data
· (if applicable) Client-side or browser based monitoring data
|
The above table does explain why some SaaS users tend to trust the provider and treat their CSP like their trusted “outsourcing partner.” Essentially, if your SaaS CSP is not doing a good job with security monitoring, then likely nobody is. On the other hand, it is unlikely that your SaaS provider will tell you when your authorized users are dumping the CRM database and taking off with it… So, even for SaaS (and definitely for PaaS and IaaS), security monitoring is ultimately YOUR responsibility!
Previous cloud security monitoring related posts are:
Category: cloud logging monitoring security Tags: cloud security, security, security monitoring
by Anton Chuvakin | January 14, 2012 | 3 Comments
This post is not a whine about how security in public cloud environments is lagging behind the traditional physical environments. There is nothing here to whine about since our experience with other IT advances – think PC, client-server, web applications, mobile devices – teaches us that it is ALWAYS the case for new technologies. The cycle, that some people might call ‘vicious’, happens like this:
- Invent
- Deploy
- Popularize
- Disaster!!!
- Secure (and eventually even “build it securely”)
and then the next tech is invented and the cycle repeats. Let’s consider security monitoring of IT resources deployed on public clouds, whether SaaS, PaaS or IaaS. Such security monitoring includes logs (primarily), network traffic analysis, host activity monitoring as well as other well-known monitoring mechanisms (for a superb review of these, please review “Security Monitoring” template by Ramon Krikken). As my research project progresses, I am coming across various challenges to cloud asset security monitoring. Here is a quick list:
- Often, unimportant assets move to the public cloud first, and the need to do security monitoring simply never appears.
- Cloud (as well as virtual) assets are known to be transient and change more often than traditional physical systems, adding chaos to the attempts to monitor “who does what” to systems and data.
- The familiar mechanisms – various network security appliances – do not map well to the cloud, and the new mechanisms (wherever available!) have a learning curve.
- Similarly, lack of visibility into the lower layers of underlying infrastructure hampers many monitoring efforts as one might have to peek into the lower layers from the higher ones.
- When lacking network data and system logs, a replacement monitoring method – application logs – comes with its own set of challenges, including working with application developers to engineer logs useful for security and not just for debugging.
- “We just trust our CSP, they’d a great job securing and monitoring our assets!” This is admittedly more likely for users of SaaS providers, but more than a few people seem to confuse “cloud” with “outsourcing”
- Fragmented control over various cloud migration efforts leads to no security monitoring (and even “no security” sometimes); rogue cloud assets are by definition unmonitored by central IT.
- Even when monitored, loss of the unified view of public cloud + virtual / private cloud + traditional makes noticing anomalous and malicious activities harder.
So, my journey continues – watch for more blog posts on cloud security monitoring as my project eventually culminates in architectural guidance for cloud security monitoring …
By the way, if you are a vendor with a technology helpful for security monitoring of public cloud assets, please brief me on your technology.
Previous cloud security monitoring related posts are:
Category: SIEM cloud logging security Tags: cloud security, security, security monitoring
by Anton Chuvakin | January 9, 2012 | 5 Comments
How exciting is that? You combine 3 non-specific words – cloud, security, monitoring – and you get … what exactly? Let’s find out!
This quarter my research focuses on cloud security monitoring and cloud logging. I will try to define the subject(s) and then provide analysis and recommendations for architecting security monitoring of public cloud assets deployed in IaaS, PaaS and even SaaS environments (the word “luck” will likely be used in that last section a lot).
Here’s where I want to take the discussion: if you have IT assets deployed on a public cloud provider network today, and you want to monitor them by using log data, where would you rather send that log data? Your broad choices are (unless you have an MSSP contract, which will change the situation a bit):
- Back to your SIEM tool deployed in your environment (if any): your cloud logs -> your environment
- To a dedicated SaaS log management tool: your cloud logs -> another cloud environment.
When I asked a few people, whether they would conceptually lean towards Choice 1 or Choice 2, they picked Choice 3.
Huh? The Choice 3 is “we are still trying to figure it out, for now we don’t monitor those assets.” A few others mistook cloud for outsourcing and stated that “they trust their provider to deal with logs”…. That’s life in the cloud circa 2012 for you.
Future posts will touch upon such exciting subjects as “what logs you can hope to get in different cloud scenarios?”, “how to compensate for not having logs?” and a few other cloud-specific monitoring challenges that you’ll face in the near future.
Category: cloud logging security Tags: cloud security, security, security monitoring
by Anton Chuvakin | December 19, 2011 | Comments Off
Mark Nicolett has published two brilliant (and I MEAN it!) notes on SIEM: “Planning for an SIEM Technology Deployment” and “How to Deploy SIEM Technology.”
I wish these notes were glued to every SIEM software/appliance box shipped since 1997 (that is when a SIEM tool was first shipped) and were required reading before you are allowed to open that box.
A few quotes to whet your appetite, but
- You must have “a set of security information and event management (SIEM) deployment project steps that will result in a complete definition of requirements, evaluation of the environment to enable a pre-deployment design, evaluation of technology choices and phased deployment.”
- Also, an organization must “Define monitoring objectives and the initial scope of deployment”
- “An environmental assessment is needed to generate information required for the design of log collection and event management infrastructure, and accurate cost estimates from SIEM vendors”
- “An SIEM deployment that lacks effective incident response is, at best, a waste of resources and, at worst, a liability that documents the organization’s failure to act on clear signals of risk. Incident response processes need to be defined before production monitoring is implemented.” Remember, IR process before SIEM!
Get the notes and read them NOW, starting from the “Planning…” one!
Category: SIEM security Tags: security, security monitoring, SIEM
by Anton Chuvakin | December 16, 2011 | 2 Comments
PCI DSS and vulnerability scanning are maybe not brothers, but definitely close relatives. PCI DSS mandates that scanning actually happens on schedule, while vulnerability assessment helps find the holes that attackers may exploit to steal the card data. So, this post is a reminder about the topic in general as well as about the fact that PCI DSS 2.0 tweaked how vulnerability management should happen in particular.
First, internal scanning was – how should I put it? – lagging a bit across merchants. Yes, it was just as mandatory, but while merchants all had their ASV reports prepared for external scanning every quarter, the scans of actual card processing systems on the inside were not as aggressive (wait..did I just call a vulnerability scan once a quarter “aggressive”? Woe be onto me…). By the way, it is a really good idea to do “quarterly” scanning more often as it allows you to avoid surprises and gives you more time to fix, rescan and obtain a passing report.
Second, if periodic (i.e quarterly) scanning was performed, scanning after major network changes (yes, just as mandatory) was lagging even further behind. What is a major change? DSS does not go into details here, but one can use – gasp! – common sense for figuring this out: if new systems or new services were exposed to hostile networks, it was a major change for sure. If processing systems were moved around on the network, new ones deployed or network ACLs changes, it probably was as well (ask you QSA maybe?)
DSS 2.0 cleans up that language. Now Req 11.2.1 reminds that a merchant should “perform quarterly internal vulnerability scans”, while Req 11.2.3 reminds to “perform internal and external scans after any significant change.”
Third, and possibly most important: internal scans now also have at passing grade! In the past, external scans must have no vulnerabilities with CVSS base score above 4.0, but there was no standard for the internal scans. And now there is: “Review the scan reports and verify that the scan process includes rescans until passing results are obtained [A.C. – presumably this implies that they are using an ASV tool that has a pass/fail indicator], or all “High” vulnerabilities as defined in PCI DSS Requirement 6.2 are resolved.” (testing procedure 11.2.1.b)
By the way, I am hearing that some organizations use two different tools for internal and external PCI scanning. Do you think this is logical? All major vulnerability assessment vendors are ASVs now (with the sole exception working towards this goal) and so reasons for picking an ASV tool for external scanning and another for internal scanning seems like a recipe for a lot of data integration efforts, manual report correlation and other totally unnecessary analytics.
As a reminder, next quarter I will publish three exciting documents about vulnerability assessment and vulnerability management, each longer than the other two (no, not really 
)
Previous vulnerability management related posts are:
- On Scanning “New” Environments that covers scanning virtual, cloud, mobile and other unusual and emerging IT environments
- On Vulnerability Prioritization and Scoring that talks about prioritizing the vulnerabilities for remediation
- On LARGE Scale Vulnerability Management that asks a few useful questions about large deployments.
Category: PCI DSS security vulnerability management Tags: PCI compliance, PCI DSS, vulnerability assessment, vulnerability management
by Anton Chuvakin | November 16, 2011 | Comments Off
It is with great pleasure that I announce my first published Gartner research piece.
Ladies and gentlemen, please welcome “Maintaining PCI Compliance: Assess the Impact of Changes in Business, Technology, and PCI DSS”! It can be found in all its 47 page glory at http://www.gartner.com/resId=1849414 (subscription to Gartner IT1 required)
The abstract follows below:
“Merchants subject to Payment Card Industry Data Security Standard (PCI DSS) rules are often blindsided by DSS changes, arrival of new payment technologies, and newly emerging business context. In addition, many organizations still narrowly focus on annual PCI assessment and not on running an ongoing compliance program. A structured approach for dealing with such changes, involving relevant stakeholders, evaluating their impact, and planning controls to close the gap should be adopted by security teams. This will help make the security program resilient to environmental and PCI changes so that the organization can be secure and PCI compliant at any moment.”
Later, I will post a few highlights to up the level of awesomeness even more…. I’d also be doing a related webinar next week.
Category: PCI DSS announcement security Tags: PCI, PCI compliance, PCI DSS
by Anton Chuvakin | November 14, 2011 | 2 Comments
This is about “clouds”, so everybody must read it 
Specifically, this was inspired by this insightful LinkedIn discussion about large-scale vulnerability management where many notable VA/VM personalities chimed in (BTW, note the reference to “the egg laying milk-wool pig” there… if you have to). In this post, I wanted to share a few quick thoughts about vulnerability assessment IN the cloud and FOR the cloud – all inspired by that discussion.
First, do you HAVE TO have a SaaS (a particular case of cloud computing delivery as per S/P/I model) solution to perform large scale vulnerability scanning, say over 100,000 IPs on a regular basis? Probably not, as there are quite a few large scale vulnerability assessment tool deployments using traditional software or appliance (or virtual appliance) model. Some people think that managing and tuning their own scalable (… which is a big deal!) scanning infrastructure is too much work, while others won’t to trust anybody else to do it for them. Today market offers plenty of choices for either side of this debate, and I don’t feel that it is appropriate for us to take sides.
However, what seem to matter more than the form factor is whether the tool evolved in just such large environments. In other words, the theme that seems to emerge in my research is that vendor’s multiyear experience with successful scanning of large environments seem to matter more than the form factor (BTW, contrary to my initial opinion). For example, a well-designed and battle-hardened remote component management of your chosen VA software tool will make your distributed vulnerability assessment much less painful, even without dipping into the mystical power of The Cloud…
Second, it seems like vulnerability management FOR the cloud is going to be trickier than we thought. If “scan ban” – a prohibition from a public cloud provider to scan assets from outside of their network – is in effect, most currently popular assessment choices fall flat, especially for large cloud (IaaS, in this case) asset populations. I am sorry, but people who say that “we just scan those public cloud assets like nothing changed” are not thinking of thousands of transient systems spread across multiple providers, managed by different teams, shielded by a lot of unknown ACLs, etc. Cloud is NOT co-location circa 2011!!
What are possible solutions that will be needed in the next 2-3 years? It sure seems like the scanning agents will make a come back. They will likely be joined by their “younger brothers” – transient or dissolvable agents. In-cloud scanner instances will likely be utilized as well, scanning only the cloud assets in their immediate vicinity. Who knows, maybe even passive scanning will come handy. On top of this, security assessment using various cloud provider APIs the likely become a reality as well; think of this as scanning offline virtual machine images, but inside the IaaS. My guess is that there will be no single standard way of doing it for the foreseeable future. Now, I plan to cover these and other fun issues in my upcoming report on vulnerability assessment technology, to come out in Q1 2012. And if I say more here, I feel I’d run afoul of our freshly updated policy, so I’d stop here
Previous vulnerability management related posts are:
- On Scanning “New” Environments that covers scanning virtual, cloud, mobile and other unusual and emerging IT environments
- On Vulnerability Prioritization and Scoring that talks about prioritizing the vulnerabilities for remediation
- On LARGE Scale Vulnerability Management that asks a few useful questions about large deployments.
Category: security vulnerability management Tags: security, vulnerability assessment, vulnerability management
