Methoden und Organisation zur Risikoerkennung

1
Methoden und Organisation zur Risikoerkennung
Thomas Kohler, UBS AG - Information Risk Control
UBS-GWMBB June 2006
2
Physical Security
3
Hacking / Phishing

• Bild Hacking

4
SPAM
5
Business as Usual
6
Agenda

• From processes
• UBS - Group IT Risk Control reporting structure
• Sarbanes Oxley Act 2002
• The Operational Risk Framework and ORA and the
  ORAP process
• Core IT applications, end user applications
• to practical means .
• Application of the legal regulatory framework
  incl. SOX
• ISF (and derivative) used for self certification
• OR control documentation
• Impact of the legal regulatory framework on
  selected projects

7
UBS - Group IT Risk Control Structure
Group Chief Risk Officer Walter Stuerzinger
Group Head Operational Risk
IB ORC
Global WMBBCRO
Global AMCRO
Corporate Center
Business Groups
Group Head IT Risk Control
Global WMBBIT Risk Control
IBIT Risk Control
Global AMIT Risk Control
Group Head IT Risk Mgmt
Global WMBB IT Risk Mgmt
IBIT Risk Mgmt
Global AM IT Risk Mgmt
8
Sarbanes-Oxley Act 2002 - Table of Contents

• A broad accounting, disclosure, corporate
  governance and ethics reform measure intended to
  address shortcomings in US federal laws after
  Enron and other corporate accounting scandals
• Enacted July 30, 2002 some provisions effective
  immediately upon enactment others upon adoption
  of SEC rules
• Applies to SEC-registered companies, including
  non-US companies such as UBS listed on the NYSE
  or NASDAQ or otherwise required to file an annual
  report on Form 20-F. Imposes substantive
  corporate governance requirements (as well as
  disclosure requirements) on foreign and private
  issuers
• Accounting oversight provisions apply to non-US
  accounting firms that audit SEC-registered
  companies

9
The Operational Risk Framework - Overview
Governance
External - Basel II - SOX 404 - Other
Internal - OREX - Training - Other
Policies Standards
ORF
Response
Data Collection
Controlling
ORAP
ORAP
Evaluation
Reporting
ORI
ORI Operational Risk Inventory
ORAP
ORAP
Identification
10
OR Control Documentation - Where?

• All OR Control Documentation (except Metrics) may
  be viewed by any employee in the Bank via the ORA
  Editor Tool.

11
Core IT Applications / End-User Applications
Definition

• Core IT Applications
• Core IT applications are those Bank provided and
  maintained IT applications in SOX-significant UBS
  entities that reside on the Banks mainframe or
  distributed server IT infrastructure.
• Examples of typical core applications would be
  GCRS, GEAR, GLS, etc., just to name a few.
• End-User Application (EUA)
• End-User Applications are located on a users
  desktop computer (not the Banks mainframe or
  distributed server infrastructure) and are
  manipulated and maintained by the end user, i.e.
  spreadsheets.
• EUA may be an integral part of a business or
  financial process.
• They may be used for uploading data and
  performing complex calculations or for processing
  non-routine financial transactions. Such EUAs do
  not operate under the same control environment as
  core IT applications, since they are often used
  to meet financial reporting needs without the
  direct involvement of the IT function.

12
Legal Regulatory Framework
Data Protection Act
Data Protection Act
SOX
Client Information
Employee Information
Business Information
13

• Not-for-profit association
• Widely recognised as being the dominant force in
  Information Security
• Incepted 1989

Engineering, manufacturing mining 43 Financial
services and insurance 90 Transport
11 Chemicals, healthcare, pharmaceuticals 28 Telec
ommunications and post 26 Utilities and
government 21 Suppliers of consultancy and
services 30 Retail and lottery 7
TOTAL
256
E-mail info_at_securityforum.org Web
www.securityforum.org The Standard of Good
Practice (complimentary download)
www.isfsecuritystandard.com
14
OR Control Documentation Basic Elements

• The Operational Risk Framework requires the
  existence of comprehensive underlying Control
  Documentation, designed to ensure that the Banks
  processes operate correctly and effectively. The
  Operational Risk Control Documentation
  encompasses the following

Roles Responsibilities
Control Objectives
Explanatory Notes
Control Standards
Metrics
15
OR Control Documentation Example

