Erm talking points

http://www.enterprisegrc.com
Aligning Enterprise & IT Risk Management
EnterpriseGRC Solutions Risk Management
and GRC Support Solution
Proposed ERM Solution to IT, CMO and SOX

 Review ERM Success Factors & Methodology
 Aligning Enterprise Risk and IT Risk
 Provide Overview of proposed ERM Methodology & Tools
 Suggest and confirm ERM Action Plan Development and
Monitoring
Objectives - Gaining team consensus on the recommended approach

Enterprise Risk Management - Definition
 A process, ongoing and flowing
 Effected by people at every level
 Applied with a strategy in a specific setting
 Applied across the enterprise
 at every level and unit, and
 includes taking an entity-level portfolio view
of risk
 Designed to identify potential events that, if
they occur, will affect the entity and to
manage risk within its risk appetite
 Able to provide reasonable assurance to an
entity’s management and board of directors
 Geared to achievement of objectives in one
or more separate but overlapping categories
Enterprise Risk Management — Integrated Framework
Executive Summary
Copyright © September 2004 by the Committee of
Sponsoring Organizations of the Treadway Commission.

 Risk Identification
 Business Risk Assessment
 Scope & Boundary Definition
 Risk Measurement
 Risk Action Plan
 Risk Acceptance
 Safeguard Selection
 Risk Assessment Commitment
Risk Management Components

What is the value of implementing ERM?
 Reduces operational expense through streamlined control
structures
 Identifies cross-enterprise risks
 Aligns risk appetite and corporate strategy
 Enhances efficient risk response and rapid consistent decisions
 Seizes opportunities to prevent loss, rather than repair loss
 Improves the deployment of capital
ERM helps management achieve the organization’s
performance and profitability targets.

Why Risk Management?
 Minimizing Likelihood of Material Loss Such As:
 Fraud, Critical System Failure, Political Damage, Missed Strategic
Milestones or Significant Loss of Revenue.
 Ensures Delivery of Risk Information To The Business
 Enables Business Decisions By Providing A Management Process
For Capturing, Analyzing, Mitigating and Monitoring Risks to the
Business
 Provide a Unified Management Process for Risk Response

 Methodology is simple and understood, with momentum across the
organization.
 The approach is proven and tested.
 ERM action plans are monitored and measurable, using management
processes already in place.
 ERM is clear, endorsed by leadership, and has a compelling business case
sustaining continuous corporate interest.
 ERM is customized to the organization’s culture, assuring buy in and
ultimate success.
Critical Success Factors For ERM

Our ERM Approach
BusinessTechnology
Phase I. Establish ERM
Infrastructure
• Define Enterprise Risk
Management within
organization
• Define Risk Management
vision
• Define common language
• Establish objectives and
ensure that they are
aligned with vision and
are consistent with the
level of risk appetite.
• Establish key control
objectives that ensure
integrity of systems to
their respective policies
over “data governance”
• Train and Involve Early
Adapters/ Enterprise
Managers in Risk
Management Program
Phase II. Assess Business
Risk
• Identify key risks
• Source risks-key risk
drivers
• Measure risks-Impact &
Likelihood
• Categorize risks
• COSO Objective
• SSL Goals
• Link risks to business
processes
• Identify risk owners
• Provide an accurate
service inventory,
including all business
enabling assets, their
configuration and current
operational state
• Identify GAPS in Security
and IT Policy
Phase III. Develop Risk
Response
• Develop risk management
strategies
• Incorporate the strategies
into formal action plans
• Monitor status of risk
responses
• Develop risk management
systems and tools to
support implementation
across the organization.
• Align Information Lifecycle
Management and Data
Governance Management
• Rank by impact and
likelihood, enterprise
service/ asset stability
• Identify policy variance
Phase IV. Implement &
Monitor Processes
• Define criteria to measure
the effectiveness of
mitigation actions
• If possible, evaluate the
effectiveness of mitigation
actions
• Report results to
management
• Ongoing incident
response optimization,
automation
• Ongoing Root Cause
analysis for threat and
vulnerability
• Weekly, Quarterly and
Executive Reporting over
all identified Corporate
and IT Risk
• Metrics for improvement
• Demonstrate Metrics in
terms of Business
Revenue value vs. IT Cost

Phase I. Establish ERM Infrastructure
ERM in SharePoint

Triggers &
Identified Risks
Inputs
Risk Mgmt
Process & Systems
Committee
Reports, KPI, KGI
Client Feedback
Audit
Implementations,
Meeting Minutes,
Risk Watch List,
Analysis, Schedules
Outputs
Risk Management The ISO 27000 Component View

Inputs to Business Risk Model
 A Business Risk Model is used to identify business risks
impacting the company as a whole, or any specific process or
operating unit within the company.
 For each risk, a supporting knowledge base includes the
