KDS – Neo – Information System Security Policy

Classification

Information owner: Béatrice Joucreau

Public Restricted Confidential Secret
Classification level:
X
Following section to be completed for « Restricted », « Confidential » or « Secret » levels:
Recipient(s) list (name and/or entity) KDS R&D This document must not be
(optional for “Restricted” level, PCI DSS auditors exposed to service providers
mandatory for “Confidential” and ISO 27001 auditors
“Secret” levels) (names of recipients Prospects and customers with
are mandatory for « Secret » level) NDA
Revision

Version Date Name Role Revisions

Chief Security
0.1 2012-04-21 Slimen Benrabah Creation
Officer
Chief Security
1.0 2012-06-06 Slimen Benrabah Review
Officer
Chief Security
1.1 2013-02-28 Slimen Benrabah Review
Officer
Chief Security
1.2 2013-09-13 Slimen Benrabah Risk analysis changes
Officer
Chief Security
1.3 2014-11-20 Slimen Benrabah Review and validation for PCI-DSS 2014
Officer
Chief Security
1.4 2015-08-14 Slimen Benrabah Roles and responsibilities update
Officer
Chief Security
1.5 2015-09-07 Slimen Benrabah Added description of NTDE
Officer
Chief Security
1.6 2015-10-08 Slimen Benrabah Definition and inclusion of PIIE
Officer
Jean-Philippe Chief Security
1.7 2016-04-20 Password policy update
Boucharlat Officer
Jean-Philippe Chief Security Physical security policy update,
1.8 2016-11-10
Boucharlat Officer classification and review/validation
Authentication, password policy, change
1.9 2017-10-13 Béatrice Joucreau Security Officer
management update
2.0 2019-06-19 Béatrice Joucreau Security Officer Complete reworking of the policy

KDS – Neo – Information System Security Policy - Restricted - 2/29

TABLE OF CONTENTS
1 INTRODUCTION .......................................................................................................................................... 6
1.1 PURPOSE OF THIS DOCUMENT ........................................................................................................................................................ 6

1.2 SCOPE................................................................................................................................................................................................. 6

1.3 REVIEW ............................................................................................................................................................................................... 6

1.4 DISPENSATION TO THIS POLICY....................................................................................................................................................... 6

1.5 DOCUMENTARY ARCHITECTURE ...................................................................................................................................................... 6

2 DEFINITIONS ............................................................................................................................................... 7

3 INFORMATION SYSTEM SECURITY RULES ............................................................................................... 8

3.1 ORGANIZATION OF INFORMATION SECURITY................................................................................................................................ 8

3.1.1 Security policies ........................................................................................................................................................................ 8

3.1.2 Security upholding................................................................................................................................................................... 8

3.1.3 Responsibilities.......................................................................................................................................................................... 8

3.1.4 Risk management..................................................................................................................................................................... 9

3.1.5 Performance review and continual improvement........................................................................................................ 9

3.2 HUMAN RESOURCES...................................................................................................................................................................... 10

3.2.1 Awareness and security requirements .......................................................................................................................... 10

3.2.2 Hiring ......................................................................................................................................................................................... 10

3.2.3 Training ..................................................................................................................................................................................... 11

3.3 ASSET MANAGEMENT .................................................................................................................................................................... 11

3.3.1 Electronic assets management ......................................................................................................................................... 11

3.3.2 Documentation management .......................................................................................................................................... 11

3.3.3 Classification............................................................................................................................................................................ 12

3.3.4 Cardholder data ..................................................................................................................................................................... 12

3.3.5 Use of critical technologies ............................................................................................................................................... 12

3.3.6 Transfer of physical media ................................................................................................................................................. 13

3.4 LOGICAL ACCESS CONTROL .......................................................................................................................................................... 13

3.4.1 All accounts ............................................................................................................................................................................. 13

KDS – Neo – Information System Security Policy - Restricted - 3/29
3.4.2 Technical administrators ..................................................................................................................................................... 14

3.4.3 Database administrators..................................................................................................................................................... 15

3.4.4 Vendor access ......................................................................................................................................................................... 15

3.5 CRYPTOGRAPHY ............................................................................................................................................................................. 15

3.6 PHYSICAL SECURITY ....................................................................................................................................................................... 15

3.6.1 Physical access controls ...................................................................................................................................................... 15

3.6.2 Badges ....................................................................................................................................................................................... 16

3.6.3 Physical review ....................................................................................................................................................................... 17

3.6.4 Accidental and environmental threats .......................................................................................................................... 17

3.7 NETWORK ....................................................................................................................................................................................... 17

3.8 OPERATIONS SECURITY ................................................................................................................................................................. 18

3.8.1 Change management .......................................................................................................................................................... 18

3.8.2 Capacity management ........................................................................................................................................................ 19

3.8.3 Anti-malware controls ......................................................................................................................................................... 19

3.8.4 Teleworking ............................................................................................................................................................................. 19

3.8.5 Separation of environments .............................................................................................................................................. 19

3.9 LOGGING AND MONITORING ....................................................................................................................................................... 19

3.9.1 Time synchronization ........................................................................................................................................................... 19

3.9.2 Log sources.............................................................................................................................................................................. 20

3.9.3 Events ......................................................................................................................................................................................... 20

3.9.4 Log centralization .................................................................................................................................................................. 21

3.9.5 Parsing of sensitive data ..................................................................................................................................................... 21

3.9.6 File Integrity Monitoring..................................................................................................................................................... 22

3.9.7 Intrusion Detection ............................................................................................................................................................... 22

3.9.8 Access to logs ......................................................................................................................................................................... 22

3.9.9 Log review ................................................................................................................................................................................ 22

3.10 SOFTWARE DEVELOPMENT ......................................................................................................................................................... 22

3.10.1 Secure coding requirements........................................................................................................................................... 22

KDS – Neo – Information System Security Policy - Restricted - 4/29

3.10.2 Training of developers ...................................................................................................................................................... 23

3.10.3 Development environment separation ....................................................................................................................... 23

3.10.4 Refresh of the development environment ................................................................................................................ 23

3.10.5 Code review prior to production................................................................................................................................... 23

3.11 THIRD PARTY MANAGEMENT...................................................................................................................................................... 24

3.12 VULNERABILITY AND INCIDENT MANAGEMENT ....................................................................................................................... 25

3.12.1 Event and incident management .................................................................................................................................. 25

3.12.2 Vulnerabilities detection................................................................................................................................................... 25

3.12.3 Vulnerabilities correction ................................................................................................................................................. 27

3.12.4 Obstruction to vulnerabilities ......................................................................................................................................... 28

3.13 INFORMATION SECURITY ASPECTS IN BUSINESS CONTINUITY MANAGEMENT...................................................................... 28

3.13.1 Redundancy .......................................................................................................................................................................... 28

3.13.2 Back up.................................................................................................................................................................................... 28

3.13.3 Continuity of critical security processes and operational controls .................................................................. 29

3.13.4 Disaster recovery ................................................................................................................................................................. 29

3.14 COMPLIANCE ............................................................................................................................................................................... 29

KDS – Neo – Information System Security Policy - Restricted - 5/29

1 INTRODUCTION

1.1 PURPOSE OF THIS DOCUMENT

This Information System Security Policy describes the information security objectives and rules that must be
applied on the scope indicated below.

The content of this document is composed of requirements and is, therefore, mandatory.

1.2 SCOPE
This document applies on software development of Neo ecosystem by KDS and on the infrastructure that
hosts them on production.

In particular, it applies to KDS Neo Information Security Management System (ISMS) and Payment Card
Industry Data Security Standard (PCI DSS) scopes, as they are defined in KDS Neo Security Management
Policy.

This security policy does not apply on the use of software products by KDS customers.

1.3 REVIEW
This Information System Security Policy must be reviewed at least once a year and updated when necessary.

1.4 DISPENSATION TO THIS POLICY

Any dispensations to this Information System Security Policy must be approved by KDS Security Officer and
documented. KDS Neo KVSS Register and KDS Neo Security Policy Exceptions may be used to document
such exceptions.

Dispensations may be authorized on the basis of a business or technical constraint. In some cases,
compensating controls may be needed.

1.5 DOCUMENTARY ARCHITECTURE

This Information System Security Policy aims at fulfilling the requirements outlined in KDS Neo Top-Level
Information Security Policy.

If necessary, some security fields may be handled in topic-specific documents.

KDS – Neo – Information System Security Policy - Restricted - 6/29

2 DEFINITIONS
KDS INTERNAL NETWORK: KDS local network used for office work, and that contains KDS corporate
servers, devices and user workstations. Any wireless network that is not segmented from KDS corporate
servers or user workstations is included in this definition. To the contrary, any wireless network that is
isolated from KDS servers or workstations, that only enables Internet access for example, such as a guest
Wi-Fi network, is not considered as part of KDS internal network. KDS production and pre-release
environments are other examples of non-internal networks. On the contrary, KDS R&D networks are
examples of internal networks.

SOFTWARE APPLICATIVE COMPONENTS: Applicative services sold by KDS, such as Wave, Neo, Traces,
AdminSuite, Reporting...

KDS – Neo – Information System Security Policy - Restricted - 7/29

3 INFORMATION SYSTEM SECURITY RULES

3.1 ORGANIZATION OF INFORMATION SECURITY

3.1.1 Security policies

Objective: Identify the necessary information security requirements that must be applied.

Rule-01: Information system security policies for specific topics must be documented when necessary.
Rule-02: The following items must be documented:
• The description of the internal and external context that is relevant for KDS ISMS;
• The scope of the ISMS;
• The charter for PCI DSS compliance;
• High-level security responsibilities.
They are included in KDS Neo Security Management Policy.
Rule-03: Documented information system security policies, including this document and lower level
policies, must be reviewed at least once a year.

3.1.2 Security upholding

Objective: Ensure that internal security implementation is controlled and up-to-date regarding state of the
art.

Rule-04: Security must be taken into account in all projects, whether it be developments or changes to the
production environment hosting.
Rule-05: Contacts with special interest groups must be maintained, such as:
• Vendors;
• Security groups.

3.1.3 Responsibilities

Objective: Ensure that information security responsibilities are assigned and well known.

Rule-06: Information system security roles and responsibilities must be defined and assigned, in particular
regarding:
• the ISMS implementation and maintenance of the ISO 27001 certification;
• the PCI DSS compliance program;
• reporting to the top management regarding the information security management system;
• information security risks ownership.
Rule-07: Contacts with the relevant authorities must be identified and maintained. These contain at least:
• KDS PCI DSS Qualified Security Assessor (QSA);
• KDS ISO 27001 certification body;
• Credit card brands to register KDS PCI DSS compliance and to notify them in case of an incident;

KDS – Neo – Information System Security Policy - Restricted - 8/29

 • Data protection authorities.

3.1.4 Risk management

Objective: Drive security improvements according to the risks.

Rule-08: An information security risk assessment must be initiated and then reviewed at least once a year.
This must cover both the ISMS scope and the PCI DSS scope, in either one or several documents.
Rule-09: The risk assessment must contribute to the definition of a security action plan.

3.1.5 Performance review and continual improvement

Objective: Verify that security processes comply with KDS requirements.

3.1.5.1 Monitoring and measurement

Rule-10: When necessary, security management processes must be monitored. This can be done through
documented and up-to-date indicators.
Rule-11: Security committees must be gathered periodically. Their aim is to:
• Follow up action plans;
• Raise security issues and take decisions;
• Validate the risk assessment and risk treatment plan;
• Follow up security incidents.

3.1.5.2 Internal audit

Rule-12: The ISMS compliance and efficiency must be assessed through an internal audit, which details are
indicated in KDS Neo audit programme.

3.1.5.3 Management reviews

Rule-13: A management review must be conducted at least every year. This must include:
• A review of actions decided during previous management reviews;
• Changes in the context that impact the ISMS;
• Feedback to the management regarding the ISMS:
 Audit results, including nonconformities and corrective actions,
 Monitoring and measurement results,
 Fulfilment of security objectives;
