Sample Encryption Standard:: Difference between revisions

From HORSE - Holistic Operational Readiness Security Evaluation.
Jump to navigation Jump to search
No edit summary
 
(5 intermediate revisions by 2 users not shown)
Line 1: Line 1:
=='''Sample Encryption Standard'''==
==Sample Encryption Standard==
<br>
This Encryption Standard builds on the objectives established in the Asset Protection Standard, and provides specific instructions and requirements for the encryption of sensitive information assets.
The '''<Your Company Name>''' (the "Company") [[Sample Asset Protection Policy:|'''Sample Asset Protection Policy''']] defines objectives for establishing specific standards for protecting the confidentiality, integrity, and availability of '''<Your Company Name>''' information assets.<br>
<br>
This [[Encryption]] Standard builds on the objectives established in the [[Sample Asset Protection Policy:|'''Sample Asset Protection Policy''']], and provides specific instructions and requirements for the [[Encryption | encryption]] of sensitive information assets.<br>
<br>


=='''I. Scope'''==
==Objectives==
<br>
# '''General Requirements'''
All employees, contractors, part-time and temporary workers, and those employed by others to perform work on Company premises or who have been granted access to Company information or systems, are covered by this standard and must comply with associated guidelines and procedures.<br>
## Encryption shall be used to protect the confidentiality and integrity of sensitive Company information assets in accordance with the Information Handling Standard and the Integrity Protection Standard.
<br>
## The use of Company-approved encryption shall be governed in accordance with the laws of the country, region, or other regulating entity in which Users perform their work. Encryption shall not be used to violate any laws or regulations.
'''Additional Decryption Key''' refers to a public key that can be used, under certain circumstances, to decrypt messages sent or received by Users.<br>
## The Chief Administrative Officer (CAO) must approve all Company encryption processes before they are used.
<br>
## Encryption keys are considered sensitive Company information and access to them must be restricted on a need to know basis.
'''Confidentiality''' refers to protecting confidential information from disclosure. Information shall be disclosed only to those authorized to access it.<br>
## Any potential or actual compromise of a User's encryption key must be reported to Lazarus Alliance, LLC. Information Security immediately so that the certificate may be revoked or at least within twenty-four (24) hours of discovery.
<br>
# '''Message Digest Algorithms'''
'''Corporate Signing Key''' refers to a public key that is designated as the system-wide key that is trusted by all Users to sign other keys.<br>
## The following are Company-approved message digest algorithms:
<br>
### SHA-1 with 128-bit or 160 bit key
'''[[Encryption]]''' refers to a method of scrambling information to render it unreadable to anyone except the intended recipient, who must decrypt it to read it.<br>
### SHA-2 with 224- bit or 256-bit or 384-bit or 512 bit-key
<br>
# '''Symmetric Key Algorithms'''
'''Information assets''' are defined in the [[Sample Asset Identification and Classification Policy:|'''Sample Asset Identification and Classification Policy''']].<br>
## The following are Company-approved symmetric block cipher algorithms:
<br>
### AES
'''Integrity''' refers to the protection of information and systems from malicious, unauthorized, or accidental changes.<br>
### CAST5 (using a 128-bit key)
<br>
### Triple-DES
'''Message Digest Algorithm''' refers to a "thumbprint" that is mathematically derived from a message to ensure integrity.<br>
## Exceptions:
<br>
### Authorized for usage in currently deployed production systems as of September 12, 2013. Grandfathered systems and applications will remain until the system is replaced or the encryption algorithm is updated to an approved level and the system or application is removed from exception status.
'''Public Key Algorithm''' refers to a mathematical function or process that generates two mathematically related keys such that the information encrypted with one key can be decrypted only with the other key.<br>
### As of May 2010, 3DES is still authorized by Visa and the other PCI consortium. Key size options are 56, 122, and 168. We should promote 168 bit keys if 3DES is used instead of AES.
<br>
## Prior to using encryption with any of the Company-approved symmetric encryption algorithms, the encryption key must be provided to Information Security to ensure appropriate Company representatives can retrieve information should the need arise.
'''Sensitive information''' refers to information that is classified as Restricted or Confidential. Refer to the [[Sample Information Classification Standard:|'''Sample Information Classification Standard''']] for confidentiality classification categories.<br>
## Symmetric keys should be generated and handled in accordance with Company password standards established in the Access Control Standard.
<br>
# '''Public Key Algorithms'''
'''Session Key''' refers to the symmetric key used to encrypt each set of data on a per transaction basis. A different key is used for each communication session.<br>
## The following are Company-approved public-key algorithms:
<br>
### [RSA with 1024-bit or stronger bit key]
'''Symmetric Block Cipher Algorithm''' refer to method of text encryption to produce encrypted or cipher text in which a cryptographic key and algorithm are applied to a block of data at once as a group rather than to one bit at a time.<br>
## Public key encryption packages must use Corporate Signing Keys or Additional Decryption Keys to ensure the Company can retrieve the encrypted information should the need arise.
<br>
## Temporary session keys used by public key cryptosystems such as Virtual Private Networks (VPN) are exempt from escrow.
'''Symmetric Key Algorithm''' refers to a mathematical function or process where encryption and decryption keys are either the same or can be calculated from one another.<br>
## Users shall not extend trust to non-Company public keys without approval of Lazarus Alliance, LLC. Information Security.
## Public keys should be generated and handled in accordance with Company password standards established in the Access Control Standard.
## Public key pass-phrases should contain more than one word and a minimum of ten (10) total characters.
<br>
<br>


