Search results

As you may have heard already, the National Security Agency (NSA) and the Federal Bureau of Investigation (FBI) released a joint... Cloud Security Drovorub’s Ability to Conceal C2 Traffic And Its Implications For 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/15/20 Published As you may have heard already, the National Security Agency (NSA) and the Federal Bureau of Investigation (FBI) released a joint Cybersecurity Advisory about previously undisclosed Russian malware called Drovorub. According to the report, the malware is designed for Linux systems as part of its cyber espionage operations. Drovorub is a Linux malware toolset that consists of an implant coupled with a kernel module rootkit, a file transfer and port forwarding tool, and a Command and Control (C2) server. The name Drovorub originates from the Russian language. It is a complex word that consists of 2 roots (not the full words): “drov” and “rub” . The “o” in between is used to join both roots together. The root “drov” forms a noun “drova” , which translates to “firewood” , or “wood” . The root “rub” /ˈruːb/ forms a verb “rubit” , which translates to “to fell” , or “to chop” . Hence, the original meaning of this word is indeed a “woodcutter” . What the report omits, however, is that apart from the classic interpretation, there is also slang. In the Russian computer slang, the word “drova” is widely used to denote “drivers” . The word “rubit” also has other meanings in Russian. It may mean to kill, to disable, to switch off. In the Russian slang, “rubit” also means to understand something very well, to be professional in a specific field. It resonates with the English word “sharp” – to be able to cut through the problem. Hence, we have 3 possible interpretations of ‘ Drovorub ‘: someone who chops wood – “дроворуб” someone who disables other kernel-mode drivers – “тот, кто отрубает / рубит драйвера” someone who understands kernel-mode drivers very well – “тот, кто (хорошо) рубит в драйверах” Given that Drovorub does not disable other drivers, the last interpretation could be the intended one. In that case, “Drovorub” could be a code name of the project or even someone’s nickname. Let’s put aside the intricacies of the Russian translations and get a closer look into the report. DISCLAIMER Before we dive into some of the Drovorub analysis aspects, we need to make clear that neither FBI nor NSA has shared any hashes or any samples of Drovorub. Without the samples, it’s impossible to conduct a full reverse engineering analysis of the malware. Netfilter Hiding According to the report, the Drovorub-kernel module registers a Netfilter hook. A network packet filter with a Netfilter hook ( NF_INET_LOCAL_IN and NF_INET_LOCAL_OUT ) is a common malware technique. It allows a backdoor to watch passively for certain magic packets or series of packets, to extract C2 traffic. What is interesting though, is that the driver also hooks the kernel’s nf_register_hook() function. The hook handler will register the original Netfilter hook, then un-register it, then re-register the kernel’s own Netfilter hook. According to the nf_register_hook() function in the Netfilter’s source , if two hooks have the same protocol family (e.g., PF_INET ), and the same hook identifier (e.g., NF_IP_INPUT ), the hook execution sequence is determined by priority. The hook list enumerator breaks at the position of an existing hook with a priority number elem->priority higher than the new hook’s priority number reg->priority : int nf_register_hook ( struct nf_hook_ops * reg) { struct nf_hook_ops * elem; int err; err = mutex_lock_interruptible( & nf_hook_mutex); if (err < 0 ) return err; list_for_each_entry(elem, & nf_hooks[reg -> pf][reg -> hooknum], list) { if (reg -> priority < elem -> priority) break ; } list_add_rcu( & reg -> list, elem -> list.prev); mutex_unlock( & nf_hook_mutex); ... return 0 ; } In that case, the new hook is inserted into the list, so that the higher-priority hook’s PREVIOUS link would point into the newly inserted hook. What happens if the new hook’s priority is also the same, such as NF_IP_PRI_FIRST – the maximum hook priority? In that case, the break condition will not be met, the list iterator list_for_each_entry will slide past the existing hook, and the new hook will be inserted after it as if the new hook’s priority was higher. By re-inserting its Netfilter hook in the hook handler of the nf_register_hook() function, the driver makes sure the Drovorub’s Netfilter hook will beat any other registered hook at the same hook number and with the same (maximum) priority. If the intercepted TCP packet does not belong to the hidden TCP connection, or if it’s destined to or originates from another process, hidden by Drovorub’s kernel-mode driver, the hook will return 5 ( NF_STOP ). Doing so will prevent other hooks from being called to process the same packet. Security Implications For Docker Containers Given that Drovorub toolset targets Linux and contains a port forwarding tool to route network traffic to other hosts on the compromised network, it would not be entirely unreasonable to assume that this toolset was detected in a client’s cloud infrastructure. According to Gartner’s prediction , in just two years, more than 75% of global organizations will be running cloud-native containerized applications in production, up from less than 30% today. Would the Drovorub toolset survive, if the client’s cloud infrastructure was running containerized applications? Would that facilitate the attack or would it disrupt it? Would it make the breach stealthier? To answer these questions, we have tested a different malicious toolset, CloudSnooper, reported earlier this year by Sophos. Just like Drovorub, CloudSnooper’s kernel-mode driver also relies on a Netfilter hook ( NF_INET_LOCAL_IN and NF_INET_LOCAL_OUT ) to extract C2 traffic from the intercepted TCP packets. As seen in the FBI/NSA report, the Volatility framework was used to carve the Drovorub kernel module out of the host, running CentOS. In our little lab experiment, let’s also use CentOS host. To build a new Docker container image, let’s construct the following Dockerfile: FROM scratch ADD centos-7.4.1708-docker.tar.xz / ADD rootkit.ko / CMD [“/bin/bash”] The new image, built from scratch, will have the CentOS 7.4 installed. The kernel-mode rootkit will be added to its root directory. Let’s build an image from our Dockerfile, and call it ‘test’: [root@localhost 1]# docker build . -t test Sending build context to Docker daemon 43.6MB Step 1/4 : FROM scratch —> Step 2/4 : ADD centos-7.4.1708-docker.tar.xz / —> 0c3c322f2e28 Step 3/4 : ADD rootkit.ko / —> 5aaa26212769 Step 4/4 : CMD [“/bin/bash”] —> Running in 8e34940342a2 Removing intermediate container 8e34940342a2 —> 575e3875cdab Successfully built 575e3875cdab Successfully tagged test:latest Next, let’s execute our image interactively (with pseudo-TTY and STDIN ): docker run -it test The executed image will be waiting for our commands: [root@8921e4c7d45e /]# Next, let’s try to load the malicious kernel module: [root@8921e4c7d45e /]# insmod rootkit.ko The output of this command is: insmod: ERROR: could not insert module rootkit.ko: Operation not permitted The reason why it failed is that by default, Docker containers are ‘unprivileged’. Loading a kernel module from a docker container requires a special privilege that allows it doing so. Let’s repeat our experiment. This time, let’s execute our image either in a fully privileged mode or by enabling only one capability – a capability to load and unload kernel modules ( SYS_MODULE ). docker run -it –privileged test or docker run -it –cap-add SYS_MODULE test Let’s load our driver again: [root@547451b8bf87 /]# insmod rootkit.ko This time, the command is executed silently. Running lsmod command allows us to enlist the driver and to prove it was loaded just fine. A little magic here is to quit the docker container and then delete its image: docker rmi -f test Next, let’s execute lsmod again, only this time on the host. The output produced by lsmod will confirm the rootkit module is loaded on the host even after the container image is fully unloaded from memory and deleted! Let’s see what ports are open on the host: [root@localhost 1]# netstat -tulpn Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1044/sshd With the SSH server running on port 22 , let’s send a C2 ‘ping’ command to the rootkit over port 22 : [root@localhost 1]# python client.py 127.0.0.1 22 8080 rrootkit-negotiation: hello The ‘hello’ response from the rootkit proves it’s fully operational. The Netfilter hook detects a command concealed in a TCP packet transferred over port 22 , even though the host runs SSH server on port 22 . How was it possible that a rootkit loaded from a docker container ended up loaded on the host? The answer is simple: a docker container is not a virtual machine. Despite the namespace and ‘control groups’ isolation, it still relies on the same kernel as the host. Therefore, a kernel-mode rootkit loaded from inside a Docker container instantly compromises the host, thus allowing the attackers to compromise other containers that reside on the same host. It is true that by default, a Docker container is ‘unprivileged’ and hence, may not load kernel-mode drivers. However, if a host is compromised, or if a trojanized container image detects the presence of the SYS_MODULE capability (as required by many legitimate Docker containers), loading a kernel-mode rootkit on a host from inside a container becomes a trivial task. Detecting the SYS_MODULE capability ( cap_sys_module ) from inside the container: [root@80402f9c2e4c /]# capsh –print Current: = cap_chown, … cap_sys_module, … Conclusion This post is drawing a parallel between the recently reported Drovorub rootkit and CloudSnooper, a rootkit reported earlier this year. Allegedly built by different teams, both of these Linux rootkits have one mechanism in common: a Netfilter hook ( NF_INET_LOCAL_IN and NF_INET_LOCAL_OUT ) and a toolset that enables tunneling of the traffic to other hosts within the same compromised cloud infrastructure. We are still hunting for the hashes and samples of Drovorub. Unfortunately, the YARA rules published by FBI/NSA cause False Positives. For example, the “Rule to detect Drovorub-server, Drovorub-agent, and Drovorub-client binaries based on unique strings and strings indicating statically linked libraries” enlists the following strings: “Poco” “Json” “OpenSSL” “clientid” “—–BEGIN” “—–END” “tunnel” The string “Poco” comes from the POCO C++ Libraries that are used for over 15 years. It is w-a-a-a-a-y too generic, even in combination with other generic strings. As a result, all these strings, along with the ELF header and a file size between 1MB and 10MB, produce a false hit on legitimate ARM libraries, such as a library used for GPS navigation on Android devices: f058ebb581f22882290b27725df94bb302b89504 56c36bfd4bbb1e3084e8e87657f02dbc4ba87755 Nevertheless, based on the information available today, our interest is naturally drawn to the security implications of these Linux rootkits for the Docker containers. Regardless of what security mechanisms may have been compromised, Docker containers contribute an additional attack surface, another opportunity for the attackers to compromise the hosts and other containers within the same organization. The scenario outlined in this post is purely hypothetical. There is no evidence that supports that Drovorub may have affected any containers. However, an increase in volume and sophistication of attacks against Linux-based cloud-native production environments, coupled with the increased proliferation of containers, suggests that such a scenario may, in fact, be plausible. 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

