Threat Modeling: Designing for Security (2014)

Part IV. Threat Modeling in Technologies and Tricky Areas

Chapter 13. Web and Cloud Threats

In many ways, threat modeling for the web and cloud are very much like threat modeling for anything else, but these unique environments have some recurring threats, which are covered in this chapter.

This chapter is organized into web threats, cloud threats, cloud provider threats, and mobile threats. Web threats are broken into website threats, web browser, and plugin threats. Many of the cloud threats are expressed with respect to infrastructure as a service (IaaS) and platform as a service (PaaS). It closes with a section on mobile threats.

Web Threats

The web is composed of a simple and powerful set of protocols and languages. It has become a cliché to say that it has changed everything. It's easy to forget that the web is software like other software. Although you might assume that you need to threat model it in some new ways, the truth is that it's like most other software, so techniques such as STRIDE and attack trees work well for web technologies.

Website Threats

Public websites receive large amounts of scrutiny, and suffer from all that the world can throw at them. The classic STRIDE threats all apply, as do a slew of web-specific attacks that happen when you forget that there's a trust boundary between them and the apparently nice doggy that is wagging its tail and slobbering in remarkably cleverly formed SQL in your forms and JavaScript in your URLs in order to cause harm.

Usually, threats such as SQL injections and XSS are handled later in the software engineering process. You'll be developing using patterns, libraries, and frameworks that make each threat less likely, using appropriate testing tools to catch problems during testing, and watching the logs after deployment. So you're done, right? Unfortunately, no. You should be threat modeling to find the unique threats your site will be vulnerable to, such as your ad provider, your analytics code, and that authentication database you're using from some crazy start-up in San Francisco. A standard data flow diagram (DFD) showing where the data comes from for your server is essential, and a client-side DFD is also a pretty good idea, if only to ensure that you have a good test suite. A client-side DFD can also be a good way to create a list that helps you track when your dependencies issue security updates.

Web Browser and Plugin Threats

The web browser has become people's primary portal onto the Internet, and occasionally their last line of automated defense against attacks. Anyone considering building a web browser needs at least one expert with a deep knowledge of the history of browser security issues.

Browser companies could substantially help matters by being super-diligent about their security goals, and how those goals manifest between tabs, websites, and the OS hosting the browser. Clarity from browser creators on how to create a plugin that does not violate security would also be most welcome.

Web plugins or add-ons that extend browser security are becoming less and less common, in part because the two best-known and widely deployed plugins, Java and Flash, have both suffered serious and ongoing security problems. Another reason plug-ins are becoming less common is Apple's willingness to exclude Flash from the iPhone.

Any of the building blocks for finding threats can be applied to a web browser. For example, the STRIDE threats all apply to a web browser. There's spoofing of web pages for phishing or other goals, cross-tab tampering and tampering with files included from other servers. There's information disclosure about browser history vis CSS sniffing, and similar examples exist for each STRIDE threat. There are also very specific attack libraries available for web browsers and website designers.

If you're going to create a browser plugin, there are two unique elements to consider: the browser's security model and the browser's privacy model. You should also realize that auto-update is important and must be done securely.

Browser Security Model

You must deeply understand and respect the browser's security model, and not accidentally break it. This security model includes elements such as the same-origin policy, the boundaries between pages, and what can and can't open a new window, resize a window, and so on. You must also remember to treat the other sides of connections as malicious with respect to the browser. That is, from the browser's perspective, your component that sits on a web server could be under the control of an attacker, who can then send malicious content to your plugin and compromise additional systems. (Similarly, your plugin may be modified or run through a proxy that rewrites data to attack the server components.) However, there are times when breaking the browser security model is intentional and appropriate. For example, some security testing plugins do so.

