week 7
mike93
Spring2020ISOL536Chapter11Slides11.pptxUniversity of the Cumberlands School of Computer & Information Sciences
ISOL-536 - Security Architecture & Design
Chapter 11: Cloud Software as a Service (SaaS)
Spring 2020
Dr. Vululleh
Chapter 11: Cloud Software as a Service (SaaS)
11.1 What’s So Special about Clouds?
11.2 Analysis: Peel the Onion
11.2.1 Freemium Demographics
11.2.2 Protecting Cloud Secrets
11.2.3 The Application Is a Defense
11.2.4 “Globality”
11.3 Additional Requirements for the SaaS Reputation Service
Chapter 11: Cloud Software as a Service (SaaS)
11.1 What’s So Special about Clouds?
Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.
In the mobility example, we represented the management of the mobility clients and the reputation service as servers in the “cloud.” Of course, these services require far more architecture than a single or even a horizontally scaled set of servers.
11.2 Analysis: Peel the Onion
From our perspective, we need to know that data are pulled and received from many sources via a data-input function. That function, like the Data Gatherer in the business analytics example, must normalize and parse many different types of data so that the data may be kept in a unitary fashion that can be processed for reputations. One logical function, therefore, is the receipt and initial processing of the various data types. Neither of the figures of the SaaS architecture in this chapter portray reputation data collection.
Figure 11.1 SaaS Reputation Service architecture (in the cloud).
Figure 11.1 represents the cloud service as it may look, logically, from the user’s, that is, the mobility security software’s, perspective. The “cloud” means that the service has multiple points of presence across the globe to be queried. Cloud also implies large scale to support thousands, even millions, of clients. The mobile device software doesn’t need to understand any of the details behind that service. In other words, the details of data retrieval, processing, rating, and responding to queries are entirely opaque to the querying software.
11.2.1 Freemium Demographics
One standard method for dealing with the fact that authentication does not protect against all attacks is to log the actions taken on the system by the authenticated entity. Logging system activity is a typical additional control. Monitoring is often employed so that, at the very least, malicious actions can be tied to a user of the system. In order to monitor, the activity first must get logged. At best, instantiation of malicious action will be noticed and can be stopped before serious damage takes place. For social media sites, logging of action sequences is critical to identifying malicious users and ejecting them from the system before they can harm other users or the system itself.
Since for the reputation service we understand that attackers can gain access, all actions taking place on the service by each device are logged. Anomalous sets of activities trigger an investigation from the 24×7, around-the-clock security monitoring team.
In Figure 11.2, you will see the authentication service. As in the eCommerce example, the architecture has placed the authentication service within its own highly restricted network segment. Only the web front end may issue authentication requests. In this way, the authentication service cannot be attacked from the Internet. First, the front end would need to be compromised.
11.2.2 Protecting Cloud Secrets
There are certificate chaining validation methods that address this problem. And Indeed, if each enterprise customer requires a separate signing key (and most will!), then our cloud reputation service will have to employ a fairly sophisticated certificate signing and validation implementation that accounts for multiple certificate signing keys. Still, messages from the service may be signed with the same private key (so that every device can employ the public certificate/key to validate).
11.2.3 The Application Is a Defense
Even the best, most security-conscious development teams occasionally allow a serious security vulnerability to leak out into production software. So how can a service like the reputation service ensure that all non-valid input is rejected? Security software testing is beyond the scope of this book. Still, it may be worth mentioning that a typical testing strategy is to “fuzz” inputs that are likely to receive malformed messages (or other input data). When we examined the file processing chain in the endpoint security example, fuzzing was one of our recommended security controls. That software must be made to withstand poor inputs; it will be examining malicious files. In a similar way, the reputation service front end, which must receive requests from possibly malicious sources, will benefit from rigorous fuzz testing. In order to protect services further within the chain of processing, the reputation service vendor will want the front end to be as bulletproof as possible. Fuzzing is an accepted test methodology to assure a robust input defense.
11.2.3 The Application Is a Defense – Cont.
The sequencing of processing goes something like this:
A device requests a reputation for an object.
The query response process (front end) requests a reputation from the reputation processor.
The reputation is returned to the device.
It is also placed in the cache for rapid retrieval, should a subsequent request for the same information be made.
New data come in about the object.
In the back-end data store, the object reputation changes.
The reputation change triggers the reputation processing component to check the cache for the presence of the reputation.
If found (i.e., it’s still in the cache), the reputation in the cache is deleted, forcing the front end to refresh the reputation when it is next queried.
11.2.4 “Globality”
In Figure 11.2, you will see that the back-end is actually not discrete but connected and replicated to all the points of presence across the globe. This is very typical for a global SaaS service. It’s desirable to keep processing as close to the consumer as possible. Consequently, all the reputations must be replicated to each point of presence. This means that across the globe, in each data center that hosts the service, the front end, the processing service, and the reputation data are duplicated. If the reputation service is to be accurate everywhere, this replication of data has to be very fast so that a reputation query in Singapore is as accurate and up-to-date as a query in London or Hawaii. This need for the rapid dissemination of updates and rigorous duplication of data everywhere implies that the back-end can be thought of as one global system rather than discrete points. At the back-end, all the systems are connected, as they must be to achieve the performance and accuracy required from a global cloud service.
11.2.4 “Globality” – Cont.
There are three architecture patterns that seem to be emerging to provide sufficient tenant data protection.
Encrypt data as it enters the service; decrypt data when it exits – Encryption as data enter the service and decryption at exit is the preferred solution from the customer’s perspective, as long as the keying materials are held by the customer or the customer’s trusted third party.
Separate processing within the infrastructure – Each customer essentially receives distinct infrastructure and processing. Separation at the infrastructure layer is very popular with services that offer a “platform” and infrastructure, that is, Platform as a Service (PaaS) or Infrastructure as a service (IaaS).Each customer essentially receive distinct infrastructure and processing.
Encapsulate data such that it remains segregated as it is processed - If the vendor requires economies acquired from building a highly shared application (many SaaS vendors try to reap these economies) then the simple, obvious solutions will not work.
11.3 Additional Requirements for the SaaS Reputation Service
The following list of requirements focuses on the different, cloud aspects of this architecture. Earlier chapters covered in some depth other aspects, such as endpoint requirements, web requirements, and administrative needs.
The calculation processor will not read from the reputation cache. A message will be sent from the calculation processor to the cache to execute a delete of all references to an object in the cache. Failure of the deletion will be logged. No acknowledgment will be returned by the cache in response to the deletion message.
Reputation request messages must be constructed by the web front end. Only the queried object will be passed to the calculation processor.
The front end will sanitize and validate messages from the mobile device. Any message that fails validation in form or data must be rejected.
Before reputation requests will be received, a device certificate, signed by the private key of the reputation service, must be validated by the reputation front end. Certificate validation failure must cease all further communications.
11.3 Additional Requirements for the SaaS Reputation Service – Cont.
All customer reputation requests and request histories will be encapsulated with an unpredictable token. The token will be related to a cryptographic hash. The hash is the only value to be associated to service tenants. The hash-to-client relationship must be kept in a separate network segment, under separate administrative control (different team) from the application administrative team and from the storage and data administrators. Hash-to-token correlation will be done by a separate process running in the back-end, unexposed to any processing outside the internal back-end networks. Wherever stored, tenant reputation histories will be tagged with the token only. No mention of customer identity can be placed within that administrative domain or network segment.
Reputation data will be pushed from the data farm on the internal network to each reputation data instance.
Reputation data instances will exist on a segregated network that only receives requests from the reputation calculation and processing module.
There will be four distinct layers, as shown in Figure 11.2:
a. The DMZ, bastion layer containing the web service termination. Authentication of device certificates will take place before a reputation request may be made.
11.3 Additional Requirements for the SaaS Reputation Service – Cont.
There will be four distinct layers, as shown in Figure 11.2:
The DMZ, bastion layer containing the web service termination. Authentication of device certificates will take place before a reputation request may be made.
A front end module that validates requests before any processing may occur. Requests will be
regenerated before they are passed on to subsequent layers. Objects about which a reputation query
is made may only be passed from the front end after careful validation and format check. The
reputation cache is placed in this segment. It receives requests only from the front end.
The reputation calculator/processor, which only receives reformed requests from the front end.
The local reputation instance for a point of presence, which will only receive requests for data from the calculation module.
The front end request processing input must pass rigorous fuzz testing before release.
The calculation module’s request handling processing chain must pass rigorous fuzz testing before release.
An HSM will be employed at each node to perform certificate, message, and data signing operations. Multiple private keys, including customer specific keys, must be supported. Every node must validate every device certificate.*
Chapter 11: Summary
An architecture specific to global cloud products with many points of presence is the network interconnection. One way to achieve this is to establish a series of connections using VPN or IPsec tunnels over the Internet. For a performance sensitive SaaS, the vagaries of Internet routing will influence transmission times. Hence, although essentially secure across the hostile Internet, such an architecture is likely to be unsuitable for this purpose. Instead, where performance and security must both be served, a private network is often the better choice.
