<Service/Infrastructure Unit>

<System Name>

Systems Administration Manual

Version <X.X>

<Month DD, YYYY>

Security Category: Moderate

<SYSTEM NAME> SYSTEMS ADMINISTRATION MANUAL<Month DD, YYYY>

Revision History

Revision / Date / Revised By / Notes
N/A / April 29, 2005 / Steve Elky / Created generic procedures for adoption by other system owners.
N/A / February 16, 2006 / Steve Elky / Updated to reflect lessons learned
N/A / March 13, 2007 / Steve Elky / Updated from 3/2007 review of Directives
N/A / April 26, 2007 / Steve Elky / Peer Review comments
N/A / June 4, 2007 / Kyle Hendrickson / Added sample SOPs
N/A / July 30, 2007 / Dawn Thompson / QA & revision.
N/A / August 23, 2007 / Steve Elky, Kyle Hendrickson / Finalized updates
2.0 / December 2, 2015 / Sandy Chou / Replace ITS with OCIO

Table of Contents

1Introduction

1.1Scope

1.2Contacts

1.3Configuration Management of the Systems Administration Manual

1.4Location of this Document

2Operational Processes

3IT Security Related Processes

3.1General IT Security Related Information

3.1.1IT Contingency

3.1.2Hosted Application IT Contingency Plan

3.1.3Security Awareness

3.1.4Rules of Behavior

3.2IT Security Related Processes Performed by System and Application Administrators

3.2.1Account Creation

3.2.2Creating Accounts with Elevated Privileges

3.2.3Temporary and Emergency Accounts

3.2.4Initial Passwords

3.2.5Disabling Accounts

3.2.6Revoking System Access

3.2.7Account Deletion

3.2.8Periodic Account Management Procedures

3.2.9Event Based Account Management Procedures

3.2.10Password Reset Procedures

3.2.11Change Management

3.2.12Patching

3.2.13Information Handling and Dissemination

3.2.14Media Controls

3.2.15Incident Handling (Including Theft)

3.2.16Backup and Restore

3.3IT Security Related Procedures Performed by the ISSO

3.3.1Monitoring

3.3.2Incident Handling

3.3.3Reporting

3.3.4Risk Management

3.3.5Annual Risk Review (Review of Security Controls)

3.3.6Sanitization

3.4IT Security Related Procedures Performed by the System Owner

3.4.1Risk Management

3.4.2Hosted Application IT Contingency Plan Testing

3.4.3Sensitive System Positions

3.4.4Separation of Duties

3.4.5Establishing User Identity

3.4.6Revoking System Access

Involuntary Separation

3.4.7Security Awareness Training

3.4.8License Management

3.4.9Maintenance

3.5IT Security Related Procedures Performed by the Information Owner

3.6IT Security Related Procedures Performed by OCIO

3.6.1Physical Security Controls

3.6.2License Management

3.6.3Maintenance

3.6.4Monitoring

3.6.5Backup and Restore

4Appendix A – Backup Criteria

5Appendix B – Software License & Maintenance Contract Tracking

6Appendix C – Account Management Form

Table of Figures

Figure 1 – Contacts

Figure 2 – Outage Types, Impacts & Recovery Times

Figure 3 – Account Management Recurring Reviews

Figure 4 – Security Patch Tracking

Figure 5 – Program Library Access Control

Figure 6 – Sensitive Positions

Figure 7 – Allowable IT Security Role Combinations

Figure 8 – Personnel Authorized to Perform Maintenance on System by Component

Figure 9 – Backup & Retention Requirements

Figure 10 – Software License/Maintenance Contract Information

1Security Category: Moderate

<SYSTEM NAME> SYSTEMS ADMINISTRATION MANUAL<Month DD, YYYY>

1Introduction

The Systems Administration Manual contains key information and Standard Operating Procedures (SOPs) necessary to maintain the system effectively.The manual provides the definition of the software support environment, the roles and responsibilities of the various personnel, and the regular activities essential to the support and maintenance the system.