• Results of the risk assessment and status of the risk treatment plan;
• Feedback from interested parties;
• Opportunities for continual improvement.

3.1.5.4 Corrective and preventive actions

Rule-14: Monitoring, measurement, internal audits and management reviews may raise nonconformities
and opportunities for improvement. Nonconformities must be corrected.
Rule-15: The cause of nonconformities must be determined.

KDS – Neo – Information System Security Policy - Restricted - 9/29

Rule-16: If necessary, actions must be taken to fix the cause of nonconformities.
Rule-17: Effectiveness of corrective actions must be reviewed.

3.2 HUMAN RESOURCES

3.2.1 Awareness and security requirements

Objective: Make people aware of KDS security needs and of their responsibilities.

Rule-18: Personnel must receive, at least annually and upon hire, a security awareness training about:
• KDS certifications;
• implications of any nonconformity to the security and security management requirements;
• information security objectives, and particularly the confidentiality of cardholder data;
• information security policies and procedures;
• when applicable, their contribution to the ISMS effectiveness.
Rule-19: After the awareness training, personnel must acknowledge that they have read and understand
this information security policy.
Rule-20: Personnel must be required by their management to apply security policies and procedures.
Rule-21: A disciplinary process must be in place and must be communicated to the employees.

3.2.2 Hiring

Objective: Ensure that people are and remain benevolent with regards to KDS.

Rule-22: Contracts agreed with personnel (whether they are employees, interns, temporary workers,
freelance workers) must contain a confidentiality clause that remains applicable after the end of the
contract.
Rule-23: Background checks must be performed prior to employment. In particular, background of
personnel whose positions are expected to impact cardholder data must be checked to ensure that no
criminal activity related to fraud or hacking has been recorded.
Rule-24: To be effective, the level of background checking should be appropriate for the particular
position. For example, positions requiring greater responsibility or that have administrative access to critical
data or systems may warrant more detailed background checks than positions with less responsibility and
access. This process must cover internal transfers, where personnel in lower risk positions, and who have not
already undergone a detailed background check, are promoted or transferred to positions of greater
responsibility or access.
Rule-25: Background checks must be performed in accordance to local laws, and may include:
• Searching for on name and surname on the Internet;
• Asking for an extract of criminal records (Extract Bulletin n°3 in France);
• Inquiry with previous employers.
Rule-26: As the French law forbids it, extracts of criminal records must not be kept by KDS.

KDS – Neo – Information System Security Policy - Restricted - 10/29

Rule-27: Contracts with personnel and subcontractors must include confidentiality clauses that will last
after the contract’s end.

3.2.3 Training

Objective: Ensure that employees have the sufficient competence to fulfil their roles.

Rule-28: The necessary competence required to fulfil security roles must be determined.
Rule-29: Competence must be assessed, and appropriate training must be given if needed. Documented
proofs of competence must be documented (such as diplomas and certificates for example).

3.3 ASSET MANAGEMENT

Objective: Identify assets so that they are appropriately protected.

3.3.1 Electronic assets management

Rule-30: An inventory of Hosting-owned equipment must be kept up-to-date to list:
• Where cardholder data are stored, processed or transmitted;
• Servers;
• Network equipment;
• Administrators’ workstations;
• VLANs.
Rule-31: Upon termination of their contract, employees must return to KDS the assets of which they were
custodian. These include (non-exhaustive list):
• Desktop and its accessories;
• Laptop and its accessories;
• Badges (for KDS premises and for the datacentres);
• Mobile phone.
Rule-32: An inventory of sensitive media must be kept up-to-date. Sensitive media include media on which
cardholder data are or have been stored.
Rule-33: Drives (hard drives or SSD drives) extracted from servers and containing sensitive data must be
protected from theft and disclosure before being securely disposed of, as required by KDS Classification
Policy.

3.3.2 Documentation management

Rule-34: A documentation management procedure must describe how documents are identified, approved
when necessary, stored and how modifications are controlled.
Rule-35: The following documents need approval by the top management:
• The top-level information security policy;
• The classification policy.
Rule-36: Documents must keep track of their approval by detailing who approved the document and when.

KDS – Neo – Information System Security Policy - Restricted - 11/29

Rule-37: Obsolete documents can be either destroyed or archived. If archived, they must be clearly
identified as obsolete, either in the document itself or in the way they are stored (folder named “old” for
example).

3.3.3 Classification
Rule-38: KDS Classification Policy describes the information classification levels for information owned by
or in custody of KDS. This classification policy also details KDS requirements to protect information
depending on their classification level.
Rule-39: Documents managed in the Neo scope must be labelled and information must be protected
according to KDS Classification Policy.

3.3.4 Cardholder data

Rule-40: Cardholder data must not be stored if this can be avoided.
Rule-41: A cardholder data retention and encryption policy must be defined, documented and
implemented.
Rule-42: If there is a legitimate reason for storing PAN (business or technical need), PAN must be stored
encrypted according to the KDS Neo Cardholder Data Retention and Encryption Policy and to KDS
Cryptography Policy.
Rule-43: At least quarterly, stored cardholder data that exceed the retention policy defined above must be
identified and completely deleted from systems (database and files).
Rule-44: Cardholder data must not be copied, moved or stored onto local hard drives or removable media
when accessing the CDE.
Rule-45: PANs must not be transmitted or stored in environments that are out of the PCI DSS scope.
Rule-46: When displayed, PAN must be masked, so that at most only the first six and the last four digits are
visible.

3.3.5 Use of critical technologies

Rule-47: It is forbidden to connect personal devices (laptop, tablets, phones) on the company internal
network. Only the public hotspot is allowed for those personal devices.
Rule-48: It is forbidden to connect personal devices (laptop, tablets, phones) on Neo hosting networks (QT,
pre-release, production).
Rule-49: A list of all devices used to access the CDE and a list of personnel authorized to use those devices
must be maintained.
Rule-50: Within the limit of Rule-44:, removable media may only be used to carry non-sensitive information
as required by KDS Classification Policy. Non-sensitive information includes restricted information and
encrypted confidential or secret information.
Rule-51: Only KDS-provided removable media may be used.
Rule-52: KDS-provided removable media must only be used on KDS-owned equipment.