• Roles and Responsibilities
• A shortlist of distinct tasks for which a
  function is responsible
• Example
• Information Technology - System Managers System
  Manager has the responsibility to ensure the
  secure operation and administration of a given
  system. Regarding information security, he has to
  authorize requests for privileged access to
  specific systems and he has to implement,
  maintain and document appropriate security
  measures for each information system. He has to
  document suitable IT contingency plans and he
  also has to ensure that critical or sensitive
  business information and processing facilities
  are to be located in secure and protected areas.
• Control Objectives
• Derived from identifying "what could go wrong"
  within a Role Responsibility
• Provide a brief description ensuring that the
  Operational Risks within any given Role
  Responsibility are identified and addressed
  through the application of specific controls.
• Example
• Capacity and Performance Management
• To achieve the required service level (with
  respect to availability, response time, execution
  time, and stability) by assuring that, at all
  times, sufficient IT resources (CPU power and
  main memory, disk and tape capacity, network
  bandwidth, I/O bandwidth) are available to all
  systems that support business operations. This
  includes spare resources to cover unforeseen
  application growth as well as losses in case of
  hardware failures and disaster situations as
  defined in the service level agreement.

16
OR Control Documentation Example (con't)

• Explanatory Notes
• Where necessary, attached to Control Objectives.
• Provide context as to why a given Control
  Objective is deemed to be necessary for
  addressing a specific Operational Risk.
• Indicate how Controls relate to underlying
  transaction processes.
• Example
• Capacity management is responsible for
  calculating the IT resources that are necessary
  in order to deliver the IT service levels agreed
  by service management with the IT Customer. It
  supports the software development teams in the
  design and engineering phase in order to use IT
  resources efficiently. Capacity management plans
  and manages all IT resources including CPU power,
  disk and tape capacity as well as network
  capacity. Performance management provides
  capacity management with actual performance and
  utilisation figures in order to adjust their
  planning task and enable recalculation for IT
  services in operation. All business critical
  applications are monitored end-to-end and trend
  analysis is conducted in order to detect
  potential resource shortages at all times. The
  definition and approval of standardised hardware
  models (hardware vendor selection, security
  approval of hardware and base software) is dealt
  with in section 2.2 Supply Management. Capacity
  management only defines the need for resources
  supply management does the actual purchasing.
  Furthermore, storage management (assignment of
  application objects, such as database files to
  available resources (e.g. disk space) is not a
  capacity management issue and is dealt with in
  section 1.2 Data Backup and Recovery.

17
OR Control Documentation Example (con't)

• Control Standards
• Specific expectations that should be met in the
  performance of a functions' activities with
  regard to Operational Risk Control.
• Represent the actions required in order to
  address the risks identified in the Control
  Objective.
• Example
• Does the SLA specifically define the
  requirements for recoverability testing? Is
  recoverability testing performed in accordance
  with the SLA?
• Metrics
• Supplement the self certification process by
  measuring the quality of controls that have been
  performed.
• Indicate when Operational Risk levels may be
  deviating from the intended risk limit.
• Example
• Metrics Name SLA shortfalls regarding core IT
  applications
• Metrics Description Number of cases where the
  availability SLA target for the core IT
  applications cannot be met in relation to the
  number of TOP IT Services
• Calculation Percentage Average of (Numbers of
  SLA shortfalls per week /Methodology Number of
  controlled services/applications)
• Threshold green lt4 amber 4-5 red gt 5
• Metrics Type Quantitative
• Frequency Quarterly

18
International Remote Support
19
AD Design
Administration Console Provisioning System
UBSGroup.NET
20
Zentralisation vs. Localisation

Local IT

• Implementation and Application Mgmt of - Core
  Banking system
• - Front-end
• - Data Warehouse- Portfolio Management- All
  local applications
• Infrastructure Mgmt
• - Servers- Desktops- USC- Virus protection-
  HW- / SW maintenance- Incident Mgmt
• - Technical Support (1,2,3)- Delivery

localise
Local IT


localise
Central IT
central
IT Data Centre Ops
Competence Centre
CC
central


Olympic


Foton
GIM II MAP
DWH
PM
21
Conclusions

• Backup

Some days spent with laws and regs can easily
save you more days somewhere else!