-

28th of May 2014

Group IT Security Policy – V2

Entity Name Position Date Signature

-

-

1. SCOPE AND TARGETS ................................................................................................................. 4

1.1 Foreword ................................................................................................................................................. 4 1.1.1 Why a Security Policy? ......................................................................................................................... 4 1.1.2 Applicability statement ........................................................................................................................ 4 1.1.3 Group security policy approval process ............................................................................................... 4 1.1.4 Group vs. Entities responsibilities ........................................................................................................ 4 1.1.5 Policy Management ............................................................................................................................. 5

1.2 Main acronyms ........................................................................................................................................ 5

1.3 Security related business needs .............................................................................................................. 5 1.3.1 About security needs ........................................................................................................................... 6 1.3.2 Security needs and risks assessment ................................................................................................... 8

1.4 Security policy audience .......................................................................................................................... 8 1.4.1 Management related targets .............................................................................................................. 8 1.4.2 Security expertise related targets ........................................................................................................ 8 1.4.3 Personnel related targets .................................................................................................................... 8

2. SECURITY MANAGEMENT ............................................................................................................ 9

2.1 Organization and responsibilities ............................................................................................................ 9 2.1.1 Security ................................................................................................................................................ 9 2.1.2 Responsibilities .................................................................................................................................... 9 2.1.3 Security framework ........................................................................................................................... 10 2.1.4 Security forum ................................................................................................................................... 10

2.2 Conformity, reporting and improvement .............................................................................................. 11 2.2.1 Controls and traceability ................................................................................................................... 11 2.2.2 Security Reporting ............................................................................................................................. 11

2.3 Incident management and business continuity .................................................................................... 11 2.3.1 Security incident and crisis management .......................................................................................... 11 2.3.2 Business applications continuity needs ............................................................................................. 12 2.3.3 Business applications continuity means ............................................................................................ 12

2.4 Personnel management, behaviour and training .................................................................................. 13 2.4.1 HR process and procedures ............................................................................................................... 13 2.4.2 IT end user Policy ............................................................................................................................... 13

2.5 External parties management ............................................................................................................... 13 2.5.1 Outsourcing and subcontracting ....................................................................................................... 13 2.5.2 Third party IT users ............................................................................................................................ 14

2.6 Legal Compliance ................................................................................................................................... 14 2.6.1 Compliance with applicable legislation ............................................................................................. 14 2.6.2 Software Compliance ......................................................................................................................... 14

3. INFRASTRUCTURE AND OPERATIONS SECURITY .............................................................................. 15

3.1 Computing devices and network security ............................................................................................. 15 3.1.1 Workstations and mobile devices security ........................................................................................ 15 3.1.2 Group network security ..................................................................................................................... 15 3.1.3 Entities network security ................................................................................................................... 16

3.2 Operation security ................................................................................................................................. 16 3.2.1 Servers protection .............................................................................................................................. 16 3.2.2 Supervision and control ..................................................................................................................... 16

3.3 Physical and environmental security ..................................................................................................... 17 3.3.1 IT facilities perimeter and access ....................................................................................................... 17 3.3.2 Hazardous threats protection ............................................................................................................ 17

4. APPLICATIONS AND DATA SECURITY ............................................................................................ 18

4.1 Applications and data classification ...................................................................................................... 18 4.1.1 Classification process and specific security rules ............................................................................... 18

-

-

4.1.2 Inventory of the sensitive assets ........................................................................................................ 18

4.2 Development and maintenance ............................................................................................................ 18 4.2.1 Security within project management ................................................................................................ 18 4.2.2 Software development and maintenance security ............................................................................ 19

4.3 Logical access protection ....................................................................................................................... 19 4.3.1 Accounts and privileges ..................................................................................................................... 19 4.3.2 Authentication ................................................................................................................................... 20 4.3.3 Remote access ................................................................................................................................... 21

5. IT SECURITY COMPONENTS ....................................................................................................... 22

-

-

1. Scope and targets

1.1 Foreword

1.1.1 Why a Security Policy?

Information Technology (IT) has become an essential factor in the operational effectiveness and continued competitiveness of the Group. As IT becomes more and more integral to the successful delivery of the companies objectives, IT must reach a satisfactory level of reliability.

In accordance with Pernod Ricard’s ‘Integrity’ value, the security policy is a key factor in ensuring information reliability. Therefore, the application of this document has to fulfil three expectations:

To protect the Group Information systems assets,

To improve the Group IT security level among entities while taking into account their disparities in terms of activity, sales level and culture.

To ensure compliance with applicable legal requirements such as “French LSF”, Data privacy, …

1.1.2 Applicability statement

This security policy is applicable to the IT of the Group and some of its partners (customers, suppliers, consultants, etc.), therefore:

