Organizations are increasingly distributing various workloads in the cloud. In turn, business-critical data and services are increasingly spreading across this distributed infrastructure. Using the shared responsibility model as a guiding principle, organizations rely on cloud providers to protect their network, storage and compute layers. In contrast, organizations secure everything created, distributed, or stored in the public cloud.
When the public cloud was new, there were valid security concerns as the technology was unproven, but that is no longer the case. Modern cloud computing started in the 1990s, which means that providers have years of experience providing data and application access, rights management, strong governance, and system monitoring.
Naturally, not all cloud service providers are created equal. In reality, leveraging the size and scope of some cloud providers can be part of a more efficient overall security strategy for some businesses, particularly if budgets are small.
You are probably too concerned about the security process at this public cloud provider. The nature of public clouds is that they approach security using specialized personnel, automated processes, and discipline but are by no means certain.
We tend to bring together everything from software to infrastructure and development platforms, basically, anything you can add the ubiquitous acronym “as-a-Service” (-aaS) together under one giant “public cloud” roof.
For a company, “public cloud” can mean multiple infrastructure environments spanning various vendors, integrated with private cloud or on-premises infrastructure as part of a robust hybrid cloud portfolio. For another company, “public cloud” could mean they’re using Google Apps or Office 365.
The different approaches lead to generalizations about public cloud security, which tend to be off-target. Therefore, public cloud types and security considerations can vary significantly, and it is wrong to consider public cloud security as a homogeneous issue.
Similarly, it would be wrong to view all public cloud environments as the same from a security standpoint. The particular type of cloud environment may require you to distinguish between the data you are moving as part of any public cloud strategy. Different organizations have different needs and concerns regarding security, compliance, governance, SLAs, and more.
After all, to think of the public cloud as a large, leaky medium just waiting to be attacked is to miss the opportunities the cloud offers.
Public cloud providers spend an enormous amount of resources to ensure that security is a core part of the architecture in the beginning and keep their networks and services intact. Likewise, IT leaders need to understand the environments they use. You must enter your public cloud providers with the same care as you do in your own data center.
Generally, it requires a deep understanding of your public cloud security providers’ capabilities and how they match your specific needs, and you may need to implement a multi-cloud strategy to meet your various needs.
Particularly among the public cloud’s expected benefits is that it provides organizations with types of computing power, scalability, and flexibility. You don’t need to buy a single server or set up an entire data center unless it’s part of a larger IT plan.
However, this does not save you from risk; however, your data and applications’ security is your responsibility. It would help if you chose public cloud providers that make significant investments in security and related fields based on your needs. Cloud providers have software-defined structures and APIs that customers can take advantage of, and cloud security should ultimately be the customer’s responsibility.
This does not mean that your public cloud providers cannot assist you. Any cloud provider is constantly investing in their platform’s security, and they can do so on a global scale.
Public Cloud Security Recommendations
Data and applications hosted on cloud provider’s infrastructure, such as AWS, may cause uncertainty about who is responsible for what and how to protect and comply with regulations.
Opting for a public cloud means you’re signing up with a third-party provider to offer a range of services over the internet. Processing power to storage capacity are both examples of these services.
Contrary to what it may seem, a public cloud is not devoid of significant security measures. Public cloud providers have evolved and strengthened their security mechanisms over time, enabling them to handle increasingly complex attacks.
However, there are limitations to the current security level. For example, companies that handle sensitive data may not meet all the required compliance aspects with a public cloud.
New adoption of the public cloud brings new business, productivity, agility opportunities, and potential security risks. The public cloud is someone else’s computer that is a set of virtualized resources that run on a system that you control but is owned by a third party. Also, the public cloud is an extension of your network.
While the cloud service provider infrastructure is probably reasonably secure, your applications and data in the public cloud are safe only with your help.
Whether in the public cloud, private cloud, or physical data center, attackers want to compromise your network in order to steal user data, intellectual property, or computing resources. It is your duty to protect your apps and data in the public cloud by taking the appropriate precautions.
Protection is a joint obligation, according to public cloud providers, including Amazon Web Services (AWS) and Microsoft Azure. The cloud provider is in charge of ensuring that the platform is always accessible, usable, and up-to-date in this model.
Most firms believe that the cloud provider’s global data center infrastructure is more secure than theirs. What is forgotten is that you, as a customer, are responsible for protecting your applications and data running in the public cloud.
Securing your workloads in the public cloud is no different than securing them on-premises. You have complete control over what security to implement, and you should take steps to protect your content, whether customer data or intellectual property.
Communicate Early with Business Groups and DevOps
Many public cloud implementations are led by business units like DevOps, which rapidly deploy new products or usable prototypes. Challenges arise depending on the general availability of new implementation approaches, and the security team is often brought in to assist with the deployment. Both identify possible architecture-based vulnerabilities.
Ideally, security and DevOps should work together to understand public cloud projects’ scope and ensure that the application deployment architecture meets business development needs while reducing security risks.
Know Your Potential Exposure
Considering how easy an account can be set up, public cloud usage is often referred to as “shadow IT.” Employees doing the right thing for the job can create vulnerabilities if the environment is not configured correctly. It is imperative to know who uses the public cloud in your organization and make sure the environment is configured correctly.
- Monitor Public Cloud Usage: Calling the local public cloud provider’s sales manager and asking how often your business uses AWS or Azure is probably the easiest and most reliable way to find out usage. Alternatively, network visibility tools that provide use based on network application traffic are available.
- Ensure Correct Configuration: Configure the environment under security best practices. For example, each AWS service has a set of public application programming interfaces (APIs) that should be disabled if not used. Many new AWS users are unaware that Amazon Simple Storage Service is a public service that exposes everything stored on the internet unless the policy specifies otherwise. When building an initial virtual network within a resource group in Microsoft Azure, users should be aware that all outbound ports are available by default, posing possible security risks.
- Force Two-Factor Authentication: Most hacking breaches are due to stolen credentials or weak passwords. Two-factor authentication should be implemented to minimize the risk of an attacker gaining access using stolen credentials.
- Lock Up SSH: Secure Shell is the preferred method of securely managing cloud resources, but in AWS and Azure environments, it is often left exposed. Organizations also lack a clear understanding of their encryption key and certificate inventories, revealing security flaws. A cybercriminal with SSH access can easily conduct botnet-based attacks against an organization’s cloud infrastructure.
Understand the Attackers
Attackers take advantage of automation to find potential targets in minutes. Once identified, they look for vulnerabilities and check default passwords, look for SSH misconfigurations. Unlike a private data center where there is less concern about being public, public cloud resources are widely exposed.
Evaluate Your Public Cloud Security Options
When switching to the public cloud, you have many security choices to choose from, similar to other physical networking options.
Local Public Cloud Protection: Many local security services, such as security groups and web application firewalls, are available from cloud service providers (WAFs). Although these tools assist in reducing the attack surface, they are not without flaws.
Security groups are essentially port-based access control lists and provide filtering capabilities. However, you will not be able to identify or effectively control specific allowed applications, and you will not prevent threats or control file movement.
WAFs protect only HTTP and HTTPS applications and ignore all other traffic. It is also not always necessary, whereas a firewall is always critical. WAFs cannot protect applications such as Microsoft Lync, SharePoint, or Active Directory that use a wide variety of adjacent ports to function correctly. Also, they are not an effective way to define and control remote management or access tools such as SSH or Microsoft RDP.
Point Products: One of the most common approaches to securing the public cloud uses a host-based point product to detect and prevent threats. This approach’s popularity stems from the notion that local security in conjunction with an IDS or IPS is sufficient to protect your deployment.
In reality, an IDS goes against the cloud’s speed and agility as it requires manual intervention and remediation. An IPS only looks at known threats and can overlook zero-day or unknown threats. It doesn’t give you a complete view of your public cloud environment.
DIY Security: Some organizations choose a do-it-yourself approach to secure public cloud workloads using scripting and visibility tools to protect deployments. Potential downsides to this strategy include insufficient resources, lack of expertise to manage security implementation and operations, and nonexistent support in a security breach.
Organizations that rely on internal staff to manage their public cloud and security deployments must be wear-ready. Typically, only a few engineers know the environment well, but they don’t necessarily have time to keep the required documentation or manage information sharing needs. If even one of these engineers leaves the company, the organization may not be in an excellent position to manage its advancing security needs effectively.
Inline Virtualized Devices: An inline virtualized appliance, such as a virtualized next-generation firewall, provides a foundation for visibility into all traffic in your cloud deployment. Using integrated next-generation security, organizations can leverage protection for applications and data in the public cloud by using content-based identification technologies to understand what is accessed, by whom, and for what.
With this understanding, the dynamic security policy can be applied to securely enable applications, content, and users regardless of location and protect data and applications in public cloud deployments from targeted and unintentional threats.
Knowledge is Power
In public cloud security, information starts with the secure activation of all traffic passing through your environment, including mobile, network, and cloud. The size of digital data passing through these media is enormous.
By using a new generation firewall virtualized as part of a locally integrated, comprehensive security platform, organizations gain the necessary insight into traffic identity and characteristics to make more informed policy decisions to protect applications and data from threats.
Local public cloud tools provide little visibility at the application layer. Also, in some cases, in-depth knowledge of networking is required to interpret data accurately. Even with correct interpretation, it is even possible to know that 455 KB of data flows from a source IP address and port to a destination address. TCP 443 is of limited value when it is known that hundreds of applications can use TCP 443.
In some hybrid deployments where the public cloud is connected to the company via an IPsec VPN, using port-based controls to restrict access to only TCP 80 and TCP 443 seems sufficient; however, this is fundamentally flawed practice.
- At least 500 applications can use TCP 80 and TCP 443, many of which are remote access tools, and proxies.
- In most cases, applications in use require additional protocols and services such as DNS, NetBIOS, and possibly SSH, all of which require the corresponding ports to be open.
- Chef and Puppet, the most common development tools, requires a wide variety of open ports.
The truth is that port controls initially provide a level of control but do not provide contextual awareness of application traffic, content within, or the user. Understanding the entire traffic flow content, including the source/destination IP and country, can help you make more informed security policy decisions.