PCI COMPLIANCE

According to https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1.pdf,
https://www.pcisecuritystandards.org/documents/PA-DSS_v3-1.pdf,
https://www.pcisecuritystandards.org/documents/PCIDSS_QRGv3_1.pdf,
http://www.onestopclick.com/assets/PCI_Data_Security_Standard.pdf
to provide security to our service following by standarts we need to implement following
steps, most of them are highly critical.

1. Install and maintain a firewall configuration to protect cardholder data

a. 1.1.2 Current network diagram that identifies all connections between the
cardholder data environment and other networks, including any wireless
networks
b. 1.1.3 Current diagram that shows all cardholder data flows across systems
and networks
c. 1.1.5 Description of groups, roles, and responsibilities for management of
network components
d. 1.1.7 Requirement to review firewall and router rule sets at least every six
months
e. 1.3.4 Implement anti-spoofing measures to detect and block forged source IP
addresses from entering the network.
f. 1.3.6 Implement stateful inspection, also known as dynamic packet filtering.
(That is, only “established” connections are allowed into the network.)
g. 1.3.7 Place system components that store cardholder data (such as a
database) in an internal network zone, segregated from the DMZ and other
untrusted networks
2. Do not use vendor-supplied defaults for system passwords and other security
parameters
a. Implement only one primary function per server
2.2.1 Implement only one primary function per server to prevent functions that
require different security levels from co-existing on the same server. (For
example, web servers, database servers, and DNS should be implemented
on separate servers.)
Note: Where virtualization technologies are in use, implement only one
primary function per virtual system component.
For this propose we will need to implement decentralized system using next
guidline
http://www.onestopclick.com/assets/PCI_Data_Security_Standard.pdf
3. Protect stored cardholder data
a. 3.5 Document and implement procedures to protect keys used to secure
stored cardholder data against disclosure and misuse: Note: This requirement
applies to keys used to encrypt stored cardholder data, and also applies to
key-encrypting keys used to protect data-encrypting keys— such
key-encrypting keys must be at least as strong as the data-encrypting
b. 3.5.1 Restrict access to cryptographic keys to the fewest number of
custodians necessary.
c. 3.5.3 Store cryptographic keys in the fewest possible locations.
 d. 3.6 Fully document and implement all key-management processes and
procedures for cryptographic keys used for encryption of cardholder data,
including the following:
i. 3.6.1 Generation of strong cryptographic keys
ii. 3.6.2 Secure cryptographic key distribution
iii. 3.6.3 Secure cryptographic key storage
iv. 3.6.4 Cryptographic key changes for keys that have reached the end
of their cryptoperiod (for example, after a defined period of time has
passed and/or after a certain amount of ciphertext has been produced
by a given key), as defined by the associated application vendor or
key owner, and based on industry best practices and guidelines (for
example, NIST Special Publication 800-57)
v. 3.6.5 Retirement or replacement (for example, archiving, destruction,
and/or revocation) of keys as deemed necessary when the integrity of
the key has been weakened (for example, departure of an employee
with knowledge of a clear-text key component), or keys are suspected
of being compromised.
vi. 3.6.6 If manual clear-text cryptographic key-management operations
are used, these operations must be managed using split knowledge
and dual control. Note: Examples of manual key management
operations include, but are not limited to: key generation,
transmission, loading, storage and destruction.
vii. 3.6.7 Prevention of unauthorized substitution of cryptographic keys.
viii. 3.6.8 Requirement for cryptographic key custodians to formally
acknowledge that they understand and accept their key-custodian
responsibilities.
e. 3.7 Ensure that security policies and operational procedures for protecting
stored cardholder data are documented, in use, and known to all affected
parties.

4. Encrypt transmission of cardholder data across open, public networks

(SSL|SSH)
5. Protect all systems against malware and regularly update anti-virus software or
programs
6. Develop and maintain secure systems and applications
a. 6.3.1 Remove development, test and/or custom application accounts, user
IDs, and passwords before applications become active or are released to
customers.
b. 6.3.2 Review custom code prior to release to production or customers in order
to identify any potential coding vulnerability (using either manual or
automated processes) to include at least the following:
i. Code changes are reviewed by individuals other than the originating
code author, and by individuals knowledgeable about code-review
techniques and secure coding practices.
ii. Code reviews ensure code is developed according to secure coding
guidelines
 iii. Appropriate corrections are implemented prior to release.