Each entity (regional level, affiliate or data centre) must be covered by an IT security policy. The Group IT Security policy should be considered a minimum. Locally, affiliate security policy can be stricter.

If an entity security policy does not exist, the upper level security policy will be considered as directly applicable (e.g. the Group security policy will apply to an entity which does not have its own policy).

All aspects are applicable to third parties IT users, external consultants…).

Furthermore, any employee of the Pernod Ricard Group has to comply with this policy through clear and appropriate training and/or documentation as required.

1.1.3 Group security policy approval process

The Group security policy is inter-related with the IT resources and processes. It is also inter-related with each Group business process, therefore, the approval involves:

The executive management,

The Group IT department,

The Group Internal Audit department.

1.1.4 Group vs. Entities responsibilities

There are well defined responsibilities for both the Group and the entity levels functions:

Group level is responsible for defining, supporting and updating the Group security policy.

-

-

For Group applications and services spread worldwide (Prisma, Group Active Directory, ESN, Group cloud applications…), Group is responsible for global compliance and the local affiliates must apply local security rules (e.g. user management, application access right…)

Entity level is responsible for understanding and implementing the security policy taking into account specific local requirements.

1.1.5 Policy Management

The Group security policy is to be reviewed on a yearly basis in order to keep up to date with changing security requirements (new threats, etc), risk assessments, business/IT developments and entities feedback.

Policy reviews are to be conducted at a Group level in collaboration with entity security representatives. To fulfil this objective, each of the security representatives is to participate in a draft review of the Group security policy and to provide suggestions and feedback. For each policy update, an appropriate review and communication plan will be formalised.

Following the publication of the Group security policy, any existing entity level security policies will be updated in accordance with Group security policy.

1.2 Main acronyms

The main acronyms used in this document are listed in the table below:

Acronyms Meaning

A, I, C, T Availability, Integrity, Confidentiality, Traceability

BCP Business Continuity Plan

DMZ Demilitarized Zone

DRP Disaster Recovery Plan

ESN Enterprise Social Network

IS Information System

IPS Intrusion Prevention System

ISMS Information Security Management System

IT Information Technology

NDA Non-Disclosure Agreement

PKI Public Key Infrastructure

UPS Uninterruptible Power Supplies

RTO Recovery Time Objective

RPO Recovery Point Objective

SOC Security Operation centre (service provided for monitoring data centres security)

1.3 Security related business needs

-

-

1.3.1 About security needs

1.3.1.1 Criteria

These four criteria form the basis for security requirements and risks assessment. Therefore, they should be understood by each individual handling sensitive IT assets.

Criteria Meaning Main threats

Availability

Recovery of an application or data within a pre-determined time period (Recovery Time Objective) and to a pre-determined point in time (Recovery Point Objective).

System failures, environmental and natural disasters, energy supply shock

Integrity Non-alteration of data and systems.

Human error, user access rights usurpation or overruling, virus, system and software failures, hacking.

Confidentiality Non-disclosure of strategic information to unauthorised groups or individuals.

User access rights usurpation and overruling, industrial espionage, Human behaviour, and Trojans, network eavesdropping.

Traceability Capability to trace and proof the origin of an event related to the IT data and process.

Denial of action, fraud, user access rights usurpation, breach of the legal requirements.

1.3.1.2 Security levels

The security levels (or ‘criticality Levels’) defined below are the Group guidelines for any IT related processes and/or resources. The security level (1 Low, 2 Medium, 3 High) of an asset or process are determined by the business value (criticality) of the asset to the operation of the Group.

- -

Criticality Levels

1 2 3

Imp

acts

Image Image of the Group is altered, in the very short term, for a few individuals (customers, employees and partners).

Image of the Group is altered, in the short term, for a moderate number of individuals (customers, employees and partners).

Image of the Group is altered, in the middle or long term, for a large number of individuals (customers, employees and partners).

Finance Competiveness

Financial consequences are not significant regarding the profitability and the competitiveness of the concerned entity (No gearing impact).

Financial consequences impact moderately the profitability and the competitiveness of the concerned entity (gearing impact <5%).

Financial consequences impact strongly the profitability and the competitiveness of the concerned entity (gearing impact >5%).

Strategy Strategy of an entity is slightly delayed or affected (office organisation…).

Strategy of an entity is moderately delayed or affected (management organisation, product promotion…).

Strategy of an entity is affected concerning major topics (merger, acquisition, international development…).

Compliance Industry standard best practices are not fully applied (professional standards, etc…).

Some laws and regulation are not yet fully applied. The potential consequences shall remain moderate.

Some laws and regulation are not applied. Heavy penal or financial consequences can occur (impeachment, imprisonment…).

Operations Operation capacity is impacted but there is manual work arounds in place.

