Research

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:

We will close out this series with a look at several operational considerations for selecting a secrets management platform. There are quite a few secrets management tools, both commercial and otherwise, on the market, and each does things a bit differently. Rather than a giant survey of every product and how it works, we will focus on the facets of these products which enable them to handle the use cases discussed earlier. Central questions include how these platforms deploy, how they provide scalability and resiliency, and how they integrate with the services they supply secrets to? To better distinguish between products you need to understand why they were created, because core functions and deployment models are heavily influenced by a platform’s intended use. Classes of Products Secrets management platforms fall into two basic categories: general-purpose and single-purpose. General-purpose solutions provide secrets for multiple use cases, with many types of secrets. General-purpose systems can automatically provision secrets to just about any type of application – from sending user name and password to a web page, to issuing API keys, to dynamic cloud workloads. Single-purpose options – commonly called ‘embedded’ because they install into another platform – are typically focused on one use case. For example the embedded solutions focus on provisioning secrets to Docker containers, and nest into your orchestration manager (e.g.: Swarm, Kubernetes, DC/OS). This is a critical distinction, because a product embedded into a container manager may not work for non-container use cases. The good news is that many services are deployed this way so they are still useful in many environments, and because these tools leverage existing infrastructure they often integrate well and scale easily. These platforms typically leverage specific constructs of the orchestration manager or container environment to provide secrets. They also tend to make assumptions about how secrets are to be used; for example they may leverage Kubernetes’ ‘namespace’ to enforce policy or the UNIX ‘namespace’ to distribute secrets. Because containers are ephemeral, ephemeral or ‘dynamic’ secrets are often preferred for those secrets managers. The bad news is that some embedded tools assume your cluster is a secure environment, so they can safely pass and store secrets in clear text. Many embedded tools fully encrypt secrets, but they may not support diverse types of secrets or integrate with non-containerized applications. These specializations are neither good nor bad, depending on what you need for secrets management, but embedded systems may be limited. General-purpose products are typically more flexible and may take more time and to set up, but provide a breadth of functions not generally found in embedded tools. Deployment Models Solitary Servers Common among early tools focused on personal productivity, solitary servers are exactly what the name implies. They typically consist of a central secret storage database and a single server instance that manages it. Basically all functions – including user interfaces, storage management, key management, authentication, and policy management – are handled by a single service. These tools are commonly used via command-line interfaces or API, and work best for a small number of systems. Client-Server Architecture The label for this model varies from vendor to vendor. Primary/Secondary, Manager/Worker, Master/Slave, and Service/Agent are just some of the terms to describe the hierarchical relationship between the principal service which manages the repository of secrets, and the client which works with the calling application. This is by far the most common architecture. There is a repository where encrypted secrets are stored, usually a database which is shared or replicated across one or more manager nodes. And each manager can work with one or more agents to support the needs of their service or application. This architecture helps provide scalability and reliability by spawning new clients and servers as needed. These products often deploy each component as a container, leveraging the same infrastructure as the applications they serve. Many embedded products use this model to scale. Integration We already talked about how secrets are shared between a secrets management tool and a recipient, whether human or machine. And we covered integration with container management and orchestration systems, as many tools were designed to do. It’s time to mention the other common integration points and how each works. Build Servers: Tools like Jenkins and Bamboo are used by software development teams to automate the building and verification of new code. These tools commonly access one or more repositories to get updated code, grab automation scripts and libraries to set up new environments, connect to virtual or cloud services to run tests, and sign code before moving tested code into another repository or container registry. Each action requires specific credentials before it can take place. Secrets management integration is either performed as a plug-in component to the build server or as an external service it communicates with. IT Automation: Automated builds and the power of build managers have vastly improved development productivity, but orchestration tools are what move code at warp speed from developer desktops into production. Chef/Puppet/Ansible are the trio of popular orchestration tools automating IT and development tasks, the backbone of Continuous Integration and Continuous Deployment. Virtually any programable IT operation can be performed with these tools, including most VMware and all cloud services functions offered through API. As with build servers, secrets management typically installs as a component or add-on module of the orchestration tool, or runs as a service. Public Cloud Support: Public cloud is a special case. Conceptually, every use case outlined in this series is applicable to cloud services. And because every service in a public cloud is API enabled, it is the ideal playground for secrets management tools. What’s special about cloud services is how integration is managed; most secrets management tools which support the cloud directly integrate with either cloud native identity systems, cloud-native key management, or both. This offers advantages because secrets can then be provisioned in any region, to any supported service within that region, leveraging existing identities. The cloud service can fully define which user can access which secrets.

