Search results

Learn best practices to secure your cloud environment and deliver applications securely Webinars Master the Zero Trust strategy for improved cybersecurity Learn how to implement zero trust security into your business In today’s digital world, cyber threats are becoming more complex and sophisticated. Businesses must adopt a proactive approach to cybersecurity to protect their sensitive data and systems. This is where zero trust security comes in – a security model that requires every user, device, and application to be verified before granting access. If you’re looking to implement zero trust security in your business or want to know more about how it works, you’ll want to watch this webinar. AlgoSec co-Founder and CTO Avishai Wool will discuss the benefits of zero trust security and provide you with practical tips on how to implement this security model in your organization. March 15, 2023 Prof. Avishai Wool CTO & Co Founder AlgoSec Relevant resources Protecting Your Network’s Precious Jewels with Micro-Segmentation, Kyle Wickert, AlgoSec Watch Video Professor Wool - Introduction to Microsegmentation Watch Video Five Practical Steps to Implementing a Zero-Trust Network 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

Properly configured firewalls are vital in any comprehensive cybersecurity strategy. However, even the most robust configurations can be... Uncategorized How To Prevent Firewall Breaches (The 2024 Guide) 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 1/11/24 Published Properly configured firewalls are vital in any comprehensive cybersecurity strategy. However, even the most robust configurations can be vulnerable to exploitation by attackers. No single security measure can offer absolute protection against all cyber threats and data security risks . To mitigate these risks, it’s crucial to understand how cybercriminals exploit firewall vulnerabilities. The more you know about their tactics, techniques, and procedures, the better-equipped you are to implement security policies that successfully block unauthorized access to network assets. In this guide, you’ll understand the common cyber threats that target enterprise firewall systems with the goal of helping you understand how attackers exploit misconfigurations and human vulnerabilities. Use this information to protect your network from a firewall breach. Understanding 6 Tactics Cybercriminals Use to Breach Firewalls 1. DNS Leaks Your firewall’s primary use is making sure unauthorized users do not gain access to your private network and the sensitive information it contains. But firewall rules can go both ways – preventing sensitive data from leaving the network is just as important. If enterprise security teams neglect to configure their firewalls to inspect outgoing traffic, cybercriminals can intercept this traffic and use it to find gaps in your security systems. DNS traffic is particularly susceptible to this approach because it shows a list of websites users on your network regularly visit. A hacker could use this information to create a spoofed version of a frequently visited website. For example, they might notice your organization’s employees visit a third-party website to attend training webinars. Registering a fake version of the training website and collecting employee login credentials would be simple. If your firewall doesn’t inspect DNS data and confirm connections to new IP addresses, you may never know. DNS leaks may also reveal the IP addresses and endpoint metadata of the device used to make an outgoing connection. This would give cybercriminals the ability to see what kind of hardware your organization’s employees use to connect to external websites. With that information in hand, impersonating managed service providers or other third-party partners is easy. Some DNS leaks even contain timestamp data, telling attackers exactly when users requested access to external web assets. How to protect yourself against DNS leaks Proper firewall configuration is key to preventing DNS-related security incidents. Your organization’s firewalls should provide observability and access control to both incoming and outgoing traffic. Connections to servers known for hosting malware and cybercrime assets should be blocked entirely. Connections to servers without a known reputation should be monitored closely. In a Zero Trust environment , even connections to known servers should benefit from scrutiny using an identity-based security framework. Don’t forget that apps can connect to external resources, too. Consider deploying web application firewalls configured to prevent DNS leaks when connecting to third-party assets and servers. You may also wish to update your security policy to require employees to use VPNs when connecting to external resources. An encrypted VPN connection can prevent DNS information from leaking, making it much harder for cybercriminals to conduct reconnaissance on potential targets using DNS data. 2. Encrypted Injection Attacks Older, simpler firewalls analyze traffic by looking at different kinds of data packet metadata. This provides clear evidence of certain denial-of-service attacks, clear violations of network security policy , and some forms of malware and ransomware . They do not conduct deep packet inspection to identify the kind of content passing through the firewall. This provides cybercriminals with an easy way to bypass firewall rules and intrusion prevention systems – encryption . If malicious content is encrypted before it hits the firewall, it may go unnoticed by simple firewall rules. Only next-generation firewalls capable of handling encrypted data packets can determine whether this kind of traffic is secure or not. Cybercriminals often deliver encrypted injection attacks through email. Phishing emails may trick users into clicking on a malicious link that injects encrypted code into the endpoint device. The script won’t decode and run until after it passes the data security threshold posed by the firewall. After that, it is free to search for personal data, credit card information, and more. Many of these attacks will also bypass antivirus controls that don’t know how to handle encrypted data. Task automation solutions like Windows PowerShell are also susceptible to these kinds of attacks. Even sophisticated detection-based security solutions may fail to recognize encrypted injection attacks if they don’t have the keys necessary to decrypt incoming data. How to protect yourself against encrypted injection attacks Deep packet inspection is one of the most valuable features next-generation firewalls provide to security teams. Industry-leading firewall vendors equip their products with the ability to decrypt and inspect traffic. This allows the firewall to prevent malicious content from entering the network through encrypted traffic, and it can also prevent sensitive encrypted data – like login credentials – from leaving the network. These capabilities are unique to next-generation firewalls and can’t be easily replaced with other solutions. Manufacturers and developers have to equip their firewalls with public-key cryptography capabilities and obtain data from certificate authorities in order to inspect encrypted traffic and do this. 3. Compromised Public Wi-Fi Public Wi-Fi networks are a well-known security threat for individuals and organizations alike. Anyone who logs into a password-protected account on public Wi-Fi at an airport or coffee shop runs the risk of sending their authentication information directly to hackers. Compromised public Wi-Fi also presents a lesser-known threat to security teams at enterprise organizations – it may help hackers breach firewalls. If a remote employee logs into a business account or other asset from a compromised public Wi-Fi connection, hackers can see all the data transmitted through that connection. This may give them the ability to steal account login details or spoof endpoint devices and defeat multi-factor authentication. Even password-protected private Wi-Fi connections can be abused in this way. Some Wi-Fi networks still use outdated WEP and WPA security protocols that have well-known vulnerabilities. Exploiting these weaknesses to take control of a WEP or WPA-protected network is trivial for hackers. The newer WPA2 and WPA3 standards are much more resilient against these kinds of attacks. While public Wi-Fi dangers usually bring remote workers and third-party service vendors to mind, on-premises networks are just as susceptible. Nothing prevents a hacker from gaining access to public Wi-Fi networks in retail stores, receptions, or other areas frequented by customers and employees. How to protect yourself against compromised public Wi-Fi attacks First, you must enforce security policies that only allow Wi-Fi traffic secured by WPA2 and WPA3 protocols. Hardware Wi-Fi routers that do not support these protocols must be replaced. This grants a minimum level of security to protected Wi-Fi networks. Next, all remote connections made over public Wi-Fi networks must be made using a secure VPN. This will encrypt the data that the public Wi-Fi router handles, making it impossible for a hacker to intercept without gaining access to the VPN’s secret decryption key. This doesn’t guarantee your network will be safe from attacks, but it improves your security posture considerably. 4. IoT Infrastructure Attacks Smartwatches, voice-operated speakers, and many automated office products make up the Internet of Things (IoT) segment of your network. Your organization may be using cloud-enriched access control systems, cost-efficient smart heating systems, and much more. Any Wi-Fi-enabled hardware capable of automation can safely be included in this category. However, these devices often fly under the radar of security team’s detection tools, which often focus on user traffic. If hackers compromise one of these devices, they may be able to move laterally through the network until they arrive at a segment that handles sensitive information. This process can take time, which is why many incident response teams do not consider suspicious IoT traffic to be a high-severity issue. IoT endpoints themselves rarely process sensitive data on their own, so it’s easy to overlook potential vulnerabilities and even ignore active attacks as long as the organization’s mission-critical assets aren’t impacted. However, hackers can expand their control over IoT devices and transform them into botnets capable of running denial-of-service attacks. These distributed denial-of-service (DDoS) attacks are much larger and more dangerous, and they are growing in popularity among cybercriminals. Botnet traffic associated with DDoS attacks on IoT networks has increased five-fold over the past year , showing just how promising it is for hackers. How to protect yourself against IoT infrastructure attacks Proper network segmentation is vital for preventing IoT infrastructure attacks . Your organization’s IoT devices should be secured on a network segment that is isolated from the rest of the network. If attackers do compromise the entire network, you should be protected from the risk of losing sensitive data from critical business assets. Ideally, this protection will be enforced with a strong set of firewalls managing the connection between your IoT subnetwork and the rest of your network. You may need to create custom rules that take your unique security risk profile and fleet of internet-connected devices into account. There are very few situations in which one-size-fits-all rulemaking works, and this is not one of them. All IoT devices – no matter how small or insignificant – should be protected by your firewall and other cybersecurity solutions . Never let these devices connect directly to the Internet through an unsecured channel. If they do, they provide attackers with a clear path to circumvent your firewalls and gain access to the rest of your network with ease. 5. Social Engineering and Phishing Social engineering attacks refer to a broad range of deceptive practices used by hackers to gain access to victims’ assets. What makes this approach special is that it does not necessarily depend on technical expertise. Instead of trying to hack your systems, cybercriminals are trying to hack your employees and company policies to carry out their attacks. Email phishing is one of the most common examples. In a typical phishing attack , hackers may spoof an email server to make it look like they are sending emails from a high-level executive in the company you work for. They can then impersonate this executive and demand junior accountants pay fictitious invoices or send sensitive customer data to email accounts controlled by threat actors. Other forms of social engineering can use your organization’s tech support line against itself. Attackers may pretend to represent large customer accounts and will leverage this ruse to gain information about how your company works. They may impersonate a third-party vendor and request confidential information that the vendor would normally have access to. These attacks span the range from simple trickery to elaborate confidence scams. Protecting against them can be incredibly challenging, and your firewall capabilities can make a significant difference in your overall state of readiness. How to protect yourself against social engineering attacks Employee training is the top priority for protecting against social engineering attacks . When employees understand the company’s operating procedures and security policies, it’s much harder for social engineers to trick them. Ideally, training should also include in-depth examples of how phishing attacks work, what they look like, and what steps employees should take when contacted by people they don’t trust. 6. Sandbox Exploits Many organizations use sandbox solutions to prevent file-based malware attacks. Sandboxes work by taking suspicious files and email attachments and opening them in a secure virtual environment before releasing them to users. The sandbox solution will observe how the file behaves and quarantine any file that shows malicious activity. In theory, this provides a powerful layer of defense against file-based attacks. But in practice, cybercriminals are well aware of how to bypass these solutions. For example, many sandbox solutions can’t open files over a certain size. Hackers who attach malicious code to large files can easily get through. Additionally, many forms of malware do not start executing malicious tasks the second they are activated. This delay can provide just enough of a buffer to get through a sandbox system. Some sophisticated forms of malware can even detect when they are being run in a sandbox environment – and will play the part of an innocent program until they are let loose inside the network. How to protect yourself against sandbox exploits Many next-generation firewalls include cloud-enabled sandboxing capable of running programs of arbitrary size for a potentially unlimited amount of time. More sophisticated sandbox solutions go to great lengths to mimic the system specifications of an actual endpoint so malware won’t know it is being run in a virtual environment. Organizations may also be able to overcome the limitations of the sandbox approach using Content Disarm and Reconstruction (CDR) techniques. This approach keeps potentially malicious files off the network entirely and only allows a reconstructed version of the file to enter the network. Since the new file is constructed from scratch, it will not contain any malware that may have been attached to the original file. Prevent firewall breaches with AlgoSec Managing firewalls manually can be overwhelming and time-consuming – especially when dealing with multiple firewall solutions. With the help of a firewall management solution , you easily configure firewall rules and manage configurations from a single dashboard. AlgoSec’s powerful firewall management solution integrates with your firewalls to deliver unified firewall policy management from a single location, thus streamlining the entire process. With AlgoSec, you can maintain clear visibility of your firewall ruleset, automate the management process, assess risk & optimize rulesets, streamline audit preparation & ensure compliance, and use APIs to access many features through web services. 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 is Network Security Monitoring? Network security monitoring is the process of inspecting network traffic and IT infrastructure for... Network Security Top 9 Network Security Monitoring Tools for Identifying Potential Threats 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 2/4/24 Published What is Network Security Monitoring? Network security monitoring is the process of inspecting network traffic and IT infrastructure for signs of security issues. These signs can provide IT teams with valuable information about the organization’s cybersecurity posture. For example, security teams may notice unusual changes being made to access control policies. This may lead to unexpected traffic flows between on-premises systems and unrecognized web applications. This might provide early warning of an active cyberattack, giving security teams enough time to conduct remediation efforts and prevent data loss . Detecting this kind of suspicious activity without the visibility that network security monitoring provides would be very difficult. These tools and policies enhance operational security by enabling network intrusion detection, anomaly detection, and signature-based detection. Full-featured network security monitoring solutions help organizations meet regulatory compliance requirements by maintaining records of network activity and security incidents. This gives analysts valuable data for conducting investigations into security events and connect seemingly unrelated incidents into a coherent timeline. What To Evaluate in a Network Monitoring Software Provider Your network monitoring software provider should offer a comprehensive set of features for collecting, analyzing, and responding to suspicious activity anywhere on your network. It should unify management and control of your organization’s IT assets while providing unlimited visibility into how they interact with one another. Comprehensive alerting and reporting Your network monitoring solution must notify you of security incidents and provide detailed reports describing those incidents in real-time. It should include multiple toolsets for collecting performance metrics, conducting in-depth analysis, and generating compliance reports. Future-proof scalability Consider what kind of network monitoring needs your organization might have several years from now. If your monitoring tool cannot scale to accommodate that growth, you may end up locked into a vendor agreement that doesn’t align with your interests. This is especially true with vendors that prioritize on-premises implementations since you run the risk of paying for equipment and services that you don’t actually use. Cloud-delivered software solutions often perform better in use cases where flexibility is important. Integration with your existing IT infrastructure Your existing security tech stack may include a selection of SIEM platforms, IDS/IPS systems, firewalls , and endpoint security solutions. Your network security monitoring software will need to connect all of these tools and platforms together in order to grant visibility into network traffic flows between them. Misconfigurations and improper integrations can result in dangerous security vulnerabilities. A high-performance vulnerability scanning solution may be able to detect these misconfigurations so you can fix them proactively. Intuitive user experience for security teams and IT admins Complex tools often come with complex management requirements. This can create a production bottleneck when there aren’t enough fully-trained analysts on the IT security team. Monitoring tools designed for ease of use can improve security performance by reducing training costs and allowing team members to access monitoring insights more easily. Highly automated tools can drive even greater performance benefits by reducing the need for manual control altogether. Excellent support and documentation Deploying network security monitoring tools is not always a straightforward task. Most organizations will need to rely on expert support to assist with implementation, troubleshooting, and ongoing maintenance. Some vendors provide better technical support to customers than others, and this difference is often reflected in the price. Some organizations work with managed service providers who can offset some of their support and documentation needs by providing on-demand expertise when needed. Pricing structures that work for you Different vendors have different pricing structures. When comparing network monitoring tools, consider the total cost of ownership including licensing fees, hardware requirements, and any additional costs for support or updates. Certain usage models will fit your organization’s needs better than others, and you’ll have to document them carefully to avoid overpaying. Compliance and reporting capabilities If you plan on meeting compliance requirements for your organization, you will need a network security monitoring tool that can generate the necessary reports and logs to meet these standards. Every set of standards is different, but many reputable vendors offer solutions for meeting specific compliance criteria. Find out if your network security monitoring vendor supports compliance standards like PCI DSS, HIPAA, and NIST. A good reputation for customer success Research the reputation and track record of every vendor you could potentially work with. Every vendor will tell you that they are the best – ask for evidence to back up their claims. Vendors with high renewal rates are much more likely to provide you with valuable security technology than lower-priced competitors with a significant amount of customer churn. Pay close attention to reviews and testimonials from independent, trustworthy sources. Compatibility with network infrastructure Your network security monitoring tool must be compatible with the entirety of your network infrastructure. At the most basic level, it must integrate with your hardware fleet of routers, switches, and endpoint devices. If you use devices with non-compatible operating systems, you risk introducing blind spots into your security posture. For the best results, you must enjoy in-depth observability for every hardware and software asset in your network, from the physical layer to the application layer. Regular updates and maintenance Updates are essential to keep security tools effective against evolving threats. Check the update frequency of any monitoring tool you consider implementing and look for the specific security vulnerabilities addressed in those updates. If there is a significant delay between the public announcement of new vulnerabilities and the corresponding security patch, your monitoring tools may be vulnerable during that period of time. 9 Best Network Security Monitoring Providers for Identifying Cybersecurity Threats 1. AlgoSec AlgoSec is a network security policy management solution that helps organizations automate and orchestrate network security policies. It keeps firewall rules , routers, and other security devices configured correctly, ensuring network assets are secured properly. AlgoSec protects organizations from misconfigurations that can lead to malware, ransomware, and phishing attacks, and gives security teams the ability to proactively simulate changes to their IT infrastructure. 2. SolarWinds SolarWinds offers a range of network management and monitoring solutions, including network security monitoring tools that detect changes to security policies and traffic flows. It provides tools for network visibility and helps identify and respond to security incidents. However, SolarWinds can be difficult for some organizations to deploy because customers must purchase additional on-premises hardware. 3. Security Onion Security Onion is an open-source Linux distribution designed for network security monitoring. It integrates multiple monitoring tools like Snort, Suricata, Bro, and others into a single platform, making it easier to set up and manage a comprehensive network security monitoring solution. As an open-source option, it is one of the most cost-effective solutions available on the market, but may require additional development resources to customize effectively for your organization’s needs. 4. ELK Stack Elastic ELK Stack is a combination of three open-source tools: Elasticsearch, Logstash, and Kibana. It’s commonly used for log data and event analysis. You can use it to centralize logs, perform real-time analysis, and create dashboards for network security monitoring. The toolset provides high-quality correlation through large data sets and provides security teams with significant opportunities to improve security and network performance using automation. 5. Cisco Stealthwatch Cisco Stealthwatch is a commercial network traffic analysis and monitoring solution. It uses NetFlow and other data sources to detect and respond to security threats, monitor network behavior, and provide visibility into your network traffic. It’s a highly effective solution for conducting network traffic analysis, allowing security analysts to identify threats that have infiltrated network assets before they get a chance to do serious damage. 6. Wireshark Wireshark is a widely-used open-source packet analyzer that allows you to capture and analyze network traffic in real-time. It can help you identify and troubleshoot network issues and is a valuable tool for security analysts. Unlike other entries on this list, it is not a fully-featured monitoring platform that collects and analyzes data at scale – it focuses on providing deep visibility into specific data flows one at a time. 7. Snort Snort is an open-source intrusion detection system (IDS) and intrusion prevention system (IPS) that can monitor network traffic for signs of suspicious or malicious activity. It’s highly customizable and has a large community of users and contributors. It supports customized rulesets and is easy to use. Snort is widely compatible with other security technologies, allowing users to feed signature updates and add logging capabilities to its basic functionality very easily. However, it’s an older technology that doesn’t natively support some modern features users will expect it to. 8. Suricata Suricata is another open-source IDS/IPS tool that can analyze network traffic for threats. It offers high-performance features and supports rules compatible with Snort, making it a good alternative. Suricata was developed more recently than Snort, which means it supports modern workflow features like multithreading and file extraction. Unlike Snort, Suricata supports application-layer detection rules and can identify traffic on non-standard ports based on the traffic protocol. 9. Zeek (formerly Bro) Zeek is an open-source network analysis framework that focuses on providing detailed insights into network activity. It can help you detect and analyze potential security incidents and is often used alongside other NSM tools. This tool helps security analysts categorize and model network traffic by protocol, making it easier to inspect large volumes of data. Like Suricata, it runs on the application layer and can differentiate between protocols. Essential Network Monitoring Features Traffic Analysis The ability to capture, analyze, and decode network traffic in real-time is a basic functionality all network security monitoring tools should share. Ideally, it should also include support for various network protocols and allow users to categorize traffic based on those categories. Alerts and Notifications Reliable alerts and notifications for suspicious network activity, enabling timely response to security threats. To avoid overwhelming analysts with data and contributing to alert fatigue, these notifications should consolidate data with other tools in your security tech stack. Log Management Your network monitoring tool should contribute to centralized log management through network devices, apps, and security sensors for easy correlation and analysis. This is best achieved by integrating a SIEM platform into your tech stack, but you may not wish to store all of your network’s logs on the SIEM, because of the added expense. Threat Detection Unlike regular network traffic monitoring, network security monitoring focuses on indicators of compromise in network activity. Your tool should utilize a combination of signature-based detection, anomaly detection, and behavioral analysis to identify potential security threats. Incident Response Support Your network monitoring solution should facilitate the investigation of security incidents by providing contextual information, historical data, and forensic capabilities. It may correlate detected security events so that analysts can conduct investigations more rapidly, and improve security outcomes by reducing false positives. Network Visibility Best-in-class network security monitoring tools offer insights into network traffic patterns, device interactions, and potential blind spots to enhance network monitoring and troubleshooting. To do this, they must connect with every asset on the network and successfully observe data transfers between assets. Integration No single security tool can be trusted to do everything on its own. Your network security monitoring platform must integrate with other security solutions, such as firewalls, intrusion detection/prevention systems (IDS/IPS), and SIEM platforms to create a comprehensive security ecosystem. If one tool fails to detect malicious activity, another may succeed. Customization No two organizations are the same. The best network monitoring solutions allow users to customize rules, alerts, and policies to align with specific security requirements and network environments. These customizations help security teams reduce alert fatigue and focus their efforts on the most important data traffic flows on the network. Advanced Features for Identifying Vulnerabilities & Weaknesses Threat Intelligence Integration Threat intelligence feeds enhance threat detection and response capabilities by providing in-depth information about the tactics, techniques, and procedures used by threat actors. These feeds update constantly to reflect the latest information on cybercriminal activities so analysts always have the latest data. Forensic Capabilities Detailed data and forensic tools provide in-depth analysis of security breaches and related incidents, allowing analysts to attribute attacks to hackers and discover the extent of cyberattacks. With retroactive forensics, investigators can include historical network data and look for evidence of compromise in the past. Automated Response Automated responses to security threats can isolate affected devices or modify firewall rules the moment malicious behavior is detected. Automated detection and response workflows must be carefully configured to avoid business disruptions stemming from misconfigured algorithms repeatedly denying legitimate traffic. Application-level Visibility Some network security monitoring tools can identify and classify network traffic by applications and services , enabling granular control and monitoring. This makes it easier for analysts to categorize traffic based on its protocol, which can streamline investigations into attacks that take place on the application layer. Cloud and Virtual Network Support Cloud-enabled organizations need monitoring capabilities that support cloud environments and virtualized networks. Without visibility into these parts of the hybrid network, security vulnerabilities may go unnoticed. Cloud-native network monitoring tools must include data on public and private cloud instances as well as containerized assets. Machine Learning and AI Advanced machine learning and artificial intelligence algorithms can improve threat detection accuracy and reduce false positives. These features often work by examining large-scale network traffic data and identifying patterns within the dataset. Different vendors have different AI models and varying levels of competence with emerging AI technology. User and Entity Behavior Analytics (UEBA) UEBA platforms monitor asset behaviors to detect insider threats and compromised accounts. This advanced feature allows analysts to assign dynamic risk scores to authenticated users and assets, triggering alerts when their activities deviate too far from their established routine. Threat Hunting Tools Network monitoring tools can provide extra features and workflows for proactive threat hunting and security analysis. These tools may match observed behaviors with known indicators of compromise, or match observed traffic patterns with the tactics, techniques, and procedures of known threat actors. AlgoSec: The Preferred Network Security Monitoring Solution AlgoSec has earned an impressive reputation for its network security policy management capabilities. The platform empowers security analysts and IT administrators to manage and optimize network security policies effectively. It includes comprehensive firewall policy and change management capabilities along with comprehensive solutions for automating application connectivity across the hybrid network. Here are some reasons why IT leaders choose AlgoSec as their preferred network security policy management solution: Policy Optimsization: AlgoSec can analyze firewall rules and network security policies to identify redundant or conflicting rules, helping organizations optimize their security posture and improve rule efficiency. Change Management: It offers tools for tracking and managing changes to firewall and network data policies, ensuring that changes are made in a controlled and compliant manner. Risk Assessment: AlgoSec can assess the potential security risks associated with firewall rule changes before they are implemented, helping organizations make informed decisions. Compliance Reporting: It provides reports and dashboards to assist with compliance audits, making it easier to demonstrate regulatory compliance to regulators. Automation: AlgoSec offers automation capabilities to streamline policy management tasks, reducing the risk of human error and improving operational efficiency. Visibility: It provides visibility into network traffic and policy changes, helping security teams monitor and respond to potential security incidents. 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

