July 25, 2018 | IBM i

How IBM i Addresses PCI DSS Default Password and Security Protection Requirements

image

How IBM i Addresses PCI DSS Default Password and Security Protection Requirements

The Payment Card Industry (PCI) Data Security Standard (DSS) can be overwhelming to comply with due to the vast number of requirements you have to be concerned about. Complying with PCI requirements can seem like a daunting task. Especially since the requirements can be vague and there is no how-to instruction guide. This isn’t the case with PCI DSS Requirement 2, which is more specific than some of the other areas.

 

This post is part of an ongoing series describing how an IBM i partition can meet PCI DSS requirements, with each post covering one set of requirements. This week, let’s look at PCI DSS requirement 2, the requirement to “not use vendor supplied defaults for system passwords and other security parameters”.

What the PCI DSS standard says about vendor-supplied defaults

PCI DSS Requirement 2 specifies that companies must not “…use vendor-supplied defaults for system passwords and other security parameters.” In order to make installation easy, vendors provide default passwords. The problem is that the default password is known by anyone who uses that application or system. This makes it easy for hackers to learn the default password for a wide variety of systems and applications. You can bet that if a hacker is trying to access your system, a default password is going to be the first thing they try.

 

It’s important to change default passwords, as soon as you implement a new system or application in order to protect your data, per requirement 2.1. This applies to your users too. If they use a mobile device to connect or transmit cardholder data via a wireless device, they should also make sure they change their vendor-supplied passwords upon implementation.

 

IBM i system security audit programs like iSecurity Audit can be used to run reports of users who haven’t changed their passwords since implementing a new system or application. This will allow you to easily identify those users who still need to change their default passwords and allow for quick remediation.

Defining Configuration Standards

PCI DSS Requirement 2.2 requires that you define configuration standards for all system components, which include changing all vendor-supplied defaults and eliminating any default accounts that are not required for the system to function.

 

Requirement 2.2.1 further states that you must “…implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server…” For example, don’t put your credit card processing on the IBM i partition where you run Web browsing, IBM Notes email, or your production order processing application. Each function should and must have its own primary function.  A benefit that IBM i offers is that with logical partitioning you are able to segregate partitions by function easily, in order to ensure that you have the proper security levels defined.

 

User and system value replication programs such as iSecurity Replication are great solutions for ensuring a new IBM i partition is configured according to your configuration standards.  It’s important to define users with the proper authority and to require passwords that meet a set of criteria.  Being able to replicate your users, passwords and parameters can help ensure that your new systems are setup according to your standards.  Having a baseline for your system values that you can modify to meet partition needs helps ensure that your system is secure.  Even better is having an automated way to replicate those values to a new system or LPAR.

 

You must also disable any services, daemons and protocols that are not required for the system to function properly.  In addition to disabling any of the unnecessary services, daemons and protocols you must implement a way to secure those services which are required for the application or system to run, and you must configure security to prevent someone from misusing the system.  You also need to remove any unnecessary functionality, such as subsystems, file systems, web services, command line access or features.

 

For IBM i, this means that you need to remove access to areas of the system that the user doesn’t need in order to do their day to day activities.  If a user doesn’t need FTP access then you should prevent them from using it.  If they do need it, then you need to monitor their access and be able to show what they did with it come audit time.  For most users this also means revoking command line access and setting object level authorities.

 

Exit point solutions such as iSecurity Firewall ensure that your IBM i is protected and secure by controlling object access at the activity level (read, write, delete, run etc.). By securing native and IFS objects as well as files, libraries, programs, and commands, your system is protected from unwarranted access.  For configuration compliance, you may also want to look at an IBM i user emergency provision and reporting program like iSecurity Authority on Demand that can provide the flexibility to provide and report on emergency one-time access to critical data and processes, without having to permanently provide users with elevated authorities.

What is strong cryptography?

PCI DSS Requirement 2.3 focuses on protecting all administrative access to the system via any non-console access to the system, including web and browser based access. The access has to be encrypted with strong cryptography to prevent unauthorized access. This really means you should have strong password requirements, including using accepted algorithms, such as AES, TDES, RSA, ECC and ElGamal, and have strong key lengths. You also have to key-management in place for an added layer of protection. Both IBM and third-party vendors provide software for activating and managing cryptography when accessing applications.

 

On IBM i, this also means you should have your password level system value set to level 2 or higher, in order to protect your system.  In addition, using a self-service password reset solution such as iSecurity Password Reset can help add another layer of security to your password management.  Self-service password reset programs enable users to reset their passwords on their own, by going through two-factor authentication. Since compliance wants users to frequently change their passwords, sometimes a user forgets the new one. These solutions can help increase efficiencies and reduce helpdesk calls while supporting compliance.

Additional Requirement for Hosting Providers

If you are a hosting provider and your customers have customer credit card data, then you must comply with the final requirement for Section 2 (section 2.6, “Shared hosting providers must protect each entity’s hosted environment and cardholder data…”).  This requirement has a separate appendix that outlines the steps you need to take to segregate your customers and ensure that no one can gain unauthorized access to another customer’s sensitive data.  Luckily, IBM i provides the methodology to segregate customers in separate partitions, which helps make this requirement easier to manage.

 

While PCI DSS Requirement 2 is less vague than some of the other requirements, it can still be difficult to comply with without a security solution. Working with an IBM i security vendor like SEA can make it easy for you to generate reports and consolidate information and meet the PCI DSS standard. Feel free to contact us at SEA if you need more information on meeting the PCI DSS standard with your IBM i partitions.