topreads

Every time a game-changing technology comes around, organizations are forced to scramble.

As business leaders, you can’t just order your CIO or CISO go on a college recruiting binge for cloud computing specialists. While some universities and technical institutes are actually offering formal concentrations in cloud computing, there are two challenges associated with this approach: First, there aren’t enough cloud-savvy college students yet, at least not when it comes to adapting those skills to a real-world setting. And second, hiring well-educated cloud technologists really isn’t what organizations need.

We already have many people working in our IT shops and security operations centers with transferrable skills that will let them help their organizations develop, deploy, and manage applications and workloads in the cloud. In a cloud-centric environment, solutions are less about infrastructure and more about working with the DevOps team to spin up a virtual private cloud to support faster and more frequent software releases.

This is causing a re-imagining of the roles and skill sets of IT and security teams in a cloud-first world. For instance, the move to the cloud means that IT hardware has typically been separated—or, “abstracted” as your technical teams will tell you—from the overall computing process. As a result, the shifting nature of skill sets means that you need fewer of the traditional technical skills than was the case in the pre-cloud days. For instance, network administrators need to understand how to automate cloud networking, while storage administrators must upskill to run such tools as S3 and Glacier instead of an in-house storage-area network fabric. Above all, you need smart, adaptable, and inquisitive people who understand cryptography and identity/access management in order to secure data in the cloud.

As your company’s risk profile changes, your cloud architect can help you decide what components of your IT system to move into the cloud.

Appetite for Risk

As with any decision, there’s always a risk. But what’s considered acceptable risk? According to Duca, that’s up to you. To benefit from the quick scaling that a cloud provider can offer, you don’t have to put a critical software ap- plication out there right away, nor sensitive customer data. At the same time, you should first consider the risks you’re already facing by hosting your apps and data in-house.

“If your systems are all on premises, you’re probably protecting your data the same way you did ten years ago,” said Duca. “That kind of security won’t suffice for the next ten—and, possibly, not even for the next two—years.”

So, exploiting new options doesn’t necessarily mean accepting more risk than you can handle. As your company’s risk profile changes, your cloud architect can help you decide what components of your IT system to move into the cloud, precisely because cloud providers can protect some of it better than you can.

While recent news stories about high-profile data breaches might be enough reason to bring on a skilled CA, there are many upside drivers, too. For instance, traditional IT leadership might not even be aware of the ins and outs of how the cloud can benefit your business.

“My approach would be to find a ‘born- in-the-cloud’ expert,” said Duca. “Find some- one who’s got competency to work in one of the cloud platforms—Google Cloud Platform, Amazon Web Services (AWS®), Microsoft Azure®, etc. The more competency they’ve actually got in those different clouds, the saf- er it’s probably going to be for you and the organization.”

So, What Is a Cloud Architect?

Claus emphasized both the immediate benefits and the long-horizon value of taking advantage of the cloud. And that means changing your IT department.

“A cloud architect brings the perspective of modernization and efficiencies that come from leveraging cloud technologies into ex- isting and new projects,” said Claus. “A clear line of sight on the benefits and returns for adopting cloud technologies needs to be front and center during the evolution of an IT department.”

A cloud initiative includes reducing the footprint of on-premises data centers. A savvy CA will recommend which IT workloads to move to scalable cloud providers and show IT staff how their own tasks and workloads can evolve to manage these new technologies. The strategic objective should be to free up resources to re-invest for tackling even more complex projects that are truly mission-critical to the business.

Strategic Security Planning

If you’re still contemplating a move to the cloud, your business faces security risks even while everything is primarily in-house, simply because the nature and behavior of your users, data, and applications will change. A cloud architect brings a new strategic perspective to your top-level security planning.

“Threat management was once about blocking and keeping bad things out,” said Duca. It was simplistic. “I had antivirus, then I had a firewall. That was a very static world. I had one device and an IP address and that was it.”

