Search results

Tsippi Dach, Director of Communications at AlgoSec, explores the relationship between NetOps and SecOps and explains why they are the... DevOps The importance of bridging NetOps and SecOps in network management Tsippi Dach 3 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 4/16/21 Published Tsippi Dach, Director of Communications at AlgoSec, explores the relationship between NetOps and SecOps and explains why they are the perfect partnership The IT landscape has changed beyond recognition in the past decade or so. The vast majority of businesses now operate largely in the cloud, which has had a notable impact on their agility and productivity. A recent survey of 1,900 IT and security professionals found that 41 percent or organizations are running more of their workloads in public clouds compared to just one-quarter in 2019. Even businesses that were not digitally mature enough to take full advantage of the cloud will have dramatically altered their strategies in order to support remote working at scale during the COVID-19 pandemic. However, with cloud innovation so high up the boardroom agenda, security is often left lagging behind, creating a vulnerability gap that businesses can little afford in the current heightened risk landscape. The same survey found the leading concern about cloud adoption was network security (58%). Managing organizations’ networks and their security should go hand-in-hand, but, as reflected in the survey, there’s no clear ownership of public cloud security. Responsibility is scattered across SecOps, NOCs and DevOps, and they don’t collaborate in a way that aligns with business interests. We know through experience that this siloed approach hurts security, so what should businesses do about it? How can they bridge the gap between NetOps and SecOps to keep their network assets secure and prevent missteps? Building a case for NetSecOps Today’s digital infrastructure demands the collaboration, perhaps even the convergence, of NetOps and SecOps in order to achieve maximum security and productivity. While the majority of businesses do have open communication channels between the two departments, there is still a large proportion of network and security teams working in isolation. This creates unnecessary friction, which can be problematic for service-based businesses that are trying to deliver the best possible end-user experience. The reality is that NetOps and SecOps share several commonalities. They are both responsible for critical aspects of a business and have to navigate constantly evolving environments, often under extremely restrictive conditions. Agility is particularly important for security teams in order for them to keep pace with emerging technologies, yet deployments are often stalled or abandoned at the implementation phase due to misconfigurations or poor execution. As enterprises continue to deploy software-defined networks and public cloud architecture, security has become even more important to the network team, which is why this convergence needs to happen sooner rather than later. We somehow need to insert the network security element into the NetOps pipeline and seamlessly make it just another step in the process. If we had a way to automatically check whether network connectivity is already enabled as part of the pre-delivery testing phase, that could, at least, save us the heartache of deploying something that will not work. Thankfully, there are tools available that can bring SecOps and NetOps closer together, such as Cisco ACI , Cisco Secure Workload and AlgoSec Security Management Solution . Cisco ACI, for instance, is a tightly coupled policy-driven solution that integrates software and hardware, allowing for greater application agility and data center automation. Cisco Secure Workload (previously known as Tetration), is a micro-segmentation and cloud workload protection platform that offers multi-cloud security based on a zero-trust model. When combined with AlgoSec, Cisco Secure Workload is able to map existing application connectivity and automatically generate and deploy security policies on different network security devices, such as ACI contract, firewalls, routers and cloud security groups. So, while Cisco Secure Workload takes care of enforcing security at each and every endpoint, AlgoSec handles network management. This is NetOps and SecOps convergence in action, allowing for 360-degree oversight of network and security controls for threat detection across entire hybrid and multi-vendor frameworks. While the utopian harmony of NetOps and SecOps may be some way off, using existing tools, processes and platforms to bridge the divide between the two departments can mitigate the ‘silo effect’ resulting in stronger, safer and more resilient operations. We recently hosted a webinar with Doug Hurd from Cisco and Henrik Skovfoged from Conscia discussing how you can bring NetOps and SecOps teams together with Cisco and AlgoSec. You can watch the recorded session here . Schedule a demo Related Articles Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read 5 Multi-Cloud Environments Cloud Security Mar 19, 2023 · 2 min read Convergence didn’t fail, compliance did. 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* Phone number* country* Select country... By submitting this form, I accept AlgoSec's privacy policy Schedule a call