KDS – Neo – Information System Security Policy - Restricted - 12/29

3.3.6 Transfer of physical media
Rule-53: Transfer of physical media out of the CDE must be formally approved by the Hosting manager.

3.4 LOGICAL ACCESS CONTROL

Objective: Restrict accesses to the production environment.

Rule-54: The following roles are defined on the production environment:

Role Consumer users (Non-consumer) (Non-consumer)

Basic users Privileged users

Type of Use KDS software Basic accesses with Without administrative With administrative
use for their own no impact on accesses accesses
purposes cardholder data
KDS software functional Production technical
administrators administrators

Type of Access personal Reading access on No access to personal Access to personal

access data and their own personal data and cardholder data and cardholder data
cardholder data No impact on the but could impact their Impact their security
security of security
cardholder data

Examples Standard KDS users Users of: Administrators of: Hosting members
(cardholders) • Traces • AdminSuite Database
Supervisors • Backoffice • SMP-Admin administrators
Arrangers
Accountants

The following rules apply only to non-consumer users.

3.4.1 All accounts

Rule-55: Users must be assigned with personal identifier(s).
Rule-56: Personal identifiers or authenticators (passwords, passphrases, certificates, tokens, smart cards…)
must neither be shared with someone nor reused for another account.
Rule-57: If technically possible, personal accounts must be used instead of generic accounts, and generic
accounts must be deactivated. In case they cannot be deactivated, their use must be restricted to
emergency needs.
Rule-58: Accounts of terminated users must be immediately revoked.

KDS – Neo – Information System Security Policy - Restricted - 13/29

Rule-59: If exceptional generic accounts exist, and if they can give access to information alone, the
authentication secrets attached to them must be renewed as soon as one of the sharers is terminated.
Rule-60: Inactive accounts over 90 days old must be removed or disabled, except in case of irregularly used
accounts, such as database accounts.
Rule-61: User accounts must be locked out after at most 6 invalid logon attempts for a minimum of 30
minutes or until an administrator resets the account.
Rule-62: System/session idle time out features must be set to 15 minutes or less.
Rule-63: Authentication secrets must not be stored unprotected and must not transit in clear on the
network. Protected storage includes encrypted secrets and permission-protected secrets.
Rule-64: Passwords and passphrases must comply with KDS Password Policy. In addition to the
requirements of KDS Password Policy, technical administrators’ passwords must comply with the definition
of “strong” passwords given into the KDS Password Policy.
Rule-65: Cryptographic authenticators (digital signatures) must comply with KDS Cryptography Policy.
Rule-66: New passwords cannot be the same as the four previously used passwords.
Rule-67: First-time passwords for new users, and reset passwords for existing users, are set to a unique
value for each user and changed after first use.
Rule-68: Authorized accesses must be restricted according to the least privilege principle. This implies that
accesses that have not been explicitly authorized must be denied.
Rule-69: All components must implement the aforementioned access control rules.
Rule-70: An access review must be performed at least quarterly and comprises two steps:
• An identities review: the list of accounts must be compared with the list of identities
• An authorization review: the list of permissions must be compared to the access needs.
Rule-71: If a user requests a password reset by phone, e-mail, web, or another non-face-to-face method,
the user’s identity is verified before the password is reset.

3.4.2 Technical administrators

Rule-72: Only the Hosting team may be authorized to have administrative accesses to the production
environment systems.
Rule-73: Administrative access to the cardholder data environment (CDE) must use at least two-factor
authentication.
Rule-74: Administrative accesses to the production environment must be formally approved by the Hosting
manager before being provisioned. This approval must indicate:
• Administrator’s name;
• User ID (Login name);
• Date of approval;
• Approver name and trace of validation;
• assigned privileges to components.

KDS – Neo – Information System Security Policy - Restricted - 14/29

Rule-75: Systems must enforce restrictions to prevent individual users to use service accounts to remotely
login (from the LAN or from another CDE systems).
Rule-76: Inside the CDE, whenever possible, a centralized authentication directory must be used.

3.4.3 Database administrators

Rule-77: Access to cardholder data encryption keys must be formally approved by the Hosting manager.
Rule-78: Authenticate all access to any database containing cardholder data or personally identifiable
information. This includes access by applications, administrators, and all other users.
Rule-79: Application-IDs (SQL accounts) used by applications for SQL queries must be restricted to the
least privileges.
Rule-80: The database must enforce restrictions to prevent individual users or unknown program/process
to use Application-IDs to arbitrary access the database.
Rule-81: Employees (except DBA) are not allowed to directly access or query database containing
cardholder data.

3.4.4 Vendor access

Rule-82: Vendor default passwords must be replaced.
Rule-83: Enable accounts for vendors’ remote access only during the time period needed.
Rule-84: Vendors remote accounts must be disabled when not being needed.
Rule-85: Monitor vendor remote access accounts when in use.
Rule-86: Remote-access technologies used by vendors and business partners to access the CDE must be
active on demand, with proper validation of the Security Officer and immediately deactivated after use.

3.5 CRYPTOGRAPHY
Objective: Ensure appropriate and effective use of cryptography.

Rule-87: All cryptographic controls as well as key management must comply with KDS Cryptography Policy.

3.6 PHYSICAL SECURITY

Objective: Restrict physical access to sensitive information and information systems.

3.6.1 Physical access controls

Rule-88: All individual physical accesses to KDS private suites in the datacentres must be restricted.
Rule-89: Physical accesses to servers and network equipment must be restricted.
Rule-90: Video cameras (if used) and access control systems must be protected from tampering or
disabling.

KDS – Neo – Information System Security Policy - Restricted - 15/29

Rule-91: If video cameras are used, video images must be stored for one month, according to the French
laws and regulations.
Rule-92: Access to the video-surveillance servers must be controlled and restricted.
Rule-93: Access to the video-surveillance servers must be reviewed at least quarterly.
Rule-94: Video-surveillance network flows must be authenticated, encrypted and protected against
tampering.
Rule-95: Access control logs must be stored for at least three months.
Rule-96: Information on KDS servers must not be visible from outside the private suites (for example, labels
with server names).
Rule-97: Workstations, computers left unattended must be locked after 5 minutes.

3.6.2 Badges

3.6.2.1 KDS offices in Issy-les-Moulineaux

Rule-98: Accesses to Issy-les-Moulineaux are restricted by badge.
Rule-99: Distinct types of accesses can be distinguished:
• Permanent accesses (though during opening hours): for permanent employees or service
providers working on site;
• Temporary accesses: for fixed-term employees or service providers, temporary workers, interns;
• Visitors (including service providers who need to access the office for a short period of time).
Rule-100: Managers are accountable for accesses given to people who work under their control.
Rule-101: Badges may not be shared.
Rule-102: Visitors, only when needed, may be allowed to be entitled with a generic badge. When this
occurs, their names must be registered, as well as the name of the person approving the badge.
Rule-103: Badges must be granted the least accesses necessary.
Rule-104: Visitors must be accompanied when they access the offices.
Rule-105: All badges must be surrendered when not needed anymore.
Rule-106: Any forgotten or lost badge must be notified to one’s manager and the IT team as soon as
possible, and in no more than one working day, so that accesses are deactivated.

3.6.2.2 Datacentres
Rule-107: Distinct types of access can be distinguished:
• Permanent accesses;
• Temporary accesses;
• Visitors.
Rule-108: Visitors must be identified as such and must be easily distinguishable from datacentre personnel.
Rule-109: Visitors must always be accompanied.
KDS – Neo – Information System Security Policy - Restricted - 16/29
Rule-110: All badges must be surrendered when not needed anymore.
Rule-111: A visitors log must be used to identify who accesses the datacentre and the private suites. This
log must be kept at least 3 months.
Rule-112: The Hosting manager is the owner of KDS private suites physical security. As such, he formally
approves all accesses to the private suites. This approval may be delegated. Records of approval and of
delegation of approval must be kept for at least one year.
Rule-113: Any forgotten or lost badge must be notified to the Hosting manager as soon as possible, and in
no more than one working day, so that accesses are deactivated.
Rule-114: A review of authorized physical accesses must be performed every quarter.

3.6.3 Physical review

Rule-115: A physical review of each private suite used by KDS in the datacentres must be performed at
least annually. This physical review aims at detecting any anomalies, including rogue devices that could
have been plugged onto servers.
Rule-116: Physical review reports must be kept at least 3 years.

3.6.4 Accidental and environmental threats

Rule-117: Datacentres must implement protections against:
• Fire;
• Flooding;
• Excessive heat;
• Power failure.
Rule-118: Smoking, eating and drinking is forbidden into the private suites.
Rule-119: Telecommunication cables between servers must be enclosed in the private suite.
Rule-120: Network jacks must not be accessible from outside the private suite.
Rule-121: Equipment must be maintained.

3.7 NETWORK
Objective: Protect information when it is transmitted over networks.

Rule-122: A diagram must identify connections between the cardholder data environment and other
networks.
Rule-123: A diagram must show cardholder data flows across components and networks.
Rule-124: The production network must at least contain a demilitarized zone (DMZ) and an internal zone
(INZ).
Rule-125: Firewalls rules must be reviewed at least every six months.
Rule-126: Network configuration standards must be applied on all network components.

KDS – Neo – Information System Security Policy - Restricted - 17/29

Rule-127: The production network must be segmented from any wireless network (excluding GSM).
Rule-128: The presence of unauthorized wireless access points on the PCI DSS networks must be checked
on a periodical basis, in the primary and secondary datacentres.
Rule-129: In case unauthorized wireless access points are detected on the PCI DSS networks, an incident
management procedure must be implemented.
Rule-130: Secure protocols with authentication, encryption and integrity checking (TLS, SSH, IPSEC, etc.)
must be used for communication above public networks (MPLS included).
Rule-131: Host-based firewalls must be activated and configured on administrators’ workstations and
laptops.
Rule-132: Host-based firewalls running on administrators’ workstations and laptops must not be alterable
by them.
Rule-133: Penetration tests must be performed at least every six months on segmentation controls and
after any significant change to segmentation controls to verify that the PCI DSS scope is correctly
segmented from out-of-scope systems.

3.8 OPERATIONS SECURITY

Objective: Ensure that operation activities are performed securely.

3.8.1 Change management

Rule-134: System configuration standards must be applied to all components.
Rule-135: A change management process must be documented and implemented whenever a significant
change occurs. This process must include:
• Documentation of impact;
• Documented change approval by the Hosting manager;
• Tests of the change on non-production environments: quality and tests, then quality-assurance,
then pre-production
• Application of all security requirements;
• Tests to ensure the change did not imply security regressions;
• Correction of the nonconformities revealed by the tests;
• Back-out procedures;
• Update of documentation.
Examples of change include:
• Addition, deletion, and modification of user ID with administrative capabilities on the CDE;
• Installation of a new server;
• Change in the network architecture: new VLAN, new network interface…;
• Change in the cardholder data storage system;
• Installation of a security patches (hotfixes).

KDS – Neo – Information System Security Policy - Restricted - 18/29

Rule-136: After each KDS software development, the infrastructure must be monitored as well as the
correct behaviour of the platform, in order to detect and promptly react to any adverse impact.

3.8.2 Capacity management

Rule-137: Resources consumption must be monitored. Future capacity requirements must be taken into
account in order to plan for additional resources when needed.

3.8.3 Anti-malware controls

Rule-138: All Windows machines, including servers, administrators’ workstations and laptops, must be
equipped with an anti-malware software.
Rule-139: Users must not be able to alter or to disable the anti-malware software.
Rule-140: Anti-malware software must be configured for real-time protection.
Rule-141: Anti-malware software must be configured for daily automatic updates.
Rule-142: Anti-malware software must be configured for weekly scans.
Rule-143: Anti-malware software log generation must be enabled and logs must be centralized.
Rule-144: Anti-malware logs must be kept available for at least one year.
Rule-145: Any disabling must be formally authorized by the Hosting manager.