following sections:
 Identify Consequences of Risk (describes what happens to the
organization if risk is realized)
 Measure Risk (examples of risk indicators and measures)
 Identify Root Causes of Risk (examples of why the risk may exist)

Business Risk Model (Big 4 Model)
EMPOWERMENT RISK
Authority/Limit Change Readiness
Communications Leadership
*Performance Incentives
INFORMATION PROCESSING/
TECHNOLOGY RISK
*Access *Availability *Data Integrity
*Infrastructure *Relevance
INTEGRITY RISK
*Employee Fraud *Product/Physical Security
Illegal Acts Management Fraud
Reputational Unauthorized Use
*Intellectual Property
OPERATIONS RISK
*Consolidation Process *Customer
Satisfaction/Service
Environmental *Inventory Conversion
*Obsolescence/Shrinkage/Waste
*Order to Delivery Cycle Time
*Pricing/Product Standardization
*Product Development *Production
Schedule *Revenue Cycle *Business
Interruption *Capacity
Efficiency/Maintenance Health and Safety
Human Resources *Performance/Quality
Measurement Sourcing
OPERATIONAL
*Pricing/Operational *Contract Commitment
*Performance/Quality Measurement
Alignment Completeness and Accuracy
FINANCIAL
*Budget and Planning *Completeness and
Accuracy *Accounting Information *Financial
Reporting Evaluation *Taxation *Investment
Evaluation *Regulatory Reporting
STRATEGIC
Environmental Scan Business Portfolio
*Valuation *Performance Measurement
Organizational Structure Resource
Allocation Planning Life Cycle
E N V I R O N M E N T R I S K
I N F O R M A T I O N F O R D E C I S I O N M A K I N G R I S K
P R O C E S S R I S K
*Competitor Catastrophic Loss
FINANCIAL RISK
Cash Flow
Collateral
Commodity
Concentration - Credit
Concentration - Liquidity
Currency
Equity
Financial Instrument
Interest Rate
Opportunity Cost
*Settlement/Default
Sensitivity Sovereign/Political Shareholder Relations Legal Regulatory Capital Availability *Industry
Restructuring

Business Model for Information Security - BMIS
Copyright
ISACA®

Key Roles & Responsibilities - Committee
 Chief Financial officer
 Security Manager
 Risk Management
Committee
 Risk Mitigation
Implementation
Owners
 Stakeholders & Users
…Everyone in an entity has some responsibility for enterprise risk
management. The chief executive officer is ultimately responsible
and should assume ownership. Other managers SUPPORT the
entity’s risk management philosophy, promote compliance with its
risk appetite, and manage risks within their spheres of
responsibility consistent with risk tolerances. A risk officer, financial
officer, internal auditor, and others usually have key SUPPORT
responsibilities. Other entity personnel are responsible for
executing enterprise risk management in accordance with
established directives and protocols. The board of directors
provides important oversight to enterprise risk management, and is
aware of and concurs with the entity’s risk appetite. A number of
external parties, such as customers, vendors, business partners,
external auditors, regulators, and financial analysts often provide
information useful in effecting enterprise risk management, but
they are not responsible for the effectiveness of, nor are they a part
of, the entity’s enterprise risk management.
Enterprise Risk Management — Integrated
Framework Executive Summary Copyright ©
September 2004 by the Committee of Sponsoring
organizations of the Treadway Commission.

Risk Management Process - Purpose and Scope
 Risk Response Takes Cost - Effective Measures To Mitigate Risks &
Considers:
 Risk Management Ownership & Accountability
 Different Kinds of IT Risks (Technology, Security, Continuity,
Regulatory, Etc.)
 Defined & Communicated Risk Tolerance Profile
 Root Cause Analyses & Risk Brainstorming Sessions
 Quantitative And / or Qualitative Risk Measurement
 Risk Assessment Methodology
 Risk Action Plan
 Timely Reassessment

 External Risks – Global and Economy
 Cost Risks
 Schedule Risks
 Technology Risks
 Operational Risks
 Legal and Regulatory Risks
 Market Risks
Corporate Risk

 Cost Risks: directly or indirectly under the project manager's control or within his or her
area of influence
 Cost overruns by project teams or subcontractors, vendors, and consultants
 Scope creep, expansion, and change that has not been managed
 Poor estimating or errors that result in unforeseen costs
 Overrun of budget and schedule
 Schedule Risks: can cause project failure by missing or delaying a market opportunity
for a product or service.
 Inaccurate estimating, resulting in errors
 Increased effort to solve technical, operational, and external problems
 Resource shortfalls, including staffing delays, insufficient resources, and unrealistic
expectations of assigned resources
 Unplanned resource assignment--loss of staff to other, higher priority projects
Project Risk

