Search results

Cloud security is one of the big buzzwords in the security space along with big data and others. So we’ll try to tackle where cloud... Information Security Cloud Security: Current Status, Trends and Tips Kyle Wickert 2 min read Kyle Wickert Short bio about author here Lorem ipsum dolor sit amet consectetur. Vitae donec tincidunt elementum quam laoreet duis sit enim. Duis mattis velit sit leo diam. Tags Share this article 6/25/13 Published Cloud security is one of the big buzzwords in the security space along with big data and others. So we’ll try to tackle where cloud security is today, where its heading as well as outline challenges and offer tips for CIOs and CSOs looking to experiment with putting more systems and data in the cloud. The cloud is viewed by many as a solution to reducing IT costs and ultimately has led many organizations to accept data risks they would not consider acceptable in their own environments. In our State of Network Security 2013 Survey , we asked security professionals how many security controls were in the cloud and 60 percent of respondents reported having less than a quarter of their security controls in the cloud – and in North America the larger the organization, the less security controls in the cloud. Certainly some security controls just aren’t meant for the cloud, but I think this highlights the uncertainty around the cloud, especially for larger organizations. Current State of Cloud Security Cloud security has clearly emerged with both a technological and business case, but from a security perspective, it’s still a bit in a state of flux. A key challenges that many information security professionals are struggling with is how to classify the cloud and define the appropriate type of controls to secure data entering the cloud. While oftentimes the cloud is classified as a trusted network, the cloud is inherently untrusted since it is not simply an extension of the organization, but it’s an entirely separate environment that is out of the organization’s control. Today “the cloud” can mean a lot of things: a cloud could be a state-of-the-art data center or a server rack in a farm house holding your organization’s data. One of the biggest reasons that organizations entertain the idea of putting more systems, data and controls in the cloud is because of the certain cost savings. One tip would be to run a true cost-benefit-risk analysis that factors in the value of the data being sent into the cloud. There is value to be gained from sending non-sensitive data into the cloud, but when it comes to more sensitive information, the security costs will increase to the point where the analysis may suggest keeping in-house. Cloud Security Trends Here are several trends to look for when it comes to cloud security: Data security is moving to the forefront, as security teams refocus their efforts in securing the data itself instead of simply the servers it resides on. A greater focus is being put on efforts such as securing data-at-rest, thus mitigating the need to some degree the reliance on system administrators to maintain OS level controls, often outside the scope of management for information security teams. With more data breaches occurring each day, I think we will see a trend in collecting less data where is it simply not required. Systems that are processing or storing sensitive data, by their very nature, incur a high cost to IT departments, so we’ll see more effort being placed on business analysis and system architecture to avoid collecting data that may not be required for the business task. Gartner Research recently noted that by 2019, 90 percent of organizations will have personal data on IT systems they don’t own or control! Today, content and cloud providers typically use legal means to mitigate the impact of any potential breaches or loss of data. I think as cloud services mature, we’ll see more of a shift to a model where it’s not just these vendors offering software as a service, but also includes security controls in conjunction with their services. More pressure from security teams will be put on content providers to provide such things as dedicated database tiers, to isolate their organization’s data within the cloud itself. Cloud Security Tips Make sure you classify data before even considering sending it for processing or storage in the cloud. If data is deemed too sensitive, the risks of sending this data into the cloud must be weighed closely against the costs of appropriately securing it in the cloud. Once information is sent into the cloud, there is no going back! So make sure you’ve run a comprehensive analysis of what you’re putting in the cloud and vet your vendors carefully as cloud service providers use varying architectures, processes, and procedures that may place your data in many precarious places. Schedule a demo Related Articles 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 5 Multi-Cloud Environments Cloud Security 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

