A.15 ABC Inc. InfoSec Application Password Policy


A.15 ABC Inc. InfoSec Application Password Policy

Policy No. 14

Effective date Month / Day / Year

Implement by Month / Day / Year

1.0 Purpose

This policy states the requirements for securely storing and retrieving application usernames and passwords (i.e., application credentials) for use by a program that will access an application running on one of ABC Inc.'s networks.

Computer programs running on ABC Inc.'s networks often require the use of one of the many internal application servers. In order to access one of these applications, a program must authenticate to the application by presenting acceptable credentials. The application privileges that the credentials are meant to restrict can be compromised when the credentials are improperly stored.

2.0 Scope

This policy applies to all software that will access an ABC Inc., multi- user production application.

3.0 Policy

3.1 General

In order to maintain the security of ABC Inc.'s internal applications, access by software programs must be granted only after authentication with credentials. The credentials used for this authentication must not reside in the main, executing body of the program's source code in cleartext. Application credentials must not be stored in a location that can be accessed through a web server.

3.2 Specific Requirements
3.2.1. Storage of Database User Names and Passwords
  • Application user names and passwords may be stored in a file separate from the executing body of the program's code. This file must not be world readable.

  • Application credentials may reside on the application server. In this case, a hash number identifying the credentials may be stored in the executing body of the program's code.

  • Application credentials may be stored as part of an authentication server (i.e., an entitlement directory), such as an LDAP server used for user authentication. Application authentication may occur on behalf of a program as part of the user authentication process at the authentication server. In this case, there is no need for programmatic use of application credentials.

  • Application credentials may not reside in the documents tree of a web server.

  • Pass through authentication (i.e., Oracle OPS$ authentication) must not allow access to the application based solely upon a remote user's authentication on the remote host.

  • Passwords or passphrases used to access an application must adhere to the Password Policy.

3.2.2. Retrieval of Application User Names and Passwords

If stored in a file that is not source code, then application user names and passwords must be read from the file immediately prior to use. Immediately following application authentication, the memory containing the user name and password must be released or cleared.

The scope into which you may store application credentials must be physically separated from the other areas of your code, e.g., the credentials must be in a separate source file. The file that contains the credentials must contain no other code but the credentials (i.e., the user name and password) and any functions, routines, or methods that will be used to access the credentials.

For languages that execute from source code, the credentials' source file must not reside in the same browseable or executable file directory tree in which the executing body of code resides.

3.2.3. Access to Application User Names and Passwords

Every program or every collection of programs implementing a single business function must have unique application credentials.

Application passwords used by programs are system-level passwords as defined by the Password Policy. Developer groups must have a process in place to ensure that application passwords are controlled and changed in accordance with the InfoSec Password Policy. This process must include a method for restricting knowledge of application passwords to a need-to-know basis.

4.0 Enforcement

Any employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

5.0 Definitions

Application: Any program, or database which provides access to information (e.g. SAP, Siebel, Oracle, SQL Server . . .).

Computer language: A language used to generate programs.

Credentials: Something you know (e.g., a password or pass phrase) and/or something that identifies you (e.g., a user name, a fingerprint , voiceprint, retina print) are presented for authentication.

Entitlement: The level of privilege that has been authenticated and authorized. The privileges level at which to access resources.

Executing body: The series of computer instructions that the computer executes to run a program.

Hash: An algorithmically generated number that identifies a datum or its location.

LDAP: Lightweight Directory Access Protocol, a set of protocols for accessing information directories.

Module: A collection of computer language instructions grouped together either logically or physically. A module may also be called a package or a class, depending upon which computer language is used.

Name space: A logical area of code in which the declared symbolic names are known and outside of which these names are not visible.

Production: Software that is being used for a purpose other than when software is being implemented or tested .

6.0 Exceptions

Exceptions to information system security policies exist in rare instances where a risk assessment examining the implications of being out of compliance has been performed, where a Policy Exception Form has been prepared by the data owner or management, and where this form has been approved by both the CSO or Director of InfoSec and the Chief Information Officer (CIO).

7.0 Revision History

Date ___/____/_____

Version:_______________________

Author:____________________________________

Summary:__________________________________




Wireless Operational Security
Wireless Operational Security
ISBN: 1555583172
EAN: 2147483647
Year: 2004
Pages: 153

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net