I’ll admit, the notion of kinship—or a commonality of purpose—is not new, at least not in theory. Business schools and academic journals have talked about this theme as a prerequisite for leadership success for many years. Unfortunately, it has not always played out as drawn up on the whiteboard.

In my current role, I see our CISO at Palo Alto Networks as more than a business colleague. We are united in our over-reaching goals, but also in our shared understanding of fighting a common adversary. In our changing roles from worrying first about technology issues to solving our company’s most strategic business problems, we have a mirrored interest in solving critical, real-world crises. We may be coming at problem-solving with slightly different orientations—the CIO focused on how technology can positively disrupt business models, and the CISO centered on how security can enhance our customers’ trust in our brand—but we each know that we have to end up at the same place, even if it means we have to be flexible in how we get there.

We also are involved in another important organizational change: The increasing demand that we work in a far more decentralized structure where we are co-creating with business units and developers (DevOps), and where security is embedded from the start in all digital transformation processes (DevSecOps). It’s an exciting time to be doing all this, as technology disrupts every industry by using automated tools, machine learning, and other emerging technologies to change how we work and how our customers use technology.

OK, kinship is a great concept and a powerful fulcrum for positive change. But in many organizations, that may be the easy part. By contrast, encouraging and understanding how to benefit from dynamic tension can either build on the benefits of kinship…or render it a worthless slogan.

This give-and-take between smart, motivated, innovative, and—yes—ego-driven executives should be cultivated and used as a force-multiplier. At the heart of dynamic tension is the mutual acknowledgement that, at times, our agendas will differ and we need to communicate closely and honestly to be able to resolve differences and achieve optimal business outcomes.

Increasingly, CIOs are being measured by their ability to engender speed and agility in the organization and CISOs on their ability to prevent successful cybersecurity attacks. As any business executive can attest, sometimes those goals appear to be at cross purposes. While these agendas can lead to confusion about priorities and may become the source of conflict, it’s up to the CIO and CISO (without the CEO mandating it) to resolve any alignment issues. The key here is keeping the “eye on the prize,” which is an opportunity, agile organization that promotes cybersecurity for the good of all parties.

Done well, this dynamic tension can be a powerful catalyst for process improvement. However, if we don’t manage the dynamic tension properly, it can be corrosive to organization success.

For example, take the notion of who the CISO should report to. There’s a lot of debate on this topic, especially around the question of whether the CISO should roll up to the CIO and his/her team. A very good article recently published in SecurityRoundtable.org addressed this idea with a simple principle: Check your ego at the door.

For example, take the notion of who the CISO should report to. There’s a lot of debate on this topic, especially around the question of whether the CISO should roll up to the CIO and his/her team. A very good article recently published in SecurityRoundtable.org addressed this idea with a simple principle: Check your ego at the door.

Regardless of who they report to, I strongly believe that CISOs need independence from IT leaders to do their jobs properly—and that extends to budgets. The CISO needs a budget that is separate and apart from the CIO’s budget. As a CIO, I value independence for the security team, because I’ve seen first-hand how it has helped us improve our security outcomes. The independence does come at a cost though, since it requires both leaders to collaborate at much higher levels and have a common set of objectives around security. Often, I see a misalignment between CIOs and CISOs, and in some cases, disrespect between the two leaders.

At a recent analysts’ conference that I attended, I heard that 67% of business leaders and board members are pushing CIOs, CISOs, and other technical leaders—hard—to evolve their services and approaches faster and more aggressively. Board members have climbed aboard the digital-transformation bandwagon, and they want their organizations to move quicker than their competitors toward that goal.

But other research among CISOs indicates that most cybersecurity executives believe things might be moving too fast for them to properly assess risks and their implications. For security, that means business leaders want to deploy not only applications in the cloud, but also vital IT services, such as security, to avail themselves all of cloud’s benefits. Board members and business leaders have fast become big believers in the notion of “disposable IT,” which imposes a smaller footprint on enterprises, while providing greater agility and, potentially, cost savings. Many CISOs, however, are still in a traditional mindset of purchasing multiyear licenses for security, backed up by a lot of testing, risk analysis, and methodical decision-making.

How should organizations span the chasm between the “go faster” mandate from the board and the “let’s tame the cyber-risk monster” philosophy of the CISO?

The Consumption Model for Security

Cybersecurity consumption models must mirror IT consumption models, with heavy attention to actual usage patterns and how security maps to IT services. For instance, if your IT organization has adopted say, a DevOps process, your IT usage and availability profile could change every week, every day, or perhaps even every few hours. Security consumption must align with those IT-usage trend lines.

It’s helpful to view this process as a threelegged stool. First, there’s an operational need; second, the developers build the solution to meet that need; and, third, security must be bound to those operational and development cycles. Unfortunately, DevOps— so far—doesn’t typically include this security leg. Research indicates that about 80% of organizations are embracing DevOps, but far less have made the transition to DevSecOps.

DevOps cycles move faster and faster each day. Business leaders are demanding real-time adaptation of software to match operational requirements, and security must match that every step of the way. If not, new DevOps scenarios and requirements will have come and gone before the security team can figure out what was needed—yesterday. Hence, there’s a need to shift from DevOps to DevSecOps, where security is natively part of the DevOps process.

If your CISO isn’t able to be an equal part of this DevOps process, then he or she is going to need to prepare a really good explanation to the C-suite executive team and the board. The reality is the business will simply continue without their support.

You Can Never Be Too Agile

Adopting a pay-as-you-go cybersecurity consumption model enables the agility, responsiveness, scalability, and cost efficiency today’s application-development and deployment cycles require. Organizations that hesitate moving this way are likely to find themselves over-investing in security capex and not being able to pivot on a dime when new risks emerge.

Case in point: I recently meet with a CIO who wanted to transform his company’s data center, and he told me it took an inordinately long amount of time re-architect, get approval, and roll it out. So much so that he admitted that, today, the center is already out of date. Getting caught up in monolithic, long-term investments simply doesn’t make sense if you wish to remain competitive in the increasingly digitized markets.

Too often, organizations have a fractured situation.

A primary reason for accumulation of technical debt is the lack of a framework— including a governance structure—to manage open source components. In some cases, Prendergast says, legal, technical and practical issues can collide. “Too often, organizations have a fractured situation. Legal experts make decisions without any knowledge of licensing fees or security, while a security group doesn’t acknowledge legal issues or understand how developers work,” he explains.

DevOps presents particularly vexing challenges, author Behr says. The whole point of a DevOps initiative is to remove red tape and streamline processes. “But the situation can create a Frankenstein of technical debt. If you’re not careful you find yourself adopting an endless array of one-off solutions. Debt piles up as people make quick choices that aren’t part of an integrated and coordinated plan,” Behr explains.

Finding a More Secure Open Source Way

Like enterprise risk, “Technical debt is not something you ever completely eliminate,” says Prendergast. “The goal is to reduce technical debt and, along with it, risk exposure in the cybersecurity space.” This includes open source components used in public clouds. He identifies three primary ways to address the challenge.

• Engage in open discussion. It’s important to ensure that the board and senior executives understand the concept of technical debt and how, particularly in a DevOps environment that relies on open source components, it can play out. “People need to identify risks and responsibilities. They need to understand how and why the organization uses open source as part of its business framework,” Prendergast explains. This includes discussions with partners, open source groups and peers at tech and open source conferences.

• Develop a cohesive strategy and build a framework for managing open source components. A governance framework and clear policies are paramount. This includes criteria for how groups choose open source components, how they use and retire containers, and how security tools fit into the picture. Accenture’s Benameur says it’s important to automate security processes, including static and dynamic analysis. Yet, at the same time, it’s vital to avoid procedures and processes undermining the speed and efficiency of DevOps. Benameur says that DevSecOps is a logical solution. It focuses on a more systematic and organization-wide shift in values, attitudes and methods.
• Determine how best to evaluate and consume technology, including open source components. The way organizations select, adopt and use software has changed radically. Clouds and platform-as-a-service (PaaS)—particularly AWS, Azure and Google Cloud—have transformed the way organizations develop code and software. “You have to understand your technology stack, licensing and governance models, APIs and how open source fits into these systems,” Prendergast explains. Metrics and scorecards are also critical, Behr says. “When an organization understands what works, what doesn’t work and how things work, they are in a position to create greater value.”

