Login
Cisco and AWS demonstrate shared responsibility that identifies Security “of” the Cloud versus Security “in” the Cloud.
Shared responsibility remains central to every cloud initiative and defines how cloud providers and customers work together to achieve maximum security across all aspects of the cloud. While shared responsibility is a common term, surprisingly few people understand the model and fewer still have implemented it correctly. The lack of consistent security controls across cloud services does not go unnoticed by attackers, as they probe for vulnerabilities and slip undetected through unsecured cracks.
Security teams should start by understanding the security controls provided by their cloud service providers to help them highlight areas that are susceptible to threats and attacks. Matrices, such as the following from Amazon Web Services (AWS), give a clear view of the shared responsibility model to guide an organization’s approach:
Once Security teams understand the areas they’re responsible for securing, they can begin to construct a security model that includes the right set solutions to serve their needs.
The most effective security model is built around centralized policy and distributed enforcement, allowing security policy to be applied consistently across operating systems, applications and data using multiple security solutions. Security teams should look for ideal solutions that seamlessly integrate into their unified policy. A good first step is to ask the cloud provider for their recommendations and visit cloud marketplaces, such as the AWS Marketplace, to find and try solutions. Customers can also utilize relationships with their security vendors to obtain best practices.
As Mark Twain once said, “History doesn’t repeat itself, but it often rhymes.” There are fundamental differences between on-premise and cloud security practices and controls. However, the way in which security teams discover best practices has not changed. New playbooks from trusted vendors and cloud providers are available to help security teams implement layered approaches to securing their organizations. Security teams should examine these concepts and build on them to protect their specific cloud services without needing to reinvent new models on their own. A good place to start is Cisco’s Cloud Security page.
Watch the recent AWS and Cisco webinar to hear industry analysts, head CISO advisors, and AWS experts discuss shared responsibility, industry challenges and the ways in which other security teams are addressing the problem, and then visit the AWS Marketplace to see the latest Cisco Secure offerings. Purchasing Cisco Secure on AWS Marketplace has the additional benefit of meeting the AWS Enterprise Discount Program commitments.
What is your experience with shared responsibility? We invite you to share your thoughts.
More Cisco and AWS blogs:
We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!
Cisco Secure Social Channels
Cloud computing has revolutionized the IT world, making it easier for companies to deploy infrastructure and applications and deliver their services to the public. The idea of not spending millions of dollars on equipment and facilities to host an on-premises data center is a very attractive prospect to many. And certainly, moving resources to the cloud just has to be safer, right? The cloud provider is going to keep our data and applications safe for sure. Hackers won’t stand a chance. Wrong. More commonly than anyone should, I often hear this delusion from many customers. The truth of the matter is, without proper configuration and the right skillsets administering the cloud presence, as well as practicing common-sense security practices, cloud services are just (if not more) vulnerable.
The Shared Responsibility Model
Before going any further, we need to discuss the shared responsibility model of the cloud service provider and user.
When planning your migration to the cloud, one needs to be aware of which responsibilities belong to which entity. As the chart above shows, the cloud service provider is responsible for the cloud infrastructure security and physical security of such. By contrast, the customer is responsible for their own data, the security of their workloads (all the way to the OS layer), as well as the internal network within the companies VPC’s.
One more pretty important aspect that remains in the hands of the customer is access control. Who has access to what resources? This is really no different than it’s been in the past, exception being the physical security of the data center is handled by the CSP as opposed to the on-prem security, but the company (specifically IT and IT security) are responsible for locking down those resources efficiently.
Many times, this shared responsibility model is overlooked, and poor assumptions are made the security of a company’s resources. Chaos ensues, and probably a firing or two.
So now that we have established the shared responsibility model and that the customer is responsible for their own resource and data security, let’s take a look at some of the more common security issues that can affect the cloud.
Amazon S3
Amazon S3 is a truly great service from Amazon Web Services. Being able to store data, host static sites or create storage for applications are widely used use cases for this service. S3 buckets are also a prime target for malicious actors, since many times they end up misconfigured.
One such instance occurred in 2017 when Booz Allen Hamilton, a defense contractor for the United States, was pillaged of battlefield imagery as well as administrator credentials to sensitive systems.
Yet another instance occurred in 2017, when due to an insecure Amazon S3 bucket, the records of 198 million American voters were exposed. Chances are if you’re reading this, there’s a good chance this breach got you.
A more recent breach of an Amazon S3 bucket (and I use the word “breach,” however most of these instances were a result of poor configuration and public exposure, not a hacker breaking in using sophisticated techniques) had to do with the cloud storage provider “Data Deposit Box.” Utilizing Amazon S3 buckets for storage, a configuration issue caused the leak of more than 270,000 personal files as well as personal identifiable information (PII) of its users.
One last thing to touch on the subject of cloud file storage has to do with how many organizations are using Amazon S3 to store uploaded data from customers as a place to send for processing by other parts of the application. The problem here is how do we know if what’s being uploaded is malicious or not? This question comes up more and more as I speak to more customers and peers in the IT world.
API
APIs are great. They allow you to interact with programs and services in a programmatic and automated way. When it comes to the cloud, APIs allow administrators to interact with services, an in fact, they are really a cornerstone of all cloud services, as it allows the different services to communicate. As with anything in this world, this also opens a world of danger.
Let’s start with the API gateway, a common construct in the cloud to allow communication to backend applications. The API gateway itself is a target, because it can allow a hacker to manipulate the gateway, and allow unwanted traffic through. API gateways were designed to be integrated into applications. They were not designed for security. This means untrusted connections can come into said gateway and perhaps retrieve data that individual shouldn’t see. Likewise, the API requests to the gateway can come with malicious payloads.
Another attack that can affect your API gateway and likewise the application behind it, is a DDOS attack. The common answer to defend against this is Web Application Firewall (WAF). The problem is WAFs struggle to deal with low, slow DDOS attacks, because the steady stream of requests looks like normal traffic. A really great way to deter DDOS attacks at the API gateway however is to limit the number of requests for each method.
A great way to prevent API attacks lies in the configuration. Denying anonymous access is huge. Likewise, changing tokens, passwords and keys limit the chance effective credentials can be used. Lastly, disabling any type of clear-text authentication. Furthermore, enforcing SSL/TLS encryption and implementing multifactor authentication are great deterrents.
Compute
No cloud service would be complete without compute resources. This is when an organization builds out virtual machines to host applications and services. This also introduces yet another attack surface, and once again, this is not protected by the cloud service provider. This is purely the customers responsibility.
Many times, in discussing my customers’ migration from an on-premises datacenter to the cloud, one of the common methods is the “lift-and-shift” approach. This means customers take the virtual machines they have running in their datacenter and simply migrating those machines to the cloud. Now, the question is, what kind of security assessment was done on those virtual machines prior to migrating? Were those machines patched? Were discovered security flaws fixed? In my personal experience the answer is no. Therefore, these organizations are simply taking their problems from one location to the next. The security holes still exist and could potentially be exploited, especially if the server is public facing or network policies are improperly applied. For this type of process, I think a better way to look at this is “correct-and-lift-and-shift”.
Now once organizations have already established their cloud presence, they will eventually need to deploy new resources, and this can mean developing or building upon a machine image. The most important thing to remember here is that these are computers. They are still vulnerable to malware, so regardless of being in the cloud or not, the same security controls are required including things like anti-malware, host IPS, integrity monitoring and application control just to name a few.
Networking
Cloud services make it incredibly easy to deploy networks and divide them into subnets and even allow cross network communication. They also give you the ability to lock down the types of traffic that are allowed to traverse those networks to reach resources. This is where security groups come in. These security groups are configured by people, so there’s always that chance that a port is open that shouldn’t be, opening a potential vulnerability. It’s incredibly important from this perspective to really have a grasp on what a compute resource is talking to and why, so the proper security measures can be applied.
So is the cloud really safe from hackers? No safer than anything else unless organizations make sure they’re taking security in their hands and understand where their responsibility begins, and the cloud service provider’s ends. The arms war between hackers and security professionals is still the same as it ever was, the battleground just changed.
The post Is Cloud Computing Any Safer From Malicious Hackers? appeared first on .
Whether you’re trying to inform purchasing decisions or just want to better understand the cybersecurity market and its players, industry analyst reports can be very helpful. Following our recent accolades by Forrester and IDC in their respective cloud security reports, we want to help customers understand how to use this information.
Our VP of cybersecurity, Greg Young, taps into his past experience at Gartner to explain how to discern the most value from industry analyst reports.
The post How To Get The Most Out Of Industry Analyst Reports appeared first on .
FreshRSS 