iv. Code-review results are reviewed and approved by management prior
to release.

Note: This requirement for code reviews applies to all custom code (both
internal and public-facing), as part of the system development life cycle. Code
reviews can be conducted by knowledgeable internal personnel or third
parties. Public-facing web applications are also subject to additional controls,
to address ongoing threats and vulnerabilities after implementation, as
defined at PCI DSS Requirement 6.6

c. 6.4 Follow change control processes and procedures for all changes to
system components. The processes must include the following:
i. 6.4.1 Separate development/test environments from production
environments, and enforce the separation with access controls.
ii. 6.4.2 Separation of duties between development/test and production
environments
iii. 6.4.3 Production data (live PANs) are not used for testing or
development
iv. 6.4.4 Removal of test data and accounts before production systems
become active
d. 6.4.5 Change control procedures for the implementation of security patches
and software modifications must include the following:
i. 6.4.5.1 Documentation of impact.
ii. 6.4.5.2 Documented change approval by authorized parties.
iii. 6.4.5.3 Functionality testing to verify that the change does not
adversely impact the security of the system.
iv. 6.4.5.4 Back-out procedures.
e. 6.5 Address common coding vulnerabilities in software-development
processes as follows: Train developers in secure coding techniques,
including how to avoid common coding vulnerabilities, and understanding how
sensitive data is handled in memory. Develop applications based on secure
coding guidelines. Note: The vulnerabilities listed at 6.5.1 through 6.5.10 were
current with industry best practices when this version of PCI DSS was
published. However, as industry best practices for vulnerability management
are updated (for example, the OWASP Guide, SANS CWE Top 25, CERT
Secure Coding, etc.), the current best practices must be used for these
requirements.
i. 6.5.1 Injection flaws, particularly SQL injection. Also consider OS
Command Injection, LDAP and XPath injection flaws as well as other
injection flaws.
ii. 6.5.2 Buffer overflows. Examine and improve software-development
policies and procedures and interview responsible personnel to verify
that buffer overflows are addressed by coding techniques that include:
Validating buffer boundaries. Truncating input strings.
iii. 6.5.3 Insecure cryptographic storage
 iv. 6.5.4 Insecure communications
v. 6.5.5 Improper error handling
vi. 6.5.6 All “high risk” vulnerabilities identified in the vulnerability
identification process (as defined in PCI DSS Requirement 6.1).
vii. 6.5.7 Cross-site scripting (XSS)
viii. 6.5.8 Improper access control (such as insecure direct object
references, failure to restrict URL access, directory traversal, and
failure to restrict user access to functions).

ix. 6.5.10 Broken authentication and session management Note:

Requirement 6.5.10 is a best practice until June 30, 2015, after which
it becomes a requirement.
Examine and improve software development policies and procedures
and interview responsible personnel to verify that broken
authentication and session management are addressed via coding
techniques that commonly include: Flagging session tokens (for
example cookies) as “secure” Not exposing session IDs in the URL
Incorporating appropriate time-outs and rotation of session IDs after a
successful login.
x. 6.6 For public-facing web applications, address new threats and
vulnerabilities on an ongoing basis and ensure these applications are
protected against known attacks by either of the following methods:
Reviewing public-facing web applications via manual or automated
application vulnerability security assessment tools or methods, at least
annually and after any changes Note: This assessment is not the
same as the vulnerability scans performed for Requirement 11.2.
Installing an automated technical solution that detects and prevents
web based attacks (for example, a web application firewall) in front of
public facing web applications, to continually check all traffic.
7. Restrict access to cardholder data by business need to know
“Need to know” is when access rights are granted to only the least amount of data
and privileges needed to perform a job.
a. 7.1 Limit access to system components and cardholder data to only those
individuals whose job requires such access.
b. 7.1.1 Define access needs for each role, including: System components and
data resources that each role needs to access for their job function Level of
privilege required (for example, user, administrator, etc.) for accessing
resources
c. 7.1.2 Restrict access to privileged user IDs to least privileges necessary to
perform job responsibilities
d. 7.1.3 Assign access based on individual personnel’s job classification and
function.
e. 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. This access control system must include the following:
 i. 7.2.1 Coverage of all system components