Nick Ellsmore is an Australian cybersecurity professional whose thoughts on the future of cybersecurity are always insightful. Having a... Cloud Security Errare humanum est 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 11/25/21 Published Nick Ellsmore is an Australian cybersecurity professional whose thoughts on the future of cybersecurity are always insightful. Having a deep respect for Nick, I really enjoyed listening to his latest podcast “Episode 79 Making the cyber sector redundant with Nick Ellsmore” . As Nick opened the door to debate on “all the mildly controversial views” he has put forward in the podcast, I decided to take a stab at a couple of points made by Nick. For some mysterious reason, these points have touched my nerve. So, here we go. Nick: The cybersecurity industry, we spent so long trying to get people to listen to us and take the issue seriously, you know, we’re now getting that, you know. Are the businesses really responding because we were trying to get people to listen to us? Let me rephrase this question. Are the businesses really spending more on cybersecurity because we were trying to get people to listen to us? The “cynical me” tells me No. Businesses are spending more on cybersecurity because they are losing more due to cyber incidents. It’s not the number of incidents; it’s their impact that is increasingly becoming devastating. Over the last ten years, there were plenty of front-page headliners that shattered even seemingly unshakable businesses and government bodies. Think of Target attack in 2013, the Bank of Bangladesh heist in 2016, Equifax breach in 2017, SolarWinds hack in 2020 .. the list goes on. We all know how Uber tried to bribe attackers to sweep the stolen customer data under the rug. But how many companies have succeeded in doing so without being caught? How many cyber incidents have never been disclosed? These headliners don’t stop. Each of them is another reputational blow, impacted stock options, rolled heads, stressed-out PR teams trying to play down the issue, knee-jerk reaction to acquire snake-oil-selling startups, etc. We’re not even talking about skewed election results (a topic for another discussion). Each one of them comes at a considerable cost. So no wonder many geniuses now realise that spending on cybersecurity can actually mitigate those risks. It’s not our perseverance that finally started paying off. It’s their pockets that started hurting. Nick: I think it’s important that we don’t lose sight of the fact that this is actually a bad thing to have to spend money on. Like, the reason that we’re doing this is not healthy. .. no one gets up in the morning and says, wow, I can’t wait to, you know, put better locks on my doors. It’s not the locks we sell. We sell gym membership. We want people to do something now to stop bad things from happening in the future. It’s a concept of hygiene, insurance, prevention, health checks. People are free not to pursue these steps, and run their business the way they used to .. until they get hacked, get into the front page, wondering first “Why me?” and then appointing a scapegoat. Nick: And so I think we need to remember that, in a sense, our job is to create the entire redundancy of this sector. Like, if we actually do our job, well, then we all have to go and do something else, because security is no longer an issue. It won’t happen due to 2 main reasons. Émile Durkheim believed in a “society of saints”. Unfortunately, it is a utopia. Greed, hunger, jealousy, poverty are the never-ending satellites of the human race that will constantly fuel crime. Some of them are induced by wars, some — by corrupt regimes, some — by sanctions, some — by imperfect laws. But in the end — there will always be Haves and Have Nots, and therefore, fundamental inequality. And that will feed crime. “Errare humanum est” , Seneca. To err is human. Because of human errors, there will always be vulnerabilities in code. Because of human nature (and as its derivative, geopolitical or religious tension, domination, competition, nationalism, fight for resources), there will always be people willing to and capable of exploiting those vulnerabilities. Mix those two ingredients — and you get a perfect recipe for cybercrime. Multiply that with never-ending computerisation, automation, digital transformation, and you get a constantly growing attack surface. No matter how well we do our job, we can only control cybercrime and keep the lid on it, but we can’t eradicate it. Thinking we could would be utopic. Another important consideration here is budget constraints. Building proper security is never fun — it’s a tedious process that burns cash but produces no tangible outcome. Imagine a project with an allocated budget B to build a product P with a feature set F, in a timeframe T. Quite often, such a project will be underfinanced, potentially leading to a poor choice of coders, overcommitted promises, unrealistic expectations. Eventually leading to this (oldie, but goldie): Add cybersecurity to this picture, and you’ll get an extra step that seemingly complicates everything even further: The project investors will undoubtedly question why that extra step was needed. Is there a new feature that no one else has? Is there a unique solution to an old problem? None of that? Then what’s the justification for such over-complication? Planning for proper cybersecurity built-in is often perceived as FUD. If it’s not tangible, why do we need it? Customers won’t see it. No one will see it. Scary stories in the press? Nah, that’ll never happen to us. In some way, extra budgeting for cybersecurity is anti-capitalistic in nature. It increases the product cost and, therefore, its price, making it less competitive. It defeats the purpose of outsourcing product development, often making outsourcing impossible. From the business point of view, putting “Sec” into “DevOps” does not make sense. That’s Ok. No need. .. until it all gloriously hits the fan, and then we go back to STEP 1. Then, maybe, just maybe, the customer will say, “If we have budgeted for that extra step, then maybe we would have been better off”. 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

