How safe is Cloud Computing?

Cloud computing refers to the technology of providing software and hardware services over the Internet. Cloud providers manage large data centers that store, manage and process data, allowing users to easily scale their current infrastructure.

Cloud security has emerged in response to the increasing need to defend complex ecosystems. However, before you decide on using a centralized security solution, you need to understand its benefits and challenges. This article offers a review of benefits and challenges, which may help you understand whether centralized cloud security is the right choice for you.

Many of the security threats faced by traditional data centers extend to cloud computing environments. In both cases, cybercriminals aim to exploit vulnerabilities in software and hardware. However, cloud computing introduces another factor, because attackers can exploit technology and processes managed by either the cloud provider or the cloud customer. The responsibility for addressing and mitigating these risks are shared between the two parties. Understanding this relationship is critical to securing the cloud.

NIST identifies the following characteristics and models for cloud computing:

• Essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service
• Service Models: software as a service (SaaS), platform as a service (PaaS), and infrastructure as a service (IaaS)
• Deployment Models: private cloud, community cloud, public cloud, and hybrid cloud

Risks of Cloud Computing

Lack of Visibility

Shifting operations, assets, and workloads to the cloud means transferring the responsibility of managing certain systems and policies to a contracted cloud service provider (CSP). As a result, organizations lose visibility into some network operations, services, and resource usage and cost.?

Organizations must obtain visibility into their cloud services to ensure security, privacy, and adherence to organizational and regulatory requirements. It typically involves using additional tools for cloud security configuration monitoring and logging and network-based monitoring. Organizations should set up protocols up front with the assistance of the CSP to alleviate these concerns and ensure transparency.????

Cloud Misconfigurations

Threat actors can exploit system and network misconfigurations as entry points that potentially allow them to move laterally across the network and access confidential resources.?Misconfigurations?can occur due to overlooked system areas or improper security settings.

Data Loss

Organizations leverage backups as a defensive tactic against data loss. Cloud storage is highly resilient because vendors set up redundant servers and storage across several geographic locations. However, cloud storage and Software as a Service (SaaS) providers are increasingly targeted by Ransomware attacks that compromise customer data.

Accidental Data Exposurenbsp;

Organizations must protect data privacy and confidentiality to ensure?compliance?with various regulations, including GDPR, HIPAA, and PCI DSS. Data protection regulations impose strict penalties for failing to secure data. Organizations also need to protect their own data to maintain a competitive advantage.

Placing data in the cloud offers great benefits but creates major security challenges for organizations. Unfortunately, many organizations migrate to the cloud without prior knowledge as to how to ensure they are using it securely, putting sensitive data at risk of exposure.

Identity Theft

Phishing attacks often use cloud environments and applications to launch attacks. The widespread use of cloud-based email, like G-Suite and Microsoft 365, and document sharing services, like Google Drive and Dropbox, has made email attachments and links a standard.?

Many employees are used to emails asking them to confirm account credentials before accessing a particular website or document. It enables cybercriminals to trick employees into divulging cloud credentials, making accidental exposure of credentials a major concern for many organizations.

Insecure Integration and APIs

APIs enable businesses and individuals to sync data, customize the cloud service experience, and automate data workflows between cloud systems. However, APIs that fail to encrypt data, enforce proper access control, and sanitize inputs appropriately can cause cross-system vulnerabilities. Organizations can minimize this risk using industry standard APIs that utilize proper authentication and authorization protocols.?

Data Sovereignty

Cloud providers typically utilize several geographically distributed data centers to improve the performance and availability of cloud-based resources. It also helps CSPs ensure they can maintain service level agreements (SLAs) during business-disrupting events like natural disasters or power outages.

Organizations that store data in the cloud do not know where this data is stored within the CSP’s array of data centers. Since data protection regulations like GDPR limit where EU citizens’ data can be sent, organizations using a cloud platform with data centers outside the approved areas risk regulatory non-compliance. Organizations should also consider jurisdictions when governing data. Each jurisdiction has different laws regarding data.

?

Consumers Have Reduced Visibility and Control. When transitioning assets/operations to the cloud, organizations lose some visibility and control over those assets/operations. When using external cloud services, the responsibility for some of the policies and infrastructure moves to the CSP.

The actual shift of responsibility depends on the cloud service model(s) used, leading to a paradigm shift for agencies in relation to security monitoring and logging. Organizations need to perform monitoring and analysis of information about applications, services, data, and users, without using network-based monitoring and logging, which is available for on-premises IT.

On-Demand Self Service Simplifies Unauthorized Use. CSPs make it very easy to provision new services. The on-demand self-service provisioning features of the cloud enable an organization's personnel to provision additional services from the agency's CSP without IT consent. The practice of using software in an organization that is not supported by the organization's IT department is commonly referred to as shadow IT.

Due to the lower costs and ease of implementing PaaS and SaaS products, the probability of unauthorized use of cloud services increases. However, services provisioned or used without IT's knowledge present risks to an organization. The use of unauthorized cloud services could result in an increase in malware infections or data exfiltration since the organization is unable to protect resources it does not know about. The use of unauthorized cloud services also decreases an organization's visibility and control of its network and data.