Before your organization can move business applications to the cloud, it must deploy network security solutions that can reliably block... Network Segmentation Host-based firewalls vs. network-based firewalls for network security? 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 Before your organization can move business applications to the cloud, it must deploy network security solutions that can reliably block cybercrime and malware. Firewalls are essential cybersecurity tools that protect network traffic against threat actors. There are many different types of firewalls available, but put the same basic principles in action. Before finding out which types of firewalls offer the best security performance for your cloud implementation, it’s important to cover how firewalls work and what characteristics set them apart. How firewalls work: Different types of firewalls explained Firewalls are best explained through analogy. Think of firewalls as 24/7 security guards with deep knowledge of millions of criminals. Whenever the security guard sees a criminal approaching an access point, they block access and turn the criminal away. This kind of access control is accomplished in a few different ways. Some firewalls inspect packets for suspicious characteristics. Others use stateful inspection to identify malicious traffic. Some incorporate contextual awareness to tell the difference between harmless traffic and cyberattacks . Here are some of the major types of firewalls and how they work: Packet filtering firewalls inspect data traveling through inline junction points like routers and switches. They don’t route data packets themselves, but compare them to a list of firewall rules. For example, they may filter packets that are traveling to untrusted IP addresses and drop them. Circuit-level gateways monitor TCP handshake data and other protocol messages for signs of unauthorized access. These firewalls don’t inspect individual packets or application layer monitoring, though. Proxy firewalls apply application layer filtering that filters data according to a wide range of characteristics. This category includes web application firewalls, which are a type of reverse proxy firewall – they protect the server from malicious traffic by filtering clients before they reach the server. Stateful inspection firewalls examine and compare multiple packets to find out if they are part of an established network session. This offers a high degree of control over incoming and outgoing traffic while providing comprehensive logs on network connections. Next-generation firewalls combine packet inspection, stateful inspection, antivirus, and additional technologies to protect organizations against unknown threats and vulnerabilities. These firewalls are expensive and have high bandwidth requirements, but they also offer a high level of protection. All of these firewalls exist in different forms. Traditional hardware firewalls are physical devices that sit between network devices and the internet. Network-based firewalls are software-defined apps designed to do the same thing. Hardware, software, or cloud? firewall deployment methods compared Organizations have multiple options when deciding to host firewalls on their private networks. The market offers a vast number of security devices and firewall providers, ranging from Cisco hardware to software solutions like Microsoft’s Windows firewall. Large enterprises use a combination of firewall solutions to adopt a multi-layered security posture. This allows them to achieve network scalability and segmentation while offering different levels of protection to data centers, individual devices, and user endpoints. As firewall technology becomes more accessible, smaller organizations are following suit. Here are some of the delivery formats that firewall solutions commonly come in: Network-based Firewalls are self-contained hardware appliances. They typically run custom operating systems using Linux distributions designed for secure computer networking. They can be challenging to configure and deploy, but are appropriate for a wide range of use cases. Host-based Firewalls run as software on a server or other device. You can run host-based firewalls on individual computers, or at the host level of a cloud environment. The firewalls offer granular control over security rules and individual hosts, but consume resources in the process. Cloud Hosted Firewalls are provided by third-party security partners as a service. These firewalls may be entirely managed by a third-party partner, making them ideal for small organizations that can’t afford building their own security infrastructure from the ground up. How to select an optimal firewall solution for your organization Every organization has a unique security risk profile. Finding the right firewall deployment for your organization requires in-depth knowledge of your network’s security vulnerabilities and potential for long-term growth. Some of the issues you have to consider include: Identifying technical objectives for individual firewalls. There are no one-size-fits-all firewall solutions. One solution may match a particular use case that another does not. Both stateless packet inspection firewalls and sophisticated next-generation solutions operate at different levels of the OSI model, which means each device should serve a well-defined purpose. Selecting firewall solutions that match your team’s expertise. Consider your IT team’s technical qualifications. If configuring a sophisticated next-generation firewall requires adding talent with specialized certifications to your team, the cost of that deployment will rise considerably. Deploying firewalls in ways that improve security performance while reducing waste. Optimal firewall architecture requires effective network segmentation and good security policies. Deploying a secure local area network (LAN) and using virtual private networks (VPNs) can help optimize firewall placement throughout the organization. Determining which kinds of traffic inspection are necessary. Different types of network connections require different levels of security. For example, a public-facing Wi-Fi router is far more likely to encounter malicious traffic than an internal virtual local area network (VLAN) that only authenticated employees can access. How to choose between host-based firewalls and network-based firewalls when moving to the cloud Organizations that are transitioning to cloud infrastructure need to completely rethink their firewall deployment strategy. Firewalls are the cornerstone of access control, and cloud-hosted infrastructure comes with the shared responsibility model that puts pressure on security leaders to carefully deploy security resources. In many cases, you’ll face tough decisions concerning which type of firewall to deploy at particular points in your network. Building an optimal deployment means working through the pros and cons of each option on a case-by-case basis. Host-based firewalls and network-based firewalls are the two main options you’ll encounter for most use cases. Let’s look at what each of those options look like from a complete network security perspective . 1. Host-based firewalls offer flexibility but may introduce vulnerabilities A cloud-native organization that exclusively uses host-based firewalls will have a cloud environment filled with virtual machines that take the place of servers and individual computers. To protect those devices, the organization will implement host-based firewalls on every virtual machine and configure them accordingly. This provides the organization with a great deal of flexibility. IT team members can clone virtual machines and move them within the cloud on demand. The host-based firewalls that protect these machines can move right alongside them, ensuring consistent security policies are enforced without painstaking manual configuration. It’s even possible to move virtual machines between cloud environments – like moving a virtual server from Amazon AWS to Microsoft Azure – without having to create completely new security policies in the process. This makes it easy for IT teams to work securely without introducing friction. However, if attackers gain privileged access to host-based firewalls, they gain the same level of control. They may switch off the firewall or install malicious code in ways that other security technologies cannot detect. Even highly secure organizations are subject to this kind of risk. Imagine an attacker compromises the credentials of a system administrator with firewall configuration privileges. Very few obstacles stand between an insider threat and the sensitive data they wish to exfiltrate. Network-based firewalls offer independent security Compared to host-based firewall products, it’s much harder for a malicious insider to compromise a network-based firewall solution managed by a cloud provider. That’s because the physical hardware is operating on a completely separate system from the host. In a cloud-native environment, the network-based firewall would be a fully hardened device managed by a third-party provider running their own intrusion detection systems. This makes it much harder for attackers to successfully infiltrate and compromise systems without being noticed. At the same time, independent network-based firewall architecture means that the attacker would have to compromise both your network and the cloud provider’s network without triggering security alerts from either. This adds a great deal of complexity to any attack, and significantly increases the chance it will be detected. However, few organizations can afford to exclusively deploy hardware firewalls at every layer of their network. Even those that can afford it will run into significant challenges when planning for growth and scalability. Segment your network for optimal protection While they offer increased security, hardware firewalls are costly to deploy and maintain. Most organizations segment their networks in ways that offer extensive multi-layered protection to their most sensitive data while allowing more flexible host-based firewalls to protect less critical assets. Every organization has a unique balance between optimal network-based firewall and host-based firewall deployment. This depends heavily on the volume of sensitive data the organization regularly accesses, and the security of its connections with users and third-party service providers. Proper network segmentation helps reduce the organization’s attack surface and decrease the risk of business disruption. 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

