PCI Series: Requirement 6 - Develop and Maintain Secure Systems and Applications

This post is the fifth installment in my PCI DSS series - 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 is related to requirement six (i.e. the requirement to develop and maintain secure systems and applications). The outline and mapping of individual articles to requirements can be found in the overarching post that started the series.

Section six of the PCI DSS standard covers guidelines related to secure application development and testing. IdM and its ecosystem can help in multiple ways to address requirements in this part of the PCI-DSS standard. First of all, IdM includes a set of Apache modules for

different methods of authentication. These modules externalize authentication logic from a web application so that the application does not need to re-implement different authentication methods itself. Such an approach significantly reduces the effort that developers need to invest into building different authentication capabilities into their applications - allowing them to focus on the business logic of the application itself and to deliver results faster. Externalized authentication based on Apache modules is (just) one of the best practices currently being adopted in the industry. There are a number of modules that provide different authentication methods, including:

• A forms based password or one-time-password (OTP) authentication module (...a module that integrates with a given application's login page and uses the PAM stack and SSSD in particular).
• A Kerberos based single-sign-on (GSSAPI) module that allows for login into an application without prompting a given user for his or her credentials if he (or she) is already authenticated against a Kerberos server and holds proof of the authentication.
• Certificate based modules based on either NSS or OpenSSL crypto libraries that enable certificate based authentication into an application.
• A SAML module that connects an application to an identity provider (IdP); IdP-based federation uses redirection of the application login to an IdP - then accepting an authentication assertion as issued by the IdP.
• An OpenID Connect module (similar to the SAML module) that allows an application to accept an OpenID Connect ticket from an authentication server.

The modules and details on how to integrate them are described on the following wiki page. Of note: all of the aforementioned modules are available in the current shipping version of Red Hat Enterprise Linux except for the OpenID Connect one.

As mentioned (above), externalizing authentication saves a lot of effort and is a good practice. To make developer life even easier we have been working on a container-based developer environment that would provide an application container, Apache web server (with pre-configured modules), an authentication server based on IdM (FreeIPA), and a client that allows for the testing of an application via browser. A prototype of this setup can be found here and the following video demonstrates how it can be used for development.

There is also an existing feature of the IdM server that allows for the management of SSH keys for different environments. Imagine you have an application with an administrative account. There are some operations that are done using this account, including SSH-ing into the system the application is running on. If you are developing this application, or if you are testing this application, or (perhaps) if you are deploying this appliaction - you would (likely) want to have different credentials for administrative accounts. IdM allows for the creation of ID views. Loading different SSH keys into different views enables use of the same administrative account across different environments with different SSH keys. Together, with different credentials, IdM allows for defining access control rules that are different for different environments and thus (for example) addresses requirement 6.4.1 (...or, to some extent, requirement 6.5.8).

Finally, it's worth mentioning that it's generally not a good idea to store passwords in configuration files. That said, indeed, some applications were built this way (in the past). To help developers to deal with secrets that an application needs to use, there are plans to provide a secrets API that would allow applications to fetch or store secrets in a more secure way without putting them in clear text in configuration files. You can read more about this capability here. A Technology Preview of the API is included as a part of SSSD (System Security Services Daemon) in the beta release of Red Hat Enterprise Linux 7.3.  Please reach out if you are interested in using this feature - our Technical Account Managers and Solution Architects would love to speak with you.

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