| Policy ID No. | Policy | Policy Text | Policy Commentary |
|---|---|---|---|
| 1.0 | Minimum Password Length | The length of passwords must always be checked automatically at the time that users construct or select them. All passwords must have at least eight (8) characters | In many systems, passwords are the first and only line of defense. Guessing passwords is a popular and often successful attack method by which unauthorized persons gain system access. For example, Dr. Thomas Longstaff of the CERT at Carnegie-Mellon University wrote in the February 1993 issue of Computers & Security: "Simple password guessing is still the most prevalent and effective method of system penetration" (page 76). Context-sensitive guessing is used in addition to automated methods like so-called "password crackers." Passwords with only a few characters are much easier to guess than passwords with at least six characters. Eight is considered by many experts to be a minimum password length for general-purpose commercial systems. The policy is applicable to user-chosen passwords as well as system-generated passwords. On most platforms, operating systems software or linked access control security software can be used to automatically enforce this policy. Also see "Difficult-to-guess password required" |
| 2.0 | Difficult-to-Guess Passwords Required | All user-chosen passwords for computers and networks must be difficult to guess. Words in a dictionary, derivatives of user-IDs, and common character sequences such as "12345678" must not be employed. Likewise, personal details such as spouse's name, license plate, social security number, and birthday must not be used unless accompanied by additional unrelated characters. User-chosen passwords must also not be any part of speech. For example, proper names, geographical locations, common acronyms, and slang must not be employed. | The most frequently encountered problem with security systems is human error, and choosing an easily-guessed password is one of the most common security-related mistakes. This policy puts users on notice that they must choose passwords which are difficult for unauthorized parties to guess. Ideally, this policy should be enforced automatically by the system managing password changes, and the enforcement software should be invoked at the time users choose new passwords. This policy and the related control measures are particularly important if users are employing the same password on multiple systems (for instance on so-called "single sign-on systems"). If a single sign-on password is guessed, an intruder then gains access to many systems, whereas access to only one system would be obtained if a single sign-on system were not employed. Suggestions for constructing a difficult-to-guess yet easy-to-remember password: (a) string several words together (these passwords are also known as "passphrases"), (b) shift a word up, down, left or right one row on the keyboard, (c) bump characters in a word a certain number of letters up or down the alphabet, (d) transform a regular word according to a specific method, such as making every other letter a number reflecting its position in the word, (e) combine punctuation or numbers with a regular word, (f) create acronyms from words in a song, a poem, or another known sequence of words, (g) deliberately misspell a word--but not a common misspelling, or (h) combine a number of personal facts like birth dates and favorite colors. Also see the policies entitled "Passwords Must Contain Both Alphabetic and Non-Alphabetic Characters," "Cyclical Passwords Prohibited,", "Suspected Disclosure Forces Password Changes." |
| 3.0 | Cyclical Passwords Prohibited | Users are prohibited from constructing passwords made up of a certain number of characters that do not change combined with a certain number of characters which predictably change. In these prohibited passwords, characters which change are typically based on the month, a department, a project, or some other easily-guessed factor. For example, users must not employ passwords like "XXX34JAN" in January, "XXX34FEB" in February, etc. | This policy is intended to prevent the circumvention of facilities in operating systems and access control systems that prevent the selection of previously-used passwords. So-called "cyclical passwords" are employed by many users as a way to defeat these security systems. Cyclical passwords allow users to continue to employ the same basic password, varying only a part of the password so as to satisfy an automated process which compares the old and new passwords to make sure that previous passwords are not reused. This security-eroding approach is particularly prevalent among users who must log-into many different machines. While single-sign-on systems may make the log-in process easier for these users, if the users employ cyclical passwords, the security of the network and connected systems will be reduced (perhaps becoming lower than before the deployment of the single-sign-on system). Also see the policy entitled "Difficult-to-Guess Passwords Required." |
| 4.0 | Passwords Must Contain Both Alphabetic and Non-Alphabetic Characters | All user-chosen passwords must contain at least one alphabetic and one non-alphabetic character. Non-alphabetic characters include numbers (0-9) and punctuation. The use of control characters and other non-printing characters is discouraged because they may inadvertently cause network transmission problems or unintentionally invoke certain system utilities. | The intention of this policy is to put users on notice that they must take specific steps to make their passwords difficult for unauthorized parties and system penetration software to guess. There are a number of specific steps that users can be told to perform (it is desirable that password change software enforces these rules). These include use of upper and lower case in the same password. Be sure to check systems documentation before writing this policy since some systems have rigid restrictions about the type of characters permitted. See the policies entitled "Difficult-to-Guess Passwords Required" and "Minimum Password Length" |
| 5.0 | Display and Printing of Passwords | The display and printing of passwords must be masked, suppressed, or otherwise obscured so that unauthorized parties will not be able to observe or subsequently recover them. | The intention behind this policy is to prevent passwords from falling into the hands of unauthorized parties. This policy supports two secure systems design principles: (1) each user should have a unique password and user-ID, and (2) each user should have a password known only to that user. Specifically, whenever a user types a password into a system, the password should not be displayed on a monitor. If a password were to be displayed, persons nearby could "shoulder-surf" (look over the shoulder of the user) to obtain the password. Likewise, persons doing "dumpster-diving" (going through the trash) could recover printed passwords. |
| 6.0 | Assignment of Initial Password | The initial password issued by a security administrator must be valid only for the involved user's first on-line session. At that time, the user must be forced to choose another password before any other work can be done. | The intent of this policy is to make sure that only an involved end-user knows their own password. This will in turn allow system activity logged with a corresponding personal user-ID to be uniquely attributable to a certain user. The type of initial password in the policy is sometimes called an "expired password" or a "temporary password" in that it is valid for only one on-line session. Both administrators and end-users must change default or initial passwords before they do any work on the system. This policy assumes group user-IDs are not employed and also that users are permitted to choose their own passwords (no forced system-generated passwords). Also see the policies entitled "Difficult-to-Guess Passwords" and "Changing Vendor Default Passwords," |
| 7.0 | Limit on Consecutive Unsuccessful Attempts to Enter a Password | To prevent password guessing attacks, the number of consecutive attempts to enter an incorrect password must be strictly limited. After no more than six unsuccessful attempts to enter a password, the involved user-ID must be either: (a) suspended until reset by a system administrator, (b) temporarily disabled for no less than three minutes, or (c) if dial-up or other external network connections are involved, disconnected. | One of the most frequently successful attack methods for gaining system access is simple password guessing. Besides simple context-sensitive guessing (knowing a bit about the user and the circumstances), attackers can use password cracker programs to exhaustively go through words in the dictionary. Whether it be a determined manual attack or an automated password guessing attack, this policy will help to ensure that the attack is unsuccessful. Some agencies may wish to put a time frame into the policy, so that the words that "after six (6) unsuccessful attempts" become "after six (6) unsuccessful attempts within five minutes." Likewise a similar result may be achieved by qualifying this phrase with the words "during a single on-line session." It should be noted that, with this approach, some legitimate users will be locked out of their user-IDs if they are poor typists, if they are still learning how to use the system, or if they are having trouble remembering their password. These users will contact the security administrator for a new expired password. The contact with the security administrator also provides an opportunity for the security administrator to give the involved user the information needed to properly log-in the next time he/she uses the system. To support a higher security environment, the six attempts may be lowered. Also see the policies entitled "Suspected Disclosure Forces Password Changes," "Assignment of Initial Password," and "Difficult-to-Guess Passwords" |
| 8.0 | Changing Vendor Default Passwords | All vendor-supplied default passwords must be changed before any computer or communications system is used for State of Alaska business. | One of the oldest, yet still most successful ways to break into systems is to employ default vendor passwords. These default passwords are strings such as "sysadm" or "sysmanager." Typically, the vendor-supplied default passwords are known by both the technical people with experience on this platform as well as the hacker/cracker community. Too many organizations forget to change these passwords before they press the involved systems into production mode. This policy specifically puts technical staff on notice that they must change all vendor default passwords in order to achieve the most basic level of security. Also see the policy entitled "Assignment of Initial Passwords." |
| 9.0 | Suspected Disclosure Forces Password Changes | All passwords must be promptly changed if they are suspected of being disclosed, or known to have been disclosed to unauthorized parties. | The basic secure systems design principle behind this policy is that ONLY the user should know their password (this policy assumes that all users have their own unique user-IDs). If the password in question has been disclosed to some other party, or if this is only suspected, then the password must be immediately changed. This policy implies that the users are able to change their password whenever circumstances warrant. If this is not possible for technical or administrative reasons, as an alternative, a security administrator could reset the involved user's password immediately. Also see the policy entitled "Assignment of Initial Passwords," |
| 10.0 | Password Changes After Compromise of a Computer System | If a computer system employs passwords as its primary access control mechanism, all passwords must be changed immediately after evidence of system compromise has been discovered. At this time, all users must be instructed to change their passwords on other machines, if passwords on the compromised machine are also used on these other machines. | While this policy may at first appear to be obvious to those people who have been working in the information security field for a long time, it is not obvious to newly-appointed systems administrators, network managers, and other technical staff. While the changing of all passwords may not eradicate the source of the compromise, it is a necessary step in the direction of reestablishing a trusted computing environment. Note that this policy also stresses that the passwords on other machines must be changed too; far to few technical people appreciate that a users often employ the same password across a variety of machines. Unless these other passwords are changed, the other machines are at significant risk of compromise as well. For a related policy see "Required Actions Following Suspected System Intrusion." |
| 11.0 | Writing Passwords Down and Leaving Where Others Could Discover | Passwords must not be written down and left in a place where unauthorized persons might discover them. | Discovering passwords written down and left in the top drawer, taped to a computer monitor, or in some other conspicuous spot is a surprisingly common way for penetration attackers (tiger team members) to break into computers. Surprising as it may seem, many users don't think about these risks unless management alerts them to the problems. Note that this policy does not say that users must not write their passwords down; only that they must not be left in a spot where others could recover them. |
| 12.0 | Password Sharing Prohibition | Passwords must never be shared or revealed to anyone else besides the authorized user unless specifically authorized by the Agency Computer Security Officer. The ACSO should take into account that exceptions expose the authorized user to responsibility for actions that the other party takes with the password. The ACSO must make it clear to the user with the shared password that they are responsible for activities undertaken by the person who has their password. The way a user prevents themselves from being improperly held accountable for the actions of another is to keep their password secret. | In an effort to be polite, be more productive, or to save time, users often share their passwords. Sometimes system attackers masquerade as though they are information systems security staff, then asking users for their passwords. When requested to do so, a surprisingly large number of users will readily provide their password. Whenever users disclose their passwords, they inadvertently compromise system access controls and make logs of user activity less useful. It is important that users keep their passwords exclusively to themselves, and the intention of this policy is to remind them to do just that. The policy has a threat in it, specifically the part that talks about being responsible for the actions of another. At many organizations, in the small systems environment (client/server, local area networks, etc.) a casual attitude toward security has traditionally prevailed; a policy like this seeks to counteract this attitude. See also "Users Responsible for All Activities Involving Personal User-Ids" |
| 13.0 | Users Responsible for All Activities Involving Personal User-IDs | Users are responsible for all activity performed with their personal user-IDs. User-IDs may not be utilized by anyone but the individuals to whom they have been issued unless authorized by the ACSO. | The intention of this policy is to make it clear that sharing user-IDs and associated passwords is risky. If users share user-IDs and passwords, logs will not reflect the true identity of the users, and will accordingly be less useful for disciplinary actions, prosecutions, and investigations. Likewise, user specific privilege controls mean little when users are sharing user-IDs and passwords. This policy has some positive side-effects that may not be readily apparent. For example, when an employee goes on vacation, to be in compliance with the policy, they may not give their user-ID and password to someone else so that other person can check the employee's electronic mail. |
| 14.0 | When and How Passwords May Be Disclosed by Security Administrators | Security administrators must only disclose passwords if a new user-ID is being assigned, if the involved user has forgotten or misplaced a password, or if the involved user is otherwise locked out of his or her user-ID. Security administrators must not reveal a password unless the involved user can be personally identified or through a call back to a known State of Alaska phone number. | This policy is intended to make it clear when and how security administrators (who are also often systems administrators) may disclose a password. There are many cases on record where "social engineering" (in this case masquerading as a legitimate user) is used to get security administrators to reveal a password. Note that this policy does allow a security administrator to reveal a password over the telephone so long as adequate evidence of identity is provided (for example mother's maiden name, social security number, etc.). A security administrator my use a call back procedure to call a known State of Alaska office to minimize the risk of social engineering. This over-the-phone process is expedient, although it is definitely less secure than requiring the user to show up in person. For related ideas, see the policies entitled "Suspected Disclosure Forces Password Changes" and "Password Sharing Prohibition." |
| 15.0 | Positive Identification Required for Initial System Usage | All users must be positively identified prior to being able to use any computer or communications system resources. | Positive identification ordinarily involves user-IDs and fixed passwords, but may also include confirmation by a known person in the office. The Agency Computer Security Officer will be the decision maker when it comes to a precise definition of "positive identification." The intention of this policy is to ensure that no unauthorized person is given an account on a State of Alaska computer system. As organizations adopt more interconnected systems, this policy becomes increasingly important. For example, a stand-alone departmental local area network poses a relatively limited vulnerability, but when such a LAN is connected to a wide area network, the need for all users to be positively identified is increased. |
| 16.0 | User-ID and Password Required for Access to State of Alaska Network Systems. | All users must have their identity verified with a user-ID and a secret password--or by other means which provide equal or greater security--prior to being permitted to use State of Alaska high and medium risk "multi-user" systems. | The intent of this policy is to make sure that only authorized people can gain access to organizational networks. The public access side of network systems, such as web and anonymous ftp servers, are by definition low risk and are outside of this policy. Administrative access to low risk systems, such as administrator login or ftp access used to manage a web server, falls under the medium or high risk category and is subject to this policy. The policy also allows the organization to move to extended user authentication via biometrics, call-back systems, dynamic password identity tokens, etc. Also see the policies entitled "Minimum Password Length", "Unique User-ID and Password Required" and "Granting User-IDs to Outsiders." |
| 17.0 | Unique User-ID and Positive User Authentication Required <<>> | Every user must have a single unique user-ID and a personal secret password or other positive user authentication. This user-ID and password will be required for access to State of Alaska multi-user computers and computer networks. | With the ever-increasing number of computers and networks found in modern organizations, use of various user-IDs for the same person is getting to be too complex. This policy simplifies all that for both users and systems administrators. Another intention of the policy is to ensure that all multi-user systems and networks have access control software which can uniquely identify and restrict the privileges of each user. These access control facilities also allow special logging and monitoring software to be used. The use of the same user-ID on all computers and networks across an organization is additionally desirable (but not required) because it makes analysis of activity logs considerably easier. The use of the term "multi-user computer" in the policy effectively exempts workstations. The policy described here also prohibits group user-IDs -- typically a significant problem in those organizations where the level of awareness about information security is low. The term "positive user authentication" allows for smart cards, dynamic password tokens, biometrics and other technologies. See also the policies entitled |
| 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" |
| 27.0 | Restriction of Third Party Dial-Up Privileges | Third party vendors must only be given in-bound dial-up maintenance privileges when the system manager determines that they have legitimate business need. These privileges should be enabled only for the time period required to accomplish approved tasks. The Agency Computer Security Officer may modify this requirement on a case by case basis to satisfy a legitimate business need. Exemptions to this policy should not violate "Extended User Authentication Systems Required for Dial-Up Lines". | Dial-up maintenance privileges have been used by a number of hackers, crackers, and other system attackers to gain unauthorized access to systems. It is ill-advised to leave dial-up ports, such as those used by vendors for remote maintenance, open and available if they are not needed. The intention of this policy is to keep maintenance ports turned off, and keep third parties off the system unless they have first obtained approval from State of Alaska management. Having a formal approval process will also discourage--if not prevent--others from attempting to masquerade as though they are a vendor representative as a way to get onto a system. The use of the word "in-bound" in the policy provides an exemption for sophisticated maintenance systems that automatically dial (out-bound) the vendor's system when they detect a problem. Also see the policies entitled "Extended User Authentication Systems Required for Dial-Up Lines" and "Dial-Up Connections Must Always Utilize Firewalls." |
| 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. |
| 30.0 | Unbecoming Conduct and the Revocation of Access Privileges | State of Alaska management reserves the right to revoke the privileges of any user at any time. Conduct that interferes with the normal and proper operation of State of Alaska information systems, which adversely affects the ability of others to use these information systems, or which is harmful or offensive to others will not be permitted. | The intention of this policy is to put users on notice that they jeopardize their status as authorized users if they engage in the activities described. For example, crashing the system could reasonably be expected to be harmful to other users, and would accordingly subject the perpetrator to disciplinary action including privilege revocation. Rather than specifying all the nasty things that people could do, such as crashing a system, this policy is discreet and high-level. The broadly-stated policy may also give management ample latitude when it comes to making a decision about privilege revocation. Persons who abuse their privileges may also be subject to disciplinary action including civil or criminal legal action. Also see the policies entitled "Default User Privileges and Need for Explicit Approvals" and "Periodic Review and Reauthorization of User Access Privileges." |
| 31.0 | Prohibitions Against Testing Information System Controls | Workers must not test, or attempt to compromise State of Alaska computer security system controls unless specifically approved in advance and in writing by the State Computer Security Officer and the appropriate Agency Computer Security Officer. | When users to attempt to break controls, this fosters an "attack ethic," i.e., an environment where it is acceptable for workers to attempt to break system controls. This policy eliminates an often invoked excuse for computer crimes, as the perpetrators may say that they were merely "testing the control system so as to be able to improve it." Of course, internal auditors already have this approval (in their departmental mission statement), and they should continue to test controls. While there is merit to regularly testing controls to illuminate weaknesses, this activity needs to be strictly controlled and performed in a confidential manner (lest the results be exploited by employees and others). This policy also prohibits "tiger team attacks" (also known as "penetration attacks") unless approved in advance by management. See also "Prohibition Against Exploiting Systems Security Vulnerabilities" |
| 32.0 | Prohibition Against Exploiting Systems Security Vulnerabilities | Users must not exploit vulnerabilities or deficiencies in information systems security to damage systems or information, to obtain resources beyond those they have been authorized to obtain, to take resources away from other users, or to gain access to other systems for which proper authorization has not been granted. All such vulnerabilities and deficiencies should be promptly reported to the Agency Computer Security Officer. | The intention of this policy is to make it clear that users must not take advantage of information security vulnerabilities and deficiencies, even if they are aware of such problems. One example of such a problem involves having knowledge of a special password that allows a user to do things they would otherwise not be able to perform. In a broad sense, this policy is saying that users are given only the privileges explicitly granted to them--if they can do something else due to security problems, they are not authorized to take advantage of these problems. As written, the policy includes errors made by systems administrators, for example if a user was given too many privileges. While this example may not involve a control vulnerability, it is decidedly a deficiency associated with the deployment of controls. For related ideas, see the policies entitled "Required Reporting of Information Security Incidents" and "Restricted Use of Diagnostic Test Hardware and Software." |
| 34.0 | Administrative Security Management for All Networked Computers | Configurations and set-up parameters on all computers attached to the State of Alaska network must comply with State of Alaska security management policies and standards. | The intention of this policy is to clearly state that all LAN administrators, mainframe access control package administrators, and the like must consistently abide by internal security management policies and standards. Often these administrators are tempted to do things their own way, perhaps inadvertently opening an unauthorized access pathway to connected machines. This policy may at first seem unnecessary; some people may think that everyone else knows that the weakest link in a chain will be the first to break. But there is merit to stating this idea in writing, perhaps giving management something else to use when attempting to get administrators to abide by internal policies and standards. |
| 35.0 | Reporting Changes in User Duties to Systems Security Administration | Management must promptly report all significant changes in end-user duties or employment status to the computer system security administrators handling the user-IDs of the affected persons. | The intention behind this policy is to support the notion of least privilege. End-user privileges must promptly be turned off if an individual has been terminated, transferred, promoted, put on leave without pay, or otherwise no longer in the same position. Systems security administrators don't generally know about these changes unless they receive notification from the involved managers (or alternately from the Human Resources Department). A separate but related policy requiring that all such status-change information be kept in strict confidence is advisable because a terminated employee may bring a defamation of character lawsuit. This policy may be particularly useful when it comes time to establish standard procedures for notifying administrators about worker status changes. See the related policies entitled "Changing Physical Access Control Codes on Worker Termination" and "Transfer of Information Custodian Duties After Employee Terminations." |
| 36.0 | Maintenance of Master User-ID and Privilege Database | So that their privileges may be expediently revoked on short notice, records reflecting all the computer systems on which users have user-IDs must be kept up-to-date. | The intention behind this policy is to make sure that all user-IDs that an employee (or consultant, contractor, temporary, etc.) uses can be readily identified and the associated privileges quickly revoked. This will, for instance, be useful when an employee has been shown to be embezzling, in which case all user-IDs should be shut down immediately. Even when less dramatic changes in user status take place, such a database can be very helpful in determining which systems security administrators should be notified. Also see the policies entitled "Naming Standard for a Single User-ID Used on All Platforms." |
| 37.0 | Transfer of Information Custodian Duties After Employee Terminations | When a worker leaves any position with the State of Alaska, both computer resident files and paper files must be promptly reviewed by their immediate manager to determine who should become the custodian of such files, and/or the appropriate methods to be used for file disposal. The computer user's manager must then promptly reassign the computer user's duties as well as specifically delegate responsibility for information formerly in the computer user's possession. | The intention behind this policy is to clearly and expediently transfer custodian responsibilities, and thereby to ensure that security measures are maintained in minimally acceptable ways. The reassignment of duties process is especially important if the files contain sensitive, critical, or valuable information. This policy also implicitly puts employees on notice that their files will be examined by others after they leave the organization. Additionally, with this policy, managers are put on notice that they are responsible for the proper handling of a departed worker's information. The policy helps to avoid fraud, sabotage, and other abuses, which frequently take place when no specific person has responsibility for a certain area (perpetrators often take advantage of the confusion surrounding the departure of an employee). See the policies entitled "Changing Physical Access Control Codes on Worker Termination" |
| 38.0 | Logs Required on Application Systems Handling Sensitive Information | All production application systems which handle sensitive State of Alaska information must generate logs that show every addition, modification, and deletion to such sensitive information. | The intention behind this policy is to be able to account for all changes to sensitive information like personnel records, strategic plans, and product design specifications. For example, the payroll database in most organizations should have an associated log which shows who updated the payroll amounts and when. This type of information will be very helpful when attempting to investigate and correct problems like errors and fraud. This policy essentially indicates which applications should have associated logs (also called "audit trails"). The log data elements (for example, whether a before-and-after image should be logged) will need to be determined on a case-by-case basis. |
| 39.0 | Inclusion of Security Relevant Events in System Logs | Computer systems handling sensitive, valuable, or critical information must securely log all significant computer security relevant events. Examples of computer security relevant events include: password guessing attempts, attempts to use privileges that have not been authorized, modifications to production application software, and modifications to system software. | This policy is intended to specify which computer systems must have system logs reflecting security relevant events. It is particularly relevant to microcomputers, workstations, local area network servers, client/server systems, and similar small systems that often lack adequate logs. It may be necessary to further specify what constitutes a "security relevant event" in the policy. Note that the policy only requires logs for systems handling sensitive, valuable, or critical information. |
| 40.0 | Required Retention Period of Logs | Logs containing computer security relevant events must be retained for at least three (3) months. During this period, such logs must be secured such that they cannot be modified, and such that they can be read only by authorized persons. These logs are important for error correction, forensic auditing, security breach recovery, and related efforts. | The intention of this policy is to clearly specify the retention period for logs as well as the need for secure storage of logs. The policy can be expanded to define explicitly what events are deemed as "security relevant." There is nothing special about three months; the figure will vary by agency and the nature of the business and the information involved. Be sure to check with internal legal counsel and records management staff about the appropriate time period to retain such records. The retention period for business transactions will generally be much longer than the retention period for security relevant events; a log of security relevant events generally does not contain business transactions. |
| 41.0 | Logs of User-Initiated Security Relevant Activities | To assure that users are held accountable for their actions on State of Alaska computer systems, one or more records tracing security relevant activities to specific users must be securely maintained for a reasonable period of time. | The intention of this policy is to clearly specify that all user-initiated security relevant activities must be logged and retained for a certain period (three months for instance). This information will be helpful to those people in security administration, computer operations, and internal auditing. The information also serves as a deterrent to abusive acts, as well as important information for the "help desk" to use when figuring out the nature of a problem. The policy makes reference to security relevant activities like user changes to file access privileges, user changes to a secret password, and the like. |
| 42.0 | Information to Capture When Computer Crime or Abuse is Suspected | To provide evidence for investigation, prosecution, and disciplinary actions, certain information must be immediately captured whenever it is suspected that a computer crime or abuse has taken place. The relevant information must then be securely stored off-line until such time as the State Computer Security Officer determines that State of Alaska will no longer need the information. The information to be immediately collected includes the current system states, as well as back-up copies of all potentially involved files. | This policy is intended to put systems management on notice that certain information must be captured and securely stored until needed by internal auditors, prosecuters, security administrators, and others. The policy allows evidence to be captured and secured, so that it will later be admissible in court. On the other hand, if the evidence remained on the computer for a certain period, there is a possibility that it could have been modified by unauthorized parties. If the evidence could have been modified, it will not be convincing in the eyes of the court. Note also that the process of capturing information should take place even if there is only a suspected problem. It is better to have this information and then dispose of it if it's not needed, than to not have the information and then be unable to take certain courses of action (such as prosecution). The policy thus makes sure that a snap-shot of the current situation is preserved for later use. |
| 43.0 | Persons Authorized to View Logs | All security, system and application logs must be maintained in a form that cannot readily be viewed by unauthorized persons. A person is unauthorized if they are not a member of the internal audit staff, systems security staff, systems management staff, or if they do not clearly have a need for such access to perform regular duties. Unauthorized users must obtain written permission from the Agency Computer Security Officer prior to being granted such access. | The intention of this policy is to limit access to all logs--including security, application and system logs--to only those persons who have a bone fide need to have such access. Access by unauthorized persons can reveal user-IDs, transaction specifics, and other information that may be instrumental in fraud, sabotage, and other abuses. If logs are encrypted, they will be exceedingly difficult for unauthorized people to view or modify. In terms of off-site storage, encryption is really the only truly effective way to prevent unauthorized access. Rather than encryption, in less secure environments, use of file access controls may be sufficient. In some circumstances, written permission for access to application logs may be granted by the information owner/sponsor, rather than the Agency Computer Security Officer. This policy assumes that other types of access control will also be in place. |
| 44.0 | Regular and Prompt Review of System Logs | To allow proper remedial action, computer operations or information security staff must review records reflecting security relevant events in a periodic and timely manner. | The intention of this policy is to require that computer operations or information security staff promptly review logs. This review process can be greatly facilitated if the logs produce exception reports indicating items of a suspicious nature in need of follow-up. To ask a person to go through a log reflecting all system events on a busy multi-user system is like asking them to find a "needle in a haystack." Prompt review of logs might, for example, be important if there was a hacker who was attempting to guess passwords via a dial-up line. If the logs were never reviewed, and if there were no other mechanism (like pager alerts) to notify the people who could do something about it, the organization may never have become aware of the attacks. If the attacks were not stopped--or at least discouraged by telling the hacker that they are being closely monitored--the hacker may be encouraged to continue. Likewise, the chronological window for taking remedial action (such as stopping an employee from making copies of personell records) closes quickly unless corrective steps are promptly initiated. In some environments, such as electronic funds transfer systems, the window in which adjustments must be made is very slim (a few days). In environments such as this, the time frame for log review may also be included in an agency specific policy. The policy could be expanded to include application logs, in which case user management or information owners/sponsors may be involved in the review process. |
| 45.0 | Notification of Users About Logging of Security Violations | Users must be put on notice about the specific actions that constitute security violations. Users must also be informed that such violations will be logged. Violations will subject users to disciplinary actions up to and including termination and prosecution. | The intention of this policy is to require that all users be clearly informed about the actions which constitute a security violation. To discourage users from engaging in these actions, they should be told that their activities will be logged. Disciplinary action will be very difficult if users have not been told about, and do not clearly understand what is expected of them. Violations will subject users to disciplinary actions up to and including termination and prosecution. Typically these violations would include attempts to compromise controls through password guessing, changing system access controls, as well as other actions such as crashing the system. |
| 46.0 | Testing for Viruses Prior to Use on State Systems | To prevent infection by computer viruses, workers must not use any externally-provided software from a person or organization other than a known and trusted supplier. The only exception to this is when such software has first been tested and approved by the Agency Computer Security Officer. | The intention of this policy is to keep all software used on State of Alaska systems free from viruses, worms, Trojan horses, and other unauthorized programs. Note that the policy is not restricted to production systems; these unauthorized programs propagate rapidly and make no distinction between production and non-production systems. The policy requires only a negligible amount of extra work associated with the handling of externally-provided software. Normally, users would employ only that software which has been approved for internal use and which is in keeping with existing licenses with vendors. Thus this policy helps restrict the software that users may run. In a roundabout way, the policy also helps to discourage unauthorized copying of software for which State of Alaska does not have a license. Although it does not need to be placed in the policy, the testing performed should always be done on an isolated machine. Some Agencies may want to specify what constitutes a "known and trusted supplier" (ordinarily not an electronic bulletin board, a users group, or some other non-commercial entity). Some Agencies may wish to expand the policy to require that all such testing of externally-supplied software be documented. Some organizations may wish to change the policy such that it requires all specific copies of software provided by non-trusted parties to be tested (rather than one copy, which is then alleged to be the same as other copies provided by the organization). On a separate note, this policy allows users to down-load software from third party systems--it just prohibits them from executing it until it has been properly tested. See the policies entitled "Immediate Reporting of Suspected Computer Virus Infestation." |
| 49.0 | Approved Virus Checking Programs Required on PCs and Servers | Virus checking programs approved by the Agency Computer Security Officer must be continuously enabled on all servers and personal computers. | This policy doesn't make distinctions between integrity checkers, virus screening packages, virus behavior detection packages, and the like. Instead, it relies on the iAgency Computer Security Officer to identify one or more standard virus detection software packages. The emphasis is on networked machines because a virus or similar program can propagate much faster in a networked environment than it can in a stand-alone computing environment. The policy focuses on small systems because these are the computers which are most often hit by virus infections, not mainframes and other large-scale systems. For related ideas, see "Testing for Viruses Prior to Use on State Systems" and "Immediate Reporting of Suspected Computer Virus Infestation" |
| 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." |
| 54.0 | Restricted Use of Diagnostic Test Hardware and Software | Diagnostic test hardware and software, such as communications line monitors and network sniffers, must be used only by authorized personnel for testing and development purposes. Access to such hardware and software must be strictly controlled. | Diagnostic test hardware and software can be used to insert spurious messages on a communications line so that a fraud may be perpetrated. The tools may also allow people to read communications line traffic that they would otherwise not be able to examine. These wiretapping tools have, for instance, been used to capture readable passwords which are then later used to gain unauthorized system access. The intention of this policy is thus to restrict the use of such powerful tools to troubleshooting and other authorized business activities. The policy gives local management significant leeway in determining the ways in which they secure these hardware and software tools. For instance, some managers will require that line monitor devices be locked in a closet, while others will be satisfied with the use of a metal key to activate and deactivate the device. There is a greater need for this policy in those environments using fixed passwords (rather than dynamic passwords) for system access control. |
| 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. |
| 59.0 | Release of Systems Documentation to Third Parties | Prior to being released to third parties, all documentation that describes State of Alaska systems or systems procedures must be reviewed by the Agency Computer Security Officer to ensure that confidential information is not being inadvertently disclosed. | It is important to communicate to workers that documentation, not just business records, may warrant restricted dissemination procedures. This policy puts staff on notice that they are not to release internal systems documentation without prior approval. The approval could also be provided by the Information Systems Department manager, legal counsel, or some other manager. This policy is also called for because many system crackers/hackers use so-called "social engineering" (also known as "conning") to get information about internal systems, which in turn allows them to break into these systems. If employees are on notice that such information is not to be distributed to outsiders without prior permission, it is less likely that they will fall for such ploys. |
| 60.0 | Information as an Important State of Alaska asset | Information is an important State of Alaska asset. Accurate, timely, relevant, and properly protected information is absolutely essential to State of Alaska's business. To ensure that information is properly handled, all accesses to, uses of, and processing of State of Alaska information must be consistent with State of Alaska information systems related policies and standards. | This general policy helps to set the context for a number of other information security policies. Such a statement is frequently incorporated into the first set of policies as well as summary material oriented towards users and members of the management team. It is necessary for these people to appreciate how information has become a critical factor of production in modern business--only then can they appreciate the pressing need for information security. The intention of this policy is thus to motivate the need for information security measures and to contextualize the use of information systems in modern organizations. |
| 61.0 | Tools Used to Break Systems Security Prohibited | Unless specifically authorized by the Agency Computer Security Officer, State of Alaska workers must not acquire, possess, trade, or use hardware or software tools that could be employed to evaluate or compromise information systems security. Examples of such tools include those which defeat software copy-protection, discover secret passwords, identify security vulnerabilities, or decrypt encrypted files. | Because these tools can be and often are used to circumvent controls, their possession and use should be severely restricted. Possession and use should be allowed only for those who have a need for such powerful tools, such as security auditors and tiger-team staff (penetration attack team members). While these tools are readily available on the open market, on the Internet, and on electronic bulletin boards, State of Alaska users should not be in possession of these tools. Thus, ordinary users should not have a collection of vulnerability identification tools like SATAN and COPS stored on their hard drive. Likewise, users should not have a protocol analyzer (a "sniffer") in their possession because it can be used to perform actions such as a wiretap, password reading, and unauthorized data viewing. For the same reason, users should not have a database which contains working serial numbers needed to operate stolen software. Some users may claim that they never intended to use such tools, that they only acquired them to learn about computers. This policy removes the whole question of the user's intent from the discussion; if users have the tools, they may be disciplined or terminated. Also see the policies "Prohibition Against Testing Information System Controls," and "Disclosure of Information About Information System Vulnerabilities" |
| 62.0 | Handling of Third Party Confidential and Proprietary Information | Unless specified otherwise by contract, all confidential or proprietary information that has been entrusted to State of Alaska by a third party must be protected as though it was State of Alaska confidential information. | In many cases the people handling third party information do not have access to the contracts which define agreed-upon procedures for handling information entrusted to State of Alaska. This policy by default assigns a classification of "confidential" to all such information. |
| 63.0 | Software and/or Data Exchanges with Third Parties Require Agreements | Exchanges of software and/or data between State of Alaska and any third party may not proceed unless a written agreement has first been signed. Such an agreement must specify the terms of the exchange, as well as the ways in which the software and/or data is to be handled and protected. This policy does not cover release of information designated as public. | The intention of this policy is to prevent misunderstandings about the use of and protection of State of Alaska proprietary or sensitive information. For example, an agency and a consultant exchange mailing lists, it could be specified in writing that the lists are to be used once only (or whatever other arrangements have been established). Having a written contract also provides some assurance that controls will be used to prevent the information from being disclosed to unauthorized third parties and from being used for purposes other than those originally intended. Because it encourages some restraint associated with the dissemination of information, this policy is relevant to electronic mail and the Internet. |
| 64.0 | Disclosure of Information on State Systems to Law Enforcement | By making use of State of Alaska systems, users consent to allow all information they store on State of Alaska systems to be divulged to law enforcement at the discretion of State of Alaska management. | This policy puts users on notice that they should not have an expectation of privacy with respect to State of Alaska systems. It also puts users on notice that no search warrant will be necessary before law enforcement agents gain access to information they store on State of Alaska systems. Management may wish to reveal certain information (such as electronic mail logs) to law enforcement; this could be appropriate if management discovered the use of its computing facilities to conduct drug deals or some other illegal activity. Like the policy entitled "Right of Management to Examine Data Stored on State of Alaska Systems," this policy helps to manage user expectations, making sure that users understand they do not have normal privacy protections applicable to public communications carriers (like the phone company). For Third Parties this applies to any data or data systems that contain State of Alaska data. For the Third Parties this does not include proprietary and company confidential information but only pertains to the portions that are relevant to work performed for the State of Alaska. Also see the policy entitled "Disclosure of Private Information to Third Parties" and "Electronic Mail Messages Are Company Records." |
| 65.0 | Privacy Expectations and Information Stored on State Systems | At any time and without prior notice, State of Alaska management reserves the right to examine archived electronic mail, personal file directories, hard disk drive files, and other information stored on State of Alaska information systems. This examination is performed to assure compliance with internal policies, support the performance of internal investigations, and assist with the management of State of Alaska information systems. | The intention of this policy is to put computer users on notice that the information they store, transmit, or otherwise process via State of Alaska information systems is subject to management review. This will encourage them to use such information systems for business purposes only. It will also help to deter unethical or illegal activities such as down-loading pornography from the Internet, and then storing such information on a State of Alaska computer hard disk drive. See the policies entitled "Privacy Expectations and Electronic Mail," |
| 67.0 | No Blanket Monitoring of Employee Communications | In general terms, State of Alaska does not engage in blanket monitoring of employee communications. It does, however, reserve the right to monitor, access, retrieve, read, and/or disclose employee communications when: (a) a legitimate business need exists that cannot be satisfied by other means, (b) the involved employee is unavailable and timing is critical to a business activity, (c) there is reasonable cause to suspect criminal activity or policy violation, or (d) monitoring is required by law, regulation, or third-party agreement. | The intention of this policy is to put employees on notice that their communications may be monitored under certain circumstances. The policy also seeks to assure employees that a "big brother" style blanket monitoring process does not exist, and the right to monitor will be used judiciously and only when a legitimate business need exists. For a related idea, see the policy entitled "Privacy Expectations and Information Stored on State of Alaska Systems." |
| 69.0 | Monitoring of Electronic Mail Messages | Messages sent over State of Alaska internal electronic mail systems are not subject to the privacy provisions of the Electronic and Communications Privacy Act of 1986 (which prohibits wiretapping), and therefore may be read by State of Alaska management and system administrators. | This policy makes it clear that management and technical staff may read worker electronic mail messages when management authorizes it. By the same token, technical staff may not monitor e-mail without authorization. Also see the policy entitled "Privacy Expectations and Electronic Mail." |
| 70.0 | Notification of Suspected Loss or Disclosure of Sensitive Information | If secret, confidential, or private data is lost, is disclosed to unauthorized parties, or is suspected of being lost or disclosed to unauthorized parties, its owner and the Agency Computer Security Officer must be notified immediately. | Prompt notification of loss or disclosure is a necessary precursor to performing effective damage control. For instance, if information about a new but not yet released RFP has been mistakenly disclosed to a vendor, then the date for the official announcement may need to be changed. The intention of the policy is therefore to require that all workers report all losses or disclosures of sensitive information. |
| 71.0 | Disclosure of Information System Vulnerabilities | Details about information system vulnerabilities, such as the details of a recent system security breach, must NOT be distributed to persons who do not have a demonstrable need-to-know. | The intention of this policy is to let those few people, who have access to details about information system vulnerabilities, know that disclosure should be strictly controlled. If vulnerability information were to fall into the hands of unauthorized parties, these people could use it to compromise the organization's systems. These unauthorized parties could also use it to blackmail (extort) or publicly embarrass the organization. The vulnerability information may also erode the confidence that users and management have in the Information Systems Department, and for this reason should also be restricted. |
| 72.0 | Information With Multiple Risk Categories On Single System | If a computer system contains information with varying risk categories, the controls used must reflect the highest risk information on the system. | The intention of this policy is to make sure that sensitive information is not improperly disclosed because it is on the same system as other less sensitive information. Separately, this policy would for example indicate that the operating system's access control mechanisms must be strong enough to protect the most sensitive information on the system; this means that all the other types of information must bear the overhead of this most sensitive type of information. |
| 74.0 | Organization and Maintenance of Computer Emergency Response Team | The State must organize and maintain a computer emergency response team (CERT) that will provide accelerated problem notification, damage control, and problem correction services in the event of computer related emergencies such as virus infestations, hacker break-ins, and the like. | The classic CERT that has been the model for many in-house CERTs can be found at Carnegie Mellon University, in Pittsburgh, Pennsylvania, USA; their e-mail address is cert@cert.org. The Carnegie Mellon CERT assists users of the Internet network, while other CERTs coordinate investigations and problem eradication efforts on an international basis. By formally defining an in-house CERT, an organization becomes better prepared to deal with security-related contingencies. Use of an in-house CERT also reduces the probability that problems will become public knowledge. The intention of this policy is thus to require that Data Processing or related technical management set-up and support a CERT. Also see the policies entitled "Internal Reporting of Information Security Violations & Problems," and "Information Security Alert System." |
| 75.0 | Required Actions Following Suspected System Intrusion | Whenever a systems administrator has good reason to believe that a information security system has been compromised, the involved computer must be immediately removed from all networks. The systems administrator must then examine the system and take appropriate actions (such as password changes and virus scans) before restoring the system to the network. The current system log must also be copied to separate data storage media. | This policy seeks to establish the minimum actions that systems administrators must take in response to a system intrusion and related problems. All too often systems administrators get pressure from user management not to disconnect from an internal network, not to check to see which files have changed, and not to reestablish a reliable access control system. This policy overrides user management wishes, requiring these essential steps to be performed. For related ideas, see the policies entitled "Password Changes After Compromise of a Computer System," and "Required Retention Period of Logs." |
| 76.0 | Information Security Alert System | Agency Computer Security Officer must establish, maintain, and periodically test a communications system a method to allow workers to promptly notify appropriate staff about suspected information security problems. These problems include computer virus infestations, hacker break-ins, improper disclosure of internal information to outsiders, system service interruptions, and other events with serious information security implications. | The intention of this policy is to make sure that management establishes and supports an appropriate communications system for the prompt notification of information security staff. This is different from an organizational structure for the prompt mobilization of information security staff, for example a Computer Emergency Response Team (CERT). Without such a communications system, all too often attacks are ignored, thus allowing attackers to continue to try other methods. Similarly, unless such problems are promptly communicated, there is a serious danger that total losses will be much greater than they need to be. This can be clearly seen with virus infestations on a computer network, where each minute of delay means further business interruptions and additional data destruction. In many organizations, the notification process will involve pagers, telephone number calling trees, and other methods. Also see the policies entitled "Organization and Maintenance of Computer Emergency Response Team," and "Required Reporting of Information Security Incidents." |
| 77.0 | Update & Test Information Systems Contingency Plans | For computer and communications systems, management must prepare, periodically update, and regularly test contingency plans. These plans must provide for the continued operation of critical systems in the event of an interruption or degradation of service. | In this context, the words "contingency plans" apply to both emergencies as well as disasters. In the course of preparing contingency plans, organizations should go through what is called a business impact analysis, which examines the effects of various loss scenarios. For example, if a bomb were to go off in a computer center, what would the impact be? Only when the impacts are determined and ranked by priority, can contingency planning resources be allocated efficiently, and can a logical contingency plan be prepared. This policy is intended to mandate the regular update and testing of contingency plans. The information systems field moves so fast that updates are required at the very least annually, and very often more frequently. Of course, other types of contingency plans will also be needed. For example, if a bomb goes off in an organization's headquarters building, then personnel will need another set of offices if the organization's work is going to continue. This backup office space would generally be covered in a facilities contingency plan. Also see the policy entitled "Annual Information Security Planning Process Required." |
| 79.0 | Store Critical Production Data Securely At Off-Site Location | Backups of essential business information and software must be stored in an environmentally protected and access-controlled site, which is a sufficient distance away from the originating facility to escape a local disaster. | The intention of this policy is to require that up-to-date backup media is stored at a location some distance from its primary location. If a bomb goes off and destroys a building, then backups which were co-located with the original copies will be of very little, or no use whatsoever. The policy also makes a point of emphasizing the need for environmental controls, because excessive heat and airborne particulate matter can damage some types of magnetic recording media. Likewise, only authorized people should be able to access the remotely located backups. In some cases encryption of backups will be advisable in order to assure that only authorized people can access this critical information stored on these backups. |
| 82.0 | Misrepresentation of Identity on Electronic Communication Systems | Misrepresenting, obscuring, suppressing, or replacing a user's identity on an electronic communications system is forbidden. The user name, electronic mail address, organizational affiliation, and related information included with messages or postings must reflect the actual originator of the messages or postings. | The intention of this policy is to put users on notice that they may not misrepresent their identity on electronic communication systems, even for practical jokes or other humor. The scope of the policy is deliberately broad (specifically "electronic communication systems") so that it includes telephone systems as well as electronic mail systems. Note that this policy does not require all the routing information on an electronic mail message to be maintained, only the originator's identity. Separately, under this policy, the use of another person's user-ID is a policy violation (and technically electronic forgery). This policy assumes that no group user-IDs have been assigned; in other words, each user should have one or more personal user-IDs. |
| 83.0 | Large Networks Must Be Divided into Separate Domains | Each Agency network must, at a minimum, have a separately-defined logical domain. Each domain must be protected with suitable security perimeters and access control mechanisms. | This policy requires network management staff to review access controls between Agencies on the State of Alaska WAN. While each logical domain need not include a separate access control mechanism, management needs to justify this decision (hence the use of the word "suitable" in the policy). All too often large networks allow users to roam all over the network without encountering any barriers whatsoever. The logical domains referred to in the policy might be the individual Agencies or their internal organizational units (such as an accounts payable department), activities (such as Teacher Certification), or locations (such as a headquarters building) . The barriers may be implemented with communications front-ends, routers, gateways, firewalls, and other network components that include access controls. The most common method used to restrict access to parts of a network is passwords, although other mechanisms like encryption can also be employed. Also see the policies entitled "Dial-Up Connections Must Always Utilize Firewalls," and "Positive Identification Required for Initial System Usage." |
| 85.0 | Dial-Up Connections Must Utilize an Access Control Point | All inbound dial-up lines connected to State of Alaska internal networks must pass through an additional access control point before users can reach a log-in banner. The access control point can be a firewall or other security device suitably configured to only restrict unauthorized activities. | The intention of this policy is to restrict dial-in connections with authorized parties such as consultants, travelling executives, and technicians working from home (telecommuters). Some organizations may allow extended user authentication systems (smart cards with dynamic passwords, dial-back modems, etc.) to be used. The advantage to this process is that users would not be required to log-in twice; the approach is therefore consistent with the notion of single-sign-on. In part this policy is an acknowledgement that traditional fixed password systems do not provide adequate security--at least when used the way that so many firms have implemented them. Acknowledging this, a two-layer approach provides additional security. This policy seeks to directly address dial-up modems that some users may have placed on their desks, that can in turn be used to gain direct access to a local area network (LAN). Also see the policy entitled "Restriction of Third Party Dial-Up Privileges," |
| 86.0 | External Network Connections Require Firewalls | All in-bound connections to State of Alaska networks must pass through an additional access control point (such as a firewall, VPN, or access server) before users can reach protected State of Alaska computer resources.. | This policy is intended to make sure that the periphery of an internal network always has strong access control mechanisms. If the boundaries to a network cannot be protected, then the controls inside the network may be superfluous. Examples would be a thrid party broadband device (cable modem or DSL) or a wireless access point located inside the State network. Separately, this policy requires all external real-time connections to have a firewall or comparable security system. Also see the policy entitled "Positive Identification Required for Initial System Usage" |
| 87.0 | Internet Connections Require Approved Firewalls | All connections between State of Alaska internal networks and the Internet (or any other publicly-accessible computer network) must include an approved firewall and related access controls. | This policy is intended to prevent departments, divisions, and other organizational units from establishing their own connections to the Internet, or for that matter, any other external computer network. This policy mandates a standard way to make connections between internal networks and external networks. Consistency in network access controls is absolutely essential if effective security is going to be achieved. Without this policy, various parts of an organization are likely to establish their own external connections, and often these connections will lack adequate security; these connections may later be used by outsiders to gain unauthorized access to internal networks. For related ideas, see the policies entitled "Restriction of Third Party Dial-Up Privileges," "Large Networks Must Be Divided into Separate Domains," |
| 88.0 | Direct Network Connections With Outside Organizations | The establishment of a direct connection between State of Alaska systems and computers at external organizations, via the Internet or any other public network, is prohibited unless this connection has first been approved by the Agency Computer Security Officer. | Encryption Tunnels, such as VPNs, may be useful in certain circumstances but they introduce additional security risks. This policy requires that users obtain approval of the information security manager or some other person responsible for information security before they establish such connections. Before approving such connections, a number of questions need to be answered, specifically: "Who will be able to access State of Alaska systems?", "What information on State of Alaska systems will be available to them?", "What logging systems will track the activity of these outsiders?", "What is the real business need underlying this type of a connection?", and "Is there another way that we can achieve the desired productivity without introducing additional information security vulnerabilities?" For related ideas, see the policies entitled "Restriction of Third Party Dial-Up Privileges," "Large Networks Must Be Divided into Separate Domains" |
| 89.0 | Security Requirements for Work at Home Arrangements | Work at home (telecommuting) arrangements are a management option, not a universal employee benefit. Permission to telecommute is the decision of the involved employee's manager. Before a telecommuting arrangement can begin, this manager must be satisfied that an alternative worksite (such as a home office) is appropriate for the State of Alaska work performed by the involved employee. Security factors that must be evaluated and approved by the Agency Computer Security Officer before authorizing telecommuting include: Virus scanning, Firewall, VPN, Data backup and Physical Security. | Discussions about "alternative worksites" (notably home offices) have become more prevalent in the last few years. Whenever these arrangements are being considered it is important to consider what happens to State of Alaska physical assets (such as computers) as well as information assets. See also the policies "Dial-Up Connections Must Utilize an Access Control Point", " External Network Connections Require Firewalls", and "Internet Connections Require Approved Firewalls" |
| 90.0 | question??????????? Automated Encryption Key Management Systems Preferred | Whenever such facilities are commercially available, State of Alaska must employ automated rather than manual encryption key management processes. | The intention of this policy is to save State of Alaska money and time, as well as to obtain the most effective security system available. For some encryption systems (particularly those which are "home-grown"), there are no applicable commercially-available key management systems. But recent commercial offerings include a number of strong key management systems, such as those available from Information Resource Engineering of Baltimore, MD. Key management is very complex, and as such should be automated to reduce the probability of human error. Automation also reduces the probability of accidental key disclosure to unauthorized persons. Some organizations may wish to put the word "standard" into the policy to ensure interoperability with other key management systems. See the policies entitled "Explicit Assignment of Encryption Key Management Functions" and "Encryption Key Management Systems and Separation of Duties." A: T; E: MH. |
| 91.0 | Maximum Life of Encryption Keys | Whenever encryption is used to protect State of Alaska data, the keys must be changed at least every six months. | The intention of this policy is to force periodic changes in encryption keys. Changing the keys more rapidly will increase the security of an encryption system. If an adversary is able to derive a particular encryption key through cryptanalysis, they must start from the beginning whenever the key is changed. See the policy entitled "Stated Life for All Encryption Keys" |
| 92.0 | Encryption Keys Must Not Be Re-used. | When changing an encryption key a previous key must not be used. | This policy is intended to make it clear that the people handling keys generate a new key. This policy should not be confused with the policy "Maximum Life of Encryption Keys" which states how frequently keys should change. For related the policy entitled "Maximum Life of Encryption Keys" |
| 93.0 | Process for Generating Encryption Keys | Whenever encryption is used, the keys employed must be generated by means which are not practically replicateable by an adversary, and which will yield keys that are difficult-to-guess. An example of this key generation process is the use of a pseudo-random number generator which takes the low order bits of the computer clock as input. | The intention of this process is to ensure that encryption systems provide all the security they are meant to provide. If encryption keys are easily guessed, then the security provided by encryption systems may be easily compromised. For example, if users choose their own encryption keys, a guessibility-related screening process is recommended. This policy is a derivative of a policy regarding so-called "weak keys" for the Triple Data Encryption Standards (3DES); certain weak keys make 3DES cryptanalysis quite easy and these keys must accordingly be avoided. Often the key generation process is part of an automated key management process Also see the policies entitled "Minimum Length for User-Chosen Encryption Keys" |
| 94.0 | Minimum Length for User-Chosen Encryption Keys. | Whenever user-chosen encryption keys are employed, the encryption system must prevent users from employing keys made up of less than eight (8) characters. | Like the policy entitled "Process for Generating Encryption Keys," the intention of this policy is to make sure that an encryption system provides the security it was meant to provide. If encryption keys are easily guessed (because they are made up of too few characters), then an encryption system can be readily compromised. This policy is targeted at users who need to encrypt data on their computer system and does not apply to encryption of network traffic. For a related idea, see the policy entitled "Minimum Password Length." |
| 95.0 | Protection for Encryption Key Generation Materials | Whenever encryption is used, materials to develop encryption keys as well as hardcopy versions of keys must be kept locked when not in use. Protective measures to prevent these keying materials from falling into the wrong hands must be observed throughout the life cycle of the information protected by the keys. | The term "keying materials" is used to refer to data encryption keys, keys which encrypt other keys (master keys), initialization vectors (IVs), pseudo-random number generator seeds, and other parameters used to control or initialize encryption processes. The intention of this policy is to prevent the parameters used to construct encryption keys from falling into the wrong hands, and then being used to construct or intelligently-guess encryption keys. As soon as possible after their use, these keying materials should be destroyed according to approved procedures for most sensitive information (shredding, burning, etc.). For more on this, see the policy entitled "Destruction of Encryption Key Generation Materials." |
| 96.0 | Protection for Plaintext Encryption Master Keys | Only two approaches for protecting plaintext (readable) master keys are acceptable to the State of Alaska. Master keys may be manually handled via dual control with split knowledge. Alternatively, they may be stored in tamper-proof modules. In all other places, they must appear only in encrypted form. | This policy specifies the permissible ways to protect the keys at the top of a hierarchy of keys -- the most sensitive type of encryption keys. Master keys are used to encrypt all other keys, or at least encrypt keys which in turn encrypt other keys. If a master key is revealed, an entire encryption system can quickly be compromised. Accordingly, significant efforts are needed to prevent these keys from falling into the wrong hands. When in readable form, master keys must be chopped into segments (components), each of which does not reveal the original master key (also known as "split knowledge"). Alternatively, they may be stored in hardware modules which will automatically erase the keys if someone tampers with the module. For related ideas, see the policies entitled "Protection for Encryption Key Generation Materials" and "Encryption Key Management Systems and Separation of Duties." |
| 97.0 | Destruction of Encryption Key Generation Materials | All supplies used for the generation, distribution, and storage of keys must be protected from disclosure to unauthorized persons. When they are not longer needed, they must be destroyed by pulping, shredding, burning, or other methods approved by the Agency Computer Security Officer. | The intention of this policy is to prevent unauthorized parties from obtaining access to the information used to generate, distribute, or store encryption keys. This might allow these parties to obtain copies of the keys, which in turn would allow them to obtain the sensitive information protected with encryption. The policy also serves to make workers aware that these materials are sensitive and that they should be handled with care. See the policy entitled "Protection for Encryption Key Generation Materials ." |
| 98.0 | Time Frame for Destruction of Key Exchange Material | Custodians of key exchange material must destroy this material according to approved procedures within a reasonable time -- not to exceed ten business days -- following the successful verification of a key exchange process. | The intent of this policy is to clearly specify when custodians of keying materials (master keys, encryption key components, initialization vectors, random number generator seeds, etc.) must destroy the keying materials they have received. The smaller the amount of time that these materials exist outside the system, and the fewer the number of people that have them, the more secure the encryption process will be. While the key management process is increasingly being automated, there are still many encryption systems where manual key loaders and other technology requires human involvement. It is for those manual situations that this policy was intended. |
| 99.0 | Prevention of Unauthorized Disclosure of Encryption Keys | Encryption keys must be prevented from unauthorized disclosure via technical controls such as encryption under a separate key or use of tamper-resistant hardware. | The intention of this policy is to specify that measures must always be taken to prevent the unauthorized disclosure of encryption keys. If encryption keys are disclosed, the security of encryption systems is in most instances defeated (assuming the algorithm and implementation are public knowledge, which they are with the Triple Data Encryption Standard (3DES)). Tamper resistant hardware prevents people from opening it to recover the encryption keys stored inside. |
| 100.0 | Transmission of Cleartext Private Encryption Keys Prohibited | If private encryption keys are transmitted over communication lines, they must be sent in encrypted form. The Public key in a Public Key Encryption System must not be encrypted. The encryption of keys should be performed with a stronger algorithm than is used to encrypt other sensitive data protected by encryption. | The intention of this policy is to prevent users from inadvertently sending readable (cleartext) encryption keys over communication systems. If this is done, then the encryption process (depending on the type of system) may be easily circumvented. Note that the second sentence is a guideline and not a policy (the word "should" is used rather than "must"). For example, if the organization in question is using a standard "symmetric" encryption algorithm, such as the Triple Data Encryption Standard (3DES), implementation of the guideline in the second sentence would be straightforward. |
| 101.0 | Storing Encryption Keys on Same Media as Protected Data Prohibited | If encryption is used to protect sensitive data resident on computer storage media, the encryption keys and related encryption keying materials (initialization vectors, time-and-date stamps, salt parameters, etc.) used in the encryption process must not be stored anywhere on this storage media in unencrypted form. | The intention of this policy is to prevent an astute cryptanalyst from noticing that the keying materials are stored on the same data storage media as encrypted data. Surprising as it may seem, several commercial encryption packages use this approach, which of course may be quickly circumvented. Use of hidden files or hidden directories for the unencrypted storage of these keying materials is not acceptable. To put both the keying materials and the encrypted data on the same media is like using tape to affix a front door key to one's front door. |
| 102.0 | BIG QUESTION???? Stored File Encryption Systems Must Include Key Escrow | All encryption processes used to encrypt files stored on State of Alaska information systems must include key escrow functions. These special functions allow State of Alaska management to recover encrypted information should there be system errors, human errors, or other problems. | The intent of this policy is to require encryption systems used for regular business activities to employ a system with key escrow. This is targeted at encryption used for long term file storage and is not intended for transient encryption processes used in data communications. Basically key escrow allows management (or some other trusted party) to decrypt files when and if needed. A secure process (known as escrow) is needed to ensure that data can be decrypted under any circumstances. This may be required in the event of emergencies, staff unavailability, personnel disputes, or criminal investigations. Without key escrow features, management runs a significant risk that an encrypted file cannot be read should the holder of the key be unavailable. In the case of archived files, it is important to maintain the keys should the archived files be needed later. Note that the policy does not address encryption processes embedded in information systems, such as the encryption used in an SSL web browser session. It only deals with "general purpose encryption systems," not special purpose encryption systems like those which do digital signatures, password encryption, and the like. |
| 103.0 | Required Procedures for Personal Computer Modems in Autoanswer Mode | Users must not leave modems connected to personal computers in autoanswer mode without Agency Computer Security Officer review and authorization. | Modems left in auto-answer mode expose the organization to unauthorized visitors, especially when these modem connections have no access control system. This problem is particularly serious if the PC is connected to an internal network. Rather than prohibiting the use of modems, or even requiring the use of dynamic password systems, this policy relies on the awareness and judgement of the ACSO to approve and monitor the useage of auto-answer modems. See also "Dial-Up Connections Must Utilize an Access Control Point" |
| 104.0 | Privacy Expectations and Electronic Messaging, such as E-Mail and Voice Mail | Workers must treat electronic messages and files as private information. Electronic mail must be handled as a private and direct communication between a sender and a recipient. | The intention of this policy is to clearly specify what type of privacy workers should expect when it comes to electronic mail and other electronic messaging systems such as voice mail and pagers. A clear understanding of the privacy they can expect will enable users to make appropriate decisions about the types of information to send via electronic mail. This policy does not address matters such as looking at messages in order to support the administration of an electronic mail system. Such message examination would be fully in keeping with this policy so long as the intention was to maintain or administer the system, and not to violate another's privacy. The words "messages and files" in the policy make it apply to messages in transit, messages that have not yet been read that are stored in a holding file, and messages that have been read and archived. Also see the policy entitled "Monitoring of Electronic Mail Messages," |
| 105.0 | Treat Electronic Mail as Public Communications | Consider electronic mail to be the electronic equivalent of a postcard. Unless the material is encrypted, users must refrain from sending credit card numbers, passwords, research and development information, and other sensitive data via electronic mail. | The intention of this policy is to impress users with the fact that their electronic mail communications are not protected the way an ordinary letter going through the postal service is. Unknown parties can readily intercept e-mail and use the contents as they please, without either the sender's or the recipient's knowledge. The policy also alerts users to the primary mechanism to secure e-mail communications: encryption. |
| 106.0 | Profane, Obscene or Derogatory Remarks in Electronic Mail Messages | Workers should not use profanity, derogatory remarks, obscenities, or harassing, embarrassing, indecent, intimidating or other unethical remarks in electronic mail messages. Such remarks -- even when made in jest -- may create legal problems such as defamation of character. Special caution is warranted because back-up and archival copies of electronic mail may actually be more permanent and more readily accessed than traditional paper communications. | Many users consider electronic mail to be more informal than traditional paper letters. This can lead to the inclusion of obscenities or derogatory comments that would not have been included in a paper letter. This policy is intended to put workers on notice that their electronic mail may come back to haunt them, and be a legal problem for their employer. The policy also indirectly discourages "flaming," the practice of venting negative emotions via electronic mail (as well as other ways to communicate such as Internet chat rooms). |
| 107.0 | Telecommuter Remote System Information Security Procedures | As a condition of continued employment, telecommuters agree to abide by all remote system security procedures. These include, but are not limited to, compliance with software license agreements, performance of regular back-ups, and anti-virus software. | The intention of this policy to make telecommuters aware of the procedures they must perform on a day-to-day basis. If an agency is going to permit its sensitive information to be used in remote locations that cannot be easily supervised, it is reasonable for it to insist that certain security precautions be observed. Because telecommuting introduces new risks, a more stringent and specially-documented policy dealing with telecommuters may be set by the Agency Computer Security Officer on a case by case basis. This policy is also appropriate for workers which are not -- properly speaking -- telecommuters, but who nonetheless take organizational information to their home or on business trips. |
| 108.0 | Right To Conduct Inspections of Telecommuter Environments | State of Alaska maintains the right to conduct inspections of telecommuter offices with one or more days advance notice. | The intention of this policy is to put telecommuters on notice that State of Alaska representatives may conduct inspections of their home offices. This will help ensure that telecommuters observe both safety and security policies and procedures. In return for permitting employees to telecommute, State of Alaska has the right to conduct inspections of its property kept in the houses of telecommuters. Thus, by conducting inspections, State of Alaska management is carrying out it's duty to protect State of Alaska assets. It is only because the home is generally the domain of the employee that such a right to inspect must be clearly communicated and/or negotiated. The policy allows multiple follow-up inspections to correct deficiencies that were detected during prior visits. |
| 109.0 | Internet Access With State Computers Must Go Through a Firewall | Internet access using computers inside State of Alaska offices is permissible only when users go through a State of Alaska firewall. Other ways to access the Internet, such as dial-up connections with an Internet Service Provider (ISP), are prohibited if the connected computer is also attached to a State of Alaska network. | This policy prevents users from deliberately or unwittingly circumventing the controls supported by a firewall. These controls include the ability to: screen down-loaded files for viruses, scan down-loaded files for keywords, bar the connection with certain web sites, and block the down-loading of Java applets. The policy is restricted to computers in State of Alaska offices because telecommuters and mobile computer users cannot practically live up to the requirements of this policy. There may be circumstances where technicians or users need to test equipment or an ISP, however this must be done from a computer that is not connected to a State of Alaska network. For a related idea, see the policy entitled "Permissible Internet Access Without Firewalls." |
| 110.0 | Required Reporting of Information Security Incidents | All suspected information security incidents must be reported as quickly as possible to the Agency Computer Security Officer. | This policy is intended to require that all problems and violations are promptly brought to the attention of those who can actually do something about them. If problems and violations go unreported, they may lead to much greater losses for the organization than would have been incurred, had the problems been reported right away. Also see the policies entitled "Internal Reporting of Information Security Violations & Problems," and "Information Security Alert System" |
| 112.0 | Centralized Reporting of Information Security Problems | All known vulnerabilities -- in addition to all suspected or known violations -- must be communicated in an expeditious and confidential manner to the State Computer Security Officer. Unauthorized disclosures of State of Alaska information must additionally be reported to the involved information owners. Reporting security violations, problems, or vulnerabilities to any party outside State of Alaska (except external auditors) without prior written approval from the remarks is strictly prohibited. | This policy is intended to establish that the State Computer Security Officer is the focal point for all reports of vulnerabilities, violations and other security problems. Unless there is centralized reporting, no loss history can be compiled, no loss analysis can be conducted, and no related decision-making can be performed. Centralized reporting is also useful for the mobilization of a computer emergency response team (CERT), an organization-wide contingency plan, and other important defensive resources. The policy is also helpful because it alleviates the reporting party's concerns about short-circuiting the chain of command; without a policy like this, local managers may get upset because problem reports make them look bad and they didn't get a chance to stop the reporting process from reaching top management. The policy is also helpful because it indicates what needs to be communicated and to whom. |
| 113.0 | Interference with Reporting of Information Security Problems | Any attempt to interfere with, prevent, obstruct, or dissuade a staff member in their efforts to report a suspected information security problem or violation is strictly prohibited and cause for disciplinary action. Any form of retaliation against an individual reporting or investigating information security problems or violations is also prohibited and cause for disciplinary action. | This policy attempts to encourage workers who wish to report an information security problem or violation, yet are concerned that they may find it difficult, problematic, or otherwise ill-advised. These "whistle blowers" often are concerned that their own immediate management will penalize them for reporting problems or violations. This policy attempts to foster a perspective that is in the best interest of the State of Alaska that all security problems be reported and that it is against this policy for anyone to interfere with the reporting, even if the report may make someone "look bad". |
| 114.0 | Protection of Workers Who Report Information Security Problems | State of Alaska will protect workers who report in good faith what they believe to be a violation of laws or regulations, or conditions that could jeopardize the health or safety of other workers. This means that such workers will not be terminated, threatened, or discriminated against because they report what they perceive to be a wrongdoing or dangerous situation. Before taking any other action, these workers must report the problem to their manager or the Agency Computer Security Officer, and then give the organization time to remedy the situation. | The intention of this policy is to assure workers who are considering reporting problems that the organization will protect them. This should encourage workers to make reports when they may otherwise have been deterred by the potential adverse consequences. This policy does not prohibit external reporting -- it only states that the problem should first be internally reported. The policy is deliberately defined in a broad manner so that it includes information security problems; it also includes physical security problems as well as worker safety problems. For a related idea, see the policy entitled "External Reporting of Information Security Violations." |
| 116.0 | Immediate Reporting of Suspected Computer Virus Infestation | Computer viruses, worms, trojans and other malicious code can spread quickly and need to be eradicated as soon as possible to limit serious damage to computers and data. Accordingly, if workers report a computer virus infestation to the Agency Computer Security Officer immediately after it is noticed, even if their negligence was a contributing factor, no disciplinary action will be taken. The only exception to this early reporting amnesty will be those circumstances where a worker knowingly caused a computer virus to be introduced into State of Alaska systems. However, if a report of a known infestation is not promptly made, and if an investigation reveals that certain workers were aware of the infestation, these workers may be subject to disciplinary action. | This policy is intended to encourage quick reporting of viruses, which is essential if their growth is to be limited and consequential losses are to be contained. A notable aspect of the policy is that disciplinary action may be taken if there is a delay in reporting a problem. Because even minutes can make a great difference when it comes to the propagation of computer viruses, the word "immediately" was used in the policy. Of course, if a worker has written a virus and let it loose on State of Alaska computers, then this should still be cause for disciplinary action, even if the employee did call the Information Security Department promptly after it got out of hand. The policy, as written, does not stop such a disciplinary action because it refers to "negligence" rather than a deliberate malicious act. Also see the policies "Testing for Viruses Prior to Use on State of Alaska Systems" and "Internal Reporting of Information Security Violations & Problems." |
| 117.0 | Required Investigation Following Computer Crimes | Whenever evidence clearly shows that State of Alaska has been victimized by a computer or communications crime, a thorough investigation must be performed. This investigation must provide sufficient information so that management can take steps to ensure that: (1) such incidents cannot reasonably take place again, and (2) effective security measures have been reestablished. | This policy is intended to make sure that appropriate action is taken in response to computer or communications system crimes. Too often there is an inclination to "sweep" the whole affair "under the rug." To prevent the potential supression of information about vulnerabilities (often because it could be embarrasing to someone), this policy requires that an investigation be started. In most instances, department and other local management will not have the expertise to carry out such a sophisticated investigation. Thus, the policy indirectly requires these managers to contact the Agency Computer Security Officer and the State Computer Security Officer. The policy also helps guard against lawsuits alleging that management did not take care of problems even though they were "on notice" that security problems existed. Also see the policy entitled "Confidentiality of Internal Investigations Information" |
| 118.0 | Retention of Information Security Violation and Problem Information by the State Computer Security Officer | Information describing all reported information security problems and violations must be retained for a period of three (3) years. | The intention of this policy is to put everyone on notice that certain important information security related information must not be destroyed. The information referred to in the policy is helpful when doing risk assessments, when planning information security projects, and when developing budgets. It may also be useful for prosecution or disciplinary actions. The policy applies to computer logs and internal correspondence, as well as notes from investigations. Also see the policies entitled "Annual Analysis of Information Security Violations & Problems" and "External Reporting of Information Security Violations." |
| 119.0 | Annual Analysis of Information Security Violations & Problems | An annual analysis of reported information security problems and violations must be prepared by the State Computer Security Officer. | The intention of this policy is to require the State Computer Security Officer to prepare a status report of losses and problems encountered. Such a historical analysis is helpful when performing risk assessments, when preparing job performance evaluations, and also when preparing budgets and project plans for the coming year. Although it may sound like more work for often-overworked information security staff, this policy can help establish and maintain a regular communication path with top management. Notice that the methodology for performing such analyses is not mentioned so as to give the Security Officer the leeway to change its approach as it becomes more sophisticated. Items that at a minimum must be reviewed include: User Authentication; Incidents such as virus infestation; Security problems with vendors. Specific information that could assist hackers, such as IP address or open ports, should not be included in the annual report if the report is to be made public. Also see the policies entitled "Required Investigation Following Computer Crimes" and "Retention of Information Security Violation & Problem Information." |
| 120.0 | Information Security is Overhead, Not a Charge-Back Item | Information security products and services are provided through Administration overhead budgets, and must not be charged-back to each agency. | This policy is intended to encourage the allocation of sufficient funds for information security within the State of Alaska. When charge-back systems are used to transfer the costs for information security, all too often unit managers will decide to reduce or eliminate information security. This is not a serious problem if each unit has independent and unconnected information systems, but if they are connected via a network (as they increasingly are), consistency is absolutely required if adequate security is to be achieved. Thus, by providing a central overhead budget, the compliance with internal information security standards is significantly enhanced. Separate organizational units can still go their own way with special approval -- if they wish to pay for custom systems. This policy helps ensure that all units have sufficient controls, no matter what their budget. This policy addresses one of the organizational design issues that often conspires to render information security ineffective, impotent, and/or irrelevant. |
| 122.0 | delete delete delete Overview of Tasks Performed by Computer Security Officers, both State and Agency | The Computer Security Officers are responsible for establishing and maintaining organization-wide information security policies, standards, guidelines, and procedures. The focus of these activities is on information, no matter what form it takes, no matter what technology is used to handle it, no matter where it resides, and no matter which people possess it. | One intention of this policy is to make it clear that the Computer Security Officers have organization-wide responsibility. Another intention is to clearly emphasize that the Computer Security Officers focuses on information per se, not on computers (it should no longer be called the "Computer Security Department"). Although it may organizationally report to the Chief Information Officer (CIO) of a large subsidiary or the Director of the Information Technology Department, the Information Security Department needs to be clearly seen as an authority throughout the organization. Another purpose of this policy is to clearly communicate to workers what the Information Security Department actually does. Many workers have an erroneous view that the Information Security Department will do everything related to information security, and that they need not be involved. The tasks outlined in the policy should be modified to reflect the organizational structure and design at State of Alaska. For example, the policy could be expanded to include investigations, compliance review, and other activities. Some organizations would prefer to put the material found in this policy in a mission statement (or charter) rather than a policy. Also see the policies entitled "Centralized Responsibility for Information Security," "Information Security is Every Worker's Duty," "Information Security Department Mission Supports State of Alaska Goals," and "Specific Tasks Performed by the Information Security Department." A: E; E: LMH. |
| 123.0 | Specific Tasks Performed by the Computer Security Officers, both State and Agency | The Computer Security Officers must provide the direction and technical expertise to ensure that State of Alaska's information is properly protected. This includes consideration of the confidentiality, integrity, and availability of both information and the systems that handle it. The Officers will act as liaisons on information security matters between all State of Alaska entities, and must be the focal point for all information security activities throughout the State of Alaska. The Officers must perform risk assessments, prepare action plans, evaluate vendor products, participate with in-house system development projects, assist with control implementations, investigate information security breaches, and perform other activities which are necessary to assure a secure information handling environment. | The intention of this policy is to provide specific information about the responsibilities of the Computer Security Officers. Because information security is a new field, many workers will be unclear about the duties of and the contribution to be made by an Information Security Department. This policy can help to eliminate arguments about and focus the work of the Computer Security Officers. |
| 124.0 | Annual Information Security Planning Process Required | Working in conjunction with the responsible management, the Information Computer Security Officers must annually prepare plans for the improvement of information security on all major State of Alaska information systems. | The intention of this policy is to require Agency Computer Security Officers and the State Computer Security Officer, to annually prepare a formal plan for improving information security. So much of the work in the information security field is "putting out fires" (handling urgent problems) that information security people need to periodically step back and take another look at what is now being done and what should be done. In other words, this policy requires that staff focus on what's important, not just what's urgent. Separately, this policy communicates that not only should information security people prepare the annual plan, but management should also participate. The policy also indirectly supports the periodic performance of a risk assessment (risk analysis); without specific knowledge of the current risks and vulnerabilities, an organization cannot prepare information security plans that truly respond to its unique business needs. Also see the policies entitled "Preparation and Maintenance of Computer Disaster Recovery Plans," "Preparation and Maintenance of Computer Emergency Response Plans," and "Annual Analysis of Information Security Violations & Problems." |
| 125.0 | Designated Agency Computer Security Officer | Every State of Alaska entitiy that maintains a computer network must have a designated Security Officer. The Security Officer is responsible for defining user privileges, monitoring access control logs, coordinating with the State Computer Security Officer and performing similar activities. | The intention of this policy is to make sure that a specific person is designated as the one responsible for security. When it is not clear who is responsible for security, often security tasks get neglected, and as a result the organization is unduly exposed to various problems. All computer systems that handle sensitive, critical, or valuable information should have some sort of access control system. Most often this will involve fixed passwords, but other technologies may also be used. There is no requirement that security officers do their job full-time; part-time security officers are often used in smaller organizations or for those systems which are managed by departments or other decentralized organizational units. Also see the policy entitled "Designated State Computer Security Officer." |
| 126.0 | delete delete delete Back-Up Security Administrator Must Be Designated and Trained | Every multi-user State of Alaska system with an access control system must have a designated employee who is responsible for user-ID assignment and user access privilege control. This systems administrator must also have a designated and trained back-up employee who can fill-in when necessary. | This policy is intended to prevent awkward situations where a security administrator does not have a designated and/or trained back-up person, in which case business activity may be impaired or interrupted. Separately, if a back-up administrator is ready to fill-in for a regular administrator, then it is unlikely that security systems will need to be compromised in order to continue necessary business activity. Note that both the regular and the back-up persons should be employees; this is because employees are generally more loyal and most often have a longer tenure with State of Alaska than contractors, consultants, temporaries, and the like. Furthermore, this policy can be used to obtain both necessary staffing and training resources. On another note, this policy assumes that the words "access control system" have been defined elsewhere; generally these words mean a fixed password user identification system with associated user access privilege controls, but many other options such as dynamic password tokens are also available. Also see the policy entitled "Designated Security Administrator for All Multi-User Systems." A: T; E: LMH. |
| 127.0 | The State Computer Security Officer Must Maintain and Update the State of Alaska Security Policy | The State Computer Security Officer must prepare, maintain, and disseminate the State of Alaska Security Policy which concisely describes State of Alaska information security policies. | The objective of this policy is to require the State Computer Security Officer to prepare and maintain the security policies of the State of Alaska. Without specific policies on information security, the State may have a difficult time securing it's networked data systems. Likewise, without specific written policies, the authority to conduct awareness and training efforts may be problematic. The State Computer Security Officer must ensure that all State of Alaska computer users are aware of and have convenient access to any necessary materials required to maintain information security. |
| 128.0 | Involvement of Agency Information Security staff | All information security problems must be handled with the involvement and cooperation of Agency information security staff. The use of external consultants, computer security response teams, or other outsiders is specifically prohibited unless these have been approved by the State Computer Security Officer. | This policy helps keep security problems inside the organization, lessening the probability that they will become known to unauthorized parties. The policy also fosters the use of the in-house information security group rather than alternative suppliers of information security services. It thus keeps costs down and also assures that in-house policies, standards, methods, and the like will be consistently applied. Although this policy does not require that all work be done by a central in-house information security group, it does require the group's approval. Outsourcing is therefore still an option, particularly when there are not enough in-house staff members to handle a certain project. |
| 129.0 | Designated State Computer Security Officer with Uncontested Statewide Authority | The State of Alaska must establish and support a Computer Security Officer placed in the organizational structure in such a position that they have the authority to enforce security policies and oversee information security practices. | The intention of this policy is to ensure that the State Computer Security Officer can be effective. The State Computer Security Officer must have uncontested authority over information security issues. This position must be more than a figurehead with no real authority. The policy is particularly important as the duties of the Agency Computer Security Officers are typically assigned on a part-time basis to workers performing other functions. The State Computer Security Officer must work with the Agency Computer Security Officers, support their activities and provide technical guidance. Other duties typical of the State Computer Security Officer are to prepare annual reports, coordinate the response to incidents, act as a central spokesperson to the user community on information security issues, and coordinate the flow of information among Agency Computer Security Officers. Also see the policy entitled "Designated Agency Computer Security Officer." |
| 130.0 | Security Responsibilities for Real-Time Connections with Third Parties | Before any third party users are permitted to reach State of Alaska systems via real-time computer connections, specific written approval of both the State Computer Security Officer and the Agency Computer Security Officer is required. Requests for approvals must specify the security related responsibilities of State of Alaska, the security related responsibilities of the common carrier (if used), and the security related responsibilities of all other involved third parties. These responsibility statements must also address the liability exposures of the involved parties. | The purpose of this policy is to prevent real-time (as opposed to store-and-forward) connections of State of Alaska systems with third parties unless these have been shown to be adequately secure. This policy would for instance prevent consultants form having access to confidential data unless security issues had previously been examined, and approved controls had been properly implemented. Only after clearly specifying security responsibilities can the State of Alaska determine whether they want to accept the risks that the connection presents. The policy would allow internal users to employ out-bound dial-up systems to access third party electronic mail services and on-line database retrieval services without the need for a security evaluation and approval process. This policy would also allow Internet electronic mail connections because these are store-and-forward (not real-time) connections. Also see the policy entitled "Internet Connections Require Approved Firewalls." |
| 131.0 | Extended User Authentication Systems Required for In-Bound Access to State of Alaska Computer Systems. | To positively identify the calling party, all in-bound connections to State of Alaska's internal computer data network must employ extended user authentication. The approved technology for extended authentication must provide more security than traditional fixed password systems. The specific technology selected for extended user authentication will change over time but must be approved by the Agency Computer Security Officer. | The intention behind this policy is to require extra system access controls for every inbound connection, such as dial-up modems or broadband connections over the Internet. Since these interface points have historically been vulnerable spots, extra access controls are warranted. Extended user authentication systems are most often used in conjunction with user-IDs and passwords, although they may also replace user-IDs and/or passwords. These extended user authentication systems include but are not limited to call-back devices, identity tokens, biometrics (thumb-print readers, retina scanners, voice print readers, etc.). |
| 132.0 | Changing Physical Access Control Codes on Worker Termination | In the event that a worker is terminating their relationship with the State of Alaska, all physical security access codes known by the worker must be deactivated or changed. For example, the serial number recorded on a magnetic stripe attached to an identification badge must be changed before the badge is reissued to another worker. | This policy is intended to eliminate any confusion about the identity of the person who is using an access code. The policy may also prevent a terminated worker from using a copy of the access mechanism (like a magnetic card) to gain unauthorized entry to State of Alaska work areas. This objective is particularly important if the worker is disgruntled and potentially vengeful. The policy makes mention of "access codes known by the worker," and accordingly includes both those systems where the code is known only by the user as well as those systems where several people know the code (also known as "lockwords"). This broad scope implies another objective of the policy--to keep the terminated worker from gaining access to State of Alaska premises, and committing some crime or abusive act, in a manner that might look like it was perpetrated by an authorized worker. |
| 133.0 | Internal Network Addresses Must Not Be Publicly Released | The internal addresses, configurations, and related system design information for State of Alaska networked computer systems must be restricted such that both systems and users outside the internal network cannot access this information without explicit management approval. | This conservative policy seeks to prevent hackers and other unauthorized parties from obtaining information about State of Alaska's internal network and connected systems. The idea behind this restriction is that attacks will be made significantly more difficult if this information is not readily obtainable. The more that an attacker knows about internal configurations the greater the chances that they will be able to obtain unauthorized entry. With many Internet firewalls, internal electronic mail address information is shared with machines outside the network, inadvertently revealing a target for future attacks. This policy also requires that system administrators responsible for firewalls establish access control restrictions such that commands like PING cannot be used by external parties to gather information on machines connected to the internal network. Also see the policy entitled "Release of Systems Documentation to Third Parties" |
| 134.0 | ?????????????? Encryption Key Management Systems and Separation of Duties | [we are not sure how this can work in the SOA/ACS network or with modern tech] State of Alaska encryption systems must be designed such that no single person has full knowledge of any single encryption key. This must be achieved by separation of duties and dual control. Separation of duties refers to use of more than one individual to handle a certain important activity, while dual control means that two people must be simultaneously present for an important activity to be accomplished. | The intention of this policy is to prevent any one individual from gaining access to a full encryption key. If a full encryption key was held by any one individual, then this individual could (depending on how the encryption system was set-up) decrypt other keys and/or decrypt sensitive information. This could lead to fraud, sabotage, privacy invasion and other problems. By breaking keys into components such activities are then not possible without collusion. Breaking keys into components usually involves creating two bit strings, which when combined via an exclusive-OR operation yield a production encryption key. This entire process is often automated via hardware called "key loaders." The notions described in this policy can be also applied to passwords, initialization vectors, pseudo-random number generator seeds, and other parameters used in security-related processes. See the policies entitled "Separation of Duties and Control Over State of Alaska Assets" and "Protection of Password Generation Algorithms." A: T; E: MH. |
| 135.0 | Tools Used to Break Systems Security Prohibited | Unless specifically authorized by the State Computer Security Officer, State of Alaska workers must not acquire, possess, trade, or use hardware or software tools that could be employed to evaluate or compromise information systems security. Examples of such tools include those which defeat software copy-protection, discover secret passwords, identify security vulnerabilities, or decrypt encrypted files. This policy applies to all State of Alaska computer systems, premises and devices connected to any State of Alaska network system. | Because these tools can be and often are used to circumvent controls, their possession and use should be severely restricted. Possession and use should be allowed only for those who have a need for such powerful tools, such as EDP auditors and tiger-team staff (penetration attack team members). While these tools are readily available on the open market, on the Internet, and on electronic bulletin boards, State of Alaska users should not be in possession of these tools in such a way that they could be used to compromise any State of Alaska system. Thus, ordinary users should not have a collection of vulnerability identification tools like SATAN and COPS stored on their hard drive at work. Likewise, users should not have a Sniffer(TM) in their possession because it can be used to perform a wiretap. For the same reason, users should not have a database which contains working serial numbers needed to operate stolen software. Some users may claim that they never intended to use such tools, that they only acquired them to learn about computers. This policy removes the whole question of the user's intent from the discussion; if users have the tools, they are in violation of the policy. Note that this policy does not prohibit an employee from using such tools on a home computer unless that computer is configured to access any State of Alaska data system. The policy is not intended to prohibit any authorized user from accessing State of Alaska web or e-mail services. Also see the policies "Prohibition Against Testing Information System Controls," "Disclosure of Information About Information System Vulnerabilities." |
| 136.0 | Naming Standard for a Single User-ID Used on All Platforms | No matter how many systems they access, State of Alaska workers must have only one computer system user-ID. Unless advance permission from the State Computer Security Officer has been granted, all computer system administrators must consistently observe the user-ID naming standards specified by the State of Alaska Security Policy. | The intention of this policy is to simplify both administrative and security work for networked computer systems. A significant number of different user-IDs for a single individual can lead to great confusion. This confusion is particularly undesirable at the time that a worker leaves the organization, in which case staff may scramble to determine which user-IDs need to be deactivated. The policy simplifies these activities, as well as forensic activities like log analysis associated with computer crime investigation. A consistent approach to user-ID construction may, in some instances, be impossible if the technology does not allow it (for example some systems allow only a few characters in user-IDs); it is in recognition of these circumstances that exceptions are mentioned in the second sentence of the policy. This policy takes a strong stand in favor of the existing State of Alaska enterprise e-mail ID. Note also that this policy will facilitate the establishment and administration of a single sign-on system. See the policies entitled "Unique User-ID and Positive User Authentication Required," "Maintenance of Master User-ID and Privilege Database." |
| 137.0 | Confidentiality of Internal Investigations Information | Until charges are pressed or disciplinary action taken, all investigations of alleged criminal or abusive conduct must be kept strictly confidential to preserve the reputation of the suspected party. | Beyond the objective stated in the policy, this policy helps reduce the probability that State of Alaska will be hit with a lawsuit alleging defamation of character. The intention of the policy is to clearly define the point in time when it becomes permissible to disclose information about employee investigations. One desirable aspect of this policy is that investigations which do not result in prosecution (pressing charges) or disciplinary action will never be disclosed (declassified). If the employee never knew about the investigation, then they can remain as a worker in good standing. On the other hand, if the employee heard about an investigation in process that later turned out to be inappropriate, they may become disgruntled or soon leave the organization. The policy mentions the "reputation" of the individual rather than staying out of legal trouble because the dignity of the individual is a more noble goal, and because it is taken for granted that management wants to operate within the confines of the law. Also see the policy entitled "Required Investigation Following Computer Crimes." |
| 138.0 | Install And Monitor Intrusion Detection Systems | To allow the State of Alaska to promptly respond to attacks, all primary ingress points from the Internet to the State network must be running an intrusion detection system approved by and implemented with the concurrence of the State Computer Security Officer. | The term "primary" refers to the major connections that carry the bulk of legitimate traffic to and from the Internet. Intrusion detection systems are different from vulnerability identification systems. The former provides an alert system telling staff when the defenses have been breached. The latter tells staff what needs fixing in order to bolster the defenses. Typically an intrusion detection system will feed a network management system (NMS) or some other notification system that will immediately alert those who are in a position to do something. For example, members of a Computer Emergency Response Team (CERT) can get into action based on pager alerts from an intrusion detection system. This policy helps to ensure that all systems on the periphery of an internal network have adequate intrusion detection systems. The State Computer Security Officer is responsible for approving an IDS product and for ensuring that it is installed and implemented in a fashion that protects State of Alaska resources. |
| 139.0 | Assign Explicit Responsibility For Information Security Tasks | Specific information security responsibilities must be incorporated into all worker job descriptions if such workers have access to sensitive, valuable, or critical information. | The time has come to stop saying that information security is everyone's responsibility, but at the same time ignoring the need to specifically assign responsibility to certain people. This policy is intended to create clearity about what is expected of all people who have access to sensitive, valuable, or critical information. Included within the scope of this policy are end-users, who often believe that they have no responsibilities in the information security area. In reality, end-users are on the front line in the battle against intruders, viruses, and other information security problems. Today's information security environment involves the distribution of information not only to end-user desktop computers, but also to workers' homes, to outsourcing firm's premises, to strategic partners' premises, and to other locations. These and other people must cohesively work together as a team in order to achieve genuine information security. This can only be done if the responsibilities of each are explicitly assigned. |
| 140.0 | Encryption of Network Traffic | All Network Traffic that Passes Between State of Alaska Local Area Networks and that Traverse Public Networks Must Employ Strong Encryption. | Portions of the State of Alaska Wide Area Network make use of public networks, such as a telephone utilities lines. The intent of this policy is to ensure that all traffic that could be observed by tools such as packet analyzers is encrypted. While the State can ensure that it’s employees respect the privacy and security of data transmissions, the same cannot be said for unknown Telco employees. Encryption is the only mechanism available to secure data transmitted over lines that the State does not control. Note that this policy specifically calls for encryption, which is not the same as hashing or encapsulating. |
| 141.0 | All security incident information must be tracked by the affected ACSO and forwarded to the SCSO | All security incident related information, such as viruses and hacks, must be tracked by the affected Agency Computer Security Officer. Information gathered by the Agency must be passed along as soon as possible to the State Computer Security Officer. | The intent of this policy is to ensure that all information gathered during a security incident makes it to the central security office. It is important that there be a single point of contact on security that can look for patterns and systemic vulnerabilities. While an individual agency my see a specific security incident as minor, when combined with incidents from other agencies patterns of attack may become clearer. The key here is the need for good communication between the State Computer Security Officer and the various Agency Computer Security Officers. |
| 142.0 | Users may not connect a modem to any phone system on a network-connected machine without authorization. | No computer user may connect a modem to a phone line if the computer with the modem is attached to a State of Alaska computer network without Agency Computer Security Officer approval. | One of the largest potential security holes in the State of Alaska network is the use of uncontrolled modems. If the computer with the modem is on a State network it is possible for a hacker to use the trusted computer with the modem to gain access to State computer resources and data. It is probable that the legitimate user of the computer would appear in security logs as the party performing the hack. This policy is intended to protect both the State of Alaska resources and legitimate State computer users. It is the role of the Agency Computer Security Officer to ensure that any modems in use within their Agency of responsibility conform to the State of Alaska security policies. |
| 143.0 | Restricted Access to Network Traffic Encryption Keys | Access to keys used to encrypt network traffic must be restricted on a need-to-know basis. The State Computer Security Officer must approve all parties who have access to encryption keys. | Encryption is the primary bastion against eavesdropping and wire tapping, particularly in a converged network that will carry both data and voice. The intent of this policy is to prevent the wide spread dissemination of the keys used to encrypt network traffic. It is crucial that only those with an absolutely critical need have access to the encryption keys used on State of Alaska network transport. The State Computer Security Officer must maintain the comprehensive list of those with the encryption keys and approve any change to the list. Any variation from this policy is a dangerous violation of the State of Alaska security policy. |
| 144.0 | Wireless access points will not subject protected State of Alaska networks to unnecessary risk. | Wireless access points shall not be deployed on any protected State of Alaska network in a manner that would expose or otherwise bypass existing security mechanisms of that network. The State Computer Security Officer shall review all wireless networks which have internal connectivity to any State of Alaska network to ensure policy adherence. | This policy is simple in requirement, but complex in administration and implementation. A policy such as this will provide for protecting ALL wireless access points connected to State of Alaska networks. Such protection is necessary as wireless technologies are still continuing to evolve, and Computer Security Officers will have the burden of staying knowledgeable and abrest of changes, vulnerabilities and how to best protect the State of Alaska. See also the policy "Wireless network connections to protected State of Alaska networks must employ encrypted tunnels." |
| 145.0 | Wireless network connections to protected State of Alaska networks must employ encrypted tunnels. | This policy sets forth the necessity of protecting the transmit and receive data streams of wireless network connections by requiring such traffic to take place within encrypted tunnels which meet State of Alaska security standards. | The implementation of such a policy as this is critical in maintaining a set level of security. Without such a policy in place, packet analyzers could be employed to garner knowledge which could be utilized to spoof legitimate clients. This is most notable with the discover of limitations within the WEP (Wireless Equivalency Privacy) protocol in 2001, in which WEP was demonstrated ineffective at providing a private communication link between a client and an access point. By employing encrypted tunnels, such as VPN or other technologies, the State of Alaska ensures that the data streams passing within a communication link between client and an access point cannot be easily intercepted. Also see the policy "Wireless access points will not subject protected State of Alaska networks to unnecessary risk" |
| 146.0 | Agencies will ensure VPN technologies meet State of Alaska Security Policy | The Agency running an encrypted remote login service will ensure that the VPN technology it has deployed meets the requirements set forth by the State Computer Security Officer, for cipher strength, key length, key expiration, key revocation and timeouts. | |
| 147.0 | Remote login connections to State of Alaska networks will utilize a connection timeout. | All remote logins to the State of Alaska networks, i.e. those connections that are not directly and full time on-line with a State LAN, will timeout after a time period specified by the State Computer Security Officer. | This policy is intent upon preventing a remote user from logging into a computer system on a State of Alaska protected network and inadvertently leaving their remote connection active. The Agency or State Computer Security Officer shall ensure that remotely accessible computer systems will employ a watchdog connection timeout to prevent connections from remaining active after they are no longer required. The State Computer Security Officer is responsible for determining the maximum timeout value to be used. |
| 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. |
| 149.0 | All External Connections Reviewed Annually | The State Computer Security Officer will conduct, at a minimum, an annual review of the external connections to the State of Alaska network. Agency Computer Security Officers will provide an accurate listing of all external connections to facilitate the review. This listing will include the agency involved, inception date, any involved third parties, contact information for both, security category of the connection and a brief business justification of why the connection needs to exist. | This policy is intended to apply to external connections provided by the agencies participating in the state’s network arrangements, such as dial-up connections or wireless. A policy such as this can help spur the creation of a comprehensive managed list of external connections. Agency provided external connections are a likely path for unwelcome intrusion. The risk of such connections mandate that the agency not only adhere closely to relevant security policies, but to also initiate practices of diligent, centralized management of such connections. Such practices make annual review a routine but necessary exercise. Under this policy, a violation would be the existence of an undocumented external connection. |
| 150.0 | Restrictions on Tiger Team Activities and Release of Findings | Only the State Computer Security Officer may authorize Tiger Team activities and the release of their findings. | A Tiger Team is a group that attempts to break in to a computer network or otherwise access secured computing services using hacker style techniques. Tiger Team activities, by definition, attempt to compromise security. For this reason it is important that they only be done when necessary and with the authorization of the State Computer Security Officer. It is equally important that any results of a Tiger Team be kept confidential and be released only to the affected Agency Computer Security Officer or others on a need to know basis. |
| 151.0 | Agencies can write their own security policy as long as they are no less stringent than these | An Agency may develop a Security Policy but it must not subject the State to reduced security. | Some Agencies may find that the officially adopted State of Alaska Security Policy is inadequate for their needs. An agency may develop a policy but it is critical that the alternate Security Policy be no less stringent than the official policy. For an Agency to develop and adopt their own Security Policy it must be reviewed and approved by the State Computer Security Officer. |
| 152.0 | Annual Review of Computer Security Officers | An independent third party must perform an annual review of all Computer Security Officers to ensure they are enforcing the State of Alaska security policies and using industry standard best practices. The results of the reviews will be provided to the Commissioner of Administration and are to remain confidential. | The role of Computer Security Officers, both Agency and State, are vital to the implementation of the State of Alaska Security Policy. Security officers are responsible for ensuring the continued functioning of State networks in a secure fashion. An independent review must be performed so that that State can be assured that someone is "watching the watchers". |