Several experts have told me in all seriousness that browser security models are now so complex that I should not even write a section about this. I'm tempted to say that browser plugins, like crypto, is a domain for which you need expertise and penetration testing. It would be wonderful if browser manufacturers could fix this, and offer easier to understand plugin models so that plugins could be developed without putting the people who install them at risk. For a history of the three flaws in one popular plugin, see Mark Pilgrim's article “Avoid Common Pitfalls in Greasemonkey” (O'Reilly Network, 2005). (As an aside, Pilgrim's blog post is a good example of a “Note to API Callers,” as discussed in Chapter 7, “Processing and Managing Threats.”) For a book-length treatment of the full complexity of modern browsers, see Michal Zalewski's The Tangled Web (No Starch Press, 2011).

Browser Privacy Model

Similar to respecting the browser's security model, your plugin should respect the browser's privacy model. You should not allow tracking or surveillance in any way that the browser does not, and you should ensure that your controls are at least as accessible as those offered by the browser.

Auto-Update

It is very likely that you will have numerous security issues with your plugin, and you should therefore ensure that it's easy to report bugs to you, and that your updater works well with the browser's auto-update mechanism, and that you have a security update process that can deliver security updates without any tradeoffs such as new or changed user interfaces, new licenses, or similar impediments to upgrading.

Cloud Tenant Threats

You can use an attacker grouping approach to break out cloud threats. There are two main classes of new attackers (threats) when you move an IT system to the cloud: those from insiders at the cloud operator, and those from your fellow tenants of the cloud system. There are generally some new instances of availability threats, based on the increased complexity of connectivity. There are also two sets of legal threats: those that add complexity and/or effort or reduce the assurance of compliance, and the different legal standards around data given to third parties. Lastly, there's a hybrid of those legal threats, which are threats to forensic response. In this section, you'll see the term cloud provider used to refer to an organization that offers any combination of infrastructure, platform, or software as a service. Their customer is you, and like their other customers, you are a tenant of their service. Attackers might be tenants, or those who have broken in.

Insider Threats

When you move your data or operations to someone else's cloud, you add a trust boundary. That boundary has the employees and contractors of the cloud operator inside of it, with your data. As administrators, they have unavoidable technical access to the data you provide. They may intentionally attack you, fall victim to an attack themselves, accidentally misconfigure software, or fail to perform maintenance, such as wiping disks between re-allocations.

There are two ways to mitigate this threat: contractually and cryptographically. Contractual approaches dominate today because they're easier; and for most of the risks, it turns out that a contract is sufficient. However, contracts may not be subject to negotiation unless you're spending lots of money. Unfortunately, companies often use contracts to protect personal information, where much of the risk is external to the companies signing the contracts.

The cryptographic approach is to encrypt the data (and possibly obfuscate the code) before sending it. This is easier with a cloud storage system than with software as a service. Well-encrypted, integrity-protected, and authenticated data can be stored anywhere with a very low reduction in safety. (The encrypted state of the data will influence what processing can be done on the encrypted data. There is interesting cryptographic research on processing encrypted data, which as of this writing usually isn't part of the standard crypto libraries that you should use.) Of course, the keys need to be stored securely, or you're trading confidentiality and integrity for availability.

Co-Tenant Threats

These threats are to tenants of “infrastructure as a service” (IaaS) and to a lesser degree “platform as a service” (PaaS), whereby the provider/tenant trust boundary allows tenants to execute arbitrary code inside the data center. In IaaS, the code execution privileges are effectively unlimited, although they may formally be limited to what a non-administrative account can do. In PaaS, the code that is supposed to execute is far more limited. Historically, few platforms were constructed with a threat model that the most important attacker is already on the system. It is far more common, and probably even appropriate, for platform designers to worry about the trust boundary between the system and those who cannot execute any code. Unless the platform software has been carefully constructed to resist elevation of privilege attacks and to prioritize finding and fixing those, there are likely vulnerabilities that allow an attacker to violate the rules. That leads to second-order threats to the cloud tenants.

There is also a set of threats from other tenants, ranging from the trivial to the movie plot. At the trivial end, you may be behind the same single firewall as your competitor, or someone without an IT department. You might also be on the same domain as they are, such as cloudapp.net or s3.amazonaws.com. Some defenses, such as firewalls, need to be managed as part of the cloud deployment. Your systems may also come under attack as stepping-stones to other tenants of the cloud provider. Beyond that, another tenant might try to bust out of their virtual machine and take over a host, giving them access to your machine as well (if you're sharing machines). An attacker might also be able to access the network or storage (either local cache or storage specific to the cloud). Another tenant might be taken over to run a DoS attack against you, or an attacker might sign up to do so.

Threats to Compliance

There are three typical issues here. First, for many compliance regimes—but most notably PCI and HIPAA—the entire stack, including physical security, needs to be compliant. Therefore, the only way to have a PCI assessed app is for your cloud provider to be assessed PCI compliant. Second, there can be issues with auditing and logging. Not all cloud operators will provide logs of access to their APIs or web consoles. This can lead to technical issues, such as it may be impossible to see who added or changed accounts. That technical issue can lead to a compliance issue. The final issue is when you get into the PaaS and SaaS market, you often lose the ability to leverage cryptography at the filesystem or database level, as well as any concept of end-to-end encryption.

Legal Threats

The primary new legal threat when you move data to the cloud relates to laws that (at least in the U.S.) substantially reduce your ability to know about or challenge legal requests for your information, such as subpoenas or warrants. Data you store on your own systems is often more legally protected than data you store on someone else's systems. The legal demands served on your cloud provider may also contain provisions forbidding them from telling you about those demands, or you may be informed after the data has already been provided.

Of course, there's also the need to negotiate agreements related to privacy, security, and reliability. Contractual provisions for both privacy and security need to cover your business needs and your compliance needs. Privacy is covered by a hodge-podge of U.S. regulations. In the European Union, and those places with a safe harbor agreement for data from European countries, there's a set of requirements, most importantly for the organization holding the data to name a data custodian. That custodian has certain responsibilities, and you'll need to address those if you're moving data collected under EU or other similar privacy regimes.

It is, of course, important to consider these issues with your attorney; this section is intended only to outline some of the points you should discuss with them. Your attorney may have additional concerns.

Threats to Forensic Response

After an intrusion, your VM may be shut down by the cloud provider. You may have instantiated a system large enough that performing complete snapshot or a memory dump is time consuming; but most important, you may not have a defensible chain of custody.

Miscellaneous Threats

Some cloud providers offer easy to use virtual machine images, uploaded by kind strangers for your convenience, and out of the goodness of their hearts. Sometimes, the people who uploaded them really did so out of the goodness of their hearts. Other times, the images are not so safe, and trusting them for anything serious is probably foolish.

Cloud Provider Threats

There is also a set of threats to the cloud provider that cloud providers must consider, and cloud customers should consider. These are all threats from or caused by the folks to whom you give access to your systems. These are split into threats caused by malicious behavior by the tenant that targets the provider, such as attempts by the tenant to hack the provider; and threats caused by tenant behavior, such as blacklisting.

Threats Directly from Tenants

The largest threat is that a tenant will find a way to break out of whatever sandbox you put them in, and be able to take actions you don't want them taking. Those actions might be on the order of running code on the raw hardware and tampering with either your billing or your other customers, or it might be connecting to networks that should be firewalled off. In particular, US-CERT has warned about threats to the IPMI (Intelligent Platform Management Interface) (US-CERT, 2013). These threats are sometimes managed by putting IPMI on an isolated network. If a tenant breaks out, they may be able to access such a management network. The sandbox escape threats are more likely when clients are held back by fewer security boundaries. Thus, a client in a Software as a Service (SaaS) environment has more barriers than one trying to escape from an Infrastructure as a Service offering.

There's also a fraud (repudiation) threat, which is that a new tenant might sign up with someone else's personal data and/or credit card, preparatory to committing fraud, running a botnet, or DDoSing a game server. These threats can be partially addressed by charging the card immediately for the first portion of service, or charging a sign-up fee, although that may be inhibitory to new business. If there are throttles for e-mail sent or similar things, it may be useful to tie them to length of tenancy.

Unfortunately, many of the ways to address these threats are at odds with the low-friction, get-started-quickly value proposition that cloud providers want to offer. There may be interesting ways to address these trade-offs that have yet to be invented, but for now appropriate monitoring for anomalies is important. Such monitoring has to build on the unique elements of the business, so custom code will be needed.

Threats Caused by Tenant Behavior

There's a set of threats that tenants can cause, including spamming and piracy. These problems are magnified in those cases where accounts are free to anyone, and essentially anonymous. These threats are less clear-cut than issues such as spoofing, tampering, or information disclosure. If your requirements are clear, there's no question about whether the threat violates them. In contrast, perhaps the e-mails are all going to an authorized list? Perhaps the person who uploaded that song is the artist, or is authorized to do so? Or perhaps the use of an image is permissible under the law? This lack of clarity makes these threats harder to manage than the classical security violations.

The United States has a somewhat clear set of rules regarding notice and take down. These give cloud providers a legal defense against copyright claims until they receive a formalized notice of infringement, after which they must take certain actions, generally taking down the content. Following those processes is prudent, as jumping to judgment and action on a notice may threaten the protections you otherwise have.

These threats lead to an indirect threat to the provider and other tenants, which is backlash from the attacks. That backlash can include visits or calls from law enforcement, reports from other parties that require investigation or response, and blacklisting. Once a tenant has sent spam, been part of a botnet, and so on, there's a risk that the IP, subnet, or ASN may be blacklisted. The behaviors that lead to blacklisting may be violations of the terms of service. Responding to the behavior and getting IP addresses de-listed is likely a manual and time-consuming task.

Mobile Threats

Threats to mobile devices are generally similar to threats to other computers. For example, someone who can run code on the device may read your files, use your authentication data, etc. There are a few additional threats for mobile devices, including increased likelihood of device loss, difficulty managing the devices, and business models conflicting with security updates.

The threat of device loss is clearly higher for mobile devices than for servers. The two main ways to address device loss are device wipe and data wipe. Device wipe can cause conflict, as many devices are owned by your employees or contractors, so in wiping their device, you may be deleting data that is not yours to delete. Data wipe can be accomplished by sending encrypted data to the device, and only sending the key needed to access the data when the data is accessed.

Many mobile devices are locked to specific software providers, and constrain which software can be loaded onto the device. This may threaten the ability of a compliance team to load them up with compliance-ware. When a mobile device is locked, then you define the person holding the device as a threat. The device and its physical shell become a trust boundary that you must carefully consider, as all communication is subject to tampering, denial of service, and information disclosure.

Lastly, many wireless carriers threaten the ability of the software makers to deliver patches to devices in the field, claiming that arbitrary patching threatens them with bricked devices and support costs. This means that fielded mobile devices can be vulnerable to security problems that are fixed in newer versions of software.

Summary

The web is comprised of software which can be threat modeled like any other software. There are a variety of recurring threat classes that are best managed by using safer languages and test frameworks that focus on those classes. These threats are things like XSS and SQL injection. There are also recurring patterns within the web and cloud that you should consider when threat modeling.

The browser and its plugins have threat models that should be documented by the browser maker. Those threat models should cover both security and privacy, and you need to understand them to program the browser.

Cloud tenants come under threat from insiders at the cloud provider and from co-tenants. Limits on code execution make attacking your co-tenants harder, so as you move up the stack from IaaS to PaaS to SaaS, co-tenant attacks become less likely. There are also a variety of threats to compliance and legal threats that cloud tenants must account for. In addition, forensic response may be threatened if you are a cloud tenant.

Cloud providers have to worry about threats of their tenants attacking them, and the side effects that can occur when their tenants attack others. In particular, if tenants can access management networks that are normally isolated, the impact on security can be exceptionally large.

Mobile computers, including laptops, tablets, and phones are much like other computers, except the frequency of device loss is far higher. Some mobile devices are locked in ways that restrict the loading of software, making it hard to add compliance-ware, and possibly changing the threat model to include the person who uses the device. Such locking may also threaten patching, leaving devices vulnerable to known issues, and effectively removing the “need to find a vulnerability” barrier to attack.