In this section we will discuss the core features of a secrets management platform. There are basic functions every secrets management platform needs to address the basic use cases. These include secure storage and disbursement of secrets, identity management, and API access, for starters. There are plenty of tools out there, many open source, and several bundled into other platforms. But when considering what you need from one of these platforms, the key thing to keep in mind is that most of them were originally developed to perform a single very specific task – such as injecting secrets into containers at runtime, or integrating tightly with a Jenkins build server, or supplementing a cloud identity service. Those do one thing well, but typically do not address multiple use cases. Now let’s take a closer look at the key features. Core Features Storing Secrets Secrets management platforms are software applications designed to support other applications in a very important task: securely storing and passing secrets to the correct parties. The most important characteristic of a secrets management platform is that it must never leave secret information sitting around in clear text. Secure storage is job #1. Almost every tool we reviewed provides one or more encrypted repositories – which several products call a ‘vault’ – to store secret information in. As you insert or update secrets in the repository, they are automatically encrypted prior to being written to storage. Shocking though it may be, at least one product you may come across does not actually encrypt secrets – instead storing them in locations its developers consider difficult to access. The good news is that most vaults use vetted implementations of well-known encryption algorithms to encrypt secrets. But it is worth vetting any implementation, with your regulatory and contractual requirements in mind, prior to selecting one for production use. With the exception of select platforms which provide ‘ephemeral secrets’ (more on these later), all secret data is stored within these repositores for future use. Nothing is stored in clear text. How each platform associates secrets with a given user identifier, credential, or role varies widely. Each platform has its own way of managing secrets internally, but mostly they use a unique identifier or key-value pair to identify each secret. Some store multiple versions of a secret so changes over time can be recalled if necessary for recovery or auditing, but the details are part of their secret sauce. The repository structure varies widely between offerings. Some store data in simple text or JSON files. Some use key-value pairs in a NoSQL style database. Others use a relational or Big Data database of your choice. A couple employ multiple repository types to increase isolation between secrets and/or use cases. Their repository architecture is seldom determined by strong security; more common drivers are low cost and ease of use for the product developers. And while a repository of any type can be secured, the choice of repository impact scalability, how replication is performed, and how quickly you can find and provision secrets. Another consideration is which data types a repository can handle. Most platforms we reviewed can handle any type of data you want to store: string values, text fields, N-tuple pairings, and binary data. Indexing is often performed automatically as you insert items, to speed lookup and retrieval later. Some of these platforms really only handle string, which simplifies programmatic API but limits their usability. Again, products tailored to a particular use case may be unsuitable for other uses or across teams. Identity and Access Management Most secrets management platforms concede IAM to external Active Directory or LDAP services, which makes sense because most firms already have IAM infrastructure in place. Users authenticate to the directory store to gain access, and the server leverages existing roles to determine which functions and secrets the user is authorized to access. Most platforms are also able to use a third-party Cloud Identity Service or Privileged Access Management service, or to directly integrate with cloud-native directory services. Note that a couple of the platforms we reviewed manage identity and secrets internally, rather than using an external identity store. This is not a bad thing because they then tend to include secrets management to supplement password or key management, and internally management of identity is part of their security architecture. Access and Usage Most platforms provide one or more programming interfaces. The most common, to serve secrets in automated environments, is an access API. A small and simple set of API calls are provided to authenticate a session, insert a record, locate a secret, and share a secret to a specific user or service. More advanced solutions also offer API access to advanced or administrative functions. Command-line access is also common, leveraging the same basic functions in a command-driven UNIX/Linux environment. A handful of others also offer a graphical user interface, either directly or indirectly, sometimes through another open source project. Sharing Secrets The most interesting aspect of a secrets management system is how it shares secrets with users, services, or applications. How do you securely provide a secret to its intended recipient? As in the repository, as discussed above, secrets in transit must be protected, which usually means encryption. And there are many different ways to pass secrets around. Let’s take a look at the common methods of secret passing. Encrypted Network Communications: Authenticated service or users are passed secrets, often in clear text, within an encrypted session. Some use Secure Sockets Layer (SSL), which is not ideal, for encrypted transport, but thankfully most use current versions of Transport Layer Encryption, which als authenticates the recipient to the secrets management server. PKI: Several secrets management platforms combine external identity management with a Public Key Infrastructure to validate recipients of secrets and transmit PKI encrypted payloads. The platform determines who will receive a secret, and encrypts the content with the recipient’s public key. This ensures that only the intended recipient can decrypt the secret, using their private key.

