Four lessons on post-cloud migration from an application security perspective

1. If you haven’t focused on security yet, do it now.

Security is rarely in the line of sight, but often ends up in the crosshairs. People on the business side who need to get things done “quickly and efficiently” rarely add “safely and securely, too.”

Security is often viewed as, at best, a necessary evil and, at worst, an impediment to efficiency to be overcome.

However, making things too easy is an open invitation for fraud, tampering or loss. Search anywhere on the internet and you will find alarming examples of unscrupulous employees who took advantage of subpar controls to embezzle millions of dollars over many years. Even more common are stories of how a lack of security policies led to inadvertent exposure of customers’ sensitive data.

None of this is new. But what is new is how a transition to the cloud will dial up the importance of protecting company data – in a big way.

2. Don’t open the door to fraud.

With the cloud, significant software updates don’t come every 3 to 5 years, but every quarter– and sometimes even faster. This happens whether the business wants them or is ready for them. And not being ready can create real risk. In other words, unless you’re mitigating risk, you’re accepting it.

For example, one cloud software provider made a “small” change that repurposed two fields used to define an employee’s status. For most customers, the change was inconsequential. However, a few had HR and identity and access management systems with discordant assumptions about those fields. Suddenly some employees (and some former ones, too) had new powers and privileges that no one had accounted for. Another provider added a new feature that enabled people to cut and paste values in a spreadsheet-like UI – including million-dollar one-time payments to unfamiliar vendors.

Staying abreast of potential changes from cloud software vendors may sound like a Sisyphean task. The effort requires real commitment to a permanent application security program and to the organizational change required to make it effective, which can be surprisingly difficult. The alternative, however, is akin to opening the barn door and hoping for the best with the horse.

3. Don’t ignore the forest for the trees.

Consider that a single business process can easily span multiple systems, e.g., both legacy “on-prem” software and cloud-based solutions. While cloud software providers do a remarkably good job at security, many of those protections end at your front door. Providers can’t see into your processes, or the integrations with your other systems. Managing risk between systems and across the entire enterprise is completely out of their control.

It is a risk to focus so exclusively on applications that you forget the impacts on your complete business process. Before you accept or enable any new or changing features in a software update, you must ask and answer a host of questions to cover that broader context:

What impact could new features have on every existing business process? What effect will they have on the business more broadly? How will they come to bear on internal organizations, and will they affect different ones differently? Do they create any new risks or exacerbate existing ones? Do we need to change how we define roles? Do they have implications for KPIs or financial statements? Could they create a compliance or legal issue? The list of questions can be long.

There is no one right set of questions, no one set of “best practices” to implement either, because every organization is different. It is necessary to invent them, and then re-invent them, on a regular basis.

4. Do what it takes to find common ground.

We find that many organizations have yet to adopt this process-centric, cross-application view and approach to security. Even when business leaders recognize the need, it’s more common than not to severely underestimate the effort and commitment required, including the magnitude of the organizational and cultural change involved.

No single internal function can possibly answer all these questions. You can’t just leave it to the CISO’s team – they don’t have the breadth and depth of perspective and experience to examine each change in all the necessary contexts.

And it’s critical to do more than play defense. If someone in your organization isn’t looking at new features for opportunities they could create, you’re leaving money on the table. Remember, your competitors get these same updates too.

In the age of cloud migration, your organization requires a dedicated, cross-functional team, designed and optimized for cooperation. But this can be more difficult than it sounds…and it already sounds pretty difficult.

One thing we often encounter is a communications gap between stakeholders when it comes to even basic issues. For example, a manager on the business side might ask IT for permission to have someone on their team approve journal entries in their new cloud-based system. IT will likely ask what role the business wants to assign that person. The manager might not understand what is meant by “role” and counter with the assertion that they just need someone to make journal entries.

Clearly, the lack of a common vocabulary can lead to a major disconnect between the business and IT. Appropriately, each comes from a different domain with a different perspective and a different set of skills. However, it’s easy to see how miscommunications like this can occur, and even how potentially serious consequences can arise as a result. This highlights the need for strong governance over a dedicated, cross-functional application security team.

I know there’s a lot here, but frankly I’m just scratching the surface. If you’d like to hear more, shoot me a message. My team has conversations every day with companies facing these challenges.