Search results

Webinars Migrate & modernize: Supercharging your Cisco Nexus refresh with ACI If you still have Cisco Nexus 7000 devices in your environment, surely you have been inundated with end-of-life warnings and next-gen messaging touting the benefits of upgrading to Nexus 9000 with Cisco ACI. We know, modernizing your infrastructure can be a real pain, but with change also comes opportunity! Find out in this session how to leverage your Nexus refresh to increase your efficiency and productivity, and reduce security concerns at the same time. AlgoSec’s Jeremiah Cornelius, along with Cisco’s Cynthia Broderick, will guide you on how to: Migrate your current Nexus flows to ACI using your preferred mode – network or application centric Remove vulnerabilities caused by human error via automation of network change processes. Instantly identify and remediate risk and compliance violations. June 9, 2021 Cynthia Broderick DC Networking, Business Development at Cisco Jeremiah Cornelius Technical Leader for Alliances and Partners at AlgoSec Relevant resources Modernize your network and harness the power of Nexus & Cisco ACI with AlgoSec Watch Video AlgoSec’s integration with Cisco ACI Watch Video Cisco & AlgoSec achieving application-driven security across your hybrid 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... phone By submitting this form, I accept AlgoSec's privacy policy Continue

Challenges in Managing Security in Native, Hybrid and Multi-Cloud Environments 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... phone By submitting this form, I accept AlgoSec's privacy policy Continue

The firewall audit checklist: Six best practices for simplifying firewall compliance and risk mitigation 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... phone By submitting this form, I accept AlgoSec's privacy policy Continue

Explore Algosec's customer success stories to see how organizations worldwide improve security, compliance, and efficiency with our solutions. Nationwide Organization Nationwide Industry Financial Services Headquarters Columbus Ohio, USA Download case study Share Customer
success stories AlgoSec delivers an application-centric solution to meet the network security challenges of one of the top financial services firms in the US. To learn more, go to https://algosec.com/ Schedule time with one of our experts

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

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 6 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* Phone number* country* Select country... By submitting this form, I accept AlgoSec's privacy policy Schedule a call