Recommendations from Rajpreet Kaur, Senior Principal Analyst at Gartner, in her recent blog on remote working, and a perspective on how... Security Policy Management Deploying NSPM to Implement a Gartner Analyst’s Work from Home Network Security Advice Jeffrey Starr 2 min read Jeffrey Starr Short bio about author here Lorem ipsum dolor sit amet consectetur. Vitae donec tincidunt elementum quam laoreet duis sit enim. Duis mattis velit sit leo diam. Tags Share this article 4/27/20 Published Recommendations from Rajpreet Kaur, Senior Principal Analyst at Gartner, in her recent blog on remote working, and a perspective on how Network Security Policy Management systems can help enterprises act upon this guidance The COVID-19 pandemic has been the catalyst for a global migration to remote home working. Managing and mitigating the network security risks this presents, on such an unprecedented scale and for a long period of time, poses a significant challenge even for companies that had remote access working plans in place before the pandemic. Not only are cybercriminals taking advantage of network insecurities to leverage attacks, they are also exploiting human anxiety around the crisis to break through security barriers. In fact, a recent survey found that 40 percent of companies reported seeing increased cyberattacks as they enable remote working. So how should organizations manage their security during these massive changes in network usage? In a recent blog , Rajpreet Kaur , Gartner Senior Principal Analyst, and a specialized expert on both hybrid environment network security and NSPM tools, offered recommendations to organizations on how to handle remote infrastructure security challenges, many of which closely align with a focus on network policy automation and application security. Here’s how network security policy management systems can support and enable Rajpreet Kaur’s key recommendations. 1. Don’t panic and start moving things to the cloud without a proper architectural design in place. Panicking and starting a large-scale move to the cloud without a proper plan in place can lead to poor security controls and ill-prepared migration. Before moving to the cloud, organizations must consider their network’s architectural design, which should always start with analysis. The analytical and discovery capabilities of NSPM systems automate this process by discovering and mapping network connectivity and providing a network map, which helps you to understand your network components, making migrations easier, faster and glitch-free. 2. Design a proper network security architecture and plan considering limited disruption and supporting work from home. Implementing these immediate and urgent network changes can only be done effectively and securely with robust change management processes. As with network analysis, NSPM automation capabilities are also vital in rapid change management. Security automation dramatically accelerates change processes, with request generation to implementation time drastically shortened and enables better enforcement and auditing for regulatory compliance. It also helps organizations overcome skill gaps and staffing limitations, which may have already been impacted by the current crisis. NSPM solutions enable full end-to-end change analysis and automation, including what if security checks, automation design, push of changes, and full documentation and audit trail. This ensures that changes can be implemented rapidly, and applied consistently and efficiently, with a full audit trail of every change. 3. Plan for what you need now, don’t try to implement a long-term strategic solution to fix your immediate needs. The current widespread move to home working is adding an extra layer of complexity to remote network security, since organizations are finding themselves having to implement new security policies and roll out adoption in a very short timeframe. Considering this, it’s important for organizations to focus on short-term needs, rather than attempting to develop a long-term strategic solution. Trying to develop a long-term solution in such a short window can be overwhelming and increase the risk of opening security vulnerabilities. Using NSPM speeds up the configuration and implementation process, allowing you to get your remote network security firewall policies up and running as soon as possible, with minimum disruption to your remote workforce. Once you have dealt with the critical immediate needs, you can then focus on developing a more long-term strategy. 4. Try to support your existing work from home employees by doing minimal changes to the existing architecture, like meeting throughput requirements and upgrading the equipment or restricting the access to a group of employees at times. Managing application connectivity and accessibility is key to ensuring minimal work disruption as employees move to remote working. An effective NSPM solution allows you to discover, identify and map business applications to ensure that they are safe and have the necessary connectivity flows. Having such a view of all the applications that are accessing the network allows security teams to map the workflow and provides visibility of the application’s required connectivity in order to minimise outages. 5. For any new network changes and upgrades, or new deployments, consider developing a work from home first strategy. Developing a work from home (WFH) strategy has never been more essential. The challenge is that WFH is a more vulnerable environment; employees are accessing sensitive data from a range of home devices, via outside networks, that may not have the same security controls. On top of this, cyber threats have already seen a sharp increase as cybercriminals exploit the widespread anxiety and vulnerabilities caused by the global crisis. IT security and networking staff are therefore having to do more, with the same staffing levels, whilst also navigating the challenges of doing this remotely from home. NSPM capabilities can help in overcoming these WFH issues. Security teams may, for example, need to change many Firewall rules to allow secure access to sensitive data. An effective NSPM solution can facilitate this and enable fast deployment by providing the ability to make changes to applications’ firewall openings from a single management interface. 6. Enhance security around public facing applications to protect against COVID-19 related cyber-attacks. With the move to remote working, organizations are increasingly relying on applications to carry out their work from home. Ensuring that business-critical applications stay available and secure while shifting to remote work is key to avoiding workflow disruption. It’s essential to take an application centric approach to application security, and an effective NSPM solution can help you to better manage and secure your business-critical applications . As discussed above, application visibility is key here. NSPM systems provides comprehensive application visibility, security operation teams can monitor critical applications for risks and vulnerabilities to ensure that they are safe. Gartner’s Rajpreet Kaur has delivered a good combination of practical and timely guidance along with the logical insights underlying the useful recommendations. These tips bring helpful guidance on the Work from Home security challenge that stands out for its clear relevance when there is now so much other noise out there. A robust NSPM can help you rapidly implement these invaluable recommendations. Schedule a demo Related Articles 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 5 Multi-Cloud Environments Cloud Security 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 Advanced Cyber Threat and Incident Management Advanced Cyber Threat and Incident Management is a whiteboard-style series of lessons that examine some of the challenges and provide technical tips for helping organizations detect and quickly respond to cyber-attacks while minimizing the impact on the business. Lesson 1 SIEM solutions collect and analyze logs generated by the technology infrastructure, security systems and business applications. The Security Operations Center (SOC) team uses this information to identify and flag suspicious activity for further investigation. In this lesson, Professor Wool explains why it’s important to connect the information collected by the SIEM with other databases that provide information on application connectivity, in order to make informed decisions on the level of risk to the business, and the steps the SOC needs to take to neutralize the attack. How to bring business context into incident response Watch Lesson 2 In this lesson Professor Wool discusses the need for reachability analysis in order to assess the severity of the threat and potential impact of an incident. Professor Wool explains how to use traffic simulations to map connectivity paths to/from compromised servers and to/from the internet. By mapping the potential lateral movement paths of an attacker across the network, the SOC team can, for example, proactively take action to prevent data exfiltration or block incoming communications with Command and Control servers. Bringing reachability analysis into incident response 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

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

