Securing Digital Identities Through Mergers and Acquisitions

Digital identities are a common part of any modern enterprise organization. Tracking and management of these identities can be a difficult task. Many times, the merging organizations have different approaches to digital identity management and could have very differing opinions on how to secure them. This is especially true if both parties already have their own PKI environment and processes that need to be integrated. Each will have its own set of identities and templates that have already been deployed, and its own way of managing applications.

Many organizations look at M&A as a chance to update and standardize the way they do things. Some may move infrastructure to the cloud, while others look at it as an opportunity to implement new technologies or invest in outsourcing. But what many organizations fail to realize is that M&A provides the perfect opportunity to incorporate an enhanced digital identity management platform to both elevate overall security capabilities, and optimize the IT project work associated with  M&A.

Large scale projects of M&A are exactly when you need to have the right tools in place to manage data and track changes. Identity management tools have the power to help you quickly gather information and easily automate tasks throughout the merger process. Automating the discovery process allows you to have a continuous view of the digital identities in the environment without the headaches of trying to manually track them.

Here are a few examples of why an M&A is a perfect time to implement the proper enterprise tools for digital identity management:

• In the case of having multiple PKI environments, the issuing Certificate Authorities (CAs) from both environments will need to be distributed to the end-points across the combined organizations. This ensures that all of the certificates can be trusted. If this is not done, critical errors can arise, such as:

• • Application whitelisting can fail on security devices
  • SSL connections to enterprise applications can fail or be very inconsistent, causing an overload to the help desk
  • SSL interception technologies such as WAN accelerators, SSL Inspection devices, and proxy servers can cause traffic blocks if their issued certificates are not trusted by all entities.

• Many applications will need to be moved or re-platformed. Having a tool in place to quickly issue certificates and deploy them to the appropriate locations is vital. Manual processes will slow down integration tasks and cause human errors that are difficult to track down.
• There may be a general lack of security visibility for integrated servers and applications. Having a tool in place to detect and report on these issues can allow the new security team to quickly assess weaknesses and respond to them in a timely manner, instead of being surprised by a new audit finding down the road.
• Modern IT organizations are looking for options to alleviate the workload from day-to-day management and security of an on-premise PKI environment and move to a PKI as-a-Service offering. M&A is an ideal time to migrate a new PKI infrastructure into a secure hosted solution.
• An additional budget may be available. In most organizations, IT budgets are held flat year over year. M&As often unlock additional “Integration” funds that can be used to implement new toolsets. At the end of the M&A when IT budgets are re-assessed for the combined company, the expense spends for the new tool subscription/maintenance can then be justified and rolled into the ongoing IT budget plan.

Many of the tasks identified below can be greatly simplified by implementing the Keyfactor’s PKI as-a-Service and certificate lifecycle automation platform before or during an M&A project. While migration projects will vary greatly between organizations, the tasks below illustrate some of the most common questions and scenarios that Keyfactor solves. Let’s see how you can optimize these tasks and make your migration easier, faster, and more secure.

An M&A can present unique budget opportunities for an IT Manager. Corporations realize that they will need to invest in new tools and services to complete the M&A activity. For this reason, organizations often create special integration budgets to absorb these costs and write them off as spending related to the M&A.

This gives IT managers the opportunity to have greater flexibility in what they purchase and how much they spend.

After the M&A is complete, IT budgets will be re-assessed and adjusted to accommodate the management expenses of the combined company. If tools that were purchased for the M&A are still needed, these expenses will be added to the overall IT budget going forward.

When it comes to digital identities, there are four main areas that should be looked at when considering IT spend for an M&A:

1. Tools – Having the right tools in place can help minimize labor costs associated with the M&A, as well as your long-term IT management costs. The right platform should make all of your digital identity management tasks more efficient and your data more accurate. Keyfactor’s platform has the capabilities you need to automate and scale, and can be brought in as a fully managed cloud-hosted solution or client-hosted solution.
2. People – Ensure that you have enough people to do the job right. Digital identities are a key piece of your overall security strategy. An M&A is not the time to cut corners. Ensure that you are adequately staffed to address the issues that come up and correct This may include bringing in consultants or additional staff during the M&A project. Keyfactor has experts in all areas of digital identity management, as well as partnerships with industry leaders in encryption hardware platforms. Let us help you find the people you need to be successful. Keyfactor also has the capability to fully outsource the management of your CAs.
3. Security – Redesign and rebuild during an M&A brings the opportunity to make improvements. Your environment should always be more secure after an M&A than it was before. Don’t take steps backward. Digital identity is a key attack vector for security incidents and must be constantly improving. If you are migrating your CAs during an M&A, take the opportunity to put additional safeguards in place. Here are a few examples of improvement opportunities that may present themselves:

