Search results

Jeremiah Cornelius, Technical Lead for Alliances and Partners at AlgoSec, discusses how Cisco Nexus Dashboard Orchestrator (NDO) users can achieve policy-driven application-centric security management with AlgoSec. Leading Edge of the Data Center with AlgoSec and Cisco NDO AlgoSec ASMS A32.6 is our latest release to feature a major technology integration, built upon our well-established collaboration with Cisco — bringing this partnership to the front of the Cisco innovation cycle with... Application Connectivity Management Achieving policy-driven application-centric security management for Cisco Nexus Dashboard Orchestrat Jeremiah Cornelius 2 min read Jeremiah Cornelius Short bio about author here Lorem ipsum dolor sit amet consectetur. Vitae donec tincidunt elementum quam laoreet duis sit enim. Duis mattis velit sit leo diam. Tags Share this article 1/2/24 Published Jeremiah Cornelius, Technical Lead for Alliances and Partners at AlgoSec, discusses how Cisco Nexus Dashboard Orchestrator (NDO) users can achieve policy-driven application-centric security management with AlgoSec. Leading Edge of the Data Center with AlgoSec and Cisco NDO AlgoSec ASMS A32.6 is our latest release to feature a major technology integration, built upon our well-established collaboration with Cisco — bringing this partnership to the front of the Cisco innovation cycle with support for Nexus Dashboard Orchestrator (NDO) . NDO allows Cisco ACI – and legacy-style Data Center Network Management – to operate at scale in a global context, across data center and cloud regions. The AlgoSec solution with NDO brings the power of our intelligent automation and software-defined security features for ACI, including planning, change management, and microsegmentation, to this global scope. I urge you to see what AlgoSec delivers for ACI with multiple use cases, enabling application-mode operation and microsegmentation, and delivering integrated security operations workflows. AlgoSec now brings support for Shadow EPG and Inter-Site Contracts with NDO, to our existing ACI strength. Let’s Change the World by Intent I had my first encounter with Cisco Application Centric Infrastructure in 2014 at a Symantec Vision conference. The original Senior Product Manager and Technical Marketing lead were hosting a discussion about the new results from their recent Insieme acquisition and were eager to onboard new partners with security cases and added operations value. At the time I was promoting the security ecosystem of a different platform vendor, and I have to admit that I didn’t fully understand the tremendous changes that ACI was bringing to security for enterprise connectivity. It’s hard to believe that it’s now seven years since then and that Cisco ACI has mainstreamed software-defined networking — changing the way that network teams had grown used to running their networks and devices since at least the mid-’90s. Since that 2014 introduction, Cisco’s ACI changed the landscape of data center networking by introducing an intent-based approach, over earlier configuration-centric architecture models. This opened the way for accelerated movement by enterprise data centers to meet their requirements for internal cloud deployments, new DevOps and serverless application models, and the extension of these to public clouds for hybrid operation – all within a single networking technology that uses familiar switching elements. Two new, software-defined artifacts make this possible in ACI: End-Point Groups (EPG) and Contracts – individual rules that define characteristics and behavior for an allowed network connection. ACI Is Great, NDO Is Global That’s really where NDO comes into the picture. By now, we have an ACI-driven data center networking infrastructure, with management redundancy for the availability of applications and preserving their intent characteristics. Through the use of an infrastructure built on EPGs and contracts, we can reach from the mobile and desktop to the datacenter and the cloud. This means our next barrier is the sharing of intent-based objects and management operations, beyond the confines of a single data center. We want to do this without clustering types, that depend on the availability risk of individual controllers, and hit other limits for availability and oversight. Instead of labor-intensive and error-prone duplication of data center networks and security in different regions, and for different zones of cloud operation, NDO introduces “stretched” shadow EPGs, and inter-site contracts, for application-centric and intent-based, secure traffic which is agnostic to global topologies – wherever your users and applications need to be. NDO Deployment Topology – Image: Cisco Getting NDO Together with AlgoSec: Policy-Driven, App-Centric Security Management  Having added NDO capability to the formidable shared platform of AlgoSec and Cisco ACI, regional-wide and global policy operations can be executed in confidence with intelligent automation. AlgoSec makes it possible to plan for operations of the Cisco NDO scope of connected fabrics in application-centric mode, unlocking the ACI super-powers for micro-segmentation. This enables a shared model between networking and security teams for zero-trust and defense-in-depth, with accelerated, global-scope, secure application changes at the speed of business demand — within minutes, rather than days or weeks. Change management : For security policy change management this means that workloads may be securely re-located from on-premises to public cloud, under a single and uniform network model and change-management framework — ensuring consistency across multiple clouds and hybrid environments. Visibility : With an NDO-enabled ACI networking infrastructure and AlgoSec’s ASMS, all connectivity can be visualized at multiple levels of detail, across an entire multi-vendor, multi-cloud network. This means that individual security risks can be directly correlated to the assets that are impacted, and a full understanding of the impact by security controls on an application’s availability. Risk and Compliance : It’s possible across all the NDO connected fabrics to identify risk on-premises and through the connected ACI cloud networks, including additional cloud-provider security controls. The AlgoSec solution makes this a self-documenting system for NDO, with detailed reporting and an audit trail of network security changes, related to original business and application requests. This means that you can generate automated compliance reports, supporting a wide range of global regulations, and your own, self-tailored policies. The Road Ahead Cisco NDO is a major technology and AlgoSec is in the early days with our feature introduction, nonetheless, we are delighted and enthusiastic about our early adoption customers. Based on early reports with our Cisco partners, needs will arise for more automation, which would include the “zero-touch” push for policy changes – committing Shadow EPG and Inter-site Contract changes to the orchestrator, as we currently do for ACI APIC. Feedback will also shape a need for automation playbooks and workflows that are most useful in the NDO context, and that we can realize with a full committable policy by the ASMS Horizon Security Analyzer. Contact Us! I encourage anyone interested in NDO and enhancing their operational maturity in aligned network and security operation, to talk to us about our joint solution. We work together with Cisco teams and resellers and will be glad to share more. Schedule a demo Related Articles Q1 at AlgoSec: What innovations and milestones defined our start to 2026? AlgoSec Reviews Mar 19, 2023 · 2 min read 2025 in review: What innovations and milestones defined AlgoSec’s transformative year in 2025? AlgoSec Reviews Mar 19, 2023 · 2 min read Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read Speak to one of our experts Speak to one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Schedule a call