Operation capacity is moderately impacted (Less than two days).

Operation capacity is severely impacted (More than two days).

Mai

n r

eq

uir

em

en

ts

Availability

Minimum RTO: xx / Minimum RPO : xx. The recovery time and recovery point objectives should be defined in the Service Level Agreements (SLA's) agreed with the business for each IT system/service. The SLA's defined for security level '1' should take into consideration the guidelines above.

Minimum RTO: xx / Minimum RPO : xx. The recovery time and recovery point objectives should be defined in the Service Level Agreements (SLA's) agreed with the business for each IT system/service. The SLA's defined for security level '2' should take into consideration the guidelines above and should be in line with the DRP requirements.

Minimum RTO: xx / Minimum RPO : xx. The recovery time and recovery point objectives should be defined in the Service Level Agreements (SLA's) agreed with the business for each IT system/service. The SLA's defined for security level '3' should take into consideration the guidelines above and should be inline with the DRP requirements.

Integrity

No specific integrity controls required. However, version control is encouraged.

Checksums and/or transaction/security logging and/or protected data format should be in place.

Transaction and security logging measures should be in use, along with backup and retention procedures in line with the guidelines above.

Confidentiality

Data has the status of Public or Internal is published internally to all employees (Intranet), no specific protection required.

Data can be communicated to a limited number of people and should be subject to user access rights restrictions and password protection.

Data is considered "Confidential". Its owners and people who may have knowledge should be identified. User access rights and password protection should be implemented when the data is stored and the data should be encrypted when transmitted.

Traceability

There are no specific traceability requirements. The origin of the data should be easily identified. The traceability requirements should be in line with the guidance above and all applicable legislation.

Where there is a requirement to prove the origin and manipulations of data. The traceability requirements should be in line with the guidance above and all applicable legislation, fiscal and audit requirements.

-

-

1.3.2 Security needs and risks assessment

The IT services and procedures supporting each business process of the Group (General management, Finance, Human Resources, Audit and control, Production and delivery, R&D, legal affairs, Sales, Purchasing, Marketing, communication, group interest promotion and protection) should be protected according to a business oriented risks assessment.

A business oriented risk assessment process should be conducted each year on the main IT assets of the Group and of each affiliate and signed by key business stakeholders. It will assess the risk through:

The security needs of the asset (potential impacts for each A, I, C, T criteria)

The exposure of the asset to the applicable threats,

The residual vulnerabilities of the asset environment.

1.4 Security policy audience

1.4.1 Management related targets

Target 1: Both functional (non-IT) and IT management actively support the IT security policy.

Target 2: Management follow up the security achievements through regular security reviews and reporting.

Target 3: Security is driven by business oriented risk assessment.

Target 4: An appropriate management reporting procedure is in place in the event of security events (failures).

1.4.2 Security expertise related targets

Target 1: Each entity maintains the necessary expertise, either through its internal organisation or 3rd parties, in accordance with its security requirements.

Target 2: The Corporate IT function provides security support and guidance where applicable.

Target 3: Security expertise is shared among the Group.

Target 4: Every IT user is aware of his/her responsibilities in relation to IT security.

1.4.3 Personnel related targets

Target 1: Each Group employee is aware of his/her role and obligation in relation to IT security.

Target 2: A consistent Group culture exists in the field of IT protection.

Target 3: People involvement is encouraged.

Target 4: Sanctions are known and applied.

-

-

2. Security management

2.1 Organization and responsibilities

2.1.1 Security

A) The role of the Group IT department is to manage the Group security strategywhich is formalised in the Group security policy. It also has the responsibility to organise a Group Security Forum (see 2.1.4) and to provide the executive management with a clear view of the security achievements and the IT related risk exposure levels. The Group IT department should also pursue global convergence and coherence in entities’ security-related, processes, tools and equipment strategy.

B) In addition to its active participation in the security forum, it is recommended that each entity define a specific security policy in compliance with the Group Security Policy. Where no entity level security policy exists the Group security policy will apply. Entities are responsible for the implementation of the applicable policy, for promoting IT security, and regularly reporting to the Group.

C) Each entity should nominate an individual to be responsible for IT security and to participate in the Group Security Forum.

D) IT users should be aware of the defined security practices. As such should be active participants with alerting and reporting obligations.

E) Each entity should alert the Group IT department’s security team in case of severe security events or in the case of a threat that could impact the Group IT security or other entities.

F) In the event that Group IT identifies threats which could endanger some entities, an alert will be broadcasted to the person responsible for security in each entity or their nominated contact (helpdesk, etc.). Security IT alerts may be escalated to Infrastructure managers and CIO / IT Directors if necessary

2.1.2 Responsibilities