• Consider outsourcing your infrastructure to PKI management experts. Your company is not in the business of running PKI systems. Keyfactor is. We have teams of industry experts combined with decades of PKI management experience that can manage your PKI for you and help ensure that your data is secure with our SOC 2 Level II certified data centers and
• Implement new tools for auditing and reporting of certificate use. Improved visibility of your environment for how certificates are being issued and deployed will greatly increase your ability to detect and respond to incidents quickly and
• Implement HSM technology to secure critical identities. At a minimum, this should be included for the storage of your issuing CAs, as well as high-value certificates such as code signing certificates or certificates used for external facing critical systems.
• Implement a secure code signing solution. Signing your internally developed code and scripts can greatly increase your security posture. It can enable technologies such as application whitelisting and secure software deployment tools. Since code signing certificates are critical assets in your company, make sure you have a solid plan of how to manage these certificates prior to deployment.
• Improve physical security. If the M&A project requires you to move equipment make sure that the new data center has security controls in place for best practice deployment. Secure your assets with secured cabinets or video surveillance systems.
• Implement new automation technologies to allow automated certificate management and deployment. This can be done in conjunction with DevOps projects that may be happening as a part of the integration

When starting a merger or acquisition, IT organizations have common tasks that are key to the project’s success. This process starts with digital certificate discovery and builds through the implementation of the merged systems and completion of the M&A. Being able to move quickly through the initial phases of the project will allow you to more accurately define the timeline, task list, and overall budget for the project.

• Discovery and Inventory
• Policy Definition (Standards & Policies)
• Migration Planning
• Implementation

These phases are typically an iterative cycle that includes these high-level categories:

The first step is always to assess what you really need to merge as a part of the project. This is true for all IT infrastructure. What servers do we need to migrate? What applications are in scope? Is there a duplication of functionality that needs to be merged into a single platform? All of this is true for servers, networks, data, and digital identities.

The digital identity function is commonly overlooked by organizations as not essential. But as they move forward into the implementation phases, they find out that it is business-critical to the process. Unfortunately, many organizations often begin addressing it far too late in the process.

Without a quality digital identity management tool in place, administrators must try to manually inventory the thousands of certificates from all of the devices and certificate authorities in the enterprise, and keep up with the constant change.

Obtaining a clear understanding of the overarching digital identity infrastructure is essential to maintaining the longer-term security of an organization and its corporate reputation. Most certificates have a multi-year lifetime and need to be managed throughout this process. A security incident due to mishandled certificates or acquisition of an organization with inadequate security policies could lead to an expensive breach.

Here are some common questions about digital identity that must be answered very early in the process:

• What certificate authorities are in use? (public and private)
• How are certificates issued, and what is the approval process?
• What certificates already exist in the environment, and where are they installed?
• How are code signing keys issued and secured and who has access to them?
• Who has the ability and access to perform certificate management tasks?
• Are any applications or infrastructure components reliant on these issuance processes for automation?
• How can we establish enterprise-wide trust for identities from both organizations?
• How many certificates do we have in use before and after this migration? (Note: If you are currently relying on a digital identity management product that relies on per-certificate fees, this could have a significant impact on the project budget.)

A primary key to gaining efficiencies in the discovery process is automation. Most organizations have far too many certificates in their environment to try and manually maintain an accurate list. It is not uncommon for an enterprise to have 500,000 or more certificates in use. These certificates renew or expire every day, so having dynamic data connections is critical to seeing the most current and accurate information.

The Keyfactor platform offers several options to quickly get this information into the console for reporting and management.