Before I became a Sale Engineer I started my career working in operations and I don’t remember the first time I heard the term zero trust... Zero Trust AlgoSec and Zero-Trust for Healthcare Adolfo Lopez 2 min read Adolfo Lopez 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/26/24 Published Before I became a Sale Engineer I started my career working in operations and I don’t remember the first time I heard the term zero trust but I all I knew is that it was very important and everyone was striving to get to that level of security. Today I’ll get into how AlgoSec can help achieve those goals, but first let’s have a quick recap on what zero trust is in the first place. There are countless whitepapers and frameworks that define zero trust much better than I can, but they are also multiple pages long, so I’ll do a quick recap. Traditionally when designing a network you may have different zones and each zone might have different levels of access. In many of these types of designs there is a lot of trust that is given once they are in a certain zone. For example, once someone gets to their workplace at the hospital, the nursing home, the dental center or any other medical office and does all the necessary authentication steps (proper company laptop, credentials, etc…) they potentially have free reign to everything. This is a very simple example and in a real-world scenario there would hopefully be many more safeguards in place. But what does happen in real world scenarios is that devices still manage to get trusted more than they should. And from my own experience and from working with customers this happens way too often. Especially in the healthcare industry this is becoming more and more important. These days there are many different types of medical devices, some that hold sensitive information, some scanning instruments, and some that might even be critical to patient support. More importantly many are connected to some type of network. Because of this level of connectivity, we do need to start shifting toward this idea of zero trust. In healthcare cybersecurity isn’t just a matter of maintaining the network, it’s about maintaining the critical operations of the hospitals running smoothly and patient data safe and secure. Maintaining security policies is critical to achieving zero trust. Below you can see some of the key features that AlgoSec has that can help achieve that goal. Feature Description Security Policy Analysis Analyze existing security policy sets across all parts of the network (on-premises and cloud) with various vendors. Policy Cleanup Identify and remove redundant rules, duplicate rules, and more from the first report. Specific Recommendations Over time, recommendations become more specific, such as identifying unnecessary rules (e.g., a printer talking to a medical device without actual use). Application Perspective Tie firewall rules to actual applications to understand the business function they support, leading to more targeted security policies. Granularity & Visibility Higher level of visibility and granularity in security policies, focusing on specific application flows rather than broad network access. Security Posture by Application View and assess security risks and vulnerabilities at the application level, improving overall security posture. One of my favorite aspects of the AlgoSec platform is that we not only help optimize your security policies, but we also start to look at security from an application perspective. Traditionally, firewall change requests come in and it’s just asking for very specific things, “Source A to Destination B using Protocol C.” But using AlgoSec we tie those rules to actual applications to see what business function this is supporting. By knowing the specific flows and tying them to a specific application this allows us to keep a closer eye on the actual security policies we need to create. This helps with that zero trust journey because having that higher level of visibility and granularity helps to keep the rules more specific. Instead of a change request coming in that is allowing wide open access between two subnets the application can be designed for only the access that is required. It also allows for an overall better view of the security posture. Zero trust, like many other ideas and frameworks in our industry might seem farfetched at first. We ask ourselves, how do we get there or how do we implement without it becoming so cumbersome that we give up on it. I think it’s normal to be a bit pessimistic about achieving the goal and it’s completely fine to look at some projects as moving targets that we might not have a hard deadline on. There usually isn’t a magic bullet that accomplish our goals, especially something like achieving zero trust. Multiple initiatives and projects are necessary. With AlgoSec’s expertise in application connectivity and policy management, we can be a key partner in that journey. Schedule a demo Related Articles Q1 at AlgoSec: What innovations and milestones defined our start to 2026? AlgoSec Reviews Mar 19, 2023 · 2 min read 2025 in review: What innovations and milestones defined AlgoSec’s transformative year in 2025? AlgoSec Reviews Mar 19, 2023 · 2 min read Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read Speak to one of our experts Speak to one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Schedule a call

Horizon ACE gives you complete visibility into your cloud applications, simplifies network security policy management, and automates compliance across your multi-cloud infrastructure. Horizon ACE Information Center Getting started Why Horizon ACE Horizon ACE access Horizon ACE videos Let’s connect Getting started Great news! As a valued AlgoSec Cloud customer, you now have extended access to AlgoSec Cloud Enterprise (Horizon ACE). We're so excited for you to experience the next level of cloud security, designed to give you unparalleled visibility and control. You're already doing great things with AlgoSec for network security. Now, Horizon ACE is here to help you do even more, providing deeper insights and comprehensive management across your entire multi-cloud environment. Important: To ensure you can see and use all the amazing features the app analyzer has to offer, you'll need to open the required permissions in your cloud environment. This is a crucial step that ensures the program can access all the data required to give you a complete picture. You can find detailed instructions and a list of the permissions needed for your specific cloud provider here: AWS: Horizon ACE Access AWS Azure: Horizon ACE Access Azure GCP: Horizon ACE Access GCP Why Horizon ACE? Horizon ACE gives you complete visibility into your cloud applications, simplifies network security policy management, and automates compliance across your multi-cloud infrastructure. Think of it as your new co-pilot for cloud security, helping you: One unified view: Seamlessly combine cloud posture management with your existing AlgoSec network security. Get a truly holistic perspective of your entire environment. With Horizon ACE, you can bridge the gap between your cloud and on-premise infrastructure to achieve unified hybrid security. With Horizon ACE you can: Gain a single, holistic view across both environments. Enforce consistent policies. Simplify change management. To get a clearer picture of how Horizon ACE can transform your security, download our one-pager. Deeper, actionable insights: Dive into advanced features that give you immediate, practical intelligence about your cloud security health. You'll know exactly what to do next. Amplified protection: Proactively discover and tackle risks across your entire cloud environment, strengthening the already solid foundation you have with AlgoSec. Horizon ACE access We're all about empowering you with the best cloud security tools available. This extended access to Horizon ACE is our way of providing you with: See everything (beyond the network!): Get a full, real-time inventory of all your cloud applications and infrastructure. No more blind spots – you'll see everything, far beyond traditional network boundaries. Spot risks before they're problems: Proactively find vulnerabilities and misconfigurations across your entire cloud setup. Horizon ACE helps you identify potential issues before they can impact your operations, building on your current security efforts. Keep compliance simple: Maintain strong and continuous compliance with industry standards and your internal policies. Horizon ACE brings you deeper, cloud-native insights to make compliance easier than ever. Streamline your day: Automate security workflows and policy enforcement. This means more time for you and consistent security across all your expanding cloud resources. Ready to explore your new Horizon ACE access? You've already been granted access! Look for a welcome email with simple instructions to confirm and get started. We'll be there to guide you through the initial steps, helping you quickly get comfortable with the Horizon ACE dashboard and all its powerful features. We've designed this to be a smooth, insightful, and incredibly valuable experience for you! Join the growing community of leading organizations who are transforming their cloud security with the unified power of AlgoSec. We're here to help you master your cloud security journey! Horizon ACE videos Horizon ACE Access Horizon ACE Overview Application Discovery Horizon ACE Dashboard Horizon ACEConfiguration & Compliance Container Security Let’s connect Have a question, need more information, or just want to say hello? We'd love to hear from you Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Continue

