Research

As much as it pained me, Friday morning I slipped out of my house at 3:30am, drove to the nearest Apple Store, set up my folding chair, and waited patiently to acquire an iPhone 5s. I was about number 150 in line, and it was a good thing I didn’t want a gold or silver model. This wasn’t my first time in a release line, but it is most definitely the first time I have stood in line since having children and truly appreciated the value of sleep. It wasn’t that I felt I must have new shiny object, but because, as someone who writes extensively on Apple security, I felt it was important to get my hands on a Touch ID equipped phone as quickly as possible, to really understand how it works. I learned even more than I expected. The training process is straightforward and rapid. Once you enable Touch ID you press and lift your finger, and if you don’t move it around at all the iPhone prompts you to slightly change positioning for a better profile. Then there is a second round of sensing the fringes of your finger. You can register up to five fingers, and they don’t have to all be your own. What does this tell me from a security perspective? Touch ID is clearly storing an encrypted fingerprint template, not a hashed one. The template is modified over time as you use it (according to Apple statements). Apple also, in their Touch ID support note, mentions that there is a 1 in 50,000 chance of a match of the section of fingerprint. So I believe they aren’t doing a full match of the entire template, but of a certain number of registered data points. There are some assumptions here, and some of my earlier assumptions about Touch ID were wrong. Apple has stated from the start that the fingerprint data is encrypted and stored in the Secure Enclave of the A7 chip. In my earlier Macworld and TidBITS articles I explained that I thought they really meant hashed, like a passcode, but I now believe not only that I was wrong, but that there is even more to it. Touch ID itself is insanely responsive. As someone who has used many fingerprint scanners before, I was stunned by how quickly it works, from so many different angles. The only failures I have are when my finger is really wet (it still worked fine during a sweaty workout). My wife had more misreads after a long bath when her skin was saturated and swollen. This is the future of unlocking your phone – if you want. I already love it. I mentioned that the fingerprint template (Apple prefers to call it a “mathematical representation”, but I am sticking with standard terms) is encrypted and stored. I believe that Touch ID also stores your device passcode in the Secure Enclave. When you perform a normal swipe to unlock, then use Touch ID, it clearly fills in your passcode (or Apple is visually faking it). Also, during the registration process you must enter your passcode (and Apple ID passwords, if you intend to use Touch ID for Apple purchases). Again, we won’t know until Apple confirms or denies, but it seems that your iPhone works just like normal, using standard passcode hashing to unlock and encrypt the device. Touch ID stores this in the Secure Enclave, which Apple states is walled off from everything else. When you successfully match an enrolled finger, your passcode is loaded and filled in for you. Again, assumptions abound here, but they are educated. The key implication is that you should still use a long and complicated passcode. Touch ID does not prevent brute-force passcode cracking! The big question is now how the Secure Enclave works, and how secure it really is. Based on a pointer provided by James Arlen in our Securosis chat room, and information released from various sources, I believe Apple is using ARM TrustZone technology. That page offers a white paper in case you want to dig deeper than the overview provides, and I read all 108 pages. The security of the system is achieved by partitioning all of the SoC hardware and software resources so that they exist in one of two worlds – the Secure world for the security subsystem, and the Normal world for everything else. Hardware logic present in the TrustZone-enabled AMBA3 AXI(TM) bus fabric ensures that Normal world components do not access Secure world resources, enabling construction of a strong perimeter boundary between the two. A design that places the sensitive resources in the Secure world, and implements robust software running on the secure processor cores, can protect assets against many possible attacks, including those which are normally difficult to secure, such as passwords entered using a keyboard or touch-screen. By separating security sensitive peripherals through hardware, a designer can limit the number of sub-systems that need to go through security evaluation and therefore save costs when submitting a device for security certification. Seems pretty clear. We still don’t know exactly what Apple is up to. TrustZone is very flexible and can be implemented in a number of different ways. At the hardware level, this might or might not include ‘extra’ RAM and resources integrated into the System on a Chip. Apple may have some dedicated resources embedded in the A7 for handling Touch ID and passcodes, which would be consistent with their statements and diagrams. Secure operations probably still run on the main A7 processor, in restricted Secure mode so regular user processes (apps) cannot access the Secure Enclave. That is how TrustZone handles secure and non-secure functions sharing the same hardware. So, for the less technical, part of the A7 chip is apparently dedicated to the Secure Enclave and only accessible when running in secure mode. It is also possible that Apple has processing resources dedicated only to the Secure Enclave, but either option still looks pretty darn secure. The next piece is the hardware. The Touch ID sensor itself may be

