top of page

Search results

696 results found with an empty search

  • AlgoSec | Sunburst Backdoor: A Deeper Look Into The SolarWinds’ Supply Chain Malware

    Update : Next two parts of the analysis are available here and here . As earlier reported by FireEye, the actors behind a global... Cloud Security Sunburst Backdoor: A Deeper Look Into The SolarWinds’ Supply Chain Malware 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/15/20 Published Update : Next two parts of the analysis are available here and here . As earlier reported by FireEye, the actors behind a global intrusion campaign have managed to trojanise SolarWinds Orion business software updates in order to distribute malware. The original FireEye write-up already provides a detailed description of this malware. Nevertheless, as the malicious update SolarWinds-Core-v2019.4.5220-Hotfix5.msp was still available for download for hours since the FireEye’s post, it makes sense to have another look into the details of its operation. The purpose of this write-up is to provide new information, not covered in the original write-up. Any overlaps with the original description provided by FireEye are not intentional. For start, the malicious component SolarWinds.Orion.Core.BusinessLayer.dll inside the MSP package is a non-obfuscated .NET assembly. It can easily be reconstructed with a .NET disassembler, such as ILSpy , and then fully reproduced in C# code, using Microsoft Visual Studio. Once reproduced, it can be debugged to better understand how it works. In a nutshell, the malicious DLL is a backdoor. It is loaded into the address space of the legitimate SolarWinds Orion process SolarWinds.BusinessLayerHost.exe or SolarWinds.BusinessLayerHostx64.exe . The critical strings inside the backdoor’s class SolarWinds.Orion.Core.BusinessLayer.OrionImprovementBusinessLayer are encoded with the DeflateStream Class of the .NET’s System.IO.Compression library, coupled with the standard base64 encoder. Initialisation Once loaded, the malware checks if its assembly file was created earlier than 12, 13, or 14 days ago. The exact number of hours it checks is a random number from 288 to 336. Next, it reads the application settings value ReportWatcherRetry . This value keeps the reporting status, and may be set to one of the states: New (4) Truncate (3) Append (5) When the malware runs the first time, its reporting status variable ReportWatcherRetry is set to New (4) . The reporting status is an internal state that drives the logic. For example, if the reporting status is set to Truncate , the malware will stop operating by first disabling its networking communications, and then disabling other security tools and antivirus products. In order to stay silent, the malware periodically falls asleep for a random period of time that varies between 30 minutes and 2 hours. At the start, the malware obtains the computer’s domain name . If the domain name is empty, the malware quits. It then generates a 8-byte User ID, which is derived from the system footprint. In particular, it is generated from MD5 hash of a string that consists from the 3 fields: the first or default operational (can transmit data packets) network interface’s physical address computer’s domain name UUID created by Windows during installation (machine’s unique ID) Even though it looks random, the User ID stays permanent as long as networking configuration and the Windows installation stay the same. Domain Generation Algorithm The malware relies on its own CryptoHelper class to generate a domain name. This class is instantiated from the 8-byte User ID and the computer’s domain name, encoded with a substitution table: “rq3gsalt6u1iyfzop572d49bnx8cvmkewhj” . For example, if the original domain name is “ domain “, its encoded form will look like: “ n2huov “. To generate a new domain, the malware first attempts to resolve domain name “ api.solarwinds.com “. If it fails to resolve it, it quits. The first part of the newly generated domain name is a random string, produced from the 8-byte User ID, a random seed value, and encoded with a custom base64 alphabet “ph2eifo3n5utg1j8d94qrvbmk0sal76c” . Because it is generated from a random seed value, the first part of the newly generated domain name is random. For example, it may look like “ fivu4vjamve5vfrt ” or “ k1sdhtslulgqoagy “. To produce the domain name, this string is then appended with the earlier encoded domain name (such as “ n2huov “) and a random string, selected from the following list: .appsync-api.eu-west-1[.]avsvmcloud[.]com .appsync-api.us-west-2[.]avsvmcloud[.]com .appsync-api.us-east-1[.]avsvmcloud[.]com .appsync-api.us-east-2[.]avsvmcloud[.]com For example, the final domain name may look like: fivu4vjamve5vfrtn2huov[.]appsync-api.us-west-2[.]avsvmcloud[.]com or k1sdhtslulgqoagyn2huov[.]appsync-api.us-east-1[.]avsvmcloud[.]com Next, the domain name is resolved to an IP address, or to a list of IP addresses. For example, it may resolve to 20.140.0.1 . The resolved domain name will be returned into IPAddress structure that will contain an AddressFamily field – a special field that specifies the addressing scheme. If the host name returned in the IPAddress structure is different to the queried domain name, the returned host name will be used as a C2 host name for the backdoor. Otherwise, the malware will check if the resolved IP address matches one of the patterns below, in order to return an ‘address family’: IP Address Subnet Mask ‘Address Family’ 10.0.0.0 255.0.0.0 Atm 172.16.0.0 255.240.0.0 Atm 192.168.0.0 255.255.0.0 Atm 224.0.0.0 240.0.0.0 Atm fc00:: fe00:: Atm fec0:: ffc0:: Atm ff00:: ff00:: Atm 41.84.159.0 255.255.255.0 Ipx 74.114.24.0 255.255.248.0 Ipx 154.118.140.0 255.255.255.0 Ipx 217.163.7.0 255.255.255.0 Ipx 20.140.0.0 255.254.0.0 ImpLink 96.31.172.0 255.255.255.0 ImpLink 131.228.12.0 255.255.252.0 ImpLink 144.86.226.0 255.255.255.0 ImpLink 8.18.144.0 255.255.254.0 NetBios 18.130.0.0 255.255.0.0 NetBios 71.152.53.0 255.255.255.0 NetBios 99.79.0.0 255.255.0.0 NetBios 87.238.80.0 255.255.248.0 NetBios 199.201.117.0 255.255.255.0 NetBios 184.72.0.0 255.254.0.0 NetBios For example, if the queried domain resolves to 20.140.0.1 , it will match the entry in the table 20.140.0.0 , for which the returned ‘address family’ will be ImpLink . The returned ‘address family’ invokes an additional logic in the malware. Disabling Security Tools and Antivirus Products If the returned ‘address family’ is ImpLink or Atm , the malware will enumerate all processes and for each process, it will check if its name matches one of the pre-defined hashes. Next, it repeats this processed for services and for the drivers installed in the system. If a process name or a full path of an installed driver matches one of the pre-defined hashes, the malware will disable it. For hashing, the malware relies on Fowler–Noll–Vo algorithm. For example, the core process of Windows Defender is MsMpEng.exe . The hash value of “ MsMpEng ” string is 5183687599225757871 . This value is specifically enlisted the malware’s source under a variable name timeStamps : timeStamps = new ulong[1] { 5183687599225757871uL } The service name of Windows Defender is windefend – the hash of this string ( 917638920165491138 ) is also present in the malware body. As a result, the malicioius DLL will attempt to stop the Windows Defender service. In order to disable various security tools and antivirus products, the malware first grants itself SeRestorePrivilege and SeTakeOwnershipPrivilege privileges, using the native AdjustTokenPrivileges() API. With these privileges enabled, the malware takes ownership of the service registry keys it intends to manipulate. The new owner of the keys is first attempted to be explicitly set to Administrator account. If such account is not present, the malware enumerates all user accounts, looking for a SID that represents the administrator account. The malware uses Windows Management Instrumentation query “ Select * From Win32_UserAccount ” to obtain the list of all users. For each enumerated user, it makes sure the account is local and then, when it obtains its SID, it makes sure the SID begins with S-1-5- and ends with -500 in order to locate the local administrator account. Once such account is found, it is used as a new owner for the registry keys, responsible for manipulation of the services of various security tools and antivirus products. With the new ownership set, the malware then disables these services by setting their Start value to 4 (Disabled): registryKey2.SetValue(“Start”), 4, RegistryValueKind.DWord); HTTP Backdoor If the returned ‘address family’ for the resolved domain name is NetBios , as specified in the lookup table above, the malware will initialise its HttpHelper class, which implements an HTTP backdoor. The backdoor commands are covered in the FireEye write-up, so let’s check only a couple of commands to see what output they produce. One of the backdoor commands is CollectSystemDescription . As its name suggests, it collects system information. By running the code reconstructed from the malware, here is an actual example of the data collected by the backdoor and delivered to the attacker’s C2 with a separate backdoor command UploadSystemDescription : 1. %DOMAIN_NAME% 2. S-1-5-21-298510922-2159258926-905146427 3. DESKTOP-VL39FPO 4. UserName 5. [E] Microsoft Windows NT 6.2.9200.0 6.2.9200.0 64 6. C:\WINDOWS\system32 7. 0 8. %PROXY_SERVER% Description: Killer Wireless-n/a/ac 1535 Wireless Network Adapter #2 MACAddress: 9C:B6:D0:F6:FF:5D DHCPEnabled: True DHCPServer: 192.168.20.1 DNSHostName: DESKTOP-VL39FPO DNSDomainSuffixSearchOrder: Home DNSServerSearchOrder: 8.8.8.8, 192.168.20.1 IPAddress: 192.168.20.30, fe80::8412:d7a8:57b9:5886 IPSubnet: 255.255.255.0, 64 DefaultIPGateway: 192.168.20.1, fe80::1af1:45ff:feec:a8eb NOTE: Field #7 specifies the number of days (0) since the last system reboot. GetProcessByDescription command will build a list of processes running on a system. This command accepts an optional argument, which is one of the custom process properties enlisted here . If the optional argument is not specified, the backdoor builds a process list that looks like: [ 1720] svchost [ 8184] chrome [ 4732] svchost If the optional argument is specified, the backdoor builds a process list that includes the specified process property in addition to parent process ID, username and domain for the process owner. For example, if the optional argument is specified as “ ExecutablePath “, the GetProcessByDescription command may return a list similar to: [ 3656] sihost.exe C:\WINDOWS\system32\sihost.exe 1720 DESKTOP-VL39FPO\UserName [ 3824] svchost.exe C:\WINDOWS\system32\svchost.exe 992 DESKTOP-VL39FPO\UserName [ 9428] chrome.exe C:\Program Files (x86)\Google\Chrome\Application\chrome.exe 4600 DESKTOP-VL39FPO\UserName Other backdoor commands enable deployment of the 2nd stage malware. For example, the WriteFile command will save the file: using (FileStream fileStream = new FileStream(path, FileMode.Append, FileAccess.Write)) { fileStream.Write(array, 0, array.Length); } The downloaded 2nd stage malware can then the executed with RunTask command: using (Process process = new Process()) { process.StartInfo = new ProcessStartInfo(fileName, arguments) { CreateNoWindow = false, UseShellExecute = false }; if (process.Start()) … Alternatively, it can be configured to be executed with the system restart, using registry manipulation commands, such as SetRegistryValue . 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

  • Data center migration checklist + project plan template

    Minimize risks and maximize benefits with a successful data center migration Explore key considerations and strategies Data center migration checklist + project plan template 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. Data center migration What is a data center migration? What are the four types of data center migration? What are data center migration best practices? How to plan for a successful data center migration? What are some common challenges of a data center migration? What are some common drawbacks of a data center migration? Checklist for a successful data center migration What are some data center migration tools? Get the latest insights from the experts Use these six best practices to simplify compliance and risk mitigation with the AlgoSec White paper Learn how AlgoSec can help you pass PCI-DSS Audits and ensure Solution overview 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

  • AlgoSec | 5 mindset shifts security teams must adopt to master multi-cloud security

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

  • Our Values - AlgoSec

    Our 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

  • AlgoSec | 20 Firewall Management Best Practices for Network Security

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

  • AlgoSec Announces Support for Privileged Access Management to Enhance Security Management and Reduce Network Attack Surface

    New version of Security Management Solution supports central control of access credentials, extends DevOps integrations, and optimizes security management processes AlgoSec Announces Support for Privileged Access Management to Enhance Security Management and Reduce Network Attack Surface New version of Security Management Solution supports central control of access credentials, extends DevOps integrations, and optimizes security management processes February 19, 2019 Speak to one of our experts 19 February 2019 – AlgoSec , the leading provider of business-driven network security management solutions, has introduced the AlgoSec Security Management Solution version 2018.2. The new version features support for privileged access management solutions, enabling customers to further enhance their organization’s security management processes with centralized control of device credentials and privileged accounts. AlgoSec 2018.2 delivers seamless access to security devices protected by privileged access control solutions, with no need to duplicate or save those devices’ account access credentials externally. It also includes extended support for DevOps and enhanced support functions for a range of market-leading security controls, to accelerate automation of network security management while minimizing the organization’s attack surface. “With support for privileged access control solutions, customers can now take a business-centric approach to security policy management that ensures agility and continuity, while maintaining a strong security and compliance posture across all of their strategic assets and privileged accounts,” said Omer Ganot, Product Manager at AlgoSec. “The range of new features and enhancements in version 2018.2 further extends AlgoSec’s business-driven security management capabilities, which optimize agility, security and compliance across today’s hybrid enterprise networks.” Key new features introduced in AlgoSec version 2018.2 include: Support for CyberArk Privileged Access Security Solution AlgoSec version 2018.2 gives access to security devices protected by CyberArk’s solution without duplicating or saving those devices’ access credentials, helping joint customers maintain centralized control of all privileged accounts and credentials. Enhanced support for Cisco, VMware, F5, Fortinet and Juniper devices Extended change management for Cisco Firepower devices controlled by the Firepower Management Center, giving full automation and end-to-end provisioning Extended change management support for VMWare NSX Distributed Firewalls, enabling rules to be automatically added, modified, disabled or removed from policies Seamless integration with Cisco Tetration , enabling automation of micro-segmentation projects; also reduces attack surface by combining endpoint and network security Extended support for F5’s BIG-IP Advanced Firewall Manager module Enhanced integration with FortiManager security policies, enabling fully automated management of related Fortinet firewalls managed by FortiManager Enhanced workflow automation for Juniper SRX firewalls New integrations with External Application Deployment Systems for DevOps DevOps can deploy new applications and manage their connectivity with new APIs for application, flow and object editing, and for user / role permission management. APIs are available for Ansible, Puppet and Chef Optimized user experience 2018.2 features a new, dedicated UI for troubleshooting results of traffic simulation queries, helping users to fine-tune their network maps and achieve automation faster The AlgoSec Security Management Solution version 2018.2 is generally available. About AlgoSec The leading provider of business-driven network security management solutions, AlgoSec helps the world’s largest organizations align security with their mission-critical business processes. With AlgoSec, users can discover, map and migrate business application connectivity, proactively analyze risk from the business perspective, tie cyber-attacks to business processes and intelligently automate network security changes with zero touch – across their cloud, SDN and on-premise networks. Over 1,800 enterprises , including 20 of the Fortune 50, utilize AlgoSec’s solutions to make their organizations more agile, more secure and more compliant – all the time. Since 2005, AlgoSec has shown its commitment to customer satisfaction with the industry’s only money-back guarantee. All product and company names herein may be trademarks of their registered owners. *** Media Contacts: Tsippi Dach AlgoSec [email protected] Craig Coward Context Public Relations [email protected] +44 (0)1625 511 966

  • AlgoSec | Network segmentation vs. VLAN explained

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

    AlgoSec ObjectFlow 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

  • Enterprise Guide To Cloud Security - AlgoSec

    Enterprise Guide To Cloud Security 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

bottom of page