Attacks on water treatment plants show just how vulnerable critical infrastructure is to hacking – here’s how these vital services should... Cyber Attacks & Incident Response Stop hackers from poisoning the well: Protecting critical infrastructure against cyber-attacks 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 3/31/21 Published Attacks on water treatment plants show just how vulnerable critical infrastructure is to hacking – here’s how these vital services should be protected. Criminals plotting to poison a city’s water supply is a recurring theme in TV and movie thrillers, such as 2005’s Batman Begins. But as we’ve seen recently, it’s more than just a plot device: it’s a cyber-threat which is all too real. During the past 12 months, there have been two high-profile attacks on water treatment systems that serve local populations, both with the aim of causing harm to citizens. The first was in April 2020, targeting a plant in Israel . Intelligence sources said that hackers gained access to the plant and tried altering the chlorine levels in drinking water – but luckily the attack was detected and stopped. And in early February, a hacker gained access to the water system of Oldsmar, Florida and tried to pump in a dangerous amount of sodium hydroxide. The hacker succeeded in starting to add the chemical, but luckily a worker spotted what was happening and reversed the action. But what could have happened if those timely interventions had not been made? These incidents are a clear reminder that critical national infrastructure is vulnerable to attacks – and that those attacks will keep on happening, with the potential to impact the lives of millions of people.  And of course, the Covid-19 pandemic has further highlighted how essential critical infrastructure is to our daily lives. So how can better security be built into critical infrastructure systems, to stop attackers being able to breach them and disrupt day-to-day operations?  It’s a huge challenge, because of the variety and complexity of the networks and systems in use across different industry sectors worldwide. Different systems but common security problems For example, in water and power utilities, there are large numbers of cyber-physical systems consisting of industrial equipment such as turbines, pumps and switches, which in turn are managed by a range of different industrial control systems (ICS). These were not designed with security in mind:  they are simply machines with computerized controllers that enact the instructions they receive from operators.  The communications between the operator and the controllers are done via IP-based networks – which, without proper network defenses, means they can be accessed over the Internet – which is the vector that hackers exploit. As such, irrespective of the differences between ICS controls, the security challenges for all critical infrastructure organizations are similar:  hackers must be stopped from being able to infiltrate networks; if they do succeed in breaching the organization’s defenses, they must be prevented from being able to move laterally across networks and gain access to critical systems. This means  network segmentation  is one of the core strategies for securing critical infrastructure, to keep operational systems separate from other networks in the organization and from the public Internet and surround them with security gateways so that they cannot be accessed by unauthorized people. In the attack examples we mentioned earlier, properly implemented segmentation would prevent a hacker from being able to access the PC which controls the water plant’s pumps and valves. With damaging ransomware attacks increasing over the past year, which also exploit internal network connections and pathways to spread rapidly and cause maximum disruption,  organizations should also employ security best-practices to block or limit the impact of ransomware attacks  on their critical systems. These best practices have not changed significantly since 2017’s massive WannaCry and NotPetya attacks, so organizations would be wise to check and ensure they are employing them on their own networks. Protecting critical infrastructure against cyber-attacks is a complex challenge because of the sheer diversity of systems in each sector.  However, the established security measures we’ve outlined here are extremely effective in protecting these vital systems – and in turn, protecting all of us. Schedule a demo Related Articles Q1 at AlgoSec: What innovations and milestones defined our start to 2026? AlgoSec Reviews Mar 19, 2023 · 2 min read 2025 in review: What innovations and milestones defined AlgoSec’s transformative year in 2025? AlgoSec Reviews Mar 19, 2023 · 2 min read Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read Speak to one of our experts Speak to one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Schedule a call

Linux containers aren’t new. In fact, this technology was invented 20 years ago. In 2013, Docker entered the scene and revolutionized... Cloud Security Operation “Red Kangaroo”: Industry’s First Dynamic Analysis of 4M Public Docker Container Images 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/1/20 Published Linux containers aren’t new. In fact, this technology was invented 20 years ago. In 2013, Docker entered the scene and revolutionized Linux containers by offering an easy-to-use command line interface (CLI), an engine, and a registry server. Combined, these technologies have concealed all the complexity of building and running containers, by offering one common industry standard . As a result, Docker’s popularity has sky-rocketed, rivalling Virtual Machines, and transforming the industry. In order to locate and share Docker container images, Docker is offering a service called Docker Hub . Its main feature, repositories , allows the development community to push (upload) and pull (download) container images. With Docker Hub, anyone in the world can download and execute any public image, as if it was a standalone application. Today, Docker Hub accounts over 4 million public Docker container images . With 8 billion pulls (downloads) in January 2020 and growing , its annualized image pulls should top 100 billion this year. For comparison , Google Play has 2.7M Android apps in its store, with a download rate of 84 billion downloads a year. How many container images currently hosted at Docker Hub are malicious or potentially harmful? What sort of damage can they inflict? What if a Docker container image downloaded and executed malware at runtime? Is there a reliable way to tell that? What if a compromised Docker container image was downloaded by an unsuspecting customer and used as a parent image to build and then deploy a new container image into production, practically publishing an application with a backdoor built into it? Is there any way to stop that from happening? At Prevasio, we asked ourselves these questions multiple times. What we decided to do has never been done before. The Challenge At Prevasio, we have built a dynamic analysis sandbox that uses the same principle as a conventional sandbox that ‘detonates’ malware in a safe environment. The only difference is that instead of ‘detonating’ an executable file, such as a Windows PE file or a Linux ELF binary, Prevasio Analyzer first pulls (downloads) an image from any container registry, and then ‘detonates’ it in its own virtual environment, outside the organization/customer infrastructure. Using our solution, we then dynamically analyzed all 4 million container images hosted at Docker Hub. In order to handle such a massive volume of images, Prevasio Analyzer was executed non-stop for a period of one month on 800 machines running in parallel. The result of our dynamic scan reveals that: 51 percent of all containers had “critical” vulnerabilities, while 13 percent were classified as “high” and four percent as “moderate” vulnerabilities. Six thousand containers were riddled with cryptominers, hacking tools/pen testing frameworks, and backdoor trojans. While many cryptominers and hacking tools may not be malicious per se, they present a potentially unwanted issue to an enterprise. More than 400 container images (with nearly 600,000 pulls) of weaponized Windows malware crossing over into the world of Linux. This crossover is directly due to the proliferation of cross-platform code (e.g. GoLang, .NET Core and PowerShell Core). Our analysis of malicious containers also shows that quite a few images contain a dynamic payload. That is, an image in its original form does not have a malicious binary. However, at runtime, it might be scripted to download a source of a coinminer, to then compile and execute it. A dynamic analysis sandbox, such as Prevasio Analyzer, is the only solution that provides a behavioral analysis of Docker containers. It is built to reveal malicious intentions of Docker containers by executing them in its own virtual environment, revealing a full scope of their behavior. The whitepaper with our findings is available here . Schedule a demo Related Articles Q1 at AlgoSec: What innovations and milestones defined our start to 2026? AlgoSec Reviews Mar 19, 2023 · 2 min read 2025 in review: What innovations and milestones defined AlgoSec’s transformative year in 2025? AlgoSec Reviews Mar 19, 2023 · 2 min read Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read Speak to one of our experts Speak to one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Schedule a call

Security Policy Management with Professor Wool Best Practices: Incorporating Security into DevOps Best Practices for Incorporating Security into DevOps, is a whiteboard-style series of lessons that examine the challenges of and provide technical tips for how to incorporate security throughout the DevOps process. Lesson 1 In this lesson, Professor Wool examines the need for and the process of adjusting application connectivity throughout each stage of the DevOps lifecycle. Best Practices for Incorporating Security Automation into the DevOps Lifecycle Watch Lesson 2 In theory adding capacity should be fairly straightforward, with minimal need for any intervention by the organization’s security team. But in practice it’s a little more complex. In this video Professor Wool provides some tips and best practices to help you add capacity without having to change your security policies, complete a security review or worse still, cause an outage or gap in the security perimeter. Tips for Adding Capacity Without Changing Your Security Policies Watch Lesson 3 In a typical DevOps scenario development team adds new functionality to an existing business application and then rolls it out into production. However, while the new functionality worked as planned in both the test and pre-production environments, the application then fails when moved into the live production environment. In this video, Professor Wool will discuss the reasons why this process went wrong, and how you can fix it. How to Integrate Security into the Test Environment Watch Lesson 4 In previous lessons Professor Wool discussed how building security into DevOps processes at an early stage helps organizations maximize the speed and agility of application development, while minimizing the risks of problems and outages when the applications go live. In this whiteboard video Professor Wool looks at how security automation helps to speed up the practice of Continuous Integration (CI) - a core element of DevOps. How to Integrate Security into the CI Process Watch Have a Question for Professor Wool? Ask him now Choose a better way to manage your network Choose a better way to manage your network Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Continue

