How to Deliver Privilege Access Management

Transcription

1 How to Deliver Privilege Access Management Running a PAM project can be a big challenge for an organization. Many security projects can be largely stand alone, impacting operational teams in the business only peripherally and often only during deployment. PAM projects are different in that they seek to change operational processes in a way which is certain to impact support and application teams and may also impact developers and other teams. Successful PAM projects can actually have a beneficial effect upon overall operational effectiveness however, not only reducing the number outages within an organization but actually making it quicker and easier for authorized individuals to access systems for maintenance and repair. Scope The scope of a PAM project is, as for every other project, important to get right from the start. A PAM project concerns systems, accounts and processes and the scope for the project must consider all of these elements. Whilst a large scope may offer the promise of a greater return and cheaper unit pricing, it also increases the chances of project failure or at the very least unexpected challenges with inevitable additional cost and complexity. Try ring fencing the initial scope and limiting it to one geography or business unit. Be aware however that the scope needs to fit with the way your organization already operates. If you have a global windows admin team, then a regional scope will be harder to control than one which instead focuses just on Windows servers and excludes other platforms. Similarly, be careful that you understand everything in your scope and don t exclude anything which cannot reasonably be separated out. If for instance you have very heavy use of systems accounts by applications, then excluding application use of privilege may make it impossible to deliver a truly effective server and administrator project. Indeed, the very first stage in your project, even before you have started to build out your PAM control infrastructure should be to document the three elements within your scope. Workstream 1 Assessment & Documentation PAM vendors will normally supply tools to help you identify privileged accounts and where they are used. This is a very good starting point in building out your scope. What these tools will generally not help you with is the process element. Consider the simplistic case of a single application server: The server will be built upon an operating system which will have in-built service accounts. This might include root for UNIX and local Administrator for Windows. There will almost certainly be other subsystems which each have their own privileged service accounts so even at the operating system level there are likely to be several accounts requiring control. Next, the server may require middleware and even simple applications might have a database and rely upon a web server. Both of these will have service accounts associated with them and may well be managed by different teams. Already we have three groups of service accounts used by three different operational teams. There will also be some overlap with Web and database teams using the root/administrator account at times. Now we add the application, which may come with its own service accounts but will likely use some of the above. It will probably be managed by its own operational team and may also have developers with access to the system as well. We now have possibly five teams with four groups of service account and lots of cross use of accounts by different teams. Now overlay upon this picture the different processes which might be involved in accessing this system. There will certainly be change control and trouble ticketing systems which regulate what is done to this system, but these processes may well be bypassed in the event of a catastrophic failure. There may be regular maintenance processes outside of the formalized change control system and there may be break glass systems allowing developers to access the system. Move into a world of Devops and things may get even more complicated. Capturing the details of the systems and accounts and who uses them is not sufficient, it is vitally

2 important that you have the context of how those accounts are accessed by the various teams. Fortunately, this problem doesn t scale too badly; there will be many such servers but they will all be managed by one platform team, one database team and one web team. The applications teams may vary but at least the problem for the rest of the teams stays manageable. You will end up building a matrix of access which is system by account, by team, by process. This matrix is important as it will shape the way you manage privilege within your PAM system. Much of this detail will come through discussion with the management and members of the individual teams. Listen out for exceptions to process. One team may tell you that everything goes through ServiceNow or some other system and another team may announce that they don t use that. Getting access logs from a few systems can be enlightening as often teams will tell you they do things by-the-book but the logs will tell you differently. 80% of security breaches involve privileged credentials Ensure that you make friends with the teams because you are going to have to work with them to redesign many of these processes to live within your PAM environment. You are going to want these people to be reasonable and open to new ideas so you had better show them the same regard when trying to understand how things are at present. One of the most important things you must do now, and this is often forgotten by PAM projects, is to understand the SDLC or System (not software) Development Life Cycle. How do new systems get brought into existence and what happens to them when they are taken out of service? There is nothing more frustrating than running a PAM delivery project only to find a year later that you have many systems operating outside of it; or that you have a constant operational challenge for the PAM team in manually adding and removing systems. A good PAM project will seek to automate the sustainability so that your PAM system doesn t try to change passwords on decommissioned servers and knows about servers newly added. PAM isn t just for servers and operational teams. One of the best uses of PAM is allowing security controls like vulnerability management systems to access the infrastructure. This can often be a quick win as PAM systems such as CyberArk come with interfaces to many common technologies built in. Make sure that your project considers opportunities like these in its scope. Workstream 2 Building the Control Building the core PAM infrastructure out is probably the only easy part of the project. Bear in mind however that the PAM system may end up controlling privileged access to most of the business-critical systems in your organization. You are going to have to ensure that it is very secure and that it has very high availability. How you achieve this will depend upon the PAM solution you have selected. CyberArk for instance has both security and high availability design in from the start and the patterns for achieving your required levels of both are readily available. It is important to think about the nature of your organization here. It is great if your password vault has six nines of availability but if users can t access the password because the web front end or workflow element is unreachable in an isolated data center then you are asking for trouble. Think in terms of service continuity here rather than system availability or disaster recovery. And remember, the time it becomes most important to access privileged accounts is during a major outage. Your PAM system is most needed at the time it is most likely to be unavailable. Finally, you must have a doomsday option of a manual recovery of passwords and a manual process for disseminating them if all else fails! I have already mentioned PAM sustainability in terms of systems under management but there is a very important sustainability element in terms of users of the system. PAM is there to allow authorized individuals (and occasionally systems and applications) to access privileged accounts under appropriate circumstances. Deciding who is authorized and who is not is a key element of any PAM system. Authorization is generally to a group of system and accounts on those systems and tends to

