{"id":106,"date":"2024-09-03T10:00:00","date_gmt":"2024-09-03T10:00:00","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=106"},"modified":"2024-09-03T10:00:00","modified_gmt":"2024-09-03T10:00:00","slug":"cloud-providers-must-own-up-to-their-part-in-the-current-state-of-insecurity","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=106","title":{"rendered":"Cloud providers must own up to their part in the current state of insecurity"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

The shared responsibility model has been foundational to cybersecurity from the start. But modern developments and complications, especially in the cloud, are beginning to erode our ability to truly share responsibility for secure results.<\/p>\n

The premise of shared responsibility is that a vendor is responsible for building a system that can<\/em> be secure, and the organization that uses the system is responsible for implementing<\/em> the system securely.<\/p>\n

Consider the safe. One of the oldest security technologies around, safes are relatively easy to understand from a shared responsibility perspective: The manufacturer builds a box with a lock on the door, and you install it in your office (or home, or secret underground lair, or \u2026).<\/p>\n

The manufacturer has obvious responsibilities. It needs to ensure the walls of the safe aren\u2019t easy to breach, the hinges on the door aren\u2019t easy to disconnect, and the lock isn\u2019t easy to pick. The manufacturer even provides specifications for how long the safe will endure various forms of attack.<\/p>\n

The buyer also has responsibilities when installing the safe. This includes how it is bolted in, who has access to it, and how it is protected from extreme force. The combination or key to the safe should also be kept secure from an adversary \u2014 a sticky note nearby with the combination is a bad idea.<\/p>\n

<\/a>Shared responsibility in IT isn\u2019t so simple<\/h2>\n

As technology becomes more complex, the model becomes more strained. When physical technologies become obsolete or vulnerabilities come to light, we often face a binary choice: to keep using the flawed system, or to replace it outright. But with computing technologies, we have a new option: upgrade in place.<\/p>\n

In early computer systems, these upgrades took the form of patches: new pieces of software that modified the behavior of existing systems. The software vendor had the responsibility to make sure the new software mostly worked \u2014 and when it didn\u2019t, like the vulnerability<\/a> that led to the Slammer worm, we have really bad days. The buyer \u201cjust\u201d needed to install the software.<\/p>\n

Even when software worked in a lab, it didn\u2019t always work in real environments. Application ecosystems are complicated, and vendors had to navigate the myriad ways their software might be used: which operating systems it would be installed on and what applications would rely on them.<\/p>\n

The easiest solution became configuration-drivenupdates: Rather than releasing a patch that disabled old functionality while implementing new capabilities, the new software contained both options, and a new, user-configurable, setting would be available. The vendors \u201cshared\u201d the responsibility for the user to manually enable this new setting \u2014 and if it broke things, the user could just disable the setting, rather than having to manually reinstall old software.<\/p>\n

<\/a>Backwards compatibility takes us \u2026 backwards<\/h2>\n

Unfortunately, once you keep support for old, vulnerable versions of your software, people will continue to use old, vulnerable versions of your software.<\/p>\n

Vendors shrugged their shoulders, and pundits blamed software users for choosing to use a working-but-vulnerable version instead of a broken-but-patched version (as if that was a real choice). And as more users continued to use the vulnerable features, vendors had to continue to support the vulnerable versions, which enabled more users to rely on the vulnerable features, which \u2026 you get the picture.<\/p>\n

Software has mostly stopped being single purpose, where a vendor can understand exactly how their customers will use it. Instead, it\u2019s become general purpose, with most software doing very simple things well, but being used in highly unpredictable ways. And no longer does an IT team even install most software, because most organizations are no longer \u201cmetal-native\u201d \u2014 owning their own computer systems \u2014 but are instead cloud-native, SaaS-native<\/a>, and AI-native.<\/p>\n

<\/a>Building castles in the cloud<\/h2>\n

As companies started relying increasingly on software they didn\u2019t control, they lost even the signal that a software vendor had updated its software choices. Initially, as more applications used CDNs to host their websites, these CDNs often had insecure settings. It wasn\u2019t until 2013 that CDNs could securely validate SSL\/TLS certificates at the origin. Due to the high costs involved, CDNs \u201clet\u201d customers manage their own secure configurations.<\/p>\n

While CDNs had to deal with the complexity of any number of origin and end-user systems they talked to, that was relatively simple compared to the challenge of the cloud service provider (CSP) world, where the likes of AWS, Azure, and GCP operate. Not only do they have to support innumerable single-cloud configurations, their customers also want to use their software in hybrid and multi-cloud environments.<\/p>\n

The memorable CapitalOne breach<\/a> is a classic example of the challenge of correctly configuring things in the hybrid cloud world. A proxy service in AWS<\/a> handled authentication, and while it had a (relatively) simple configuration when every request came from within the AWS environment, it needed a more complex configuration to handle requests that came from outside (where the hybrid environment was located).<\/p>\n

In the wake of the breach, AWS released several new capabilities and guides, but disavowed any responsibility for CapitalOne\u2019s imperfect implementations.<\/p>\n

<\/a>Lack of responsibility leads to a lack of incentives<\/h2>\n

Entire industries \u2014 from ecosystem hardeners like cloud-native application protection platforms (CNAPP)<\/a>, SaaS security posture management (SSPM), and cyber asset attack surface management (CAASM)<\/a> to application defenders such as application security posture management (ASPM), application detection and response (ADR), and web application and API protection (WAAP) \u2014 have risen (and some fallen) just to try to help companies protect their applications inside these dangerous ecosystems.<\/p>\n

Every day it gets harder. CSPs release new capabilities at an astounding rate, and each of those needs safe configuration. Old capabilities are silently updated with new security features to fix known issues, but customers are expected to stumble onto new documentation and notice the changes entirely on their own.<\/p>\n

Cloud providers need to stop denying that they hold some fault in the current state of insecurity. Their security tooling needs to be easier to use at scale. Unsafe configurations must be easy to identify, and when they do discover problems, they should bear the burden of helping their customers become more safe.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

The shared responsibility model has been foundational to cybersecurity from the start. But modern developments and complications, especially in the cloud, are beginning to erode our ability to truly share responsibility for secure results. The premise of shared responsibility is that a vendor is responsible for building a system that can be secure, and the […]<\/p>\n","protected":false},"author":1,"featured_media":107,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-106","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/106"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=106"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/106\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/107"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=106"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=106"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=106"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}