This post will discuss why secrets management is needed at all, along with the diverse use cases which teams need it to address. In every case there is some secret data which needs to be sent – hopefully not in plain text – to an application or service. And in every case we want the ability to provide secrets, both when an operator is present and automatically. The biggest single issue is that security around these secrets today is largely absent, and they are kept in cleartext within documents of various types. Let’s dive in. Use Cases API Gateways and Access Keys: Application Programming Interfaces are how software programs interact with other software and services. These API form the basic interface for joint operation. To use an API you must first authenticate yourself – or your code – to the gateway. This is typically done by providing an access key, token, or response to a cryptographic challenge. For ease of automation many developers hard-code access keys, leaving themselves vulnerable to simple file or code inspection. And all too often, even when kept in a private file on the developer’s desktop, keys are accidentally shared or posted, such as to public code repositories. The goal here is to keep access keys secret while still provisioning to valid applications as needed. Automated Services: Applications are seldom stand-alone entities. They are typically comprised of many different components, databases, and supporting services. And with current application architectures we launch many instances of an application to ensure scalability and resiliency. As we launch applications, whether in containers or as servers, we must provision them with configuration data, identity certificates, and tokens. How does a newly created virtual machine, container, or application discover its identity and access the resources it needs? How can we uniquely identify a container instance among a sea of clones? In the race to fully automate the environment, organizations have automated so fast that they got out over their skis, with little security and a decided imbalance towards build speed. Developers typically place credentials in configuration files which are conveniently available to applications and servers on startup. We find production credentials shared with quality assurance and developer systems, which are commonly far less secure and not always monitored. They are also frequently shared with other applications and services which should not have access. The goal is to segregate credentials without causing breakage or unacceptable barriers. Build Automation: Most build environments are insecure. Developers tend to feel security during development slows them down, so they often bypass security controls in development processes. Build environments are normally under developer control, on development-owned servers, so few outsiders know where they are or how they operate. Nightly build servers has been around for over a decade, with steadily increasing automation to improve agility. As things speed up we remove human oversight. Continuous Integration and Continuous Deployment use automation to speed software delivery. Build servers like Jenkins and Bamboo automatically regenerate application as code, formation templates, and scripts are checked into repositories. When builds are complete we automatically launch new environments to perform functional, regression, and even security tests. When these tests pass, some organizations launch the code in production! Build server security has become an important topic. We no longer have the luxury of leaving passwords, encryption keys, and access tokens sitting in unprotected files or scripts. But just as continuous integration and DevOps improve agility, we need to automate the provisioning of secrets into the process as well, and create an audit trail to prove we are delivering code and services securely. Encrypted Data: Providing encryption keys to unlock encrypted volumes and file stores is a common task, both on-premise and for cloud services. In fact, automated infrastructure makes the problem more difficult as the environment is less static, with thousands of services, containers and applications popping in and out of service. Traditionally we have used key management servers designed to handle secure distribution and management of keys, but a number of commercial key management tools (hardware and software) have not been augmented for Infrastructure and Platform as a Service. Additionally, developers demand better API integration for seamless use with applications. This capability is frequently lacking, so some teams use cloud native key management, while others opt for secrets management as a replacement. Sharing: Collaboration software has helped development, quality assurance, and product mamagement teams cooperate on projects; even though people in these groups are less and less likely to share office space. User are more likely to work from home, at least part time. In some contexts the issue is how to securely share information across a team of remote developers, but that use case overlaps with having IT share secret data across multiple data centers without exposing it in clear text, or exposed in random files. The databases that hold data for chat and collaboration services tend to not be very secure, and texting certificates to a co-worker is a non-starter. The solution is a central, robust repository, where a select group of users can store and retrieve secrets. Of course there are plenty more use cases. In interviews we discuss everything from simple passwords to bitcoin wallets. But for this research we need to focus on the issues developers and IT security folks asked about. Our next post will discuss the core features and functions of a secrets management system, as well as some advanced functions which differentiate commercial options from open source. We want to provide a sense of what is possible, and help guide readers to the subset of functions they need for their use cases. Share:

