• No results found

Security Policy Presentation

N/A
N/A
Protected

Academic year: 2021

Share "Security Policy Presentation"

Copied!
178
0
0

Loading.... (view fulltext now)

Full text

(1)
(2)

© 2008 Security Architecture - All Rights Reserved. CONTENTS

Why a Course on Policy?

Information Security Policy Policy in Context

Regulatory Drivers Policy Standards

Policy Development

Writing Policies and Guidelines … and Summary

(3)
(4)

© 2008 Security Architecture - All Rights Reserved. SECTION OBJECTIVES

1. Emphasize the importance of security policy.

2. Present the areas security policy addresses.

3. Look at policy as a layer within the context of Defense in Depth.

(5)

WHY POLICY?

Policy is the foundation for all the other elements in information security.

Without effective policies there is no basis for ensuring that security tools,

technologies, and processes are used appropriately to address risks.

(6)

© 2008 Security Architecture - All Rights Reserved. WHY POLICY?

Developing policy is an art, always specific to the organization in question.

No one can sell you pre-written policies.

There are processes, templates, and good information sources that can help.

(7)

WHY POLICY?

Security in many organizations today is too focused on technology and tools, and not enough on business requirements,

physical and information assets, and risk assessment.

(8)

© 2008 Security Architecture - All Rights Reserved. WHY POLICY?

Policy addresses all elements of security in your organization:

People

Communications

Processes and operations

Physical and intellectual property Technical infrastructure

(9)

WHY POLICY?

Security is

commonly handled from the bottom

up, but…

The most effective security structure begins from the top down Æ

Security Technologies

Security Standards & Guidelines Security Policies

Business Requirements

Exec Mgmt

(10)

© 2008 Security Architecture - All Rights Reserved. WHAT IS POLICY?

Security policy is a set of documents that explain how an organization will protect its physical and electronic assets.

Policy states what will (or will not) be

done, how policy is to be carried out and enforced, and often why the policy exists.

(11)

WHAT IS POLICY?

Security policy addresses: Employee behavior

Business practices Risk management Operations

(12)

© 2008 Security Architecture - All Rights Reserved. EMPLOYEE BEHAVIOR

Acceptable use policy

Email and communications policy Security awareness and education Access control policy

Regulatory compliance

Roles and responsibilities

(13)

BUSINESS PRACTICES

Acceptable use policy

External communications policy Transaction security policy

Privacy policy

Change management Security planning

(14)

© 2008 Security Architecture - All Rights Reserved. RISK MANAGEMENT

Business asset valuation Risk acceptance policy

Mission Impact Assessment

Disaster recovery/business continuity policy

Internal controls

Audit and assessment policy

(15)

OPERATIONS

Acceptable use policy

Email and communications policy Network and security monitoring Incident response

Access control policy Physical security

(16)

© 2008 Security Architecture - All Rights Reserved. TECHNICAL MEASURES

Anti-virus policy Firewall policy

Intrusion detection policy Application security policy

Identity management and provisioning Access control

Fraud detection

(17)

DEFENSE IN DEPTH

Is the practice of layering defenses to improve an organization’s security

posture.

Is a leading security principle in information assurance.

Applies to any or all layers in a security architecture.

(18)

© 2008 Security Architecture - All Rights Reserved. DEFENSE IN DEPTH

Defense in depth is an integrated set of

information security measures and actions, implemented to provide multiple layers of security across:

People

Technology Operations

(19)

DEFENSE IN DEPTH

People

Information security begins with

commitment from senior management Policies and procedures should cover all organizational aspects related to people

Training and awareness Personnel security

Human resources Physical security

(20)

© 2008 Security Architecture - All Rights Reserved. DEFENSE IN DEPTH

Technology

Security measures should be deployed at network, platform, and application layers Security technology should be chosen to address stated policies based on identified risks

Technology is a means to implement security policy

(21)

DEFENSE IN DEPTH

Operations

Day-to-day activities to maintain security posture:

Security management

Monitoring and event management Readiness assessments and testing Certification and accreditation

Intrusion detection, alerting, and response Patch management

(22)

© 2008 Security Architecture - All Rights Reserved. DEFENSE IN DEPTH

Security layers form a concentric set of boundaries:

Network Infrastructure

Computing Platforms

Application Environment

(23)

DEFENSE IN DEPTH

Multiple Controls Across Multiple Layers

Physical Security

Locks Biometrics PIV Credentials/ID Badges CCTV Disaster Recovery/COOP Guards RFID

Perimeter (Network Layer)

Boundary Routers VPN Firewalls Proxy Servers

Network IDS/IPS RADIUS NAC Gateway Anti-Virus Spam Blocker

Host (Platform Layer)

Host IDS/IPS Server Anti-Virus Server Anti-Spyware Desktop Anti-Virus Patch Management Server Certificates

Software (Application Layer)

Web Service Security Application Proxy Input Validation Database Security Content Filter Data Encryption Identity Management

Personnel (User Layer)

Authentication & Authorization PKI RBAC Training Two-Factor Authentication Biometrics Clearances

(24)

© 2008 Security Architecture - All Rights Reserved. LEADING INFOSEC INVESTMENTS

Network Security

Distributed security controls

Policy and configuration enforcement (NAC) Event monitoring and management (SIEM) User Management

User provisioning/identity management Single sign-on

Content Security

Anti-virus/anti-spyware

Content filtering and spam control Data loss protection

(25)

INTRO WORKSHOP

9 Task: Build class company situation addressing industry, structure, operations areas, and user communities.

(26)

SECURITY POLICY

(27)

SECTION OBJECTIVES

1. Provide an overview of security policy.

2. Define and show the relationship between policies, standards, guidelines, and

procedures.