In our previous post we have provided some details about a new fork of Kinsing malware, a Linux malware that propagates across... Cloud Security Router Honeypot for an IRC Bot 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. glibc_2 Tags Share this article 9/13/20 Published In our previous post we have provided some details about a new fork of Kinsing malware, a Linux malware that propagates across misconfigured Docker platforms and compromises them with a coinminer. Several days ago, the attackers behind this malware have uploaded a new ELF executable b_armv7l into the compromised server dockerupdate[.]anondns[.]net . The executable b_armv7l is based on a known source of Tsunami (also known as Kaiten), and is built using uClibc toolchain: $ file b_armv7l b_armv7l: ELF 32-bit LSB executable, ARM, EABI4 version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, with debug_info, not stripped Unlike glibc , the C library normally used with Linux distributions, uClibc is smaller and is designed for embedded Linux systems, such as IoT. Therefore, the malicious b_armv7l was built with a clear intention to install it on such devices as routers, firewalls, gateways, network cameras, NAS servers, etc. Some of the binary’s strings are encrypted. With the help of the HexRays decompiler , one could clearly see how they are decrypted: memcpy ( &key, "xm@_;w,B-Z*j?nvE|sq1o$3\"7zKC4ihgfe6cba~&5Dk2d!8+9Uy:" , 0x40u ) ; memcpy ( &alphabet, "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ. " , 0x40u ) ; for ( i = 0; i < = 64; ++i ){ if ( encoded [ j ] == key [ i ]) { if ( psw_or_srv ) decodedpsw [ k ] = alphabet [ i ] ; else decodedsrv [ k ] = alphabet [ i ] ; ++k; }} The string decryption routine is trivial — it simply replaces each encrypted string’s character found in the array key with a character at the same position, located in the array alphabet. Using this trick, the critical strings can be decrypted as: Variable Name Encoded String Decoded String decodedpsw $7|3vfaa~8 logmeINNOW decodedsrv $7?*$s7

