A Publication by Proximity

PCI DSS Compliance with IBM i

Raz-Lee Security whitepaper

IntroductionAs merchants have taken advantage of technological advances to seek new markets and provide additional customer service through the web, they have also come under increased threat from cyber attacks and financial fraud. And the problem should not be underestimated. PrivacyRights.org reports that ‘over 868 million records with sensitive information were breached between January 2005 and June 2014’ . As most businesses store credit and debit card information (numbers, expiration dates, verification codes and personal data) online, this information is in many cases easily accessible and could be used for malicious purposes.

Weak points are everywhere – point-of-sale devices, web-applications, data transmissions, wireless hotspots, personal computers and more. As the key participant in card-based transactions, it is vitally important that merchants use security procedures and technologies to prevent the theft of cardholder data.  Updated to reflect PCI-DSS v3.1

A survey of businesses in the US and Europe reveals activities that may put cardholders at risk.

81% store payment card numbers

73% store payment card expiration dates

71% store payment card verification codes

57% store customer data on the payment card magnetic strip

16% store other personal data.

Source: Forrester Consulting ‘The State of PCI Compliance’

Need to have, need to know

Any organisation that stores, processes or transmits cardholder data is required to

comply with the Payment Card Industry (PCI) Security Standards. This includes the

manufacturers of PIN entry devices (PCI PIN Transaction Security, PCI PTS for short), the

software developers of payment applications (PCI Payment Application Data Security

Standard, PCI PA-DSS for short) and the merchants and service providers of secure

payment environments (PCI Data Security Standard, PCI DSS for short). PCI DSS is

intended to help merchants prevent payment card fraud and protect cardholders data.

A merchant (in all instances) failing to comply with any part of the regulation could be

severely fined by the PCI Security Standard Council, by up to $500,000 per incident. At

the end of the day, the company is responsible for how it manages its data, and,

regardless of the size of the organisation, its compliance must be assessed on a regular

basis.

There are three continuous steps for

adhering to PCI DSS for applicable

organisations:

Assess: identify all locations of cardholder

data, take an inventory of IT assets and

business processes for payment card

processing and analyse them for

vulnerabilities that could expose cardholder

data.

Repair: fix identified vulnerabilities,

securely removing any unnecessary

cardholder data storage, and implementing

secure business processes.

Report: document assessment and

remediation details, and submit compliance

reports to the acquiring bank and card

brands merchants do business with (or other

requesting entity if they are a service

provider).

Credit Card information and IBM i

IBM i presents a unique set of challenges when it comes to PCI DSS compliance. IBM i

hosts payment card processing applications such as home grown ERP and web

applications that accept and process payment cards. Although IBM i systems are

perceived as secure, this is not wholly accurate - system exit points are vulnerable to

malicious attack and comprehensive application data trails are not provided by the

operating system, allowing exposure of data and creating a new security need.

Indeed, requirement 5.1.2 in the latest version of the PCI-DSS, v3.1 makes specific

reference to the IBM i (referred to as the AS/400 in the documentation):

For systems considered to be not commonly affected by malicious software, perform

periodic evaluations to identify and evaluate evolving malware threats in order to

confirm whether such systems continue to not require anti-virus software.

Complying with PCI DSS

PCI-DSS consists of 12 requirements within six categories which cover best security

practices. On the proceeding pages their is a summary of these requirements, focusing

on the relevant items for IBM i security.

Each requirement is followed by a summary guideline specifying how to actually

implement it. We recommend a careful review of formal PCI documentation before

defining and implementing site-security procedures.

Build and Maintain a Secure Network

Requirement 1: Install and maintain a firewall configuration to protect

cardholder data

‘All systems must be protected from unauthorized access from untrusted networks, whether entering the system via the Internet as e-commerce, employee Internet access through desktop browsers, employee e-mail access, dedicated connections such as business-to-business connections, via wireless networks, or via other sources. Often, seemingly insignificant paths to and from untrusted networks can provide unprotected pathways into key systems. Firewalls are a key protection mechanism for any computer network.’