3.8.4 Teleworking
Rule-146: Only KDS-provided equipment must be used to access the production environment.

3.8.5 Separation of environments

Rule-147: Development, quality and tests, quality assurance, pre-production and production environments
must be separated.

3.9 LOGGING AND MONITORING

Objective: Record events and generate evidence that would be useful to detect or analyse a security
incident.

The following paragraphs do not apply to KDS software application components.

3.9.1 Time synchronization

Rule-148: All system components must be set to get accurate date and time from an internal time server.
Rule-149: The internal time server must get time synchronization from external industry-accepted time
sources that use UTC signals, at Stratum-2 level
(http://support.ntp.org/bin/view/Servers/StratumTwoTimeServers).
Rule-150: As any other CDE software, NTP clients and servers must be kept up-to-date regarding vendor
security hotfixes (to avoid any compromising of the time accuracy).

KDS – Neo – Information System Security Policy - Restricted - 19/29

Rule-151: Central time servers must peer with each other.
Rule-152: Only technical administrators may be authorized to access NTP configuration.
Rule-153: Changes to time settings must be logged, monitored and reviewed.

3.9.2 Log sources

Rule-154: Audit trails must be enabled and secured for all system components:
• Windows and Linux servers;
• Network equipment: load balancers, firewalls, switches…
Rule-155: Audit trails must be enabled and secured for all service and middleware components:
• Proxies;
• Mail servers;
• Web servers;
• Database;
• Other services (SSH, SFTP…).

3.9.3 Events
Rule-156: The following events must be logged:

Event to log Description

All individual accesses to cardholder data Access (R/O or R/W) to cardholder data.

Examples:

• Access to transactions details with clear-text

PAN.
• Access to sensitive files with clear-text PAN.
• Access to database tables that provide clear-
text PAN.

All actions taken by any individual with root or Examples:

administrative privileges
• All commands executed as root or
administrative ID.
• All actions made through applications with
administrative privileges.
• All actions made on database with
administrative privileges.
Access to all audit trails Access (except reading: changes, additions,
deletions) to files, views or menu that contain
logs.

Invalid logical access attempts

KDS – Neo – Information System Security Policy - Restricted - 20/29

 Use of identification and authentication This includes successful login, elevation of
mechanisms privileges, timeout, password changes, addition or
deletion of accounts with root or administrative
privileges …

Initialization, stopping or pausing of the audit

logs

Creation and deletion of system-level objects Examples:

• Device drivers
• Device configuration files
• System drivers
• System configuration files
• System libraries

Content of log Description

User identification Login, Name, User, accounts

Type of event Actions names or code

Date and time Must be accurate using NTP.

Success or failure indication Results of the action attempted.

Origination of event Source IP address or source hostname according

the DNS

Identity or name of affected data, system Could be a combination of: local server name (as
component, or resource. log will be centralized), software, tables, files,
database….

3.9.4 Log centralization

Rule-157: Logs must be backed up, in real time, to a centralized log server.
Rule-158: The centralized log server must be segmented from the other servers’ network.
Rule-159: The logs retention period is twelve (12) months.

3.9.5 Parsing of sensitive data

Rule-160: Logs must be parsed in order to avoid PAN to be stored on the centralized server.

KDS – Neo – Information System Security Policy - Restricted - 21/29

3.9.6 File Integrity Monitoring
Rule-161: A file-integrity monitoring tool must be deployed on each operating system of the CDE in order
to detect unauthorized modification of critical system files, configuration files, or content files.
Rule-162: The file-integrity alerts must be sent to the centralization log server.
Rule-163: A file-integrity monitoring must be deployed on the log server to detect malicious alteration of
logs.
Rule-164: Alerts raised by the file-integrity monitoring tool must be treated.

3.9.7 Intrusion Detection

Rule-165: Intrusion-detection systems (IDS) must be implemented on the CDE.
Rule-166: IDS must be configured, maintained and updated as described in instructions in the vendor
documentation.
Rule-167: IDS attack signatures must be updated daily with vendor official database.
Rule-168: The IDS system is listening on perimeter and critical points as:
• a monitor port of the internal zone (INZ) firewall that allows to monitor traffic between the DMZ
and database systems.
Rule-169: Critical signatures and triggers are set to generate alerts. Alerts must be sent by email to the
Hosting and Security team.

3.9.8 Access to logs

Rule-170: Access to log files may only be authorized to the Hosting team.

3.9.9 Log review

Rule-171: At least daily, logs for all system components must be reviewed in order to detect exceptions
(unauthorized access, attacks…). This daily task could be performed by log harvesting, parsing, and alerting
tools, such as a security information and event management tool (SIEM).
Rule-172: All detection exceptions must be traced in a follow-up process.

3.10 SOFTWARE DEVELOPMENT

Objective: Ensure that developments do not introduce vulnerabilities and do not put sensitive data at risk.

3.10.1 Secure coding requirements

Rule-173: Applications development process must be based on the secure coding guidelines, such as
OWASP. In particular, the following topics must be covered:
• Injection, in particular but not limiting to SQL injections;
• Buffer overflow;
• Insecure cryptographic storage;
• Error handling;

KDS – Neo – Information System Security Policy - Restricted - 22/29

 • Cross-site scripting;
• Access control
• Cross-site request forgery;
• Session management.
Rule-174: Information security must be included throughout the development life cycle.
Rule-175: Services exposed to public networks must require authentication and must use protocols that are
authenticated, encrypted and protected against tampering.
Rule-176: Communications with suppliers containing users’ data must be authenticated, encrypted and
protected against tampering.
Rule-177: Development or test accounts must be removed before applications are released to customers.

3.10.2 Training of developers

Rule-178: Developers must be trained to secure coding techniques at least annually (for example on the
OWASP guidelines).

3.10.3 Development environment separation

Rule-179: Development, test and pre-production environments must be separated from the production
environment.
Rule-180: Access control mechanism must be enforced to ensure that the development environment
cannot access the production. This access control must include:
• Network-level filtering (firewalling or ACL): development systems and workstations cannot
connect to the production.
• Accounting restrictions: developers do not own any account on production systems).
• A separation of duties between personnel assigned to the development/test environments and
those assigned to the production environment is mandatory.
• Development/test servers must never be exposed on Internet.