3. Identify categories and key components of security policies.

(28)

© 2008 Security Architecture - All Rights Reserved. INFORMATION SECURITY POLICY

Policies, Standards, Guidelines

Elements of Policies, Standards & Guidelines Policy Objectives

Policy Classifications Policy Components

Information Security Policy Framework Policy Support

Policy Development Lifecycle Delivery Methods

(29)

INFORMATION SECURITY POLICY

Without strong management policies, corporate security programs will be less effective and not align with management objectives.

Policies are the blueprint for the security framework

Policies, Standards and Guidelines enables the corporation to implement the specific controls processes and awareness programs to raise the level of information security and assurance.

(30)

© 2008 Security Architecture - All Rights Reserved. POLICES & STANDARDS

Policies

High Level “umbrellas” Low Level

Standards

Corporate-wide standards Local Guidelines

Procedures

Local repeatable processes

User Management Policies

All system users must be individually identified

OS Authentication

Unix, Windows users … Administrative access vs. general

How-To

Request an account Approve a new system

(31)

HOW THEY RELATE

Policy

Governance “Thou Shall”

What Management wants to achieve and why.

Standards

Desired Mechanisms

Technical specification of how to implement policy

Procedure

Steps to carry out

Detailed instructions

Guidelines

(32)

© 2008 Security Architecture - All Rights Reserved. ELEMENTS OF A POLICY

Scope – What you are going to protect

High Level Policy Statement – 30,000 ft overview Accountability – personnel

Non- compliance – a statement pertaining to loss if compromised

Monitoring – how policies, standards or guidelines will be validated

Exceptions – in the event that a community of users cannot meet compliance

(33)

INFORMATION SECURITY POLICY OBJECTIVES

Foster information confidentiality

Outline data integrity responsibilities Define assets that require protection

How resources should be used efficiently and appropriately

Provide for system availability Raise awareness

Provide a foundation, a roadmap and a compass for information security audit, process,

(34)

© 2008 Security Architecture - All Rights Reserved.

WORKSHOP #1

9 Task: Draft security policy outlines for 3 of the following:

• Acceptable use • Data protection/privacy • Change management • Firewalls • Building access • Network authentication • Anti-virus • Intrusion detection • Information classification • Business continuity 33

(35)

ELEMENTS OF A STANDARD

Scope – How you are going to protect

Role & Responsibilities – defining, executing, and supporting standards

Guidance – references overriding policy statements

Baseline standards – high level statements for platform and applications

Technical Standard – product/version

specifications and associated descriptions

Administrative Standard - initial and ongoing administration of platform and applications

(36)

© 2008 Security Architecture - All Rights Reserved. ELEMENTS OF A GUIDELINE

Guidelines should be based on industry best practices (whenever possible)

Purpose – to efficiently meet the standard and policy requirements

Intent – description of guideline’s objectives

Roles & Responsibilities – defining, executing and supporting guidelines

Guideline Statements – step by step process to implement policy elements

Operational Statements - defines the “how” of day to day operations

(37)

POLICY DEVELOPMENT LIFE-CYCLE

Planning:

•Requirements

•ID core corp. issues

•Solicit input from groups •Data collection

Development:

•Draft initial position statement •Security group interaction •Legal, ITSC, HR input

•Best practices

•Coordinated draft policy •Security council review •Policy approval Implementation: •Supporting docs •Roll-out •Awareness Periodic Review: •Incidents •Audit •Controls effectiveness Policy Mgmt

(38)

© 2008 Security Architecture - All Rights Reserved. POLICY CLASSIFICATIONS Regulatory Public Internal Confidential Restrictive (Private)

HIPAA, FCRA, GLBA, SOX

Marketing materials

Trade secrets, proprietary ideas, HR Information

Non-public corporate financial reports

Corporate payroll information, credit card transactions,

customer data

(39)

POLICY CATEGORIES

Information Security

Computer security policy Program policy Issue-specific policy System-specific policy General Business HR policies Travel policy

(40)

© 2008 Security Architecture - All Rights Reserved. COMMON POLICY COMPONENTS

Intent / Purpose

Scope and applicability

Policy authors and sponsors Roles and responsibilities

Effective and review dates Compliance measures

Supplementary information and resources

(41)

GENERAL POLICY CONTENT

Date of effective enforcement

Statement of intent and audience

Sponsor / authorizing corporate officer (or committee) Policy objectives and expectations

Exception and change request process Breach of policy response process

Review and expiration dates

Corporate boundaries outlined in policy

Prohibited activities, liability issues, legal requirements, due diligence, etc.

(42)

© 2008 Security Architecture - All Rights Reserved. POLICY DELIVERY

Email, Intranet, Paper, Training class Get everyone involved and interested Solicit feedback

Make “fun” policy delivery continual Enforce and reinforce

Part of security awareness and training

(43)

WORKSHOP #2

9 Task: Fill out the 3 outlines from WS#1 with the contents on the previous slide.

(44)

SECURITY POLICY

(45)

SECTION OBJECTIVES

1. Show policy’s role within an information security program.

2. Explain the steps in the management of the information security program.

(46)

© 2008 Security Architecture - All Rights Reserved. SECURITY MANAGEMENT FRAMEWORK

Information Security Management ISO/IEC 27001 & 27002

Enterprise Security Policies Standards & Guidelines

Compliance, Monitoring & Audits

Best Practices

You need to start with a foundation … Where implementation details are resolved by the business … Which are validated and watched to assure they are being implemented in practice …

And which are expressed as activities and practices that are of high quality …

Grounded in a comprehensive structure … 1 2 3 4 5 45

(47)

POLICIES & TECHNICAL ARCHITECTURE Policy Definition Policies Personnel Statutory Program Mgmt Security Incident Info Classification Systems Life Cycle Physical & Environ

