GLOBAL CORPORATE POLICY

INFORMATION SECURITY

Global Software Development Security

Policy
Information Security

Prepared by: Kerry Brine

Management Team: Corporate Information Security

Classification: Internal Use

Date Prepared: 21 Feb 2020 Version: 1.2 Approved

Page 1 of 8 Internal Use

GLOBAL CORPORATE POLICY
INFORMATION SECURITY

Contents

1. Document Information ................................................................................................................................. 3

1.1. Document Change History................................................................................................................... 3
1.2. Document Approval Matrix.................................................................................................................. 3
2. Overview ........................................................................................................................................................ 4
3. Purpose ........................................................................................................................................................... 4
4. Scope .............................................................................................................................................................. 4
5. Policy ............................................................................................................................................................... 5
6. Governance .................................................................................................................................................. 8
7. Non-Compliance .......................................................................................................................................... 8

Page 2 of 8 Internal Use

GLOBAL CORPORATE POLICY
INFORMATION SECURITY

1. Document Information
1.1. Document Change History

DATE VERSION NUMBER AUTHOR(S) REVISION NOTES SECTION ID EDITED

2 May 2018 1 Kerry Brine First Draft

14 February 1.1 Kerry Brine Formal Approval Headers
2019
14 February 1.2 Mike Craigue/Kerry Specifically include Scope, 5e/K. Other minor
2020 Brine third parties in clarifications
scope.
Require 3rd parties to
validate code is
secure 5e./K.
Reference to OWASP

1.2. Document Approval Matrix

NAME ROLE SIGNATURE DATE

Dirk Maxwell Chief Information Security Officer 21 February 2020

Michael Brooks Chief Information Officer 21 February 2020

Kerry Brine Sr. Dir. Security Assurance 21 February 2020

Page 3 of 8 Internal Use

GLOBAL CORPORATE POLICY
INFORMATION SECURITY

2. Overview
Custom software is an integral part of business operations at LKQ that supports business activities such
as ERP and eCommerce operations. To protect confidential and business proprietary information
managed within these systems it is necessary to ensure security is an integral part of the software
development and customization process.

3. Purpose
This policy aims to ensure that security is an integral part of the development process for all bespoke
software and establishes required security controls, best practices and safeguards to be
implemented to achieve this goal.

4. Scope
This policy applies to all employees, systems and information of LKQ corporation, its subsidiaries and
affiliate companies as well as any third parties, contractors, business partners or service providers that
may have access to LKQ information or systems.

This Policy applies to information stored, transmitted or processed by LKQ including; Hardcopy
documents, Electronic data, Software, Hardware, Storage media and Communications networks
whether supplied by LKQ its partners or vendors.

Any references to LKQ also includes LKQ subsidiary companies or other operating companies within
the LKQ Global Group (regardless of the local operating name). This policy applies to all software
development, application customization, inclusion of open source libraries and software developed
by LKQ or through contracted third parties. It does not apply to commercial off the shelf software
(COTS) however any customization or modification of COTS is in scope of this policy.

Page 4 of 8 Internal Use

GLOBAL CORPORATE POLICY
INFORMATION SECURITY

5. Policy
a. During the software development lifecycle, the requirements for security shall be identified
and implemented at all stages, from project initiation, during project management, design,
build, test, implementation and maintenance. The policy applies whether the software is built
in-house or developed by a third party on behalf of LKQ.
b. Security requirements shall be identified and documented during design and shall take
account of all LKQ security policies.
c. Software development projects that involve the storage or processing of personal information
or applications that will be exposed publicly shall include a compliance workstream to
address privacy and security requirements. This workstream will identify whether there are any
additional controls that are required, above the baseline controls identified in this policy.
d. Security requirements identified as key areas in the design phase shall be included in the test
plan. Appropriate security testing shall be performed, based on the potential impact of the
security controls being breached. Testing shall not be restricted to tests that assume that a
user or attacker would never attempt something; i.e. not only testing that things work (positive
testing), but also testing to see what happens when unexpected input or actions are
undertaken (negative testing).
e. Software developed by third parties, contracted to LKQ for the development, shall be held
responsible for their own code security and quality assurance prior to delivery to LKQ. This may
include quality check such as static code security scans, dynamic code security scans and
threat modeling of the data flows for their systems as agreed.
f. Software development shall be undertaken in a secure physical location.
g. Software development shall take place on a secure IT infrastructure with appropriate network
and server security in place, including all approved security patches (including applications
whether LKQ developed or supplied by third parties, development tools and database
environments) and malware protection
h. Development, test and production environments shall be physically or logically separated.
i. Separation of duties between development, test and production shall be implemented.
Where resource structures prevent different persons performing these roles, the principal of
accountability shall be preserved by allocating different UserIDs to one individual for each
defined function. Use of the correct ID for the correct function shall be enforced.
j. The software development process shall establish requirements to meet any other applicable
legislative, regulatory and industry schemes (such as GDPR, PCI, HIPAA, SOX).
k. The software development process shall also consider additional controls in proportion to
identified risk through a risk assessment process that considers requirements such as;