Relevant summary: [1.1] Establish and implement firewall and router configuration standards[1.2] Build firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment[1.3] Prohibit direct public access between the Internet and any system component in the cardholder data environment[1.4] Install personal firewall software on any mobile and/or employee-owned devices that connect to the Internet when outside the network (for example, laptops used by employees), and which are also used to access the network.

Guidelines:

This requirement is preventing criminals from virtually accessing payment system

networks and stealing cardholder data. Remote access to IBM i can be accomplished via

FTP, remote commands, SQL and ODBC protocols. The company's firewall solution must

ensure that unauthorised users are blocked from penetrating corporate systems, by

covering all 53 IBM i communication protocols (FTP, ODBC, Telnet, SQL, etc). Each

network access point should be logged and any breach attempt should be immediately

reported.

Requirement 2: do not use vendor-supplied defaults for system passwords and

other security parameters

Malicious individuals (external and internal to an entity) often use vendor default passwords and other vendor default settings to compromise systems. These passwords and settings are well known by hacker communities and are easily determined via public information.

Relevant summary: [2.1] Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network[2.3] Encrypt all non-console administrative access using strong cryptography. Use technologies such as SSH, VPN, or TLS for web-based management and other non-console administrative access

Guidelines:

Internal and external attacks often result from using default or easy-to-guess

administrator passwords. Specifically on IBM i, default profiles beginning with the letter

“Q” (i.e. QSECOFR, QSYS) need to be carefully monitored. Organisations should employ

tools that provide full password management capabilities, including enforcement of site-

defined password policies. In addition, the selected security solution should produce

detailed daily reports of unsecured passwords.

Protect Cardholder Data

Requirement 3: Protect stored cardholder data

Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should also be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending unprotected PANs using end-user messaging technologies, such as e-mail and instant messaging.

Relevant summary: [3.3] Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see the full PAN[3.4] Render PAN unreadable anywhere it is stored[3.5] Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse

Guidelines:

This objective is very simple – protecting stored payment card data to prevent its

unauthorised use. Data encryption is a very effective way to prevent intruders from

using stolen information even when they succeed in obtaining it. Naturally, encryption

keys must be strong and should be managed securely. In addition, the ideal security

system should allow display control of classified data on the user’s screen, by restricting

access of unauthorised users to specific database records and fields.

Requirement 4: Encrypt transmission of cardholder data across open, public networks

Sensitive information must be encrypted during transmission over networks that are easily accessed by malicious individuals. Misconfigured wireless networks and vulnerabilities in legacy encryption and authentication protocols continue to be targets of malicious individuals who exploit these vulnerabilities to gain privileged access to cardholder data environments.

Relevant summary: [4.1] Use strong cryptography and security protocols (for example, TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks

Guidelines:

Sensitive cardholder data should be encrypted before transferring it between IBM i and

other platforms. More advanced solutions, such as tokenisation provide additional

safeguards. Such solutions actually reduce the scope of the PCI footprint which needs to

be protected to a central data vault only, lowering the cost and shortening the process

of attaining PCI DSS compliance.

Maintain a Vulnerability Management Program

Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs

Malicious software, commonly referred to as “malware”—including viruses, worms, and Trojans—enters the network during many business-approved activities including employee e-mail and use of the Internet, mobile computers, and storage devices, resulting in the exploitation of system vulnerabilities. Anti-virus software must be used on all systems commonly affected by malware to protect systems from current and evolving malicious software threats. Additional anti-malware solutions may be considered as a supplement to the anti-virus software; however, such additional solutions do not replace the need for anti-virus software to be in place.

Relevant summary: [5.1] Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers)[5.2] Ensure that the anti-virus mechanism is current, running and can generate audit logs.

Guidelines:

IBM i hardware and software architecture enforces the validation of every stored object

(program or data) through a Licensed Internal Codes authority component. Therefore, no

currently-known virus can attack IBM i. However, the IBM i can serve as a host for PC-

based viruses, stored on IFS and then redistributed to other PC machines, infecting files