Instructions

  1. Perform a search and replace on the following variables contained in this document:
  2. Replace <System Name> with the name of the system this manual applies to
  3. Replace <group name> with the Library group or division that owns the system
  4. Replace <account maintenance utility> with the name of the utility, application or command used to perform account maintenance (e.g., adding accounts, deleting accounts, etc.)
  5. Carefully read and address all the yellow highlighted sections.Yellow highlighted sections contain sample text that must be reviewed and modified or replaced to represent the actual processes used by the system.
  6. Address any instructions.Instructions are highlighted in blue text.
  7. Delete any instructions from the final document.
  8. Note that auditing will be carried out against the procedures contained in this document. Therefore, the System Owner must ensure that the Systems Administration Manual is accurate and that it is followed by the applicable personnel.>

1.1Scope

This Systems Administration Manual covers the <System Name>system.This manual and its processes and procedures are to be used by the <System Name> system administration staff to perform operations in a defined and secure manner.Systems administration staff can consist of anyone involved in the administrator of the system.This can include, but is not limited to:

  • Systems Administrators
  • Application Administrators[1]
  • Account Management Personnel
  • Help Desk Personnel
  • Information System Security Officers (ISSO)[2]
  • System Owner (SO)
  • Information Owners (IO)

1.2Contacts

Figure 1 – Contacts

Role / Title / Address / Phone Number / Email Address
System Owner (SO)
Information Owner (IO)[3]
System/Application Administrator(S/AA)[4]
Information System Security Officer (ISSO)
Backup ISSO
Designated Approving Authority (DAA)

1.3Configuration Management of the Systems Administration Manual

This Systems Administration Manual is under control of the <System Name> Configuration Management Plan.

1.4Location of this Document

Hard copies of this document are stored in <facility name, room number>.

Electronic copies of this document are stored at <path to location on file server or web server requiring authentication to access the document.>

2Operational Processes

<Insert Operational Processes in this section.Add as many sections as are necessary.>

3IT Security Related Processes

There are numerous IT security related processes that are performed in support of <System Name>. These processes are categorized by the parties responsible for performing them. The categories are:

  • System and Application Administrators (including Help Desk and Account Management personnel)
  • Information System Security Officer
  • System Owner
  • Information Owner
  • Office of the Chief Information Office Services

3.1General IT Security Related Information

The following sections detail key operational details.

3.1.1IT Contingency

<System Name> has been designated as a Tier<insert tier> system, which means that it must be restored within <insert time per Tier classification> of any outage that occurs which affects the operation of the system.This tier rating was determined based on the impact of the loss of system availability. The impact of these outages is illustrated in the following table, along with allowable outage times.

Figure 2 – Outage Types, Impacts & Recovery Times[5]

Business Function Supported / Outage Impact / Allowable Outage Time

Contingency activities for <System Name> are shared between group name and OCIO.The aspects of the IT Contingency Plan that OCIO will undertake for the System Owner are documented in the Memorandum of Understanding/Interconnection Security Agreement (MOU/ISA) between the system owner and OCIO.OCIO handles the technical aspects of:

  • Damage Assessment
  • Recovery Operations
  • Return to Operations

All these items are covered in the MOU/ISA and are documented in the Library of Congress IT Continuity Of Operations Plan (COOP).

3.1.2Hosted Application IT Contingency Plan

The <System Name>IT Contingency Plan is a standalone document, containing the contingency SOPs.

3.1.3Security Awareness

The Library provides both initial and refresher security awareness training at which time users are required to accept the Library of Congress Rules of Behavior for Using Information Technology Systems.

3.1.4Rules of Behavior

Rules of Behavior are part of the Library of Congress Security Awareness Training. All new employees are required to complete the Library of Congress Security Awareness Training as part of orientation. All contracts have the requirement for contractors to complete the Library of Congress Security Awareness Training.

3.2IT Security Related ProcessesPerformed by System and Application Administrators

The procedures in this section are performed by System and Application Administrators. This grouping includes Help Desk and Account Management personnel where appropriate.

3.2.1Account Creation

It has been determined by the System Owner that Library personnel and non-Library personnel (including contractors, volunteers, etc.) using the <System Name> system, must undergo <insert appropriate background screening including security investigations commensurate with the level of access accorded to them in to this system>in accordance with LCR 2024-3, 2024-4 and 2024-5.

Before an account is created, the account management personnel must receive a completed account management form<Update account management form as necessary.> (Appendix C – Account Management Form).<If any additional screening is required, proof of success must also be indicated on the form.>This Form must state the badge number[6] of the individual.The accounts management personnel must validate that the user has completed the Security Awareness Training.This information can be obtained from the Office of Management and Training.