Business-driven Security Management For The Federal Governments Download PDF Download PDF Add a Title Add a Title Add a Title Schedule time with 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 Continue

The hybrid manifesto Download PDF Download PDF Add a Title Add a Title Add a Title Schedule time with 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 Continue

Learn how ESG principles are driving sustainable environmental strategies Discover how companies integrate ESG to reduce footprint and contribute to a greener future Our environmental strategy Schedule time with 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 Continue Environmental commitment and vision AlgoSec recognizes the importance of protecting the environment, we at AlgoSec are committed to reducing our carbon footprint and our waste by efficiently coding our product. For minimal environmental impact, the company has defined a long-term strategy, which includes working towards reinforcing its reduction goals and strengthening them through information and employee awareness. Our goal AlgoSec is determined to reduce our environmental impact, by striving to decrease the GHG emissions from our worldwide operations and from our products (as applicable), thus ensuring a safer and more sustainable future for us all. We are continuously looking for ways to maximize energy efficiency while minimizing water consumption and waste accumulation throughout our operations. Our next steps We are committed to infusing as part of our business plan strategic actions to advance reduction in GHG emissions, as part of Scope 1&2. We will continue to reduce our environmental impact by monitoring our progress and taking strategic actions to help achieve our goals. What we have achieved so far Implementation of a worldwide hybrid model since 2020, thus inducing a reduction in emissions spent on employee commuting, as well as electricity usage and water consumption. Waste management program – Reduce trash and the use of plastic at the office, in addition to recycling or reusing 99% of our electronic waste Raising employee awareness of effective use of energy in the office Product sustainability – we strive to increase the energy efficiency of our products by advanced product coding. Certification Verification Statement for GHG Scope 1&2: Additional related links: AA1000AS Reports | Accountability Global Sustainability Consultancy and Standards New York, London, Dubai, Riyadh BDO has conducted the assurance for AlgoSec Greenhouse Gas inventory for scopes 1 and 2 according to GHG protocola The assurance procedure was done according to the disclosures required by the AccountAbility AA1000AS v3 standard and the ISO 14064-3 verification methodology. The assurance process was conducted professionally, impartially and independently.

Securing & managing hybrid network security Download PDF Download PDF Add a Title Add a Title Add a Title Schedule time with 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 Continue

Learn how Microsoft Azure and AlgoSec solutions help companies improve visibility and identify risk in large complex hybrid networking environments Webinars Joint webinar with Microsoft Azure - Understanding Hybrid Network Security Learn how Microsoft Azure and AlgoSec solutions help companies improve visibility and identify risk in large complex hybrid networking environments In this joint webinar with Microsoft, we discuss the challenges in these hybrid networks and how Microsoft Azure and AlgoSec are helping companies leverage cloud technologies to add more capacity and business applications without increasing their exposure to security risk. During the webinar you will hear Yuval Pery, the Product Manager for Azure Network Security at Microsoft, review and discuss the security features and options available with Microsoft Azure. We also have Yoav Yam-Karnibad, the Product Manager for Cloud Network Security at AlgoSec, show the integrations that exist today between AlgoSec and Microsoft Azure that help improve visibility and identify and prioritize risk in today’s hybrid environments. September 14, 2023 Yoav Yam-Karnibad Product Manager, Cloud Network Security at AlgoSec Yuval Pery Product Manager, Azure Network Security at Microsoft Relevant resources Firewall Rule Recertification with Application Connectivity Keep Reading AlgoSec Cloud for Microsoft Azure Keep Reading Firewall management services
Proactive network security Keep Reading 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