Cloud threats increased by 95 percent in 2022 alone! At a time when many organizations are moving their resources to the cloud and... Cloud Security Cloud Security Architecture: Methods, Frameworks, & Best Practices 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 8/8/23 Published Cloud threats increased by 95 percent in 2022 alone! At a time when many organizations are moving their resources to the cloud and security threats are at an all-time high, focusing on your cloud security architecture has never been more critical. While cloud adoption has revolutionized businesses, it has also brought complex challenges. For example, cloud environments can be susceptible to numerous security threats. Besides, there are compliance regulations that you must address. This is why it’s essential to implement the right methods, frameworks, and best practices in cloud environments. Doing so can protect your organization’s sensitive cloud resources, help you meet compliance regulations, and maintain customer trust. Understanding Cloud Security Architecture Cloud security architecture is the umbrella term that covers all the hardware, software, and technologies used to protect your cloud environment. It encompasses the configurations and secure activities that protect your data, workloads, applications, and infrastructure within the cloud. This includes identity and access management (IAM), application and data protection, compliance monitoring, secure DevOps, governance, and physical infrastructure security. A well-defined security architecture also enables manageable decompositions of cloud deployments, including mixed SaaS, PaaS, and IaaS deployments. This helps you highlight specific security needs in each cloud area. Additionally, it facilitates integration between clouds, zones, and interfaces, ensuring comprehensive coverage of all deployment aspects. Cloud security architects generally use a layered approach when designing cloud security. Not only does this improve security, but it also allows companies to align business needs with technical security practices. As such, a different set of cloud stakeholders, including business teams and technical staff, can derive more value. The Fundamentals of Cloud Security Architecture Every cloud computing architecture has three core fundamental capabilities; confidentiality, integrity, and availability. This is known as the CIA triad. Understanding each capability will guide your efforts to build, design, and implement safer cloud environments. 1. Confidentiality This is the ability to keep information hidden and inaccessible to unauthorized entities, such as attackers, malware, and people in your organization, without the appropriate access level. Privacy and trust are also part of confidentiality. When your organization promises customers to handle their data with utmost secrecy, you’re assuring them of confidentiality. 2. Integrity Integrity means that the services, systems, and applications work and behave exactly how you expect. That is, their output is consistent, accurate, and trustworthy. If these systems and applications are compromised and produce unexpected or misleading results, your organization may suffer irreparable damage. 3. Availability As the name implies, availability assures your cloud resources are consistently accessible and operational when needed. So, suppose an authorized user (whether customers or employees) needs data and applications in the cloud, such as your products or services. In that case, they can access it without interruption or significant downtime. Cybercriminals sometimes use denial-of-service (DoS) attacks to prevent the availability of cloud resources. When this happens, your systems become unavailable to you or your customers, which isn’t ideal. So, how do you stop that from happening and ensure your cloud security architecture provides these core capabilities? Approaches to Cloud Security Architecture There are multiple security architecture approaches, including frameworks and methodologies, to support design and implementation steps. Cloud Security Frameworks and Methodologies A cloud security framework outlines a set of guidelines and controls your organizations can use when securing data, applications, and infrastructures within the cloud computing environment. Frameworks provide a structured approach to detecting risks and implementing appropriate security protocols to prevent them. Without a consistent cloud security framework, your organization exposes itself to more vulnerabilities. You may lack the comprehensive visibility to ensure your data and applications are adequately secure from unauthorized access, data exposure, malware, and other security threats. Plus, you may have limited incident response capabilities, inconsistent security practices, and increased operational risks. A cloud security framework also helps you stay compliant with regulatory requirements. Lastly, failing to have appropriate security frameworks can erode customer trust and confidence in your ability to protect their privacy. This is why you must implement a recognized framework to significantly reduce potential risks associated with cloud security and ensure the CIA of data and systems. There are numerous security frameworks. Some are for governance (e.g., COBIT and COSO), architecture (e.g., SABSA), and the NIST cybersecurity framework. While these generally apply broadly to technology, they may also apply to cloud environments. Other cloud-specific frameworks include the ISO/IEC 27017:2015, Cloud Control Matrix (CCM), Cloud Security Alliance, and the FedRAMP. 1. NIST Cybersecurity Framework (NIST CSF) The National Institute of Standards and Technology’s Cybersecurity Framework (NIST CSF) outlines a set of guidelines for securing security systems. It has five core capabilities: Identify, Protect, Detect, Respond, and Recover. Identify – What processes, assets, and systems need protection? Protect – Develop and implement the right safeguards to ensure critical infrastructure services delivery. Detect – Implement the appropriate mechanisms to enable the timely discovery of cybersecurity incidents. Respond – Develop techniques to contain the impact of potential cybersecurity incidents. Recover – Implement appropriate measures to restore business capabilities and services affected by cybersecurity events. While the NIST CSF is a general framework for the security of your organization’s systems, these five pillars can help you assess and manage cloud-related security risks. 2. ISO/IEC 27017:2015 ISO 27017 is a cloud security framework that defines guidelines on information security issues specific to the cloud. The framework’s security controls add to the ISO/IEC 27002 and ISO/IEC 27001 standards’ recommendations. The framework also offers specific security measures and implementation advice for cloud service providers and applications. 3. Sherwood Applied Business Security Architecture (SABSA) First developed by John Sherwood, SABSA is an Enterprise Security Architecture Framework that provides guidelines for developing business-driven, risk, and opportunity-focused security architectures to support business objectives. The SABSA framework aims to prioritize your business needs, meaning security services are designed and developed to be an integral part of your business and IT infrastructure. Here are some core principles of the Gartner-recommended SABSA framework for enterprises: It is business-driven. SABSA ensures security is integrated into your entire business strategy. This means there’s a strong emphasis on understanding your organization’s business objectives. So, any security measure is aligned with those objectives. SABSA is a risk-based approach. It considers security vulnerabilities, threats, and their potential impacts to prioritize security operations and investments. This helps your organization allocate resources effectively to address the most critical risks first. It promotes a layered security architecture. Earlier, we mentioned how a layered approach can help you align business and technical needs. So, it’s expected that this is a core principle of SABSA. This allows you to deploy multiple security controls across different layers, such as physical security, network security, application security, and data security. Each layer focuses on a specific security aspect and provides special controls and measures. Transparency: SABSA provides two-way traceability; that is, a clear two-way relationship exists between aligning security requirements and business goals. This provides a clear overview of where expenditure is made ad the value that is returned. Modular approach: SABSA offers agility for ease of implementation and management. This can make your business flexible when meeting changing market or economic conditions. 4. MITRE ATT&CK The MITRE ATT&CK framework is a repository of techniques and tactics that threat hunters, defenders, red teams, and security architects can use to classify, identify, and assess attacks. Instead of focusing on security controls and mechanisms to mitigate threats, this framework targets the techniques that hackers and other threat actors use in the cloud. So, using this framework can be excellent if you want to understand how potential attack vectors operate. It can help you become proactive and strengthen your cloud security posture through improved detection and incident response. 5. Cloud Security Alliance Cloud Controls Matrix (CSA CCM) The CSA CCM is a cybersecurity control framework specifically for cloud computing. It contains 197 control objectives structured in 17 domains that cover every critical aspect of cloud technology. Cloud customers and cloud service providers (CSPs) can use this tool to assess cloud implementation systematically. It also guides customers on the appropriate security controls for implementation by which actor in the cloud supply chain. 6. Cloud Security Alliance Security Trust Assurance and Risk (CSA STAR) The CSA STAR framework is for CSPs. It combines the principles of transparency, thorough auditing, and harmonization of standards. What CSA STAR does is to help you, as a cloud customer, assess a cloud service provider’s reliability and security posture. There are two ways this can happen: CSA STAR Certification: This is a rigorous third-party assessment of the CSP’s security controls, posture, and practices. The CSP undergoes a thorough audit based on the CSA’s Cloud Control Matrix (CCM), which is a set of cloud security controls aligned with industry standards. CSA STAR Self-Assessment: The CSA also has a Consensus Assessment Initiative Questionnaire (CAIQ). CSPs can use this to test and report on their security controls and practices. Since it’s a self-assessment procedure, it allows CSPs to be transparent, enabling customers like you to understand a CSP’s security capabilities before adopting their services. Challenges and Considerations in Cloud Security Architecture Before any cloud deployment, it’s important to understand the threats you may face, such as privilege-based attacks and malware, and be prepared for them. Since there are many common threats, we’ll quickly run through the most high-profile ones with the most devastating impacts. It’s important to remember some threats may also be specific to the type of cloud service model. 1. Insider risks This includes the employees in your organization who have access to data, applications, and systems, as well as CSP administrators. Whenever you subscribe to a CSP’s services, you entrust your workloads to the staff who maintain the CSP architecture. 2. DoS attacks Direct denial-of-service (DDoS) attacks are critical issues in cloud environments. Although security perimeters can deflect temporary DDoS attacks to filter out repeated requests, permanent DoS attacks are more damaging to your firmware and render the server unbootable. If this happens, you may need to physically reload the firmware and rebuild the system from the ground up, resulting in business downtime for weeks or longer. 3. Data availability You also want to consider how much of your data is accessible to the government. Security professionals are focusing on laws and examples that demonstrate when and how government authorities can access data in the cloud, whether through legal processes or court rulings. 4. Cloud-connected Edge Systems The concept of “cloud edge” encompasses both edge systems directly connected to the cloud and server architecture that is not directly controlled by the cloud service provider (CSP). To extend their services to smaller or remote locations, global CSPs often rely on partners as they cannot have facilities worldwide. Consequently, CSPs may face limitations in fully regulating hardware monitoring, ensuring physical box integrity, and implementing attack defenses like blocking USB port access. 5. Hardware Limitations Having the most comprehensive cloud security architecture still won’t help you create stronger passwords. While your cloud security architects focus on the firmware, hardware, and software, it’s down to the everyday users to follow best practices for staying safe. Best Practices in Cloud Security Architecture The best practices in Cloud Security Architecture are highlighted below: 1. Understand the shared responsibility model Cloud security is implemented with a shared responsibility model. Although, as the cloud customer, you may have most of the obligation, the cloud provider also shares some of the responsibility. Most vendors, such as Amazon Web Services (AWS) and Microsoft Azure, have documentation that clearly outlines your specific responsibilities depending on the deployment type. It’s important to clearly understand your shared responsibility model and review cloud vendor policies. This will prevent miscommunications and security incidents due to oversight. 2. Secure network design and segmentation This is one of the principles of cloud security architecture – and by extension, a best practice. Secure network design and segmentation involve dividing the network into isolated segments to avoid lateral movements during a breach. Implementing network segmentation allows your organization to contain potential risks and attacks within a specific segment. This can minimize the effects of an incident on your entire network and protect critical assets within the cloud infrastructure. 3. Deploy an Identity and access management (IAM) solution Unauthorized access is one of the biggest problems facing cloud security. Although hackers now use sophisticated tools to gain access to sensitive data, implementing a robust identity and access management (IAM) system can help prevent many threats. Consider access policies like role-based access control (RBAC) permissions, multi-factor authentication (MFA), and continuous threat monitoring. 4. Consider a CASB or Cloud Security Solution (e.g., Cloud-Native Application Protection (CNAPP) and Cloud Workload Protection Platforms (CWPP) Cloud Access Security Brokers (CASBs) provide specialized tools to enforce cloud security policies. Implementing a CASB solution is particularly recommended if you have a multi-cloud environment involving different vendors. Since a CASB acts as an intermediary between your organization’s on-premise infrastructure and CSPs, it allows your business to extend security policies and controls to the cloud. CASBs can enhance your data protection through features like data loss prevention, tokenization, and encryption. Plus, they help you discover and manage shadow IT through visibility into unauthorized cloud services and applications. Besides CASB solutions, you should also consider other solutions for securing your cloud environments. This includes cloud-native application protection (CNAPP) and cloud workload protection platforms (CWPP). For example, a CNAPP like Prevasio can improve your cloud security architecture with tailored solutions and automated security management. 5. Conduct Audits, Penetration Testing, and Vulnerability Testing Whether or not you outsource security, performing regular penetration tests and vulnerability is necessary. This helps you assess the effectiveness of your cloud security measures and identify potential weaknesses before hackers exploit them. You should also perform security audits that evaluate cloud security vendors’ capabilities and ensure appropriate access controls are in place. This can be achieved by using the guidelines of some frameworks we mentioned earlier, such as the CSA STAR. 6. Train Your Staff Rather than hiring new hires, training your current staff may be beneficial. Your employees have been at your company for a while and are already familiar with the organization’s culture, values, and processes. This could give them an advantage over new hires. As most existing IT skills can be reused, upskilling employees is more efficient and may help you meet the immediate need for a cloud IT workforce. Train your staff on recognizing simple and complex cybersecurity threats, such as creating strong passwords, identifying social engineering attacks, and advanced topics like risk management. 7. Mitigate Cloud Misconfigurations A misconfigured bucket could give access to anyone on the internet. To minimize cloud misconfigurations and reduce security risks, managing permissions in cloud services carefully is crucial. Misconfigurations, such as granting excessive access permissions to external users, can enable unauthorized access and potential data breaches. Attackers who compromise credentials can escalate their privileges, leading to further data theft and broader attacks within the cloud infrastructure. Therefore, it is recommended that IT, storage, or security teams, with assistance from development teams, personally configure each cloud bucket, ensuring proper access controls and avoiding default permissions. 8. Ensure compliance with regulatory requirements Most organizations today need to comply with strict regulatory requirements. This is especially important if you collect personally identifiable information (PII) or if your business is located in certain regions. Before you adopt a new cloud computing service, assess their compliance requirements and ensure they can fulfill data security needs. Failure to meet compliance requirements can lead to huge penalties. Other best practices for your cloud security include continuous monitoring and threat intelligence, data encryption at rest and in transit, and implementing intrusion detection and intrusion prevention systems. Conclusion When establishing a robust cloud security architecture, aligning business objectives and technical needs is important. Your organization must understand the shared responsibility model, risks, the appropriate implementation framework, and best practices. However, designing and developing cloud computing architectures can be complicated. Prevasio can secure your multi-cloud environment in minutes. Want to improve your cloud security configuration management? Prevasio’s agentless CNAPP can provide complete visibility over cloud resources, ensure compliance, and provide advanced risk monitoring and threat intelligence. Speak to us now. Schedule a demo Related Articles Q1 at AlgoSec: What innovations and milestones defined our start to 2026? AlgoSec Reviews Mar 19, 2023 · 2 min read 2025 in review: What innovations and milestones defined AlgoSec’s transformative year in 2025? AlgoSec Reviews Mar 19, 2023 · 2 min read Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read Speak to one of our experts Speak to one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Schedule a call

Enterprises are embracing cloud platforms to drive innovation, enhance operational efficiency, and gain a competitive edge. Cloud... Hybrid Cloud Security Management Securing Cloud-Native Environments: Containerized Applications, Serverless Architectures, and Microservices Malcom Sargla 2 min read Malcom Sargla 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/6/23 Published Enterprises are embracing cloud platforms to drive innovation, enhance operational efficiency, and gain a competitive edge. Cloud services provided by industry giants like Google Cloud Platform (GCP), Azure, AWS, IBM, and Oracle offer scalability, flexibility, and cost-effectiveness that make them an attractive choice for businesses. One of the significant trends in cloud-native application development is the adoption of containerized applications, serverless architectures, and microservices. While these innovations bring numerous benefits, they also introduce unique security risks and vulnerabilities that organizations must address to ensure the safety of their cloud-native environments. The Evolution of Cloud-Native Applications Traditionally, organizations relied on on-premises data centers and a set of established security measures to protect their critical applications and data. However, the shift to cloud-native applications necessitates a reevaluation of security practices and a deeper understanding of the challenges involved. Containers: A New Paradigm Containers have emerged as a game-changer in the world of cloud-native development. They offer a way to package applications and their dependencies, ensuring consistency and portability across different environments. Developers appreciate containers for their ease of use and rapid deployment capabilities, but this transition comes with security implications that must not be overlooked. One of the primary concerns with containers is the need for continuous scanning and vulnerability assessment. Developers may inadvertently include libraries with known vulnerabilities, putting the entire application at risk. To address this, organizations should leverage container scanning tools that assess images for vulnerabilities before they enter production. Tools like Prevasio’s patented network sandbox provide real-time scanning for malware and known Common Vulnerabilities and Exposures (CVEs), ensuring that container images are free from threats. Continuous Container Monitoring The dynamic nature of containerized applications requires continuous monitoring to ensure their health and security. In multi-cloud environments, it’s crucial to have a unified monitoring solution that covers all services consistently. Blind spots must be eliminated to gain full control over the cloud deployment. Tools like Prevasio offer comprehensive scanning of asset classes in popular cloud providers such as Amazon AWS, Microsoft Azure, and Google GCP. This includes Lambda functions, S3 buckets, Azure VMs, and more. Continuous monitoring helps organizations detect anomalies and potential security breaches early, allowing for swift remediation. Intelligent and Automated Policy Management As organizations scale their cloud-native environments and embrace the agility that developers demand, policy management becomes a critical aspect of security. It’s not enough to have static policies; they must be intelligent and adaptable to evolving threats and requirements. Intelligent policy management solutions enable organizations to enforce corporate security policies both in the cloud and on-premises. These solutions have the capability to identify and guard against risks introduced through development processes or traditional change management procedures. When a developer’s request deviates from corporate security practices, an intelligent policy management system can automatically trigger actions, such as notifying network analysts or initiating policy work orders. Moreover, these solutions facilitate a “shift-left” approach, where security considerations are integrated into the earliest stages of development. This proactive approach ensures that security is not an afterthought but an integral part of the development lifecycle. Mitigating Risks in Cloud-Native Environments Securing containerized applications, serverless architectures, and microservices in cloud-native environments requires a holistic strategy. Here are some key steps that organizations can take to mitigate risks effectively: 1. Start with a Comprehensive Security Assessment Before diving into cloud-native development, conduct a thorough assessment of your organization’s security posture. Identify potential vulnerabilities and compliance requirements specific to your industry. Understanding your security needs will help you tailor your cloud-native security strategy effectively. 2. Implement Continuous Security Scanning Integrate container scanning tools into your development pipeline to identify vulnerabilities early in the process. Automate scanning to ensure that every container image is thoroughly examined before deployment. Regularly update scanning tools and libraries to stay protected against emerging threats. 3. Embrace Continuous Monitoring Utilize continuous monitoring solutions that cover all aspects of your multi-cloud deployment. This includes not only containers but also serverless functions, storage services, and virtual machines. A unified monitoring approach reduces blind spots and provides real-time visibility into potential security breaches. 4. Invest in Intelligent Policy Management Choose an intelligent policy management solution that aligns with your organization’s security and compliance requirements. Ensure that it offers automation capabilities to enforce policies seamlessly across cloud providers. Regularly review and update policies to adapt to changing security landscapes. 5. Foster a Culture of Security Security is not solely the responsibility of the IT department. Promote a culture of security awareness across your organization. Train developers, operations teams, and other stakeholders on best practices for cloud-native security. Encourage collaboration between security and development teams to address security concerns early in the development lifecycle. Conclusion The adoption of containerized applications, serverless architectures, and microservices in cloud-native environments offers unprecedented flexibility and scalability to enterprises. However, these advancements also introduce new security challenges that organizations must address diligently. By implementing a comprehensive security strategy that includes continuous scanning, monitoring, and intelligent policy management, businesses can harness the power of the cloud while safeguarding their applications and data. As the cloud-native landscape continues to evolve, staying proactive and adaptive in security practices will be crucial to maintaining a secure and resilient cloud environment. Schedule a demo Related Articles Q1 at AlgoSec: What innovations and milestones defined our start to 2026? AlgoSec Reviews Mar 19, 2023 · 2 min read 2025 in review: What innovations and milestones defined AlgoSec’s transformative year in 2025? AlgoSec Reviews Mar 19, 2023 · 2 min read Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read Speak to one of our experts Speak to one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Schedule a call

As with all cloud vendors, AWS users share responsibility for securing their infrastructure against risk. Amazon provides the tools you... AWS Security group architecture for AWS: How to overcome security group limits 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/9/23 Published As with all cloud vendors, AWS users share responsibility for securing their infrastructure against risk. Amazon provides the tools you need to filter traffic, but configuring those tools is up to you. Firewalls are one of the tools you’ll use to filter traffic and secure Virtual Private Cloud (VPC) instances. Instead of using traditional firewalls, Amazon provides users with AWS security groups, which are flexible, stateful firewalls capable of filtering inbound and outbound traffic. However, there are limits to what you can do with AWS security groups. First, they only allow traffic – you can’t configure them to deny traffic. Second, the maximum number of rules you can set for a single group is 60. This isn’t a big issue for an Amazon EC2 instance designed to address inbound traffic. You’ll either want your AWS EC2 to accept ingress from the entire internet or you’ll want to configure access for a few internal IP addresses. But for outbound traffic, 60 rules simply isn’t enough. You’ll use a dozen of them just allowing access to GitHub’s API . Add in a few third-party partners and you’re already well past the limit. Amazon VPC resource limits explained Amazon sets clear limits on the AWS services and resources it makes available to users. In some cases, you can increase these limits by contacting AWS support. These limits are generally assessed on a per-Region basis. Here are some of the limits Amazon places on AWS users: Security group limits 2500 VPC security groups per Region 60 IPv4 rules per security group 60 IPv6 rules per security group 5 security groups per network interface VPC and subnet limits 5 VPCs per Region 200 Subnets per VPC 5 IPv4 CIDR blocks per VPC 5 IPv6 CIDR blocks per VPC Limits to elastic IP addresses and gateways 5 Elastic IP addresses per Region 2 Elastic IP Addresses per public NAT gateway 5 Egress-only internet gateways per Region 5 NAT gateways per Availability Zone One carrier gateway per VPC Prefix list limits 100 prefix lists per Region 1000 versions per prefix list 5000 prefix list references per resource type Network ACL limits 200 Network ACLs per VPC 20 Rules per Network ACL How to manage AWS cloud security group limits effectively Traditional firewalls may have thousands of security rules, including a complex combination of inbound rules and egress filters. Crucially, they can also enforce outbound rules that include denying traffic – something Amazon does not allow regular security groups to do. While AWS offers powerful tools for securing cloud workflows, Amazon VPC users must find ways to overcome these limitations. Fortunately, there are a few things you can do to achieve exactly that. Optimize your VPC security groups. Use Network Access Control Lists to secure assets at the subnet level. Use a domain name filtering system that reduces the number of IP addresses security group rules need to resolve. Optimize your Amazon virtual private cloud configuration Amazon VPC is a virtual network that contains many of the elements you’d expect from a traditional network. It has IP addresses, route tables, subnets, and internet gateways. Unlike a traditional network, you can easily configure many of your VPC environment through a command line interface (CLI). You can establish VPC peering connections, implement identity and access management (IAM) protocols, and configure elastic network interfaces without manually handling any hardware. But first, you need to set up and protect your VPC by setting up and configuring security groups. If you don’t specify a particular group, Amazon EC2 will use the default security group. If you haven’t added new security groups since creating your AWS account, you may only have that one default security group. The first step to optimizing security is expanding the number of security groups you have available. Here’s an example of the code you can use to create a new security group in the AWS console:aws ec2 create-security-group –group-name web-pci-sg –description “allow SSL traffic” –vpc-id vpc-555666777 This creates a new group named web-pci-sg and describes it as a group designed to allow SSL traffic on the network. Remember that security groups don’t support deny rules. Here is the code you would use to add a rule to that group: aws ec2 authorize-security-group-ingress \ –group-name web-pci-sg \ –protocol https \–port 443 \ –cidr This rule specifically allows SSL traffic using the HTTPS protocol to use port 443, which is the standard port for HTTPS traffic. You can use the last argument to specify the cidr block the rule will direct traffic through. This gives you the ability to manage traffic through specific subnets, which is important for the next step. This example focuses on just one type of rule in one context. To take full advantage of the security tools AWS makes available, you’ll want to create custom rules for endpoints, load balancers, nat gateways, and more. Although you’re limited to 60 rules per security group, creating many groups lets you assign hundreds of rules to any particular instance. Security architecture and network ACLs Network Access Control Lists provide AWS users with additional filtering capabilities. Network ACLs are similar to security groups in many ways, but come with a few key differences: Network ACLs can contain deny rules. You can write Network ACL rules to include explicit actions, like blocking particular IP addresses or routing VPN users in a specific way. Network ACLs are enforced at the subnet level. This means they apply to every instance in the subnet, in addition to whatever rules exist at the security group level. As mentioned above, each Network ACL can contain up to 20 rules. However, you can have up to 200 Network ACLs per VPC, which gives you a total of 4000 potential rules. Along with instance-specific security group rules, this offers much more flexibility for setting up robust AWS security architecture. Since Network ACLs can deny traffic, they are a useful tool for managing access to databases and other sensitive assets. For example, you may wish to exclude users who don’t have the appropriate permissions from your Amazon RDS instance. You may also want to filter SSH (Secure Shell) connections coming from unknown sources, or limit connections between different internal instance types. To do this effectively, you need to group these assets under the same subnet and make sure that the appropriate rules are enabled for all of them. You can also write asset-specific rules at the security group level, ensuring every asset has its own optimal configuration. The larger your AWS environment is, the more complex this process may become. Take care to avoid misconfigurations – it’s very easy to accidentally write security group rules and Network ACL rules that aren’t compatible, or that cause problems when you access the instance. To avoid this, try to condense your rules as much as possible. Avoid limits by filtering domain names directly Although you can create a large number of rules by creating additional security groups, you still may want to add more than 60 rules in a single group. There are many scenarios where this makes more sense than arbitrarily adding (and managing) new groups. For example, you might have a production instance that needs updates from several third-party partners. You also need to periodically change and update the technologies this instance relies on, so you’d like to keep its rules in a single security group. This reduces misconfiguration risk by keeping all the relevant rules in one place – not spread out across multiple groups. To overcome this limit, you need to reduce the number of IP addresses that the security group filters. You can do this by deploying a third-party solution that allows security rules to perform DNS resolution. This eliminates the need for AWS to resolve the domain name. Since AWS security groups can’t compute domain names on their own, you’ll need to deploy a third-party NAT gateway on your public VPC to filter outbound traffic in this way. Once you do this, you can write rules that filter outgoing connections based on their domain name. This effectively bypasses the 60 IP limit because you are not referring to specific IP addresses. At the same time, it simplifies management and makes rules much easier to read and understand. Instead of looking up and adding all of Github’s API IP addresses, you can write rules that reference the domain “Github.com”. If Github decides to change its IP infrastructure, your security rules will automatically reference the new addresses – you won’t have to go back and update them. The earlier you address AWS security group limits, the better There is an unlimited number of ways you can arrange your security groups and Network ACLs. Even in a small environment, the prospect may seem daunting. However, the flexibility Amazon provides to its cloud users is a valuable security feature. Those who go the process enjoy clear security performance benefits. If you start to planning for the architecture of your security and filtering policies early, you’ll be better equipped to scale those policies upwards as your organization grows. This will prevent security processes from becoming a growth bottleneck and maintain a high level of efficiency even as those policies become larger and more complex. See me explain this issue in person in my new whiteboard video: Schedule a demo Related Articles Q1 at AlgoSec: What innovations and milestones defined our start to 2026? AlgoSec Reviews Mar 19, 2023 · 2 min read 2025 in review: What innovations and milestones defined AlgoSec’s transformative year in 2025? AlgoSec Reviews Mar 19, 2023 · 2 min read Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read Speak to one of our experts Speak to one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Schedule a call

Prof. Avishai Wool, AlgoSec co-founder and CTO, breaks down the truths and myths about micro-segmentation and how organizations can... Micro-segmentation Why Microsegmentation is Still a Go-To Network Security Strategy 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 5/3/22 Published Prof. Avishai Wool, AlgoSec co-founder and CTO, breaks down the truths and myths about micro-segmentation and how organizations can better secure their network before their next cyberattack Network segmentation isn’t a new concept. For years it’s been the go-to recommendation for CISOs and other security leaders as a means of securing expansive networks and breaking large attack surface areas down into more manageable chunks. Just as we separate areas of a ship with secure doors to prevent flooding in the event of a hull breach, network segmentation allows us to seal off areas of our network to prevent breaches such as ransomware attacks, which tend to self-propagate and spread laterally from machine to machine. Network segmentation tends to work best in controlling north-south traffic in an organization. Its main purpose is to segregate and protect key company data and limit lateral movement by attackers across the network. Micro-segmentation takes this one step further and offers more granular control to help contain lateral east-west movement. It is a technique designed to create secure zones in networks, allowing companies to isolate workloads from one another and introduce tight controls over internal access to sensitive data. Put simply, if network segmentation makes up the floors, ceilings and protective outer hull, micro-segmentation makes up the steel doors and corridors that allow or restrict access to individual areas of the ship. Both methods can be used in combination to fortify cybersecurity posture and reduce risk vulnerability across the security network. How does micro-segmentation help defend against ransomware? The number of ransomware attacks on corporate networks seems to reach record levels with each passing year. Ransomware has become so appealing to cybercriminals that it’s given way to a whole Ransomware-as-a-Service (RaaS) sub-industry, plying would-be attackers with the tools to orchestrate their own attacks. When deploying micro-segmentation across your security network, you can contain ransomware at the onset of an attack. When a breach occurs and malware takes over a machine on a given network, the policy embedded in the micro-segmented network should block the malware’s ability to propagate to an adjacent micro-segment, which in turn can protect businesses from a system-wide shutdown and save them a great financial loss. What does Zero Trust have to do with micro-segmentation? Zero trust is a manifestation of the principle of “least privilege” security credentialing. It is a mindset that guides security teams to not assume that people, or machines, are to be trusted by default. From a network perspective, zero-trust implies that “internal” networks should not be assumed to be more trustworthy than “external” networks – quotation marks are intentional. Therefore, micro-segmentation is the way to achieve zero trust at the network level: by deploying restrictive filtering policy inside the internal network to control east-west traffic. Just as individuals in an organization should only be granted access to data on a need-to-know basis, traffic should only be allowed to travel from one area of the business to another only if the supporting applications require access to those areas. Can a business using a public cloud solution still use micro-segmentation? Prior to the advent of micro-segmentation, it was very difficult to segment networks into zones and sub-zones because it required the physical deployment of equipment. Routing had to be changed, firewalls had to be locally installed, and the segmentation process would have to be carefully monitored and managed by a team of individuals. Fortunately for SecOps teams, this is no longer the case, thanks to the rapid adoption of cloud technology. There seems to be a misconception associated with micro-segmentation where it might be thought of as a strictly private cloud environment network security solution, whereas in reality, micro-segmentation can be deployed in a hybrid cloud environment – public cloud, private cloud and on-premise. In fact, all public cloud networks, including those offered by the likes of Azure and AWS, offer “baked in” filtering capabilities that make controlling traffic much easier. This lends itself well to the concept of micro-segmentation, so even those businesses that use a hybrid cloud setup can still benefit enormously. The Bottom Line Micro-segmentation presents a viable and scalable solution to tighten network security policies, despite its inherent implementation challenges. While many businesses may find it hard to manage this new method of security, it’s nevertheless a worthwhile endeavor. By utilizing a micro-segmentation method as part of its network security strategy, an organization can immediately bolster its network security against possible hackers and potential data breaches. To help you navigate through your micro-segmentation fact-finding journey, watch this webcast or read more in our resource hub . Schedule a demo Related Articles Q1 at AlgoSec: What innovations and milestones defined our start to 2026? AlgoSec Reviews Mar 19, 2023 · 2 min read 2025 in review: What innovations and milestones defined AlgoSec’s transformative year in 2025? AlgoSec Reviews Mar 19, 2023 · 2 min read Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read Speak to one of our experts Speak to one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Schedule a call

Insecure Service Protocols and Ports Okay, we all have them… they’re everyone’s dirty little network security secrets that we try not to... Risk Management and Vulnerabilities Removing insecure protocols In networks Matthew Pascucci 2 min read Matthew Pascucci Short bio about author here Lorem ipsum dolor sit amet consectetur. Vitae donec tincidunt elementum quam laoreet duis sit enim. Duis mattis velit sit leo diam. Tags Share this article 7/15/14 Published Insecure Service Protocols and Ports Okay, we all have them… they’re everyone’s dirty little network security secrets that we try not to talk about. They’re the protocols that we don’t mention in a security audit or to other people in the industry for fear that we’ll be publicly embarrassed. Yes, I’m talking about cleartext protocols which are running rampant across many networks. They’re in place because they work, and they work well, so no one has had a reason to upgrade them. Why upgrade something if it’s working right? Wrong. These protocols need to go the way of records, 8-tracks and cassettes (many of these protocols were fittingly developed during the same era). You’re putting your business and data at serious risk by running these insecure protocols. There are many insecure protocols that are exposing your data in cleartext, but let’s focus on the three most widely used ones: FTP, Telnet and SNMP. FTP (File Transfer Protocol) This is by far the most popular of the insecure protocols in use today. It’s the king of all cleartext protocols and one that needs to be smitten from your network before it’s too late. The problem with FTP is that all authentication is done in cleartext which leaves little room for the security of your data. To put things into perspective, FTP was first released in 1971, almost 45 years ago. In 1971 the price of gas was 40 cents a gallon, Disneyland had just opened and a company called FedEx was established. People, this was a long time ago. You need to migrate from FTP and start using an updated and more secure method for file transfers, such as HTTPS, SFTP or FTPS. These three protocols use encryption on the wire and during authentication to secure the transfer of files and login. Telnet If FTP is the king of all insecure file transfer protocols then telnet is supreme ruler of all cleartext network terminal protocols. Just like FTP, telnet was one of the first protocols that allowed you to remotely administer equipment. It became the defacto standard until it was discovered that it passes authentication using cleartext. At this point you need to hunt down all equipment that is still running telnet and replace it with SSH, which uses encryption to protect authentication and data transfer. This shouldn’t be a huge change unless your gear cannot support SSH. Many appliances or networking gear running telnet will either need the service enabled or the OS upgraded. If both of these options are not appropriate, you need to get new equipment, case closed. I know money is an issue at times, but if you’re running a 45 year old protocol on your network with the inability to update it, you need to rethink your priorities. The last thing you want is an attacker gaining control of your network via telnet. Its game over at this point. SNMP (Simple Network Management Protocol) This is one of those sneaky protocols that you don’t think is going to rear its ugly head and bite you, but it can! escortdate escorts . There are multiple versions of SNMP, and you need to be particularly careful with versions 1 and 2. For those not familiar with SNMP, it’s a protocol that enables the management and monitoring of remote systems. Once again, the strings can be sent via cleartext, and if you have access to these credentials you can connect to the system and start gaining a foothold on the network, including managing, applying new configurations or gaining in-depth monitoring details of the network. In short, it a great help for attackers if they can get hold of these credentials. Luckily version 3.0 of SNMP has enhanced security that protects you from these types of attacks. So you must review your network and make sure that SNMP v1 and v2 are not being used. These are just three of the more popular but insecure protocols that are still in heavy use across many networks today. By performing an audit of your firewalls and systems to identify these protocols, preferably using an automated tool such as AlgoSec Firewall Analyzer , you should be able to pretty quickly create a list of these protocols in use across your network. It’s also important to proactively analyze every change to your firewall policy (again preferably with an automated tool for security change management ) to make sure no one introduces insecure protocol access without proper visibility and approval. Finally, don’t feel bad telling a vendor or client that you won’t send data using these protocols. If they’re making you use them, there’s a good chance that there are other security issues going on in their network that you should be concerned about. It’s time to get rid of these protocols. They’ve had their usefulness, but the time has come for them to be sunset for good. Schedule a demo Related Articles Q1 at AlgoSec: What innovations and milestones defined our start to 2026? AlgoSec Reviews Mar 19, 2023 · 2 min read 2025 in review: What innovations and milestones defined AlgoSec’s transformative year in 2025? AlgoSec Reviews Mar 19, 2023 · 2 min read Navigating Compliance in the Cloud AlgoSec Cloud Mar 19, 2023 · 2 min read Speak to one of our experts Speak to one of our experts Work email* First name* Last name* Company* country* Select country... Short answer* By submitting this form, I accept AlgoSec's privacy policy Schedule a call