Research

Those of you who have followed Securosis for a while know that our Quant research is the big daddy of all our projects. We build a very granular process map for a certain function, build a metrics model, and in some cases survey our community to figure out what they do and what they don’t. We have already tackled Patch Management, Network Security Operations, and Database Security Options. Our latest Quant study tackled Malware Analysis. Here’s an excerpt from the Introduction to provide some context: It has been clear for a while that today’s anti-malware defenses basically don’t work, and as a result way too much malware makes it through your defenses. When you get an infection you start a process to figure out what happened. First you figure out what the attack is, how it works, how to stop it (or work around it), and how far it has spread within your organization. That’s all before you can even think about fixing it. To the best of our knowledge, no one has built a specific process map for what this looks like, or a model for figuring out how much it costs to deal with malware on an operational basis. We built the process map and cost model to help folks understand the true impact of malware attacks. It’s not pretty, and many folks, I’m sure, would rather not know. But this research is for those who want to understand malware analysis. You can see from the process map below that this isn’t a process for the faint of heart, and that’s why most organizations fail in their malware defense efforts. B many organizations do a fair job of fighting malware because they take a very structured and analytical approach to understanding attacks, isolating attack vectors, finding already compromised devices, and updating controls to prevent reinfection. Check out the full report and the accompanying metrics model (.xlsx). As you read this report it is worth keeping the Quant philosophy in mind: the high level process framework is intended to cover all the tasks involved, but that doesn’t mean you need to do everything. Individual organizations pick and choose the appropriate steps for them. This exhaustive model can help you understand the operational processes of analyzing malware. We would like to thank Sourcefire for sponsoring the research, and all the folks who took a few minutes to fill out the survey. And finally, if you are interested in the blog posts that iteratively built up the series, check out the Malware Analysis Quant Index of Posts. Share:

If you are interested in discussing use cases and deployment models for Tokenization, you’re in luck! This Thursday (June 14th) at 1pm Eastern, I will be offering a webcast on Tokenization with Intel & McAfee. While many people are looking for scope reduction, reduced audit costs, and simplified security controls for PCI, that does not mean there is only one way to roll out a Tokenization system. There are several options, each with its own advantages, and the best fit depends entirely on your particular goals and how you manage your IT systems. In this webcast I will provide an overview of the three main deployment models and delve into the reasons customers choose each of them. If you are interested you can join us for free by registering: 3 Core Tokenization Models – Choosing the Right PCI DSS Strategy. As always, we will leave time for Q&A at the end. Share:

