| Policy ID No. | Policy | Policy Text | Policy Commentary |
|---|---|---|---|
| 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. |
| 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. |
| 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. |
| 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." |
| 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." |
| 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. |
| 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. |
| 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" |
| 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" |
| 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." |
| 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". |
| 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." |
| 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." |
| 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.). |
| 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. |
| 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. |
| 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. |