Research

Over the years the RSA Conference has racked up some (legitimate) criticism that its session selection process was too opaque, started too early for up-to-date content, and didn’t always reflect the community at large. I am a bit biased because I have been involved with RSAC for a while now, and talk to the organizers year round, but I know they make a concerted effort to deal with these issues. (No, I’m not on any of the selection committees). For example they can’t really release the names of the track leads since there is a swarm (or is that murder?) of PR and marketing pros who are paid to get their representatives on stage, no matter what. I guarantee you that if those names get out, those individuals will be hammered directly. The early Call For Papers? This is a large event with a ton of tracks and a selection process. Hold the CFP too close to the event and it opens yet more cans of messes. Community representation? Funny you ask! This year RSAC has dedicated an entire track to crowdsourced submissions. The goal is to directly address all the criticism above: Submissions are open until March 12, only a month before the conference. Anyone can submit, but corporate presentations will most definitely be scrutinized. The community will vote to pick the best sessions. Anyone can vote – not just RSAC attendees! RSAC attendee votes get weighted more, which should help reduce gaming the system. The final selections will be by a public panel, based on the top 25 vote receivers. The panel is comprised of known entities, who are used to dealing with PR and marketing techniques. Yes, I am on the panel. I also feel honored that they approached me early to get ideas and feedback on this concept. They have put a lot of thought into this (especially Britta Glade, who probably hates me for calling her out). It won’t be perfect but it’s version 1.0. If you always wanted to speak at RSA, but couldn’t get through the process, give it a shot. This is a great chance for new speakers, late-breaking research, and creative sessions. Share:

Earlier today in the Friday Summary I vented frustrations at news articles blaming the victims of crimes, and often guessing at the facts. Having been on the inside of major incidents that made the international news (more physical than digital in my case), I know how little often leaks to the outside world. I picked on the Wired article because it seemed obsessed with the lack of encryption on Anthem data, without citing any knowledge or sources. Just as we shouldn’t blindly trust our government, we shouldn’t blindly trust reporters who won’t even say, “an anonymous source claims”. But even a broken clock is right twice a day, and the Wall Street Journal does cite an insider who says the database wasn’t encrypted (link to The Verge because the WSJ article is subscription-only). I won’t even try too address all the issues involved in encrypting a database. If you want to dig in we wrote a (pretty good) paper on it a few years ago. Also, I’m very familiar with the healthcare industry, where encryption is the exception more than the rule. Many of their systems simply can’t handle it due to vendors not supporting it. There are ways around that but they aren’t easy. So let’s look at the two database encryption options most likely for a system like this: Column (field) level encryption. Transparent Database Encryption (TDE). Field-level encryption is complex and hard, especially in large databases, unless your applications were designed for it from the start. In the work I do with SaaS providers I almost always recommend it, but implementation isn’t necessarily easy even on new systems. Retrofitting it usually isn’t possible, which is why people look at things like Format Preserving Encryption or tokenization. Neither of which is a slam dunk to retrofit. TDE is much cleaner, and even if your database doesn’t support it, there are third party options that won’t break your systems. But would either have helped? Probably not in the slightest, based on a memo obtained by Steve Ragan at CSO Online. The attacker had proficient understanding of the data platforms and successfully utilized valid database administrator logon information They discovered a weird query siphoning off data, using valid credentials. Now I can tell you how to defend against that. We have written multiple papers on it, and it uses a combination of controls and techniques, but it certainly isn’t easy. It also breaks many common operational processes, and may not even be possible depending on system requirements. In other words, I can always design a new system to make attacks like this extremely hard, but the cost to retrofit an existing system could be prohibitive. Back to Anthem. Of the most common database encryption implementations, the odds are that neither would have even been much of a speed bump to an attack like this. Once you get the right admin credentials, it’s game over. Now if you combined with multi factor authentication and Database Activity Monitoring, that would have likely helped. But not necessarily against a persistent attacker with time to learn your systems and hijack legitimate credentials. Or perhaps encryption that limited access based on account and process, assuming your DBAs never need to run big direct queries. There are no guarantees in security, and no silver bullets. Maybe encrypting the database would have helped, but probably not the way most people do it. But it sure makes a nice headline. I am starting a new series on datacenter encryption and tokenization Monday, which will cover some of these issues. Not because of the breach – I am actually already 2 weeks late. Share:

Rich here, Another week, another massive data breach. This morning I woke up to a couple interview requests over this. I am always wary of speaking on incidents based on nothing more than press reports, so I try to make clear that all I can do is provide some analysis. Maybe I shouldn’t even do that, but I find I can often defuse hyperbole and inject context, even without speaking to the details of the incident. That’s a fine line any of us on press lists walk. To be honest, more often than not I see people fall into the fail bucket by making assumptions or projecting their own bias. Take this Anthem situation. I kept my comments along the lines of potential long-term issues for people now suffering exposed personal information (for example a year of credit monitoring is worthless when someone loses your Social Security Number). I was able to talk about who suffers the consequences of these breaches, trends in long-term impacts on breached companies, and the weaknesses in our financial and identity systems that make this data valuable. I did all of that without blaming Anthem, guessing as to attribution, or discussing potential means and motivations. Those are paths you can consider if you have inside information (verified, of course), but even then you need to be cautious. It was disappointing to read some of the articles on this breach. One in particular stood out because it was from a major tech publication, and the reporter seemed more interested in blaming Anthem and looking smarter than anything else. This is the same person who seriously blew it on another story recently due to the same hubris (but no apologies, of course). There is a difference between analyzing and guessing, and it is often hubris. Analysis means admitting what you don’t know, and challenging and doubting your own assumptions. Constantly. I have a huge fracking ego, and I hate being wrong, but I care more about the truth and facts than being right or wrong. To me, it’s like science. Present the facts and the path to your conclusions, making any assumptions clear. Don’t present assumptions as facts, and always assume you don’t know everything and what you do know changes sometime. Most of the time. And for crap’s sake, enough with blaming the victim and thinking you know how the breach occurred when you don’t have a single verified source (if you have one, put it in the article). Go read Dennis Fisher’s piece for how to play it straight and still make a point. Unless you are Ranum. We all need to bow down to Ranum, who totally gets it. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian quoted on Tokenization. Paper on dynamic authorization by Gunnar Peterson (Registration required). Securosis Posts We know, slow week. We blame random acts of sleep deprivation. New Paper: Security and Privacy on the Encrypted Network. Incite 2/4/2015: 30×32. Applied Threat Intelligence: Use Case #3, Preventative Controls. Favorite Outside Posts Adrian: Spy Agencies Secretly Rely On Hackers. One of the best aspects of this profession is being able to expand your mind based on really cool research from security people. Spy organizations would be crazy not to do the same! Look at the names on the list – half the people I follow to learn from because they do really interesting research. Mike: Looking for the Teachable Moments. Never stop learning. It’s a simple as that. Rich: Every Frame a Painting. This is a YouTube channel of short segments of film analysis. I’m a big film geek, and I love dissecting a scene or work and learning more about how films are made. The Jackie Chan one is my favorite so far. If you like it you can donate to support it. JJ: Use The ‘Fire Model’ When You Get Criticized At Work. Editor’s note: I am so glad I don’t have to deal with things like this. I’m probably unemployable at this point -rich. Mortman: The Queen Of Code. History FTW. Mortman (2): A Cybersecurity Wake Up Call for Emergency Managers. Rich should appreciate this one. Research Reports and Presentations Security and Privacy on the Encrypted Network. Monitoring the Hybrid Cloud: Evolving to the CloudSOC. Security Best Practices for Amazon Web Services. Securing Enterprise Applications. Secure Agile Development. Trends in Data Centric Security White Paper. Leveraging Threat Intelligence in Incident Response/Management. Pragmatic WAF Management: Giving Web Apps a Fighting Chance. The Security Pro’s Guide to Cloud File Storage and Collaboration. The 2015 Endpoint and Mobile Security Buyer’s Guide. Top News and Posts Cross Site Scripting vulnerability found in IE 11 Yet Another Flash Patch Fixes Zero-Day Flaw The Oracle of Security Flaws via LiquidMatrix Marriott Android App Left Credit Card Data Vulnerable Security Basics for Docker Who’s Hijacking Internet Routes? WiFi blocking… blocked. There could be legitimate enterprise problems with this. A CIO Perspective on Security in the Cloud U.S. Officials Say Chinese Cyberespionage ‘Needs to Stop’ Share:

Rich here. Last week I talked about learning to grind it out. Whether it’s a new race distance, or plowing through a paper or code that isn’t really flowing, sometimes you need to just put your head down, set a pace, and keep moving. And sometimes that’s the absolute worst thing to do. I have always been a natural sprinter; attracted both to sports and other achievements I could rocket through with sheer speed and power. I was horrible at endurance endeavors (physical and mental) as a kid and into my early 20’s. I mean, not “pretending to be humble horrible” but “never got the Presidential Physical Fitness thing because I couldn’t run a mile worth a crap” horrible. And procrastinating? Oh my. I had, I shit you not, a note in my file at the University of Colorado not to “cut him any breaks” because I so thoroughly manipulated the system for so long. (8 years of continuous undergrad… you make a few enemies on the way). It was handwritten on a Post-It, right on my official folder. It was in my mid-20’s that I gained the mental capacity for endurance. Mountain rescue was the biggest motivator because only a small percentage of patients fell near roads. I learned to carry extremely heavy loads over long distances, and then take care of a patient at the end. You can’t rely on endurance – we used to joke that our patients were stable or dead, since it isn’t like we could just scoop them off the road (mostly). Grinding is essential, but can be incredibly unproductive if you don’t pop your head up every now and then. Like the time we were on a physically grueling rescue, at about 11,000’, at night, in freezing rain, over rough terrain. Those of us hauling the patient out were turning into zombies, but someone realized we were hitting the kind of zone where mistakes are made, people get hurt, and it was time to stop. Like I said before: “stable or dead”, and this guy was relatively stable. So we stopped, a couple team members bunkered in with him for the night, and we managed to get a military helicopter for him in the morning. (It may have almost crashed, but we won’t talk about that.) It hadn’t occurred to me to stop; I was too deep in my inner grind, but it was the right decision. Just like the problem I was having with some code last year. It wouldn’t work, no matter what I did, and I kept trying variation after variation. I hit help forums, chat rooms, you name it. Then I realized it wasn’t me, it was a bug (this time) in the SDK I was using. Only when I tried to solve the problem from an entirely new angle, instead of trying to fix the syntax, did I figure it out. The cloud, especially, is funny that way. Function diverges from documentation (if there is any) much more than you’d think. Just ask Adrian about AWS SNS and undocumented, mandatory, account IDs. In security we can be particularly prone to grinding it out. Force those logs into the SIEM, update all the vulnerable servers before the auditor comes back, clear all the IDS alerts. But I think we are at the early edge of a massive transition, where popping our heads up to look for alternatives might be the best approach. ArcSight doesn’t have an AWS CloudTrail connector? Check out a hybrid ELK stack or cloud-native SIEM. Tired of crash patching for the next insert pseudo-cool name here vulnerability? Talk to your developers about autoscaling and continuous deployment. Every year I try to block out a week, or at least a few half-days, to sit back, focus on research, and see which of my current assumptions and work patterns are wrong or no longer productive. Call it “active resting”. I think I have come up with some cool stuff for this year, both in my work habits and security controls. Now I just need time to play with the code and configurations, to see if any of it actually works. But unlike my old patients, my code and writing seem to be both unstable and dead, so I won’t get my hopes too high. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich gave a webcast on the SaaS security lifecycle for SkyHigh Networks. Rich quoted on IoT security. Mostly about the hype. Dave Lewis on DDoS Attacks Continue To Rise in Forbes. Favorite Securosis Posts Rich: There’s a lot of hype on threat intel. Mike is doing a great job showing how to actually use the stuff, as in Applied Threat Intelligence: Use Case #2, Incident Response/Management. Mike: New Paper: Monitoring the Hybrid Cloud. Adrian and I are ahead of the general market, but if you aren’t thinking about how you will monitor cloud stuff you will be behind the curve (and the 8-ball) before long. Other Securosis Posts Incite 1/28/2015: Shedding Your Skin. Applied Threat Intelligence: Use Case #1, Security Monitoring. Firestarter: 2015 Trends. New Paper: Monitoring the Hybrid Cloud. Applied Threat Intelligence: Defining TI. Favorite Outside Posts Mortman: A complete guide to Puppy Bowl XI. Editor’s note: we need to pay more attention to how Mort spends his free time. Rich: Glenn Fleishman on the risk and problems posed by Internet connected devices. Yep, major DDoS attacks now rely on thousands of home routers. It’s an interesting (and real) scenario. Mike: Security Should Be the Top Driver for DevOps – Stormy makes a great point here: if security is going to be relevant moving forward, we had better grok and integrate these DevOps principles. Period. Research Reports and Presentations Monitoring the Hybrid Cloud: Evolving to the CloudSOC. Security Best Practices for Amazon Web Services. Securing Enterprise Applications. Secure Agile Development. Trends in Data Centric Security White Paper. Leveraging Threat Intelligence in Incident Response/Management. Pragmatic WAF Management: Giving Web Apps a Fighting Chance. The

Rich, Mike, and Adrian each pick a trend they expect to hammer us in 2015. Then we talk about it, probably too much. From threat intel to tokenization to SaaS security. And oh, we did have to start with a dig on the Pats. Cheating? Super Bowl? Really? Come on now. Watch or listen: Share:

Rich here. Last weekend I ran a local half-marathon. It wasn’t my first, but I managed to cut 11 minutes off my time and set PRs (Personal Record for you couch potatoes) for both the half and a 10K. I didn’t really expect either result, especially since I was out of running for nearly a month due to a random foot injury (although I kept biking). My times have been improving so much lately that I no longer have a good sense of my race paces. Especially b cause I have only run one 10K in the past 3 years that didn’t involve pushing about 100 lbs of kids in a jog stroller. This isn’t bragging – I’m still pretty slow compared to ‘real’ runners. I haven’t even run a marathon yet. These improvements are all personal – not to compare myself to others. I have a weird relationship with running (and swimming/biking). I am most definitely not a natural endurance athlete. I even have the 23andMe genetic testing results to prove it! I’ve been a sprinter my entire life. For you football fans, I could pop off a 4.5 40 in high school (but weighed 135, limiting my career). In lifting, martial arts, and other sports I always had a killer power to weight ratio but lacked endurance for the later rounds. While I have never been a good distance runner running has always been a part of my life. Mostly to improve my conditioning for other sports, or because it was required for NROTC or other jobs. I have always had running shoes in the closet, have always gone through a pair a year, and have been in the occasional race pretty much forever. I even would keep the occasional running log or subscription to Runners World, but I always considered a marathon beyond my capabilities, and lived with mediocre times and improvements. (I swear I read Runners World for the articles, not the pictures of sports models in tight clothes). Heck, I have even had a couple triathlon coaches over the years, and made honest attempts to improve. And I’ve raced. Every year, multiple tris, rides, and runs a year. But then work, life, or travel would interfere. I’d stick to a plan for a bit, get a little better, and even got up to completing a half-marathon without being totally embarrassed. Eventually, always, something would break the habit. That’s the difference now. I am not getting faster because I’m getting younger. I’m getting faster because I stick to the plan, or change the plan, and just grind it out no matter what. Injured, tired, distracted, whatever… I still work out. This is the longest continuous (running) training block I have ever managed to sustain. It’s constant, incremental improvement. Sure, I train smart. I mix in the right workouts. Take the right rest days and adjust to move around injuries. But I. Keep. Moving. Forward. And break every PR I’ve ever set, and am now faster than I was in my 20’s for any distance over a mile. Maybe it’s age. Maybe, despite the Legos and superhero figures on my desk I am achieving s modicum of maturity. Because I use the same philosophy in my work. Learning to program again? Make sure I code nearly every day, even if I’m wiped or don’t have the time. Writing a big paper that isn’t exciting? Write every day; grind it out. Keeping up my security knowledge? Research something new every day; even the boring stuff. Now my life isn’t full of pain and things I hate. Quite the contrary – I may be happier than I’ve ever been. But part of that is learning to relish the grind. To know that the work pays off, even those times it isn’t as fun. Be it running, writing, or security, it always pays off. And, for some of those big races, it means pushing through real pain knowing the endorphins at the end are totally worth it. That, and the post-race beers. Hell, even Michelob Ultra isn’t too bad after 13 miles. Runner’s high and all. Now I need to go run a race with Mike. He’s absolutely insane for taking up running at his age (dude is ancient). Maybe we can go do the Beer Mile together. That’s the one even Lance bailed on after one lap. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences I’m giving a webcast on managing SaaS security later this month for SkyHigh Networks. Rich quoted at TechTarget on hardware security. Favorite Securosis Posts Mike: Firestarter: Full Toddler – The disclosure battles heat up (again) and we wonder when someone is going to change Google’s diaper… Other Securosis Posts Incite 1/21/2015: Making the Habit. New Paper: Security Best Practices for Amazon Web Services. Summary: No Surprises. Incite 1/14/2015: Facing the Fear. Your Risk Isn’t My Risk (Apple Thunderbolt Edition). Friday Summary: Favorite Films of 2014 (Redux). Incite 1/7/2014: Savoring the Moment. Favorite Outside Posts Mike Rothman: Question checklist for reviewing your new marketing materials…. There is so much crappy marketing out there, especially in the security industry. Every marketeer should make sure to go through Godin’s list before sending anything out to the market. Pepper: The flood through the crack in the Great Firewall. The Iconfactory effectively DDoSed by China. Rich: Will Sharing Cyberthreat Information Help Defend the United States? Good analysis. We can’t legislate ourselves out of the cybersecurity mess, but if all we do is bitch on Twitter, we sure won’t get anywhere. Richard is one of the few trying to really engage on the issue and help navigate the complexity. Dave Lewis: 3 Problems With UK PM Cameron’s Crypto Proposal. Nope, it isn’t just in the US. Rich #2: A Spy in the Machine. This is one reason consumer privacy and security, without back doors for governments is so important. Research Reports and Presentations Security Best Practices for Amazon Web Services. Securing Enterprise Applications. Secure Agile Development. Trends in

I could probably write a book on AWS security at this point, except I don’t have the time, and most of you don’t have time to read it. So I wrote a concise paper on the key essentials to get you started – including the top four things to do in the first five minutes with a new AWS account. Here is an excerpt: Amazon Web Services is one of the most secure public cloud platforms available, with deep datacenter security and many user-accessible security features. Building your own secure services on AWS requires properly using what AWS offers, and adding additional controls to fill the gaps. Never forget that you are still responsible for everything you deploy on top of AWS, and for properly configuring AWS security features. AWS is fundamentally different from a virtual datacenter (private cloud), and understanding these differences is key for effective cloud security. This paper covers the foundational best practices to get you started and help focus your efforts, but these are just the beginning of a comprehensive cloud security strategy. The paper has a [permanent home]((https://securosis.com/research/publication/security-best-practices-for-amazon-web-services). Or you can directly download the PDF. I would especially like to thank AlienVault for licensing this paper. Remember companies that license our content don’t get to influence or steer it (outside of submitting comments like anyone else), but their support means we get to release it all for free. Share:

Yes, people, the disclosure debate is still alive and kicking. But now it is basically a pissing match between two of the largest tech companies. With Google setting rigid deadlines, and Microsoft stuck on their rigid schedule, who will win? Grab the popcorn as we talk about egos, internal inconsistencies, and why putting the user first is so damn hard. Watch or listen below: Share:

Rich here, First a quick note. I will be giving a webcast on managing SaaS security later this month. I am about to start writing more on the Cloud Security Gateway market and new techniques for dealing with SaaS. I planned to write something irreverent in this week’s Summary (like my favorite films), but it has been an odd week in the security world. I expect the consequences to play out over the next decade. I should probably write this up as a dedicated post, but my thoughts are shifting around so much that I am not sure my ideas are ready to stand on their own. Before I go into this, please keep in mind that the security ‘world’ is a collection of different groups. Tribes might be a better word. But across all subgroups we tend to be skeptical and critical. That is quite healthy, considering what we do, but can easily turn negative and self-defeating. This is especially true when we engage with society at large. We are, on the whole, the pain-in-the-ass cousin who shows up at the holidays and delights in challenging and debating the rest of the family long past the point where anyone else cares. Yeah, we get it, you caught me in a logical fallacy because I like my new TV but bitched at you for not recycling your beer cans. You win. Now pass the stuffing and STFU. Also factor in our inherent bias against anyone who does things others don’t understand. (Hat tip to Rob Graham for first introducing me to this concept). We have a long lineage that looks something like heretic > witch > egghead > nerd > geek > hacker. No, not everyone reading this is a hacker, but society at large cannot really differentiate between specific levels of technical wizardry. This is especially true for those of you who play with offensive security, no matter how positive your contributions. Back to the main story, which is shorter than all this preamble. This week the White House proposed some updates to our computer security laws. Some good, some bad. The Twitter security echo chamber exploded a bit, with much hand-wringing over how this could lead to bad legal consequences – not only for anyone working legitimately in offensive security; it could also create all sorts of additional legal complexities with chilling effects. There are actually a bunch of proposals circulating, which would affect not only cybersecurity but general Internet usage. From the UK wanting to ban encryption, to mandating DNSSEC, to the FBI wanting to ban effective encryption, to… well, everyone wanting to ban encryption, file sharing, and… stuff. Many in the security world seem to feel we should have some say over these laws and policies. But we have mostly seen vendors lobby to have their products mandated (and then shrug when people using them get hacked), professional groups pushing to have their training or certifications mandated, and the occasional researcher treated like a dancing monkey for the cameras. And political leaders probably don’t see much distinction between any of these and the big Internet protests that their Hollywood funders all tell them are just criminals who want to watch movies free. We have mostly done this to ourselves. We are fiercely independent, so it isn’t like we speak with a single voice. We can’t even decide what constitutes a “security professional”. Then we keep shooting ourselves in the foot by demanding evidence from law enforcement and intelligence agencies on things like the Sony hack. And, er, telling the FBI they are wrong rarely works out well. I am not telling anyone not to do or say what they want. Just keep in mind how the world views you (as witches), and how much technology just scares people, no matter how much they love their iPhones. And if you want to affect politics you need to play politics. Twitter ain’t gonna cut it. Seriously, no one likes that smarty-pants cousin (or in-law, in my case). And if any lobbyists are reading this, please fix the Kinderegg ban first, then get started on defending encryption. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences As I mentioned, I am presenting on managing SaaS security on the 29th. Favorite Securosis Posts Mike Rothman: Your Risk Isn’t My Risk. It is always important to consider likelihood when looking at new attacks. Rich puts the latest in context. Rich: Incite 1/14/2015: Facing the Fear. Because that was my only other choice. I mean, it’s still a good post, but it isn’t like I had an option. Other Securosis Posts And now you see why I had to pick Mike’s post. Favorite Outside Posts Adrian Lane: The importance of deleting old stuff. Honestly, it’s not as valuable as you think, and it is likely to cause harm in the long run. Mike Rothman: The Stunning Scale of AWS. I remember Rich mentioning some of these stats after he got back from the AWS conference in 2013. It is shocking to see this documented, and to understand that when trying to really scale something… commercial products just won’t cut it. Really interesting. Rich: Encryption is Not the Enemy. Dennis lays it out nicely, not that I expect the latest round of crypto wars to end any time soon. Research Reports and Presentations Securing Enterprise Applications. Secure Agile Development. Trends in Data Centric Security White Paper. Leveraging Threat Intelligence in Incident Response/Management. Pragmatic WAF Management: Giving Web Apps a Fighting Chance. The Security Pro’s Guide to Cloud File Storage and Collaboration. The 2015 Endpoint and Mobile Security Buyer’s Guide. Analysis of the 2014 Open Source Development and Application Security Survey. Defending Against Network-based Distributed Denial of Service Attacks. Reducing Attack Surface with Application Control. Top News and Posts Obama’s War on Hackers. Money quote: “This War on Hackers is likely to be no more effective than the War on Drugs”. Gitrob Combs Github Repositories for Secret Company Data. Looks super useful. President

Last Friday I wrote an article on the Thunderstrike proof of concept attack against Macs. I won’t spend any more time analyzing it but I think it’s valuable as an example of risk assessment. The short version is… it’s a creative attack that, if you have physical access to a Mac, could allow you to completely compromise it by merely connecting external hardware and triggering a reboot. The attack is against the firmware, and even removing the Mac’s hard drive leaves it infected. The Thunderstrike proof-of-concept takes advantage of this trust to replace the contents of the Mac’s boot ROM with the attacker’s own code, effectively embedding it into the Mac’s hardware and making it impossible to remove using standard techniques. The attack works because Apple relies on software checks to confirm the firmware is valid, and Hudson developed techniques to circumvent those checks (and even replace the encryption key). Apple is taking this seriously; it is already fixed on new hardware (Retina iMacs and new Mac Minis), and a further fix for older hardware is coming soon according to my sources (sooner than you probably think). But that is only a partial fix because an attacker can still downgrade the firmware and then execute the attack, although that doubles the time requirement. In my article I made clear that very few people need to worry about this now: While all Macs are technically vulnerable to the Thunderstrike attack, few TidBITS readers face any immediate risk. The attack is highly targeted – someone needs both physical access to your Mac and time to reboot it and reinstall the firmware. On top of that, it isn’t like everyone is walking around with maliciously modified Thunderbolt dongles. So why write it up? Why talk about an attack that has to be designed for the specific hardware version you are using, requires physical control of your device, and can’t realistically spread on any wide basis? Because I’m at risk, as are many readers here at Securosis. For the TidBITS crowd I mostly wanted to assuage concerns and compensate for the usual spate of over-hyped stories. For Securosis? Some of you need to worry. I have direct reports of executives and security pros being compromised when their hardware leaves their control; typically when traveling internationally, usually to one of a few countries. (Make that mostly one country). BTW, I don’t have any reports of these attacks on Macs, and I am very interested if you have a confirmed report, even if you can’t provide details. Starting in about 2008 I started paying a lot more attention to physical control over my computers and mobile devices under certain circumstances (I am not counting hacker conferences – I have always kept hard control at those). The reports coming in from clients indicated that customs and hotel rooms were not safe places to lose physical control. I even stopped traveling to China with devices I was worried about, which did inhibit my ability to get work done while there. Thunderstrike itself isn’t a big deal. It’s super interesting, but damn low on the risk list. Mostly. As a proof of concept it is incredibly educational, and some of you, especially readers of this site, need to pay attention to these kinds of attacks (for yourselves or your organizations). That’s why I like this story as a good example of understanding risk. For one publication, TidBITS, I wrote it up to debunk fear. For another, here, I am writing it up as a warning of real risk, if you fall into the right bucket. [Ed: The presentation is also remarkably readable – much easier to understand than I expected for something this complicated. –cp] Share: