| Policy ID No. | Policy | Policy Text | Policy Commentary |
|---|---|---|---|
| 18.0 | Leaving Sensitive Systems Without Logging-Off | If the computer system to which they are connected are medium or high risk systems, users must not leave their computer unattended for more than half an hour without first logging-out or otherwise locking the computer from unauthorized use. | This policy seeks to prevent unauthorized disclosure of information as well as unauthorized use. Instead of mandating a period of no activity beyond which jobs will be automatically terminated, this policy puts the onus of responsibility on the user. The Agency Computer Security Officer may set the unattended time window to a lower value. Screen savers that require passwords or similar mechanisms are acceptable. |
| 19.0 | Granting User-IDs to Outsiders | Individuals who are not employees, contractors, or consultants must not be granted a user-ID or otherwise be given privileges to use State of Alaska computers or communications systems without the approval of the Agency Computer Security Officer has first been obtained. | The intention behind this policy is to make sure that unauthorized outsiders are not using State of Alaska resources without specific management knowledge and permission. This policy is also intended to make sure that outsiders like customers and utility service providers (e.g., telephone company employees) are kept off State of Alaska systems unless specific management permission is obtained. Also see the policies entitled "User-ID and Password Required for Access to State of Alaska Network Systems," and "Unique User-ID and Password Required" |
| 20.0 | Information Systems Access Privileges Terminate When Workers Leave | All State of Alaska information systems privileges must be promptly terminated at the time that a worker is no longer employed by the State of Alaska. | The intention of this policy is to instruct systems administrators, network managers, and others in similar positions that they must promptly revoke the privileges of workers who are no longer employed by the State of Alaska. Often these matters are ignored in favor of more pressing things. Whatever the reason, if privileges are not promptly terminated, ex-employees, former contractors, and others are thereby able to commit undesirable acts. This policy encourages the development of an in-house system to communicate changes in worker employment status to the systems administrators and others who must alter system privileges. For a related idea, see the policy entitled "Reporting Changes in User Duties to Systems Security Administration." |
| 21.0 | Gaining Unauthorized Access Via State Information Systems | Workers using State of Alaska information systems are prohibited from gaining unauthorized access to any other information systems or in any way damaging, altering, or disrupting the operations of these systems. Likewise, workers are prohibited from capturing or otherwise obtaining passwords, encryption keys, or any other access control mechanism which could permit unauthorized access. | The intention of this policy is to clearly establish management's position forbidding hacking (also called cracking) activities via State of Alaska information systems. The policy is written in such a way that it applies to both internal and also external information systems. The policy embraces a wide variety of hacker techniques, including social engineering (where a hacker masquerades as someone else), and password grabbers (which record passwords via wiretap like mechanisms). The words "access control mechanism" include smart cards, dynamic password tokens, and the like. Separately, this policy can be used to discipline, and perhaps terminate, a worker who was hacking via State of Alaska information systems. For related ideas, see the policies entitled "Prohibition Against Testing Information System Controls" and "Tools Used to Break Systems Security Prohibited." |
| 22.0 | Where to Use Computer System Access Controls | All computer-resident information in the high or medium risk categories must have system access controls to ensure that it is not improperly disclosed, modified, deleted, or rendered unavailable. | The intention of this policy is to ensure that State of Alaska information will be properly protected. This policy mandates the use of access controls to protect sensitive, critical or valuable information. It is also a good idea to define "system access controls" (perhaps secret passwords and user-IDs, perhaps smart cards, etc.). This policy is also relevant to client/server systems, mobile computing systems, personal computing systems, PDAs, wireless, and the like. Very small remote systems, such as alphanumeric pagers, may not be able to support the desired access control, in which case the organization in question must decide whether it will accept the risk, or prohibit the handling of such information on these systems. See the introduction defining high, medium and low risk systems. |
| 23.0 | Privilege Restriction Based on legitimate business need | The computer and communications system privileges of all users, systems, and programs must be restricted based on a legitmate business need. | The intention of this policy is to prevent the granting of excessive privileges to users. Excessive privileges often allow users to perform abusive and unauthorized acts, such as viewing private information belonging to other users. Excessive privileges may also allow users to commit errors which have serious consequences, such as bringing a communications server down during business hours. Borrowed from the military, the need-to-know approach is a fundamental idea underlying nearly all commercial access control systems. |
| 24.0 | Existence of User Access Capabilities Does Not Imply Usage Permission | Users must not read, modify, delete, or copy a file belonging to another user without first obtaining permission from the owner of the file. Unless general user access is clearly provided, the ability to read, modify, delete, or copy a file belonging to another user does not imply permission to actually perform these activities. | The intention of this policy is to define appropriate boundaries around the files maintained by computer users, who often have no file access controls whatsoever. The policy essentially says "Just because you can do it, doesn't mean that you are allowed to do it." The policy makes reference to information owners, which ideally would make decisions about access to certain types of information. Nonetheless, in many situations the owner is by default the user on whose PC the information resides. For a related idea, see the policy entitled "Default to Denial of Access Control Privileges." |
| 25.0 | User-IDs Must Each Uniquely Identify a Single User | Each computer and communication system user-ID must uniquely identify only one user. Shared or group user-IDs are not permitted. | This policy establishes a definitive link between a user-ID and an individual (and in some cases a software process or a computer system). The converse is not necessary, i.e., individual users may have multiple user-IDs. Without unique user-IDs, logs cannot be used to definitively indicate the activities of a particular user. This problem in turn is likely to prevent an organization from taking disciplinary actions or entering into prosecutions for computer abuse; it may also prevent the provision of needed remedial training. Without unique user-IDs, privileges cannot be restricted on a user-by-user basis. If privileges cannot be restricted by user, then it will be very difficult to implement separation of duties, dual control, and other security measures. This is a fundamental policy which underlies many access control policies, procedures, and the like. Nothing in this policy prevents the deployment of systems that make the specific computers involved user-transparent (e.g., client/server systems); for example, users may sign-into a network-based application and not a specific computer system. See the policies entitled "Unique User-ID and Password Required" |
| 26.0 | Generic User-IDs Based on Job Function Prohibited | Generic user-IDs based on job function are prohibited. Instead, user-IDs must uniquely identify specific individuals. | The intention of this policy is to prevent systems administrators and other technical staff from creating generic user-IDs based on job titles. This is a short-cut that many technical staff members employ to reduce the overhead associated with changes in worker employment status. With this short-cut, when someone leaves the organization, the password associated the user-ID can simply be changed. The new person who plays the role would employ the new password, while the person who departed would know only the old password. While this approach may sound appealing in theory, there can be difficulties associated with system logs -- which individual's activity do the logs show? Of greater concern is the practice where generic user-IDs are assigned and shared passwords are employed. Individual user accountability (via logs) is very difficult if not impossible to achieve in this environment. Another reason why the generic user-ID approach may be chosen has to do with database management systems, and the delegation of privileges. The same applies to privileges which may be incorporated into so-called "objects" (special programs). In either instance, dropping a user may cause downstream problems with other users or processes. Separately, the use of a generic user-IDs is furthermore ill-advised because it doesn't allow the files in a departed worker's directories to simply exist without modification until they are claimed by others, archived, or deleted. On another point, the policy is written such that group user-IDs cannot be assigned for contracting firms, outsourcing firms, or other third parties. For related ideas, see the policies entitled "Unique User-ID and Password Required" |
| 28.0 | Dormant User-IDs and Automatic Privilege Revocations | All user-IDs must automatically have the associated privileges revoked after a sixty (60) day period of inactivity. | Dormant user-IDs or accounts have been used by many to commit fraud and sabotage. Unauthorized users find dormant user-IDs attractive because the authorized users are unlikely to notice unauthorized usage. The intention of this policy is to eliminate the opportunity for unauthorized users to employ dormant user-IDs for various nefarious purposes (fraud, industrial espionage, etc.). If an authorized user goes on vacation or leave-without-pay for an extended period, this policy will result in their user-ID being revoked. When they return, the authorized user would make a request that the security administrator reinstate privileges. The administrator would then check the individual's status with management, and follow-through with the request if it is consistent with management's intentions. Note that the user-ID can continue to be defined while the associated privileges have been revoked. Because systems administrators are often quite overworked, they may not get around to revoking privileges of users in a timely manner. Accordingly, an automated version of this policy acts as a safety net to reduce vulnerabilities brought on by the lack of timely attention on the part of an administrator. Another reason why IDs should be temporarily revoked but still defined is that it gives relevant managers an opportunity to review the files associated with the ID, and later to dispose of or transfer responsibility for these files as necessary. |
| 148.0 | All firewalls will include access control for device administration. | Firewall configurations must include access controls which prevent unauthorized persons from connecting, viewing or changing configuration of the device. | The intent of this policy is to ensure that network protection devices, like firewalls, have in place suitable access controls that allow only authorized personnel to administer or make configuration changes. This could be accomplished through allowing only certain IP addresses administrative access. This policy does not prohibit more restrictive access controls, such as no network connectivity for administration, restricting access to a separate VLAN for device management or requiring 'second person' systems for device administration. |