Sample Access Control Standard:: Difference between revisions

From HORSE - Holistic Operational Readiness Security Evaluation.
Jump to navigation Jump to search
No edit summary
Line 1: Line 1:
==Document History==
==Sample Access Control Standard==
<br>
This Access Control Standard builds on the objectives established in the [[Sample Asset Protection Policy:|'''Sample Asset Protection Standard''']], and provides specific instructions and requirements for the proper identification, authentication, and authorization controls necessary to access Company information assets.
{| id="table1" width="100%" border="1"
 
| bgcolor="#C0C0C0" | '''Version'''
==Objectives==
| bgcolor="#C0C0C0" | '''Date'''
# '''Identification'''
| bgcolor="#C0C0C0" | '''Revised By'''
## Each User must have a unique account identifier or user ID.
| bgcolor="#C0C0C0" | '''Description'''
## User communities and working groups must not share a single user ID for system access to ensure accurate accounting of user access and actions.
|-
## User IDs should not be shared or used by anyone other than the User to whom they are assigned. Users shall be accountable for all activity associated with their assigned user IDs.
| 1.0
## User IDs should be added, modified, and deleted in accordance with Company-approved account management processes.
| 1 January 2009 <Current date>
## User IDs must be disabled within twenty-four (24) hours of notification of a status change (for example, resignation or change in job).
| Michael D. Peters '''<Owners's name>'''
### User IDs must be disabled as soon as possible (Immediately) when user has been terminated under adversarial conditions to prevent retaliatory risks to company assets, resources, reputation, and employees. Any requests must come from MediaWiki system to satisfy historical tracking, compliance requirements and audit requirements.
| This version replaces any prior version.
## User IDs that are unused, dormant, or inactive for 15 days must be disabled.
|}
## User IDs that are disabled for 90 days must be deleted.
<br>
## Temporary User IDs (for testing, contractors and temporary employees) should have an account expiration date that coincides with the anticipated end of employment, testing, or contract.
==Document Certification==
# '''Authentication'''
<br>
## Each user ID or account must be assigned a password.
{| id="table1" width="100%" border="1"
## Passwords on new accounts must expire upon first log-in and require an immediate password change.
| bgcolor="#C0C0C0" | '''Description'''
## All default system and application passwords must be changed prior to placing in the production environment or connecting to a live network.
| bgcolor="#C0C0C0" | '''Date Parameters'''
## Authentication credentials such as passwords and tokens should not be used by anyone other than the User to whom they are assigned.
|-
## Passwords must conform to the following criteria, with native system enforcement when possible:
| '''Designated document recertification cycle in days:'''
### Password length must be eight (8) characters or longer. If the system does not support eight (8) characters, the password must contain the maximum number of characters allowed by the system.
| 30 - 90 - 180 - '''365''' '''<Select cycle>'''
### Passwords must not be equal to, or a derivative of, the user ID.
|-
### Passwords must contain at least one (1) alphabetic and one (1) non-alphabetic character.
| '''Next document recertification date:'''
## When password criteria cannot be enforced by the native system, an automated password system or tool should be used, whenever possible, to verify and enforce the password criteria.
| 1 January 2010 '''<Date>'''
## Password changes are required every ninety (90) days.
|}
## Password changes are required every three hundred and sixty-five (365) days for service and system IDs accounts, or within twenty-four (24) hours upon the termination of any employee with knowledge of the password to service and system IDs accounts.
<br>
### The account name and password must be transcribed onto a physical document containing the following information:
=='''Sample Access Control Standard'''==
#### Custodians name and position
<br>
#### Date of creation
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>
#### Date of recertification
<br>
#### Asset account belongs to
This Access Control Standard builds on the objectives established in the [[Sample Asset Protection Policy:|'''Sample Asset Protection Policy''']], and provides specific instructions and requirements for the proper identification, authentication, and authorization controls necessary to access Company information assets.<br>
#### Password of the account
### There must be two identical copies of this document provided to the Chief Administrative Officer (CAO) and the Chief Executive Officer (CEO) for physical safe storage or password vault application.
#### The document must be placed into a sealed envelope and placed into safe storage or password vault application.
#### The sealed envelope must be destroyed when it is replaced by a newly certified document.
### Under no circumstances should the document reside electronically in any email system, file system, or storage media without the highest level of encryption applied according to the Lazarus Alliance, LLC. Encryption Standard.
## Password changes are required every one hundred and eighty (180) days for user IDs with administrative or equivalent privileges or within twenty-four (24) hours upon the termination of any employee with knowledge of the password to administrative accounts.
## Users should be notified a minimum of fifteen (15) days before a current password expires.
## Grace log-ins after a required password change must be limited to three (3) log-ins.
## Passwords must not be allowed in rapid succession, in order to prevent a user from "cycling" through passwords.
## All systems, in accordance with the Auditing Standard, must log the date and time for all failed and successful user attempts to access the system.
## All systems, in accordance with the Auditing Standard, must limit the number of failed log-on attempts to three (3) before disabling the user ID.
## Authentication credential, as user IDs and passwords, must not be written down or stored in readable form in automatic log-in scripts, software macros, terminal function keys, in computers without access control, shortcuts, or in other locations where unauthorized persons might discover them.
## All passwords must be immediately changed if known or suspected of being disclosed.
## All systems must require and authenticate a valid user ID and password or token prior to granting access to network or system resources.
## Authentication data (e.g. password files) must be protected with encryption controls to prevent unauthorized individuals from obtaining the data.
## Authentication data transmitted over a public or shared network must be encrypted in accordance with the Encryption Standard and Information Handling Standard.
# '''Authorization'''
## User access to information will be based on the confidentiality classification of the information asset.
## Users should be only authorized the level of access to information assets that is required to meet an approved business need or perform prescribed job responsibilities.
## Access to sensitive information must be provided on a need-to-know basis.
## User access rights to files, directories, and other objects should be assigned on a group basis and not assigned individually, unless doing so cannot be avoided.
## Log-in time restrictions, whenever practical, should be set to limit the time of day when users can be logged into the system or network.
## The number of concurrent log-ins allowed per user ID should be restricted to the minimum number required to perform a given job function.
## Administrative access must be limited to only those users that explicitly require such privileged access. This access shall not be granted until a properly documented request has been approved by three designated managers to include the Chief Administrative Officer (CAO).
## User with administrative responsibilities must not use a privileged account unless specifically performing actions that required an elevated privilege level.
<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>
'''Authentication''' refers to the controls for providing Users the means to verify or validate a claimed identity through the presentation of something they know (e.g., passwords), something they own (e.g., hardware token), or something they are (e.g. fingerprint, biometrics, etc.).<br>
<br>
'''Authorization''' refers to the controls for determining the resources that Users are permitted to access based upon the permissions and privileges for which they have been authorized.<br>
<br>
'''Confidentiality classifications''' are defined in the [[Sample Information Classification Standard:|'''Sample Information Classification Standard''']].<br>
<br>
'''[[Encryption | 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>
'''Identification''' refers to the controls for providing Users the means to convey their identities through the use of pre-determined identifiers.<br>
<br>
'''Information assets''' are defined in the [[Sample Asset Identification and Classification Policy:|'''Sample Asset Identification and Classification Policy''']].<br>
<br>
'''Integrity''' refers to the protection of information and systems from malicious, unauthorized, or accidental changes.<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>
=='''II. Requirements'''==
<br>
:'''A. Identification'''<br>
<br>
::1. Each User must have a unique account identifier or user ID.<br>
<br>
::2. User communities and working groups must not share a single user ID for system access to ensure accurate accounting of user access and actions.<br>
<br>
::3. User IDs should not be shared or used by anyone other than the User to whom they are assigned. Users shall be accountable for all activity associated with their assigned user IDs.<br>
<br>
::4. User IDs should be added, modified, and deleted in accordance with Company-approved account management processes.<br>
<br>
::5. User IDs must be disabled within twenty-four (24) hours of notification of a status change (for example, termination or change in job).<br>
<br>
::6. User IDs that are unused, dormant, or inactive for seventeen (17) days must be disabled.<br>
<br>
::7. User IDs that are disabled for ninety (90) days must be deleted.<br>
<br>
::8. Temporary User IDs (for testing, contractors and temporary employees) should have an account expiration date that coincides with the anticipated end of employment, testing, or contract.<br>
<br>
:'''B. Authentication'''<br>
<br>
::1. Each user ID or account must be assigned a password.<br>
<br>
::2. Passwords on new accounts must expire upon first log in and require an immediate password change.<br>
<br>
::3. All default system and application passwords must be changed prior to placing in the production environment or connecting to a live network.<br>
<br>
::4. Authentication credentials such as passwords and tokens should not be used by anyone other than the User to whom they are assigned.<br>
<br>
::5. Passwords must conform to the following criteria, with native system enforcement when possible:<br>
<br>
::*Password length must be eight (8) characters or longer. If the system does not support eight (8) characters, the password must contain the maximum number of characters allowed by the system.<br>
::*Passwords must not be equal to, or a derivative of, the user ID.<br>
::*Passwords must contain at least one (1) alphabetic and one (1) non-alphabetic character.<br>
::*Passwords must not contain more than two (2) identical consecutive characters.<br>
<br>
::6. When password criteria cannot be enforced by the native system, an automated password system or tool should be used, whenever possible, to verify and enforce the password criteria.<br>
<br>
::7. Password changes are required every forty-five (45) days.<br>
<br>
::8. Password changes are required every sixty (60) days for User IDs with administrative or equivalent privileges or within twenty-four (24) hours upon the termination of any employee with knowledge of the password to administrative accounts.<br>
<br>
::9. Users should be notified a minimum of seven (7) days before a current password expires.<br>
<br>
::10. Grace logins after a required password change must be limited to three (3).<br>
<br>
::11. Passwords must not be allowed in rapid succession in order to prevent a user from "cycling" through passwords.<br>
<br>
::12. All systems, in accordance with the [[Sample Auditing Standard:|'''Sample Auditing Standard''']], must log the date and time for all failed and successful user attempts to access the system.<br>
<br>
::13. All systems, in accordance with the [[Sample Auditing Standard:|'''Sample Auditing Standard''']], must limit the number of failed log-on attempts to three (3) before disabling the user ID.<br>
<br>
::14. Authentication credentials, as user IDs and passwords, must not be written down or stored in readable form in automatic login scripts, software macros, terminal function keys, in computers without access control, shortcuts, or in other locations where unauthorized persons might discover them.<br>
<br>
::15. All passwords must be immediately changed if known or suspected of being disclosed.<br>
<br>
::16. All systems must require and authenticate a valid user ID and password or token prior to granting access to network or system resources.<br>
<br>
::17. Authentication data (e.g. password files) must be protected with encryption controls to prevent unauthorized individuals from obtaining the data.<br>
<br>
::18. Authentication data transmitted over a public or shared network must be encrypted in accordance with the [[Sample Encryption Standard:|'''Sample Encryption Standard''']] and [[Sample Information Handling Standard:|'''Sample Information Handling Standard''']].<br>
<br>
:'''C. Authorization'''<br>
<br>
::1. User access to information will be based on the confidentiality classification of the information asset.<br>
<br>
::2. Users should be only authorized the level of access to information assets that is required to meet an approved business need or perform prescribed job responsibilities.<br>
<br>
::3. Access to sensitive information must be provided on a need-to-know basis.<br>
<br>
::4. User access rights to files, directories, and other objects should be assigned on a group basis and not assigned individually, unless doing so cannot be avoided.<br>
<br>
::5. Login time restrictions, whenever practical, should be set to limit the time of day when Users can be logged into the system or network.<br>
<br>
::6. The number of concurrent logins allowed per user ID should be restricted to the minimum number required to perform a given job function.<br>
<br>
::7. Administrative access must be limited to only those users that explicitly require such privileged access.<br>
<br>
::8. User with administrative responsibilities must not use a privileged account unless specifically performing actions that required an elevated privilege level.<br>
<br>
<br>
<gallery>
Image:Access Control Standard.png|Access Control Standard page one of eleven.
Image:Access Control Standard(1).png|Access Control Standard page two of eleven.
Image:Access Control Standard(2).png|Access Control Standard page three of eleven.
Image:Access Control Standard(3).png|Access Control Standard page four of eleven.
Image:Access Control Standard(4).png|Access Control Standard page five of eleven.
Image:Access Control Standard(5).png|Access Control Standard page six of eleven.
Image:Access Control Standard(6).png|Access Control Standard page seven of eleven.
Image:Access Control Standard(7).png|Access Control Standard page eight of eleven.
Image:Access Control Standard(8).png|Access Control Standard page nine of eleven.
Image:Access Control Standard(9).png|Access Control Standard page ten of eleven.
Image:Access Control Standard(10).png|Access Control Standard page eleven of eleven.
</gallery>


=='''III. Responsibilities'''==
<br>
The Chief Information Security Officer (CISO) approves the Access Control Standard. The CISO also is responsible for ensuring the development, implementation, and maintenance of the Access Control Standard.<br>
<br>
Company management, including senior management and department managers, is accountable for ensuring that the Access Control 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 Access Control 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 processes and procedures that are consistent with the Access Control Standard; defining the access control requirements for information assets associated with their functional authority; processing requests associated with Company-approved access request procedure; determining the level of access and authorizing access based on Company-approved criteria; ensuring the revocation of access for those who no longer have a business need to access information assets; and ensuring the access controls and privileges are reviewed at least annually.<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; administering access to information assets as authorized by the Owner; and implementing procedural safeguards and cost-effective controls that are consistent with the Access Control Standard.<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 Access Control Standard and associated guidelines; following Company-approved processes and procedures to request and obtain access to information assets; ensuring authorization credential such as password and tokens are not written down or stored in a place where unauthorized persons might discover them; reporting immediately to <INSERT CONTACT> when authorization credentials have been or may have been compromised; and maintaining the confidentiality, integrity and availability of information accessed consistent with the Owner's approved safeguards while under the User's control.<br>
<br>
=='''IV. Enforcement and Exception Handling'''==
<br>
Failure to comply with the Access Control 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 Access Control 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'''==
[[file:Access Control Standard.png]]
<br>
[[file:Access Control Standard(1).png]]
The Access Control Standard will be reviewed and revised in accordance with the [[Sample Information Security Program Charter:|'''Sample Information Security Program Charter''']].<br>
[[file:Access Control Standard(2).png]]
<br>
[[file:Access Control Standard(3).png]]
<br>
[[file:Access Control Standard(4).png]]
Recommended:       _______________________________________________________<br>
[[file:Access Control Standard(5).png]]
<br>
[[file:Access Control Standard(6).png]]
::Signature
[[file:Access Control Standard(7).png]]
::<Typed Name>
[[file:Access Control Standard(8).png]]
::Chief Information Security Officer
[[file:Access Control Standard(9).png]]
<br>
[[file:Access Control Standard(10).png]]
Approved:       _______________________________________________________<br>
<br>
::Signature
::<Typed Name>
::Chief Information Officer

