No fighting in the war room

Information security isn’t an island unto itself. Running and overseeing an effective security program is a mammoth task that requires a deep understanding of the business and collaboration with colleagues through the organization. Yet, security teams continue to operate in a bit of a bubble. This is not a knock on the industry; people tend to focus on what they know and what they’re tasked with at work. That said, given the state of today’s cybersecurity requirements, running an insular program can (ironically enough) have detrimental effects.

Security practitioners take pride in their work. Often, this pride of ownership results in blocking out advice and/or considerations from non-security staff. However, IT, operations, and application development teams could become a security practitioner’s best ally, if we were to let them. Who knows the network architecture better than the ops team? Is anyone more equipped to explain how a new application behaves than the person who built it? These different perspectives about your technology environment, whether on-premises or in the cloud, help prevent downstream effects when change management is involved, again, if we invite them.

Challenges with Cloud Change Management

Cloud and application environments are dynamic by nature. They are built to accommodate the ever-changing needs of the business as it grows. Precisely because of this flexible nature, protecting the cloud and applications has proven to be a challenge for security teams. Operations and application/development/engineering teams may have a different perspective from the security team, based on the fact that their initiatives and incentives are differently prioritized. The friction is compounded when security feels it is repeatedly excluded from decisions about what hardware, software, and applications are deployed. To rectify insecure implementations after the fact, security may feel it has to elbow its way into forcing changes that keep systems more secure, but which may break/inhibit/alter systems. This (broken) process creates a great deal of tension between teams, slows forward progress, and can hinder future collaboration.

Whether security teams like it or not, all business units that have a stake in managing the cloud and applications need to be considered and represented in the conversation about the best way to protect those clouds and applications. Putting this into perspective, when the proverbial shoe is on the other foot with shadow IT, for instance, the organization’s cybersecurity posture can be severely impacted if the security team has not been included in discussions and/or the implementation.

Shifting Focus

When it comes to the cloud, change is constant, and though security is an important factor, so too are speed, agility, ease of use, uptime, and availability. Any changes made by any one area can impact another, which is why cross-team collaboration is of utmost importance.

The most effective technology programs, processes, and changes happen by consulting not only the teams with direct responsibility, but every team whose workflows will be affected–including operations, IT, development, or security. And cloud-focused changes in particular come with a set of interdependencies. Each change could trigger ensuing changes in the environment, but to anticipate or decide how to deal with these changes, you must first involve stakeholders from affected teams in the planning process.

Change management, like an incident response plan, should be a collaborative program, meaning its ongoing and adapts to current business needs. While a CISO or CTO could deliver an edict on how change management in the cloud will occur, it’s better to form a committee that meets regularly. The committee should be composed of stakeholders who interact with systems on a daily basis and have different perspectives on what “good” or “acceptable” is.

A security practitioner’s definition of “good” or “acceptable” means protecting back-end or local applications running in the cloud by restricting network access to only those that can be deemed 100% trustworthy. Operations teams, however, are primarily interested in making sure the network is running smoothly, is accessible, and carries a low cost of ownership, resulting in fewer restrictions and a lower administrative burden. Application and DevOps teams want a system that is flexible and agile; anything that impedes progress or velocity is unwelcome.

Prioritizing Tasks and Teams

Whose needs and priorities are the most important? All of them–that’s why a collaborative committee to manage change is required. Though security staff are the experts on security controls, application owners are the experts on how applications were built, how they were deployed, how they communicate, etc. It only makes sense to include application owners in discussions about how to best protect them.  

The same can be said of IT/operations. Though tensions between IT and security are storied, security can benefit a great deal by working closely with IT teams to glean knowledge about network (virtual or physical) layout, operating systems and patch levels, and the tools in place for monitoring health. Conversations should be a two-way street to account for both a manageable system and a secure one.

Too often business units focus only on their own tasks and priorities. If a critical patch is issued, for instance, the security team might want to update immediately to avoid additional potential exposure. However, deploying the patch without proper testing (which requires a delay itself) could result in some other part of the system malfunctioning. Finding the right balance of security and productivity is key. To get there, different teams must speak with one another on a regular basis, sharing ideas and expressing concerns. It’s likely that you already know the players: they’re the people you run up against when the security team unilaterally decides to lock down access to a system, when you start receiving an abundance of alerts from an application that was deployed in the cloud (without security’s knowledge), or when data from a new tool begins mysteriously showing up in your event logs.

Creating a Collaborative Environment

Recruit colleagues to a collaborative committee that can work together to build an improved change management process. It’s important to form this committee and start discussions outside of any current problems–you want to start out on an even plane. Explain that the goal is to incorporate the needs and interests of people affected by changes to the cloud environment, and that you have a willingness to hear their thoughts and concerns. Some of this work is as much psychological as it is practical; the less time teams spend butting heads, the more time everyone has for productive work. And you’re more likely to reach amicable solutions to change management problems if you start with a discussion rather than an argument.

Because you might encounter hesitation when introducing the idea of yet another meeting or job responsibility, lead with the positive benefits of a collaborative process: reduced friction, greater transparency, and the ability to anticipate downstream effects. Schedule discussions regularly but not too frequently: once a month or once per quarter. And last but not least, ensure that discussions are just that: discussions, not decrees or contentious arguments among disparate teams. Remember that there are many sides to any technology issue and one team’s needs don’t trump another’s.

Sean Lutner, Infrastructure Architect

Written by Sean Lutner, Infrastructure Architect

Sean is the Infrastructure Architect at Edgewise, responsible for all the things that make the Edgewise platform performant, scalable, and secure behind the scenes. With nearly two decades of experience in positions contributing to and leading infrastructure and security teams at a diverse range of companies spanning many industries, he brings the viewpoint of the customer with him to the Edgewise product.