Enterprise IT Risk
 Problems with immature technology
 Use of the wrong tools
 Software that is untested or fails to work
properly , Requirement changes with no change
management
 Failure to understand or account for product
complexity
 Integration problems
 Software/hardware performance issues--poor
response times, bugs, errors
 Inadequate resolution of priorities or conflicts
 Failure to designate authority to key people
 Insufficient communication or lack of
communication plan ,
 Size of transaction volumes--too great or too
small
 Rollout and implementation risks--too much,
too soon
 Access Control Administration
 Firewall Policy Administration
 Security Incident Detection
 Security Incident Response
 Security Policy Awareness
 Data Backup
 Data Recovery
 Threat & Vulnerability Monitoring and
Management
 Virus Control
 Business disruption, inability of client to access
business services
 Business failure, inability of internal operations
to process any business process
 Increase in software licensing cost, or non
anticipated software licensing cost
 Increase in software licensing cost, or non
anticipated software licensing cost
 Increase in hardware related expense or non
anticipated hardware expense
 Hardware Software Integration or compatibility
issues
 Network/LAN availability including general and
secure access to file shares
 Personnel resource and availability, general
attendance by consultants and internal
employees
 Loss of key personnel due to illness, resignation
or reassignment
 Change in market impacting fiscal viability of
engagement
 Natural disaster such as flood or fire

Example (SAP) ERP Risk – Chapter 3 – ISACA’s Publication
 Project Management and Program Governance - The major concerns for ERP
implementations involve organizational issues rather than technological issues. This
section discusses the risks of and key controls for an ERP project, including:
 Organizational change management and training
 Planning and problem management
 Lack of executive sponsorship
 Reliance on third parties
 Project cost blowout
 Business Process Reengineering Risks - Reengineering of the business processes will
most likely result in structural and job role changes within the enterprise. Staff who
had worked within the legacy environment for an extended period of time may find it
difficult to adapt to new roles, and, as a result, certain business functions may not be
properly performed in the post-implementation environment. Also, there is a risk that
the reengineered business processes may not have been configured properly, resulting
in incorrect processing (e.g., incorrect tax indicators) or inadequate business controls
(e.g., three-way match on purchases being bypassed).

ERP Risk – Business Finance
 Distributed Computing Experience
Risks - Although it is sometimes
overlooked, the IT architecture may
be totally overhauled with the
implementation of ERP. The
enterprise may move from a
centralized mainframe environment
to a distributed client-server
environment. New skills are required
to manage and maintain this
environment, and the impact of this
change is often underestimated.
 Data Quality Risks
 Program Interface Risks

Extended Governance Risk Compliance (GRC)
RunBooks identify the
services and systems that
support critical business
transactions
Policy Mapping
is the foundation
of actionable,
auditable
control
Assessment Reviews Asset Class
CMDB alignment with policy and
standards
(such as the selected control
frameworks)
Risk Management iterates the gap between policy,
standards and business realities
Information Technology
Executive Management
Internal Audit reviews / selects controls
Determines area of greatest concern
Affirms effectiveness of Risk process
Risk
Assessment
RunBooks CMDB
Policy Process

Outputs of Risk Management Process
 The steps in the risk management process result to:
 Establish the context
 Identify the risks
 Analyze risks
 Evaluate risks
 Treat risks
 Monitor and review
 Communicate and consult

Phase II. Assess Business Risk
We Are HERE!

Phase II: Assess Business Risk
(Making Risk Visible and Accessible to Controls)
 Communicating Risk- Inputs and Agenda
 Execute – Program, Meetings, Risk Response
 Measure – Risk Measurement & Impact Analysis, Performance
 Record – Meeting Minutes, Management Reporting
 Archive – Meeting Minutes, KPI Results

Phase II. Assessing Business Risk - Our Tools and Deliverables

What is Significance?
 When is a something significant?
 What results occur when a risk is
significant?
 In what manner will significance
change?
 Which criteria were applied to the
interpretation of significance?
Phase II: Assess Business Risk Criteria
What is Likelihood?
 Likely
 Relative Likelihood
 Unlikely
 Never
What is Impact?
 Minor
 Major
 Catastrophic

Significance of Risk – Analyze the Risks - So What?
(Reference Slide)
 Risk analysis determines how often identified risks are likely to occur and the magnitude of
their consequences.
 The significance of risk is expressed as a combination of its consequence or impact on the
objectives of the project and the likelihood of those consequences occurring.
 Consequence and likelihood may be accounted for using a qualitative, semi-qualitative or
quantitative approach. The qualitative approach is most common and is briefly described
below.
 The likelihood criteria are expressed as a probability of the annual occurrence on a descriptive
