Cloud: 5 / 3 / 4, the responsibility line, the risks, and the ten services

5 / 3 / 4

The definition of cloud computing that every standards body and every exam paper uses comes from NIST SP 800-145, and it is a triple worth memorising as a number before you memorise it as a list: five essential characteristics, three service models, four deployment models.

The five essential characteristics are what make a service a cloud service rather than a rented server.

1. Broad network access — reachable over the network by standard mechanisms, from thin clients and thick clients alike.
2. Rapid elasticity — capacity expands and contracts with demand, and resources are released when the work ends.
3. Measured service — usage is metered at an abstraction appropriate to the service (storage, processing, bandwidth, active accounts), then monitored, controlled and reported, so both parties see the same numbers.
4. On-demand self-service — the consumer provisions capacity unilaterally, with no human interaction with the provider.
5. Resource pooling — a multi-tenant model in which physical and virtual resources are assigned and reassigned by demand, with location independence, though the consumer may be able to constrain location coarsely (country, region, data centre).

Characteristics 4 and 5 are the two that carry security consequences you can name. Self-service means resources are not permanent parts of the consumer's IT estate — nobody in IT necessarily knows they exist, which is where shadow deployments come from. Pooling means somebody else's workload is on your silicon.

Three service models, and the line that moves

The three models are nested: each higher one hands more of the stack to the provider.

• SaaS — the provider runs the application; the consumer uses it, typically through a browser, and avoids installing, maintaining, upgrading and patching anything. Consumer control extends at most to user-specific application settings.
• PaaS — the provider supplies a platform: building blocks, language tooling, runtimes and deployment tools. It is fairly described as an operating system in the cloud. The consumer controls the deployed application and some of its configuration, but not the operating system.
• IaaS — the consumer gets virtual machines and virtualized hardware, and controls the operating system, the deployed applications, and possibly limited control of select networking components such as host firewalls.

That last clause — limited control of select networking components — belongs to IaaS and nowhere else, and it is the phrase exam questions use to fingerprint the model.

Worked example — the Rideau Library catalogue, three ways. Suppose a critical vulnerability is announced tomorrow in the Linux kernel, in the application runtime, and in the catalogue application itself. Who fixes each?

Under SaaS, the library subscribes to a hosted catalogue product. The provider patches the kernel, the runtime and the application; the library's obligations are to manage its own user accounts, configure the product's sharing and retention settings correctly, and hold the provider to a contract. Every one of the library's remaining risks is an identity, configuration and contract risk — which is exactly where SaaS breaches actually happen.

Under PaaS, the library deploys its own catalogue code onto a managed platform. The provider patches the kernel and the runtime; the library patches its own application and owns every dependency it pulled in. Notice what has changed: the library now has code to maintain, but still no operating system to maintain.

Under IaaS, the library provisions virtual machines. The provider patches the hypervisor and the physical estate; the library patches the kernel, the runtime and the application, configures the host firewall, and owns the guest images and snapshots. The library has the most control and, in exact proportion, the most work.

The generalisation is the one sentence a marker looks for: a control does not disappear when you move to the cloud — it changes owner, and the owner changes with the service model.

Four deployment models

• Public — open to the general public or a large industry group, owned by a seller of cloud services and running on the provider's premises. Every component sits outside the enterprise firewall in a multi-tenant infrastructure. Cheapest; weakest or absent service-level agreements; and compliance with privacy law remains the subscriber's responsibility regardless of where the data sits.
• Private — within the organisation's own IT environment, managed in-house or outsourced, on premises or off. The motivation is security, and specifically tighter control over the geographic location of stored data.
• Community — access restricted as in a private cloud, but shared among several independent organisations with common requirements that usually also need to exchange data. Healthcare is the standard example; costs spread over more subscribers than a private cloud and fewer than a public one.
• Hybrid — two or more distinct clouds bound together by technology enabling data and application portability, with sensitive data kept in the private portion and cloud bursting as the canonical mechanism for handling load peaks.

A useful memory hook: private is most secure and most expensive with limited scalability; public is cheapest and most scalable with the weakest guarantees; community and hybrid sit between, and hybrid is the one that buys public-cloud scalability without putting the sensitive data there.

Cloud-specific risks, each with a countermeasure

The Cloud Security Alliance's classic threat list is the one to be able to reproduce with countermeasures. Note first the discipline the exam rewards: some risks are cloud-specific — they exist because of the delivery model — and others are ordinary risks that merely also occur in cloud. A SQL injection flaw is not a cloud risk; a hostile co-tenant on your CPU cache is.

1. Abuse and nefarious use of cloud computing. Easy, often free, registration lets attackers operate from inside the cloud — spam, malicious code hosting, denial of service — with the provider's reputation and address space behind them. Countermeasures: stricter initial registration and validation; monitoring for credit-card fraud and coordinating on it; comprehensive inspection of customer network traffic; and monitoring public blacklists for one's own netblocks.
2. Insecure interfaces and APIs. The management API is the control plane; everything else rests on it, and it is reachable by anyone on the Internet who obtains a credential. Countermeasures: analyse the provider's interface security model; strong authentication and access control together with encrypted transmission; and understand the whole dependency chain of APIs you build on.
3. Malicious insiders. The model confers unprecedented trust on the provider, and provider system administrators and managed security providers are structurally high-risk roles with no equivalent on a system you run yourself. Countermeasures: strict supply-chain management and supplier assessment; human-resources requirements written into the legal contract; transparency into the provider's information-security practices and compliance reporting; and defined breach-notification processes.
4. Shared technology issues. The shared substrate — processor caches, GPUs, memory controllers — was never designed for strong multi-tenant isolation, and per-client VM isolation helps but is not sufficient. Countermeasures: installation and configuration best practice; monitoring for unauthorised change; strong authentication and access control for administrative operations; SLAs covering patching and vulnerability remediation; and vulnerability scanning with configuration audits.
5. Data loss or leakage. Countermeasures: strong API access control; encryption and integrity protection for data in transit and at rest; analysing data protection at design time and at run time; and strong key generation, storage, management and destruction.
6. Account or service hijacking, usually through stolen credentials. Countermeasures: prohibit credential sharing between users and services; two-factor authentication; proactive monitoring for unauthorised activity; and understand the provider's policies and SLAs.
7. Unknown risk profile. Moving to cloud cedes control over things that affect security, and shadow deployments bypass policy entirely. Countermeasures: disclosure of applicable logs and data; partial or full disclosure of infrastructure detail such as patch levels and firewall configuration; and monitoring and alerting on the information that is disclosed.

Data protection: two database models

The multi-instance model gives each subscriber a separate DBMS on a separate virtual machine instance; the subscriber controls role definition, user authorisation and administration, and the isolation is one the subscriber can reason about. The multi-tenant model gives all subscribers one predefined shared environment and separates them by tagging each row with a subscriber identifier. It gives the appearance of exclusive use, and its correctness depends entirely on the provider's implementation — a single missing predicate is a cross-tenant disclosure.

The ideal at-rest posture is that the client encrypts and stores only ciphertext, with the provider never holding the key. Be honest about what that leaves: even then, corruption and denial of service remain. Encryption protects confidentiality; it does not stop the provider, or an attacker inside the provider, destroying the data or making it unreachable. Candidates who claim encryption solves cloud data risk lose the mark that this sentence earns.

The ten Security-as-a-Service categories

The CSA's SecaaS listing is a taxonomy of security functions delivered as cloud services. There are ten, and the count itself is examinable:

1. Identity and access management — identity provisioning and deprovisioning, plus access management (authentication and access control); requires the provider to exchange identity attributes with the enterprise's chosen identity provider.
2. Data loss prevention — protecting and verifying data at rest, in motion and in use.
3. Web security — real-time protection delivered by proxying or redirecting web traffic through the provider.
4. E-mail security — control over inbound and outbound mail: phishing and spam, policy enforcement, encryption and continuity.
5. Security assessments — third-party audits against a standard; distinctively outside the provider's own province, though the provider supplies the tools and access points.
6. Intrusion management — detection, prevention and response: IDS plus IPS plus the reaction to what they find.
7. Security information and event management — aggregating log and event data by push or pull and correlating it for real-time alerting.
8. Encryption — key material and cryptographic operations offered as a service.
9. Business continuity and disaster recovery — flexible infrastructure, redundancy of function and hardware, monitored operations, geographically distributed data centres and network survivability.
10. Network security — allocating access, distributing and monitoring network security services.