devopsy.kinsta.cloud

Tag: policy management

  • Shared Responsibility? Yeah.

    Shared Responsibility? Yeah.

    One of the things that the last decade or two of enhancements has brought about is an increasing reliance on everyone across the organization to be more secure. While users have long since thrown up their hands and looked for ways to minimize the fallout when a vendor they frequent is compromised, enterprises have to lock down their own things. And given the ever-increasing volume and sophistication of attacks, the demands are growing.

    Cloud brought us the concept of a ‘shared responsibility‘ model. It is necessary in a world where an org does not control the physical servers and supporting infrastructure that applications ultimately run on. The fact is, the shared responsibility model was really cloud vendors reminding us that we still have to protect our apps, no matter where they’re deployed.

    This model and DevOps together have driven us to demand more of developers and DevOps teams with regard to security. It has also driven ops to have to care more, as more is exposed and security demands are up while security staff isn’t.

    And I’ll just remind you of the obvious. If you are responsible for security at the organization, you can get help from everyone, but those people’s job and direct responsibility is not security. They’re lending a hand because everyone cares, and that is the current state of most enterprises – DevOps made everyone involved in the SDLC a bit more responsible for all the things that aren’t their jobs (often a very good thing, often … not), but they’re not specially trained for it. That’s what security teams are for. And high-quality development security/policy management tools offer Dev and Ops and everyone in between a bit of guidance to good security practices along the way. I’ve praised putting security feedback right in the IDE half a dozen times here and elsewhere, and as a security-conscious developer, will continue to do so until it is so pervasive that people start to worry I’m losing it by going on about it. That’s a great example of helping everyone be more secure without requiring a ton of security staff hours in training. Developers don’t purposely write insecure code any more than they set out to make buggy spaghetti code. Giving tools to help them make the code more secure is a huge bonus – to them and to the corporate security team. So, if you’re not using them, start. And look into all of the other options to help non-security staff lock down their bit. The number of available security people on the market is perhaps the largest it has ever been (It’s so bad I actually know a security researcher who took months to find a new gig – that is pretty much unheard of or a unique case before recent days), but budgets to grow the security team aren’t there – any more than they are currently there to grow most teams. So tools to help are still imperative because you’re not going to get double the security staff in 2024 unless there’s only one of you … and you threatened to quit if they don’t get you help, which no one recommends as a negotiation tactic, so even if you’re solo, no doubling for you.

    Just remember who is responsible for overall infosec. Make use of the specialist and their knowledge in their space by finding tools to help them secure in a manner that matches workflow. Then verify because the organization’s security posture is security’s job.

    And keep rocking it. We’ve got so much cool stuff going on at the moment in IT in general that there is plenty of opportunity to improve architectures that are even relatively recent. Check what you have, consider it from a security perspective, improve what you have and keep rolling along.

    But first, relax, take a breather, and enjoy the holiday period.

  • Quali Update Strengthens Infrastructure Security

    Quali Update Strengthens Infrastructure Security

    Quali today announced enhancements to its Torque automated infrastructure platform to add support for security scans and Open Policy Agent (OPA) software being advanced under the auspices of the Cloud Native Computing Foundation (CNCF).

    OPA enables organizations to implement cybersecurity policies as code. The challenge many organizations have encountered is that not many developers have mastered the programming language required to implement OPA. Quali is embedding OPA in a platform that enables IT teams to implement it using a graphical tool that enables central management and application of those policies.

    David Ben Shabat, vice president of research and development at Quali, said the overall goal is to implement scans and policies in a way that reduces the number of misconfigurations that are made when organizations provision infrastructure-as-code (IaC).

    As part of that effort, Torque now flags any policies that fail validation. In addition, administrators can pick and choose which OPA policies to import, including both out-of-the-box and existing custom policies. Those policies then enable Torque to automate approvals or denials of deployments based on compliance with those policies after scans and other health checks have been run.

    Quali has been making a case for policy-based triggers for cost controls, automated start-up, shut down and pausing of IT environments to give IT teams more control over infrastructure using a software-as-a-service (SaaS) platform. That approach enables IT teams to provide a set of guardrails for provisioning infrastructure that prevent mistakes from being made, noted Ben Shabat. Those controls can be applied using the graphical tool Quali provides or programmatically via an application programming interface (API) that Quali exposes, noted Ben Shabat.

    It’s not uncommon for a port to be left open, for example, which cybercriminals later exploit to exfiltrate data. Quali is offering a DevOps platform that allows for central application of policies that act as guardrails to prevent developers from making these types of mistakes as an alternative to scripts created using tools such as Terraform. That approach also provides more visibility into how infrastructure resources are being consumed.

    Every minute a developer spends managing infrastructure is one less minute they could be spending writing code. As application environments become more complex, it is becoming more challenging for developers to manage infrastructure-as-code. The issue is that DevOps teams who could provision infrastructure for developers are overwhelmed by the number of projects they need to manage. As a result, DevOps teams are becoming bottlenecks. Naturally, that only encourages more developers to provision infrastructure on their own, leading to more mistakes.

    It’s not clear whether IT organizations will look for an alternative to provision infrastructure in a way that doesn’t require developers to have as much infrastructure expertise. However, as organizations look to lock down software supply chains, the way infrastructure is provisioned using code will, in many cases, need to be reconsidered within the context of a larger DevSecOps workflow.

  • More Than Half of DevOps Pros Have Backdoor Access to IT Infrastructure

    More Than Half of DevOps Pros Have Backdoor Access to IT Infrastructure

    A survey of 600 DevOps professionals conducted by strongDM, a platform for managing access to IT infrastructure, found nearly two-thirds (64%) had productivity impacted on a daily or weekly basis because of access issues.

    It’s not surprising that, as a result, DevOps teams created a number of workarounds to gain access, even though those methods don’t comply with cybersecurity best practices, according to the survey. More than half of respondents (55%) maintained backdoor access to systems, and 42% have embraced shadow IT to get access to tools and systems they needed for their roles, the survey found.

    Worse yet, the survey found that 53% of respondents admitted they are sharing credentials across teams.

    Well over half (57%) of respondents said it could take days or weeks for access requests to be approved, with 40% reporting it takes days to add tools to existing access solutions. Nearly three-quarters (73%) of respondents also noted it requires 15 minutes or more to gain access to infrastructure.

    More than half of respondents (52%) said they have missed deadlines due to issues with accessing infrastructure, with 53% of those respondents being held accountable for the missed deadline even if it was caused by their lack of access to infrastructure.

    Justin McCarthy, CTO for strongDM, said despite all the hype surrounding identity management and zero-trust IT, it’s clear many organizations are still struggling with the basics of access control. That issue has been further exacerbated by the need to enable more DevOps professionals to work from home since the start of the COVID-19 pandemic more than two years ago, he added.

    Many of those organizations are still relying on virtual private networks (VPNs) even though it’s been shown that stealing the credentials to access those VPNs is relatively trivial, McCarthy added.

    In place of those approaches to access IT infrastructure, strongDM is making a case for a dedicated infrastructure access platform that manages and audits access to databases, servers, clusters and web apps. It is based on local client software, a gateway intermediary and configuration tools that track roles and permissions.

    The benefits of that approach span everything from lower IT support costs to faster onboarding of new IT staff, noted McCarthy.

    Managing infrastructure access for DevOps teams is, of course, always going to be a challenge. DevOps teams are made up of engineers—among the most challenging types of end users to support. Many of them will use their own expertise to circumvent any process they deem to be inefficient. The trouble is, many of those end-runs would not pass muster with cybersecurity teams responsible for access management. The challenge each of those cybersecurity teams needs to come to terms with is the amount of time they want to spend time looking for these cybersecurity policy workarounds versus making it easier to securely access IT infrastructure.

    The sad truth is both DevOps and cybersecurity professionals are wasting a lot of time and effort trying to outwit each other when that time could be put to better use.

  • DevSecOps: Realities of Policy Management

    DevSecOps: Realities of Policy Management

    Policy management is essential to scale cloud environments and is key to secure DevOps practices. It enables organizations to manage policies put in place that secure the cloud environment, ensure Kubernetes configurations are secure and enable the continuous monitoring of a company’s overall security posture. 

     As businesses migrate workloads across multi-cloud architectures to achieve the agility and scalability needed to keep up with the pace of digital transformation, the growing demands placed upon developers often leave a gap that exposes potential threats and risks in the configuration settings, making security an even greater focus in DevOps. In fact, IDC’s 2020 survey found that 67% of breaches in the cloud are caused by misconfigured applications or infrastructure, including some of the industry’s largest breaches like Marriott’s second breach.

     To add to this, the first State of Policy Management report by Nirmata and the creators of the CNCF project Kyverno revealed that nearly 50% of users in cloud-native environments have now adopted some type of policy management solution. This tipping point of mainstream adoption across production cloud-native environments is making it critically important for DevOps teams to look at their practices and simplify and operationalize policy management across their Kubernetes stack by eliminating vulnerabilities through built-in, curated policies, without the barrier of learning complex policy languages. But this widespread adoption also acknowledges that organizations are finally realizing the need to put attention, investment and innovation into addressing security and compliance gaps as they adopt Kubernetes through proper DevSecOps practices and tools so applications being built can empower businesses.

    To confidently build cloud applications in Kubernetes, DevSecOps teams need to accept these DevSecOps realities and apply policy management effectively. 

     Customization Creates Security Risks

    Kubernetes can be highly customized, but DevSecOps teams need visibility into what’s happening in each cluster as organizations scale to ensure application reliability and security. Exploits on containers—including malware installation, cryptomining, host access and privilege escalation—offer opportunities for more security vulnerabilities. They can exist in images, production-accessible container registries, failed builds and third-party admission controllers in Kubernetes clusters.

    To address these risks in applications running on Kubernetes, it’s important to protect your environment with three A’s: Authentication, authorization and admission. This should be done at the cluster layer which enables secure access to authenticated entities that are authorized to perform certain actions. One way to accomplish this is through policy management. In fact, according to the State of Policy Management report, the top use case for policy management is for Kubernetes admission control (31%). When a request is authorized, having a policy in place ensures the request goes through another set of filters. For example, an authorized request may be rejected by an admission controller due to quotas or due to other higher-priority requests. In addition to validation, admission webhooks can also mutate incoming requests as a way of processing request objects for use before reaching the Kubernetes API server. 

    Configuration Issues

    Container images, namespaces, runtime privileges, persistent storage and control plane, together with network policies that are not compatible with best practices, are a source of misconfiguration and risk exposures. It’s this potential for greater risk exposures that have led configuration management to be a key driver of policy management adoption. In the Nirmata State of Policy Management report, it ranked third in security tools that are adopted today and fourth for the organization’s plans for future adoption.

    There are several ways to define security policies to protect cloud environments. Policies can be used for auditing purposes, to reject pod creation or to mutate the pod and limit what it can do. By default, pods can receive traffic from any source and send traffic to any destination. Network policies allow you to limit the ingress and egress access for your pods. The network policy typically translates to firewall rules.

    Lack of Adequate Authorization 

    Cloud authentication allows authorized users to securely access information stored in the cloud with authentication provided through cloud-based services. In The State of Policy Management report, key findings revealed that more than 24% of respondents today are using tools like policy management to authenticate users accessing applications. With data theft one of the fastest-growing and most expensive cybercrimes, the ability to process information and have strong authorization measures needs to be part of DevSecOps best practices.  

    In Kubernetes environments, as a user request is authenticated, it goes through an authorization workflow that decides if the request should be granted. It evaluates the request attributes against all policies and allows or denies the request. The main authorization mechanism is role-based access control (RBAC). Each authenticated request has an HTTP verb like GET, POST or DELETE, and authenticated entities have a role that allows or denies the request. Other authorization mechanisms include attribute-based access control (ABAC), node authorization and webhook mode.

    As the trend of moving security further to the left in the application life cycle accelerates, developers are being required to take active responsibility for it, which creates a higher desire for automation. The rapid releases can expose applications to many vulnerabilities, raising the risk of a breach.  With DevSecOps, organizations can transform the development pipeline by shifting security and compliance to the left, enabling developers to check the code before every commit. In doing so, security and compliance vulnerabilities can be identified and fixed in development, saving the organization from high costs and negative publicity from potential breaches. 

    There’s no doubt that Kubernetes is complex and challenging to adopt. On top of this, the development landscape is flooded with tools and more demands are being placed on engineers.  These shifts are changing the traditional role of a developer, leaving a gap for organizations to address to get the most out of DevOps. But by taking a secure, continuous, iterative approach that also includes policy management, companies can reduce the risk and exposure of their cloud environments. The more mature an organization’s DevOps practices are, then generally, the stronger the security and compliance practices are—they grow in relation to each other. The most innovative companies accept policy management in DevSecOps as a necessity of development and adopt some level of policy management best practices. With the right implementation tools like policy management and security and compliance best practices, organizations can remain efficient in agile and DevOps while adhering to critical go-live deadlines—which can’t be missed in this fast-paced business environment.