Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Version 2.1.0
Publication of this SNIA Technical Proposal has been approved by the SNIA. This document represents a stable proposal for use as agreed upon by the Security TWG. The SNIA does not endorse this proposal for any other purpose than the use described. This proposal may not represent the preferred mode, and the SNIA may update, replace, or release competing proposal at any time. If the intended audience for this release is a liaison standards body, the future support and revision of this proposal may be outside the control of the SNIA or originating Security TWG. Suggestion for revision should be directed to http://www.snia.org/feedback/.
The SNIA hereby grants permission for individuals to use this document for personal use only, and for corporations and other business entities to use this document for internal use only (including internal copying, distribution, and display) provided that: 1. Any text, diagram, chart, table or definition reproduced must be reproduced in its entirety with no alteration, and, 2. Any document, printed or electronic, in which material from this document (or any portion hereof) is reproduced must acknowledge the SNIA copyright on that material, and must credit the SNIA for granting permission for its reuse. Other than as explicitly provided above, you may not make any commercial use of this document, sell any or this entire document, or distribute this document to third parties. All rights not explicitly granted are expressly reserved to SNIA. Permission to use this document for purposes other than those enumerated above may be requested by e-mailing tcmd@snia.org please include the identity of the requesting individual and/or company and a brief description of the purpose, nature, and scope of the requested use. Copyright 2008 Storage Networking Industry Association.
ii
Revision History
Revision 2.1.0 Date 9/4/2008 Sections All Originator: Eric Hibbard Comments Initial SNIA Proposal
iii
Table of Contents
EXECUTIVE SUMMARY ................................................................................................ 1 1 INTRODUCTION.......................................................................................................... 2 2 SNIA STORAGE SECURITY CORE BCPS.............................................................. 3 2.1 GENERAL STORAGE SECURITY (GEN)....................................................................... 3 2.1.1 GEN01 Identify & Assess All Storage Interfaces..................................... 3 2.1.2 GEN02 Create Risk Domains..................................................................... 3 2.1.3 GEN03 Monitor & Control Physical Access ............................................. 4 2.1.4 GEN04 Avoid Failures Due to Common Mistakes ................................... 5 2.1.5 GEN05 Address Data Security Compliance ............................................. 5 2.1.6 GEN06 Implement Appropriate Service Continuity ................................. 6 2.1.7 GEN07 Align Storage and Policy .............................................................. 7 2.2 STORAGE SYSTEMS SECURITY (SSS)........................................................................ 7 2.2.1 SSS01 Understand the Exposures ........................................................... 7 2.2.2 SSS02 Utilize Event Logging..................................................................... 8 2.2.3 SSS03 Secure Backups and Replication................................................ 10 2.2.4 SSS04 Use Trusted and Reliable Infrastructure .................................... 11 2.3 STORAGE MANAGEMENT SECURITY (SMS).............................................................. 11 2.3.1 SMS01 Secure the Management Interfaces ........................................... 11 2.3.2 SMS02 Harden Management Applications............................................. 12 2.3.3 SMS03 Tightly Control Access and Privileges ...................................... 12 2.3.4 SMS04 Restrict Remote Support ............................................................ 13 2.3.5 SMS05 Include Configuration Management (CM).................................. 13 3 SNIA STORAGE SECURITY TECHNOLOGY SPECIFIC BCPS ........................... 14 3.1 NETWORK ATTACHED STORAGE (NAS)................................................................... 14 3.1.1 NAS01 Network File System (NFS) ......................................................... 14 3.1.2 NAS02 SMB/CIFS ..................................................................................... 15 3.2 BLOCK-BASED IP STORAGE (IPS)........................................................................... 15 3.2.1 IPS01 Secure iSCSI .................................................................................. 15 3.2.2 IPS02 Secure FCIP ................................................................................... 16 3.3 FIBRE CHANNEL STORAGE (FCS) ........................................................................... 16 3.3.1 FCS01 Secure FCP ................................................................................... 16 3.3.2 FCS02 Secure Fibre Channel Storage Networks................................... 17 3.4 ENCRYPTION FOR STORAGE (ENC) ......................................................................... 17 3.4.1 ENC01 Protect Externalized Data ........................................................... 18 3.4.2 ENC02 Pedigree of Encryption ............................................................... 18 3.4.3 ENC03 Risk Assessment in Use of Encryption ..................................... 19 3.4.4 ENC04 Encryption Issues........................................................................ 19 3.5 KEY MANAGEMENT FOR STORAGE (KMS) ............................................................... 20 3.5.1 KMS01 Key Management Principles....................................................... 20 3.5.1 KMS02 Key Management Functions....................................................... 21 3.5.1 KMS03 Key Management Issues............................................................. 21
Storage Security BCPs
Version 2.1.0
iv
3.6 LONG-TERM INFORMATION SECURITY ...................................................................... 22 3.6.1 ARC01 On-line Fixed Content ................................................................. 22 3.6.2 ARC02 Off-line Fixed Content ................................................................. 22 4 SUMMARY................................................................................................................. 24 APPENDIX A REFERENCES .................................................................................... 25 APPENDIX B BEST CURRENT PRACTICES (BCP) BACKGROUND..................... 27 ABOUT THE AUTHOR(S) ............................................................................................ 29 ABOUT THE SNIA........................................................................................................ 30 ABOUT THE SNIA SECURITY TECHNICAL WORK GROUP ................................................. 30 ABOUT THE SNIA STORAGE SECURITY INDUSTRY FORUM .............................................. 30 INDEX ........................................................................................................................... 31
Executive Summary
With the increasing importance and emphasis on security in mind, the SNIA Security Technical Work Group (TWG) has prepared a revision to the SNIA storage security best current practices (BCPs). This vendor neutral guidance has a broad scope, covering both storage systems and entire storage ecosystems. These new SNIA storage security BCPs are grouped into core BCPs and technology specific BCPs. The core BCPs are intended to apply to all storage systems/ecosystems and they cover basic storage security elements. The technology specific BCPs are above and beyond the core BCPs and they may or may not apply. When they do apply, multiple categories of the technology specific BCPs may be applicable for a given environment. The following lists the categories associated with both the core and technology specific BCPs: Core: General Storage Security Storage Systems Security Storage Management Security Technology specific: Network Attached Storage (NAS) Block-based IP Storage Fibre Channel Storage Encryption for Storage Key Management for Storage Long-term Information Security
Judicious use of the SNIA storage security best current practices will allow an organization to take a holistic approach to securing its storage systems/ecosystems.
1 Introduction
From a storage perspective, storage security represents the convergence of the storage, networking, and security disciplines, technologies, and methodologies for the purpose of protecting and securing digital assets. From a security perspective, storage security is simply a part of information assurance, which includes information security, network and communications security, host-based security, and data security. Although security within storage has some unique attributes, these attributes are not significant enough to warrant a special designation like storage security; however, the need to draw attention to the security aspects of this segment of infrastructure is the primary reason the Storage Networking Industry Association (SNIA) Security Technical Work Group (TWG) uses the term storage security. As with many aspects of security, a balance must be struck between mitigating risks and minimizing the impacts, which may take the form of cost, complexity, throughput, availability, scalability, etc. Each organization must make its own trade-off decisions based on its unique situation (e.g., deployed infrastructure, legal and regulatory requirements, and due care expectations) and the importance of its data. The purpose of this SNIA document is to provide broad guidance to organizations seeking to secure their individual storage systems as well as their storage ecosystems. This guidance is provided in a vendor neutral manner as a collection of best current practices or BCPs1. By focusing on best practices rather than a more minimalist set of requirements, organizations have flexibility in how they implement this guidance (e.g., specific technology areas, phased approach, etc.). Most of the BCPs are written in layman terms, avoiding unnecessary storage- or securityspecific jargon and acronyms. However, the target audience is expected to have a basic working knowledge of storage or security practices and concepts. As written, this content should be usable by practitioners, IT architects, IT managers, and corporate executives (CIOs and CSOs, in particular).
Readers who are familiar with the initial version of the SNIA storage security BCPs may want to consult Appendix B for additional background information. SNIA Technical Proposal
Most organizations are motivated to protect sensitive (and business/mission critical) data, which typically represents a small fraction of the total data. This narrow focus on the most important data can be leveraged as the starting point for data classification and a way to prioritize protection activities. Storage Security BCPs
Version 2.1.0
GEN02.B Logical Segregate storage traffic from normal server traffic Use FC/zoning and IP/VLANs to control network access Use hardware-enforced zoning for access control Use LUN Masking at the point closest to source device Segregate management traffic from all other traffic Carefully review configuration of network gateways, especially FC-iSCSI3 GEN02.C Virtual Manage the movement of virtual servers4 Carefully monitor migration of virtual servers between risk domains Assure that a virtual server image is afforded the same protections as if it were a physical server Ensure appropriate service level objectives for virtual storage Match the availability objective for the storage cloud to the application requirements Match the confidentiality and privacy requirements for the storage cloud to the types of information stored
Within the context of this document, FC-iSCSI is a shorthand notation for storage networking gateways that allow iSCSI initiators and targets to use and be used by Fibre Channel entities, and vice versa. 4 Virtual servers are much easier to migrate between physical hosts in an infrastructure and this movement may have unintended security consequences. For example, moving a virtual server from a lower-risk (more trusted) to a higher-risk (less trusted) domain may expose the sensitive information the server contains or allowed to process unless its configuration is hardened appropriately. Conversely when a virtual server is moved from a higher-risk (less trusted) domain to a lower-risk (more trusted) domain, its hardening configuration may interfere with normal operation unless it is matched to that appropriate for the lower-risk domain. Storage Security BCPs
Version 2.1.0
Within this context, a Definitive Software Library (DSL) stores the master copies of all software and it is from this source that software control and release is managed. Storage Security BCPs
Version 2.1.0
Regularly test controls and review processes GEN05.D Detect, Monitor, and Evaluate Ensure that the storage layer participates in the external audit logging measures Monitor the audit logging events and issue the appropriate alerts GEN05.E Information Retention & Sanitization Implement appropriate data retention measures Implement appropriate data integrity and authenticity measures Correctly sanitize data upon deletion, repurposing or decommissioning of hardware Correctly sanitize virtual server images, and their copies, at end of life GEN05.F Privacy Implement appropriate data access control measures to control access to data and metadata (e.g., search results); assume a least privilege posture whenever possible Implement appropriate data confidentiality measures to prevent unauthorized disclosure GEN05.G Legal Ensure that the use of data deduplication does not conflict with data authenticity requirements Ensure data and media sanitization mechanisms do not violate preservation orders Ensure proper chain of custody procedures are followed when evidentiary data (e.g., audit logs, metadata, mirror images, point-in time copies, etc.) is handled
Within this context, automation refers to the processes and technologies that facilitate a failover to DR/BC facility resources. The underlying assumptions are that the DR/BC facility is a hot site and that this failover is executed with no or very little human intervention. Storage Security BCPs
Version 2.1.0
GEN06.C Planning & Testing Perform on-going planning and regular testing of assumption, which are critical to successful DR/BC. Develop test cases Document and script Test as regressions with every configuration change (a loop-hole we closed before should not be reopened by accident) Use automated testing tools (largest shops) to run the most possible test cases to improve quality of security infrastructure
Note that traditional security scanning only looks for publicly known issues in widely used software, and will not find anything new or unique in your specific implementations. Automated negative testing (such as robustness testing or fuzzing) provides capability to facilitate discovering new issues when more detailed analysis is needed. Storage Security BCPs
Version 2.1.0
Maintain awareness of advertised vulnerabilities in virtualization platforms and their management applications SSS01.B Maintain Security of Systems Install security patches and fixes in a timely fashion Consider upgrading applications/software when end-of-life products contain exploitable, but unpatchable vulnerabilities SSS01.C Monitor for Zero-day Events Integrate intrusion detection/prevention technology
Not all event log entries are created equal, as some may only be useful for debugging purposes, provide system health status, warn of minor configuration problems, etc. From an audit logging perspective the management events (i.e., what a human did) are always of interest, the data access events are usually of limited interest (except in situations where critical files and directories need to be tightly monitored), and control events are typically of the least interest (they can provide useful information during root-cause analysis after an incident). In addition, audit logging often requires the event entries of interest to be handled differently and separately from most other event log entries generated by a device. This special handling can be accomplished by having the devices send the audit log entries to special log infrastructure or they can be culled out of the general log stream, using a log filtering mechanism (a more challenging approach because it requires all the event entries of interest to be know a priori). Another aspect of this special handling is that an organization often has to demonstrate that it is monitoring (e.g., generating alerts for anomalous events) and reporting; these actions usually require some form of centralized logging infrastructure beyond simple collectors. The logging BCPs described in this section were derived from the SNIA Audit Logging for Storage whitepaper (available at: http://www.snia.org/forums/ssif/knowledge_center/white_papers) and they offer guidance on
audit logging for storage systems/ecosystems. Additional guidance can be found in NIST8 Special Publication 800-92 Guide to Security Log Management. SSS02.A Include Storage in Logging Policy With regard to storage systems and devices, the following elements of policy should be addressed: Storage systems and devices must participate in audit logging All significant storage management events are collected Log data is preserved Log data is archived and retained The device time is synchronized with a reliable, external source The logging policy should include evidentiary expectations (authenticity, chain of custody, etc.) SSS02.B Employ External Event Logging Implement centralized9 audit logging to collect events from all sources in a single repository Establish and use a common, accurate time source across the environment to assure that event records from different sources can be correlated For anything other than system health monitoring and debugging, device resident logs are not recommended because they are more easily subjected to tampering or destruction, there is limited storage space available for logs, and they preclude the use of centralized automated analysis, alerting, and archiving. Storage devices must be capable of natively logging events to one, and preferably multiple, external log servers (preferably syslog10). Audit logging for which compliance, accountability, and/or security serve as the primary drivers must have devices configured to log events on a transactional basis (no buffering) . Implement an analysis protocol to correlate audit log records to identify significant security events that provide indication of security incidents SSS02.C Ensure Complete Event Logging From an accountability perspective the management events are always of interest, the data access events are usually of limited interest (except in situations where critical files and directories need to be tightly monitored), and control events are typically of the least interest (they can provide useful information during root-cause analysis after an incident). Once the types of events to be logged have been determined, then ALL occurrences of these events must be logged (both in-band and out-of-band) The following kinds of events should be logged: Failed logon attempts11 Failed file and object access attempts Account and group profile additions, changes, and deletions
The Computer Security Resource Center (CSRC) within the National Institute of Standards and Technology (NIST) makes a wide range of information security resources available at: http://csrc.nist.gov/publications/nistpubs/ 9 Centralization in this context should not be interpreted as meaning that all audit logging within an organization has to use a common infrastructure. It is more important to have storage systems/ecosystems within a single risk domain use a common audit logging infrastructure. 10 The Internet Engineering Task Force (IETF) has an activity called the Security Issues in Network Event Logging (syslog) Work Group (http://www.ietf.org/html.charters/syslog-charter.html), which is standardizing event logging. 11 Successful logons should also be logged. Storage Security BCPs
Version 2.1.0
Changes to system security configurations (e.g., audit logging, network filtering, zoning changes) Changes to security server usage (e.g., syslog, network time protocol or NTP, domain name system or DNS, authentication) System shutdown and restarts Privileged operations (i.e., administrator initiated changes) Use of sensitive utilities (e.g., sudo, cron) Access to critical data files Movement of virtual servers between physical hosts Each log entry should include a timestamp (date and time), a severity level, the source of the log entry (distinguishing name, IP address, etc.), and a description of the event. Use care when filtering on fields like severity as the enterprise logging policy should serve as the guide for determining what kind of filtering is appropriate and what level of information requires long term storage. SSS02.D Implement Appropriate Retention and Protection Make sure the event log data from the affected systems are handled and retained correctly Implement appropriate measures to preserve log integrity and prevent their modification or destruction (either maliciously or accidentally) Depending on the importance of the data and/or the type of log entries, protective measures may be required to ensure the confidentiality12 and integrity of the log data. Use special purpose log servers to handle unique and/or sensitive data requirements Leverage log relays and log filtering to minimize the impact of specialized storage requirements (WORM)
12
Some log entries may expose things like passwords (e.g., when a user types a password instead of the userid), but more subtle problems may exist as well (e.g., search commands that expose specific names and health issues). Storage Security BCPs
Version 2.1.0
10
Ensure that the replication approach provides adequate protections against unauthorized access (e.g., encryption in-flight)
Discovery services are a convenient way for administrators to provide and use (and even manage) storage resources because configurations do not need to be set a priori. However, the IETF specified approach for securing iSNS and SLP against a range of attacks is to use IPsec, which can be difficult to configure. The use of IPsec eliminates most or all of the convenience, so it is rarely used in combination with the discovery services; consequently, an organization ends up trading off security for convenience, which may not be appropriate for sensitive and business/mission critical data. Storage Security BCPs
Version 2.1.0
13
11
Avoid indirect attacks from IT infrastructure (DNS, SLP, NTP) In-band and out-of-band management should be subjected to common security measures SMS01.C Control Vendor Maintenance Restrict access to dial-in modems used for vendor support Restrict access to out-of-band management network to authorized hosts and protocols
The SNIA Storage Management Initiative Specification (SMI-S) Version 1.1.1 is defined in ANSI INCITS 3882008 Storage Management. 15 The Open Web Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of application software; its website at http://www.owasp.org is a good source of information for common web application problems. Storage Security BCPs
Version 2.1.0
12
SMS03.A Configure Administrative Accounts Remove manufacturers' default passwords Use separate user IDs and require strong passwords for each user on each device When possible, use a centralized authentication (e.g., RADIUS, Single-Sign-on, etc.) solution for improved monitoring and control SMS03.B Use Good Access Control Practices Grant the least set of privileges required to perform the activity Employ separation of duties, differentiating security administrator and storage administrator privileges Manage access permissions by role rather than by user
Consider logging dynamic configuration changes introduced through mechanisms like the dynamic host configuration protocol (DHCP), dynamic discovery, etc. Storage Security BCPs
Version 2.1.0
16
13
14
NAS01.D Secure Data on NFS Filer Exported file systems should be in their own partitions to prevent system degradation by an attacker writing to an exported file system until it is full. Encrypt data at-rest when necessary Do not allow NFS exports of administrative file systems (e.g., /etc) Guard against malware (e.g., viruses, worms, rootkits, etc.) Continually monitor content placed in NFS shares and relevant access controls
17 18
No iFCP-specific BCPs are included in this document. IETF RFC 3723 Securing Block Storage Protocols over IP is also a useful source of information for securing IP storage. Storage Security BCPs
Version 2.1.0
15
IPS01.A Control iSCSI Network Access and Protocols Filter based on source IP addresses and protocols Avoid connecting iSCSI interfaces to general purpose LANs; segregate for security and performance Carefully use VLANs when the use of physically isolated LANs are not an option IPS01.B Implement iSCSI Security Measures Use CHAP authentication for both initiators and targets in all iSCSI implementations Use IPsec to secure the communication channel when sensitive data could be exposed Avoid indirect attacks from IT infrastructure (iSNS19, SLP20, DNS)
19 20
RFC 4171, Internet Storage Name Service (iSNS), provides useful security guidance for the iSNS. RFC 3723, Securing Block Storage Protocols over IP, provides useful security guidance for the Service Location Protocol Version 2 (SLPv2). Storage Security BCPs
Version 2.1.0
16
FCS01.B Implement FCP Security Measures Use SCSI-based protection information21 to help minimize the risk of data loss by protecting data through the complete data path. Use DH-CHAP authentication22 (per ANSI 4262007 FC-SP ) Use ESP_Header23 to protect Fibre Channel connections that leave the protected area
The SCSI Protection Information Model is defined in ANSI INCITS 4052005 SCSI Block Commands 2 (SBC-2). 22 In this context, DH-CHAP is a reference to the AUTH-A element of ANSI INCITS 4262007 Fibre Channel Security Protocols (FC-SP) 23 ESP_Header Authentication and Confidentiality optional headers are defined in ANSI INCITS 424 2007 Fibre Channel Framing and Signaling-2 (FC-FS-2). Storage Security BCPs
Version 2.1.0
21
17
The encryption BCPs described in this section and the key management BCPs described in the next section were significantly influenced by the SNIA Encryption of Data At-rest Step-by-step Checklist whitepaper (available at: http://www.snia.org/forums/ssif/knowledge_center/white_papers). These BCPs offer guidance on ensuring data confidentiality for storage systems/ecosystems. The remainder of this section identifies the applicable BCPs when using encryption within storage systems/ecosystems.
24
Within this context, externalized data is data that has left the direct control of the organization. This loss of control can be temporary (e.g., transmission between two data centers) or long-term (e.g., archived in a third-party data center). 25 Consider using tape drives, which are compliant with the IEEE 1619.1-2007 standard, or other encryption mechanisms that offer a comparable level of protection. SNIA Technical Proposal
18
ENC02.C Strength of Encryption Consider meeting or exceeding the US NIST (SP 800-57 Part 1) recommended minimum symmetric security levels, defined as bits of strength (not key size) 80 bits of security until 2010 (128-bit AES and 1024-bit RSA) 112 bits of security through 2030 (3DES, 128-AES and 2048-bit RSA) 128 bits of security beyond 2030 (128-AES and 3072-bit RSA)
19
If undecided between two potential points of encryption, pick the one closest to the application generating the data ENC04.B Align with Data Reduction Services Ensure that compression is performed before encryption to realize the maximum data reduction benefits Ensure that deduplication is performed prior to encryption (and compression) to realize the maximum data reduction benefits ENC04.C Proof of Encryption Ensure the encryption mechanisms create appropriate audit log entries (activation, verification, integrity checks, re-keying, etc.) Agree in advance what audit log material will be necessary for the legal department to accept that encryption was properly performed Perform regular and audited checks that encryption was properly performed, consider outside accreditation
20
21
KMS03.B Plan for Problems Have a compromise recovery plan in the event of a key compromise. Consider escrowing keying material used to protect business/mission critical information26
26
The loss on an encryption key with no key recovery capability (backups, escrow, etc.) renders all of the corresponding ciphertext (i.e., data encrypted under the lost key) unusable. This situation and risk will persist for as long as the data is stored as ciphertext. Storage Security BCPs
Version 2.1.0
22
ARC02.A Establish Off-line Fixed Content Policy Identify the types of data to be accepted as well as the preservation period (e.g., not longer than 30 years) Assure that the service operates in accordance with the policy by defining its characteristics such as: Fixed content data object maintenance policy Authorization policy Specify the preservation activities performed for fixed content data objects subject to the policy. Define a cryptographic maintenance policy for cryptographic mechanisms ARC02.B Maintain Off-line Fixed Content Security Assure that access control mechanisms are appropriate to the lifespan of the fixed content objects Perform periodic data conversions and revalidations to assure the integrity and authenticity of data to address data format changes or technological obsolescence during the lifespan of fixed content data Address long-term non-repudiation of digitally signed data when required Ensure that the cryptographic assurances of confidentiality27 and authenticity are maintained
27
There is an implicit assumption that encryption keys are protected and available to decrypt ciphertext stored in the off-line fixed content. As noted in the Key Management BCPs, the loss of a key renders its corresponding ciphertext unusable. Storage Security BCPs
Version 2.1.0
23
4 Summary
Storage technology has an intimate relationship with data (the crown jewels) of many organizations. Frequently it is the repository for this data as well as the last opportunity for defense. Thus, it seems logical that storage systems/ecosystems should participate in some or all of the typical security services (i.e., confidentiality, integrity, availability, access control, and non-repudiation). A defense-in-depth security strategy is becoming increasingly realizable as more data security measures become available. Although potentially complex to implement, storage security can be an effective element of a defense-in-depth strategy, and in many cases, it is truly the last line of defense. The SNIA storage security best current practices, described in this document, provide detailed guidance to help with the implementation of such a strategy.
24
Appendix A References
This appendix provides a complete list of the documents and standards that were consulted and/or used in the production of these best current practices. ANSI INCITS 3882008 Storage Management. ANSI INCITS 4052005 SCSI Block Commands 2 (SBC-2). ANSI INCITS 4262007 Fibre Channel Security Protocols (FC-SP) ANSI INCITS 4242007 Fibre Channel Framing and Signaling-2 (FC-FS-2) IEEE 1619-2007 IEEE Standard for Cryptographic Protection of Data on BlockOriented Storage Devices IEEE 1619.1-2007 IEEE Standard for Authenticated Encryption with Length Expansion for Storage Devices IEEE 1619.2 Draft Standard for Wide-Block Encryption for Shared Storage Media IEEE 1619.3 Draft Standard for Key Management Infrastructure for Cryptographic Protection of Stored Data IETF RFC 3720 Internet Small Computer Systems Interface (iSCSI) IETF RFC 3723 Securing Block Storage Protocols over IP IETF RFC 3821 Fibre Channel Over TCP/IP (FCIP) IETF RFC 4171 Internet Storage Name Service (iSNS) IETF RFC 4810 Long-Term Archive Service Requirements ISO/IEC 10116:2006 Information technology -- Security techniques -- Modes of operation for an n-bit block cipher ISO/IEC 11770-1:1996 Information technology -- Security techniques -- Key management -- Part 1: Framework ISO/IEC 11770-2:1996 Information technology -- Security techniques -- Key management -- Part 2: Mechanisms using symmetric techniques ISO/IEC 18033-1:2005 Information technology -- Security techniques -- Encryption algorithms -- Part 1: General ISO/IEC 18033-3:2005 Information technology -- Security techniques -- Encryption algorithms -- Part 3: Block ciphers ISO/IEC 27001:2005 Information technology -- Security techniques -- Information security management systems -- Requirements ISO/IEC 27002:2005 Information technology -- Security techniques -- Information security management -- Code of practice for information security management NIST FIPS 197 -- Advanced Encryption Standard (AES) NIST Special Publication 800-38A Recommendation for Block Cipher Modes of Operation - Methods and Techniques NIST Special Publication 800-38C Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality NIST Special Publication 800-38D Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) for Confidentiality and Authentication NIST Special Publication 800-57 Part 1 Recommendation on Key Management Part 1: General (Revised) NIST Special Publication 800-57 Part 2 Recommendation on Key Management Part 2: Best Practices for Key Management Organization NIST Special Publication 800-67 Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher NIST Special Publication 800-88 Guide for Media Sanitization NIST Special Publication 800-92 Guide to Security Log Management Payment Card Industry (PCI) Data Security Standard (DSS) Version 1.1
Storage Security BCPs
Version 2.1.0
25
Storage Networking Industry Association (SNIA), Introduction to Storage Security, http://www.snia.org/forums/ssif/knowledge_center/white_papers. Storage Networking Industry Association (SNIA), Audit Logging for Storage, http://www.snia.org/forums/ssif/knowledge_center/white_papers. Storage Networking Industry Association (SNIA), Encryption of Data At-rest Step-bystep Checklist, http://www.snia.org/forums/ssif/knowledge_center/white_papers. Trusted Computing Group (TCG), TCG Storage Architecture Core Specification Version 1.0 Revision 0.9
26
Storage
Networking
Security
DAR
DIF SRM
SSS
27
# 1 2 3 4 5 6 7 8 9 10
Recommendation Summary Secure the Storage Management Identify and Assess All Storage Interfaces Create Risk Domains Monitor and Control Physical Access Avoid Failures Due to Common Mistakes Address Data Security Compliance Protect Externalized Data Understand the Exposures Implement Appropriate Service Continuity Utilize Event Logging
Table B1. Storage Security BCP Version 1.0 This document builds upon and expands the original set of SNIA storage security best current practices (BCPs). In addition, the new BCPs are organized into categories that apply generally to all storage (known as core) and categories that are technology specific. Each of these categories is further subdivided into elements and sub-elements; a new numbering scheme, which tracks the new structure, has also been introduced to aid in referencing the BCPs. To assist readers who are familiar with the original BCPs, a mapping diagram has been prepared (see Figure B2). It is worth noting that many of the original BCPs have become elements of the General Storage Security category.
# 1 2 3 4 5 6 7 8 9 Recommendation Summary Secure the Storage Management Identify and Assess All Storage Interfaces Create Risk Domains Monitor and Control Physical Access Avoid Failures Due to Common Mistakes Address Data Security Compliance Protect Externalized Data Understand the Exposures Implement Appropriate Service Continuity Type Core Core Core Specific BCP Category General Storage Security Storage Systems Security Storage Management Security Network Attached Storage
Specific Block-based IP Storage Specific Fibre Channel Storage Specific Encryption for Storage Specific Key Management for Storage
28
Richard Austin
Richard is a 30+ year veteran of the IT industry in positions ranging from software developer to security architect. Before beginning a career as an independent consultant, he was focused on technology and processes for successfully protecting the 14PB storage area network infrastructure within the global IT organization of a Fortune 25 company. He earned a MS degree with a concentration in information security from Kennesaw State University, a National Center of Academic Excellence in Information Assurance Education, and serves as a part-time faculty in their CSIS department where he teaches in the Information Security and Assurance program. He holds the CISSP certification and is an active member of SNIA's Storage Security Industry Forum and Security Technical Working Group. He is a Senior Member of the IEEE and also belongs to the IEEE Computer Society, ACM, CSI, HTCIA, ISACA and ISSA (where he also serves on their international ethics committee). He is a frequent writer and presenter on storage networking security and digital forensics.
29
30
Index
A access controls, 5, 15 to data and metadata, 6 zoning, 4 accountability, 5 ANSI INCITS 3882008, 12, 25 4052005, 17, 25 4242007, 17, 25 4262007, 17, 25 archive. See fixed content asset assessments, 3 audit logging, 9 accountability, 5 chain of custody, 6 common infrastructure, 9 confidentiality, 10 external, 6, 9 handling, 10 integrity, 10 monitoring, 6 no buffering, 9 retention, 10 traceability, 5 audit trail, 13 legal-quality, 22 auditor information systems, 5 authentication, 18 centralized, 11, 13 port, 4 strong, 15 authenticity, 5, 6, 23 B backup security, 10 backups, 7, 10 BC. See business continuity BCPs. See best current practices best current practices, 2 core, 3 technology specific, 14 bits of strength, 19 business continuity, 6 fixed content, 22 C centralized authentication, 13 chain of custody, 5, 6, 9, 22 Storage Security BCPs
Version 2.1.0
chain of trusted individuals, 10 change detection, 13 change management, 13 CHAP, 16 classify, 5 Command Line Interface, 12 compliance, 3, 5, 22 compression with deduplication, 20 with encryption, 20 confidentiality, 6, 16, 18, 23 keying material, 21 configuration management operational, 13 practices, 13 cryptographic algorithms, 18 assurances, 23 maintenance, 23 mechanisms, 23 cryptoperiod, 20 D data authenticity, 6 availability, 10, 22 classification, 3 confidentiality, 6 critical, 7, 10 deduplication, 6 destruction, 7 disposition, 22 evidentiary, 6 externalized, 18 integrity, 6, 10, 16 most sensitive identify, 7 priority, 7 privacy, 22 recovery, 22 replication, 10, 22 resiliency, 10 retention, 6, 7, 22 sanitization, 6 value, 18 deduplication with compression, 20 with encryption, 20 default zones, 17 Definitive Software Library, 5 SNIA Technical Proposal
denial of service, 12 DH-CHAP, 17 directory services, 11 disaster recovery, 6 fixed content, 22 DNS, 10, 11, 12, 16 DR. See disaster recovery dynamic discovery, 11 E e-Discovery, 22 encryption algorithms, 18 data at-rest, 15, 18 data in-flight, 18 modes of operation, 18 operational issues, 19 pedigree, 18 point of, 19 proof of, 19, 20 rollback plan, 19 strength of, 19 with compression, 20 with deduplication, 20 ESP_Header, 17 event logging centralized audit logging, 9 control, 8 data access, 8 health monitoring, 9 management, 8 time source, 9 evidence, 5 evidentiary requirements, 8 export controls, 21 externalized data, 18 F fault-tolerance, 10 FCIP, 16 FCP, 16, 17 FC-SP authentication, 17 policy, 16, 17 Fibre Channel Protocol, 16, 17 fixed content disaster recovery, 22 governance, 22 off-line, 22 access control, 23
31
cryptographic assurances, 23 data conversions, 23 data revalidations, 23 maintenance policy, 23 non-repudiation, 23 policy, 23 preservation period, 23 on-line, 22 authenticity, 22 business continuity, 22 chain of custody, 22 data availability, 22 data disposition, 22 data privacy, 22 data recovery, 22 data replication, 22 data retention, 22 e-Discovery, 22 on-lineevidentiary, 22 fuzzing, 7 G governance, 22 H HTTPS, 11, 12, 13 I IEEE 1619.1-2007, 25 1619.3 (draft), 20, 25 1619-2007, 17, 25 IETF RFC 3720, 15, 25 RFC 3723, 15, 25 RFC 3821, 16, 25 RFC 4171, 25 RFC 4810, 22, 25 import controls, 21 integrity, 6 interfaces management in-band, 3 out-of-band, 3 intrusion detection, 8 prevention, 8 IPsec, 11, 13, 16 iSNS, 11, 16 ISO/IEC 10116:2006, 17, 25 11770-1:1996, 20, 25 11770-2:1996, 20, 25 18033-1:2005, 17, 25 18033-3:2005, 17, 25 Storage Security BCPs
Version 2.1.0
27001:2005, 7, 25 27002:2005, 7, 25 K Kerberos, 14, 15 key backup, 21 change, 21 cryptoperiod, 20, 21 derivation, 21 disposition, 21 escrowing, 22 lifetime, 20 recovery, 21 secure distribution, 21 size, 18, 19 space, 18, 20 update, 21 wrapping, 21 keys data encryption, 20 data-encrypting, 20 key-encrypting, 20 plaintext, 20 weak, 20 L LDAP, 15 least privilege, 6, 17 LUN masking, 4, 16 M maintenance cryptographic, 23 policy, 23 system, 5 vendor, 12 malware, 15 management in-band, 12 out-of-band, 11 media sanitization, 7 metadata chain of custody, 6 mistakes, 5 modems, 12, 13 multi-key, 21 N NAS. See network attached storage network attached storage, 14 NFS, 14 SMB/CIFS, 15 network filtering, 12 NFS SNIA Technical Proposal
ACLs, 14 encryption, 15 IPsec, 14 Kerberos, 14 multi-protocol, 14 network access, 14 well-known ports, 14 NIST FIPS 197, 17, 25 SP 800-38A, 17, 25 SP 800-38C, 17, 25 SP 800-38D, 17, 25 SP 800-57 Part 1, 19, 20, 25 SP 800-57 Part 2, 20, 25 SP 800-67, 17, 25 SP 800-88, 25 SP 800-92, 9, 25 non-repudiation, 5 long-term, 23 NPIV, 16 NTLMv2, 15 NTP, 10, 11, 12 O out-of-area recovery, 6 P PCI DSS v1.1, 25 personally identifiable information, 3, 7 physical access cable plant, 4 facilities, 4 network infrastructure, 4 storage resources, 4 physical protection, 4 physical security, 3 PII. See personally identifiable information planning DR/BC, 7 point of encryption, 19 policy, 3, 7 authorization, 23 cryptographic maintenance, 23 fixed conent, 23 logging, 9 maintenance, 23 storage compliance, 7 storage-specific, 7 port authentication, 4 preservation activities, 23
32
orders, 6 period, 23 privacy fixed content, 22 proof of encryption, 19 of records retention, 10 R RADIUS, 13, 15 random number generation, 21 recovery activities, 6 disaster, 6 key, 21 out-of-area, 6 plan, 22 times, 6 reliability, 10 remote network access, 13 removable media, 18 replication, 7, 10 approach, 11 fixed content automatic, 22 security, 10 repurposing, 6 retention, 6 risk analysis, 5 assessment, 5 domains, 3 audit logging, 9 logical, 4 physical, 3 virtual, 4
management, 5 transfer, 18 treatment, 5 roles access permissions, 13 fixed content, 22 rights and privileges, 5 rootkits, 15 RS-232, 11 S SAN, 17 sanitization, 6 media, 6 secure baseline, 13 security patches, 8 security scans, 7 sensitive data, 18 separation of duties, 13 service continuity, 3 business continuity, 6 disaster recovery, 6 service discovery protocols, 11 SLP, 11, 12, 16 SMB/CIFS encryption, 15 SMI-S, 12 SMTP, 11 SNMP, 12 social engineering, 4 split-key, 21 SSH, 11 SSHv2, 13 SSL, 11 storage cloud, 4 storage security, 2
strength of encryption, 19 symmetric encryption modes, 18 syslog, 9, 10 T time source, 9 TLS, 11 traceability, 5 trusted services, 11 V virtual server, 4 storage, 4 virtual server images sanitize, 6 virtualization platforms advertised vulnerabilities, 8 viruses, 15 VLANs, 4, 16 VPN, 11 vulnerability assessments, 7 W weak keys, 20 WORM, 7, 10 worms, 15 Z zero-day events, 8 zoning, 4 basic, 17
33