The Cloud Breach Blame Game

As cloud computing becomes an ever more critical component of any modern financial technology infrastructure, cloud deals are coming under increased regulatory scrutiny.

Way back in 2007, the network of Heartland Payments Systems was hacked. Over the following months, the New Jersey credit and debit card processing business admitted that the perpetrators had gained access to data on more than 100 million cards. Until the Equifax hack in 2017, it was the biggest data breach of all time.

After the hack, Heartland founder and CEO Robert Carr went on the offensive, putting the blame on compliance auditors who had previously given the company a clean bill of health. Neither Carr, nor any other senior managers, lost their jobs. By blaming a third party, he successfully shirked responsibility for the massive loss of client information. More than a decade later, the results would likely have been different. 

This kind of buck-passing is becoming inconceivable, says Jennifer Bayuk, an independent information security expert. And as regulators increasingly turn their attention specifically to cloud security, she predicts that a company’s executive management will be held more accountable.

“Carr got away with it 10 years ago. I don’t think people are getting away with that anymore,” says Bayuk, who has held cybersecurity and operational risk management roles at JP Morgan, Citi, and Bear Stearns. 

While Carr got to keep his job, Rick Smith, who was CEO of Equifax at the time of the hack, was forced into early retirement—albeit, with hefty stock compensation. 

It’s becoming clearer that regulators will not allow financial firms to duck ultimate responsibility for security, and are turning their attention to the cloud. The US Securities and Exchange Commission (SEC), for example, sent out a risk alert in late May saying its examiners had identified risks with the storage of customer records by broker-dealers and investment advisers in the cloud, and noted that firms do not always use the available security features offered by providers.

Cloud Complexity

Certainly, cloud adoption in fintech has proceeded slower than anticipated because of concerns around security. And no wonder—cloud deployment is complex and multi-faceted. 

Firstly, there is complexity around how large banks and asset managers use cloud, with multi-cloud environments, contracted to several providers in different geographies. They will have private and public clouds, and a universe of third parties who may have access to sensitive data, all with their own connections to their own providers.

Even smaller firms, which could have just one provider or none, could find themselves in the cloud by accident, as it were, by virtue of using a software-as-a-service vendor that is running on top of AWS or Azure, or because they use middle-office systems like Workday or Salesforce, says Mark Nicholson, who leads the financial services cyber risk services practice at Deloitte. 

“The nature of relationships gets fairly complicated and you have to make sure you understand where you are in that chain, how many degrees away from the actual cloud provider you are,” he says. “Each of your vendors has different responsibilities to you depending on where in the relationship they are.”

So the question becomes: Where along these interlinked chains does responsibility lie? The big cloud providers would argue that they do have certain responsibilities—but only to an extent. Providers like AWS encode a shared responsibility model into their contracts, where accountability is divided between them and the end user. 

Kieran Norton, a principal in the cyber risk services practice at Deloitte, says financial firms don’t always understand this shared responsibility model. If you think about the responsibility as a layered structure, with the highest level being governance and the running of compliance programs, then the cloud provider is only responsible at the bottom end, depending on whether it be software- or infrastructure-as-a-service.

“They are responsible for physical security, maybe infrastructure security,” Norton says. “But then as you move up in the platform and application, the enterprise is increasingly responsible. A lot of risk comes when you don’t understand that shared responsibility model and you see things as being covered by a provider that are not.”

This relationship is often explained like this: The providers are responsible for security of the cloud, while the customer is responsible for security in the cloud. For customers, that means they must take ownership of the configuration and management of security controls for their operating system and applications, and of encryption of data in transit and at rest.    

Cloud providers are also not fully liable for most of the cost of data breaches, according to Byron Collie, technology fellow and second line cybersecurity risk in operational risk at Goldman Sachs, who spoke at the OpRisk North America conference in New York in June.

“Guess what? Cloud vendors have very limited liability when you look at their contracts. The standard is how much you have paid them in the prior 12 months—that’s it. So however much you have paid Amazon, Google, or Azure is how much they will pay out for liability if you have an event that affects you,” said Collie, adding that it is therefore important to make sure your cloud environment is properly insured against cyber attack.

However, cloud insurance is still in its infancy, and payouts are unlikely to cover anything like the full cost of breaches.

