White Paper - Bitpipedocs.media.bitpipe.com/io_13x/io_133274/item_1408298/PKI...every certificate...

Published by CSS Research l Q3 2016

PKI ﹘ The New Best PracticesWhite Paper

1www.css-security.com | © 2016 Certified Security Solutions, Inc. All Rights Reserved.

PKI ﹘ The New Best Practices

WHITE PAPER | Published by CSS Research | Q3 2016

OverviewPublic Key Infrastructure (PKI) has undergone an evolution since its commercial introduction in the 1990s. While widespread PKI adop-tion has ebbed and flowed over the years, it is again emerging as a secure, cost-effective and efficient technology environment to issue digital certificates for authentication, encryption and code signing. Enterprises face new uncertainties and must make decisions on how to ensure the ongoing trust of old and new PKI environments and the resulting certificates. This white paper outlines how PKI has evolved and highlights common PKI weaknesses of today. Then, insights and best practices are offered to show how organizations are identifying challenges, addressing questions and managing issues to reduce risk and meet audit and compliance requirements for their PKI operations.

Aging PKIs vs. New Use CasesPKI is not new. According to the Thales Ponemon Institute 2015 PKI Global Trends Study, many PKI implementations are more than 10 years old and support more than seven or eight applications.

Figure 1. The Evolution of PKI Implementation

2015

Strong AuthEncryption

2

WHITE PAPER | PKI ﹘ The New Best Practices | Q3 2016

www.css-security.com | © 2016 Certified Security Solutions, Inc. All Rights Reserved.

Every year the IT security industry announces that this is the “year of PKI.” While the importance and usefulness of PKI has varied over time, it continues to be used for a host of enterprise use cases, as well as being implemented for emerging Internet of Things (IoT) sys-tems. With the evolution of IoT and the need for authentication and encryption for high-volume and low-power endpoints, PKI continues to spark new interest.

However, that landscape has changed over time. Deploying a PKI 10 years ago meant a completely different set of use cases, issues and standards. PKI was then only used for a recognized set of use cases with established standards such as Wi-Fi, device authentication, user authentication, secure email, SSL or code signing. With the widespread use of mobile devices and applications enabling remote workforces spurring the Bring Your Own Device (BYOD) revolution, certificates have evolved to become the standard for device authentication to a network for a host of new use cases, thus creating a new set of PKI requirements.

The newest challenges on the horizon come in the form of IoT, the Internet of Everything (IoE) and what is also being termed as the Indus-trial Internet. The Verizon State of the Market Internet of Things 2016 report forecasts the installed base of IoT endpoints to grow from 9.7 Billion in 2014 to 30 Billion in 2020. Robots on the plant floor, smart light bulbs, implanted medical devices, software and sensitive data all need to be validated as authentic and protected from malicious access or corrupt code. How can disparate IoT system elements that need to connect to an enterprise network – and sometimes to another enterprise’s network – be secured? What level of trust and assurance is needed for each of the elements? How can the appropriate level of security be embedded into devices with limited computing power? PKI and certificate-based authentication, encryption and code signing are experiencing a revival as a technology to help overcome a host of IoT security challenges.

Certificates are being used in new ways for IoT and the enterprise network is often encountering new things. Even an office coffee maker connected to the Internet has security implications. Large commercial brewing systems offer new features such as automatic supply ordering, usage information or maintenance and failure alerts. The coffee maker is essentially a third-party device connecting through the network. The enterprise will need to understand the security controls, what data is transmitted and which network resources the device needs to access to determine the privacy implications, potential vulnerabilities and new risks that could result from providing access to the network.

The important takeaway is that the PKI that might have been estab-lished for Wi-Fi 10 years ago hasn’t changed much, while the PKI for IoT systems and certificate management for today and beyond must address vastly different needs and vulnerabilities. With the typical PKI being implemented eight years ago to support standard use cases, it wasn’t likely built to support the breadth of today’s applications and devices that can rely on certificates.