As with all cloud vendors, AWS users share responsibility for securing their infrastructure against risk. Amazon provides the tools you... AWS Security group architecture for AWS: How to overcome security group limits Prof. Avishai Wool 6 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/9/23 Published As with all cloud vendors, AWS users share responsibility for securing their infrastructure against risk. Amazon provides the tools you need to filter traffic, but configuring those tools is up to you. Firewalls are one of the tools you’ll use to filter traffic and secure Virtual Private Cloud (VPC) instances. Instead of using traditional firewalls, Amazon provides users with AWS security groups, which are flexible, stateful firewalls capable of filtering inbound and outbound traffic. However, there are limits to what you can do with AWS security groups. First, they only allow traffic – you can’t configure them to deny traffic. Second, the maximum number of rules you can set for a single group is 60. This isn’t a big issue for an Amazon EC2 instance designed to address inbound traffic. You’ll either want your AWS EC2 to accept ingress from the entire internet or you’ll want to configure access for a few internal IP addresses. But for outbound traffic, 60 rules simply isn’t enough. You’ll use a dozen of them just allowing access to GitHub’s API . Add in a few third-party partners and you’re already well past the limit. Amazon VPC resource limits explained Amazon sets clear limits on the AWS services and resources it makes available to users. In some cases, you can increase these limits by contacting AWS support. These limits are generally assessed on a per-Region basis. Here are some of the limits Amazon places on AWS users: Security group limits 2500 VPC security groups per Region 60 IPv4 rules per security group 60 IPv6 rules per security group 5 security groups per network interface VPC and subnet limits 5 VPCs per Region 200 Subnets per VPC 5 IPv4 CIDR blocks per VPC 5 IPv6 CIDR blocks per VPC Limits to elastic IP addresses and gateways 5 Elastic IP addresses per Region 2 Elastic IP Addresses per public NAT gateway 5 Egress-only internet gateways per Region 5 NAT gateways per Availability Zone One carrier gateway per VPC Prefix list limits 100 prefix lists per Region 1000 versions per prefix list 5000 prefix list references per resource type Network ACL limits 200 Network ACLs per VPC 20 Rules per Network ACL How to manage AWS cloud security group limits effectively Traditional firewalls may have thousands of security rules, including a complex combination of inbound rules and egress filters. Crucially, they can also enforce outbound rules that include denying traffic – something Amazon does not allow regular security groups to do. While AWS offers powerful tools for securing cloud workflows, Amazon VPC users must find ways to overcome these limitations. Fortunately, there are a few things you can do to achieve exactly that. Optimize your VPC security groups. Use Network Access Control Lists to secure assets at the subnet level. Use a domain name filtering system that reduces the number of IP addresses security group rules need to resolve. Optimize your Amazon virtual private cloud configuration Amazon VPC is a virtual network that contains many of the elements you’d expect from a traditional network. It has IP addresses, route tables, subnets, and internet gateways. Unlike a traditional network, you can easily configure many of your VPC environment through a command line interface (CLI). You can establish VPC peering connections, implement identity and access management (IAM) protocols, and configure elastic network interfaces without manually handling any hardware. But first, you need to set up and protect your VPC by setting up and configuring security groups. If you don’t specify a particular group, Amazon EC2 will use the default security group. If you haven’t added new security groups since creating your AWS account, you may only have that one default security group. The first step to optimizing security is expanding the number of security groups you have available. Here’s an example of the code you can use to create a new security group in the AWS console:aws ec2 create-security-group –group-name web-pci-sg –description “allow SSL traffic” –vpc-id vpc-555666777 This creates a new group named web-pci-sg and describes it as a group designed to allow SSL traffic on the network. Remember that security groups don’t support deny rules. Here is the code you would use to add a rule to that group: aws ec2 authorize-security-group-ingress \ –group-name web-pci-sg \ –protocol https \–port 443 \ –cidr This rule specifically allows SSL traffic using the HTTPS protocol to use port 443, which is the standard port for HTTPS traffic. You can use the last argument to specify the cidr block the rule will direct traffic through. This gives you the ability to manage traffic through specific subnets, which is important for the next step. This example focuses on just one type of rule in one context. To take full advantage of the security tools AWS makes available, you’ll want to create custom rules for endpoints, load balancers, nat gateways, and more. Although you’re limited to 60 rules per security group, creating many groups lets you assign hundreds of rules to any particular instance. Security architecture and network ACLs Network Access Control Lists provide AWS users with additional filtering capabilities. Network ACLs are similar to security groups in many ways, but come with a few key differences: Network ACLs can contain deny rules. You can write Network ACL rules to include explicit actions, like blocking particular IP addresses or routing VPN users in a specific way. Network ACLs are enforced at the subnet level. This means they apply to every instance in the subnet, in addition to whatever rules exist at the security group level. As mentioned above, each Network ACL can contain up to 20 rules. However, you can have up to 200 Network ACLs per VPC, which gives you a total of 4000 potential rules. Along with instance-specific security group rules, this offers much more flexibility for setting up robust AWS security architecture. Since Network ACLs can deny traffic, they are a useful tool for managing access to databases and other sensitive assets. For example, you may wish to exclude users who don’t have the appropriate permissions from your Amazon RDS instance. You may also want to filter SSH (Secure Shell) connections coming from unknown sources, or limit connections between different internal instance types. To do this effectively, you need to group these assets under the same subnet and make sure that the appropriate rules are enabled for all of them. You can also write asset-specific rules at the security group level, ensuring every asset has its own optimal configuration. The larger your AWS environment is, the more complex this process may become. Take care to avoid misconfigurations – it’s very easy to accidentally write security group rules and Network ACL rules that aren’t compatible, or that cause problems when you access the instance. To avoid this, try to condense your rules as much as possible. Avoid limits by filtering domain names directly Although you can create a large number of rules by creating additional security groups, you still may want to add more than 60 rules in a single group. There are many scenarios where this makes more sense than arbitrarily adding (and managing) new groups. For example, you might have a production instance that needs updates from several third-party partners. You also need to periodically change and update the technologies this instance relies on, so you’d like to keep its rules in a single security group. This reduces misconfiguration risk by keeping all the relevant rules in one place – not spread out across multiple groups. To overcome this limit, you need to reduce the number of IP addresses that the security group filters. You can do this by deploying a third-party solution that allows security rules to perform DNS resolution. This eliminates the need for AWS to resolve the domain name. Since AWS security groups can’t compute domain names on their own, you’ll need to deploy a third-party NAT gateway on your public VPC to filter outbound traffic in this way. Once you do this, you can write rules that filter outgoing connections based on their domain name. This effectively bypasses the 60 IP limit because you are not referring to specific IP addresses. At the same time, it simplifies management and makes rules much easier to read and understand. Instead of looking up and adding all of Github’s API IP addresses, you can write rules that reference the domain “Github.com”. If Github decides to change its IP infrastructure, your security rules will automatically reference the new addresses – you won’t have to go back and update them. The earlier you address AWS security group limits, the better There is an unlimited number of ways you can arrange your security groups and Network ACLs. Even in a small environment, the prospect may seem daunting. However, the flexibility Amazon provides to its cloud users is a valuable security feature. Those who go the process enjoy clear security performance benefits. If you start to planning for the architecture of your security and filtering policies early, you’ll be better equipped to scale those policies upwards as your organization grows. This will prevent security processes from becoming a growth bottleneck and maintain a high level of efficiency even as those policies become larger and more complex. See me explain this issue in person in my new whiteboard video: Schedule a demo Related Articles Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read 5 Multi-Cloud Environments Cloud Security Mar 19, 2023 · 2 min read Convergence didn’t fail, compliance did. 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* Phone number* country* Select country... By submitting this form, I accept AlgoSec's privacy policy Schedule a call

Learn about firewall rule automation and change management to streamline processes, reduce human error, and enhance network security with effective change controls. Firewall rule automation & change management explained ------- ---- Select a size ----- Get the latest insights from the experts Choose a better way to manage your network

Learn how to move applications to the cloud seamlessly. Explore best practices for cloud migration, minimizing downtime, and optimizing your cloud environment Cloud migration: How to move applications to the cloud Responsiveness to the ever-growing demand coming from the business is redefining IT processes and technologies. One way IT can improve responsiveness and business agility is by moving business applications to the cloud. In the cloud, businesses increase their agility while reducing costs. But in the process of migrating applications to the cloud, network security is often neglected. When this happens, applications are deployed in the cloud with inadequate security and compliance measures, or, conversely, the security team steps in and halts the migration process. This puts the company at risk. On the one hand, inadequate security makes it easier for hackers to access the network and mount an attack against the company – exposing the company to financial losses and legal repercussions. On the other hand, if the business is unable to respond to market demands in a timely fashion, there are clear financial implications. In this paper, we take a deep dive into the process that enterprise organizations take when approaching a migration project. We look at the challenges associated with migration projects and discuss a systematic process that organizations should embrace when approaching these types of projects. Introduction There are multiple advantages to adopting a cloud architecture and migrating applications to it, but there are also security concerns that need to be taken into consideration. Below are the top four advantages and the security challenge that accompanies each. Security and data protection When adopting public cloud computing, data itself is much more accessible, no matter where it is located. Users can access the data they need from any location and device. An additional benefit relates to disaster recovery processes that include out-of-the-box backup and restore functionality. In the cloud, there is a need to maintain additional servers in a remote location. However, these advantages do not come without a cost. Once the data is no longer kept on-premises, security must be tightened. The closed garden we had when data resided on servers protected by firewalls in our facilities, is gone. Additional security controls must be employed. Special consideration should be given to upholding regulatory requirements regarding the data itself. There are best practices to uphold, as well as financial penalties if organizations do not comply with them. Business agility Spinning up a server in the cloud is a matter of minutes. Cloud computing is considered an enabler for digital transformation, as businesses work to be more agile and accommodating to their customers’ needs. All you need is a credit card. No hardware is required to be purchased, shipped or connected to your data center. The ease of spinning up a new cloud server makes shadow IT possible. But this is also a security problem. It is hard to control the security aspect of each cloud server if you are unaware of it. Therefore, visibility and strong prefrail security measures such as identity management and cloud firewalls that protect access from the internet, are needed. For each cloud server, you need to set an allowed connectivity baseline and incorporate it into the sever creation process. Financial benefits The cloud offers zero maintenance costs and zero capital costs. Additional financial gains should be taken into consideration such as the reduction in IT support costs and the flexibility offered by cloud server usage of paying only for what you consume. This means you don’t have to purchase expensive hardware needed during peak times only. Of course, there are also hidden costs when migrating to the cloud. Usage needs to be monitored and optimized and your cloud assets need to be monitored and maintained. Additional security measures need to be put in place. This includes purchasing additional software as well as hiring additional personnel proficient in securing a cloud architecture. Faster time to market The cloud, coupled with DevOps practices and tools, delivers a flexible framework that enables companies to deliver innovations faster to market. However, there are lingering questions about the impact on security. With multiple functional teams collaborating on development, and so many moving parts in the process, security is often not incorporated into the release process. Rather it’s tacked on at the end. And this is where you need a security policy automation that supports the DevOps methodology. The solution needs to be able to automatically copy the firewall rules and then make the necessary modifications to map rules to the new objects – for each new environment in the DevOps lifecycle. With the right automation solution, security can be baked into the release process. Get a Demo Advantages and security challenges of the cloud Public cloud security is the responsibility of both the cloud vendor and cloud customers. This joint ownership of security is often called the shared responsibility model. On one side you have security of the cloud infrastructure itself. Security OF the cloud The cloud vendor is responsible for securing the infrastructure that runs all the services offered in the cloud. This includes both software-related services such as compute, storage, database, and networking as well as hardware services. The cloud vendor is also responsible for securing the physical facilities themselves. On the other side, you have security within the cloud accounts. Security IN the cloud Cloud customers are responsible for the security of the services they consume. For example, when using Amazon Elastic Compute Cloud (Amazon EC2) the customer needs to perform all the necessary security configuration and management tasks. Any software or utility that the customer installs should be followed by configuring all relevant security controls, including security groups, third-party firewalls and other necessary security configurations. Cloud customers are responsible for managing and securing the data that resides in the consumed cloud service. Figure 1: Shared responsibility model The shared responsibility model Data center network security is already quite complex. Customers generally utilize multiple vendors to manage their network security, including SDNs, such as Cisco ACI and VMWare NSX. Adding cloud network security controls to the mix raises the complexity up several notches. Cloud network security consists of multi-layered security controls. You have the cloud vendor infrastructure controls spanning across asset types, such as instances, databases, storage, and accounts; and across configuration types, such as deployment location, security groups, and more. You also have cloud providers’ security products, such as Azure Firewall and AWS WAF. And on top all of that, third-party vendors have not left the cloud network security controls ring and are providing dedicated firewalls for the cloud, such as CloudGuard by Check Point, V-Series by Palo Alto Networks and more. When migrating an application to the cloud it is important to determine how you are going to guard your cloud assets. What mix of security controls are you going to utilize to secure your data? Cloud network security controls Gain visibility into which applications your organization has Obtaining an inventory of applications is the foundation of your security and essential for your cloud migration. The process of discovering all the applications used by your business is not a trivial task. Most businesses have two types of applications – enterprise and departmental. Enterprise applications, which are the more complex applications in your data center, usually serve many business units and can span multiple geographies and even company subsidiaries. In most cases, the IT team is well-aware of them. While documentation of these applications and their connectivity requirements may not be perfect, that is a good starting point for the migration process. Note that there may still be a need to update the documentation. Many departments or business units purchase their department applications such as Business Intelligence solutions or project management tools. Some of these applications may be SaaS while others are installed on corporate servers. For these types of applications, it is likely that documentation never existed. Fortunately, in most cases, their architecture isn’t complex. It should be relatively easy to obtain the necessary connectivity information needed to migrate them to the cloud. The key here is to know that these applications exist. There are two ways to generate a list of applications. The first requires using consultants to conduct thorough interviews with the various stakeholders in each department and each geography. A second, more cost-effective and efficient way, is to use visibility and automation solutions such as AlgoSec’s AppViz and AppChange. Tools like AlgoSec’s AppViz help discover, identify, and map business applications on your network. Once the list of applications – the foundation – is in place, you can move onto the next stage in the process of closing the security gap as you migrate to the cloud: understanding each application’s attributes, such as the number of servers, the associated business processes and the network connectivity requirements. These attributes help determine the complexity involved in migrating applications. Gain visibility into your current network and its security elements Several attributes can affect the complexity of migrating an application to the cloud, including the application’s network connectivity requirements and the firewall rules that allow/deny that connectivity. A mapping of the network connectivity yields a deeper understanding of network traffic complexity which, in turn, provides insight into the flows you will need to migrate and maintain with the application in the cloud (see Figure 2). Additionally, this information will tell you how many applications are dependent on a specific server. The more applications a server serves, the harder it is to migrate one of them. It may be necessary to migrate the server itself or to migrate multiple applications at the same time. Mapping the firewall rules provides insight into the security measures you will need to put in place once the application has been migrated to the cloud. As a rule of thumb, the more firewall rules are required, the greater the complexity. A mapping of the firewall rules enables you to identify and decommission firewall rules that are no longer necessary post-migration. How do you generate documentation of application connectivity? The obvious choice is to employ a solution that automatically maps the various network traffic flows, servers and firewall rules for each application. If you do not have access to such an automation solution, then manual documenting, however tedious, will provide the necessary information. Visibility into what you have is key for cloud migration Applications that store data about personal information When an application holds sensitive data such as personal information it is worth thinking twice before moving it to the cloud. In most cases, data privacy laws mandate where personal data should be stored, and when the information can be collected, processed, or communicated. Over 80 countries and territories have adopted comprehensive data protection laws. Most of Europe has already adopted comprehensive data protection laws such as GDPR. Many Latin American, Asian, and African countries have done so as well. Many US states also have data protection regulations such as the California Consumer Privacy Act and the New York SHIELD Act. It is worthwhile checking what is legally allowed before moving such an application to a cloud, as well as considering the cloud’s geographical location. Highly-regulated applications An additional issue to look out for is whether the application is subject to regulatory requirements such as HIPPA or requires PCI DSS compliance. If the answer is yes, you must find out the security compliance status of that application and whether moving it to the cloud would violate that status. HIPPA, for example, requires accountability practices on all LANs, WANs, and for users accessing the network remotely through a Virtual Private Network (VPN). PCI compliance requires, for example, a firewall at each internet connection and between any DMZ and the internal network zone. Applications subject to these and similar regulations are not the best candidates, to say the least, for migration to the cloud. Applications already exposed to the internet On the other hand, if an application has elements that are already exposed to the internet, such as the web server in Figure 2 below, that’s a good indication that maybe some of it, if not all, can be moved to the cloud for the elasticity and cost savings gain. For these applications, you have most probably already implemented strong security inside the application server, backed with strong security limitations in front of and behind the web-facing interface. Adopting these strong limitations also when moving the workload to the cloud will ensure the security of the server and of the internal network behind it. Using network segmentation as a guide Finally, if you manage your network segmentation correctly, the servers and applications that reside in the less isolated zones are the best candidates for moving to the more open cloud. For example, applications and servers in a zone with only one firewall that acts as a barrier between the zone and the internet are good candidates for migration. Whereas entities in protected zones such as server group 1 in Figure 2, which reside behind several firewalls, should remain in your on-premise data center. Figure 2: Network segmentation Which applications should I move first? Whether you move all your applications to the cloud or just a few of them, and whether you use one or multiple cloud vendors, you now need to manage and maintain security and compliance in the cloud just as you did in your on-premise network over which you have complete control. Establishing a route from a server in the cloud to a server on the on-premise network requires an intimate understanding of both the cloud security controls and the on-premise security devices. If there are separate cloud and on-premise network security teams, as is the norm in many businesses, collaboration between the teams is needed which, of course, adds its own complexity. Once applications are deployed in the cloud, you will likely want to be able to move between cloud providers ‘at the speed of the cloud’ to avoid vendor lock-in and to minimize costs. While you might be led to believe that this is a simple requirement, in reality each cloud provider has its own unique network security controls with which you need to familiarize yourself. There are several ways to manage security across the hybrid cloud environment. You can manage the environment manually, which is slow, time-consuming, and error-prone. You can use the cloud provider’s native controls to manage the cloud network security in addition to the existing tools and methodology you currently use for your on-premise environment. However, bear in mind that cloud security controls do not provide a holistic view of security across your entire estate and their limited capabilities may not sufficiently support your business’s security posture. Alternatively, there are third party automated network security policy management solutions that span the entire hybrid environment, which can assist in managing your entire network security. Migration is only the beginning The AlgoSec platform makes it easy to support your cloud migration journey, ensuring that migration does not block critical business services while meeting compliance requirements. AlgoSec’s powerful Application Discovery capabilities help you understand the network flows in your organization. You can effectively connect the recognized traffic flows to the business applications that use them. AlgoSec manages the network security policy across your hybrid network estate and proactively checks every proposed firewall rule change request against your network security strategy to ensure that the change doesn’t introduce risk or violate compliance requirements. Migrate with AlgoSec AlgoSec, a global cybersecurity leader, empowers organizations to secure application connectivity and cloud-native applications throughout their multi-cloud and hybrid network. Trusted by more than 1,800 of the world’s leading organizations, AlgoSec’s application-centric approach enables to securely accelerate business application deployment by centrally managing application connectivity and security policies across the public clouds, private clouds, containers, and on-premises networks. Using its unique vendor-agnostic deep algorithm for intelligent change management automation, AlgoSec enables acceleration of digital transformation projects, helps prevent business application downtime and substantially reduces manual work and exposure to security risks. AlgoSec’s policy management and CNAPP platforms provide a single source for visibility into security and compliance issues within cloud-native applications as well as across the hybrid network environment, to ensure ongoing adherence to internet security standards, industry, and internal regulations. Learn how AlgoSec enables application owners, information security experts, DevSecOps and cloud security teams to deploy business applications up to 10 times faster while maintaining security at www.algosec.com . Let's start your journey to our business-centric network security. About AlgoSec Select a size Introduction Advantages and security challenges of the cloud The shared responsibility model Cloud network security controls Visibility into what you have is key for cloud migration Which applications should I move first? Migration is only the beginning Migrate with AlgoSec About AlgoSec Get the latest insights from the experts Choose a better way to manage your network