To add another wrinkle: Firms whose data is in the cloud also have a responsibility to other firms in that environment, says Deloitte’s Nicholson. “Something that has been overlooked but is starting to come into focus is the shared liability,” he says, referring to not just the liability that cloud provider has to its client firm, but also the liability that the client itself carries. “They might be doing something within the cloud that could impact on the broader cloud environment and be subject to liability from the cloud provider or other third and fourth parties that are using it,” Nicholson adds.

Misconfiguration Threat

Threat actors in the cloud could be “advanced persistent threats”—also known as nation-states; they could be hackers looking to steal money or data; they are often opportunists looking for any weak spot they can exploit. But most often, cloud security issues are caused by the users themselves: an unpatched server or unsecured Simple Storage Service (S3) bucket. 

Teresa Walsh, global head of intelligence at the Financial Service Information Sharing and Analysis Center (FS-Isac), told The Wall Street Journal’s Cyber Executive Forum, held in London in June, that while most people imagine hackers bombarding cloud environments with attacks, “if you look at a lot of the issues that people have had over the past few years, it’s usually down to human error, through bad configurations, or a lack of understanding about what they are dealing with.”

The beauty of cloud technology is its agility: System administrators can spin up instances of an application to the cloud easily. But these have to be configured, often with code written by the admins. And what if that code is buggy? “It is not typically part of the assessment of a cloud environment to go and look at code that creates these instances,” Bayuk says.

Cloud providers have robust security features, but if they update these, the admin has to go in and change the scripts they used to create the instances. 

A common issue for system administrators was that AWS’s S3 buckets used to be open to the public by default, while many users assumed that they were private by default. “You don’t know when using these technologies what the default parameters are unless you test them or if you actively try to find out. And if you found out once and put security on it, but then this feature was extended to do something else, you may need to revisit that entire configuration,” says Bayuk.

A cottage industry sprang up among hackers looking for open buckets to exploit, and some high-profile companies, including Verizon and Dow Jones, had sensitive data exposed. AWS has since introduced security features such as Block Public Access to help users address the issue, and experts say these will be effective if implemented properly. 

However, when providers add upgrades or new security features like these, it takes time to figure out how to implement them. Each change is accompanied by “tons of documentation,” says Bayuk, and it can be difficult to complete the upgrade before vendors stop supporting the prior version.

“To take advantage of some of the features of these cloud services, you have to do a lot of work understanding how they have created a security feature that then you need to use. I am a programmer and a systems engineer, and it takes me hours of going through documentation to figure this out. Unless you have an Amazon engineer sitting next to you—which we cannot afford—explaining how it works and best practice in using the service, it becomes extremely difficult to figure it out quickly,” she says.

At a couple of hundred pages, the Amazon S3 bucket guide is “not exactly Ikea instructions,” quipped FS-Isac’s Walsh at the WSJ event in London. “You need to know what you are doing and how much you can actually do, in terms of configuring and monitoring for issues. That’s where contract issues come into play: Have you set yourself up for failure, or do you have a partnership with your cloud provider to make it as secure as possible?” 

Keeping Up with the Regulations

There is a bewildering amount of standards, rules and regulations out there, with large areas of overlap and no harmonization. Their application to firms will of course vary, depending on the complexity of the firm and what they are using cloud for, where in the world data is stored, and what third parties and customers the firm deals with. Parsing and reconciling the rules and standards at state and national level and in territories abroad keeps compliance departments very busy. 

These rules aren’t going away. The EU’s General Data Protection Regulation (GDPR) and California’s Consumer Privacy Act have broken new ground for the protection of personal data, with other states and countries around the world poised to pass their own legislation. The New York State Department of Financial Services has passed cybersecurity requirements. There are the Federal Financial Institutions Examinations Council (FFIEC) standards and the National Institute of Standards and Technology (NIST) cybersecurity framework. Firms must take these all into account.

Goldman Sachs, for example, “must ensure it conducts assessments against the FFIEC cybersecurity assessment tool, the NIST framework, and the industry-developed hybrid financial-sector cyber protocol,” said Collie at the OpRisk conference. 

Then there are the operational risk standards—BCBS 195 and Basel III—plus cyber risk rules and regulations as well, he said. “What we do is we have a broader operational risk management program construct, with educational and business policies and standards; risk control frameworks; assessment frameworks; and a monitoring, analysis and governance construct,” Collie said. “Most of the regulation and directions really focus on the assessment piece at the moment.”