Internet-Accessible Management APIs can be compromised. CSPs expose a set of application programming interfaces (APIs) that customers use to manage and interact with cloud services (also known as the management plane). Organizations use these APIs to provision, manage, orchestrate, and monitor their assets and users. These APIs can contain the same software vulnerabilities as an API for an operating system, library, etc. Unlike management APIs for on-premises computing, CSP APIs are accessible via the Internet exposing them more broadly to potential exploitation.

Threat actors look for vulnerabilities in management APIs. If discovered, these vulnerabilities can be turned into successful attacks, and organization cloud assets can be compromised. From there, attackers can use organization assets to perpetrate further attacks against other CSP customers.

Separation Among Multiple Tenants Fails. Exploitation of system and software vulnerabilities within a CSP's infrastructure, platforms, or applications that support multi-tenancy can lead to a failure to maintain separation among tenants. This failure can be used by an attacker to gain access from one organization's resource to another user's or organization's assets or data. Multi-tenancy increases the attack surface, leading to?an increased chance of data leakage if the separation controls fail.

This attack can be accomplished by exploiting vulnerabilities in the CSP's applications, hypervisor, or hardware, subverting logical isolation controls or attacks on the CSP's management API. To date, there has not been?a documented security failure of a CSP's SaaS platform that resulted in an external attacker gaining access to tenants' data.

No reports of an attack based on logical separation failure were identified; however,?proof-of-concept exploits?have been demonstrated.

Data Deletion is Incomplete.?Threats associated with data deletion exist because the consumer has reduced visibility into where their data is physically stored in the cloud and a reduced ability to verify the secure deletion of their data. This risk is concerning because the data is spread over a number of different storage devices within the CSP's infrastructure in a multi-tenancy environment. In addition, deletion procedures may differ from provider to provider. Organizations may not be able to verify that their data was securely deleted and that remnants of the data are not available to attackers. This threat increases as an agency uses more CSP services.

Credentials are stolen. If?an attacker gains access to a user's cloud credentials, the attacker can have access to the CSP's services to provision additional resources (if credentials allowed access to provisioning), as well as target the organization's assets. The attacker could leverage cloud computing resources to target the organization's administrative users, other organizations using the same CSP, or the CSP's administrators. An attacker who gains access to a CSP administrator's cloud credentials may be able to use those credentials to access the agency's systems and data.

Administrator roles vary between a CSP and an organization. The CSP administrator has access to the CSP network, systems, and applications (depending on the service) of the CSP's infrastructure, whereas the consumer's administrators have access only to the organization's cloud implementations. In essence, the CSP administrator has administration rights over more than one customer and supports multiple services.

Vendor Lock-In Complicates Moving to Other CSPs. Vendor lock-in becomes an issue when an organization considers moving its assets/operations from one CSP to another. The organization discovers the cost/effort/schedule time necessary for the move is much higher than initially considered due to factors such as non-standard data formats, non-standard APIs, and reliance on one CSP's proprietary tools and unique APIs.

This issue increases in service models where the CSP takes more responsibility. As an agency uses more features, services, or APIs, the exposure to a CSP's unique implementations increases. These unique implementations require changes when a capability is moved to a different CSP. If a selected CSP goes out of business, it becomes a major problem since data can be lost or cannot be transferred to another CSP in a timely manner.

Increased Complexity Strains IT Staff. Migrating to the cloud can introduce complexity into IT operations. Managing, integrating, and operating in the cloud may require that the agency's existing IT staff learn a new model. IT staff must have the capacity and skill level to manage, integrate, and maintain the migration of assets and data to the cloud in addition to their current responsibilities for on-premises IT.

Key management and encryption services become more complex in the cloud. The services, techniques, and tools available to log and monitor cloud services typically vary across CSPs, further increasing complexity. There may also be emergent threats/risks in hybrid cloud implementations due to technology, policies, and implementation methods, which add complexity. This added complexity leads to an increased potential for security gaps in an agency's cloud and on-premises implementations.

Insiders Abuse Authorized Access. Insiders, such as staff and administrators for both organizations and CSPs, who abuse their authorized access to the organization's or CSP's networks, systems, and data are uniquely positioned to cause damage or exfiltrate information.

The impact is most likely worse when using IaaS due to an insider's ability to provision resources or perform nefarious activities that require forensics for detection. These forensic capabilities may not be available with cloud resources.

Stored Data is Lost.?Data stored in the cloud can be lost for reasons other than malicious attacks. Accidental deletion of data by the cloud service provider or a physical catastrophe, such as a fire or earthquake, can lead to the permanent loss of customer data. The burden of avoiding data loss does not fall solely on the provider's shoulders. If a customer encrypts its data before uploading it to the cloud but loses the encryption key, the data will be lost. In addition, inadequate understanding of a CSP's storage model may result in data loss. Agencies?must consider data recovery and be prepared for the possibility of their CSP being acquired, changing service offerings, or going bankrupt.

This threat increases as an agency uses more CSP services. Recovering data on a CSP may be easier than recovering it at an agency because an SLA designates availability/uptime percentages. These percentages should be investigated when the agency selects a CSP.

CSP Supply Chain is compromised. If the CSP outsources parts of its infrastructure, operations, or maintenance, these third parties may not satisfy/support the requirements that the CSP is contracted to provide with an organization. An organization needs to evaluate how the CSP enforces compliance and check to see if the CSP flows its own requirements down to third parties. If the requirements are not being levied on the supply chain, then the threat to the agency increases.

This threat increases as an organization uses more CSP services and is dependent on individual CSPs and their supply chain policies.

