GLOBAL POLICY MANUAL

GIT-28 Access Control

Global IT

Date effective: July 2016

Approved: Michael Vögele, CIO

Table of Contents

1 Summary ................................................................................................................................. 2
2 Access Control ......................................................................................................................... 2
2.0 Scope ......................................................................................................................................... 2
2.1 Access Authorizations ............................................................................................................... 2
2.2 Database access ........................................................................................................................ 2
2.3 Allocation of user accounts ....................................................................................................... 2
2.4 Unique accounts ....................................................................................................................... 2
2.5 No group, shared, or generic accounts ..................................................................................... 3
2.6 Administrative accounts ........................................................................................................... 3
2.7 Need to know ............................................................................................................................ 3
2.8 Role re-evaluation ..................................................................................................................... 3
2.9 Role review process .................................................................................................................. 3
2.10 Inactive accounts ...................................................................................................................... 4
2.11 Account Termination ................................................................................................................ 4
2.12 Allocation of password.............................................................................................................. 4
2.13 Password changes and resets ................................................................................................... 4
2.14 New or replacement password ................................................................................................. 4
2.15 Initial passwords ....................................................................................................................... 4
2.16 Initial passwords communications channel .............................................................................. 5
2.17 Password compromise .............................................................................................................. 5
2.18 Password first-use ..................................................................................................................... 5
2.19 Password duration .................................................................................................................... 5
2.20 Password attempts and lockout ............................................................................................... 5
2.21 Password history ....................................................................................................................... 6
2.22 Inactive sessions........................................................................................................................ 6
2.23 Password complexity and length .............................................................................................. 6
2.24 Encryption ................................................................................................................................. 6
2.25 Non-adidas accounts ................................................................................................................. 6
2.26 Remember Password ................................................................................................................ 7
2.27 Two-factor authentication ........................................................................................................ 7
2.28 Remote service access .............................................................................................................. 7
3 Further Information ................................................................................................................. 8
3.1 Change History .......................................................................................................................... 8
4 References............................................................................................................................... 8

Latest update: 30.11.2016 Company Confidential

adidas Group - Global Policy Manual Page 1 of 9
GIT-28 Access Control Date effective: July 2016
Approved: Michael Vögele, CIO

1 Summary
This policy is to address the requirements for access control to information systems. It is
focused on the prevention of unauthorised access and the need for authorised access in
accordance with the requirements of the business.

2 Access Control
2.0 Scope
This document applies to all IT-systems and individuals granted access to IT-resources.
IT-systems include all communication network components, business application systems
and any computing system provided to users for the purpose of achieving the tasks in
their assigned roles.

2.1 Access Authorizations

Access to any adidas-Group GIT information system and application must be documented,
controlled and authenticated.

Rationale
Authentication ensures that the individual is who he or she claims to be to ensure only
legitimate access to adidas-Group GIT information system.

2.2 Database access

Authenticate all access to any database containing cardholder data. This includes access
by applications, administrators, and all other users. Restrict user direct access or queries
to databases to database administrators.

Rationale
Without user authentication the potential for unauthorized or malicious access increases.
Also, database access should be granted through programmatic methods only (for
example, through stored procedures).

2.3 Allocation of user accounts

The allocation of user accounts must be restricted and controlled, and access must be
granted according to individuals’ role within the business.

Rationale
The adidas-Group IT information systems often contain non-public information that
requires protection. Access to the systems must be controlled based on the ‘need to
know’.

2.4 Unique accounts

Each account name must be unique, assigned to a single user and must not be reassigned
for a defined grace period after it was terminated.

Latest update: 30.11.2016 Company Confidential

adidas Group - Global Policy Manual Page 2 of 9
GIT-28 Access Control Date effective: July 2016
Approved: Michael Vögele, CIO

Rationale
In order to speed up issue resolution, it is necessary to know which users performed what
action. Reusing usernames could lead to conflicts with the roles of the previous user.

2.5 No group, shared, or generic accounts

No group, shared, or generic accounts and passwords are allowed on any of the systems.

Rationale
Generic accounts are known and can be easily misused by malicious users. Group or
shared accounts make it difficult to determine who performed an action.

2.6 Administrative accounts