Audit Telecom Logical Access Id / Auth / Auth Remote Access Computer Systems Support & Operations

Guidelines Standards

Tech Controls Risk Mgmt

Inventory Asset

Ownership Assessment Analysis

Technical Security Architecture

(48)

© 2008 Security Architecture - All Rights Reserved. INFORMATION SECURITY PROGRAM

Technology Integration Operations, Administration & Control Audit & Review Process Prototyping & Elaboration Policy Design Assess

Deploy Manage &

Support

(49)

INFORMATION ASSURANCE MODEL Monitoring, Detection and Prevention Incident Response, Risk Mitigation Vulnerability Analysis, Audit & Review, Forensics Control Selection, Implementation and Operation Policy Protect Assess Detect Respond

(50)

© 2008 Security Architecture - All Rights Reserved. THE ISMS (ISO 27001) MODEL

Establish the ISMS Maintain and Improve the ISMS Implement and Operate the ISMS Monitor and Review the ISMS Plan Do Check Act Information Security Requirements and Expectations Managed Information Security & Operations

49

(51)

POLICY

Policy is the hub of the wheel … its central focus.

It should be a reference point for actions taken and decisions made.

Policy should be used when activities “on the wheel” are undertaken.

Reviews should be conducted to ensure policy reflects business objectives.

(52)

© 2008 Security Architecture - All Rights Reserved. AUDIT, ASSESSMENT & REVIEW

Policy is a key component of audit activities: Evaluate current security picture

Compare against policy

Performed on a regular basis and after a security event or as defined by a

regulatory agency

Results of audit and review process are used in the next phase of the security process

(53)

SECURITY STRATEGIC PLANNING

Iterative policy development should be part of strategic planning cycles:

High level planning

Use policy as a benchmark and a compass New strategic initiatives always impact

policy

Looks at process, not technology Uses audit and review findings

(54)

© 2008 Security Architecture - All Rights Reserved. TECHNOLOGY INTEGRATION

The way security technologies work together is driven by security policy (remember defense in depth):

Technical planning and implementation Based on policy

Uses audit and review as well as developed

process to determine technological requirements Tactical implementation of strategic goals

The swords and shields of information security

(55)

POLICY MANAGEMENT TOOLS

Apply security policies to systems

Validate computers and applications connecting to the environment

Detect policy compromise

Automatic remediation if out of compliance May maintain “white list” of applications

(56)

© 2008 Security Architecture - All Rights Reserved. Operation, Administration and Control

Operational actions should be dictated by policy: Keeping the processes and technology running Responding to security events

Testing and practicing the right execution People play a key role

Uses technology, process and policy to provide input to the audit and review process

(57)

WORKSHOP #3

9 Task: Write a security awareness policy to communicate the information security program to employees. How would this differ for customers? (to be revisited…)

(58)

SECURITY POLICY

(59)

SECTION OBJECTIVES

1. Define and explain major regulatory requirements affecting policy.

2. Understand which and what type of regulations impact your organization.

(60)

© 2008 Security Architecture - All Rights Reserved. DUE CARE

What it is:

General principle addressing obligation of

business managers to act reasonably and in the best interests of their organizations

What it means:

Management can be held accountable for the efforts taken (or not taken) to comply with

regulations, including those governing privacy safeguards and related policies.

(61)

HIPAA

What it is:

Health Insurance Portability and Accountability Act of 1996

A set of regulations governing health data privacy Affects medical service providers, insurance

companies, companies, schools, etc.

Intended to allow individuals to control access to and release of their personal medical information Specifies what must be protected, and who has to safeguard it, but not how data is protected

(62)

© 2008 Security Architecture - All Rights Reserved. HIPAA

What it means:

Healthcare industry participants must ensure that personal data is only disclosed subject to patient consent

Applies to many health transactions that have been

automated in recent years, as well as manual processes Extends responsibility to data in transit over and between networks

Strongly implies needs for encryption, authentication, authorization, and other security provisions, but leaves implementation details to organizations.

(63)

HIPAA

What has to be done:

Effective in April 2003, affected organizations must implement procedures to comply with the Privacy Rule

Includes consumer/patient notification, preferences, and

explicit permission for release of protected health information (PHI)

Since 2005, these same organizations must achieve compliance with the Security Rule

Establishes guidelines for the minimum requirements to ensure confidentiality, security and integrity of electronically stored and transmitted health information.

Covers electronic and non-electronic forms of information Does not provide specific instruction on how organizations should safeguard PHI

(64)

© 2008 Security Architecture - All Rights Reserved. GLBA

What it is:

Graham-Leach-Bliley Financial Services Modernization Act of 1999

A set of regulations governing financial data privacy Affects financial institutions and affiliated businesses working with personal financial data

Particularly addresses sharing of non-public personal information by financial institutions

Intended to allow individuals to control use and release of their personal financial information

Specifies what must be protected, and who has to safeguard it, and acceptable compliance guidelines

(65)

GLBA

What it means:

Financial institutions must disclose their privacy policies up-front and again at least annually

Requires FI’s to deliver privacy policy notices to consumers/customers to offer and describe opt-out provisions

Holds FI’s responsible for safeguarding customer data whether through normal business

operations, theft, fraud, or exceptional circumstances

(66)

© 2008 Security Architecture - All Rights Reserved. SARBANES-OXLEY

What it is:

Public Company Accounting Reform and Investor Protection (Sarbanes-Oxley) Act of 2002

A set of regulations governing financial reporting requirements for companies

Reduces the time allotted for release of earnings and other financial report data

(67)

SARBANES-OXLEY

What it means:

Senior management now requires more up-to-date understanding of all financial information

