Hybrid cloud management: All you need to know

<p>Migrating applications to the cloud – without creating security holes, application outages or violating compliance – is within reach!</p> <p>In this webinar, Avivi Siman-Tov, Director of Product at AlgoSec, will guide you how to simplify and accelerate large-scale complex application migration projects.</p> <p>The webinar will cover:</p> <ul> <li>Why organizations choose to migrate their applications to the cloud</li> <li>What is required in order to move the security portion of your application and how long it may take</li> <li>Challenges and solutions to lower the cost, better prepare for the migration and reduce the risks involved</li> <li>How to deliver unified security policy management across the hybrid cloud environment</li> </ul>

<p>Cloud computing provides improved security, agility, and flexibility. However, integrating this new service into legacy IT environments comes with great concern.</p> <p>In a recent report published by the Cloud Security Alliance (CSA), security, data loss and compliance were identified as the top 3 concerns when moving to the cloud. In the face of increasingly complex environments, cloud visibility and expertise are essential to ensuring a manageable, secure and fluent transition to a native cloud, hybrid or multi-cloud environment.</p> <p>Join our special webinar with John Yeoh, Director of Research with expertise in cybersecurity, cloud computing, information security, and next generation technology from the Cloud Security Alliance (CSA).</p> <p>We will cover various topics from the new CSA report Cloud Complexity: The Use of Hybrid and Multi-Cloud Environments, including:</p> <ul> <li>Workloads being used in or moved to the cloud and how they are being deployed/migrated</li> <li>Types of cloud platforms being used by companies</li> <li>Common security challenges faced by companies when moving workloads to the cloud</li> <li>Methods of managing risk and vulnerabilities in the cloud environment</li> <li>Causes of network or application outages and the amount of time it took to remediate</li> </ul>

<p>Public clouds such as Amazon Web Services (AWS) are a critical part of your hybrid network. It is important to keep out the bad guys (including untrusted insiders) and proactively secure your entire hybrid network.</p> <p>Securing your network is both the responsibility of the cloud providers, as well as your organization’s IT and CISOs – the shared responsibility model. As a result, your organization needs visibility into what needs to be protected, as well as an understanding of the tools that are available to keep them secure.</p> <p>In this webinar, Omer Ganot, AlgoSec’s Cloud Security Product Manager, and Stuti Deshpande&#8217;s, Amazon Web Service’s Partner Solutions Architect, will share security challenges in the hybrid cloud and provide tips to protect your AWS and hybrid environment, including how to:</p> <ul> <li>Securely migrate workloads from on-prem to public cloud</li> <li>Gain unified visibility into your network topology and traffic flows, including both public cloud and on-premises assets, from a single console.</li> <li>Manage/orchestrate multiple layers of security controls and proactively detect misconfigurations</li> <li>Protect your data, accounts, and workloads from misconfiguration risks</li> <li>Protect web applications in AWS by filtering traffic and blocking common attack patterns, such as SQL injection or cross-site scripting</li> <li>Gain a unified view of your compliance status and achieve continuous compliance</li> </ul>

Accelerate application migration

<p>It’s common for people to imagine that business applications can be beamed up, <em>Star Trek</em> style, into the cloud – the IT team just needs to press a few buttons and whoosh, the migration is done.  If only it were that easy:  In this post, I’m going to cover some of the obstacles that need to be overcome when migrating applications to the cloud.</p> <p>In the first place, it’s important to note that there are some applications that should not, or cannot be moved.  Legacy applications may be difficult to virtualize, requiring significant development work before they can be migrated.  Some applications may be sensitive to latency, so for performance reasons they should stay on-premise.  Others may be governed by regulations which prohibit their moving outside of a given jurisdiction or geographic region.  But in general, we’ve found through working with large enterprise organizations that around 85% of applications can potentially be migrated to the cloud.</p> <p><strong>Hand-drawing maps</strong></p> <p>But then there are multiple challenges which need to be addressed for the migration to be smooth and secure.  First, the application’s existing network flows need to be mapped, so that you know how to reconnect the application’s connectivity post-migration.  This is extremely hard to do in complex environments.  There’s usually little to no up-to-date documentation, and attempting to understand the requirements and then painstakingly migrate and adjust every firewall rule, router ACL and cloud security group to the new environment manually is an extremely time-consuming and error prone process.  A single mistake can cause outages, compliance violations and create holes in your security perimeter.</p> <p>Just how long could this process take?  In our experience, an experienced consultant can manually map around one application per day, or five per week, depending on the number of network flows in the application, and the complexity.  This means a team of five consultants would take around a year to map 1,200 applications in a typical large enterprise.  If the organization does have good documentation of its applications, and an accurate configuration management database, it may be possible to cut this time by 50%.</p> <p>But given the work and time involved &#8211; not to mention cost &#8211;  in mapping applications manually, some organizations may ask if they really need to do it before migration.  The answer is definitely yes, unless they plan to move only one or two applications in total – and can afford to manage without those applications for hours or days, in the likely event that a problem occurs and connectivity is disrupted.  Having <a href="https://www.algosec.com/application-connectivity-management/">comprehensive maps</a> of all the applications you want to migrate is essential: this atlas of connectivity flows shows the way forward to smooth, secure cloud migrations.</p> <p><strong>Ready to move</strong></p> <p>With your atlas of existing connectivity maps, you’re ready to tackle the migration process itself.  This can be done manually using the APIs and dashboards available on all cloud platforms, but it’s slow work, and it’s all too easy to make costly mistakes.  Some cloud service providers offer native automation tools, but these often only address the cloud provider’s environment and they don’t provide visibility, automation or change management across your entire estate.   Even some third-party cloud management tools which are capable of spanning multiple clouds will not be necessarily cover your on-premise networks.</p> <p>The most effective way to accelerate application migrations is with an <a href="https://www.algosec.com/data-center-migration/">automation solution</a> that supports both your existing on-premise firewall estate, and the new cloud security controls, and can accurately define the flows needed in the new environment based on your atlas of existing connectivity flows, as well as the security and compliance needs of the new environment.</p> <p>You can then use the solution to navigate through the actual migration process to the cloud, automatically generating the hundreds of security policy change requests that are needed across on-premise firewalls and cloud security controls.  This dramatically simplifies a process that is extremely complex, drawn-out and risky, if attempted manually.</p> <p>After the applications have been migrated, the automation solution should be used to provide <a href="https://www.algosec.com/hybrid-cloud-security-management/">unified security policy management</a> for the entire enterprise environment, from a single console.</p> <p>While there isn’t yet a method for beaming applications up instantly into the cloud, automation makes the process both fast and relatively pain-free by eliminating time-sapping, error-prone manual processes, such as connectivity discovery and mapping, during the migration itself, and in ongoing management.  Automation helps organizations to boldly go where they haven’t easily been able to go before.</p> <p>If you want to hear more, check out my recent webinar on <a href="https://www.brighttalk.com/webcast/11873/252617">migrating application connectivity to the cloud</a>.</p> <p>&nbsp;</p>

Customer story securelink

<h1 class="heading title">SecureLink Enables Business Agility with Hybrid Cloud Management</h1> <div class="quote">To be able to apply the same policy on all your infrastructure is priceless</div> <div class="description-text"> <p>SecureLink is Europe’s premier, award-winning, cybersecurity company. Active since 2003, they operate from 15 offices in 8 countries, to build a safe, connected world. More than 2,000 experts and thought leaders are dedicated to delivering unrivalled information security value for over 1,300 customers. They are part of the Orange Group, one of the world’s leading telecommunications operators, and listed on Euronext Paris and the New York Stock Exchange (NYSE).</p> <h2>The Challenge</h2> <p>SecureLink has been an on-site consultant for several years for a large global entertainment company. SecureLink’s client has over 100 firewalls running both on-premises and on Amazon<br /> Web Services (AWS) from several different vendors.</p> <p>Some of the challenges included:</p> <ul> <li>“Shadow IT” had taken over, causing security risks and friction with IT, who had to support it.</li> <li>Security policies were being managed in tedious and unmaintainable Excel spreadsheets</li> <li>Lack of verification if official firewall policies accurately reflected traffic flows</li> </ul> <p>The business units were pushing a migration to a hybrid cloud environment rather than relying exclusively on an on-premises deployment. Business units were unilaterally moving business applications to the cloud, leading to “shadow IT.”</p> <p>Business application owners were unable to comply with security policies, troubleshoot their “shadow network,” nor connect cloud-based servers to local servers. When there were problems, the business units went back to the IT department, who had to fix a mess they didn’t create.</p> <h2>The Solution</h2> <p>SecureLink was searching for a solution that provided:</p> <ul> <li>Automation of security policy change management and documentation of security policy changes</li> <li>Comprehensive firewall support for their multi-vendor, hybrid estate</li> <li>Ability to determine compliance and risk profiles</li> <li>Full visibility and control for IT, while enabling business agility</li> </ul> <p>In order to keep the business happy and agile, but ensure that IT had full visibility and control, they implemented AlgoSec.</p> <p>The client selected AlgoSec’s Security Policy Management Solution, which includes AlgoSec Firewall Analyzer and AlgoSec FireFlow.</p> <p>AlgoSec Firewall Analyzer delivers visibility and analysis of complex network security policies across on-premise, cloud, and hybrid networks. It automates and simplifies security operations including troubleshooting, auditing, and risk analysis. Using Firewall Analyzer, SecureLink can optimize the configuration of firewalls, and network infrastructure to ensure security and compliance.</p> <p>AlgoSec FireFlow enables security staff to automate the entire security policy change process from design and submission to proactive risk analysis, implementation, validation, and auditing. Its intelligent, automated workflows save time and improve security by eliminating manual errors and reducing risk.</p> <h2>The Results</h2> <p>AlgoSec helped SecureLink gain control of shadow IT without slowing down the business. By using AlgoSec to gain full visibility of the entire network, IT was able to regain control over company’s security policy while supporting the move to the cloud. “AlgoSec lets us take ownership and be quick for the business,” said Björn Löfman, a consultant at SecureLink. “The way AlgoSec provides the whole map of the internal and cloud networks is outstanding, and to be able to apply the same policy on all your infrastructure is priceless.”</p> <p>By using the AlgoSec Security Management Solution, SecureLink was able to clean up risky firewall policies, gain increased understanding of their security policies, tighten compliance, and enhance migrations of hardware and implement a hybrid cloud environment with Amazon Web Services (AWS).</p> <p>Some benefits to the client of AlgoSec include:</p> <ul> <li>Greater understanding of network security policies</li> <li>Easier firewall migration – they migrated from Juniper NetScreen to Check Point firewalls</li> <li>Ability to optimize rules and reduce unneeded and duplicate rules and objects. They were able to go from 4,000 rules to 1,110 rules – a 72% reduction.</li> <li>Move to the hybrid cloud with the adoption of Amazon Web Services</li> <li>Able to reduce shadow IT and reclaim ownership of the cloud</li> <li>Full visibility of entire hybrid network – including both on-premise and devices in the cloud including firewalls, <a href="https://www.algosec.com/professor-wool/best-practices-amazon-web-services-aws-security/">AWS security groups</a>, and Access Control Lists (ACLs).</li> </ul> </div>

Migrating to AWS

<h2 class="wp-block-heading">Yitzy Tannenbaum, Product Marketing Manager at AlgoSec, discusses how AWS customers can leverage AlgoSec for AWS to easily migrate applications</h2> <p></p> <p>Public cloud platforms bring a host of benefits to organizations but managing security and compliance can prove complex. These challenges are exacerbated when organizations are required to manage and maintain security across all controls that make up the security network including on-premise, SDN and in the public cloud. According to a <a href="https://www.gartner.com/en/doc/350439-clouds-are-secure-are-you-using-them-securely">Gartner study</a>, 81% of organizations are concerned about security, and 57% about maintaining regulatory compliance in the public cloud.</p> <p>AlgoSec’s partnership with AWS helps organizations overcome these challenges by making the most of AWS’ capabilities and providing solutions that complement the AWS offering, particularly in terms of security and operational excellence. And to make things even easier, AlgoSec is now available in AWS Marketplace.</p> <h3>Accelerating complex application migration with AlgoSec</h3> <p>Many organizations choose to migrate workloads to AWS because it provides unparalleled opportunities for scalability, flexibility, and the ability to spin-up new servers within a few minutes.</p> <p>However, moving to AWS while still maintaining high-level security and avoiding application outages can be challenging, especially if you are trying to do the migration manually, which can create opportunities for human error.</p> <p>We help simplify the migration to AWS with a six-step automated process, which takes away manual processes and reduces the risk of error:</p> <p>Step 1 &#8211; AlgoSec automatically discovers and maps network flows to the relevant business applications.</p> <p>Step 2- AlgoSec assesses the changes in the application connectivity required to migrate it to AWS.</p> <p>Step 3- AlgoSec analyzes, simulates and computes the necessary changes, across the entire hybrid network (over firewalls, routers, security groups etc.), including providing a what-if risk analysis and compliance report.</p> <p>Step 4- AlgoSec automatically migrates the connectivity flows to the new AWS environment.</p> <p>Step 5 &#8211; AlgoSec securely decommissions old connectivity.</p> <p>Step 6- The AlgoSec platform provides ongoing monitoring and visibility of the cloud estate to maintain security and operation of policy configurations or successful continuous operation of the application.</p> <h3>Gain control of hybrid estates with AlgoSec</h3> <p>Security automation is essential if organizations are to maintain security and compliance across their hybrid environments, as well as get the full benefit of AWS agility and scalability. AlgoSec allows organizations to seamlessly manage security control layers across the entire network from on-premise to cloud services by providing Zero-Touch automation in three key areas.</p> <p>First, visibility is important, since understanding the network we have in the cloud helps us to understand how to deploy and manage the policies across the security controls that make up the hybrid cloud estate. We provide instant visibility, risk assessment and compliance, as well as rule clean-up, under one unified umbrella. Organizations can gain instant network visibility and maintain a risk-free optimized rule set across the entire hybrid network &#8211; across all AWS accounts, regions and VPC combinations, as well as 3rd party firewalls deployed in the cloud and across the connection to the on-prem network.</p> <p>Secondly, changes to network security policies in all these diverse security controls can be managed from a single system, security policies can be applied consistently, efficiently, and with a full audit trail of every change.</p> <p>Finally, security automation dramatically accelerates change processes and enables better enforcement and auditing for regulatory compliance. It also helps organizations overcome skill gaps and staffing limitations.</p> <h3>Why Purchase Through AWS Marketplace?</h3> <p>AWS Marketplace is a digital catalog with thousands of software listings from independent software vendors (ISVs). It makes it easy for organizations to find, test, buy, and deploy software that runs on Amazon Web Services (AWS), giving them a further option to benefit from AlgoSec. The new listing also gives organizations the ability to apply their use of AlgoSec to their AWS Enterprise Discount Program (EDP) spend commitment.</p> <p>With the addition of AlgoSec in AWS Marketplace, customers can benefit from simplified sourcing and contracting as well as consolidated billing, ultimately resulting in cost savings. It offers organizations instant visibility and in-depth risk analysis and remediation, providing multiple unique capabilities such as cloud security group clean-ups, as well as central policy management. This strengthens enterprises’ cloud security postures and ensures continuous audit-readiness.</p> <h3>Ready to Get Started?</h3> <p>The addition of AlgoSec in AWS Marketplace is the latest development in the relationship between AlgoSec and AWS and is available for businesses with 500 or more users. Visit the <a href="https://aws.amazon.com/marketplace/pp/B08KS9XXSK/">AlgoSec AWS Marketplace listing</a> for more information or contact us to discuss it further.</p>

Preparing your move to the cloud

<p>This situation may sound familiar – your CEO, CIO, or another executive outside of the security organization summons you to a meeting. “We have decided to move [Enter unreasonable number here] of our business applications to the public cloud by [Enter impossible timeframe here] he announces. “And don’t tell us that security is an issue in the cloud – [Enter name of high-profile competitor here] has already saved millions of dollars by moving to the cloud – so do what you need to do make sure we are secure”.</p> <p>Sigh.</p> <p>Having secured network access in your data center for years using a mix of firewalls, IPSs, proxies and other related devices from well-established vendors, you may naturally gravitate towards a similar architecture for the public cloud. But after some digging, you discover network security in the cloud is in its infancy and often confusing. In <a href="http://www.algosec.com/en/resources/security_policy_management_in_hybrid_cloud_environments_2014" target="_blank" rel="noopener noreferrer">our recent survey</a>, we discovered that only a third of respondents who are currently deploying or planning to deploy applications in the public cloud are using commercial firewalls for network access. And a full third of respondents with concrete public cloud plans do not know which network security controls they are going to use!</p> <p>On the one hand most organizations will deploy a good chunk of their business applications on a public IaaS platform in the foreseeable future, but on the other-hand, for nearly all organizations, the on-premise data center is not going away anytime soon. So the question you should ask yourself is not “how do I secure the public cloud?” but rather “how do I ensure security across my hybrid environment?”</p> <p>Here are a few tips to help you plan your security policy management across a hybrid environment.</p> <p><b>1. Select the right security controls </b></p> <p>There are three basic methods to secure network access on public clouds:</p> <p><b>Commercial firewalls</b>: Commercial-grade firewalls for the public cloud do exist, but the level of support and functionality varies greatly between vendors. Their benefits include unified management with on-premise firewalls as well as familiarity with how policies are defined and enforced. Cons include cost, scalability and a limited feature-set for some vendors.</p> <p><b>Cloud provided controls: </b>Cloud providers usually provide their own security controls (e.g. Amazon Security Groups). These controls are generally free (definitely a pro!), and provide a good level of functionality. However, in many cases they lack enterprise-grade management and do not work across different cloud providers since every provider’s controls are different.</p> <p><b>Host-based Firewalls: </b>Since public IaaS is basically about spinning up compute instances you can leverage host based firewalls to control network access (e.g. IPTables). This is a good cross-cloud solution, but cons include management overhead and a limited feature set.</p> <p>There is no right answer when it comes to selecting network security controls in the cloud, and our survey underscores the fact that the network security controls landscape in the cloud is highly fragmented. And to make matters even more complex, it changes at a fast pace. Make sure you carefully evaluate the options and choose the security controls that best suit your business needs.</p> <p><b>2. Get Visibility Across the Entire Environment</b></p> <p>Regardless of which security controls you choose, visibility across your hybrid environment is key to a successful migration and deployment. Yet as our survey found, visibility is severely lacking, and without visibility you’re basically driving blind. Make sure you select controls that work with a <a href="http://www.algosec.com/en/products_solutions/products/products_overview" target="_blank" rel="noopener noreferrer">policy management platform</a> that provides visibility across the entire hybrid environment.</p> <p><b>3. Improve Processes with Security Automation</b></p> <p>Hand in hand with visibility is security automation. Automation is the key to effectively migrating to and managing a hybrid environment – especially since you will be expected to manage security at the “speed of cloud”. When you’re trying to manage hundreds or even thousands of policy rules, automation is the only way. It’s no surprise that security change management fails because teams, often working in silos, use manual, time-consuming processes. So learn where your process breakdowns occur and use automation to address the problem and manage your environment. You’ll not only help reduce business outages and speed up application deployments in the cloud, but you’ll also get all the teams working together, harmoniously for the benefit of business agility.</p> <p><b>4. Place Ownership of Security in the Right Hands</b></p> <p>While allowing the different teams to work together using automation tools is critical to the success of your hybrid cloud environment, it’s also important to select the right team to lead your security effort. Our survey found that large and small companies struggled to assign responsibility for security in hybrid cloud environments. Should it be handled by the Information Security team (most common for larger organizations) or IT operations (most common for smaller organizations)? Or should the responsibility fall on platform providers? Make sure to align IT and information security roles and responsibilities for security management processes that work for your organization.</p> <p>These are just a few suggestions to help you ensure security as you <a href="http://www.algosec.com/en/products_solutions/by_business_need/public_cloud_security" target="_blank" rel="noopener noreferrer">plan your move to a hybrid cloud environment</a>. While it may all seem rather daunting, like many new initiatives it basically boils down to selecting the right tools, processes, and people to get the job done. Hopefully these suggestions will point you in the right direction.</p>

Advanced traffic filtering in AWS