Revision as of 17:50, 15 January 2014

Sample Access Control Standard

This Access Control Standard builds on the objectives established in the Sample Asset Protection Standard, and provides specific instructions and requirements for the proper identification, authentication, and authorization controls necessary to access Company information assets.

Objectives

  1. Identification
    1. Each User must have a unique account identifier or user ID.
    2. User communities and working groups must not share a single user ID for system access to ensure accurate accounting of user access and actions.
    3. User IDs should not be shared or used by anyone other than the User to whom they are assigned. Users shall be accountable for all activity associated with their assigned user IDs.
    4. User IDs should be added, modified, and deleted in accordance with Company-approved account management processes.
    5. User IDs must be disabled within twenty-four (24) hours of notification of a status change (for example, resignation or change in job).
      1. User IDs must be disabled as soon as possible (Immediately) when user has been terminated under adversarial conditions to prevent retaliatory risks to company assets, resources, reputation, and employees. Any requests must come from MediaWiki system to satisfy historical tracking, compliance requirements and audit requirements.
    6. User IDs that are unused, dormant, or inactive for 15 days must be disabled.
    7. User IDs that are disabled for 90 days must be deleted.
    8. Temporary User IDs (for testing, contractors and temporary employees) should have an account expiration date that coincides with the anticipated end of employment, testing, or contract.
  2. Authentication
    1. Each user ID or account must be assigned a password.
    2. Passwords on new accounts must expire upon first log-in and require an immediate password change.
    3. All default system and application passwords must be changed prior to placing in the production environment or connecting to a live network.
    4. Authentication credentials such as passwords and tokens should not be used by anyone other than the User to whom they are assigned.
    5. Passwords must conform to the following criteria, with native system enforcement when possible:
      1. Password length must be eight (8) characters or longer. If the system does not support eight (8) characters, the password must contain the maximum number of characters allowed by the system.
      2. Passwords must not be equal to, or a derivative of, the user ID.
      3. Passwords must contain at least one (1) alphabetic and one (1) non-alphabetic character.
    6. When password criteria cannot be enforced by the native system, an automated password system or tool should be used, whenever possible, to verify and enforce the password criteria.
    7. Password changes are required every ninety (90) days.
    8. Password changes are required every three hundred and sixty-five (365) days for service and system IDs accounts, or within twenty-four (24) hours upon the termination of any employee with knowledge of the password to service and system IDs accounts.
      1. The account name and password must be transcribed onto a physical document containing the following information:
        1. Custodians name and position
        2. Date of creation
        3. Date of recertification
        4. Asset account belongs to
        5. Password of the account
      2. There must be two identical copies of this document provided to the Chief Administrative Officer (CAO) and the Chief Executive Officer (CEO) for physical safe storage or password vault application.
        1. The document must be placed into a sealed envelope and placed into safe storage or password vault application.
        2. The sealed envelope must be destroyed when it is replaced by a newly certified document.
      3. Under no circumstances should the document reside electronically in any email system, file system, or storage media without the highest level of encryption applied according to the Lazarus Alliance, LLC. Encryption Standard.
    9. Password changes are required every one hundred and eighty (180) days for user IDs with administrative or equivalent privileges or within twenty-four (24) hours upon the termination of any employee with knowledge of the password to administrative accounts.
    10. Users should be notified a minimum of fifteen (15) days before a current password expires.
    11. Grace log-ins after a required password change must be limited to three (3) log-ins.
    12. Passwords must not be allowed in rapid succession, in order to prevent a user from "cycling" through passwords.
    13. All systems, in accordance with the Auditing Standard, must log the date and time for all failed and successful user attempts to access the system.
    14. All systems, in accordance with the Auditing Standard, must limit the number of failed log-on attempts to three (3) before disabling the user ID.
    15. Authentication credential, as user IDs and passwords, must not be written down or stored in readable form in automatic log-in scripts, software macros, terminal function keys, in computers without access control, shortcuts, or in other locations where unauthorized persons might discover them.
    16. All passwords must be immediately changed if known or suspected of being disclosed.
    17. All systems must require and authenticate a valid user ID and password or token prior to granting access to network or system resources.
    18. Authentication data (e.g. password files) must be protected with encryption controls to prevent unauthorized individuals from obtaining the data.
    19. Authentication data transmitted over a public or shared network must be encrypted in accordance with the Encryption Standard and Information Handling Standard.
  3. Authorization
    1. User access to information will be based on the confidentiality classification of the information asset.
    2. Users should be only authorized the level of access to information assets that is required to meet an approved business need or perform prescribed job responsibilities.
    3. Access to sensitive information must be provided on a need-to-know basis.
    4. User access rights to files, directories, and other objects should be assigned on a group basis and not assigned individually, unless doing so cannot be avoided.
    5. Log-in time restrictions, whenever practical, should be set to limit the time of day when users can be logged into the system or network.
    6. The number of concurrent log-ins allowed per user ID should be restricted to the minimum number required to perform a given job function.
    7. Administrative access must be limited to only those users that explicitly require such privileged access. This access shall not be granted until a properly documented request has been approved by three designated managers to include the Chief Administrative Officer (CAO).
    8. User with administrative responsibilities must not use a privileged account unless specifically performing actions that required an elevated privilege level.


Document Examples

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