Prendergast suggests five core criteria for selecting open source solutions: your ability to operate, manage and support the component; whether you can extend it in the future; its security framework (including how long it takes for a group to patch vulnerabilities); potential licensing or legal issues; and its long-term viability.

Ultimately, says Behr, “It’s important for executives to understand the conditions and trade-offs that lead to technical debt. The end goal is the adoption of open source components that lead to fluidity, reliability, sustainability and value.”

Let’s be clear: I’m no Pollyanna when it comes to the target-rich environment that the cloud has become and what it will be in the future. The potential threat vectors presented by hackers, organized cybercriminal gangs, and bad state actors over the next several years are breathtaking. So, it’s important for all of us to know what we’ll be up against as we necessarily and deliberately rely and depend on the cloud.

With more and more data—and with more of that data deemed mission critical—created, stored, and managed in the cloud, bad actors will naturally take aim. Developments like the Internet of Things are a great example of why: The fact that the IoT represents a multi-trillion-dollar target makes it a gigantic target for the bad guys. This is becoming even more an issue as “smart things” are connected to the cloud without sufficient integrated security or as users fail to adopt proper security hygiene.

The Changing Face of Cloud Security

With such a broad attack surface, in an always-on environment, fraudsters have already exfiltrated data and caused cyber mischief. So it’s up to us to do more. A lot more.

Already, some things are happening. One of the best is the imminent demise of passwords, which are giving way to biometrics and other steps in multi-factor authentication. Still, we cannot underestimate the intelligence, creativity, and determination of hackers, whether they are lone wolves (which they rarely are), part of digital crime syndicates, or state-sponsored bad actors.

They are coming after us in the cloud, and they will amp up their efforts in the cloud of the future. There’s good news, however: We’re all ramping up and fortifying our cloud security frameworks in anticipation of more penetration attempts.

Already, cloud environments are being fortified with machine language engines to analyze global data points in the hundreds of billions of cloud-based transactions. AI and machine learning normalize the and push out attack indicators that are more meaningful, timely, and accurate. This will make our detection efforts far better—an order of magnitude better, in fact.

I’ll give you an example from my own experience. I’ve been part of both the DevOps group and the information security group in my organization. Several years ago, we began increasing our use of automation and saw a lot of value in that. At the same time, our executive team was unsure how our organization was going to incorporate the cloud and how to approach it.

We decided to leverage public cloud to see if we could improve our speed and agility in developing applications. The results were well beyond our expectations. Previously, it had taken about 45 days to deploy a mid-size application. When we shifted DevOps to the cloud, we were able to develop a comparable app in one hour. From 45 days to one hour is a remarkable achievement, particularly in today’s world of rapid innovation and highly “consumerized” customer expectations.

With that experience, we decided that we wanted to move forward, which was when we created our DevOps group and continued with automation. The results have been so successful, we’ve made a decision to go all-in with the cloud for our entire organization. Our current philosophy is: If we can move an application to the cloud we are going to do so—as long as we know that we can secure it properly.

Shifting Left Securely

Ensuring that we can secure each application in the cloud has necessitated a shift left for our organization, so that we are defining and configuring security at the beginning of the development process and not at the end. It has also required us to make sure that our teams understand one of the core concepts of cloud security, which is that it is a shared-security model. Our cloud provider is responsible for certain aspects of security, and we are responsible for certain aspects, including our applications.

The benefits are not just in cybersecurity, but also disaster recovery and business continuity.

