© 2008 Security Architecture - All Rights Reserved.
SECURITY POLICY
© 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
1
SECURITY POLICY
SECTION 1: WHY POLICY?
© 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.
3
© 2008 Security Architecture - All Rights Reserved.
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.
4
© 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.
5
© 2008 Security Architecture - All Rights Reserved.
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.
6
© 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
7
© 2008 Security Architecture - All Rights Reserved.
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
BusinessRequirements
ExecMgmt
8
© 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.
9
© 2008 Security Architecture - All Rights Reserved.
WHAT IS POLICY?
Security policy addresses:
Employee behavior
Business practices
Risk management
Operations
Technical measures
10
© 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
11
© 2008 Security Architecture - All Rights Reserved.
BUSINESS PRACTICES
Acceptable use policy
External communications policy
Transaction security policy
Privacy policy
Change management
Security planning
Regulatory compliance
12
© 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
13
© 2008 Security Architecture - All Rights Reserved.
OPERATIONS
Acceptable use policy
Email and communications policy
Network and security monitoring
Incident response
Access control policy
Physical security
14
© 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
15
© 2008 Security Architecture - All Rights Reserved.
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.
16
© 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
17
© 2008 Security Architecture - All Rights Reserved.
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
18
© 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
19
© 2008 Security Architecture - All Rights Reserved.
DEFENSE IN DEPTH
Operations
Day-to-day activities to maintain security posture:
Security managementMonitoring and event managementReadiness assessments and testingCertification and accreditationIntrusion detection, alerting, and responsePatch managementTraining
20
© 2008 Security Architecture - All Rights Reserved.
DEFENSE IN DEPTH
Security layers form a concentric set of boundaries:
Network Infrastructure
Computing Platforms
Application Environment
21
© 2008 Security Architecture - All Rights Reserved.
DEFENSE IN DEPTH
Multiple Controls Across Multiple Layers
Physical SecurityLocks 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
22
© 2008 Security Architecture - All Rights Reserved.
LEADING INFOSEC INVESTMENTS
Network Security
Distributed security controlsPolicy and configuration enforcement (NAC)Event monitoring and management (SIEM)
User Management
User provisioning/identity managementSingle sign-on
Content Security
Anti-virus/anti-spywareContent filtering and spam controlData loss protection
23
© 2008 Security Architecture - All Rights Reserved.
INTRO WORKSHOP
Task: Build class company situation addressing industry, structure, operations areas, and user communities.
24
SECURITY POLICY
SECTION 2: INFORMATION SECURITY POLICY
© 2008 Security Architecture - All Rights Reserved.
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.
4. Introduce security policy processes.
26
© 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
27
© 2008 Security Architecture - All Rights Reserved.
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.
28
© 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
29
© 2008 Security Architecture - All Rights Reserved.
HOW THEY RELATE
PolicyGovernance“Thou Shall”
What Management wants to achieve and why.
StandardsDesired Mechanisms
Technical specification of how to implement policy
ProcedureSteps to carry outDetailed instructions
Guidelines
How to deal with new & unusual situations
30
© 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
31
© 2008 Security Architecture - All Rights Reserved.
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, technology and operations
32
© 2008 Security Architecture - All Rights Reserved.
WORKSHOP #1
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
© 2008 Security Architecture - All Rights Reserved.
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
34
© 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
35
© 2008 Security Architecture - All Rights Reserved.
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•Compliance monitoring
Periodic Review:•Incidents•Audit•Controls effectiveness
PolicyMgmt
36
© 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
37
© 2008 Security Architecture - All Rights Reserved.
POLICY CATEGORIES
Information Security
Computer security policy
Program policy
Issue-specific policy
System-specific policy
General Business
HR policies
Travel policy
Time and expense policy
38
© 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
39
© 2008 Security Architecture - All Rights Reserved.
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.
Local issues resolved by standards, guidelines, and other supporting documents ?
40
© 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
41
© 2008 Security Architecture - All Rights Reserved.
WORKSHOP #2
Task: Fill out the 3 outlines from WS#1 with the contents on the previous slide.
42
SECURITY POLICY
SECTION 3: POLICY IN CONTEXT
© 2008 Security Architecture - All Rights Reserved.
SECTION OBJECTIVES
1. Show policy’s role within an information security program.
2. Explain the steps in the management of the information security program.
44
© 2008 Security Architecture - All Rights Reserved.
SECURITY MANAGEMENT FRAMEWORK
Information Security ManagementISO/IEC 27001 & 27002
Enterprise Security Policies
Standards & Guidelines
Compliance, Monitoring & Audits
BestPractices
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
© 2008 Security Architecture - All Rights Reserved.
POLICIES & TECHNICAL ARCHITECTURE
Policy Definition
Policies
PersonnelStatutory
Program MgmtSecurity Incident
Info ClassificationSystems Life CyclePhysical & Environ
AuditTelecomLogical AccessId / Auth / AuthRemote AccessComputer SystemsSupport & Operations
Guidelines Standards
Tech Controls Risk Mgmt
Inventory Asset Ownership
Assessment Analysis
Technical Security Architecture
Engineering Analysis & Design Solution Selection
46
© 2008 Security Architecture - All Rights Reserved.
INFORMATION SECURITY PROGRAM
TechnologyIntegration
Operations,Administration & Control
Audit &Review
ProcessPrototyping& Elaboration
Policy
Design Assess
Deploy Manage &Support
47
© 2008 Security Architecture - All Rights Reserved.
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
48
© 2008 Security Architecture - All Rights Reserved.
THE ISMS (ISO 27001) MODEL
Establishthe ISMS
Maintain and Improve the
ISMS
Implementand Operate
the ISMS
Monitor and Review the
ISMS
Plan
Do
Check
Act
InformationSecurity Requirements
and Expectations
Managed InformationSecurity & Operations
49
Policy
© 2008 Security Architecture - All Rights Reserved.
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.
50
© 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
51
© 2008 Security Architecture - All Rights Reserved.
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
52
© 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
53
© 2008 Security Architecture - All Rights Reserved.
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
54
© 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
55
© 2008 Security Architecture - All Rights Reserved.
WORKSHOP #3
Task: Write a security awareness policy to communicate the information security program to employees. How would this differ for customers? (to be revisited…)
56
SECURITY POLICY
SECTION 4: REGULATORY DRIVERS
© 2008 Security Architecture - All Rights Reserved.
SECTION OBJECTIVES
1. Define and explain major regulatory requirements affecting policy.
2. Understand which and what type of regulations impact your organization.
58
© 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.
59
© 2008 Security Architecture - All Rights Reserved.
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
60
© 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.
61
© 2008 Security Architecture - All Rights Reserved.
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
62
© 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
63
© 2008 Security Architecture - All Rights Reserved.
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
64
© 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
65
© 2008 Security Architecture - All Rights Reserved.
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 business management
66
© 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.
67
© 2008 Security Architecture - All Rights Reserved.
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.
68
© 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.
69
© 2008 Security Architecture - All Rights Reserved.
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
70
© 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
71
© 2008 Security Architecture - All Rights Reserved.
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.
72
© 2008 Security Architecture - All Rights Reserved.
WORKSHOP #4
Task: Determine what regulatory or other governing principles apply to our organization. Write a customer or public notification communicating the relevant policy.
73
SECURITY POLICY
SECTION 5: POLICY STANDARDS
© 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.
75
© 2008 Security Architecture - All Rights Reserved.
Examples of Standards
ISO/IEC 27001 and 27002 (ISO 17799)
Common Criteria
NIST 800 Series of Special Publications
NIST Federal Information Processing Standards (FIPS)
76
© 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.
77
© 2008 Security Architecture - All Rights Reserved.
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 27002 and Part 2 becomes 27001.
78
© 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.
79
© 2008 Security Architecture - All Rights Reserved.
THE INFORMATION SECURITY MANAGEMENT SYSTEM
ISO 27001 provides a comprehensive process reference for establishing and operationalizingand 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.
80
© 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.
81
© 2008 Security Architecture - All Rights Reserved.
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 Organisation for Economic Co-operation and Development (OECD)
82
© 2008 Security Architecture - All Rights Reserved.
ISO/IEC 27001 PROCESS APPROACH
Information security management system
General requirements
Establishing and managing the ISMS
Establish the ISMSImplement and operate the ISMS Monitor and review the ISMSMaintain and improve the ISMS
Documentation requirementsGeneralControl of documents Control of records
Management responsibility Management commitment
Resource management Provision of resourcesTraining, awareness and competence
Internal ISMS audits
Management review of the ISMSGeneralReview inputReview output
ISMS improvementContinual improvementCorrective actionPreventive action
The ISO 27001 standard presents a concise (process steps contained in just 10 pages) prescription for information security management.
83
© 2008 Security Architecture - All Rights Reserved.
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 Treatment, but does not include this topic among the security clauses.
84
© 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
85
© 2008 Security Architecture - All Rights Reserved.
COMMON CRITERIA – PART 1
Defines general concepts & principles
Presents constructs for expressing security objectives and defining requirements
Used for background information
86
© 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
87
© 2008 Security Architecture - All Rights Reserved.
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
88
© 2008 Security Architecture - All Rights Reserved.
COMMON CRITERIA: RELATIONSHIPS
Countermeasures
Threats
Vulnerabilities Risk
Assets
valuewish 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
89
© 2008 Security Architecture - All Rights Reserved.
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.
90
© 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)
91
© 2008 Security Architecture - All Rights Reserved.
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)800-97 (Wireless security)
92
© 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)
93
© 2008 Security Architecture - All Rights Reserved.
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)
94
© 2008 Security Architecture - All Rights Reserved.
WORKSHOP #5
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.
95
SECURITY POLICY
SECTION 6: POLICY DEVELOPMENT
© 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.
97
© 2008 Security Architecture - All Rights Reserved.
POLICY DEVELOPMENT
Effective security policy implementation rests with the guidelines and procedures that translate security policies and standards into practice.
98
© 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
99
© 2008 Security Architecture - All Rights Reserved.
ENTERPRISE POLICY MANAGEMENT
Eliminate unwanted users, computers, and applications from the enterprise
Protect users, computers, and applications from compromise
Enforce safe and correct behavior
100
© 2008 Security Architecture - All Rights Reserved.
KEY POLICY DOCUMENTS
Security Policies and Procedures Manual (SPPM)
Security Administrator Manual (SAM)
Information Security Plan
101
© 2008 Security Architecture - All Rights Reserved.
SECURITY POLICIES AND PROCEDURES MANUAL
Consolidated security policy reference
Serves as authoritative source/record
Policies address what is to be done
Procedures specific how to do it
102
© 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
103
© 2008 Security Architecture - All Rights Reserved.
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
104
© 2008 Security Architecture - All Rights Reserved.
POLICY COMPONENTS
Statement of Purpose
Scope
Roles and Responsibilities
Effective Implementation and Review Dates
Specified Security Practices
105
© 2008 Security Architecture - All Rights Reserved.
POLICY TOPICS
Asset Classification and Control
Access Control
Privacy
Organizational Practices
Systems Development
Incident Response
Communications
Physical Security and Operations
Business Continuity and Disaster Recovery
106
© 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
107
© 2008 Security Architecture - All Rights Reserved.
FUNCTIONAL POLICIES
Acceptable use
Incident response
Disaster recovery
Privacy
Awareness
Change management
108
© 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
109
© 2008 Security Architecture - All Rights Reserved.
INCIDENT RESPONSE
Coverage: known and unknown threats
Prioritization/criticality
Incident response team
Incident response procedures
Discovery
Notification
Escalation
Communication
110
© 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
111
© 2008 Security Architecture - All Rights Reserved.
PRIVACY
Scope
Internal and external requirements
Data stewardship
Levels of protection needed
Communication/notification plan
112
© 2008 Security Architecture - All Rights Reserved.
AWARENESS
Policy distribution
Awareness training
Communication plan
Compliance expectations
Non-compliance consequences
Sign-off
113
© 2008 Security Architecture - All Rights Reserved.
CHANGE MANAGEMENT
Scope and coverage
Change request procedures
Change management decision making
Thresholds for escalation
114
© 2008 Security Architecture - All Rights Reserved.
TECHNICAL POLICIES
Access control
Anti-virus
Identity management
Intrusion detection/protection
Application security
Encryption
Web server configuration
115
© 2008 Security Architecture - All Rights Reserved.
ACCESS CONTROL
Mandatory/discretionary access
Role-based and/or resource-based
Authentication and authorization
Remote access
116
© 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
117
© 2008 Security Architecture - All Rights Reserved.
IDENTITY MANAGEMENT
User provisioning
User de-provisioning
Authorization and identification
Credentialing (issue and revocation)
Password policies
118
© 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
119
© 2008 Security Architecture - All Rights Reserved.
APPLICATION SECURITY
Application coverage
Network-level protection (e.g. application proxy firewalls)
Coding requirements
Parameter validation
Session management
Authorization
120
© 2008 Security Architecture - All Rights Reserved.
Usage parameters
Monitoring
Archiving requirements
Remote access
Email integrity
Attachment handling
121
© 2008 Security Architecture - All Rights Reserved.
ENCRYPTION
Required and recommended use
Strength required/approved algorithms
Authentication
Accountability/Non-repudiation
Data protection
Information in transit
Information at rest
122
© 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
123
SECURITY POLICY
SECTION 7: WRITING POLICIES
© 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.
125
© 2008 Security Architecture - All Rights Reserved.
POLICY WRITING
Get broad involvement in the process
Department representatives
Legal
Human resources
Information Technology
Audit and compliance
126
© 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
© 2008 Security Architecture - All Rights Reserved.
POLICY WRITING
Be clear
Policies should be well written
State policies succinctly
Leave no room for misinterpretation
Emphasize brevity where you can
128
© 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)
129
© 2008 Security Architecture - All Rights Reserved.
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
Employees need training
130
© 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
131
© 2008 Security Architecture - All Rights Reserved.
POLICY WRITING
Policies must be enforced
Non-compliance comes with consequences
Actions back up words
Enforcement has to be consistent
132
© 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)
133
© 2008 Security Architecture - All Rights Reserved.
INFORMATION SECURITY POLICIES
Data classification
Acceptable use
Data protection
Privacy
Risk Management
134
© 2008 Security Architecture - All Rights Reserved.
RISK MANAGEMENT
Introduction
Authority
Purpose
Objectives
Target Audience
Related Policies
135
© 2008 Security Architecture - All Rights Reserved.
RISK MANAGEMENT
Overview
Importance of Risk Management
Governing regulations
Incorporating Risk Management into IT Processes
Key Roles
136
© 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
© 2008 Security Architecture - All Rights Reserved.
RISK MANAGEMENT
Risk Mitigation
Options
Strategy
Controls and implementation
Cost-benefit analysis
Residual risk
138
© 2008 Security Architecture - All Rights Reserved.
ACCESS & IDENTIFICATION POLICIES
Authentication
Authorization
PKI
Biometrics
Digital signatures
139
© 2008 Security Architecture - All Rights Reserved.
DIGITAL SIGNATURES
Purpose and objectives
Background and scope
Applicability to electronic services
Public Key technology and PKI
Usage of certificates
Certification process
140
© 2008 Security Architecture - All Rights Reserved.
TECHNOLOGY & COMMUNICATION POLICIES
Firewall
Anti-virus
Mobile Data Protection
Encryption
Intrusion detection/intrusion protection
Web server configuration
Network connectivity
141
© 2008 Security Architecture - All Rights Reserved.
WEB SERVER CONFIGURATION
Introduction
Authority
Purpose and scope
Target audience
General IS security principles
142
© 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
143
© 2008 Security Architecture - All Rights Reserved.
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
Web server access controls
144
© 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
145
© 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
Web server security checklist
146
© 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
147
© 2008 Security Architecture - All Rights Reserved.
SUPPORT & OPERATIONS SECURITY POLICIES
Incident response
Event correlation
Disaster recovery
Business continuity
Security awareness
Change management
148
© 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
149
© 2008 Security Architecture - All Rights Reserved.
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
150
© 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
151
© 2008 Security Architecture - All Rights Reserved.
PHYSICAL & ENVIRONMENTAL POLICIES
Building/facility access
Perimeter security
Hazardous materials
152
© 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
153
© 2008 Security Architecture - All Rights Reserved.
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
The right place for “best practices”
154
© 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
155
© 2008 Security Architecture - All Rights Reserved.
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
Personal Firewalls and Appliances
156
© 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
157
© 2008 Security Architecture - All Rights Reserved.
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
158
© 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
159
© 2008 Security Architecture - All Rights Reserved.
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
Internally and externally auditable
160
© 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
161
© 2008 Security Architecture - All Rights Reserved.
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
162
© 2008 Security Architecture - All Rights Reserved.
POLICY IMPLEMENTATION: REAL-WORLD EXAMPLE
163
© 2008 Security Architecture - All Rights Reserved.
WORKSHOP #7
Task: Write a security policy guideline for incident response.
164
SECURITY POLICY
SUMMARY
© 2008 Security Architecture - All Rights Reserved.
WHY DO WE NEED POLICY?
Compliance
Exceed Industry Practices
Response
Risk Assessment
166
© 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
© 2008 Security Architecture - All Rights Reserved.
WHY: INDUSTRY PRACTICES
Certification and accreditation
Standards certification
ISO/IEC
Common Criteria
FISMA requirements
168
© 2008 Security Architecture - All Rights Reserved.
WHY: RESPONSE
Incident response
Event management, correlation, and response
Disaster response and recovery
169
© 2008 Security Architecture - All Rights Reserved.
WHY: RISK ASSESSMENT
Risk analysis and mitigation
Audit and assessment
Effectiveness measurements and metrics
170
SECURITY POLICY
ADDITIONAL INFORMATION RESOURCES
© 2008 Security Architecture - All Rights Reserved.
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 technology-specific security guidelines
172
© 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
173
© 2008 Security Architecture - All Rights Reserved.
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
174
© 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)
175
© 2008 Security Architecture - All Rights Reserved.
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.
176