Tag: PAM

  • How Can IT Admins Maintain a Grip on Secure Access?

    How Can IT Admins Maintain a Grip on Secure Access?

    Today’s IT environment is evolving at a rapid pace, requiring production environments to be highly scalable and elastic and requiring faster software release cycles and cloud adoption.

    As a result, there’s a broad move toward Docker containers to make software deployment faster, easier and more consistent across computing environments. Bundling an application and its supporting code, libraries, settings and assets into a single container enables the speed and flexibility that today’s business environment demands.

    At the same time, many large enterprises are also experimenting with creating internal startups, or labs, that are given latitude to innovate, housed under the company umbrella and resources. Similarly, some companies are hosting startup-like “innovation incubators,” where developers are empowered to think and work like startups, within the relative safety of the corporate environment. They can quickly test new ideas, using the “fail fast, succeed fast” startup mentality, without incurring the usual risks of an independent startup.

    It’s a new agile way of working that companies, in the race to innovate, are widely embracing. In fact, more than half of Fortune 500 companies have some version of these startup-like efforts housed within at least one business unit. 

    Replicating the unstructured movement of a small–say, six-person–startup is difficult to do within an enterprise environment. Nevertheless, the rapid pace, combined with the flexibility to innovate, is what the vast majority of developers desire today. But, it does mean that enterprises’ IT environments have to be ready to adapt.

    IT Administrators Under Pressure

    Developers on these innovation teams are often given the freedom to select the tools they’d like to work with. That can–and often does–include Docker containers, which adds to the complexity of the IT environment. 

    The environment that fuels developer innovation also creates additional concerns for the IT administrators supporting them. Developers can work so rapidly–creating hundreds of new servers each day–but often only do the bare minimum in terms of security. How can IT admins maintain secure access in the face of these changes? How can they keep track of who has access to what application and what data, when those applications and data are constantly changing? That’s a massive issue when it comes to compliance.

    As containers make enterprise IT environments even more complex, IT admins are under pressure to carefully manage access without slowing down development. The more complex the environment becomes, the more important it will be to have a holistic view of all of their underlying infrastructure, including the hybrid or multi-cloud environments that support platforms such as Docker and Kubernetes.

    Meanwhile, the enterprise executive team, often the CISO, overseeing both the development and IT departments is hard at work trying to satisfy the requirements of both groups. Of course, it’s in the business’s best interest to innovate and explore. But, all that innovation means nothing if the business is no longer secure and open to compliance concerns.

    Below are three steps executives should follow in order to keep their developers and IT admins happy.

    Consider the Developer Experience for Secure Access

    Off-the-shelf single sign-on solutions (SSO) may be good enough for business employees who need to access Outlook or Salesforce, but they aren’t robust enough for privileged IT users, like developers, who need to access secure environments. 

    Privileged access management (PAM) software sprung up to serve IT users, but even this isn’t a perfect solution, because traditional PAM tools are often too clunky to use, nonintuitive, or hard to configure. A bad user experience simply encourages developers to bypass PAM however they can, which is a compliance risk.

    Businesses need a way to deploy secure access very quickly, so they can holistically manage access to critical IT resources without slowing down development. That means choosing secure access solutions that are built with the developer’s needs in mind.

    Lean PAM solutions prioritize automated, instant access to secure IT environments with the click of a button, combining the convenience of modern SSO solutions with the security and fit of a PAM solution. If sysadmins have a great PAM user experience, they’re more likely to play by the rules. 

    Opt for Role-Based, Time-Bound Access

    To maintain the highest levels of security, access must be controlled on a role-by-role basis. Your rock-star in-house developers should be able to quickly spin up access to core IT infrastructure whenever they need it, while a third-party development contractor should only have limited access to those same resources for the time in which they are working in your environment–and no longer than that. 

    This is where we begin to see time-limited, credential-less secure access, enabled by ephemeral certificates, start to play a role in privileged access management. Ephemeral certificates are short-lived access tokens that are automatically generated and automatically expire–so access is granted only for as long as it is needed to authenticate and authorize privileged connections. 

    In other words, privileged access is able to move toward a just-in-time model, eliminating the need for passwords and clumsy credential management. IT users no longer need to authenticate using credentials at all–instead, based on predefined roles and security policies, they are granted access to resources only as and when required.

    Ultimately, ephemeral certificates help streamline access processes, ensuring that IT admins don’t have to worry about revoking access when access roles or needs change.

    Make It Easy on the IT Admin, Too

    Speaking of IT admins, it’s important to consider their experience, too.

    Admins want to give staff the best tools for the job without compromising corporate security. The friction between admins and developers begins when the developers feel that the tools admins force them to use are slowing down their work. In reaction, admins become frustrated when more unmanaged, unmonitored tools enter the corporate network, requiring more of their time to implement, configure or remediate if something has gone wrong.

    The right technology solutions make life easier for IT admins, too. That means secure access solutions that can be installed and deployed within a single day–not weeks–and that introduce automated routines and maintenance to eliminate manual work in the access management process. Accountability, in the form of session monitoring and logging, is also important. 

    Ultimately, it’s about giving IT admins some distance. They can retain the oversight they need to feel comfortable about organizational security, without needing to be on top of every single secure access decision in the organization. At the same time, developers retain the autonomy they need to work quickly without feeling like they’ve got someone looking over their shoulder. 

    By enabling rapid development, while keeping a watchful eye on enterprise security, enterprises can satisfy both their developers and IT admins, and ultimately, the business’s bottom line.

    — Markku Rossi

  • 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

  • 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