While public cloud has been a critical catalyst in our ability to shift left with security, we would not have been able to do so as easily or successfully if it were not for technology innovations in the world of security as well. Without getting too technical, one example of a new technology helping us shift left is an open-source solution called Terraform.

Basically, Terraform gives us the ability to modularize the security policy, so it lives with each application and is vetted, approved and defined throughout the application’s lifecycle. When we need to change security policies, it is much easier. And, when the application goes away, the policy is removed from the firewall. This not only helps with security; it also helps with compliance and auditing because you have an audit trail of any policy changes made in the application.

The Benefits of Shifting Left

By embracing public cloud and shifting left with DevOps and security, organizations can see significant benefits in cost savings, quality control, speed to market and even corporate culture. At my organization, we are seeing rapid acceleration in the way we’re able to remediate applications and, at the same, we are significantly increasing our security.

We are reducing risk to the organization at multiple levels. We can deploy infrastructure and applications at a quicker pace, and we can mitigate the risk of ransomware in the cloud because we have more agility in securely redeploying our applications if our servers are locked.

These and countless other regulations and standards have a big impact on how, when, where, and why you move important data, applications, and workloads to the cloud. Sorting this out requires you to do your homework and make smart decisions about your use of the cloud in a highly regulated industry. But let me emphasize that you do not have the option to turn away from the cloud just because regulatory compliance may be tricky.

Take SOX, for instance. Part of that act is a requirement of separation of duties, where developers are not allowed to directly push their code into a production system. But in a world where DevOps is fast becoming standard operating procedure, moving code to a completely different group of people who have not been involved in the process up until that point runs directly counter to what DevOps is all about. You end up with more silos, which adds complexity, inefficiency, and speed bumps.

Rather than just throw up their hands and blame the regulation, business leaders must empower their DevOps teams—working in concert with their InfoSec colleagues from the start—to develop and implement new policies that (A) account for the regulatory requirements, but also (B) operate smoothly in a cloud-first mindset.

Sounds tricky, right? Yes, in fact, it can be. But business leaders must listen to their DevOps, security, and compliance teams, which increasingly are collaborating on ways to support the letter and spirit of the standard without slowing down the DevOpsand-cloud locomotive. This is our “new normal,” and business leaders know that this is being done on an enterprise level at scale.

If FUD—fear, uncertainty, and doubt—is holding back your organization about cloud adoption amid the web of regulations and standards, you are not alone. But since when do organizations succeed by being cautious? Embracing cloud and DevOps in a secure, compliant manner is being done all the time-it is a movement that cannot be slowed, let alone stopped, by regulatory concerns.

So, what should business executives and boards of highly regulated organizations do when it comes to balancing the “need for speed” personified by cloud and DevOps with regulatory governance?

For instance, how data is handled in the cloud is fundamentally different from how it has been done in the data center, and many regulations were written in the pre-cloud timeframe. Fortunately, many standards have been written in ways to allow for a broader, looser, or newer interpretation in a cloud environment rather than in a physical, on-premises environment. Suppose there is a statute that you’ve always interpreted as “you must have virus protection on your servers.” But when you examine the statute more closely, it may actually say something different. For instance, in the HiTrust compliance standard for healthcare, it says, “Detection, prevention, and recovery controls should be implemented to protect against malicious code, and appropriate user awareness procedures on malicious code shall be provided.” That is a big difference, because that allows you to rewrite policies that account for containers, immutable servers, or server-less computing.

Your teams have to do that kind of work--examine the regulations and interpret them in a modernized, real-world context where cloud, not on-site physical data centers, is the standard. This means your compliance and governance teams must work as closely and as collaboratively as possible with your DevOps teams and cloud architects. Even though many in-house compliance teams are hard-wired to block anything that may feel remotely close to a regulatory fault line, business leaders need to strongly encourage them to find ways to help the cloud and DevOps teams get what they need.

At the same time, the unlimited capacity and scalability of the cloud is meaningless unless the data stored, analyzed, managed, and presented by the cloud is relevant and accurate. Take a common industrial process like semiconductor chip baths. Those baths must be kept at a certain temperature, or else production yields will be impacted and bad parts will slip into the manufacturing supply chain. “We don’t just need more data, we need more accurate data,” notes Jamison Utter, business development manager at Palo Alto Networks. “Sensors act as our eyes by giving us visibility into real-time conditions in those baths, and then they act as our hands by actually acting on the data, such as adjusting the temperature in the bath when it goes out of the prescribed operating parameters.

“IoT is great, but it’s not that interesting by itself,” he adds. “We need the cloud to do that; but the cloud also isn’t nearly as important without a reliable stream of real-time data from new sources. That’s what IoT does for the cloud.”

So, what should business leaders do when it comes to getting the most value out of this powerful combination of IoT and the cloud?

Remember that ‘connected things’ is really a full business ecosystem, not a point solution or an individual application,” according to Utter. “Otherwise, your teams will be creating more and more information silos, rather than turbo-charging your organization with powerful insights.”

‘Connected things’ is really a full business ecosystem, not a point solution or an individual application.

Corner-office executives and board members also need to keep in mind that actionable intelligence gleaned from IoT systems can only be properly captured, analyzed, managed, and acted on in the cloud. “The cloud is the best place to review patterns of how and where data is accessed, and to generate the telemetry necessary to find patterns, anomalies, and ‘ah-ha’ moments,” said Prendergast. “And the tie-in to cybersecurity is critical,” he added. “Without the capacity, power, and intelligence in the cloud, it’s far more difficult to see things that shouldn’t be happening with your connected things, like postage meters downloading documents.”

Finally, executives need to ensure that IoT is treated as a cloud-powered and cloud-enabled system that aligns with business objectives. “Don’t separate your business unit personnel who will be using the information generated from IoT from the technical teams building and managing those systems,” said Utter. “The only way to drive true symbiosis between IoT and the cloud is to ensure you treat them as part of your overall business ecosystem, where all your data points, sensors, and inputs, from all around the world, all connected in the cloud. That’s where the true business value of your cloud comes, and where IoT acts as the eyes and hands of the cloud.”

One way to think about the value of containerization is to consider what it was like to share documents before the introduction of Adobe’s Portable Document Format (PDF) solution. Today, we don’t worry about translating or recoding documents written in one environment, like Windows, but that need to be shared and read in many other formats such as an iPad running iOS, or an Android-based smartphone. PDF normalized documents into a single format, and containers are doing the same thing for applications that can be used in any physical or virtual computing environment. This means your developers can revise and update code anywhere, anytime, and on any type of system because they are using the same development environment as when they’re in the office working on their production systems.

And as DevOps becomes both commonplace and essential in helping organizations navigate their way to becoming truly digital businesses, containers become indispensable tools. One of the big attractions to containers centers on our favorite subject: cybersecurity.

Instead of developing and deploying large, monolithic blocks of code, containers enable software to be broken down into smaller chunks that can be checked more frequently and quicker when new threats emerge. Container infrastructure vendors like Docker and others have made cybersecurity a big priority and have integrated stronger security defenses into their tools from the start.

But that doesn’t mean you can take cybersecurity for granted as your organization embraces containers. Containers are not necessarily a new technology, but they are newer to enterprise use; that means attention must continue to be paid when using containers to ensure that the same cyber hygiene and best practices traditionally used in software development are applied to containerized applications.

Containers enable software to be broken down into smaller chunks that can be checked more frequently.

There is the reality, as well, that bad actors will be drawn to containers by the very fact that they are new and a hot topic. “There are going to be zero-day exploits that will be attempted, and the bad guys are likely to be aggressive,” according to Prendergast. “Any new technology has an Achilles heel, so you need to re-evaluate your risk profile.” On the positive side, however, “If you are worried about the potential for a container being compromised, you can simply kill that container and launch a new one in seconds,” he said. “You don’t have to worry about replicating the fix across multiple web servers; it’s easier, faster, more efficient, and safer.”