ii. 7.2.2 Assignment of privileges to individuals based on job
classification and function.
iii. 7.2.3 Default “deny-all” setting.
f. 7.3 Ensure that security policies and operational procedures for restricting
access to cardholder data are documented, in use, and known to all affected
parties.

8. Identify and authenticate access to system components

a. 8.1 Define and implement policies and procedures to ensure proper user
identification management for nonconsumer users and administrators on all
system components as follows:
i. 8.1.1 Assign all users a unique ID before allowing them to access
system components or cardholder data.
ii. 8.1.2 Control addition, deletion, and modification of user IDs,
credentials, and other identifier objects.
iii. 8.1.3 Immediately revoke access for any terminated users.
iv. 8.1.4 Remove/disable inactive user accounts within 90 days.
v. 8.1.5 Manage IDs used by vendors to access, support, or maintain
system components via remote access as follows: Enabled only
during the time period needed and disabled when not in use.
Monitored when in use.
vi. 8.1.6 Limit repeated access attempts by locking out the user ID after
not more than six attempts.
vii. 8.1.7 Set the lockout duration to a minimum of 30 minutes or until an
administrator enables the user ID.
viii. 8.1.8 If a session has been idle for more than 15 minutes, require the
user to re-authenticate to re-activate the terminal or session.
b. 8.2 In addition to assigning a unique ID, ensure proper user-authentication
management for non-consumer users and administrators on all system
components by employing at least one of the following methods to
authenticate all users:
i. Something you know, such as a password or passphrase Something
you have, such as a token
ii. 8.2.1 Using strong cryptography, render all authentication credentials
(such as passwords/phrases) unreadable during transmission and
storage on all system components.
iii. 8.2.2 Verify user identity before modifying any authentication
credential—for example, performing password resets, provisioning
new tokens, or generating new keys.
iv. 8.2.3 Passwords/phrases must meet the following: Require a
minimum length of at least seven characters. Contain both numeric
and alphabetic characters. Alternatively, the passwords/phrases must
have complexity and strength at least equivalent to the parameters
specified above.
 v. 8.2.4 Change user passwords/passphrases at least once every 90
days.
vi. 8.2.5 Do not allow an individual to submit a new password/phrase that
is the same as any of the last four passwords/phrases he or she has
used.
vii. 8.2.6 Set passwords/phrases for first time use and upon reset to a
unique value for each user, and change immediately after the first use.
c. 8.4 Document and communicate authentication policies and procedures to all
users including:
i. Guidance on selecting strong authentication credentials
ii. Guidance for how users should protect their authentication credentials
iii. Instructions not to reuse previously used passwords
iv. Instructions to change passwords if there is any suspicion the
password could be compromised.
d. 8.5 Do not use group, shared, or generic IDs, passwords, or other
authentication methods
e. 8.7 All access to any database containing cardholder data (including access
by applications, administrators, and all other users) is restricted as follows:
All user access to, user queries of, and user actions on databases are
through programmatic methods. Only database administrators have the
ability to directly access or query databases. Application IDs for database
applications can only be used by the applications (and not by individual users
or other non-application processes)
f. 8.8 Ensure that security policies and operational procedures for identification
and authentication are documented, in use, and known to all affected parties.
9. Track and monitor all access to network resources and cardholder data
Logging, monitoring etc.
10. Regularly test security systems and processes.
a. Implement a methodology for penetration testing
b. Perform external penetration testing at least annually and after any significant
infrastructure or application upgrade or modification (such as an operating
system upgrade, a sub-network added to the environment, or a web server
added to the environment).
c. 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.
Keep all intrusion-detection and prevention engines, baselines, and
signatures up to date.
d. 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
e. Implement a process to respond to any alerts generated by the
changedetection solution.
f. 11.6 Ensure that security policies and operational procedures for security
monitoring and testing are documented, in use, and known to all affected
parties.