Ramon Krikken
BG Analyst
2 years at Gartner
15 years IT industry
Ramon Krikken is an analyst in the Gartner IT1 Security and Risk Management Strategies team. He covers software/application security; service-oriented architecture (SOA) security; structured and unstructured data security management, including data masking, redaction and tokenization...Read Full Bio
by Ramon Krikken | May 22, 2012 | Submit a Comment
This is a sister post to Anton Chuvakin’s “Our SIEM Futures Paper Publishes!” from yesterday. We collaborated on a “Security Information and Event Management Futures” note [subscription required], in which we discuss how we believe the technology will evolve in response to current and expected trends. Although Anton is now the primary GTP analyst to cover SIEM, I still have a strong interest because its place in the greater monitoring and security data analysis space.
If you look at the table of contents, you will notice the first of our “big 5 trends” relates to context data. As I’ve written in the past, context comes in several forms – some of it can be automatically derived or created by IT systems, while some of it has to be provided by humans (i.e., where humans have to “teach” the system what the meaning of certain context is). State data (e.g., the location of a person as derived from a physical access control system) is context, and events themselves can be context, too. Context is vital, because without it we would end up drowning in false positives and false negatives.
Right now, most SIEM treat context (and especially state data) differently from events. They are able to pull in state data as context for events, but performing analysis on the state data itself can be incredibly challenging. Using SIEM for multi-dimensional analytics over events and state turns out to be well-nigh impossible … as some customers-that-must-go-unnamed have explained to me in light of using SIEM for “non-traditional” use cases. This needs to change.
Although I still have reservations about “big data analytics for security” (mostly because it will for the foreseeable future be difficult to separate the wheat from the chaff in vendor claims and solutions), I do believe the need for better data processing and analytics is getting greater. Whether this is general SIEM evolution, a split in the SIEM market, or an entirely new class of technology parallel to top-tier SIEM remains to be seen. And, perhaps more importantly, how well this can be commoditized (i.e., have low requirements for involvement of data analysts and such) is a big question mark for me.
Category: Security Tags: big data analytics, data analytics, event management, log management, security analytics, security information and event management, siem
by Ramon Krikken | May 17, 2012 | 2 Comments
A well-known security meme is that “encryption is easy, it’s key management that’s hard.” But while this may be true for certain encryption use cases, it’s most definitely not true across the board. It’s a convenient meme for vendors, of course, who’ll simply point at a “we use AES” or “we’re FIPS 140-2 validated” statement and call it good. But for the end user this nothing short of unhelpful.
Understanding cryptography is hard, and validating a system where the core crypto is only one small part of a large, critical system is even harder. One of the largest problems in my opinion is the scope of FIPS 140-2. First off, the lowest level (1) doesn’t mean much in terms of how well the crypto system is implemented. But furthermore, it creates validation only for part of the entire solution. As an example, see a 2010 incident where FIPS 140-2 level 2 validated USB flash drives were compromised completely.
To get a better handle on crypto, current customers might review the just-updated “Understanding and Evaluating Cryptographic Systems: An Information Security Foundation” [subscription required] for a more complete picture. The evaluation includes algorithms, protocols, key generation, but also – very important – the overall system itself:
Proper design and implementation of cryptography are challenging, even when secure algorithms and protocols are used. Misapplied or incorrect hardware, software and architecture can all reduce or negate cryptographic security.
in the end, the strength of the system is just one piece of the puzzle. A more fundamental problem, and one that needs to be addressed before the crypto system evaluation starts is that the power of encryption is grossly overestimated. And I will address that in a series future posts.
Category: Uncategorized Tags: cryptography, encryption, FIPS 140, keys, NIST
by Ramon Krikken | May 14, 2012 | Submit a Comment
In our recent customer-facing research project on mobile application development, security was a smaller but important consideration for many participants.
When I read through a recent “this is what developing for Android looks like” blog post on the effects of Android fragmentation, I got inspired to write a quick piece on the platform. The open playground versus the walled garden approaches of the Android and Apple platforms, respectively, definitely play into how security can and must be designed.
One aspect of open versus closed is the ability to control and change what you have. Avoiding vendor lock-in and heavy-handed vendor or carrier control (which in the consumer space often is often related to digital media) can be beneficial to security in the enterprise environment. On the open grounds those with the time and effort could create their own secure operating system specification, and those with less time can simply pick a few useful security components and add them on. To do so in a walled garden can be very difficult, if not impossible, and enterprises sure have a few complaints about controlling applications and data on the Apple platform here.
But notwithstanding a desire to maintain consumer choice and easily implement controls, it’s unavoidable to acknowledge that the walled garden can be very helpful for implementing security in B2E environments. If the endpoint is to handle sensitive data, we need a certain amount of control over the hardware and/or the operating system. This allows us to support or add on security features without the user having the ability to modify or remove them. The open Android model therefore definitely worries some enterprises when it concerns BYOD.
Neither platform is ideal for B2E – particularly for BYOD, where neither Android nor Apple have the best support for enterprise B2E application and data security requirements. In fact, right now both open and walled models have specific benefits that are appealing. But a variety of security and non-security factors sure do seem to drive organizations in the direction of favoring the walled garden, for better or for worse.
Category: Uncategorized Tags:
by Ramon Krikken | May 10, 2012 | 2 Comments
It doesn’t take a clairvoyant – or in this case, an research analyst – to see that “big data” is becoming (if it isn’t already, perhaps) a major buzzword in security circles. Not only big data as applied to security, but also security for big data. But what does “securing big data” actually mean?
Not too long ago I wrote a post about renaming DAM to DAP, and published a fairly large report about current DAP capabilities [subscription required]. In the report, I note that:
But database security for other types of databases, such as non-relational data stores that are increasingly important in the age of big data and cloud, mostly goes uncovered.
Note that I specifically focus on the platforms used to store and process the data, not the data itself. We have to distinguish those two, just as we distinguish document formats from the contents stored in a document. Yes, platform capabilities are important, but they don’t capture the full breadth of security concerns with – as we define it – data that is high in volume, velocity, and variety. In an environment that is all about really putting data to use, how do you design the right controls?
Or more precisely, what exactly we will need to do about this at the technology level – i.e., which technical controls make sense given specific exposure and threats to this information (not all of which result from [lack of] capabilities in the platform)? The latter part of that question requires more effort than just throwing “the usual” security solutions that have simply been re-badged with a “big data” label. Technical controls are no substitute for good understanding of data and its use.
Don’t get me wrong, I do believe several vendors will create very useful solutions – and some will be extensions of traditional products. So although I don’t believe the need for securing big data is a fad, the impending storm of marketing slogans around securing big data (and its possible ramification of leading to ineffective control designs) may well make it feel like one.
Much of the “securing big data” will need to be handled by understanding the data and its usage patterns – lest we repeat the “grant all” stance used in many RDBMSs instances. In other words, know your data to know your controls.
Category: Security Tags: big data, big data security, DAP, data management, Database Security, fad
by Ramon Krikken | May 7, 2012 | Comments Off
We’ve just finished parsing 1.5K data points in a customer-facing research project on mobile applications. We spoke mostly with development team members, but also had a few architects and other functions represented (we even had a person from a marketing team in the mix). The data is very rich, and we’ve spent considerable time deriving our insights and conclusions.
It wasn’t on security in particular, but we did talk to pretty much every customer about that topic. In most cases it was actually the customer that raised the issue, which makes me happy because that means it’s certainly on people’s minds. But on the not-so-good side, many participants were still investigating how to best provide security on and for mobile applications. That should be no surprise, though: many moving parts, several different platforms, and a mix of application and data types does not make things easy.
I haven’t quite finalized the advice yet, but I think the combination of security for the development process, the application infrastructure, and the applications themselves will provide us with plenty to write about. But one thing that is apparent to me at this point (and perhaps this is no surprise either) is the following:
- Pay attention to web services (particularly RESTful services), and how they can be secured!
Yes, the client side is extremely important (and I’ll definitely cover that in future posts). But especially with lots of customers looking at B2E, building and securing services the right way is going to be critical. Some existing technologies may be reusable. The foundations – especially standards – should be re-examined to make sure they’re sound. If you are a Gartner customer looking for advice on this I’d of course be happy to discuss this on a call even before our notes publish.
And for those interested in how we did the research, check out this recent blog post by my colleague Danny Brian. If you like user-centrism you’ll certainly appreciate our process.
Category: Applications Cloud Security Tags: mobile, mobile applications, rest, security, services, soa, web services
by Ramon Krikken | May 3, 2012 | 1 Comment
We’re always trying to get closer to developing more useful security metrics, and examining analogies provides a way to relate these measurements and metrics to things we already know (and that we perceive as being done and measured well). I like good analogies, but I don’t want to be limited by not-so-good ones.
“Flying an airplane” is one such analogy (it is used in various books, articles, discussions, etc.) The idea is that keeping systems up and running is operationally similar to flying an airplane: the gauges and indicators help pilots to safely fly. Similarly, SIEM, AV, IDS, and other security controls provide ways for IT to keep an eye on their systems. But I’m concerned the analogy misses some important consideration:
- Preventing airplanes from crashing due to pilot error or mechanical failure is different from protecting it from intentional acts to crash it. This is much like “oil changes” don’t covering predictions related to people pouring sugar in the fuel tank (which extends to random failures and intentional attack differences in IT).
- Preventing airplanes from crashing is not just related to flying – it’s also related to building airplanes correctly, and to maintaining them the right way. Likewise, running IT systems is only a piece of “doing” IT, where the security is built in and then maintained.
- Preventing airplanes from crashing is also not done in isolation: there are many, many airplanes in the sky at any moment. The complexity of IT systems (which are systems of systems) also does not lend itself to an isolated analysis.
- But most importantly, preventing airplanes from crashing is a small operational aspect of something larger. Airplanes, after all, do not exist just to fly. They exist to transport people and things from point A to point B. This is just like IT systems not existing just to run, but to support a business (process).
So I would argue that what we’re really trying to do is “run the airline.” What do you think?
Category: Security Tags: airlines, airplanes, analogies, attacks, av, business process, hackers, ids, risk, security metrics, siem
by Ramon Krikken | April 27, 2012 | Comments Off
It must be Friday, because it’s definitely FUD-filled! Hide your valuables, because the VMWare ESX code leak is sure to cause IT systems to go dark around the world (and thus your alarm company’s systems too, I’m sure).
OK, so enough with the hyperbole. Let’s be fair: it’s certainly possible that source code availability will allow surfacing some new problems. And they could even be quite severe. But given the circumstances, how more likely is it to happen with source code than without?
For one, the binary code for ESX is available for analysis already. People find flaws a plenty in COTS without ever laying eyes on the source code. But in addition, the source code is available for analysis to third parties (as evidenced by the code being stolen not from VMWare, but from someone else). Surely some of them have laid eyes (or, more likely, run tools) on the code itself.
So when I see quotes like “If even more code gets published, that act at least partially takes away an advantage that VMware has enjoyed over the open source code hypervisor competition. Both Xen and KVM source code were published for everyone to see,” I sure do wonder if it matters all that much.
But that’s exactly the point – although we might guess, we don’t yet know. And because of how VMWare handles its code with respect to distribution to third parties, I think it could make for some excellent data points around the “many eyes principle.” In other words, with more and differently motivated (or skilled?) eyes on the source code, what would we see pop up?
Perhaps we’ll even find evidence of a government back door, who knows!
Update: when I wrote the post it wasn’t clear to me whether CEIEC had a legitimate copy of the VMWare source. From comments by the hacker it appears now they might not. How this changes the type and number of eyes is something worth digging into.
Category: Cloud Security Tags: cots, hypervisor, KVM, many eyes principle, open source software, oss, security, VMware, WMware ESX, XEN
by Ramon Krikken | April 25, 2012 | Comments Off
Security at the application-layer is getting ever more attention due to the large number of vulnerabilities that keep popping up in off-the-shelf and home-built software (although, in my opinion, it is still not getting enough attention). Aside from expanding security activities in the SDLC, we’re seeing calls for – amongst things – application monitoring. But what does “application” mean in these cases?
When I look at various application security efforts, though, it seems security coverage for the application platform (the middleware, if you will) and databases (or data repositories) is hit-or-miss. The same is true for infrastructure-focused security coverage. So whose responsibility is it? What bucket do these fall into? Consider that:
- Systems and network teams generally consider middleware and databases to be part of the application layer
- Application teams generally consider middleware and databases to be part of the infrastructure
And it is not just middleware and databases. Just ask IT teams who should, for example, own and manage a web application firewall. Or ask whether monitoring administrative users in business applications is an element of “privileged user monitoring.” The answers are certainly not always clear-cut.
I don’t have a perfect answer either – splitting the world into the tiniest of buckets isn’t necessarily helpful. But coarse-grained buckets with no agreement on what goes where isn’t either. Let’s just remember that differences in perspective must be acknowledged and dealt with, or control gaps will eventually form.
Category: Applications Security Tags: application security, Database Security, middleware security
by Ramon Krikken | April 23, 2012 | Comments Off
I’m hoping you can all make it out to San Diego at the end of August this year. We’re planning to have another great Catalyst conference, featuring not only our Gartner for Technical Professionals analysts and content, but also a good number of awesome external speakers, too!
Different from previous years, though, we won’t have dedicated security tracks. Rather, we’re organizing all our talks around three major themes:
- Mobility
- IT as a Broker: Clouds and Services
- Information Everywhere
Not to worry, we have security & risk and identity & privacy content in all three areas. In fact, we have a great deal of security content throughout. A sneak peek at the agenda reveals topics such as:
- Mobile application security architecture
- Mobile platform security and controls
- Security monitoring in the cloud
- Security intelligence and shared intelligence
- Information sprawl research results
- Encryption and data masking (in general, and for cloud)
- Content-aware controls
Many of these topics have multiple talks, so as you can see there’s a lot for the security-minded. For those more interested in identity, Ian Glazer posted some more information in an earlier blog post. Also keep an eye on the Catalyst 2012 site for more information.
Category: Uncategorized Tags: big data, cat12, catalyst, cloud, mobility, nexus, security, social media
by Ramon Krikken | April 19, 2012 | Comments Off
We’re always working on updating our software security / application security coverage, and the time has come to spend a few months on gathering new information for the application security program guidance document. To make it more than “here’s another general maturity model – do everything it says,” I’m looking for what makes and breaks the program in practice. And in particular, I’m looking for anecdotes and data in the area of developer training, which is somewhat of an opaque area for me. To wit, consider if and how the following relates to developer training:
“teach a man how to fish, and he may still end up starving the whole family.”
In other words, what exactly should developers be trained on?
I’ve asked a quite a few people for data. Data that shows how training improves software security quality. And I’ve come up empty-handed. I realize it’s hard to measure. Ideally we’d have a controlled study to gather some data, but such studies can be hard to pull off.
I know some of the more mature software security teams / programs do measure this in various ways. If you have some data to share, please do let me know in comments or via email! (and I’ll keep it in strictest confidence when requested, of course). You can reach me at first.last@gartner.com
Related: if you’re going to be at the 2012 U.S. Security Summit, stop by at my session “The Art of Saying Yes - Selling Application Security To Developers and Architects” on Tuesday (in the Business of IT Security track). We’re also featuring many other Technical Insights sessions by my GTP colleagues in the other tracks.
Category: Security Tags: application security, developer training, security, security summit, security training, software security