scale from Rare to Almost certain. Consequences are rated in terms of the potential impact on
the key criteria (i.e. Performance, Cost, Schedule) identified during the context step. The
impact is then also described on a scale from insignificant to catastrophic.
 Significance as a scale of 1 to 5 in Likelihood factored against a scale of 1 to 5 in Impact.
 On a scale of 1 to 25, the organization can establish a criteria for action and a matrix of activity
that would meet that criteria.

Phase II Tool: Risk Heat Map
Likelihood
Significance
LowHigh
Low High

Phase III. Develop Risk Response
Responsibilities that must be adopted

 Key activities within this phase :
 Determine appropriate risk response considering the
appropriate management strategies
 Key Outputs
 Risk Management Action Plans

Avoid
• PROHIBIT
unacceptable high
risk activities,
transactions,
financial losses, and
asset exposures
through appropriate
limit structures and
corporate standards.
• STOP specific
activities by
redefining objectives,
refocusing strategies
or redirecting
resources.
• ELIMINATE at the
source by designing
and implementing
internal preventive
processes.
Accept and Control
• ACCEPT risk at its
present level taking
no further action.
• PLAN for well-defined
contingencies by
documenting a
responsive plan and
empowering people
to make decisions
and periodically test
and, if necessary,
execute the plan.
• CONTROL risk
through internal
processes that
reduce the likelihood
of events occurring to
an acceptable level.
Share
• SHARE risk/rewards
of investing in new
markets and
products by entering
into alliances or joint
ventures.
• CREATE new value-
adding products,
services and
channels.
• RENEGOTIATE
existing contractual
agreements to
reshape risk profile,
i.e. transfer or
reduce.

Phase III: We Collectively Define our Risk Appetite
 Risk management demonstrates a methodology and
criteria
 Risk management provides evidence of the criteria
behind our choices
How much risk is too
much?
Do we have a process
in place to defend
and justify our
choices?

Corporate Risk Management Tools address
 Corporate Level Review of Company Specific Risk
 Roll Up of Individual Company Risks,
 Assignment of Relative Risk Criteria
 Ownership of Communicated Risk To Both Shareholders And
Throughout The Corporate Enterprise.
 Governs How Corporate Leadership Interprets & Assigns Weighted
Value To Company Specific Risk & Impact
 Initial Risk Assessment & Accountability Rests At The Individual
Company Level
 Disclosure Committee Reviews & Determines Disclosure
Requirements

Risks and Response - Ongoing Risk Tracking
Respond
Report
Reduce

 Activity for assessing application & infrastructure risk
 Supports enterprise level concerns where situation left unchecked might result
in material loss:
 Examples: fraud, critical business enabling system failure, political damage, missed strategic
milestones or significant loss of revenue.
 Facilitates management decisions to achieve it security & control objectives
 Responds to threats by:
 Reducing complexity
 Increasing objectivity
 Identifying important decision factors
 Enabled by IT risk - identification & impact analysis
 Involves multi - disciplinary functions
Risk Management IT Process - Purpose and Scope

Technology Risk Tracking – by Service, Asset, Policy
 Technology Controls Map
 Report Classification
 Key Vs. Non Key
 Definition of Terms and Controls

Project Risk Management Purpose and Scope
 Facilitates The Effective Management of Risk Within An
Enterprise Project
 Enables Project Team To Collaborate In
 Identifying Risk, Analyzing Risk, And Planning Appropriate Actions.
 Risk-related Actions Are Planned, Scheduled And Tracked As
Additional Tasks In The Project Plan
 Risk Tracking Occurs In A Risk Watch List
 On-going Activity Throughout The Project
 Depends On All Project Team Members Being Risk-aware,
Utilizing The Defined Risk Management Process

Reflect and Report What We Need to Know

Phase IV. Implement and Monitor
Integrated Evidence for SOX, FDIC, ISO27000, SOC 2, ROC

CobiT Detail Objective – Matrix Aligned to Other Standards

 Management should establish A general risk assessment
approach which defines :
 Scope & boundaries,
 Methodology to be adopted for risk assessments,
 Responsibilities & the required skills.
 Management should lead the identification of the risk
mitigation solution & be involved in identifying
vulnerabilities.
 Security specialists should lead threat identification & it
specialists should drive the control selection.
 The quality of the risk assessments should be ensured by
a structured method & skilled risk assessors.
CobiT Detail Objective

Audit Velocity increases Maturity
 Approach: Find a flaw, fix
a flaw
 Approach: Find a lot of
flaws and keep a list
 Approach: align
vulnerability metrics into
a continual service
improvement model
48

Root Cause Analysis
 What is the root cause for any failure
 Example: “metrics indicate 80% of malicious code infections are
attributed to vulnerable versions of Java”
 What were the steps to create the finding?
 What are the expectations as a result of this finding?
 What is the measure of Security Program health?
49

Technical (one)
 Looking for security weaknesses
 Vulnerability Assessment
 Network Penetration Testing
 Web Application Penetration Testing
 Source Code Analysis