For individuals without Library of Congress building access badges, the System Owner must ensure that identity is established per NIST SP 800-63, Level 2.

  1. To establish identity, the user must be required to submit identifying information consisting of the ID number from a Driver’s License, Passport or financial account.
  2. Before creating an account for an individual without a Library of Congress building access badge, the Application Administrator must inspect and verify the identifying information provided by applicant through record checks either with the applicable agency or institution or through credit bureaus or similar databases, and confirms that the identifying information in records are on balance consistent with the sensitivity of the application and sufficient to identify a unique individual.
  3. The identifying information (ID number from a Driver’s License, Passport or financial account) must not be backed up or otherwise stored in either electronic or paper form.
  4. Once an account is created, the identifying information (ID number from a Driver’s License, Passport or financial account) must be purged from the system as follows:

Modify or replace the following sample SOP to remove identifying information from system>

  1. Review the account using <account management utility> and remove any identifying information.
  2. For each documents/record related to the account request that has been electronically stored on the system, do one of the following:
  3. If the related documentation is no longer needed, delete the document/record and purge all temporary directories, including the Recycle Bin.
  4. Electronically redact any personally identifying information, including any stored in metadata, and overwrite the original document/record.

User accounts must be assigned to individual users. Group Accounts (i.e., multiple users sharing a single account) are expressly forbidden. As part of the account creation process, ensure that no Group Accounts are approved and created.

SOP to Create a New Account

Modify or replace the following sample SOP to Create a New Account

  1. Log onto the system
  2. From the command line type smitty
  3. Select Security & Users
  4. Select Users
  5. Select Add a User
  6. Enter the user name
  7. If the user is not an administrator, change true to false
  8. In HOME directory, add /home/username
  9. Select false for “Another user can SU TO USER.”
  10. Press the Enter button

3.2.2Creating Accounts with Elevated Privileges

Before an administrative account can be created for anyone in the <System Name>, group namerequires the acceptance of the Privileged User Rules of Behavior.These rules serve as an agreement between the group namemanager and the privileged users of the group namethat they will adhere to the rules for the system. Privileged use is defined as “use of rights beyond that of a typical IT system user to manage and maintain an IT system.”

SOP to Create Elevated Privileged Accounts

Modify or replace the following SOP to indicate the procedures regarding how Elevated Privileged Accounts will be created.>

  1. Send an email to the ISSO for <System Name> (see section 1.2 Contacts for this information) requesting them to verify that the user who has requested an elevated privileged account has signed a Privileged User Rules of Behavior form within the past year.
  2. If the ISSO confirms this (via email), following the procedures listed in section 3.2.1. Account Creation to create an account with the following properties:
  3. The elevated account name must be prefixed with a “#” (e.g., #jsmith)
  4. If the ISSO cannot confirm the request, contact the requester and notify them that the account cannot be created until the ISSO is in possession of a Privileged User Rules of Behavior form signed by the user within the past year.

3.2.3Temporary and Emergency Accounts

When an account request is received for a temporary or emergency account, the System Owner or designate may sign off via signature, email or telephone to authorize such accounts.Temporary or emergency accounts must still have requests documented after the fact.

  • Temporary or emergency accounts must be created with an expiration date of no more than five days after the creation date.
  • Temporary or emergency accounts must be deleted within 30 days of their creation dates.
  • The ISSO and Systems Administrators must be notified via email of any temporary or emergency accounts, their purposes and the expiration dates.
3.2.3.1Temporary and Emergency Account Creation

Modify or replace the following SOP to indicate the procedures for creating temporary and emergency accounts. The SOP must include a provision for ensuring the requirements provided in section 3.2.3 Temporary and Emergency Accounts (see bulleted list) will be met.Do not modify the <User Account> variable in the followingsample SOP.

  1. Using <account management utility, follow the procedures listed in section 3.2.1 Account Creation to create an account whose expiration data is set to expire no more than 5 days from the creation date.
  2. Create a calendar appointment with the following details:
  3. Date of appointment: Any date within 30 days of the account creation date
  4. Time: Any free time within normal working hours
  5. Invitees: Yourself and all other account administrators
  6. Subject: “Reminder to remove the <User Account> account from <System Name>”
  7. Priority: High
  8. Reminder: Enabled
3.2.3.2Temporary and Emergency Account Deletion