A) Corporate IT is responsible for the security of corporate applications, infrastructure and data. It is also responsible for promoting this Group IT security policy, and for coordinating and reinforcing global level of security, possibly through implementation of worldwide solution such as IPS, firewall management… This implies that Corporate IT has to take any necessary steps to establish and promote clear and adequate rules to protect corporate IT assets. Corporate IT is also responsible for coordinating security efforts on a Group level in order to promote standard and homogenous practices.

B) Internal Audit is responsible for following up the implementation of security in accordance with legal and fiscal requirements, through regular audits of affiliates and Group. Internal Audit provides both executive management and Corporate IT with a reporting of differences between requirements and practices.

C) Entities IT teams and management are responsible for respecting the corporate rules, for protecting the entity IT according to the specific needs and obligations, and for implementing the local (applicable) IT security policy. The local Entity IT team is also responsible for ensuring they are familiar with applicable local legalisation and ensuring their IT procedures are compliant with these regulations.

D) Users are responsible for their data in accordance with Group and/or the entity policies.

-

-

2.1.3 Security framework

A) The security framework consists of:

A Group Security policy which details rules to be followed. This policy expresses “the what” and does not document “the how”. Every entity should formalize the procedures and guides (the how).

A security policy in each entity which cannot be less restrictive than the Group security policy. This document should be aligned with Group security policy. When such a security policy doesn’t exist, the Group security policy applies to the entity level.

A Business Continuity Plan (BCP) at the Group level and in each entity. This BCP defines priorities and conditions of continuity for each sensitive application.

A formal IT user policy or procedure should be in place in each entity. This may be in the form of security procedures and policies (dos and don’ts) training or may be through a documented IT user policy.

Other procedures which concern security rules implementation such as access rights implementation, security events reporting, back-ups, operations etc.

Guidelines which provide recommendations and support to conduct security related actions such as system configuration, access control technologies, etc.

2.1.4 Security forum

-

-

A) A security forum is defined at the corporate level and its members are the individuals responsible for security throughout the Group. The target of this security forum is to enable a continual improvement in the security practices of the Group and to facilitate cooperation among the people involved.

B) The security forum requires a structured communication approach. Therefore, continuous exchange and communication is encouraged.

2.2 Conformity, reporting and improvement

2.2.1 Controls and traceability

A) IT data and process security related controls should be defined and documented. It is the responsibility of each IT department to build and maintain the list of controls. The controls list should include: the person in charge (Who), a brief description of the target and modus operandi of the control (What), the date of the next control (When), and the frequency (How often).

B) Whether the control is manual or automated, a record should be kept of the result of each control. The record conservation period will be in line with the requirements of the application owner.

C) Alarms, logs and audit trails related to the controls which are held will be safely stored for a period in line with the control result conservation period requirement.

2.2.2 Security Reporting

A) Each entity’s senior IT management is aware of the security strengths and weaknesses within his area of responsibility. The IT management provides the executive management with an explicit yearly report containing the accurate level of information. This report summarises the achievements or events related to the most sensitive topics, such as: security audits main results, number and nature of severe incidents, conformity and efficiency of the BCP, security policy accuracy…

B) Operational security must be ensured on a continuous basis. In addition to security supervision, regular security reporting should be performed and submitted to the entity IT management. This report provides visibility on the main security indicators ( for example, servers and environment availability, number of random or specific attacks, frequency of virus detection, number of virus infections, restores from back-up results, results of safeguards integrity controls …).

C) Reporting and dashboards documents should be stored safely with a record of the persons who have been presented or communicated those documents.

2.3 Incident management and business continuity

2.3.1 Security incident and crisis management

A) Employees of the Group should be aware of the different kind of security events they may face. An appropriate process should allow for each employee to report a security event such as: virus infection, network intrusion or critical system malfunction.

B) In case of a security incident or crisis, points of contact will be named for each entity. Points of contact will be reachable through phone or mail. After a pre-qualification, the point of contact will have the responsibility to dispatch the alert accordingly. A record of each alert will be kept. At least one point of contact must be reachable at any moment during working hours.

-

-

C) It is important that the person(s) in charge of dealing with an alert is empowered sufficiently to manage an event and is guaranteed access to the appropriate level of decision maker. Empowerment rules should be clearly defined. They should include the specific conditions for emergency actions.

D) For each incident (from alert to incident resolution), a log should be kept recording each person involved and the action taken. Evidence should be kept to help with a post incident review.

E) An alert and crisis management process should be defined for the Group, including an appropriate escalation procedure.

F) A follow-up for each security incident is encouraged, with the lessons learned being applied in order to prevent reoccurrence of the event.

2.3.2 Business applications continuity needs