Azure Security Best Practices: Don't Get Caught with Your Cloud Pants Down   Executive Summary   The cloud isn't some futuristic fantasy... Cloud Security Azure Security Best Practices Asher Benbenisty 5 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 11/25/24 Published Azure Security Best Practices: Don't Get Caught with Your Cloud Pants Down Executive Summary The cloud isn't some futuristic fantasy anymore, folks. It's the backbone of modern business, and Azure is charging hard, fueled by AI, to potentially dethrone AWS by 2026. But with this breakneck adoption comes a harsh reality: security can't be an afterthought. This article dives deep into why robust security practices are non-negotiable in Azure and how tools like Microsoft Sentinel and Defender XDR can be your digital bodyguards. Introduction Let's face it, organizations are flocking to the cloud like moths to a digital flame. Why? Cost savings, streamlined operations, and the ability to scale at warp speed. We're talking serious money here – a projected $805 billion spent on public cloud services in 2024! The cloud's not just disrupting the game; it is the game. And the playing field is shifting. AWS might be the king of the hill right now, but Azure's hot on its heels, thanks to some serious AI muscle. ( As of 2024, they hold market shares of 31%, 24%, and 11%, respectively .) Forbes even predicts an Azure takeover by 2026. Exciting times, right? Hold your horses. This rapid cloud adoption has a dark side. Security threats are lurking around every corner, and sticking to best practices is more crucial than ever. Cloud service managers, listen up: you need to wrap your heads around the shared responsibility model (Figure 1). Think of it like this: you and Azure are partners in crime prevention. You're both responsible for keeping your digital assets safe, but you need to know who's holding which piece of the security puzzle. Don't assume security is built-in – it's a team effort, and you need to pull your weight. Figure 1: The shared responsibility model Azure's Security Architecture: A Fortress in the Cloud Okay, I get it. The shared responsibility model can feel like navigating a maze blindfolded. But here's the deal: whether you're dabbling in IaaS, PaaS, or SaaS, Azure's got your infrastructure covered. Their global network of data centers is built like Fort Knox, meeting industry standards like ISO/IEC 27001:2022 , HIPAA , and NIST SP 800-53 . But remember your part of the bargain! Azure provides a killer arsenal of security products to protect your workloads, both in Azure and beyond. Figure 2: Azure’s security architecture Take Microsoft Sentinel, for example. This superhero of a tool automatically sniffs out threats, investigates them, and neutralizes them before they can wreak havoc. It's like having a 24/7 security team with superhuman senses. And don't forget about Microsoft Defender XDR. This comprehensive security suite is like a digital Swiss Army knife, protecting your identities, endpoints, applications, email, and cloud apps. It's got your back, no matter where you turn. With Sentinel and Defender XDR in your corner, you're well-equipped to tackle the security challenges that come with cloud adoption. But don't get complacent! Let's dive into some core security best practices that will make your Azure environment an impenetrable fortress. Core Security Best Practices: Lock Down Your Secrets Protecting Secrets: Best Practices Using Azure Key Vault We all have secrets, right? In the digital world, those secrets are things like passwords, API keys, and encryption keys. You can't just leave them lying around for any cybercriminal to snatch. That's where Azure Key Vault comes in. This secure vault is like a digital safe deposit box for your sensitive data. It uses hardware security modules (HSMs) to keep your secrets locked down tight, even if someone manages to breach your defenses. Big names like Victoria's Secret & Co , Evup, and Sage trust Key Vault to keep their secrets safe. Figure 3: A new Key Vault named “algosec-kv” Here's a pro tip: once you've stashed your secrets in Key Vault, use a managed identity to access them. This eliminates the need to hardcode credentials in your code, minimizing the risk of exposure. var client = new SecretClient(new Uri("https://. vault.azure.net/ "), new DefaultAzureCredential(),options); KeyVaultSecret secret = client.GetSecret(""); string secretValue = secret.Value; Key Vault is a fantastic tool, but it's not a silver bullet. Download our checklist of additional best practices to keep your secrets safe: Database and Data Security: More Than Just Locking the Door Azure offers a smorgasbord of data storage solutions, from Azure SQL Database to Azure Blob Storage. But securing your data isn't just about protecting it at rest. You need to think about data in use and data in transit, too. Download our checklist for a full action plan: Identity Management: Who Are You, and What Are You Doing Here? Encryption is great, but it's only half the battle. You need to know who's accessing your resources and what they're doing. That's where identity access management (IAM) comes in. Think of IAM as a digital bouncer, controlling access to your network resources. It's all about verifying identities and granting the right level of access – no more, no less. Zero-trust network access (ZTNA) is your secret weapon here. It's like having a security checkpoint at every corner of your network, ensuring that only authorized users can access your resources. Figure 4: Zero-trust security architecture Remember the Capital One breach? A misconfigured firewall and overly broad permissions led to a massive data leak. Don't let that be you! Follow Azure's IAM documentation to build a robust and secure identity management system. Network Security: Building a Digital Moat Your network architecture is the foundation of your security posture. Choose wisely, my friends! The hub-spoke model is a popular choice in Azure, centralizing common services in a secure hub and isolating workloads in separate spokes. Figure 5: Hub-spoke network architecture in Azure (Source: Azure documentation ) For a checklist of how the hub-spoke model can boosts your security, download our checklist here. Digital Realty , a real estate investment giant, uses the hub-spoke model to secure its global portal and REST APIs. It's a testament to the power of this architecture for both security and performance. Figure 6: Digital Realty’s use of hub-spoke architecture (Adapted from Microsoft Customer Stories ) Operational Security: Stay Vigilant, Stay Secure (Continued) When a security incident strikes, your response time is critical. Think of operational security as your digital first aid kit. It's about minimizing human error and automating processes to speed up threat detection and response. We've already talked about MFA, password management, and the dynamic duo of Defender XDR and Sentinel. Download our checklist for a few more operational security essentials to add to your arsenal. Figure 7: Build-deploy workflow automation (Source: Azure documentation ) Think of these best practices as guardrails, guiding you toward secure decisions. But remember, flexibility is key. Adapt these practices to your specific environment and architecture. Conclusion As Azure's popularity skyrockets, so do the stakes. The shared responsibility model means you're not off the hook when it comes to security. Azure provides powerful tools like Sentinel and Defender XDR, but it's up to you to use them wisely and follow best practices. Protect your secrets like they're buried treasure, secure your data with Fort Knox-level encryption, implement identity management that would make a border patrol agent proud, and build a network architecture that's a digital fortress. And don't forget about operational security – it's the glue that holds it all together. But let's be real, managing security policies across multiple clouds can be a nightmare. That's where tools like AlgoSec CloudFlow come in. They provide a clear view of your security landscape, helping you identify vulnerabilities and streamline policy management. It's like having a security command center for your entire cloud infrastructure. So, what are you waiting for? Request a demo today and let AlgoSec help you build an Azure environment that's so secure, even the most determined cybercriminals will be left scratching their heads. 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* Phone number* country* Select country... By submitting this form, I accept AlgoSec's privacy policy Schedule a call

