Sample Encryption Standard:: Difference between revisions

From HORSE - Holistic Operational Readiness Security Evaluation.
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
==Document History==
==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.
{| id="table1" width="100%" border="1"
 
| bgcolor="#C0C0C0" | '''Version'''
==Objectives==
| bgcolor="#C0C0C0" | '''Date'''
# '''General Requirements'''
| bgcolor="#C0C0C0" | '''Revised By'''
## 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.
| bgcolor="#C0C0C0" | '''Description'''
## 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.
|-
## The Chief Administrative Officer (CAO) must approve all Company encryption processes before they are used.
| 1.0
## Encryption keys are considered sensitive Company information and access to them must be restricted on a need to know basis.
| 1 January 2009 <Current date>
## 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.
| Michael D. Peters '''<Owners's name>'''
# '''Message Digest Algorithms'''
| This version replaces any prior version.
## The following are Company-approved message digest algorithms:
|}
### SHA-1 with 128-bit or 160 bit key
<br>
### SHA-2 with 224- bit or 256-bit or 384-bit or 512 bit-key
==Document Certification==
# '''Symmetric Key Algorithms'''
<br>
## The following are Company-approved symmetric block cipher algorithms:
{| id="table1" width="100%" border="1"
### AES
| bgcolor="#C0C0C0" | '''Description'''
### CAST5 (using a 128-bit key)
| bgcolor="#C0C0C0" | '''Date Parameters'''
### Triple-DES
|-
## Exceptions:
| '''Designated document recertification cycle in days:'''
### 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.
| 30 - 90 - 180 - '''365''' '''<Select cycle>'''
### 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.
|-
## 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.
| '''Next document recertification date:'''
## Symmetric keys should be generated and handled in accordance with Company password standards established in the Access Control Standard.
| 1 January 2010 '''<Date>'''
# '''Public Key Algorithms'''
|}
## The following are Company-approved public-key algorithms:
<br>
### [RSA with 1024-bit or stronger bit key]
=='''Sample Encryption Standard'''==
## 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.
The '''<Your Company Name>''' (the "Company") [[Sample Asset Protection Standard:|'''Sample Asset Protection Standard''']] defines objectives for establishing specific standards for protecting the confidentiality, integrity, and availability of '''<Your Company Name>''' information assets.<br>
## Users shall not extend trust to non-Company public keys without approval of Lazarus Alliance, LLC. Information Security.
<br>
## Public keys should be generated and handled in accordance with Company password standards established in the Access Control Standard.
This [[Encryption]] Standard builds on the objectives established in the [[Sample Asset Protection Standard:|'''Sample Asset Protection Standard''']], and provides specific instructions and requirements for the [[Encryption | encryption]] of sensitive information assets.<br>
## Public key pass-phrases should contain more than one word and a minimum of ten (10) total characters.
<br>
<br>


=='''I. Scope'''==
==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>
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>
<br>
'''Additional Decryption Key''' refers to a public key that can be used, under certain circumstances, to decrypt messages sent or received by Users.<br>
<br>
'''Confidentiality''' refers to protecting confidential information from disclosure. Information shall be disclosed only to those authorized to access it.<br>
<br>
'''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>
<br>
'''[[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>
<br>
'''Information assets''' are defined in the [[Sample Asset Identification and Classification Standard:|'''Sample Asset Identification and Classification Standard''']].<br>
<br>
'''Integrity''' refers to the protection of information and systems from malicious, unauthorized, or accidental changes.<br>
<br>
'''Message Digest Algorithm''' refers to a "thumbprint" that is mathematically derived from a message to ensure integrity.<br>
<br>
'''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>
<br>
'''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>
<br>
'''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>
<br>
'''Symmetric Block Cipher Algorithm''' refers to method of text [[Encryption | 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>
<br>
'''Symmetric Key Algorithm''' refers to a mathematical function or process where [[Encryption  | encryption]] and decryption keys are either the same or can be calculated from one another.<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>


=='''II. Requirements'''==
<br>
'''A. General Requirements'''<br>
<br>
::1. [[Encryption | 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 | 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 | encryption]] processes before they are used.<br>
<br>
::4. [[Encryption | 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 a 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>
::*SHA-2 with 224- bit or 256-bit or 384-bit or 512 bit-key<br>
<br>
'''C. Symmetric Key Algorithms'''<br>
<br>
::1. The following are Company-approved symmetric block cipher algorithms:<br>
<br>
::*CAST5 (using a 128-bit key)<br>
::*AES<br>
<br>
::2. Prior to using [[Encryption | encryption]] with any of the Company-approved symmetric [[Encryption | encryption]] algorithms, the [[Encryption | 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>
::*AES with <SPECIFY #>-bit to <SPECIFY #>-bit key<br>
<br>
::2. Public key [[Encryption | 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'''==
[[file:Encryption Standard.png]]
<br>
[[file:Encryption Standard(1).png]]
The Chief Information Security Officer (CISO) approves the [[Encryption | encryption]] Standard. The CISO also is responsible for ensuring the development, implementation, and maintenance of the Encryption Standard.<br>
[[file:Encryption Standard(2).png]]
<br>
[[file:Encryption Standard(3).png]]
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>
[[file:Encryption Standard(4).png]]
<br>
[[file:Encryption Standard(5).png]]
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>
[[file:Encryption Standard(6).png]]
<br>
[[file:Encryption Standard(7).png]]
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 | encryption]] to safeguard sensitive company information; and reporting loss or compromise of any [[Encryption | 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 the Company CISO. Exceptions shall be permitted only on receipt of written approval from the CISO. The CISO will periodically report current status to the Company CIO or its designee.<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><br>
Recommended:        _______________________________________________________<br>
<br>
::Signature
::<Typed Name>
::Chief Information Security Officer
<br>
Approved:        _______________________________________________________<br>
<br>
::Signature
::<Typed Name>
::Chief Information Officer

Revision as of 15:08, 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.