<p>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.</p> <p>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.</p> <p>Your Amazon VPC provides you with several tools to do this. The two most important ones are <strong>security groups </strong>and <strong>Network Access Control Lists (NACLs).</strong></p> <ul> <li><strong>Security groups</strong> are stateful firewalls that secure inbound traffic for individual EC2 instances.</li> <li><strong>Network ACLs</strong> are stateless firewalls that secure inbound and outbound traffic for VPC subnets.</li> </ul> <p>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.</p> <p>For example, your <a href="https://www.algosec.com/resources/what-are-firewall-rules/"><strong>firewall</strong><strong> rules</strong></a> 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.</p> <p>Before you can <a href="https://www.algosec.com/solutions/network-security-management/"><strong>manage AWS network security effectively</strong></a>, you must familiarize yourself with how AWS security tools work and what sets them apart.</p> <p><strong>Everything you need to know about security groups vs NACLs</strong></p> <p><strong>AWS security groups</strong><strong> explained:</strong></p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p><strong>AWS NACLs</strong><strong> explained:</strong></p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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 <a href="https://www.algosec.com/blog/50-percent-of-failures-are-caused-by-human-error/"><strong>potential security vulnerabilities</strong></a>.</p> <p><strong>How to configure and map NACL associations</strong></p> <p>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.</p> <p>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.</p> <p><strong>To find out which NACL is associated with a subnet:</strong></p> <ol> <li>Open the <a href="https://console.aws.amazon.com/vpc/"><strong>Amazon VPC</strong><strong> console</strong></a>.</li> <li>Select <strong>Subnets</strong> in the navigation pane. Select the subnet you want to inspect.</li> <li>The <strong>Network ACL </strong>tab will display the ID of the ACL associated with that network, and the rules it contains.</li> </ol> <p><strong>To find out which subnets are associated with a NACL:</strong></p> <ol> <li>Open the <a href="https://console.aws.amazon.com/vpc/"><strong>Amazon VPC</strong><strong> console</strong></a>.</li> <li>Select <strong>Network ACLS</strong> in the navigation pane. Click over to the column entitled <strong>Associated With.</strong></li> <li>Select a Network ACL from the list.</li> <li>Look for <strong>Subnet associations </strong>on the details pane and click on it. The pane will show you all subnets associated with the selected Network ACL.</li> </ol> <p>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.</p> <p><strong>5 best practices for AWS NACL management</strong></p> <ol> <li><strong> Pay close attention to default NACLs, especially at the beginning</strong></li> </ol> <p>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.</p> <p>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.</p> <ol start="2"> <li><strong> Implement a two-tiered system where NACLs and security groups complement one another</strong></li> </ol> <p>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.</p> <p>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).</p> <ol start="3"> <li><strong> Look out for ineffective, redundant, and misconfigured deny rules</strong></li> </ol> <p>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.</p> <p>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.</p> <ol start="4"> <li><strong> Limit outbound traffic to the required ports or port ranges</strong></li> </ol> <p>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.</p> <p>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.</p> <ol start="5"> <li><strong> Test your security posture frequently and verify the results</strong></li> </ol> <p>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.</p> <p>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.</p> <p><strong>How to diagnose security group rules and NACL rules with flow logs</strong></p> <p>Flow logs allow you to verify whether your <a href="https://www.algosec.com/solutions/firewall-management/"><strong>firewall</strong><strong> rules follow security best practices</strong></a> 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.</p> <p>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.</p> <p>Flow logs are available at three distinct levels, each accessible through its own console:</p> <ul> <li>Network interfaces</li> <li>VPCs</li> <li>Subnets</li> </ul> <p>You can use the <strong>ping</strong> 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.</p> <p>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.</p> <p>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:</p> <table style="border-collapse: collapse; width: 100%;"> <tbody> <tr style="border-style: solid; border-color: #000000;"> <td style="width: 100%;"> aws ec2 create-flow-logs \</p> <p>&#8211;resource-type NetworkInterface \</p> <p>&#8211;resource-ids eni-1235b8ca123456789 \</p> <p>&#8211;traffic-type ALL \</p> <p>&#8211;log-group-name my-flow-logs \</p> <p>&#8211;deliver-logs-permission-arn arn:aws:iam::123456789101:role/publishFlowLogs</td> </tr> </tbody> </table> <p>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:</p> <table style="border-collapse: collapse; width: 100%;"> <tbody> <tr style="border-style: solid; border-color: #000000;"> <td style="width: 100%;"> 2 123456789010 eni-1235b8ca123456789 203.0.113.12 172.31.16.139 0 0 1 4 336 1432917027   1432917142 ACCEPT OK</td> </tr> </tbody> </table> <table style="border-collapse: collapse; width: 100%;"> <tbody> <tr style="border-style: solid; border-color: #000000;"> <td style="width: 100%;"> 2 123456789010 eni-1235b8ca123456789 172.31.16.139 203.0.113.12 0 0 1 4 336 1432917094   1432917142 REJECT OK</td> </tr> </tbody> </table> <p>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:</p> <ul> <li><strong>Version</strong> tells you the version currently in use. Default flow logs requests use Version 2. Expanded custom requests may use Version 3 or 4.</li> <li><strong>Account-id </strong>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.</li> <li><strong>Interface-id </strong>shows the unique ID of the network interface for the traffic currently under inspection.</li> <li><strong>Srcaddr </strong>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.</li> <li><strong>Dstaddr </strong>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.</li> <li><strong>Srcport </strong>is the source port for the traffic under inspection.</li> <li><strong>Dstport </strong>is the destination port for the traffic under inspection.</li> <li><strong>Protocol </strong>refers to the corresponding <a href="http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml"><strong>IANA traffic protocol number</strong></a>.</li> <li><strong>Packets </strong>describes the number of packets transferred.</li> <li><strong>Bytes </strong>describes the number of bytes transferred.</li> <li><strong>Start </strong>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.</li> <li><strong>End </strong>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.</li> <li><strong>Action </strong>describes what happened to the traffic under inspection: <ul> <li>ACCEPT means that traffic was allowed to pass.</li> <li>REJECT means the traffic was blocked, typically by security groups or NACLs.</li> </ul> </li> </ul> <ul> <li><strong>Log-status </strong>confirms the status of the flow log: <ul> <li>OK means data is logging normally.</li> <li>NODATA means no network traffic to or from the network interface was detected during the specified interval.</li> <li>SKIPDATA means some flow log records are missing, usually due to internal capacity restraints or other errors.</li> </ul> </li> </ul> <p>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.</p> <p>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.</p> <p>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.</p> <p>However, this model <em>does </em>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?</p> <p><strong>The basics:  security groups</strong></p> <p>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 <em>instance –</em> a virtualized computer in the AWS estate.  <a href="https://www.algosec.com/professor-wool/best-practices-amazon-web-services-aws-security/">AWS Security Groups</a> 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 <a href="https://www.youtube.com/watch?v=nVnhFYsdBr0&amp;index=1&amp;list=PLIQj82uPckgpvhSzyZDgh1mjLqaRflIxB">video lesson 1:  the fundamentals of AWS Security Groups</a>, but the crucial points to be aware of are as follows.</p> <p>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.</p> <p>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.</p> <p><strong>Adding Network ACLs into the mix</strong></p> <p>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.</p> <p>The first difference is that NACLs are not directly tied to instances, but are tied with the <em>subnet</em> within your AWS virtual private cloud that <em>contains</em> the relevant instance.  This means that the rules in a NACL apply to <em>all </em>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, <em>plus</em> 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.</p> <p>The second difference is that NACLs can be written to include an explicit action, so you can write ‘deny’ rules &#8211; 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.</p> <p><strong>It’s all about the order</strong></p> <p>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.</p> <p>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.</p> <p>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?</p> <p>The order by which rules are evaluated is this; For <u>inbound</u> 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.</p> <p>For <u>outbound</u> 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.</p> <p>You can see me explain this topic in person in my new whiteboard video:</p> <p><iframe src="https://www.youtube.com/embed/X-MdCb9FMLc?list=PLIQj82uPckgpvhSzyZDgh1mjLqaRflIxB" width="560" height="315" frameborder="0" allowfullscreen="allowfullscreen"></iframe></p>

Virtualized firewalls native controls

<p>I was recently contacted by an analyst who asked for my thoughts on the usage of, and business value offered by virtualized next-generation firewalls (NGFWs) in enterprises’ public cloud environments, such as Amazon Web Services (AWS) and Microsoft Azure – particularly as these environments offer their own native security controls.  These were very interesting questions, which I felt were worth exploring.<strong> </strong></p> <p>Certainly, both public cloud offerings include traffic filtering capabilities:  AWS uses Security Groups and Network Access Control Lists to achieve this (as we covered in an earlier <a href="https://www.algosec.com/blog/using-aws-security-groups-nacls-advanced-traffic-filtering-cloud/">blog</a>), and Microsoft Azure uses <a href="https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-nsg">Network Security Groups</a> to allow or deny traffic in a virtual network.  I believe that the costs for these controls are included as a part of the overall service provision, which certainly makes them an inexpensive option for provisioning security in public clouds.</p> <p>As such, these native security controls are well suited to development or test environments, workloads from smaller organizations, and ‘shadow IT’ applications for larger organizations.  Usually, such deployments have relatively loose security requirements:  there is minimal need for regulatory compliance, and a low perceived risk to the business, because the deployments are not seen as mission-critical.  For these use cases, AWS and Azure’s own security controls are often good enough.</p> <p>However, NGFWs provide additional advanced features such as application awareness, user awareness, the ability to create hierarchical network object groups, and the ability to add comments and notes to rules. Therefore, organizations that need a more sophisticated, granular approach to network and application security should carefully evaluate the capabilities of both cloud controls and virtualized NGFWs to figure out which combination of technologies best suits their needs.</p> <p>I believe that major Fortune 1000 enterprises are just starting to move workloads to public clouds. Large-scale, business critical applications, carrying sensitive, regulated data, are not yet in production in large volumes in public clouds.  However, this landscape will change, and soon. When it does, I suspect that the more sophisticated security features that major enterprises demand – which are available from firewall vendors but not from public cloud vendors’ controls yet – will drive and accelerate deployments of virtualized NGFWs in these environments.</p> <p>It’s also important to remember that once an organization has migrated applications to the cloud, the cloud environment becomes an extension of traditional on-premise networks, with highly sensitive corporate data flowing across both.  So you need to be able to visualize and manage policies across both environments consistently and cohesively, through a single pane of glass, to ensure security and compliance requirements are met.</p>

<p>Migrating applications to the cloud – without creating security holes, application outages or violating compliance – is within reach!</p> <p>In this webinar, Avivi Siman-Tov, Director of Product at AlgoSec, will guide you how to simplify and accelerate large-scale complex application migration projects.</p> <p>The webinar will cover:</p> <ul> <li>Why organizations choose to migrate their applications to the cloud</li> <li>What is required in order to move the security portion of your application and how long it may take</li> <li>Challenges and solutions to lower the cost, better prepare for the migration and reduce the risks involved</li> <li>How to deliver unified security policy management across the hybrid cloud environment</li> </ul>

Customer story securelink

<h1 class="heading title">SecureLink Enables Business Agility with Hybrid Cloud Management</h1> <div class="quote">To be able to apply the same policy on all your infrastructure is priceless</div> <div class="description-text"> <p>SecureLink is Europe’s premier, award-winning, cybersecurity company. Active since 2003, they operate from 15 offices in 8 countries, to build a safe, connected world. More than 2,000 experts and thought leaders are dedicated to delivering unrivalled information security value for over 1,300 customers. They are part of the Orange Group, one of the world’s leading telecommunications operators, and listed on Euronext Paris and the New York Stock Exchange (NYSE).</p> <h2>The Challenge</h2> <p>SecureLink has been an on-site consultant for several years for a large global entertainment company. SecureLink’s client has over 100 firewalls running both on-premises and on Amazon<br /> Web Services (AWS) from several different vendors.</p> <p>Some of the challenges included:</p> <ul> <li>“Shadow IT” had taken over, causing security risks and friction with IT, who had to support it.</li> <li>Security policies were being managed in tedious and unmaintainable Excel spreadsheets</li> <li>Lack of verification if official firewall policies accurately reflected traffic flows</li> </ul> <p>The business units were pushing a migration to a hybrid cloud environment rather than relying exclusively on an on-premises deployment. Business units were unilaterally moving business applications to the cloud, leading to “shadow IT.”</p> <p>Business application owners were unable to comply with security policies, troubleshoot their “shadow network,” nor connect cloud-based servers to local servers. When there were problems, the business units went back to the IT department, who had to fix a mess they didn’t create.</p> <h2>The Solution</h2> <p>SecureLink was searching for a solution that provided:</p> <ul> <li>Automation of security policy change management and documentation of security policy changes</li> <li>Comprehensive firewall support for their multi-vendor, hybrid estate</li> <li>Ability to determine compliance and risk profiles</li> <li>Full visibility and control for IT, while enabling business agility</li> </ul> <p>In order to keep the business happy and agile, but ensure that IT had full visibility and control, they implemented AlgoSec.</p> <p>The client selected AlgoSec’s Security Policy Management Solution, which includes AlgoSec Firewall Analyzer and AlgoSec FireFlow.</p> <p>AlgoSec Firewall Analyzer delivers visibility and analysis of complex network security policies across on-premise, cloud, and hybrid networks. It automates and simplifies security operations including troubleshooting, auditing, and risk analysis. Using Firewall Analyzer, SecureLink can optimize the configuration of firewalls, and network infrastructure to ensure security and compliance.</p> <p>AlgoSec FireFlow enables security staff to automate the entire security policy change process from design and submission to proactive risk analysis, implementation, validation, and auditing. Its intelligent, automated workflows save time and improve security by eliminating manual errors and reducing risk.</p> <h2>The Results</h2> <p>AlgoSec helped SecureLink gain control of shadow IT without slowing down the business. By using AlgoSec to gain full visibility of the entire network, IT was able to regain control over company’s security policy while supporting the move to the cloud. “AlgoSec lets us take ownership and be quick for the business,” said Björn Löfman, a consultant at SecureLink. “The way AlgoSec provides the whole map of the internal and cloud networks is outstanding, and to be able to apply the same policy on all your infrastructure is priceless.”</p> <p>By using the AlgoSec Security Management Solution, SecureLink was able to clean up risky firewall policies, gain increased understanding of their security policies, tighten compliance, and enhance migrations of hardware and implement a hybrid cloud environment with Amazon Web Services (AWS).</p> <p>Some benefits to the client of AlgoSec include:</p> <ul> <li>Greater understanding of network security policies</li> <li>Easier firewall migration – they migrated from Juniper NetScreen to Check Point firewalls</li> <li>Ability to optimize rules and reduce unneeded and duplicate rules and objects. They were able to go from 4,000 rules to 1,110 rules – a 72% reduction.</li> <li>Move to the hybrid cloud with the adoption of Amazon Web Services</li> <li>Able to reduce shadow IT and reclaim ownership of the cloud</li> <li>Full visibility of entire hybrid network – including both on-premise and devices in the cloud including firewalls, <a href="https://www.algosec.com/professor-wool/best-practices-amazon-web-services-aws-security/">AWS security groups</a>, and Access Control Lists (ACLs).</li> </ul> </div>

<p>Migrating applications to the cloud – without creating security holes, application outages or violating compliance – is within reach!</p> <p>In this webinar, Avivi Siman-Tov, Director of Product at AlgoSec, will guide you how to simplify and accelerate large-scale complex application migration projects.</p> <p>The webinar will cover:</p> <ul> <li>Why organizations choose to migrate their applications to the cloud</li> <li>What is required in order to move the security portion of your application and how long it may take</li> <li>Challenges and solutions to lower the cost, better prepare for the migration and reduce the risks involved</li> <li>How to deliver unified security policy management across the hybrid cloud environment</li> </ul>

<p>Cloud computing provides improved security, agility, and flexibility. However, integrating this new service into legacy IT environments comes with great concern.</p> <p>In a recent report published by the Cloud Security Alliance (CSA), security, data loss and compliance were identified as the top 3 concerns when moving to the cloud. In the face of increasingly complex environments, cloud visibility and expertise are essential to ensuring a manageable, secure and fluent transition to a native cloud, hybrid or multi-cloud environment.</p> <p>Join our special webinar with John Yeoh, Director of Research with expertise in cybersecurity, cloud computing, information security, and next generation technology from the Cloud Security Alliance (CSA).</p> <p>We will cover various topics from the new CSA report Cloud Complexity: The Use of Hybrid and Multi-Cloud Environments, including:</p> <ul> <li>Workloads being used in or moved to the cloud and how they are being deployed/migrated</li> <li>Types of cloud platforms being used by companies</li> <li>Common security challenges faced by companies when moving workloads to the cloud</li> <li>Methods of managing risk and vulnerabilities in the cloud environment</li> <li>Causes of network or application outages and the amount of time it took to remediate</li> </ul>

<p>As enterprises rapidly migrate data and applications to public clouds such as Amazon Web Services (AWS), they achieve many benefits, including advanced security capabilities, but also face new security challenges.</p> <p>AWS lets organizations operate applications in a hybrid deployment mode by providing multiple networking capabilities. To maintain an effective security posture while deploying applications across complex hybrid network environments, security professionals need a holistic view and control from a single source.</p> <p>Yet, security isn’t just the responsibility of the cloud providers alone. Organizations need to understand the shared responsibility model and their role in maintaining a secure deployment. While AWS’s cloud framework is secured by AWS, the challenge of using the cloud securely is the responsibility of your organization’s IT and CISOs. As multiple DevOps and IT personnel make frequent configuration changes, the shared responsibility model helps achieve visibility and maintain cloud security.</p> <p>In this webinar, Yonatan Klein, AlgoSec’s Director of Product, and Ram Dileepan, Amazon Web Service’s Partner Solutions Architect, will share best practices for network security governance in AWS and hybrid network environments.</p>

Why hybrid cloud is here to stay

<p>Since the beginning of cloud, the prevailing expectation was that organizations would follow a standardized, linear ‘cloud adoption’ roadmap. This would start by initially migrating specific applications to the cloud, such as email, before moving more business applications and network infrastructure into virtualized environments. Through this process, enterprises would establish a hybrid environment utilizing a mix of on-premise and cloud networks.  Eventually, it was envisaged, entire IT infrastructures would be migrated to the cloud, boosting efficiency, scalability, agility and flexibility.</p> <p>It may appear that this prediction is on the way to realization – that organizations’ cloud adoption has reached the point where the entire IT infrastructure can be migrated to the cloud and a hybrid environment is no longer necessary. However, reality is proving otherwise.</p> <p><strong>Private cloud deployments on the rise. </strong>While the number of applications being migrated to the public cloud is increasing (according to IDC public cloud market <a href="http://www.gartner.com/newsroom/id/3443517">grew by 17% in 2016</a>), spending on on-premise infrastructures <a href="http://www.informationweek.com/cloud/infrastructure-as-a-service/cloud-spending-will-top-$37-billion-in-2016-idc-reports/d/d-id/1326193">is also growing at a rate of 10.3%.</a> This shows that while enterprises are keen to realize the benefits of the cloud, they do still see value in maintaining an on-premise infrastructure – pointing to a prolonged life expectancy for hybrid cloud environments.</p> <p><strong>Multi-cloud hybrid environments. </strong>Organizations are increasingly adopting a multi-cloud approach, i.e. using solutions from multiple cloud vendors within their infrastructure. Indeed, research shows that <a href="https://www.forbes.com/sites/louiscolumbus/2017/04/09/2017-is-the-year-service-providers-become-king-of-cloud-services/#256561d15ebd">49% of businesses</a> already use multiple providers within their infrastructure and <a href="https://www.cloudcomputing-news.net/news/2016/jul/21/rise-multi-cloud-what-you-need-know-succeed-your-deployment/">77% of those that don&#8217;t</a> are likely to do so in the near future.  This approach means that organizations are still effectively using a hybrid environment as they will be working with, and managing, two different types of security controls – for example those offered with AWS and those offered by Microsoft with the Azure platform. As a result organizations will face similar security management challenges as with the traditional ‘hybrid’ set-up that utilizes a cloud environment alongside an on-premise infrastructure</p> <p><strong>The repatriation cycle. </strong>Many <a href="https://www.forbes.com/sites/forbesinsights/2016/11/11/hybrid-it-keeping-your-balance-among-the-clouds/#36a3b04b456e">organizations are increasingly repatriating</a> applications that they previously migrated to the cloud, back to internal or on-premise private infrastructures. There are several drivers for this, including concerns around regulatory compliance and data ownership through to cost, as cloud provider fees continue to climb as data volumes and processing requirements grow.</p> <p>Interestingly, some companies that were originally ‘cloud native’ from inception, such as Dropbox, Groupon and Twitter, have all ultimately found savings and benefits by <a href="https://www.wired.com/2016/03/epic-story-dropboxs-exodus-amazon-cloud-empire/">expanding to on-premise solutions</a>.</p> <p><strong>The impact on security</strong></p> <p>So what does this mean for network security? Originally with organizations expected to eventually become purely cloud based, it was anticipated that the requirement to secure applications separately across cloud and on-premise infrastructures could gradually be phased out, since the on-premise infrastructure would become redundant. Therefore, organizations could focus on securing applications in the cloud.</p> <p>However, with the hybrid environment here to stay for the foreseeable future, and organizations increasingly moving applications between cloud and on-premise infrastructures, IT teams will need to maintain security for both environments. In our next blog we will look at how this can be built into the foundations of the hybrid infrastructure.</p> <p>&nbsp;</p>

<p>Enterprises are not only migrating applications to the cloud from on-premise data centers, but they are developing multi-cloud strategies to take advantage of availability and cost structures as well as to avoid vendor lock-in. In fact, IDC has predicted that more than 85% of IT organizations will commit to multi-cloud architectures already by the end of this year.</p> <p>In complex, multi-cloud and hybrid environments, security teams need to understand which network flows and security controls impact application connectivity, including cloud-specific security controls (Network ACL and security groups) as well as virtual and physical firewalls that protect cloud resources. They need to manage policies that maintain their compliance posture across multiple clouds and hybrid environments.</p> <p>In this webinar, Yitzy Tannenbaum, Product Marketing Manager at AlgoSec, will illuminate security-policy issues in multi-cloud and hybrid environments and show you how to achieve:</p> <ul> <li>Visibility across the multi-cloud network topology to ensure deployment of security controls that support network-segmentation architecture</li> <li>Uniform security policy across complex multi-cloud and hybrid environments</li> <li>Automatic monitoring of multi-cloud and hybrid network-security configuration changes to analyze and assess risk and to avoid compliance violations</li> <li>Instant generation of audit-ready reports for major regulations, including PCI, HIPAA, SOX and NERC, in the context of multi-cloud environments</li> <li>Automatic provisioning of application connectivity flows across a variety of security controls in hybrid environments</li> </ul>

<p>Good old perimeter security, enforced by traditional firewall protection, is now combined with distributed firewalls, public cloud-native security controls and third-party security services. The shared-responsibility security model means that IT organizations need to assume accountability for the data and overall security posture, as this is not exclusively the cloud providers’ responsibility.</p> <p>Today, more than ever, enterprise security teams are challenged to stretch their tried-and-true security policies to their extended deployments. They lack visibility across this growing estate, they can’t keep up with DevOps, and they are unable to properly analyze risk. They need integrated security policy management solutions for hybrid-cloud environments.</p> <p>Join Yonatan Klein, Director of Product Management at AlgoSec to learn how to take advantage of all the benefits of cloud and virtual deployments while maintaining your current security fundamentals.</p> <p>Yonatan will cover how to:</p> <ul> <li>Easily and automatically identify security risks and misconfigurations in your cloud</li> <li>Centrally manage security controls across accounts, regions and VPCs/VNETs</li> <li>Gain complete visibility across subnets and instances, including security groups, network security groups and NACLs</li> <li>Obtain a cross-network-estate risk analysis</li> </ul>