• Direct integration with private and public CA databases – Our direct integrations allow for real-time inventorying of issued and revoked certificates to be imported into our database. Any certificate issued by the will be available for reporting/management whether it was issued through the Keyfactor system or not. Our ability to integrate with multiple certificate authorities allows you to integrate PKI environments from both organizations into a single consolidated platform.
• Robust SSL/TLS scanning capabilities – Our SSL/TLS scanning capabilities can be used to identify certificates that are presented on the network. This can help detect where certificates are used. It will track what IP addresses and ports the certificate appears on, and automatically populate that usage information back into the certificate database.
• Certificate store management and inventory – Our management orchestration engine connects to certificate stores on common devices to manage inventory, deployment, and revocation tasks. This inventory is then tied to the certificate database information. These common locations include Windows/IIS servers, Java keystores, and F5 BigIP devices. Any other device that supports the management of certificates via an API can be integrated into the platform for certificate automation via our AnyAgent technology.
• Certificate Store Discovery – Our software scans and identifies hosts and keystores such as Java Keystores or PEM files. These keystores can then be brought under management and directly managed from the Keyfactor platform.
• Manual Certificate Import – Any certificates that are currently not online or available can also be imported directly into the application.

Once the certificates are imported into the database, detailed search and reporting capabilities can be used to present data that will be critical throughout the migration. These reports can be generated through scheduling or in real-time. Here are some examples of reports that may help throughout the M&A process:

• How many certificates are still active on a particular Certificate Authority or template?
• What certificates are coming up for expiration?
• How many self-signed certificates exist in the organization?
• How many wildcard certificates do we have?

With a Digital Identity Management Platform in place to automate certificate management, the discovery and management of certificates can be automated, and the administrators can focus on managing the results through the console.

As additional information is discovered about a certificate throughout the project, it is also important to be able to quickly and easily store that information with the certificate. This information is held so that it can be used for future reference or used in conjunction with the implementation of automated processes. This is referred to as metadata. The Keyfactor application can support adding as many metadata fields as necessary to your certificates. Metadata can be viewed in the console, exported to reports, or consumed via the API.

Some examples of key pieces of metadata that you may want to track with the certificate are:

• Application Name
• SDLC environment (Dev, Prod, Test, etc)
• Cloud platform (AWS, Azure, Google)
• The owner (User or Department)
• Email address for notifications (Team Distribution List)
• Cost center for charge-backs
• Help desk ticket number from the original request
• Project name
• Notes about tasks related to the renewal process of the certificate (up to 4000 characters per field).

Due to the number of certificates in use, it is also necessary to be able to manage these certificates at scale. Reporting, management, and editing of certificates must be able to be done by groups of certificates. At Keyfactor, we refer to these as “collections”. Collections of certificates can be defined based upon any criteria you specify, whether it be x.509 certificate data or metadata associated with those certificates. Criteria can be grouped into logical groupings using and/or operators to further define your collection. These collections can then be integrated into Keyfactor reporting, dashboards, and automation processes. Security delegation is also available for the management of these certificates.

After you have a good understanding of the digital identity landscape, it is important to review the architecture and security policies being used in both organizations and determine what your standards and policies will be going forward. In some cases, this may be an M&A of the policies of both companies; in other cases, one company’s security policies and architecture decisions may better meet the needs of the newly integrated enterprise. Either way, the architecture, and standards must be defined and documented so that your infrastructure and development teams know how their solutions should be implemented.

Different organizations may have very different approaches- es to how digital identities should be issued and managed. Some are very lax and may allow for scenarios such as granting far too many administrators permissions to generate certificates or access private keys. These standards should all be reviewed and decisions documented.  Some of these decisions may result in a significant amount of re-work for the application migration teams, so it’s best to include input from those teams in your decision-making process.

Common questions in this phase of the migration are:

• Who is the responsible decision-maker for digital identity policies and migration plans? There will be conflicts between organizations that need to be resolved.
• Will administrators from both organizations continue to have access to certificates, or will those roles be pared down and consolidated to a specific team?
• What is the appropriate level of encryption within the organization (i.e., algorithms, key length, issuing, etc.)?
• Where will HSM technology be used to store keys?
• How will code signing be handled, such as who can sign code? (Note: This is critical to the development work that will happen as part of the M&A)
• What will be trusted and used in the organization? (private and public)
• Will any existing CAs be deprecated, and if so, which certificates/applications will be affected?
• What is the acceptable key handling policy? How are private keys communicated and transferred between devices and individuals?