?Insufficient Due Diligence Increases Cybersecurity Risk.?Organizations migrating to the cloud often perform insufficient due diligence. They move data to the cloud without understanding the full scope of doing so, the security measures used by the CSP, and their own responsibility to provide security measures. They make decisions to use cloud services without fully understanding how those services must be secured.

Cloud security also presents some challenges. The list below reviews some of these challenges.

·???????? Single point of failure—a unified security solution can become a possible single point of failure, since all the security capabilities are concentrated in one appliance. Hackers would only have to disrupt one centralized system to bring down the security of the entire company.

·???????? Performance limitations—a unified security solution have a great effect on performance in terms of data throughput of the system.

·???????? Unnecessary costs—small companies may require just a few of the security features offered by centralized security systems. As a result, they may pay for features they don’t need.

Cloud Security for Dummies

Cloud Security For Beginners

Advancing Your Cloud Security Journey

Common Risks of AWS – Amazon Web Services

Amazon Web Services (AWS) has strong safeguards to protect your privacy, and manages compliance programs in its infrastructure. However, there are some common security risks associated with AWS, including:

Data encryption

Weak IAM

Misconfigured security groups

Unpatched or outdated software

Insecure network connections

Insufficient monitoring and logging

Lacking audit logs on AWS activity

Unsecured S3 buckets

IAM permissions

Unsecured sensitive data stored in the cloud

Vulnerabilities in source control and function repos

Container vulnerabilities in Amazon Elastic Container Registry (ECR)

Open source vulnerabilities

1- Unrestricted and long-lived access to S3 buckets

S3 (Simple Storage Service) lets users keep data that can be easily and securely retrieved. In this, users select a region and create a bucket to upload data. The S3 system uploads and stores data on multiple data centers in that region and also fixings all found lost redundancy.

S3 buckets are susceptible to ransomware attacks if they permit unfiltered access to all users. Attackers can use an account that has read/write permission and use it to encrypt admin and also core documents and folders. Aside from this, attackers can also rewrite settings or set up malware within the application using such privileges.

Therefore, AWS users must approve and manage permissions for those who have access to these buckets. Permissions can be of the list following kinds: edit permission, view permission, upload/delete, and list.?Reviewing permission for all these buckets?is an essential action to mitigate AWS security risks.

You will need to implement?temporary access with the IAM Roles strategy?when accessing your data. You can create custom policies with some conditions like IP address for your IAM roles. So, you can define a secure process between your application and S3 Buckets.

2- Undetected request events to your S3 Buckets

S3 Buckets can become targets for information theft because they handle objects and store application files. Cyber-attacks leading to data leaks consist of countless requests for accessing data in these buckets. And in the absence of bucket logs, these requests go undetected until it is too late.

S3 Buckets do not generate logs by default?given that it needs to be turned on manually. Once enabled, S3 buckets will create access logs for any type of request made to the buckets with details such as the type of request, the resource used for the request, and date-time stamps.?Having gain access logs helps in assessing AWS security risks by keeping an eye on requests?and also recognizing the type of requests made. Having access logs helps in assessing AWS security risks by monitoring requests and identifying the type of requests made.

An AWS Security Audit?would be an ideal approach to identify such misconfigurations.

3- Malevolent AWS API requests

There are multiple AWS APIs available in public and the attackers could use these endpoints to explode some of your architecture details. They can try to sniff access details from your application’s communication with AWS services like DynamoDB, SQS, SNS, API Gateway

Then the attackers can use this information to inject malicious codes right into API to launch DDoS attacks or use these infected APIs for SQL Injection for an extensive cyberattacks.

You need to always use?proper encryption options with these AWS services at this point. Also, it is recommended that?you should use AWS SDK when developing AWS-integrated applications. Because AWS SDK signs your requests by default.

For monitoring, Amazon CloudTrail allows users to access the complete history of all API calls made to the account.?These logs include Request, Response, IP address as well as date-time stamps. Once these logs are created, they are stored in a pre-designated S3 bucket. Having CloudTrail enabled will certainly help you detect any kind of AWS security risks by monitoring all API calls.?Also, you can get notified with CloudTrail Event with some specific security issues like root user login.

Amazon CloudTrails (Source:AWS)

4- Unfiltered traffic from untrusted sources

When traffic has unrestricted access to your deployed AWS instances or load balancers, there is a possibility that attackers can gather information about the application to launch an attack. By limiting particular traffic to specific instances, you will stop attackers from gaining insight into the application.

Without an effectively configured network, attacks such as DDoS can be launched from a group of IPs and also can rapidly overwhelm a system. To prevent such attacks you require to configure the network to deny traffic from suspicious sources. This also aids in reducing the attack area of an application by limiting traffic as well as controlling access. Security Groups act like a firewall by allowing just specific traffic to any instance. As an example, the EC2 instance may have multiple Security Groups assigned to it, for which the rules can be updated at any time. As well as only the allowed traffic can access the instance. These rules define specific sources for accessing the instance by using protocols such as ICMP or TCP along with destination ports.?To stay clear of any AWS security risks only specific IP addresses or ranges ought to be allowed access.

NACL is an additional layer of security that manages the traffic to and also from a subnet. Similar to other security groups you can set up NACL with security rules. In NACL, rules are evaluated based on the rule number. The first rule that matches a request is offered priority and implemented.?To avoid any type of AWS security risks, check to see if an NACL rule allows all ports or IP addresses.?This will certainly make the system vulnerable, so remove the rule as well as create new restrictive rules for appropriate ports or IP.

5- Incorrect permission and privileges

Not all users need access to all folders and divisions of the application. For instance, non-admin users would not require access to the control panel or admin files. Identity and Access Management allows users to manage account access by setting up user accounts and also permissions. IAM also allows for the creation of user groups which assists in assigning permissions collectively to users who belong to a specific group. Identity and Access Management enables users to manage account access by setting up user accounts and permissions. IAM also enables the creation of user groups which helps in assigning permissions collectively to users that belong to a specific group. While assigning permissions,?you need to understand the demands and requirements of the set of permissions.?Review all users who have higher access privileges and regularly update users based on their functions. Also, you need to prevent using AWS Managed Policies.?You can create custom policies based on the application stage and user role.

6- Login and credential theft

Plenty of cyber-attacks on cloud services are based on credential theft. Credentials are the gold mines for hackers, allowing them to totally take over an account. Cyber-attacks faced by establishments such as CodeSpaces and Timehop are an example of exactly how extensive damage can be done by credential theft.?There are some ways to secure your account and sign in information:

·???????? 2 Factor Authentication or Multi-Factor Authentication can protect accounts in case credentials are stolen

·???????? Continuous monitoring for failed or anonymous logins

·???????? Store your application and system logs with strict rights

·???????? Do not push your credentials git repositories and logs

·???????? You can make use of services such as AWS Secrets Manager to rotate login credentials

AWS Secret Manager Integration (Source: AWS)

7- Vulnerable multi-tenant cloud infrastructure

The notion that multi-tenant systems have more security risks is not correct. Rather the security of your system and also infrastructure figures out the level of security. AWS has adopted numerous measures to ensure the proper partition of data between users as well as to ensure that there are no data leaks in the case of multi-tenant systems.?Still, users can take extra precautions in areas as pointed out listed below

·???????? Secure access for end users — like Oauth2

·???????? Central control panel and infrastructure

·???????? Monitoring actively the runtime and services

·???????? Vulnerability and also automated patching management

·???????? Invest in Private Networking like DirectConnect

8- Protect your public endpoints with WAF

If you need to serve API endpoints or web applications in public, you need to monitor and take action against popular attack types like DDoS, ReDoS, XSS, … in real-time.You can easily create a powerful layer-7 firewall with AWS WAF service against OWASP Top 10 rules. AWS WAF is a web application firewall that lets you monitor the HTTP and HTTPS requests that are forwarded to your protected web application resources. You can protect the following resource types:

·???????? Amazon CloudFront distribution

·???????? Amazon API Gateway REST API

·???????? Application Load Balancer

·???????? AWS AppSync GraphQL API

·???????? Amazon Cognito user pool

You can get benefit from managed rules to mitigate attacks with minimum effort. Also, if you want to create a more resilient application, you can create your own rule sets.?You can evaluate the incoming requests in real-time and accept or deny them with such information as IP address, HTTP header, originated country, and the presence of SQL/XSS code that is likely to be malicious.?For instance,?if you do not serve in a specific country, you can block all requests coming from this country.

As more and more companies are moving toward cloud-based systems, AWS security risks continue to increase. Security breaches and cyberattacks can trigger a tremendous influence on financial and brand value. To ensure that your cloud services are completely secure, you will certainly require an extensive AWS security audit which can detect security gaps as well as offer a comprehensive fixing plan and guidance.

Common Risks of Microsoft Azure Cloud

Cloud Misconfiguration

Misconfiguration is the root cause of most Microsoft Azure PaaS security problems. Azure itself is a secure platform, but it is easy to configure and use Azure infrastructure insecurely. Millions of private records have leaked in the last few years because of cloud misconfiguration, especially the misconfiguration of databases and object storage services.

?

The average organization operates at least 14 misconfigured IaaS instances, according to McAfee’s Cloud Adoption and Risk Report, with an average of 2,269 misconfiguration incidents per month. Misconfiguration doesn’t always cause cloud security problems, but cloud security problems are almost always caused by misconfiguration.

?

Misunderstanding the Shared Responsibility Model

Microsoft Azure operates a shared responsibility security model. Microsoft is responsible for some aspects of Azure security; users are responsible for other aspects. Security vulnerabilities result when Azure users don’t understand what they are responsible for and the tools and services Azure provides to help them. The division of responsibility differs depending on the Azure service.

For IaaS services such as Azure VMs, Microsoft is responsible for physical security, network hardware, and the hypervisor. Users are responsible for the security of the operating system, network configuration, identity management, data storage, applications, and more. On a PaaS platform like Azure Web Apps, Microsoft takes additional security responsibilities, including for network configuration and the operating system.

Azure users who don’t understand where the division of responsibility is are at risk of creating easily avoided security vulnerabilities.

Failing To Encrypt Data at Rest

Data should be encrypted at rest and in transit. While encryption in transit can be complicated, encryption at rest is straightforward on Azure, which offers several encryptions and key management strategies depending on the type of storage.

Unlike AWS’s S3, Azure Blob Storage encrypts blobs by default, either with Microsoft-managed or user-supplied keys. However, VM disks are not encrypted by default, creating a potential security vulnerability. Azure users can, and should, activate disk encryption. For managed disks, Azure offers both server-side encryption and Azure Disk Encryption options, both of which are free.