Previous Part of the analysis is available here. Next Part of the analysis is available here. Update from 19 December 2020: ‍Prevasio... Cloud Security Sunburst Backdoor, Part II: DGA & The List of Victims 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/17/20 Published Previous Part of the analysis is available here . Next Part of the analysis is available here . Update from 19 December 2020: Prevasio would like to thank Zetalytics for providing us with an updated (larger) list of passive (historic) DNS queries for the domains generated by the malware. As described in the first part of our analysis, the DGA (Domain Generation Algorithm) of the Sunburst backdoor produces a domain name that may look like: fivu4vjamve5vfrtn2huov[.]appsync-api.us-west-2[.]avsvmcloud[.]com The first part of the domain name (before the first dot) consists of a 16-character random string, appended with an encoded computer’s domain name. This is the domain in which the local computer is registered. From the example string above, we can conclude that the encoded computer’s domain starts from the 17th character and up until the dot (highlighted in yellow): fivu4vjamve5vfrt n2huov In order to encode a local computer’s domain name, the malware uses one of 2 simple methods: Method 1 : a substitution table, if the domain name consists of small letters, digits, or special characters ‘-‘, ‘_’, ‘.’ Method 2 : base64 with a custom alphabet, in case of capital letters present in the domain name Method 1 In our example, the encoded domain name is “n2huov” . As it does not have any capital letters, the malware encodes it with a substitution table “rq3gsalt6u1iyfzop572d49bnx8cvmkewhj” . For each character in the domain name, the encoder replaces it with a character located in the substitution table four characters right from the original character. In order to decode the name back, all we have to do is to replace each encoded character with another character, located in the substitution table four characters left from the original character. To illustrate this method, imagine that the original substitution table is printed on a paper strip and then covered with a card with 6 perforated windows. Above each window, there is a sticker note with a number on it, to reflect the order of characters in the word “n2huov” , where ‘n’ is #1, ‘2’ is #2, ‘h’ is #3 and so on: Once the paper strip is pulled by 4 characters right, the perforated windows will reveal a different word underneath the card: “domain” , where ‘d’ is #1, ‘o’ is #2, ‘m’ is #3, etc.: A special case is reserved for such characters as ‘0’ , ‘-‘ , ‘_’ , ‘.’ . These characters are encoded with ‘0’ , followed with a character from the substitution table. An index of that character in the substitution table, divided by 4, provides an index within the string “0_-.” . The following snippet in C# illustrates how an encoded string can be decoded: static string decode_domain( string s) { string table = "rq3gsalt6u1iyfzop572d49bnx8cvmkewhj" ; string result = "" ; for ( int i = 0 ; i < s.Length; i++) { if (s[i] != '0' ) { result += table[(table.IndexOf(s[i]) + table.Length - 4 ) % table.Length]; } else { if (i < s.Length - 1 ) { if (table.Contains(s[i + 1 ])) { result += "0_-." [table.IndexOf(s[i + 1 ]) % 4 ]; } else { break ; } } i++; } } return result; } Method 2 This method is a standard base64 encoder with a custom alphabet “ph2eifo3n5utg1j8d94qrvbmk0sal76c” . Here is a snippet in C# that provides a decoder: public static string FromBase32String( string str) { string table = "ph2eifo3n5utg1j8d94qrvbmk0sal76c" ; int numBytes = str.Length * 5 / 8 ; byte [] bytes = new Byte[numBytes]; int bit_buffer; int currentCharIndex; int bits_in_buffer; if (str.Length < 3 ) { bytes[ 0 ] = ( byte )(table.IndexOf(str[ 0 ]) | table.IndexOf(str[ 1 ]) << 5 ); return System.Text.Encoding.UTF8.GetString(bytes); } bit_buffer = (table.IndexOf(str[ 0 ]) | table.IndexOf(str[ 1 ]) << 5 ); bits_in_buffer = 10 ; currentCharIndex = 2 ; for ( int i = 0 ; i < bytes.Length; i++) { bytes[i] = ( byte )bit_buffer; bit_buffer >>= 8 ; bits_in_buffer -= 8 ; while (bits_in_buffer < 8 && currentCharIndex < str.Length) { bit_buffer |= table.IndexOf(str[currentCharIndex++]) << bits_in_buffer; bits_in_buffer += 5 ; } } return System.Text.Encoding.UTF8.GetString(bytes); } When the malware encodes a domain using Method 2, it prepends the encrypted string with a double zero character: “00” . Following that, extracting a domain part of an encoded domain name (long form) is as simple as: static string get_domain_part( string s) { int i = s.IndexOf( ".appsync-api" ); if (i > 0 ) { s = s.Substring( 0 , i); if (s.Length > 16 ) { return s.Substring( 16 ); } } return "" ; } Once the domain part is extracted, the decoded domain name can be obtained by using Method 1 or Method 2, as explained above: if (domain.StartsWith( "00" )) { decoded = FromBase32String(domain.Substring( 2 )); } else { decoded = decode_domain(domain); } Decrypting the Victims’ Domain Names To see the decoder in action, let’s select 2 lists: List #1 Bambenek Consulting has provided a list of observed hostnames for the DGA domain. List #2 The second list has surfaced in a Paste bin paste , allegedly sourced from Zetalytics / Zonecruncher . NOTE: This list is fairly ‘noisy’, as it has non-decodable domain names. By feeding both lists to our decoder, we can now obtain a list of decoded domains, that could have been generated by the victims of the Sunburst backdoor. DISCLAIMER: It is not clear if the provided lists contain valid domain names that indeed belong to the victims. It is quite possible that the encoded domain names were produced by third-party tools, sandboxes, or by researchers that investigated and analysed the backdoor. The decoded domain names are provided purely as a reverse engineering exercise. The resulting list was manually processed to eliminate noise, and to exclude duplicate entries. Following that, we have made an attempt to map the obtained domain names to the company names, using Google search. Reader’s discretion is advised as such mappings could be inaccurate. Decoded Domain Mapping (Could Be Inaccurate) hgvc.com Hilton Grand Vacations Amerisaf AMERISAFE, Inc. kcpl.com Kansas City Power and Light Company SFBALLET San Francisco Ballet scif.com State Compensation Insurance Fund LOGOSTEC Logostec Ventilação Industrial ARYZTA.C ARYZTA Food Solutions bmrn.com BioMarin Pharmaceutical Inc. AHCCCS.S Arizona Health Care Cost Containment System nnge.org Next Generation Global Education cree.com Cree, Inc (semiconductor products) calsb.org The State Bar of California rbe.sk.ca Regina Public Schools cisco.com Cisco Systems pcsco.com Professional Computer Systems barrie.ca City of Barrie ripta.com Rhode Island Public Transit Authority uncity.dk UN City (Building in Denmark) bisco.int Boambee Industrial Supplies (Bisco) haifa.edu University of Haifa smsnet.pl SMSNET, Poland fcmat.org Fiscal Crisis and Management Assistance Team wiley.com Wiley (publishing) ciena.com Ciena (networking systems) belkin.com Belkin spsd.sk.ca Saskatoon Public Schools pqcorp.com PQ Corporation ftfcu.corp First Tech Federal Credit Union bop.com.pk The Bank of Punjab nvidia.com NVidia insead.org INSEAD (non-profit, private university) usd373.org Newton Public Schools agloan.ads American AgCredit pageaz.gov City of Page jarvis.lab Erich Jarvis Lab ch2news.tv Channel 2 (Israeli TV channel) bgeltd.com Bradford / Hammacher Remote Support Software dsh.ca.gov California Department of State Hospitals dotcomm.org Douglas Omaha Technology Commission sc.pima.gov Arizona Superior Court in Pima County itps.uk.net IT Professional Services, UK moncton.loc City of Moncton acmedctr.ad Alameda Health System csci-va.com Computer Systems Center Incorporated keyano.local Keyano College uis.kent.edu Kent State University alm.brand.dk Sydbank Group (Banking, Denmark) ironform.com Ironform (metal fabrication) corp.ncr.com NCR Corporation ap.serco.com Serco Asia Pacific int.sap.corp SAP mmhs-fla.org Cleveland Clinic Martin Health nswhealth.net NSW Health mixonhill.com Mixon Hill (intelligent transportation systems) bcofsa.com.ar Banco de Formosa ci.dublin.ca. Dublin, City in California siskiyous.edu College of the Siskiyous weioffice.com Walton Family Foundation ecobank.group Ecobank Group (Africa) corp.sana.com Sana Biotechnology med.ds.osd.mi US Gov Information System wz.hasbro.com Hasbro (Toy company) its.iastate.ed Iowa State University amr.corp.intel Intel cds.capilanou. Capilano University e-idsolutions. IDSolutions (video conferencing) helixwater.org Helix Water District detmir-group.r Detsky Mir (Russian children’s retailer) int.lukoil-int LUKOIL (Oil and gas company, Russia) ad.azarthritis Arizona Arthritis and Rheumatology Associates net.vestfor.dk Vestforbrænding allegronet.co. Allegronet (Cloud based services, Israel) us.deloitte.co Deloitte central.pima.g Pima County Government city.kingston. City of Kingston staff.technion Technion – Israel Institute of Technology airquality.org Sacramento Metropolitan Air Quality Management District phabahamas.org Public Hospitals Authority, Caribbean parametrix.com Parametrix (Engineering) ad.checkpoint. Check Point corp.riotinto. Rio Tinto (Mining company, Australia) intra.rakuten. Rakuten us.rwbaird.com Robert W. Baird & Co. (Financial services) ville.terrebonn Ville de Terrebonne woodruff-sawyer Woodruff-Sawyer & Co., Inc. fisherbartoninc Fisher Barton Group banccentral.com BancCentral Financial Services Corp. taylorfarms.com Taylor Fresh Foods neophotonics.co NeoPhotonics (optoelectronic devices) gloucesterva.ne Gloucester County magnoliaisd.loc Magnolia Independent School District zippertubing.co Zippertubing (Manufacturing) milledgeville.l Milledgeville (City in Georgia) digitalreachinc Digital Reach, Inc. deniz.denizbank DenizBank thoughtspot.int ThoughtSpot (Business intelligence) lufkintexas.net Lufkin (City in Texas) digitalsense.co Digital Sense (Cloud Services) wrbaustralia.ad W. R. Berkley Insurance Australia christieclinic. Christie Clinic Telehealth signaturebank.l Signature Bank dufferincounty. Dufferin County mountsinai.hosp Mount Sinai Hospital securview.local Securview Victory (Video Interface technology) weber-kunststof Weber Kunststoftechniek parentpay.local ParentPay (Cashless Payments) europapier.inte Europapier International AG molsoncoors.com Molson Coors Beverage Company fujitsugeneral. Fujitsu General cityofsacramento City of Sacramento ninewellshospita Ninewells Hospital fortsmithlibrary Fort Smith Public Library dokkenengineerin Dokken Engineering vantagedatacente Vantage Data Centers friendshipstateb Friendship State Bank clinicasierravis Clinica Sierra Vista ftsillapachecasi Apache Casino Hotel voceracommunicat Vocera (clinical communications) mutualofomahabanMutual of Omaha Bank 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

