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
Policy Level
COBIT: Free
NIST: Free
ISO 17799: $50
Standards Level
ISO 15408: $90
Procedures Level
Guided Implementation
SABSA
You Develop
SABSA Lifecycle
Strategy &
Concept
Contextual
Conceptual
Manage &
Measure
Attributes defined
and measured
Design
Implement
Copyright SABSA Limited. Printed with permission
From: www.SABSA.com
Logical,
Physical,
Component,
Operational
Implementation of SABSA
Develop
Contextual
(Business Risk)
Develop
Conceptual
(Control Objectives)
Develop Logical
(Security Policies)


Develop
Component
(Security Tools)
Develop
Operational
(Service Mgmt)
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


Develop Physical
(Security
Procedures)
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
Conceptual Security Architecture:
Architects View: Control Objectives
Security Strategies & Architecture
Logical Security Architecture:
Designers View: Security Policies
Security Services
Physical Security Architecture
Builder’s view: Security Rules, Practices, Procedures
Security Mechanisms
Component Security Architecture
Tradesman’s view: Security Standards
Security Products & Tools
Copyright SABSA Limited. Printed with permission
From: www.SABSA.com
Operational
Security
Architecture:
Facility
Manager’s
View:
Operational
Risk Mgmt
Security
Service Mgmt
Zachman Framework
(Abbrev.)
Layer
What
(Data)
How
(Function)
Where
(Network)
Who
(People)
Scope
(Planner)
Business
Model
(Owner)
System Model
(Designer)
Technology
(Builder)
Component
(Implementer)
Functioning
(Worker)
www.ZIFA.com: Zachman Institute for
Framework Architecture
When
(Time)
Why
(Motive)
COBIT History
COSO
Proper tone & action
from top mgmt.
Identify & manage risk
Manage change
Define policies &
procedures
Consider all Info. sources:
Non-routine, external,
informal
Monitor/audit
controls
Control
Environment
Risk
Assessment
Control Activities
Monitoring
Information & Communication
Comm. of Sponsoring Org. of the Treadway Commission
COSO:
Two Levels of Controls
Entity-Level Control
 Cuts cross functions:





Personnel policies
Computer controls
Risk identification
Financial reporting
processes
System-wide monitoring
Process Activity Level
 Transaction processing is
independent:





Purchasing transaction
Sales (credit) transaction
Account balances
Disclosures
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
Process
Engineering
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
established at the project
level
Definition, planning &
performance become defacto standards from
project to project
Events are tracked
Common Features include:
 Planning Performance
 Disciplined Performance
 Verifying Performance
 Tracking Performance
Level 3 – Well Defined




Standardized security
processes across
organization
Personnel are trained to
ensure knowledge and
skills
Assurance (audits) track
performance
Measures are defined
based upon the defined
process
Common Features include:
 Defining a Standard
Process
 Perform the Defined
Process
 Coordinate Security
Practices
Level 4 – Quantitatively Controlled


Measurable goals for
security quality exist
Measures are tied to
the business goals of
the organization
Common Features
include:
 Establish Measurable
Quality Goals
 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%
compliance but
are striving for 100%”
Today’s
Baseline
“We hope to be
COBIT Level 3
(Or NIST compliant)
within one year”
Goal
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
we are
Where we
want to be
COBIT Levels
Lvl
Lvl
0
1
Nonexistent Initial/
Ad hoc
Lvl
2
Repeatable
but intuitive
Lvl
Lvl
Lvl
3
4
5
Defined Managed & Optimized
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
Compliance
Policy
Monitoring
Testing, logs,
metrics
Awareness
Implementation
Security architecture
and engineering
Policy,
Procedure,
Standards
Training &
Publishing
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
Philosophy of organization
Created by Senior Mgmt
Reviewed periodically
Procedures:
Detailed steps to
implement a policy.
Written by process
owners
Employees must understand intent
Auditors test for compliance
Standards:
An image of
what is acceptable
Guidelines
Recommendations
and acceptable
alternatives
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
 Direction of Management
 Requires approval from
senior mgmt
 Should change infrequently
 Communicated to entire
workforce via varied means
 Technology-independent
 Should have 24 or less
 One general mandate
stated in fewer than 1-3
sentences
Procedures
 Specific Directions





Document every step
Changes with procedure
Provided on Need-toKnow basis
Should be tested
Technology-specific
Level 4 Monitoring:
Includes Metrics
Metrics inform management (and
independent auditors) of the effectiveness
of the security program
 Monitoring achievement of control
objective may be 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
Tactical
Metrics
Policy compliance metrics
Exceptions to policy/standards
Changes in process or system
affecting risk
Incident management effectiveness
Operational
Metrics Vulnerability Scan results
Server config. standards
compliance
IDS monitoring results
Firewall log analysis
Patch mgmt status
Monitoring Function: Metrics
Risk:
The aggregate ALE
% of risk eliminated, mitigated,
transferred
# of open risks due to inaction
Cost Effectiveness:
What is:
Cost of workstation security per user
Cost of email spam and virus
protection per mailbox
Operational Performance
Time to detect and contain incidents
% packages installed without problem
% of systems audited in last quarter
Organizational Awareness:
% of employees passing quiz, after
training vs. 3 months later
% of employees taking training
Technical Security Architecture
# of malware identified and neutralized
Types of compromises, by severity &
attack type
Attack attempts repelled by control
devices
Volume of messages, KB processed
by communications control devices
Security Process Monitoring:
Last date and type of BCP, DRP, IRP
testing
Last date asset inventories were
reviewed & updated
Frequency of executive mgmt review
activities compared to planned
Workbook: Metrics
Metrics Selected
What are the most important areas to monitor in your organization?
Lunatic gunman
FERPA Violation
Category
Major Risks:
Metric
Operational
Web Availability
Calculation & Collection
Method
Period of
Reporting
Information Tech. Group
1 year
Cost of incidents
Incident Response totals
6 months
% employees passing FERPA
quiz
Annual email requesting
testing
1 year
% employees completing
FERPA training
Two annual trainings with
1 year
sign-in. Performance review
# Hours Web unavailable
Incident Response form
6 months
# brute force attacks
Incident Response form
1 month
# malware infections
Incident Response form
1 month
Strategic Cost of security/terminal
Tactical
Cracking Attempt
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
1.
2.
3.
4.
The PRIMARY focus of COBIT or CMM
Level 4 is
Security Documentation
Metrics
Risk
Business Continuity
Question
1.
2.
3.
4.
“Employees should never open email
attachments, except if the attachment is
expected and for business use”. This is an
example of a:
Policy
Procedure
Guideline
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