?

Data Storage Access Misconfiguration

A permission system governs access to data stored in Azure Blob Storage. Azure Storage has a simple permission system compared to other cloud platforms, which makes misconfiguration less likely. But it is possible for a user to set permissions that expose data to the entire internet.

?

Often, this is done for convenience or to share data without having to set access permissions and identities correctly. Whatever the motivation, it’s a mistake that can expose Azure users to expensive, embarrassing, and potentially illegal security risks.

Exposing Services to the Open Internet

When we mentioned the shared responsibility model for security, we said that IaaS users are responsible for the security of operating systems and applications. That includes databases and other services running on servers.

For example, users are responsible for securing MySQL or MongoDB databases they install on their Azure VM. Those databases are not particularly insecure, but inexperienced users can configure them so that anyone can access the data they store. Hundreds of millions of records have been leaked in this way over the past few years.

Lack of Security Monitoring

Azure lacks out-of-the-box alerts and notifications for the telemetry businesses care most about. While tools such as Azure Security Center include some alerts and will let you know about serious security flaws, such as unencrypted disk volumes, for the most part, Azure expects users to create and manage alerts and notifications based on the extensive telemetry Azure provides.

?The consequence is that many businesses with infrastructure on Azure lack insight into their infrastructure and potential security vulnerabilities.

Main Cloud Security Issues and Threats in 2024

Almost every organization has adopted cloud computing to varying degrees within their business. However, with this adoption of the cloud comes the need to ensure that the organization’s cloud security strategy is capable of protecting against the top threats to cloud security.

Misconfiguration

Misconfigurations of cloud security settings are a leading cause of cloud data breaches. Many organizations’ cloud security posture management strategies are inadequate for protecting their cloud-based infrastructure.

Several factors contribute to this. Cloud infrastructure is designed to be easily usable and to enable easy data sharing, making it difficult for organizations to ensure that data is only accessible to authorized parties. Also, organizations using cloud-based infrastructure also do not have complete visibility and control over their infrastructure, meaning that they need to rely upon security controls provided by their cloud service provider (CSP) to configure and secure their cloud deployments. Since many organizations are unfamiliar with securing cloud infrastructure and often have multi-cloud deployments – each with a different array of vendor-provided security controls – it is easy for a misconfiguration or security oversight to leave an organization’s cloud-based resources exposed to attackers.

Unauthorized Access

Unlike an organization’s on-premises infrastructure, their cloud-based deployments are outside the network perimeter and directly accessible from the public Internet. While this is an asset for the accessibility of this infrastructure to employees and customers, it also makes it easier for an attacker to gain unauthorized access to an organization’s cloud-based resources. Improperly-configured security or compromised credentials can enable an attacker to gain direct access, potentially without an organization’s knowledge.

Insecure Interfaces/APIs

CSPs often provide a number of application programming interfaces (APIs) and interfaces for their customers. In general, these interfaces are well-documented in an attempt to make them easily-usable for a CSP’s customers.

However, this creates potential issues if a customer has not properly secured the interfaces for their cloud-based infrastructure. The documentation designed for the customer can also be used by a cybercriminal to identify and exploit potential methods for accessing and exfiltrating sensitive data from an organization’s cloud environment.

Hijacking of Accounts

Many people have extremely weak password security, including password reuse and the use of weak passwords. This problem exacerbates the impact of phishing attacks and data breaches since it enables a single stolen password to be used on multiple different accounts.

Account hijacking is one of the more serious cloud security issues as organizations are increasingly reliant on cloud-based infrastructure and applications for core business functions. An attacker with an employee’s credentials can access sensitive data or functionality, and compromised customer credentials give full control over their online account. Additionally, in the cloud, organizations often lack the ability to identify and respond to these threats as effectively as for on-premises infrastructure.

Lack of Visibility

An organization’s cloud-based resources are located outside of the corporate network and run on infrastructure that the company does not own. As a result, many traditional tools for achieving network visibility are not effective for cloud environments, and some organizations lack cloud-focused security tools. This can limit an organization’s ability to monitor their cloud-based resources and protect them against attack.

External Sharing of Data

The cloud is designed to make data sharing easy. Many clouds provide the option to explicitly invite a collaborator via email or to share a link that enables anyone with the URL to access the shared resource.

While this easy data sharing is an asset, it can also be a major cloud security issue. The use of link-based sharing – a popular option since it is easier than explicitly inviting each intended collaborator – makes it difficult to control access to the shared resource. The shared link can be forwarded to someone else, stolen as part of a cyberattack, or guessed by a cybercriminal, providing unauthorized access to the shared resource. Additionally, link-based sharing makes it impossible to revoke access to only a single recipient of the shared link.

Malicious Insiders

Insider threats are a major security issue for any organization. A malicious insider already has authorized access to an organization’s network and some of the sensitive resources that it contains. Attempts to gain this level of access are what reveals most attackers to their target, making it hard for an unprepared organization to detect a malicious insider.

On the cloud, detection of a malicious insider is even more difficult. With cloud deployments, companies lack control over their underlying infrastructure, making many traditional security solutions less effective. This, along with the fact that cloud-based infrastructure is directly accessible from the public Internet and often suffers from security misconfigurations, makes it even more difficult to detect malicious insiders.

Cyberattacks