As we mentioned in the first post of the Evolving Endpoint Malware Detection series, Control Lost, attackers have gotten rather advanced. They don’t use the same file or malware delivery vehicle twice, constantly morph attacks, and make it very hard to use the fundamental file-based detection which underpins traditional anti-malware tools. So efforts to detect malware can no longer focus exclusively on what the malware looks like (basically a file hash or some other identifying factor) and must incorporate a number of new data sources for identification. These new sources include what it does, how it gets there, and who sent it; combined with traditional file analysis they enable you to improve accuracy and reduce false positives. No, we don’t claim there is no place for traditional anti-malware (signature matching) anymore. First of all, compliance continues to mandate AV, so unless you are one of the lucky few without regulatory oversight, you don’t have a choice. But more pragmatically, not all attacks are ‘advanced’. Many use known malware kits, leveraging known bad files. Existing malware engines do a good job of identifying files they have already seen, so there is no reason to ever let a recognizable bad file execute on your device – certainly not to confirm it’s bad. But obviously the old tactics of detecting malware aren’t getting it done. So these additional data sources provide additional information to pinpoint good and bad code more accurately, and the most promising is behavioral analysis. The good news is that the industry has made a tremendous research investment in profiling the kinds of behavior which indicating attacks, and in building detection tools to look for those kinds of behavioral indicators in real time as code executes on devices. We will cover these behavioral indicators in this post, and get to the other data sources later in the series. Profiling Behaviors When we say “malware profile”, what are we talking about? That depends on what you are trying to accomplish. One use for profiles is malware analysis, described in depth by Malware Analysis Quant. In this case the goal is to understand what the malware looks like and does, in detail. You can then use the profile to find other devices which have been compromised. Another use case leverages profiles of typical malware actions to detect an attack on a device before infection. This is all about figuring out what the malware does and when, and then using that information to stop it before it does damage. Several things are useful to know for detection: Registry settings Processes/services Injected code New executables Domains/protocols Network communication targets (C&C) Mandiant’s term, Indicators of Compromise, sums it up pretty well. Basically, if the malware injects malicious code into a standard operating systems file (such as winlogon.exe or services.exe in Windows), perhaps adds certain registry keys to a Windows device to ensure persistence, contacts particular external servers that distribute malware, or even uses an encrypted protocol (presumably command and control traffic), you have useful evidence that executable is malicious and can block it. Finite Ways to Die Malware profiles are terrific if you can capture a sample of the malware and run it through a battery of static and dynamic analyses to really figure out what it does – as documented in Malware Analysis Quant. But what happens if you can’t get the malware? Do you just wait until your devices have been owned to develop a profile? That sounds a lot like the reactive approach the industry has relied on for years – to disastrous effect. You need a list of generic behaviors that indicate malicious activity, and to use it as a early warning system indicating possible attacks. Of course, purely relying on specific behaviors can result in false positives – because injecting code and changing registry settings can be legitimate actions, such as when patching. You probably learned that lesson the hard way when using host intrusion prevention technologies (HIPS) years ago. So you need to use behavioral indicators for first-level alerting, and then additional analysis to figure out whether you are really under attack. This process is akin to receiving an alert from your SIEM. You cannot assume a SIEM alert represents an attack, but it provides a place to start investigation. A skilled analyst examines the alert and validates or dismisses the attack, as documented in Network Security Operations Quant. How does the analyst determine whether the attack is real? By applying their experience to understand the alert’s context. But on a typical endpoint or server device, you don’t have a skilled human analyst to wade through all the potential alerts. So you need a tool which can apply sufficient context to determine what is an attack and what is not – determining what to block and what to allow. Obviously this kind of black magic demands much deeper discussion, to get a feel for how it really works (and, more importantly, to figure out whether a vendor really manages to pull it off, as you evaluate offerings), so we will consider the details next in this series. Typical Behavioral Indicators To provide an idea of what kinds of behavioral indicators you should be looking for, here are some typical indicators employed by malware: Memory corruption/injection/buffer overflow: The old standard of compromising devices is to alter the “execution flow of a program by submitting crafted input to the application.” That’s not our definition – it comes from Haroon Meer’s 2010 paper (PDF) documenting the history of memory attacks. If you aren’t familiar with this attack vector, the paper provides a great primer. Suffice it to say that memory corruption is alive and well, and any behavioral detection approach must watch for these attacks. System file/configuration/registry changes: Normal executables rarely update registry, configuration, or system file settings; so any activity of this sort warrants investigation. Parent/child process inconsistencies: Some processes and executables should always be launched by specific processes and executables. If these relationships are violated, that might indicate malware. Droppers