While this all might be confusing for compliance departments and technologists alike, one thing is clear: regulators are much less tolerant of blaming third parties, as Heartland’s Richard Carr did. The Office of the Comptroller of the Currency (OCC), which has some of the strictest requirements around security management, says in guidance for banks managing third-party relationships that it “expects a bank to practice effective risk management, regardless of whether the bank performs the activity internally or through a third party. A bank’s use of third parties does not diminish the responsibility of its board of directors and senior management to ensure that the activity is performed in a safe and sound manner and in compliance with applicable laws.”

In the UK, the Financial Conduct Authority has told WatersTechnology that the buck stops with firms and that the cloud providers shared responsibility model is fine, but it’s not enough. 

Nausicaa Delfas, executive director at the regulator, recently told WatersTechnology that regulators consider cloud to be another form of outsourcing, and that the regulated firm remains responsible for the security of the data.  

Authorities are also increasingly concerned about the potential systemic risks of cloud—if AWS experiences an outage, what would happen if many too-big-to-fail banks are using them for critical functions? The emergence of more cloud providers and solutions has spread the risk around, but smaller vendors may still be relying on the same providers. The Bank of England’s Future of Finance report released on June 20 says that AWS and Microsoft account for nearly half of all revenues from public cloud infrastructure.

Concentration risk should form part of the consideration of vendor relationships, said Lee Rubin, counsel at global law firm Pillsbury Winthrop Shaw Pittman.

“So while we are expanding our outsourcing strategy, ultimately the concentration risk below that might still be there. This is particularly important for financial services firms, which are highly regulated and need to ensure that if a provider goes down, the bank isn’t going to fall over,” said Rubin, who spoke on the same panel as Walsh at the London conference.

“Banks have to know their full subcontractor chain and do risk assessments on that, rather than just relying on their prime contractors to satisfy regulatory obligations,” said Rubin. 

Starting with Standards

This landscape of complex vendor relationships and overlapping rules can be overwhelming, but experts say firms can start by looking at what standards are there to provide guidance. 

Rubin said that while risk assessments and understanding the supply chain are important, standardization inspires confidence in customers that a partner understands the firm’s environment and has taken steps to mitigate risk. 

“An example of this that we have seen is ISO 20718,” Rubin says. “This is two or three years old now, but at the time it was looked on as an industry standard for how vendors can handle and process data—a very hot topic with GDPR and everything. But more importantly, it can give a foothold for regulated industries to get comfortable with how information in the cloud is secured.”

Standards can be built into contracts to ensure the vendor obtains the compliance standard on day one, and to act as benchmarks when it comes time to renew the contract, he added.

However, an overreliance on standards provides a false sense of security, warns Bayuk. They are certainly useful as a starting point, but should be considered as guidelines, not as a definitive list of boxes to check for compliance.

“Regulators and standards bodies try to list controls that will minimize risk to an acceptable level in a generic way that could apply to everyone. But because everyone’s assets that they are managing with their computers are completely different, and the mechanism they use to allow their authorized users to access those assets are completely different, one single generic checklist is never going to cover your very specific application that you built internally or are managing in the cloud.” 

Financial firms will take their own approaches to how they structure their third-party risk management process according to their size, activities and risk profile. The OCC notes in its guidance, for instance, that some banks disperse accountability along business lines, while others centralize management under departments like compliance or security. 

But, the guidance says, however a bank structures this process, the board is responsible. Regulators will be placing more emphasis on operational resilience—assuming that a business will get hacked and must mitigate this impact with a focus on its systems—and placing more responsibility with senior management. Managing cloud resilience is complex: A firm must understand the cloud vendor, its third parties—and any third parties used by its third-party partners, otherwise known as fourth-party partners—the criticality of its applications and all the regulatory requirements.

Ultimately, to do it effectively, a firm needs governance, assessment and monitoring wrapped up in a clear strategy. And that strategy can no longer be passing the buck. 

Only users who have a paid subscription or are part of a corporate subscription are able to print or copy content.

To access these options, along with all other subscription benefits, please contact info@waterstechnology.com or view our subscription options here: http://subscriptions.waterstechnology.com/subscribe

You are currently unable to copy this content. Please contact info@waterstechnology.com to find out more.

Most read articles loading...

You need to sign in to use this feature. If you don’t have a WatersTechnology account, please register for a trial.

Sign in
You are currently on corporate access.

To use this feature you will need an individual account. If you have one already please sign in.

Sign in.

Alternatively you can request an individual account here