Managers must certify and be accountable for the financial reports their companies issue

Managers must describe and evaluate their internal controls for effectiveness

All findings must be certified by external auditors Many former IT responsibilities elevated to

(68)

© 2008 Security Architecture - All Rights Reserved. FISMA

What it is:

Federal Information Security Management Act (Title III of E-Government Act of 2002)

A set of organizational practices, roles, and

responsibilities for government agencies related to information security.

Applies to all federal agencies and contractors managing or maintaining federal systems.

(69)

FISMA

What it means:

All federal agencies submit annual reports on

security practices, controls, and level and extent of documentation.

Agency-level scores given based on factors such as consistent and comprehensive implementation of practices, and effective use of controls.

Responsibility for information security placed under federal CIOs, following standards and guidance produced by NIST.

(70)

© 2008 Security Architecture - All Rights Reserved. CALIFORNIA SECURITY BREACH NOTIFICATION

What it is:

SB 1386 passed in 2003 covering any person or business that conducts business in California

Requires businesses to give public notice of information security breaches resulting in disclosure of personal

information.

Notification only must occur to California residents;

however, 37 other states have now enacted similar laws Only exception is for encrypted data.

Statute applies regardless of where the data is physically stored or where the breach occurs.

(71)

EUROPEAN UNION DIRECTIVES

EU Data Protection Directive (1998)

Imposes data privacy requirements on entities that transport data across national borders.

Places data ownership and control in the hands of originating businesses.

Explicit permission for third-party data sharing

Disclosure/data sharing must be in the interest of the data subject

Applies to US companies that do business with the EU Rules in US Dept. of Commerce “safe harbor” privacy framework

(72)

© 2008 Security Architecture - All Rights Reserved. EUROPEAN UNION DIRECTIVES

EU E-Commerce Directive (2000)

Creates minimum requirements for selling to EU consumers and businesses online.

Addresses both business practices and information transparency.

Mandatory business location and contact information Reproduce-ability of online contract terms

Prompt notice of order confirmation

Local additional imposed by some EU member states

(73)

EUROPEAN UNION DIRECTIVES

EU Electronic Communications Directive (2002) Creates a framework for an EU-wide effort to regulate unsolicited electronic mail or “spam.” Prohibits businesses without pre-existing

customer relationships to solicit consumers unless they opt in.

Makes illegal the common US business practice of sharing marketing leads between affiliated

companies.

Also constrains the use of “cookies” without explicit consumer notification.

(74)

© 2008 Security Architecture - All Rights Reserved.

WORKSHOP #4

9 Task: Determine what regulatory or other governing principles apply to our organization. Write a customer or public notification communicating the relevant policy.

(75)
(76)

© 2008 Security Architecture - All Rights Reserved. SECTION OBJECTIVES

1. Define and explain major information security standards relevant to policy. 2. Identify sources of information to help

guide policy and standard development.

(77)

Examples of Standards

ISO/IEC 27001 and 27002 (ISO 17799) Common Criteria

NIST 800 Series of Special Publications NIST Federal Information Processing Standards (FIPS)

(78)

© 2008 Security Architecture - All Rights Reserved. ISO/IEC 27001 & 27002

The ISO/IEC 27000 series is a comprehensive set of

controls comprising best practices in information security. It is an internationally recognized information security

standard, broad in scope and generic in applicability. It focuses on risk identification, assessment and

management. It is aligned with common business goals:

Ensure business continuity Minimize business damage

Maximized return on investments

It is about information security, not IT security. It is much more commonly applied in commercial organizations than in government.

(79)

ISO/IEC 27001 & 27002 (from ISO 17799)

Originally created as BS17799, this framework was first submitted in 1995, and revised in 1998, but was not

adopted by the International Standards Organization until 1999 .

Significantly revised in 2005, it was formally converted to two related International Standards

Organization/International Electrotechnical Commission (ISO/IEC) standards, 27001 & 27002.

ISO 17799 covers both security management practices and security controls.

Somewhat confusingly, what had been referred to as Part 1 and Part 2 in the 17799 standard were numerically reversed in the new ISO/IEC numbering, so that Part 1 becomes

(80)

© 2008 Security Architecture - All Rights Reserved. THE STANDARD

Part 1 – Code of Practice

ISO 17799 (became ISO 27002 in July 2007) provides 133 security controls under 39 security

categories organized into 11 major clauses to identify the particular safeguards that are appropriate to their particular business.

These security controls correspond to hundreds of more detailed

technologies, measures, and elements of practice.

The standard stresses the importance of risk management and makes it clear that you do not have to

implement every single guideline; only those that are relevant.

Part 2 – IS Management Standard

ISO/IEC 27001 tells how to build an Information Security Management System. It defines a four-step process instructing you how to apply ISO/IEC 17799 and how to establish,

implement, monitor, and maintain an

ISMS.

It is a formal methodology for setting up an information security management system.

ISO/IEC 27001 establishes guidelines and general principles for initiating, implementing, maintaining, and improving information security management in an organization.

(81)

THE INFORMATION SECURITY MANAGEMENT SYSTEM

ISO 27001 provides a comprehensive process reference for establishing and operationalizing and information security management system. “System” in this context means a set of explicit, standard, repeatable processes and activities, and not necessarily a hardware- or software-based

mechanism.

There are numerous vendor tools on the market intended to implement an ISMS according to the ISO 27001 standard.

(82)

© 2008 Security Architecture - All Rights Reserved. THE ISMS MODEL: PLAN-DO-CHECK-ACT

Phase ISMS Action Description

Plan Establish Establish ISMS policy, objectives, processes and procedures relevant to managing risk and improving information security to deliver results in accordance with an

organization’s overall policies and objectives. Do Implement and Operate Implement and operate the ISMS policy,