For whatever reason, I picked up a copy of a magazine my wife received as part of her interior design study work. I was absent-mindedly thumbing through it, waiting for the microwave to heat my coffee, when suddenly one of the the pictures made me stop and pay attention. It was a picture of a woman in a red leather catsuit, posed seductively by a stove. WTF? What is this ad trying to tell me? I must really not be part of their target market – but who is their target market? And another picture, this time a woman on top of a Mercedes, wearing a showgirl costume with lots of makeup. And then a woman with several ‘handymen’ fixing stuff around the house. And so on. Now, I bought a fancy Miele dishwasher, but I didn’t notice my wife responding with a racy outfit. In fact I’m pretty sure “sexy” and “kitchen appliance” are at opposite ends of her universe. I dug a bit deeper, and saw that the articles were on with topics such as: how to keep your junk drawer organized, and the best way to store linen napkins and flatware. I dove into the pile of magazines: Architectural Digest. Cote Sud. English Country Living. They are filled with the same type of content, regardless of country. All I could think was, “Who are they selling this stuff to, exactly?” So I asked my wife. She answered, “It’s all fantasy. They selling women a fantasy about a lifestyle or a way of living they don’t currently have. In some cases it’s what they aspire to, in other cases it’s like a virtual dollhouse. And if people feel they need to go there, they ought to buy a doll house first – have you seen the prices on that stuff?” I looked a little taken aback, so my wife added “Your magazines are the same, that stereo porn you read. It’s all a fantasy.” I say “Nuh-uh. That’s all … wait a minute.” Was she right? I leafed through a couple copies of Stereophile and TAS. Yeah, there are some similarities, posing products in the home. And what the hell is that woman doing on the sofa next to those speakers? I look at some of the home theater trade rags, and now I think she’s got me. Oh, man, I feel silly. Looking for an exception to the rule she’s just thrown down, I think “Ah-ha!” – that can’t be true for business and technology! I go to the land where old technology magazines go to die: the guest bathroom. There must be some old copies of CIO or NetworkWorld, or some such nonsense from way back in 2008 to counter her argument. “My kingdom for a copy of Red Herring!”, and then I found several old magazines. Surely IT can’t be selling fantasy!?! But holy crap, there it was: Cartoons of Microsoft users brandishing swords and holding shields, teaming up to slay mythical IT problems as if they were in some Tolkienesque adventure. The ads show paperless offices, consumer personalization, private clouds, and great ideas that spawn success. User-friendly. Cost-effective. Interactive. Proactive! And then it happened: an ad spoke to me. A Citrix advertisement with a giant hand crushing servers. I must admit I have had that fantasy several times! When pulling an all-nighter in an over-chilled data center because some effing patch wouldn’t apply properly, I would have loved nothing better than to throw that machine out the third-floor data center window. So it was true – it’s all fantasy, and vendors are selling a dream. Even in technology and security, where I thought we were more grounded. With the slow death of print media, websites are not quite as in-your-face about it, but it’s still there. Granted, my experiences never included happy twenty-something models with trendy clothes, all smiling at each other like they just got laid. It was old T-shirts, yesterday’s unshaven faces, and lots of empty diet Pepsi cans in a sea of fast food wrappers. IT technology articles are just as driven by fantasy indulgence as English Country Living, and compared to real everyday lives they are just as absurd. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian’s 15 Ways to Get More From Log Files, at Dark Reading. Mike quoted on the “Renaissance Information Security Professional”. Favorite Securosis Posts Adrian Lane: Understanding Data Encryption Systems. This is a very simple way to visualize encryption & key management deployments. Other Securosis Posts Incite 6/6/2012: Universally Awesome. Understanding and Selecting Data Masking: Technical Architecture. Friday Summary: June 1, 2012. Favorite Outside Posts Adrian: Jamming Tripoli: Inside Moammar Gadhafi’s Secret Surveillance Network. Long but very interesting article about Internet surveillance. And the sales pitch for surveillance products to the Libyan Government cracked me up – something about “the constant struggle against criminals and terrorism”. Our own Chris Pepper pointed out that it all “sounded unpleasantly familiar.” Ask yourself again why privacy protections are not built into every email tool? Because they would make it very difficult to collect intelligence and monitor rivals – in every country, not just Libya. Rich Mogull: Rob Graham’s Confirmed: LinkedIn 6mil password dump is real. Solid analysis. Project Quant Posts Malware Analysis Quant: Index of Posts. Malware Analysis Quant: Metrics – Monitor for Reinfection. Malware Analysis Quant: Metrics – Remediate. Malware Analysis Quant: Metrics – Find Infected Devices. Malware Analysis Quant: Metrics – Define Rules and Search Queries. Malware Analysis Quant: Metrics – The Malware Profile. Research Reports and Presentations Report: Understanding and Selecting a Database Security Platform. Vulnerability Management Evolution: From Tactical Scanner to Strategic Platform. Watching the Watchers: Guarding the Keys to the Kingdom. Network-Based Malware Detection: Filling the Gaps of AV. Tokenization Guidance Analysis: Jan 2012. Applied Network Security Analysis: Moving from Data to Information. Tokenization Guidance. Top News and Posts Crypto breakthrough shows Flame was designed by world-class scientists. Hiding Android Malware. MD5 password scrambler ‘no longer safe’. IE 10’s ‘Do-Not-Track’

With all the vacation I have planned this summer, finding time for work may be a challenge. We had 4 days at home after the Barcelona trip and then headed down to Orlando where the girls’ dance troupe did a performance at Downtown Disney. Yup, a 7-hour drive, a pair of 3-day Park Hopper tickets (which we didn’t use), costumes, hotel, and meals, so we could see the girls dance for less than 30 minutes – melting in 90+ degree weather. And it was worth every penny. They love to perform and we love to watch them. The owner of their dance studio always does a nice job with the choreography and getting all the age groups involved. Thankfully for my wallet’s sake, the Disney trip only happens every two years, so I get a 24-month respite from Orlando in June. But it wasn’t all dance all the time. On Monday we did the Universal theme parks, where the highlight was the Harry Potter attraction in Islands of Adventure. XX1 is a huge Potter fan and she has been looking forward to touring Hogsmeade since the park opened – right after the last time she performed in Orlando. Touring Hogwarts was great and checking out the shops provided a few hours of fun as well. Even better, we survived the trip without buying wands, though we did bring home some of the famous Bertie Bott’s Every-Flavour Beans. Amazingly enough, I wasn’t keen on trying the rotten egg flavor. Go figure. I also got my bi-annual dose of roller coasters. And then some. We went to the park with a group of folks on the dance trip, and a few were fans of the coasters. So I had some running buddies. Normally the Boss allows me to peel away from herding the kids to jump on one coaster. But with a lot of help around and with some of the kids old enough to ride the coasters themselves, I had a lot more flexibility to ride away. I did the Hulk Coaster twice. There is nothing like the feel of being shot out of a cannon. I rode the Dragon Challenge as well, where your feet dangle to provide a different feel. But the highlight of the day was the Rockit with XX2, who was on her first real roller coaster. She wasn’t tall enough to ride the other rides and just made the requirement on this one. The kind folks at Universal gave us a VIP pass (because she was so excited when she passed the height requirement), so we scooted to the front of the line and jumped into the front row. It isn’t just an ordinary roller coaster. You ascend 167 feet vertically (literally), and then the fun begins. XX2 is a real daredevil – she not only wasn’t scared, but she lifted her hands as we descended through the first drop. By the way, I was holding on for dear life. She was so excited, I’m just glad I was able to share that experience with her. We also dragged the other kids (kicking and screaming) on a less intense ride, and they seemed to enjoy it. I explained to my kids that for me, roller coasters represent the fear that can paralyze many folks in every aspect of their lives. Too many folks don’t try things or take risks or live their life to the fullest because they are scared. The only way to overcome that fear is to face it and realize it all works out. I have come to enjoy the anticipation of the experience, the adrenaline surge as you climb the hill, the trust needed to let go and just enjoy, and finally the feeling of accomplishment as the ride comes to a grinding halt at the end. Not to be too melodramatic, but roller coasters kind of reset my worldview when I was a kid. My Dad forced me to go on the Comet at Hershey Park when I was about 10 or 11. I didn’t want to go. I was scared. And every time I strap into a roller coaster I remember that day. I remember overcoming self-imposed limitations of what I can do and what was safe. XX2 needs no convincing to do anything. She came out of the womb fearless. The other two need a bit more coaxing, and I can only hope that 30 years from now they thank me for forcing them out of their comfort zones. –Mike Photo credits: “Life is a roller coaster…. you have your ups and downs unless you fall off” ~ Happy FRISKY Friday ~ originally uploaded by turtlemom4bacon Heavy Research We are back at work on a variety of blog series, so here is a list of the research currently under way. Remember you can get our Heavy Feed via RSS, where you can see all our content in its unabridged glory. And you can get all our research papers too. Understanding and Selecting Data Masking Technical Architecture How It Works Pragmatic Key Management Understanding Data Encryption Systems Introduction Evolving Endpoint Malware Detection Control Lost Understanding and Selecting a Database Security Platform Final Paper Available Incite 4 U The weakness of account recovery: We got another stark reminder that it’s not if, but when you get popped, this week. CloudFlare’s CEO lost control of his email when attackers reset his password. But Prince says passwords are at least 20 characters, random, and not used on other services. So how did they get his account? Leave it to Krebs to figure out what really happened. The attackers gamed the account recovery process at Google (where he had both personal and corporate email) by tricking AT&T into forwarding his voicemail to a different account. It’s a pretty complicated hack, but if you use Gmail (or Google apps) for email, their 2-step verification is a must. Just remember that, depending on your phone, taking advantage of their SMS backup system might be as simple