and/or mapped network drives. Organisations should employ an anti-virus solution that

provides full protection against Windows-compatible viruses and programs used or

stored on the IBM i server. The selected anti-virus tool should also support definition of

automatic, pre-scheduled periodic scans.

Requirement 6: Develop and maintain secure systems and applications

Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed by vendor-provided security patches, which must be installed by the entities that manage the systems. All systems must have all appropriate software patches to protect against the exploitation and compromise of cardholder data by malicious individuals and malicious software.

Relevant summary: [6.3] Develop internal and external software applications (including web-based administrative access to applications) securely.

Guidelines:

Security mechanisms should be defined to audit and capture user activities in real-time

and automatically respond to any security event – by sending messages/alerts to various

destinations, initiating external programs, etc. Changes in business-critical data should

also be monitored, and configured to alert relevant personnel when user-defined

thresholds are breached.

Implement Strong Access Control Measures

Requirement 7: Restrict access to cardholder data by business need-to-know

To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according to job responsibilities.

Relevant summary: [7.1] Limit access to system components and cardholder data to only those individuals whose job requires such access[7.2] Establish an access control system for systems components that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.

Guidelines:

User authorisations should be defined in strict accordance with their specific

responsibilities. Personnel having access to production/system libraries should be

restricted and continuously monitored. The security system should dynamically allow for

receiving additional authorisations, according to pre-defined dates/times, IP addresses,

etc. When higher rights are provided, the system should then log the activity and send

an audit report and real-time alerts.

Requirement 8: Identify and authenticate access to system components

Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for their actions. When such accountability is in place, actions taken on critical data and systems are performed by, and can be traced to, known and authorized users and processes.

The effectiveness of a password is largely determined by the design and implementation of the authentication system—particularly, how frequently password attempts can be made by an attacker, and the security methods to protect user passwords at the point of entry, during transmission, and while in storage.

Relevant summary: [8.1] Define and implement policies and procedures to ensure proper user identification management for non-consumer users and administrators on all system components[8.2] ensure proper user-authentication management for non-consumer users and administrators on all system components[8.3] Incorporate two-factor authentication for remote network access originating from outside the network by personnel (including users and administrators) and all third parties, (including vendor access for support or maintenance) [8.5] Authenticate and closely manage passwords for all privileged, managerial and administrative users.

Guidelines:

This objective is to ensure that any action on sensitive cardholder data can be

performed only by authorised users. To achieve this, full password management

capabilities must be employed, including enforcement of site-defined password policies

(i.e. password expiration time). In addition, all user activities must be monitored by the

system (see Requirement 10: Track and monitor all access to network resources and

cardholder data).

Requirement 9: Restrict physical access to cardholder data Any physical access to data or systems that house cardholder data provides the opportunity for individuals to access devices or data and to remove systems or hardcopies, and should be appropriately restricted.

Relevant summary: [9.1] Use appropriate facility entry controls to limit and monitor physical access to systems in the cardholder data environment.

Guidelines:

Companies should consider automatically protecting unattended workstations to assure

full network security server control.

Regularly Monitor and Test Networks Requirement 10: Track and monitor all access to network resources and cardholder data

Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong.

Relevant summary: [10.1] Implement audit trails to link all access to system components to each individual user[10.2] Implement automatic audit trails for all system components, for the following events (at the very least): Access to cardholder data or audit trails, actions taken by users with admin privileges, failed login attempts, etc. [10.3] Keep all user activity information: user ID, event type, date/time, success/failure indication, origination of event, affected data/resource [10.5] Secure audit trails so they cannot be altered [10.7] Retain audit trails for at least one year.

Guidelines:

To effectively manage and protect sensitive data, it is critical to track and log user

activities. If something goes wrong, this log would allow the necessary analysis to

determine the cause and the people responsible for it. Employ a system that monitors

any operating system activity, keeps all relevant information and generates full detailed

reports in various formats. Responses should be initiated in real-time to potential threats

and security violations.