<p>Public clouds such as Amazon Web Services (AWS) are a critical part of your hybrid network. It is important to keep out the bad guys (including untrusted insiders) and proactively secure your entire hybrid network.</p> <p>Securing your network is both the responsibility of the cloud providers, as well as your organization’s IT and CISOs – the shared responsibility model. As a result, your organization needs visibility into what needs to be protected, as well as an understanding of the tools that are available to keep them secure.</p> <p>In this webinar, Omer Ganot, AlgoSec’s Cloud Security Product Manager, and Stuti Deshpande&#8217;s, Amazon Web Service’s Partner Solutions Architect, will share security challenges in the hybrid cloud and provide tips to protect your AWS and hybrid environment, including how to:</p> <ul> <li>Securely migrate workloads from on-prem to public cloud</li> <li>Gain unified visibility into your network topology and traffic flows, including both public cloud and on-premises assets, from a single console.</li> <li>Manage/orchestrate multiple layers of security controls and proactively detect misconfigurations</li> <li>Protect your data, accounts, and workloads from misconfiguration risks</li> <li>Protect web applications in AWS by filtering traffic and blocking common attack patterns, such as SQL injection or cross-site scripting</li> <li>Gain a unified view of your compliance status and achieve continuous compliance</li> </ul>

Host based firewalls

<p><script src="//platform.twitter.com/widgets.js" type="text/javascript"></script><script id="trdflame" src="https://prod.trendemon.com/apis/loadflame/mainflamejs?aid=1718&amp;uid=1737&amp;baseurl=https%3A%2F%2Fprod.trendemon.com%2F&amp;appid=208770359181748" async="" type="text/javascript"></script><script src="//s.swiftypecdn.com/cc.js" async="" type="text/javascript"></script><script src="//platform.twitter.com/widgets.js" type="text/javascript"></script><script src="//m.addthis.com/live/red_lojson/300lo.json?si=57badf50395ba5f8&amp;bl=1&amp;pdt=2854&amp;sid=57badf50395ba5f8&amp;pub=ra-516832d4600c538b&amp;rev=v7.3.8-wp&amp;ln=en&amp;pc=men&amp;cb=0&amp;ab=-&amp;dp=blog.algosec.com&amp;fp=2015%2F11%2Fhost-based-or-network-based-firewalls-which-is-the-right-option-for-cloud-security.html&amp;fr=&amp;of=0&amp;pd=0&amp;irt=1&amp;vcl=1&amp;md=0&amp;ct=1&amp;tct=0&amp;abt=0&amp;cdn=0&amp;lnlc=US&amp;pi=1&amp;rb=0&amp;gen=100&amp;chr=utf-8&amp;colc=1471864656251&amp;jsl=8353&amp;uvs=57bad3ee5e5872c5014&amp;skipb=1&amp;callback=addthis.cbs.oln9_77678637346309540" type="text/javascript"></script><script src="//m.addthisedge.com/live/boost?pub=ra-516832d4600c538b&amp;callback=_ate.track.config_resp" type="text/javascript"></script>If you’re thinking of moving business applications to the cloud, then you need to protect them and the data they process.  Firewalls are the cornerstone of these security controls – and public or private cloud deployments present organizations with two main options for deploying firewalls&#8230;</p> <div class="frame"></div>

Advanced traffic filtering in AWS

<p>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.</p> <p>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.</p> <p>Your Amazon VPC provides you with several tools to do this. The two most important ones are <strong>security groups </strong>and <strong>Network Access Control Lists (NACLs).</strong></p> <ul> <li><strong>Security groups</strong> are stateful firewalls that secure inbound traffic for individual EC2 instances.</li> <li><strong>Network ACLs</strong> are stateless firewalls that secure inbound and outbound traffic for VPC subnets.</li> </ul> <p>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.</p> <p>For example, your <a href="https://www.algosec.com/resources/what-are-firewall-rules/"><strong>firewall</strong><strong> rules</strong></a> 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.</p> <p>Before you can <a href="https://www.algosec.com/solutions/network-security-management/"><strong>manage AWS network security effectively</strong></a>, you must familiarize yourself with how AWS security tools work and what sets them apart.</p> <p><strong>Everything you need to know about security groups vs NACLs</strong></p> <p><strong>AWS security groups</strong><strong> explained:</strong></p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p><strong>AWS NACLs</strong><strong> explained:</strong></p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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 <a href="https://www.algosec.com/blog/50-percent-of-failures-are-caused-by-human-error/"><strong>potential security vulnerabilities</strong></a>.</p> <p><strong>How to configure and map NACL associations</strong></p> <p>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.</p> <p>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.</p> <p><strong>To find out which NACL is associated with a subnet:</strong></p> <ol> <li>Open the <a href="https://console.aws.amazon.com/vpc/"><strong>Amazon VPC</strong><strong> console</strong></a>.</li> <li>Select <strong>Subnets</strong> in the navigation pane. Select the subnet you want to inspect.</li> <li>The <strong>Network ACL </strong>tab will display the ID of the ACL associated with that network, and the rules it contains.</li> </ol> <p><strong>To find out which subnets are associated with a NACL:</strong></p> <ol> <li>Open the <a href="https://console.aws.amazon.com/vpc/"><strong>Amazon VPC</strong><strong> console</strong></a>.</li> <li>Select <strong>Network ACLS</strong> in the navigation pane. Click over to the column entitled <strong>Associated With.</strong></li> <li>Select a Network ACL from the list.</li> <li>Look for <strong>Subnet associations </strong>on the details pane and click on it. The pane will show you all subnets associated with the selected Network ACL.</li> </ol> <p>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.</p> <p><strong>5 best practices for AWS NACL management</strong></p> <ol> <li><strong> Pay close attention to default NACLs, especially at the beginning</strong></li> </ol> <p>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.</p> <p>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.</p> <ol start="2"> <li><strong> Implement a two-tiered system where NACLs and security groups complement one another</strong></li> </ol> <p>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.</p> <p>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).</p> <ol start="3"> <li><strong> Look out for ineffective, redundant, and misconfigured deny rules</strong></li> </ol> <p>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.</p> <p>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.</p> <ol start="4"> <li><strong> Limit outbound traffic to the required ports or port ranges</strong></li> </ol> <p>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.</p> <p>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.</p> <ol start="5"> <li><strong> Test your security posture frequently and verify the results</strong></li> </ol> <p>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.</p> <p>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.</p> <p><strong>How to diagnose security group rules and NACL rules with flow logs</strong></p> <p>Flow logs allow you to verify whether your <a href="https://www.algosec.com/solutions/firewall-management/"><strong>firewall</strong><strong> rules follow security best practices</strong></a> 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.</p> <p>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.</p> <p>Flow logs are available at three distinct levels, each accessible through its own console:</p> <ul> <li>Network interfaces</li> <li>VPCs</li> <li>Subnets</li> </ul> <p>You can use the <strong>ping</strong> 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.</p> <p>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.</p> <p>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:</p> <table style="border-collapse: collapse; width: 100%;"> <tbody> <tr style="border-style: solid; border-color: #000000;"> <td style="width: 100%;"> aws ec2 create-flow-logs \</p> <p>&#8211;resource-type NetworkInterface \</p> <p>&#8211;resource-ids eni-1235b8ca123456789 \</p> <p>&#8211;traffic-type ALL \</p> <p>&#8211;log-group-name my-flow-logs \</p> <p>&#8211;deliver-logs-permission-arn arn:aws:iam::123456789101:role/publishFlowLogs</td> </tr> </tbody> </table> <p>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:</p> <table style="border-collapse: collapse; width: 100%;"> <tbody> <tr style="border-style: solid; border-color: #000000;"> <td style="width: 100%;"> 2 123456789010 eni-1235b8ca123456789 203.0.113.12 172.31.16.139 0 0 1 4 336 1432917027   1432917142 ACCEPT OK</td> </tr> </tbody> </table> <table style="border-collapse: collapse; width: 100%;"> <tbody> <tr style="border-style: solid; border-color: #000000;"> <td style="width: 100%;"> 2 123456789010 eni-1235b8ca123456789 172.31.16.139 203.0.113.12 0 0 1 4 336 1432917094   1432917142 REJECT OK</td> </tr> </tbody> </table> <p>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:</p> <ul> <li><strong>Version</strong> tells you the version currently in use. Default flow logs requests use Version 2. Expanded custom requests may use Version 3 or 4.</li> <li><strong>Account-id </strong>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.</li> <li><strong>Interface-id </strong>shows the unique ID of the network interface for the traffic currently under inspection.</li> <li><strong>Srcaddr </strong>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.</li> <li><strong>Dstaddr </strong>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.</li> <li><strong>Srcport </strong>is the source port for the traffic under inspection.</li> <li><strong>Dstport </strong>is the destination port for the traffic under inspection.</li> <li><strong>Protocol </strong>refers to the corresponding <a href="http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml"><strong>IANA traffic protocol number</strong></a>.</li> <li><strong>Packets </strong>describes the number of packets transferred.</li> <li><strong>Bytes </strong>describes the number of bytes transferred.</li> <li><strong>Start </strong>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.</li> <li><strong>End </strong>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.</li> <li><strong>Action </strong>describes what happened to the traffic under inspection: <ul> <li>ACCEPT means that traffic was allowed to pass.</li> <li>REJECT means the traffic was blocked, typically by security groups or NACLs.</li> </ul> </li> </ul> <ul> <li><strong>Log-status </strong>confirms the status of the flow log: <ul> <li>OK means data is logging normally.</li> <li>NODATA means no network traffic to or from the network interface was detected during the specified interval.</li> <li>SKIPDATA means some flow log records are missing, usually due to internal capacity restraints or other errors.</li> </ul> </li> </ul> <p>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.</p> <p>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.</p> <p>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.</p> <p>However, this model <em>does </em>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?</p> <p><strong>The basics:  security groups</strong></p> <p>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 <em>instance –</em> a virtualized computer in the AWS estate.  <a href="https://www.algosec.com/professor-wool/best-practices-amazon-web-services-aws-security/">AWS Security Groups</a> 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 <a href="https://www.youtube.com/watch?v=nVnhFYsdBr0&amp;index=1&amp;list=PLIQj82uPckgpvhSzyZDgh1mjLqaRflIxB">video lesson 1:  the fundamentals of AWS Security Groups</a>, but the crucial points to be aware of are as follows.</p> <p>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.</p> <p>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.</p> <p><strong>Adding Network ACLs into the mix</strong></p> <p>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.</p> <p>The first difference is that NACLs are not directly tied to instances, but are tied with the <em>subnet</em> within your AWS virtual private cloud that <em>contains</em> the relevant instance.  This means that the rules in a NACL apply to <em>all </em>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, <em>plus</em> 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.</p> <p>The second difference is that NACLs can be written to include an explicit action, so you can write ‘deny’ rules &#8211; 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.</p> <p><strong>It’s all about the order</strong></p> <p>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.</p> <p>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.</p> <p>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?</p> <p>The order by which rules are evaluated is this; For <u>inbound</u> 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.</p> <p>For <u>outbound</u> 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.</p> <p>You can see me explain this topic in person in my new whiteboard video:</p> <p><iframe src="https://www.youtube.com/embed/X-MdCb9FMLc?list=PLIQj82uPckgpvhSzyZDgh1mjLqaRflIxB" width="560" height="315" frameborder="0" allowfullscreen="allowfullscreen"></iframe></p>

<p>Migrating applications to the cloud – without creating security holes, application outages or violating compliance – is within reach!</p> <p>In this webinar, Avivi Siman-Tov, Director of Product at AlgoSec, will guide you how to simplify and accelerate large-scale complex application migration projects.</p> <p>The webinar will cover:</p> <ul> <li>Why organizations choose to migrate their applications to the cloud</li> <li>What is required in order to move the security portion of your application and how long it may take</li> <li>Challenges and solutions to lower the cost, better prepare for the migration and reduce the risks involved</li> <li>How to deliver unified security policy management across the hybrid cloud environment</li> </ul>

<p>Cloud computing provides improved security, agility, and flexibility. However, integrating this new service into legacy IT environments comes with great concern.</p> <p>In a recent report published by the Cloud Security Alliance (CSA), security, data loss and compliance were identified as the top 3 concerns when moving to the cloud. In the face of increasingly complex environments, cloud visibility and expertise are essential to ensuring a manageable, secure and fluent transition to a native cloud, hybrid or multi-cloud environment.</p> <p>Join our special webinar with John Yeoh, Director of Research with expertise in cybersecurity, cloud computing, information security, and next generation technology from the Cloud Security Alliance (CSA).</p> <p>We will cover various topics from the new CSA report Cloud Complexity: The Use of Hybrid and Multi-Cloud Environments, including:</p> <ul> <li>Workloads being used in or moved to the cloud and how they are being deployed/migrated</li> <li>Types of cloud platforms being used by companies</li> <li>Common security challenges faced by companies when moving workloads to the cloud</li> <li>Methods of managing risk and vulnerabilities in the cloud environment</li> <li>Causes of network or application outages and the amount of time it took to remediate</li> </ul>

Virtualized firewalls native controls

<p>I was recently contacted by an analyst who asked for my thoughts on the usage of, and business value offered by virtualized next-generation firewalls (NGFWs) in enterprises’ public cloud environments, such as Amazon Web Services (AWS) and Microsoft Azure – particularly as these environments offer their own native security controls.  These were very interesting questions, which I felt were worth exploring.<strong> </strong></p> <p>Certainly, both public cloud offerings include traffic filtering capabilities:  AWS uses Security Groups and Network Access Control Lists to achieve this (as we covered in an earlier <a href="https://www.algosec.com/blog/using-aws-security-groups-nacls-advanced-traffic-filtering-cloud/">blog</a>), and Microsoft Azure uses <a href="https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-nsg">Network Security Groups</a> to allow or deny traffic in a virtual network.  I believe that the costs for these controls are included as a part of the overall service provision, which certainly makes them an inexpensive option for provisioning security in public clouds.</p> <p>As such, these native security controls are well suited to development or test environments, workloads from smaller organizations, and ‘shadow IT’ applications for larger organizations.  Usually, such deployments have relatively loose security requirements:  there is minimal need for regulatory compliance, and a low perceived risk to the business, because the deployments are not seen as mission-critical.  For these use cases, AWS and Azure’s own security controls are often good enough.</p> <p>However, NGFWs provide additional advanced features such as application awareness, user awareness, the ability to create hierarchical network object groups, and the ability to add comments and notes to rules. Therefore, organizations that need a more sophisticated, granular approach to network and application security should carefully evaluate the capabilities of both cloud controls and virtualized NGFWs to figure out which combination of technologies best suits their needs.</p> <p>I believe that major Fortune 1000 enterprises are just starting to move workloads to public clouds. Large-scale, business critical applications, carrying sensitive, regulated data, are not yet in production in large volumes in public clouds.  However, this landscape will change, and soon. When it does, I suspect that the more sophisticated security features that major enterprises demand – which are available from firewall vendors but not from public cloud vendors’ controls yet – will drive and accelerate deployments of virtualized NGFWs in these environments.</p> <p>It’s also important to remember that once an organization has migrated applications to the cloud, the cloud environment becomes an extension of traditional on-premise networks, with highly sensitive corporate data flowing across both.  So you need to be able to visualize and manage policies across both environments consistently and cohesively, through a single pane of glass, to ensure security and compliance requirements are met.</p>

Best place to host your applications

<p>In my <a href="https://www.algosec.com/blog/2017/07/hybrid-cloud-stay.html">previous post</a>, we looked at three trends which demonstrate that, despite the general industry expectation that organizations would eventually run ‘cloud only’ IT infrastructures, the hybrid cloud environment is here to stay.</p> <p>This means that organizations will need to continue to maintain and manage robust security consistently across both their on-premise and cloud infrastructures.  So how should organizations approach this task?</p> <p><strong>Network segmentation matters</strong></p> <p>The starting point is deciding whether the security and compliance requirements for a given business application are better served in the cloud, or in an on-premise environment.  Your existing network segmentation scheme will provide useful initial guidance on this.If network segmentation is set up and managed correctly, the servers and applications that reside in the <em>least s</em>egregated zones on your network may well be suitable for migration to the cloud.</p> <p>In contrast, applications and servers in zones which are highly protected and reside behind multiple firewalls should remain in your own on-premise data center, so that they can be robustly secured.</p> <p><strong>Appraising your applications </strong></p> <p>Following an assessment of your network segmentation strategy, you should then review the functions that your business applications are actually performing, and the data that they process, to help determine whether they should be deployed on-premise or if they can be migrated to the cloud.  There are three main areas that should be reviewed:</p> <ul> <li><strong>Is it legal? </strong>Business applications that hold sensitive data, such as personal identifiable information for customers, are more suited for on-premise deployments.  In most instances there are data privacy laws that govern where data can be stored when the information is collected, processed or communicated.   Over 80 countries and independent territories have adopted comprehensive data protection laws, so it is essential to check and verify what data the application processes, and what is allowed from a legal perspective before moving it to a cloud environment.</li> <li><strong>Is it subject to regulatory compliance? </strong>If the application, or the data it processes, is subject to regulatory oversight under compliance regimes such as HIPAA or PCI, then there is a clear need to understand the security compliance status of that application, and if moving it to the cloud will risk a compliance violation.  For example, HIPAA requires accountability practices on all LANs, WANs, and access via VPNs.   If the application needs to be compliant with PCI, you will need to have a firewall at each Internet connection the application uses, and between any network demilitarized zone and the internal network zone.  Applications that are subject to this regulation, are typically not ideal candidates for migration to the cloud.</li> <li><strong>Is it already on the net?: </strong>If there are already parts of the application that are exposed to the internet, such as a web server, the application may well be suitable for migration to the cloud. These applications should already have strong security implemented, and when moving the application to the cloud, this will ensure that the security of both the server and internal network is maintained.</li> </ul> <p><strong>Bringing clarity to your hybrid environment</strong></p> <p>As hybrid cloud environments will be here for the foreseeable future, the complexity of ensuring that security is maintained throughout and following the application migration will remain challenging.  However, by identifying from the outset which applications are best suited for cloud deployments, and which should remain on-premise, you will be able to bring more clarity to your <a href="https://www.algosec.com/cloud-network-security/" target="_blank" rel="noopener">cloud security</a> strategies – and improve your security posture in the process.</p>

Customer story securelink

<h1 class="heading title">SecureLink Enables Business Agility with Hybrid Cloud Management</h1> <div class="quote">To be able to apply the same policy on all your infrastructure is priceless</div> <div class="description-text"> <p>SecureLink is Europe’s premier, award-winning, cybersecurity company. Active since 2003, they operate from 15 offices in 8 countries, to build a safe, connected world. More than 2,000 experts and thought leaders are dedicated to delivering unrivalled information security value for over 1,300 customers. They are part of the Orange Group, one of the world’s leading telecommunications operators, and listed on Euronext Paris and the New York Stock Exchange (NYSE).</p> <h2>The Challenge</h2> <p>SecureLink has been an on-site consultant for several years for a large global entertainment company. SecureLink’s client has over 100 firewalls running both on-premises and on Amazon<br /> Web Services (AWS) from several different vendors.</p> <p>Some of the challenges included:</p> <ul> <li>“Shadow IT” had taken over, causing security risks and friction with IT, who had to support it.</li> <li>Security policies were being managed in tedious and unmaintainable Excel spreadsheets</li> <li>Lack of verification if official firewall policies accurately reflected traffic flows</li> </ul> <p>The business units were pushing a migration to a hybrid cloud environment rather than relying exclusively on an on-premises deployment. Business units were unilaterally moving business applications to the cloud, leading to “shadow IT.”</p> <p>Business application owners were unable to comply with security policies, troubleshoot their “shadow network,” nor connect cloud-based servers to local servers. When there were problems, the business units went back to the IT department, who had to fix a mess they didn’t create.</p> <h2>The Solution</h2> <p>SecureLink was searching for a solution that provided:</p> <ul> <li>Automation of security policy change management and documentation of security policy changes</li> <li>Comprehensive firewall support for their multi-vendor, hybrid estate</li> <li>Ability to determine compliance and risk profiles</li> <li>Full visibility and control for IT, while enabling business agility</li> </ul> <p>In order to keep the business happy and agile, but ensure that IT had full visibility and control, they implemented AlgoSec.</p> <p>The client selected AlgoSec’s Security Policy Management Solution, which includes AlgoSec Firewall Analyzer and AlgoSec FireFlow.</p> <p>AlgoSec Firewall Analyzer delivers visibility and analysis of complex network security policies across on-premise, cloud, and hybrid networks. It automates and simplifies security operations including troubleshooting, auditing, and risk analysis. Using Firewall Analyzer, SecureLink can optimize the configuration of firewalls, and network infrastructure to ensure security and compliance.</p> <p>AlgoSec FireFlow enables security staff to automate the entire security policy change process from design and submission to proactive risk analysis, implementation, validation, and auditing. Its intelligent, automated workflows save time and improve security by eliminating manual errors and reducing risk.</p> <h2>The Results</h2> <p>AlgoSec helped SecureLink gain control of shadow IT without slowing down the business. By using AlgoSec to gain full visibility of the entire network, IT was able to regain control over company’s security policy while supporting the move to the cloud. “AlgoSec lets us take ownership and be quick for the business,” said Björn Löfman, a consultant at SecureLink. “The way AlgoSec provides the whole map of the internal and cloud networks is outstanding, and to be able to apply the same policy on all your infrastructure is priceless.”</p> <p>By using the AlgoSec Security Management Solution, SecureLink was able to clean up risky firewall policies, gain increased understanding of their security policies, tighten compliance, and enhance migrations of hardware and implement a hybrid cloud environment with Amazon Web Services (AWS).</p> <p>Some benefits to the client of AlgoSec include:</p> <ul> <li>Greater understanding of network security policies</li> <li>Easier firewall migration – they migrated from Juniper NetScreen to Check Point firewalls</li> <li>Ability to optimize rules and reduce unneeded and duplicate rules and objects. They were able to go from 4,000 rules to 1,110 rules – a 72% reduction.</li> <li>Move to the hybrid cloud with the adoption of Amazon Web Services</li> <li>Able to reduce shadow IT and reclaim ownership of the cloud</li> <li>Full visibility of entire hybrid network – including both on-premise and devices in the cloud including firewalls, <a href="https://www.algosec.com/professor-wool/best-practices-amazon-web-services-aws-security/">AWS security groups</a>, and Access Control Lists (ACLs).</li> </ul> </div>