50

Vulnerability Assessment
 Scanning systems looking for a set of vulnerabilities
(a list)
 Looks for common and known vulnerabilities
 Uses a scanning tool
 Performed in house and by third party
Let’s look at common and recommended scanning tools.
Source is OWASPVulnerability Scanning Tools - OWASP
51

OWASP Listed Vulnerability Scanning Tools
Name Owner Licence Platforms
Acunetix WVS Acunetix Commercial / Free (Limited Capability) Windows
AppScan IBM Commercial Windows
AVDS Beyond Security Commercial / Free (Limited Capability) N/A
BugBlast Buguroo Offensive Security Commercial SaaS or On-Premises
Burp Suite PortSwiger Commercial / Free (Limited Capability) Most platforms supported
Contrast Contrast Security Commercial / Free (Limited Capability) SaaS or On-Premises
GamaScan GamaSec Commercial Windows
Grabber Romain Gaucher Open Source Python 2.4, BeautifulSoup and PyXML
Grendel-Scan David Byrne Open Source Windows, Linux and Macintosh
GoLismero GoLismero Team GPLv2.0 Windows, Linux and Macintosh
Hailstorm Cenzic Commercial Windows
IKare ITrust Commercial N/A
IndusGuard Web Indusface Commercial SaaS
N-Stealth N-Stalker Commercial Windows
Netsparker MavitunaSecurity Commercial Windows
Nexpose Rapid7 Commercial / Free (Limited Capability) Windows/Linux
Nikto CIRT Open Source Unix/Linux
52

What to do with a list of known vulnerabilities
 Scanners provide a score of 1 to 5 (relative to what?)
 CVSS Common Vulnerability Scoring System is method used to classify
 OCTAVE Operational Critical Threat, Asset, and Vulnerability Evaluation
 OCTAVE defines three phases, is criticized as complex and not providing
detailed quantitative analysis of security exposure.
Phase 1: Build
Asset-Based
Threat Profiles
Phase 2: Identify
Infrastructure
Vulnerabilities
Phase 3: Develop
Security Strategy
and Plans
54

Penetration Tests
 Red Team Exercises or Ethical Hacking – (Yes, I’m compelled to talk about blue
team, but not yet.)
 We know we have flaws - pen test seeks to exploit them
 Simulates attacker (does not cause harm)
 Output: Identification of susceptible assets (sites)
 In short: As good as the people who perform them and as valuable as the
reduced risk on the items that get remediated
A red team is an independent group that challenges an organization to improve its
effectiveness. The United States intelligence community (military and civilian) has red
teams that explore alternative futures and write articles as if they were foreign world
leaders.
Red team - Wikipedia, the free encyclopedia
55

Penetration Testing – Operations Evaluation
 War Dialing (looking for modems – especially plugged into older
enterprise hardware)
 Sniffing – Wireshark -Configuring a monitor port on a managed
switch - network tap
 Eavesdropping
 Radiation monitoring
 Dumpster diving
 Social Engineering
http://www.lawtechnologytoday.org/2015/03/information-security-threat-
social-engineering-and-the-human-element/
You typically insert a network tap inline between two nodes in a
network, such as between your firewall and your first switch. $$$
Not typically in audit budget
56

Security Process Review (two)
 Looking for weaknesses and vulnerabilities
Security Assessment Report
Deficient Security Posture
Technology
People
Process
57

Security Process
 Process is more than policy, although we start with
policy
 What are two great frameworks for establishing
necessary procedure and work product to show that
the processes are effective?
 Cobit5 and NIST Cybersecurity Framework
 http://www.nist.gov/cyberframework/upload/cybersec
urity-framework-021214.pdf
 National Institute of Standards and Technology, U.S.
Department of Commerce (Not copyrightable in the
United States.)
58

You Need to U Read
 International Organization for Standardization, Risk management – Principles and
guidelines, ISO 31000:2009, 2009.
http://www.iso.org/iso/home/standards/iso31000.htm
 International Organization for Standardization/International Electrotechnical
Commission, Information technology – Security techniques – Information security risk
management, ISO/IEC 27005:2011, 2011.
http://www.iso.org/iso/catalogue_detail?csnumber=56742
 Joint Task Force Transformation Initiative, Managing Information Security Risk:
Organization, Mission, and Information System View, NIST Special Publication 800-39,
March 2011. http://csrc.nist.gov/publications/nistpubs/800-39/SP800-39-final.pdf
 U.S. Department of Energy, Electricity Subsector Cybersecurity Risk Management
Process, DOE/OE-0003, May 2012.
http://energy.gov/sites/prod/files/Cybersecurity%20Risk%20Management%20Process
%20Guideline%20%20Final%20-%20May%202012.pdf
59