controls, processes and procedures. Check Monitor and Review Assess and, where applicable, measure

process performance against ISMS policy, objectives and practical experience and report the results to management for review.

Act Maintain and Improve Take corrective and preventive actions, based on the results of the internal ISMS audit and management review or other relevant information, to achieve continual improvement of the ISMS.

(83)

ISO/IEC 27001

Adopts a process approach for establishing, implementing, operating, monitoring, reviewing, maintaining and improving an organization's Information Security Management System (ISMS).

The approach presented in ISO 27001 encourages its users to emphasize the importance of:

a) understanding an organization’s information security requirements and the need to establish policy and objectives for information security;

b) implementing and operating controls to manage an organization's information security risks in the context of the organization’s overall business risks;

c) monitoring and reviewing the performance and effectiveness of the ISMS; and

d) continual improvement based on objective measurement.

Reflects the principles articulated in the Guideline for the Security of Information Systems and Networks, published in 2002 by the

(84)

© 2008 Security Architecture - All Rights Reserved. ISO/IEC 27001 PROCESS APPROACH

Information security management system

General requirements

Establishing and managing the ISMS

Establish the ISMS

Implement and operate the ISMS

Monitor and review the ISMS Maintain and improve the ISMS Documentation requirements General Control of documents Control of records Management responsibility Management commitment Resource management Provision of resources Training, awareness and competence

Internal ISMS audits

Management review of the ISMS General Review input Review output ISMS improvement Continual improvement Corrective action Preventive action

The ISO 27001 standard presents a concise (process steps contained in just 10 pages) prescription for information security management.

(85)

ISO 27002 CLAUSES

The 11 clauses (with the number of main security categories included within each clause) are:

Security Policy (1)

Organizing Information Security (2) Asset Management (2)

Human Resources Security (3)

Physical and Environmental Security (2)

Communications and Operations Management (10) Access Control (7)

Information Systems Acquisition, Development and Maintenance (6) Information Security Incident Management (2)

Business Continuity Management (1) Compliance (3)

ISO 27002 also has a preliminary section of Risk Assessment and

(86)

© 2008 Security Architecture - All Rights Reserved. COMMON CRITERIA

Provides a basis for evaluating security properties of IT products and systems. Sections:

1. Introduction & General Model

2. Security Functional Requirements 3. Security Assurance Requirements

(87)

COMMON CRITERIA – PART 1

Defines general concepts & principles

Presents constructs for expressing security objectives and defining requirements

(88)

© 2008 Security Architecture - All Rights Reserved. COMMON CRITERIA – PART 2

Established a set of functional components as a standard way of expressing the

functional requirements for evaluated systems

Used for guidance when formulating

statements of requirements for security functions

(89)

COMMON CRITERIA – PART 3

Establishes a set of assurance components as a standard way of expressing the

assurance requirements for evaluated systems

Catalogs the set of assurance components, facilities & classes

Used when determining required levels of assurance

(90)

© 2008 Security Architecture - All Rights Reserved. COMMON CRITERIA: RELATIONSHIPS

Countermeasures Threats Vulnerabilities Risk Assets value wish to minimize impose may be reduced by leading to may contain exploit to reduce may be aware of Owners Threat

Agents wish to abuse and/or damage give rise to

to

that increase

to

(91)

NIST 800 SERIES

A set of guidelines covering a broad range of security topics, from high-level planning and security practices, to detailed

treatment of specific technologies

The government’s take at “best practices”

Primary focus for Certification & Accreditation requirements, especially in the federal civilian arena.

Targeted at federal agencies, but useful commercially too.

(92)

© 2008 Security Architecture - All Rights Reserved. NIST 800 SERIES

General security practices:

800-14 (Securing IT systems) 800-16 (Security training)

800-18 (Security plans)

800-30 (Risk management)

800-34 (Contingency planning)

800-37 (Certification & Accreditation) 800-53A (Security assessment)

800-64 (Security in the SDLC)

800-100 (Information Security Handbook) 800-115 (Security testing)

(93)

NIST 800 SERIES

Focused security practices: 800-3 (Incident response) 800-9 (E-commerce)

800-21 (Implementing cryptography)

800-23 (Security assurance & acquisition) 800-40 (Patch handling)

800-44 (Securing public web servers) 800-88 (Media sanitization)

800-92 (Security log management) 800-95 (Secure web services)

(94)

© 2008 Security Architecture - All Rights Reserved. NIST 800 SERIES

Security technology guidelines: 800-25 (Digital signatures)

800-31 (IDS)

800-32 (Federal PKI) 800-41 (Firewalls)

800-45 (Email security)

800-48 (Wireless network security) 800-77 (IPSec VPNs)

800-94 (IDS and IPS systems) 800-113 (SSL VPNs)

800-123 (Server security)

(95)

FEDERAL INFORMATION PROCESSING STANDARDS (FIPS)

Mandatory Security Standards: FIPS 140 (Cryptographic modules)

FIPS 186 (Digital signature standard)

FIPS 191 (Local area network (LAN) security)

FIPS 197 (Advanced encryption standard (AES)) FIPS 199 (Security categorization)

FIPS 200 (Minimum security requirements) FIPS 201 (Personal identity verification)

(96)

© 2008 Security Architecture - All Rights Reserved.

WORKSHOP #5

9 Task: Select an appropriate standard for use in implementing our organization’s security policies. Write a standard for vendor

selection, keeping Defense in Depth principles in mind.

(97)
(98)

© 2008 Security Architecture - All Rights Reserved. SECTION OBJECTIVES

1. Define policy hierarchy.

2. Identify key policy documents. 3. Describe major policy topics.

4. Present functional policy scope. 5. Present technical policy scope.