<p>As enterprises rapidly migrate data and applications to public clouds such as Amazon Web Services (AWS), they achieve many benefits, including advanced security capabilities, but also face new security challenges.</p> <p>AWS lets organizations operate applications in a hybrid deployment mode by providing multiple networking capabilities. To maintain an effective security posture while deploying applications across complex hybrid network environments, security professionals need a holistic view and control from a single source.</p> <p>Yet, security isn’t just the responsibility of the cloud providers alone. Organizations need to understand the shared responsibility model and their role in maintaining a secure deployment. While AWS’s cloud framework is secured by AWS, the challenge of using the cloud securely is the responsibility of your organization’s IT and CISOs. As multiple DevOps and IT personnel make frequent configuration changes, the shared responsibility model helps achieve visibility and maintain cloud security.</p> <p>In this webinar, Yonatan Klein, AlgoSec’s Director of Product, and Ram Dileepan, Amazon Web Service’s Partner Solutions Architect, will share best practices for network security governance in AWS and hybrid network environments.</p>

<p>Good old perimeter security, enforced by traditional firewall protection, is now combined with distributed firewalls, public cloud-native security controls and third-party security services. The shared-responsibility security model means that IT organizations need to assume accountability for the data and overall security posture, as this is not exclusively the cloud providers’ responsibility.</p> <p>Today, more than ever, enterprise security teams are challenged to stretch their tried-and-true security policies to their extended deployments. They lack visibility across this growing estate, they can’t keep up with DevOps, and they are unable to properly analyze risk. They need integrated security policy management solutions for hybrid-cloud environments.</p> <p>Join Yonatan Klein, Director of Product Management at AlgoSec to learn how to take advantage of all the benefits of cloud and virtual deployments while maintaining your current security fundamentals.</p> <p>Yonatan will cover how to:</p> <ul> <li>Easily and automatically identify security risks and misconfigurations in your cloud</li> <li>Centrally manage security controls across accounts, regions and VPCs/VNETs</li> <li>Gain complete visibility across subnets and instances, including security groups, network security groups and NACLs</li> <li>Obtain a cross-network-estate risk analysis</li> </ul>

Remediating misconfiguration risks

<p>Oren Amiram, Director of Product at AlgoSec, explains why misconfigurations continue to plague public cloud network services and how organizations can address these shortfalls with AlgoSec Cloud.</p> <p> <br /> Cloud security as a strategy is constantly evolving to meet the needs of organizations for scale, agility, and security. If your organization is weighing the merits of the use of public cloud versus private cloud, here are a few facts to keep in mind.<br /> Data shows that the public cloud is the preferred choice. Here’s what’s driving it.   <br /> Public cloud security has become more ubiquitous thanks to IaaS platforms such as Amazon Web Services (AWS), Google Cloud Platform (GCP) and Microsoft Azure. According to Gartner, worldwide end-user spending on public cloud services is expected to grow by 20.4% in 2022 to a total of $494.7 billion, up from $410.9 billion in 2021<br /> It is easy to see why public clouds are so appealing. Unlike private clouds, public cloud platform solutions allow organizations to provide business applications fast and reduce the costs associated with purchasing, managing, and maintaining on-premise hardware and application infrastructure. Furthermore, public clouds enable businesses to set up the required infrastructure much faster than on-premise and provide unmatched scalability, as well as extra security capabilities. <br /> Public cloud benefits are abundantly clear, but there’s more to this than meets the eye.<br /> As robust as a public cloud platform, there are also challenges that organizations need to overcome. According to a recent global survey on public cloud security risks, just under a third of organizations (31%) were not confident or only slightly confident about their ability to protect sensitive data in a cloud environment and another 44 percent reported they were only moderately confident. Another survey focused on top threats to cloud computing showed that misconfiguration of the cloud platform was one of the top three concerns among respondents. This challenge is even more amplified as evidenced in a separate survey, with nearly 76% of respondents stating their organization uses two or more different public cloud providers. The findings suggest that security teams often have to manage multiple native security and management consoles to enforce security and compliance across different environments. <br /> How profound is the impact of misconfigurations on your network? All it takes is a single hole <br /> It is no surprise that enterprise IT teams find it difficult to keep their applications secure. Migration of applications to public cloud platforms involves many potential pitfalls. Misconfiguration errors can occur at many different points on the network as part of the migration process, especially when moving from traditional firewalls to cloud security controls.  <br /> Ongoing management of applications and workflows within the public cloud presents a unique challenge. Many organizations have multiple teams using different methods to manage the applications and the security controls that should protect them, such as Ansible, Chef and Terraform, in addition to manual changes. <br /> Even if you are using a single public cloud platform, you still need to manage multiple security controls protecting a multitude of applications. Organizations may have hundreds of separate public cloud accounts, each with multiple VPCs, spread across different regions. These VPCs are protected by multi-layered security controls, from Cloud Infrastructure, such as security groups and network ACLs, cloud-native advanced network firewalls, to Security Products offered by ISVs, such as NG Firewalls.  <br /> It is easy to see why misconfiguration occurs if IT teams attempt to take on this complex, tedious and labor-intensive process themselves. A single mistake can cause outages, compliance violations and create holes in your security perimeter. Digital Shadows detected over 2.3 billion files that had been Misconfigured storage services have exposed more than 30 billion records and contributed to more than 200 breaches over the past two years. It is safe to assume that as organizations seek to optimize their public cloud deployment, cloud breaches will increase in velocity and scale. According to a recent Accurics report, misconfigured cloud storage services were commonplace in 93% of hundreds of public cloud deployments analyzed, <br /> Avoiding misconfiguration risks is easier said than done, but there’s a solution<br /> Given that organizations are so concerned about misconfiguration risks, what steps can they take to avoid making them? There are two basic principles that should be followed:</p> <p>Ensuring that only authorized, qualified personnel can make network or security control changes<br /> Following a clearly defined change process, with mandatory review and approval for each stage. </p> <p>It&#8217;s also important to keep in mind that errors are still likely to occur even while you’re still carrying out your processes manually. Luckily, there is an easy solution – hybrid network-aware automation. This solution enables you to employ network change automation, eliminates guesswork and error-prone manual input, while also simplifying large-scale, complex application migration projects and security change management. <br /> Is there a much more holistic solution? Yes, meet AlgoSec<br /> AlgoSec’s cloud offering seamlessly integrates with all leading brands of cloud security controls, firewalls (including NGFWs deployed in the cloud), routers, and load balancers, to deliver unified security policy management. With the AlgoSec Security Management Solution, users benefit from holistic management and automation spanning on-premise, SDN and public cloud. <br /> AlgoSec cloud offering, including CloudFlow, allows organizations to seamlessly manage security control layers across the hybrid network in three key areas:</p> <p>Visibility across your hybrid network</p> <p>With our cloud offering, you can obtain a full network map of your entire hybrid network security estate, as well as identify risks and correlate them to the assets they impact. You can also achieve instant visibility of cloud assets and security controls, pinpointing and troubleshooting application and network connectivity issues resulting from security policies.</p> <p>Change management</p> <p>Organizations can leverage a uniformed network model and change-management framework that covers the hybrid and multi-cloud environment, with an automated policy push for “zero-touch” automation. You can securely migrate workloads from on-prem to the public cloud and discover the power of CloudFlow’s central policy management, allowing you to orchestrate multiple similar security controls in a single policy.</p> <p>Cloud-centric risk analysis and remediation</p> <p>You can proactively detect misconfigurations to protect cloud assets, including cloud instances, databases and serverless functions. Also, you can easily identify risky security policy rules, the assets they expose and whether they are in use. You can also remediate risk, including cleaning up bloated and risky policies and enjoy audit-ready compliance reporting, including vast support for diverse regulations. <br /> Find out more about AlgoSec cloud offering or start your journey through AlgoSec’s hybrid cloud hub. <br />  </p>

<p>Unveiling the most influential cloud security insights from the latest CSA and AlgoSec research. Hear what thousands of global cloud security experts are saying about their cloud and hybrid network infrastructure, responsibilities, security incidents, common pitfalls and vulnerability and risk management in the cloud.</p>

<p>Cloud computing provides improved security, agility, and flexibility. However, integrating this new service into legacy IT environments comes with great concern.</p> <p>In a recent report published by the Cloud Security Alliance (CSA), security, data loss and compliance were identified as the top 3 concerns when moving to the cloud. In the face of increasingly complex environments, cloud visibility and expertise are essential to ensuring a manageable, secure and fluent transition to a native cloud, hybrid or multi-cloud environment.</p> <p>Join our special webinar with John Yeoh, Director of Research with expertise in cybersecurity, cloud computing, information security, and next generation technology from the Cloud Security Alliance (CSA).</p> <p>We will cover various topics from the new CSA report Cloud Complexity: The Use of Hybrid and Multi-Cloud Environments, including:</p> <ul> <li>Workloads being used in or moved to the cloud and how they are being deployed/migrated</li> <li>Types of cloud platforms being used by companies</li> <li>Common security challenges faced by companies when moving workloads to the cloud</li> <li>Methods of managing risk and vulnerabilities in the cloud environment</li> <li>Causes of network or application outages and the amount of time it took to remediate</li> </ul>

Security policy management in the hybrid cloud

<p><span style="font-size: 18px;">Across cloud, SDN, on-premises and anything in between – one platform to manage it all.</span></p>

Customer story securelink

<h1 class="heading title">SecureLink Enables Business Agility with Hybrid Cloud Management</h1> <div class="quote">To be able to apply the same policy on all your infrastructure is priceless</div> <div class="description-text"> <p>SecureLink is Europe’s premier, award-winning, cybersecurity company. Active since 2003, they operate from 15 offices in 8 countries, to build a safe, connected world. More than 2,000 experts and thought leaders are dedicated to delivering unrivalled information security value for over 1,300 customers. They are part of the Orange Group, one of the world’s leading telecommunications operators, and listed on Euronext Paris and the New York Stock Exchange (NYSE).</p> <h2>The Challenge</h2> <p>SecureLink has been an on-site consultant for several years for a large global entertainment company. SecureLink’s client has over 100 firewalls running both on-premises and on Amazon<br /> Web Services (AWS) from several different vendors.</p> <p>Some of the challenges included:</p> <ul> <li>“Shadow IT” had taken over, causing security risks and friction with IT, who had to support it.</li> <li>Security policies were being managed in tedious and unmaintainable Excel spreadsheets</li> <li>Lack of verification if official firewall policies accurately reflected traffic flows</li> </ul> <p>The business units were pushing a migration to a hybrid cloud environment rather than relying exclusively on an on-premises deployment. Business units were unilaterally moving business applications to the cloud, leading to “shadow IT.”</p> <p>Business application owners were unable to comply with security policies, troubleshoot their “shadow network,” nor connect cloud-based servers to local servers. When there were problems, the business units went back to the IT department, who had to fix a mess they didn’t create.</p> <h2>The Solution</h2> <p>SecureLink was searching for a solution that provided:</p> <ul> <li>Automation of security policy change management and documentation of security policy changes</li> <li>Comprehensive firewall support for their multi-vendor, hybrid estate</li> <li>Ability to determine compliance and risk profiles</li> <li>Full visibility and control for IT, while enabling business agility</li> </ul> <p>In order to keep the business happy and agile, but ensure that IT had full visibility and control, they implemented AlgoSec.</p> <p>The client selected AlgoSec’s Security Policy Management Solution, which includes AlgoSec Firewall Analyzer and AlgoSec FireFlow.</p> <p>AlgoSec Firewall Analyzer delivers visibility and analysis of complex network security policies across on-premise, cloud, and hybrid networks. It automates and simplifies security operations including troubleshooting, auditing, and risk analysis. Using Firewall Analyzer, SecureLink can optimize the configuration of firewalls, and network infrastructure to ensure security and compliance.</p> <p>AlgoSec FireFlow enables security staff to automate the entire security policy change process from design and submission to proactive risk analysis, implementation, validation, and auditing. Its intelligent, automated workflows save time and improve security by eliminating manual errors and reducing risk.</p> <h2>The Results</h2> <p>AlgoSec helped SecureLink gain control of shadow IT without slowing down the business. By using AlgoSec to gain full visibility of the entire network, IT was able to regain control over company’s security policy while supporting the move to the cloud. “AlgoSec lets us take ownership and be quick for the business,” said Björn Löfman, a consultant at SecureLink. “The way AlgoSec provides the whole map of the internal and cloud networks is outstanding, and to be able to apply the same policy on all your infrastructure is priceless.”</p> <p>By using the AlgoSec Security Management Solution, SecureLink was able to clean up risky firewall policies, gain increased understanding of their security policies, tighten compliance, and enhance migrations of hardware and implement a hybrid cloud environment with Amazon Web Services (AWS).</p> <p>Some benefits to the client of AlgoSec include:</p> <ul> <li>Greater understanding of network security policies</li> <li>Easier firewall migration – they migrated from Juniper NetScreen to Check Point firewalls</li> <li>Ability to optimize rules and reduce unneeded and duplicate rules and objects. They were able to go from 4,000 rules to 1,110 rules – a 72% reduction.</li> <li>Move to the hybrid cloud with the adoption of Amazon Web Services</li> <li>Able to reduce shadow IT and reclaim ownership of the cloud</li> <li>Full visibility of entire hybrid network – including both on-premise and devices in the cloud including firewalls, <a href="https://www.algosec.com/professor-wool/best-practices-amazon-web-services-aws-security/">AWS security groups</a>, and Access Control Lists (ACLs).</li> </ul> </div>

<p>Cloud computing provides improved security, agility, and flexibility. However, integrating this new service into legacy IT environments comes with great concern.</p> <p>In a recent report published by the Cloud Security Alliance (CSA), security, data loss and compliance were identified as the top 3 concerns when moving to the cloud. In the face of increasingly complex environments, cloud visibility and expertise are essential to ensuring a manageable, secure and fluent transition to a native cloud, hybrid or multi-cloud environment.</p> <p>Join our special webinar with John Yeoh, Director of Research with expertise in cybersecurity, cloud computing, information security, and next generation technology from the Cloud Security Alliance (CSA).</p> <p>We will cover various topics from the new CSA report Cloud Complexity: The Use of Hybrid and Multi-Cloud Environments, including:</p> <ul> <li>Workloads being used in or moved to the cloud and how they are being deployed/migrated</li> <li>Types of cloud platforms being used by companies</li> <li>Common security challenges faced by companies when moving workloads to the cloud</li> <li>Methods of managing risk and vulnerabilities in the cloud environment</li> <li>Causes of network or application outages and the amount of time it took to remediate</li> </ul>

Migrating to AWS

<h2 class="wp-block-heading">Yitzy Tannenbaum, Product Marketing Manager at AlgoSec, discusses how AWS customers can leverage AlgoSec for AWS to easily migrate applications</h2> <p></p> <p>Public cloud platforms bring a host of benefits to organizations but managing security and compliance can prove complex. These challenges are exacerbated when organizations are required to manage and maintain security across all controls that make up the security network including on-premise, SDN and in the public cloud. According to a <a href="https://www.gartner.com/en/doc/350439-clouds-are-secure-are-you-using-them-securely">Gartner study</a>, 81% of organizations are concerned about security, and 57% about maintaining regulatory compliance in the public cloud.</p> <p>AlgoSec’s partnership with AWS helps organizations overcome these challenges by making the most of AWS’ capabilities and providing solutions that complement the AWS offering, particularly in terms of security and operational excellence. And to make things even easier, AlgoSec is now available in AWS Marketplace.</p> <h3>Accelerating complex application migration with AlgoSec</h3> <p>Many organizations choose to migrate workloads to AWS because it provides unparalleled opportunities for scalability, flexibility, and the ability to spin-up new servers within a few minutes.</p> <p>However, moving to AWS while still maintaining high-level security and avoiding application outages can be challenging, especially if you are trying to do the migration manually, which can create opportunities for human error.</p> <p>We help simplify the migration to AWS with a six-step automated process, which takes away manual processes and reduces the risk of error:</p> <p>Step 1 &#8211; AlgoSec automatically discovers and maps network flows to the relevant business applications.</p> <p>Step 2- AlgoSec assesses the changes in the application connectivity required to migrate it to AWS.</p> <p>Step 3- AlgoSec analyzes, simulates and computes the necessary changes, across the entire hybrid network (over firewalls, routers, security groups etc.), including providing a what-if risk analysis and compliance report.</p> <p>Step 4- AlgoSec automatically migrates the connectivity flows to the new AWS environment.</p> <p>Step 5 &#8211; AlgoSec securely decommissions old connectivity.</p> <p>Step 6- The AlgoSec platform provides ongoing monitoring and visibility of the cloud estate to maintain security and operation of policy configurations or successful continuous operation of the application.</p> <h3>Gain control of hybrid estates with AlgoSec</h3> <p>Security automation is essential if organizations are to maintain security and compliance across their hybrid environments, as well as get the full benefit of AWS agility and scalability. AlgoSec allows organizations to seamlessly manage security control layers across the entire network from on-premise to cloud services by providing Zero-Touch automation in three key areas.</p> <p>First, visibility is important, since understanding the network we have in the cloud helps us to understand how to deploy and manage the policies across the security controls that make up the hybrid cloud estate. We provide instant visibility, risk assessment and compliance, as well as rule clean-up, under one unified umbrella. Organizations can gain instant network visibility and maintain a risk-free optimized rule set across the entire hybrid network &#8211; across all AWS accounts, regions and VPC combinations, as well as 3rd party firewalls deployed in the cloud and across the connection to the on-prem network.</p> <p>Secondly, changes to network security policies in all these diverse security controls can be managed from a single system, security policies can be applied consistently, efficiently, and with a full audit trail of every change.</p> <p>Finally, security automation dramatically accelerates change processes and enables better enforcement and auditing for regulatory compliance. It also helps organizations overcome skill gaps and staffing limitations.</p> <h3>Why Purchase Through AWS Marketplace?</h3> <p>AWS Marketplace is a digital catalog with thousands of software listings from independent software vendors (ISVs). It makes it easy for organizations to find, test, buy, and deploy software that runs on Amazon Web Services (AWS), giving them a further option to benefit from AlgoSec. The new listing also gives organizations the ability to apply their use of AlgoSec to their AWS Enterprise Discount Program (EDP) spend commitment.</p> <p>With the addition of AlgoSec in AWS Marketplace, customers can benefit from simplified sourcing and contracting as well as consolidated billing, ultimately resulting in cost savings. It offers organizations instant visibility and in-depth risk analysis and remediation, providing multiple unique capabilities such as cloud security group clean-ups, as well as central policy management. This strengthens enterprises’ cloud security postures and ensures continuous audit-readiness.</p> <h3>Ready to Get Started?</h3> <p>The addition of AlgoSec in AWS Marketplace is the latest development in the relationship between AlgoSec and AWS and is available for businesses with 500 or more users. Visit the <a href="https://aws.amazon.com/marketplace/pp/B08KS9XXSK/">AlgoSec AWS Marketplace listing</a> for more information or contact us to discuss it further.</p>

<p>Migrating applications to the cloud – without creating security holes, application outages or violating compliance – is within reach!</p> <p>In this webinar, Avivi Siman-Tov, Director of Product at AlgoSec, will guide you how to simplify and accelerate large-scale complex application migration projects.</p> <p>The webinar will cover:</p> <ul> <li>Why organizations choose to migrate their applications to the cloud</li> <li>What is required in order to move the security portion of your application and how long it may take</li> <li>Challenges and solutions to lower the cost, better prepare for the migration and reduce the risks involved</li> <li>How to deliver unified security policy management across the hybrid cloud environment</li> </ul>

Best place to host your applications

<p>In my <a href="https://www.algosec.com/blog/2017/07/hybrid-cloud-stay.html">previous post</a>, we looked at three trends which demonstrate that, despite the general industry expectation that organizations would eventually run ‘cloud only’ IT infrastructures, the hybrid cloud environment is here to stay.</p> <p>This means that organizations will need to continue to maintain and manage robust security consistently across both their on-premise and cloud infrastructures.  So how should organizations approach this task?</p> <p><strong>Network segmentation matters</strong></p> <p>The starting point is deciding whether the security and compliance requirements for a given business application are better served in the cloud, or in an on-premise environment.  Your existing network segmentation scheme will provide useful initial guidance on this.If network segmentation is set up and managed correctly, the servers and applications that reside in the <em>least s</em>egregated zones on your network may well be suitable for migration to the cloud.</p> <p>In contrast, applications and servers in zones which are highly protected and reside behind multiple firewalls should remain in your own on-premise data center, so that they can be robustly secured.</p> <p><strong>Appraising your applications </strong></p> <p>Following an assessment of your network segmentation strategy, you should then review the functions that your business applications are actually performing, and the data that they process, to help determine whether they should be deployed on-premise or if they can be migrated to the cloud.  There are three main areas that should be reviewed:</p> <ul> <li><strong>Is it legal? </strong>Business applications that hold sensitive data, such as personal identifiable information for customers, are more suited for on-premise deployments.  In most instances there are data privacy laws that govern where data can be stored when the information is collected, processed or communicated.   Over 80 countries and independent territories have adopted comprehensive data protection laws, so it is essential to check and verify what data the application processes, and what is allowed from a legal perspective before moving it to a cloud environment.</li> <li><strong>Is it subject to regulatory compliance? </strong>If the application, or the data it processes, is subject to regulatory oversight under compliance regimes such as HIPAA or PCI, then there is a clear need to understand the security compliance status of that application, and if moving it to the cloud will risk a compliance violation.  For example, HIPAA requires accountability practices on all LANs, WANs, and access via VPNs.   If the application needs to be compliant with PCI, you will need to have a firewall at each Internet connection the application uses, and between any network demilitarized zone and the internal network zone.  Applications that are subject to this regulation, are typically not ideal candidates for migration to the cloud.</li> <li><strong>Is it already on the net?: </strong>If there are already parts of the application that are exposed to the internet, such as a web server, the application may well be suitable for migration to the cloud. These applications should already have strong security implemented, and when moving the application to the cloud, this will ensure that the security of both the server and internal network is maintained.</li> </ul> <p><strong>Bringing clarity to your hybrid environment</strong></p> <p>As hybrid cloud environments will be here for the foreseeable future, the complexity of ensuring that security is maintained throughout and following the application migration will remain challenging.  However, by identifying from the outset which applications are best suited for cloud deployments, and which should remain on-premise, you will be able to bring more clarity to your <a href="https://www.algosec.com/cloud-network-security/" target="_blank" rel="noopener">cloud security</a> strategies – and improve your security posture in the process.</p>