Information security is vital to business continuity. Organizations trust their IT teams to enable innovation and business transformation... Risk Management and Vulnerabilities How to optimize the security policy management lifecycle 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 Information security is vital to business continuity. Organizations trust their IT teams to enable innovation and business transformation but need them to safeguard digital assets in the process. This leads some leaders to feel that their information security policies are standing in the way of innovation and business agility. Instead of rolling new a new enterprise application and provisioning it for full connectivity from the start, security teams demand weeks or months of time to secure those systems before they’re ready. But this doesn’t mean that cybersecurity is a bottleneck to business agility. The need for speedier deployment doesn’t automatically translate to increased risk. Organizations that manage application connectivity and network security policies using a structured lifecycle approach can improve security without compromising deployment speed. Many challenges stand between organizations and their application and network connectivity goals. Understanding each stage of the lifecycle approach to security policy change management is key to overcoming these obstacles. Challenges to optimizing security policy management ` Complex enterprise infrastructure and compliance requirements A medium-sizded enterprise may have hundreds of servers, systems, and security solutions like firewalls in place. These may be spread across several different cloud providers, with additional inputs from SaaS vendors and other third-party partners. Add in strict regulatory compliance requirements like HIPAA , and the risk management picture gets much more complicated. Even voluntary frameworks like NIST heavily impact an organization’s information security posture, acceptable use policies, and more – without the added risk of non-compliance. Before organizations can optimize their approach to security policy management, they must have visibility and control over an increasingly complex landscape. Without this, making meaningful progress of data classification and retention policies is difficult, if not impossible. Modern workflows involve non-stop change When information technology teams deploy or modify an application, it’s in response to an identified business need. When those deployments get delayed, there is a real business impact. IT departments now need to implement security measures earlier, faster, and more comprehensively than they used to. They must conduct risk assessments and security training processes within ever-smaller timeframes, or risk exposing the organization to vulnerabilities and security breaches . Strong security policies need thousands of custom rules There is no one-size-fits-all solution for managing access control and data protection at the application level. Different organizations have different security postures and security risk profiles. Compliance requirements can change, leading to new security requirements that demand implementation. Enterprise organizations that handle sensitive data and adhere to strict compliance rules must severely restrict access to information systems. It’s not easy to achieve PCI DSS compliance or adhere to GDPR security standards solely through automation – at least, not without a dedicated change management platform like AlgoSec . Effectively managing an enormous volume of custom security rules and authentication policies requires access to scalable security resources under a centralized, well-managed security program. Organizations must ensure their security teams are equipped to enforce data security policies successfully. Inter-department communication needs improvement Application deliver managers, network architects, security professionals, and compliance managers must all contribute to the delivery of new application projects. Achieving clear channels of communication between these different groups is no easy task. In most enterprise environments, these teams speak different technical languages. They draw their data from internally siloed sources, and rarely share comprehensive documentation with one another. In many cases, one or more of these groups are only brought in after everyone else has had their say, which significantly limits the amount of influence they can have. The lifecycle approach to managing IT security policies can help establish a standardized set of security controls that everyone follows. However, it also requires better communication and security awareness from stakeholders throughout the organization. The policy management lifecycle addresses these challenges in five stages ` Without a clear security policy management lifecycle in place, most enterprises end up managing security changes on an ad hoc basis. This puts them at a disadvantage, especially when security resources are stretched thin on incident response and disaster recovery initiatives. Instead of adopting a reactive approach that delays application releases and reduces productivity, organizations can leverage the lifecycle approach to security policy management to address vulnerabilities early in the application development lifecycle. This leaves additional resources available for responding to security incidents, managing security threats, and proactively preventing data breaches. Discover and visualize application connectivity The first stage of the security policy management lifecycle revolves around mapping how your apps connect to each other and to your network setup. The more details can include in this map, the better prepared your IT team will be for handling the challenges of policy management. Performing this discovery process manually can cost enterprise-level security teams a great deal of time and accuracy. There may be thousands of devices on the network, with a complex web of connections between them. Any errors that enter the framework at this stage will be amplified through the later stages – it’s important to get things right at this stage. Automated tools help IT staff improve the speed and accuracy of the discovery and visualization stage. This helps everyone – technical and nontechnical staff included – to understand what apps need to connect and work together properly. Automated tools help translate these needs into language that the rest of the organization can understand, reducing the risk of misconfiguration down the line. Plan and assess security policy changes Once you have a good understanding of how your apps connect with each other and your network setup, you can plan changes more effectively. You want to make sure these changes will allow the organization’s apps to connect with one another and work together without increasing security risks. It’s important to adopt a vulnerability-oriented perspective at this stage. You don’t want to accidentally introduce weak spots that hackers can exploit, or establish policies that are too complex for your organization’s employees to follow. This process usually involves translating application connectivity requests into network operations terms. Your IT team will have to check if the proposed changes are necessary, and predict what the results of implementing those changes might be. This is especially important for cloud-based apps that may change quickly and unpredictably. At the same time, security teams must evaluate the risks and determine whether the changes are compliant with security policy. Automating these tasks as part of a regular cycle ensures the data is always relevant and saves valuable time. Migrate and deploy changes efficiently The process of deploying new security rules is complex, time-consuming, and prone to error . It often stretches the capabilities of security teams that already have a wide range of operational security issues to address at any given time. In between managing incident response and regulatory compliance, they must now also manually update thousands of security rules over a fleet of complex network assets. This process gets a little bit easier when guided by a comprehensive security policy change management framework. But most organizations don’t unlock the true value of the security policy management lifecycle until they adopt automation. Automated security policy management platforms enable organizations to design rule changes intelligently, migrate rules automatically, and push new policies to firewalls through a zero-touch interface. They can even validate whether the intended changes updated correctly. This final step is especially important. Without it, security teams must manually verify whether their new policies successfully address the vulnerabilities the way they’re supposed to. This doesn’t always happen, leaving security teams with a false sense of security. Maintain configurations using templates Most firewalls accumulate thousands of rules as security teams update them against new threats. Many of these rules become outdated and obsolete over time, but remain in place nonetheless. This adds a great deal of complexity to small-scale tasks like change management, troubleshooting issues, and compliance auditing. It can also impact the performance of firewall hardware , which decreases the overall lifespan of expensive physical equipment. Configuration changes and maintenance should include processes for identifying and eliminating rules that are redundant, misconfigured, or obsolete. The cleaner and better-documented the organization’s rulesets are, the easier subsequent configuration changes will be. Rule templates provide a simple solution to this problem. Organizations that create and maintain comprehensive templates for their current firewall rulesets can easily modify, update, and change those rules without having to painstakingly review and update individual devices manually. Decommission obsolete applications completely Every business application will eventually reach the end of its lifecycle. However, many organizations keep decommissioned security policies in place for one of two reasons: Oversight that stems from unstandardized or poorly documented processes, or; Fear that removing policies will negatively impact other, active applications. As these obsolete security policies pile up, they force the organization to spend more time and resources updating their firewall rulesets. This adds bloat to firewall security processes, and increases the risk of misconfigurations that can lead to cyber attacks. A standardized, lifecycle-centric approach to security policy management makes space for the structured decommissioning of obsolete applications and the rules that apply to them. This improves change management and ensures the organization’s security posture is optimally suited for later changes. At the same time, it provides comprehensive visibility that reduces oversight risks and gives security teams fewer unknowns to fear when decommissioning obsolete applications. Many organizations believe that Security stands in the way of the business – particularly when it comes to changing or provisioning connectivity for applications. It can take weeks, or even months to ensure that all the servers, devices, and network segments that support the application can communicate with each other while blocking access to hackers and unauthorized users. It’s a complex and intricate process. This is because, for every single application update or change, Networking and Security teams need to understand how it will affect the information flows between the various firewalls and servers the application relies on, and then change connectivity rules and security policies to ensure that only legitimate traffic is allowed, without creating security gaps or compliance violations. As a result, many enterprises manage security changes on an ad-hoc basis: they move quickly to address the immediate needs of high-profile applications or to resolve critical threats, but have little time left over to maintain network maps, document security policies, or analyze the impact of rule changes on applications. This reactive approach delays application releases, can cause outages and lost productivity, increases the risk of security breaches and puts the brakes on business agility. But it doesn’t have to be this way. Nor is it necessary for businesses to accept greater security risk to satisfy the demand for speed. Accelerating agility without sacrificing security The solution is to manage application connectivity and network security policies through a structured lifecycle methodology, which ensures that the right security policy management activities are performed in the right order, through an automated, repeatable process. This dramatically speeds up application connectivity provisioning and improves business agility, without sacrificing security and compliance. So, what is the network security policy management lifecycle, and how should network and security teams implement a lifecycle approach in their organizations? Discover and visualize The first stage involves creating an accurate, real-time map of application connectivity and the network topology across the entire organization, including on-premise, cloud, and software-defined environments. Without this information, IT staff are essentially working blind, and will inevitably make mistakes and encounter problems down the line. Security policy management solutions can automate the application connectivity discovery, mapping, and documentation processes across the thousands of devices on networks – a task that is enormously time-consuming and labor-intensive if done manually. In addition, the mapping process can help business and technical groups develop a shared understanding of application connectivity requirements. Plan and assess Once there is a clear picture of application connectivity and the network infrastructure, you can start to plan changes more effectively – ensure that proposed changes will provide the required connectivity, while minimizing the risks of introducing vulnerabilities, causing application outages, or compliance violations. Typically, it involves translating application connectivity requests into networking terminology, analyzing the network topology to determine if the changes are really needed, conducting an impact analysis of proposed rule changes (particularly valuable with unpredictable cloud-based applications), performing a risk and compliance assessment, and assessing inputs from vulnerabilities scanners and SIEM solutions. Automating these activities as part of a structured lifecycle keeps data up-to-date, saves time, and ensures that these critical steps are not omitted – helping avoid configuration errors and outages. Functions Of An Automatic Pool Cleaner An automatic pool cleaner is very useful for people who have a bad back and find it hard to manually operate the pool cleaner throughout the pool area. This type of pool cleaner can move along the various areas of a pool automatically. Its main function is to suck up dirt and other debris in the pool. It functions as a vacuum. Automatic pool cleaners may also come in different types and styles. These include automatic pressure-driven cleaners, automatic suction side-drive cleaners, and robotic pool cleaners. Migrate and deploy Deploying connectivity and security rules can be a labor-intensive and error-prone process. Security policy management solutions automate the critical tasks involved, including designing rule changes intelligently, automatically migrating rules, and pushing policies to firewalls and other security devices – all with zero-touch if no problems or exceptions are detected. Crucially, the solution can also validate that the intended changes have been implemented correctly. This last step is often neglected, creating the false impression that application connectivity has been provided, or that vulnerabilities have been removed, when in fact there are time bombs ticking in the network. Maintain Most firewalls accumulate thousands of rules which become outdated or obsolete over the years. Bloated rulesets not only add complexity to daily tasks such as change management, troubleshooting and auditing, but they can also impact the performance of firewall appliances, resulting in decreased hardware lifespan and increased TCO. Cleaning up and optimizing security policies on an ongoing basis can prevent these problems. This includes identifying and eliminating or consolidating redundant and conflicting rules; tightening overly permissive rules; reordering rules; and recertifying expired ones. A clean, well-documented set of security rules helps to prevent business application outages, compliance violations, and security gaps and reduces management time and effort. Decommission Every business application eventually reaches the end of its life: but when they are decommissioned, its security policies are often left in place, either by oversight or from fear that removing policies could negatively affect active business applications. These obsolete or redundant security policies increase the enterprise’s attack surface and add bloat to the firewall ruleset. The lifecycle approach reduces these risks. It provides a structured and automated process for identifying and safely removing redundant rules as soon as applications are decommissioned while verifying that their removal will not impact active applications or create compliance violations. We recently published a white paper that explains the five stages of the security policy management lifecycle in detail. It’s a great primer for any organization looking to move away from a reactive, fire-fighting response to security challenges, to an approach that addresses the challenges of balancing security and risk with business agility. Download your copy here . 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