Cybercrime is a business, and cybercriminals select their targets based upon the expected profitability of their attacks. Cloud-based infrastructure is directly accessible from the public Internet, is often improperly secured, and contains a great deal of sensitive and valuable data. Additionally, the cloud is used by many different companies, meaning that a successful attack can likely be repeated many times with a high probability of success. As a result, organizations’ cloud deployments are a common target of cyberattacks.

Denial of Service Attacks

The cloud is essential to many organizations’ ability to do business. They use the cloud to store business-critical data and to run important internal and customer-facing applications.

This means that a successful Denial of Service (DoS) attack against cloud infrastructure is likely to have a major impact on a number of different companies. As a result, DoS attacks where the attacker demands a ransom to stop the attack pose a significant threat to an organization’s cloud-based resources.

Common Risks of GCP - Google Cloud Platform

Just about every process in the Google Cloud Platform (GCP) is regulated by identity access management (IAM). Yet, when it comes to IAM while using GCP, many users today are making major security mistakes. Unfortunately, these missteps lead to critical gaps creating pathways to your data.

So, what do these misconfigurations look like?

1. Confusing ‘allUsers’ group and ‘allAuthenticatedUsers’

There are two types of users on GCP: allUsers, which are both authenticated users and unauthenticated anonymous users, and allAuthenticatedUsers, which can be anyone with a verified Google account.

Granting allUsers access to one of your buckets is like leaving your front door unlocked. Basically, anyone who obtains the link will be able to access it freely — creating an opportunity for public data exposure.

Granting allAuthenticatedUsers access is slightly more restricted than allUsers, but not by much. This simply limits those that can access your data to anyone who is authenticated with a Google account or a service account, but not anonymous users.

All team members should be cognizant of the use of these permissions and ideally avoid using them if possible. Alternately, restrictions can be applied to prevent the use of these across GCP .

2. Excessive permissions and user privilege escalation

If an Identity is over-privileged, it can directly or indirectly promote itself to the ownership level of a bucket. With this level of privilege, they have the authority to make administrative decisions that could compromise your entire operation.

Let’s look at an example of what an Identity with excessive permissions could achieve:

Copy data out of your bucket to an attacker-owned bucket.

Delete all of your data and then delete your bucket.

Create a new bucket with the same name in the attacker’s project, and give read/write permissions for files to everyone; the attacker could grant storage object creator and storage object viewer roles to the allUsers group to accomplish this.

Copy the data from the backup bucket to the new bucket in the attacker’s project.

Thus, it is very important to understand the Effective Permissions (aka: end-to-end permissions) of all your GCP Identities whether they be human or non-human.

3. Storage access and constraints

The constraint that’s most relevant to this misconfiguration is called domain restricted sharing.

If you place your data storage buckets with sensitive data under a certain project or folder, you can then apply this constraint at the project or folder level to specify that no IAM permissions be granted to anyone outside of your organization.

If you are a G Suite customer, you can grant access to the G Suite ID for your domain. This will prevent any user who has not authenticated to your G Suite domain from being granted IAM permissions to any resources in your project.

The issues with using this constraint are as follows:

It prevents the IAM permissions from being changed. This means that anything that’s already misconfigured when you apply this constraint will stay that way.

If your buckets are not already organized and segmented by projects (or folders) such that public and private buckets are clearly separated, you won’t be able to implement this constraint.

With this in mind, what Cloud Ops teams need to ensure is that they think through the design of their data storage architecture with Identities and access in mind. This will ensure that when implemented these issues don’t arise … and go unknown until it is too late.

4. Storage access and VPC constraints

Virtual Public Cloud (VPC) Service Controls can also help mitigate the misconfiguration of storage buckets.

GCP allows you to make resources private, which means they can’t be accessed via the Internet even if the IAM policy allows it. This control allows you to set up a VPC service perimeter around projects and then control access to that perimeter based on things like your IP address, geographic location, and conditions on the device requesting the access, among other things.

The issues with using a VPC Service Control are as follows:

You could easily miss valid use cases and actually interrupt your business while implementing a service perimeter.

If your buckets are not already organized by project, this will not be a feasible solution for you.

While this is a great control, it comes back to the importance of fully understanding you data and identity access requirements. You need to know where you data is and which Identities will require access and from where they need it. Furthermore, you need to continuously monitor for potential changes to ensure that things stay locked down.

5. Secrets management and encryption

Users often want to know whether encryption will prevent the exposure of their files.

GCP provides encryption on stored objects by default with keys that they manage. You might think that this approach would reduce data exposure, but it doesn’t.

When you apply IAM permissions that allow the public to read objects in buckets, Google is obliged to decrypt the data — the same as it would for your internal users. This also applies to customer managed encryption keys (CMEKs) that you are able to provision and control in the key management service (KMS).

The one case that encryption would not allow data exposure is with customer supplied encryption keys (CSEKs) because Google never stores those. In this case, you have to store and manage your own keys. For use with storage buckets, you must supply your public key to Google to allow it to encrypt the data being stored in the bucket. But, under this configuration, GCP has no way to decrypt the data for you without that.

So, if an unauthorized party gains access to the encrypted objects, they would need to separately obtain access to your keys in order to decrypt the data.

6. API keys

API keys in GCP are a form of authentication and authorization that can be used when calling specific API endpoints in the cloud. These keys are tied directly to GCP projects and are therefore considered less secure than OAuth 2.0 client credentials or service account user-managed keys.

In a secure cloud environment, all assets and resources should be monitored for when they are created, updated, or deleted. This makes sensitive credentials like API keys especially important to track.

Unfortunately, GCP does not currently support a native way to programmatically inventory API keys across an entire GCP organization.

7. Disabled logging and monitoring

While this is listed as #7, it is one of the most important things you need to avoid.

It’s surprising how many organizations don’t enable, configure, or even review the logs and telemetry data that public clouds provide, which in many cases can be extremely sophisticated. Someone on your enterprise cloud team should have the responsibility for regularly reviewing this data and flagging security-related events. Be sure to enable logging and monitoring functionality to support these efforts.

Learn How Sonrai Eliminates Cloud Misconfigurations.

Tips for Addressing Cloud Security GCP Security Misconfigurations

Now that you have a better idea of some of the more common GCP security misconfigurations, here are some tips that can help you avoid them:

Know your cloud environments and define a security foundation.

Review access controls to ensure only authorized users can take action on specified cloud resources. This includes ensuring IAM policies are properly implemented, such as bucket policies on storage accounts inside of GCP.

Enforce the principle of least privilege by only giving your users the permissions they need to do their jobs.

Implement logging, which can identify changes to your cloud environments and help determine the extent of an incident.

Remember, much of this work can be automated to help you rapidly discover misconfigurations, data that lives where it shouldn’t, and identities that shouldn’t have access to it.

Take advantage of the right tools, analyze your cloud environments, and perform best practice assessments and audits.

Main Cloud Security Concerns in 2024

In the Cloud Security Report, organizations were asked about their major security concerns regarding cloud environments. Despite the fact that many organizations have decided to move sensitive data and important applications to the cloud, concerns about how they can protect it there abound.

Data Loss/Leakage

Cloud-based environments make it easy to share the data stored within them. These environments are accessible directly from the public Internet and include the ability to share data easily with other parties via direct email invitations or by sharing a public link to the data.

The ease of data sharing in the cloud – while a major asset and key to collaboration in the cloud – creates serious concerns regarding data loss or leakage. In fact, 69% of organizations point to this as their greatest cloud security concern. Data sharing using public links or setting a cloud-based repository to public makes it accessible to anyone with knowledge of the link, and tools exist specifically for searching the Internet for these unsecured cloud deployments.

Data Privacy/Confidentiality

Data privacy and confidentiality is a major concern for many organizations. Data protection regulations like the EU’s General Data Protection Regulation (GDPR), the Health Insurance Portability and Accessibility Act (HIPAA), the Payment Card Industry Data Security Standard (PCI DSS) and many more mandate the protection of customer data and impose strict penalties for security failures. Additionally, organizations have a large amount of internal data that is essential to maintaining competitive advantage.

Placing this data on the cloud has its advantages but also has created major security concerns for 66% of organizations. Many organizations have adopted cloud computing but lack the knowledge to ensure that they and their employees are using it securely. As a result, sensitive data is at risk of exposure – as demonstrated by a massive number of cloud data breaches.

Accidental Exposure of Credentials

Phishers commonly use cloud applications and environments as a pretext in their phishing attacks. With the growing use of cloud-based email (G-Suite, Microsoft 365, etc.) and document sharing services (Google Drive, Dropbox, OneDrive), employees have become accustomed to receiving emails with links that might ask them to confirm their account credentials before gaining access to a particular document or website.

This makes it easy for cybercriminals to learn an employee’s credentials for cloud services. As a result, accidental exposure of cloud credentials is a major concern for 44% of organizations since it potentially compromises the privacy and security of their cloud-based data and other resources.

Incident Response

Many organizations have strategies in place for responding to internal cybersecurity incidents. Since the organization owns all of their internal network infrastructure and security personnel are on-site, it is possible to lock down the incident. Additionally, this ownership of their infrastructure means that the company likely has the visibility necessary to identify the scope of the incident and perform the appropriate remediation actions.

With cloud-based infrastructure, a company only has partial visibility and ownership of their infrastructure, making traditional processes and security tools ineffective. As a result, 44% of companies are concerned about their ability to perform incident response effectively in the cloud.

Legal and Regulatory Compliance

Data protection regulations like PCI DSS and HIPAA require organizations to demonstrate that they limit access to the protected information (credit card data, healthcare patient records, etc.). This could require creating a physically or logically isolated part of the organization’s network that is only accessible to employees with a legitimate need to access this data.

When moving data protected by these and similar regulations to the cloud, achieving and demonstrating regulatory compliance can be more difficult. With a cloud deployment, organizations only have visibility and control into some of the layers of their infrastructure. As a result, legal and regulatory compliance is considered a major cloud security issue by 42% of organizations and requires specialized cloud compliance solutions.

Data Sovereignty/Residence/Control

Most cloud providers have a number of geographically distributed data centers. This helps to improve the accessibility and performance of cloud-based resources and makes it easier for CSPs to ensure that they are capable of maintaining service level agreements in the face of business-disrupting events such as natural disasters, power outages, etc.

Organizations storing their data in the cloud often have no idea where their data is actually stored within a CSP’s array of data centers. This creates major concerns around data sovereignty, residence, and control for 37% of organizations. With data protection regulations such as the GDPR limiting where EU citizens data can be sent, the use of a cloud platform with data centers outside of the approved areas could place an organization in a state of regulatory non-compliance. Additionally, different jurisdictions have different laws regarding access to data for law enforcement and national security, which can impact the data privacy and security of an organization’s customers.

