devopsy.kinsta.cloud

Tag: cloud-native security

  • DevSecOps Tech Radar Highlights Diverse Tooling Adoption

    DevSecOps Tech Radar Highlights Diverse Tooling Adoption

    The DevSecOps Technology Radar showcases the opinions cloud-native groups have about DevSecOps tools. To review, The Technology Radar is a periodic report from the Cloud Native Computing Foundation (CNCF), a burgeoning host for new open source projects that are becoming pivotal underpinnings to cloud-native architecture at large.

    Just like previous radars, the DevSecOps Technology Radar was assembled using feedback from the CNCF end-user community, which is a group of over 155 organizations that use cloud-native technologies to build and distribute their services, spanning startups and enterprises. The Radar report organizes popular tools into adopt, trial and/or assess status, based on a technology’s active use and its maturity.

    ‘Adopt’ means these tools are stable and come highly recommended for use in production systems.

    ‘Trial’ means users have had some success with these tools, and it is recommended that others consider them.

    ‘Assess’ means these are promising tools that are good for solving specific needs.

    So, why was DevSecOps selected as this Radar’s theme? According to the Radar team, DevSecOps was chosen because it is highly relevant to current development focuses. “We realized that more than half of the tools we were using in CI/CD were actually security-oriented,” said Sergiu Petean, head of DevOps at Allianz Direct. This goes beyond DevOps—”this is definitely an uppercase ‘Sec’,” he said.

    “More than half of our time is spent discussing designs around security,” said Keith Nielsen, director, cloud architecture at Discover Financial Services. Financial services especially must find innovative methods to balance speed-to-market with security. Nielsen also cited the rapid rate of change in this space, which requires companies to continually reevaluate their security posture.

    DevSecOps Radar Results

    So, where did the CNCF end-user community place popular DevSecOps tools? The Radar ended up rating 16 tools across the three different levels:

    • Adopt: Istio, Sonarqube, Artifactory, Hashicorp Vault, Calico/Tigera, Terraform, ArgoCD and OPA.
    • Trial: XRay.
    • Assess: Cilium, Harness, SonaType Nexus, Hashicorp Sentinel, GitHub Actions, Linkerd and Trivy.

    The above results were based on 252 votes from end users across 35 tools, with most respondents coming from large companies across multiple sectors.

    Out of these tools, Terraform collected the highest number of ‘Adopt’ votes. This technology aids the move toward infrastructure-as-code (IaC) with declarative configuration files, which is important for DevSecOps automation. Tied for second place were Hashicorp Vault and Artifactory, indicating that secrets management, access control and continuous updates for security are pressing requirements.

    Other open source tools on the Radar are providing impressive ways to unify security controls. For example, OPA is a universal layer for applying policies that could help unite fragmented authorization across applications. Or, service mesh options like Linkerd and Istio place a sidecar proxy around applications to centrally manage access control, observability and networking across a large microservices ecosystem. Such projects are programmable to fit into the DevSecOps pipeline.

    Analysis

    In general, the radar team was somewhat surprised to see such a high number of security tools in use today. Some tools compete in the same arena, making hunting for the right tool challenging. “The sheer number of products is a bit staggering … what we’re seeing is a highly fractured strategy from different companies,” explained Nielsen, who said he expected more consolidation on capabilities.

    After evaluating the DevSecOps tooling landscape, The Radar team organized their core findings into three main takeaways:

    Usability is compromised at the expense of security. Security features are necessary, but they often come at the cost of usability. The DevSecOps Radar team found that the developer experience for most tools is poor. Many disparate tools must be stitched together to have a truly automated pipeline which is cumbersome to implement. “The tools are getting better, but still there’s not a cohesive, prescriptive way to develop for the cloud,” said Nielsen.

    The pace of change in the security space is rapid. Major cloud providers continue to rapidly release new services, which has led to an explosion in new tools. Simultaneously, the speed of innovation is accelerating within companies, opening up unique security needs. Combined, this means the security landscape is constantly shifting. “Security tools are trying to keep up with the services and how you host them and run them,” Nielsen said. “We definitely weren’t expecting to see so many newcomers in the security space,” Petean agreed. Though DevSecOps is spoiled for choice these days, “it’s always better to have options,” he added.

    Microsegmentation is important but presents a significant challenge. Many great tools enable companies to improve how they segment traffic, such as service mesh tools like Linkerd and Istio. However, implementing cloud-native microsegmentation is bumping against legacy implementations for established companies. Between API gateways, service mesh, edge firewalls and Kubernetes federated firewall functions, DevSecOps has much complexity to deal with, Nielsen said.

    The DevSecOps Technology Radar: In Review

    In recent years, cloud-native technology has placed increasing emphasis on solving the security puzzle. Companies continue to reevaluate their security approach in light of cloud-native strategies, novel vulnerabilities and new compliance requirements. DevSecOps is proving to be a useful, if not necessary, practice to maintain both security and rapid software delivery.

    With new security tools and unique approaches coming out so frequently, it’s easy to have “analysis paralysis.” However, DevSecOps must start somewhere. And, for those who trust the opinions of the CNCF Technology Radar, you now have some helpful insights on where to begin.

  • Cloud-Native Security and Performance: Two Sides of the Same Coin

    Cloud-Native Security and Performance: Two Sides of the Same Coin

    You’re running Kubernetes in a production environment, and you need to apply a patch — perhaps to a commercial application, an open source component or even a container image. How long should it take to implement that patch in production? Thirty days? One day? One hour?

    Remember, cloud-native environments are supposed to respond to change in real-time. Such a response isn’t simply scaling up or down as needed. It’s also essential to respond to security threats, and performance issues, as close to real-time as possible.

    Containers, and the microservices they support, are also ephemeral. They can live for five minutes or even less, and yet unpatched microservices are just as dangerous as more permanent code.

    Patching must also fit within your application lifecycle. Teams with a mature DevOps process typically release code weekly, daily or even hourly. Their ability to apply the patch and roll to production quickly, significantly reduces their security risk. Are your operators up to the task?

    Poor Security Management Becomes a Performance Problem

    The connections between security and performance go well beyond cloud-native environments. Denial-of-service (DoS) attacks obviously target a site’s performance, as do cryptojacking and to a lesser extent, ransomware attacks.

    In many cases, performance monitoring gives an organization its first indication that such an attack is underway. However, monitoring isn’t just for recognizing attacks in progress. It also plays an important role in the prevention of attacks as well — especially in cloud-native environments.

    To understand this point, think about how organizations have traditionally handled patch management, especially to software infrastructure: A vendor (or open source project) releases a patch. The enterprise applies the patch in a test environment that resembles production somewhat. After running a range of integration tests over the course of days or even weeks, the ops team may be ready to deploy the patch into production. 

    Another likely scenario: The ops team may collect several patches to different pieces of software, hoping to test and deploy them all at once. In the meantime, more time goes by, giving attackers even more opportunity for mischief.

    The reason that applying patches in an enterprise production environment takes so long is because IT leadership perceives that patch management is a high-risk activity. Patches may make a piece of software behave poorly or not at all — and the complex interdependencies among both applications and infrastructure components compound the risk of failure unpredictably.

    Cloud-Native Computing Changes the Equation

    Cloud-native computing extends cloud best practices such as scalability and resilience to the entire enterprise IT landscape, providing a new paradigm for computing across hybrid IT environments that leverage virtualization, containers and serverless computing as appropriate.

    At the center of the cloud-native movement is the open source container orchestration platform, Kubernetes. Kubernetes requires and reinforces a cloud-native architectural approach that decomposes applications into containerized microservices. 

    Deploying, managing and operating microservice-based workloads at scale becomes the central challenge for Kubernetes, and for cloud-native infrastructure in general.

    To manage patches, organizations must follow cloud-native principles. Monolithic, “test everything for weeks” approaches simply do not align with the dynamic, ephemeral nature of cloud-native software.

    Just as application developers use canary testing for features they are rolling out, canary testing infrastructure updates largely supplants testing in the full-blown test environment. 

    Testing patches (or updates) become an ongoing, largely automated process of trying new configurations in limited production environments, analyzing the resulting performance and rolling back changes if necessary.

    Operators can now test patches (or new releases) more quickly in production, in a way that ideally minimizes the impact on the applications that end-users interact with.

    How, then, should operators manage such canary environments? By monitoring the performance of the software under test.

    The Convergence of Security and Performance Monitoring

    Unpatched software is the leading source of vulnerabilities in the enterprise IT landscape, and managing patches in dynamic environments requires performance monitoring.

    Add patch management to other performance-related cyberthreats, such as denial of service, ransomware and cryptomining, and it’s clear that security and performance monitoring are two parts of a broad spectrum of IT operations management (ITOM) capabilities.

    In cloud-native infrastructure, ITOM doesn’t stop at monitoring. Instead, operators require observability tools that monitor logs, traces and metrics across the entire infrastructure, in addition to providing tools that operators can use to mitigate and prevent problems with the infrastructure.

    In other words, where monitoring is a passive, “watch the dashboard” activity, observability goes the extra mile, promoting an active, “understand and fix the problem” mentality.

    It doesn’t really matter if those problems are performance or security-related — in many cases, there’s no distinction. Today’s operators must work with tools that bring the two together into a full-fledged security, compliance and monitoring solution.

    The Intellyx Take

    Some analysts argue that IT infrastructure has followed a natural progression from on-premises servers to virtualization to cloud computing to containers. However, there is a fatal flaw in this argument.

    The first three environments in this sequence follow a clear pattern, as virtual machines work much the same as physical servers, be they on-premises or in the cloud. As a result, coding applications remained largely unchanged as enterprises worked their way along this progression to the cloud.

    Containers, however, are fundamentally different — especially once you place them into Kubernetes and the cloud-native context overall. With cloud-native computing, it’s essential to rethink the nature of the application from the ground up. Cloud-native computing is, in fact, an entirely new paradigm for enterprise IT.

    It’s no wonder, therefore, that core operational activities like security and performance monitoring have a new role in the cloud-native world. Indeed, security and performance are every bit as important as before, but today, we must deal with both at once in the context of a dynamic, ephemeral application landscape.

    Only within this context does it become clear what cloud-native vendors like Sysdig are offering. The world of IT infrastructure is changing, and with it the world of enterprise application development and deployment. Security and performance are as important as ever. Don’t let them fall through the cracks.

  • Practical Approaches to Long-Term Cloud-Native Security

    Practical Approaches to Long-Term Cloud-Native Security

    There is no shortage of advice out there about how to secure modern, cloud-native workloads. By now, most developers and IT engineers who work with cloud-native deployments have heard all of the mantras about DevSecOps, shift-left security, multi-layer defenses and dynamic baselining (to name just some of the key concepts that are driving IT security conversations these days).

    One thing is to talk about security best practices and another is to design a cloud strategy that makes it not only possible but also easy to implement them. Even more challenging is planning a strategy that facilitates security best practices over the long term.

    Keep reading for tips on meeting these challenges and devising a long-term security strategy.

    Security Is a Long Game

    It’s easy to think of security as something you have to do in real time. After all, threats and attacks usually happen suddenly, and reacting to them quickly is key to preventing serious damage.

    If your security strategy centers on finding and remediating threats as they appear, you end up stuck in what is essentially a break/fix mode. You’re constantly reacting, rather than being proactive.

    A much more effective security strategy is one that minimizes the threats you face in the first place. That type of strategy requires long-term planning.

    Sure, you will always need to be prepared to detect some threats that you didn’t anticipate, and react quickly in the event a breach occurs. No security plan is perfect, and the unexpected will sometimes still happen. But by focusing as much as possible on long-term security solutions that stop most threats from materializing, you end up with a much safer and more reliable security posture.

    Building a Long-Term Security Strategy

    What does it actually take to implement a security strategy that protects you over the long term? It all boils down to four elements: data, infrastructure, processes and culture.

    Data

    For many organizations, data stored in the cloud is the workload that poses the greatest risk. It’s the reason why there is a seemingly never-ending stream of headlines about major security breaches that involve the theft of sensitive data stored in the cloud.

    Therefore, mitigating threats to data in the cloud is a critical requirement for long-term security. Some best practices in this regard include:

    • Assess your data: Data security starts with knowing what is in your data, and how sensitive the data is. Data cataloging can help with this process, but so can tools such as Amazon Macie, which helps identify personally identifiable information with cloud-based data.
    • Access control: Access control frameworks are another crucial line of defense against cloud-based data breaches. Just remember that simply enabling IAM is not enough; you must also audit IAM policies to avoid misconfigurations that could lead to a breach (which was the lesson learned by Capital One, among others).

    Infrastructure

    These days, we tend to treat infrastructure–meaning the cloud-based and/or on-premise data centers that host workloads–as a relatively generic and interchangeable part of the solution stack. But while it is true that, generally speaking, no one cloud or data center is inherently more secure than another, the way you design your infrastructure plays a key role in your ability to secure modern workloads over the long term.

    Best practices on the infrastructure front, for long-term security include:

    • Immutable infrastructure: Embrace infrastructure platforms, such as ECS or EKS, that make it easy to deploy and update applications in an immutable way. Immutable building-blocks may not work for all use cases, but where possible, they reduce the number of variables and handoffs you have to contend with in order to deploy or update an application (and the more variables and handoffs, the greater the chance of an oversight that will create a security vulnerability).
    • Access control: While IAM frameworks can help prevent some types of unauthorized access, you can also increase the security of your infrastructure using Access Control Lists. A best practice is to adopt a whitelisting approach that blocks all traffic by default, and allows only explicitly trusted hosts.
    • Avoiding bloat: Cloud-native infrastructure makes it easy to spin up virtual machines, databases or other infrastructure components that you don’t truly need, and keep them running. Doing so increases your attack surface. For that reason, identifying and shutting down unused infrastructure is critical for ensuring long-term security. It also helps cut cloud costs, but that is another topic.
    • Parity: In order for developers, ITOps and security teams to be able to communicate and coordinate effectively, they should all be working with the same types of infrastructure environments. Collaboration becomes much more difficult if, for example, you use an on-premise data center for development, then deploy production workloads to the cloud. Avoid this by striving to create parity across your infrastructure whenever possible.

    Processes

    Processes are the second key ingredient in creating a long-term security plan for cloud-native workloads. Obviously, the processes you use will reflect, in part, your particular workloads and tools. But no matter your situation, your processes should be designed with the following security goals in mind:

    • Consistency: Your IT organization may consist of different teams, each with different responsibilities and agendas. Nonetheless, to the extent possible, all teams should follow the same procedures when developing, testing, staging and deploying applications. Doing so reduces the chances of variables or oversights that can undermine security. You can help achieve this consistency by creating and enforcing IT governance procedures across the organization.
    • Shift-left: Processes are the part of your IT operation where shift-left security can have the greatest effect. Shift-left security means making security a priority from the start of the application delivery pipeline. Importantly, however (and this is a point that some organizations overlook), doing shift-left security correctly also means bolstering security operations at later stages of the pipeline, too. Don’t just shift security left and call it a day; aim to make security a primary consideration at all stages of your delivery chain.

    Culture

    Culture is something that can be difficult to formalize; indeed, if you try to stuff cultural values down your employees’ throats, you risk compromising the whole point of having an organic culture in place. Instead, you want to encourage your team members to naturally embrace values that promote a culture of security. Strategies that can help achieve that include:

    • Bug bounties: Incentivize your team to look for and address security issues by hosting bug bounties for your organization’s workloads. For this purpose, “bug” should be defined broadly to include not just security bugs within code, but any kind of configuration issue in your infrastructure, tools or applications that could lead to security vulnerabilities. That way, your bug bounties can include not just developers, but all members of the IT organization.
    • Encourage shared ownership: A culture in which each engineer owns a specific application, infrastructure or process is one that limits transparency and opportunities to address security risks. Strive instead to promote shared ownership of IT assets so each team member knows his or her work may be reviewed by others, which helps to encourage best practices and reduce security issues. In essence, these are part of the values that DevOps and DevSecOps prioritize.

    Conclusion

    By designing infrastructure, processes and cultural practices that promote security, you put your organization in a position to optimize security over the long term. Planning ahead for security is the only way to escape the break/fix cycle of responding to vulnerabilities as they are discovered, which leaves you always treading water and never pushing the needle. You won’t be able to prevent all security issues, but you can greatly reduce the number that crop up by baking security into your infrastructure, processes and culture.

    This sponsored article was written on behalf of Eplexity.

    — Chris Tozzi

  • 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