As your organization adopts a hybrid IT infrastructure, there are more ways for hackers to steal your sensitive data. This is why cloud... Cloud Security Cloud Application Security: Threats, Benefits, & Solutions 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 6/29/23 Published As your organization adopts a hybrid IT infrastructure, there are more ways for hackers to steal your sensitive data. This is why cloud application security is a critical part of data protection. It allows you to secure your cloud-based applications from cyber threats while ensuring your data is safe. This post will walk you through cloud application security, including its importance. We will also discuss the main cloud application security threats and how to mitigate them. What is Cloud Application Security Cloud application security refers to the security measures taken to protect cloud-based assets throughout their development lifecycle. These security measures are a framework of policies, tools, and controls that protect your cloud against cyber threats. Here is a list of security measures that cloud application security may involve: Compliance with industry standards such as CIS benchmarks to prevent data breaches. Identity management and access controls to prevent unauthorized access to your cloud-based apps. Data encryption and tokenization to protect sensitive data. Vulnerability management through vulnerability scanning and penetration testing. Network perimeter security, such as firewalls, to prevent unwanted access. The following are some of the assets that cloud security affects: Third-party cloud providers like Amazon AWS, Microsoft Azure, and Google GCP. Collaborative applications like Slack and Microsoft Teams. Data Servers. Computer Networks. Why is Cloud Application Security Important Cloud application security is becoming more relevant as businesses migrated their data to the cloud in recent years. This is especially true for companies with a multi-cloud environment. These types of environments create a larger attack surface for hackers to exploit. According to IBM , the cost of a data breach in 2022 was $4.35 million. And this represents an increase of 2.6% from the previous year. The report also revealed that it took an average of 287 days to find and stop a data breach in a cloud environment. This time is enough for hackers to steal sensitive data and really damage your assets. Here are more things that can go wrong if organizations don’t pay attention to cloud security: Brand image damage: A security breach may cause a brand’s reputation to suffer and a decline in client confidence. During a breach, your company’s servers may be down for days or weeks. This means customers who paid for your services will not get access in that time. They may end up destroying your brand’s image through word of mouth. Lost consumer trust: Consumer confidence is tough to restore after being lost due to a security breach. Customers could migrate to rivals they believe to be more secure. Organizational disruption: A security breach may cause system failures preventing employees from working. This, in turn, could affect their productivity. You may also have to fire employees tasked with ensuring cloud security. Data loss: You may lose sensitive data, such as client information, resulting in legal penalties. Trade secrets theft may also affect the survival of your organization. Your competitors may steal your only leverage in the industry. Compliance violations: You may be fined for failing to comply with industry regulations such as GDPR. You may also face legal consequences for failing to protect consumer data. What are the Major Cloud Application Security Threats The following is a list of the major cloud application security threats: Misconfigurations: Misconfigurations are errors made when setting up cloud-based applications. They can occur due to human errors, lack of expertise, or mismanagement of cloud resources. Examples include weak passwords, unsecured storage baskets, and unsecured ports. Hackers may use these misconfigurations to access critical data in your public cloud. Insecure data sharing: This is the unauthorized or unintended sharing of sensitive data between users. Insecure data sharing can happen due to a misconfiguration or inappropriate access controls. It can lead to data loss, breaches, and non-compliance with regulatory standards. Limited visibility into network operations: This is the inability to monitor and control your cloud infrastructure and its apps. Limited network visibility prevents you from quickly identifying and responding to cyber threats. Many vulnerabilities may go undetected for a long time. Cybercriminals may exploit these weak points in your network security and gain access to sensitive data. Account hijacking: This is a situation where a hacker gains unauthorized access to a legitimate user’s cloud account. The attackers may use various social engineering tactics to steal login credentials. Examples include phishing attacks, password spraying, and brute-force attacks. Once they access the user’s cloud account, they can steal data or damage assets from within. Employee negligence and inadequately trained personnel: This threat occurs when employees are not adequately trained to recognize, report and prevent cyber risks. It can also happen when employees unintentionally or intentionally engage in risky behavior. For example, they could share login credentials with unauthorized users or set weak passwords. Weak passwords enable attackers to gain entry into your public cloud. Rogue employees can also intentionally give away your sensitive data. Compliance risks: Your organization faces cloud computing risks when non-compliant with industry regulations such as GDPR, PCI-DSS, and HIPAA. Some of these cloud computing risks include data breaches and exposure of sensitive information. This, in turn, may result in fines, legal repercussions, and reputational harm. Data loss: Data loss is a severe security risk for cloud applications. It may happen for several causes, including hardware malfunction, natural calamities, or cyber-attacks. Some of the consequences of data loss may be the loss of customer trust and legal penalties. Outdated security software: SaaS vendors always release updates to address new vulnerabilities and threats. Failing to update your security software on a regular basis may leave your system vulnerable to cyber-attacks. Hackers may exploit the flaws in your outdated SaaS apps to gain access to your cloud. Insecure APIs: APIs are a crucial part of cloud services but can pose a severe security risk if improperly secured. Insecure APIs and other endpoint infrastructure may cause many severe system breaches. They can lead to a complete system takeover by hackers and elevated privileged access. How to Mitigate Cloud Application Security Risks The following is a list of measures to mitigate cloud app security risks: Conduct a thorough risk analysis: This entails identifying possible security risks and assessing their potential effects. You then prioritize correcting the risks depending on their level of severity. By conducting risk analysis on a regular basis, you can keep your cloud environment secure. You’ll quickly understand your security posture and select the right security policies. Implement a firm access control policy: Access control policies ensure that only authorized users gain access to your data. They also outline the level of access to sensitive data based on your employees’ roles. A robust access control policy comprises features such as: Multi-factor authentication Role-based access control Least Privilege Access Strong password policies. Use encryption: Encryption is a crucial security measure that protects sensitive data in transit and at rest. This way, if an attacker intercepts data in transit, it will only be useful if they have a decryption key. Some of the cloud encryption solutions you can implement include: Advanced Encryption Standard (AES) Rivest -Shamir-Addleman (RSA) Transport Layer Security (TSL) Set up data backup and disaster recovery policies: A data backup policy ensures data is completely recovered in case of breaches. You can always recover the lost data from your data backup files. Data backup systems also help reduce the impact of cyberattacks as you will restore normal operations quickly. Disaster recovery policies focus on establishing protocols and procedures to restore critical systems during a major disaster. This way, your data security will stay intact even when disaster strikes. Keep a constant watch over cloud environments: Security issues in cloud settings can only be spotted through continuous monitoring. Cloud security posture management tools like Prevasio can help you monitor your cloud for such issues. With its layer analysis feature, you’ll know the exact area in your cloud and how to fix it. Test and audit cloud security controls regularly: Security controls help you detect and mitigate potential security threats in your cloud. Examples of security controls include firewalls, intrusion detection systems, and database encryption. Auditing these security controls helps to identify gaps they may have. And then you take corrective actions to restore their effectiveness. Regularly evaluating your security controls will reduce the risk of security incidents in your cloud. Implement a security awareness training program: Security awareness training helps educate employees on cloud best practices. When employees learn commonly overlooked security protocols, they reduce the risks of data breaches due to human error. Organize regular assessment tests with your employees to determine their weak points. This way, you’ll reduce chances of hackers gaining access to your cloud through tactics such as phishing and ransomware attacks. Use the security tools and services that cloud service providers offer: Cloud service providers like AWS, Azure, and Google Cloud Platform (GCP) offer security tools and services such as: Web application firewalls (WAF), Runtime application self-protection (RASP), Intrusion detection and prevention systems Identity and access management (IAM) controls You can strengthen the security of your cloud environments by utilizing these tools. However, you should not rely solely on these features to ensure a secure cloud. You also need to implement your own cloud security best practices. Implement an incident response strategy: A security incident response strategy describes the measures to take during a cyber attack. It provides the procedures and protocols to bring the system back to normal in case of a breach. Designing incident response plans helps to reduce downtime. It also minimizes the impact of the damages due to cyber attacks. Apply the Paved Road Security Approach in DevSecOps Processes: DevSecOps environments require security to be integrated into development workflows and tools. This way, cloud security becomes integral to an app development process. The paved road security approach provides a secure baseline that DevSecOps can use for continuous monitoring and automated remediation. Automate your cloud application security practices Using on-premise security practices such as manual compliance checks to mitigate cloud application security threats can be tiring. Your security team may also need help to keep up with the updates as your cloud needs grow. Cloud vendors that can automate all the necessary processes to maintain a secure cloud. They have cloud security tools to help you achieve and maintain compliance with industry standards. You can improve your visibility into your cloud infrastructures by utilizing these solutions. They also spot real-time security challenges and offer remediations. For example, Prevasio’s cloud security solutions monitor cloud environments continually from the cloud. They can spot possible security threats and vulnerabilities using AI and machine learning. What Are Cloud Application Security Solutions? Cloud application security solutions are designed to protect apps and other assets in the cloud. Unlike point devices, cloud application security solutions are deployed from the cloud. This ensures you get a comprehensive cybersecurity approach for your IT infrastructure. These solutions are designed to protect the entire system instead of a single point of vulnerability. This makes managing your cybersecurity strategy easier. Here are some examples of cloud security application solutions: 1. Cloud Security Posture Management (CSPM) : CSPM tools enable monitoring and analysis of cloud settings for security risks and vulnerabilities. They locate incorrect setups, resources that aren’t compliant, and other security concerns that might endanger cloud infrastructures. 2. The Cloud Workload Protection Platform (CWPP) : This cloud application security solution provides real-time protection for workloads in cloud environments . It does this by detecting and mitigating real-time threats regardless of where they are deployed. CWPP solutions offer various security features, such as: Network segmentation File integrity monitoring Vulnerability scanning. Using CWPP products will help you optimize your cloud application security strategy. 3. Cloud Access Security Broker (CASB) : CASB products give users visibility into and control over the data and apps they access in the cloud. These solutions help businesses enforce security guidelines and monitor user behavior in cloud settings. The danger of data loss, leakage, and unauthorized access is lowered in the process. CASB products also help with malware detection. 4. Runtime Application Self Protection (RASP): This solution addresses security issues that may arise while a program is working. It identifies potential threats and vulnerabilities during runtime and thwarts them immediately. Some of the RASP solutions include: Input validation Runtime hardening Dynamic Application Security testing 5. Web Application and API protection (WAAP) : These products are designed to protect your organization’s Web applications and APIs. They monitor outgoing and incoming web apps and API traffic to detect malicious activity. WAAP products can block any unauthorized access attempts. They can also protect against cyber threats like SQL injection and Cross-site scripting. 6. Data Loss Prevention (DLP): DLP products are intended to stop the loss or leaking of private information in cloud settings. These technologies keep track of sensitive data in use and at rest. They can also enforce rules to stop unauthorized people from losing or accessing it. 7. Security Information and Event Management (SIEM) systems : SIEM systems track and analyze real-time security incidents and events in cloud settings. The effect of security breaches is decreased thanks to these solutions. They help firms in detecting and responding to security issues rapidly. Cloud Native Application Protection Platform (CNAPP) The CNAPP, which Prevasio created, raises the bar for cloud security. It combines CSPM, CIEM, IAM, CWPP, and more in one tool. A CNAPP delivers a complete security solution with sophisticated threat detection and mitigation capabilities for packaged workloads, microservices, and cloud-native applications. The CNAPP can find and eliminate security issues in your cloud systems before hackers can exploit them. With its layer analysis feature, you can quickly fix any potential vulnerabilities in your cloud . It pinpoints the exact layer of code where there are errors, saving you time and effort. CNAPP also offers a visual dynamic analysis of your cloud environment . This lets you grasp the state of your cloud security at a glance. In the process, saving you time as you know exactly where to go. CNAPP is also a scalable cloud security solution. The cloud-native design of Prevasio’s CNAPP enables it to expand dynamically and offer real-time protection against new threats. Let Prevasio Solve Your Cloud Application Security Needs Cloud security is paramount to protecting sensitive data and upholding a company’s reputation in the modern digital age. To be agile to the constantly changing security issues in cloud settings, Prevasio’s Cloud Native Application Protection Platform (CNAPP) offers an all-inclusive solution. From layer analysis to visual dynamic analysis, CNAPP gives you the tools you need to keep your cloud secure. You can rely on Prevasio to properly manage your cloud application security needs. Try Prevasio today! Schedule a demo Related Articles 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 5 Multi-Cloud Environments Cloud Security 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

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