Separate administrative accounts must be used to perform any administrator task. The
administrative account password must be different from all other account passwords held
by that user.

Rationale
Accounts with increased privileges, such as the “administrator” or “root” account, have
the potential to greatly impact the security or operational functionality of a system. A
separate account prevents the user from accidentally using administrative rights.

2.7 Need to know

Access to all IT systems must be restricted based on role and need to know.

Rationale
Without a mechanism to restrict access based on user’s business responsibilities, users
may unknowingly be granted access to data they are not authorised to view.

2.8 Role re-evaluation

The accounts and roles granted to every user must be re-evaluated at regular intervals
and at least annually.

Rationale
It is important to check whether the existing account and role management process is
working properly and to correct any findings.

2.9 Role review process

For each organisation a process must exist that ensures significant changes to duties are
reported and relevant accounts and roles are reviewed and approved.

Rationale
When changes occur in the organisation or individual responsibilities accounts may
accumulate more access rights then required. Notifications of role changes must be done
promptly and initiate an update.

Latest update: 30.11.2016 Company Confidential

adidas Group - Global Policy Manual Page 3 of 9
GIT-28 Access Control Date effective: July 2016
Approved: Michael Vögele, CIO

2.10 Inactive accounts

All user accounts need to be checked on a monthly basis to deactivate those accounts not
used for more than 90 days.

Rationale
Existence of inactive accounts allows an unauthorized user exploit the unused account to
potentially access non-public data.

2.11 Account Termination

All adidas-Group information systems accounts must be promptly terminated when a user
leaves the company and reviewed and updated when a role change occurred.

Rationale
User accounts that are not needed anymore must be promptly terminated because they
can be easily misused.

2.12 Allocation of password

The allocation of passwords must be thoroughly controlled. Password settings and use
must adhere to strict standards.

Rationale
Passwords help ensure that people do not access systems or applications unless they
have been authorized to do so. Strong passwords prevent malicious access.

2.13 Password changes and resets

Password changes and resets must be initiated only by the affected user. Under no
circumstances may a user delegate or otherwise request that another person handle this
task on the user's behalf.

Rationale
Delegating password resets to another person could result into that person knowing
another account and passwords which they could use to gain access to systems of another
user.

2.14 New or replacement password

Any issue of a new or replacement password will only be made by authorised
administrative personnel and ensures authenticating the user’s identity.

Rationale
Many malicious individuals use "social engineering” (e.g. calling a help desk and acting as
a legitimate user) to have a password changed so they can utilize a user account.

2.15 Initial passwords

Initial passwords assigned during password resets must have a unique value for each
user.

Latest update: 30.11.2016 Company Confidential

adidas Group - Global Policy Manual Page 4 of 9
GIT-28 Access Control Date effective: July 2016
Approved: Michael Vögele, CIO

Rationale
If the same password is used for every new user set up, an internal user, former
employee, or malicious individual may know or easily discover this password, and use it to
gain access to accounts.

2.16 Initial passwords communications channel

The initial passwords must be sent through a communications channel other than the
channel used to log on to adidas Group systems.

Rationale
This is to ensure that passwords are sent only to right person.

2.17 Password compromise

Passwords must be kept private, i.e. not shared, coded into programs, or written down. IT
Security must be informed in the event of a password suspected to be shared or
compromised.

Rationale
If passwords are shared the account could be used by others in the user’s absence,
resulting in unauthorized account access and/or account misuse. Timely notifications will
ensure that a proper response can be initiated to revoke the password and to ensure the
systems security.

2.18 Password first-use

Systems are required to force a password change at first use of an account. Initial
passwords must have a unique value.

Rationale
If the same password is used multiple times, a malicious individual may know or easily
discover this password, and use it to gain access to accounts.

2.19 Password duration

All user and administrative account passwords must be configured to change at least
every 90 days.

Rationale
The longer passwords are used the more they are at risk of being disclosed or discovered.

2.20 Password attempts and lockout

All systems and applications must be configured to permit twenty-five attempts to enter a
correct password; otherwise the user account is disabled or locked for a period of 10
minutes.

Latest update: 30.11.2016 Company Confidential

adidas Group - Global Policy Manual Page 5 of 9
GIT-28 Access Control Date effective: July 2016
Approved: Michael Vögele, CIO

Rationale
If an account is locked out due to someone continually trying to guess a password,
controls to delay reactivation of these locked accounts stops the malicious individual from
continually guessing the password.

2.21 Password history

All systems and applications must be configured to not allow a user to set a password to
the same as the previous twenty-four passwords.

Rationale
If passwords are reused the more they are at risk of being disclosed or discovered.

2.22 Inactive sessions

If a session has been inactive for more than 15 minutes it must be locked. The user must
re-authenticate to re-activate the session.

Rationale
When users walk away from an open machine with access to critical network or non-
public data, that machine may be used by others in the user’s absence, resulting in
unauthorized account access and/or account misuse.

2.23 Password complexity and length

All passwords must be at least eight characters long and must contain at least 3 of the
following character types: Upper case, lower case, numeric, special character.
For B2C accounts passwords must have at least 8 characters with at least 1 lower, 1
upper character and 1 number (users must be allowed to add special and/or additional
characters if they choose).

Rationale
If passwords are short a malicious individual could easily compromise weak accounts and
gain access to systems under the guise of a valid user account.

2.24 Encryption
All passwords must be encrypted using strong cryptography during transmission and
storage on all systems.

Rationale
A malicious individual can easily intercept unencrypted password during transmission or
directly access the user IDs and unencrypted passwords in files where they are stored,
and use this stolen data to gain unauthorized access.

2.25 Non-adidas accounts

Do not use the same password for adidas-Group accounts as for other non-adidas
accounts (e.g. private email account, Facebook, twitter).

Latest update: 30.11.2016 Company Confidential

adidas Group - Global Policy Manual Page 6 of 9
GIT-28 Access Control Date effective: July 2016
Approved: Michael Vögele, CIO

Rationale
Personal accounts may be less protected and easily compromised by and malicious
person that could use the information to gain access to adidas Group systems.

2.26 Remember Password

Do not use the "Remember Password", "Remember me", or similar features of
applications (e.g., Outlook, Internet Explorer, Facebook).

Rationale
In case this feature has been chosen and a virus infects the system, the virus will look for
saved password files within the application.

2.27 Two-factor authentication

Two-factor authentication is required for all remote network access (access originating
from outside the adidas-Group or from untrusted networks).

Rationale
Two-factor authentication provides improved security for higher-risk accesses, such as
those originating from outside the adidas-Group network.

2.28 Remote service access

Remote-access for vendors requires approval on a case by case basis and must follow the
change management process. Activities must be monitored and the access must be
immediately deactivated after use.

Rationale
Allowing vendors (i.e. POS vendors) access into a system for support increases the
chances of unauthorized access. Therefore it is necessary to approve it and ensure that
the time period is as small as possible.

Latest update: 30.11.2016 Company Confidential

adidas Group - Global Policy Manual Page 7 of 9
GIT-28 Access Control Date effective: July 2016
Approved: Michael Vögele, CIO

3 Further Information
3.1 Change History
Description of changes to previous versions / releases in table form:

Version/release Date Changes

1.3.1 30.11.2016 Reviewed and signed, CIO

1.3.0 06.07.2016 Change of the rule “2.20. Password attempts and lockout”
and “2.21. Password history”

1.2.0 30.12.2015 Change of the rule “2.23. Password complexity and length”
to allow more consumer-friendly passwords.

1.1.0 22.06.2015 Increased password complexity requirements for rule 2.23.

Password complexity and length

1.0.0 26.03.2014 Initial version of the policy

Format & Meaning: [version].[subversion].[release]

Version: substantive new content
e.g. additional rule; fundamentally changed subject
Subversion: enhancements in content
e.g. improved explanation; clarification in environment
Release editorial corrections and reviews without significant change
e.g. typos, wording
especially annual reviews that are approved without changes.

4 References
N/A.

Latest update: 30.11.2016 Company Confidential

adidas Group - Global Policy Manual Page 8 of 9
GIT-28 Access Control Date effective: July 2016
Approved: Michael Vögele, CIO

Approval

location date Signature Michael Vögele, CIO

Latest update: 30.11.2016 Company Confidential

adidas Group - Global Policy Manual Page 9 of 9