why good technology is necessary, but not sufficient · why good technology is necessary, but not...
TRANSCRIPT
Why Good Technology is Necessary, but not Sufficient Information security in context
IT Risk & Assurance
Mårten Trolin, PhD, CISA
15 November 2012
2
““It is so much easier to use the same account for everyone.”
“It is too expensive to build a separate test environment.”
“You know, that doesn’t apply to me, because…”
“To save time, we copy the access rights of an existing user.”
3
Contents
2 Information Security in practice - How to build secure systems from good components
3 Real-life examples and discussion
1 Who are we
4
We are a global knowledge-company with local ties
Approximately 2000 employees with some 70 offices in Sweden
163,000 employees in more than 140 countries around the globe
5
Four main business areas
Assurance Audit, qualified accounting
issues and accounting
Advisory services Risk management and business
development
Transaction
advisory services Transaction advice
Tax Tax advice
IT Risk & Assurance
6
About Ernst & Young IT Risk and Assurance
IT Assurance IT Controls IT Risk Transformation
►Evaluation of global client
regarding IT management
and risks
►Control evaluation of large
telecom operator
►Risk assessment of
governmental clients
administrative service
►Assessment of current
and support for new
control framework at large
bank
►Internal audit of IT
controls at large global
automotive manufacturer
►Construction of
intellectual property
control system at a global
IT-company
►IT outsourcing program
for large global IT-
organization
7
Contents
3 Real-life examples and discussion
Who are we
2 Information Security in practice - How to build secure systems from good components
1
8
Information Security Process
Define
Goals
Identification
of Risks
Identification
of Controls
Design
Evaluation of
Controls
Operational
Evaluation of
Controls
► Overview
► Case example
9
Information Security Process Overview
► Important to have clear understanding of the context and completeness of the IT
security
► Understanding of context
► Break-down approach to ensure completeness
► Having understand context of IT security gain understanding of all included elements
► Example:
► Even though network security is top-notch
► Servers considered the most secure on market
► Security settings are near perfect
► One access administrator who does not control authorization of new user requests
10
Information Security process
► Major international chemical producer
► Based from the EU, with international operations
spanning the globe
► Publicly traded on two stock exchanges (NYSE
and LSE)
► Numerous accounts of both suppliers and
customers
► Annual net sales of around €9 billion
► Major IT systems supporting purchasing,
production, logistics, finance, accounting, HR,
customer etc.
► Situation
► Leakage of sensitive financial information
► Used to trade with LaChem’s stock right before
publication of yearly financial report
► No economic loss for LaChem, but major loss for
some of the major stock owners
► Loss of credibility for LaChem’s operations
LaChem corporation
► Phase 1: Review of IT security status as
LaChem
► Phase 2: Consult and aid in construction of
new policies, processes and controls for IT
security at LaChem
Ernst & Young’s assignment
11
Information Security Process
Define
Goals
Identification
of Risks
Identification
of Controls
Design
Evaluation of
Controls
Operational
Evaluation of
Controls
12
Information Security Goals
► Has the company a clear information security objective?
► Is the objective reasonable?
► Does the company work towards the objective?
► Organization
► Technology
13
IT Security Goals -LaChem
► Has the company a clear information security objective?
► “We need to protect internal information as leakages can result in
damaging our market position, customer trust and stock value”
► Is the objective reasonable?
► ?
► Does the company work towards the objective?
► Examine the organization
► Contact client
► Examine available Information Technology
► If relevant/necessary, contact third party suppliers of IT systems
14
IT Security Process
Define
Goals
Identification
of Risks
Identification
of Controls
Design
Evaluation of
Controls
Operational
Evaluation of
controls
15
Identification of Risks
► Identify high risk areas and (financial) systems, possibly together with financial auditors
or the client
► Assess possible risks
► Set audit scope
► Technical review
► Governance review
► Process review
► Legal compliance review
16
Identification of Risks -LaChem
► Identify high risk areas and (financial) systems, possibly together with financial auditors
or the client
► Sensitive information leakages
► Financial reports
► Sales figures
► Customer, client, supplier information
► Assess possible risks
► Risk of leakages
► Impact of leakages
► Set audit scope
► Technical review – include LaChem’s information systems in review?
► Governance review – should the governance of LaChem’s information systems be included?
► Process review - are LaChem’s information security processes to be included?
► Legal compliance review – is there added benefit of reviewing legal compliance of LaChem’s
IT systems?
17
IT Security Process
Define
Goals
Identification
of Risks
Identification
of Controls
Design
Evaluation of
Controls
Operational
Evaluation of
controls
18
Identification of Controls -What controls are in place
► Which processes are critical?
► How are they controlled?
► How is the audit team going to evaluate these controls?
► Which systems and applications are critical?
► How are they controlled?
► How is the audit team going to evaluate these controls?
19
Identification of Controls -LaChem
► Which processes are critical?
► Information security policy and compliance
► Privileged access management
► Application change processes
► …
► Which systems and applications are critical?
► Financial reporting system information security
► General and specific security settings
► IT Infrastructure
► …
► Concepta is the main financial reporting tool used at LaChem
► Consolidation tool for local entities
► One responsible manager
► Central team of administrators, local reporters at all major LaChem sites
► Governed by LaChem’s general policies
► Change Management, IT Security, Information Security…
► In-house constructed reporting system from the 1980’s
► Using third party tool to evaluate and present information
► In-house unit responsible for servers and databases
20
Evaluation of Controls -Research and documentation
User …
User …
User …
User…
User…
Concepta
Application
Server
Concepta
Application
Database
Planning
Application
Server
Planning
Application
Webserver
Presentation
Application
Server Presentation
Application
Publisher
Data
summation
Appliaction
Server/DB
User…
User …
User …
User …
User …
User …
User …
User …
User …
User …
User …
User …
User …
User …
User Denmark
User Norway
User Sweden
Oth
er
inte
rface L
ogin
Microsoft
NAV
local country
db
Microsoft
NAV
local country
db
Microsoft
NAV
local country
db Microsoft
NAV
local country
db
Microsoft
NAV
local country
db Microsoft
NAV
local country
db
Financial
Dataware
house
Planning
application
Database
Server
Win
dow
s L
og in
► In-house developed
application
► In-house managed
server / DB
► Third party supplied
application
► In-house managed
server / DB
► Managed in-
house
21
Information Security Process
Define
Goals
Identification
of Risks
Identification
of Controls
Design
Evaluation of
Controls
Operational
Evaluation of
Controls
22
Design Evaluation of Controls
► Understanding the design of the control of the following areas:
► Change Management ► Control objectives: Only authorized, tested and approved systems and program changes are
implemented in applications, interfaces, databases and operating systems.
► Logical Access ► Control objectives: Only authorized personnel have access to data and applications to carry out specific
functions.
► IT Operations ► Control objectives: Ensure that financial data and information is backed up and can be recomposed with
accuracy and completeness. Scheduled jobs are monitored and corrected in time. That incidents are
investigated and mitigated in a timely manner.
23
Design Evaluation of Controls
► Tasks
► Identify and contact responsible personnel
► Interview personnel working with system input and output
► Interview systems maintenance and development personnel (servers, DBs, OS & applications)
► Interview systems administrators
► If necessary contact (external) systems developer
24
Design Evaluation of Controls -Controls in processes at LaChem
► Identify and contact responsible personnel
► CFO, CIO, CSO
► Interview personnel working with system input and output
► Controllers, Auditors
► IT Managers, IT Security Managers
► Administrative, technical, operational IT personnel
► Interview systems maintenance and development personnel (servers, DBs, OS &
applications)
► IT Operations personnel contacted to for example control physical access, system resources
access, network/server/DB/OS controls
► Interview systems administrators
► Application owners/responsible contacted to gain deeper information of applications
► If necessary contact (external) systems developer
► Third party supplier of consolidation application contacted
25
Design Evaluation of Controls -Controls in processes at LaChem
► Change Management ► LaChem has effective controls with an exception in change management process – in-house
developers sometimes move their own changes into the live production environment
► Logical Access ► LaChem is lacking in their user access control process – lacking control of authorization,
lacking in routine privilege reviews, lacking in traceability of new and change of user acesses
► IT Operations ► LaChem has effective controls in the IT-operation control processes
26
Information Security Process
Define
Goals
Identification
of Risks
Identification
of Controls
Design
Evaluation of
Controls
Operational
Evaluation of
Controls
27
Operational Evaluation of Controls -Control of operations at LaChem - summary
► Walkthrough and test using the areas in scope
► For financial audits, the following three categories are covered:
► Manage Changes
► Logical Access
► IT Operations
► Test samples are taken for each area and reviewed
► If mistakes are detected, mitigating controls are investigated in order to evaluate the
risk
28
Operational Evaluation of Controls -Control of operations
► Tasks
► Obtain documentation regarding systems and processes in scope
► Organizational charts
► Network charts
► Systems interface charts
► Flows of data and transactions
► Changes and problems
► Process documentation
► IT policies
► Operational documentations – system logs, signed documents, authorization lists, personnel
lists etc.
► Risk analyses and continuity planning
29
Operational Evaluation of Controls -Control of operations at LaChem
► Change Management ► Control objectives: Only authorized, tested and approved systems and program changes are
implemented in applications, interfaces, databases and operating systems.
► LaChem are lacking in their Change management operations
► Lacking tests of changes
► Developers also test and/or put changes into the live production environment
► In-house application Concepta lacking in traceability of changes
30
Operational Evaluation of Controls -Control of operations at LaChem
► Logical Access ► Control objectives: Only authorized personnel have access to data and applications to carry
out specific functions.
► LaChem are lacking in their Logical Access operations
► No operational control of authorization
► No reviews of user accesses
► No documentation/traceability of new users or changes of user acesses
► Numerous accounts with privileged access, even though this might not be their job
31
Operational Evaluation of Controls -Control of operations at LaChem
► IT Operations ► Control objectives: Ensure that financial data and information is backed up and can be
recomposed with accuracy and completeness. Scheduled jobs are monitored and corrected in
time. That incidents are investigated and mitigated in a timely manner.
► LaChem approved
► Good control of access to system resources
► Good operational control of backups
32
Summary of the IT Security process
► Top-down approach
► Design can rule out details – most likely if a control design is not working, the
operational aspect of that control is not working
► LaChem evalutation summary:
Define
Goals
Identification
of Risks
Identification
of Controls
Design
Evaluation of
Controls
Operational
Evaluation of
controls
Area Design Operations
Change management
Logical access
IT operations
33
Contents
Real-life examples and discussion
Who are we
Information Security in practice - How to build secure systems from good components
1
3
2
34
Real-Life Examples
► Password in drawer or under keyboard
► Sensitive production data used in tests
► Firewall rules added arbitrarily
► Users not removed from system
after leaving the company
35
Lack of Formalized Procedures
“We don’t need to write this down”
“We are too busy to spend time writing papers”
“No-one would read it anyway”
36
Non-Compliance with Formal Procedures
“Are there rules?”
“The procedures are too complicated.”
“You know, that doesn’t apply to me, because…”
“No-one cares if we do it by the book or not.”
37
Lack of Segregation of Duties
“It is not a problem in our company, because…”
“Our IT department is too small”
“Why would we need that?”
38
Lack of Traceability
“It is so much easier to use the same account for everyone.”
“We log everything and store it a secure folder on the server.”
“We log everything, but we need to clear the log every week to
save disk space.”
“We usually log everything, but we had to turn it off last month.”
39
Lack of Test Procedures
“It is quite enough to test the new functions.”
“It is too expensive to build a separate test environment.”
“We just make sure to monitor the application carefully after
putting it into production.”
40
Lack of Good Access Management
“Paper-work for every user is just a waste of time.”
“It is the responsibility of the immediate supervisor to inform us
when privileges are to be removed.”
“To save time, we copy the access rights of an existing user.”
41
No Tests of Backup Tapes
“We don’t need to, because our system cannot produce invalid
backups.”
“We do it once every month, except that extraordinary
circumstances prevented us from testing the last three
months.”
“That is the responsibility of the XYZ department.”
42
Who Does the Job
► Specialized IT security personnel, CISO, CSO CIO etc. IT Security
Internal audit ► The organizations own internal audit (usually larger companies
and government authorities).
External audit ► As a part of the external audit
IT Personnel ► Non-specialized IT personnel (usually SMEs)
Consultants ► Performing a complete IT-audit or supporting above mentioned
parties in different ways
www.ey.com/se
The information contained within this document and any related oral presentation conducted by Ernst & Young AB (EY) contains proprietary information and may not be disclosed, used or duplicated - in whole or in part - for any purpose without the express written consent of EY.