Kyle Wickert explains how organizations can balance the need to modernize their networks without compromising security For businesses of... Digital Transformation Modernizing your infrastructure without neglecting security Kyle Wickert 2 min read Kyle Wickert 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/19/21 Published Kyle Wickert explains how organizations can balance the need to modernize their networks without compromising security For businesses of all shapes and sizes, the inherent value in moving enterprise applications into the cloud is beyond question. The ability to control computing capability at a more granular level can lead to significant cost savings, not to mention the speed at which new applications can be provisioned. Having a modern cloud-based infrastructure makes businesses more agile, allowing them to capitalize on market forces and other new opportunities much quicker than if they depended on on-premises, monolithic architecture alone. However, there is a very real risk that during the goldrush to modernized infrastructures, particularly during the pandemic when the pressure to migrate was accelerated rapidly, businesses might be overlooking the potential blind spot that threatens all businesses indiscriminately, and that is security. One of the biggest challenges for business leaders over the past decade has been managing the delicate balance between infrastructure upgrades and security. Our recent survey found that half of organizations who took part now run over 41% of workloads in the public cloud, and 11% reported a cloud security incident in the last twelve months. If businesses are to succeed and thrive in 2021 and beyond, they must learn how to walk this tightrope effectively. Let’s consider the highs and lows of modernizing legacy infrastructures, and the ways to make it a more productive experience. What are the risks in moving to the cloud? With cloud migration comes risk. Businesses that move into the cloud actually stand to lose a great deal if the process isn’t managed effectively. Moreover, they have some important decisions to make in terms of how they handle application migration. Do they simply move their applications and data into the cloud as they are as a ‘lift and shift’, or do they seek to take a more cloud-native approach and rebuild applications in the cloud to take full advantage of its myriad benefits? Once a business has started this move toward the cloud, it’s very difficult to rewind the process and unpick mistakes that may have been made, so planning really is critical. Then there’s the issue of attack surface area. Legacy on-premises applications might not be the leanest or most efficient, but they are relatively secure by default due to their limited exposure to external environments. Moving said applications onto the cloud has countless benefits to agility, efficiency, and cost, but it also increases the attack surface area for potential hackers. In other words, it gives bots and bad actors a larger target to hit. One of the many traps that businesses fall into is thinking that just because an application is in the cloud, it must be automatically secure. In fact, the reverse is true unless proper due diligence is paid to security during the migration process. The benefits of an app-centric approach One of the ways in which AlgoSec helps its customer master security in the cloud is by approaching it from an app-centric perspective. By understanding how a business uses its applications, including its connectivity paths through the cloud, data centers and SDN fabrics, we can build an application model that generates actionable insights such as the ability to create policy-based risks instead of leaning squarely on firewall controls. This is of particular importance when moving legacy applications onto the cloud. The inherent challenge here is that a business is typically taking a vulnerable application and making it even more vulnerable by moving it off-premise, relying solely on the cloud infrastructure to secure it. To address this, businesses should rank applications in order of sensitivity and vulnerability. In doing so, they may find some quick wins in terms of moving modern applications into the cloud that have less sensitive data. Once these short-term gains are dealt with, NetSecOps can focus on the legacy applications that contain more sensitive data which may require more diligence, time, and focus to move or rebuild securely. Migrating applications to the cloud is no easy feat and it can be a complex process even for the most technically minded NetSecOps. Automation takes a large proportion of the hard work away and enables teams to manage cloud environments efficiently while orchestrating changes across an array of security controls. It brings speed and accuracy to managing security changes and accelerates audit preparation for continuous compliance. Automation also helps organizations overcome skills gaps and staffing limitations. We are likely to see conflict between modernization and security for some time. On one hand, we want to remove the constraints of on-premises infrastructure as quickly as possible to leverage the endless possibilities of cloud. On the other hand, we have to safeguard against the opportunistic hackers waiting on the fray for the perfect time to strike. By following the guidelines set out in front of them, businesses can modernize without compromise. To learn more about migrating enterprise apps into the cloud without compromising on security, and how a DevSecOps approach could help your business modernize safely, watch our recent Bright TALK webinar here . Alternatively, get in touch or book a free demo . Schedule a demo Related Articles 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 5 Multi-Cloud Environments Cloud Security 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, stresses the importance of getting the often-overlooked function of managing network... Professor Wool Bridging Network Security Gaps with Better Network Object Management 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 4/13/22 Published Prof. Avishai Wool, AlgoSec co-founder and CTO, stresses the importance of getting the often-overlooked function of managing network objects right, particularly in hybrid or multi-vendor environments Using network traffic filtering solutions from multiple vendors makes network object management much more challenging. Each vendor has its own management platform, which often forces network security admins to define objects multiple times, resulting in a counter effect. First and foremost, this can be an inefficient use of valuable resources from a workload bottlenecking perspective. Secondly, it creates a lack of naming consistency and introduces a myriad of unexpected errors, leading to security flaws and connectivity problems. This can be particularly applicable when a new change request is made. With these unique challenges at play, it begs the question: Are businesses doing enough to ensure their network objects are synchronized in both legacy and greenfield environments? What is network object management? At its most basic, the management of network objects refers to how we name and define “objects” within a network. These objects can be servers, IP addresses, or groups of simpler objects. Since these objects are subsequently used in network security policies, it is imperative to simultaneously apply a given rule to an object or object group. On its own, that’s a relatively straightforward method of organizing the security policy. But over time, as organizations reach scale, they often end up with large quantities of network objects in the tens of thousands, which typically lead to critical mistakes. Hybrid or multi-vendor networks Let’s take name duplication as an example. Duplication on its own is bad enough due to the wasted resource, but what’s worse is when two copies of the same name have two distinctly different definitions. Let’s say we have a group of database servers in Environment X containing three IP addresses. This group is allocated a name, say “DBs”. That name is then used to define a group of database servers in Environment Y containing only two IP addresses because someone forgot to add in the third. In this example, the security policy rule using the name DBs would look absolutely fine to even a well-trained eye, because the names and definitions it contained would seem identical. But the problem lies in what appears below the surface: one of these groups would only apply to two IP addresses rather than three. As in this case, minor discrepancies are commonplace and can quickly spiral into more significant security issues if not dealt with in the utmost time-sensitive manner. It’s important to remember that accuracy is the name in this game. If a business is 100% accurate in the way it handles network object management, then it has the potential to be 100% efficient. The Bottom Line The security and efficiency of hybrid multi-vendor environments depend on an organization’s digital hygiene and network housekeeping. The naming and management of network objects aren’t particularly glamorous tasks. Having said that, everything from compliance and automation to security and scalability will be far more seamless and risk averse if taken care of correctly. To learn more about network object management and why it’s arguably more important now than ever before, watch our webcast on the subject or read more in our resource hub . Schedule a demo Related Articles 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 5 Multi-Cloud Environments Cloud Security 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

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