Download NIST Assessment Tool
http://www.nist.gov/cyberframework/csf_reference_tool.cf
m
60

U Need to Use: NIST Framework for Improving Critical
Infrastructure Cybersecurity; Annex A
61

Determine Alignment to ISMS and CobiT or ITGCC program
62

Cobit 5: Process Area Assessment
 APO12: Manage Risk, “Continually identify, assess and
reduce IT-related risk within levels of tolerance set by
enterprise executive management.”
 APO13: Manage Security, “Define, operate and
monitor a system for information security
management.”
 DSS05: Manage Security Services, “Protect enterprise
information to maintain the level of information
security risk acceptable to the enterprise in
accordance with the security policy. Establish and
maintain information security roles and access
privileges and perform security monitoring.”
63

Assessment (two) v. Audit (three)
 Security assessment is comprehensive review of
systems and applications performed by trained
security professionals (CISSP/ CCIE/ CCNA/ CISM)
 Security assessments normally include use of
testing tools and goes beyond automated scanning
 Involves thoughtful review of the threat
environment, current and future risk, and value
definition of the targeted environments
 The output of assessment is a report addressed to
management with recommendations in both
technical and non technical language
64

Auditing Security Assessment & Verification
 Compliance checks
 Internal and external
 Frequency of review
 Standard of due care
 Internal Audit typically performs assessment for
internal audience
 External Audits are performed for external investors
and as part of third party due diligence requirements
 Third Party review is emphasized to avoid “conflict of
interest”
65

Security Audit – Raising the right Bar
 Cloud Security Alliance Control Matrix – Cloud
Operational Security
 Controls Domain and Controls Matrix (98 Controls with
Mappings)
Value – architecture, portability and interoperability; physical,
network, compute, storage, applications, and data, differentiates
service provider versus tenants
 United States NIST Publication 200, NIST SP 800-54
rev4 – (mentioned earlier)
 PCI-DSS – The Payment Card Industry Data Standard
 Associated to credit card processing – however should be
true in general – 12 tenants
66

What are the “Related Metrics” from Manage Risk APO12
 Continually identify, assess
and reduce IT-related risk
within levels of tolerance
set by enterprise executive
management.
 Integrate the management
of IT-related enterprise risk
with overall ERM, and
balance the costs and
benefits of managing IT-
related enterprise risk.
 Related Metrics
 Degree of visibility and
recognition in the current
environment
 Number of loss events with
key characteristics captured
in repositories
 Percent of audits, events and
trends captured in
repositories
 Percent of key business
processes included in the risk
profile
 Completeness of attributes
and values in the risk profile
 Percent of risk management
proposals rejected due to
lack of consideration of other
related risk
 Number of significant
incidents not identified and
included in the risk
management portfolio
 Percent of IT risk action plans
executed as designed
 Number of measures not
reducing residual risk
*Align, Plan and Organize
67

What are the “Related Metrics” from Manage Security APO13
 Define, operate and
monitor a system for
information security
management.
 Keep the impact and
occurrence of
incidents within the
enterprise’s risk appetite
levels.
 Related Metrics
 Number of key security
roles clearly defined
 Number of security
related incidents
 Level of stakeholder
satisfaction with the
security plan throughout
the enterprise
solutions deviating from
the plan
solutions deviating from
the enterprise
architecture
 Number of services with
confirmed alignment to
the security plan
incidents caused by non-
adherence to the
security plan Number of
solutions developed
with confirmed
alignment to the security
plan
*Align, Plan and Organize
68

What are the “Related Metrics” from Manage Security Services DSS05
 Protect enterprise
information to maintain
the level of information
security risk acceptable to
the enterprise in
accordance with the
security policy. Establish
and maintain information
security roles and access
privileges and perform
security monitoring.
 Minimize the business
impact of operational
vulnerabilities and
incidents.
 Related Metrics
 Number of vulnerabilities
discovered
 Number of firewall
breaches
 Percent of individuals
receiving awareness
training relating to use of
endpoint devices
 Number of incidents
involving endpoint devices
 Number of unauthorized
devices detected on the
network or in the end-
user environment
 Average time between
change and update of
accounts
 Number of accounts (vs.
number of authorized
users/staff)
 Percent of periodic tests
of environmental security
devices
 Average rating for physical
security assessments
 Number of physical
security-related incidents
 Number of incidents
relating to unauthorized
access to information
* Deliver, Service and Support
69

Technical Security Testing (one)
Goal: assess risk by discovering flaws that persist in systems
and applications
 Technical testing is looking for security flaws, specifically impacts to
confidentiality, integrity or availability, ways to steal, alter or destroy
information
 Vulnerability Assessments are looking for weakness
 Penetration testing adds human factor
 Code review includes errors that make it susceptible, e.g. to buffer overflow,
SQL insertion, etc.
 Phishing is to see what users do when presented with typical malicious email
scenarios
 Password assessments evaluate password settings and practices, (sometimes as
a part of scanning)
70

Threat Vectors – Attack surface
 Methods attackers use to touch or exploit vulnerabilities
 A systems attack surface represents all of the ways in
which an attacker could attempt to introduce data to
exploit a vulnerability
 If you look at a list of vulnerabilities, you get too much
information, so we have to start by analyzing our network, our
data, evaluating our assets and their attack surface, then their
vulnerabilities to known threats
 One way to reduce risk is to minimize the attack vectors
 Once we know those vectors, we remediate prioritized threats
by reducing the likelihood of exploiting vulnerabilities
71

Shift in attack vectors:
Server Side v. Client Side Attacks
 Attacks against a listening service are called “Server-side
attacks”
 TCP server side attacks are initiated by an attacker (client)
 Client-side attacks work in reverse, where victim initiates
the traffic, usually by clicking on a link or email.
 We have to understand the environment from the
perspective of an adversary.
 We use threat modelling and ask “Who is the adversary
and what does the adversary want to accomplish?”
72

STRIDE – Microsoft Privacy Standard (MPSD) in response to
FIPS
 Spoofing v. Authentication
 Tampering v. Integrity
 Repudiation v. Non-Repudiation
 Information Disclosure v. Confidentiality
 Denial of Service v. Availability
 Elevation of Privilege v. Authorization
73

Legacy CobiT Mapping
Primary
 PLANNING AND ORGANIZATION, Assess Risks PO9
 Business Risk Assessment (PO 9.1)
 Risk Assessment Approach (PO 9.2)
 Risk Identification (PO 9.3)
 Risk Measurement (PO 9.4)
 Risk Action Plan (PO 9.5)
 Risk Acceptance (PO 9.6)
 Risk Assessment Commitment (PO 9.8)
 Formal Project Risk Management (PO 10.1)
 ACQUISITION & IMPLEMENTATION (AI1) Identify Automated Solutions
 Risk Analysis Report (AI 1.8)
 DELIVERY AND SUPPORT, Ensure System Security DS5
Secondary
 PLANNING AND ORGANIZATION
 PO6 Communicate Management Aims 6.8 Security and Internal Control Framework Policy

Risk Process Maturity
Level Maturity Description
3 Defined Process: An organization-wide risk management policy defines when and how to
conduct risk assessments. Risk assessment follows a defined process that is documented
and available to all staff through training. Decisions to follow the process and to receive
training are left to the individual’s discretion. The methodology is convincing and sound,
and ensures that key risks to the business are likely to be identified. Decisions to follow the
process are left to individual IT managers and there is no procedure to ensure that all
projects are covered or that the ongoing operation is examined for risk on a regular basis.
Risk Management
10 2 543
Non-Existent Initial Repeatable Defined Managed Optimized

4 Managed and Measurable: The assessment of risk is a standard procedure and exceptions to following
the procedure would be noticed by IT management. It is likely that IT risk management is a defined
management function with senior level responsibility. The process is advanced and risk is assessed at
the individual project level and also regularly with regard to the overall IT operation. Management is
advised on changes in the IT environment which could significantly affect the risk scenarios, such as an
increased threat from the network or technical trends that affect the soundness of the IT strategy.
Management is able to monitor the risk position and make informed decisions regarding the exposure it
is willing to accept. Senior management and IT management have determined the levels of risk that the
organization will tolerate and have standard measures for risk/return ratios. Management budgets for
operational risk management projects to reassess risks on a regular basis. A risk management database
is established.
Risk Management
10 2 543

5 Optimized: Risk assessments have developed to the stage where a structured,
organization-wide process is enforced, followed regularly and well managed. Risk
brainstorming and root cause analysis, involving expert individuals, are applied
across the entire organization. The capturing, analysis and reporting of risk
management data are highly automated. Guidance is drawn from leaders in the
field and the IT organization takes part in peer groups to exchange experiences.
Risk management is truly integrated into all business and IT operations, is well
accepted and extensively involves the users of IT services.
Risk Management
10 2 543

 Risk Management Process Should Be Invoked For Every Capital or Strategic
Project.
 At The Start of Each Project, Risk Management Should Commence By
Establishing A Risk Management Plan.
 Change Request With Significance >9 Risk
 Release With Significance >9 Risk
 IT Project With Significance >9 Risk
 Application Service With Significance > 9 Risk
 Maintenance Service With Significance > 9 Risk
Risk Management - Input or Process Triggers

Moving Through A Risk Cycle Status Codes
Status Description
Reviewed & Accepted Risk will be allowed to remain as described. Risk is
determined to be acceptable, given business priorities &
total vulnerability.
Controls Required Team is assigned to determine & implement compensating
controls
Critical Controls Required Exposure is determined to be unacceptable. Team is to
implement compensating controls as quickly as possible.
Emergency –
Immediate Action
Required
Emergency risk situation requires immediate team
management & notification.

Activity/ Outputs
Output Description
Apparent IT System or
Technology resource
based Vulnerability
A person in the IT domain is made aware by interaction with others or through his/her own doing, of an
apparent technology weakness. This weakness is determined by management to possibly merit risk team
consideration. The risk is not associated with an SDM management effort, and therefore requires isolated
entry to the RiskWatch
Significance Evaluation
and Risk Criteria
Template
The significance evaluation is a formal process based in agreed standards for determining the quality
statements associated to an estimated risk. Establishing "RiskWatch COBIT Project Definitions" can be
achieved by implementing a template of criteria definitions
Report Risk Any IT person can launch the Risk Watch to enter details of a perceived risk. Management reviews the risk
to determine its appropriateness for Risk Watch. The steps to filling out the RiskWatch form are detailed in
the RiskWatch Form Entry Work Instruction
RiskWatch Meeting
Review
Occurs weekly. Meeting is preceded by the posting of intended items for review and followed by posted
summary of results. Metrics are gathered and stored in the work products folder as determined by the
RiskWatch team.
Threat & Vulnerability
Analysis
Used to identify and document the threats and vulnerabilities associated with any asset being evaluated.
Security Management Responds to identified threat by ensuring the risk response and compensating controls are effectively
enforced
Mitigated Risk The risk is mitigated to significance of 9 or less with acceptable controls in place.
Attestation of Risk Fair and reasonable discovery and disclosure of risks

Process Exit Criteria
 Risk Process Continues Until The Process Response Is
Implemented
 Risk Is Mitigated To Acceptable Managed Residual Risk or
Removed
 Mitigated Risk Where Significance Is Less Than “9” &
Appropriate Controls Are Identified For Ongoing Risk
Management

Measurements
Key Performance Indicators
 Number of Risk Management Meetings & Workshops
 Number of Risk Management Improvement Projects
 Number of Improvements To The Risk Assessment Process
 Level of Funding Allocated To Risk Management Projects
 Number & Frequency of Updates To Published
 Risk Limits & Policies

Measurements Key Goal Indicators – Reference Slide
 Increased Awareness of The Need For Risk Assessments
 Decreased Number of Incidents Caused By Risks Identified After The Fact
 Increased Number of Identified Risks That Have Been Sufficiently Mitigated
 Increased Number of IT Processes With Formal Documented Risk Assessments
Completed
 Appropriate Percent or Number of Cost Effective Risk Assessment Measures
 Increased Number of Projects Completed On Time & On Budget
 Availability of Accurate Project Schedule & Budget Information
 Decrease In Systemic & Common Project Problems
 Improved Timeliness of Project Risk Identification
 Increased organization Satisfaction With Project Delivered Services
 Improved Timeliness of Project Management Decisions
 Number & Frequency of Risk Monitoring Reports
 Number of Personnel Trained In Risk Management Methodology

Risk Management Program Workflows

To Sum it Up – Just Do It
 Risks Management Policy Signed by CFO and CIO
 IT Security Manager Responsibilities Assigned
 Appropriate Funding Allocated (If Required)
 Risk Awareness Training – What gets listed and how
 Meeting Time and Standard Agenda Format Established
 SUPPORT sessions To Enter Risk Items
 Risk Meeting Agenda Posted
 Risk Meeting
 Posted Risk Meeting Action Items and Notes
 Follow Up Risk Response
 Iterate Enter Risks - Update Risks - Post Agenda – Meeting - Post Notes -
Follow Up Risk Response

Principle 4. Enabling a Holistic Approach:
 Processes—Describe an organised set of practices and activities to achieve certain objectives
and produce a set of outputs in support of achieving overall IT-related goals
 Organisational structures—Are the key decision-making entities in an organisation
 Culture, ethics and behaviour—Of individuals and of the organisation; very often
underestimated as a success factor in governance and management activities
 Principles, policies and frameworks—Are the vehicles to translate the desired behaviour into
practical guidance for day-to-day management
 Information—Is pervasive throughout any organisation, i.e., deals with all information
produced and used by the enterprise. Information is required for keeping the organisation
running and well governed, but at the operational level, information is very often the key
product of the enterprise itself.
 Services, infrastructure and applications—Include the infrastructure, technology and
applications that provide the enterprise with information technology processing and services
 People, skills and competencies—Are linked to people and are required for successful
completion of all activities and for making correct decisions and taking corrective actions

Erm talking points

More Related Content

What's hot

Viewers also liked

Similar to Erm talking points

More from EnterpriseGRC Solutions, Inc.

Recently uploaded

Erm talking points

Editor's Notes