(99)

POLICY DEVELOPMENT

Effective security policy implementation rests with the guidelines and procedures that translate security policies and

(100)

© 2008 Security Architecture - All Rights Reserved. POLICY HIERARCHY

Information security policy applies at many inter-related levels:

Corporate or agency-wide

Department or business unit Functional processes

Technical measures

(101)

ENTERPRISE POLICY MANAGEMENT

Eliminate unwanted users, computers, and applications from the enterprise

Protect users, computers, and applications from compromise

(102)

© 2008 Security Architecture - All Rights Reserved. KEY POLICY DOCUMENTS

Security Policies and Procedures Manual (SPPM)

Security Administrator Manual (SAM) Information Security Plan

(103)

SECURITY POLICIES AND PROCEDURES MANUAL

Consolidated security policy reference Serves as authoritative source/record Policies address what is to be done

(104)

© 2008 Security Architecture - All Rights Reserved. SECURITY ADMINISTRATOR MANUAL

Administrative reference for security staff Emphasis on operational guidelines

Addresses major administrative procedures

Monitoring and alerting

Notification and incident response Backup and recovery

Systems and penetration testing

(105)

INFORMATION SECURITY PLAN

Enterprise-wide strategic and tactical plan May be part of corporate IT Plan

Should correlate directly to business strategic plan

Must be available and accessible First place auditors go to

(106)

© 2008 Security Architecture - All Rights Reserved. POLICY COMPONENTS

Statement of Purpose Scope

Roles and Responsibilities

Effective Implementation and Review Dates

Specified Security Practices

(107)

POLICY TOPICS

Asset Classification and Control Access Control Privacy Organizational Practices Systems Development Incident Response Communications

Physical Security and Operations

(108)

© 2008 Security Architecture - All Rights Reserved. SUGGESTED DEVELOPMENT PRIORITY

Information Security Policies

Overarching statement from senior mgmt

Cover the 11 domains, 39 control areas (ISO 27002)

Access & Identification Security Policies Technology & Communications Policies Support & Operations Security Policies

Physical & Environmental Security Policies

(109)

FUNCTIONAL POLICIES Acceptable use Incident response Disaster recovery Privacy Awareness Change management

(110)

© 2008 Security Architecture - All Rights Reserved. ACCEPTABLE USE

Coverage and responsibility Internal and external uses Data ownership

Data protection requirements

Personal use of corporate systems

(111)

INCIDENT RESPONSE

Coverage: known and unknown threats Prioritization/criticality

Incident response team

Incident response procedures Discovery

Notification Escalation

(112)

© 2008 Security Architecture - All Rights Reserved. DISASTER RECOVERY

Defining disasters Coverage

Recovery time

Supporting processes (e.g. backup, off-site)

DR team

Recovery procedures Test plan

(113)

PRIVACY

Scope

Internal and external requirements Data stewardship

Levels of protection needed

(114)

© 2008 Security Architecture - All Rights Reserved. AWARENESS Policy distribution Awareness training Communication plan Compliance expectations Non-compliance consequences Sign-off 113

(115)

CHANGE MANAGEMENT

Scope and coverage

Change request procedures

Change management decision making Thresholds for escalation

(116)

© 2008 Security Architecture - All Rights Reserved. TECHNICAL POLICIES Access control Anti-virus Identity management Intrusion detection/protection Application security Email Encryption

Web server configuration

(117)

ACCESS CONTROL

Mandatory/discretionary access

Role-based and/or resource-based Authentication and authorization Remote access

(118)

© 2008 Security Architecture - All Rights Reserved. ANTI-VIRUS

Coverage (local, wide-area, remote) Potential points/sources of infection Use of AV software

AV gateways (e.g. email servers) Update requirements

Patch management Mobile devices

(119)

IDENTITY MANAGEMENT

User provisioning

User de-provisioning

Authorization and identification

Credentialing (issue and revocation) Password policies

(120)

© 2008 Security Architecture - All Rights Reserved. INTRUSION DETECTION/PREVENTION

IDS/IPS placement within the architecture Event logging, monitoring, and correlation Intrusion notification and response

Internal and external protection Network IDS

Host IDS

(121)

APPLICATION SECURITY

Application coverage

Network-level protection (e.g. application proxy firewalls)

Coding requirements Parameter validation Session management Authorization

(122)

© 2008 Security Architecture - All Rights Reserved. EMAIL Usage parameters Monitoring Archiving requirements Remote access Email integrity Attachment handling 121

(123)

ENCRYPTION

Required and recommended use

Strength required/approved algorithms Authentication

Accountability/Non-repudiation Data protection

Information in transit Information at rest

(124)

© 2008 Security Architecture - All Rights Reserved. WEB SERVER CONFIGURATION

Server placement within architecture Required services and ports available Process permissions (e.g. “run-as”) General access control

Administrative access control

(125)
(126)

© 2008 Security Architecture - All Rights Reserved. SECTION OBJECTIVES

1. Describe policy writing process. 2. Review major policy categories.

3. Outline one policy area from each category.

4. Understand by example guideline structure and content.

(127)

POLICY WRITING

Get broad involvement in the process Department representatives

Legal

Human resources

Information Technology Audit and compliance

(128)

© 2008 Security Architecture - All Rights Reserved. POLICY WRITING

Gather the requirements that drive policy Business objectives Regulatory requirements Functional requirements Technical requirements User requirements 127

(129)

POLICY WRITING

Be clear

Policies should be well written State policies succinctly

Leave no room for misinterpretation Emphasize brevity where you can

(130)

© 2008 Security Architecture - All Rights Reserved. POLICY WRITING

Avoid naming specific technologies

Classes of technology may be appropriate Vendors or products appear in standards