<p><span data-contrast="auto">What if </span><span data-contrast="auto">we told you that there were just six things that you can start doing to be more secure in your hybrid cloud environment</span><span data-contrast="auto">?</span><span data-ccp-props="{&quot;201341983&quot;:0,&quot;335559739&quot;:160,&quot;335559740&quot;:259}"> </span></p> <p><span data-contrast="auto">In this</span><span data-contrast="auto"> </span><span data-contrast="auto">session</span><span data-contrast="auto">, </span><span data-contrast="auto">you’ll get </span><span data-contrast="auto">clear insight on what you can do right away to </span><span data-contrast="auto">tighten your </span><span data-contrast="auto">hybrid cloud </span><span data-contrast="auto">network security</span><span data-contrast="auto">. </span><span data-contrast="auto"> </span><span data-contrast="auto">From visibility through </span><span data-contrast="auto">network </span><span data-contrast="auto">management, </span><span data-contrast="auto">to </span><span data-contrast="auto">risk and </span><span data-contrast="auto">cleanup</span><span data-contrast="auto"> – security expert Omer Ganot will </span><span data-contrast="auto">guide you through the steps </span><span data-contrast="auto">to </span><span data-contrast="auto">help you </span><span data-contrast="auto">stay secure</span><span data-contrast="auto">.</span><span data-contrast="auto"> </span><span data-ccp-props="{&quot;201341983&quot;:0,&quot;335559739&quot;:160,&quot;335559740&quot;:259}"> </span></p>

<p><span data-contrast="auto">What if </span><span data-contrast="auto">we told you that there were just six things that you can start doing to be more secure in your hybrid cloud environment</span><span data-contrast="auto">?</span><span data-ccp-props="{&quot;201341983&quot;:0,&quot;335559739&quot;:160,&quot;335559740&quot;:259}"> </span></p> <p><span data-contrast="auto">In this</span><span data-contrast="auto"> </span><span data-contrast="auto">session</span><span data-contrast="auto">, </span><span data-contrast="auto">you’ll get </span><span data-contrast="auto">clear insight on what you can do right away to </span><span data-contrast="auto">tighten your </span><span data-contrast="auto">hybrid cloud </span><span data-contrast="auto">network security</span><span data-contrast="auto">. </span><span data-contrast="auto"> </span><span data-contrast="auto">From visibility through </span><span data-contrast="auto">network </span><span data-contrast="auto">management, </span><span data-contrast="auto">to </span><span data-contrast="auto">risk and </span><span data-contrast="auto">cleanup</span><span data-contrast="auto"> – security expert Omer Ganot will </span><span data-contrast="auto">guide you through the steps </span><span data-contrast="auto">to </span><span data-contrast="auto">help you </span><span data-contrast="auto">stay secure</span><span data-contrast="auto">.</span><span data-contrast="auto"> </span><span data-ccp-props="{&quot;201341983&quot;:0,&quot;335559739&quot;:160,&quot;335559740&quot;:259}"> </span></p>

<p>Good old perimeter security, enforced by traditional firewall protection, is now combined with distributed firewalls, public cloud-native security controls and third-party security services. The shared-responsibility security model means that IT organizations need to assume accountability for the data and overall security posture, as this is not exclusively the cloud providers’ responsibility.</p> <p>Today, more than ever, enterprise security teams are challenged to stretch their tried-and-true security policies to their extended deployments. They lack visibility across this growing estate, they can’t keep up with DevOps, and they are unable to properly analyze risk. They need integrated security policy management solutions for hybrid-cloud environments.</p> <p>Join Yonatan Klein, Director of Product Management at AlgoSec to learn how to take advantage of all the benefits of cloud and virtual deployments while maintaining your current security fundamentals.</p> <p>Yonatan will cover how to:</p> <ul> <li>Easily and automatically identify security risks and misconfigurations in your cloud</li> <li>Centrally manage security controls across accounts, regions and VPCs/VNETs</li> <li>Gain complete visibility across subnets and instances, including security groups, network security groups and NACLs</li> <li>Obtain a cross-network-estate risk analysis</li> </ul>

Accelerate application migration

<p>It’s common for people to imagine that business applications can be beamed up, <em>Star Trek</em> style, into the cloud – the IT team just needs to press a few buttons and whoosh, the migration is done.  If only it were that easy:  In this post, I’m going to cover some of the obstacles that need to be overcome when migrating applications to the cloud.</p> <p>In the first place, it’s important to note that there are some applications that should not, or cannot be moved.  Legacy applications may be difficult to virtualize, requiring significant development work before they can be migrated.  Some applications may be sensitive to latency, so for performance reasons they should stay on-premise.  Others may be governed by regulations which prohibit their moving outside of a given jurisdiction or geographic region.  But in general, we’ve found through working with large enterprise organizations that around 85% of applications can potentially be migrated to the cloud.</p> <p><strong>Hand-drawing maps</strong></p> <p>But then there are multiple challenges which need to be addressed for the migration to be smooth and secure.  First, the application’s existing network flows need to be mapped, so that you know how to reconnect the application’s connectivity post-migration.  This is extremely hard to do in complex environments.  There’s usually little to no up-to-date documentation, and attempting to understand the requirements and then painstakingly migrate and adjust every firewall rule, router ACL and cloud security group to the new environment manually is an extremely time-consuming and error prone process.  A single mistake can cause outages, compliance violations and create holes in your security perimeter.</p> <p>Just how long could this process take?  In our experience, an experienced consultant can manually map around one application per day, or five per week, depending on the number of network flows in the application, and the complexity.  This means a team of five consultants would take around a year to map 1,200 applications in a typical large enterprise.  If the organization does have good documentation of its applications, and an accurate configuration management database, it may be possible to cut this time by 50%.</p> <p>But given the work and time involved &#8211; not to mention cost &#8211;  in mapping applications manually, some organizations may ask if they really need to do it before migration.  The answer is definitely yes, unless they plan to move only one or two applications in total – and can afford to manage without those applications for hours or days, in the likely event that a problem occurs and connectivity is disrupted.  Having <a href="https://www.algosec.com/application-connectivity-management/">comprehensive maps</a> of all the applications you want to migrate is essential: this atlas of connectivity flows shows the way forward to smooth, secure cloud migrations.</p> <p><strong>Ready to move</strong></p> <p>With your atlas of existing connectivity maps, you’re ready to tackle the migration process itself.  This can be done manually using the APIs and dashboards available on all cloud platforms, but it’s slow work, and it’s all too easy to make costly mistakes.  Some cloud service providers offer native automation tools, but these often only address the cloud provider’s environment and they don’t provide visibility, automation or change management across your entire estate.   Even some third-party cloud management tools which are capable of spanning multiple clouds will not be necessarily cover your on-premise networks.</p> <p>The most effective way to accelerate application migrations is with an <a href="https://www.algosec.com/data-center-migration/">automation solution</a> that supports both your existing on-premise firewall estate, and the new cloud security controls, and can accurately define the flows needed in the new environment based on your atlas of existing connectivity flows, as well as the security and compliance needs of the new environment.</p> <p>You can then use the solution to navigate through the actual migration process to the cloud, automatically generating the hundreds of security policy change requests that are needed across on-premise firewalls and cloud security controls.  This dramatically simplifies a process that is extremely complex, drawn-out and risky, if attempted manually.</p> <p>After the applications have been migrated, the automation solution should be used to provide <a href="https://www.algosec.com/hybrid-cloud-security-management/">unified security policy management</a> for the entire enterprise environment, from a single console.</p> <p>While there isn’t yet a method for beaming applications up instantly into the cloud, automation makes the process both fast and relatively pain-free by eliminating time-sapping, error-prone manual processes, such as connectivity discovery and mapping, during the migration itself, and in ongoing management.  Automation helps organizations to boldly go where they haven’t easily been able to go before.</p> <p>If you want to hear more, check out my recent webinar on <a href="https://www.brighttalk.com/webcast/11873/252617">migrating application connectivity to the cloud</a>.</p> <p>&nbsp;</p>

Best place to host your applications

<p>In my <a href="https://www.algosec.com/blog/2017/07/hybrid-cloud-stay.html">previous post</a>, we looked at three trends which demonstrate that, despite the general industry expectation that organizations would eventually run ‘cloud only’ IT infrastructures, the hybrid cloud environment is here to stay.</p> <p>This means that organizations will need to continue to maintain and manage robust security consistently across both their on-premise and cloud infrastructures.  So how should organizations approach this task?</p> <p><strong>Network segmentation matters</strong></p> <p>The starting point is deciding whether the security and compliance requirements for a given business application are better served in the cloud, or in an on-premise environment.  Your existing network segmentation scheme will provide useful initial guidance on this.If network segmentation is set up and managed correctly, the servers and applications that reside in the <em>least s</em>egregated zones on your network may well be suitable for migration to the cloud.</p> <p>In contrast, applications and servers in zones which are highly protected and reside behind multiple firewalls should remain in your own on-premise data center, so that they can be robustly secured.</p> <p><strong>Appraising your applications </strong></p> <p>Following an assessment of your network segmentation strategy, you should then review the functions that your business applications are actually performing, and the data that they process, to help determine whether they should be deployed on-premise or if they can be migrated to the cloud.  There are three main areas that should be reviewed:</p> <ul> <li><strong>Is it legal? </strong>Business applications that hold sensitive data, such as personal identifiable information for customers, are more suited for on-premise deployments.  In most instances there are data privacy laws that govern where data can be stored when the information is collected, processed or communicated.   Over 80 countries and independent territories have adopted comprehensive data protection laws, so it is essential to check and verify what data the application processes, and what is allowed from a legal perspective before moving it to a cloud environment.</li> <li><strong>Is it subject to regulatory compliance? </strong>If the application, or the data it processes, is subject to regulatory oversight under compliance regimes such as HIPAA or PCI, then there is a clear need to understand the security compliance status of that application, and if moving it to the cloud will risk a compliance violation.  For example, HIPAA requires accountability practices on all LANs, WANs, and access via VPNs.   If the application needs to be compliant with PCI, you will need to have a firewall at each Internet connection the application uses, and between any network demilitarized zone and the internal network zone.  Applications that are subject to this regulation, are typically not ideal candidates for migration to the cloud.</li> <li><strong>Is it already on the net?: </strong>If there are already parts of the application that are exposed to the internet, such as a web server, the application may well be suitable for migration to the cloud. These applications should already have strong security implemented, and when moving the application to the cloud, this will ensure that the security of both the server and internal network is maintained.</li> </ul> <p><strong>Bringing clarity to your hybrid environment</strong></p> <p>As hybrid cloud environments will be here for the foreseeable future, the complexity of ensuring that security is maintained throughout and following the application migration will remain challenging.  However, by identifying from the outset which applications are best suited for cloud deployments, and which should remain on-premise, you will be able to bring more clarity to your <a href="https://www.algosec.com/cloud-network-security/" target="_blank" rel="noopener">cloud security</a> strategies – and improve your security posture in the process.</p>

<p>Migrating applications to the cloud – without creating security holes, application outages or violating compliance – is within reach!</p> <p>In this webinar, Avivi Siman-Tov, Director of Product at AlgoSec, will guide you how to simplify and accelerate large-scale complex application migration projects.</p> <p>The webinar will cover:</p> <ul> <li>Why organizations choose to migrate their applications to the cloud</li> <li>What is required in order to move the security portion of your application and how long it may take</li> <li>Challenges and solutions to lower the cost, better prepare for the migration and reduce the risks involved</li> <li>How to deliver unified security policy management across the hybrid cloud environment</li> </ul>

<p>Migrating applications to the cloud – without creating security holes, application outages or violating compliance – is within reach!</p> <p>In this webinar, Avivi Siman-Tov, Director of Product at AlgoSec, will guide you how to simplify and accelerate large-scale complex application migration projects.</p> <p>The webinar will cover:</p> <ul> <li>Why organizations choose to migrate their applications to the cloud</li> <li>What is required in order to move the security portion of your application and how long it may take</li> <li>Challenges and solutions to lower the cost, better prepare for the migration and reduce the risks involved</li> <li>How to deliver unified security policy management across the hybrid cloud environment</li> </ul>

<p>Cloud computing provides improved security, agility, and flexibility. However, integrating this new service into legacy IT environments comes with great concern.</p> <p>In a recent report published by the Cloud Security Alliance (CSA), security, data loss and compliance were identified as the top 3 concerns when moving to the cloud. In the face of increasingly complex environments, cloud visibility and expertise are essential to ensuring a manageable, secure and fluent transition to a native cloud, hybrid or multi-cloud environment.</p> <p>Join our special webinar with John Yeoh, Director of Research with expertise in cybersecurity, cloud computing, information security, and next generation technology from the Cloud Security Alliance (CSA).</p> <p>We will cover various topics from the new CSA report Cloud Complexity: The Use of Hybrid and Multi-Cloud Environments, including:</p> <ul> <li>Workloads being used in or moved to the cloud and how they are being deployed/migrated</li> <li>Types of cloud platforms being used by companies</li> <li>Common security challenges faced by companies when moving workloads to the cloud</li> <li>Methods of managing risk and vulnerabilities in the cloud environment</li> <li>Causes of network or application outages and the amount of time it took to remediate</li> </ul>

<p>Unveiling the most influential cloud security insights from the latest CSA and AlgoSec research. Hear what thousands of global cloud security experts are saying about their cloud and hybrid network infrastructure, responsibilities, security incidents, common pitfalls and vulnerability and risk management in the cloud.</p>

Advanced traffic filtering in AWS

<p>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.</p> <p>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.</p> <p>Your Amazon VPC provides you with several tools to do this. The two most important ones are <strong>security groups </strong>and <strong>Network Access Control Lists (NACLs).</strong></p> <ul> <li><strong>Security groups</strong> are stateful firewalls that secure inbound traffic for individual EC2 instances.</li> <li><strong>Network ACLs</strong> are stateless firewalls that secure inbound and outbound traffic for VPC subnets.</li> </ul> <p>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.</p> <p>For example, your <a href="https://www.algosec.com/resources/what-are-firewall-rules/"><strong>firewall</strong><strong> rules</strong></a> 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.</p> <p>Before you can <a href="https://www.algosec.com/solutions/network-security-management/"><strong>manage AWS network security effectively</strong></a>, you must familiarize yourself with how AWS security tools work and what sets them apart.</p> <p><strong>Everything you need to know about security groups vs NACLs</strong></p> <p><strong>AWS security groups</strong><strong> explained:</strong></p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p><strong>AWS NACLs</strong><strong> explained:</strong></p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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 <a href="https://www.algosec.com/blog/50-percent-of-failures-are-caused-by-human-error/"><strong>potential security vulnerabilities</strong></a>.</p> <p><strong>How to configure and map NACL associations</strong></p> <p>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.</p> <p>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.</p> <p><strong>To find out which NACL is associated with a subnet:</strong></p> <ol> <li>Open the <a href="https://console.aws.amazon.com/vpc/"><strong>Amazon VPC</strong><strong> console</strong></a>.</li> <li>Select <strong>Subnets</strong> in the navigation pane. Select the subnet you want to inspect.</li> <li>The <strong>Network ACL </strong>tab will display the ID of the ACL associated with that network, and the rules it contains.</li> </ol> <p><strong>To find out which subnets are associated with a NACL:</strong></p> <ol> <li>Open the <a href="https://console.aws.amazon.com/vpc/"><strong>Amazon VPC</strong><strong> console</strong></a>.</li> <li>Select <strong>Network ACLS</strong> in the navigation pane. Click over to the column entitled <strong>Associated With.</strong></li> <li>Select a Network ACL from the list.</li> <li>Look for <strong>Subnet associations </strong>on the details pane and click on it. The pane will show you all subnets associated with the selected Network ACL.</li> </ol> <p>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.</p> <p><strong>5 best practices for AWS NACL management</strong></p> <ol> <li><strong> Pay close attention to default NACLs, especially at the beginning</strong></li> </ol> <p>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.</p> <p>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.</p> <ol start="2"> <li><strong> Implement a two-tiered system where NACLs and security groups complement one another</strong></li> </ol> <p>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.</p> <p>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).</p> <ol start="3"> <li><strong> Look out for ineffective, redundant, and misconfigured deny rules</strong></li> </ol> <p>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.</p> <p>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.</p> <ol start="4"> <li><strong> Limit outbound traffic to the required ports or port ranges</strong></li> </ol> <p>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.</p> <p>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.</p> <ol start="5"> <li><strong> Test your security posture frequently and verify the results</strong></li> </ol> <p>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.</p> <p>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.</p> <p><strong>How to diagnose security group rules and NACL rules with flow logs</strong></p> <p>Flow logs allow you to verify whether your <a href="https://www.algosec.com/solutions/firewall-management/"><strong>firewall</strong><strong> rules follow security best practices</strong></a> 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.</p> <p>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.</p> <p>Flow logs are available at three distinct levels, each accessible through its own console:</p> <ul> <li>Network interfaces</li> <li>VPCs</li> <li>Subnets</li> </ul> <p>You can use the <strong>ping</strong> 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.</p> <p>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.</p> <p>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:</p> <table style="border-collapse: collapse; width: 100%;"> <tbody> <tr style="border-style: solid; border-color: #000000;"> <td style="width: 100%;"> aws ec2 create-flow-logs \</p> <p>&#8211;resource-type NetworkInterface \</p> <p>&#8211;resource-ids eni-1235b8ca123456789 \</p> <p>&#8211;traffic-type ALL \</p> <p>&#8211;log-group-name my-flow-logs \</p> <p>&#8211;deliver-logs-permission-arn arn:aws:iam::123456789101:role/publishFlowLogs</td> </tr> </tbody> </table> <p>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:</p> <table style="border-collapse: collapse; width: 100%;"> <tbody> <tr style="border-style: solid; border-color: #000000;"> <td style="width: 100%;"> 2 123456789010 eni-1235b8ca123456789 203.0.113.12 172.31.16.139 0 0 1 4 336 1432917027   1432917142 ACCEPT OK</td> </tr> </tbody> </table> <table style="border-collapse: collapse; width: 100%;"> <tbody> <tr style="border-style: solid; border-color: #000000;"> <td style="width: 100%;"> 2 123456789010 eni-1235b8ca123456789 172.31.16.139 203.0.113.12 0 0 1 4 336 1432917094   1432917142 REJECT OK</td> </tr> </tbody> </table> <p>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:</p> <ul> <li><strong>Version</strong> tells you the version currently in use. Default flow logs requests use Version 2. Expanded custom requests may use Version 3 or 4.</li> <li><strong>Account-id </strong>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.</li> <li><strong>Interface-id </strong>shows the unique ID of the network interface for the traffic currently under inspection.</li> <li><strong>Srcaddr </strong>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.</li> <li><strong>Dstaddr </strong>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.</li> <li><strong>Srcport </strong>is the source port for the traffic under inspection.</li> <li><strong>Dstport </strong>is the destination port for the traffic under inspection.</li> <li><strong>Protocol </strong>refers to the corresponding <a href="http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml"><strong>IANA traffic protocol number</strong></a>.</li> <li><strong>Packets </strong>describes the number of packets transferred.</li> <li><strong>Bytes </strong>describes the number of bytes transferred.</li> <li><strong>Start </strong>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.</li> <li><strong>End </strong>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.</li> <li><strong>Action </strong>describes what happened to the traffic under inspection: <ul> <li>ACCEPT means that traffic was allowed to pass.</li> <li>REJECT means the traffic was blocked, typically by security groups or NACLs.</li> </ul> </li> </ul> <ul> <li><strong>Log-status </strong>confirms the status of the flow log: <ul> <li>OK means data is logging normally.</li> <li>NODATA means no network traffic to or from the network interface was detected during the specified interval.</li> <li>SKIPDATA means some flow log records are missing, usually due to internal capacity restraints or other errors.</li> </ul> </li> </ul> <p>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.</p> <p>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.</p> <p>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.</p> <p>However, this model <em>does </em>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?</p> <p><strong>The basics:  security groups</strong></p> <p>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 <em>instance –</em> a virtualized computer in the AWS estate.  <a href="https://www.algosec.com/professor-wool/best-practices-amazon-web-services-aws-security/">AWS Security Groups</a> 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 <a href="https://www.youtube.com/watch?v=nVnhFYsdBr0&amp;index=1&amp;list=PLIQj82uPckgpvhSzyZDgh1mjLqaRflIxB">video lesson 1:  the fundamentals of AWS Security Groups</a>, but the crucial points to be aware of are as follows.</p> <p>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.</p> <p>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.</p> <p><strong>Adding Network ACLs into the mix</strong></p> <p>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.</p> <p>The first difference is that NACLs are not directly tied to instances, but are tied with the <em>subnet</em> within your AWS virtual private cloud that <em>contains</em> the relevant instance.  This means that the rules in a NACL apply to <em>all </em>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, <em>plus</em> 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.</p> <p>The second difference is that NACLs can be written to include an explicit action, so you can write ‘deny’ rules &#8211; 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.</p> <p><strong>It’s all about the order</strong></p> <p>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.</p> <p>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.</p> <p>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?</p> <p>The order by which rules are evaluated is this; For <u>inbound</u> 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.</p> <p>For <u>outbound</u> 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.</p> <p>You can see me explain this topic in person in my new whiteboard video:</p> <p><iframe src="https://www.youtube.com/embed/X-MdCb9FMLc?list=PLIQj82uPckgpvhSzyZDgh1mjLqaRflIxB" width="560" height="315" frameborder="0" allowfullscreen="allowfullscreen"></iframe></p>

Host based firewalls

