Info.

Security
Program
Development
Acknowledgments
Material is sourced from:
 CISM® Review Manual 2012, ©2011, ISACA. All rights reserved.
Used by permission.
 CISA® Review Manual 2011, ©2010, ISACA. All rights reserved.
Used by permission.

Author: Susan J Lincke, PhD

Univ. of Wisconsin-Parkside
Reviewers/Contributors: Todd Burri, Kahili Cheng

Funded by National Science Foundation (NSF) Course, Curriculum and

Laboratory Improvement (CCLI) grant 0837574: Information Security:
Audit, Case Study, and Service Learning.
Any opinions, findings, and conclusions or recommendations expressed
in this material are those of the author(s) and/or source(s) and do not
necessarily reflect the views of the National Science Foundation.
Objectives
The student should be able to:
Define security baseline, gap analysis,
metrics, compliance, policy, standard,
guideline, procedure
Describe COBIT, CMM, Levels 1-5
Develop security metrics
Security Program Requirements
 Must develop an enterprise security
architecture at conceptual, logical, functional,
and physical levels
 Must manage risk to acceptable levels
 Risk
develops the Business Case that convinces
mgmt security should be performed
 Must be defined in business terms to help
nontechnical stakeholders understand and
endorse program goals
 Must provide security-related feedback to
business owners and stakeholders
 Security
Framework &
Architecture
Architecture: SABSA/Zachman
Framework: COBIT, CMM
Implementation Function
Publicly Available Framework Guided Implementation

Policy Level
COBIT: Free
NIST: Free
ISO 17799: $50 SABSA
Standards Level
ISO 15408: $90

Procedures Level You Develop

SABSA Lifecycle
Contextual
Conceptual
Strategy &
Concept

Logical,
Manage & Physical,
Measure Design Component,
Operational
Attributes defined
and measured
Implement

Copyright SABSA Limited. Printed with permission

From: www.SABSA.com
 Implementation of SABSA
Develop
Contextual
(Business Risk)

Develop
Conceptual
(Control Objectives)

Develop Physical Develop Develop

Develop Logical Operational
(Security Component
(Security Policies) (Service Mgmt)
Procedures) (Security Tools)
 Do first 2 stages first – there can be considerable work in parallel for
the subsequent stages.
 For each stage answer: what, why, how, who, where, when
 On previous slide what and why are provided.
 When all 6 stages x 6 questions = 36 answers are done – plan is
complete Copyright SABSA Limited. Printed with permission
From: www.SABSA.com
Security Architecture: SABSA
Contextual Security Architecture:
Business View: Business Risk Model
Business Process Model
Operational
Conceptual Security Architecture: Security
Architects View: Control Objectives Architecture:
Security Strategies & Architecture
Facility
Logical Security Architecture: Manager’s
Designers View: Security Policies View:
Security Services Operational
Physical Security Architecture Risk Mgmt
Builder’s view: Security Rules, Practices, Procedures
Security Mechanisms Security
Component Security Architecture Service Mgmt
Tradesman’s view: Security Standards
Security Products & Tools
Copyright SABSA Limited. Printed with permission
From: www.SABSA.com
 Zachman Framework
(Abbrev.)
Layer What How Where Who When Why
(Data) (Function) (Network) (People) (Time) (Motive)
Scope
(Planner)
Business
Model
(Owner)
System Model
(Designer)
Technology
(Builder)
Component
(Implementer)
Functioning
(Worker)
www.ZIFA.com: Zachman Institute for
Framework Architecture
 COBIT History
COSO
Comm. of Sponsoring Org. of the Treadway Commission
Proper tone & action
Control

Information & Communication

from top mgmt.
Environment

Identify & manage risk

Manage change Risk
Assessment
Define policies &
procedures Control Activities
Consider all Info. sources:
Non-routine, external,
informal
Monitoring
Monitor/audit
controls
 COSO:
