In collaboration with our partner 
“The top risk for cloud migration is not even technological. The biggest risk is that you’re opening yourself up to a risk landscape that is completely new to people at all levels in your organization, including top management. That’s the biggest risk because if you’re trying to solve a new problem with an old toolset then it won’t work.
“You don’t go to the cloud just because you want to change your cost structure. Banks and financial services companies don’t move to a cloud model just because they want to move away from data centers. They do it because they are changing the way they interact with their clients or customers. That’s one of the key reasons companies move to the cloud.
“If we look at the BFS sector today, banks are moving from being in a branch and opening branches everywhere to having to do everything on an app. To do that, banks need to expose more and more services online that used to be completely offline.
“You can take out a mortgage now online, right? It used to be a completely offline process. You had your banking systems and you had to walk into the branch to do that. So, the more you want to move online, the more you want to change your business model, the more you need to expose and the more scalability you need.
“Companies move to the cloud because they understand they’ll need this scalability. But the key risk, first of all, is around the people and the processes. The people, as in, do we have the right skill set in the company to handle the different risk landscape, the changed risk landscape? And do we have the processes for the people to follow?”
“This first type of risk is about mindset. So, organizations should understand what they’re dealing with then accept it and put in place the right structures to deal with it.
“Technologies are a dime a dozen. There are hundreds of cloud security technologies. And they are all competing on doing stuff a little bit better and handling an ever-narrowing aspect of cloud security.
“So, we can always get better with tools. It’s like tweaking a car, right? You can always get better at it. But in the 80/20 rule, that’s the 20%. The 80%, the lion’s share, is the mindset, is having the right skill set, is having the right processes.
“The right process for us, for example, can be shifting security to the left because when you move to the cloud, then you’re doing things much more quickly. And when you are doing things more quickly, you can’t hold on to the old way we’ve done security, which is security at the end of the development process.
“You can no longer do that and still remain secure because you’re building servers on the go. You are deploying code on the go. Companies sometimes deploy seven or eight new versions a day. So, you must incorporate security as an integral part of these processes rather than following the waterfall model as used to happen.
“When we look at banking and finance, we understand that these organizations have very traditional procedures and skillsets, and they need to change these things. And, of course, their technology needs to change as well. But the key point is people, processes, technology – 80% is people and processes, 20% technologies.”
“The second risk is an inherent risk, or a risk associated with the most important role of security. And for us at Qualitest, the key role of security is to enable innovation.
“What do I mean by this? The adoption of new technologies, if we look at it more broadly, will be weak and slow unless security plays a strong part. People will be wary to use their banks online or do their insurance online unless all these companies build in security from the get-go as a functionality of their solution. And that’s the role of security now.
“Inherently, when companies move to the cloud, they move to the cloud to be quicker and to innovate faster. But if the security function still thinks it has the power to say yes or no to the organization wanting to develop something new, that’s a problem.
“The role of security used to be like a police force, let’s be honest. Even as recently as 7 years ago, banks were asking, oh, can we ever move to the cloud and move all these sensitive data into the cloud? And security said, no, unilaterally, no! But that didn’t hold water because banks’ business models didn’t justify keeping it the old way.
“So, the problem here is that a bank or financial services provider can have a security operation that is still with the old mindset of yes or no. However, the organization itself by moving to the cloud wants to make more rapid decisions and rapid innovation.
“And then two things can happen: one, the organization will innovate with disregard for security. And that’s a risk. And the second, which is a larger risk, is that security will stifle innovation.”
“Security should not fool itself into thinking it can say yes, you can do that, or no, you can’t do that. It’s not for us to decide whether a bank or financial services company can or can’t allow this functionality or this new service. That’s a very old-fashioned concept of security.
“Instead, the business decides what it’s doing. Security should only be saying, OK, this is the service you want to run. Cool. Let’s see how we can do that in a secure manner.
“The new concept of security is to enable and support rapid innovation with the right structure and the right tools. We don’t say, yes, you can do it or no, you can’t.”
“When you move to the cloud, suddenly you have all these new technologies and all these new security technologies in place. And the problem is that too much reliance on technology can lead to vulnerability fatigue so that you can’t see the forest for the trees and identify what’s next.
“Banks and financial services firms today each have around 10 to 15 scanning technologies whose purpose is to find vulnerabilities. And these tools come up with hundreds or thousands of vulnerabilities. But financial organizations don’t know what to do with these vulnerabilities anymore. Why? Because there are three problems.
“One, usually whoever owns the process of finding vulnerabilities does not own the process of mitigating them. This can create misalignment or a security-development disconnect. As an example, if we are scanning the code repository, the security function in the organization will own the scanning, they will own the issue. But they won’t own the solution.
“The second issue is around poor normalization. Each security tool is an island and has its own risk metrics. So, when a bank or financial services organization gets a set of results – and again, these are hundreds or thousands of results – they’re not normalized. So, there is no way for the organization to compare apple with apple and know its real risk level and prioritize the mitigation process.
“The third issue is a lack of aggregation and correlation. Sometimes several vulnerabilities can be solved by a single fix. But right now, security needs to contact each developer team about each vulnerability one by one and tell them what they need to do.
“These three problems can create a bigger problem, whereby organizations end up with too many vulnerabilities owned by the wrong people. So, introducing fixes becomes a cumbersome process and cyber security becomes a huge bottleneck. The bottom line is it creates what I call, fatigue: OK, so you find a lot of problems, but you can’t deal with them as an organization.
“And this is a large risk, as security again gets disregarded, organizations get into a sort of rut and so we lose the edge.”
“We propose a new solution to this problem, one that I’m working on right now, which takes an orchestrated approach to vulnerability management. This is based on a centralized intelligent engine or “brain” that collates all the inputs from these different scanning tools and normalizes the results.
“This brain also automates many security processes that organizations currently perform manually and struggle with. So, imagine no longer having to worry about whether the right problems are with the right people. Or not having to fret about how to prioritize risk levels according to internal policies. Instead, it’s all done automatically.
“Crucially, the central engine or brain will also keep monitoring the mitigation process. So, you will know if a particular developer has fixed their issue or not. Plus, you’ll know that without having to scan the code again. So, you’ll know continuously the risk level of each part of your organization.
“So, this orchestrator will solve the problem of finding a simpler way to understand the bigger picture, as it holds more information and builds more logic into each vulnerability. But by itself, it will not solve the problem of over-reliance on technology.
“Again, this all comes back to the same three-pronged approach of people, processes and technologies. So, the right process can be having a service-level agreement between the developer teams and the security function that says, for example, that the dev team will mitigate any critical vulnerabilities within 10 hours.”
According to Uri, banks and financial services organizations moving to the cloud should keep these three questions top of mind:
And not just for regulatory and reputational reasons. Today’s banking and financial services customers and clients also have the choice to go elsewhere if they don’t like what’s on offer.
So, however you manage risk, your security and cyber security testing need to act as business enablers. They should open doors to fast and accurate online services and experiences that your clients and customers trust.
We can help you embrace this business transformation and manage the risks of cloud migration. Our engineers will provide the resources, expertise and processes you need to develop a robust and secure strategy.
Qualitest partners with Sauce Labs to leverage the test automation you need to achieve continuous testing that integrates into your CI/CD pipeline. Get in touch to find out more about how you can improve your current test automation efforts to achieve speed and scale in the cloud.