A) IT and Business managements should participate in a business continuity needs assessment (BIA – Business Impact Analysis), resulting from a risk assessment. For each critical application, a SLA (Service Level Agreement) should be maintained specifying the maximum acceptable duration of unavailability in the case of a severe security event.

B) In line with the applications continuity needs, a BCP (Business Continuity Plan) is formalised and acknowledged by both functional and IT management. It describes:

The overall continuity strategy.

The continuity needs of each critical application.

The continuity commitment (SLA) agreed for each application (maximum delay in recovery (RTO), recovery point objective (RPO), etc.) the continuity procedures and recovery methods for each application.

2.3.3 Business applications continuity means

A) Each entity’s continuity infrastructure and protection measures are in line with business needs. It is the responsibility of each entity’s IT management to regularly evaluate the efficiency of continuity infrastructure and means.

B) The measures used to ensure business continuity and system availability include:

The Business Continuity Plan (see before).

The back-up plans: back-up plans describe strategies, frequencies, solution, storage conditions and retention, taking into account the legal and finance constraints

The restore plans: restore plans describe the procedures to restore the data and / or system, the associated verification and the steps required to return to a normal situation.

The Disaster Recovery Plan (DRP): the DRP describes the procedures to be used in case of major system failure or location disaster. A disaster, and the consequent implementation of the DRP, should be declared by the entities senior management team. The DRP should be reviewed at least one a year , and on business changes (new critical application, new platform implementation, …)

The test plans: Test plans are formalised and include the test frequency, conditions and processes for each component of the BCP. DRP test should be performed at least once a year resulting in successful recovery, including test of servers and data restorations.

-

-

The DRP and test plans apply to internal Data Centres, Outsourced hosted applications and Cloud platforms.

2.4 Personnel management, behaviour and training

2.4.1 HR process and procedures

HR, employee manager or business application owners should initiate every credential and access rights requests in relation to employees’ roles and responsibilities. Requests are always approved by application owner and traced by the IT department (or any other appropriate grantor of privileges)

This should be formalized through Active Directory updates and application access right set-up, taking into account segregation of duties.

Any modification (new role, departure, transfer) must follow the same process and be subject to the same approvals.

For each critical application or data resource, user access rights must be reviewed on a regular basis (at least once a year) by the application or resource owner.

2.4.2 IT end user Policy

A) An end user IT policy should be defined in each entity, this may take the form of documented IT end user policies and procedures and may also include formal IT induction training.

B) The end user IT policy should include guidelines regarding use of emails and the Internet, passwords protection and renewal, computer ,smartphones and tablets configuration, use of communication tools (e.g. Skype), use of cloud storage (e.g. DropBox), Enterprise Social network (PR Chatter), data management and classification and all dos and don’ts defined by the affiliate.

C) It is recommend that IT security training is available to the new starters. The training plan should include: Internet, email, computer and smartphone use policies, ESN etiquette, user access account and password rules, physical computing equipment protection.

D) Employees awareness of security concerns should be maintained. This awareness reinforcement can use regular messages from the IT department, communication from executive management, reminders of recent security events.

E) Each employee is required to formally accept the User policy and ESN policy

2.5 External parties management

2.5.1 Outsourcing and subcontracting

A) Prior to the establishment of an outsourcing or subcontracting contract (data centre, application development, etc.), a contract risk analysis should be performed. This risk analysis will determine the main risks to be covered by specific contractual requirements. Furthermore, it will draw the perimeter of the “need to know” and the “need to do” for the supplier.

B) Any contract related to sensitive IT assets (level 2 and 3) should include a NDA (Non-Disclosure Agreement).

C) Prior to contract signature, outsourcing or cloud contracts should include the specific obligation the supplier has to fulfil in relation to IT security. For critical outsourcing or cloud contracts, it may

-

-

be extended to the whole scope of the present security policy. In case of hosting or cloud solutions, a reversibility clause should be included in the contract. When required, data privacy protection clause, with declaration to local administration, must be signed.

D) Any outsourcing or cloud contract concerning critical assets (level 3) should include a procedure which entitles the entity to launch a control audit or require specific security audit certification (ISAE 3402, SSAE 16....). It stipulates the obligation of the suppliers to take the necessary steps in case of established security weaknesses. Furthermore, severe security breaches or non-conformities regarding the obligations of the supplier will be identified as possible reasons for a contract review.

E) For internet web sites or sensitive applications, periodic intrusion tests should be performed. The supplier must have the obligation to fix any major issue.

2.5.2 Third party IT users and contractors

A) User and security policies are applicable for each and every third party users. Therefore, it should be provided prior to the use of the IT resources.

B) Third party users and contractors should have a nominative account with an expiration date corresponding to the end of their contract

C) Each third party user should sign a NDA.

D) The company employing the third party user should sign a general NDA.

2.6 Legal Compliance

2.6.1 Compliance with applicable legislation

All IT systems, policies and procedures must be compliant with all local (country or state specific), regional and Group applicable legislation. This includes but is not limited to fiscal and audit legislation (e.g.: Loi de Sécurité Financière (LSF) and local financial reporting requirements), health and safety legislation, employment legislation, freedom of information legislation, data protection legislation, internet use legislation, electronic commerce legislation, etc.

2.6.2 Software Compliance

All software used in the Group should be approved by the IT department responsible for the entity where it is used. All software must be licensed and operated in line with the terms of the applicable licensing agreement.

Software usage must be periodically reviewed and compared against the acquired licensing rights.

-

-

3. Infrastructure and operations security

It is imperative that security solutions implemented on the network and sensitive resources efficiently protect the IT assets against various attack scenarios. Therefore, it is recommended that the security solutions, their implementation and configuration are to be assessed on a regular basis, through technical and intrusive audits on each of the entities’ sensitive networks.

3.1 Computing devices and network security

3.1.1 Workstations and mobile devices security

A) To be granted access to the entity or Group networks, a workstation must be equipped with an up-to-date and efficient solution against malicious software (virus, spywares, key loggers, etc). A procedure should be employed to verify this requirement is met. In case of non-conformity of the workstation, any communication between the workstation and the network resources is forbidden, and the workstation may only be routed to a specific network location with the adequate update tools.

B) It is recommended that end users are not given the access rights to change configuration settings of the workstations or are allowed to install software.

C) Any laptop and Windows tablet should be equipped with an efficient personal computer firewall. This firewall is kept up-to-date and its configuration interface access is limited to the workstation administrator. In the event that a personal firewall is not present alternative security provision should be in place for example redirection through the entity firewall prior to accessing IT resources or through a secure 3rd party.

D) Any mobile device should be managed through an MDM (Mobile device management) tool, allowing IT to wipe any device in case the device is lost or stolen.

E) It is recommend that system and main software updates are automated for workstations, laptops and Windows tablets, especially updates related to security. Where this is not available, and in some cases not desirable, a suitable manual procedure should be in place. Users should not be allowed to modify the software updates client configuration or to stop such an on-going process.

F) Sensitive workstations should be protected against robbery (ex: a security cable, locked cabinet…) while each mobile device user should be provided with appropriate physical security means to protect the device. In case of robbery, the device user should contact the IT department as quickly as possible. Whenever possible, the use of local data encryption tools is encouraged.

G) Mobile devices are operated taking into account their security capability and the potential threats they may generate.

3.1.2 Group network security

A) The Group network security requirements concerning interconnections with Group networks are extremely important since they are intended to protect the entire Group. Any failure to respect the Group requirements may result in disconnection of the entity from the Group network.

Among others, the Group requirements deal with:

Virus and malicious codes protection.

-

-

Architecture: segmentation and firewalls, application priorities management,

Interconnection requirements and limitations.

B) Each entity’s IT department is responsible for preventing Group networks from unwanted security events.

C) With the implementation of SOC service (a service monitoring network Intrusion on 24x7), it is mandatory to keep IPS located in local/regional Data Centres … Any major threat identified by Corporate IT may result in an immediate disconnection of the affected country or region.

3.1.3 Entities network security

A) Users privileges are controlled prior to any kind of access to entities local network resources. Generic accounts are not allowed and mechanisms prevent network authentication systems from brute force attacks. Whenever possible, authentication data will be encrypted between the user’s workstation and the authentication server.

B) Remote users should not access entities local networks without the appropriate security devices authenticating their access. Remote users’ authentication is checked prior to any active connection to networks. Authentication data should be encrypted.

C) Interconnections with third-parties are not recommended until an official interconnection agreement, committing both parties, has been signed by the person in charge of security within the entity and the third party. This agreement describes commitments of third parties regarding security, architecture at both ends and operative solutions. The agreement will be submitted to the approval of the Group IT department.

3.2 Operation security

3.2.1 Servers protection

A) It is recommended that each server has a designated administrator for securityThe administrators have to keep their passwords confidential and to renew these passwords regularly with non-trivial ones. Generic administration accounts are forbidden. Strictly controlled, formalised and documented mechanisms should be in place for password escrow in case of emergency.

B) Servers are stored in dedicated rooms equipped with the appropriate physical and environmental protection. (See 3.3 Physical and environmental security).

C) Application of updates, especially security updates, is managed through a well-defined patch management procedure. Patch management is reinforced by regular check-ups to assess the correct implementation of updates. Whenever possible, patch management is monitored through a specific solution or appliance.

D) Servers access logs and security parameters modifications should be safely recorded. Those records include unsuccessful attempts.

E) A database administrator should ensure that steps are taken to provide a level of security in line with the security needs of the data. The privileges of the data administrator will be determined in accordance with the owner(s) of each database related application(s).

3.2.2 Supervision and control

-

-

A) Critical security indicators should be monitored on a real-time basis: virus attacks, security systems status, critical system failures. Other security indicators and logs (access logs, firewall logs, proxy log, etc.) are reviewed frequently. Security related supervision procedures are described in a document. A record should be kept of security indicators and logs results.

B) Batch control processes should be formalized for sensitive applications, such as financial applications. A batch control processes description includes the main steps of batch control and refers to the alert related procedures. In case of failure, a proper batch recovery procedure must be documented.

C) An overall application landscape with data flows between applications must be documented and kept up-to-date.

D) Audit tracking management procedures should be clearly defined in order to keep track of any event related to IT security. Among others: gateways access, authentication failures, critical data access, intrusion attempts. The audit trails are to be safely stored in order to facilitate forensic investigations.

3.3 Physical and environmental security

3.3.1 IT facilities perimeter and access

A) IT facilities perimeter is clearly defined, especially the exact location of technical rooms and the security level of each area within this perimeter. The security level can be labelled as “MEDIUM” or as “HIGH”. The level “HIGH” is being applicable to all data centres.

B) Only authorised people can access IT facilities. It is recommended that for critical data centres an access control system is in place, this system should only allow access to authorised people.

C) Video surveillance systems may also be deployed for critical data centres.

D) Unauthorised access to critical data centres should trigger an alarm system.

3.3.2 Hazardous threats protection

A) IT facility room materials should be “fireproof” and any inflammable material is secured accordingly.

B) Firefighting equipment is installed in accordance with the criticality of the IT facilities. For the most critical IT facilities, automated fire suppression systems should be in place.

C) IT facilities should be located in a place where flooding related risk is highly unlikely.

D) Electrical surges or spikes should be prevented through adequate equipment and the risk of power outage should be mitigated by the use of UPS, generators and alternative source of supply.

E) Critical data centres should employ a Disaster Recovery Plan to mitigate against loss of the facility through natural or man-made disaster (terrorism, building fire, etc.).

F) IT facilities should be equipped with adequate air conditioning systems.

G) These devices (UPS, air conditioning, fire suppression system) should be periodically checked and maintained through appropriate contract with 3rd parties. Capacity of such equipment should be reviewed to match the evolution of the data centre to be protected.

-

-

4. Applications and data security

4.1 Applications and data classification

4.1.1 Classification process and specific security rules

A) Each application manager assesses security needs of his application regarding the availability, integrity, confidentiality and traceability criteria. This assessment should be kept up to date. The assessment should be performed on the application’s main functions and data.

B) Assessment of the applications is controlled by the person in charge of security in each entity. The person in charge of security ensures the coherence between the security needs of the application, main functions, data and resources (servers, network,). Thus, the person in charge of security is able to provide a clear view of the entity’s IT resources security level.

C) For each sensitive asset (application, data, shared resources), the person in charge of security specifies the specific security measures to be applied to the asset. The measures can be related to any of the security domains (physical security, logical security, continuity, etc.).

4.1.2 Inventory of the sensitive assets

A) In each entity, the person in charge of security should keep an inventory of each sensitive IT asset (level 2 or 3) and the relevant information associated with them (asset owner, security requirements, protection measures, etc.).

B) The inventory of sensitive assets is controlled and audited at least once a year. The owner is informed of any disparity between the requirements and the protection measures in place, and the remediation required.

C) The overall asset protection process, from classification to specific security is shown in the following diagram:

Application assets

Classification

process

Impact scale

A, I, C, T

Linked resources

Inventory

update

Specific

rules

Stamping

Credentials

Life cycle

…

A, I, C, T

Owner

Localisation

4.2 Development and maintenance

4.2.1 Security within project management

A) Each new application development or evolution project should take security into account for each step of the project. The formalization level of this process is based on the sensitiveness of the project. Therefore, the first step is the determination of application security needs, in line with the chapter “Applications and data classification” (4.1). All necessary measures are formalised in order to meet these security needs.

B) A formalised process describing the security methodology to be applied for each project should be adopted. This process should include at the minimum:

-

-

The initial security needs assessment by the application owner and its review by the person in charge of security.

The security measures to be implemented.

The initial go ahead.

The continuous controls.

4.2.2 Software development and maintenance security

A) Software development should be carried out on a specific environment separate from the production environments. If the development or quality control environment is refreshed with Production data, the person in charge of development or testing must guarantee to keep sensitive (see security levels matrix) data confidential and not to share with any 3rd party without any confidentiality agreement.

B) For sensitive applications, a specific access authorisation process should be used, where the application process business owner is required to authorise access requests to avoid access of non-authorized users.

C) Development outsourcing contracts should stipulate security requirements. They should include: intellectual copyright protection right and non-disclosure clause as a minimum.

D) Any contract concerning code, software or systems should include clearly defined Service Level Agreements and detailed support and update procedures.

E) On-site maintenance ought to be performed under the supervision of the person responsible for the systems.

F) For sensitive systems and applications, remote maintenance should be performed under the supervision of the person in charge of the system. Remote access to development systems must be conducted in line with the Security Policy remote access provisions (4.3.3).

G) Whenever possible, maintenance operations should not provide the maintenance operator access to sensitive data (application data, other configuration data).

H) The maintenance user access accounts and passwords should be used for maintenance purposes only and should not be generic.

I) Whenever possible, developers should not have write access to production environment.

4.3 Logical access protection

4.3.1 Accounts and privileges

A) Granting user access right and privileges relies on secure procedures typically defined by the application or business process owner. It is business driven and based on a “need to know” and a “need to do” basis (privileges are not to be granted by default) in relation to the functional role of the users. More precisely, accounts and privileges are granted in a way to ensure the segregation of duties and privileges.

B) For IT people, segregation principles allow for a clear distinction between security, development and production activities.

-

-

C) Except under exceptional circumstances (e.g. forensic oriented legal procedures), the accounts and rights database should be protected and not accessible to system administrators. The authentication related secrets are encrypted for each application.

D) The user’s privileges are reviewed regularly in order to check the following security properties:

Each user is granted the appropriate rights.

Each account implemented in the system is linked to one and only one legitimate user.

The reviews are held by application or business process owner and take into consideration the latest information concerning users’ role (change of role, promotion departure etc.).

4.3.2 Authentication

A) Except in exceptional circumstances, passwords remain the strict property of the user and are not to be accessible by any other person.

B) Passwords length and quality should be of a sufficient level to prevent dictionary attacks, brute force attacks or social engineering. Nowadays, the best practises recommend:

Passwords may not contain the user's AccountName (Account Name) value or entire displayName (Full Name value). Both checks are not case sensitive.

The password contains characters from three of the following categories: o Uppercase letters of European languages (A through Z, with diacritic marks, Greek

and Cyrillic characters) o Lowercase letters of European languages (a through z, sharp-s, with diacritic marks,

Greek and Cyrillic characters) o Base 10 digits (0 through 9) o Non-alphanumeric characters (special characters) (for example, !, $, #, %) o Any Unicode character that is categorized as an alphabetic character but is not

uppercase or lowercase. This includes Unicode characters from Asian languages.

Set Passwords must meet complexity requirements to Enabled. This policy setting, combined with a minimum password length of 8, ensures that there are at least 218,340,105,584,896 different possibilities for a single password. This makes a brute force attack difficult, but still not impossible.

Set Maximum password age to a value between 30 and 90 days, depending on your environment. This way, an attacker has a limited amount of time in which to compromise a user's password and have access to your network resources.

Set Enforce password history to 24. This will help mitigate vulnerabilities that are caused by password reuse.

Set Minimum password age to a value of 2 days. Setting the number of days to 0 allows immediate password changes, which is not recommended.

C) Systems and applications should incorporate session timeouts. The timeout length should be set by both the IT and Business managements.

D) Unsuccessful attempts to access sensitive information or resources should be logged by the system and recorded through security follow-up statistics and dashboards. It is recommended that accounts are disabled after 3 unsuccessful attempts or an alternative security access mechanism is in place to prevent multiple access attempts (e.g.: account locked during 30 minutes before new attempt to login is possible).

-

-

E) Sensitive data and IT resource accesses should be recorded in application and system logs (unsuccessful accesses, time of accesses).

4.3.3 Remote access

A) Remote users should be authenticated through strong authentication methods or, at the minimum, through a security agent ensuring that the user issuing requesting authentication is using their authorised mobile computer or device.

B) Data exchanged between the user’s device and application servers should be protected through end to end encryption relying on trustworthy encryption standards.

- -

5. IT security components

The following scheme contains the main IS security components.

BCP

Group

security

policy

Other

documents

and

procedures

Group

security

charter

Rules / Targets Transformation Means Results

IT corporate defines main

targets and rules

IT corporate provides support

in definition of the rules

•Group Security Forum

•Awareness and training material

•Alert crisis management

•Security and IT risks surveillance

Risk management

framework

Information Classification and inventory

•Group IT Security Policy

•Risks assessment tools

•Technical security guides

•Auto evaluation tool

•Main procedures (Traces and evidence management, rights positioning…)

Documents

Documents / Tools / Procedures

Organisation / Others

Local

security

policy

Security common

tools

Affiliates build local

security referentials