Today we will discuss platform architectures and deployment models. Before I jump into the architectural models, it’s worth mentioning that these architectures are designed in response to how enterprises use data. Data is valuable because we use it to support business functions. Data has value in use. The more places we can leverage data to make decisions, the more valuable it is. However, as we have seen over the last decade, data propagation carries many risks. Masking architectures are designed to fit within existing data management frameworks and mitigate risks to information without sacrificing usefulness. In essence we are inserting controls into existing processes, using masking as a guardian, to identify risks and protect data as it migrates through the enterprise applications that automate business processes. As I mentioned in the introduction, we have come a long way from masking as nothing more than a set of scripts run by an admin or database administrator. Back then you connected directly to a database, or ran scripts from the console, and manually moved files around. Today’s platforms proactively discover sensitive data and manage policies centrally, handling security and data distribution across dozens of different types of information management systems, automatically generating masked data as needed for different audiences. Masking products can stand alone, serving disparate data management systems simultaneously, or be embedded as a core function of a dedicated data management service. Base Architecture Single Server/Appliance: A single appliance or software installation that performs static ‘ETL’ data masking services. The server is wholly self-contained – performing all extraction, masking, and loading from a single location. This model is typically used in small and mid-sized enterprises. It can scale geographically, with independent servers in regional offices to handle masking functions, usually in response to specific regional regulatory requirements. Distributed: This option consists of a central management server with remote agents/plug-ins/appliances that perform discovery and masking functions. The central server distributes masking rules, directs endpoint functionality, catalogs locations and nature of sensitive data, and tracks masked data sets. Remote agents periodically receive updates with new masking rules from the central server, and report back sensitive data that has been discovered, along with the results of masking jobs. Scaling is by pushing processing load out to the endpoints. Centralized Architecture: Multiple masking servers, centrally located and managed by a single management server, are used primarily for production and management of masked data for multiple test and analytics systems. Proxy/Bridge Cluster: One or more appliances or agents that dynamically mask streamed content, typically deployed in front of relational databases, to provide proxy-based data masking. This model is used for real-time masking of non-static data, such as database queries or loading into NoSQL databases. Multiple appliances provide scalability and failover capabilities. This may or may not be used in a two-tier architecture. Appliances, software, and virtual appliance options are all available. But unlike most security products, where appliances dominate the market, masking vendors generally deliver their products as software. Windows, Linux, and UNIX support is all common, as is support for many types of files and relational databases. Support for virtual appliance deployment is common among the larger vendors but not universal, so inquire about availability if that is key to your IT service model. A key masking evolution is the ability to apply masking policies across different data management systems (file management, databases, document management, etc.) regardless of platform type (Windows vs. Linux vs. …). Modern masking platforms are essentially data management systems, with policies set at a central location and applied to multiple systems through direct connection or remote agent software. As data is collected and moved from point A to point B, one or more data masks are applied to one or more ‘columns’ of the data. Deployment and Endpoint Options While masking architecture is conceptually simple, there are many different deployment options, each particularly suited to protecting one or more data management systems. And given masking technologies must work on static data copies, live database repositories, and dynamically generated data (streaming data feeds, application generated content, ad hoc data queries, etc.), a wide variety of deployment options are available to accommodate the different data management environments. Most companies deploy centralized masking servers to produce safe test and analytics data, but vendors offer the flexibility to embed masking directly into other applications and environments where large-footprint masking installations or appliances are unsuitable. The following is a sample of the common deployments used for remote data collection and processing. Agents: Agents are software components installed on a server, usually the same server that hosts the data management application. Agents have the option of being as simple or advanced as the masking vendor cares to make them. They can be nothing more than a data collector, sending data back to a remote masking server for processing, or might provide masking as data is collected. In the latter case, the agent masks data as it is received, either completely in memory or from a temporary file. Agents can be managed remotely by a masking server or directly by the data management application, effectively extending data management and collaboration system capabilities (e.g., MS SharePoint, SAP). One of the advantages of using agents at the endpoint rather than in-database stored procedures – which we will describe in a moment – is that all traces of unmasked data can be destroyed. Either by masking in ‘ephemeral’ memory, or by ensuring temporary files are overwritten, sensitive data is not leaked through temporary storage. Agents do consume local processor, memory, and storage – a significant issue for legacy platforms – but only a minor consideration for virtual machines and cloud deployments. Web Server Plug-ins: Technically a form of agent, these plug-ins are installed as web application services, as part of an Apache/web application stack used to support the local application which manages data. Plug-ins are an efficient way to transparently implement masking within existing application environments, acting on the data stream before it reaches the application or extending the application’s functionality

