Download ppt - Info. Security Program Development. Acknowledgments Material is sourced from: CISM® Review Manual 2012, ©2011, ISACA. All rights reserved. Used by permission

Info. SecurityProgram Development

AcknowledgmentsMaterial 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, PhDUniv. 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, procedureDescribe COBIT, CMM, Levels 1-5Develop 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

SecurityFramework & Architecture

Architecture: SABSA/ZachmanFramework: COBIT, CMM

Implementation Function

Policy Level

COBIT: Free

NIST: Free

ISO 17799: $50 SABSA

Standards Level

ISO 15408: $90

Procedures Level You Develop

Publicly Available Framework Guided Implementation

SABSA Lifecycle

Strategy &Concept

Design

Implement

Manage &Measure

Logical,Physical,Component,Operational

ContextualConceptual

Attributes defined and measured

Copyright SABSA Limited. Printed with permissionFrom: www.SABSA.com

Implementation of SABSA

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

Develop Contextual

(Business Risk)

DevelopConceptual

(Control Objectives)

Develop Logical(Security Policies)

Develop Physical(Security

Procedures)

Develop Component

(Security Tools)

DevelopOperational

(Service Mgmt)


Security Architecture: SABSAContextual Security Architecture:Business View: Business Risk Model

Business Process Model

Conceptual Security Architecture:Architects View: Control ObjectivesSecurity Strategies & Architecture

Logical Security Architecture:Designers View: Security Policies

Security Services

Physical Security ArchitectureBuilder’s view: Security Rules, Practices, Procedures

Security Mechanisms

Component Security ArchitectureTradesman’s view: Security Standards

Security Products & Tools

OperationalSecurity

Architecture:

FacilityManager’s

View:OperationalRisk Mgmt

SecurityService Mgmt


Zachman Framework (Abbrev.)

Layer What(Data)

How(Function)

Where(Network)

Who(People)

When(Time)

Why(Motive)

Scope(Planner)

Business Model(Owner)

System Model(Designer)

Technology(Builder)

Component (Implementer)

Functioning(Worker)

www.ZIFA.com: Zachman Institute for Framework Architecture

COBIT HistoryCOSO

Comm. of Sponsoring Org. of the Treadway Commission

ControlEnvironment

Risk Assessment

Control Activities

Monitoring

Info

rma

tion

& C

om

mu

nica

tion

Proper tone & actionfrom top mgmt.

Identify & manage riskManage change

Define policies & procedures

Monitor/auditcontrols

Consider all Info. sources:Non-routine, external, informal

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.


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.


COBIT:Monitoring

ME1 Monitor and evaluate IT performance.

ME2 Monitor and evaluate internal control. ME3 Ensure regulatory compliance. ME4 Provide IT governance.


SSE-CMM Process Overview

EngineeringProcess

Risk Process

AssuranceProcess

SSE-CMM: System Security Eng – Capability Maturity Model

Stage 0 Nonexistent:Control processes are not recognized as important

Stage 1 Initial/Ad HocControl processes are important but no coordinated effort exists

Stage 2 Repeatable but IntuitiveMany controls are in place but not documented; events are tracked

Stage 5 OptimizedContinual reevaluation ensures responsiveness and improvement

Stage 4 Managed and MeasurableOperating effectiveness is evaluated; automatic processes introduced

Stage 3 Defined ProcessControls, policies, procedures, and event handling are fully documented

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 de-facto 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 improvement arise from measures and security events

New technologies and processes are evaluated

Common Features include:

Improve Organizational Capability

Improve Process Effectiveness (ROI)

Security Baseline

Today’sBaseline

“We are at 50%compliance butare striving for 100%”

GoalBaseline

“We hope to beCOBIT Level 3(Or NIST compliant)within one year”

Security StandardsThese standards can be used to develop or advance a

security program (if one is not in place): ISO/IEC 27001 ISACA COBIT

Lvl1

Initial/Ad hoc

Lvl2

Repeatablebut intuitive

Lvl3

DefinedProcess

Lvl4

Managed &Measurable

Lvl5

Optimized

Lvl0

Nonexistent

Wherewe are

Where wewant to be

Gap Analysis: What do we need to do to achieve our goal?

COBIT Levels

Achieving Higher Maturity Levels

Level 3: Policy DocumentationLevel 4-5: Metrics

Security Functions

Strategy

Policy

Awareness

Implemen-tation

Compliance

Monitoring Training &Publishing

Monitor industry practicesProvide recommendations

Policy,Procedure,Standards

Security architectureand engineering

Testing, logs,metrics

Metrics, investigation,security escalation

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 DocumentationPolicy= Direction for ControlPhilosophy of organizationCreated by Senior MgmtReviewed periodically

Employees must understand intentAuditors test for compliance

Procedures:Detailed steps toimplement a policy.Written by processowners

Standards:An image ofwhat is acceptable

GuidelinesRecommendationsand acceptablealternatives

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 ProceduresPolicies 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-to-Know basis

Should be tested Technology-specific

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

TacticalMetrics

Opera-tional

Metrics

StrategicMetrics

Metrics

Project Plan or Budget MetricsRisk performanceDisaster Recovery Test resultsAudit resultsRegulatory compliance results

Policy compliance metricsExceptions to policy/standardsChanges in process or system affecting riskIncident management effectiveness

Vulnerability Scan resultsServer config. standards complianceIDS monitoring resultsFirewall log analysisPatch mgmt status

Monitoring Function: MetricsRisk:

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

Category Metric Calculation & Collection Method

Period of Reporting

Strategic Cost of security/terminal

Information Tech. Group

1 year

Cost of incidents Incident Response totals

6 months

Tactical % employees passing FERPA quiz

Annual email requesting testing

1 year

% employees completing FERPA training

Two annual trainings with sign-in. Performance review

1 year

# Hours Web unavailable

Incident Response form 6 months

Opera-tional

# brute force attacks Incident Response form 1 month

# malware infections Incident Response form 1 month

Major Risks:FERPA Violation

Cracking Attempt

Web AvailabilityLunatic gunman

What are the most important areas to monitor in your organization?

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 Privilege2. Management approval3. Prevention, detection, correction4. 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

ReferenceSlide # 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