Protecting the Cloud

The cloud provides a number of advantages to organizations; however, it also comes with its own security threats and concerns. Cloud-based infrastructure is very different from an on-premises data center, and traditional security tools and strategies are not always able to secure it effectively. For more information about leading cloud security issues and threats, download the Cloud Security Report.

Weaponized vulnerabilities are tools that allow attackers to enter and move within a cloud, giving them a key to it. For example, targeted phishing campaigns that Weaponized various Google services are Weaponized exploits.

Vulnerability is a weakness in an IT system that can be exploited by an attacker to deliver a successful attack. Attackers can exploit vulnerabilities through flaws, features, or user error, and often combine one or more to achieve their goal. The four main types of vulnerabilities in information security are network vulnerabilities, operating system vulnerabilities, process (or procedural) vulnerabilities, and human vulnerabilities.

Cloud Security Best Practices

Understand Your Shared Responsibility Model

When you work with a cloud service provider to move your systems and data to the cloud, you have a partnership with the cloud provider, and you share responsibility for your security implementation. It is important to see which security actions still exist and which ones are currently handled by providers.?

All cloud providers use a shared security responsibility model. Exact responsibilities vary between providers, but might include:

·???????? Segmentation and isolation of CPU, storage and memory between tenants

·???????? Protect hardware through software, hardware, and physical securitycontrols

·???????? Rapid failover and high availability

·???????? Built-in backup, restore, and disaster recovery solutions

As a cloud customer, typically your responsibility is securing data and workloads. Make sure the shared responsibility model for your cloud provider is clear to you, and that you are doing your part to secure your workloads.

Cloud Security Posture Management (CSPM)

The?shared responsibility model?(public cloud infrastructure model) requires that workloads, users, applications, and sensitive data all be protected by the cloud customer.?CSPM tools?help uncover security weaknesses and remediate them.?CSPM?helps you discover bugs and misconfigurations, understand security and policy violations through threat detection, and fix and patch issues before cyber-attacks can occur.

CSPM solutions work automatically to continuously identify misconfigurations that can lead to data leaks and breaches. Automated detection of misconfigurations enables organizations to regularly make necessary fixes. It provides visibility into public cloud infrastructure, an environment usually abstracted to cloud customers. Using CSPM, organizations can finally locate cloud misconfigurations and apply fixes on time.

Set Up Backup and Recovery Solutions

Although many cloud services guarantee high availability and durability, these features do not protect you from data loss or unwanted changes. To ensure that your data is always recoverable, you should implement a backup and recovery solution. Backup solutions can protect against ransomware infections, accidental or malicious data deletion.

To keep your data accessible and recoverable, consider the following strategies:

·???????? Use incremental backups to conserve storage resources and limit the impact on system performance during backups.?

·???????? Implement the 3-2-1 rule by placing three backup copies in at least two locations, one of them physically distant from where real-time data is stored.

·???????? Infrequently used data, such as compliance data, should be archived to separate, lower cost storage.

Secure Your User Endpoints

Another element of cloud security best practices is securing user endpoints. Most users access the Cloud Service through a web browser. Therefore, it is important to deploy advanced client-side security to keep users’ browsers up-to-date and protect them from attacks.

You should also consider implementing an endpoint security solution to protect end-user devices. Users are increasingly accessing cloud services through non-company-owned devices, requiring a strategy that can accommodate non-managed endpoint devices.

Minimize the Amount of Data in Your Environment

Reducing the amount of data in your environment is a proven way to increase security while narrowing compliance with regulations such as GDPR and CCPA. As data security regulations become more critical, organizations can reduce costs by improving security while narrowing compliance. Data discovery technologies can help organizations reduce the risk and compliance footprint by identifying sensitive data, removing it if not necessary for the organization, and ensuring it is appropriately secured.

·???????? Vulnerability scanning and vulnerability management

·???????? Dynamic threat analysis

Secure cloud native infrastructure?– Automate compliance and security posture of your public cloud IaaS and Kubernetes infrastructure according to best practices. Aqua checks your cloud services, Infrastructure-as-Code templates, and Kubernetes setup against best practices and standards, to ensure the infrastructure you run your applications on is securely configured and in compliance.?

·???????? Cloud Security Posture Management (CSPM)

·???????? Kubernetes Security

Secure cloud native workloads?– protect VM, container and Serverless workloads using granular controls that provide real-time detection and granular response, only blocking the specific processes that violate police. Aqua leverages modern micro-services concepts to enforce immutability of your applications in runtime, establishing zero-trust networking, and detecting and stopping suspicious activities, including zero-day attacks.

·???????? Container security

·???????? VM security

·???????? Serverless security

Secure hybrid cloud infrastructure?– apply cloud native security over hybrid-cloud and multi-cloud deployments, with persistent controls that follow your workloads wherever they run.

I have worked on both Azure & AWS production Environments including the security aspects & Azure Monitoring as well but not on GCP - Google Cloud Production Environment for which I had couple of Training Sessions, Yet i have tried to cover most of the cloud environments which are used nowadays and also eventually Google is a Sinking ship which not many would like to be associated with , Do reach out to me for any support or Query on cloud Security [email protected]

Disclosure & Legal Disclaimer Statement Some of the Content has been taken from Open Internet Sources just for representation purposes.

Anjoum Sirohhi