After you have a good understanding of the overall digital identity landscape, it is important to review the architecture and security policies being used in both organizations and determine what your standards and policies will be going forward.

Defining policies and standards can be a very manual process that can be very time-consuming. However, having the appropriate information available to you quickly can help you make quicker and more accurate decisions. For instance, if you want to establish a security policy that says, “wildcard certificates are not allowed”, it may be useful to run a report on wildcard certificates to properly evaluate the impact of that decision.

This data will also be essential in auditing the environment to ensure that applications are being deployed in compliance with these policies. Auditing reports can be created to identify certificates that are out of compliance with your security policies.

Defining policies and standards can be a very manual process that can be very time-consuming. However, having the appropriate information available to you quickly can help you make quicker and more accurate decisions.

Here are a few examples of reports that could be created for policy compliance reporting:

• Key length of less than 2048 in use
• Self-signed certificates in use
• Certificates generated off a non-approved CA
• Code signing certificates already issued

The Keyfactor platform provides reports with the data you need, right out of the box.

The Keyfactor platform can help you enforce your security policies by the implementation of an optional custom policy module that will enforce specific security restrictions. This policy module can restrict certificate issuance based upon templates and machine names, preventing unauthorized certificate issuance or certificate template use. It can prevent users from going directly to the CA to get a certificate, even if they have the security permissions to access the CA. The policy’s whitelisting mandates that certificates are issued from the Keyfactor Command server (in-band), and not by a rogue administrator going directly to the CA with requests generated by other toolsets like IIS or a client tool (out of band). Alternatively, third-party certificates issued out of band can be detected with our SSL scans. Reporting and alerts can be configured to allow either custom workflows or manual processes to address these issues.

When defining access to your PKI environment via native tools, the options to grant access may be fairly limited. You may not want to grant all of your administrators the ability to log into your public CA portal to generate certificates or grant them “Enterprise Admin” rights through your organization to manage PKI resources. Keyfactor has a very detailed Role-Based Access Control (RBAC) for users and groups that can be used as a gateway for controlling that access. Users can be delegated access to do exactly what they need to do, and ONLY what they need to do, thereby helping maintain a least privileged access model.

After completing the analysis of the digital identity infrastructure, it will be necessary to begin a deeper dive into the application and device integration of the certificates. This process will not only include identifying in detail where the certificates are used and planning for their migration, but also some analysis on whether the approach is compliant with the overarching security policies defined in phase 2.

These questions could include:

• Are there certificates in use from certificate authorities that will be retired? How will we re-issue them from a new certificate authority?
• Where will new certificates be needed? Are there updated auto-enrollment policies?
• Are the certificates in use acceptable to the security policy, or will they need to be reissued? If reissuing, how can we ensure that all devices connecting to them trust the new issuing CA?
• As we merge our networks, do we have the appropriate certificates and trusted root CAs in place to support our NAC, Wireless, VPN and mobile device management solutions?
• How are certificates currently deployed? How will they be integrated going forward?
• Are there automated processes or DevOps integrations that will be impacted by an M&A?
• Are there new efficiencies that can be gained by implementing DevOps processes into the migration activity?
• How will we merge processes into our existing systems for helpdesk or workflow automation (i.e., ServiceNow, Remedy, SCCM)?

As you move through this phase, you will start deciding how you will integrate with your existing infrastructure and applications. Although you may not be doing the actual implementations yet, you are planning for how the integrations will be done. The organization will be planning and developing new applications and migrating applications to new platforms. It is a time of change. Use this to your advantage. While these applications are being re-designed and implemented, integrate them into a digital identity management platform at the same time. After the migration is complete, developers are not going to want to re-write these applications in order to move to a new tool. This may be the one chance that you have to integrate a certificate automation platform into these systems.

The Keyfactor platform has robust API capabilities that al- lows easy integration with any application that manages certificate management tasks. It can be integrated into DevOps technologies such as Docker, Ansible, Kubernetes, and Puppet to automate certificate management tasks,  and ensures that certificate data is always available via the Keyfactor console.

Since the Keyfactor platform is not middle-ware, it is not a requirement to issue the certificates through the platform in order to inventory and manage them in the console. As such, it will not interfere with any existing certificate processes that are already in place. The platform will install alongside your existing infrastructure to include additional functionality that you can use to your advantage when migrating applications and bulk managing certificate data. This allows for much greater flexibility in how you address the issues that may arise during your project.

Code signing keys are considered high-value assets in an organization. There may be a lot of development activity that will require code to be signed. You will want to prevent any risk of security breaches by ensuring that code signing keys cannot get into the hands of development teams that should not have them or even worse, leaked outside the organization. The Keyfactor code signing module can secure all of your code signing certificates throughout the process, and allow you to implement secure code signing practices without changing the way your developers currently sign their code. It will give you the ability to control your code signing keys without releasing them to developers, while still ensuring that they can sign the new code that they are developing.

This is where your planning and discovery information is all put to the test. In a best-case scenario, all of the planning was thorough and complete, and you can move right through your implementation phase. This rarely happens. There will always be surprises in a large-scale project. The key to success will be the ability to detect the issue and react quickly so that you do not affect timelines for other implementation teams. There will always be some reassessment work that needs to be done.

The discovery and planning phases should be completed as quickly as possible at the beginning of the project to leave adequate time for the testing and implementation of new technology. Nearly every M&A project has a deadline. Sometimes this deadline is set at the executive level; other times it may be set by an outside entity such as an investment firm or regulatory agency. Having the right answers during the discovery process for your digital identities can be the deciding factor on whether or not the company meets or misses timelines. Incorrect planning of digital identities can lead to application outages, project re-work, and bypassed security processes that in the long run could drive up costs of labor and regulatory fines, and impact revenue.

In many cases, the digital identity migration plan must be completed in advance of other application migrations, due to their reliance on digital identities or encryption certificates. For this reason, your plan must be flexible and adaptable. This does not mean that you should sacrifice your security policies in order to move the project forward – although some people may ask you to do that. Instead, you must ensure that your overarching identity solution is built in a way that allows you to quickly react to things that may change throughout the project. You must be able to quickly add new templates, adjust workflows, generate reports, and issue certificates as the requests come in. This agility will be the difference between successfully meeting deadlines or not.

In many cases, the migration of digital identities must be completed prior to any application or infrastructure migrations due to dependencies on the availability of those digital identities.

Some of the key tasks that will be part of the implementation phase include:

• Communication of policies and process to all involved teams
• Deployment of trusted root certificates to all devices
• Updating of auto-enrollment policies for auto-enrolled certificates as necessary
• Implementation of audit processes to ensure policies are being followed
• Issuance of new certificates for migrating web apps which will likely include certificates from multiple certificate authorities
• Implementation of new certificates for updated proxy, SSL Intercept, and wifi access
• Implementation of certificate issuance/DevOps processes for new application deployments (i.e., Puppet, Docker, Ansible, Kubernetes)
• Clean up of old certificates in the environment that are no longer in use

When implementing new systems, the automation capabilities of the Keyfactor application are a game-changer. Certificates can be requested by developers and deployed directly to the devices where the certificates are needed. Approval processes can be automated and easily integrated with external applications or ticket management systems such as ServiceNow or Remedy.

With the Keyfactor platform able to manage all of your enterprise certificate authorities, it is possible to renew/re-issue certificates from a different certificate authority. In an  M&A scenario, it is possible to take a certificate that was issued by Company A and submit that request to be re-issued from the Company B certificate authority, thereby effectively migrating that certificate to a new certificate authority or template.

In some cases, the acquisition is not an acquisition of an entire business. It may only be an acquisition of a specific business unit or a product line. In these cases, the company being acquired may not allow their Active Directory servers or certificate authority servers to be migrated. Using our gateway technology, it is also possible to connect to certificate authorities in a completely un-trusted Active Directory forest. This can allow issuing and migration of certificates between environments even in cases where the Active Directory infrastructure is not being merged as a part of the migration project.

Using our gateway technology, certificates can be issued to devices in non-trusted domains to support migration scenarios with limited system access.

The Keyfactor platform can do full Root of Trust management. Not only does the platform deploy the end-entity certificates, but it can also be used as a method of deployment for new or updated trusted root certificates to the servers and devices in your environment.

Extensive REST-based APIs allow automation of nearly every function in the application. Certificate stores can be dynamically registered and managed and certificates can be requested, deployed, and managed all through the API. Our API Developer’s Guide can help your development teams quickly integrate applications if necessary.