Increasing Cisco ACI adoption with AlgoSec 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

6 best practices to stay secure in the hybrid cloud 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

Product Marketing Manager AlgoSec Cloud Navigating Compliance in the Cloud 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 6/29/25 Published Cloud adoption isn't just soaring; it's practically stratospheric. Businesses of all sizes are leveraging the agility, scalability, and innovation that cloud environments offer. Yet, hand-in-hand with this incredible growth comes an often-overlooked challenge: the increasing complexities of maintaining compliance. Whether your organization grapples with industry-specific regulations like HIPAA for healthcare, PCI DSS for payment processing, SOC 2 for service organizations, or simply adheres to stringent internal governance policies, navigating the ever-shifting landscape of cloud compliance can feel incredibly daunting. It's akin to staring at a giant, knotted ball of spaghetti, unsure where to even begin untangling. But here’s the good news: while it demands attention and a strategic approach, staying compliant in the cloud is far from an impossible feat. This article aims to be your friendly guide through the compliance labyrinth, offering practical insights and key considerations to help you maintain order and assurance in your cloud environments. The foundation: Understanding the Shared Responsibility Model Before you even think about specific regulations, you must grasp the Shared Responsibility Model . This is the bedrock of cloud compliance, and misunderstanding it is a common pitfall that can lead to critical security and compliance gaps. In essence, your cloud provider (AWS, Azure, Google Cloud, etc.) is responsible for the security of the cloud – that means the underlying infrastructure, the physical security of data centers, the global network, and the hypervisors. However, you are responsible for the security in the cloud . This includes your data, your configurations, network traffic protection, identity and access management, and the applications you deploy. Think of it like a house: the cloud provider builds and secures the house (foundation, walls, roof), but you’re responsible for what you put inside it, how you lock the doors and windows, and who you let in. A clear understanding of this division is paramount for effective cloud security and compliance. Simplify to conquer: Centralize your compliance efforts Imagine trying to enforce different rules for different teams using separate playbooks – it's inefficient and riddled with potential for error. The same applies to cloud compliance, especially in multi-cloud environments. Juggling disparate compliance requirements across multiple cloud providers manually is not just time-consuming; it's a recipe for errors, missed deadlines, and a constant state of anxiety. The solution? Aim for a unified, centralized approach to policy enforcement and auditing across your entire multi-cloud footprint. This means establishing consistent security policies and compliance controls that can be applied and monitored seamlessly, regardless of which cloud platform your assets reside on. A unified strategy streamlines management, reduces complexity, and significantly lowers the risk of non-compliance. The power of automation: Your compliance superpower Manual compliance checks are, to put it mildly, an Achilles' heel in today's dynamic cloud environments. They are incredibly time-consuming, prone to human error, and simply cannot keep pace with the continuous changes in cloud configurations and evolving threats. This is where automation becomes your most potent compliance superpower. Leveraging automation for continuous monitoring of configurations, access controls, and network flows ensures ongoing adherence to compliance standards. Automated tools can flag deviations from policies in real-time, identify misconfigurations before they become vulnerabilities, and provide instant insights into your compliance posture. Think of it as having an always-on, hyper-vigilant auditor embedded directly within your cloud infrastructure. It frees up your security teams to focus on more strategic initiatives, rather than endless manual checks. Prove it: Maintain comprehensive audit trails Compliance isn't just about being compliant; it's about proving you're compliant. When an auditor comes knocking – and they will – you need to provide clear, irrefutable, and easily accessible evidence of your compliance posture. This means maintaining comprehensive, immutable audit trails . Ensure that all security events, configuration changes, network access attempts, and policy modifications are meticulously logged and retained. These logs serve as your digital paper trail, demonstrating due diligence and adherence to regulatory requirements. The ability to quickly retrieve specific audit data is critical during assessments, turning what could be a stressful scramble into a smooth, evidence-based conversation. The dynamic duo: Regular review and adaptation Cloud environments are not static. Regulations evolve, new services emerge, and your own business needs change. Therefore, compliance in the cloud is never a "set it and forget it" task. It requires a dynamic approach: regular review and adaptation . Implement a robust process for periodically reviewing your compliance controls. Are they still relevant? Are there new regulations or updates you need to account for? Are your existing controls still effective against emerging threats? Adapt your policies and controls as needed to ensure continuous alignment with both external regulatory demands and your internal security posture. This proactive stance keeps you ahead of potential issues rather than constantly playing catch-up. Simplify Your Journey with the Right Tools Ultimately, staying compliant in the cloud boils down to three core pillars: clear visibility into your cloud environment, consistent and automated policy enforcement, and the demonstrable ability to prove adherence. This is where specialized tools can be invaluable. Solutions like AlgoSec Cloud Enterprise can truly be your trusted co-pilot in this intricate journey. It's designed to help you discover all your cloud assets across multiple providers, proactively identify compliance risks and misconfigurations, and automate policy enforcement. By providing a unified view and control plane, it gives you the confidence that your multi-cloud environment not only meets but also continuously maintains the strictest regulatory requirements. Don't let the complexities of cloud compliance slow your innovation or introduce unnecessary risk. Embrace strategic approaches, leverage automation, and choose the right partners to keep those clouds compliant and your business secure. 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