Discover how micro-segmentation can help you reduce the surface of your network attacks and protect your organization from cyber-attacks. Webinars CTO Round Table: Fighting Ransomware with Micro-segmentation In the past few months, we’ve witnessed a steep rise in ransomware attacks targeting anyone from small companies to large, global enterprises. It seems like no organization is immune to ransomware. So how do you protect your network from such attacks? Join our discussion with AlgoSec CTO Prof. Avishai Wool and Guardicore CTO Ariel Zeitlin, and discover how micro-segmentation can help you reduce your network attack surface and protect your organization from cyber-attacks. Learn: Why micro-segmentation is critical to fighting ransomware and other cyber threats. Common pitfalls organizations face when implementing a micro-segmentation project How to discover applications and their connectivity requirements across complex network environments. How to write micro-segmentation filtering policy within and outside the data center November 17, 2020 Ariel Zeitlin CTO Guardicore Prof. Avishai Wool CTO & Co Founder AlgoSec Relevant resources Defining & Enforcing a Micro-segmentation Strategy Read Document Building a Blueprint for a Successful Micro-segmentation Implementation Keep Reading Ransomware Attack: Best practices to help organizations proactively prevent, contain and respond 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... phone By submitting this form, I accept AlgoSec's privacy policy Continue

Discover AlgoSec's transformative 2024 journey: innovation in secure connectivity, industry leadership, and a bold vision for an empowered, Network Security 2024 in review: A transformative year for AlgoSec in secure application connectivity Adel Osta Dadan 4 min read Adel Osta Dadan 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/16/24 Published As we close out 2024, I find myself reflecting on what has truly been a transformative journey for AlgoSec . This year has been filled with ground-breaking innovation, meaningful industry recognition, and a deep commitment to our vision of secure application connectivity. It has been a year where every challenge was met with determination, every milestone became a stepping-stone toward a greater future, and every success strengthened our resolve to lead in secure connectivity. Q1: Redefining secure application connectivity. We started the year by challenging traditional approaches to secure application connectivity, setting the tone for everything that followed. State of Network Security Report : The release of our State of Network Security Report was the first major milestone, quickly becoming a cornerstone of our thought leadership. This report highlighted major trends such as the enduring importance of hybrid networks and the growing shift toward multi-cloud strategies. We emphasized that security could—and should—be a driver of digital transformation. The findings made it clear that advanced tools like SD-WAN and SASE are no longer optional but essential for navigating today’s increasingly complex connectivity landscape. Launch of AlgoSec A33: In March, we launched AlgoSec A33, an application-first approach to security management. This was not just another product release; it was a clear statement of our belief that security should be an enabler of business growth. With A33, we offered seamless integration into business processes, aligning security with broader organizational goals. This launch symbolized our commitment to making secure application connectivity the foundation for organizational success. Q2: Advancing security automation and building connections. Building on the momentum from Q1, the second quarter was about advancing our automation capabilities and strengthening connections within our community. Recognition from GigaOm and Gartner : During Q2, we received meaningful recognition from GigaOm and Gartner, being named an Established Vendor in Gartner Peer Insights Voice of the Customer for Secure Connectivity Automation Platforms. This recognition validated our dedication to combining intelligent automation with human expertise, simplifying network security across increasingly complex multi-cloud environments. It was a proud moment that affirmed our efforts and pushed us to do even more. Industry Conversations on Secure Connectivity: We also took the lead in important industry conversations during this period. From enhancing visibility to tackling the challenges of multi-cloud security, AlgoSec was at the forefront—delivering solutions that drove operational efficiency while addressing the real-world challenges faced by our customers. These conversations reinforced our position as a proactive leader committed to shaping the future of secure connectivity. Q3: Setting new standards in secure connectivity. Moving into Q3, our goal was to push the boundaries further and set new industry standards for secure connectivity. Introduction of Security Application Connectivity. Anywhere (SACA): One of the major highlights of the third quarter was the introduction of our Security Application Connectivity Anyware (SACA) framework. SACA embodied our vision that secure connectivity is fundamental to digital transformation. By providing our customers with confidence in their application flows—without sacrificing performance or agility—we enabled them to innovate with assurance. AlgoSummit 2024: In September, we hosted AlgoSummit 2024—our flagship event that brought together customers, partners, and industry experts. AlgoSummit was not just an event but a collaborative platform for shared learning and innovation. Together, we explored the evolving landscape of secure connectivity in hybrid and multi-cloud environments. This summit further solidified AlgoSec's role as a visionary leader in the industry, committed to both solving today’s challenges and anticipating those of tomorrow. Q4: Expanding Zero Trust and navigating regulatory changes. As we entered the final quarter, our focus shifted to expanding our Zero Trust offerings and helping customers prepare for upcoming regulatory changes. Zero Trust Architecture Expansion: We made significant strides in advancing our Zero Trust network architecture initiatives in Q4. As hybrid environments grow more complex, we understood the need to simplify Zero Trust adoption for our customers. By leveraging both micro and macro-segmentation strategies, we offered a streamlined, application-centric approach that provided greater visibility and control—ensuring that connectivity remained secure, segmented, and compliant. Navigating DORA Compliance : Another key focus for Q4 was helping our customers navigate the requirements of the Digital Operational Resilience Act (DORA). With the compliance deadline fast approaching, we used our intelligent automation tools to make the transition as smooth as possible. Our solutions offered comprehensive visibility, automated risk assessments, and policy recertification, allowing financial institutions to meet DORA’s stringent standards confidently and strengthen their resilience. Recognition for innovation and ethical leadership Throughout the year, our commitment to responsible innovation and ethical leadership did not go unnoticed. SC Awards Finalist in Application Security: Being named a finalist in the SC Awards for Application Security was a significant milestone, reaffirming our dedication to protecting the applications that drive business growth and innovation. Top InfoSec Innovator Award from CyberDefense Magazine: In November, we were recognized as a Top InfoSec Innovator by CyberDefense Magazine. This accolade underscored our focus on ethical innovation—delivering security solutions that are trustworthy, responsible, and aligned with global standards. Accolades in Network and Application Security : Additionally, we were named a Hot Company in Secure Application Connectivity and recognized as the Most Innovative in Application Security. These awards were not just acknowledgments of our technology but a testament to our ongoing commitment to setting new standards of transparency, accountability, and secure connectivity. Cisco Meraki Marketplace Tech Partner of the Month : In October 2024, we were honored as the Cisco Meraki Marketplace Tech Partner of the Month based on our continued innovation and dedication to application security . This recognition highlights our ability to deliver holistic visibility, automate security policy changes, reduce risks, and ensure continuous compliance through seamless integration with Cisco Meraki solutions. Looking to the future: building on the foundations of 2024 Reflecting on 2024, it’s clear that this has been a year of significant growth, innovation, and resilience. The lessons we’ve learned and the progress we’ve made have laid a strong foundation for the future. As we look ahead to 2025, our mission remains clear: to continue providing application-centric security solutions that not only protect but also empower our customers to achieve their strategic objectives. I am incredibly grateful for the dedication of our team, the trust our customers have placed in us, and the opportunity to continue shaping the future of secure connectivity. Here’s to another year of impactful innovation, collaboration, and leadership as we step confidently into 2025. 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* Phone number* country* Select country... By submitting this form, I accept AlgoSec's privacy policy Schedule a call