Partner solution brief AlgoSec and Illumio: stronger together Download PDF Schedule time with one of our experts Schedule time with one of our experts Work email* First name* Last name* Company* country* Select country... phone By submitting this form, I accept AlgoSec's privacy policy Continue

Executive brochure – The business benefits of AlgoSec Horizon platform Brochure Download PDF Schedule time with one of our experts Schedule time with one of our experts Work email* First name* Last name* Company* country* Select country... phone By submitting this form, I accept AlgoSec's privacy policy Continue

Learn best practices for effective network firewall security management. Enhance your security posture with proper configuration, monitoring, and maintenance. Network firewall security management ------- ---- Select a size ----- Get the latest insights from the experts Firewall rule recertification - An application-centric approach Watch webinar Firewalls ablaze? Put out network security audit & compliance fires Watch webinar Firewall rule recertification Read document Choose a better way to manage your network

Containers aren’t VMs. They’re a great lightweight deployment solution, but they’re only as secure as you make them. You need to keep... Cloud Security Best Practices for Docker Containers’ Security Rony Moshkovich 3 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 7/27/20 Published Containers aren’t VMs. They’re a great lightweight deployment solution, but they’re only as secure as you make them. You need to keep them in processes with limited capabilities, granting them only what they need. A process that has unlimited power, or one that can escalate its way there, can do unlimited damage if it’s compromised. Sound security practices will reduce the consequences of security incidents. Don’t grant absolute power It may seem too obvious to say, but never run a container as root. If your application must have quasi-root privileges, you can place the account within a user namespace , making it the root for the container but not the host machine. Also, don’t use the –privileged flag unless there’s a compelling reason. It’s one thing if the container does direct I/O on an embedded system, but normal application software should never need it. Containers should run under an owner that has access to its own resources but not to other accounts. If a third-party image requires the –privileged flag without an obvious reason, there’s a good chance it’s badly designed if not malicious. Avoid running a Docker socket in a container. It gives the process access to the Docker daemon, which is a useful but dangerous power. It includes the ability to control other containers, images, and volumes. If this kind of capability is necessary, it’s better to go through a proper API. Grant privileges as needed Applying the principle of least privilege minimizes container risks. A good approach is to drop all capabilities using –cap-drop=all and then enabling the ones that are needed with –cap-add . Each capability expands the attack surface between the container and its environment. Many workloads don’t need any added capabilities at all. The no-new-privileges flag under security-opt is another way to protect against privilege escalation. Dropping all capabilities does the same thing, so you don’t need both. Limiting the system resources which a container guards not only against runaway processes but against container-based DoS attacks. Beware of dubious images When possible, use official Docker images. They’re well documented and tested for security issues, and images are available for many common situations. Be wary of backdoored images . Someone put 17 malicious container images on Docker Hub, and they were downloaded over 5 million times before being removed. Some of them engaged in cryptomining on their hosts, wasting many processor cycles while generating $90,000 in Monero for the images’ creator. Other images may leak confidential data to an outside server. Many containerized environments are undoubtedly still running them. You should treat Docker images with the same caution you’d treat code libraries, CMS plugins, and other supporting software, Use only code that comes from a trustworthy source and is delivered through a reputable channel. Other considerations It should go without saying, but you need to rebuild your images regularly. The libraries and dependencies that they use get security patches from time to time, and you need to make sure your containers have them applied. On Linux, you can gain additional protection from security profiles such as secomp and AppArmor . These modules, used with the security-opt settings, let you set policies that will be automatically enforced. Container security presents its distinctive challenges. Experience with traditional application security helps in many ways, but Docker requires an additional set of practices. Still, the basics apply as much as ever. Start with trusted code. Don’t give it the power to do more than it needs to do. Use the available OS and Docker features for enhancing security. Monitor your systems for anomalous behavior. If you take all these steps, you’ll ward off the large majority of threats to your Docker environment. Schedule a demo Related Articles Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read 5 Multi-Cloud Environments Cloud Security Mar 19, 2023 · 2 min read Convergence didn’t fail, compliance did. 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* Phone number* country* Select country... By submitting this form, I accept AlgoSec's privacy policy Schedule a call