=='''II. Requirements'''==
==Document Examples==
<br>
Use these samples as a guide for your policy development. Fully customizable versions are available from [http://policy-machine.com The Policy Machine].<br>
'''A. General Requirements'''<br>
<br>
::1. Encryption shall be used to protect the confidentiality and integrity of sensitive Company information assets in accordance with the [[Sample Information Handling Standard:|'''Sample Information Handling Standard''']] and the [[Sample Integrity Protection Standard:|'''Sample Integrity Protection Standard''']].<br>
<br>
::2. The use of Company-approved encryption shall be governed in accordance with the laws of the country, region, or other regulating entity in which Users perform their work. Encryption shall not be used to violate any laws or regulations.<br>
<br>
::3. <SPECIFY ROLE OR DEPARTMENT> must approve all Company encryption processes before they are used.<br>
<br>
::4. Encryption keys are considered sensitive Company information and access to them must be restricted on a need to know basis.<br>
<br>
::5. Any potential or actual compromise of an User's encryption key must be reported to <SPECIFY TITLE OR DEPARTMENT> within <SPECIFY TIMEFRAME>.<br>
<br>
'''B. Message Digest Algorithms'''<br>
<br>
::1. The following are Company-approved message digest algorithms:<br>
<br>
::*SHA-1 with 128-bit or 160 bit key<br>
::*MD5<br>
<br>
::2. MD5 shall be used for file hashing only.<br>
<br>
::3. MD5 shall not be used in signatures or certificates.<br>
<br>
'''C. Smmetric Key Algorithms'''<br>
<br>
::1. The following are Company-approved symmetric block cipher algorithms:<br>
<br>
::*Triple-DES<br>
::*Blow Fish<br>
<br>
::2. Prior to using encryption with any of the Company-approved symmetric encryption algorithms, the encryption key must be provided to <SPECIFY THE CENTRAL COMPANY KEY ESCROW NAME> to ensure appropriate Company representatives can retrieve information should the need arise.<br>
<br>
::3. Symmetric keys should be generated and handled in accordance with Company password standards established in the [[Sample Access Control Standard:|'''Sample Access Control Standard''']].<br>
<br>
'''D. Public Key Algorithms'''<br>
<br>
::1. The following are Company-approved public-key algorithms:<br>
<br>
::*RSA with <SPECIFY #>-bit to <SPECIFY #>-bit key<br>
::*Diffie-Hellman with <SPECIFY #>-bit to <SPECIFY #>-bit key<br>
<br>
::2. Public key encryption packages must use Corporate Signing Keys or Additional Decryption Keys to ensure the Company can retrieve the encrypted information should the need arise.<br>
<br>
::3. Temporary session keys used by public key cryptosystems such as Virtual Private Networks (VPN) are exempt from escrow.<br>
<br>
::4. Users shall not extend trust to non-Company public keys without approval of <SPECIFY>.<br>
<br>
::5. Public keys should be generated and handled in accordance with Company password standards established in the [[Sample Access Control Standard:|'''Sample Access Control Standard''']].<br>
<br>
::6. Public key pass-phrases should contain more than one word and a minimum of <SPECIFY #> total characters.<br>
<br>
=='''III. Responsibilities'''==
<br>
The Chief Information Security Officer (CISO) approves the Encryption Standard. The CISO also is responsible for ensuring the development, implementation, and maintenance of the Encryption Standard.<br>
<br>
Company management, including senior management and department managers, is accountable for ensuring that the Encryption Standard is properly communicated and understood within their respective organizational units. Company management also is responsible for defining, approving and implementing procedures in its organizational units and ensuring their consistency with the Encryption Standard.<br>
<br>
Asset Owners (Owners) are the managers of organizational units that have primary responsibility for information assets associated with their functional authority. When Owners are not clearly implied by organizational design, the CIO will make the designation. The Owner is responsible for defining process and procedures that are consistent with the Encryption Standard and associated guidelines, and determining the business impact if the integrity of an information asset is compromised.<br>
<br>
Asset Custodians (Custodians) are the managers, administrators and those designated by the Owner to manage, process or store information assets. Custodians are responsible for providing a secure processing environment that protects the confidentiality, integrity, and availability of information, and coordinating with administrators to ensure proper encryption controls are used.<br>
<br>
Users are the individuals, groups, or organizations authorized by the Owner to access to information assets. Users are responsible for familiarizing and complying with the Encryption Standard and associated guidelines; properly using Company-approved encryption to safeguard sensitive company information; and reporting loss or compromise of any encryption keys within <SPECIFY TIMEFRAME> to <SPECIFY ROLE OR DEPARTMENT> and immediate supervisor.<br>
<br>
=='''IV. Enforcement and Exception Handling'''==
<br>
Failure to comply with the Encryption Standard and associated guidelines and procedures can result in disciplinary actions up to and including termination of employment for employees or termination of contracts for contractors, partners, consultants, and other entities. Legal actions also may be taken for violations of applicable regulations and laws.<br>
<br>
Requests for exceptions to the Encryption Standard should be submitted to <Insert Title> in accordance with the Information Security Standards Exception Procedure. Prior to official management approval of any exception request, the individuals, groups, or organizations identified in the scope of this standard will continue to observe the Encryption Standard.<br>
<br>
=='''V. Review and Revision'''==
<br>
The Encryption Standard will be reviewed and revised in accordance with the [[Sample Information Security Program Charter:|'''Sample Information Security Program Charter''']].<br>
<br>
Approved: _______________________________________________________<br>
<br>
::Signature<br>
<br>
::<Insert Name><br>
<br>
::Chief Information Security Officer<br>
<br>
<br>
<gallery>
Image:Encryption Standard.png|Encryption Standard page one of eight.
Image:Encryption Standard(1).png|Encryption Standard page two of eight
Image:Encryption Standard(2).png|Encryption Standard page three of eight
Image:Encryption Standard(3).png|Encryption Standard page four of eight
Image:Encryption Standard(4).png|Encryption Standard page five of eight
Image:Encryption Standard(5).png|Encryption Standard page six of eight
Image:Encryption Standard(6).png|Encryption Standard page seven of eight
Image:Encryption Standard(7).png|Encryption Standard page eight of eight.
</gallery>

Latest revision as of 15:12, 21 January 2014

Sample Encryption Standard

This Encryption Standard builds on the objectives established in the Asset Protection Standard, and provides specific instructions and requirements for the encryption of sensitive information assets.

Objectives

  1. General Requirements
    1. Encryption shall be used to protect the confidentiality and integrity of sensitive Company information assets in accordance with the Information Handling Standard and the Integrity Protection Standard.
    2. The use of Company-approved encryption shall be governed in accordance with the laws of the country, region, or other regulating entity in which Users perform their work. Encryption shall not be used to violate any laws or regulations.
    3. The Chief Administrative Officer (CAO) must approve all Company encryption processes before they are used.
    4. Encryption keys are considered sensitive Company information and access to them must be restricted on a need to know basis.
    5. Any potential or actual compromise of a User's encryption key must be reported to Lazarus Alliance, LLC. Information Security immediately so that the certificate may be revoked or at least within twenty-four (24) hours of discovery.
  2. Message Digest Algorithms
    1. The following are Company-approved message digest algorithms:
      1. SHA-1 with 128-bit or 160 bit key
      2. SHA-2 with 224- bit or 256-bit or 384-bit or 512 bit-key
  3. Symmetric Key Algorithms
    1. The following are Company-approved symmetric block cipher algorithms:
      1. AES
      2. CAST5 (using a 128-bit key)
      3. Triple-DES
    2. Exceptions:
      1. Authorized for usage in currently deployed production systems as of September 12, 2013. Grandfathered systems and applications will remain until the system is replaced or the encryption algorithm is updated to an approved level and the system or application is removed from exception status.
      2. As of May 2010, 3DES is still authorized by Visa and the other PCI consortium. Key size options are 56, 122, and 168. We should promote 168 bit keys if 3DES is used instead of AES.
    3. Prior to using encryption with any of the Company-approved symmetric encryption algorithms, the encryption key must be provided to Information Security to ensure appropriate Company representatives can retrieve information should the need arise.
    4. Symmetric keys should be generated and handled in accordance with Company password standards established in the Access Control Standard.
  4. Public Key Algorithms
    1. The following are Company-approved public-key algorithms:
      1. [RSA with 1024-bit or stronger bit key]
    2. Public key encryption packages must use Corporate Signing Keys or Additional Decryption Keys to ensure the Company can retrieve the encrypted information should the need arise.
    3. Temporary session keys used by public key cryptosystems such as Virtual Private Networks (VPN) are exempt from escrow.
    4. Users shall not extend trust to non-Company public keys without approval of Lazarus Alliance, LLC. Information Security.
    5. Public keys should be generated and handled in accordance with Company password standards established in the Access Control Standard.
    6. Public key pass-phrases should contain more than one word and a minimum of ten (10) total characters.


Document Examples

Use these samples as a guide for your policy development. Fully customizable versions are available from The Policy Machine.

  • Encryption Standard page one of eight.

    Encryption Standard page one of eight.

  • Encryption Standard page two of eight

    Encryption Standard page two of eight

  • Encryption Standard page three of eight

    Encryption Standard page three of eight

  • Encryption Standard page four of eight

    Encryption Standard page four of eight

  • Encryption Standard page five of eight

    Encryption Standard page five of eight

  • Encryption Standard page six of eight

    Encryption Standard page six of eight

  • Encryption Standard page seven of eight

    Encryption Standard page seven of eight

  • Encryption Standard page eight of eight.

    Encryption Standard page eight of eight.

Retrieved from "http://horseproject.wiki/index.php?title=Sample_Encryption_Standard:&oldid=10032"