3.10.4 Refresh of the development environment

Rule-181: Real PANs must not be used for testing or development.
Rule-182: Production encryption and decryption keys must never be present in the development
environment or known by developers.
Rule-183: For legitimate technical or business reasons, the development environment may be refreshed
with production data with a process that replace production encrypted PAN by a set of fake PAN previously
encrypted with the test keys set.

3.10.5 Code review prior to production

Rule-184: Before being delivered to production, code changes must be reviewed (using either manual or
automated processes).

KDS – Neo – Information System Security Policy - Restricted - 23/29

Rule-185: Code review must be performed by individuals other than the original author, with enough
knowledge of code review techniques and secure coding practices.
Rule-186: Code reviews must ensure code is developed according to secure coding guidelines (see PCI DSS
Requirement 6.5). The code review must include the following checks:
• New functionalities or change does not adversely impact the security of the system
• Validation of all input (to prevent XSS, SQL injection...) is effective
• Proper error handling is in place
• Use of secure cryptographic storage API
• Secure communication is effective
• Role-based access control (RBAC) is effective (authorization is enforced on server-side)
• Old releases, test functions, accounts and data, or scripts or debug menu has been removed.
• Debug/Logging/Traces functions must be set to a normal level where PAN are not written in logs,
traces or debug files.
• Accounts and credentials used on the development environment by developers and testers have
been properly removed from code, database schemas and application configuration files
Rule-187: Only supported libraries must be used for developments.

3.11 THIRD PARTY MANAGEMENT

Objective: Ensure that KDS security requirements are applied by service providers.

Rule-188: New service providers’ security must be evaluated and validated before engagement.
Rule-189: KDS security requirements regarding confidentiality, integrity and availability must be
documented and agreed with service providers that could impact security.
• In particular, contracts with KDS service providers who store, process or transmit cardholder data
or could impact the security of cardholder data, must contain the acknowledgement that those
service providers are responsible for the security of cardholder data.
Rule-190: KDS security requirements regarding confidentiality, integrity and availability must be
documented and agreed along the services and product supply chain.
Rule-191: If service providers can impact cardholder data security, the requirement that they be PCI DSS
compliant must be documented in the contracts.
Rule-192: An inventory of service providers must be maintained. This inventory must indicate whether the
service provider could impact the security of cardholder data.
Rule-193: A document must indicate which PCI DSS requirements are managed by each service providers,
and which are managed by KDS.
Rule-194: PCI DSS compliance status must be monitored at least every year for service providers who store,
process or transmit cardholder data, or who could impact the security of cardholder data.

KDS – Neo – Information System Security Policy - Restricted - 24/29

Rule-195: ISO 27001 compliance status must be monitored at least every year for service providers who
could impact security. This must include the verification that the certification scope includes the service
provided.
Rule-196: Third parties that access non-public information must have signed non-disclosure agreements.
Rule-197: Third parties are not allowed to directly access the production environment.
Rule-198: Security must be taken into account whenever there is a change with the service provided or
with the providers themselves. This implies that risks related to this service must be re-assessed.
Rule-199: An inventory of maintenance contracts must be maintained.
Rule-200: Contracts with customers must include the acknowledgement that KDS is responsible for the
security of cardholder data it possesses or otherwise stores, processes, or transmits on behalf of the
customer.

3.12 VULNERABILITY AND INCIDENT MANAGEMENT

Objective: Prevent exploitation of vulnerabilities and ensure a consistent and effective approach if they are
exploited.

3.12.1 Event and incident management

Rule-201: On-duty personnel must be designated to manage production and security events 24/7.
Rule-202: Vulnerabilities and incidents must be managed in compliance with KDS Neo Incident
Management Policy.

3.12.2 Vulnerabilities detection

Rule-203: Vulnerabilities are identified through:
• A vulnerability watch;
• Internal observations;
• Internal or external vulnerability scans;
• Internal or external penetration testing;
• Internal ISO 27001 audits [see 3.1.5.2];
• External audits (customer audits, ISO 27001 certification audits, PCI DSS audits…).

3.12.2.1 Vulnerability watch

Rule-204: All system, framework and IT components must be included on the vulnerability watch process.
For instance:
• Operating systems (Linux, AIX, Solaris, Windows…)
• Databases (Oracle, MS SQL, MySQL…)
• Services (Apache, IIS, SSH, XFB…)
• Application framework (Tomcat, Jboss, Webpshere, Coldfusion, .Net libraries…)
• Network devices (Firewall, routers, switches...)
Rule-205: Outside sources must be used to identify new vulnerabilities, such as:
KDS – Neo – Information System Security Policy - Restricted - 25/29
 • Vendors official advisories on their websites;
• Attendance to security conferences;
• Private and public CERT, such as the CERT-FR https://cert.ssi.gouv.fr/;
• US CERT: http://www.us-cert.gov/;
• BugTraq: http://www.securityfocus.com/archive/1;
• Linux Redhat / Centos: https://rhn.redhat.com/errata/rhel-server-errata-security.html;
• Oracle DB: http://www.oracle.com/;
• Microsoft Windows: http://technet.microsoft.com/en-us/security/bulletin.

3.12.2.2 Internal vulnerability scans

Rule-206: Internal vulnerability scans must be performed at least every quarter and after any significant
change in the network (such as new system component installations, changes in network topology).
Rule-207: Scans must target every internal IP addresses and URL in the CDE.
Rule-208: Rescans are required until all “High” vulnerabilities are resolved.
Rule-209: Scans must be performed by an independent qualified internal or external resource, which
vulnerability database is up-to-date.
Rule-210: Authenticated scans (i.e. with administrative credentials) are not required.
Rule-211: Scan reports must be kept 3 years.

3.12.2.3 External vulnerability scans

Rule-212: External vulnerability scans must be performed at least quarterly and after any significant change
in the network (such as new system component installations, changes in network topology, product
upgrades).
Rule-213: External vulnerability scans must be performed by a PCI SSC approved scanning vendor (ASV).
Rule-214: External scans reports must state a “PASS” or “COMPLIANT” certified result.
Rule-215: Scan reports must be kept 3 years.

3.12.2.4 Penetration tests

Rule-216: External penetration tests must be conducted on KDS production environment at least once a
year and after any significant change.
Rule-217: Internal penetration tests must be conducted on the production network at least once a year and
after any significant change.
Rule-218: Penetration tests must be planned and agreed to avoid disruption of KDS production.
Rule-219: Penetration tests reports must be kept 3 years.

KDS – Neo – Information System Security Policy - Restricted - 26/29

3.12.3 Vulnerabilities correction
Rule-220: Each vulnerability discovered must be assigned with a risk ranking. This ranking may be defined
by vendors, auditors, scanning tools themselves, or may be re-assessed by KDS depending on its own
context. Risk rankings are defined as “Low”, “Medium”, “High” and “Critical”.
Rule-221: A vulnerability register must be maintained to list all software vulnerabilities discovered on the
production environment. For each vulnerability, this register must contain:
• its scope:
 KDS software application,
 platform vendor-caused vulnerability,
 non-vendor-caused vulnerability (for example, vulnerabilities related to configuration
items, cryptography, unnecessary listening services…);
• its risk ranking: depending on the easiness to exploit the vulnerability (taking into account the
existence of preconditions such as authentication or network access) and its impact;
• concise description of the vulnerability;
• details of the risk acceptance criteria items;
• the decision to accept or to fix the vulnerability.
Rule-222: Risk acceptance criteria are, for all software vulnerabilities:
• A PCI DSS obligation to fix;
• The risk ranking;
• The residual risk;
• The difficulty to fix the vulnerability, including a technical or business constraint.
These criteria are also used to decide on a correction delay.
Rule-223: For vulnerabilities related to KDS software application, vulnerabilities must be fixed, according to
PCI DSS, if:
• either the risk ranking is high;
• or the vulnerability concerns one of the following topics:
 injection
 buffer overflow
 insecure cryptographic storage
 insecure communications
 Improper error handling
 XSS
 Improper access control (insecure direct object references, failure to restrict URL access,
directory traversal, failure to restrict user access to functions)
 CSRF
 Broken authentication and session management
 OWASP top 10 vulnerabilities.
Compensating controls may be envisaged when legitimate technical or business constraints prevent KDS
from meeting this requirement.

KDS – Neo – Information System Security Policy - Restricted - 27/29

Rule-224: All “Critical” or “High” risk vulnerabilities raised by vulnerability scans must be fixed. By default,
the considered level of risk is the one given by the scanning tool but it may be modified by KDS in the
vulnerability register.
Rule-225: For vulnerabilities related to the platform and caused by vendors, all applicable patches must be
applied, according to PCI DSS.
Rule-226: For vulnerabilities related to the platform and caused by vendors, critical vulnerabilities must be
fixed within 1 month. Other vulnerabilities must be fixed within 3 months.

3.12.4 Obstruction to vulnerabilities

Rule-227: Public-facing web applications must be protected against known attacks by a web-application
firewall.

3.13 INFORMATION SECURITY ASPECTS IN BUSINESS CONTINUITY MANAGEMENT

Objective: Reduce the impacts of disruptive incidents affecting availability.

3.13.1 Redundancy
Rule-228: All critical network equipment must be redundant.

3.13.2 Back up

3.13.2.1 Customer data

Rule-229: Customer data must be backed-up at least daily.
Rule-230: Back-ups must be kept at least one week.
Rule-231: Restoration tests must be performed at least once a year.
Rule-232: Back-ups must be kept out of the production environment.

3.13.2.2 Technical configurations

Rule-233: Network and security configurations (firewall rules, switches configurations, global policies…)
must be backed up at least before they are modified.
Rule-234: Back-ups must be kept at least six months.
Rule-235: Effectiveness tests of those back-ups must be performed at least twice a year.

3.13.2.3 Source code

Rule-236: KDS software source code must be backed-up at least daily.
Rule-237: Back-ups must be kept one week.
Rule-238: Restoration tests must be performed at least quarterly.

KDS – Neo – Information System Security Policy - Restricted - 28/29

3.13.3 Continuity of critical security processes and operational controls
Rule-239: Reviews must be performed quarterly to ensure that personnel are following the security policies
and operational procedures, and in particular:
• Daily log reviews;
• Firewall reviews;
• Applying configuration standards to new systems;
• Responding to security alerts;
• Change management process.
Rule-240: Failure of critical security controls must be quickly detected and reported. This applies to at least:
• Firewalls;
• IDS (intrusion detection system);
• FIM (file integrity monitoring);
• Antivirus;
• Physical access controls;
• Logical access controls;
• Audit logging mechanisms;
• Segmentation controls: firewalls and VLAN.
Rule-241: When a failure of a critical security control is detected, the following tasks must be performed:
• Restore security functions;
• Identify and document the duration of the security failure with date and time start to end
• Identify and document root cause of failure
• Document remediation required to address root cause
• Implement controls to prevent cause of failure from reoccurring
• Identify and address security issues that arose during the failure
• Assess risks to determine whether further actions are required as a result of the security failure
• Resume monitoring of security.

3.13.4 Disaster recovery

Rule-242: A disaster recovery plan must be defined and implemented.
Rule-243: The disaster recovery plan must be tested every year.

3.14 COMPLIANCE
Rule-244: KDS must maintain its compliance to PCI DSS.
Rule-245: KDS must maintain its compliance to ISO 27001 on the ISMS scope.
Rule-246: Licences must be obtained and maintained for proprietary software products.
Rule-247: KDS must be compliant with the General Data Protection Regulation (GDPR).

KDS – Neo – Information System Security Policy - Restricted - 29/29