Tag: micro-segmentation

  • Managing a New Kind of Complexity in Software-Defined Networking

    Managing a New Kind of Complexity in Software-Defined Networking

    Software-defined networking (SDN) has moved up the enterprise IT agenda in recent years. And it’s easy to see why–in theory, SDNs are far quicker and easier to control and alter than traditional networks. By using open protocols to apply controls from the network edge, SDNs enable network engineers to shape traffic from a single centralized console, rather than working with individual switches across the network.

    In turn, this makes software-defined networks far more agile than traditional networks, with opportunities for automatic load balancing, streamlined processes, on-demand provisioning of new applications and traffic flows–in short, a network that works much harder for the organization. So, it’s no surprise that organizations are embracing SDN. A 2019 Verizon study found that while just 15% of respondents said their companies had implemented SDN, 57% expected to do so within two years.

    However, deploying SDNs can introduce new challenges for network staff revolving around complexity–in particular, complexity in relation to managing network security. Let’s take a closer look at what this means.

    A Shift in Complexity

    Any organization that moves to a software-defined environment essentially moves from datacenter-focused firewalls into a model where its security policies are defined by software within its fabric. This requires a far more granular level of security policies, on a much larger scale and with far more agility, than in traditional networks. Why? Because security controls are much more diverse.

    In a traditional setup, network security policy is relatively monolithic. A set of servers is protected by a perimeter firewall, filtering so-called north-south traffic that enters the network from the outside. Traditionally, east-west traffic within the datacenter itself is not subject to any filtering, which introduces security risks–particularly in terms of enabling malicious parties to laterally explore the environment once they have compromised a single endpoint.

    By contrast, in an SDN environment, built-in firewalls are considered part of the infrastructure. It is likely that the organization will have multiple tenants, each containing a unique set of granular security policies dictating which assets can connect to which other assets within the SDN fabric. An SDN environment is likely, for example, to incorporate one contract with Cisco Application Centric Architecture (ACI), VMWare NSX distributed firewalls and so on. There is a lot of complexity to manage.

    Ultimately, the organization in question needs to identify which elements within the newly software-defined network need to connect to each other. Then, create granular security policies that enforce this, dividing the network into smaller zones to prevent lateral infiltration by malicious parties. In short, they need to introduce micro-segmentation. 

    Managing Micro-Segmentation

    There are two main challenges associated with micro-segmentation from a security point of view. First, the organization needs to define the micro-segmented zones, and second, it needs to enforce and maintain the security policies that enable that micro-segmentation.

    How do we define micro-segmentation zones? This is all about understanding the assets within your environment, which databases contain the most sensitive data and therefore need to be segmented off from each other, which assets are talking to each other and how traffic is flowing throughout the network. Crucially, all this should be contextualized in terms of business applications–in other words, you need to understand the traffic that makes business applications work. This enables you to design a micro-segmentation architecture–and the security roles to enable it–that are centered around your business-critical services. Solutions that automatically discover and map all of the traffic flows within and through a datacenter are invaluable at this point.

    Then we move onto enforcement and maintenance of those rules on an ongoing basis, and this is where a security policy management solution is truly critical. All this complexity and dynamism cannot be managed manually. Each time a new business application is introduced, or an existing one removed or amended, the security policies also need to change–and these changes could be happening on a daily or even an hourly basis in a large organization.

    Automating the Management Process

    So, given the flexibility and rapid changes that SDN enables, how should organizations approach managing and maintaining security policies across their entire enterprise network? The most effective way is with an automation solution that holistically supports the SDN environment and its security controls, alongside existing traditional on-premise firewall estates.

    It’s important to note that the SDN deployment will be subjected to the same compliance and auditing requirements as existing networks. The security management solution must be capable of providing visibility across both physical and virtual network functions so that the overall compliance status can be centrally monitored and logged for audit purposes.

    Automated security policy management solutions generate filtering policies based on enabling only the traffic required for every application in the datacenter. This is a way of approaching intent-based networking, which comes back to looking at the components of each individual application and how they are communicating with each other. Furthermore, automated security policy management solutions audit and record every single change that is made across the network, making it easier to demonstrate compliance continuously.

    With the right automation solution, IT and security teams can eliminate time-consuming, error-prone manual security processes, such as connectivity discovery and mapping, migrating and ongoing maintenance of their environments. This frees up the teams to strategically maximize the benefits of the SDN deployment, and reap its rewards of increased flexibility and enhanced network security.

  • Common Cloud Security Mistakes and How to Avoid Them

    Common Cloud Security Mistakes and How to Avoid Them

    Over the last few years, it’s become apparent that traditional on-premise security policies are not a good fit for newer cloud-native environments. Even though the writing has been on the wall for a long time, the brewing security crisis still hasn’t been resolved. Far too many organizations continue to use security measures that are ineffective for cloud-native environments, along with inconsistent policy enforcement that leads to huge oversights and gaping organizational loopholes. The sad truth is that today, it doesn’t take a master hacker to infiltrate most cloud-native deployments.

    Many of the most infamous security breaches would have been extremely difficult to prevent even with an ideal security environment, but the weakness of the system is endemic, reaching far beyond a handful of vulnerable organizations. Even if some malicious actors could still get through, there’s no reason for organizations to leave their attack surface so blatantly unprotected.

    Here are increasingly common cloud security mistakes DevOps teams still make, and our suggestions for how you can stop them in your organization.

    Ignore Zombie Workloads

    Many organizations ignore zombie workloads that run on their architecture. When your team is stretched and you’re facing a number of serious security issues, it’s easy to dismiss zombie programs as nothing more than a harmless irritation.

    In actuality, having zombie resources scattered around your deployment blocks your ability to spot serious cryptojackers. Zombie workloads are often an indication of, and an invitation to, more significant invasions into your infrastructure. A report by SkyBoxSecurity revealed in 2018, cryptojacking was the leading attack vector. DevOps teams need to recognize the threat of hosting a program mining your resources for cryptocurrency, and take immediate steps to block them.

    Turn a Blind Eye to Leaky S3 Buckets

    AWS service buckets, particularly the S3 bucket, is one of the oldest cloud-native services. As a result, many S3 buckets are still governed by very old rules and regulations that leave many ways for someone to accidentally make the bucket public, open up access to unauthorized users and expose sensitive data.

    A study by HTTPCS reports 58% of AWS S3 buckets are accessible to the public, and 20% of them aren’t write-protected. Not only can malicious actors get to your sensitive customer data through S3 buckets, but often they can access your cloud credentials as well. Some of the most disastrous data breaches began from unrestricted access to S3 buckets, and it’s one of the most common causes of data breaches overall. It’s vital to regularly check your AWS console for public buckets.

    Allow Runtime Updates to Bypass the CI/CD Pipeline

    Every DevSecOps team agrees that your deployment is more secure when runtime updates are passed through the CI/CD pipeline, but that doesn’t mean the policy is always enforced. Developers will repeatedly ignore your security policies through practices, such as using open-source libraries, to avoid the security process of the CI/CD pipeline and speed up deployment.

    While this saves developers some time on releasing updates, it places a heavier burden on security teams, who have to run extra scans for these rogue workloads. What’s more, it builds complacency among DevOps teams, who assume there is no way to prevent unauthorized workloads and end up simply accepting them. Eventually, your security posture erodes to the extent that malicious actors can run harmful workloads without attracting your attention–until it’s too late.

    Permit Unrestricted Network Access

    Instead of spending hours on segmentation and separate access permissions, all too many DevOps teams fall back on a blanket set of network configurations that fall far short of the necessary access restrictions. They often place all their workloads into a single VPC, opening up access to third parties in the process.

    Without restrictions on public network access, it takes far longer for security teams to identify and isolate negligent and malicious activities. In a short space of time, DevSecOps teams find themselves overlooking serious oversights like unrestricted public root access, opening up enormous holes in their security profile.

    Faulty Rule Configurations for Micro-Segmentation

    When DevOps teams use micro-segmentation in containers, they face unique challenges. The more granular you get with your segmentation, the greater the risk you’ll miss faulty policy rules.

    Even your most familiar rule sets can create massive vulnerabilities. For example, if you allow your developers to use a specific IP to connect to the production runtime environment through SSH, you could unwittingly end up permitting unrestricted public access to sensitive areas. Sometimes, these faulty rule configurations go overlooked for as long as several months. To avoid supporting faulty rules, it’s important to audit them regularly with a tool such as Amazon Inspector’s Agentless Network Assessment.

    Avoiding AWS cloud security mistakes requires a shift in mindset. The harsh truth is a significant number of cloud-native deployments commit not just one, but several of the mistakes listed above. Cloud environments are deliberately decoupled from the network infrastructure in order to enable agile business practices, but DevSecOps teams continue to use network security techniques that aren’t capable of meeting the unique challenges of the cloud.

    The only way to fix these mistakes is to turn to new technologies designed for cloud security, such as using cloud workload identities to bridge the chasm between business logic and network infrastructure. Until ACLs and security groups are untethered from the network infrastructure and join cloud-agile business logic, they’ll fail to provide adequate cloud-native security.

    — Ran Ilany