3 align with team boundaries. Windows system administrators for instance may be authorized to access local Administrator accounts on some or all Windows servers in the organization. They should not however be authorized to access root on UNIX servers, nor should they have automatic access to local Administrator on their own workstation! Correctly authorizing users to be able to request access to an account is normally done within an IAM (Identity and Access Management) system. You may know it as a provision system or similar. Correct integration with this system is a vital project goal in any PAM delivery project. This is certainly not a oneoff activity as individuals will come and go and will change teams, moving from server support to application management teams for instance. The PAM system must be integrated with the organizations JML (Joiner, Mover, Leaver) and Recertification processes to be effective and this is almost always accomplished by ensuring that it is properly provisioned through IAM. Where this can often be challenging is where IAM systems are ineffective or not ubiquitous and it is often true that organizations have multiple provisioning systems for different parts of the organization. When integrating with these systems remember that using a poorly governed system run by a system administration team may not meet governance standards as it is their access which you are seeking to control. Workstream 3 Delivering PAM Services The core of any PAM project is building out the process models to allow authorized users to access privileged accounts. Remember however that these processes already exist within your organization and your challenge is to regulate and control them with PAM. As a bonus, you can take manual process and make them automated to actually improve the efficiency and effectiveness of your operational teams. Delivering processes which lead to the operational organization being less effective must be seen as an overall project failure and avoided at all costs. 40% of organizations use the same security for privileged accounts as standard accounts To achieve service quality improvements whilst also improving privilege account governance, it is necessary to look at the existing operational processes. The first thing to note is that not all existing processes should be allowed in a post PAM world. Some access to privilege may not meet organizational standards or may explicitly be prohibited by local statute or through industry compliance frameworks. Typical examples of this might include Financial Services rules from regulators such as the MAS as well as banking secrecy rules governing access to systems and data in jurisdictions like Switzerland or Luxemburg. Ensure that you understand the frameworks within which you must operate when evaluating access and processes for inclusion in your PAM system. Identifying such issues early on will help as careful negotiation will be necessary and alternative approaches must be developed to ensure that operational capabilities are not put at risk. Once you have a list of processes to be onboarded into PAM you can begin to consider how to achieve good governance and control whilst improving service efficiency. The easiest way to improve efficiency is through automation. A process such as accessing an account on a system to perform some scheduled maintenance or to resolve a reported problem will normally be driven from a change control or trouble ticketing system respectively. A ticket will be issues covering a particular system or subsystem and assigned to an appropriate individual for action. That individual has already been authorized to use privilege to perform the duties specified in the trouble ticket or change request. The change or ticket has probably already received approval from the system owner and it is therefore pointless to have a PAM workflow which requires the system owner or head of the admin team to authorize the access. Integrating PAM workflow systems with your existing change and trouble ticketing systems increases efficiency without impacting the level of control or oversight of the use of privilege. Another typical situation might be emergency access to a system where time is of the essence. It can be

4 very frustrating for all concerned, if during a major service outage, those most capable of restoring proper operation spend their time trying to find approvers for their access. A typical PAM enabled process might require post approval (within a set time period) for access used during a declared outage or emergency. The fact that only preauthorized individuals are able to use this access and that approval is provided after the fact ensure that oversight is maintained without increasing risk to the environment, and this probably closely mirrors how things are done in a pre-pam environment. Vaulting Vs. Fully Managed PAM One of the most frustrating aspects of past PAM projects I have observed is the belief that initially the PAM project should simple vault the accounts in scope rather than have them under full management. In a fully managed system the PAM solution takes responsibility for changing passwords on target systems and can do this periodically as part of a password rotation strategy as well as after each access to avoid passwords becoming known to system administrators. In a vaulted or stored solution, the users are responsible for changing passwords. Project teams who believe that the vaulted solution is a half-way house to the fully managed systems are mistaken. Fully managed systems provide both significantly better security and governance at the same time as improving operational efficiency. There is no good reason to deploy a vaulted only system in a welldesigned PAM environment. Other Considerations So far, we have only really considered core PAM functionality, but PAM offers many more capabilities for the mature organization. Fine Grained Access Control The PAM systems discussed in most of this document refer to coarse grained access to highly privileged accounts but often it is desirable to provide more fine-grained access for some users. UNIX has long had the sudo system designed to give specific individuals access to just some subset of UNIX commands but the sudo system was 20% of organizations have never changed their default passwords on privileged accounts designed and developed in a time where security and governance needs were far less demanding. Often these systems were run by the system admins themselves and were thus prone to abuse and lacked oversight. Use of fine grained access is highly desirable in very dynamic environments where application teams are making frequent changes to services and even where users require greater control of their own workstations than might be normal. Good PAM solutions can provide such fine gained control and integrate it within the overall PAM environment, benefiting from monitoring and oversight as well as automated authorization, sustainability and other features of the core PAM system. Even if you don t have fine grained access management within your initial scope consider how a later project may look to take advantage of such features. Direct System Access One of the best ways to improve both security and efficiency is to miss out the stage in the process where an authorized user receives a password and must then connect to and login to a target system using that password. Modern PAM systems should provide a mechanism of directly connecting the user to the system without that individual ever needing to know the password. The advantage of such systems from a security and governance perspective is that monitoring or recording of the session is also often possible with such direct connections. This may be particularly important in highly regulated industries and goes a long way towards root cause analysis for system outages due to poor systems management. Devops If your environment relies on agile Devops processes select a PAM system which supports Devops by design. PAM systems which do not have specific Devops tooling will struggle and probably fail to support the needs of an agile environment. Devops solutions do exist but failing to integrate them with PAM can cause significant management and governance headaches once operational.

5 Monitoring, Reporting and Analytics An important secondary control in Privileged Access Management is monitoring. This can range from being able to report on who is accessing which privileged account and equally importantly who can access those accounts and under what circumstances, to being able to replay or analyze individual sessions to confirm what activity took place whilst privilege was used. More recently analytics on use has become possible with the ability to spot misuse of accounts using machine learning technology to identify anomalies. Often this more advanced ability is located in a separate SIEM or UEBA system but CyberArk has integrated this ability into its own solutions. SSH Key Management A big challenge, particularly in UNIX environments is SSH key management. Much like passwords, SSH keys are used to protect access to privileged user accounts and verify trust in automated application to application communications. Some organizations use stand-alone systems for discovery and management of SSH keys but integrating SSH key management with your primary PAM solution is far better. If key management is or is likely to be an issue for your organization, ensure that you select a PAM solution which includes an SSH key management facility. Summary To run a successful PAM project, consider the following: 1. Align your scope to your organizational structure. This is particularly important when delivery is to be staged over several project cycles. 2. Build up a picture of Systems, Accounts, Users and Operational processes. This will inform the structure for access within your PAM control. 3. Don t forget to build in sustainability by considering the system development life cycle. 4. Design your control for the required level of service continuity and have a backup plan when that isn t enough! PAM will effectively be a service at the highest level of criticality for your organization. 5. Integration with IAM or provision systems is vital for sustainability but these systems must be well run to avoid undermining the effectiveness of you PAM control. 6. Ensure that you understand the frameworks within which you must operate when evaluating access and processes for inclusion in your PAM system. Not every existing process or access criteria may be acceptable in a post PAM world. 7. Integrate with trouble ticket, change control and major incident systems to provide automation for many common processes. 8. Think in terms of real world uses for privilege and avoid adding complexity or needless levels of control or oversight to PAM authorizations. 9. There is no good reason to deploy a vaulted only system in a well-designed PAM environment. A fully managed environment is superior in every way to a vaulted system. 10. If your environment relies on agile Devops processes select a PAM system which supports Devops by design. 11. Monitoring and reporting is an essential secondary control for PAM and some regulated industries may require session monitoring or advanced analytics. 12. UNIX environments tend to be heavy users of SSH keys for privilege access and whilst separate SSH key management tools exist it is better to have this integrated into a PAM control.