Granular policies and procedures may need to be tied to a specific technology (e.g. operating system)

Technical standards compliance may be specified for products (e.g. FIPS 140-2)

(131)

POLICY WRITING

Educate the organization

Even the most appropriate policies are

ineffective if they are not communicated and understood

Adherence requires awareness Policies need distribution

(132)

© 2008 Security Architecture - All Rights Reserved. POLICY WRITING

Policies are living documents

Policy is a process, not a one-time initiative Review and revision cycles are part of policy Keeping current is essential

Interdependencies mean that changes in one area need to be examined for impacts to others

(133)

POLICY WRITING

Policies must be enforced

Non-compliance comes with consequences Actions back up words

(134)

© 2008 Security Architecture - All Rights Reserved. POLICY WRITING

Tools are available to facilitate policy creation

PoliVec Policy Builder

NetIQ/PentaSafe VigilEnt Policy Center Symantec Enterprise Security Manager Information Shield PolicyShield

BindView (now also part of Symantec)

(135)

INFORMATION SECURITY POLICIES Data classification Acceptable use Data protection Privacy Risk Management

(136)

© 2008 Security Architecture - All Rights Reserved. RISK MANAGEMENT Introduction Authority Purpose Objectives Target Audience Related Policies 135

(137)

RISK MANAGEMENT

Overview

Importance of Risk Management Governing regulations

Incorporating Risk Management into IT Processes

(138)

© 2008 Security Architecture - All Rights Reserved. RISK MANAGEMENT

Risk Assessment

System identification and characterization Threat identification Vulnerability identification Control Analysis Likelihood determination Impact Analysis Risk determination 137

(139)

RISK MANAGEMENT

Risk Mitigation Options

Strategy

Controls and implementation Cost-benefit analysis

(140)

© 2008 Security Architecture - All Rights Reserved. ACCESS & IDENTIFICATION POLICIES

Authentication Authorization PKI Biometrics Digital signatures 139

(141)

DIGITAL SIGNATURES

Purpose and objectives Background and scope

Applicability to electronic services Public Key technology and PKI

Usage of certificates Certification process

(142)

© 2008 Security Architecture - All Rights Reserved. TECHNOLOGY & COMMUNICATION POLICIES

Firewall Anti-virus Email

Mobile Data Protection Encryption

Intrusion detection/intrusion protection Web server configuration

Network connectivity

(143)

WEB SERVER CONFIGURATION

Introduction Authority

Purpose and scope Target audience

(144)

© 2008 Security Architecture - All Rights Reserved. WEB SERVER CONFIGURATION

Planning and management

Planning a web server deployment Security management staffing

Management practices System security plan Web server platforms

(145)

WEB SERVER CONFIGURATION

Secure installation and configuration Network placement

Installing and configuring the OS Testing the OS

Platform security resources and responsibility Installing and configuring the web server

(146)

© 2008 Security Architecture - All Rights Reserved. WEB SERVER CONFIGURATION

Secure web access

Security of web content

Collection of personal information Active and dynamic content controls Authentication requirements

Data integrity requirements Encryption requirements

(147)

WEB SERVER CONFIGURATION

Web server administration Logging and monitoring

Backup and restore procedures Security/penetration testing plan Intrusion/compromise recovery Remote administration

(148)

© 2008 Security Architecture - All Rights Reserved. WEB SERVER CONFIGURATION

Web server administration Logging and monitoring

Backup and restore procedures Security/penetration testing plan Intrusion/compromise recovery Remote administration

(149)

SUPPORT & OPERATIONS SECURITY POLICIES Incident response Event correlation Disaster recovery Business continuity Security awareness Change management

(150)

© 2008 Security Architecture - All Rights Reserved. INCIDENT RESPONSE

Overview Purpose

Coverage and responsibility Current threat environment Need for incident response

Proactive and reactive postures

Incident response interaction with other areas

(151)

INCIDENT RESPONSE

Establishing an Incident Response Team Goals and objectives

Constituencies served IRT structure

Management support and accountability Standard operating procedures handbook Staffing the team

(152)

© 2008 Security Architecture - All Rights Reserved. INCIDENT RESPONSE

Operations

Communications plan Logging and monitoring Incident notification

Legal obligations

Public/media disclosure policy Post-incident analysis

(153)

PHYSICAL & ENVIRONMENTAL POLICIES

Building/facility access Perimeter security

(154)

© 2008 Security Architecture - All Rights Reserved. FACILITY ACCESS

Purpose and objectives Coverage and scope

Individual and management responsibility Zone classification

Access control provisions

Employee and contractor access rules Credentialing and revocation

(155)

GUIDELINES

Guidelines explain how policies and standards will be achieved.

Specific to operational practices and technologies

May include educational information Topical descriptions and definitions Tips and tricks, lessons learned

(156)

© 2008 Security Architecture - All Rights Reserved. GUIDELINES: REAL-WORLD EXAMPLE

Take as an example, NIST Special

Publication 800-41, “Guidelines on Firewalls and Firewall Policy”

Introduction

Purpose and scope

Audience and assumptions Document organization

(157)

GUIDELINES: REAL-WORLD EXAMPLE

Overview of Firewall Platforms Intro to Firewall Technology Packet Filter Firewalls

Stateful Inspection Firewalls

Application Proxy Gateway Firewalls Dedicated Proxy Servers

Hybrid Firewall Technologies Network Address Translation Host-based Firewalls

(158)

© 2008 Security Architecture - All Rights Reserved. GUIDELINES: REAL-WORLD EXAMPLE

Firewall Environments

Guidelines for Building Firewall Environments DMZ Networks

Virtual Private Networks Intranets

Extranets

Infrastructure Components: Hubs and Switches Intrusion Detection Systems

Domain Name Service (DNS)

Placement of Servers in Firewall Environments

(159)

GUIDELINES: REAL-WORLD EXAMPLE

Firewall Security Policy

Firewall Policy

Implementing a Firewall Ruleset Testing Firewall Policy

Firewall Implementation Approach Firewall Maintenance & Management

Physical Security Of The Firewall Environment

Periodic Review Of Information Security Policies A Sample Topology and Ruleset

(160)

© 2008 Security Architecture - All Rights Reserved. GUIDELINES: REAL-WORLD EXAMPLE

Firewall Administration

Access To The Firewall Platform

Firewall Platform Operating System Builds Firewall Failover Strategies

Firewall Logging Functionality Security Incidents

Firewall Backups

Function-Specific Firewalls

(161)

PROCEDURES

Step-by-step recipe for how to implement and configure security measures

Explicit documentation from both the

vendor and the implementing organization Technology specific

(162)

© 2008 Security Architecture - All Rights Reserved. POLICY IMPLEMENTATION: REAL-WORLD EXAMPLE

Filtering (varies by type of firewall):

Physical location of packet (inside/outside perimeter) Source address

Destination address

Type of TCP/IP application (service, port) Relationship to other packets

Application function content (e.g., GET, PUT)

Action/Result:

Accept: allow packet to pass through Drop: deny access; no response

Deny/Reject: deny access; respond with ICMP echo

Logging

(163)

POLICY IMPLEMENTATION: REAL-WORLD EXAMPLE

Access control rules are processed in order Once a rule is satisfied, no other rules are

checked - packet is either accepted or denied depending on the rule

If no rules are satisfied, the packet is denied (default for most firewalls)

Complex and/or poor sequencing of policies rules that result in packets to be accepted may create security vulnerabilities

(164)

© 2008 Security Architecture - All Rights Reserved. POLICY IMPLEMENTATION: REAL-WORLD EXAMPLE

(165)

WORKSHOP #7

(166)

SECURITY POLICY

(167)

WHY DO WE NEED POLICY?

Compliance

Exceed Industry Practices Response

(168)

© 2008 Security Architecture - All Rights Reserved. WHY: COMPLIANCE

Health Insurance Portability and Accountability Act (HIPAA)

Health Care Industry

Graham-Leach-Bliley Act (GLBA) Financial services institutions

“Reasonable man” measure

Businesses are legally obligated to install well-known safety measures to protect against well-known threats Limit liability

Complex system of federal, state, and sector-specific laws

(169)

WHY: INDUSTRY PRACTICES

Certification and accreditation Standards certification

ISO/IEC

Common Criteria

(170)

© 2008 Security Architecture - All Rights Reserved. WHY: RESPONSE

Incident response

Event management, correlation, and response

Disaster response and recovery

(171)

WHY: RISK ASSESSMENT

Risk analysis and mitigation Audit and assessment

(172)

SECURITY POLICY

(173)

CERT (www.cert.org)

What is it?

Computer Emergency Response Team

Run by the Software Engineering Institute (SEI) at Carnegie Mellon

Tracks and publishes threats and vulnerabilities Maintains databases of practices and

(174)

© 2008 Security Architecture - All Rights Reserved. US-CERT (www.uscert.gov)

What is it?

United States Computer Emergency Readiness Team

Run by US Dept. of Homeland Security

Federal agencies required to notify US-CERT of breaches within one hour of discovery

Point of interaction/communication between

federal cyber security interests, the public, and private sector entities

(175)

DITSCAP/DIACAP

What is it?

DoD Information Technology Security Certification and Accreditation Process

(superceded by DoD Information Assurance Certification and Accreditation Process

Primarily applies in the defense part of the public sector

Formal structure specifies six sections and 18 appendices

Many of the DITSCAP requirements are related to policy

(176)

© 2008 Security Architecture - All Rights Reserved. PRIVACY REGULATIONS

Alston-Bird (www.alston.com)

Intellectual Property and Privacy practices Online privacy library

Summary reports on global regulations and legislation

International Association of Privacy Professionals (www.privacyassociation.org)

Tracks information privacy practices, laws, and developments worldwide

Training and certifications in privacy (CIPP)

(177)

POLICY DEVELOPMENT

Charles Cresson Wood

Information Security Policies Made Easy (v.9)

www.infosecurityinfrastructure.com

Also titles on roles and responsibilities, e-commerce, security controls, etc.

(178)

SECURITY POLICY

Stephen Gantz CISSP-ISSAP, CEH, CGEIT

Principal Architect

References

Related documents

A statistically significant negative correlation was dem- onstrated in the study cohort between the maternal serum PIGF levels, foetal heart rate (FHR), birth weight and length,

When the fields of the Form(s) for a step are defined, a default page template is generated by Bonita Open Solution and linked with an html file that directs how the Form is to be

(1990) The Competitive Advantage of Nations, Free Press, New York. Winning the race for talent in emerging markets. From the editors: Endogeneity in international

UPnP Control Point (DLNA) Device Discovery HTTP Server (DLNA, Chormecast, AirPlay Photo/Video) RTSP Server (AirPlay Audio) Streaming Server.. Figure 11: Simplified

The wild fish receiving building effluent microscreen filtration and UV irradiation equipment are also performing well, as indicated by the water quality data for TSS, UV

Each case study consists of one building, which was scaled up or down in order to make fair comparisons of the GHG emissions attributed to the technical systems with increased

We made the following three hypotheses: (1) individuals with normal aging would present hyper-activation in the frontopari- etal network and default mode network and hypo-activation

Since these intermediate galaxies are a subset of the quiescent population, we can use the stellar synthesis models to constrain the size and frequencies of the required bursts of