"The installed base of IoT endpoints to grow from 9.7 Billion in 2014 to 30 Billion in 2020." — Verizon State of the Market Internet of Things 2016

3



PKI Then and Now

Implementing Your Own Certificate Authority (CA) vs. Purchasing Through a Third Party

There are two critical considerations in this category that have emerged over time. First is who implements and manages the CA. Second is the cost of the CA and resulting certificates. There are a number of vendors that offer CA products. Depending on organizational needs, deploying an in house CA may be an economical approach to support large scale certificate consumption. However, in many cases, if only a small of certificates are required, purchasing those certificates from a vendor, may provide the best solution. Over the past few years, a third offering has emerged where companies will run and manage certificate authorities on behalf of a company thus allowing the ben-efits of an in house CA without the operational overhead – essentially a managed PKI service. Today, many larger organizations have hybrid environments and source certificates from a combination of in-house CAs and external providers, thus creating a more challenging environ-ment to inventory and track certificates.

All too often, when looking at a certificate deployment, the focus is incorrectly placed on the cost of the certificate rather than the cost of ownership of that certificate over the lifespan of the asset it’s pro-tecting. With the overall cost of CA software being reduced to nearly free, the attention needs to be shifted to how a certificate will be consumed, trusted and managed over time through the full lifecycle of the certificate, not just at deployment. Effective management of certificates in an organization needs to encompass planning for every certificate that the enterprise will issue in order to balance usage and management in the cost/benefit model for the enterprise.

Two-Tier vs. Three-Tier DesignTen to fifteen years ago, PKI experts needed to discuss the architecture and design of PKI and determine whether to design and implement a two- or three-tier PKI. Today, that discussion isn’t necessary as years of successful secure PKI operation have established the reasons for a two- or three-tier design. The vast majority of PKIs are two-tier with three-tier deigns being implemented when specific technical, manage-ment and industry-imposed requirements exist. Enterprises also used to debate whether or not to implement a Hardware Security Module (HSM) as part of the PKI environment to protect private keys. Today, including an HSM is a more standard practice to protect sensitive private keys against a growing set of attack vectors.

4



Dedicated PKI Experts vs. Security/ IT Team Management

PKI in large enterprises used to be managed by a dedicated team responsible for all things related to the infrastructure and certifi-cates. Over time, PKI management has often been transitioned to the responsibility of a security or IT team. While the security team is knowledgeable, they're rarely solely dedicated to PKI. This tends to place conflicting pressure and challenges on the multiple teams that are often spread thin with responsibilities for PKI, as well as a host of other security and IT technology and tools.

PKI Implementation ﹘ New Risks

PKI and certificates are vulnerable and a number of significant breaches have been perpetrated via certificates. Chris Hickman, CSS, VP, Managed Services, Enterprise Services, states. “Without knowing the potential vulnerabilities, establishing policies and procedures to prevent them and having a way to identify impacted certificates, your PKI and IT assets are at risk.” Keep in mind that one single breach can compromise the trust of an entire PKI and the issued certificates.

SSL/TLS Weaknesses & Key VulnerabilitiesSecure Socket Layer (SSL) and Transport Layer Security (TLS) cryp-tographic protocols ensure that the appropriate handshakes occur between two communicating computer applications (i.e., a web browser and a server) to ensure privacy and data integrity. SSL standards have improved over time and the nomenclature has changed to the more appropriate TLS. The SSL/TLS cryptographic protocol was one of the driving forces behind certificate adoption and the large volume of certificates in circulation today.

An organization's ability to identify and quickly mitigate SSL/TLS certificate vulnerabilities for services that are susceptible to attacks is imperative. The Heartbleed vulnerability certainly drove this point home for a lot of organizations. As a way to attack a web server and hijack the private keys of that web server through OpenSSL, Heartbleed gave malicious actors a way to encrypt or decrypt communications, steal data and impersonate services and users. Heartbleed was one of the first real attacks that compromised private keys held in software, highlighting for some organizations a problem they didn’t realize they had: a way to identify, find and revoke the certificates with the impacted keys.

“Without knowing the potential vulnerabilities, establishing policies and procedures to prevent them and having a way to identify impacted certificates, your PKI and IT assets are at risk.”

Chris Hickman, VP, Managed Services

Certified Security Solutions

5



Root Certificate Vulnerabilities

Another challenge comes from attacks on root certificate key stores relied upon by applications, browsers and devices, etc. An example from Dell featured personal computers using the pre-installed CA root certificate that contained a critical vulnerability. Exploitation of the vulnerability could allow a remote attacker to read encrypted HTTPS web browser traffic, impersonate a website or perform other attacks on the affected system. Other large organizations, including Comodo and Lenovo, have had their root certificate keys compromised.

Weak Cryptography and HashingCertificate key strength is critical to ensuring trust among relying parties with compliance, assurance and relying party capabilities all driving cryptography decisions. From a PKI standpoint, it’s important to create a set of policy guidelines that mandate adherence to a spe-cific algorithm or algorithm capabilities. SHA-1 digital certificates are no longer being issued and are scheduled to reach their expiration before January 1, 2017. Continued use of SHA-1 certificates places organizations in a cryptographically-insecure position against cyber adversaries. Research confirms that the SHA-1 signing algorithm is weak and when it is likely to be broken by a hash collision. Projections of the time and finances needed to crack SHA-1 have been signifi-cantly decreased. While hashing different messages should result in unique hashes, actual collisions can lead to the same hash value being produced for different messages which can ultimately be exploited to create fake certificates. Time is running out for organizations to identify and implement an SHA-1 deprecation plan to ensure that every certificate issued is based on the more secure SHA-2 algorithm.

Migration from SHA-1 to SHA-2 for Secure Cert Protection

Migration PlanOrganizations that issue or consume certificates need to develop a migration plan specific to their business situation to transition from SHA-1 to SHA-2 successfully.

Hash CollisionWhen two different pieces of data yield the same hash value, a hash collision occurs. The SHA-1 signing algorithm is weak and thus vulnerable to a hash collision.

SHA-2 SecureThe SHA-2 signing algorithm is significantly stronger and not subject to the same vulnerabilities as SHA-1. SHA-2 offers secure cert protection.

SHA-1Weak

SHA-1 to SHA-2Migration

SHA-2Strong

6



Increased PKI ScrutinyAs malicious attacks become more frequent, PKI is coming under increased scrutiny from internal compliance teams, external auditing organizations and regulatory entities. The PKI is a core piece of enterprise security, al-though it is often left to fend for itself. Many are old, making them unlikely to meet the requirements for emerging technology. Others don’t receive the dedicated management expertise they once had, with PKI operations often being folded into the volume of other security or IT functions. Still others are simply forgotten yet continue to issue certificates with little or no oversight. The lack of management puts an organization at risk of outage or breach. Organizations successfully taking advantage of PKI as an important security control are active in conducting their own internal audits. They are also implementing tools to enable real-time PKI health and compliance reporting in an effort to reduce risk and prove the intended PKI assurance level needed to meet and exceed external audit and regu-latory requirements.

Internal AuditA strong framework assessing and auditing security can be found in the 20 SANS CIS Critical Security Controls. A number of the SANS CIS controls can be useful for PKI auditing to identify and assess the devices and ap-plications authorized to connect to a network and those that are not. The first three controls are focused on the inventory of authorized and unau-thorized devices, inventory of authorized and unauthorized software and secure configuration of hardware and software on mobile devices, laptops, workstations and servers. Part of the assessment for these controls should include identifying the location of every device and application certificate, as well as how the certificates are issued and managed over time. In working with clients, Certified Security Solutions (CSS) often discovers a number of organizations that are unaware of where certificates live and exactly how many they have, increasing the surface area for vulnerability and maximizing the challenge of being able to respond to a certificate-related incident.

7



Incident ReportingIncident monitoring and alerts help an organization minimize the potential for holes in the security system, in addition to quickly addressing issues and learning from past issues. One example highlighting the importance of monitoring and managing your PKI and certificate operations lies in how an organization suspends network access for a severed employ-ee. Most organizations will shut off the Active Directory (AD) access. That may be fine if all authentication occurs through AD, but if the employee had a device that was authenticated to connect to the network solely through a certificate, more steps must be taken. If the organization does not know to re-voke the certificate, the employee can still access the network and the organization may not know. An auditor may ask how an organization can be sure that a terminated employee isn’t still connecting their iPad (or other device) to the network. Being able to answer questions like these go a long way in complying with audit and regulatory requirements.

External AuditThe Thales Ponemon Institute 2015 PKI Global Trends Study found that 56% of respondents are concerned about their PKI meeting external mandates and standards. This makes it clear that enterprises are concerned about audit readiness. Audit readiness is especially critical in highly regulated markets, including finance and healthcare.

The current Payment Card Industry (PCI) DSS 3.2 mandates the following for cardholder data:

• Encryption across open, public networks using strong cryptography is required

• Only trusted keys and certificates

• That the protocol in use only supports secure versions or configurations

• Encryption strength is appropriate for the encryption methodology in use

56% of respondents are concerned about their PKI meeting external mandates and standards

Figure 2. Thales Ponemon Institute 2015 PKI Global Trends Study Findings

8



Any certificates used for authentication and code signing need to feature strong cryptography. Trusted certificates should feature a stronger hashing algorithm, like SHA-2. For organizations that may have been using SHA-1 cryptography for their certificates, a migration to SHA-2 was needed to meet audit requirements. Enterprises that were quickly and efficiently able to identify and revoke their inventory of SHA-1 certificates and issue new SHA-2 across their large store of devices transitioned smoothly.

The Health Insurance Portability and Accountability Act (HIPAA) Security Rule establishes national standards to protect an individual’s electronic personal health information that is created, received, used or maintained by a covered entity. The Security Rule requires appropriate administrative, physical and technical safeguards to ensure the confidentiality, integrity and security of electronic protected health information. For breaches of over 500 individuals, HIPAA-covered entities are required to report the breach to the HHS Office for Civil Rights (OCR). The OCR also investigates breach complaints, as well as conducts proactive audits.

The OCR may assess civil and criminal penalties based on impact from a breach and the OCR’s determination of negligence. Ultimately, it is the requirement of the HIPPA-covered entity to produce the burden of proof that it adhered to and actively enforced the established HIPAA Security Rules.

Since tracking began in late 2009, the number of breaches are shocking. Medical record theft is a lucrative business as they may contain both financial and personal identifying information in the same record. They may contain useful information that can be appended to existing data to make a record more identifiable or valuable.Figure 3. Recent Surge in

Compromised Individuals from Hack/IT Issue

568,358 297,269 900,684 238,207 1,796,755

111,812,172

9,619,368 -

20,000,000 40,000,000 60,000,000 80,000,000

100,000,000 120,000,000

U.S. Department Health and Human Service Office for Civil RightsCompromised Individuals from Hack/IT Issue

as of 4/30/16

9



Consider the monetary impact of HIPAA breaches. The IBM Ponemon 2015 Cost of Data Breach Study: Global Analysis estimated the average cost of a U.S. healthcare breach per exposed personally-identifiable record at $398. The estimated sale price of a record on the black mar-ket was $363. Companies that aren’t managing all security angles are paying for it. Thieves are finding the holes and getting rich.

Auditors reviewing entities such as medical device vendors, mobiles healthcare apps, insurers, payment processors and software vendors are conducting their audits from the standpoint of assuming there was a breach and working backwards. They examine all potential points where a breach could occur, as well as each of the controls protecting those points. This includes the PKI and every certificate.

Auditors may start with broad questions and drill down to explore the specific security technology:

• What do you do to mitigate risk?

• What are your compensating controls?

• What are you doing to ensure that certificates that you are issuing are trusted?

• How do you know certificates are issued to the right sources?

• How many certificates do you issue and to whom?

• How do you know where every certificate is?

• How do you revoke certificates?

It’s not enough to only be compliant with the initial audit. Organiza-tions must adhere to the established controls over time. While most aren't building publicly rooted CAs, the criteria that go into building a publically-trusted CA offers robust guidelines to answer the following questions:

• Are we implementing the appropriate compensating controls and procedures around our PKI so that it can be trusted by our enter-prise in the same way a banking website is trusted?

• Do we have the right sets of checks and balances in place to ensure we're consistently meeting those standards?

"The estimated average cost of a U.S. healthcare breach per exposed personally-identifiable record at $398." — IBM Ponemon 2015 Cost of Data Breach Study: Global Analysis

10



PKI Disaster RecoveryMany organizations running their own enterprise PKIs have never done end-to-end Disaster Recovery (DR) testing. This is different than just testing CA or root recovery and reinstalling a certificate. The most effective DR testing should include:

• What it would take to rebuild the entire PKI environment, including the root CAs, issuing CAs, validation schemes and Online Certificate Status Protocol (OCSP) or CRL

• Making sure that the certificates are consumable by the relying parties that need them

• Putting together a testing plan and organizing a test environment

• Testing and fixes

Good Intentions Gone Bad – Why A PKI May Not Be HealthyPKI vulnerabilities are likely not intentional. Often vulnerabilities are simply the result of smart people with good intentions who don’t work in the PKI space 100% of the time. Let’s explore the risk associated with putting a CA online.

In one CSS client example, an IT team member cleaning out some old server racks decided to throw away an old, non-supported server that hadn’t been powered up for six months. The old server was the root CA. As there were no compensating controls to require verification with another team member before retiring a server, the root CA needed to be recovered. The next challenge came in that while there was a back-up, it was a cloud-based backup. In order to complete the recovery, the root was published online. Per the Thales Ponemon Institute 2015 PKI Global Trends Study, 32% of respondents said they have an online root. According to Chris Hickman, CSS VP, Managed Services, "The best practice is to never publish the root online. Exposing the root online, even for the briefest of moments makes it vulnerable to potential access of the CA keys, ultimately degrading the intended PKI assurance level."

An enterprise may choose to build their own PKI or buy certificates that meet a certain assurance level. The assumption is that those certificates offer the intended level of trust over time. Because of operational changes, inconsistent enforcement or adherence to policies and procedures, lack of knowledge or limited time, an enterprise can downgrade the overall security of its PKI over a period of time. It’s like a sliding scale with the PKI getting less secure with age.

"The best practice is to never publish the root online. Exposing the root online, even for the briefest of moments makes it vulnerable to potential access of the CA keys, ultimately degrading the intended PKI assurance level." — Chris Hickman, Certified Security Solutions (CSS) VP, Managed Services

11



What Can and Can't Be RemediatedWhat can be done if an element of the PKI is compromised or if a change is needed to a CA? What is the net effect of that change? Is it something that can be mitigated or not?

If the PKI has been compromised, the most conservative approach be-lieves that even the most minor compromise puts the environment at risk, and because of that, the level of assurance is lost and a new PKI must be implemented. Old certificates must be immediately replaced and new ones issued from a new, uncompromised PKI. However, if the new PKI is deployed and monitored the same as the compromised PKI, chances are the new PKI will be subject to the same vulnerabilities. For some less crit-ical use cases, an enterprise may opt to continue as is, tighten up some of the controls and monitor the PKI environment more closely to ensure the compromise doesn’t happen again, but this decision should be made on a case-by-case basis.

How Remediation Impacts CertificatesSome things can’t be changed, such as CA names. Most products forbid it. Signing algorithm and key length are two other certificate features that can’t be changed without revoking the original and issuing a new one. While some minor changes can be made along the way, some changes will have broad-reaching effects. For example, an organization can make the change to publish a CRL to a new location. While most CAs will allow for this, the existing deployed certificates will not reflect that new location.

A best practice for many CAs is to issue certificates with a limited life span, say one or two years depending on the use case. However, through bad practices, necessity or lack of appropriate tools to manage the certificate life cycle, organizations may issue certificates with longer life spans. The challenge occurs when a global change to certificates is needed. The cer-tificates with the longer life spans may not be updated until the current certificate expires. This is especially true with certificate auto-enrollment where default settings may control certificate issuance to an old root that should no longer be trusted.

Planning for the Next Audit EventPreparing for a security audit is always challenging, often more so when trying to provide an audit trail for security tools like PKI that may have never been audited before or that do not typically have tools dedicated to monitoring and management. If an enterprise doesn’t have access to its complete inventory of certificates, it’s impossible to say with any level of certainty that every certificate is under the protection of the established PKI controls and is being employed for the intended use.

12



Importance of Certificate Policy and Certification Practice StatementThe Certificate Policy (CP) and Certification Practice Statement (CPS) are the guiding documents that outline how certificates and the PKI are man-aged and essentially proves the intended level of assurance to a relying party during a digital certificate handshake. Even privately rooted CAs, at a minimum, should have a have corresponding CP and CPS documents that correctly identify how an organization will use, consume and manage certificates in the infrastructure around them.

Building A Security Level and Sticking To ItDepending on the use case, an organization may plan for a PKI with low, medium or high assurance. The key is to maintain the original assurance level over time. Not maintaining this original level essentially degrades the security. Not only do you risk having to explain why the original level wasn’t maintained after a breach, but an auditor may perceive the downgrade as a failure to adhere to a specific standard.

PKI – A Recap of the New Best PracticesPKI best practices boil down to four main areas related to security controls: documenting, operationalizing, reviewing and testing and internal auditing.

1. Documenting Controls. The critical PKI documents are the CP and CPS. The CP details all of the assurance level elements of the PKI so that the assurance level associated with a certificate can be presented to the relying party. Then, the relying party can make a decision relat-ed to the level of trust to place in the certificate. The CPS documents how a CA manages the certificates it issues within the confines of the technical architecture and standard operating procedures in the en-terprise. The combined documents prove assurance levels to relying parties and outline how the organization manages that assurance level over time to prove the certificate is trusted. Creating a business continuity DR plan should also be created as one of the documents that outline the PKI controls.

13



2. Operationalizing Controls. Operationalizing enterprise security controls means that standard and consistent policies and procedures are put into place and followed consistently over time. A critical component to operationalizing controls involves how to incorporate, explain and document changes, also called change control. Compensating controls are another important element. A compensating control is an additional security measure designed to add security to a complex and sensitive environment, such as PKI. Adding an HSM to the root, securing where the HSM is stored and controlling and monitoring who has access to it are all considered compensating controls. Consistently keeping the HSMs in a separate locked cabinet under 24/7 video surveillance for which only three people have a key adds additional compensating controls to satisfy audit requirements.

3. Review and Testing of Controls. Once controls have been docu-mented and operationalized, review and test them on a regular basis. This is often part of an internal audit and should include review and testing of all the elements included in your CP, CPS, business continuity and DR plans for all PKI elements. If there is a legitimate need for a change, kick off a change control to update any of the documents. Think of them as living, breathing documents that evolve with the goal of maintaining the PKI’s intended level of assurance.

4. Internal Auditing of Controls. Organizations that schedule and conduct their own audits regularly are easily able to answer external auditor questions and provide proof of the required level of assurance. This is where PKI operations management tools come in handy to identify and offer real-time reporting on the entire catalogue of certificates across all CAs, regardless of whether they were issued internally or purchased through a third party, along with all of the certificate characteristics. Organizations should also monitor and benchmark the enterprise PKI controls against current and emerging standards including the CA/Brower Forum, WebTrust and industry regulatory agencies. This helps the organization stay abreast of upcoming trends. Another best practice is to hire a third-party PKI expert to conduct an annual PKI health check for anything that the organization may not be considering.

14



ConclusionPKI has changed considerably in the last 20 years. Companies can ex-pect continued evolution as PKI experiences a resurgence to support authentication, encryption and code signing applications for large-scale IoT systems. Aging enterprise PKIs may not be a good fit for current compliance and regulatory requirements or technical requirements. Best practices for maintaining trusted PKI assurance levels and meeting audit and regulatory compliance include:

Understand new PKI risks

Ensure controls are planned, documented and implemented

Conduct internal audits to ensure controls are followed and make sense over time

Have a DR plan and test it

Remediate what makes sense and consider starting fresh when reme-diation is not an option

Implement PKI operation management tools to monitor and report on the status and health of the entire environment

Prepare for external audits

Getting Started: CSS Can HelpIf you have questions about managing PKI operations or are seeking PKI expertise to assist with PKI setup, health or optimization, don’t hesitate to contact us. CSS PKI experts are actively working with cli-ents to help them address their unique situation through the CMS PKI Operations Management Platform, as well as PKI health checks, readiness assessments, design and deployment, and managed services.

About Certified Security Solutions (CSS)

As the market leader in enterprise and IoT digital identity security for data, devices and applications, CSS is a cyber security company that builds and supports platforms to enable secure commerce for global businesses connected to the Internet. Headquartered in Cleveland, Ohio, with operations throughout North America, CSS is at the forefront of delivering innovative software products and SaaS solutions that are secure, scalable, economical and easy to integrate into any business. Visit www.css-security.com for more information.

7 Best Practices for Maintaining Trusted PKI Assurance Levels & Meeting Compliance

01

02

03

04

05

06

07

Contact Us

css-security.com

877.715.5448

15



About CSS Research

CSS Research is a specialized division of CSS launched to monitor threat intelligence for more than 3.7 Billion IP addresses, offering continuous oversight and threat intelligence insights on the digital certificates used to secure SSL/TLS connections across the Internet. Other key departmental features include threat intelligence thought leadership, driving and executing initiatives focused on improving early detection of certificate vulnerabilities, identifying compromis-es and forgeries and supporting key customer accounts with deep knowledge and expertise.

In preparation for participating in the Google-sponsored Certificate Transparency project, CSS Research monitors and publishes weekly public SSL/TLS data on more than 3.7 billion IPv4 addresses, including:

• Total certificates identified (SSL/TLS, ECC, device certificates, etc.)• Certificate issuer market share• Self-signed certificates versus those issued by a CA• Certificate issuance and expiration statistics• Signature algorithm breakdown (SHA-1 / SHA-2, etc.)

Weekly statistics, additional initiative information, and the option for organizations to request their own custom Public SSL Report can be found on the CSS Research web page.

Additional References & Resources

20 SANS CIS Critical Security Controls

IBM Ponemon 2015 Cost of Data Breach Study: Global Analysis

Health Insurance Portability and Accountability Act) Security Rule

Payment Card Industry (PCI) DSS 3.2

PKI Professionals LinkedIn Group

Thales Ponemon Institute 2015 PKI Global Trends Study

The Verizon State of the Market Internet of Things

Date post:	04-Aug-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

White Paper - Bitpipedocs.media.bitpipe.com/io_13x/io_133274/item_1408298/PKI...every certificate...

Documents