Robert Bigman is uniquely equipped to share actionable tips for hardening your network security against vulnerabilities Don’t miss this opportunity to learn the latest threats and how to handle them Webinars Measures that actually DO reduce your hacking risk Learn from the best how to defeat hackers and ransomware As incidents of ransomware attacks become more common, the time has come to learn from the best how to defeat hackers. Join us as Robert Bigman, the former CISO of the CIA, presents his webinar Measures that Actually do Reduce your Hacking Risk. Robert Bigman is uniquely equipped to share actionable tips for hardening your network security against vulnerabilities. Don’t miss this opportunity to learn the latest threats and how to handle them. April 20, 2022 Robert Bigman Consultant; Former CISO of the CIA Relevant resources Ensuring critical applications stay available and secure while shifting to remote work Keep Reading Reducing risk of ransomware attacks - back to basics Keep Reading Ransomware Attack: Best practices to help organizations proactively prevent, contain and Keep Reading 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

Linux containers aren’t new. In fact, this technology was invented 20 years ago. In 2013, Docker entered the scene and revolutionized... Cloud Security Operation “Red Kangaroo”: Industry’s First Dynamic Analysis of 4M Public Docker Container Images 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 12/1/20 Published Linux containers aren’t new. In fact, this technology was invented 20 years ago. In 2013, Docker entered the scene and revolutionized Linux containers by offering an easy-to-use command line interface (CLI), an engine, and a registry server. Combined, these technologies have concealed all the complexity of building and running containers, by offering one common industry standard . As a result, Docker’s popularity has sky-rocketed, rivalling Virtual Machines, and transforming the industry. In order to locate and share Docker container images, Docker is offering a service called Docker Hub . Its main feature, repositories , allows the development community to push (upload) and pull (download) container images. With Docker Hub, anyone in the world can download and execute any public image, as if it was a standalone application. Today, Docker Hub accounts over 4 million public Docker container images . With 8 billion pulls (downloads) in January 2020 and growing , its annualized image pulls should top 100 billion this year. For comparison , Google Play has 2.7M Android apps in its store, with a download rate of 84 billion downloads a year. How many container images currently hosted at Docker Hub are malicious or potentially harmful? What sort of damage can they inflict? What if a Docker container image downloaded and executed malware at runtime? Is there a reliable way to tell that? What if a compromised Docker container image was downloaded by an unsuspecting customer and used as a parent image to build and then deploy a new container image into production, practically publishing an application with a backdoor built into it? Is there any way to stop that from happening? At Prevasio, we asked ourselves these questions multiple times. What we decided to do has never been done before. The Challenge At Prevasio, we have built a dynamic analysis sandbox that uses the same principle as a conventional sandbox that ‘detonates’ malware in a safe environment. The only difference is that instead of ‘detonating’ an executable file, such as a Windows PE file or a Linux ELF binary, Prevasio Analyzer first pulls (downloads) an image from any container registry, and then ‘detonates’ it in its own virtual environment, outside the organization/customer infrastructure. Using our solution, we then dynamically analyzed all 4 million container images hosted at Docker Hub. In order to handle such a massive volume of images, Prevasio Analyzer was executed non-stop for a period of one month on 800 machines running in parallel. The result of our dynamic scan reveals that: 51 percent of all containers had “critical” vulnerabilities, while 13 percent were classified as “high” and four percent as “moderate” vulnerabilities. Six thousand containers were riddled with cryptominers, hacking tools/pen testing frameworks, and backdoor trojans. While many cryptominers and hacking tools may not be malicious per se, they present a potentially unwanted issue to an enterprise. More than 400 container images (with nearly 600,000 pulls) of weaponized Windows malware crossing over into the world of Linux. This crossover is directly due to the proliferation of cross-platform code (e.g. GoLang, .NET Core and PowerShell Core). Our analysis of malicious containers also shows that quite a few images contain a dynamic payload. That is, an image in its original form does not have a malicious binary. However, at runtime, it might be scripted to download a source of a coinminer, to then compile and execute it. A dynamic analysis sandbox, such as Prevasio Analyzer, is the only solution that provides a behavioral analysis of Docker containers. It is built to reveal malicious intentions of Docker containers by executing them in its own virtual environment, revealing a full scope of their behavior. The whitepaper with our findings is available here . 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

