Research

Rich here… Some weeks I can’t decide if I should write something personal, professional, or technical in the Summary intro. Especially when I’m absolutely slammed and haven’t been blogging. This week I’ll err on the side of personal, and I’m sure you all will give me a little feedback if you prefer the geeky. Last summer and fall I had a bit of a health scare, when I thought I was, well, dying, at breakfast with Mr. Rothman. Now I know many people think they’ve felt that way while dining with Mike, but I seriously thought I was going out for the count. Many months and medical tests later, they think it was just something with my stomach, and beyond a more-than-fair share of indigestion, I have moved on with life. I have always tried to be a relatively self-aware individual (well, not counting most of my life before age 27 or so). Some people blow off scares like that, but I figured it was a good way to review my life priorities. I came up with a simple list: 1 Family/Health 2 Fitness 3 Work … … … … … … 4 Everything else Yes, in that order. I can’t be there for my family if I’m not healthy, and my wife and kids matter a lot more to me than anything else. I don’t begrudge people who prioritize differently – I know plenty of people who put work/career in front of family (although few admit it to themselves). That’s their decision to make, and some of them see financial health the way I look at physical health. That’s also why I put fitness ahead of work. For me, it is intrinsically tied to health, but the difference is that I will skip a workout if necessary to be there for my family. But aside from the health benefits (not counting the injuries), I want to be very active and very old someday, which I can’t do without working out. A lot. And it keeps me sane. Then comes work. As the CEO of a startup facing its most important year ever, work has to come before everything else. This Securosis thing isn’t just a paycheck – it is long-term financial security for my family. I can’t afford to screw it up. The upside of The List is that it makes decisions simple. Can I carve out 2 hours for a workout during business hours so I can be home with my family that night? Yes. Do I skip a Saturday morning ride because I have been traveling a lot and need to spend time with the kids? Yes. Can I travel for that conference during a birthday? No. The downside of my list is that “everything else” is a distant fourth to the top three items. That means less contact with friends; dropping most of my hobbies that don’t involve pools, bikes, or running shoes; and not having the diversity in my life that I enjoyed before my family. Other than the part about friends, I am okay with those sacrifices. When the kids are older I can start woodworking, recreational hacking, and playing with the soldering iron again. I don’t have much of a social life and I work at home, which is pretty isolating, and maybe I will figure that out as the kids get older. It also means I dropped nearly all my emergency services work, and for the first time since I was 18 I might drop it completely for a few years. And, in case you were wondering, The List is the reason I haven’t been writing as much. We are completing some seriously important long-term projects for the company and those need to take priority over the short stuff. But I like algorithms. Keeps things simple, especially when you need to make the hard choices. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Quiet. Must be summer. Favorite Securosis Posts Adrian Lane: Pragmatic WAF Management: Policy Management. I don’t normally pick my own posts but I like this one. And there was so much ground to cover I am afraid I might have left something out, so I would appreciate feedback. Mike Rothman: Pragmatic WAF Management: Policy Management. WAFs still ain’t easy, nor are they going to be. But understanding how to build and manage your policies is the first step. Adrian lays out what you need to know. Rich: Always Assume. This is an older post, but it came up in an internal discussion today and I think it is still very relevant. Other Securosis Posts Pragmatic WAF Management: Application Lifecycle Integration. Incite 8/15/2012: Fear (of the Unknown). Endpoint Security Management Buyer’s Guide: Ongoing Controls – Device Control. Endpoint Security Management Buyer’s Guide: Ongoing Controls – File Integrity Monitoring. Favorite Outside Posts Mike Rothman: Triple DDoS vs. krebsonsecurity. You know you have friends in high places when a one man operation is blasted by all sorts of bad folks. Krebs describes his battle against DDoS in this post and it’s illuminating. We will do some research on DDoS in the fall – we think this is an attack tactic you will need to pay much more attention to. Adrian Lane: Software Runs the World. I’m not certain we can say software is totally to blame for the Knight Capital issue, but this is a thought-provoking piece in the mainstream media. Although I am certain those of you who have read Daemon are unimpressed. Rich: Gunnar’s interview with Jason Chan of Netflix security. A gold mine for cloud security nuggets. Project Quant Posts Malware Analysis Quant: Index of Posts. Research Reports and Presentations Understanding and Selecting Data Masking Solutions Evolving Endpoint Malware Detection: Dealing with Advanced and Targeted Attacks. Implementing and Managing a Data Loss Prevention Solution. Defending Data on iOS. Malware Analysis Quant Report. 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

Rich here. Two weeks ago I got to experience something that wasn’t on the bucket list because it was so over the top I lacked the creativity to even think of putting it on the bucket list. I’ve been a cycling fan for a while now. Not only is it one of the three disciplines of triathlon, but I quite enjoy cycling for its own sake. As with tri, it’s one of the only sports out there where you can not only do what the pros do, but sometimes participate in the same events with them. You might run into a pro football player at a bar or restaurant, but it isn’t uncommon to see a pro rider, runner, or triathlete riding the same Sunday route as you, or even setting up in the same start/transition area for a race. Earlier this year Barracuda networks started sponsoring the Garmin-Sliptream team (for a short time it was Garmin-Barracuda, and now it’s Garmin-Sharp-Barracuda). I made a joke to @petermanmc about needing analyst support for the Tour de France, and something like 6 months later I found myself flying out to France for a speaking gig… and a little bike riding. I won’t go into the details of what I did outside the speaking part, but suffice it to say I got a fair bit of road time and caught the ends of a few stages. It was an unbelievable experience that even the Barracuda folks (especially a fellow cyclist from the Cuda exec team) didn’t expect. One of the bonuses was getting to meet some of the team and the directors. It really showed me what it takes to play at the absolute top of the game in one of the most popular sports on the planet (the TdF is the single biggest annual sporting event). For example, during a dinner after the race about half the team was also lined up for the Olympics. We heard the Sky team (mostly UK riders) all hopped on a plane mere hours after winning the Tour so they could continue training. None of the Garmin riders competing in the Olympics had as much as a single celebratory drink as far as I could tell. After three weeks of racing some of the hardest rides out there, they didn’t really take one night off. Earlier in the day, watching the finish to the Tour, I was talking with one of the development team riders who is likely to move up to the full pro team soon. Me: “Have you ever seen the Tour before?” Him: “Nope, it’s my first time. Pretty awesome.” Me: “Does it inspire you to train harder?” Him: “No. I always train harder.” That was right up there with one of the pros who told me he doesn’t understand all the attention the Tour gets. To him, it’s just another race on the schedule. “We’ll be riding these same stages in a few months and no one will be out there”. That’s the difference between those at the top of the game, and those who wonder why they can’t move up. It doesn’t matter if it’s security, cycling, or whatever else you are into. Only those with a fusion reactor of internal motivation, mixed with a helping of natural talent, topped off with countless hours of effective training and practice, have any chance of winning. And trust me, there are always winners and losers. I’d like to think I’m as good at my job as those cyclists are at theirs. Maybe I am, maybe I’m not, but the day I start thinking I get to do things like snag a speaking gig at the Tour de France because of who I am or where I work, rather than how well I do what I do, is the day someone else gets to go. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich presented at Black Hat and Defcon, but we have otherwise been out of the media. Favorite Securosis Posts Mike Rothman: New Series: Pragmatic WAF Management. WAFs have a bad name, but it’s not entirely due to the technology. Adrian and I will be doing a series over the next couple weeks to dig into a more effective operational process for managing your WAF. PCI says buy it, so you may as well get the most value out of the device, right? Adrian Lane: Earning Quadrant Leadership. What a great post. Do you have any idea how often vendors and customers ask us this question? Rich: Pragmatic WAF Management: the Trouble with WAF. Ah, WAF. Other Securosis Posts Endpoint Security Management Buyers Guide: the ESM Lifecycle. Endpoint Security Management Buyer’s Guide: The Business Impact of Managing Endpoints. Incite 8/1/2012: Media Angst. Incite 7/25/2012: Detox. Incite 7/18/2012: 21 Days. Proxies –Meet the ‘Agents’ of Cloud Computing. Heading out to Black Hat 2012! FireStarter: We Need a New Definition of Dead. Takeaways from Cloud Identity Summit. Favorite Outside Posts Adrian Lane: Tagging and Tracking Espionage Botnets. I’m fascinated by botnets – both because of the solid architectures they employ as well as plenty of clever secure coding. I wish mainstream software development was as good. Mike Rothman: Q2 Earnings Call Transcripts. I’m a sucker for the quarterly earnings calls. Seeking Alpha provides transcripts, which can be pretty enlightening for understanding what’s going on with a company. Check out a sampling from Check Point, Fortinet, Symantec, SolarWinds, and Sourcefire. Pepper: The Power Strip That Lets You Snoop On An Entire Network. I want one! Adrian Lane: Top Ten Black Hat Pick Up Lines. OK, not really security per se, but it was funny. And we need more humor in security. TSA jokes only go so far. Mike Rothman: Lessons Netflix Learned from the AWS Storm. You can learn from someone else, or you can learn the hard way (through painful personal experience). I prefer the former. Go figure. It’s truly a huge gift that companies like Netflix air their dirty laundry about

Rich here. I’m starting to think I might be dealing with a bit of burnout. No, not the “security burnout” that keeps cropping up on Twitter and in blog posts, but a bit of a personal burnout. I just find myself lacking a bit of general enthusiasm and creativity that usually keeps me plowing away at a productive rate. This burnout doesn’t have anything to do with security. I still freaking love our profession, even if some of our debates are getting a bit stale. We are long past the early days of the social dialog created by blogs, Twitter, and podcasts. So our discussions lack a certain freshness as we beat postmortem horse after postmortem horse. It also isn’t related to my job, which is freaking awesome. Aside from the usual advantages of working for myself, I have a flexibility I still can’t believe is possible. It stuns me that our business model works, because we seem to be doing everything independent analyst firms supposedly cannot get away with. Seriously, it doesn’t make sense – not that I’m complaining. Plus, how many analysts get to manage software projects and build technical labs? Personal life? All is good there. Awesome wife and kids. I get to race triathlons despite a full time job and young kids. Although I won’t lie – I could get out of the house a little more (aside from my workouts). A little social interaction somewhere other than a security conference won’t hurt. But as I write this I realize what the problem might be. I am seriously freaking tired. Bone weary, can barely function from day to day tired. The culprit? A cute little three year old and her younger sister who have taken to waking us up at 5am every day. For 3 years. And they demand constant attention every waking hour. I know I’m far from the first to go through this, and those of you with older kids can stop grinning with the superiority of someone who managed to swim to shore after the Titanic went down. I’d appreciate it if you would just quietly enjoy my pain and keep it to yourself. Aside from the lack of sleep, I also realized that Securosis has now been in business almost exactly five years. It all started in a Margaritaville during Black Hat when I got the word my condo in Boulder had sold and I now had enough financial runway to survive for 6 months. Ask Chris Hoff – he was there and didn’t believe me when I said I was resigning from Gartner the following Monday (he also hooked me up with my first project, which didn’t hurt). I had wanted to do something different for a while, and that cash cushion was exactly what I needed. But 5 years is 5 years and I am fully willing to admit that some of the enthusiasm of that first year has worn off. It isn’t new or different anymore, even though I get to do new and different things almost daily. Okay – so I’ve identified two problems, and I’m not the kind of person to sit back and wait for change. Step 1 is getting one of those “okay to wake” clocks for the kiddo. They have lights that change color when it’s okay to get out of the room in the morning. The thought of sleeping in until 6am consistently is more exciting than… well, pretty much anything. Seriously, far more exciting than even my various teenage male fantasies. After that? Time to pull a Rothman and get out of the house and work at coffee shops a bit more. I love the cats, but they don’t give a crap about oracle padding attacks or cloud APIs. I need to get a little creative with the research and writing again, and that probably means slowing down the day to day distraction schedule and turning off RSS and Twitter. Those two things and launch our damn SaaS product finally. I’m pretty sure every day will be new and interesting again when I suddenly have to support customers and start acting like a software company. Oh, heck, just watching Rothman’s head explode when he realizes he’s a vendor again will give me at least a month or two of daily amusement. And if that comes with 8 hours of sleep and a good workout every day? So much the better. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich’s monstrous sandboxing article at TidBITS. Adrian’s 15 Ways to Get More From Log Files on Dark Reading. Mike’s monthly Dark Reading blog: Time to deploy the FUD weapon?. Rich in a New York Times blog on Apple. Favorite Securosis Posts Rich: Mike’s Can You Stop a Targeted Attack?. Mike: Returning the favor, Rich’s Thoughts on Active Defense, Intrusion Deception, and Counterstrikes. Mike (again): Answering Questions about Sandboxing, Gatekeeper, and the Mac App Store – It’s not really an internal post but Rich wrote it, so it counts. A great overview of what Mountain Lion adds from a security standpoint. Adrian: And here I thought Empty Nest was the best post for the analysis. Other Securosis Posts Incite 6/27/2012: Empty Nest. Understanding and Selecting Data Masking: Buyer’s Guide. Favorite Outside Posts Rich: Dennis Fisher’s LeBron James, Advanced Attackers and the Best Man Theory. Nails it, and boy does Dennis show off his background as a sports writer! Mike: Nora Ephron’s 1996 Wellesley Commencement Speech. A must-read, especially if you have daughters. Brutally honest about herself, her life, and the state of society back in 1996. Adrian: From a security standpoint, Rich’s monstrous sandboxing article at TidBITS was a really good read, but the most thought provoking was The Many Pivots of Justin.TV – a couple weeks old but I just ran across it. 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

Earlier this week Joseph Menn published a confusing article over at Reuters that conflated “active defense” with “strike back” technologies. As Chris Hoff said on Twitter: “active defense” is not the same as “strike back.” The first sentence is a bullshit premise. Active defense, deception, and counterattacks are things I have been interested in for a long time. The principles aren’t new – just go read the Cuckoo’s Egg – but we are seeing a small revival as the nature of attackers cycles back to data theft from the decade-plus distraction of website defacements and low-end phishing & malware. Mike and I talk a lot about reacting faster and better (see React Faster and Better: New Approaches for Advanced Incident Response). As is now being recognized more broadly, no security toolset can eliminate successful attacks, so we need to focus just as heavily on incident response. The problem? We generally lack mechanisms to identify the attacks that our tools miss. I wrote in Force Attacker Perfection that we can put in more barriers and monitors to increase our chances of detecting an attack. But my premise was a bit flawed – we still need some sort of trigger to identify real attacks, with far fewer false positives than we have come to accept from our tools. No one has time to look through every SIEM or IDS alert on a day to day basis, never mind logs. One way around this is to implement active defenses, honeypots, and tripwires. To avoid Menn’s mistake, here are some possible definitions we can work with: Active defense: Altering your environment and system responses dynamically based on the activity of potential attackers, to both frustrate attacks and more definitively identify actual attacks. Try to tie up the attacker and gain more information on them without engaging in offensive attacks yourself. A rudimentary example is throwing up an extra verification page when someone tries to leave potential blog spam, all the way up to tools like Mykonos that deliberately screw with attackers to waste their time and reduce potential false positives. Intrusion deception: Pollute your environment with false information designed to frustrate attackers. You can also instrument these systems/datum to identify attacks. DataSoft Nova is an example of this. Active defense engages with attackers, while intrusion deception can also be more passive. Honeypots & tripwires: Purely passive (and static) tools with false information designed to entice and identify an attacker. Counterstrike: Attack the attacker by engaging in offensive activity that extends beyond your perimeter. These aren’t exclusive – Mykonos also uses intrusion deception, while Nova can also use active defense. The core idea is to leave things for attackers to touch, and instrument them so you can identify the intruders. Except for counterattacks, which move outside your perimeter and are legally risky. You don’t need to be highly advanced to implement some of these ideas, and you certainly don’t necessarily need products. We are starting to integrate some of these concepts into our environment, and doing so creatively with no real budget. But my biggest fear isn’t being attacked, or even breached – I worry about finding out on Pastebin or in the morning news. I know I can’t keep all attackers out, and I can’t review our forensic logs every day, and I know that no signature-based tool can detect everything, so my only choice is to drop some tripwires to hopefully figure out when someone makes it in. I’m not saying my definitions are canonical – and they need work – but it’s important to distinguish between passive deception, active deception/defense, and offensive activity. Share:

In our last post we covered the four enterprise key management strategies. Today we will finish off Pragmatic Key Management with recommendations on how to pick the right strategy for your project or organization. To recap, there are four key management strategies: Local management Silo management Key management service Enterprise key management As much as I would like to drag this out into a long and complex assessment process, it’s actually fairly simple: You should never use local key management for anything other than development, testing, and one-off applications. About the only thing I use it for is some personal encryption, and not even much of that. Stick with silo management if it meets your needs, but this generally only works for encryption-oriented silos such as full disk encryption, email, and a couple other cases. By ‘needs’ I mean everything from basic manageability and auditing/reporting all the way through administrator separation of duties, key rotation/backup/restore, multi-location key synchronization and replication, and all sorts of other requirements beyond the scope of this series. When local and silo won’t work, a key management service is the way to go. Full enterprise key management is nice to have, but not something to focus on at the start. If you do stick with silo management but need a key manager for another project, it is often worthwhile to transition your siloed applications over to the key manager; once you have a key manager you might as well take advantage of it for backup, restore, redundancy, and other management features. The key is to think strategically. Once you start managing multiple encryption applications, you will eventually move into some sort of dedicated key manager. To build a key management service, pick a platform that will grow as you increase usage – even if the first deployment is narrowly scoped. People often start with a single application, database, or storage encryption project – a silo where key management is poor or doesn’t exist. But don’t choose purely based on immediate requirements – pick something that meets your immediate needs and can expand into other areas, for example by providing a backup key manager for disk encryption. We see two common problems when people build key management strategies. The first is that they don’t build strategically. Everyone buys or builds key management for each project, rather than offering and taking advantage of a central service whenever possible. On the other end of the spectrum, organizations obsess over implementing enterprise key management but forget to properly managing their silos and projects. We see the best success when organizations plan strategically and then grow into broader key management. Practically speaking, this typically starts with a single project using a dedicated key manager, which is then expanded and leveraged for other complementary projects. It’s fine to keep some silos, and it’s okay to have key managers in their own silos when there is no need to plug them into something larger. For example, you don’t necessarily need to have both your database encryption and full disk encryption projects report up to a single enterprise key manager. We have mentioned this before, but sweet spots which may justify moving up to a key manager include: Backup encryption Database encryption Application encryption In all three areas we tend to see strong need for encryption but weak key management. To recap: avoid local management; silos are fine when they meet your needs; step projects up to key managers when it makes sense for the project; expand coverage over time; and stick with one platform for cleaner management when feasible. Key management and how you structure your crypto system both matter more than the encryption engine itself. We haven’t discussed key manager selection criteria (fodder for a future report); but it should be obvious that deployment is easier when products support standards, include good APIs and plugins, and play well out of the box with common platforms and software. You should now have a much better idea of how data encryption systems work, the different strategies for managing encryption keys, and how to pick the best one for your organization. Share:

Yes, folks, at long last, here is my follow-up to Understanding and Selecting a DLP Solution. As you might guess from the title, this one is focused on implementation and management. After you have picked a tool, this will help you get up and running, and then keep it running, with as little overhead as possible. I would like to thank McAfee for licensing the paper and making it possible for us to give this stuff out for free (and by now we hope you’ve figured out that all the content is developed independently and objectively). McAfee is hosting the paper and you can download it from us: Landing page PDF (direct) Share:

In our last post we covered the components of data encryption systems and ran through some common examples. Now it’s time to move on to key management itself, and dig into the four different key management strategies. We need to start with a discussion of the differences between encryption operations and key management; then we will detail the different enterprise-level strategies. The differences between key management and encryption operations As we focus on data encryption across the organization rather than isolated applications of basic encryption, it is time to spend a moment on what we mean when we discuss key management vs. encryption operations. Every data encryption operation involves a key, so there is always a key to manage, but a full-fledged management system is the most important aspect of building a multipart encryption system. Many data encryption systems don’t bother with “real” key management – they only store keys locally, and users never interacts with the key directly. For example, if you encrypt data with a passphrase using one of the many common command-line tools available, the odds are good that you don’t do anything with the key beyond choosing an encryption algorithm and key length. Super-simple implementations don’t bother to store the key at all – it is generated as needed from the passphrase. In slightly more complex (but still relatively simple) cases the key is actually stored with the data, protected by a series of other keys which are still generated from passphrases. There is a clear division between this and the enterprise model, where you actively manage keys. Key management involves separating keys from data for increased more flexibility and security. It does not require you to move to keys to an external system, but that is one of the more important options. You can have multiple keys for the same data, the same key for multiple files, key backup and recovery, and many more choices. The four key management strategies There are four main approaches to managing data encryption keys within an organization. These apply to individual cryptosystems, to various different kinds of applications, and to larger and more complicated cryptography systems. Many of them also apply to other kinds of encryption operations, such as digital signatures and certificates, but we aren’t concerned with those for this paper. Local key management This option is the closest to doing nothing at all for key management. Keys are all managed locally (on a single system or a cluster of systems), with all key functions handled within a single application. Local key management is actually quite common, even though it isn’t always the best idea. Common examples include: Full disk encryption managed by a single user (e.g., Bitlocker or FileVault without tying into a key management server) Transparent database encryption Building encryption into an application server Basic backup encryption File server or SAN/NAS encryption In each of these cases all keys can be managed locally – in which case any key rotation, backup/restore, or auditing also must be built into the local system, but more often these capabilities are simply nonexistent. Local key management isn’t necessarily bad, in particular isolated scenarios. For example, if you back up your data unencrypted, or with a system that uses its own keys, there may be no reason to worry about managing local keys. But for anything serious – including anything with compliance requirements – relying on local key management is asking for trouble. Silo key management This refers to separating the keys a the local system and managing them within a multi-system application. Whatever software stack/system you run manages its own keys for its own client software. Full disk encryption is one of the most common enterprise examples. A central management server handles configuration and keys for all encrypted laptops and desktops. This key management system is never used for anything else, such as databases, but may manage other data encryption features supported by the product (including file/folder encryption). All important key management functions, including administrative and recovery keys, rotation, backup/restore, and audit, are built into the silo key manager. Other typical uses include email encryption, some backup encryption tools, and even enterprise Digital Rights Management – DRM is implemented through cryptography. Silo key management is totally suitable when it meets the particular requirements of the situation. When encryption is the key function of a product, as with full disk encryption, this approach often works perfectly – with no need for additional key management. On the other hand, when encryption is merely a feature of an existing product, key management is often minimal at best – typified by encryption products bolted onto exiting backup systems. Key management services So far the two strategies we have discussed keep the keys within a single system or application stack. The next couple strategies introduce a new component: a dedicated key management system. When local or silo key management is inadequate, it’s time to bring in a tool specifically to address the problem. Move keys outside the silo and integrate dedicated key management with one or more applications. This used to be incredibly difficult, but more and more products (both commercial and free software / Open Source) now support key management standards that make it much easier to use external management. Before standards we had to either rely on the vendor to provide proprietary hooks, or reverse engineer the entire thing. A variety of dedicated key management options are available – including hardened hardware appliances, software, virtual appliances, and even Software as a Service (SaaS). We are focusing on key management strategies rather than products, so we won’t go into all the various features and functions, but suffice it to say they tend to have far more robust capabilities (and often stronger security) than all but the best silo tools. Aside from all the added functionality of an external service, the external service can manage keys for multiple different silos. This can be important for unifying auditing/reporting and meeting other compliance requirements. Key management services

Ah, summer. That time of year where our brains naturally start checking out, even if it’s inconvenient. You have probably noticed a bit of a slowdown on the blog as we succumb to the sweet call of adventure. And by ‘adventure’ I mean the delicate balance of being way freaking behind while trying to squeeze in family vacations and a few conferences. Since my kids are too young for school I can’t really use them as the excuse for taking time off. No, in my case it is the temperatures over 100F that started a month or so ago and won’t subside until sometime close to Halloween. Phoenix is not fun in the summer if you get my drift. Today, for example, when I do my short run after my hour on the bike trainer, the temp will be somewhere around 104F. So I was super excited to spend last week in my home town of Boulder, Colorado. I grew up in New Jersey, but moved to Boulder when I was 18, spent the next 16 years there, and consider Boulder the place I really grew up. Some places just fit a person, and Boulder appealed to me on more levels that I can explain. The culture, physical environment, and social scene all aligned with that perfect cosmic center of the Universe all the new-age freaks claim is somewhere behind Pasta Jay’s. This was the first time I had been back for any length of time in about 5 years, and it was was my first time back since becoming a parent. It was sort of funny – when I lived there I didn’t think there was much for kids to do until they were old enough to climb, hike, ski, and ride. I was all worried my kids would be bored out of their gourds. Sure, I know where all 20+ bars near the Pearl St. Mall are located, but I had to email friends to find a single playground. But man, they are all over the place! And the best part? A lot are located really close to all those bars… which were coincidentally a reasonable bike ride from the house we rented. Yep, total coincidence. I mean, it isn’t like we’d plan that sort of thing. On the downside, instead of escaping from 100+ in Phoenix to Boulder’s typical 60-80F this time of year, we landed in a heat wave. As in 90F+. The technical term for that is “extreme suckage”. They always say you can’t go home, and to some extent that’s true. The life I had in Boulder is long dead. Friends have moved on, the ones who stayed got old (like me), the bars of our youth are now – if they exist at all – the bars of someone else’s youth, and if I tried to spend my leisure time doing everything I did back then I would soon be hunting for a good divorce lawyer in between those mountain rescues. In some ways it is good that I left Boulder, even if I miss it every day. I was instantly pulled out of my single/childless life and forced to drop things – like 5 martial arts classes a week, on top of dozens of mountain rescues, and ski patrol every other weekend, and all the other ways I passed my time. They were instantly severed instead of being drawn out in a long, painful process of separation and personal realizations that life changed and I need to back off. For me, life changed instantly instead of slowly. I know this because it is 100+ fracking degrees at 9am where I live, which is an excellent reminder. I have seen how most of my other friends with kids struggled to balance their lives through this transition, and ripping off the Band-Aid isn’t a bad way to do it. On the other hand, Boulder is still Boulder. Some of the buildings change, but I felt just as at home there last week as I did 6 years ago when I left. The 15 minute rain still comes in every day between 4 and 4:30, the convenience store in Jamestown is still a perfect place to stop for some coffee while riding a (rented) road bike in the hills, and the annoying-ass Rainbow Family kids – who you know have loaded parents – still camp out on the Pearl St. Mall begging for cash. You can go home. It’s just that someone else lives there now – even if you never left. With that, daycare just called and I need to go pick up a little kid with a fever and end my work day. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences We have been on vacation – nothing to see here. Favorite Securosis Posts Adrian Lane: Market Share Nonsense. Mike Rothman: Malware Analysis Quant [Final Paper]. Check out the final paper for the epic Malware Analysis Quant research. And then play a drinking game for every step in the process you don’t do. Make sure you don’t drive after that. Rich: What Adrian said. I need to write a follow-up on some of the BS vendors have tried to pull on me over the years. Like paying cash under the table for references. I tried my best, but I know at least once I was fooled… and it probably happened more than that. Other Securosis Posts Evolving Endpoint Malware Detection: Providing Context. New Paper: Defending Data on iOS. Incite 6/13/2012: Tweeting Idiocy. Understanding and Selecting Data Masking: Management and Advanced Features. Upcoming: Tokenization Webcast This Week. Evolving Endpoint Malware Detection: Behavioral Indicators. Favorite Outside Posts Adrian Lane: Mistakes Were Made: Incident Response. An informative rant on incident response and preparedness. Mike Rothman: Pre to postmortem: the inside story of the death of Palm and webOS. As a student of business, I love stories that dig into how anything can go from the top to the bottom within a few short years.

A while back we ran a show-of-hands survey at a conference of senior IT security pros. Nearly none of them wanted to support iOS, but nearly all of them needed to support iOS. Which did seem odd, considering how many were using iPhones. The good news is that although we can’t manage iOS the way we have traditionally managed most of our other employee systems, the platform itself is a lot more secure than most of the other things you are using. I know, you don’t believe me, so just read this paper. We also have plenty of options for protecting data going to the device, and once it’s on the device. This is the part that tends to be a bit more complicated, with a very wide range of tools and approaches, but all the things we review in this report are realistic and working in production environments. Hopefully this report simplifies things a bit, and as far as we know it is the only place someone has compiled all the options in one place, plus provided a neutral perspective on capabilities and usefulness. So take a look: Landing Page Direct link to the PDF: Defending Data on iOS (v 1.0) Special thanks to Watchdox for licensing this content so I can feed my kids (well, the one who bothers to eat). As always the research was developed completely independently and published on this blog for peer review throughout the entire process, in accordance with our Totally Transparent Research process. Share:

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