• Logging, auditing and anti-fraud controls

• Protection of sensitive data including use of encryption, separation of sensitive data from
non-sensitive data, truncation, masking, non-storage, pseudonymization or hashing
• Vulnerabilities in the operating system or application layer discovered via
I. source code / static analysis scans during development
II. operating system scans at any step of the systems lifecycle
III. dynamic code scans after code complete or periodically after launch
Page 5 of 8 Internal Use
GLOBAL CORPORATE POLICY
INFORMATION SECURITY

IV. Administration processes including password resets and authorization

• Access control requirements including the principle of least privilege, separation of duties
and creation of role based access rules
• Need for file integrity monitoring
• Risk mitigation controls if vendor support is required
• Backup and recovery
• Integrity needs including message authentication and repudiation
• Need for peer or independent code reviews and/or static code analysis.
l. No confidential production data, such as credit card numbers, may be used in testing or
development. Test and development environments shall utilize data sets that have been
stripped of confidential or customer identifiable information. Test data shall comply with local
data protection or privacy legislation.
m. The test environment shall be a separate environment designed to closely resemble the actual
production environment. All testing shall be completed and high-risk issues resolved before
the code can be approved for migration to production.
n. The project shall identify whether it is appropriate (for instance PCI compliance) to review
custom code prior to release to production or to customers to help identify any potential
coding vulnerability. The review shall be carried out by a different developer to the builder
and can either be undertaken manually or using approved tools.
o. All test data and configurations, including custom user accounts, passwords and vendor
defaults shall be removed prior to promoting code to production.
p. All appropriate security patches must be applied to the system prior to migration of the
software and all infrastructure shall have a clean vulnerability scan.
q. All aspects of logging and auditing shall be documented and undertaken from the
implementation date.
r. There shall be an audit log of the movement of software packages between environments.
The movement of packages can only be performed from nominated accounts following an
approval.
s. Any vendor activity shall be authorized via change control and monitored and logged whilst
accessing their product on LKQ's systems.
t. Support staff, whether LKQ or third party, shall have the minimum of access rights/privileges
necessary to resolve current issues, with only restricted access to live data when necessary.
Once the problem has been resolved access rights shall be withdrawn and the password
changed. Activity shall be logged and reviewed by management to ensure that only
appropriate actions were undertaken.
u. Application layer penetration testing shall be considered for external facing applications and
the decision recorded within the projects compliance workstream and security plan.
v. All development staff shall be appropriately trained in industry best practice development
methods, secure coding and testing to ensure that security is incorporated throughout the
software development life cycle and that coding vulnerabilities are not introduced. They shall
understand legal, regulatory and industry scheme (e.g. PCI) requirements that impact their
role.

Page 6 of 8 Internal Use

GLOBAL CORPORATE POLICY
INFORMATION SECURITY

w. Development staff shall be encouraged to maintain their security knowledge through access
to appropriate resources providing assistance and information about developing secure
applications.
x. All web applications shall utilize secure coding guidelines such as the Open Web Application
Security Project guidelines (http://www.owasp.org), particularly the latest Top 10 vulnerability
list.
y. Design, build and test phases shall prevent the creation of common coding vulnerabilities
during software development or maintenance. These include the following:

• Unvalidated input
• Broken access control (for example, malicious use of user IDs)
• Broken authentication and session management (use of account credentials and session
cookies)
• Cross-site scripting (XSS) attacks
• Buffer overflows
• Injection flaws (for example, structured query language (SQL) injection)
• Improper error handling
• Insecure storage
• Denial of service
• Insecure configuration management

Page 7 of 8 Internal Use

GLOBAL CORPORATE POLICY
INFORMATION SECURITY

6. Governance
Any deviation from this policy requires prior written approval by LKQ’s Global CIO and LKQ’s Global
CISO. The following documentation must be submitted by a business unit or subsidiary IT leader or
regional IT leader when requesting any deviation from policy:
• Written approval from business unit (or subsidiary) IT leader and regional IT leader.
• A full written explanation regarding why the policy requirements cannot be met.
• A detailed risk mitigation strategy that will be in place until the compliance is achieved.
• A detailed remediation plan with named resourcing and committed milestones.

LKQ Global Chief Information Security Officer and designees have the right to conduct independent
assessments and take any other steps necessary to measure or otherwise validate compliance with
this policy. Each subsidiary of LKQ Corporation is required to fully cooperate with any such activities
including but not limited to providing access and credentials where needed and providing any
needed assistance.

7. Non-Compliance
Policy violations will be subject to disciplinary action, up to and including termination of employment,
subject to local laws.

Page 8 of 8 Internal Use