It’s the first of June, and I’m sure most of you are thinking about vacation, if not actually on vacation at this point. I’m here holding down the fort while the rest of Securosis is visiting places cooler and more fun. I’m taking time to reflect on security topics and my research agenda. I have been mulling over the topic of IT buying security products for the sake of security. Sounds irrational, right? We have known for years that people only buy security products to help satisfy compliance requirements, and then only grudgingly, to meet the minimum requirements. But people buying security to help secure things keeps popping up here and there, and I have been waiting for better evidence before blogging about it. Just before the RSA conference I decided to bring it up in an internal meeting, and the conversation went a bit like this: Me: “I think I should mention buying security for the sake of security as a trend.” Partner #1: “Why?” Me: “The number of security driven inquiries has doubled.” Partner #1: “Twice nothing is nothing. Move on.” Me: “Agreed, but twice 3-5% is something to take notice of.” Partner #2: “Where are you getting your data from?” Me: “Customer conversations and anecdotal vendor evidence. At least a dozen, maybe 15 references, since January, mostly in the area of data and database security.” Partner #2: “Meh. Not a great sample pool, or sample size. It’s so small in comparison to compliance it’s an afterthought. It’s really not worth mentioning.” Me: “Yeah, OK, agreed. But the customer questions seem to be driven by risk analysis, and the conversations just seems different. I think we could keep our eyes open on this.” So it’s not really worth talking about, but here I am mentioning it because it keeps popping up. I figured I’d open it up for discussion with our readers, to see what others are seeing. It’s not an actual trend, but it’s interesting – to me, at least. The evidence clearly shows that security is a compliance-driven market, and there is not enough evidence to say we see a real a change. But the conversations are a bit different than they used to be. More often focused on security, more focused on data, with some understanding of risk and a bit of a six-sigma-esque approach to security roadmaps. So maybe it’s not security at all – maybe it’s sophistication of buyers and their internal processes. And why do I care? Because if security or risk is the driver, it changes who buys the products and what features they focus on and ask about – because the use cases differ between security and compliance buyers. I am thinking out loud, but I’d love to hear what’s driving your product selection today. The other issue to talk about is my research agenda. It’s been hectic here since a month before RSA and it’s only just starting to let up. So it’s time to take a breath and look at the topics you want to hear about. Since Mike joined we have really filled out endpoint and network security; and we have continued to do a lot in analytics, data security, and security management. But despite the amount of expertise we have in house, we have done very little with application security, cloud, and access management. WAF management has been among the top 4 items on my research agenda for 2.5 years now, but has yet to percolate to the top. Identity and Access Management for cloud computing is an incredibly confusing topic which I think we could really shed some light on. And there are plenty of interesting technologies for application security we should delve into as well. We will reset the research agenda again soon, so now is a good time to weigh in on the areas you’re most interested in. Oh, and if you visit Arizona in the coming weeks, stay away from flashlights. Apparently they’re dangerous. Yikes! On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences The Macalope consults The Mogull Adrian presents on selecting a tokenization strategy. We missed Rich’s TidBITS article on hardening Mac OS X. Favorite Securosis Posts Adrian Lane: Low Hanging Fruit. When my encrypted tunnel failed the other day and email immediately decided to synch, I prayed no one was listening. Made me change all my passwords just in case. Mike Rothman: Pragmatic Key Management: Introduction. Rich had me at Pragmatic. I look forward to this series – crypto is integral to the cloud and we all need to revisit our Bob & Alice flowcharts. Other Securosis Posts White Paper: Understanding and Selecting a Database Security Platform. White Paper: Vulnerability Management Evolution. Security, Metrics, Martial Arts, and Triathlon: a Meandering Friday Summary. Evolving Endpoint Malware Detection: Control Lost. Continuous Learning. Friday Summary: May 18, 2012. Understanding and Selecting Data Masking: How It Works. Understanding and Selecting Data Masking: Defining Data Masking. Favorite Outside Posts Adrian Lane: The Cost of Fixing Vulnerabilities vs. Antivirus Software. Jeremiah asks whether our security investment dollars can be spent better. Most firms I speak with keep metrics to determine whether security programs are helping, improve over time, and provide some hints about the relative cost/benefit tradeoffs of different security investments. The data supports Jeremiah’s assertion. Mike Rothman: E-Soft (e-soft.co.uk) Uses Bogus Copyright Claims to Stifle Research. I guess some companies never learn from others. Security by obscurity is not a winning strategy. How about actually fixing the damn bug? Yeah, that’s too radical. Project Quant Posts Malware Analysis Quant: Index of Posts. Malware Analysis Quant: Metrics – Monitor for Reinfection. Malware Analysis Quant: Metrics – Remediate. Malware Analysis Quant: Metrics – Find Infected Devices. Malware Analysis Quant: Metrics – Define Rules and Search Queries. Malware Analysis Quant: Metrics – The Malware Profile. Malware Analysis Quant: Metrics – Dynamic Analysis. Research Reports and Presentations Report: Understanding and Selecting a Database Security Platform. Vulnerability Management Evolution: From Tactical Scanner to Strategic Platform. Watching the Watchers:

One of the common problems in working with encryption is getting caught up with the intimate details of things like encryption algorithms, key lengths, cipher modes, and other minutiae. Not that these details aren’t important – depending on what you’re doing they might be critical – but in the larger scheme of things these aren’t the aspects most likely to trip up your implementation. Before we get into different key management strategies, let’s take a moment to look at crypto systems at the macro level. We will stick to data encryption for this paper, but these principles apply to other types of cryptosystems as well. Note: For simplicity I will often use “encryption” instead of “cryptographic operation” through this series. If you’re a crypto geek, don’t get too hung up… I know the difference – it’s for readability. The three components of a data encryption system Three major components define the overall structure of an encryption system: The data: The object or objects to encrypt. It might seem silly to break this out, but the security and complexity of the system are influenced by the nature of the payload, as well as by where it is located or collected. The encryption engine: The component that handles the actual encryption (and decryption) operations. The key manager: The component that handles key and passes them to the encryption engine. In a basic encryption system all three components are likely located on the same system. Take personal full disk encryption (the default you might use on your home Windows PC or Mac) – the encryption key, data, and engine are all kept and run on the same hardware. Lose that hardware and you lose the key and data – and the engine, but that isn’t normally relevant. But once we get into SMB and the enterprise we tend to split out the components for security, management, reliability, and compliance. Building a data encryption system Where you place these components define the structure, security, and manageability of your encryption system: Full Disk Encryption Our full disk encryption example above isn’t the sort of approach you would want to take for an organization of any size greater than 1. All major FDE systems do a good job of protecting the key if the device is lost, so we aren’t worried about security too much from that perspective, but managing the key on the local system means the system is much less manageable and reliable than if all the FDE keys are stored together. Enterprise-class FDE manages the keys centrally – even if they are also stored locally – to enable a host of more advanced functions; including better recovery options, audit and compliance, and the ability to manage hundreds of thousands of systems. Database encryption Let’s consider another example: database encryption. By default, all database management systems (DBMS) that support encryption do so with the data, the key, and the encryption engine all within the DBMS. But you can mix and match those components to satisfy different requirements. The most common alternative is to pull the key out of the DBMS and store it in an external key manager. This can protect the key from compromise of the DBMS itself, and increases separation of duties and security. It also reduces the likelihood of lost keys and enables extensive management capabilities – including easier key rotation, expiration, and auditing. But the key could be exposed to someone on the DBMS host itself because it must be stored in memory at before it can be used to encrypt or decrypt. One way to protect against this is to pull both the encryption engine and key out of the DBMS. This could be handled through an external proxy, but more often custom code is developed to send the data to an external encryption server or appliance. Of course this adds complexity and latency… Cloud encryption Cloud computing has given rise to a couple additional scenarios. To protect an Infrastructure as a Service (IaaS) storage volume running at an external cloud provider you can place the encryption engine in a running instance, store the data in a separate volume, and use an external key manager which could be a hardware appliance connected through VPN and managed in your own data center. To protect enterprise files in an object storage service like Amazon S3 or RackSpace Cloud Files, you can encrypt them on a local system before storing them in the cloud – managing keys either on the local system or with a centralized key manager. While some of these services support built-in encryption, they typically store and manage the key themselves, which means the provider has the (hopefully purely theoretical) ability to access your data. But if you control the key and the encryption engine the provider cannot read your files. Backup and storage encryption Many backup systems today include some sort of an encryption option, but the implementations typically offer only the most basic key management. Backup up in one location and restoring in another may be a difficult prospect if the key is stored only in the backup system. Additionally, backup and storage systems themselves might place the encryption engine in any of a wide variety of locations – from individual disk and tape drives, to backup controllers, to server software, to inline proxies. Some systems store the key with the data – sometimes in special hardware added to the tape or drive – while others place it with the engine, and still others keep it in an external key management server. Between all this complexity and poor vendor implementations, I tend to see external key management used for backup and storage more than for just about any other data encryption usage. Application encryption Our last example is application encryption. One of the more secure ways to encrypt application data is to collect it in the application, send it to an encryption server or appliance, and then store the encrypted data in a separate database. The keys

Few terms strike as much dread in the hearts of security professionals as key management. Those two simple words evoke painful memories of massive PKI failures, with millions spent to send encrypted email to the person in the adjacent cube. Or perhaps it recalls the head-splitting migraine you got when assigned to reconcile incompatible proprietary implementations of a single encryption standard. Or memories of half-baked product implementations that worked fine on in isolation on a single system, but were effectively impossible to manage at scale. And by scale, I mean “more than one”. Over the years key management has mostly been a difficult and complex process. This has been aggravated by the recent resurgence in encryption – driven by regulatory compliance, cloud computing, mobility, and fundamental security needs. Fortunately, encryption today is not the encryption of yesteryear. New techniques and tools remove much of the historical pain of key management – while also supporting new and innovative uses. We also see a change in how organizations approach key management – a move toward practical and lightweight solutions. In this series we will explore the latest approaches for pragmatic key management. We will start with the fundamentals of crypto systems rather than encryption algorithms, what they mean for enterprise deployment, and how to select a strategy that suits your particular project requirements. The historic pain of key management Technically there is no reason key management needs to be as hard as it has been. A key is little more than a blob of text to store and exchange as needed. The problem is that everyone implements their own methods of storing, using, and exchanging keys. No two systems worked exactly alike, and many encryption implementations and products didn’t include the features needed to use encryption in the real world – and still don’t. Many products with encryption features supported only their own proprietary key management – which often failed to meet enterprise requirements in areas such as rotation, backup, separation of duties, and reporting. Encryption is featured in many different types of products but developers who plug an encryption library into an existing tool have (historically) rarely had enough experience in key management to produce refined, easy to use, and effective systems. On the other hand, some security professionals remember early failed PKI deployments that costs millions and provided little value. This was at the opposite end of the spectrum – key management deployed for its own sake, without thought given to how the keys and certificates would be used. Why key management isn’t as hard as you think it is As with most technologies, key management has advanced significantly since those days. Current tools and strategies offer a spectrum of possibilities, all far better standardized and with much more robust management capabilities. We no longer have to deploy key management with an all-or-nothing approach, either relying completely on local management or on an enterprise-wide deployment. Increased standardization (powered in large part by KMIP, the Key Management Interoperability Protocol) and improved, enterprise-class key management tools make it much easier to fit deployments to requirements. Products that implement encryption now tend to include better management features, with increased support for external key management systems when those features are insufficient. We now have smoother migration paths which support a much broader range of scenarios. I am not saying life is now perfect. There are plenty of products that still rely on poorly implemented key management and don’t support KMIP or other ways of integrating with external key managers, but fortunately they are slowly dying off or being fixed due to constant customer pressure. Additionally, dedicated key managers often support a range of non-standards-based integration options for those laggards. It isn’t always great, but it is much easier to mange keys now than even a few years ago. The new business drivers for encryption and key management These advances are driven by increasing customer use of, and demand for, encryption. We can trace this back to 3 primary drivers: Expanding and sustained regulatory demand for encryption. Encryption has always been hinted at by a variety of regulations, but it is now mandated in industry compliance standards (most notably the Payment Card Industry Data Security Standard – PCI-DSS) and certain government regulations. Even when it isn’t mandated, most breach disclosure laws reduce or eliminate the need to publicly report loss of client information if the lost data was encrypted. Increasing use of cloud computing and external service providers. Customers of cloud and other hosting providers want to protect their data when they give up physical control of it. While the provider often has better security than the customer, this doesn’t reduce our visceral response to someone else handling our sensitive information. The increase in public data exposures. While we can’t precisely quantify the growth of actual data loss, it is certainly far more public than it has ever been before. Executives who previously ignored data security concerns are now asking security managers how to stay out of the headlines. More enforcement of more regulations, increasing use of outsiders to manage our data, and increasing awareness of data loss problems, are all combining to produce the greatest growth the encryption market has seen in a long time. Key management isn’t just about encryption (but that is our focus today) Before we delve into how to manage keys, it is important to remember that cryptographic keys are used for more than just encryption, and that there are many different kinds of encryption. Our focus in this series is on data encryption – not digital signing, authentication, identity verification, or other crypto operations. We will not spend much time on digital certificates, certificate authorities, or other signature-based operations. Instead we will focus on data encryption, which is only one area of cryptography. Much of what we see is as much a philosophical change as improvement in particular tools or techniques. I have long been bothered people’s tendency to either indulge in encryption idealism at one end, and or dive

We are pleased to announce the availability of a new research paper, Understanding and Selecting Database Security Platforms. And this paper covers most of the facets for database security today. We started to refresh our original Database Activity Monitoring paper in October 2011, but stopped short when our research showed that platform evolution has stopped converging – and has instead diverged again to embrace independent visions of database security, and splintering customer requirements. We decided our original DAM research was becoming obsolete. Use cases have evolved and vendors have added dozens of new capabilities – they have covered the majority of database security requirements, and expanded out into other areas. These changes are so significant that we needed to seriously revisit our use cases and market drivers, and delve into the different ways preventative and detective data security technologies have been bundled with DAM to create far more comprehensive solutions. We have worked hard to fairly represent the different visions of how database security fits within enterprise IT, and to show the different value propositions offered by these variations. These fundamental changes have altered the technical makeup of products so much that we needed new vocabulary to describe these products. The new paper is called “Understanding and Selecting Database Security Platforms” (DSP) to reflect these major product and market changes. We want to thank our sponsors for the Database Security Platform paper: Application Security Inc, GreenSQL, Imperva, and McAfee. Without sponsors we would not be able to provide our research for free, so we appreciate deeply that several vendors chose to participate in this effort and endorse our research positions. You can download the DSP paper. Share: