Research

I hope everyone enjoyed the holidays… just in time to return to work, catch up on email, and watch the entire Internet burn down thanks to a cluster of hardware vulnerabilities built into pretty much every computing platform available. I won’t go into details or background on Meltdown and Spectre (note: if I ever discover a vulnerability, I want it named “CutYourF-ingHeartOutWithSpoon”). Instead I want to talk about them in the context of the cloud, short-term and long-term implications, and some response strategies. These are incredibly serious vulnerabilities – not only due to their immediate implications, but also because they will draw increased scrutiny to a set of hardware weaknesses, which in turn are likely to require a generational fix (a computer generation – not your kids). Meltdown Briefly, Meltdown increases the risk of a multi-tenancy break. This has impacts on three levels: It potentially enables any instance or guest on a system to read all the memory on that system. This is the piece which cloud providers have almost completely patched. On a single system, it could also allow code in a container to read the memory of the entire server. This is likely also patched by cloud providers (AWS/Google/Microsoft). Because Function as a Service (‘serverless’) offerings are really implemented as code in containers, the same issues apply to these products. Meltdown is a privilege escalation vulnerability and requires a malicious process to be run on the system – you cannot use it to gain an initial foothold or exploitation, but to do things like steal secrets from memory once you have presence. Meltdown in its current form on major cloud providers is likely not an immediate security risk. But just to be safe I recommend immediately applying Meltdown patches at the operating system level to any instances you have running. This would have been far worse if there hadn’t been a coordinated disclosure between researchers, hardware and operating system vendors, and cloud providers. You may see some performance degradation, but anything that uses autoscaling shouldn’t really notice. Spectre Spectre is a different group of vulnerabilities which relies on a different set of hardware-related issues. Right now Spectre only allows access to memory the application already has access to. This is still a privilege escalation issue because it’s useful for things like allowing hostile JavaScript code in a browser access to data outside its sandbox. This also seems like it could be an issue for anything which runs multiple processes in a sandbox (such as containers), and might allow reading data from other guests or containers on the same host. Exploitation is difficult, the cloud providers are on it, and there is nothing to be done right now – other than to pay attention. So for both attacks, your short-term action is to patch instances and keep an eye on upcoming patches. Oh – and if you run a private cloud, you really need to patch everything yesterday and be prepared to replace all your hardware within the next few years. All your hardware. Oops. Long-term implications and recommendations These are complex vulnerabilities related to deeply embedded hardware functionality. Spectre itself is more an entire vulnerability/exploit class than a single patchable vulnerability. Right now we seem to have the protections we need available, and the performance implications appear manageable (although the performance impact will be costly for some customers). The bigger concern is that we don’t know what other variants of both vulnerability classes may appear (or be discovered by malicious actors who don’t make them public). The consensus among my researcher friends is that this is a new area of study; while it’s not completely novel, it’s definitely drawing highly intelligent and experienced eyeballs. I will be very surprised if we don’t see more variants and implications over the next few years. Hardware manufacturers need to update chip designs, which is a slow process, and even then they are likely to leave holes which researchers will eventually discover. Let’s not mince words – this is a very big deal for cloud computing. The immediate risk is very manageable but we need to be prepared for the long-term implications. As this evolves, here is what I recommend: Obviously, immediately patch all your operating systems on all your instances to the best of your ability. Hopefully cloud provider mitigations at the hypervisor level are already protecting you, but it’s still better to be safe. Start with a focus on instances where memory leaks are the worst threat. For highly sensitive workloads (e.g., encryption) immediately consider moving to dedicated tenancy and don’t run any less-privileged workloads on the same hardware. Dedicated tenancy means you rent a whole box from your cloud provider, and only your workloads run on it. This eliminates much of the concern of guest to host breaks. Migrate to dedicated PaaS where possible, especially for things like encryption operations. For example if you move to an AWS Elastic Load Balancer and perform discrete application data encryption in KMS, your crypto operations and keys are never exposed in the memory of any general-purpose system. This is the critical piece: the hardware underpinning these services isn’t used for anything other than the assigned service. So another tenant cannot run a malicious process to read the box’s physical memory. If you can’t run malicious code as a tenant, then even if you break multi-tenancy you still need to compromise the entire system – which cloud providers are damn good at preventing. Removing customers’ ability to run arbitrary processes is a massive roadblock to exploitation of these kinds of vulnerabilities. Continue to migrate workloads to Function as a Service (also called ‘serverless’ and ‘Lambda’), but recognize there still are risks. Moving to servlerless pushes more responsibility for mitigating future vulnerabilities in these (and any other) classes onto your cloud provider, but since tenants can run nearly arbitrary code there is always a chance of future issues. Right now my feeling is that the risk is low, and far lower than running things

The gang almost makes it through half the episode before dropping some inappropriate language as they summarize 2017. Rather than focusing on the big news, we spend time reflecting on the big trends and how little has changed, other than the pace of change. How the biggest breaches of the year stemmed from the oldest of old issues, to the newest of new. And last we want to thank all of you for all your amazing support over the years. Securosis has been running as a company for a decade now, which likely scares all of you even more than us. We couldn’t have done it without you… seriously. Share:

This week Mike and Rich address the recent spate of operational fails leading to massive security breaches. This isn’t yet another blame the victim rant, but a frank discussion of why these issues are so persistent and so difficult to actually manage. We also discuss the rising role of automation and its potential to reduce these all-too-human errors. Watch or listen: Share:

Every year, as I travel the security conference circuit, hallway conversations always turn to, “See anything interesting?”. To be honest, I can’t remember the last time I was excited about an honestly cool security technology (which I didn’t create myself, but let’s not go there today). I see plenty of cloud innovation, and plenty of security evolution, but not a lot of revolution. A week ago I picked up my iPhone X. Although I received a background brief on Face ID a couple weeks earlier, I hadn’t gotten my hands on it until then. And, really, didn’t get to play with it until the next day after spending 5 hours restoring my data (all 200 GB of it). Face ID is the most compelling security advance I have seen in a very long time. It’s game-changing not merely due to technology, but also thanks to design and implementation. Apple has created a new authentication modality. First things first: Face ID nails nearly every criteria I came up with to evaluate it. The false positive rate, within certain genetic constraints, is 1 in a million compared, to 1 in 50,000. The inherent security architecture doesn’t look quite as tied to hardware as Touch ID (because the phone needs the sensor package for other capabilities), but does appear to be either as strong (including the software implementation) or close enough in practical circumstances. Watch enough videos of journalists buying masks of their own faces, and it’s clear Face ID is more expensive to circumvent than Touch ID. We haven’t actually seen a public crack yet, but I always assume it will happen eventually. Because history. Apple sometimes has a weak spot underestimating adversaries in their threat models, but they did a good job on this one. In my pre-release article I wrote: Face ID doesn’t need to be the same as Touch ID – it just needs to work reasonably equivalently in real-world use. In my personal experience, and with every user I’ve talked with and in every article I’ve read, Face ID’s core usability is equal to or greater than Touch ID’s. For example, it doesn’t work as well at many angles you could touch your phone from, but it works better in the kitchen and after a shower/workout. I’ve tested it in all sorts of lighting conditions and haven’t found one that trips it up yet. The only downside is I can’t register my wife’s face, and we were become accustomed to using Touch ID on each other’s devices. I do believe it’s slower at actual recognition, but it’s nearly impossible to notice due to the implementation. Face ID is tightly bound to activity, which masks its latency. For example, the time to swipe your fingers is long enough to unlock, where with Touch ID recognition and unlocking were the same action, which made the latency more visible. But I think it’s time to justify that hyperbolic headline. Apple didn’t just throw a facial recognition sensor into the iPhone and replace a fingerprint sensor – they enabled a new security modality. I call this “continuous authentication”. When you use an iPhone you look at the iPhone (some calls and music listening excepted). Instead of unlocking your iPhone once and opening up everything, or requiring you to put your finger on the sensor when an app or feature wants to re-authenticate, the phone can quickly scan your face on demand. And the iPhone does this constantly. Here are the examples I’ve discovered so far: It’s already been widely reported that notification, by default, don’t show details on the lock screen until you look at the iPhone. This is my favorite new feature because it improves security with effectively zero usability impact. I always disabled Control Center on the lock screen for security reasons, but like notifications, just looking at my phone unlocks it. It’s just too bad my thumb can’t reach that upper right corner. Safari now (optionally) uses Face ID before filling in passwords on web sites. Previously, even with Touch ID, they filled in automatically when the phone was unlocked. Apple Pay and the App Store now authenticate with your face without separate authentication actions. Apps can authenticate as you open them. This is where I notice that Face ID is a likely bit slower, but because I don’t need to take another action it feels faster. The lock screen and Safari passwords are, to my knowledge, legitimately new modalities. The others are evolutions of previous use cases. Face ID allows your iPhone to authenticate you under nearly every circumstance you would use your phone and need to authenticate, but without requiring any user action. I think we are just scratching the surface of what’s possible here. Yes, we’ve used tools like Yubikeys plugged into devices to keep sessions open, but I think it’s clear how this is different. This is just the first generation of Face ID. Imagine the use cases once it evolves and can, for example, register multiple users. My Xbox Kinect (may it rest in peace) already does this pretty well, so we know it’s possible (Kinect’s implementation is as secure, and it’s a lot bigger). One of the biggest problems in healthcare security is quickly authenticating to shared workstations in clinical environments… I could see a future version of Face ID significantly addressing that problem. I previously said that Touch ID enables you to use a strong password with the convenience of no password at all. Face ID not only exceeds that mark, it may be the ultimate expression of it, by deeply integrating effortless authentication throughout the user experience without requiring new behaviors. That, my friends, is the power of security design, not just security engineering. Share:

About a year ago I first heard the dreaded acronym “MVC”. It was during a call about a potential project, and this contact kept namedropping it like Kanye or something – not that I knew what it meant at the time. I kept wondering how Model/View/Controller was so important to their deployment. Eventually I learned it stands for “Minimum Viable Cloud”. I want to take whichever consultant came up with that concept, dip them in chocolate, and toss them into a bear preserve. In the spring. Say around March or April. I’ve been hearing it more frequently since then, and here’s what it means, why I think it is a stupendously terrible idea, and a better alternative. Note that I don’t assume MVC is universally defined or understood – it seems to be more of a catchall term designed to assuage cloud fears while driving big consulting projects. The general consensus seems to be that you predefine and build your cloud environment, then shovel all your projects into it. Typically this is a single account (bye bye blasts radius management), with 1-3 virtual networks (dev/prod/???), and the full architecture built out like a single data center. All the security groups, subnets, and other major structures are predefined. These deployments are more likely to have a bunch of virtual appliance versions of the same tools used on-premise. There is a lot of complex work to set up and isolate subnets and such, some minimal cloud-level IAM and alerting, and a lot of baggage carried over from existing operations. It doesn’t work. Not for long. MVC fundamentally breaks agility and reinforces bad old habits. Even if you try to design a ‘friendlier’ MVC deployemnt, it doesn’t scale and doesn’t offer the security benefits of a cloud-native approach. With MVC everything you deploy has to fit an established pattern. Instead of fitting security to the project you are forced to fit the project to the security. Don’t interpret that statement as me saying security is a lower priority – it is an equal priority. The best security is when the parts are designed to cooperate and reinforce each other. You can’t do that with MVC. It is an anti-pattern. MVC also typically results in many assets of differing security contexts sharing the same virtual network and cloud account/subscription/project. It is often selected because, at the start it looks easier to manage, but in the long term it becomes harder, as you struggle to deal with all those conflicting contexts and isolate everything out in an environment not designed for that type of isolation. Instead follow the cloud-native pattern… which works for lift and shift as well as new builds. In this approach the application and security architecture teams work together and design in parallel (ideally – you could add in security later, just not too late). You fit the security to the application. At the start there is a lot of learning new things, but over time you learn and build a library of relatively standard design patterns. You deploy into a clean account/subscription/project each time if you can. This enables you to minimize the number of privileged users who need access to the cloud account and simplifies, overall, the configuration of the accounts. This approach helps you close in on immutable and indempotent deployments (for production – development environments are still more free-form). You now have an isolated environment working within very defined constraints/definitions. This reduces complexity and is a bit of a security dream. It does increase another kind of complexity: managing all these different environments. There are organizations managing thousands of cloud accounts today. Management shifts to automation, deployment pipelines, and maintaining security guardrails across accounts. The alternative is complexity within an account, often leading to conflicting and difficult-to-enforce security boundaries. And that’s the key. I don’t claim managing cloud-native deployments is necessarily easier, but it shifts management in a direction that improves inherent security. You gain stronger security boundaries and tighten control, but in exchange you need to adopt automation and new management techniques and tooling. MVC always fails over the long term. Always – you inevitably reach a point where too many things, across too many conflicting security contexts, are sharing a single implementation. It seems easier up front (and probably is, especially if you are new to the cloud), but sooner than you think you will need to make security compromises. It additionally inhibits your ability to properly design security for any individual project, because the applications are restricted to a pre-configured set of rules. MVC usage correlates highly with ‘monoclouds’: stuffing everything into a single account with a small number of virtual networks. We also see some MVC deployments where they create a standard template and then deploy it into multiple accounts. Those aren’t quite as bad, but you still cannot fit security to the application and deployment. This is a period of massive transition. Greater than corporate adoption of the Internet itself, because the cloud requires deeper reengineering of underlying architectures. This is an incredible opportunity to break out of constraints of the past which have inhibited security – especially backward-looking MVC and monoclouds. Focus on education, automation, and tooling. Instead of building an MVC take a cloud project (ideally a new one) and “right fit” its security. Then take those lessons and move onto the next project. You will trade off getting all your sh** into the cloud as quickly as possible, but gain security and be able to move even more quickly over the long term. Share:

The team is back from the dead, and so are some really crappy cloud ideas. Watch or listen: Share:

As I was flying home from a meeting today I read two security stories that highlighted the differences between bad and less bad ways to report on security issues. Before I go into them, here is how I evaluate articles related to either stunt hacking or super-popular technology: Is there a real vulnerability? Is it exploitable, and to what degree? What are the actual, known, demonstrable consequences of exploitation? Would other controls or the real-world ecosystem limit either exploitation or impact? Who is writing the article or giving the presentation, who are their sources, and why are they talking about it? How did the vendor/target/whoever respond to the situation, and how is this reflected in the article? These are actually the same criteria I apply to original research reports and conference presentations. Now on to the articles: First, a contact at Apple pointed me to this article by Lily Hay Newman in Wired on “privacy risks” with CoreML. (Let’s be honest: I am known to have a real sore spot for this kind of article – the pointer wasn’t accidental. I’ll save you some time by summing it up: CoreML enables machine learning in apps. These apps can have access to your photos (with permission). Machine learning is hard, so bad actors can sneak in code to do things like find nudies or which products you have in the background of photos. This is against the App Store guidelines, but no one really knows whether Apple would detect it. There’s one small quote at the end from an actual security researcher admitting that such an app could just upload every photo to the cloud if it had this permission anyway. Here is how I’ve been summarizing these kinds of pieces, since basically the start of Securosis: There is a new technology getting some decent attention. Hypothetically someone might be able to do bad stuff with it. Let’s put “iPhone” or “critical infrastructure” in the headline so we get lots of clicks. (This list is growing, though – today I would add cars, airplanes, home automation, electronic toys, and robots/drones). Let’s barely mention that multiple other vendors or product categories have the same capability and often worse security controls. Because iPhones! I want to contrast Wired’s piece with a different piece at BleepingComputer on a backdoor in a satellite Internet system heavily used in shipping. The reason this article is a good contrast is because it starts with a similar premise – a researcher finding an issue and taking it to the press (in this case clearly to get some media coverage). I’m not convinced this basis for articles is usually a good thing because a lot of companies push their researchers for “big” findings like this to get attention. But some are legitimately important issues which do need coverage that vendors or whoever would otherwise try to cover up. In this case: Most ships use a popular satellite Internet system. There is a backdoor (literally named backdoor) in the system, plus another vulnerability. The system is at end-of-life, still in wide use, and will not be patched. The system is for Internet traffic only, not ship control, and the networks are separated. Exploiting this is hard but possible. Although you can’t get into control systems, it could be used for tracking or economic malfeasance. It is at least partially patched, and the vendor warned everyone. The key differences: This was a real exploitable vulnerability, not purely hypothetical. The article clearly defined the scope of potential exploitation. The piece was quickly updated with a statement from the product vendor that indicates the issue may not be even as bad as reported by the security vendor. Or an issue at all any more (but the update should be called out at the top, because it totally undermines the rest of the piece). Now, is this article great? No – the headline and section titles are more hyperbolic than the actual text – editors often do this after a writer submits an article. Also I think the refining statement should be at the top. According to Inmarsat’s statement (after release) the exploit requires physical access and remote exploitation is blocked on shoreside firewalls. The positives of the article are that it mostly balances the risk, highlights a really stupid mistake (the backdoor was insanely easy to exploit) and was based… on reality. Do you want to see a similar situation that involved a real exploit, real risks, a horrible vendor response, and resulting widespread action? Check out this article on a pacemaker recall due to exploitable vulnerabilities. It even highlights issues with how it was handled by both researchers and ÷vendors. Share:

Transport Layer Security (TLS) is fundamental to the security of the Internet. Proposed changes to the protocol are generating extensive controversy within and outside the security industry. Rather than getting into cryptographic specifics, this post focuses on the root of the controversy, and why we believe TLS 1.3 should proceed with the full support of technical professionals. What is TLS 1.3? – Transport Layer Security (TLS) is the primary protocol for securely sending information over the Internet. It is the successor to SSL (Secure Sockets Layer) and built into every web browser and web server, as well as many other applications. Nearly every website in the world uses TLS to one degree or another to protect communications – including signing into a site with a password, banking, and reading email. TLS is also embedded into many other applications and the guts of the Internet. You use it every day. If you are reading this on our website you used TLS to see this page. If you checked your email today, TLS is what prevented someone on the Internet from reading it. If you are completely non-technical, think of it as a security envelope for your data. But TLS does much more. TLS 1.3 is a proposed draft to update the current version (TLS 1.2 – surprise!) and improve security and performance. As with any software, TLS is never ‘perfect’, and needs updating from time to time. For example one change cuts the window to initiate a secure connection in half. 1.3 also simplifies the kinds of encryption it supports to eliminate known security vulnerabilities. TLS 1.3 is already supported in some web browsers, even though the standard isn’t final. Why is TLS 1.3 controversial? – Version 1.3 eliminates a security weakness of TLS 1.2, but that exact weakness is used by many organizations to monitor their networks. Some organizations and security vendors want to retain it so they can continue to use existing technique to monitor traffic. We need to choose between better inherent Internet security and supporting a widely used monitoring technique. Monitoring itself is not inherently bad. Common tools like Data Loss Prevention rely on peering into encrypted connections on corporate networks to identify sensitive data being accidentally or maliciously exposed. Other tools sniff connections to recognize attacker activity, and then either block or alert. It’s a form of wiretapping, but one widely used as part of security programs rather than for spying – although it can obviously be used for both. Security is always a balancing act, so we often face these difficult decisions. Fortunately in this case there are alternative techniques to achieve the same security goals, so our position is that we should not keep a vulnerability in a core Internet protocol just to support existing security tools. The controversy is about security vs. cost. Existing monitoring approaches can support 1.3, so a possibly higher implementation cost should not excuse a security reduction. What exactly is the security weakness TLS 1.3 eliminates? – Version 1.3 eliminates support for an older way of setting up encrypted connections using a master key. It could enable someone with a copy of the master key to sniff all encrypted traffic. They could also decrypt any previously recorded traffic protected with that key. The proposed updates to TLS use a different key for every connection, so there is no master key which could allow unrestricted monitoring. We call this Perfect Forward Secrecy, if you want to look it up. This is a pretty big weakness, which has been used in attacks. Unfortunately it’s also used by legitimate security tools for more efficient monitoring. Does TLS 1.3 reduce enterprise and government security? – No. It changes how you need to implement some security. It will cost money to update to new kinds of systems to perform the same kinds of monitoring. It will require rethinking how we do some things today. But it does not eliminate the ability to achieve security objectives. Organizations that need to monitor traffic can do so with four techniques: Active interception (man in the middle) techniques. Using software to capture traffic on endpoint systems, instead of on the network. Capturing data on Internet servers. For example, some cloud services allow you to track all employee data and activity. For servers you control, you can still use TLS 1.2. It will likely be supported for many years. Do we really need to remove passive monitoring from TLS 1.2? – Yes. We face a simple choice: we can make network sniffing attacks harder, or easier. We can improve security, or leave a known vulnerability. Our position is that we should always choose stronger security. The Internet is littered with the consequences of choosing weaker options, especially for encryption. Support for passive monitoring of encrypted connections may help some aspects of an organization’s security program, but only at the expense of long-term security. Attackers, criminal and otherwise, can leverage this to spy on organizations, individuals, and governments. They can potentially record traffic on networks and then decrypt it later… even weeks, months, or years later. We have seen this exploited in criminal and government attacks – it is not a theoretical vulnerability. What is the impact if TLS 1.3 is adopted? – There won’t be any immediate impact in most cases. TLS 1.2 is still completely supported and will be for a long time. As online services start adopting TLS 1.3, organizations which rely on passive sniffing of encrypted connections may start losing visibility into those connections. Organizations which want to maintain this visibility will need to update their tools and techniques. But the entire Internet won’t shift to TLS 1.3 overnight, so there is time to make the transition. Transport Layer Security 1.3 brings important security improvements to one of the most foundational technologies used to protect Internet communications. It eliminates a form of passive sniffing that, although used for legitimate security purposes, also weakens Internet communications. We would rather have an inherently secure Internet than keep a

It’s usually more than a little risky to comment on hypothetical Apple products, but while I was out at Black Hat and DEF CON Apple accidentally released the firmware for their upcoming HomePod. Filled with references to other upcoming products and technologies, the firmware release makes it reasonably probable that Apple will release an updated iPhone without a Touch ID sensor, relying instead on facial recognition. A reasonable probability is far from an absolute certainty, but this is an interesting enough change that I think it’s worth taking a few minutes to outline how I intend to evaluate any “Face ID”, should it actually appear. They key is to look for equivalence, rather than exactness. I don’t care whether Face ID (we’ll roll with that name for now) works exactly like Touch ID – we just need it close enough, or even better. Is it as secure? There are three aspects to evaluate: Does it cost as much to circumvent? Touch ID isn’t perfect – there are a variety of ways to create fake fingerprints which can spoof it. The financial cost is not prohibitive for a serious attacker, but the attacks are all time-consuming enough that the vast vast majority of iPhone users don’t need to worry about them. I am sure someone will come up with ways around Face ID, but if they need to take multiple photos from multiple angles, compute a 3D model, 3D print the model, then accurately surface it with additional facial feature details, I’ll call that a win for Apple. It will make an awesome DEF CON or CCC presentation though. Does it have an equivalent false positive rate? From what I see, Touch ID has a false positive rate low enough to be effectively 0 in real-world use. As long as Face ID is about the same, we’ll be good to go. Does it use a similarly secure hardware/software architecture? One of the most important aspects of Touch ID is how it ties into the Secure Enclave (and, by extension, the Secure Element). These are the links that embed anti-circumvention techniques in the hardware and iOS, enabling incredibly strong security; supporting use in payment systems, banking applications, etc. I would be shocked if Apple didn’t keep this model, but expect changes to support the different kind of processing and increased multi-purpose nature of the underlying hardware (general-purpose cameras, perhaps). Is it as easy to use? The genius of Touch ID was that it enabled consumers to use strong password, with the same convenience as no password at all (most of the time). Face ID will need to hit the same marks to be seen as successful. Is it as fast? The first version of Touch ID was pretty darn fast, taking a second or less. The second (current) version is so fast that most of the time you barely notice it. Face ID doesn’t need to be exactly as fast, but close enough that the average user won’t notice a difference. If I need to hold my iPhone steady in front of my face while a little capture box pops up with a progress bar saying “Authenticating face…”, it will be a failure. But we all know that isn’t going to happen. Does it work in as many different situations (at night, walking, etc.)? Touch ID is far from perfect. I work out a ton and, awesome athlete that I am, I sweat like Moist from Dr. Horrible’s Sing-Along Blog. Touch ID isn’t a fan. Face ID doesn’t need to work in exactly the same situations, but in an equivalent number of real-world situations. For example I use Touch ID to unlock my phone sitting on a table to pass off to one of the kids, or while lying sideways in bed with my face mushed into a pillow. Face ID will probably require me to pick the phone up and look at it. In exchange, I’ll probably be able to use it with wet hands in the kitchen. Tradeoffs are fine – so long as they are net neutral, positive, or insignificant. Does it offer an equivalent set of features? My wife and I actually trust each other and share access to all our devices. With Touch ID we enroll each other’s fingerprints. Touch ID also (supposedly) improves over time. Ideally Face ID will work similarly. Is it as reliable? The key phrase here is false negative rate. Even second-generation Touch ID can be fiddly at times, as in my workout example above. With Face ID we’ll look more at things like changing facial hair, lighting conditions, moving/walking, etc. These tie into ease of use, but in those cases it’s more about number of situations where it works. This question comes down to Is Face ID as reliable within its supported scenarios? This is one area where I could see some big improvements over Touch ID. Conclusion Plenty of articles will focus on all the differences if Face ID becomes a reality. Plenty of people will complain it doesn’t work exactly the same. Plenty of security researchers will find ways to circumvent it. But what really matters is whether it hits the same goal: Allow a user to use a strong password with the convenience of no password at all… most of the time. Face ID doesn’t need to be the same as Touch ID – it just needs to work reasonably equivalently in real-world use. I won’t bet on Face ID being real, but I will bet that if Apple ships it, they will make sure it’s just as good as Touch ID. Share:

TL;DR: SaaS enables Zero Trust networks with pervasive encryption and access. Box vendors lose once again. It no longer makes sense to run your own mail server in your data center. Or file servers. Or a very long list of enterprise applications. Unless you are on a very very short list of organizations. Running enterprise applications in an enterprise data center is simply an anachronism in progress. A quick peek at the balance sheets of the top tier Software as a Service providers shows the transition to SaaS continues unabated. Buying and maintaining enterprise applications, such as mail servers, files servers, ERP, CRM, ticketing systems, HR systems, and all the other organs of a functional enterprise has never been core to any organization. It was something we did out of necessity, reducing the availability of resources better used to achieving whatever mission someone wrote out and pasted on a wall. That isn’t to say using back-office systems better, running them more efficiently, or leveraging them to improve business operations didn’t offer value, but really, at the heart of things, all the cost and complexity of keeping them running has mostly been a drag on operations and budgets. In an ideal world SaaS wipes out major chunks of capital investments and reduces the operational overhead of maintaining the basil metabolic rate of the enterprise, freeing cash and people to build and run the things that make the organization different, competitive, and valuable. It isn’t like major M&A press releases cite “excellent efficiency in load balancing mail servers” or “global leaders in SharePoint server maintenance” as reasons for big deals. And SaaS reduces reliance on corporate networks – freeing employees to work at their kids’ sporting events and on cruise ships. SaaS offers tremendous value, but it is the Wild West of cloud computing. Top tier providers are strongly incentivized to prioritize security through sheer economics. A big breach at an enterprise-class SaaS provider is a likely existential event. (Okay, perhaps it would take two breaches to knock one into ashes). But smaller providers are often self- or venture-backed startups, more concerned with growing market share and adding features, hoping to stake their claims in the race to own the frontier. Security is all fine and good so long as it doesn’t slow things down or cost too much. Like our other Tidal Forces I believe the transition to SaaS will be a net gain for security, but one without pain or pitfalls. It is driving a major shift in security processes, controls, and required tooling and skills. There will be winners and losers, both professionally and across the industry. The Wild West demands strong survival instincts. Major SaaS providers for back-office applications can be significantly more secure than the equivalent application running in your own data center, where resources are constrained by budgets and politics. The key word in that sentence is can. Practically speaking we are still early in the move to SaaS, with as wide a range of security as we have opportunistic terrain. Risk assessment for SaaS doesn’t fit neatly within the usual patterns, and isn’t something you can resolve with site visits or a contract review. One day, perhaps, things will settle down, but until then it will take a different cache of more technical assessment skills set to avoid ending up with some cloud-based dysentery. There are fewer servers to protect. As organizations move to SaaS they shut down entire fleets of their most difficult-to-maintain servers. Email servers, CRM, ERP, file storage, and more are all replaced with software subscriptions and web browsers. These transitions occur at different paces with differing levels of difficulty, but the end result is always fewer boxes behind the firewall to protect. There is no security consistency across SaaS providers. I’m not talking about consistent levels of security, but about which security controls are available and how you configure them. Every provider has its own ways of managing users, logs (if they have them), entitlements, and other security controls. No two providers are alike, and each uses its own provider-specific language and documentation to describe things. Learning these for a dozen services might not be too bad, but some organizations use dozens or hundreds of different SaaS providers. SaaS centralizes security. Tied of managing a plethora of file servers? Just move to SaaS to gain omniscient views of all your data and what people are doing with it. SaaS doesn’t always enable security centralization, but when it does it can significantly improve overall security compared to running multiple, disparate application stacks for a single function. Yes, there is a dichotomy here; as the point above mentions, every single SaaS provider has different interfaces for security. In this case we gain advantages, because we no longer need to worry about the security of actual servers, and for certain functions we can consolidate what used to be multiple, disparate tools into a single service. The back office is now on the Internet and with always encrypted connections. All SaaS is inherently Internet accessible, which means anywhere and anytime encrypted access for employees. This creates cascading implications for traditional ways of managing security. You can’t sniff the network because it is everywhere, and routing everyone home through a VPN (yes, that is technically possible) isn’t a viable strategy. And a man-in-the-middle attack on your users is a doozy for security. Without the right controls credential theft enables someone to access essential enterprise systems from anywhere. It’s all manageable but it’s all different. It’s also a powerful enabler for zero trust networks. Even non-SaaS back offices will be in the cloud. Don’t trust a SaaS service? Can’t find one that meets your needs? The odds are still very much against putting something new in your data center – instead you’ll plop it down with a nice IaaS provider and just encrypt and manage everything yourself. The implications of these shifts go far deeper than not having to worry about securing a few extra servers. (And