This week we are starting a new research series on Secrets Management. What is secrets management and why do you care? A good number of you in security will be asking these questions. Secrets Management platforms do exactly what the name implies; they store, manage and provide secrets. This technology addresses several problems most security folks don’t yet know they have. As development teams leverage automation and orchestration techniques, they are creating new security issues to be tackled. Let’s jump into some of the back story, and then outline what we will accomplish in this research effort. It sounds cliche, sure, but IT and application environments are genuinely undergoing radical change. New ways of deploying applications as microservices or into containers is improving our ability to cost-effectively scale services and large systems. Software defined IT stacks and granular control over services through API provide tremendous advantages in agility. Modern operational models such as Continuous Integration and DevOps amplify these advantages, bringing applications and infrastructure to market faster and more reliably. Perhaps the largest change currently affecting software development and IT is cloud computing: on-demand and elastic services offers huge advantages, but predicated on automated infrastructure defined as software. While cloud is not a necessary component to these other advancements, it’s makes them all the more powerful. Leveraging all these advancements together, a few lines of code can launch – or shut down – an entire (virtual) data center in minutes, with minimal human involvement or effort. Alongside their benefits, automation and orchestration raise new security concerns. The major issue today is secure sharing of secret information. Development teams need to share data, configurations, and access keys across teams to cooperate on application development and testing. Automated build servers need access to source code control, API gateways, and user roles to accomplish their tasks. Servers need access to encrypted disks, applications need to access databases, and containers must be provisioned with privileges as they start up. Automated services cannot wait around for users to type in passwords or provide credentials! So we need new agile and automated techniques to provision data, identity, and access rights. Obtaining these secrets is essential for automation scripts to function, but many organizations cling to the classic (simple) mode of operation: place secrets in files, or embed them into scripts, so tasks can complete without human intervention. Developers understand this is problematic, but it’s a technical problem most sweep under the rug. And they certainly do not go out of their way to tell security about how they provision secrets, so most CISOs and security architects are unaware of this emerging security issue. This problem is not new. No administrator wants to be called into work in the middle of the night to enter a password so an application can restart. So IT administrators routinely store encryption keys in files so an OS or application can access them when needed. Database administrators place encryption keys and passwords in files to facilitate automated reboots. Or they did until corporate networks came under even more attack; then we saw a shift to keys, certificates, and passwords. Since then we have relied upon everything from manual intervention, key management servers, and even hardware dongles to provide a root of trust to establish identity and provision systems. But those models not only break the automation we rely upon to reduce costs and speed up deployments, lack also the programmatic interfaces needed to integrate with cloud services. To address the changes described above, new utilities and platforms have been created to rapidly provide information across groups and applications. The term for this new class of product is “Secrets Management”; it is changing how we deliver identity, secrets, and tokens; as well as changing the way we validate systems for automated establishment of trust. In this research we will explore why this is an issue for many organizations, what sort of problems these new platforms tackle, and how they work in these newer environments. Specifically, we will cover: Use Cases: We will start by considering specific problems which make secret sharing so difficult: such as moving passwords in clear text, providing keys to encryption engines, secure disk storage, knowing which processes are trustworthy, and mutual (bidirectional) authentication. Then we will discus specific use cases driving secrets management. We will cover issues such as provisioning containers and servers, software build environments, database access, and encrypted disk & file stores; we will continue to examine sharing secrets across groups and controlling who can launch which resources in private and public cloud environments. Components and Features: This section will discuss the core features of a secrets management platform. We will discuss the vault/repository concept, the use of ephemeral non-vault systems, identity management for vault access, role-based authorization, network security, and replication for both resiliency and remote access. We will cover common interfaces such as CLI, API, and HTTP. We’ll contrast open source personal productivity tools with newer commercial products; we will also consider advanced features such as administration, logging, identity store integration, ability to provide secure connections, and policy enforcement. Deployment Considerations: Next we will discuss what is stored in a repository, and how secrets are shared or integrated with dependent services or applications. We will discuss both deployment models; as well as the secrets to be shared: passwords, encryption keys, access tokens, API keys, identity certificates, IoT key pairs, secure configuration data, and even text files. We will also offer some advice on product selection criteria and what to look for. As we leverage cloud services and rely more heavily on automation to provision applications and IT resources, we find more and more need to get secrets to applications and scripts securely. So our next post will start with use cases driving this market. 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

Endpoint security has undergone a renaissance recently. Similar to network security a decade ago, the technology had not seen significant innovation for years, and adversaries improved to a point where many organizations questioned why they kept renewing existing endpoint protection suites. It was an untenable situation. The market spoke, and security companies responded with a wave of new offerings and innovations which do a much better job detecting both advanced adversaries and the techniques they use to obfuscate their activities. To be clear, there is no panacea. Nothing is 100% effective in protecting endpoints. But the latest wave of products has improved dramatically over what was available two years ago. But that creates a conundrum for organizations of all sizes. With so many vendors addressing the endpoint security market with seemingly similar offerings, what should a customer buy? Which features make the most sense, depending on the sophistication and adversaries an organization faces? Ultimately, how can potential customers make heads or tails of the noise coming from the security marketing machinery? At Securosis the situation was frustrating. So many buzzwords were thrown around without context. New companies emerged, making claims we considered outrageous on effectiveness. Some of this nonsense reminds us of a certain database vendor’s Unbreakable claims. Yes, we’ve been in this business a long time. And yes, we’ve seen pretty much everything. Twice. But we’ve never seen a product that blocks every attack with no false positives. Even though some companies were making that claim. Sadly, that was only the tip of the iceberg of our irritation. There was a public test of these endpoint solutions, which we thought drew the wrong conclusions with a suspect methodology. If those tests were to be believed, some products kicked butt while others totally sucked. But we’ve talked with a bunch of folks who got results were consistent with the public tests, and others whose results were diametrically opposed. And not every company with decent technology was included in the tests. So if a customer were making a choice entirely based on that public test they could be led astray – ultimately, how a product performs in your environment can only really be determined by testing in your environment. In Securosis-land frustration and irritation trigger action. So we got irritated and decided to clarify a very murky situation. If we could help organizations figure out what capabilities were important to them based on the problems they were trying to solve, they would be much better educated consumers when sitting with endpoint security vendors. If we could map out a process to test the efficacy of each product and compare “apples to apples”, they would make much better purchase decisions based on requirements – not how many billboards a well-funded vendor bought. To be clear, billboards and marketing activity are not bad. You can’t grow a sustainable company without significant marketing and brand-building. But marketing is no reason to buy an endpoint security product. We found little correlation between marketing spend and product capability. So at Securosis we decided to write an Endpoint Advanced Protection Buyer’s Guide. This comprehensive project will provide organizations what they need to select and evaluate endpoint security products. It will roll out over the next month, delivered in two main parts: Selection Criteria: This part of the Buyer’s Guide will focus on the capabilities you need to address the problems you face. We’ll explain terms like file-less malware and exploit pathways, so when vendors use them you will know what they’re talking about. We will also prepare a matrix to help you assess their capabilities against your requirements, based on attacks you expect to face. POC Guide: Figuring out what product seems to fit is only half the battle. You need to make sure it works in your environment. That means a Proof of Concept (POC) to prove value and that the product does what they say. That old “Trust, but verify” thing. So we’ll map out a process to test the capabilities of endpoint security products. Prevention vs. Detection/Response We have seen a pseudo-religious battle being fought, between a focus on trying to block attacks, versus focusing on detection and response once an attack is successful. We aren’t religious, and believe the best answer is a combination. As mentioned above, we don’t buy into the hype that any product can stop every attack. But we don’t believe prevention is totally useless either. So you’ll be looking at both prevention technologies and detection/response, but perhaps not at the same time. We’ll prepare versions of the Buyer’s Guide for both prevention and detection/response. And yes, we’ll also integrate them for those who want to evaluate a comprehensive Endpoint Advanced Protection Suite. Licensing Education Those of you familiar with our Securosis business model know we post research on our blog, and then license content to educate the industry. You also probably know that we research using our Totally Transparent Research methodology. We don’t talk about specific vendors, nor do we mention or evaluate specific products. But why would an endpoint company license a totally vendor-neutral buyer’s guide which educates customers to see through their marketing shenanigans? Because they believe in their products. And they want an opportunity to show that their products actually provide a better mousetrap, and can solve the issues facing organizations around protecting endpoints. So hats off to our licensees for this project. They are equipping their prospects to ask tough questions and to evaluate their technology objectively. We want to thank (in alphabetical order) Carbon Black, Cybereason, Cylance, ENDGAME, FireEye, SentinelONE and Symantec for supporting this effort. We expect there may be a handful of others later in the year, and we’ll recognize them if and when they come onboard. We will post pieces of the Buyer’s Guide to the blog over the next month. As always we value the feedback of our readers, so it you see something wacky, please let us know. Share:

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:

It’s been a while since I’ve done a webcast, so if you are going through the DTs like I am, you are in luck. On Wednesday at 1 PM ET (10 AM PT), I’m doing an event with my friends at SafeBreach on our Dynamic Security Assessment content. I even convinced them to use one of my favorite sayings in the title: Hope Is Not a Strategy – How To Confirm Whether Your Controls Are Controlling Anything [giggles] It’ll be a great discussion, as we discuss and debate not only whether the security stuff you’ve deployed works, but how you can know it works. You can register now. See you there. Share: