Search results

Yitzy Tannenbaum, Product Marketing Manager at AlgoSec, discusses how AWS customers can leverage AlgoSec for AWS to easily migrate... Uncategorized Migrating to AWS in six simple steps Yitzy Tannenbaum 2 min read Yitzy Tannenbaum 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 Yitzy Tannenbaum, Product Marketing Manager at AlgoSec, discusses how AWS customers can leverage AlgoSec for AWS to easily migrate applications Public cloud platforms bring a host of benefits to organizations but managing security and compliance can prove complex. These challenges are exacerbated when organizations are required to manage and maintain security across all controls that make up the security network including on-premise, SDN and in the public cloud. According to a Gartner study , 81% of organizations are concerned about security, and 57% about maintaining regulatory compliance in the public cloud. AlgoSec’s partnership with AWS helps organizations overcome these challenges by making the most of AWS’ capabilities and providing solutions that complement the AWS offering, particularly in terms of security and operational excellence. And to make things even easier, AlgoSec is now available in AWS Marketplace. Accelerating complex application migration with AlgoSec Many organizations choose to migrate workloads to AWS because it provides unparalleled opportunities for scalability, flexibility, and the ability to spin-up new servers within a few minutes. However, moving to AWS while still maintaining high-level security and avoiding application outages can be challenging, especially if you are trying to do the migration manually, which can create opportunities for human error. We help simplify the migration to AWS with a six-step automated process, which takes away manual processes and reduces the risk of error: Step 1 – AlgoSec automatically discovers and maps network flows to the relevant business applications. Step 2- AlgoSec assesses the changes in the application connectivity required to migrate it to AWS. Step 3- AlgoSec analyzes, simulates and computes the necessary changes, across the entire hybrid network (over firewalls, routers, security groups etc.), including providing a what-if risk analysis and compliance report. Step 4- AlgoSec automatically migrates the connectivity flows to the new AWS environment. Step 5 – AlgoSec securely decommissions old connectivity. Step 6- The AlgoSec platform provides ongoing monitoring and visibility of the cloud estate to maintain security and operation of policy configurations or successful continuous operation of the application. Gain control of hybrid estates with AlgoSec Security automation is essential if organizations are to maintain security and compliance across their hybrid environments, as well as get the full benefit of AWS agility and scalability. AlgoSec allows organizations to seamlessly manage security control layers across the entire network from on-premise to cloud services by providing Zero-Touch automation in three key areas. First, visibility is important, since understanding the network we have in the cloud helps us to understand how to deploy and manage the policies across the security controls that make up the hybrid cloud estate. We provide instant visibility, risk assessment and compliance, as well as rule clean-up, under one unified umbrella. Organizations can gain instant network visibility and maintain a risk-free optimized rule set across the entire hybrid network – across all AWS accounts, regions and VPC combinations, as well as 3rd party firewalls deployed in the cloud and across the connection to the on-prem network. Secondly, changes to network security policies in all these diverse security controls can be managed from a single system, security policies can be applied consistently, efficiently, and with a full audit trail of every change. Finally, security automation dramatically accelerates change processes and enables better enforcement and auditing for regulatory compliance. It also helps organizations overcome skill gaps and staffing limitations. Why Purchase Through AWS Marketplace? AWS Marketplace is a digital catalog with thousands of software listings from independent software vendors (ISVs). It makes it easy for organizations to find, test, buy, and deploy software that runs on Amazon Web Services (AWS), giving them a further option to benefit from AlgoSec. The new listing also gives organizations the ability to apply their use of AlgoSec to their AWS Enterprise Discount Program (EDP) spend commitment. With the addition of AlgoSec in AWS Marketplace, customers can benefit from simplified sourcing and contracting as well as consolidated billing, ultimately resulting in cost savings. It offers organizations instant visibility and in-depth risk analysis and remediation, providing multiple unique capabilities such as cloud security group clean-ups, as well as central policy management. This strengthens enterprises’ cloud security postures and ensures continuous audit-readiness. Ready to Get Started? The addition of AlgoSec in AWS Marketplace is the latest development in the relationship between AlgoSec and AWS and is available for businesses with 500 or more users. Visit the AlgoSec AWS Marketplace listing for more information or contact us to discuss it further. Schedule a demo Related Articles Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read 5 Multi-Cloud Environments Cloud Security Mar 19, 2023 · 2 min read Convergence didn’t fail, compliance did. Mar 19, 2023 · 2 min read Speak to one of our experts Speak to one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Schedule a call

Problems with firewalls can be quite disastrous to your operations. When firewall rules are not set properly, you might deny all... Firewall Change Management Firewall troubleshooting steps & solutions to common issues 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/10/23 Published Problems with firewalls can be quite disastrous to your operations. When firewall rules are not set properly, you might deny all requests, even valid ones, or allow access to unauthorized sources. There needs to be a systematic way to troubleshoot your firewall issues, and you need to have a proper plan. You should consider security standards, hardware/software compatibility, security policy planning , and access level specifications. It is recommended to have an ACL (access control list) to determine who has access to what. Let us give you a brief overview of firewall troubleshooting best practices and steps to follow. Common firewall problems With the many benefits that firewalls bring, they might also pop out some errors and issues now and then. You need to be aware of the common issues, failures, and error codes to properly assess an error condition to ensure the smooth working of your firewalls. Misconfiguration errors A report by Gartner Research says that misconfiguration causes about 95% of all firewall breaches. A simple logical flaw in a firewall rule can open up vulnerabilities, leading to serious security breaches. Before playing with your firewall settings, you must set up proper access control settings and understand the security policy specifications. You must remember that misconfiguration errors in CLI can lead to hefty fines for non-compliance, data breaches , and unnecessary downtimes. All these can cause heavy monetary damages; hence, you should take extra care to configure your firewall rules and settings properly. Here are some common firewall misconfigurations: Allowing ICMP and making the firewall available for ping requests Providing unnecessary services on the firewall Allowing unused TCP/UDP ports The firewall is set to return a ‘deny’ response instead of a ‘drop’ for blocked ports. IP address misconfigurations that can allow TCP pinging of internal hosts from external devices. Trusting DNS and IP addresses that are not properly checked and source verified. Check out AlgoSec’s firewall configuration guide for best practices. Hardware issues Hardware bottlenecks and device misconfigurations can easily lead to firewall failures. Sometimes, running a firewall 24/7 can overload your hardware and lead to a lowered network performance of your entire system. You should look into the performance issues and optimize firewall functionalities or upgrade your hardware accordingly. Software vulnerabilities Any known vulnerability with your firewall software must be dealt with immediately. Hackers can exploit software vulnerabilities easily to gain backdoor entry into your network. So, stay current with all the patches and updates your software vendors provide. Types of firewall issues Most firewall issues can be classified as either connectivity or performance issues. Here are some tools you can use in each of these cases: Connectivity Issues Some loss of access to a network resource or unavailability usually characterizes these issues. You can use network connectivity tools like NetStat to monitor and analyze the inbound TCP/UDP packets. Both these tools have a wide range of sub-commands and tools that help you trace IP network traffic and control the traffic as per your requirements. Firewall Performance Issues As discussed earlier, performance issues can cause a wide range of issues, such as unplanned downtimes and firewall failures, leading to security breaches and slow network performance. Some of the ways you can rectify it include: Load balancing by regulating the outbound network traffic by limiting the internal server errors and streamlining the network traffic. Filtering the incoming network traffic with the help of Standard Access Control List filters. Simplifying firewall rules to reduce the load on the firewall applications. You can remove unused rules and break down complex rules to improve performance. Firewall troubleshooting checklist steps Step 1. Audit your hardware & software Create a firewall troubleshooting checklist to check your firewall rules, software vulnerabilities, hardware settings, and more based on your operating system. This should include all the items you should cover as part of your security policy and network assessment. With Algosec’s policy management , you can ensure that your security policy is complete, comprehensive and does not miss out on anything important. Step 2. Pinpoint the Issue Check what the exact issue is. Generally, a firewall issue can arise from any of the three conditions: Access from external networks/devices to protected resources is not functioning properly Access from the protected network/resources to unprotected resources is not functioning properly. Access to the firewall is not functioning properly. Step 3. Determine the traffic flow Once you have ascertained the exact access issue, you should check whether the issue is raised when traffic is going to the firewall or through the firewall. Once you have narrowed down this issue, you can test the connectivity accordingly and determine the underlying cause. Check for any recent updates and try to roll back if that can solve the issue. Go through your firewall permissions and logs for any error messages or warnings. Review your firewall rules and configurations and adjust them for proper working. Depending upon your firewall installation, you can make a checklist of items. Here is a simple guide you can follow to conduct routine maintenance troubleshooting . Monitor the network, test it out, and repeat the process until you reach a solution. Firewall troubleshooting best practices Here are some proven firewall troubleshooting tips. For more in-depth information, check out our Network Security FAQs page. Monitor and test Regular auditing and testing of your Microsoft firewall can help you catch vulnerabilities early and ensure good performance throughout the year. You can use expert-assisted penetration testing to get a good idea of the efficacy of your firewalls. Also be sure to check out the auditing services from Algosec , especially for your PCI security compliance . Deal with insider threats While a Mac or Windows firewall can help you block external threats to an extent, it can be powerless regarding insider attacks. Make sure you enforce strong security controls to avoid any such conditions. Your security policies must be crafted well to avoid any room for such conditions, and your access level specifications should also be well-defined. Device connections Make sure to pay attention to the other modes of attack that can happen besides a network access attempt. If an infected device such as a USB, router, hard drive, or laptop is directly connected to your system, your network firewall can do little to prevent the attack. So, you should put the necessary device restrictions in your privacy statement and the firewall rules. Review and Improve Update your firewall rules and security policies with regular audits and tests. Here are some more tips you can follow to improve your firewall security: Optimize your firewall ruleset to allow only necessary access Use unique user IP instead of a root ID to launch the firewall services Make use of a protected remote Syslog server and keep it safe from unauthorized access Analyze your firewall logs regularly to identify and detect any suspicious activity. You can use tools like Algosec Firewall Analyzer and expert help to analyze your firewall as well. Disable FTP connections by default Setup strict controls on how and which users can modify firewall configurations. Include both source and destination IP addresses and the ports in your firewall rules. Document all the updates and changes made to your firewall policies and rules. In the case of physical firewall implementations, restrict the physical access as well. Use NAT (network address translation) to map multiple private addresses to a public IP address before transmitting the information online. How does a firewall actually work? A Windows firewall is a network security mechanism that allows you to restrict incoming network traffic to your systems. It can be implemented as a hardware, software, or cloud-based security solution . It acts as a barrier stopping unauthorized network access requests from reaching your internal network and thus minimizing any attempt at hacking or breach of confidential data . Based on the type of implementation and the systems it is protecting, firewalls can be classified into several different types. Some of the common types of firewalls are: Packet filtering – Based on the filter standards, a small amount of incoming data is analyzed and subjected to restriction on distribution across the network. Proxy service – An application layer service that acts as an intermediary between the actual servers to block out unauthorized access requests. Stateful inspection – A dynamic packet filtering mechanism that filters out the network packets. Next-Generation Firewall (NGFW) – A combination of deep packet inspection and application level inspection to block out unauthorized access into the network. Firewalls are essential to network security at all endpoints, whether personal computers or full-scale enterprise data centers. They allow you to set up strong security controls to prevent a wide range of cyberattacks and help you gain valuable data. Firewalls can help you detect suspicious activities and prevent intrusive attacks at the earliest. They can also help you regulate your incoming and outgoing traffic routing, helping you implement zero-trust security policies and stay compliant with security and data standards. Schedule a demo Related Articles Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read 5 Multi-Cloud Environments Cloud Security Mar 19, 2023 · 2 min read Convergence didn’t fail, compliance did. Mar 19, 2023 · 2 min read Speak to one of our experts Speak to one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Schedule a call