Hackers at the Chaos Computer Club were the first to spoof Apple’s Touch ID sensor. They used existing techniques, but at higher resolution. A quick response: The technique can be completed with generally available materials and technology. It isn’t the sort of thing everyone will do, but there is no inherent barrier to entry such as high cost, special materials, or super-special skills. The CCC did great work here – I just think the hype is a bit off-base. On the other hand, Touch ID primarily targets people with no passcodes, or 4-digit PINs. It is a large improvement for that population. We need some perspective here. Touch ID disables itself if the phone is rebooted or you don’t use Touch ID for 48 hours (or if you wipe your iPhone remotely). This is why I’m comfortable using Touch ID even though I know I am more targeted. There is little chance of someone getting my phone without me knowing it (I’m addicted to the darn thing). I will disable Touch ID when crossing international borders and at certain conferences and hacker events. Yes, I believe if you enable Touch ID it could allow law enforcement easier access to your phone (because they can get your fingerprint, or touch your finger to your phone). If this concerns you, turn it off. That’s why I intend to disable it when crossing borders and in certain countries. As Rob Graham noted, you can set up Touch ID to use your fingertip, not the main body of your finger. I can confirm that this works, but you do need to game the setup a little. Your fingertip print is harder to get, but still not impossible. Not all risk is equal. For the vast majority of consumers, this provides as much security as a strong passcode with the convenience of no passcode. If you are worried you might be targeted by someone who can get your fingerprint, get your phone, and fake out the sensor… don’t use Touch ID. Apple didn’t make it for you. PS: I see the biggest risk for Touch ID in relationships with trust issues. It wouldn’t shock me at all to read about someone using the CCC technique to invade the privacy of a significant other. There are no rules in domestics… Share:

I am psyched to announce that our Black Hat Vegas class went well, and we have been invited to teach in Seattle December 9-10 and 11-12. As before, we will be bringing some advanced material, but you shouldn’t be scared off – advanced skillz are not required to make it through the class. You can sign up for the class here. The short description is: CLOUD SECURITY PLUS (CCSK-Plus) Provide students with the practical knowledge they need to understand the real cloud security issues and solutions. The Cloud Security Plus class provides students a comprehensive two-day review of cloud security fundamentals and prepares them to take the Cloud Security Alliance Certificate of Cloud Computing Security Knowledge (CCSK) exam (this course is also known as the CCSK-Plus). Starting with a detailed description of cloud computing, the course covers all major domains in the latest Guidance document from the Cloud Security Alliance, and includes a full day of hands-on cloud security training covering both public and private cloud. Share:

I had a really great Friday Summary planned. I was going to go all in-depth and metaphysical on something really important, with a full-on “and knowing is half the battle” conclusion at the end, tying it back to security and making you reevaluate your life. That was before my 6-month-old decided to go to bed after 11pm, then wake up at 3am, and not go back to sleep until 5:15am. Followed by my 4.5-year-old waking me up at 6am because, although she knew it was too early, I forgot to put the iPad that she is allowed to watch until it’s time to wake us up in her room. Then there was the cat. That f***ing cat. (It was my turn to take the baby… he had already wrecked my wife the nights before). So someone is reevaluating their life, but it isn’t you. Instead, I’m going to emulate Adrian: here is my stream of consciousness… Residential alarm companies don’t really like hackers/tinkerers. I have some extensive home automation and I want to pull alerts out of my alarm panel (without enabling control) to trigger certain things and use the sensors. The phone calls tend not to go well. They all have home automation packages they will gladly sell me, and usually after the third time I tell them I have thousands of dollars and tons of custom programming of my own system they finally get it. None of them want to let you access the panel you pay for because they are legitimately worried about false alarms. Can’t really blame them – I wouldn’t trust me either. I finally added some security cameras, mostly to watch the kids outside in the play pool when I have to run inside for my morning… constitutional. I’d like to put some in the play areas but I don’t like how intrusive they look. Need to figure that out. There is a bobcat in our neighborhood. It’s living in the yard of a house that has been effectively abandoned for 3 years because no one seems to know who actually owns or is responsible for it. The bank would sure like the cash, but doesn’t want to deal with maintenance. I smell one of those improperly handled mortgage paperwork situations. The bobcat has cubs and seems quite content to bounce around our backyards. Many neighbors are scared of it, despite, you know, scientific evidence. I mentioned on our community forum that their kids should be safe unless they leash the babies to a stake out in a backyard – that may not work out well. A bunch of neighbors would also like to gate our community due to a mild uptick in break-ins (the other reason for the alarm and camera updates). That would involve about 50 unmanned gates for 900 homes and 6,752 landscapers with keys, judging from the 24/7 blower noises around here. Seriously, we would have to give gate codes to easily over 10K people over the course of the first year. Then there is the maintenance, and if you gate a community you need to take over street maintenance. And there is no evidence that unmanned gates reduce crime. I live with a lot of very scared upper-middle-class people. Other people want to slather cameras all over our community. They don’t understand that no one watches them. Someone thought we would have a control center like a casino or something with security calling in drone strikes for suspicious vehicles. (I consider them a mild deterrent at best, and mostly useful for me to keep an eye on the kids when I need to take my morning constitutional). I mean cameras are mild deterrents – a few drone strikes would probably be pretty effective. Me? I think for a fraction of the long-term cost of either option we could hire additional security and off-duty police patrols. Incident response and active defense, baby! My 4.5-year-old and her best friend have decided which boys they are going to marry. In related news, I will be shopping for a gun safe this weekend. The new Lego Mindstorms EV3 is amazing. I’m a long-time fan of Lego robots, and this one is far more accessible to my young kids due to the ball shooter and iPhone/iPad control. I still need to do all the building and programming, but I’m working on getting them to tell me what they want it to do and break that down into discrete steps. They want me to build an “evil robot” so they can put on their super hero clothes and battle it. The 4.5-year-old has a nice Captain America shield (she was pissed the first time she threw it, because it didn’t come back), and the 3-year-old has a cool Fisher Price Spider-Man web shooter thing. Both girls, both started on super hero kicks without my influence, and both are totally awesome. That’s all I got. Go buy Legos, watch out for bobcats, and don’t get involved in your community security program unless you want to realize how nice our infosec world is in comparison. Seriously. One last note – good luck to everyone in Boulder. It’s very hard to watch the floods from the outside, but still a hell of a lot easier than what you all are going through. Stay safe! On to the Summary. To be honest, due to the lack of sleep and my family walking in the door, it’s be a bit light this week… On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich presenting on cloud encryption next week. Rich wrote two articles on Apple’s Touch ID fingerprint sensor. You can read them at Macworld and TidBITS. They were both referenced by a ton of sites. Rich also quoted on Touch ID at the Wall Street Journal. Cloud IAM webcast next week: Check it out! Adrian’s DR post on PII and Entitlement Management. Another DR piece from Mike on “Talking Threats with Senior Management”. Mike’s latest DR column on the million bot network. Mike quoted

We received an email tip today that Oracle added a new security feature to Java that might be pretty important (awaiting confirmation that I can publicly credit the person who sent it in): Deployment Rule Set is a new security feature in JDK 7u40 that allows a system administrator to control which applets or Java Web Start applications an end user is permitted to execute and which version of the Java Runtime Environment (JRE) is associated with them. Deployment Rule Set provides a common environment to manage employee access in a controlled and secure manner. Clearly it depends on how easy it is to circumvent, and I don’t even hope it will stop advanced attacks, but it does seem like it might help if you put the right policy set in place. More details are available. Share:

I am still putting my personal thoughts together on the recent NSA revelations. The short version is that when you look at it in the context of developments in vulnerability disclosure and markets, we are deep into a period of time where our benign government has actively undermined the security of citizens, businesses, and even other arms of government, at scale, in order to develop and maintain offensive capabilities. (Yes, I’m a patriotic type who considers our government benign). They traded one risk for another, with the assumption that the scale and scope of their activities would remain secret. Now that they aren’t, we will see a free for all. That’s why I am even writing about this on Securosis. Those of us in security need to prepare for both system/design vulnerabilities and specific implementation flaws. We may have to replace hardware, as foreign governments and criminals find these flaws (they will). I don’t believe this was done maliciously. It appears to be mission creep as individual units worked towards their mission without considering the overall implications. Someone at the top decided it was better to leave us exposed to widespread exploitation than lose monitoring capabilities and miss another terrorist attack (these programs existed to some degree before 9/11, but clearly have exploded since then). It was a calculated risk decision. One I may not agree with, but can sympathize with. But the end result is that we may be in the first days of cleaning up some very fundamental messes. Now that we have direct evidence, the risks of external attack have increased for organizations and consumers. The issue has gone beyond monitoring and data collection to affect every security professional, and our ability to do our jobs. Share:

PCWorld/TechHive has a very clear article on how to deal with a Twitter hack. Print it out and keep it handy, especially if you manage a corporate account. If you are very big get a phone number for Twitter security, make contact, and add it to your IR plans. Share:

I am in a bit of a pickle, and could use some advice. Over the time I have been an analyst, I have learned that it is important to have the right distribution of research. My rule of thumb is 80-90% of it should be practical research to help people get their jobs done on a daily basis. Then you can spend 10-20% on future research that I promise not to call thought leadership. Many analysts (and other pundits) fall into an esoteric trap, where they are so desperate to be seen as leaders that their research becomes more about branding and marketing, and less about helping people get their jobs done. It is totally fine to tilt at the occasional windmill, but everything in moderation. The corollary is that once you focus on the future too much you disconnect from the present and lose your understanding of current technologies and trends, and your subsequent predictions are based on reading science fiction and bad tech media articles. Those aren’t worth the bits they are printed on. And yeah, there is a lot of that going around. Always has been, especially in conference keynotes. This isn’t merely for ego gratification. On the business side you can’t survive long by selling research that doesn’t help someone get their job done. Many of my former Gartner colleagues lose track of this because they think people like their new “connected enterworld” junk, as opposed to paying for Magic Quadrants so they don’t lose their jobs when they buy something in the upper-right quadrant that doesn’t work. For a small firm like us, screw up the mix and it’s back to truck driving school. My dilemma is that a lot of the research I’m working on appears to be ahead of the general market, but still very practical and usable. I am thinking specifically of my work on Software Defined Security and DevOps. It’s the most fulfilling research I have done in a long time, especially because it gets me back to coding – even at a super-basic level. But I am borderline tilting at windmills myself – relatively few organizations are operationally ready for it. So it isn’t a load of hand-waving bullpoop – it is all real and usable today – but not for many organizations that lack the time or resources to start integrating these ideas. Not everyone has free time to play with new things. Especially with all the friggin’ auditors hanging over your head. Anyway, I have been bouncing this off people since Black Hat and am interested in what you folks think. I would love to make a go of it and have at least half my research agenda filled with using APIs, securing cloud management planes, integrating security into DevOps, and the like, but only if there is real interest out there – I gotta pay the bills. Drop me a line at rmogull at securosis dot com if you have an opinion, or leave a comment on this post. Thanks, and on to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Mike’s DDoS research quoted in the Economist… Really. Security issues are clearly becoming mass market news. Mike quoted in Dark Reading about Websense’s free CSO advisory offering. Don’t Be The Tortoise. Rich digs into his old book of parables at Dark Reading to point out that: “Agility may not always win the race, but you sure shouldn’t bet against it.” Incentives and Organizational Alignment (Or Lack Thereof). Mike’s latest Dark Reading column on Vulnerabilities and Threats. Rich on Threatpost – How I Got Here. I got to do my third favorite thing, talk about myself. Dave Mortman on Big Data Security Challenges. Rich’s piece on Apple’s security design quoted in a Techpinions article. Dave Lewis at CSO Online: Innovation And The Law Of Unintended Consequences. And more of Mr. Lewis: My (ISC)2 Report Card. Favorite Securosis Posts Mike Rothman: The future of security is embedded. Gunnar weighs in on our little blog ‘discussion’ about how to prove value in a security operation. And no, I don’t really think Rich and I were arguing. Rich: Random Thought: Meet Your New Database. Some trends are real. Both Adrian and I, former DBAs and developers, would likely go non-relational with our next projects. Mort: PCI 3.0 is coming. Hide the kids. Other Securosis Posts Tracking the Syrian Electronic Army. Third Time is the Charm. Security is Reactive. Learn to Love It. Deming and the Strategic Nature of Security. Incite 8/27/2013: You Can’t Teach Them Everything. Reactionary Idiot Test. VMWare Doubles Down on SDN. China Suffers Large DNS DDoS Attack. Friday Summary: August 23, 2013. “Like” Facebook’s response to Disclosure Fail. Research Scratchpad: Stateless Security. New Paper: The 2014 Endpoint Security Buyer’s Guide. Incite 8/21/2013: Hygienically Challenged. Two Apple Security Tidbits. Ecosystem Threat Intelligence: Use Cases and Selection Criteria. Ecosystem Threat Intelligence: Assessing Partner Risk. Favorite Outside Posts Mike Rothman: Innovation and the Law of Unintended Consequences. Dave has been killing it in his CSO blog. This latest one deals with the fact that until we can do security fundamentals well, dealing with all of these shiny innovative security objects is like moving deck chairs on the Titanic. David Mortman: ITIL vs. DevOps: Slugfest or Lovefest? Rich: Dark Patterns: inside the interfaces designed to trick you. Really great design stuff. Research Reports and Presentations The 2014 Endpoint Security Buyer’s Guide. The CISO’s Guide to Advanced Attackers. Defending Cloud Data with Infrastructure Encryption. Network-based Malware Detection 2.0: Assessing Scale, Accuracy and Deployment. Quick Wins with Website Protection Services. Email-based Threat Intelligence: To Catch a Phish. Network-based Threat Intelligence: Searching for the Smoking Gun. Understanding and Selecting a Key Management Solution. Building an Early Warning System. Implementing and Managing Patch and Configuration Management. Top News and Posts New York Times DNS Hacked. Android malware WAY worse than iOS. Russian spyboss brands Tor a crook’s paradise, demands a total ban. Obama administration asks court to force NYT reporter to reveal source. Amazon ‘wish list’ is gateway to epic social engineering hack. Former White House ‘copyright czar’

Brian Krebs is digging into the SEA and trying to out individuals: A hacking group calling itself the Syrian Electronic Army (SEA) has been getting an unusual amount of press lately, most recently after hijacking the Web sites of The New York Times and The Washington Post, among others. But surprisingly little light has been shed on the individuals behind these headline-grabbing attacks. Beginning today, I’ll be taking a closer look at this organization, starting with one of the group’s core architects. He’s just getting started, and his techniques wouldn’t stand forensic or legal scrutiny, but are still very interesting. Very similar to the stuff Mandiant dug up on Chinese hackers. Everyone leaves tracks. Everyone. Share:

Few things make me happier than getting to publicly disagree with one of my coworkers. Earlier today Mike suggested that security is too reactive and tactical to succeed. Then we hear the usual platitudes about treating security as a risk management function, better metrics, blah blah blah. Not that there is anything wrong with all that, but it needs to be discussed in context of the fundamental nature of security. Which is an ongoing state of disruptive innovation. Security is reactive by nature – the moment it isn’t is the moment you really lose. The question is how to best provide yourself with the most time to plan your reactions, and what kind of infrastructure you can put in place to reduce the cost and complexity of any course corrections. Business innovation tends to result from three primary drivers: Competitive response. A competitor does something; you need to respond to stay in the game. Competitive advantage. You do something to gain an edge, and force others to respond. Efficiency/effectiveness. You streamline and improve your processes to reduce overhead. But security only shares one of those drivers. Security innovation is dominated by externalities: Business innovation. The business does something new, so you need to respond. Attacker innovation. Internal efficiency/effectiveness. “Doing security better”. Two of the three forces on a business are internal, with only competitive response driven by an outside actor. Security flips that. We can’t ever fully predict what the business or attackers will do down the road, so we need to scramble to react. That’s why we can never seem to skate ahead of the puck. You can’t skate ahead of a quantum field state that will eventually collapse into a single wave function – there are too many options to choose one. The trick, as Chris Hoff and I have been talking about at RSA for about 6 years now, is to take a strategic approach to prediction. This is why even a risk-based security approach is, in reality, just another tactical piece. The strategic piece is building a methodology to inform your working assumptions for what the future holds, and building your program to respond quickly once a direction is set. It isn’t magic, and some of you do this intuitively. You stay up to date on the latest research, both in and out of security. You track both new attack and general technology trends. You engage heavily with the business to understand their strategic direction before they make the tactical technology choices you later have to secure. A lot of this looks almost identical to Mike’s recommendations, but the reason organization after another fails in their risk-based, metrics-driven, incident response programs is they to and run them in a bubble, and assume situations are static on at least an annual basis. If you build your program assuming everything will change underneath you, you will be in much better shape. And I absolutely believe this is a realistic and pragmatic goal that others have achieved. Share: