PCI Series: Requirement 2 – Do Not Use Vendor-Supplied Defaults for System Passwords and Other Security Parameters

This article is third in a series dedicated to the use of Identity Management (IdM) and related technologies to address the Payment Card Industry Data Security Standard (PCI DSS). This specific post covers the PCI DSS requirement related to not using vendor-supplied defaults for system passwords and other security parameters. The outline and mapping of individual articles to the requirements can be found in the overarching post that started the series.

The second section of the PCI-DSS standard applies to defaults - especially passwords and other security parameters. The standard calls for the reset of passwords (etc.) for any new system before placing it on the network. IdM can help here. Leveraging IdM for centralized accounts and policy information allows for a simple automated provisioning of new systems with

tightened configurations. In addition, Red Hat Satellite 6 and IdM play well together - allowing for automatic enrollment of Linux systems into an IdM managed identity fabric.

Requirements 2.2.3 and 2.3 (also covered in Appendix A2) call for use of different security features like SSH or TLS. Both SSH and TLS require a solution that would provision and manage associated keys. IdM comes to rescue in both cases. For SSH IdM can manage and deliver user and host public keys to the systems joined to the IdM domain. For TLS both the client and server need to have proper certificates and private keys. Where do they come from? How they are tracked and renewed? IdM, together with a client side component called certmonger (integrated with the Linux operating system), allows for provisioning, tracking and rotation of the certificates. These key management aspects of the environment are usually left to the IT professionals to figure out. With IdM and certmonger, certificate management can really become an automated process making environment more secure and less susceptible to a human error or misconfiguration.

TLS is used in many places for many purposes and while automation is great... it's not enough. If certificates are issued by a single certificate authority for multiple environments and use cases there is a chance that a certificate issued for one purpose will be misused to authenticate a different connection. This can be mitigated with fine grained access control rules implemented inside each of the services that accepts TLS based authentication. But this is error prone. Having a certificate authority (CA) for a domain of use would be preferable. Unfortunately creating such CAs is usually a hassle and a cost. This is why the IdM team is working on a solution called subCAs. With just a single command an administrator would be able to create a subCA dedicated to a particular domain of use. Then all the certificates issued by this subCA would be usable only within the context of that specific domain.

Finally, requirement 2.2.4 calls for configuring system security parameters. Once again, IdM, with central management of the host-based-access-control rules, privilege escalation (sudo), and SELinux (for user mapping) provides a relief and help with such configuration.

Questions about how Identity Management relates to requirement two?  Reach out using the comments section (below).