1 SP A Framework for Designing Cryptographic Key Management Systems 5/25/2012 Lunch and Learn Scott Shorter
2 Topics Follows the Sections of SP draft 2: Introduction Framework Basics Goals of a CKMS Security Policies Roles and Responsibilities Keys and Metadata Interoperability and Transitioning Security Controls Testing and System Assurance Disaster Recovery Security Assessment Technological Challenges
3 SP Metadata Title: A Framework for Designing Cryptographic Key Management Systems Revision: draft 2 Date: 3/21/2012 Authors: Elaine Barker, Miles Smid, Dennis Branstad, Santosh Chokhani
4 Author Accomplishments Barker: SP Recommendations on Key Management SP A Recommendation for Random Number Generation Using Deterministic Random Bit Generators Branstad: NIST SP , Guidelines for the Accreditation of Personal Identity Verification Card Issuers Chokhani: IETF RFCs 2527 & 3647 on Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework Smid: Retired from NIST CSD Godfather of FIPS 140 and AES Co-author of NIST SP series.
5 Section 1 Introduction Cryptography is used: To protect information from unauthorized disclosure to detect unauthorized modification, and to authenticate the identities of system entities Cryptography is useful: when data transmission or authentication happens over channels that are not physically protected As an additional layer of protection against insiders and hackers.
6 Cryptographic Services Cryptography can provide the following types of protection Confidentiality is obtained by encrypting data in such a way that only authorized parties can access the keys to decrypt the data. Integrity can be demonstrated through digital signature or message authentication algorithms Source authentication provides assurance that protected data came from an authorized entity. These protections are applicable to data, but also to cryptographic keys and metadata. Example: X.509 certificates bind a public key to an individual or device identity. The certificate provides integrity protection to the public key, identity and other metadata, and source authentication of the issuer is derived from the signature on the certificate. This is called a trusted association in the framework
7 CKMS Defined Cryptographic Key Management System (CKMS) The policies, procedures, components and devices that protect, manage and distribute cryptographic keys and associated metadata. CKMS Component Any hardware, software, or firmware that is used to implement a CKMS. CKMS Device Any combination of CKMS components that serve a specific purpose (e.g., firewalls, routers, transmission devices, cryptographic modules, and data storage devices).
8 Trusted Association Trusted Associations The linking of a key with selected metadata elements so as to provide assurance that the key and its metadata are properly associated, originate from a particular source, have not been modified, and have been protected from unauthorized disclosure.
9 Framework Requirements The document contains a number of Framework Requirements (FRs) identified as FR:i.j, which indicates the j th FR in Section i. These are documentation requirements to be addressed when designing a CKMS FR:1.1 A conformant CKMS design shall meet all shall requirements of the Framework.
10 CKMS Design Process The CKMS Design consists of the Framework Requirements combined with the reponses to those requirements by the developers of the CKMS. So the framework requirements are basically a set of questions that once answered by the CKMS developer will produce a complete CKMS design.
11 Section 2 Framework Basics This Framework does not impose any specific policies, procedures, security requirements, or system design constraints on the CKMS; it simply requires that they be documented in a structured manner so that various CKMS designs can be understood and compared. So the framework provides a way to document CKMS designs in a common manner, not policy stipulations.
12 Algorithms and security strengths FR:2.1 The CKMS design shall specify all cryptographic algorithms and supported key sizes for each algorithm used by the system. FR:2.2 The CKMS design shall specify the estimated security strength (measured in bits of security) of all the cryptographic mechanisms that are employed to protect keys and their bound metadata.
13 Requirements and devices FR:2.3 A compliant CKMS design shall make selections and provide documentation as required by the requirements the Framework. FR:2.4 The CKMS design shall specify (e.g., make, model, and version) all major devices of the CKMS.
14 Section 3 - Goals of the CKMS FR:3.1 The CKMS design shall specify its goals with respect to the communications networks on which it will function. FR:3.2 The CKMS design shall specify the intended applications that it will support. FR:3.3 The CKMS design shall list the intended number of users and the responsibilities that the CKMS places on those users.
15 Goals: Standards Conformance FR:3.4 The CKMS design shall specify the Federal, national, and international standards that are utilized by the CKMS and how conformance is tested for each. FR:3.5 The CKMS design shall specify which commercial products are utilized in the CKMS design. FR:3.6 The CKMS design shall specify all security standards to which the CKMS conforms.
16 Goals: Usability FR:3.7 The CKMS design shall specify all user interfaces to the system. FR:3.8 The CKMS design shall specify the results of any useracceptance tests that have been performed regarding the ease of using the proposed user interfaces. FR:3.9 The CKMS design shall specify the design principles of the user interface. FR:3.10 The CKMS design shall specify all human errorprevention or failsafe features designed into the system.
17 Goals: Performance Requirements FR:3.11 The CKMS design shall specify the performance characteristics of the CKMS, including the average and peak workloads that can be handled for the types of functions and transactions implemented, and the response times for the types of functions and transactions under those respective workloads. FR:3.12 The CKMS design shall specify the techniques used to scale the system to increased-workload demands. FR:3.13 The CKMS design shall specify the extent to which the CKMS can be scaled to meet increased-workload demands. This shall be expressed in terms of additional workload, response times for the workload, and cost.
18 Goals: Maximize COTS FR:3.14 The CKMS design shall specify the COTS products used in the CKMS. FR:3.15 The CKMS design shall specify which security functions are performed by COTS products. FR:3.16 The CKMS design shall specify how COTS products are configured and augmented to meet the CKMS goals.
19 Section 4 - Security Policies Information Management Policy An Information Management Policy specifies what information is to be collected or created, and how it is to be managed. Information Security Policy An Information Security Policy is created to support and enforce portions of an Information Management Policy by specifying in more detail what information is to be protected from anticipated threats and how that protection is to be attained. CKMS Security Policy A CKMS Security Policy is created to establish and specify requirements for protecting the confidentiality, integrity, availability, and source authentication of all cryptographic keys and metadata used by the organization.
20 Information Management Policy identifies management roles and responsibilities establishes the authorization required for people performing these information management duties specifies what information is to be considered valuable and sensitive and how it is to be protected what categories of information need to be protected against unauthorized disclosure, modification or destruction. foundation for an information security policy and dictate the levels of confidentiality, integrity, availability, and source authentication protections that must be provided for various categories of sensitive and valuable information
21 Information Security Policy The rules for collecting, protecting, and distributing valuable and sensitive information in both paper and electronic form are specified in this layer of policy. Inputs: Information Management Policy, potential threats and risks Outputs: information sensitivity levels and high-level rules for protecting information
22 CKMS Security Policy The selection of all cryptographic mechanisms and protocols to be used throughout the organization s automated information systems Includes the Key Security Policy, which identifies protections applied to each key type and its metadata over their entire lifecycle. Includes Key and Metadata Retention Policy enforced by the CKMS Includes justification for how it supports the Information Security Policy
23 Security Policies
24 Specification of Security Policy FR:4.1 The CKMS design shall specify the CKMS Security Policy that it enforces. FR:4.2 The CKMS design shall specify how the CKMS Security Policy is to be enforced by the CKMS (e.g., the mechanisms used to provide the protection required by the policy). FR:4.3 The CKMS design shall specify how any automated portions of the CKMS Security Policy are expressed in an unambiguous tabular form or a formal language (e.g., XML or ASN.1), such that an automated security system (e.g., table driven or syntax directed software mechanisms) in the CKMS can enforce them. FR:4.4 The CKMS design shall specify other related security policies that support the CKMS Security Policy. For example FIPS security policy for cryptographic modules in the CKMS.
25 Key Sharing and Accountability FR:4.5 The CKMS design shall specify the policies that describe the conditions under which keys and their metadata may be shared by two or more entities. FR:4.6 The CKMS design shall specify how accountability is enforced by the CKMS.
26 Anonymity FR:4.7 The CKMS design shall specify the anonymity, unlinkability and unobservability protection policies supported, and enforced by the CKMS. FR:4.8 The CKMS design shall specify which CKMS transactions have or can be provided with anonymity protection. FR:4.9 The CKMS design shall specify how CKMS transaction anonymity is achieved when anonymity is provided. FR:4.10 The CKMS design shall specify which CKMS transactions have or can be provided with unlinkability protection. FR:4.11 The CKMS design shall specify how CKMS transaction unlinkability is achieved. FR:4.12 The CKMS design shall specify which CKMS transactions have or can be provided with unobservability protection. FR:4.13 The CKMS design shall specify how CKMS transaction unobservability is achieved.
27 Other Security Domains FR:4.16 The CKMS design shall specify the confidentiality, integrity, and source authentication policies that it enforces when communicating with entities from other security domains. FR:4.17 The CKMS design shall specify what assurances it requires when communicating with entities from other security domains. FR:4.18 The CKMS design shall specify its requirements for reviewing and verifying the security policies of other security domains with which it intends to communicate. FR:4.19 The CKMS design shall specify how it prevents or at least warns an entity of the possible security consequences of communicating with an entity in a security domain with weaker policies. FR:4.20 The CKMS design shall specify its policies regarding thirdparty sharing.
28 Multi-Level Security FR:4.21 The CKMS design shall specify whether or not it supports multi-level security domains. FR:4.22 The CKMS design shall specify each level of security domain that it supports. FR:4.23 The CKMS design shall specify how it maintains the separation of the data belonging to each security level. FR:4.24 The CKMS design shall specify whether or not it permits the upgrading or downgrading of data. FR:4.25 The CKMS design shall specify how upgrading or downgrading capabilities are restricted to the domain security officer.
29 Section 5 Roles and Responsibilities System Authority: A system authority is responsible to executivelevel management (e.g., Chief Information Officer) for the overall operation and security of a CKMS. A system authority manages all operational CKMS roles. An operational role is a role that directly operates the CKMS. System Administrator: System administrators are responsible for the personnel, daily operation, training, maintenance, and related management of a CKMS other than its keys. Cryptographic Officer: A cryptographic officer is authorized to perform cryptographic initialization and management functions on the cryptographic module. Domain Authority: A domain authority is responsible for deciding the conditions necessary for communicating with another security domain and assuring that they are met. Key Custodian: A key custodian is designated to distribute and/or load keys or key splits into a CKMS
30 Roles Continued Key Owner: A key owner is an entity (e.g., person, group, organization, device, or module) authorized to use a cryptographic key or key pair and whose identifier is associated with a cryptographic key or key pair. System User: System users employ the CKMS when key management functions are required to support an application. System users may be, and often are, key owners. Audit Administrator: An audit administrator is responsible for auditing all aspects of a CKMS to verify its security and authorized operation. Registration Agent: A registration agent is responsible for registering new entities and binding their key(s) to their identifiers and perhaps other selected metadata. The registration agent may also enter entities into a database that contains an entity key, the key identifier, and other metadata for each entity. Key Recovery Agent: A key recovery agent is allowed to recover keys from backup or archive storage after identity verification and authorization of the requesting entity CKMS Operator: A CKMS operator is authorized to operate a CKMS in place of the system administrator as directed by the system administrator.
31 Section 6 Keys and Metadata This section contains: A list of types of keys A list of types of metadata A discussion of key lifecycle states and transitions A list of key/metadata management functions Security consideration for keys and metadata in storage and during key establishment Access restrictions to key management functions A discussion of compromise recovery
33 Possible Metadata 1 Key Label: A key label is a text string that provides a human-readable and perhaps machine-readable set of descriptors for the key. Key Identifier: This element is used by the CKMS to select a specific key from a collection of keys. A key identifier is generally unique in a security domain. Owner Identifier: This element specifies the identifier (or identifiers) of the entity (or entities) that owns (or own) the key. Key Life Cycle State: A key life-cycle state is one of a set of finite states that describe the permitted conditions of a cryptographic key Key Format Specifier: This element is used to specify the format for the key.
34 Possible Metadata 2 Product used to create the Key: This element specifies which cryptographic product was used to create or generate the key. Cryptographic Algorithm using the Key: This element specifies the cryptographic algorithm that is intended to use the key. Schemes or Modes of Operation: This element defines the applicable schemes or modes of operation for performing a cryptographic function using a key. Parameters for the Key: This element specifies the parameters, if applicable, for a key. Length of the Key: This element specifies the length of the key in bits (or bytes).
35 Possible Metadata 3 Security Strength of the Key-Algorithm Pair: This element is a number indicating the amount of work (that is, the base 2 logarithm of the number of operations) that is required to break (i.e., cryptanalyze) the cryptographic algorithm. Key Type: This element identifies the key type. Appropriate Applications for the Key: This element specifies applications for which the key may be used. Security Policies Applicable to the Key Type: This element identifies the security policies applicable to the key type. Key Access Control List (ACL): An access control list identifies the entities that can access and/or use the keys Key Usage Count: This element indicates the number of times that the key has been used for a specified purpose (e.g., encryption, decryption, sign, verify, wrap, or rekey). Parent Key: This element points to the key from which the key associated with this metadata is derived.
36 Possible Metadata 4 Key Sensitivity: This element specifies the sensitivity or importance of the key. It could relate to a risk level (e.g., Low, Medium, or High) or a classification level (e.g., Confidential, Secret, or Top Secret) Key Protections: This element specifies the integrity, confidentiality, and source authentication protections applied to the key. Metadata Protections (can be a subset of the key protections or can be different): This element specifies the mechanisms used to provide integrity, confidentiality, and source authentication to the associated metadata. Trusted Association Protections: how the trusted association of metadata to the key is protected
37 Metadata Date-Time Values 1 Generation date: The date-time that a key was generated, Association date: The date-time that a key was associated with its metadata, Activation date: The date-time that a key was first used, Future activation date: The date-time that a key is to be used for the first time, Renewal date: The date-time that a public key was renewed and allowed to be used for a longer period of time, e.g., by generating a new certificate for the same public key as was provided in an old certificate Future renewal data: The date-time that a public key is to be renewed and allowed to be used for a longer period of time Date of the last rekey: The date-time that a key was replaced with a new key that was generated so that it is completely independent of the key that was replaced
38 Metadata Date-Time Values 2 Future rekey date: The date-time that the key is to be replaced with a new key that will be generated so that it is completely independent of the key being replaced, Date of the last key usage: The date-time that the key was last used for a specified purpose, Deactivation date: The date-time that a key was deactivated, Future deactivation date: The date-time that a key is to be deactivated, Expiration date: The date-time that a key s useful lifetime was terminated permanently, Revocation date: The date-time after which a key was no longer considered valid, Compromise date: The date-time that a key a key was known to have been compromised and was marked for replacement and not renewal, Destruction date: The date-time that a key was destroyed, and Future destruction date: The date-time that a key is to be destroyed.
39 Key Management Functions 1 Generate Key The key generation methods and underlying random number generators. Register Owner The initial registration of a security entity and a cryptographic key with metadata is a fundamental requirement of every CKMS. This requirement is difficult to fully automate while preserving security (i.e., protecting from the impersonation threat) and thus, it usually requires human interactions.
40 Key Management Functions 2 Activate/Deactivate Key Normal lifecycle events during processing Suspend/Reactivate Key Temporary response to an unusual condition Revoke Key A cryptographic key should be revoked as soon as feasible after it is no longer authorized for use (e.g., the key has been compromised). Key Renewal Renewal establishes a new validity period for an existing subject public key beyond its previous validity period by issuing a new certificate containing the same public key with a new validity period
41 Key Management Functions 3 Key Derivation Obtaining a key from another secret value Key Update Replacing a key with another derived from the first Key/Metadata Destruction Burning paper, overwriting or destroying digital keys, including in backup storage media.
42 Section 7 Interoperability Interoperability is achieved through the use of: Common interfaces and protocols Common formats for keys, metadata and other exchanged data Compatible data exchange methods and security mechanisms between systems
43 Transitioning Switching from one algorithm or key length to another a smooth transition often requires the capability to support the use of at least two algorithms or key lengths simultaneously interoperability can be maintained until all participants have the capability to operate with the new algorithm or key length the cryptographic protocols should be designed to identify and negotiate which algorithm and key length will be used in a particular key establishment transaction Current cryptographic algorithms should be implemented so that they can be augmented or replaced when needed. See [SP part1] and [SP A] for the NIST-recommended lifetimes of government-approved cryptographic algorithms.
44 Section 8 Security Controls Physical Security Fences, facilities, locks, alarms, cameras, visit logs, etc. Platform Security Self-protection and isolation features Access control Event logging Account management Malware Protection Auditing and Remote Monitoring Network Security Controls Cryptographic Module Controls
45 Section 9 Testing and Assurance Vendor Testing Third-Party Testing Interoperability Testing Self-Tests Performance Tests Security and Functional Tests Limitations of Testing
46 Development Assurance Configuration Management Secure Delivery Development and Maintenance Environment Security Flaw Remediation Capabilities
47 Section 10 Disaster Recovery Facility Damage Utility Service Outage Communication Outage System Hardware Failure System Software Failure Cryptographic Module Failure Key/metadata Corruption
48 Section 11 Security Assessment Third-Party Validations NIST s Cryptographic Algorithm Validation Program (CAVP) tests correctness of algorithm implementations to their standards NIST s Cryptographic Module Validation Program (CMVP) validates cryptographic modules to FIPS requirements Common Criteria validation for non-cryptographic security components
49 Other Assessment Methods Architectural Review Functional and Security Testing Penetration Testing Periodic Security Review Security Maintenance
50 Section 12 Technological Challenges New Attacks on Cryptographic Algorithms A cryptographic algorithm has an expected security life. However, as time passes new attacks may be found that reduce its security life. This, in turn, is likely to reduce the security lifetime of the CKMS that relies on the algorithm to protect data. New Attacks on Key Establishment Protocols Weaknesses are often found in protocols after they have been in use for several years. New Attacks on CKMS Devices New methods for logically attacking computer-based systems are continuously being discovered. Quantum Computing If large qubit quantum computers could be built, then the security of integer factorization and discrete log-based public-key cryptographic algorithms would be threatened.
A Draft Framework for Designing Cryptographic Key Management Systems Elaine Barker Dennis Branstad Santosh Chokhani Miles Smid IEEE Key Management Summit May 4, 2010 Purpose of Presentation To define what
NIST Special Publication 800-152 A Profile for U.S. Federal Cryptographic Key Management Systems Elaine Barker Miles Smid Dennis Branstad This publication is available free of charge from: http://dx.doi.org/10.6028/nist.sp.800-152
NIST Special Publication 800-130 A Framework for Designing Cryptographic Key Management Systems Elaine Barker Miles Smid Dennis Branstad Santosh Chokhani C O M P U T E R S E C U R I T Y NIST Special Publication
Archived NIST Technical Series Publication The attached publication has been archived (withdrawn), and is provided solely for historical purposes. It may have been superseded by another publication (indicated
National Identity Exchange Federation (NIEF) Trustmark Signing Certificate Policy Version 1.1 February 2, 2016 Copyright 2016, Georgia Tech Research Institute Table of Contents TABLE OF CONTENTS I 1 INTRODUCTION
Secure Network Communications FIPS 140 2 Non Proprietary Security Policy 21 June 2010 Table of Contents Introduction Module Specification Ports and Interfaces Approved Algorithms Test Environment Roles
FernUniversität in Hagen: Certification Authority (CA) Certification Practice Statement VERSION 1.1 Ralph Knoche 18.12.2009 Contents 1. Introduction... 4 1.1. Overview... 4 1.2. Scope of the Certification
OFFICE OF THE CONTROLLER OF CERTIFICATION AUTHORITIES TECHNICAL REQUIREMENTS FOR AUDIT OF CERTIFICATION AUTHORITIES Table of contents 1.0 SOFTWARE 1 2.0 HARDWARE 2 3.0 TECHNICAL COMPONENTS 2 3.1 KEY MANAGEMENT
(KMIP) Addressing the Need for Standardization in Enterprise Key Management Version 1.0, May 20, 2009 Copyright 2009 by the Organization for the Advancement of Structured Information Standards (OASIS).
Central Agency for Information Technology Kuwait National IT Governance Framework Information Security Agenda 1 Manage security policy 2 Information security management system procedure Agenda 3 Manage
White Paper Key Management Best Practices Data encryption is a fundamental component of strategies to address security threats and satisfy regulatory mandates. While encryption is not in itself difficult
Using BroadSAFE TM Technology 07/18/05 Layers of a Security System Security System Data Encryption Key Negotiation Authentication Identity Root Key Once root is compromised, all subsequent layers of security
Complying with PCI Data Security Solution BRIEF Retailers, financial institutions, data processors, and any other vendors that manage credit card holder data today must adhere to strict policies for ensuring
NETWORK AND CERTIFICATE SYSTEM SECURITY REQUIREMENTS Scope and Applicability: These Network and Certificate System Security Requirements (Requirements) apply to all publicly trusted Certification Authorities
Apple Inc. Certificate Policy and Certification Practice Statement Version 2.0 Effective Date: April 10, 2015 Table of Contents 1. Introduction... 4 1.1. Trademarks... 4 1.2. Table of acronyms... 4 1.3.
Certification Report EAL 4 Evaluation of SecureDoc Disk Encryption Version 4.3C Issued by: Communications Security Establishment Certification Body Canadian Common Criteria Evaluation and Certification
Best Practices for Key Management for Secure Storage Walt Hubis, LSI Corporation SNIA Legal Notice The material contained in this tutorial is copyrighted by the SNIA. Member companies and individuals may
Acquire or develop application systems software Controls provide reasonable assurance that application and system software is acquired or developed that effectively supports financial reporting requirements.
Plain English Guide To Common Criteria Requirements In The Field Device Protection Profile Version 0.75 Prepared For: Process Control Security Requirements Forum (PCSRF) Prepared By: Digital Bond, Inc.
CONTENTS 1. Executive Summary 2. Need for Data Security 3. Solution: nwstor isav Storage Security Appliances 4. Conclusion 1. EXECUTIVE SUMMARY The advantages of networked data storage technologies such
NIST Special Publication 800-133 Recommendation for Cryptographic Key Generation Elaine Barker Allen Roginsky http://dx.doi.org/10.6028/nist.sp.800-133 C O M P U T E R S E C U R I T Y NIST Special Publication
Compliance HIPAA Security COMPLIANCE Checklist For Employers All of the following steps must be completed by April 20, 2006 (April 14, 2005 for Large Health Plans) Broadly speaking, there are three major
6 th Floor, Tower A, 1 CyberCity, Ebene, Mauritius T + 230 403 6000 F + 230 403 6060 E ReachUs@abaxservices.com INFORMATION SECURITY POLICY DOCUMENT Information Security Policy Document Page 2 of 15 Introduction
Certification Report EAL 4+ Evaluation of ncipher nshield Family of Hardware Security Modules Firmware Version 2.33.60 Issued by: Communications Security Establishment Canada Certification Body Canadian
Lecture VII : Public Key Infrastructure (PKI) Internet Security: Principles & Practices John K. Zao, PhD (Harvard) SMIEEE Computer Science Department, National Chiao Tung University 2 Problems with Public
XN--P1AI (РФ) DNSSEC Policy and Practice Statement XN--P1AI (РФ) DNSSEC Policy and Practice Statement... 1 INTRODUCTION... 2 Overview... 2 Document name and identification... 2 Community and Applicability...
SMPTE Standards Transition Issues for NIST/FIPS Requirements v1.1 Contents 2010.8.23 DRM inside, Taehyun Kim ETRI, Kisoon Yoon 1 Introduction NIST (National Institute of Standards and Technology) published
Information Security Basic Concepts 1 What is security in general Security is about protecting assets from damage or harm Focuses on all types of assets Example: your body, possessions, the environment,
Enterprise Key Management: A Strategic Approach ENTERPRISE KEY MANAGEMENT A SRATEGIC APPROACH White Paper February 2010 www.alvandsolutions.com Overview Today s increasing security threats and regulatory
White Paper: Librestream Security Overview TABLE OF CONTENTS 1 SECURITY OVERVIEW... 3 2 USE OF SECURE DATA CENTERS... 3 3 SECURITY MONITORING, INTERNAL TESTING AND ASSESSMENTS... 4 3.1 Penetration Testing
NIST Special Publication 800-131A Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths Elaine Barker and Allen Roginsky Computer Security Division Information
It is a well-known fact in computer security that security problems are very often a direct result of software bugs. That leads security researches to pay lots of attention to software engineering. The
Cryptography and Network Security Third Edition by William Stallings Lecture slides by Shinu Mathew John http://shinu.info/ Chapter 1 Introduction http://shinu.info/ 2 Background Information Security requirements
Pulse Secure Network Connect Cryptographic Module Version 2.0 Non-Proprietary Security Policy Document Version 1.1 Pulse Secure, LLC. January 9, 2015 2015 by Pulse Secure, LLC. All rights reserved. May
COMPANY INFO 1 (23) Ericsson Group Certificate Value Statement - 2013 COMPANY INFO 2 (23) Contents 1 Ericsson Certificate Value Statement... 3 2 Introduction... 3 2.1 Overview... 3 3 Contact information...
Document history Version Date Remarks 1.0 19-05-2011 finalized 1.01 15-11-2012 URL updated after web page restructuring. 2 Table of Contents 1. Introduction... 4 2. Policy administration... 4 2.1 Overview...
Newcastle University Information Security Procedures Version 3 A Information Security Procedures 2 B Business Continuity 3 C Compliance 4 D Outsourcing and Third Party Access 5 E Personnel 6 F Operations
Polish Grid Certification Authority Certificate Policy and Certification Practice Statement version 0.4 (DRAFT ) September 2, 2002 1 1 Introduction 1.1 Overview This document is written according to the
Information Security Policies Version 6.1 Information Security Policies Contents: 1. Information Security page 3 2. Business Continuity page 5 3. Compliance page 6 4. Outsourcing and Third Party Access
Certification Report HP Network Automation Ultimate Edition 10.10 Issued by: Communications Security Establishment Certification Body Canadian Common Criteria Evaluation and Certification Scheme Government
Cryptography and Network Security Chapter 1 Acknowledgments Lecture slides are based on the slides created by Lawrie Brown Chapter 1 Introduction The art of war teaches us to rely not on the likelihood
A Security Flaw in the X509 Standard Santosh Chokhani CygnaCom Solutions, Inc Abstract The CCITT X509 standard for public key certificates is used to for public key management, including distributing them
NIST 800-53A: Guide for Assessing the Security Controls in Federal Information Systems Samuel R. Ashmore Margarita Castillo Barry Gavrich CS589 Information & Risk Management New Mexico Tech Spring 2007
2 Introduction to Security : IT Security Sirindhorn International Institute of Technology Thammasat University Prepared by Steven Gordon on 25 October 2013 its335y13s2l01, Steve/Courses/2013/s2/its335/lectures/intro.tex,
PART 10 COMPUTER SYSTEMS 10-1 PART 10 COMPUTER SYSTEMS The following is a general outline of steps to follow when contemplating the purchase of data processing hardware and/or software. The State Board
Credit Card Security Created 16 Apr 2014 Revised 16 Apr 2014 Reviewed 16 Apr 2014 Purpose This policy is intended to ensure customer personal information, particularly credit card information and primary
SecureDoc Disk Encryption Cryptographic Engine FIPS 140-2 Non-Proprietary Security Policy Abstract: This document specifies Security Policy enforced by SecureDoc Cryptographic Engine compliant with the
Safeguarding Data Using Encryption Matthew Scholl & Andrew Regenscheid Computer Security Division, ITL, NIST What is Cryptography? Cryptography: The discipline that embodies principles, means, and methods
Information Technology Security Policy for IBTS Pakistan Stock Exchange Limited Table of contents Information Technology Security Policy for IBTS 1- INTRODUCTION AND SCOPE... 3 2- CHARTER OF THE DOCUMENT...
Privacy Compliance Healthcare Compliance Solutions Trust and privacy are essential for building meaningful human relationships. Let Protected Trust be your Safe Harbor The U.S. Department of Health and
Guide to Data Field Encryption Contents Introduction 2 Common Concepts and Glossary 3 Encryption 3 Data Field Encryption 3 Cryptography 3 Keys and Key Management 5 Secure Cryptographic Device 7 Considerations
Healthcare Compliance Solutions Let Protected Trust be your Safe Harbor In the Health Information Technology for Economic and Clinical Health Act of 2009 (HITECH), the U.S. Department of Health and Human
IT Best Practices Audit TCS offers a wide range of IT Best Practices Audit content covering 15 subjects and over 2200 topics, including: 1. IT Cost Containment 84 topics 2. Cloud Computing Readiness 225
Detailed Review Abstract This white paper provides a detailed description of EMC Symmetrix Data at Rest Encryption features and operations. March 2011 Copyright 2010, 2011 EMC Corporation. All rights reserved.
John Essner, CISO Office of Information Technology State of New Jersey http://csrc.nist.gov/publications/nistpubs/800-144/sp800-144.pdf Governance Compliance Trust Architecture Identity and Access Management
INFORMATION SECURITY SPECIFIC VENDOR COMPLIANCE PROGRAM (VCP) ACME Consulting Services, Inc. Copyright 2016 Table of Contents INSTRUCTIONS TO VENDORS 3 VENDOR COMPLIANCE PROGRAM OVERVIEW 4 VENDOR COMPLIANCE
Understanding the Role of Hardware Data Encryption in EMV and P2PE from the CEO s Perspective Futurex. An Innovative Leader in Encryption Solutions. For over 30 years, more than 15,000 customers worldwide
Module 7 Security CS655! 7-1! Issues Separation of! Security policies! Precise definition of which entities in the system can take what actions! Security mechanism! Means of enforcing that policy! Distributed
SOFTWARE ASSET MANAGEMENT Continuous Monitoring September 16, 2013 Tim McBride National Cybersecurity Center of Excellence firstname.lastname@example.org David Waltermire Information Technology Laboratory email@example.com
Threat Model for Software Reconfigurable Communications Systems Presented to the Management Group 6 March 007 Bernard Eydt Booz Allen Hamilton Chair, SDR Security Working Group Overview Overview of the
Comparison of Controls between ISO/IEC 27001:2013 & ISO/IEC 27001:2005 Introduction The new standard ISO/IEC 27001:2013 has been released officially on 1 st October 2013. Since we understand that information
LAW No. 135 of May 15 th 2007 on archiving documents in electronic format ISSUER: THE PARLIAMENT OF ROMANIA PUBLISHED WITH: THE OFFICIAL GAZETTE NO. 345 of May 22 nd 2007 The Parliament of Romania passes
VICTORIA UNIVERSITY OF WELLINGTON Te Whare Wānanga o te Ūpoko o te Ika a Māui School of Engineering and Computer Science Te Kura Mātai Pūkaha, Pūrorohiko PO Box 600 Wellington New Zealand Tel: +64 4 463
THE RSA ROOT SIGNING SERVICE Certification Practice Statement For RSA Certificate Authorities (CAs) Last Revision Date: June 28, 2007 Version: 3.0 Published By: RSA Security Inc. Copyright 2002-2007 by
American International Group, Inc. DNS Practice Statement for the AIG Zone Version 0.2 1 Table of contents 1 INTRODUCTION... 6 1.1 Overview...6 1.2 Document Name and Identification...6 1.3 Community and
Certification Practice Statement of the Federal Reserve Banks Services Public Key Infrastructure 1.0 INTRODUCTION 1.1 Overview The Federal Reserve Banks operate a public key infrastructure (PKI) that manages
Summary of CIP Version 5 Standards In Version 5 of the Critical Infrastructure Protection ( CIP ) Reliability Standards ( CIP Version 5 Standards ), the existing versions of CIP-002 through CIP-009 have
Course Outline: Fundamental Topics System View of Network Security Network Security Model Security Threat Model & Security Services Model Overview of Network Security Security Basis: Cryptography Secret
CERTIFICATE HUNGUARD Informatics and IT R&D and General Service Provider Ltd. as a certification authority assigned by the assignment document No. 001/2010 of the Minister of the Prime Minister s Office
UNCLASSIFIED 24426399 CPA SECURITY CHARACTERISTIC ENTERPRISE MANAGEMENT OF DATA AT REST ENCRYPTION Version 1.0 Crown Copyright 2013 All Rights Reserved UNCLASSIFIED Page 1 UNCLASSIFIED Enterprise Management
FIPS 140 2 Non Proprietary Security Policy Kingston Technology Company, Inc. DataTraveler DT4000 G2 Series USB Flash Drive Document Version 1.8 December 3, 2014 Document Version 1.8 Kingston Technology
GPO Box 2343 ADELAIDE SA 5001 Tel (08) 8204 8773 Fax (08) 8204 8777 DX:467 firstname.lastname@example.org www.archives.sa.gov.au Management of Official Records in a Business System October 2011 Version
Public Key Certification Infrastructure Petr Hanácek email@example.com Faculty of Electrical Engineering and Computer Science Brno University of Technology Abstract Jan Staudek firstname.lastname@example.org
SWIFT SWIFT Qualified Certificates Certificate Policy This Certificate Policy applies to Qualified Certificates issued by SWIFT. It indicates the requirements and procedures to be followed, and the responsibilities
White Paper EMC DATA DOMAIN ENCRYPTION A Detailed Review Abstract The proliferation of publicized data loss, coupled with new governance and compliance regulations, is driving the need for customers to
Data Protection: From PKI to Virtualization & Cloud Raymond Yeung CISSP, CISA Senior Regional Director, HK/TW, ASEAN & A/NZ SafeNet Inc. Agenda What is PKI? And Value? Traditional PKI Usage Cloud Security
Content 1.Introduction to Data and Network Security. 2. Why secure your Network 3. How Much security do you need, 4. Communication of network systems, 5. Topology security, 6. Cryptosystems and Symmetric
Preface This Key Recovery Policy (KRP) is provided as a requirements document to the External Certification Authorities (ECA). An ECA must implement key recovery policies, procedures, and mechanisms that
BMC s Security Strategy for ITSM in the SaaS Environment TABLE OF CONTENTS Introduction... 3 Data Security... 4 Secure Backup... 6 Administrative Access... 6 Patching Processes... 6 Security Certifications...
Technical Proposition ADAM Software NV The global provider of media workflow and marketing technology software ADAM Software NV adamsoftware.net email@example.com Why Read this Technical Proposition?
Office of the Chief Information Officer Online File Storage BACKGROUND Online file storage services offer powerful and convenient methods to share files among collaborators, various computers, and mobile