Challenges with managing Cisco Meraki in a complex enterprise environment We have worked closely with Cisco for many years in large... Application Connectivity Management Managing the switch – Making the move to Cisco Meraki 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/4/24 Published Challenges with managing Cisco Meraki in a complex enterprise environment We have worked closely with Cisco for many years in large complex environments and have developed integrations to support a variety of Cisco solutions for our joint customers. In recent years we have seen an increased interest in the use of Cisco Meraki devices by enterprises that are also AlgoSec customers. In this post, we will highlight some of the AlgoSec capabilities that can quickly add value for Meraki customers. Meeting the Enterprise The Cisco Meraki MX is a multifunctional security and SD-WAN enterprise appliance with a wide set of capabilities to address multiple use cases—from an all-in-one device. Organizations across all industries rely on the MX to deliver secure connectivity to hub locations or multi cloud environments. The MX is 100% cloud-managed, so installation and remote management are truly zero-touch, making it ideal for distributed branches, campuses, and data center locations. In our talks with AlgoSec customers and partner architects, it is evident that the benefits that originally made Meraki MX popular in commercial deployments were just as appealing to enterprises. Many enterprises are now faced with waves of expansion in employees working from home, and burgeoning demands for scalable remote access – along with increasing network demands by regional centers. The leader of one security team I spoke with put it very well, “We are deploying to 1,200 locations in four global regions, planned to be 1,500 by year’s end. The choice of Meraki is for us a ‘no-brainer.’ If you haven’t already, I know that you’re going to see this become a more popular option with many big operations.” Natural Companions – AlgoSec ASMS and Cisco Meraki-MX This is a natural situation to meet enhanced requirements with AlgoSec ASMS — reinforcing Meraki’s impressive capabilities and scale as a combined, enterprise-class solution. ASMS brings to the table traffic planning and visualization, rules optimization and management, and a solution to address enterprise-level requirements for policy reporting and compliance auditing. In AlgoSec, we’re proud of AlgoSec FireFlow’s ability to model the security-connected state of any given endpoints across an entire enterprise. Now our customers with Meraki MX can extend this technology that they know and trust, analyze real traffic in complex deployments, and acquire an understanding of the requirements and impact of changes delivered to their users and applications that are connected by Meraki deployments. As it’s unlikely that your needs, or those of any data center and enterprise, are met by a single vendor and model, AlgoSec unifies operations of the Meraki-MX with those of the other technologies, such as enterprise NGFW and software-defined network fabrics. Our application-centric approach means that Meraki MX can be a component in delivering solutions for zero-trust and microsegmentation with other Cisco technology like Cisco ACI, and other third parties. Cisco Meraki– Product Demo If all of this sounds interesting, take a look for yourself to see how AlgoSec helps with common challenges in these enterprise environments. More Where This Came From The AlgoSec integration with Cisco Meraki-MX is delivering solutions our customers want. If you want to discover more about the Meraki and AlgoSec joint solution, contact us at AlgoSec! We work together with Cisco teams and resellers and will be glad to schedule a meeting to share more details or walk through a more in depth demo. Schedule a demo Related Articles 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 5 Multi-Cloud Environments Cloud Security 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 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 5 Multi-Cloud Environments Cloud Security 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