Requirement 11: Regularly test security systems and processes

Vulnerabilities are being discovered continually by malicious individuals and researchers, and being introduced by new software. System components, processes, and custom software should be tested frequently to ensure security controls continue to reflect a changing environment.

Relevant summary: [11.2] Run internal and external network vulnerability scans at least quarterly and after any significant change in the network[11.4] Use intrusion-detection and/or intrusion-prevention techniques to detect and/or prevent intrusions into the network. Monitor all traffic at the perimeter of the cardholder data environment as well as at critical points in the cardholder data environment, and alert personnel to suspected compromises[11.5] Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized modification (including changes, additions, and deletions) of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.

Guidelines:

This objective is to frequently test system components, processes and software

in order to ensure that security is maintained in the long term, and specifically

during new software deployment or system configuration changes. The system

should provide comprehensive analysis of your security system – the result

would be used to analyse strengths and weaknesses, check all system security

aspects and evaluate the compliance of the system with industry and corporate

policies.

Maintain an Information Security Policy

Requirement 12: Maintain a policy that addresses information security for all personnel

A strong security policy sets the security tone for the whole entity and informs personnel what is expected of them. All personnel should be aware of the sensitivity of data and their responsibilities for protecting it. For the purposes of Requirement 12, “personnel” refers to full-time and part-time employees, temporary employees, contractors and consultants who are “resident” on the entity’s site or otherwise have access to the cardholder data environment.

Guidelines:

Companies should provide all employees with security education in order to

establish firm security procedures.

Summary

Choosing the right security solution for corporate IBM i environments is a

challenging and important task, intended to minimise the risk of security

breaches and keep customer information secure. When assessing the current

security status, one must first gather all necessary security information:

•Policies

•Change controls

•Network diagrams

•Cardholder data flow

•Location of repositories, etc.

It is highly recommended to assign a project manager and key people from IT,

security, HR and legal departments to ensure that all aspects are considered in

security-related choices.

There are a number of software products on the market that help evaluate an

organisation's compliance level. The selected system should be non-disruptive to

production systems and business-critical application data, and should present

PCI DSS and other compliance rankings in summarised form per individual

systems, as well as an overall score the entire enterprise.

Finally, the evaluating software should be flexible enough to allow each site to

locally define (and schedule) its compliance and reporting requirements.

PREVENTION APPLICATIONHaving the infrastructure and tools in place to prevent malicious external attacks and internal threats is essential for safeguarding your IBM i systems. ISecurity’s prevention products provide exactly that.

With the proliferation of applications developed on the IBM i, it is vitally important to protect them from unauthorised access internally and externally while also monitoring user activities.

• Action• Anti-virus• Assessment• Authority on Demand• Central Administration• Command• Firewall• Password• Screen

• AP-Journal Business Analysis• Capture• Change Tracker• FileScope• Native and IFS Object Security

COMPLIANCE

In order to comply with PCI-DSS, iSecurity has a number of products to meet your regulatory requirements. These products can also be used to comply with other legislation including Sarbannes-Oxley and the Data Protection Act.

• Action• Assessment• Audit• Authority on Demand• Capture• Change Tracker

• Command• Compliance Evaluator• Native and IFS Object Security• System Control• User & System Value Replication

iSecurity products suite

Raz-Lee's iSecurity™ is a comprehensive user-friendly security solution for the IBM i

environment. iSecurity addresses insider threat, external security risks, and the need to

protect business-critical application data, as well as providing for effortless compliance

with mandatory security regulation such as PCI DSS, SOX and HIPAA.

Taken together, these capabilities make iSecurity the solution of choice for CIOs, IT

managers, auditors, system administrators and application managers.

FREE SECURITY AUDIT

Contact us today for a free, no obligation security audit of your IBM i environment.

CONTACT US

4-6 Kerry HillHorsforthLeedsLS18 4AY

Pure Offices Lakeview Drive NottinghamNG15 0DT

Web: www.proximity.co.ukPhone: (0113) 393 3360Email: info@proximity.co.uk