Modify or replace the following SOP to ensure temporary or emergency accounts are deleted within 30 days of creation. If this sample SOP will be used, do not modify the User Account> variable.>

When receiving a calendar appointment notification with a subject of “Reminder to remove theUser Accountfrom <System Name>” follow these procedures.

  1. Using <account management utility> on <System Name>, follow the procedures listed in section 3.2.7 Account Deletion to permanently remove the account listed in the subject line of the appointment notification.

3.2.4Initial Passwords

Initial passwords are created by the accounts management personnel and configured to force the user to change his or her password upon initial login.All initial passwords must be unique.

Initial account names and passwords are provided to users via two separate channels.Accounts management personnel provide the initial password one of the following ways:<Specify the channels. Examples are below. Choose one or more or specify a different method.>

  • Directly to the user, checking the user’s LOC badge to validate identity
  • Delivering it to an authenticable repository (e.g., an active LOC voice mail or email box.)
  • Directly to the supervisor that signed the account request form, checking the user’s LOC badge to validate identity

3.2.5Disabling Accounts

  • Disable account if the user no longer requires access
  • Disable account if system no longer uses the account
  • Departing personnel accounts must be disabled immediately (within 48 hours)
  • Departing personnel accounts in an involuntary separation situation must be disabled immediately.

SOP to Disable an Account

Modify or replace the following sample SOP to Disable an Account

  1. Disable the account as follows:
  2. Log onto the system
  3. From the command line type smitty
  4. Select Security & Users
  5. Select Users
  6. Select Lock / Unlock a User's Account
  7. Set the lock value to True
  8. Enter the user name
  9. Press the Enter button

SOP to Re-Enable an Account

Modify or replace the following sample SOP to Re-Enable an Account>

  1. Log onto the system
  2. From the command line type smitty
  3. Select Security & Users
  4. Select Users
  5. Select Lock / Unlock a User's Account
  6. Set the lock value to False

3.2.6Revoking System Access

Voluntary Separation

Voluntary separation occurs whenever a user departs the organization voluntarily or ceases to require access to the system.In such cases, the following will be ensured by the individuals responsible for account management.

  • Departing personnel accounts must be removed within 30 days of that person’s departure
  • Inactive accounts must be deleted after 60 days of inactivity unless linked to personnel activity or the inactivity was initiated by the System Administrator due to a user’s leave or duty status

<Modify or replace the following sample SOP to ensure the above requirements are being met

  1. When notified of departing personnel, disable the account according to the SOP indicated in section 3.2.5 Disabling Accounts
  2. Notify the System Owner, ISSO and other administrators as follows. Send an email with the following details:
  • Recipients: System Owner, ISSO and System Administrators (see section 1.2 Contacts for the names and email addresses of these persons)
  • Priority: High
  • Subject: Disablement and planned removal of <account name> from <System Name>
  • Message: “The following account has been disabled on <System Name> and will be removed within 30 days: <User Account>”.
  1. Unless directed otherwise by the System Owner or designate, create a calendar appointment reminder with the following details:
  2. Subject: “Planned Removal of Inactive Account(s) on <System Name>“
  3. Date of appointment: Second working day of any week that is between 50-60 days of when the account was disabled
  4. Time of appointment: Available time when you plan to perform account management
  5. Invitees: System Owner, ISSO and all account administrators for <System Name> (see section 1.2 Contacts for the names of these individuals)
  6. Priority: High
  7. Reminder: Enabled and set to notify recipients 1 day prior to date of appointment
  8. Message: Unless immediately directed otherwise, the account listed in the subject of this appointment will be deleted.

4. When receiving a calendar appointment notification with a subject of “Planned Removal of Inactive Account(s) on <System Name>“ do the following:

  1. If the notification is for an appointment scheduled for the following business day, close the reminder and do nothing (i.e., do not remove the account at this time)
  2. If the notification is for an appointment scheduled for the current business day, use the <account management utility> on <System Name> to review the user account listed in the subject line of the calendar appointment and determine if it has been inactive for over 50 days.
  3. If the account has been inactive for at least 50 days send an email to the ISSO and System Owner with the following details:
  4. Subject: Account Removal Notice!
  5. Priority: High
  6. Message: Unless directed otherwise, the following account(s) will be permanently removed from <System Name> on the next business day: <list of inactive accounts that will be removed.
  7. If the account has been active in the past 50 days, do nothing.

Involuntary Separation