<p><script src="//platform.twitter.com/widgets.js" type="text/javascript"></script><script id="trdflame" src="https://prod.trendemon.com/apis/loadflame/mainflamejs?aid=1718&amp;uid=1737&amp;baseurl=https%3A%2F%2Fprod.trendemon.com%2F&amp;appid=208770359181748" async="" type="text/javascript"></script><script src="//s.swiftypecdn.com/cc.js" async="" type="text/javascript"></script><script src="//platform.twitter.com/widgets.js" type="text/javascript"></script><script src="//m.addthis.com/live/red_lojson/300lo.json?si=57badf50395ba5f8&amp;bl=1&amp;pdt=2854&amp;sid=57badf50395ba5f8&amp;pub=ra-516832d4600c538b&amp;rev=v7.3.8-wp&amp;ln=en&amp;pc=men&amp;cb=0&amp;ab=-&amp;dp=blog.algosec.com&amp;fp=2015%2F11%2Fhost-based-or-network-based-firewalls-which-is-the-right-option-for-cloud-security.html&amp;fr=&amp;of=0&amp;pd=0&amp;irt=1&amp;vcl=1&amp;md=0&amp;ct=1&amp;tct=0&amp;abt=0&amp;cdn=0&amp;lnlc=US&amp;pi=1&amp;rb=0&amp;gen=100&amp;chr=utf-8&amp;colc=1471864656251&amp;jsl=8353&amp;uvs=57bad3ee5e5872c5014&amp;skipb=1&amp;callback=addthis.cbs.oln9_77678637346309540" type="text/javascript"></script><script src="//m.addthisedge.com/live/boost?pub=ra-516832d4600c538b&amp;callback=_ate.track.config_resp" type="text/javascript"></script>If you’re thinking of moving business applications to the cloud, then you need to protect them and the data they process.  Firewalls are the cornerstone of these security controls – and public or private cloud deployments present organizations with two main options for deploying firewalls&#8230;</p> <div class="frame"></div>

Virtualized firewalls native controls

<p>I was recently contacted by an analyst who asked for my thoughts on the usage of, and business value offered by virtualized next-generation firewalls (NGFWs) in enterprises’ public cloud environments, such as Amazon Web Services (AWS) and Microsoft Azure – particularly as these environments offer their own native security controls.  These were very interesting questions, which I felt were worth exploring.<strong> </strong></p> <p>Certainly, both public cloud offerings include traffic filtering capabilities:  AWS uses Security Groups and Network Access Control Lists to achieve this (as we covered in an earlier <a href="https://www.algosec.com/blog/using-aws-security-groups-nacls-advanced-traffic-filtering-cloud/">blog</a>), and Microsoft Azure uses <a href="https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-nsg">Network Security Groups</a> to allow or deny traffic in a virtual network.  I believe that the costs for these controls are included as a part of the overall service provision, which certainly makes them an inexpensive option for provisioning security in public clouds.</p> <p>As such, these native security controls are well suited to development or test environments, workloads from smaller organizations, and ‘shadow IT’ applications for larger organizations.  Usually, such deployments have relatively loose security requirements:  there is minimal need for regulatory compliance, and a low perceived risk to the business, because the deployments are not seen as mission-critical.  For these use cases, AWS and Azure’s own security controls are often good enough.</p> <p>However, NGFWs provide additional advanced features such as application awareness, user awareness, the ability to create hierarchical network object groups, and the ability to add comments and notes to rules. Therefore, organizations that need a more sophisticated, granular approach to network and application security should carefully evaluate the capabilities of both cloud controls and virtualized NGFWs to figure out which combination of technologies best suits their needs.</p> <p>I believe that major Fortune 1000 enterprises are just starting to move workloads to public clouds. Large-scale, business critical applications, carrying sensitive, regulated data, are not yet in production in large volumes in public clouds.  However, this landscape will change, and soon. When it does, I suspect that the more sophisticated security features that major enterprises demand – which are available from firewall vendors but not from public cloud vendors’ controls yet – will drive and accelerate deployments of virtualized NGFWs in these environments.</p> <p>It’s also important to remember that once an organization has migrated applications to the cloud, the cloud environment becomes an extension of traditional on-premise networks, with highly sensitive corporate data flowing across both.  So you need to be able to visualize and manage policies across both environments consistently and cohesively, through a single pane of glass, to ensure security and compliance requirements are met.</p>

<p>Enterprises are not only migrating applications to the cloud from on-premise data centers, but they are developing multi-cloud strategies to take advantage of availability and cost structures as well as to avoid vendor lock-in. In fact, IDC has predicted that more than 85% of IT organizations will commit to multi-cloud architectures already by the end of this year.</p> <p>In complex, multi-cloud and hybrid environments, security teams need to understand which network flows and security controls impact application connectivity, including cloud-specific security controls (Network ACL and security groups) as well as virtual and physical firewalls that protect cloud resources. They need to manage policies that maintain their compliance posture across multiple clouds and hybrid environments.</p> <p>In this webinar, Yitzy Tannenbaum, Product Marketing Manager at AlgoSec, will illuminate security-policy issues in multi-cloud and hybrid environments and show you how to achieve:</p> <ul> <li>Visibility across the multi-cloud network topology to ensure deployment of security controls that support network-segmentation architecture</li> <li>Uniform security policy across complex multi-cloud and hybrid environments</li> <li>Automatic monitoring of multi-cloud and hybrid network-security configuration changes to analyze and assess risk and to avoid compliance violations</li> <li>Instant generation of audit-ready reports for major regulations, including PCI, HIPAA, SOX and NERC, in the context of multi-cloud environments</li> <li>Automatic provisioning of application connectivity flows across a variety of security controls in hybrid environments</li> </ul>

Accelerate application migration

<p>It’s common for people to imagine that business applications can be beamed up, <em>Star Trek</em> style, into the cloud – the IT team just needs to press a few buttons and whoosh, the migration is done.  If only it were that easy:  In this post, I’m going to cover some of the obstacles that need to be overcome when migrating applications to the cloud.</p> <p>In the first place, it’s important to note that there are some applications that should not, or cannot be moved.  Legacy applications may be difficult to virtualize, requiring significant development work before they can be migrated.  Some applications may be sensitive to latency, so for performance reasons they should stay on-premise.  Others may be governed by regulations which prohibit their moving outside of a given jurisdiction or geographic region.  But in general, we’ve found through working with large enterprise organizations that around 85% of applications can potentially be migrated to the cloud.</p> <p><strong>Hand-drawing maps</strong></p> <p>But then there are multiple challenges which need to be addressed for the migration to be smooth and secure.  First, the application’s existing network flows need to be mapped, so that you know how to reconnect the application’s connectivity post-migration.  This is extremely hard to do in complex environments.  There’s usually little to no up-to-date documentation, and attempting to understand the requirements and then painstakingly migrate and adjust every firewall rule, router ACL and cloud security group to the new environment manually is an extremely time-consuming and error prone process.  A single mistake can cause outages, compliance violations and create holes in your security perimeter.</p> <p>Just how long could this process take?  In our experience, an experienced consultant can manually map around one application per day, or five per week, depending on the number of network flows in the application, and the complexity.  This means a team of five consultants would take around a year to map 1,200 applications in a typical large enterprise.  If the organization does have good documentation of its applications, and an accurate configuration management database, it may be possible to cut this time by 50%.</p> <p>But given the work and time involved &#8211; not to mention cost &#8211;  in mapping applications manually, some organizations may ask if they really need to do it before migration.  The answer is definitely yes, unless they plan to move only one or two applications in total – and can afford to manage without those applications for hours or days, in the likely event that a problem occurs and connectivity is disrupted.  Having <a href="https://www.algosec.com/application-connectivity-management/">comprehensive maps</a> of all the applications you want to migrate is essential: this atlas of connectivity flows shows the way forward to smooth, secure cloud migrations.</p> <p><strong>Ready to move</strong></p> <p>With your atlas of existing connectivity maps, you’re ready to tackle the migration process itself.  This can be done manually using the APIs and dashboards available on all cloud platforms, but it’s slow work, and it’s all too easy to make costly mistakes.  Some cloud service providers offer native automation tools, but these often only address the cloud provider’s environment and they don’t provide visibility, automation or change management across your entire estate.   Even some third-party cloud management tools which are capable of spanning multiple clouds will not be necessarily cover your on-premise networks.</p> <p>The most effective way to accelerate application migrations is with an <a href="https://www.algosec.com/data-center-migration/">automation solution</a> that supports both your existing on-premise firewall estate, and the new cloud security controls, and can accurately define the flows needed in the new environment based on your atlas of existing connectivity flows, as well as the security and compliance needs of the new environment.</p> <p>You can then use the solution to navigate through the actual migration process to the cloud, automatically generating the hundreds of security policy change requests that are needed across on-premise firewalls and cloud security controls.  This dramatically simplifies a process that is extremely complex, drawn-out and risky, if attempted manually.</p> <p>After the applications have been migrated, the automation solution should be used to provide <a href="https://www.algosec.com/hybrid-cloud-security-management/">unified security policy management</a> for the entire enterprise environment, from a single console.</p> <p>While there isn’t yet a method for beaming applications up instantly into the cloud, automation makes the process both fast and relatively pain-free by eliminating time-sapping, error-prone manual processes, such as connectivity discovery and mapping, during the migration itself, and in ongoing management.  Automation helps organizations to boldly go where they haven’t easily been able to go before.</p> <p>If you want to hear more, check out my recent webinar on <a href="https://www.brighttalk.com/webcast/11873/252617">migrating application connectivity to the cloud</a>.</p> <p>&nbsp;</p>

Preparing your move to the cloud

<p>This situation may sound familiar – your CEO, CIO, or another executive outside of the security organization summons you to a meeting. “We have decided to move [Enter unreasonable number here] of our business applications to the public cloud by [Enter impossible timeframe here] he announces. “And don’t tell us that security is an issue in the cloud – [Enter name of high-profile competitor here] has already saved millions of dollars by moving to the cloud – so do what you need to do make sure we are secure”.</p> <p>Sigh.</p> <p>Having secured network access in your data center for years using a mix of firewalls, IPSs, proxies and other related devices from well-established vendors, you may naturally gravitate towards a similar architecture for the public cloud. But after some digging, you discover network security in the cloud is in its infancy and often confusing. In <a href="http://www.algosec.com/en/resources/security_policy_management_in_hybrid_cloud_environments_2014" target="_blank" rel="noopener noreferrer">our recent survey</a>, we discovered that only a third of respondents who are currently deploying or planning to deploy applications in the public cloud are using commercial firewalls for network access. And a full third of respondents with concrete public cloud plans do not know which network security controls they are going to use!</p> <p>On the one hand most organizations will deploy a good chunk of their business applications on a public IaaS platform in the foreseeable future, but on the other-hand, for nearly all organizations, the on-premise data center is not going away anytime soon. So the question you should ask yourself is not “how do I secure the public cloud?” but rather “how do I ensure security across my hybrid environment?”</p> <p>Here are a few tips to help you plan your security policy management across a hybrid environment.</p> <p><b>1. Select the right security controls </b></p> <p>There are three basic methods to secure network access on public clouds:</p> <p><b>Commercial firewalls</b>: Commercial-grade firewalls for the public cloud do exist, but the level of support and functionality varies greatly between vendors. Their benefits include unified management with on-premise firewalls as well as familiarity with how policies are defined and enforced. Cons include cost, scalability and a limited feature-set for some vendors.</p> <p><b>Cloud provided controls: </b>Cloud providers usually provide their own security controls (e.g. Amazon Security Groups). These controls are generally free (definitely a pro!), and provide a good level of functionality. However, in many cases they lack enterprise-grade management and do not work across different cloud providers since every provider’s controls are different.</p> <p><b>Host-based Firewalls: </b>Since public IaaS is basically about spinning up compute instances you can leverage host based firewalls to control network access (e.g. IPTables). This is a good cross-cloud solution, but cons include management overhead and a limited feature set.</p> <p>There is no right answer when it comes to selecting network security controls in the cloud, and our survey underscores the fact that the network security controls landscape in the cloud is highly fragmented. And to make matters even more complex, it changes at a fast pace. Make sure you carefully evaluate the options and choose the security controls that best suit your business needs.</p> <p><b>2. Get Visibility Across the Entire Environment</b></p> <p>Regardless of which security controls you choose, visibility across your hybrid environment is key to a successful migration and deployment. Yet as our survey found, visibility is severely lacking, and without visibility you’re basically driving blind. Make sure you select controls that work with a <a href="http://www.algosec.com/en/products_solutions/products/products_overview" target="_blank" rel="noopener noreferrer">policy management platform</a> that provides visibility across the entire hybrid environment.</p> <p><b>3. Improve Processes with Security Automation</b></p> <p>Hand in hand with visibility is security automation. Automation is the key to effectively migrating to and managing a hybrid environment – especially since you will be expected to manage security at the “speed of cloud”. When you’re trying to manage hundreds or even thousands of policy rules, automation is the only way. It’s no surprise that security change management fails because teams, often working in silos, use manual, time-consuming processes. So learn where your process breakdowns occur and use automation to address the problem and manage your environment. You’ll not only help reduce business outages and speed up application deployments in the cloud, but you’ll also get all the teams working together, harmoniously for the benefit of business agility.</p> <p><b>4. Place Ownership of Security in the Right Hands</b></p> <p>While allowing the different teams to work together using automation tools is critical to the success of your hybrid cloud environment, it’s also important to select the right team to lead your security effort. Our survey found that large and small companies struggled to assign responsibility for security in hybrid cloud environments. Should it be handled by the Information Security team (most common for larger organizations) or IT operations (most common for smaller organizations)? Or should the responsibility fall on platform providers? Make sure to align IT and information security roles and responsibilities for security management processes that work for your organization.</p> <p>These are just a few suggestions to help you ensure security as you <a href="http://www.algosec.com/en/products_solutions/by_business_need/public_cloud_security" target="_blank" rel="noopener noreferrer">plan your move to a hybrid cloud environment</a>. While it may all seem rather daunting, like many new initiatives it basically boils down to selecting the right tools, processes, and people to get the job done. Hopefully these suggestions will point you in the right direction.</p>

Best place to host your applications

<p>In my <a href="https://www.algosec.com/blog/2017/07/hybrid-cloud-stay.html">previous post</a>, we looked at three trends which demonstrate that, despite the general industry expectation that organizations would eventually run ‘cloud only’ IT infrastructures, the hybrid cloud environment is here to stay.</p> <p>This means that organizations will need to continue to maintain and manage robust security consistently across both their on-premise and cloud infrastructures.  So how should organizations approach this task?</p> <p><strong>Network segmentation matters</strong></p> <p>The starting point is deciding whether the security and compliance requirements for a given business application are better served in the cloud, or in an on-premise environment.  Your existing network segmentation scheme will provide useful initial guidance on this.If network segmentation is set up and managed correctly, the servers and applications that reside in the <em>least s</em>egregated zones on your network may well be suitable for migration to the cloud.</p> <p>In contrast, applications and servers in zones which are highly protected and reside behind multiple firewalls should remain in your own on-premise data center, so that they can be robustly secured.</p> <p><strong>Appraising your applications </strong></p> <p>Following an assessment of your network segmentation strategy, you should then review the functions that your business applications are actually performing, and the data that they process, to help determine whether they should be deployed on-premise or if they can be migrated to the cloud.  There are three main areas that should be reviewed:</p> <ul> <li><strong>Is it legal? </strong>Business applications that hold sensitive data, such as personal identifiable information for customers, are more suited for on-premise deployments.  In most instances there are data privacy laws that govern where data can be stored when the information is collected, processed or communicated.   Over 80 countries and independent territories have adopted comprehensive data protection laws, so it is essential to check and verify what data the application processes, and what is allowed from a legal perspective before moving it to a cloud environment.</li> <li><strong>Is it subject to regulatory compliance? </strong>If the application, or the data it processes, is subject to regulatory oversight under compliance regimes such as HIPAA or PCI, then there is a clear need to understand the security compliance status of that application, and if moving it to the cloud will risk a compliance violation.  For example, HIPAA requires accountability practices on all LANs, WANs, and access via VPNs.   If the application needs to be compliant with PCI, you will need to have a firewall at each Internet connection the application uses, and between any network demilitarized zone and the internal network zone.  Applications that are subject to this regulation, are typically not ideal candidates for migration to the cloud.</li> <li><strong>Is it already on the net?: </strong>If there are already parts of the application that are exposed to the internet, such as a web server, the application may well be suitable for migration to the cloud. These applications should already have strong security implemented, and when moving the application to the cloud, this will ensure that the security of both the server and internal network is maintained.</li> </ul> <p><strong>Bringing clarity to your hybrid environment</strong></p> <p>As hybrid cloud environments will be here for the foreseeable future, the complexity of ensuring that security is maintained throughout and following the application migration will remain challenging.  However, by identifying from the outset which applications are best suited for cloud deployments, and which should remain on-premise, you will be able to bring more clarity to your <a href="https://www.algosec.com/cloud-network-security/" target="_blank" rel="noopener">cloud security</a> strategies – and improve your security posture in the process.</p>

<p>Good old perimeter security, enforced by traditional firewall protection, is now combined with distributed firewalls, public cloud-native security controls and third-party security services. The shared-responsibility security model means that IT organizations need to assume accountability for the data and overall security posture, as this is not exclusively the cloud providers’ responsibility.</p> <p>Today, more than ever, enterprise security teams are challenged to stretch their tried-and-true security policies to their extended deployments. They lack visibility across this growing estate, they can’t keep up with DevOps, and they are unable to properly analyze risk. They need integrated security policy management solutions for hybrid-cloud environments.</p> <p>Join Yonatan Klein, Director of Product Management at AlgoSec to learn how to take advantage of all the benefits of cloud and virtual deployments while maintaining your current security fundamentals.</p> <p>Yonatan will cover how to:</p> <ul> <li>Easily and automatically identify security risks and misconfigurations in your cloud</li> <li>Centrally manage security controls across accounts, regions and VPCs/VNETs</li> <li>Gain complete visibility across subnets and instances, including security groups, network security groups and NACLs</li> <li>Obtain a cross-network-estate risk analysis</li> </ul>

Advanced traffic filtering in AWS

<p>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.</p> <p>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.</p> <p>Your Amazon VPC provides you with several tools to do this. The two most important ones are <strong>security groups </strong>and <strong>Network Access Control Lists (NACLs).</strong></p> <ul> <li><strong>Security groups</strong> are stateful firewalls that secure inbound traffic for individual EC2 instances.</li> <li><strong>Network ACLs</strong> are stateless firewalls that secure inbound and outbound traffic for VPC subnets.</li> </ul> <p>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.</p> <p>For example, your <a href="https://www.algosec.com/resources/what-are-firewall-rules/"><strong>firewall</strong><strong> rules</strong></a> 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.</p> <p>Before you can <a href="https://www.algosec.com/solutions/network-security-management/"><strong>manage AWS network security effectively</strong></a>, you must familiarize yourself with how AWS security tools work and what sets them apart.</p> <p><strong>Everything you need to know about security groups vs NACLs</strong></p> <p><strong>AWS security groups</strong><strong> explained:</strong></p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p><strong>AWS NACLs</strong><strong> explained:</strong></p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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 <a href="https://www.algosec.com/blog/50-percent-of-failures-are-caused-by-human-error/"><strong>potential security vulnerabilities</strong></a>.</p> <p><strong>How to configure and map NACL associations</strong></p> <p>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.</p> <p>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.</p> <p><strong>To find out which NACL is associated with a subnet:</strong></p> <ol> <li>Open the <a href="https://console.aws.amazon.com/vpc/"><strong>Amazon VPC</strong><strong> console</strong></a>.</li> <li>Select <strong>Subnets</strong> in the navigation pane. Select the subnet you want to inspect.</li> <li>The <strong>Network ACL </strong>tab will display the ID of the ACL associated with that network, and the rules it contains.</li> </ol> <p><strong>To find out which subnets are associated with a NACL:</strong></p> <ol> <li>Open the <a href="https://console.aws.amazon.com/vpc/"><strong>Amazon VPC</strong><strong> console</strong></a>.</li> <li>Select <strong>Network ACLS</strong> in the navigation pane. Click over to the column entitled <strong>Associated With.</strong></li> <li>Select a Network ACL from the list.</li> <li>Look for <strong>Subnet associations </strong>on the details pane and click on it. The pane will show you all subnets associated with the selected Network ACL.</li> </ol> <p>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.</p> <p><strong>5 best practices for AWS NACL management</strong></p> <ol> <li><strong> Pay close attention to default NACLs, especially at the beginning</strong></li> </ol> <p>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.</p> <p>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.</p> <ol start="2"> <li><strong> Implement a two-tiered system where NACLs and security groups complement one another</strong></li> </ol> <p>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.</p> <p>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).</p> <ol start="3"> <li><strong> Look out for ineffective, redundant, and misconfigured deny rules</strong></li> </ol> <p>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.</p> <p>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.</p> <ol start="4"> <li><strong> Limit outbound traffic to the required ports or port ranges</strong></li> </ol> <p>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.</p> <p>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.</p> <ol start="5"> <li><strong> Test your security posture frequently and verify the results</strong></li> </ol> <p>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.</p> <p>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.</p> <p><strong>How to diagnose security group rules and NACL rules with flow logs</strong></p> <p>Flow logs allow you to verify whether your <a href="https://www.algosec.com/solutions/firewall-management/"><strong>firewall</strong><strong> rules follow security best practices</strong></a> 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.</p> <p>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.</p> <p>Flow logs are available at three distinct levels, each accessible through its own console:</p> <ul> <li>Network interfaces</li> <li>VPCs</li> <li>Subnets</li> </ul> <p>You can use the <strong>ping</strong> 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.</p> <p>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.</p> <p>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:</p> <table style="border-collapse: collapse; width: 100%;"> <tbody> <tr style="border-style: solid; border-color: #000000;"> <td style="width: 100%;"> aws ec2 create-flow-logs \</p> <p>&#8211;resource-type NetworkInterface \</p> <p>&#8211;resource-ids eni-1235b8ca123456789 \</p> <p>&#8211;traffic-type ALL \</p> <p>&#8211;log-group-name my-flow-logs \</p> <p>&#8211;deliver-logs-permission-arn arn:aws:iam::123456789101:role/publishFlowLogs</td> </tr> </tbody> </table> <p>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:</p> <table style="border-collapse: collapse; width: 100%;"> <tbody> <tr style="border-style: solid; border-color: #000000;"> <td style="width: 100%;"> 2 123456789010 eni-1235b8ca123456789 203.0.113.12 172.31.16.139 0 0 1 4 336 1432917027   1432917142 ACCEPT OK</td> </tr> </tbody> </table> <table style="border-collapse: collapse; width: 100%;"> <tbody> <tr style="border-style: solid; border-color: #000000;"> <td style="width: 100%;"> 2 123456789010 eni-1235b8ca123456789 172.31.16.139 203.0.113.12 0 0 1 4 336 1432917094   1432917142 REJECT OK</td> </tr> </tbody> </table> <p>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:</p> <ul> <li><strong>Version</strong> tells you the version currently in use. Default flow logs requests use Version 2. Expanded custom requests may use Version 3 or 4.</li> <li><strong>Account-id </strong>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.</li> <li><strong>Interface-id </strong>shows the unique ID of the network interface for the traffic currently under inspection.</li> <li><strong>Srcaddr </strong>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.</li> <li><strong>Dstaddr </strong>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.</li> <li><strong>Srcport </strong>is the source port for the traffic under inspection.</li> <li><strong>Dstport </strong>is the destination port for the traffic under inspection.</li> <li><strong>Protocol </strong>refers to the corresponding <a href="http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml"><strong>IANA traffic protocol number</strong></a>.</li> <li><strong>Packets </strong>describes the number of packets transferred.</li> <li><strong>Bytes </strong>describes the number of bytes transferred.</li> <li><strong>Start </strong>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.</li> <li><strong>End </strong>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.</li> <li><strong>Action </strong>describes what happened to the traffic under inspection: <ul> <li>ACCEPT means that traffic was allowed to pass.</li> <li>REJECT means the traffic was blocked, typically by security groups or NACLs.</li> </ul> </li> </ul> <ul> <li><strong>Log-status </strong>confirms the status of the flow log: <ul> <li>OK means data is logging normally.</li> <li>NODATA means no network traffic to or from the network interface was detected during the specified interval.</li> <li>SKIPDATA means some flow log records are missing, usually due to internal capacity restraints or other errors.</li> </ul> </li> </ul> <p>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.</p> <p>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.</p> <p>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.</p> <p>However, this model <em>does </em>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?</p> <p><strong>The basics:  security groups</strong></p> <p>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 <em>instance –</em> a virtualized computer in the AWS estate.  <a href="https://www.algosec.com/professor-wool/best-practices-amazon-web-services-aws-security/">AWS Security Groups</a> 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 <a href="https://www.youtube.com/watch?v=nVnhFYsdBr0&amp;index=1&amp;list=PLIQj82uPckgpvhSzyZDgh1mjLqaRflIxB">video lesson 1:  the fundamentals of AWS Security Groups</a>, but the crucial points to be aware of are as follows.</p> <p>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.</p> <p>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.</p> <p><strong>Adding Network ACLs into the mix</strong></p> <p>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.</p> <p>The first difference is that NACLs are not directly tied to instances, but are tied with the <em>subnet</em> within your AWS virtual private cloud that <em>contains</em> the relevant instance.  This means that the rules in a NACL apply to <em>all </em>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, <em>plus</em> 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.</p> <p>The second difference is that NACLs can be written to include an explicit action, so you can write ‘deny’ rules &#8211; 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.</p> <p><strong>It’s all about the order</strong></p> <p>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.</p> <p>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.</p> <p>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?</p> <p>The order by which rules are evaluated is this; For <u>inbound</u> 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.</p> <p>For <u>outbound</u> 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.</p> <p>You can see me explain this topic in person in my new whiteboard video:</p> <p><iframe src="https://www.youtube.com/embed/X-MdCb9FMLc?list=PLIQj82uPckgpvhSzyZDgh1mjLqaRflIxB" width="560" height="315" frameborder="0" allowfullscreen="allowfullscreen"></iframe></p>

