Creating A Cloud-Based Culture Of Security In Modern Enterprises

The key to a more secure enterprise is fostering a security-first culture.

Enterprises are increasingly moving online as part of the process of digital transformation. Migrating to the cloud makes it easier to deploy and manage new capabilities to meet business needs, largely by moving away from a centralized IT provisioning process. But just because IT can be distributed, doesn’t mean security should be. Every enterprise needs a centralized way to enforce security policies and monitor for threats. As the threat surface increases with the increasing volume and complexity of computer systems, software development tools, application programming interfaces, and services, the cloud presents an opportunity to exercise better control and more consistent policy enforcement.

The amount and the kind of technology isn’t the real problem. It’s visibility. Almost every C-level technology and security leader I speak with worries less about the systems their teams are maintaining than about all the potentially vulnerable systems they don’t see. They’re aware that these unseen software interactions are multiplying daily and that potential attacks against them are increasing just as fast.

Related: Get the highlights from our whitepaper, “CISO’s guide to Cloud Security Transformation.”

Security challenges in today’s technology landscape

Traditional security teams are usually centralized and have orders to keep the company secure and appropriately manage risk. They work based on policies and procedures, security operations, security training, and security auditing. Their job is to establish the “right” way to do things from a security perspective, then monitor and enforce that the company’s software developers are following the rules.

In today’s technology landscape, that approach has a low probability of success. Most software developers have other responsibilities away from security that seem a lot more urgent. They build applications and add business value at a rate that determines the company’s success or failure in this digital transformation.

Almost inevitably, the range and reach of software in a digital organization means there will be projects that do not meet the centrally-determined security standards. Perhaps a product isn’t in compliance because the monitoring solution is fundamentally incompatible with the product. Or security wants added processes that may slow product creation and effectiveness. When there’s a problem, standard practices dictate escalation, which usually halts development.

In every such case, the rest of the organization starts to see security as a roadblock so they seek to minimize their dealings with the security organization. Inevitably, that means security has to build systems to discover and secure rogue efforts, effectively working to secure your company against your own teams.

Leadership contributes to the problem when it insists that developers change to suit the security-improving processes. That seems reasonable, but means security should be forced onto people. I’ve seen that fail time and again: Teams get exceptions to security policy because their feature is critical, teams avoid security review by classifying a launch as a bug fix and not a new feature. Teams go out and build their own infrastructure to avoid visibility, or they conveniently forget to tell security about certain parts of their application.

So how do you get engineers whose main job is to add value for your company to spend the necessary time and resources to build security into their systems? The answer is to change not just technology nor practices, but security culture itself.

Read this next: Understand our key principles for Cloud Security and how they can be applied and implemented by reading our security foundations guide.

Strong security teams align with Software Development goals to provide solutions

The security team needs to see itself not as an organization that enforces compliance with security standards, but as an organization that helps teams build secure products. Development teams want their applications to be secure, and they alone know their applications well enough to make them secure. Ideally, security assists that goal as part of rapid development, so teams seek out and want to work with the security department.

For example, security often establishes a standard that says all passwords for any system should be stored as a salted hash, not the password itself. Each team that handles passwords must then build or use something that meets this standard. A better approach from the security team would be to provide a library or central tool for password management. That may not sound like much, but it’s a “partner” approach that saves time and fits well into an automated development process.

Moving up in complexity, take a centralized Security instruction, like “Each deployed system must run our chosen endpoint security product, called WonkaSec.” That will be easy for many teams, but if WonkaSec is incompatible with the rest of the components that a team uses—and somewhere, it will be—it’s a nightmare order from people who don’t understand what they do. 

A security team with an outdated culture will then compound the problem by telling the application team to change their architecture so it’s compatible with WonkaSec. A good security team, aligned with Software Development goals, will work with the team to find a solution like making WonkaSec compatible with their architecture through a compatibility layer or some other modification. Or it will look for a solution other than WonkaSec that’s effective and doesn’t cripple the Development team.

Related: Watch our 2021 Security Talks 2021 on-demand to get the latest insights on our security ecosystem and how you can better protect your data using cloud computing.

Security culture starts with developer buy-in 

A good security culture keeps the discussion centered on maintaining adequate security while minimizing the overall extra work by others. Inferior security culture says, “You need to do it because we said so,” forcing the other group into lots of extra work.

The key is to adapt this into the overall company culture, since no one size ever fits all, and seek a blame-free collaborative environment for improving security. The easier security is built into solutions, the more secure they will be. That comes from developer buy-in, not organizational policing.

Solve your most critical security challenges. Register for our first digital Security Summit to get fresh insights from industry leaders and help you stay ahead of the next generation of threats.