Level Up Your Security Game: Time for a Mindset Reset! Hey everyone, and welcome! If you're involved in keeping your organization safe... 5 mindset shifts security teams must adopt to master multi-cloud security 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 4/9/25 Published Level Up Your Security Game: Time for a Mindset Reset! Hey everyone, and welcome! If you're involved in keeping your organization safe online these days, you're in the right place. For years, security felt like building a super strong castle with thick walls and a deep moat, hoping the bad guys would just stay outside. But let's be real, in our multi-cloud world, that castle is starting to look a little... outdated. Think about it: your apps and data aren't neatly tucked away in one place anymore. They're bouncing around on AWS, Azure, GCP, all sorts of platforms – practically everywhere! Trying to handle that with old-school security is like trying to catch smoke with a fishing net. Not gonna work, right? That's why we're chatting today. Gal Yosef, Head of Product Management in the U.S., gets it. He's helped us dive into some crucial mindset shifts – basically, new ways of thinking – that are essential for navigating the craziness of modern security. We gotta ditch the old ways and get ready to be more agile, work together better, and ultimately, be way more effective. Mindset Shift #1: From "Our Stuff is Safe Inside This Box" to "Trust Nothing, Verify Everything" Remember the good old days? We built a perimeter – firewalls, VPNs – thinking that everything inside was safe and sound (danger!). Security was all about guarding that edge. The Problem: Well, guess what? That world is gone! Multi-cloud environments have totally shattered that perimeter. Trying to just secure the network edge leaves your real treasures – your applications, users, and data – vulnerable as they roam across different clouds. It's like locking the front door but leaving all the windows wide open! The New Way: Distributed Trust. Security needs to follow your assets, wherever they go. Instead of just focusing on the infrastructure (the pipes and wires), we need to embrace Zero-Trust principles . Think of it like this: never assume anyone or anything is trustworthy, even if they're "inside." We need identity-based, adaptive security policies that constantly validate trust, rather than just assuming it based on location. Security becomes built into applications and workloads, not just bolted onto the network. Think of it this way: Instead of one big, guarded gate, you have individual, smart locks on every valuable asset. You're constantly checking who's accessing what, no matter where they are. It's like having a personal bodyguard for each of your important things, always making sure they have the right ID. Mindset Shift #2: From "My Team Handles Network Security, Their Team Handles Cloud Security" to "Let's All Be Security Buddies!" Ever feel like your network security team speaks a different language than your cloud security team? You're not alone! Traditionally, these have been separate worlds, with network teams focused on firewalls and cloud teams on security groups. The Problem: These separate silos are a recipe for confusion and fragmented security policies. Attackers? They love this! It's like having cracks in your armor. They aren't always going to bash down the front door; they're often slipping through the gaps created by this lack of communication. The New Way: Cross-functional collaboration. We need to tear down those walls! Network and cloud security teams need to work together, speaking a shared security language. Unified visibility and consistent policies across all your environments are key. Think of it like a superhero team – everyone has their own skills, but they work together seamlessly to fight the bad guys. Regular communication, shared tools, and a common understanding of the risks are crucial. Mindset Shift #3: From "Reacting When Something Breaks" to "Always Watching and Fixing Things Before They Do" Remember the old days of waiting for an alert to pop up saying something was wrong? That's like waiting for your car to break down before you even think about checking the oil. Not the smartest move, right? The Problem: In the fast-paced world of the cloud, waiting for things to go wrong is a recipe for disaster. Attacks can happen super quickly, and by the time you react, the damage might already be done. Plus, manually checking everything all the time? Forget about it – it's just not scalable when you've got stuff spread across multiple clouds. The New Way: Continuous & Automated Enforcement. We need to shift to a mindset of constant monitoring and automated security actions. Think of it like having a security system that's always on, always learning, and can automatically respond to threats in real-time. This means using tools and processes that continuously check for vulnerabilities, enforce security policies automatically, and even predict potential problems before they happen. It's like having a proactive security guard who not only watches for trouble but can also automatically lock doors and sound alarms the moment something looks fishy. Mindset Shift #4: From "Locking Everything Down Tight" to "Finding the Right Balance with Flexible Rules" We used to think the best security was the strictest security – lock everything down, say "no" to everything. But let's be honest, that can make it super hard for people to actually do their jobs! It's like putting so many locks on a door that nobody can actually get through it. The Problem: Overly restrictive security can stifle innovation and slow things down. Developers can get frustrated, and the business can't move as quickly as it needs to. Plus, sometimes those super strict rules can even create workarounds that actually make things less secure in the long run. The New Way: Flexible Guardrails. We need to move towards security that provides clear boundaries (the "guardrails") but also allows for agility and flexibility. Think of it like setting clear traffic laws – you know what's allowed and what's not, but you can still drive where you need to go. This means defining security policies that are adaptable to different cloud environments and business needs. It's about enabling secure innovation, not blocking it. We need to find that sweet spot where security empowers the business instead of hindering it. Mindset Shift #5: From "Security is a Cost Center" to "Security is a Business Enabler" Sometimes, security gets seen as just an expense, something we have to do but doesn't really add value. It's like thinking of insurance as just another bill. The Problem: When security is viewed as just a cost, it often gets underfunded or seen as a roadblock. This can lead to cutting corners and ultimately increasing risk. It's like trying to save money by neglecting the brakes on your car – it might seem cheaper in the short term, but it can have disastrous consequences later. The New Way: Security as a Business Enabler. We need to flip this thinking! Strong security isn't just about preventing bad things from happening; it's about building trust with customers, enabling new business opportunities, and ensuring the long-term resilience of the organization. Think of it like a strong foundation for a building – without it, you can't build anything lasting. By building security into our processes and products from the start, we can actually accelerate innovation and gain a competitive advantage. It's about showing our customers that we take their data seriously and that they can trust us. Wrapping Up: Moving to a multi-cloud world is exciting, but it definitely throws some curveballs at how we think about security. By adopting these five new mindsets, we can ditch the outdated castle mentality and build a more agile, collaborative, and ultimately more secure future for our organizations. It's not about being perfect overnight, but about starting to shift our thinking and embracing these new approaches. So, let's level up our security game together! Schedule a demo Related Articles Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read 5 Multi-Cloud Environments Cloud Security Mar 19, 2023 · 2 min read Convergence didn’t fail, compliance did. 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* Phone number* country* Select country... By submitting this form, I accept AlgoSec's privacy policy Schedule a call

Explore Algosec's customer success stories to see how organizations worldwide improve security, compliance, and efficiency with our solutions. Leading payment solutions company credits AlgoSec for increasing security and compliance Organization Payment Solutions Industry Financial Services Headquarters Download case study Share Customer
success stories "Leading fintech company rapidly improves security and compliance with AlgoSec jumpstart program" Background The company is one of the largest payment solutions providers, with offices processing more than 28 billion transactions worldwide. The company services 800,000 merchant outlets that generate $120 billion in processing volume. Its businesses include credit card processing, merchant acquisition and issuance of bank credit cards. The company grew to its enormous size through innovation and acquisition. It has introduced modern technology into the payments industry and has acquired many innovative companies over the last three decades. Challenges Today, the company operates 10 data centers with varying security architectures and firewall equipment from different vendors. The security staff is currently in the process of a cross-company firewall consolidation that will take several years to complete. The company is automating its change management of firewall rules to cut down on the time and effort spent on researching and implementing rules to keep up with its fast growth. It deploys rule changes during tight, scheduled “push windows” and conducts compliance reviews twice per year. The firewall change process is highly complex with many steps: Request Design Peer Review Management Approval Implementation Validation Success for the security team is all about time. They seek to automate the process by reducing time spent on: Research and writing rules Peer reviews Staging Security peering after staging Firewall push window requirements Quarterly firewall ruleset reviews as part of compliance objectives Solution The security team acquired AlgoSec Firewall Analyzer (AFA) and deployed it at two of its data centers in Arizona and Colorado. In both locations, the company is in the process of firewall migration to consolidate on one vendor. However, they need to add firewall clusters one at a time after each migration instead of all at once. The company took advantage of AlgoSec’s Jumpstart Program that delivers the benefits of AlgoSec Firewall Analyzer in conjunction with other AlgoSec solutions quickly. With Jumpstart, the company is quickly able to: Automate the discovery and mapping of enterprise applications Automate the change management processes Adopt the new processes across the company Realize rapid ROI The company’s lead security infrastructure consultant proclaimed, “AlgoSec customized their Jumpstart Program just for us. Their people are engaged, personable, skilled and highly efficient. They became part of our team dedicated to our success.” In addition to getting Firewall Analyzer up and running quickly and delivering its benefits, the Jumpstart team’s AFA deployment immediately identified network security gaps and helped the company close them, making them more secure and compliant. Results AlgoSec Firewall Analyzer is achieving all the goals of the security team. Time for policy writing reduced from 90 hours to 15 hours – 83% less Cut the total process time by half, enabling the security team to keep up with the barrage of change requests. Reduced the admin overhead from 30 to 4 – 87% less “Automation is definitely the way to go,” declared their security consultant. “We can now stay on top of the process even while we migrate our firewalls. We are looking for more from AlgoSec.” The company is now in the process of implementing AlgoSec FireFlow (AFF) to enhance the existing change management system with intelligent network and security automation. AlgoSec FireFlow enforces compliance and automatically documents the entire change-management lifecycle. Some of the features include: Processing of firewall changes with zero-touch automation Elimination of mistakes and rework, and improvement of accountability for change requests Proactive assessment of the impact of network changes to ensure security and continuous compliance Automation of the rule–recertification processes Schedule time with one of our experts