He also points out that, as containers gain more acceptance and are more widely used for DevOps projects and as a facilitator of digital transformation, the container tools developers will undoubtedly step up their game when it comes to security and will finetune to mitigate known vulnerabilities.

Still, it’s important for business executives to ask some pointed questions when their IT execs talk about container adoption. These include:

• What’s the business advantage you expect to achieve in a containerization strategy?
• Which workloads will be put into the container, and how will you know it’s delivering a measurable business benefit?
• How will you ensure that adding containers will help accelerate our DevOps initiatives, rather than create more friction with the introduction of a new toolset?
• How will containers change our cybersecurity threat vectors, and how are you accounting for that?

In the end, business leaders don’t need to worry about how containers work–only that they are a good fit with their goals of more closely aligning how applications are developed and deployed with the needs of business users who benefit from that software.

Cloud- and web-service providers go to great lengths to absolve themselves of any obligation to protect their clients’ data, from their six-page, four-point type online contracts (that nobody ever reads before hitting Accept) to their security-related FAQs and training tools. Some even incorporate into their dashboards an explicit reminder that users, by default, are exposing their data to the public Internet. Many clients still assume that if a breach were to occur, landing them in some legal hot water, their public-cloud vendor will sit next to them in court. However, cloud providers have done everything in their power to make sure they will never have to do that.

It’s great that cloud providers offer customers a few options for setting up and configuring their cybersecurity. However, it’s a mistake to assume that the choices they provide are sufficient for every company’s needs.

Don’t Trust, Always Verify

The good news is that the zero-trust approach that leading companies have taken to secure their own IT environments can also be used to mitigate cyber risk in their digital-business initiatives. While, at one time, we assumed that everything on the inside of an organization’s network could be trusted, the increasing frequency of successful cyber-attacks built on exploiting that trust disabused us of that notion.

Traditional, perimeter-centric security strategies failed to provide the adequate visibility, control, and protection of user and application traffic. Enter zero-trust architectures, applying the principle of “never trust, always verify” to all entities—users, devices, applications, packets—regardless of what they are and their location, relative to the bounds of the corporate network.

It’s become clear—through the experience of the many companies that have dealt with breaches of their web- and cloud-based data and digital services—that exploitation of trust is as much of a risk in the public cloud as it is in the enterprise data center. Leveraging public-cloud services for digital-business efforts can change who owns and maintains the base architecture, but it does not mitigate or transfer cyber-risk responsibility.

The reality is that the public web and cloud services, are no more innately secure than any other traditional hosting options.

A public cloud service might have a great security model, but it’s not necessarily the right security model for all their customers. They may not be subject to the same regulations, have the same customer demands, or handle the same types of sensitive intellectual property as their clients. That cloud vendors provide basic security and infrastructure patching is a tremendous value. However, their priority is maintaining and monetizing their cloud infrastructure, not becoming a managed-security provider. It’s the customer’s responsibility to protect their data as robustly as if it were sitting in their own headquarters.

Consider Security from the Start

Thus, when enterprise leaders are thinking about entering into a cloud agreement, it’s critical that they start thinking about a security model for protecting the digital business. What’s more, as most companies are in multi-cloud environments, they must be able to put in place and oversee a strategy that encompasses multiple platforms in multiple locations, where regulations can vary dramatically.

By establishing zero-trust boundaries— just as they would to effectively compartmentalize different segments of their own networks—companies can better protect critical data hosted in the cloud from unauthorized applications or users, reduce the exposure of vulnerable systems, and prevent the movement of malware throughout their network.

Where to Begin

While enterprises across industries are eager to leverage the public cloud to build their digital-everywhere businesses, they must balance its benefits with their responsibility to keep sensitive data—personal health information, personally identifiable information, intellectual property, payment card data—secure. A workload containing such data must be more strongly protected that one with more benign data.