Two Levels of Controls
Entity-Level Control Process Activity Level
 Cuts cross functions:  Transaction processing is
 Personnel policies independent:
 Computer controls  Purchasing transaction
 Risk identification  Sales (credit) transaction
 Financial reporting  Account balances
processes  Disclosures
 System-wide monitoring  Often documented via
flowcharts
COBIT <-> COSO <-> SOX

http://www.isaca.org/
 COBIT:
Planning and Organization
 PO1 Define a strategic IT plan.
 PO2 Define the information architecture.
 PO3 Determine technological direction.
 PO4 Define the IT processes, organisation and relationships.
 PO5 Manage the IT investment.
 PO6 Communicate management aims and direction.
 PO7 Manage IT human resources.
 PO8 Manage quality.
 PO9 Assess and manage IT risks.
 PO10 Manage projects.

Source:  COBIT 4.1, ©2007 ISACA, All rights reserved.

 COBIT:
Acquisition and Implementation
 AI1 Identify automated solutions.
 AI2 Acquire and maintain application software.
 AI3 Acquire and maintain technology infrastructure.
 AI4 Enable operation and use.
 AI5 Procure IT resources.
 AI6 Manage changes.
 AI7 Install and accredit solutions and changes.

Source:  COBIT 4.1, ©2007 ISACA, All rights reserved.

 COBIT:
Delivery and Support
 DS1 Define and manage service levels.
 DS2 Manage third-party services.
 DS3 Manage performance and capacity.
 DS4 Ensure continuous service.
 DS5 Ensure systems security.
 DS6 Identify and allocate costs.
 DS7 Educate and train users.
 DS8 Manage service desk and incidents.
 DS9 Manage the configuration.
 DS10 Manage problems.
 DS11 Manage data.
 DS12 Manage the physical environment.
 DS13 Manage operations.

Source:  COBIT 4.1, ©2007 ISACA, All rights reserved.

 COBIT:
Monitoring
 ME1 Monitor and evaluate IT
performance.
 ME2 Monitor and evaluate internal control.
 ME3 Ensure regulatory compliance.
 ME4 Provide IT governance.

Source:  COBIT 4.1, ©2007 ISACA, All rights reserved.

SSE-CMM Process Overview

Risk
Process

Assurance Engineering
Process Process
SSE-CMM: System Security Eng –
Capability Maturity Model
Stage 5 Optimized
Continual reevaluation ensures responsiveness and improvement

Stage 4 Managed and Measurable

Operating effectiveness is evaluated; automatic processes introduced

Stage 3 Defined Process

Controls, policies, procedures, and event handling are fully documented

Stage 2 Repeatable but Intuitive

Many controls are in place but not documented; events are tracked

Stage 1 Initial/Ad Hoc

Control processes are important but no coordinated effort exists

Stage 0 Nonexistent:
Control processes are not recognized as important
Level 1 – Performed Informally
 Security design is poorly-defined
 Security issues are dealt with in a reactive
way
 No contingency plan exists
 Budgets, quality, functionality and project
scheduling is ad hoc
 No Process Areas
Level 2 – Planned & Tracked
 Procedures are Common Features include:
established at the project  Planning Performance
level  Disciplined Performance
 Definition, planning &  Verifying Performance
performance become de-
 Tracking Performance
facto standards from
project to project
 Events are tracked
Level 3 – Well Defined
 Standardized security Common Features include:
processes across  Defining a Standard
organization Process
 Personnel are trained to  Perform the Defined
ensure knowledge and Process
skills  Coordinate Security
 Assurance (audits) track Practices
performance
 Measures are defined
based upon the defined
process
Level 4 – Quantitatively Controlled
 Measurable goals for Common Features
security quality exist include:
 Measures are tied to  Establish Measurable
the business goals of Quality Goals
the organization  Objectively Manage
Performance (SLA)
Level 5 – Continuously Improving
 Continuous Common Features
improvement arise include:
from measures and  Improve
security events Organizational
 New technologies and Capability
