Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

The Real Implications of The Shared Security Model

DZone's Guide to

The Real Implications of The Shared Security Model

Read on to learn from an industry leader how to bolster your cloud security framework within a DevSecOps environment, and keep your data safe!

· Security Zone
Free Resource

Address your unique security needs at every stage of the software development life cycle. Brought to you in partnership with Synopsys.

Gone are the days when the majority of businesses could point to the cloud warily and say, “I think my data’s safer on-prem.” Organizations today are far less worried about how secure the cloud is in general, and this change in attitude has sped up cloud adoption to a great degree.

What has led to this more relaxed embrace of the cloud? In part, providers like AWS have gone to great lengths to codify and transparently communicate a Shared Responsibility Model that has expressly defined the scope and boundaries of responsibility. Increasingly, customers recognize that Amazon and its brethren have all-star teams that have a security focus ingrained in them. There’s a certain level of comfort that comes with knowing you are in good, experienced hands.

But, even as the cloud is proven to be quite secure and as confidence in it increases, Security and DevOps teams still have to be vigilant about their own workloads. Organizations have to pick up their end of the shared responsibility bargain — and in some cases, even take it a step further than what is required.

With that in mind, here’s what today’s organizations need to know in order to do that successfully and continue to benefit from all that the cloud has to offer without major security concerns stymying progress.

Focus on Controls

While the shared responsibility model lays out that providers should focus on the security of the cloud, the reality is that you still need to have the right controls in place. As this TechTarget article puts it, “Controls around logging and identity and access management give customers more granular control and greater insight into workload security.” In other words, while you may trust your cloud provider, access controls are a very good idea because they let you enforce rules and policies that make sense for your unique business. Even if AWS is adhering to industry best practices, there may be areas where it makes sense to tweak the rules to suit your unique situation.

Even better, the more insight you get via controls, the better off you’ll be when it comes to uncovering and addressing shadow IT (a big security risk) and overall monitoring and management of threats. So if you don’t have proper identity and access management controls in place currently, now is a good time to add this layer of security to your posture.

Visibility Matters

Beyond controls, perhaps the most important change you can make to fully embrace your responsibility for cloud security is to increase the visibility you have into your own cloud. Historically, many companies (especially larger enterprises) have shied away from the cloud because it offered less visibility. Frankly, that’s just not the case anymore.

This is critical for highly regulated industries and sensitive workloads in the cloud. At Threat Stack, we’ve always believed that your efforts in the cloud should be focused on the workload. You can’t know what’s happening to your files and who’s running what if you don’t have visibility into events on the host.

To ensure that your workload is always secure, you want to collect data straight from the source. This offers a level of monitoring, auditing, and alerting that’s impossible to achieve with traditional network and log driven systems. As such, it’s the best way to gain complete visibility and to fully take ownership of cloud security.

Go Beyond the Call of Duty

A recent article in Pipeline, a trade publication that speaks to the communications industry, pointed out that drawing the lines of security responsibility can be more of a gray area than it sometimes appears.

For example, wireless carriers are generally more focused on providing good reception, fast downloads, and high uptime. Their service-level agreements don’t say a whole lot about security. If an end-user clicks on a phishing email or downloads some malware by accident, that’s their problem (and it might even be an opportunity for the provider to offer yet another money-making service).

But the author of this article argues that “As an industry, it’s in our best interest to solve this problem.” Instead of looking at security as an upsell opportunity or simply not your problem, the author proposes that carriers encourage manufacturers to make more secure products and customers to upgrade and replace vulnerable products. Do this, he says, whether it’s technically your problem or not.

Why? Well, for one, it’s the right thing to do. But if the moral argument doesn’t win you over, he points out that in the case of carriers, they’re often the only ones who can detect a problem before an attack. Plus, from a more selfish angle, security issues can lead to throughput and performance issues, also — which definitely falls under the standard SLA.

Now, of course, this example is pretty specific to the wireless communications industry. But even if you’re not AT&T or Verizon, you may want to consider going above and beyond. Extending the area of your security focus can both protect your own assets and give your customers more confidence in you. If you’re in a competitive industry or have customers with compliance requirements, this can affect your sales cycles for the better (hello, renewals!)

At any rate, it’s a good idea to get a bit more complex than the standard “providers secure the cloud, we secure our data.” To determine where and how you should extend your security responsibilities, you may want to ask questions like:

  • What can we control security-wise? What can’t we control?
  • What do our customers expect of us, security-wise?
  • What do we need to focus on from a compliance perspective?
  • What types of data pass through our systems, and what security concerns arise?
  • What do our competitors cover security-wise that we don’t?
  • And more, depending on your situation.

Once you’re in a place where you feel comfortable with the security that the cloud provides your infrastructure and the security of your own applications and data, it’s a good idea to look for opportunities to go above and beyond. This will give you a competitive advantage, improve your reputation with customers, and likely affect your products and services for the better, too.

Accepting the Shared Responsibility

The shared responsibility model can feel like a burden when you first start to approach it. But the reality is that, as with many things in life, more responsibility can lead to more empowerment. When it comes to the cloud, the more you are able to take on security-wise, the better off you’ll be when the next attack comes knocking.

By understanding where you fit within the model and how you can go above and beyond for your users, you’ll improve your overall security posture. Tactically, by focusing on controls and increasing visibility into your entire infrastructure and workloads, you’ll have enough information at your fingertips to make informed decisions about cloud security. This approach is much preferable to flying by the seat of your pants, and we believe that accepting this responsibility and embracing it will go a long way towards ensuring your success.

Find out how Synopsys can help you build security and quality into your SDLC and supply chain. We offer application testing and remediation expertise, guidance for structuring a software security initiative, training, and professional services for a proactive approach to application security.

Topics:
security ,cloud security ,devsecops

Published at DZone with permission of Pete Cheslock, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}