devopsy.kinsta.cloud

Tag: privileged access management

  • Policy-Based Governance: Modernizing Authorization for the Enterprise

    Policy-Based Governance: Modernizing Authorization for the Enterprise

    As we’ve moved away from on-prem environments to cloud-based ones and policy managed via code, we’ve inadvertently changed the way the infrastructure is managed. The infrastructure that used to be managed by IT/security teams has now shifted to being managed by the engineering operations teams. With that shift, engineering teams have found themselves now in control of new environments, including the access management part. This new change of control and management of access in the privileged environment requires a new approach to the solutions we use for privileged access governance.

    Shift to Cloud-Based Environments

    Cloud adoption has grown rapidly in the past few years, and while many organizations were already moving to the cloud from on-prem, the COVID-19 pandemic accelerated the transition, causing remote working to become the norm and changing the way responsibilities are managed.

    These organizations found they needed to adopt new ways of working to be able to support and provide critical services to off-site workers. As a result, more than 90% of organizations have adopted some form of cloud-based infrastructure, changing the way they work.

    The cloud is prevailing for tech stacks that need to elevate access governance over the cloud infrastructure. In fact, a whopping 94% of enterprises report they are using cloud services today, and 75% say security is a top concern.

    Cloud Shift, Worldwide, 2019 – 2025

    “The shift to the cloud has only accelerated over the past two years due to COVID-19, as organizations responded to a new business and social dynamic,” said Michael Warrilow, research vice president at Gartner.

    Shift to a Fast-Paced, Customer-Value Mindset

    Since switching to a new agile working environment, customers have gotten used to expecting very fast service. Instead of having a change management process that deploys to production once every few weeks, it’s now common to deploy hundreds of times to production every day.

    Access: required more often, more dynamically.

    Dynamic Changes: With the shift to the agile pace in which the new company works, access has been complicated a hundredfold. (Being able to support customers, fix bugs and being able to move very quickly. Needs to support these hundreds of changes to the customer’s product in their hand.

    Scale of Access has Increased: With the shift to cloud-based infrastructure, it’s now possible to create 5000 databases, for example, with a click of a button. All of them require access management because each one requires an understanding of who needs access and in what way.

    New Solutions are Needed

    The cloud providers, AWS, Azure and GCP, are now the way that people work. And most resources, whether databases or the machines that are running are doing so in the cloud environment. However, companies that shifted to the cloud are dissatisfied with what their legacy PAM solutions can provide them for the cloud resources. These solutions are ill-suited for their new needs. Instead, they need a solution that is agile and scalable to match their new working environment.

    With a perceived lack of options, companies are choosing to have the engineering team put in time to create new solutions. These solutions are meant to provide the following benefits: A frictionless way to gain permissions, an easy way to integrate with the tools their team uses today, and instead of manual provisioning and manual access requests, these solutions should automate those tasks.

    They are creating these in a variety of ways, including the following examples:

    1. Dev Portals: Dev portals are internal developer portals that act as a storehouse of information for the developers in a company. They work by centralizing the data in an internal portal, which offers developers and managers the ability to construct a system that facilitates monitoring of the software ecosystem, receiving alerts about alterations, and visually representing interconnected details. This portal additionally simplifies the task of overseeing diverse facets of the software development lifecycle, encompassing aspects like microservices interconnections, ownership statuses, dependencies, resource allocation, and beyond. By utilizing these, companies are delivering and gaining permissions to cloud environments.

    2. Slack Bots: Many times, a developer will need elevated access to resources or databases, so they need an easy way to request and be granted the permissions they need when they need them.

    3. Terraform Automation: Terraform is an infrastructure-as-code tool that lets you build, change, and version cloud and on-prem resources safely and efficiently. Terraform policies and infrastructure code/policies could also be leveraged to define access control policies. The way it works is that engineers or support teams are required to request a change in the Terraform code in order to gain the access they need. If there is a Terraform code in place describing the policy of groups to role access to the relevant infrastructure they would like to gain access to, they can request that access by requesting a Terraform code change. They would need to understand which parts of the code to change and submit a “pull request” to make the desired change which will resolve in the permissions change. Once a Terraform code change is approved, it changes the policy of access to that infrastructure which will change the permissions that the group has.

    (a) Static: The Terraform state is static, meaning that permissions granted in this way are essentially meant to be long-lasting, standing permissions. In addition, these permissions are usually granted to a role and are very coarse-grained(not granularly defined, as they need to suit the whole role’s needs). This creates an environment of over-privileges. That is why, in many cases where the permissions should be granted to a specific task or person or for a limited time, teams choose to use one-off permission granting to manually grant the permissions. However, these one-off permissions create drifts in the environment essentially if they are not revoked. And since there is no process in place for these one-off just-in-time (JIT) permissions, the revocation needs to also be manual and needs to be remembered to be done.

    (b) “Drifts”: (A drift in Terraform is when the environment isn’t accurately reflected in the Terraform policy). Therefore, by changing the access outside of Terraform, you’re creating a drift because it doesn’t match up correctly, making it a poor answer to one-off permissions. For anything needing high privileges, you want it to be dynamic instead of remaining as part of Terraform.

    4. Jira Service Management With Your Cloud Provider: Integrating Jira with GCP (as a cloud provider example), allows the IT security team the ability to automate servicing access tickets by creating forms where teams can request a certain role or be granted access to a certain project.

    5. Manual JIT Cloud Role: This is a method that allows self-serve permissions to engineers to get the permissions they need on demand. The role needs to be predefined, and essentially, as long as the engineer is part of the group, he or she will be able to gain those privileges on-demand. This reduces the standing privileges in the environment at any given point; however, roles granted are usually for a generic cloud admin rather than being granular, as it’s hard to determine ahead of time exactly what permissions will be needed.

    Problems With DIY Solutions

    Because of the lack of the right tool, companies are spending expensive resources creating their own solutions for access control. Team members know they need something that leverages cloud capabilities rather than their PAM for on-premises. These solutions are time-consuming; companies need to build then maintain the infrastructure. They are also very limited in what they can do since they are not the company’s main concern.

    Policy-Based Governance

    With the growing adoption of cloud-based tools, it’s more important than ever that companies learn to adapt. Engineers have now found themselves in control of permissions in new environments they were not looking to manage. It’s clear that a new approach to access governance is necessary.

    The quickest and most sure-fire way to do this is by utilizing tools deliberately made for the new cloud-based era that address the challenge in a way that is suited to the new, fast-paced, dynamic cloud environment. These new solutions are policy-based and leverage the fact that with the shift to new ways of managing infrastructure, it’s necessary to give the IT and Operations teams more control, granularity and automation.

    Platforms such as Apono for cloud-based permissions management allow organizations to benefit from centralized permissions management, enforce dynamic role-based access controls, monitor and audit privileged user activities and mitigate security risks effectively.

    Final Thoughts

    In addition to the shift we have witnessed in the control of the environment and access governance, organizations are also shifting to delegating more ownership to the engineers themselves. This means providing engineering teams more control of their code — all the way to production. However, with that comes the need to give them only granular control over the environment and provide access management to their specific scope without creating a burden on the teams in managing/granting the access. This leads the operations teams to search for solutions to address the need for access management delegation in the environment. New solutions and platforms addressing the new environment’s privileged permissions management challenge need to take that into consideration as well.

    As a final note, I believe the shift in mindset occurred a few years ago already. However, we are only now realizing some of its effects. One of them is the shift in privileged access challenges and all that comes with that. Seeing the many internal solutions that small-to-large companies have created for themselves gives us an understanding of how this evolved market isn’t being addressed with the same platforms that have existed for well over a decade.

  • Security Debt: Speed vs. Common Sense

    Security Debt: Speed vs. Common Sense

    A couple years ago, we had some spectacular security events that involved DevOps and Kubernetes, where the managing team simply redeployed containers whenever one crashed. It turned out that many organizations were doing the same thing, and, what’s worse, they were not talking about it because they knew it was not a long-term solution to crashing issues.

    At the time, I thought these high-profile lessons would teach people to actually fix code issues, even in high-throughput Agile-meets-DevOps shops. I admit I also laughed, yet again, at The Phoenix Project’s expense, thinking, “Yeah, but the CISO isn’t holding things up by demanding that get fixed!” I wish that would ever get old, but it won’t.

    It seems I was wrong. Or at least partially so. Some—perhaps many—shops seem to have missed the message that these issues sent. Anecdotally, we heard this was still happening, so we started asking questions. Yep. There are shops out there (since we started with ‘anecdotally,’ I won’t pretend to put numbers around it) that still take an “If it isn’t causing disruption in core systems, don’t fix it” mentality.

    Ouch. We’ll be revisiting some of those in the future, I’m sure—when it’s listed as a vulnerability or breach somewhere.

    I’m not a security professional. Because the vast majority of enterprises do not have dedicated security and even more don’t have anything close to enough security staff, I have done security as a part of almost every job I’ve taken—because it was what needed doing the most. Many, if not most of you, are in the same boat.

    That said, I can tell when you are blatantly asking for a security incident. And running code known to be faulty or misconfigured to the point that it repeatedly crashes is deliberately asking for a security incident. “But it isn’t exposed to the Internet!” is only a valid rebuttal until an attacker gets inside the perimeter and uses your fault for something like privilege escalation. Then no one cares if it’s connected to the internet or not; they want to know how the attacker did it. And that’s on you.

    So for those organizations in which speed has overridden common sense, let’s be very clear and to the point.

    It is a best practice not to run crash-level faulty software.

    Since you must not have one, write a policy that explains this and lays out a process and/or timeline to fix these problems. Then drive it home. Make certain it is known that this policy will be enforced. For that huge majority of my readers that don’t have the level of authority that “create and promulgate a policy” implies, convince those who do. Point out the issues to them in writing. “Notified in writing of faulty practices that could bite the company in the rear,” tends to get even the most unfriendly management to click into CYA mode and do something about it.

    When we all watched those spectacular failures back in the day, I assumed that this was all about growing pains; you can do so much more with Agile/DevOps/cloud and/or Kubernetes that this type of thing would crop up and, eventually, get addressed. I still believe that. You all are still testing the boundaries and pushing the limits and making all of IT look good. It’s just going to hurt getting there sometimes. Fix the apps, make the policy, keep kicking butt and know you are killing it (as an industry. If you aren’t, stop laughing at my blanket compliment and fix yourself).

  • Privileged Access Management at the Speed of DevOps

    Privileged Access Management at the Speed of DevOps

    Privileged access management (PAM) is clearly a very important element of effective cybersecurity. PAM has been ranked number one on Gartner’s Top 10 Security Projects for two consecutive years, and it is number four on the CIS Top 20 Critical Security Controls. The struggle for many organizations, however, is they have also embraced DevOps culture, and the traditional approach to PAM clashes with the principles of a DevOps environment. Thankfully, it is possible to effectively manage privileged access in a DevOps environment—it just takes a new approach.

    Challenges of Privileged Access Management

    Despite advances in identity and access management and the existence of things like two factor or multi-factor authentication and biometric authentication, most organizations still rely on a simple username and password to authenticate an individual and grant access to network resources, applications and data.

    The concept of least privileged access—ensuring that users only have access to things they really need access to—has been preached since the dawn of cybersecurity and, when done right, can be an effective strategy. The problem is it’s tedious to do right and it’s very easy to lose track of who has privileged access to what.

    That’s where a PAM solution comes in. The whole point of privileged access management is to provide a way to track and manage who has access to what—to grant access when it is needed and revoke access when the need no longer exists. Unfortunately, there is a lot of confusion about PAM and the effort to manage privileged access is challenging for many organizations.

    Enterprise Management Associates (EMA) conducted a survey on the state of privileged access management. The survey included responses from companies representing different company sizes and industries around the world and focused on IT and cybersecurity professionals—most of whom are familiar with PAM and are directly responsible for managing or granting privileged access to users.

    There were some concerning findings from the survey regarding the perception of PAM. Twenty percent of organizations that reported using a dedicated PAM solution believe it somewhat or greatly reduces user productivity. Many respondents also expressed frustration about the amount of time required to manage privileged access. Half of the survey participants cited manually granting temporary privileges as either very (29%) or extremely (21%) time consuming, and half also said manually revoking temporary privileged access as very (33%) or extremely (17%) time consuming.

    PAM and DevOps

    As challenging as traditional PAM solutions might be for businesses around the world, they pose an even greater hurdle for organizations that have embraced DevOps. A recent episode of the Defense in Depth podcast, hosted by David Spark and Allan Alford, focused on some of the challenges of PAM. A listener had written to complain that “the traditional approach to PAM breaks everything that is DevOps. Regardless of what your PAM provider says about their ability to scale with your dev cycles, they’re lying about the real level of effort.”

    That seems like a fair assessment. Pretty much every company is somewhere on the cloud journey—and working within a DevOps framework on some level. Companies often face backlash from the DevOps team—with some going so far as to boycott efforts to introduce security tools that can’t keep up with the pace of DevOps in the cloud.

    DevOps developers express frustration about trying to build an automatic scaling, horizontal infrastructure and being dragged down by demands from the security team to install agents and change authentication modules. They complain it often means rewriting all of the scripts, resulting in significant and unnecessary effort for a solution that ultimately can’t scale properly in the DevOps environment.

    That is, unfortunately, true when it comes to traditional PAM solutions. Next generation PAM solutions, however, are built with the cloud and DevOps in mind. They are lightweight, automated, scalable and capable of integrating seamlessly with common tools and platforms.

    Rethinking Privileged Access Management

    Based on the survey, organizations understand the importance of privileged access management, but they struggle with finding a way to implement it effectively. The question from the podcast illustrates how PAM is also a significant issue for DevOps environments because traditional PAM solutions do not integrate or scale effectively.

    At the same time, we all know that PAM is a crucial element of effective cybersecurity. It’s not acceptable to just not manage privileged access, but it also doesn’t make sense to suffer through the headaches and frustration introduced by traditional solutions. Organizations need to find new privileged access management tools that work in the cloud and can scale automatically to provide PAM at the speed of DevOps.

    — Tony Bradley

  • Applying Secrets Management to DevOps

    Applying Secrets Management to DevOps

    DevOps has changed the way enterprises operate, allowing for quick and efficient product development. In order for companies to keep up with market competition, many companies that are not structurally prepared to implement DevOps will still put together a team just to meet demand, which in turn creates vulnerabilities and gaps within their security posture.

    Today, only 46% of IT professionals are confronting security risks during the initial phases of development. With security as an afterthought, DevOps teams may overlook even the most basic security practices. What’s more, in an environment that relies heavily on code, we’ve seen time and time again careless developers leaking confidential information through APIs or cryptographic keys on sites such as GitHub. As a mecca for code, it’s the primary place cybercriminals turn to gain access to the credentials developers have stored in its platform and forgotten to remove before production.

    While GitHub breaches continue to put a spotlight on DevOps security, most organizations are still missing the big picture. The reality is security hygiene remains critical, and DevOps can put their organizations at risk by neglecting basic security practices such as monitoring access and embedded secrets, such as passwords, keys and APIs.

    Where Should DevOps Teams Begin?

    The solution is simple: separate highly valuable secrets from the developer. Luckily, the key to streamlining secrets doesn’t have to be time-consuming or costly. In fact, secrets management is, at its core, an extension of privileged access management (PAM), which many enterprises already have in place.

    As an essential approach to safeguarding an organization against bad actors, one of the fastest ways to mitigate the risk of DevOps-related data is to remediate weak security practices related to PAM.

    The following are some of the most important security protocols DevOps team should apply to their delivery pipelines:

    Inventorying Privileged Accounts and Access

    Large enterprises running networks with thousands of servers and network devices often lack an accurate inventory of assets. Most organizations create a security gap by not understanding the credentials within their systems due to inadequate deprovisioning processes. A DevOps environment’s use of automation and scripts makes it even more complicated to manage privileged accounts and access.

    To ensure DevOps practices are secure beyond the initial provisioning phase, security professionals must understand where automation is stored and what embedded credentials are stored within that automation. By understanding the entire embedded privileged credential process, adamantly keeping track of each DevOps team member’s access and leveraging automation, enterprises can instantly update a user’s access when their role changes to ensure they have the right access to do their job and nothing more.

    Secrets Management Integration

    A significant challenge for DevOps teams in managing privileged credentials is finding a solution that can be seamlessly integrated into existing development toolsets.

    Many DevOps teams rely on several different tools for different phases of the development process, and simply can’t afford to use secrets management solutions and processes that don’t integrate with and address all of them. For example, if an enterprise has invested in AWS and has an Azure-specific secrets management solution, tedious steps could be added to the process. In an environment that’s focused on rapid development, developers are likely to find ways to work around these inconveniences which can put the enterprise at risk.

    To ensure an effective secrets management strategy is put in place, enterprises need to understand that it must work with every tool in the DevOps workflow. By integrating security systems with tools developers know and use, enterprises can ensure no shortcuts are putting its sensitive information at risk.

    Understanding the DevOps Pipeline

    Traditionally, enterprises think the only way to obtain a secret is to log into a server, but in DevOps that’s not the case. In DevOps, when a user with privilege inputs a piece of code, it goes through a pipeline and many enterprises are oblivious to what happens within that pipeline. This blind spot could pose serious cyber risk to the organization. For example, if three developers are working on a project and they check in code that requires privileged access, such as copying credit card information, a developer could inadvertently interject dangerous code into that project and the security team is none the wiser.

    For an environment that’s focused on individualized actions, applying secrets management and thinking twice about who has access to build within this pipeline environment is critical. By not understanding how the pipeline functions and not knowing who has access to specific data, enterprises increase their risk of an internal breach or data leak.

    The reality is managing DevOps security has nothing to do with the actual DevOps process. By integrating basic privileged management protocols, enterprises can ensure security is at the forefront–and not the backend–of the development process.

    — Tyler Reese

  • 3 Reasons Why Ephemeral Access is Best for DevOps

    3 Reasons Why Ephemeral Access is Best for DevOps

    Recently, we worked with a customer, MOST Digital, whose developers were struggling with a common workflow challenge we hear from many companies.

    The company is in the software robotics automation space—it essentially makes little robots that automate all sorts of business processes for a company, such as HR report filing or routine emails. MOST Digital developers need access to customer environments to fetch data, often jumping in and out of on-premises and cloud platforms to do so.

    The problem was developers had to use client-specific jump hosts and VPNs to transition between IT resources. The process was slow, complicated and difficult to manage, which made life more difficult for MOST Digital’s team. Projects were delayed as they had to wait to receive help from each client’s IT organization.

    “This wasn’t what MOST Digital wanted for their team,” said Sami Säisä, director and head of strategic development at MOST Digital. “We want to provide them the best environments and best tools that there are available.”

    It’s a common refrain we hear from many customers, and it makes sense. The easiest way to frustrate a developer is to throw obstacles into their workflow. Unfortunately, most common secure access solutions create obstacles, and it’s not just jump hosts or VPNs. Even privileged access management (PAM) solutions, which are supposed to simplify and centralize IT credential management, are traditionally too bulky, complicated or non-intuitive for modern workflows. That encourages developers to bypass PAM altogether, which creates a major security risk.

    So, what’s the best way to overcome the complexity brought on by credential management? Well, why not just get rid of permanent credentials?

    Ephemeral certificates are a modern form of secure access that are temporary, time-based and automatically expire. Here’s why they’re a better solution for companies that want to keep modern developers happy.

    Ephemeral Certificates Offer ‘Just in Time’ Access

    Developers are building and coding in a world that emphasizes speed, agility and elasticity. They’re taking advantage of state-of-the-art tools meant to make it faster and easier to do work. They’re taking advantage of modern, hybrid IT environments that combine multiple cloud infrastructures in an attempt to find the most effective mix of resources for development and deployment.

    The last thing they want are processes that slow down workflow. Unfortunately, secure access today often means doing just that: slowing down and stopping to manually input credentials across environments. Developers might also share credentials among each other to try and speed up work, but that creates yet another security risk.

    Traditional PAM solutions don’t make the process any easier. Those tools create a central vault to manage an organization’s secure credentials. Privileged tech users, such as developers, have to use them to access and authenticate their credentials. PAM grants access per user and per host, so a new, permanent credential needs to be created every time a new developer, contractor or contributor needs access to a new IT resource.

    However, most PAM tools were not built with the workflow of the modern developer in mind, so they slow things down while also encouraging loopholes and workarounds that compromise organizational security.

    Ephemeral certificates overcome all of this by eliminating manual credential inputs. Gartner refers to these as just-in-time access, because access credentials are created on-demand automatically and require no installation, configuration or updating. In other words, they free developers to focus exclusively on the work they do best.

    Ephemeral Certificates Eliminate Bad Habits

    Rather than deal with all of the typical secure access challenges, some developers will often bypass PAM solutions altogether, instead choosing to spin up their own SSH keys to access the IT resources they need. Those keys exist outside of the PAM solution—they are untracked and unmanaged.

    Not only is it a policy violation to have developers find workarounds for IT-approved security practices (not to mention a huge waste of the investment in a PAM solution), but it also creates a security risk.

    The best way to encourage policy adherence is to make your policy easy to follow. Developers won’t bypass your security solution if it’s easy to use, and ephemeral certificates are inherently simple.

    There Are No Credentials to Misplace–Or Have Stolen

    If every developer is creating their own SSH keys to access IT assets and no one’s keeping track of them all, what happens if one is lost or when that developer leaves the company? Suddenly, there are keys laying around that could be scooped up and used as an all-access pass to systems in your environment.

    How do you monitor and audit this type of shadow IT access? How do you trace non-policy compliant access from development to production? How do you prevent developer access to sensitive data?

    Ephemeral certificates are inherently more secure because they are temporary, only existing for the period during which access is required, and automatically expire as soon as you are done using them.

    As a result, there are no credentials to lose, misplace or steal, leaving fewer old credentials lying around for someone to take advantage of down the road. On top of that, ephemeral certificates don’t leave user-specific access credentials stored on target servers, so if someone does get access to your target server, they won’t be able to find any credentials that could be used to hop to other systems.

    Ephemeral Access Is a Step Closer to DevSecOps

    From security to IT management, there are lots of reasons why ephemeral certificates are a better solution for businesses. But the single most impactful use case is making your team’s life easier.

    Want to frustrate a developer? Throw some obstacles into their workflow. But if you want to keep your developers busy on value-driving activities, get rid of outdated and unmanageable workflows. They’ll thank you for it later.

    — Markku Rossi

  • DevSecOps: Can JIT PAM Bring Relief?

    DevSecOps: Can JIT PAM Bring Relief?

    IT and cybersecurity leaders have come to agree that the purpose and intent of DevSecOps is to create a mindset that “everyone is responsible for security,” while also incorporating application and infrastructure security directly into the software development and delivery process. DevSecOps has proven to be a critical ideology for cybersecurity, yet is littered with false starts and failures. Many of those failures can be attributed to a basic misunderstanding, wherein IT management has come to use the terms DevSecOps and DevOps interchangeably, because of the false belief that security is already part of the DevOps process.

    A recent CyberArk DevOps Survey polled respondents to determine if DevOps and security teams were integrated, less than half of the respondents said yes. What’s more, almost three-quarters said they had no privileged account security strategy for DevOps and some 99% failed to identify all of the different places privileged accounts or secrets could exist in a DevOps environment. The survey demonstrates that common and well-established security practices have not been adopted by DevOps teams. Clearly, DevOps and DevSecOps are not synonymous.

    A clear vision of what DevSecOps should be about can lead to DevOps teams releasing vulnerable software and exposing enterprises to unnecessary risk—a problem that has been manifesting itself in the rush to embrace digital transformation and re-engineer legacy apps into cloud-based equivalents. Expediency combined with a lack of understanding increases risk, which should cause alarm.

    For the most part, breaches occur because of a lack of privilege management, In other words, proper security practices dictate the who, how and when of access, along with the permissions associated with that access. It is a concept that has given birth to platforms that manage privileges, also known as privileged access management (PAM) solutions. For DevSecOps to succeed, the concept of privilege must be embraced. However there is more to security than just privilege management; namely, the context of privilege must be incorporated, such as the “why,” “when,” and “where” of access.

    Simply put, administrators and managers often forget to revoke the rights of temporary workers, contractors and other non-employees when a project is complete. It’s an issue that plagues many DevOps teams that rely on freelancers to help move the processes forward. The lesson here is one of instituting better controls and policies, which ultimately can be adopted throughout the enterprise to bring better cybersecurity to fruition.

    JIT PAM to the DevSecOps Rescue?

    Better control over privileges has created a new acronym, JIT (just in time), that takes residence in front of the PAM acronym. The concept of JIT PAM, which is being promoted by security vendors such as Beyond Trust, is one of controlling access based upon a number of different policies that are further enhanced with behavioral data.

    At the recent Beyond Trust partner summit, cybersecurity expert Derek Smith noted, “Privileged credentials exist everywhere and 100% of all advanced attacks rely on exploits of privileged credentials.” That’s a sobering thought for those in charge of cybersecurity and those who are part of the DevSecOps process. Smith said some of the best practices around PAM include, “Track and secure, govern and control, and record and audit,” exemplifying the need for a platform approach. For Beyond Trust, that means creating a platform that defines a new paradigm of trust, one that builds policy around the who,what,why,where,when of access.

    The concept offers valuable lessons to DevSecOps team members, lessons that entail incorporating the proper security elements into the application and infrastructure layers of service delivery. For the short term, those capabilities may be beyond those in the DevOps arena, meaning that they may have to turn to third-party platforms to bring forth better security. On the plus side, JIT PAM can also be used to secure legacy applications, giving DevSecOps teams more breathing room to define and re-engineer those legacy applications as they transition to the cloud.

    — Frank Ohlhorst

  • DevOps Security: 3 Privileged Access Management Best Practices

    DevOps Security: 3 Privileged Access Management Best Practices

    The tremendous upside of DevOps practices and tools are enough to keep organizations pressing forward at all costs. But when sloppy use of DevOps toolchains cause breaches, more than half the time it comes down to poor protection of privileged accounts. According to a recent study by security vendor Beyond Trust, 52 percent of IT practitioners say that overprivileged users are at the root of DevOps and other next-generation technology-caused breaches.

    If organizations are going to reap the biggest benefits from DevOps without putting their IT infrastructure and data at risk, they’re going to need to think more strategically about how they handle privileged access management (PAM), said Morey Haber, CTO at Beyond Trust. devopsy.kinsta.cloud recently caught up with Haber to break down three of the most important PAM best practices for DevOps teams to build into the continuous delivery pipeline.

    Discover and Inventory All Privileged Accounts and Assets

    You can’t manage accounts and assets you don’t know about, so this step is foundational to the whole process of PAM. Unfortunately, with so many scripts and so much automation layered all over the DevOps toolchain, it can be tremendously difficult.

    “If it’s embedded in other runtimes or it’s hard-coded into compiled executables, that discovery is the hardest,” Haber said. But it must be done. Organizations need to get clear visibility into exactly what tools are executing the automation and what the privileges are assigned to them. “Is it a power-shelf script? Is it embedded in Jenkins or somewhere else? What is actually running? Who’s running it and when?”

    Additionally, organizations need to understand where the automation is stored and, consequently where that embedded credential information is being stored, so it can be examined for tamperability and safety of the credentials.

    “Now, this isn’t something that’s easy to discover in any of the three contexts, but it has to be,” Haber said. “So, one you have to understand the entire process and where you’re actually embedding privileged credentials for the edit, storage, operation and scripting itself.”

    Manage Shared Secrets and Hard-Coded Passwords

    Hard-coded passwords are one of the biggest no-nos in credential management. Unfortunately, even when application security teams are meticulous about rooting hard-coded passwords out of their finished applications, they often leave them within the IT infrastructure that helps support the development of that software for the sake of expedience. Same goes for account sharing, which is a frequent mistake organizations make to just get the automation working and keep it working with stability.

    The problem is, this trashes any semblance of traceability or auditability of activity within the affected environment.

    “Whether that is using some type of proxy technology, a VDI environment—anything, you don’t want people logging in directly with shared accounts because you can’t trace that,” Haber said, noting there needs to be a control plane in the mix that can keep track of both individual users and script or automation accounts that are impacting the environments to track each process or activity against unique credentials. This is essential not just for compliance, but for forensics and the overall integrity of a DevOps team’s software “factory.”

    Enforce the Rule of Least Privilege

    Ultimately, strong PAM depends upon only giving individual users or specific automation accounts the exact amount of privileges they need to get their job done.

    “We see credentials being given to DevOps teams all the time that are way, way overprivileged,” Haber explains “It should come down to the least privileged model—that you’re giving enough privileges for the DevOps process to work, but not overprovisioning so that if any process or account is compromised, it doesn’t jeopardize the rest of the environment.”

    — Ericka Chickowski