| Policy ID No. | Policy | Policy Text | Policy Commentary |
|---|---|---|---|
| 50.0 | Software Testing With Sanitized Rather than Production Information | Unless written permission is first obtained from the Agency Computer Security Officer, all software testing for systems designed to handle private information must be accomplished exclusively with "sanitized" production information. Sanitized information is production information which no longer contains specific details that might be valuable, critical, sensitive, or private. | The "sanitization" process obscures certain information without significantly modifying the characteristics relevant to testing. For example, the actual first and last names of individuals in a human resources database might be mixed up such that they no longer reflect any specific persons. In this manner the actual field lengths required, the number of records in the database, and other statistics remain the same for testing purposes. The intention of the policy is to prevent unauthorized disclosure of testing information to persons such as in-house programmers and contractors. This policy is appropriate for third party packages as well as software developed in-house. The policy is particularly relevant to those environments in which end-users are doing their own programming (client-server computing, local area networks, PCs, and the like) because these new programmers may not be familiar with traditional systems development approaches. Most organizations will want to specify how to sanitize data. Also see the policies entitled "Access to Production Business Information for System Testing." |
| 52.0 | Removal of All Unauthorized Access Paths in Production Software | Prior to moving software which has been developed in-house to production status, programmers and other technical staff must remove all special access paths so that access may only be obtained via normal secured channels. This means that all trap doors and other short-cuts that could be used to compromise security must be removed. Likewise, all system privileges needed for development efforts but not required for normal production activities must be removed. | The intention of this policy is to put programmers and other system developers on notice that they must eliminate all pathways which could be used to compromise security. An example justifying this policy involved the log-in program for what used to be called ARPANET (now Internet); the developers had a special password which allowed them to gain privileged access to any log-in program without having first been granted access by the system's management. This is exactly the type of access pathway that should be eliminated prior to placing systems in production status. Although programmers may only want to save themselves time at some point in the future, by leaving such unauthorized pathways in production systems, they also create pathways that can be exploited by unauthorized parties. The policy also implicitly requires all special access paths to be disclosed in documentation. This policy is particularly relevant to those environments in which end-users are doing their own programming (client-server computing, local area networks, PCs, and the like) because these new programmers may not be familiar with traditional systems development approaches. Also see the policy entitled "Prohibition Against Trap Doors To Circumvent Access Controls." |
| 57.0 | Prohibition Against Trap Doors To Circumvent Access Controls | Programmers and other technically-oriented staff must refrain from installing trap doors that circumvent the authorized access control mechanisms found in operating systems and/or access control packages. | Trap doors are special code segments which secretly allow a systems programmer, technical support staff member, or someone else to get around standard access controls (like passwords and user-IDs). These hidden pieces of code are invoked with special undocumented commands known only to the person who wrote them. Ironically, most trap doors are installed with good intentions such as being able to install system maintenance code without performing a system re-start, being able to issue console operator commands from terminals, or being able to bypass the access control system should the system freeze-up (crash). The intention of this policy is to force all accesses via standard access control mechanisms, thus achieving uniformity, auditability, and a more secure operating environment. If trap doors exist, they could be used by unauthorized parties to wreak havoc on the system. Likewise, if the person who installed a trap door leaves the organization under less than friendly terms, the former employee can do serious damage via the trap door. See the policy entitled "Removal of All Unauthorized Access Paths in Production Software." |
| 58.0 | Install Latest Patches On Systems Located On Network Periphery | All State of Alaska networked production systems must have an adequately staffed process for expediently and regularly reviewing all newly released systems software patches, bug fixes, and upgrades. This process must also include procedures to promptly install these patches, bug fixes, and upgrades as necessary to all machines interfacing the Internet and other public networks. | The objective of this policy is to ensure that systems administrators and others are promptly updating systems software on those systems that interface with public networks like the Internet. If systems software is not promptly updated, then intruders will be able to run vulnerability identification software to identity systems susceptible to publicized exploits. This means that terrorists, hackers, virus writers and others are now using computers to identify those systems that could be breached. If network-connected systems don't have the latest software that incorporates security bug fixes, patches, and upgrades, in a matter of only a few days these systems will be identified and soon thereafter penetrated. In the years ahead, system-updating process will be increasingly performed without human intervention with the aid of automated software distribution systems. In the meanwhile, it is often a tedious but nonetheless vitally important process. |