processes are  Improve Process
evaluated Effectiveness (ROI)
Security Baseline

“We are at 50% “We hope to be

compliance but COBIT Level 3
are striving for 100%” (Or NIST compliant)
within one year”

Today’s Goal
Baseline Baseline
 Security Standards
These standards can be used to develop or advance a
security program (if one is not in place):
 ISO/IEC 27001
 ISACA COBIT

Gap Analysis: What do we need to do

to achieve our goal?

Where Where we
we are want to be
COBIT Levels

Lvl Lvl Lvl Lvl Lvl Lvl

0 1 2 3 4 5
Nonexistent Initial/ Repeatable Defined Managed & Optimized
Ad hoc but intuitive Process Measurable
Achieving Higher
Maturity Levels
Level 3: Policy Documentation
Level 4-5: Metrics
Security Functions
Monitor industry practices
Provide recommendations
Metrics, investigation,
security escalation
Strategy
Policy,
Compliance Policy Procedure,
Standards

Monitoring Awareness Training &

Publishing

Testing, logs, Implemen-

metrics tation

Security architecture
and engineering
Level 3: Security Policy
Policy = First step to developing security
infrastructure
 Set direction for implementation of
controls, tools, procedures
 Approved by senior mgmt
 Documented and communicated to all
employees and associates
Example Policies
 Risks shall be managed utilizing appropriate controls and
countermeasure to achieve acceptable levels at acceptable
costs
 Monitoring and metrics shall be implemented, managed,
and maintained to provide ongoing assurance that all
security polices are enforced and control objectives are
met.
 Incident response capabilities are implemented and
managed sufficient to ensure that incidents do not
materially affect the ability of the organization to continue
operations
 Business continuity and disaster recovery plans shall
be developed, maintained and tested in a manner that
ensures the ability of the organization to continue
operations under all conditions
Security Policy Document
 Definition of information security
 Statement of management commitment
 Framework for approaching risk and controls
 Brief explanation of policies, minimally covering
regulatory compliance, training/awareness,
business continuity, and consequences of violations
 Allocation of responsibility, including reporting
security incidents
 References to more detailed documents
Policy Documentation
Policy= Direction for Control Employees must understand intent
Philosophy of organization Auditors test for compliance
Created by Senior Mgmt
Reviewed periodically

Procedures: Standards: Guidelines

Detailed steps to An image of Recommendations
implement a policy. what is acceptable and acceptable
Written by process alternatives
owners
Policies, Procedures, Standards
 Policy Objective: Describes ‘what’ needs to be accomplished
 Policy Control: Technique to meet objectives
 Procedure: Outlines ‘how’ the Policy will be accomplished
 Standard: Specific rule, metric or boundary that implements policy

 Example 1:
 Policy: Computer systems are not exposed to illegal, inappropriate, or
dangerous software
 Policy Control Standard: Allowed software is defined to include ...
 Policy Control Procedure: A description of how to load a computer with required
software.

 Example 2:
 Policy: Access to confidential information is controlled
 Policy Control Standard: Confidential information SHALL never be emailed
without being encrypted
 Policy Guideline: Confidential info SHOULD not be written to a memory stick
Discussion: Are these effective controls by themselves?
Policy Function:
Policies and Procedures
Policies Procedures
 Direction of Management  Specific Directions
 Requires approval from  Document every step
senior mgmt  Changes with procedure
 Should change infrequently  Provided on Need-to-
 Communicated to entire Know basis
workforce via varied means  Should be tested
 Technology-independent
 Should have 24 or less
 Technology-specific
 One general mandate
stated in fewer than 1-3
sentences
 Level 4 Monitoring:
Includes Metrics
 Metrics allow independent auditors to
attest that the security program is in place
 Monitoring achievement of control
objective is more important than perfecting
security procedures
 Monitoring Function: Metrics
Project Plan or Budget Metrics
Strategic Risk performance
Metrics Disaster Recovery Test results
Audit results
Regulatory compliance results

Metrics
Opera-
Tactical
tional
Metrics Metrics Vulnerability Scan results
Policy compliance metrics Server config. standards
Exceptions to policy/standards compliance
Changes in process or system IDS monitoring results
affecting risk Firewall log analysis
Incident management effectiveness Patch mgmt status
 Monitoring Function: Metrics
Risk: Cost Effectiveness:
The aggregate ALE What is:
% of risk eliminated, mitigated, Cost of workstation security per user
transferred Cost of email spam and virus
# of open risks due to inaction protection per mailbox
Operational Performance Organizational Awareness:
Time to detect and contain incidents % of employees passing quiz, after
% packages installed without problem training vs. 3 months later
% of systems audited in last quarter % of employees taking training
Technical Security Architecture Security Process Monitoring:
# of malware identified and neutralized Last date and type of BCP, DRP, IRP
Types of compromises, by severity & testing
attack type Last date asset inventories were
Attack attempts repelled by control reviewed & updated
devices Frequency of executive mgmt review
Volume of messages, KB processed activities compared to planned
by communications control devices
 Workbook: Metrics
Metrics Selected
What are the most important areas to monitor in your organization?

Lunatic gunman Cracking Attempt

FERPA Violation
Major Risks: Web Availability

Category Metric Calculation & Collection Period of

Method Reporting
Strategic Cost of security/terminal Information Tech. Group 1 year
Cost of incidents Incident Response totals 6 months
Tactical % employees passing FERPA Annual email requesting 1 year
quiz testing
% employees completing Two annual trainings with 1 year
FERPA training sign-in. Performance review
# Hours Web unavailable Incident Response form 6 months
Opera- # brute force attacks Incident Response form 1 month
tional # malware infections Incident Response form 1 month
 Question
The difference between where an
organization performs and where they
intend to perform is known as:
1. Gap analysis
2. Quality Control
3. Performance Measurement
4. Benchmarking
 Question
“Passwords shall be at least 8 characters long,
and require a combination of at least 3 of lower
case, upper case, numeric, or symbols
characters”. This is an example of a:
1. Standard
2. Policy
3. Procedure
4. Guideline
 Question
The FIRST step in the SABSA approach is
to
1. Evaluate existing controls
2. Determine current security practices
3. Determine business risk
4. Define policies and procedures
 Question
In the architectural or design stage of the
security life cycle, the MOST important
guideline is:
1. Least Privilege
2. Management approval
3. Prevention, detection, correction
4. Confidentiality, Integrity, Availability
 Question
The PRIMARY focus of COBIT or CMM
Level 4 is
1. Security Documentation
2. Metrics
3. Risk
4. Business Continuity
 Question
“Employees should never open email
attachments, except if the attachment is
expected and for business use”. This is an
example of a:
1. Policy
2. Procedure
3. Guideline
4. Standard
 Question
The MOST important metrics when
measuring compliance include:
1. Metrics most easily automated
2. Metrics related to intrusion detection
3. Those recommended by best practices
4. Metrics measuring conformance to policy
Reference
Slide # Slide Title Source of Information

9 Security Architecture: SABSA CISM: page 158

10 Zachman Framework CISA: page 95 Exhibit 2.5

14 COBIT: Planning and Organization CISA: page 425 and CISM: page 150

15 COBIT: Acquisition and Implementations CISA: page 425 and CISM: page 150

16 COBIT: Delivery and Support CISA: page 425 and CISM: page 150

17 COBIT: Monitoring CISA: page 425 and CISM: page 150

28 Security Functions CISM: page 173 Exhibit 3.12

31 Security Policy Document CISA: page 99,100

34 Policy Function: Policy and Procedures CISA: page 99 -101

35 Level 4: Monitoring: Includes Metrics CISM: page 192 -194

36 Monitoring Function: Metrics CISM: page 192