Six levels of automation Download PDF Schedule time with one of our experts Schedule time with one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Continue

Jeremiah Cornelius, Technical Leader for Alliances and Partners at AlgoSec, explores the security capability native to VMware’s approach... Digital Transformation Intrinsic Transformation: VMware NSX-T and AlgoSec Go Beyond Virtualization 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 7/8/21 Published Jeremiah Cornelius, Technical Leader for Alliances and Partners at AlgoSec, explores the security capability native to VMware’s approach for virtual networking with NSX-T. Intrinsic transformation NSX-T culminates VMware’s decade of development of these technologies, that better align than ever before with AlgoSec’s approach for software automation of micro-segmentation and compliant security operations management. It is the latest iteration of VMware’s approach to networking and security, derived from many years as a platform for operating virtual machines, and managing these as hosted “vApp” workloads. If you’re familiar with the main players in Software Defined Networking, then you may remember that NSX-T shares its origin in the same student research at Stanford University, which also gave rise to several other competing SDN offerings. One thing that differentiated VMware from other players was their strong focus on virtualization over traditional network equipment stacks. This meant in some cases, network connections, data-packets, forwarding, and endpoints all existing in software and no “copper wire” existing anywhere! Knowing about this difference is more than a bit of trivia — it explains how the NSX family was designed with security features built into the architecture, having native capability for software security controls such as firewall segmentation and packet inspection. Described by VMware as “Intrinsic Security,” these are NSX capabilities that first drove the widespread acceptance of practical micro-segmentation in the data center. Since that first introduction of NSX micro-segmentation, a transformation occurred in customer demands, which required an expansion of VMware’s universe to horizons beyond their hypervisor and virtual machines. As a key enabler for this expansion, NSX-T has emerged as a networking and security technology that extends from serverless micro-services and container frameworks to VMs hosted on many cloud architectures located in physical data centers or as tenants in public clouds. The current iteration is called the NSX-T Service-Defined Firewall, which controls access to applications and services along with business-focused policies. Leaders in our segments If you’ve followed this far along, then maybe you’ve recognized several common themes between AlgoSec’s Security Management Suite and VMware’s NSX-T. Among these are security operations management as software configuration, modeling connectivity on business uses versus technology conventions, and transforming security into an enabling function. It’s not a surprise then, to know that our companies are technology partners. In fact, we began our alliance with VMware back in 2015 as the uptake in NSX micro-segmentation began to reveal an increased need for visibility, planning, automation, and reporting — along with requirements for extending policy from NSX objects to attached physical security devices from a variety of vendors. The sophistication and flexibility of NSX enforcement capability were excellently matched by the AlgoSec strengths in identifying risk and maintaining compliance while sustaining a change management record of configurations from our combined workflow automation. Strength to strength Up until now, this is a rosy picture painted, with an emphasis on the upsides of the AlgoSec partnership with VMware NSX-T. In the real world, we find that many of our applications are not-so-well understood as to be ready for micro-segmentation. More often, the teams responsible for the availability and security of these applications are detached from the business intent and value, further making it difficult to assess and therefore address risks. The line between traditional-style infrastructure and modern services isn’t always as clearly defined, either — making the advantages possible by migration and transformation difficult to determine and potentially introducing their own risks. It is in these environments, with multiple technologies, different stakeholders, and operation teams with different scopes, that AlgoSec solves hard problems with better automation tools. Taking advantage of NSX-T means first being faced with multiple deployment types, including public and private clouds as well as on-prem infrastructure, multiple security vendors, unclear existing network flows, and missing associations between business applications and their existing controls. These are visibility issues that AlgoSec resolves by automating the discovery and mapping of business applications , including associated policies across different technologies, and producing visual, graphic analysis that includes risk assessment and impact of changes. This capability for full visibility leads directly to addressing the open issues for risk and compliance. After all, if these present challenges in discovering and identifying risk using existing technology solutions, then there’s a big gap to close on the way to transforming these. Since AlgoSec has addressed the visibility across these, identifying risk becomes uniform and manageable. AlgoSec can lower transformation risk with NSX-T while ensuring that risk and compliance management are maintained on an ongoing basis. Workflow for risk mitigation by NSX-T intrinsic security can be driven by AlgoSec policy automation, without recourse to multiple tools when these mitigations need to cross boundaries to third-party firewalls or cloud security controls. With this integrated policy automation, what were once point-in-time configurations can be enabled for discovery-based updates for internal standards and changes to regulatory mandates. The result of AlgoSec pairing with VMWare NSX-T is a simplified overall security architecture — one that more rapidly responds to emerging risk and requests for changes, accelerates the speed of operations while more closely aligning with business, and ensures both compliant configurations and compliant lifecycle operations. VMware NSX? Ask AlgoSec The AlgoSec integration with VMware NSX-T builds on our years of collaboration with earlier versions of the NSX platform, with a track record of solving the more difficult configuration management problems for leaders of principal industries around the globe. If you want to discover more about what AlgoSec does to enable and enrich our alliance solution with VMware , contact us! AlgoSec works directly with VMware and your trusted technology delivery partners, and we’re glad to share more with you. Schedule a personal demo to see how AlgoSec makes your transformation to VMware Intrinsic Security possible now. Schedule a demo Related Articles Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read 5 Multi-Cloud Environments Cloud Security Mar 19, 2023 · 2 min read Convergence didn’t fail, compliance did. Mar 19, 2023 · 2 min read Speak to one of our experts Speak to one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Schedule a call

AlgoSec Values Download PDF Schedule time with one of our experts Schedule time with one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Continue

Integrate Security Into DevOps for Faster, Safer Application Delivery Into Production Download PDF Schedule time with one of our experts Schedule time with one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Continue

Cybersecurity is an ever prevalent issue. Malicious hackers are becoming more agile by using sophisticated techniques that are always... Cloud Security Prevasio’s Role in Red Team Exercises and Pen Testing 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/21/20 Published Cybersecurity is an ever prevalent issue. Malicious hackers are becoming more agile by using sophisticated techniques that are always evolving. This makes it a top priority for companies to stay on top of their organization’s network security to ensure that sensitive and confidential information is not leaked or exploited in any way. Let’s take a look at the Red/Blue Team concept, Pen Testing, and Prevasio’s role in ensuring your network and systems remain secure in a Docker container atmosphere. What is the Red/Blue Team Concept? The red/blue team concept is an effective technique that uses exercises and simulations to assess a company’s cybersecurity strength. The results allow organizations to identify which aspects of the network are functioning as intended and which areas are vulnerable and need improvement. The idea is that two teams (red and blue) of cybersecurity professionals face off against each other. The Red Team’s Role It is easiest to think of the red team as the offense. This group aims to infiltrate a company’s network using sophisticated real-world techniques and exploit potential vulnerabilities. It is important to note that the team comprises highly skilled ethical hackers or cybersecurity professionals. Initial access is typically gained by stealing an employee’s, department, or company-wide user credentials. From there, the red team will then work its way across systems as it increases its level of privilege in the network. The team will penetrate as much of the system as possible. It is important to note that this is just a simulation, so all actions taken are ethical and without malicious intent. The Blue Team’s Role The blue team is the defense. This team is typically made up of a group of incident response consultants or IT security professionals specially trained in preventing and stopping attacks. The goal of the blue team is to put a stop to ongoing attacks, return the network and its systems to a normal state, and prevent future attacks by fixing the identified vulnerabilities. Prevention is ideal when it comes to cybersecurity attacks. Unfortunately, that is not always possible. The next best thing is to minimize “breakout time” as much as possible. The “breakout time” is the window between when the network’s integrity is first compromised and when the attacker can begin moving through the system. Importance of Red/Blue Team Exercises Cybersecurity simulations are important for protecting organizations against a wide range of sophisticated attacks. Let’s take a look at the benefits of red/blue team exercises: Identify vulnerabilities Identify areas of improvement Learn how to detect and contain an attack Develop response techniques to handle attacks as quickly as possible Identify gaps in the existing security Strengthen security and shorten breakout time Nurture cooperation in your IT department Increase your IT team’s skills with low-risk training What are Pen Testing Teams? Many organizations do not have red/blue teams but have a Pen Testing (aka penetration testing) team instead. Pen testing teams participate in exercises where the goal is to find and exploit as many vulnerabilities as possible. The overall goal is to find the weaknesses of the system that malicious hackers could take advantage of. Companies’ best way to conduct pen tests is to use outside professionals who do not know about the network or its systems. This paints a more accurate picture of where vulnerabilities lie. What are the Types of Pen Testing? Open-box pen test – The hacker is provided with limited information about the organization. Closed-box pen test – The hacker is provided with absolutely no information about the company. Covert pen test – In this type of test, no one inside the company, except the person who hires the outside professional, knows that the test is taking place. External pen test – This method is used to test external security. Internal pen test – This method is used to test the internal network. The Prevasio Solution Prevasio’s solution is geared towards increasing the effectiveness of red teams for organizations that have taken steps to containerize their applications and now rely on docker containers to ship their applications to production. The benefits of Prevasio’s solution to red teams include: Auto penetration testing that helps teams conduct break-and-attack simulations on company applications. It can also be used as an integrated feature inside the CI/CD to provide reachability assurance. The behavior analysis will allow teams to identify unintentional internal oversights of best practices. The solution features the ability to intercept and scan encrypted HTTPS traffic. This helps teams determine if any credentials should not be transmitted. Prevasio container security solution with its cutting-edge analyzer performs both static and dynamic analysis of the containers during runtime to ensure the safest design possible. Moving Forward Cyberattacks are as real of a threat to your organization’s network and systems as physical attacks from burglars and robbers. They can have devastating consequences for your company and your brand. The bottom line is that you always have to be one step ahead of cyberattackers and ready to take action, should a breach be detected. The best way to do this is to work through real-world simulations and exercises that prepare your IT department for the worst and give them practice on how to respond. After all, it is better for your team (or a hired ethical hacker) to find a vulnerability before a real hacker does. Simulations should be conducted regularly since the technology and methods used to hack are constantly changing. The result is a highly trained team and a network that is as secure as it can be. Prevasio is an effective solution in conducting breach and attack simulations that help red/blue teams and pen testing teams do their jobs better in Docker containers. Our team is just as dedicated to the security of your organization as you are. Click here to learn more start your free trial. Schedule a demo Related Articles Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read 5 Multi-Cloud Environments Cloud Security Mar 19, 2023 · 2 min read Convergence didn’t fail, compliance did. Mar 19, 2023 · 2 min read Speak to one of our experts Speak to one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Schedule a call

Prof. Avishai Wool discusses the complexities of mergers and acquisitions for application management and how organizations can securely... Security Policy Management Managing network connectivity during mergers and acquisitions 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 7/22/21 Published Prof. Avishai Wool discusses the complexities of mergers and acquisitions for application management and how organizations can securely navigate the transition It comes as no surprise that the number of completed Mergers and Acquisitions (M&As) dropped significantly during the early stages of the pandemic as businesses closed ranks and focused on surviving rather than thriving. However, as we start to find some reprieve, many experts forecast that we’ll see an upturn in activity. In fact, by the end of 2020, M&A experienced a sudden surge and finished the year with only a 3% decline on 2019 levels. Acquiring companies is more than just writing a cheque. There are hundreds of things to consider both big and small, from infrastructure to staffing, which can make or break a merger. With that in mind, what do businesses need to do in order to ensure a secure and successful transition? When two worlds collide For many businesses, a merger or acquisition is highly charged. There’s often excitement about new beginnings mixed with trepidation about major business changes, not least when it comes to IT security. Mergers and acquisitions are like two planets colliding, each with their own intricate ecosystem. You have two enterprises running complex IT infrastructures with hundreds if not thousands of applications that don’t just simply integrate together. More often than not they perform replicated functions, which implies that some need to be used in parallel, while others need to be decommissioned and removed. This means amending, altering, and updating thousands of policies to accommodate new connections, applications, servers, and firewalls without creating IT security risks or outages. In essence, from an IT security perspective, a merger or acquisition is a highly complicated project that, if not planned and implemented properly, can have a long-term impact on business operations. Migrating and merging infrastructures One thing a business will need before it can even start the M&A process is an exhaustive inventory of all business applications spanning both businesses. An auto-discovery tool can assist here, collecting data from any application that is active on the network and adding it to a list. This should allow the main business to create a map of network connectivity flows which will form the cornerstone of the migration from an application perspective. Next comes security. A vulnerability assessment should be carried across both enterprise networks to identify any business-critical applications that may be put at risk. This assessment will give the main business the ability to effectively ‘rank’ applications and devices in terms of risk and necessity, allowing for priority lists to be created. This will help SecOps focus their efforts on crucial areas of the business that contain sensitive customer data, for instance. By following these steps you’ll get a clear organizational view of the entire enterprise environment and be able to identify and map all the critical business applications, linking vulnerabilities and cyber risks to specific applications and prioritize remediation actions based on business-driven needs. The power of automation While the steps outlined above will give you with an accurate picture of your IT topology and its business risk, this is only the first half of the story. Now you need to update security policies to support changes to business applications. Automation is critical when it comes to maintaining security during a merger or acquisition. An alarming number of data breaches are due to firewall misconfigurations, often resulting from attempts to change policies manually in a complex network environment. This danger increases with M&A, because the two merging enterprises likely have different firewall setups in place, often mixing traditional with next-generation firewalls or firewalls that come from different vendors. Automation is therefore essential to ensure the firewall change management process is handled effectively and securely with minimal risk of misconfigurations. Achieving true Zero-Touch automation in the network security domain is not an easy task but over time, you can let your automation solution run handsfree as you conduct more changes and gain trust through increasing automation levels step by step. Our Security Management Solution enables IT and security teams to manage and control all their security devices – from cloud controls in public clouds, SDNs, and on-premise firewalls from one single console. With AlgoSec you can automate time-consuming security policy changes and proactively assess risk to ensure continuous compliance. It is our business-driven approach to security policy management that enables organizations to reduce business risk, ensure security and continuous compliance, and drive business agility. Maintaining security throughout the transition A merger or acquisition presents a range of IT challenges but ensuring business applications can continue to run securely throughout the transition is critical. If you take an application centric approach and utilize automation, you will be in the best position for the merger/migration and will ultimately drive long term success. To learn more or speak to one of our security experts, schedule your personal demo . Schedule a demo Related Articles Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read 5 Multi-Cloud Environments Cloud Security Mar 19, 2023 · 2 min read Convergence didn’t fail, compliance did. Mar 19, 2023 · 2 min read Speak to one of our experts Speak to one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Schedule a call

What to do if your network is infected by ransomware How to prepare a ransomware playbook, using the existing capabilities of network security policy management tools Webinars How to stop ransomware in its tracks Stop ransomware in its tracks. Yes, it’s possible. But the time to prepare is now — before it strikes. In this session, security expert Dania Ben Peretz will demonstrate what to do if your network is infected by ransomware. She will show how to prepare a ransomware playbook, using the existing capabilities of network security policy management tools, so you can handle a ransomware incident as it happens. Join us and learn: The dangers of ransomware How to prepare the playbook How to stop ransomware when it strikes March 31, 2021 Dania Ben Peretz Product Manager Relevant resources Reducing your risk of ransomware attacks Keep Reading Ransomware Attack: Best practices to help organizations proactively prevent, contain and respond Keep Reading Fighting Ransomware - CTO Roundtable Insights 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

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

How to Secure Your Local Area Network In my last blog series we reviewed ways to protect the perimeter of your network and then we took... Firewall Change Management How to secure your LAN (Local Area Network) 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 11/12/13 Published How to Secure Your Local Area Network In my last blog series we reviewed ways to protect the perimeter of your network and then we took it one layer deeper and discussed securing the DMZ . Now I’d like to examine the ways you can secure the Local Area Network, aka LAN, also known as the soft underbelly of the beast. Okay, I made that last part up, but that’s what it should be called. The LAN has become the focus of attack over the past couple years, due to companies tightening up their perimeter and DMZ. It’s very rare you’ll you see an attacker come right at you these days, when they can trick an unwitting user into clicking a weaponized link about “Cat Videos” (Seriously, who doesn’t like cat videos?!). With this being said, let’s talk about a few ways we can protect our soft underbelly and secure our network. For the first part of this blog series, let’s examine how to secure the LAN at the network layer. LAN and the Network Layer From the network layer, there are constant things that can be adjusted and used to tighten the posture of your LAN. The network is the highway where the data traverses. We need protection on the interstate just as we need protection on our network. Protecting how users are connecting to the Internet and other systems is an important topic. We could create an entire series of blogs on just this topic, but let’s try to condense it a little here. Verify that you’re network is segmented – it better be if you read my last article on the DMZ – but we need to make sure nothing from the DMZ is relying on internal services. This is a rule. Take them out now and thank us later. If this is happening, you are just asking for some major compliance and security issues to crop up. Continuing with segmentation, make sure there’s a guest network that vendors can attach to if needed. I hate when I go to a client/vendor’s site and they ask me to plug into their network. What if I was evil? What if I had malware on my laptop that’s now ripping throughout your network because I was dumb enough to click a link to a “Cat Video”? If people aren’t part of your company, they shouldn’t be connecting to your internal LAN plain and simple. Make sure you have egress filtering on your firewall so you aren’t giving complete access for users to pillage the Internet from your corporate workstation. By default users should only have access to port 80/443, anything else should be an edge case (in most environments). If users need FTP access there should be a rule and you’ll have to allow them outbound after authorization, but they shouldn’t be allowed to rush the Internet on every port. This stops malware, botnets, etc. that are communicating on random ports. It doesn’t protect everything since you can tunnel anything out of these ports, but it’s a layer! Set up some type of switch security that’s going to disable a port if there are different or multiple MAC addresses coming from a single port. This stops hubs from being installed in your network and people using multiple workstations. Also, attempt to set up NAC to get a much better understating of what’s connecting to your network while giving you complete control of those ports and access to resources from the LAN. In our next LAN security-focused blog, we’ll move from the network up the stack to the application layer. Schedule a demo Related Articles Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read 5 Multi-Cloud Environments Cloud Security Mar 19, 2023 · 2 min read Convergence didn’t fail, compliance did. Mar 19, 2023 · 2 min read Speak to one of our experts Speak to one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Schedule a call