The goal of my last article was to eliminate the mystery of the “Cloud” by breaking it into easy‐to‐understand building blocks. A key takeaway is that the cloud is not a single operating option; it has many building blocks. The blocks or choices have a significant impact on your bank’s risk exposure. To make it clearer, how much risk is your bank willing to assume in today’s cloud environment?
Cloud computing vendors are likely hacking targets with the re‐emergence of the Meltdown and Spectre hardware vulnerabilities.
What sparked widespread worries is that these two software attacks could compromise computer chips and read sensitive information. Both vulnerabilities are based on flaws in all processing chips used in almost all computers since about 1995. There are very few exceptions. And the risk is the highest in shared multi‐tenant cloud environments.
You might think: “I have a great patching program and policy which are implemented and followed faithfully,” allowing you to think “I’m in an excellent, secure position.” The question is: “How closely do you look at your hardware patching, which is separate from the Microsoft Windows patching?” This question should be asked of the Cloud provider, and the response factored into your IT risk assessment and vendor management program
Objective
My goal in this article is to look at the different cloud choices and determine which ones are appropriate for the most riskaverse banks, and why. From Part 1, we learned about the five Critical Characteristics of Cloud computing. The focus of this article is on the service and deployment models, which will assist in understanding the risks from the Meltdown and Spectre vulnerabilities.
The three service models are:
- SaaS (Software as a Service)
- PaaS (Platform as a Service)
- IaaS (Infrastructure as a Service)
The cloud is not always all “hands‐off.” It may appear that way since there is no hardware purchase, no hardware setup, and potentially no application setup. Yet there are risks and they vary by service model choice. For instance, evaluate what data is stored in the cloud, and understand who controls the hardware patching, who assumes the liability and responsibility for breaches.
Under each model, the bank has different responsibilities for maintaining the system, such as implementing the proper patch management policy/program for hardware, software and operating system. Using a data flow diagram is the best way to grasp the what and where activity is happening.
SaaS enables the bank to access the software application, but the bank does not maintain the underlying hardware, software or operating system. The vendor is responsible for ensuring that the environment is available and working as expected. The vendor management process should show the SLAs (Service Level Agreements) for the application, and the implications if they are not met should be documented in the vendor file. It generally is the vendor’s responsibility to update the hardware and operating system. The bank’s vendor management program should spell out vendor responsibilities, due diligence and patch management duties. This is a dedicated service and within your Vendor Management program, the bank needs to understand where the data is stored, where it is backed up and the impact of a disaster. Ensure that the answers agree with bank IT policies.
PaaS allows the bank to install its own “apps” in the cloud, but overall control of the environment is retained by the cloud hosting company. Typically, in this scenario, the bank cannot control certain environment settings. It is critical to understand which party controls the patching process and what system backups exist. As always, understand who maintains the system and for which parts. Don’t be fooled into thinking that this is someone else’s problem.
IaaS is akin to renting someone else’s computer and it lives someplace else. In other words, the bank has access to the entire operating system and retains the ability to tweak most settings, including those related to storage. Most likely, the bank is responsible for maintaining all software and the operating system. This means that the bank requires procedures to patch hardware, maintain the system and set specific procedures for backups. The processes and procedures must be documented in your policies.
Regardless of the service model chosen, you have to know your responsibilities. Review bank cloud policies and add sections to your policies, procedures and programs specifically addressing data, applications and storage. Cloud computing is different and can’t be treated like local systems.
Deployment Models
Again, going back to Part 1, the following four deployment models were discussed:
- Private
- Public
- Community
- Hybrid
There are essentially three deployment models – Private, Community and Public – with the fourth being a hybrid of any of the previous three.
Private cloud service: The hardware is dedicated to a single customer. This means that your server(s) will all run on the same equipment. That equipment is not available to any other customer at any time. Dedicated cloud hardware is more expensive. The impact of any hardware vulnerability such as Meltdown or Spectre is significantly less because it only impacts your bank and you control the cloud. No other multi‐tenant customers can negatively impact your system.
Public cloud service: This approach is open and available to anyone, at any time and used for any service. This type of service is generally less costly and more vulnerable. It would be like allowing a customer to come into your business and place an application on your server and share it with the world. Generally, it is lacking controls that bank examiners probably believe is too risky.
Community cloud service: This is very similar to a Public cloud service, with the exception that the cloud customers are generally like‐minded with similar intentions. Is your core provider also a Community cloud service provider? They have an application that runs on a server that you have access to, but you do not control the operating system or the updates. It can be scaled out quickly and can grow with your growing customer base. In recent years, as the core providers develop new applications, they typically use web URLs for access. Does the core provider use dedicated hardware for your application?
Cloud Risks
As with any computer system, there are risks. One of the biggest risks is the computer operators; the next is patching shortcomings. Unpatched systems allow the exploitation of vulnerabilities that could be mitigated.
As described earlier, Meltdown and Spectre could be used to compromise computer chips, such as Intel, and read sensitive bank non‐public personal information like PINs and account numbers. The interesting piece of this dilemma is that it requires hardware and software updates. We know who is responsible for our system updates, but in cloud services, who handles those updates and who takes the risk if they are not performed and there is a breach? Does your vendor management policy/program review and account for this?
As of the published date of this article, there are firmware patches (patches to the hardware) that can be downloaded and applied to the servers and workstations alike to mitigate Meltdown and Spectre, but they are not complete solutions. Intel and AMD are still investigating this vulnerability and updating their firmware patches. Microsoft has implemented Windows software patches, which are a partial solution for these vulnerabilities.
The cloud is all about sharing resources, expanding resources and lowering cost. If the physical hardware servers in the cloud are designed to handle multiple logical servers (multi‐tenants), they could be more vulnerable than a single dedicated server that is in your server room. Any time virtual servers are located on the same hardware, it is possible to have a vulnerability that could be exploited. Up until this time, there were no known vulnerabilities.
In a Private cloud, theoretically, the data is stored on a single server dedicated to your processes. This mitigates the above mentioned chip vulnerabilities. Your data/applications are not shared with anyone else. No one should be able to get at your data if you have risk‐assessed your environment and locked it down appropriately. But, think outside of the box for a moment. Does the cloud service provide backup IT services? Where do those services store your data? Is it on the same box (read: same hard drive), or is it on another server dedicated to your processes? Is it stored on a shared server? These are things to think about when you sign the cloud services contract. “Dedicated” may not always mean that your data is on a dedicated device.
A Public cloud is the worst of all the scenarios and poses the greatest potential risk. The data stored in a public cloud should be carefully evaluated to ensure that the information stored in this type of cloud is public information, as you would store on an informational website.
In a Community cloud, understand how the data is secured. Ensure that the community is on the same security page you are. This is imperative. Talk with the provider and understand how the data and the applications are secured and separated from each other. With the proper controls in place, it is possible to create and maintain a secure environment for everyone. The key is being like‐minded and placing the appropriate trust in the cloud provider. Do your homework!
It’s all dependent on the data that you are storing, moving and accepting. Is there NPI information there? Is it sensitive corporate data? Secret marketing data? My suggestions are simple. Create data flow diagrams that document the processes, the data (in transit and at rest), how it is secured, and who has access. This is not an exhaustive list, but the beginning of the discussion. Each application and dataset is different and should be treated differently. Remember, hackers are always looking for easy ways to get to the data that you are safekeeping for your customers. It is a trust between you and your customers that should not be broken.
Join Jim Baron on TCA’s April 17, 2018 webinar to learn to talk “Cloud,” it’s a whole new world!
