Texas Administrative Code 201.13(b) requires that each agency identify, classify and protect the automated files, data bases and applications for which it has ownership responsibility. Classifying information and the applications that function to process it is at the heart of identifying and selecting appropriate security and risk management practices. Each agency's security objectives must include maintaining information integrity and confidentiality and assuring the availability of critical information technology support services.
STANDARD. All information and telecommunication resources leased or owned by the state and all time-sharing services billed to the state shall be used only to conduct state business except as otherwise provided by state law.
STANDARD. All computer software programs, applications, source code, object code, and documentation shall be deemed to be a work made for hire and is state property and shall be protected as such if developed either:
1. by state employees in the course and scope of their employment or with the use of state equipment, materials, or other resources, with the exception of employees of universities and other institutions of higher education, provided such university or institution has an intellectual property policy in place which addresses ownership rights regarding software development; or
2. by contract personnel acting under a contract with the state, unless the contract under which the software or documentation is developed specifically provides otherwise; or
3. with state funds.
STANDARD. All computer software programs, applications, and documentation purchased for the use of the state is state property and shall be protected as such.
It is an infringement of state law and policy to copy proprietary software inviolation of a licensing agreement.
GUIDELINES.
1. Agency employment agreements with employees who write or modify state- owned software should specify ownership rights in the software, with the state retaining ownership in all programs written or modified by its employees.
2. Contracts for programming work by outside personnel should spell out the ownership of all rights to the software and associated documentation.
3. Agencies should develop policies which explicitly prohibit copying proprietary software and define the disciplinary actions that will be taken in the event an employee violates the policy.
There are three general goals for information security: confidentiality, integrity, and availability.
Confidentiality means the system does not allow information to be disclosed to anyone who is not authorized to access it. Integrity means the system must not corrupt the information or allow any unauthorized malicious or accidental changes to it. Availability means the computer system keeps working efficiently and is able to recover quickly if a disaster occurs.
Confidential information requires special precautions to protect it from unauthorized or accidental access, disclosure, or dissemination. Automated information systems which process confidential information require adequate controls to safeguard against violating individual rights to privacy or endangering the public's health, welfare, or safety.
STANDARD. Confidential information shall be accessible only to personnel who are authorized by the owner on a strict "need to know" basis in the performance of their duties. Data containing any confidential information shall be readily identifiable and treated as such in its entirety.
STANDARD. When confidential or sensitive information from one agency is received by another agency in connection with the transaction of official business, the receiving agency shall maintain the confidentiality or sensitivity of the information in accordance with the conditions imposed by the providing agency.
GUIDELINES.
1. The principles of least access, separation of functions, and need to know should guide the determination of user authorizations, rather than rank, position or precedent. Group level authorizations should be avoided.
2. Sensitive data, files, and software should be marked or flagged as "Sensitive," "Confidential," or other designation which clearly distinguishes them from non-sensitive material. Data or files containing sensitive information need not be considered sensitive if the information is encrypted (see section 6.11) with encryption keys properly controlled.
3. Sensitive data in magnetic or electronic form should contain the markings in a manner appropriate to the media such that special protection requirements will be apparent to anyone accessing the data.
4. Sensitive hardcopy data should have markings on each page. Physical markings should also be applied to the exterior of all input/output media such as diskettes, tapes, and volumes which contain sensitive information.
5. Magnetic media and hard copy data which has contained sensitive information should not be disposed of or removed from state security controls without assurance that sensitive information has been deleted and cannot be recovered. Processes to delete information from magnetic media include complete degaussing, electronic overwriting, and physical destruction. Media which has been subjected to a deletion process should be tested periodically as a separate function in order to validate continued effectiveness of the process.
6. Agencies may elect to establish more than one level or category of sensitivity, considering the vulnerabilities associated with the number of employees who would otherwise have access to more sensitive information than required by their duties. In such event, the different sets of sensitive information must be distinguishable and the controls for each must be defined.
7. Procedures for removal of sensitive information from records should be devised such that the desensitized version may be available to the public in accordance with the law. Any collection of automated information or data which the owner has determined to contain no sensitive information is, by definition, public information.
8. While controls which limit access to sensitive information must normally be more restrictive than controls for the protection of non-sensitive information, the exposure associated with broad access to non-sensitive information should also be recognized.
In terms of volume, errors and omissions are the greatest causes of incorrect information processing.
STANDARD. Controls shall be established to ensure the accuracy and completeness of data. User management shall ensure that data comes from the appropriate source for the intended use.
GUIDELINES.
1. Redundant data, parity checks, control totals, etc. should be used to guard against errors in entry and transmission.
2. Selected fields should be verified. Programmed edit checks, feedback, confirmations, and reconciliations should be employed as indicated.
3. Time stamps and sequence numbers should be employed to ensure completeness of data and to relate data across files and transactions.
4. Once it has been processed, each collection of source material should be canceled or specially marked, either manually or under control of validated software, to prevent duplications or omissions.
5. User management should reconcile data submitted against data processed and returned.
6. The user organizational unit should maintain a log of the batches submitted for processing. The data input organizational unit should generate a log, by user organizational unit, of the batches received and processed.
7. The integrity of information against undetected corruption during transmission or while in storage may be enhanced by encryption. Although encryption alone may not prevent modification or destruction, any unauthorized alteration of encrypted information should be readily detected since decryption will produce unintelligible garbles.
8. Computer generated output should be periodically examined to ensure that it is accurate and complete.
State policy requires that each agency prepare a Contingency Plan that includes the procedures necessary to assure the continuation of vital agency operations in the event of a disaster. Each agency must identify and prioritize its critical applications. In the event of a disaster the agency must attempt to maintain the availability and continued operation of critical systems on a priority basis.
Each agency's Contingency Plan must outline the internal policies and procedures that are to be employed should a disaster occur. If the agency employs the services of a data center, it should coordinate the preparation of its Contingency Plan with that facility. The plan should be designed to assure the continued availability of critical applications. In the event of a disaster, critical applications should be maintained on a priority basis. The maintenance and operation of other systems is secondary to that of critical applications.
Critical applications include those systems whose loss or unavailability is unacceptable to the agency. The loss or unavailability of support services provided by these applications may adversely affect the public's health, safety, or welfare; the continuation of vital programs and services; or the fiscal or legal integrity of state operations.
Critical applications should be classified and prioritized in the following order:
1. Public Safety Applications. A disruption in processing of the application would pose an immediate threat to the public's health or safety.
2. Public Service Applications. A disruption in processing the application would adversely impact the state's ability to provide services to those who are recipients of state benefits or entitlement.
3. Financial Applications. A disruption in processing the application would seriously impair the state's ability to collect and disburse revenues including state and pension fund payroll and welfare and employment benefits or entitlement.
4. Legal Applications. A disruption in processing the application would result in a breach of state legal obligations through noncompliance with statutory or regulatory requirements, which could result in financial and other losses associated with penalties, interest, and litigation.
There are three types of mechanisms used to reach the information security goals of confidentiality, integrity, and availability.
Accountability mechanisms help trace violations or attempted violations of system security to the individuals who are responsible. Passwords and audit trails are accountability mechanisms.
Encryption is the transformation of usable information into unintelligible data using a key, or known formula. Unless the key is known to the reader, the confidentiality of the information is maintained.
Access controls limit the use of a system or an object (e.g. a file) on the system to authorized subjects (e.g. users).
Properly implemented and managed, passwords will improve the likelihood that users are who they purport to be and that a users access can be controlled effectively. Passwords are an important deterrent to intrusion.
STANDARD. Except for public users of systems where such access is authorized, or for situations where risk analysis demonstrates no need for individual accountability of users, each user of a multiple-user automated system shall be assigned a unique personal identifier or user identification. User identification shall be authenticated before the system may grant that user access to automated information.
STANDARD. A user's access authorization shall be removed from the system when the user's employment is terminated or the user transfers to a position where access to the system is no longer required.
GUIDELINES.
1. Users access rights should be established on the basis of validated identification. The user identification code should be traceable to the user for the lifetime of the records and reports in which they appear.
2. The user should be required to provide unique authentication (e.g., a password) with something that is known or possessed only by that user.
3. Each user should agree in writing to only use the identification code for the purpose for which it was intended, to not disclose a password to any other person, and to change the password promptly if he or she suspects it has been disclosed to anyone else. A copy of the agreement should be retained in the user's personnel file.
4. An automatic terminal time-out should occur after a certain period of inactivity. The user should be forced to re-submit authentication before resuming activity.
5. Users should be trained to log-off or secure terminals when not in use.
6. Inadequate physical controls for remote system components may be compensated for by strengthened logical access controls.
7. Consultants and contractors should have their access rights carefully controlled. Automatic expiration of access authorization is one effective technique.
8. Authentication need not be required for a personal computing system if all users of the system have authorization to all of the information on the system and the computer and files are physically secured when not in use.
9. In situations where an employee's system access is terminated under adverse conditions (such as forced termination of employment or forced reassignment), it is particularly important that the employee be denied any further opportunity for unsupervised access to the system once he or she is so notified.
10. Systems authorized for public use need not require individual user identification as long as the class identification as public is retained and public access functions are prescribed and controlled.
Personal passwords are used to authenticate a user's identity and to establish accountability. Access passwords are used to grant access to data and may be used where individual accountability is not required. Federal Information Processing Standard Publication 112 (FIPS PUB 112) specifies basic security criteria in the use of passwords to authenticate personal identity and data access authorization.
STANDARD. Systems which use passwords shall conform to the federal standard on password usage contained in the Federal Information Processing Standard Publication 112 (FIPS PUB 112), which specifies minimum criteria and provides guidance for selecting additional password security criteria when appropriate. A current password standard compliance document shall be maintained for each system which uses passwords, specifying the criteria to be met for the ten factors which address design, implementation, and use of access control systems as contained in the FIPS PUB 112 standard.
GUIDELINES.
1. The adequacy of a password system should be established through risk analysis.
2. Appendices to FIPS PUB 112 provide guidance on meeting the minimum criteria, reasons for exceeding them, and provide examples of password compliance documents.
3. Passwords stored on a computer should be encrypted.
4. System operators should not have unlimited access to "super-passwords." Such passwords should be carefully controlled by user management. Monitoring the use of privileged passwords is critical.
5. Consideration should be given to use of one-time passwords when there is a high threat of password compromise or for very sensitive applications. The most convenient way to implement one-time passwords may be through the use of "smart cards."
All transactions should be auditable or traceable to their origin or source.
STANDARD. Audit trails shall be maintained to provide accountability for all accesses to confidential or sensitive information and software and for all changes to automated security or access rules. An auditable, continuous chain of custody shall record the transfer of confidential or sensitive information.
Automated chronological or systematic records of changes to data are important in the reconstruction of previous versions of the data in the event of corruption. Such records, sometimes referred to as journals, are useful in establishing normal activity, in identifying unusual activity, and in the assignment of responsibility for corrupted data.
STANDARD. A sufficiently complete history of transactions shall be maintained for each session involving access to confidential or sensitive information to permit an audit of the system by tracing the activities of individuals through the system.
GUIDELINES.
1. In addition to system start-up and shut-down times, transaction histories should log the following information, at a minimum:
2. Agencies should prescribe the analysis required of transaction histories and the person or function designated to perform the analysis. Only designated personnel should have access to the transaction histories and to the results of the analyses.
3. An analysis of transaction histories for the purpose of detecting variances from the norm should be conducted regularly. In addition to checks against authorizations, particular attention should be paid to unusual times, frequency, and length of accesses, as well as anomalies which could indicate potential violations.
The establishment and maintenance of a system of internal control is an important management function. Internal audits of information resource management functions, including security of data and information technology resources, are an integral part of an overall security program. The frequency, scope, and assignment of internal audits for security of data and information technology resources should be established to ensure that agency management has timely and accurate information concerning functions management is responsible to perform.
STANDARD. Automated systems which process confidential or sensitive information must provide the means whereby authorized personnel have the ability to audit and establish individual accountability for any action that can potentially cause access to, generation of, or effect the release of the information.
GUIDELINES.
1. At a minimum, the internal audit should evaluate the following attributes of the agency's internal information security program: its effectiveness, its compliance with the state policies and standards, and the degree to which it is implemented.
2. The scope of the annual internal audit should be agency wide.
3. Internal auditors should participate in evaluating the effectiveness of security controls and in assuring their auditability and in systems development and acquisition processes.
Encryption should be considered if the information in question warrants a high level of security and is to be electronically transmitted, stored, or removed from a secure area.
Encryption is the process of character substitution or transposition in a sequence determined by an encryption formula. Most encryption uses the Data Encryption Standard (DES) formula, which has been endorsed by the National Institute of Standards and Technology. Readable text is converted to unreadable text based on a security key provided by the owner of the information. Anyone examining an encrypted file would see a string of unrelated characters or symbols. The encryption process can be reversed only by someone who has the security key.
Authority to read, write, modify, update, or delete information from automated files or data bases should be established by the designated owners of the information. Individuals may be granted a specific combination of authorities. For example, an individual may be allowed to "read only" or to "read and write but not delete" data. Authority to read, write, modify, update, or delete data may be identified at the data element level. Specific access authority should be established at the time an individual is assigned a password.
STANDARD. Controls shall ensure that legitimate users of the computer cannot access stored software or data unless they have been authorized to do so.
GUIDELINES.
1. If software is inadequate to control access to segregated parts of information within the computer, access to the entire computer system should be restricted to those with permission to access all the information.
2. Violations of access controls should be reviewed by both the owner and the user's manager.
3. If access control software is incapable of preventing programmed attacks on the information, all program compilers or assemblers and all general-purpose utilities capable of reading or updating files should be partitioned or removed from the system.
Each agency should establish appropriate internal policies and procedures to protect all classes of information. Such policies and procedures should take into consideration applicable federal and state law. Once the agency's internal security policies and procedures have been established, they must be enforced. Only then will employees recognize that information security is significant and that it is a management priority. Employees who fail to observe security requirements should be subject to disciplinary measures.
Information access authority for each employee should be reviewed on a regular basis, as well as each time a transfer, promotion, or termination from service occurs. Access authority to information should be changed or terminated as appropriate.
Management should monitor the use of information. Questionable usage of files, data bases, or communication networks should be investigated. Seemingly innocuous occurrences, such as a minor string of unsuccessful login attempts or increased system usage, can indicate unauthorized or illegal activity.
Any event which results in loss, disclosure, unauthorized modification, or unauthorized destruction of information resources constitutes a security incident or breach. The analysis of trends and types of security breaches is important to the integrity of the agency's security program. Security incident investigation provides a basis for a continuing evaluation of the agency information security posture. The objective of such analysis is to refine agency security policies, standards, and guidelines to assure their continued effectiveness and applicability.
STANDARD. Security breaches shall be promptly investigated. If criminal action is suspected, the agency must contact the appropriate local law enforcement and investigative authorities immediately. Laws governing the admissibility of evidence are very strict and without professional advice the agency may be jeopardizing possible legal actions.
STANDARD. The test functions shall be kept either physically or logically separate from production functions. Copies of production data shall not be used for testing unless the data has been declassified or unless all personnel involved in testing are otherwise authorized access to the data.
STANDARD. Appropriate information security and audit controls shall be incorporated into new systems. Each phase of systems acquisition shall incorporate corresponding development or assurances of security and auditability controls.
GUIDELINES. The following security (including audit) activities should be addressed at the appropriate phase in acquiring new information processing systems:
1. Determine sensitivity and criticality of the system information and define security objectives, i.e., assess the threats, vulnerabilities, and risks to the system.
2. Identify security alternatives and basic security framework in the selected system architecture.
3. Define security requirements and select appropriate controls.
4. Develop security test plans.
5. Design contracts to include security requirements.
6. Include approved security requirements and specifications in the development baselines.
7. Conduct tests of security in the configured components and in the integrated system.
8. Prepare documentation of security controls and assign to the documentation the appropriate level of sensitivity.
9. Conduct acceptance test and evaluation of system security.
STANDARD. After a new system has been placed in operation, all program changes shall be approved before implementation to determine whether they have been authorized, tested, and documented.
GUIDELINES.
1. System testing should be a joint effort of users and information processing organizations and should include both the manual and automated phases of the system.
2. A naming standard should be in effect to distinguish between test jobs and production jobs, test data sets and production data sets.
3. Change control procedures should ensure that all moves between the test and production environments have been authorized in writing by the appropriate manager.
4. Parallel or acceptance tests should be considered production work and therefore run by production personnel.
5. Program development personnel should access production data and production program files only to resolve emergencies. Only those authorized by the supervisor of production operations should authorize and log this access.
6. All programs should be installed into production from the source code (i.e., programs will be recompiled by a change control or comparable group).
7. Software generally referred to as "public domain" software (such as might be acquired through software exchanges or electronic bulletin boards) or software not acquired under license or contract should never be used for processing confidential or sensitive information.
8. For non-sensitive or non-critical applications, public domain software should not be used unless it has been thoroughly tested in a non-operational, isolated environment and validated to be free of contaminants or malicious code such as so-called software "viruses" or "trojan horses".
9. Requested program changes should be documented and signed by both the initiator of the request and the system owner. Changes should also be approved by the programming manager.
10. Independent peer review (whereby programmers examine each other's program code) will reduce program maintenance exposure.
11. Acceptance testing of modified programs should be performed by a quality assurance (or independent) function using control test files.
12. Only quality assurance (or independent) personnel should be authorized to apply program changes, catalog and copy newly updated programs to production libraries.
13. Automated logs should be used to monitor all access to password tables and production programs.