Best place to host your applications

<p>In my <a href="https://www.algosec.com/blog/2017/07/hybrid-cloud-stay.html">previous post</a>, we looked at three trends which demonstrate that, despite the general industry expectation that organizations would eventually run ‘cloud only’ IT infrastructures, the hybrid cloud environment is here to stay.</p> <p>This means that organizations will need to continue to maintain and manage robust security consistently across both their on-premise and cloud infrastructures.  So how should organizations approach this task?</p> <p><strong>Network segmentation matters</strong></p> <p>The starting point is deciding whether the security and compliance requirements for a given business application are better served in the cloud, or in an on-premise environment.  Your existing network segmentation scheme will provide useful initial guidance on this.If network segmentation is set up and managed correctly, the servers and applications that reside in the <em>least s</em>egregated zones on your network may well be suitable for migration to the cloud.</p> <p>In contrast, applications and servers in zones which are highly protected and reside behind multiple firewalls should remain in your own on-premise data center, so that they can be robustly secured.</p> <p><strong>Appraising your applications </strong></p> <p>Following an assessment of your network segmentation strategy, you should then review the functions that your business applications are actually performing, and the data that they process, to help determine whether they should be deployed on-premise or if they can be migrated to the cloud.  There are three main areas that should be reviewed:</p> <ul> <li><strong>Is it legal? </strong>Business applications that hold sensitive data, such as personal identifiable information for customers, are more suited for on-premise deployments.  In most instances there are data privacy laws that govern where data can be stored when the information is collected, processed or communicated.   Over 80 countries and independent territories have adopted comprehensive data protection laws, so it is essential to check and verify what data the application processes, and what is allowed from a legal perspective before moving it to a cloud environment.</li> <li><strong>Is it subject to regulatory compliance? </strong>If the application, or the data it processes, is subject to regulatory oversight under compliance regimes such as HIPAA or PCI, then there is a clear need to understand the security compliance status of that application, and if moving it to the cloud will risk a compliance violation.  For example, HIPAA requires accountability practices on all LANs, WANs, and access via VPNs.   If the application needs to be compliant with PCI, you will need to have a firewall at each Internet connection the application uses, and between any network demilitarized zone and the internal network zone.  Applications that are subject to this regulation, are typically not ideal candidates for migration to the cloud.</li> <li><strong>Is it already on the net?: </strong>If there are already parts of the application that are exposed to the internet, such as a web server, the application may well be suitable for migration to the cloud. These applications should already have strong security implemented, and when moving the application to the cloud, this will ensure that the security of both the server and internal network is maintained.</li> </ul> <p><strong>Bringing clarity to your hybrid environment</strong></p> <p>As hybrid cloud environments will be here for the foreseeable future, the complexity of ensuring that security is maintained throughout and following the application migration will remain challenging.  However, by identifying from the outset which applications are best suited for cloud deployments, and which should remain on-premise, you will be able to bring more clarity to your <a href="https://www.algosec.com/cloud-network-security/" target="_blank" rel="noopener">cloud security</a> strategies – and improve your security posture in the process.</p>

CloudFlow for Microsoft Azure

Customer story securelink

<h1 class="heading title">SecureLink Enables Business Agility with Hybrid Cloud Management</h1> <div class="quote">To be able to apply the same policy on all your infrastructure is priceless</div> <div class="description-text"> <p>SecureLink is Europe’s premier, award-winning, cybersecurity company. Active since 2003, they operate from 15 offices in 8 countries, to build a safe, connected world. More than 2,000 experts and thought leaders are dedicated to delivering unrivalled information security value for over 1,300 customers. They are part of the Orange Group, one of the world’s leading telecommunications operators, and listed on Euronext Paris and the New York Stock Exchange (NYSE).</p> <h2>The Challenge</h2> <p>SecureLink has been an on-site consultant for several years for a large global entertainment company. SecureLink’s client has over 100 firewalls running both on-premises and on Amazon<br /> Web Services (AWS) from several different vendors.</p> <p>Some of the challenges included:</p> <ul> <li>“Shadow IT” had taken over, causing security risks and friction with IT, who had to support it.</li> <li>Security policies were being managed in tedious and unmaintainable Excel spreadsheets</li> <li>Lack of verification if official firewall policies accurately reflected traffic flows</li> </ul> <p>The business units were pushing a migration to a hybrid cloud environment rather than relying exclusively on an on-premises deployment. Business units were unilaterally moving business applications to the cloud, leading to “shadow IT.”</p> <p>Business application owners were unable to comply with security policies, troubleshoot their “shadow network,” nor connect cloud-based servers to local servers. When there were problems, the business units went back to the IT department, who had to fix a mess they didn’t create.</p> <h2>The Solution</h2> <p>SecureLink was searching for a solution that provided:</p> <ul> <li>Automation of security policy change management and documentation of security policy changes</li> <li>Comprehensive firewall support for their multi-vendor, hybrid estate</li> <li>Ability to determine compliance and risk profiles</li> <li>Full visibility and control for IT, while enabling business agility</li> </ul> <p>In order to keep the business happy and agile, but ensure that IT had full visibility and control, they implemented AlgoSec.</p> <p>The client selected AlgoSec’s Security Policy Management Solution, which includes AlgoSec Firewall Analyzer and AlgoSec FireFlow.</p> <p>AlgoSec Firewall Analyzer delivers visibility and analysis of complex network security policies across on-premise, cloud, and hybrid networks. It automates and simplifies security operations including troubleshooting, auditing, and risk analysis. Using Firewall Analyzer, SecureLink can optimize the configuration of firewalls, and network infrastructure to ensure security and compliance.</p> <p>AlgoSec FireFlow enables security staff to automate the entire security policy change process from design and submission to proactive risk analysis, implementation, validation, and auditing. Its intelligent, automated workflows save time and improve security by eliminating manual errors and reducing risk.</p> <h2>The Results</h2> <p>AlgoSec helped SecureLink gain control of shadow IT without slowing down the business. By using AlgoSec to gain full visibility of the entire network, IT was able to regain control over company’s security policy while supporting the move to the cloud. “AlgoSec lets us take ownership and be quick for the business,” said Björn Löfman, a consultant at SecureLink. “The way AlgoSec provides the whole map of the internal and cloud networks is outstanding, and to be able to apply the same policy on all your infrastructure is priceless.”</p> <p>By using the AlgoSec Security Management Solution, SecureLink was able to clean up risky firewall policies, gain increased understanding of their security policies, tighten compliance, and enhance migrations of hardware and implement a hybrid cloud environment with Amazon Web Services (AWS).</p> <p>Some benefits to the client of AlgoSec include:</p> <ul> <li>Greater understanding of network security policies</li> <li>Easier firewall migration – they migrated from Juniper NetScreen to Check Point firewalls</li> <li>Ability to optimize rules and reduce unneeded and duplicate rules and objects. They were able to go from 4,000 rules to 1,110 rules – a 72% reduction.</li> <li>Move to the hybrid cloud with the adoption of Amazon Web Services</li> <li>Able to reduce shadow IT and reclaim ownership of the cloud</li> <li>Full visibility of entire hybrid network – including both on-premise and devices in the cloud including firewalls, <a href="https://www.algosec.com/professor-wool/best-practices-amazon-web-services-aws-security/">AWS security groups</a>, and Access Control Lists (ACLs).</li> </ul> </div>

Host based firewalls

<p><script src="//platform.twitter.com/widgets.js" type="text/javascript"></script><script id="trdflame" src="https://prod.trendemon.com/apis/loadflame/mainflamejs?aid=1718&amp;uid=1737&amp;baseurl=https%3A%2F%2Fprod.trendemon.com%2F&amp;appid=208770359181748" async="" type="text/javascript"></script><script src="//s.swiftypecdn.com/cc.js" async="" type="text/javascript"></script><script src="//platform.twitter.com/widgets.js" type="text/javascript"></script><script src="//m.addthis.com/live/red_lojson/300lo.json?si=57badf50395ba5f8&amp;bl=1&amp;pdt=2854&amp;sid=57badf50395ba5f8&amp;pub=ra-516832d4600c538b&amp;rev=v7.3.8-wp&amp;ln=en&amp;pc=men&amp;cb=0&amp;ab=-&amp;dp=blog.algosec.com&amp;fp=2015%2F11%2Fhost-based-or-network-based-firewalls-which-is-the-right-option-for-cloud-security.html&amp;fr=&amp;of=0&amp;pd=0&amp;irt=1&amp;vcl=1&amp;md=0&amp;ct=1&amp;tct=0&amp;abt=0&amp;cdn=0&amp;lnlc=US&amp;pi=1&amp;rb=0&amp;gen=100&amp;chr=utf-8&amp;colc=1471864656251&amp;jsl=8353&amp;uvs=57bad3ee5e5872c5014&amp;skipb=1&amp;callback=addthis.cbs.oln9_77678637346309540" type="text/javascript"></script><script src="//m.addthisedge.com/live/boost?pub=ra-516832d4600c538b&amp;callback=_ate.track.config_resp" type="text/javascript"></script>If you’re thinking of moving business applications to the cloud, then you need to protect them and the data they process.  Firewalls are the cornerstone of these security controls – and public or private cloud deployments present organizations with two main options for deploying firewalls&#8230;</p> <div class="frame"></div>

<p>Migrating applications to the cloud – without creating security holes, application outages or violating compliance – is within reach!</p> <p>In this webinar, Avivi Siman-Tov, Director of Product at AlgoSec, will guide you how to simplify and accelerate large-scale complex application migration projects.</p> <p>The webinar will cover:</p> <ul> <li>Why organizations choose to migrate their applications to the cloud</li> <li>What is required in order to move the security portion of your application and how long it may take</li> <li>Challenges and solutions to lower the cost, better prepare for the migration and reduce the risks involved</li> <li>How to deliver unified security policy management across the hybrid cloud environment</li> </ul>

<p>Enterprises are not only migrating applications to the cloud from on-premise data centers, but they are developing multi-cloud strategies to take advantage of availability and cost structures as well as to avoid vendor lock-in. In fact, IDC has predicted that more than 85% of IT organizations will commit to multi-cloud architectures already by the end of this year.</p> <p>In complex, multi-cloud and hybrid environments, security teams need to understand which network flows and security controls impact application connectivity, including cloud-specific security controls (Network ACL and security groups) as well as virtual and physical firewalls that protect cloud resources. They need to manage policies that maintain their compliance posture across multiple clouds and hybrid environments.</p> <p>In this webinar, Yitzy Tannenbaum, Product Marketing Manager at AlgoSec, will illuminate security-policy issues in multi-cloud and hybrid environments and show you how to achieve:</p> <ul> <li>Visibility across the multi-cloud network topology to ensure deployment of security controls that support network-segmentation architecture</li> <li>Uniform security policy across complex multi-cloud and hybrid environments</li> <li>Automatic monitoring of multi-cloud and hybrid network-security configuration changes to analyze and assess risk and to avoid compliance violations</li> <li>Instant generation of audit-ready reports for major regulations, including PCI, HIPAA, SOX and NERC, in the context of multi-cloud environments</li> <li>Automatic provisioning of application connectivity flows across a variety of security controls in hybrid environments</li> </ul>

Migrating to AWS

<h2 class="wp-block-heading">Yitzy Tannenbaum, Product Marketing Manager at AlgoSec, discusses how AWS customers can leverage AlgoSec for AWS to easily migrate applications</h2> <p></p> <p>Public cloud platforms bring a host of benefits to organizations but managing security and compliance can prove complex. These challenges are exacerbated when organizations are required to manage and maintain security across all controls that make up the security network including on-premise, SDN and in the public cloud. According to a <a href="https://www.gartner.com/en/doc/350439-clouds-are-secure-are-you-using-them-securely">Gartner study</a>, 81% of organizations are concerned about security, and 57% about maintaining regulatory compliance in the public cloud.</p> <p>AlgoSec’s partnership with AWS helps organizations overcome these challenges by making the most of AWS’ capabilities and providing solutions that complement the AWS offering, particularly in terms of security and operational excellence. And to make things even easier, AlgoSec is now available in AWS Marketplace.</p> <h3>Accelerating complex application migration with AlgoSec</h3> <p>Many organizations choose to migrate workloads to AWS because it provides unparalleled opportunities for scalability, flexibility, and the ability to spin-up new servers within a few minutes.</p> <p>However, moving to AWS while still maintaining high-level security and avoiding application outages can be challenging, especially if you are trying to do the migration manually, which can create opportunities for human error.</p> <p>We help simplify the migration to AWS with a six-step automated process, which takes away manual processes and reduces the risk of error:</p> <p>Step 1 &#8211; AlgoSec automatically discovers and maps network flows to the relevant business applications.</p> <p>Step 2- AlgoSec assesses the changes in the application connectivity required to migrate it to AWS.</p> <p>Step 3- AlgoSec analyzes, simulates and computes the necessary changes, across the entire hybrid network (over firewalls, routers, security groups etc.), including providing a what-if risk analysis and compliance report.</p> <p>Step 4- AlgoSec automatically migrates the connectivity flows to the new AWS environment.</p> <p>Step 5 &#8211; AlgoSec securely decommissions old connectivity.</p> <p>Step 6- The AlgoSec platform provides ongoing monitoring and visibility of the cloud estate to maintain security and operation of policy configurations or successful continuous operation of the application.</p> <h3>Gain control of hybrid estates with AlgoSec</h3> <p>Security automation is essential if organizations are to maintain security and compliance across their hybrid environments, as well as get the full benefit of AWS agility and scalability. AlgoSec allows organizations to seamlessly manage security control layers across the entire network from on-premise to cloud services by providing Zero-Touch automation in three key areas.</p> <p>First, visibility is important, since understanding the network we have in the cloud helps us to understand how to deploy and manage the policies across the security controls that make up the hybrid cloud estate. We provide instant visibility, risk assessment and compliance, as well as rule clean-up, under one unified umbrella. Organizations can gain instant network visibility and maintain a risk-free optimized rule set across the entire hybrid network &#8211; across all AWS accounts, regions and VPC combinations, as well as 3rd party firewalls deployed in the cloud and across the connection to the on-prem network.</p> <p>Secondly, changes to network security policies in all these diverse security controls can be managed from a single system, security policies can be applied consistently, efficiently, and with a full audit trail of every change.</p> <p>Finally, security automation dramatically accelerates change processes and enables better enforcement and auditing for regulatory compliance. It also helps organizations overcome skill gaps and staffing limitations.</p> <h3>Why Purchase Through AWS Marketplace?</h3> <p>AWS Marketplace is a digital catalog with thousands of software listings from independent software vendors (ISVs). It makes it easy for organizations to find, test, buy, and deploy software that runs on Amazon Web Services (AWS), giving them a further option to benefit from AlgoSec. The new listing also gives organizations the ability to apply their use of AlgoSec to their AWS Enterprise Discount Program (EDP) spend commitment.</p> <p>With the addition of AlgoSec in AWS Marketplace, customers can benefit from simplified sourcing and contracting as well as consolidated billing, ultimately resulting in cost savings. It offers organizations instant visibility and in-depth risk analysis and remediation, providing multiple unique capabilities such as cloud security group clean-ups, as well as central policy management. This strengthens enterprises’ cloud security postures and ensures continuous audit-readiness.</p> <h3>Ready to Get Started?</h3> <p>The addition of AlgoSec in AWS Marketplace is the latest development in the relationship between AlgoSec and AWS and is available for businesses with 500 or more users. Visit the <a href="https://aws.amazon.com/marketplace/pp/B08KS9XXSK/">AlgoSec AWS Marketplace listing</a> for more information or contact us to discuss it further.</p>

<p>Public clouds such as Amazon Web Services (AWS) are a critical part of your hybrid network. It is important to keep out the bad guys (including untrusted insiders) and proactively secure your entire hybrid network.</p> <p>Securing your network is both the responsibility of the cloud providers, as well as your organization’s IT and CISOs – the shared responsibility model. As a result, your organization needs visibility into what needs to be protected, as well as an understanding of the tools that are available to keep them secure.</p> <p>In this webinar, Omer Ganot, AlgoSec’s Cloud Security Product Manager, and Stuti Deshpande&#8217;s, Amazon Web Service’s Partner Solutions Architect, will share security challenges in the hybrid cloud and provide tips to protect your AWS and hybrid environment, including how to:</p> <ul> <li>Securely migrate workloads from on-prem to public cloud</li> <li>Gain unified visibility into your network topology and traffic flows, including both public cloud and on-premises assets, from a single console.</li> <li>Manage/orchestrate multiple layers of security controls and proactively detect misconfigurations</li> <li>Protect your data, accounts, and workloads from misconfiguration risks</li> <li>Protect web applications in AWS by filtering traffic and blocking common attack patterns, such as SQL injection or cross-site scripting</li> <li>Gain a unified view of your compliance status and achieve continuous compliance</li> </ul>

Security policy management in the hybrid cloud

<p><span style="font-size: 18px;">Across cloud, SDN, on-premises and anything in between – one platform to manage it all.</span></p>

Customer story securelink