Firewalls are one of the most important cybersecurity solutions in the enterprise tech stack. They can also be the most demanding.... Firewall Change Management 20 Firewall Management Best Practices for Network Security Asher Benbenisty 8 min read Asher Benbenisty 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 10/29/23 Published Firewalls are one of the most important cybersecurity solutions in the enterprise tech stack. They can also be the most demanding. Firewall management is one of the most time-consuming tasks that security teams and network administrators regularly perform. The more complex and time-consuming a task is, the easier it is for mistakes to creep in. Few organizations have established secure network workflows that include comprehensive firewall change management plans and standardized firewall best practices. This makes implementing policy changes and optimizing firewall performance riskier than it needs to be. According to the 2023 Verizon Data Breach Investigation Report, security misconfigurations are responsible for one out of every ten data breaches. ( * ) This includes everything from undetected exceptions in the firewall rule base to outright policy violations by IT security teams. It includes bad firewall configuration changes, routing issues, and non-compliance with access control policies. Security management leaders need to pay close attention to the way their teams update firewall rules, manipulate firewall logs, and establish audit trails. Organizations that clean up their firewall management policies will be better equipped to automate policy enforcement, troubleshooting, and firewall migration. 20 Firewall Management Best Practices Right Now 1. Understand how you arrived at your current firewall policies: Most security leaders inherit someone else’s cybersecurity tech stack the moment they accept the job. One of the first challenges is discovering the network and cataloging connected assets. Instead of simply mapping network architecture and cataloging assets, go deeper. Try to understand the reasoning behind the current rule set. What cyber threats and vulnerabilities was the organization’s previous security leader preparing for? What has changed since then? 2. Implement multiple firewall layers: Layer your defenses by using multiple types of firewalls to create a robust security posture. Configure firewalls to address specific malware risks and cyberattacks according to the risk profile of individual private networks and subnetworks in your environment. This might require adding new firewall solutions, or adding new rules to existing ones. You may need to deploy and manage perimeter, internal, and application-level firewalls separately, and centralize control over them using a firewall management tool. 3. Regularly update firewall rules: Review and update firewall rules regularly to ensure they align with your organization’s needs. Remove outdated or unnecessary rules to reduce potential attack surfaces. Pay special attention to areas where firewall rules may overlap. Certain apps and interfaces may be protected by multiple firewalls with conflicting rules. At best, this reduces the efficiency of your firewall fleet. At worst, it can introduce security vulnerabilities that enable attackers to bypass firewall rules. 4. Apply the principle of least privilege: Apply the principle of least privilege when creating firewall rules . Only grant access to resources that are necessary for specific roles or functions. Remember to remove access from users who no longer need it. This is difficult to achieve with simple firewall tools. You may need policies that can follow users and network assets even as their IP addresses change. Next-generation firewalls are capable of enforcing identity-based policies like this. If your organization’s firewall configuration is managed by an outside firm, that doesn’t mean it automatically applies this principle correctly. Take time to review your policies and ensure no users have unjustified access to critical network resources. . 5. Use network segmentation to build a multi-layered defense: Use network segmentation to isolate different parts of your network. This will make it easier to build and enforce policies that apply the principle of least privilege. If attackers compromise one segment of the network, you can easily isolate that segment and keep the rest secure. Pay close attention to the inbound and outbound traffic flows. Some network segments need to accept flows going in both directions, but many do not. Properly segmented networks deny network traffic traveling along unnecessary routes. You may even decide to build two entirely separate networks – one for normal operations and one for management purposes. If the networks are served by different ISPs, an attack against one may not lead to an attack against the other. Administrators may be able to use the other network to thwart an active cyberattack. 6. Log and monitor firewall activity: Enable firewall logging and regularly review logs for suspicious activities. Implement automated alerts for critical events. Make sure you store firewall logs in an accessible low-cost storage space while still retaining easy access to them when needed. You should be able to pull records like source IP addresses on an as-needed basis. Consider implementing a more comprehensive security information and event management (SIEM) platform. This allows you to capture and analyze log data from throughout your organization in a single place. Analysts can detect and respond to threats more effectively in a SIEM-enabled environment. Consider enabling logging on all permit/deny rules. This will provide you with evidence of network intrusion and help with troubleshooting. It also allows you to use automated tools to optimize firewall configuration based on historical traffic. 7. Regularly test and audit firewall performance: Conduct regular security assessments and penetration tests to identify vulnerabilities. Perform security audits to ensure firewall configurations are in compliance with your organization’s policies. Make sure to preview the results of any changes you plan on making to your organization’s firewall rules. This can be a very complex and time-consuming task. Growing organizations will quickly run out of time and resources to effectively test firewall configuration changes over time. Consider using a firewall change management platform to automate the process. 8. Patch and update firewall software frequently: Keep firewall firmware and software up to date with security patches. Vulnerabilities in outdated software can be exploited, and many hackers actively read update changelogs looking for new exploits. Even a few days’ delay can be enough for enterprising cybercriminals to launch an attack. Like most software updates, firewall updates may cause compatibility issues. Consider implementing a firewall management tool that allows you to preview changes and proactively troubleshoot compatibility issues before downloading updates. 9. Make sure you have a reliable backup configuration: Regularly backup firewall configurations. This ensures you can quickly restore settings in case of a failure or compromise. If attackers exploit a vulnerability that allows them to disable your firewall system, restoring an earlier version may be the fastest way to remediate the attack. When scheduling backups, pay special attention to Recovery Point Objectives (RPO) and Recovery Time Objectives (RTO). RPO is the amount of time you can afford to let pass between backups. RTO is the amount of time it takes to fully restore the compromised system. 10. Deploy a structured change management process: Implement a rigorous change management process for firewall rule modifications. Instead of allowing network administrators and IT security teams to enact ad-hoc changes, establish a proper approval process that includes documenting all changes implemented. This can slow down the process of implementing firewall policy changes and enforcing new rules. However, it makes it much easier to analyze firewall performance over time and generate audit trails after attacks occur. Organizations that automate the process can enjoy both well-documented changes and rapid implementation. 11. Implement intrusion detection and prevention systems (IDPS): Use IDPS in conjunction with firewalls to detect and prevent suspicious or malicious traffic. IDPS works in conjunction with properly configured firewalls to improve enterprise-wide security and enable security teams to detect malicious behavior. Some NGFW solutions include built-in intrusion and detection features as part of their advanced firewall technology. This gives security leaders the ability to leverage both prevention and detection-based security from a single device. 12. Invest in user training and awareness: Train employees on safe browsing habits and educate them about the importance of firewall security. Make sure they understand the cyber threats that firewalls are designed to keep out, and how firewall rules contribute to their own security and safety. Most firewalls can’t prevent attacks that exploit employee negligence. Use firewall training to cultivate a security-oriented office culture that keeps employees vigilant against identity theft , phishing attacks, social engineering, and other cyberattack vectors. Encourage employees to report unusual behavior to IT security team members even if they don’t suspect an attack is underway. 13. Configure firewalls for redundancy and high availability: Design your network with redundancy and failover mechanisms to ensure continuous protection in case of hardware or software failures. Multiple firewalls can work together to seamlessly take over when one goes offline, making it much harder for attackers to capitalize on firewall downtime. Designate high availability firewalls – or firewall clusters – to handle high volume traffic subject to a wide range of security threats. Public-facing servers handling high amounts of inbound traffic typically need extra protection compared to internal assets. Rule-based traffic counters can provide valuable insight into which rules activate the most often. This can help prioritize the most important rules in high-volume usage scenarios. 14. Develop a comprehensive incident response plan: Develop and regularly update an incident response plan that includes firewall-specific procedures for handling security incidents. Plan for multiple different scenarios and run drills to make sure your team is prepared to respond to the real thing when it comes. Consider using security orchestration, automation, and response (SOAR) solutions to create and run automatic incident response playbooks. These playbooks can execute with a single click, instantly engaging additional protections in response to security threats when detected. Be ready for employees and leaders to scrutinize firewall deployments when incidents occur. It’s not always clear whether the source of the issue was the firewall or not. Get ahead of the problem by using a packet analyzer to find out if firewall misconfiguration led to the incident or not early on. 15. Stay ahead of compliance and security regulations: Stay compliant with relevant industry regulations and standards, such as GDPR , HIPAA, or PCI DSS , which may have specific firewall requirements. Be aware of changes and updates to regulatory compliance needs. In an acquisition-oriented enterprise environment, managing compliance can be very difficult. Consider implementing a firewall management platform that provides a centralized view of your entire network environment so you can quickly identify underprotected networks. 16. Don’t forget about documentation: Maintain detailed documentation of firewall configurations, network diagrams, and security policies for reference and auditing purposes. Keep these documents up-to-date so that new and existing team members can use them for reference whenever they need to interact with the organization’s firewall solutions. Network administrators and IT security team members aren’t always the most conscientious documentation creators. Consider automating the process and designating a special role for maintaining and updating firewall documentation throughout the organization. 17. Regularly review and improve firewall performance: Continuously evaluate and improve your firewall management practices based on evolving threats and changing business needs. Formalize an approach to reviewing, updating, and enforcing new rules using data gathered by your current deployment. This process requires the ability to preview policy changes and create complex “what-if” scenarios. Without a powerful firewall change management platform in place, manually conducting this research may be very difficult. Consider using automation to optimize firewall performance over time. 18. Deploy comprehensive backup connectivity: In case of a network failure, ensure there’s a backup connectivity plan in place to maintain essential services. Make sure the plan includes business continuity solutions for mission-critical services as well as security controls that maintain compliance. Consider multiple disaster scenarios that could impact business continuity. Security professionals typically focus on cyberattacks, but power outages, floods, earthquakes, and other natural phenomena can just as easily lead to data loss. Opportunistic hackers may take advantage of these events to strike when they think the organization’s guard is down. 19. Make sure secure remote access is guaranteed: If remote access to your network is required, use secure methods like VPNs and multi-factor authentication (MFA) for added protection. Make sure your firewall policies reflect the organization’s remote-enabled capabilities, and provide a secure environment for remote users to operate in. Consider implementing NGFW solutions that can reliably identify and manage inbound VPN connections without triggering false positives. Be especially wary of firewall rules that automatically deny connections without conducting deeper analysis to find out whether it was for legitimate user access. 20. Use group objects to simplify firewall rules: Your firewall analyzer allows you to create general rules and apply them to group objects, applying the rule to any asset in the group. This allows you to use the same rule set for similar policies impacting different network segments. You can even create a global policy that applies to the whole network and then refine that policy further as you go through each subnetwork. Be careful about nesting object groups inside one another. This might look like clean firewall management, but it can also create problems when the organization grows, and it can complicate change management. You may end up enforcing contradictory rules if your documentation practices can’t keep up. Schedule a demo Related Articles Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read 5 Multi-Cloud Environments Cloud Security Mar 19, 2023 · 2 min read Convergence didn’t fail, compliance did. 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* Phone number* country* Select country... By submitting this form, I accept AlgoSec's privacy policy Schedule a call