The business case for AlgoSec Cloud Enterprise (Horizon ACE) Download PDF Download PDF Add a Title Add a Title Add a Title Schedule time with 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 Continue

Best practices for network security governance in AWS and hybrid network environments Webinars Cessation of Misconfigurations: Common Network Misconfiguration Risks & How to Avoid Them Avivi Siman-Tov, AlgoSec’s Director of Product | February 18, 2020 Misconfigurations aren’t simply inconvenient mistakes but serious security threats. According to Gartner, 99% of all firewall breaches will be caused by misconfigurations by 2020 and misconfigurations made OWASP’s list of Top 10 most critical web application security risks. A single change to a network device can have far-reaching effects on your business and create security holes for cybercriminals, impact your audits, and cause costly outages that bring your business to a standstill. In this webinar, Avivi Siman-Tov, AlgoSec’s Director of Product, will show examples of common misconfigurations, including device changes, business application connectivity changes, and data center migrations. He will also reveal specific techniques to help you avoid them. Watch the webinar to learn how to: Understand and map your entire network before you make a change Proactively assess the impact of a change to ensure it does not break connectivity, affect compliance or create a security hole and understand the impact of changes to your entire network Maximize the capabilities of network management automation to avoid common misconfigurations Avoid common mistakes when making changes to your network security devices February 18, 2020 Avivi Siman Tov Director of Product Relevant resources Firewall Rule Recertification - An Application-Centric Approach Keep Reading Securing & managing hybrid network security See Documentation Application first cloud security 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