So we’ve made it to the last part of our blog series on PCI 3.0 Requirement 1. The first two posts covered Requirement 1.1... Auditing and Compliance Avoid the Traps: What You Need to Know About PCI Requirement 1 (Part 3) Matthew Pascucci 2 min read Matthew Pascucci 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 9/9/14 Published So we’ve made it to the last part of our blog series on PCI 3.0 Requirement 1. The first two posts covered Requirement 1.1 (appropriate firewall and router configurations) and 1.2 (restrict connections between untrusted networks and any system components in the cardholder data environment) and in this final post we’ll discuss key requirements of Requirements 1.3 -1.5 and I’ll again give you my insight to help you understand the implications of these requirements and how to comply with them. Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports (1.3.1.): The DMZ is used to publish services such as HTTP and HTTPS to the internet and allow external entities to access these services. But the key point here is that you don’t need to open every port on the DMZ. This requirement verifies that a company has a DMZ implemented and that inbound activity is limited to only the required protocols and ports. Limit inbound Internet traffic to IP addresses within the DMZ (1.3.2): This is a similar requirement to 1.3.1, however instead of looking for protocols, the requirement focuses on the IPs that the protocol is able to access. In this case, just because you might need HTTP open to a web server, doesn’t mean that all systems should have external port 80 open to inbound traffic. Do not allow any direct connections inbound or outbound for traffic between the Internet and the cardholder data environment (1.3.3): This requirement verifies that there isn’t unfiltered access, either going into the CDE or leaving it, which means that all traffic that traverses this network must pass through a firewall. All unwanted traffic should be blocked and all allowed traffic should be permitted based on an explicit source/destination/protocol. There should never be a time that someone can enter or leave the CDE without first being inspected by a firewall of some type. Implement anti-spoofing measures to detect and block forged source IP addresses from entering the network (1.3.4): In an attempt to bypass your firewall, cyber attackers will try and spoof packets using the internal IP range of your network to make it look like the request originated internally. Enabling the IP spoofing feature on your firewall will help prevent these types of attacks. Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet (1.3.5): Similar to 1.3.3, this requirement assumes that you don’t have direct outbound access to the internet without a firewall. However in the event that a system has filtered egress access to the internet the QSA will want to understand why this access is needed, and whether there are controls in place to ensure that sensitive data cannot be transmitted outbound. Implement stateful inspection, also known as dynamic packet filtering (1.3.6): If you’re running a modern firewall this feature is most likely already configured by default. With stateful inspection, the firewall maintains a state table which includes all the connections that traverse the firewall, and it knows if there’s a valid response from the current connection. It is used to stop attackers from trying to trick a firewall into initiating a request that didn’t previously exist. Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks (1.3.7): Attackers are looking for your card holder database. Therefore, it shouldn’t be stored within the DMZ. The DMZ should be considered an untrusted network and segregated from the rest of the network. By having the database on the internal network provides another layer of protection against unwanted access. [Also see my suggestions for designing and securing you DMZ in my previous blog series: The Ideal Network Security Perimeter Design: Examining the DMZ Do not disclose private IP addresses and routing information to unauthorized parties (1.3.8): There should be methods in place to prevent your internal IP address scheme from being leaked outside your company. Attackers are looking for any information on how to breach your network, and giving them your internal address scheme is just one less thing they need to learn. You can stop this by using NAT, proxy servers, etc. to limit what can be seen from the outside. Install personal firewall software on any mobile and/or employee-owned devices that connect to the Internet when outside the network (for example, laptops used by employees), and which are also used to access the network (1.4): Mobile devices, such as laptops, that can connect to both the internal network and externally, should have a personal firewall configured with rules that prevent malicious software or attackers from communicating with the device. These firewalls need to be configured so that their rulebase can never be stopped or changed by anyone other than an administrator. Ensure that security policies and operational procedures for managing firewalls are documented, in use, and known to all affected parties (1.5): There needs to be a unified policy regarding firewall maintenance including how maintenance procedures are performed, who has access to the firewall and when maintenance is scheduled. Well, that’s it! Hopefully, my posts have given you a better insight into what is actually required in Requirement 1 and what you need to do to comply with it. 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

Application Segmentation with Cisco Secure Workload and AlgoSec 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

Webinars 5 proven ways to secure your hybrid network environment during team convergence Cloud and datacenter security teams are now one, but the tools, workflows, and policies haven’t caught up. Join ESG Principal Analyst John Grady alongside AlgoSec’s Field CTO Kyle Wickert and Product Manager Gal Yosef for a practical conversation on how leading organizations are tackling the operational challenges of security convergence. What you’ll learn: Why convergence between cloud and datacenter teams is accelerating How to reduce tool overload and policy inconsistencies What steps are teams taking to unify visibility, policy, and risk without slowing down delivery July 16, 2025 John Grady Principal Analyst | ESG Gal Yosef Product Manager | AlgoSec Kyle Wickert WW Strategic Architect Relevant resources 6 best practices to stay secure in the hybrid cloud Read Document Securing & managing hybrid network security See Documentation 6 must-dos to secure the hybrid cloud Read Document Choose a better way to manage your network Choose a better way to manage your network Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Continue

Learn how to secure your hybrid cloud environment with best practices and strategies in this article Safeguard your sensitive data from potential threats Hybrid cloud security management: Best practices + solution Select a size Which network Can AlgoSec be used for continuous compliance monitoring? Yes, AlgoSec supports continuous compliance monitoring. As organizations adapt their security policies to meet emerging threats and address new vulnerabilities, they must constantly verify these changes against the compliance frameworks they subscribe to. AlgoSec can generate risk assessment reports and conduct internal audits on-demand, allowing compliance officers to monitor compliance performance in real-time. Security professionals can also use AlgoSec to preview and simulate proposed changes to the organization’s security policies. This gives compliance officers a valuable degree of lead-time before planned changes impact regulatory guidelines and allows for continuous real-time monitoring. What Is hybrid cloud security? What are the 2 other categories of cloud security? Security benefits of a hybrid cloud solution What are the risks in hybrid cloud security? Components of hybrid cloud security Hybrid cloud security infrastructure Hybrid cloud security best practices AlgoSec and hybrid cloud security Get the latest insights from the experts Learn how AlgoSec can help you pass PCI-DSS Audits and ensure continuous Solution Overview Use these six best practices to simplify compliance and risk Case study See how this customer improved compliance readiness and risk Case study 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

Challenges with managing Cisco Meraki in a complex enterprise environment We have worked closely with Cisco for many years in large complex environments and have developed integrations to support a variety of Cisco solutions for our joint customers. In recent years we have seen an increased interest in the use of Cisco Meraki devices by enterprises that are also AlgoSec customers. In this post, we will highlight some of the AlgoSec capabilities that can quickly add value for Meraki... Application Connectivity Management Managing the switch – Making the move to Cisco Meraki Jeremiah Cornelius 2 min read Jeremiah Cornelius Short bio about author here Lorem ipsum dolor sit amet consectetur. Vitae donec tincidunt elementum quam laoreet duis sit enim. Duis mattis velit sit leo diam. Tags Share this article 1/4/24 Published Challenges with managing Cisco Meraki in a complex enterprise environment We have worked closely with Cisco for many years in large complex environments and have developed integrations to support a variety of Cisco solutions for our joint customers. In recent years we have seen an increased interest in the use of Cisco Meraki devices by enterprises that are also AlgoSec customers. In this post, we will highlight some of the AlgoSec capabilities that can quickly add value for Meraki customers. Meeting the Enterprise The Cisco Meraki MX is a multifunctional security and SD-WAN enterprise appliance with a wide set of capabilities to address multiple use cases—from an all-in-one device. Organizations across all industries rely on the MX to deliver secure connectivity to hub locations or multi cloud environments. The MX is 100% cloud-managed, so installation and remote management are truly zero-touch, making it ideal for distributed branches, campuses, and data center locations. In our talks with AlgoSec customers and partner architects, it is evident that the benefits that originally made Meraki MX popular in commercial deployments were just as appealing to enterprises. Many enterprises are now faced with waves of expansion in employees working from home, and burgeoning demands for scalable remote access – along with increasing network demands by regional centers. The leader of one security team I spoke with put it very well, “We are deploying to 1,200 locations in four global regions, planned to be 1,500 by year’s end. The choice of Meraki is for us a ‘no-brainer.’ If you haven’t already, I know that you’re going to see this become a more popular option with many big operations.” Natural Companions – AlgoSec ASMS and Cisco Meraki-MX This is a natural situation to meet enhanced requirements with AlgoSec ASMS — reinforcing Meraki’s impressive capabilities and scale as a combined, enterprise-class solution. ASMS brings to the table traffic planning and visualization, rules optimization and management, and a solution to address enterprise-level requirements for policy reporting and compliance auditing. In AlgoSec, we’re proud of AlgoSec Horizon FireFlow’s ability to model the security-connected state of any given endpoints across an entire enterprise. Now our customers with Meraki MX can extend this technology that they know and trust, analyze real traffic in complex deployments, and acquire an understanding of the requirements and impact of changes delivered to their users and applications that are connected by Meraki deployments. As it’s unlikely that your needs, or those of any data center and enterprise, are met by a single vendor and model, AlgoSec unifies operations of the Meraki-MX with those of the other technologies, such as enterprise NGFW and software-defined network fabrics. Our application-centric approach means that Meraki MX can be a component in delivering solutions for zero-trust and microsegmentation with other Cisco technology like Cisco ACI, and other third parties. Cisco Meraki– Product Demo If all of this sounds interesting, take a look for yourself to see how AlgoSec helps with common challenges in these enterprise environments. More Where This Came From The AlgoSec integration with Cisco Meraki-MX is delivering solutions our customers want. If you want to discover more about the Meraki and AlgoSec joint solution, contact us at AlgoSec! We work together with Cisco teams and resellers and will be glad to schedule a meeting to share more details or walk through a more in depth demo. Schedule a demo Related Articles Q1 at AlgoSec: What innovations and milestones defined our start to 2026? AlgoSec Reviews Mar 19, 2023 · 2 min read 2025 in review: What innovations and milestones defined AlgoSec’s transformative year in 2025? AlgoSec Reviews Mar 19, 2023 · 2 min read Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read Speak to one of our experts Speak to one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Schedule a call

Last week our CTO, Professor Avishai Wool, presented a technical webinar on the do’s and don’ts for managing external connectivity to and... Auditing and Compliance 4 tips to manage your external network connections Joanne Godfrey 2 min read Joanne Godfrey 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/10/15 Published Last week our CTO, Professor Avishai Wool, presented a technical webinar on the do’s and don’ts for managing external connectivity to and from your network . We kicked off our webinar by polling the audience (186 people) on how many external permanent connections into their enterprise network they have. 40% have less than 50 external connections 31% have 50-250 external connections 24% have more than 250 external connections 5% wish they knew how many external connections they have! Clearly this is a very relevant issue for many enterprises, and one which can have a profound effect on security. The webinar covered a wide range of best practices for managing the external connectivity lifecycle and I highly recommend that you view the full presentation. But in the meantime, here are a few key issues that you should be mindful of when considering how to manage external connectivity to and from your network: Network Segmentation While there has to be an element of trust when you let an external partner into your network, you must do all you can to protect your organization from attacks through these connections. These include placing your servers in a demilitarized zone (DMZ), segregating them by firewalls, restricting traffic in both directions from the DMZ as well as using additional controls such as web application firewalls, data leak prevention and intrusion detection. Regulatory Compliance Bear in mind that if the data being accessed over the external connection is regulated, both your systems and the related peer’s systems are now subject t. So if the network connection touches credit card data, both sides of the connection are in scope, and outsourcing the processing and management of regulated data to a partner does not let you off the hook. Maintenance Sometimes you will have to make changes to your external connections, either due to planned maintenance work by your IT team or the peer’s team, or as a result of unplanned outages. Dealing with changes that affect external connections is more complicated than internal maintenance, as it will probably require coordinating with people outside your organisation and tweaking existing workflows, while adhering to any contractual or SLA obligations. As part of this process, remember that you’ll need to ensure that your information systems allow your IT teams to recognize external connections and provide access to the relevant technical information in the contract, while supporting the amended workflows. Contracts In most cases there is a contract that governs all aspects of the external connection – including technical and business issues. The technical points will include issues such as IP addresses and ports, technical contact points, SLAs, testing procedures and the physical location of servers. It’s important, therefore, that this contract is adhered to whenever dealing with technical issues related to external connections. These are just a few tips and issues to be aware of. To watch the webinar from Professor Wool in full, check out the recording 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

Security Policy Management with Professor Wool Network Security for VMware NSX Network Security for VMware NSX with Professor Wool is a whiteboard-style series of lessons that examine the some of the challenges of and provide technical tips for managing security policies across the VMware NSX software-defined data center and traditional data center. Lesson 1 VMware’s NSX enables datacenter owners to secure East-West traffic using filtering policies that are enforced by the VMware infrastructure. However, migrating from existing traditional filtering technologies to VMware NSX can be a daunting task. In this lesson Professor will discuss why it’s important to understand the motivations for a migration to NSX in order to successfully plan and implement the actual migration to the VMware NSX platform. Migrating to NSX: Understanding the Why in Order to Figure Out the How Watch Lesson 2 When setting up an NSX data center you need to write filtering policies for any traffic that goes into an NSX data center, exits from it, or moves between different servers inside the NSX data center. In this lesson, Professor Wool recommends a multi-stage process to help users write secure and effective policies for east East-West traffic. Tips on How to Create Filtering Policies for NSX Watch Lesson 3 Once the NSX environment is up and running it needs to be part of the organization’s network security policy change process, and subject to the organization’s governance, audit, and regulatory compliance requirements. In this lesson Professor Wool discusses how to approach managing changes, auditing and compliance when the security team doesn’t ‘own’ the virtual environment. Best Practices for Bringing NSX Security Policy Management into the InfoSec Fold Watch Have a Question for Professor Wool? Ask him now 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

AlgoSec’s latest product release delivers automated application connectivity and security policy changes, deepens application visibility and discovery, and extends application risk analysis across multi-clouds and hybrid environments. Securely Accelerate Application Delivery and Policy Management with AlgoSec ASMS A32.10 AlgoSec’s latest product release delivers automated application connectivity and security policy changes, deepens application visibility and discovery, and extends application risk analysis across multi-clouds and hybrid environments. September 8, 2021 Speak to one of our experts RIDGEFIELD PARK, N.J., September 8, 2021 – AlgoSec , the application connectivity and security policy company, has introduced enhanced automated application connectivity and security policy changes, and deepened application visibility and discovery, in the latest version of its Network Security Management Solution. AlgoSec Security Management Suite (ASMS) A32.10 builds on previous versions to give IT and security experts the most comprehensive visibility and control over security across their entire hybrid environment. With A32.10, organizations can align network security with their overall business objectives, automating the process in a single platform for a seamless, zero-touch experience. The key benefits that AlgoSec ASMS A32.10 delivers to IT, network and security experts include: Intelligent application connectivity in SDNs and the cloud AlgoSec ASMS A32.10 introduces intelligent application connectivity management and enhanced security policy automation to leading SDN and cloud platforms, including VMware’s NSX-T. It also extends support for MSO-managed Cisco ACI devices, Cisco’s leading SDN platform. Application discovery and visibility across hybrid networks With A32.10 enterprises can use traffic logs to automatically discover applications on the network, providing enriched mapping across hybrid network estates. It provides a seamless and complete picture of the network across multiple public clouds including Google Cloud (GCP) and AWS Transit Gateway as well as Check Point R80 Inline and Ordering Layers. Extended application risk analysis A32.10 extends cloud risk management with new risk triggers of interest and unique filtering capabilities. When using A32.10, VMware NSX-T users can receive risk notifications, so they are aware of the potential compliance violations introduced by applications. “In this fast pace era of digital transformation, speed is of the essence. Unfortunately, many organizations confuse this for agility and take too many risks with their security, leaving them vulnerable to attack.” said Eran Shiff, Vice President, Product, of AlgoSec. “A32.10 makes it easier for organizations to securely accelerate application connectivity, enabling them to move fast across multi-cloud and hybrid environments and stay ahead of security threats, increasing business agility and compliance.” AlgoSec ASMS A32.10 is generally available. About AlgoSec AlgoSec, a global cybersecurity leader, empowers organizations to securely accelerate application delivery by automating application connectivity and security policy, anywhere. The AlgoSec platform enables the world’s most complex organizations to gain visibility, reduce risk and process changes at zero-touch across the hybrid network. AlgoSec’s patented application-centric view of the hybrid network enables business owners, application owners, and information security professionals to talk the same language, so organizations can deliver business applications faster while achieving a heightened security posture. Over 1,800 of the world’s leading organizations trust AlgoSec to help secure their most critical workloads across public cloud, private cloud, containers, and on-premises networks, while taking advantage of almost two decades of leadership in Network Security Policy Management. See what securely accelerating your digital transformation, move-to-cloud, infrastructure modernization, or micro-segmentation initiatives looks like at www.algosec.com Media Contacts: Tsippi Dach AlgoSec tsippi.dach@algosec.com Jenni Livesley Context Public Relations algosec@contextpr.co.uk +44(0)300 124 6100

Prediction over reaction WhitePaper 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

In today’s evolving threat landscape, Zero Trust Architecture has emerged as a significant security framework for organizations. One... Zero Trust Zero Trust Design Nitin Rajput 2 min read Nitin Rajput 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 5/18/24 Published In today’s evolving threat landscape, Zero Trust Architecture has emerged as a significant security framework for organizations. One influential model in this space is the Zero Trust Model, attributed to John Kinderbag. Inspired by Kinderbag’s model, we explore how our advanced solution can effectively align with the principles of Zero Trust. Let’s dive into the key points of mapping the Zero Trust Model with AlgoSec’s solution, enabling organizations to strengthen their security posture and embrace the Zero Trust paradigm. My approach of mapping Zero Trust Model with AlgoSec solution is based on John Kinderbag’s Zero Trust model ( details ) which being widely followed, and I hope it will help organizations in building their Zero trust strategy. Firstly, let’s understand what Zero trust is all about in a simple language. Zero Trust is a Cybersecurity approach that articulates that the fundamental problem we have is a broken trust model where the untrusted side of the network is the evil internet, and the trusted side is the stuff we control. Therefore, it is an approach to designing and implementing a security program based on the notion that no user or device or agent should have implicit trust. Instead, anyone or anything, a device or system that seeks access to corporate assets must prove it should be trusted. The primary goal of Zero Trust is to prevent breaches. Prevention is possible. In fact, it’s more cost effective from a business perspective to prevent a breach than it is to attempt to recover from a breach, pay a ransom, and the deal with the costs of downtime or lost customers. As per John Kinderbag, there are Four Zero Trust Design Principles and Five-Step Zero Trust Design Methodology. The Four Zero Trust Design Principles: The first and the most important principle of your Zero Trust strategy is know “What is the Business trying to achieve?”. Second, start with DAAS (Data, Application, Asset and Services) elements and protect surfaces that need protection and design outward from there. Third, determine who needs to have access to a resource in order to get their job done, commonly known as least privilege. Fourth, all the traffic going to and from a protect surface must be inspected and logged for malicious content. Define Business Outcomes Design from the inside out Determine who or what needs access Inspect and log all traffic The Five-Step Zero Trust Design Methodology To make your Zero trust journey achievable, you need a repeatable process to follow. The first step in the Zero trust is to break down your environment into smaller pieces that you need to protect (protect surfaces). The second step for deploying Zero Trust in each protect surfaces is to map the transactions flows so that we can allow only the ports and the address needed and nothing else. Everyone wants to know what products to buy to do Zero trust or to eliminate trust between digital systems, the truth is that you won’t know the answer to that until you’ve gone through the process. Which brings us to the third step in the methodology: architecting the Zero trust environment. Ultimately, we need to instantiate Zero Trust as a Layer 7 policy statement. Use the Kipling Method of Zero Trust policy writing to determine who or what can access your protect surface. The fifth design principle of Zero Trust is to inspect and log all traffic, for monitor and maintain, one needs to take all of the telemetry – whether it’s from a network detection and response tool, or from firewall or server application logs and then learn from them. As you learn over time, you can make security stronger and stronger. Define the protect surface Map the transaction flows Architect a Zero trust environment Create Zero trust policies Monitor and maintain. How AlgoSec aligns with “Map the transaction Flows” the 2nd step of Design Methodology? AlgoSec Auto-Discovery. analyses your traffic flows, turning them into a clear map. AutoDiscovery receives network traffic metadata as NetFlow, SFLOW, or full packets and then digest multiple streams of traffic metadata to let you clearly visualize your transaction flows. Once the transaction flows are discovered and optimized, the system keeps tracking changes in these flows. Once new flows are discovered in the network, the application description is updated with the new flows. Outcome: Clear visualization of transaction flows. Updated application description. Optimized transaction flows. How AlgoSec aligns with “Architect Zero Trust Policies” – the 4th step of Design Methodology? With AlgoSec, you can automate the security policy change process without introducing any element of risk, vulnerability, or compliance violation. AlgoSec allows you to ingest the discovered transaction flows as a Traffic Change request and analyze those traffic changes before they are implemented all the to your Firewalls, Public Cloud and SDN Solutions and validate successful changes as intended, all within your existing IT Service Management (ITSM) solutions. Outcome: Analyzed traffic changes for implementation. Implemented security policy changes without risk, vulnerability, or compliance violations. How Algosec aligns with “Monitor and maintain” – the 5th step of Design Methodology? AlgoSec analyzes security by analyzing firewall policies, firewall rules, firewall traffic logs and firewall change configurations. Detailed analysis of the security logs offers critical network vital intelligence about security breaches and attempted attacks like virus, trojans, and denial of service among others. With AlgoSec traffic flow analysis, you can monitor traffic within a specific firewall rule. You do not need to allow all traffic to traverse in all directions but instead, you can monitor it through the pragmatic behaviors on the network and enable network firewall administrators to recognize which firewall rules they can create and implement to allow only the necessary access. Outcome: Critical network intelligence, identification of security breaches and attempted attacks. Enhanced firewall rule creation and implementation, allowing only necessary access. 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

Hospitals are increasingly becoming a favored target of cyber criminals. Yet if you think about medical equipment that is vulnerable to... Cyber Attacks & Incident Response Checking the cybersecurity pulse of medical devices 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 6/14/16 Published Hospitals are increasingly becoming a favored target of cyber criminals. Yet if you think about medical equipment that is vulnerable to being hacked at a hospital, you might not immediately think of high-end, critical equipment such as MRI and X-ray scanners, and nuclear medicine devices. After all, these devices go through rigorous approval processes by the US Food & Drug Administration (FDA) before they are approved for safe use on patients. Yet today many, if not most, medical devices, have computers embedded in them, are connected to the hospital network, and often to the internet as well, so they provide a potential attack vector for cyber criminals. In late 2015 security researchers found that thousands of medical devices were vulnerable to attack and exposed to the public Internet. Interestingly, these researchers also found that many of the devices in question were running Windows XP – which is no longer supported or updated by Microsoft – and did not run antivirus software to protect them against malware. This combination raises an obvious security red flag. Ironically, these security vulnerabilities were further exacerbated because of the very FDA approvals process that certifies the devices. The approval process is, quite rightly, extremely rigorous. It is also lengthy and expensive. And if a manufacturer or vendor makes a change to a device, it needed to be re-certified. Until very recently, a ‘change’ to a medical device meant any sort of change – including patching devices’ operating systems and firmware to close off potential network security vulnerabilities. You can see where this is going: making simple updates to medical equipment to improve its defenses against cyberattacks was made that much more difficult and complex for the device manufacturers, because of the need for FDA re-certification every time a change was made. And of course, this potential delay in patching vulnerabilities made it easy for a hacker to try and ‘update’ the device in his own way, for criminal purposes. Hackers are usually not too concerned about getting FDA approval for their work. Fortunately, the FDA released new guidelines last year that allowed equipment manufacturers to patch software as required without undergoing re-certification—provided the change or modification does not ‘significantly affect the safety or effectiveness of the medical device’. That’s good news – but it’s not quite the end of the story. The FDA’s guidelines are only a partial panacea to the overall problem. They overlook the fact that many medical devices are running obsolete operating systems like Windows XP. What’s more, the actual process of applying patches to the computers in medical devices can vary enormously from manufacturer to manufacturer, with some patches needing to be downloaded and applied manually, while others may be pushed automatically. In either case, there could still be a window of weeks, months or even years before the device’s vendor issues a patch for a given vulnerability – a window that a hacker could exploit before the hospital’s IT team becomes aware that the vulnerability exists. This means that hospitals need to take great care when it comes to structuring and segmenting their network . It is vital that connected medical devices – particularly those where the internal OS may be out of date – are placed within defined, segregated segments of the network, and robustly protected with next-generation firewalls, web proxies and other filters. While network segmentation and filtering will not protect unpatched or obsolete operating system, they will ensure that the hospital’s network is secured to the best of its ability . Schedule a demo Related Articles Q1 at AlgoSec: What innovations and milestones defined our start to 2026? AlgoSec Reviews Mar 19, 2023 · 2 min read 2025 in review: What innovations and milestones defined AlgoSec’s transformative year in 2025? AlgoSec Reviews Mar 19, 2023 · 2 min read Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read Speak to one of our experts Speak to one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Schedule a call

As cloud adoption and digital transformation increases, more sensitive data from applications is being stored in data containers. This is... Application Connectivity Management How to Make Container Security Threats More Containable 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 9/8/22 Published As cloud adoption and digital transformation increases, more sensitive data from applications is being stored in data containers. This is why effective container security controls to securely manage application connectivity is an absolute must. AlgoSec CTO and Co-Founder, Prof. Avishai Wool provides some useful container security best practices to help you do just that. What is Container Security? Organizations, now more than ever, are adopting container technology. Instead of powering up servers and instances in the cloud, they are using containers to run business applications. Securing these is equally as important as securing other digital assets that the business is dependent on. There are two main pillars to think about: The code: you want to be able to scan the containers and make sure that they are running legitimate code without any vulnerabilities. The network: you need to control access to and from the container (what it can connect to), both inside the same cluster, other clusters, and different parts of the network. How critical is container security to managing application connectivity risks? To understand the role of container security within the overall view of network security, there are three points to consider. First, if you’re only concerned about securing the containers themselves, then you’re looking at nano-segmentation , which involves very granular controls inside the applications. Second, if you’re thinking about a slightly wider scope then you may be more concerned with microsegmentation , where you are segmenting between clusters or between servers in a single environment. Here you will want to enforce security controls that determine the allowable communication between specific endpoints at specific levels. Finally, if the communication needs to go further, from a container inside one cluster within one cloud environment to an asset that’s outside of the data center, then that might need to go through broader segmentation controls such as zoning technologies, security groups or a firewall at the border. So, there are all these layers where you can place network security policies. When you’re looking at a particular connectivity request (say for a new version of an application) from the point of view of a given container you should ask yourself: what is the container connected to? What is it communicating with? Where are those other sides of the connectivity placed? Based on that determination, you will then know which security controls you need to configure to allow that connectivity through the network. How does containerization correlate with application centric security policy management? There are a number of different aspects to the relationship between container security and application security. If an application uses containers to power up workloads then container security is very much an integral part of application security. When you’re adding new functionality to an application, powering up additional containers, asking containers to perform new tasks whereby they need to connect to additional assets, then the connectivity of those containers needs to be secured. And security controls need to be regulated or changed based on what the application needs them to do. Another factor in this relationship is the structure of the application. All the containers that run and support the application are often located in one cluster or a micro-segment of the network. So, much of the communication takes place inside that cluster, between one container or another, all in the same cluster. However, some of it can go to another cluster or somewhere that’s not even containerized. This is actually a good thing from an application point of view as the container structure can be used to understand the application structure as well. Not sure about container orchestration? Here’s what to know Container orchestration is part of a bigger orchestration play which is, in general, related to the concept of infrastructure as code. You want to be able to power up an environment with all the assets it requires, and have it function simultaneously so you can duplicate it. There are various orchestration technologies that can be used to deploy the security policies for containers , which is an excellent way to maintain container-based applications in a consistent and repeatable manner. Then if you need to double it or multiply it by 100, you can get cookie-cutter copies of the same thing. How will container security solutions play out in the future? Organizations today have the technology to enforce security controls at the container level, but these controls are very granular and it’s time-consuming to set policies and enforce them, particularly with issues like staff or skills shortages. Looking ahead, companies are likely to take a hierarchical view where container-based security is controlled at the application level by app owners or developers, and at the broader levels to ensure that the measures deployed throughout the network have the same degree of sophistication. Procedures and tooling are all evolving, so we don’t have a definitive answer as to how this will all end up. What are organizations going to be doing? Where will they place their controls? Who has the power to make the changes? When newer technologies are deployed, customer adoption will be crucial to understanding what makes the most sense. This will be interesting as there will be multiple scenarios to help companies master their security blueprint as we move forward. To learn how the use of containerization as a strategy can help reduce risk and drive application-centric security, check out this video . Schedule a demo Related Articles Q1 at AlgoSec: What innovations and milestones defined our start to 2026? AlgoSec Reviews Mar 19, 2023 · 2 min read 2025 in review: What innovations and milestones defined AlgoSec’s transformative year in 2025? AlgoSec Reviews Mar 19, 2023 · 2 min read Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read Speak to one of our experts Speak to one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Schedule a call