Omer Ganot, Cloud Security Product Manager at AlgoSec, outlines six key things that businesses should be doing to ensure their security... Hybrid Cloud Security Management Six best practices for managing security in the hybrid cloud Omer Ganot 2 min read Omer Ganot 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/5/21 Published Omer Ganot, Cloud Security Product Manager at AlgoSec, outlines six key things that businesses should be doing to ensure their security in a hybrid cloud environment Over the course of the past decade, we’ve seen cloud computing vastly transitioning from on-prem to the public cloud. Businesses know the value of the cloud all too well, and most of them are migrating their operations to the cloud as quickly as possible, particularly considering the pandemic and the push to remote working. However, there are major challenges associated with transitioning to the cloud, including the diversity and breadth of network and security controls and a dependency on legacy systems that can be difficult to shake. Public cloud allows organizations for better business continuity, easier scalability and paves the way for DevOps to provision resources and deploy projects quickly. But, what’s the security cost when looking at the full Gpicture of the entire hybrid network? Here I outline the six best practices for managing security in the hybrid cloud: 1. Use next-generation firewalls Did you know that almost half (49%) of businesses report running virtual editions of traditional firewalls in the cloud? It’s becoming increasingly clear that cloud providers’ native security controls are not enough, and that next-gen firewall solutions are needed. While a traditional stateful firewall is designed to monitor incoming and outgoing network traffic, a next-generation firewall (NGFW) includes features such as application awareness and control, integrated breach prevention and active threat intelligence. In other words, while a traditional firewall will allow for layer 1-2 protection, NGFWs allow for protection from levels 3 through 7. 2. Use dynamic objects On-premise security tends to be easier because subnets and IP addresses are typically static. In the cloud, however, workloads are dynamically provisioned and decommissioned, IP addresses change, so traditional firewalls simply cannot keep up. NGFW dynamic objects allow businesses to match a group of workloads using cloud-native categories, and then use these objects in policies to properly enforce traffic and avoid the need to frequently update the policies. 3. Gain 360-degree visibility As with any form of security, visibility is critical. Without that, even the best preventative or remedial strategies will fall flat. Security should be evaluated both in your cloud services and in the path from the internet and data center clients. Having one single view over the entire network estate is invaluable when it comes to hybrid cloud security. AlgoSec’s powerful AutoDiscovery capabilities help you understand the network flows in your organization. You can automatically connect the recognized traffic flows to the business applications that use them and seamlessly manage the network security policy across your entire hybrid estate. 4. Evaluate risk in its entirety Too many businesses are guilty of only focusing on cloud services when it comes to managing security. This leaves them inherently vulnerable on other network paths, such as the ones that run from the internet and data centers towards the services in the cloud. As well as gaining 360-degree visibility over the entire network estate, businesses also need to be sure to actively monitor those areas for risk with equal weighting in terms of priority. 5. Clean up cloud policies regularly The cloud security landscape changes at a faster rate than most businesses can realistically keep up with. For that reason, cloud security groups tend to change with the wind, constantly being adjusted to account for new applications. If a business doesn’t keep on top of its cloud policy ‘housekeeping’, they’ll soon become bloated, difficult to maintain and risky. Keep cloud security groups clean and tidy so they’re accurate, efficient and don’t expose risk. 6. Embrace DevSecOps The cloud might be perfect for DevOps in terms of easy and agile resource and security provisioning using Infrastructure-as-code tools, but the methodology is seldom used for risk analysis and remediation recommendations. Businesses that want to take control of their cloud security should pay close attention to this. Before a new risk is introduced, you should obtain an automatic what-if risk check as part of the code’s pull request, before pushing to production. From visibility and network management right through to risk evaluation and clean-up, staying secure in a hybrid cloud environment might sound like hard work, but by embracing these fundamental practices your organization can start putting together the pieces of its own security puzzle. The AlgoSec Security Management Suite (ASMS) makes it easy to support your cloud migration journey, ensuring that it does not block critical business services and meet compliance requirements. To learn more or ask for your personalized demo, click here . Schedule a demo Related Articles 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 5 Multi-Cloud Environments Cloud Security 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