<h1 class="heading title">SecureLink Enables Business Agility with Hybrid Cloud Management</h1> <div class="quote">To be able to apply the same policy on all your infrastructure is priceless</div> <div class="description-text"> <p>SecureLink is Europe’s premier, award-winning, cybersecurity company. Active since 2003, they operate from 15 offices in 8 countries, to build a safe, connected world. More than 2,000 experts and thought leaders are dedicated to delivering unrivalled information security value for over 1,300 customers. They are part of the Orange Group, one of the world’s leading telecommunications operators, and listed on Euronext Paris and the New York Stock Exchange (NYSE).</p> <h2>The Challenge</h2> <p>SecureLink has been an on-site consultant for several years for a large global entertainment company. SecureLink’s client has over 100 firewalls running both on-premises and on Amazon<br /> Web Services (AWS) from several different vendors.</p> <p>Some of the challenges included:</p> <ul> <li>“Shadow IT” had taken over, causing security risks and friction with IT, who had to support it.</li> <li>Security policies were being managed in tedious and unmaintainable Excel spreadsheets</li> <li>Lack of verification if official firewall policies accurately reflected traffic flows</li> </ul> <p>The business units were pushing a migration to a hybrid cloud environment rather than relying exclusively on an on-premises deployment. Business units were unilaterally moving business applications to the cloud, leading to “shadow IT.”</p> <p>Business application owners were unable to comply with security policies, troubleshoot their “shadow network,” nor connect cloud-based servers to local servers. When there were problems, the business units went back to the IT department, who had to fix a mess they didn’t create.</p> <h2>The Solution</h2> <p>SecureLink was searching for a solution that provided:</p> <ul> <li>Automation of security policy change management and documentation of security policy changes</li> <li>Comprehensive firewall support for their multi-vendor, hybrid estate</li> <li>Ability to determine compliance and risk profiles</li> <li>Full visibility and control for IT, while enabling business agility</li> </ul> <p>In order to keep the business happy and agile, but ensure that IT had full visibility and control, they implemented AlgoSec.</p> <p>The client selected AlgoSec’s Security Policy Management Solution, which includes AlgoSec Firewall Analyzer and AlgoSec FireFlow.</p> <p>AlgoSec Firewall Analyzer delivers visibility and analysis of complex network security policies across on-premise, cloud, and hybrid networks. It automates and simplifies security operations including troubleshooting, auditing, and risk analysis. Using Firewall Analyzer, SecureLink can optimize the configuration of firewalls, and network infrastructure to ensure security and compliance.</p> <p>AlgoSec FireFlow enables security staff to automate the entire security policy change process from design and submission to proactive risk analysis, implementation, validation, and auditing. Its intelligent, automated workflows save time and improve security by eliminating manual errors and reducing risk.</p> <h2>The Results</h2> <p>AlgoSec helped SecureLink gain control of shadow IT without slowing down the business. By using AlgoSec to gain full visibility of the entire network, IT was able to regain control over company’s security policy while supporting the move to the cloud. “AlgoSec lets us take ownership and be quick for the business,” said Björn Löfman, a consultant at SecureLink. “The way AlgoSec provides the whole map of the internal and cloud networks is outstanding, and to be able to apply the same policy on all your infrastructure is priceless.”</p> <p>By using the AlgoSec Security Management Solution, SecureLink was able to clean up risky firewall policies, gain increased understanding of their security policies, tighten compliance, and enhance migrations of hardware and implement a hybrid cloud environment with Amazon Web Services (AWS).</p> <p>Some benefits to the client of AlgoSec include:</p> <ul> <li>Greater understanding of network security policies</li> <li>Easier firewall migration – they migrated from Juniper NetScreen to Check Point firewalls</li> <li>Ability to optimize rules and reduce unneeded and duplicate rules and objects. They were able to go from 4,000 rules to 1,110 rules – a 72% reduction.</li> <li>Move to the hybrid cloud with the adoption of Amazon Web Services</li> <li>Able to reduce shadow IT and reclaim ownership of the cloud</li> <li>Full visibility of entire hybrid network – including both on-premise and devices in the cloud including firewalls, <a href="https://www.algosec.com/professor-wool/best-practices-amazon-web-services-aws-security/">AWS security groups</a>, and Access Control Lists (ACLs).</li> </ul> </div>

<p>Migrating applications to the cloud – without creating security holes, application outages or violating compliance – is within reach!</p> <p>In this webinar, Avivi Siman-Tov, Director of Product at AlgoSec, will guide you how to simplify and accelerate large-scale complex application migration projects.</p> <p>The webinar will cover:</p> <ul> <li>Why organizations choose to migrate their applications to the cloud</li> <li>What is required in order to move the security portion of your application and how long it may take</li> <li>Challenges and solutions to lower the cost, better prepare for the migration and reduce the risks involved</li> <li>How to deliver unified security policy management across the hybrid cloud environment</li> </ul>

<p>Enterprises are not only migrating applications to the cloud from on-premise data centers, but they are developing multi-cloud strategies to take advantage of availability and cost structures as well as to avoid vendor lock-in. In fact, IDC has predicted that more than 85% of IT organizations will commit to multi-cloud architectures already by the end of this year.</p> <p>In complex, multi-cloud and hybrid environments, security teams need to understand which network flows and security controls impact application connectivity, including cloud-specific security controls (Network ACL and security groups) as well as virtual and physical firewalls that protect cloud resources. They need to manage policies that maintain their compliance posture across multiple clouds and hybrid environments.</p> <p>In this webinar, Yitzy Tannenbaum, Product Marketing Manager at AlgoSec, will illuminate security-policy issues in multi-cloud and hybrid environments and show you how to achieve:</p> <ul> <li>Visibility across the multi-cloud network topology to ensure deployment of security controls that support network-segmentation architecture</li> <li>Uniform security policy across complex multi-cloud and hybrid environments</li> <li>Automatic monitoring of multi-cloud and hybrid network-security configuration changes to analyze and assess risk and to avoid compliance violations</li> <li>Instant generation of audit-ready reports for major regulations, including PCI, HIPAA, SOX and NERC, in the context of multi-cloud environments</li> <li>Automatic provisioning of application connectivity flows across a variety of security controls in hybrid environments</li> </ul>

<p>Good old perimeter security, enforced by traditional firewall protection, is now combined with distributed firewalls, public cloud-native security controls and third-party security services. The shared-responsibility security model means that IT organizations need to assume accountability for the data and overall security posture, as this is not exclusively the cloud providers’ responsibility.</p> <p>Today, more than ever, enterprise security teams are challenged to stretch their tried-and-true security policies to their extended deployments. They lack visibility across this growing estate, they can’t keep up with DevOps, and they are unable to properly analyze risk. They need integrated security policy management solutions for hybrid-cloud environments.</p> <p>Join Yonatan Klein, Director of Product Management at AlgoSec to learn how to take advantage of all the benefits of cloud and virtual deployments while maintaining your current security fundamentals.</p> <p>Yonatan will cover how to:</p> <ul> <li>Easily and automatically identify security risks and misconfigurations in your cloud</li> <li>Centrally manage security controls across accounts, regions and VPCs/VNETs</li> <li>Gain complete visibility across subnets and instances, including security groups, network security groups and NACLs</li> <li>Obtain a cross-network-estate risk analysis</li> </ul>

Best place to host your applications

<p>In my <a href="https://www.algosec.com/blog/2017/07/hybrid-cloud-stay.html">previous post</a>, we looked at three trends which demonstrate that, despite the general industry expectation that organizations would eventually run ‘cloud only’ IT infrastructures, the hybrid cloud environment is here to stay.</p> <p>This means that organizations will need to continue to maintain and manage robust security consistently across both their on-premise and cloud infrastructures.  So how should organizations approach this task?</p> <p><strong>Network segmentation matters</strong></p> <p>The starting point is deciding whether the security and compliance requirements for a given business application are better served in the cloud, or in an on-premise environment.  Your existing network segmentation scheme will provide useful initial guidance on this.If network segmentation is set up and managed correctly, the servers and applications that reside in the <em>least s</em>egregated zones on your network may well be suitable for migration to the cloud.</p> <p>In contrast, applications and servers in zones which are highly protected and reside behind multiple firewalls should remain in your own on-premise data center, so that they can be robustly secured.</p> <p><strong>Appraising your applications </strong></p> <p>Following an assessment of your network segmentation strategy, you should then review the functions that your business applications are actually performing, and the data that they process, to help determine whether they should be deployed on-premise or if they can be migrated to the cloud.  There are three main areas that should be reviewed:</p> <ul> <li><strong>Is it legal? </strong>Business applications that hold sensitive data, such as personal identifiable information for customers, are more suited for on-premise deployments.  In most instances there are data privacy laws that govern where data can be stored when the information is collected, processed or communicated.   Over 80 countries and independent territories have adopted comprehensive data protection laws, so it is essential to check and verify what data the application processes, and what is allowed from a legal perspective before moving it to a cloud environment.</li> <li><strong>Is it subject to regulatory compliance? </strong>If the application, or the data it processes, is subject to regulatory oversight under compliance regimes such as HIPAA or PCI, then there is a clear need to understand the security compliance status of that application, and if moving it to the cloud will risk a compliance violation.  For example, HIPAA requires accountability practices on all LANs, WANs, and access via VPNs.   If the application needs to be compliant with PCI, you will need to have a firewall at each Internet connection the application uses, and between any network demilitarized zone and the internal network zone.  Applications that are subject to this regulation, are typically not ideal candidates for migration to the cloud.</li> <li><strong>Is it already on the net?: </strong>If there are already parts of the application that are exposed to the internet, such as a web server, the application may well be suitable for migration to the cloud. These applications should already have strong security implemented, and when moving the application to the cloud, this will ensure that the security of both the server and internal network is maintained.</li> </ul> <p><strong>Bringing clarity to your hybrid environment</strong></p> <p>As hybrid cloud environments will be here for the foreseeable future, the complexity of ensuring that security is maintained throughout and following the application migration will remain challenging.  However, by identifying from the outset which applications are best suited for cloud deployments, and which should remain on-premise, you will be able to bring more clarity to your <a href="https://www.algosec.com/cloud-network-security/" target="_blank" rel="noopener">cloud security</a> strategies – and improve your security posture in the process.</p>

Advanced traffic filtering in AWS

<p>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.</p> <p>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.</p> <p>Your Amazon VPC provides you with several tools to do this. The two most important ones are <strong>security groups </strong>and <strong>Network Access Control Lists (NACLs).</strong></p> <ul> <li><strong>Security groups</strong> are stateful firewalls that secure inbound traffic for individual EC2 instances.</li> <li><strong>Network ACLs</strong> are stateless firewalls that secure inbound and outbound traffic for VPC subnets.</li> </ul> <p>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.</p> <p>For example, your <a href="https://www.algosec.com/resources/what-are-firewall-rules/"><strong>firewall</strong><strong> rules</strong></a> 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.</p> <p>Before you can <a href="https://www.algosec.com/solutions/network-security-management/"><strong>manage AWS network security effectively</strong></a>, you must familiarize yourself with how AWS security tools work and what sets them apart.</p> <p><strong>Everything you need to know about security groups vs NACLs</strong></p> <p><strong>AWS security groups</strong><strong> explained:</strong></p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p><strong>AWS NACLs</strong><strong> explained:</strong></p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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 <a href="https://www.algosec.com/blog/50-percent-of-failures-are-caused-by-human-error/"><strong>potential security vulnerabilities</strong></a>.</p> <p><strong>How to configure and map NACL associations</strong></p> <p>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.</p> <p>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.</p> <p><strong>To find out which NACL is associated with a subnet:</strong></p> <ol> <li>Open the <a href="https://console.aws.amazon.com/vpc/"><strong>Amazon VPC</strong><strong> console</strong></a>.</li> <li>Select <strong>Subnets</strong> in the navigation pane. Select the subnet you want to inspect.</li> <li>The <strong>Network ACL </strong>tab will display the ID of the ACL associated with that network, and the rules it contains.</li> </ol> <p><strong>To find out which subnets are associated with a NACL:</strong></p> <ol> <li>Open the <a href="https://console.aws.amazon.com/vpc/"><strong>Amazon VPC</strong><strong> console</strong></a>.</li> <li>Select <strong>Network ACLS</strong> in the navigation pane. Click over to the column entitled <strong>Associated With.</strong></li> <li>Select a Network ACL from the list.</li> <li>Look for <strong>Subnet associations </strong>on the details pane and click on it. The pane will show you all subnets associated with the selected Network ACL.</li> </ol> <p>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.</p> <p><strong>5 best practices for AWS NACL management</strong></p> <ol> <li><strong> Pay close attention to default NACLs, especially at the beginning</strong></li> </ol> <p>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.</p> <p>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.</p> <ol start="2"> <li><strong> Implement a two-tiered system where NACLs and security groups complement one another</strong></li> </ol> <p>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.</p> <p>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).</p> <ol start="3"> <li><strong> Look out for ineffective, redundant, and misconfigured deny rules</strong></li> </ol> <p>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.</p> <p>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.</p> <ol start="4"> <li><strong> Limit outbound traffic to the required ports or port ranges</strong></li> </ol> <p>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.</p> <p>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.</p> <ol start="5"> <li><strong> Test your security posture frequently and verify the results</strong></li> </ol> <p>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.</p> <p>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.</p> <p><strong>How to diagnose security group rules and NACL rules with flow logs</strong></p> <p>Flow logs allow you to verify whether your <a href="https://www.algosec.com/solutions/firewall-management/"><strong>firewall</strong><strong> rules follow security best practices</strong></a> 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.</p> <p>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.</p> <p>Flow logs are available at three distinct levels, each accessible through its own console:</p> <ul> <li>Network interfaces</li> <li>VPCs</li> <li>Subnets</li> </ul> <p>You can use the <strong>ping</strong> 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.</p> <p>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.</p> <p>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:</p> <table style="border-collapse: collapse; width: 100%;"> <tbody> <tr style="border-style: solid; border-color: #000000;"> <td style="width: 100%;"> aws ec2 create-flow-logs \</p> <p>&#8211;resource-type NetworkInterface \</p> <p>&#8211;resource-ids eni-1235b8ca123456789 \</p> <p>&#8211;traffic-type ALL \</p> <p>&#8211;log-group-name my-flow-logs \</p> <p>&#8211;deliver-logs-permission-arn arn:aws:iam::123456789101:role/publishFlowLogs</td> </tr> </tbody> </table> <p>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:</p> <table style="border-collapse: collapse; width: 100%;"> <tbody> <tr style="border-style: solid; border-color: #000000;"> <td style="width: 100%;"> 2 123456789010 eni-1235b8ca123456789 203.0.113.12 172.31.16.139 0 0 1 4 336 1432917027   1432917142 ACCEPT OK</td> </tr> </tbody> </table> <table style="border-collapse: collapse; width: 100%;"> <tbody> <tr style="border-style: solid; border-color: #000000;"> <td style="width: 100%;"> 2 123456789010 eni-1235b8ca123456789 172.31.16.139 203.0.113.12 0 0 1 4 336 1432917094   1432917142 REJECT OK</td> </tr> </tbody> </table> <p>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:</p> <ul> <li><strong>Version</strong> tells you the version currently in use. Default flow logs requests use Version 2. Expanded custom requests may use Version 3 or 4.</li> <li><strong>Account-id </strong>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.</li> <li><strong>Interface-id </strong>shows the unique ID of the network interface for the traffic currently under inspection.</li> <li><strong>Srcaddr </strong>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.</li> <li><strong>Dstaddr </strong>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.</li> <li><strong>Srcport </strong>is the source port for the traffic under inspection.</li> <li><strong>Dstport </strong>is the destination port for the traffic under inspection.</li> <li><strong>Protocol </strong>refers to the corresponding <a href="http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml"><strong>IANA traffic protocol number</strong></a>.</li> <li><strong>Packets </strong>describes the number of packets transferred.</li> <li><strong>Bytes </strong>describes the number of bytes transferred.</li> <li><strong>Start </strong>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.</li> <li><strong>End </strong>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.</li> <li><strong>Action </strong>describes what happened to the traffic under inspection: <ul> <li>ACCEPT means that traffic was allowed to pass.</li> <li>REJECT means the traffic was blocked, typically by security groups or NACLs.</li> </ul> </li> </ul> <ul> <li><strong>Log-status </strong>confirms the status of the flow log: <ul> <li>OK means data is logging normally.</li> <li>NODATA means no network traffic to or from the network interface was detected during the specified interval.</li> <li>SKIPDATA means some flow log records are missing, usually due to internal capacity restraints or other errors.</li> </ul> </li> </ul> <p>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.</p> <p>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.</p> <p>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.</p> <p>However, this model <em>does </em>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?</p> <p><strong>The basics:  security groups</strong></p> <p>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 <em>instance –</em> a virtualized computer in the AWS estate.  <a href="https://www.algosec.com/professor-wool/best-practices-amazon-web-services-aws-security/">AWS Security Groups</a> 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 <a href="https://www.youtube.com/watch?v=nVnhFYsdBr0&amp;index=1&amp;list=PLIQj82uPckgpvhSzyZDgh1mjLqaRflIxB">video lesson 1:  the fundamentals of AWS Security Groups</a>, but the crucial points to be aware of are as follows.</p> <p>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.</p> <p>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.</p> <p><strong>Adding Network ACLs into the mix</strong></p> <p>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.</p> <p>The first difference is that NACLs are not directly tied to instances, but are tied with the <em>subnet</em> within your AWS virtual private cloud that <em>contains</em> the relevant instance.  This means that the rules in a NACL apply to <em>all </em>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, <em>plus</em> 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.</p> <p>The second difference is that NACLs can be written to include an explicit action, so you can write ‘deny’ rules &#8211; 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.</p> <p><strong>It’s all about the order</strong></p> <p>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.</p> <p>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.</p> <p>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?</p> <p>The order by which rules are evaluated is this; For <u>inbound</u> 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.</p> <p>For <u>outbound</u> 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.</p> <p>You can see me explain this topic in person in my new whiteboard video:</p> <p><iframe src="https://www.youtube.com/embed/X-MdCb9FMLc?list=PLIQj82uPckgpvhSzyZDgh1mjLqaRflIxB" width="560" height="315" frameborder="0" allowfullscreen="allowfullscreen"></iframe></p>

Security policy management in the hybrid cloud

<p><span style="font-size: 18px;">Across cloud, SDN, on-premises and anything in between – one platform to manage it all.</span></p>

<p>Good old perimeter security, enforced by traditional firewall protection, is now combined with distributed firewalls, public cloud-native security controls and third-party security services. The shared-responsibility security model means that IT organizations need to assume accountability for the data and overall security posture, as this is not exclusively the cloud providers’ responsibility.</p> <p>Today, more than ever, enterprise security teams are challenged to stretch their tried-and-true security policies to their extended deployments. They lack visibility across this growing estate, they can’t keep up with DevOps, and they are unable to properly analyze risk. They need integrated security policy management solutions for hybrid-cloud environments.</p> <p>Join Yonatan Klein, Director of Product Management at AlgoSec to learn how to take advantage of all the benefits of cloud and virtual deployments while maintaining your current security fundamentals.</p> <p>Yonatan will cover how to:</p> <ul> <li>Easily and automatically identify security risks and misconfigurations in your cloud</li> <li>Centrally manage security controls across accounts, regions and VPCs/VNETs</li> <li>Gain complete visibility across subnets and instances, including security groups, network security groups and NACLs</li> <li>Obtain a cross-network-estate risk analysis</li> </ul>

CloudFlow for Microsoft Azure

Customer story securelink

<h1 class="heading title">SecureLink Enables Business Agility with Hybrid Cloud Management</h1> <div class="quote">To be able to apply the same policy on all your infrastructure is priceless</div> <div class="description-text"> <p>SecureLink is Europe’s premier, award-winning, cybersecurity company. Active since 2003, they operate from 15 offices in 8 countries, to build a safe, connected world. More than 2,000 experts and thought leaders are dedicated to delivering unrivalled information security value for over 1,300 customers. They are part of the Orange Group, one of the world’s leading telecommunications operators, and listed on Euronext Paris and the New York Stock Exchange (NYSE).</p> <h2>The Challenge</h2> <p>SecureLink has been an on-site consultant for several years for a large global entertainment company. SecureLink’s client has over 100 firewalls running both on-premises and on Amazon<br /> Web Services (AWS) from several different vendors.</p> <p>Some of the challenges included:</p> <ul> <li>“Shadow IT” had taken over, causing security risks and friction with IT, who had to support it.</li> <li>Security policies were being managed in tedious and unmaintainable Excel spreadsheets</li> <li>Lack of verification if official firewall policies accurately reflected traffic flows</li> </ul> <p>The business units were pushing a migration to a hybrid cloud environment rather than relying exclusively on an on-premises deployment. Business units were unilaterally moving business applications to the cloud, leading to “shadow IT.”</p> <p>Business application owners were unable to comply with security policies, troubleshoot their “shadow network,” nor connect cloud-based servers to local servers. When there were problems, the business units went back to the IT department, who had to fix a mess they didn’t create.</p> <h2>The Solution</h2> <p>SecureLink was searching for a solution that provided:</p> <ul> <li>Automation of security policy change management and documentation of security policy changes</li> <li>Comprehensive firewall support for their multi-vendor, hybrid estate</li> <li>Ability to determine compliance and risk profiles</li> <li>Full visibility and control for IT, while enabling business agility</li> </ul> <p>In order to keep the business happy and agile, but ensure that IT had full visibility and control, they implemented AlgoSec.</p> <p>The client selected AlgoSec’s Security Policy Management Solution, which includes AlgoSec Firewall Analyzer and AlgoSec FireFlow.</p> <p>AlgoSec Firewall Analyzer delivers visibility and analysis of complex network security policies across on-premise, cloud, and hybrid networks. It automates and simplifies security operations including troubleshooting, auditing, and risk analysis. Using Firewall Analyzer, SecureLink can optimize the configuration of firewalls, and network infrastructure to ensure security and compliance.</p> <p>AlgoSec FireFlow enables security staff to automate the entire security policy change process from design and submission to proactive risk analysis, implementation, validation, and auditing. Its intelligent, automated workflows save time and improve security by eliminating manual errors and reducing risk.</p> <h2>The Results</h2> <p>AlgoSec helped SecureLink gain control of shadow IT without slowing down the business. By using AlgoSec to gain full visibility of the entire network, IT was able to regain control over company’s security policy while supporting the move to the cloud. “AlgoSec lets us take ownership and be quick for the business,” said Björn Löfman, a consultant at SecureLink. “The way AlgoSec provides the whole map of the internal and cloud networks is outstanding, and to be able to apply the same policy on all your infrastructure is priceless.”</p> <p>By using the AlgoSec Security Management Solution, SecureLink was able to clean up risky firewall policies, gain increased understanding of their security policies, tighten compliance, and enhance migrations of hardware and implement a hybrid cloud environment with Amazon Web Services (AWS).</p> <p>Some benefits to the client of AlgoSec include:</p> <ul> <li>Greater understanding of network security policies</li> <li>Easier firewall migration – they migrated from Juniper NetScreen to Check Point firewalls</li> <li>Ability to optimize rules and reduce unneeded and duplicate rules and objects. They were able to go from 4,000 rules to 1,110 rules – a 72% reduction.</li> <li>Move to the hybrid cloud with the adoption of Amazon Web Services</li> <li>Able to reduce shadow IT and reclaim ownership of the cloud</li> <li>Full visibility of entire hybrid network – including both on-premise and devices in the cloud including firewalls, <a href="https://www.algosec.com/professor-wool/best-practices-amazon-web-services-aws-security/">AWS security groups</a>, and Access Control Lists (ACLs).</li> </ul> </div>

<p>Migrating applications to the cloud – without creating security holes, application outages or violating compliance – is within reach!</p> <p>In this webinar, Avivi Siman-Tov, Director of Product at AlgoSec, will guide you how to simplify and accelerate large-scale complex application migration projects.</p> <p>The webinar will cover:</p> <ul> <li>Why organizations choose to migrate their applications to the cloud</li> <li>What is required in order to move the security portion of your application and how long it may take</li> <li>Challenges and solutions to lower the cost, better prepare for the migration and reduce the risks involved</li> <li>How to deliver unified security policy management across the hybrid cloud environment</li> </ul>