Systems Administration Manual Template

<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, Steve Elky Updated to reflect lessons learned
2006
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 Finalized updates
Hendrickson
2.0 December 2, Sandy Chou Replace ITS with OCIO
2015
ii Security Category: Moderate

Table of Contents
1 Introduction..............................................................................................................................5
1.1 Scope................................................................................................................................5
1.2 Contacts...........................................................................................................................6
1.3 Configuration Management of the Systems Administration Manual..............................6
1.4 Location of this Document..............................................................................................6
2 Operational Processes..............................................................................................................6
3 IT Security Related Processes..................................................................................................6
3.1 General IT Security Related Information........................................................................7
3.1.1 IT Contingency............................................................................................................7
3.1.2 Hosted Application IT Contingency Plan....................................................................7
3.1.3 Security Awareness......................................................................................................8
3.1.4 Rules of Behavior........................................................................................................8
3.2 IT Security Related Processes Performed by System and Application Administrators...8
3.2.1 Account Creation.........................................................................................................8
3.2.2 Creating Accounts with Elevated Privileges................................................................9
3.2.3 Temporary and Emergency Accounts........................................................................10
3.2.4 Initial Passwords........................................................................................................11
3.2.5 Disabling Accounts....................................................................................................11
3.2.6 Revoking System Access...........................................................................................12
3.2.7 Account Deletion.......................................................................................................13
3.2.8 Periodic Account Management Procedures...............................................................14
3.2.9 Event Based Account Management Procedures........................................................16
3.2.10 Password Reset Procedures...................................................................................17
3.2.11 Change Management.............................................................................................18
3.2.12 Patching.................................................................................................................18
3.2.13 Information Handling and Dissemination.............................................................18
3.2.14 Media Controls......................................................................................................19
3.2.15 Incident Handling (Including Theft)......................................................................19
3.2.16 Backup and Restore...............................................................................................19
3.3 IT Security Related Procedures Performed by the ISSO...............................................20
3.3.1 Monitoring.................................................................................................................20
3.3.2 Incident Handling......................................................................................................20
3.3.3 Reporting...................................................................................................................20
3.3.4 Risk Management......................................................................................................20
3.3.5 Annual Risk Review (Review of Security Controls).................................................20
3.3.6 Sanitization................................................................................................................21
3.4 IT Security Related Procedures Performed by the System Owner................................21
3.4.1 Risk Management......................................................................................................21
3.4.2 Hosted Application IT Contingency Plan Testing.....................................................21
3.4.3 Sensitive System Positions........................................................................................22
3.4.4 Separation of Duties..................................................................................................22
3.4.5 Establishing User Identity..........................................................................................23
3.4.6 Revoking System Access...........................................................................................23
iii Security Category: Moderate

Involuntary Separation...........................................................................................................24
3.4.7 Security Awareness Training.....................................................................................24
3.4.8 License Management.................................................................................................24
3.4.9 Maintenance...............................................................................................................24
3.5 IT Security Related Procedures Performed by the Information Owner.........................25
3.6 IT Security Related Procedures Performed by OCIO....................................................25
3.6.1 Physical Security Controls.........................................................................................25
3.6.2 License Management.................................................................................................25
3.6.3 Maintenance...............................................................................................................25
3.6.4 Monitoring.................................................................................................................25
3.6.5 Backup and Restore...................................................................................................25
4 Appendix A Backup Criteria...............................................................................................26
5 Appendix B Software License & Maintenance Contract Tracking....................................27
6 Appendix C Account Management Form...........................................................................28
Table of Figures
Figure 1 Contacts..........................................................................................................................6
Figure 2 Outage Types, Impacts & Recovery Times....................................................................7
Figure 3 Account Management Recurring Reviews...................................................................14
Figure 4 Security Patch Tracking...............................................................................................18
Figure 5 Program Library Access Control..................................................................................19
Figure 6 Sensitive Positions........................................................................................................21
Figure 7 Allowable IT Security Role Combinations..................................................................22
Figure 8 Personnel Authorized to Perform Maintenance on System by Component.................24
Figure 9 Backup & Retention Requirements..............................................................................26
Figure 10 Software License/Maintenance Contract Information...............................................27
iv Security Category: Moderate

1 Introduction
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:
a. Replace <System Name> with the name of the system this manual applies to
b. Replace <group name> with the Library group or division that owns the system
c. 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.)
2. 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.
3. Address any instructions. Instructions are highlighted in blue text.
4. Delete any instructions from the final document.
5. 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.1 Scope
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 Administrators1
Account Management Personnel
Help Desk Personnel

1
An Application Administrator is the administrator of a particular application (i.e., IT system), as opposed to a
System Administrator, who is responsible for the underlying operating system and hardware.
5 Security Category: Moderate

Information System Security Officers (ISSO)2

System Owner (SO)
Information Owners (IO)
1.2 Contacts
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.3 Configuration Management of the Systems Administration Manual
This Systems Administration Manual is under control of the <System Name> Configuration
Management Plan.
1.4 Location 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.>
2 Operational Processes
<Insert Operational Processes in this section. Add as many sections as are necessary.>
3 IT 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:
2
Detailed procedures performed by the ISSOs are contained in the IT Security Logbook along with the record of
their activities.
3
There may be more than one Information Owner. Repeat as necessary.
4
There may be more than one System/Application Administrator. Repeat as necessary.

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.1 General IT Security Related Information
The following sections detail key operational details.
3.1.1 IT 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 Times5

Business Function Outage Impact Allowable
Supported 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).
5
Copy from the Business Impact Assessment (BIA) for the system/application.

3.1.2 Hosted Application IT Contingency Plan
The <System Name> IT Contingency Plan is a standalone document, containing the contingency
SOPs.
3.1.3 Security 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.4 Rules 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.2 IT Security Related Processes Performed 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.1 Account 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 number6 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 Drivers License, Passport or financial account.
6
Library of Congress building access badges as issued by the Office of Security and Emergency Preparedness.

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 Drivers 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 Drivers
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>
a. Review the account using <account management utility> and remove any
identifying information.
b. For each documents/record related to the account request that has been
electronically stored on the system, do one of the following:
i. If the related documentation is no longer needed, delete the
document/record and purge all temporary directories, including the
Recycle Bin.
ii. 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.2 Creating Accounts with Elevated Privileges
Before an administrative account can be created for anyone in the <System Name>, <group
name> requires the acceptance of the Privileged User Rules of Behavior. These rules serve as an

agreement between the <group name> manager and the privileged users of the <group name>
that 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:
a. The elevated account name must be prefixed with a # (e.g., #jsmith)
3. 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.3 Temporary 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.1 Temporary 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 following sample 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:

a. Date of appointment: Any date within 30 days of the account creation date
b. Time: Any free time within normal working hours
c. Invitees: Yourself and all other account administrators
d. Subject: Reminder to remove the <User Account> account from <System

Name>
e. Priority: High
f. Reminder: Enabled
3.2.3.2 Temporary 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 the
<User Account> from <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.4 Initial 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 users 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 users LOC
badge to validate identity
3.2.5 Disabling 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:

a. Log onto the system
b. From the command line type smitty
c. Select Security & Users
d. Select Users
e. Select Lock / Unlock a User's Account
f. Set the lock value to True
g. Enter the user name
h. Press the Enter button
SOP to Re-Enable an Account
< Modify or replace the following sample SOP to Re-Enable an Account>

4. Select Users
5. Select Lock / Unlock a User's Account
6. Set the lock value to False
3.2.6 Revoking 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 persons 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 users 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>.
3. Unless directed otherwise by the System Owner or designate, create a calendar

appointment reminder with the following details:
Subject: Planned Removal of Inactive Account(s) on <System Name>
Date of appointment: Second working day of any week that is between 50-60
days of when the account was disabled
Time of appointment: Available time when you plan to perform account

management
Invitees: System Owner, ISSO and all account administrators for <System Name>
(see section 1.2 Contacts for the names of these individuals)
Priority: High
Reminder: Enabled and set to notify recipients 1 day prior to date of appointment
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:

a. 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)
b. 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.
c. If the account has been inactive for at least 50 days send an email to the ISSO and
System Owner with the following details:
i. Subject: Account Removal Notice!
ii. Priority: High
iii. 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 >.
d. If the account has been active in the past 50 days, do nothing.
Involuntary Separation
Involuntary separation includes any circumstances where access for a particular user is being
removed without the willing cooperation of the individual whose access is being removed. This
is variously known as firing, hostile termination, and forced reassignment. Cases where a
supervisor believes that an individual is resigning, but is unfavorably disposed to the
organization, the resignation must be treated as an involuntary separation. In such cases, the
potential for harm to the system is extremely high. Departing personnel accounts must be
disabled immediately upon management notification, See Section 3.2.5, Disabling Accounts.
3.2.7 Account Deletion

This section only contains the procedures for deleting user accounts. For information on how to
handle separation from the organization or removal of access permissions, see Section 3.4.5.
<Modify or replace the following sample SOP to indicate your actual procedure for deleting
accounts>

4. Select Users

5. Select a User
6. Remove a User
7. Enter the username
8. Select true for Remove AUTHENTICATION information?
9. Press the Enter key
3.2.8 Periodic Account Management Procedures
Perform account management reviews per Figure 3 Account Management Recurring . Ensure
that the Resulting Action is taken. The ISSOs will audit and report on this activity.
Figure 3 Account Management Recurring Reviews

Frequency Review Type Resulting Action
Weekly Account usage activity Ensure accounts that have been unused for 30 days are disabled
Weekly Privileged User list Ensure any accounts used by Privileged Users who were reassigned or have
left the Library are disabled immediately and deleted within 60 days
Quarterly User accounts list Ensure that you are being notified of any emergency or temporary accounts
Quarterly Account usage activity Ensure accounts that have been unused for 90 days are deleted (note that
this assumes 30 days of inactivity and 60 days of the account being
disabled)
Weekly Account Maintenance Procedures
<Modify or replace the following SOP to indicate the procedure used to perform weekly
account maintenance based on the above table>
On the first working day of every week, do the following:
1. Use <account management utility> on <System Name> to review all accounts for
inactivity.
2. Using <account management utility>, disable all accounts that have not been accessed in
over 30 days.
3. Send an email with the following details:
a. Recipients: System Owner, ISSO and all administrators for <System Name> (see
section 1.2 Contacts for this information)
b. Subject: Notice: Planned Removal of Inactive Account(s) on <System Name>
c. Priority: High

d. Message: The following accounts have not been accessed in over 30 days and
have therefore been disabled. Unless you direct me otherwise, these accounts will
be permanently removed from <System Name> after 50-60 days of inactivity:
<list of inactive accounts>.
4. Unless directed otherwise by the system owner or designate, create a separate calendar
appointment for each account that has been inactive for over 30 days with the following
details:
a. Subject: Account: <User Account> will be removed from <System Name> on

the next business day due to inactivity
b. Date of appointment: Working day that is between 50-60 days of when the
account was last accessed
c. Time of appointment: Available time when you plan to perform account

management
d. Invitees: ISSO and all account administrators for <System Name> (see section 1.2
Contacts for the names of these individuals)
e. Priority: High
f. Reminder: 1 day prior to appointment
Quarterly Account Maintenance Procedures
<Modify or replace the following SOP to indicate the procedure used to perform quarterly
account maintenance base on the above table>
On the first working day of every quarter, do the following:
1. Using <account management utility> review and make a note of all accounts that have
not been accessed in over 90 days.
2. Send an email with the following details:
Recipients: System Owner, ISSO and all administrators for <System Name> (see
section 1.2 Contacts for this information)
Subject: Planned removal of inactive accounts
Message: The following accounts have not been accessed in over 90 days and
have therefore been disabled. Unless directed otherwise, these accounts will be
deleted from <System Name> on the next business day.: <list of inactive
accounts>.

Priority: High
3. Unless directed otherwise by the System Owner or designate, create a separate calendar
appointment for each account that has been inactive for over 90 days with the following
details:
a. Date of appointment: 1 business day from todays date
b. Time of appointment: Time when you plan to perform account management
c. Invitees: All account administrators for <System Name>
d. Subject: Remove account: <User Account> from <System Name>
e. Priority: High
4. When receiving a calendar appointment notification with a subject of Remove <User

Account> account on System Name> (unless previously directed otherwise by the
System Owner) follow the procedures listed in section 3.2.7 Account Deletion to remove
the account(s).
3.2.9 Event Based Account Management Procedures
When accounts have been identified as inactive accounts, whether due to inactivity or voluntary
separation, the following SOPs to remove them should be followed.
Removal of Accounts Due to Inactivity
<Modify or replace the following sample SOP to indicate how accounts are removed due to
inactivity separation>
When receiving a calendar appointment notification that contains a subject that begins
Remove <User Account> from <System Name> do the following:
a. If the notification is a reminder for an appointment scheduled for the following

business day, do nothing.
b. If the notification is a reminder for an appointment scheduled for the current
business day, remove the account (unless directed otherwise by the System Owner
or designate) as indicated in 3.2.7 Account Deletion.
Removal of Accounts Due to Voluntary Separation
voluntary separation>

When receiving a calendar appointment notification that contains a subject that begins
Remove <User Account> from <System Name> do the following:
a. If the notification is a reminder for an appointment scheduled for the following

business day, do nothing.
b. If the notification is a reminder for an appointment scheduled for the current
business day, remove the account (unless directed otherwise by the System Owner
or designate) as indicated in 3.2.7 Account Deletion.
Removal of Accounts Due to Involuntary Separation
Unlike voluntary separation, which is a standard procedure handled by the personnel responsible
for account management, involuntary separation is the direct responsibility of the System Owner
or designate. Involuntary separation includes any circumstances where access for a particular
user is being removed without the willing cooperation of the individual whose access is being
removed. This is variously known as firing, hostile termination, and forced re-assignment.
Cases where a supervisor believes that an individual is resigning, but is unfavorably disposed to
the organization, the resignation must be treated as an involuntary separation. In such cases, the
potential for harm to the system is extremely high. Therefore the following process must be used:
Prior to or concurrent with the notification of being removed from the system (or the
organization) all accounts associated with the individual must be disabled
Immediately after access to the email system has been removed, an email stating the
nature of the involuntary separation and the pertinent user name must be sent to
Terminators@loc.gov from the LOC email account of the manager authorizing the
involuntary separation or their designee
If the manager authorizing the involuntary separation has reason to believe that the
individual may damage Library of Congress resources or attempt to remove sensitive
materials, the separating individual must be escorted from his or her work area and be
allowed to remove only personal items
involuntary separation>
Remove the account as directed by the System Owner or designate as indicated in 3.2.7 Account
Deletion.
3.2.10 Password Reset Procedures
If the corresponding account has not been accessed within 48 hours of a password reset, the
password must be changed again or the account disabled. Accounts management personnel
review the accounts of all users who have requested a password change on a daily basis in order
to ensure passwords are changed within 48 hours of a reset.
SOP for Resetting Passwords

<Modify or replace the following SOP to reflect the actual password reset procedures used by the
system.>
The user must identify themselves to the account management personnel and then provide the
verbal authenticator before the password will be changed or the account will be locked out. The
account management personnel can prompt the user by asking the security question.

3. Select Users
4. Select Change a User's Password
5. Enter the user name
6. Enter the new password
7. Update the Accounts with Recently Reset Passwords document stored in <path and name
of Recently Reset Passwords list> to include the name of account for which the password
was just reset.
SOP for Newly Reset Password Review
<Modify or replace the following sample SOP to ensure that accounts management personnel
review the accounts of all users who have requested a password change on a daily basis in order
to ensure passwords are change within 48 hours of a reset, changing the password of any account
that has not been accessed within 48 hours of a reset.
1. Every morning at the start of the shift, the day shift Application Administrator will review
the Accounts with Recently Reset Passwords list stored in <path and name of Recently
Reset Passwords list>.
2. For each account that was reset more than 48 hours ago and is enabled (per the Recently
Reset Passwords list), login to the account to ensure that the password was reset (if it was
reset, the login will fail.)
3. If the password was reset, remove the entry concerning this account from the Recently
Reset Passwords list.
4. Otherwise, reset the password, disable the account and notify the user (1) that the
password was reset again, (2) where to call to obtain the new password and (3) how to
get the account re-enabled.
5. Indicate on the Recently Reset Passwords list that the account is disabled.
3.2.11 Change Management
Any changes to the <System Name> must follow the procedures contained within the <System
Name> Configuration Management Plan (CMP.) The only exceptions are changes implemented
following Standard Operating Procedures documented in the Systems Administration Manual
(this document).

3.2.12 Patching
On a <weekly/monthly/quarterly> basis, the websites for all vendors of subsystems comprising

this system are reviewed to identify new security related patches to the software. The decision to
implement or not to implement is documented in Figure 4 Security Patch Tracking. Actual
implementation follows the <System Name> Configuration Management Plan (CMP).
Figure 4 Security Patch Tracking
Patch Link Date Release Summary of Decision to Decision

Designation Vulnerability Implement or Date
Reason Patch Not
Implemented
3.2.13 Information Handling and Dissemination
The following procedures must be followed by all system users.
a) Store hard copies and soft copy contained on removable media (e.g., tapes, floppy disks,
CD-ROM/CD-R, flash drives, etc.) in a government approved storage container per the
direction of the System Owner when not under the direct control of approved personnel
b) Any output from the system must be marked with its Security Category if the Security
Category is Moderate or High
c) Any output from the system marked Security Category: Moderate, Security Category:
High and Limited Official Use Only are not be emailed outside of the Library of
Congress email system, they may only be emailed between Library of Congress email
accounts
d) Any output from the system marked Security Category: Moderate, Security Category:
High and Limited Official Use Only must be shredded, burned or otherwise destroyed
before being disposed
e) Any output from the system may not be provided to anyone other than individuals
authorized by the System Owner unless approved by the System Owner
f) <If output from the system regularly needs to be provided to an external partner, specify
the output, the partner and the requirement in this list.>
3.2.14 Media Controls
All media for the <System Name> system is managed by OCIO with the exception of source
media for system components not managed by OCIO. This media is stored in <enter location>
and is tracked through the <System Name> Configuration Management Plan and is audited on an
annual basis. Access to all program libraries is restricted and controlled through the use of
operating system level access controls listed in

Figure 5 Program Library Access Control

Category Description System/Path Access Group Name
3.2.15 Incident Handling (Including Theft)
The following procedures must be followed by all system users.
The theft or loss of a mobile or portable system must be immediately reported to the
<replace with designated entity within the Service or Enabling Unit>.
Personal property controls and reporting of property theft/loss must be managed
according to LCR 1815-1, Reporting Missing or Stolen Library Property.
Inappropriate or unusual activity must be reported to the ISSO, who will work with the
appropriate individuals to investigate, take appropriate actions to resolve the incident and
report the outcome.
3.2.16 Backup and Restore
Backup requests may be submitted using the Storage Allocation Request (SAR) for those having
access to that Remedy application or using email from the Designated Signing Authority7 (DSO).
Restore requests are detailed in the IT Contingency Plan. See Section 3.1.2.
3.3 IT Security Related Procedures Performed by the ISSO
Numerous IT security-related activities are performed by the ISSO. The IT Security Logbook
contains these procedures and records. The following sections are included to ensure that System
and Application Administrators understand the scope of their duties as opposed to ISSO duties.
3.3.1 Monitoring
The <System Name> system ISSO monitors the logs associated with <System Name>. These
procedures are contained in the IT Security Logbook.
Audit logs are kept on-line for <replace with number at least 30> days. Audit logs are retained in
some form for 180 days. The following procedure is used to rotate the audit logs:
SOP for Audit Log Rotation
<Modify or replace the following sample SOP or script to indicated how audit logs are actually
rotated>
1. Log into the system with administrator privileges.

2. Stop the audit log processes.
7
The DSO is specified in the Memorandum of Understanding with OCIO.

3. On the first day of every month, copy the audit logs from <path and name of audit log
files> to the audit log archives: <path and name of audit log archive files>.
4. Delete the audit logs from <path and name of audit log files>.
5. Restart the audit log process.
3.3.2 Incident Handling

The ISSO handles all security incidents for <System Name>. Incident handling procedures for IT
Security incidents are contained in the IT Security Logbook.
3.3.3 Reporting
Quarterly, the status of the systems Plan Of Action & Milestones (if one exists) is reported to the
System Owner and the Designated Approving Authority. Annually, the status of the security
activities on the <System Name> system are reported to OCIO in accordance with LCR 1620.
All required reporting is performed by the ISSO. Reporting procedures are contained in the IT
Security Logbook.
3.3.4 Risk Management
The ISSO will track and report on the actions and milestones in the Plan Of Action & Milestones
(POAM) if one exists. These procedures are contained in the IT Security Logbook.
3.3.5 Annual Risk Review (Review of Security Controls)

Annually, the ISSO performs the Annual Risk Review of the <System Name> system. These
procedures are contained in the IT Security Logbook. The Annual Risk Review is reported to the
IT Security Program Manager for the Service Unit, which in turn is reported to the Chief
Information Security Officer and summarized in the annual Library of Congress IT Security
Report.
3.3.6 Sanitization
OCIO manages sanitization for all system servers and backup media. The ISSO manages any
other media associated with the system. These procedures are contained in the IT Security
Logbook.
3.4 IT Security Related Procedures Performed by the System Owner
The following activities are the responsibility of the System Owner or designate. The System
Owner must ensure that resources are available to perform all system functions except those
performed by OCIO.
3.4.1 Risk Management
The System Owner is responsible for a subset of activities in regards to Certification &
Accreditation (C&A) which can be found in the LC Certification & Accreditation Guidance

document. In general, these activities involve ensuring that C&A is performed; addressing the
Plan of Action & Milestones (POAM); ensuring security considerations exist in solicitations; and
using Security Advisors and contractors appropriately.
3.4.2 Hosted Application IT Contingency Plan Testing
The System Owner is responsible for ensuring that the <System Name> IT Contingency Plan is
tested at least semi-annually. This testing consists of:
Notification to the OCIO Point of Contact (documented in the Memorandum of

Understanding with OCIO)
OCIOs response that recovery has been completed
Acceptance Testing
Communications to the OCIO Point of Contact system users that the system is available
This covers any type of disaster from the point of view of the application owner. Please note that
contingencies for the personnel and workspace should be part of the application owners Service
or Enabling Infrastructure COOP.
A successful test of a Hosted Application IT Contingency Plan does not require OCIO to actually
perform any technical exercises, though it does require OCIO communicate with the application
owner.
Coordinate all IT Contingency Plan testing with the ISSO. The ISSO reports on IT Contingency
Plan testing as part of the Annual Risk Review.
3.4.3 Sensitive System Positions
The System Owner, in consultation with the Designated Approving Authority, is responsible for
ensuring that all positions of system responsibility have been reviewed and classified in terms of
their sensitivity in accordance with LCR 2024-2. These positions are listed in Figure 6
Sensitive Positions. Personnel occupying these positions have been required to sign a Privileged
Rules of Behavior Acceptance and are required to renew this annually. These procedures are
contained in the IT Security Logbook.
Figure 6 Sensitive Positions

Position Reason for Sensitivity
ISSO/Backup ISSO
System Administrator
Application Administrator
Help Desk
Access has been granted according to the principle of least privilege, and where possible, ensures
the segregation of duties.

In order to protect against fraud, the following strategy is used for privileged roles. <Choose one
or more of the following.>
<Vacations are required annually at a minimum

Duties are rotated among staff members
There are at least 2 individuals trained to fulfill any privileged task>
3.4.4 Separation of Duties
The System Owner is responsible for ensuring sufficient separation of duties for roles with
significant IT security responsibilities. Figure 7 Allowable IT Security Role Combinations is
drawn from the General IT Security Directive and shows the basic requirements for separation of
duties.
Figure 7 Allowable IT Security Role Combinations

DAA8 CO CISO OCIO ISSO SO IO SA
PM
DAA N/A No No No No Yes Yes No
CO No N/A Yes Yes Yes No No No
CISO No Yes N/A Yes No No No No
OCIO No Yes Yes N/A Yes No No No
PM
ISSO No Yes No Yes N/A No No No
SO Yes No No No No N/A Yes No
IO Yes No No No No Yes N/A No
SA No No No No No No No N/A
<Insert any other separation of duties requirements.>
3.4.5 Establishing User Identity
The System Owner is responsible for ensuring that the identity of all system users is established
before granting access to the system. Identity can be established by using the Library of
Congress building access badge number. 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. SOPs for performing these activities are contained in Section 3.2.1 Account Creation.
3.4.6 Revoking System Access
Voluntary Separation
8
DAA: Designated Approving Authority, CO: Certifying Official, CISO: Chief Information Security Officer, OCIO
PM: IT Security Program Manager, ISSO: Information Systems Security Officer, SO: System Owner, IO:
Information Owner, SA: Systems Administrator (includes Application Administrators, Help Desk and Account
Management personnel, etc.)

Separation can include having access revoked from a particular system as well as leaving the
Library. As individuals job responsibilities change throughout their careers, it is normal for
access to a particular system to no longer be necessary.
As part of separation, whether it is separation from the Library or separation from a system, the
System Owner must ensure that any confidentiality issues concerning the system are discussed.
In the case of separation from the Library, the standard separation process is sufficient unless
there are special considerations for this system.
System Owners must ensure that the system/application administrators responsible for account
management are part of the Terminators group in the Library of Congress email system. The
System Owners must send an email to ITSHotline@loc.gov with following information:
Please add <insert names of account management personnel> to Terminators List. I am

the System Owner for <System Name>.
Involuntary Separation
Unlike voluntary separation, which is a standard procedure handled by the personnel responsible
for account management, involuntary separation is the direct responsibility of the System Owner
or designate. Follow the procedure for removal of accounts due to involuntary separation,
located in 3.2.9 Event Based Account Management Procedures.

3.4.7 Security Awareness Training
The System Owner is responsible for identifying, developing and delivering any security
awareness training beyond the standard annual Security Awareness Training provided by the
Library.
<If the system requires specialized security awareness training or the system server users are not
associated with the Library (e.g., staff, contractors, volunteers, etc) outline the security
awareness training requirements here.>
3.4.8 License Management
The System Owner or designate tracks all system-related licenses, maintaining software
maintenance on all system-related licenses. Additionally the System Owner or designate must
audit all system-related licenses on a yearly basis and report the audit results and the status of
licenses to OCIO on an annual basis. The System Owner is not required to track or maintain
licenses for OCIO provided services. The documentation related to the system-related licenses,
including the responsible party for each software package, is attached in Appendix B Software
License & Maintenance Contract Tracking.

3.4.9 Maintenance
The System Owner is responsible for maintenance on non-OCIO supported components of the
<System Name> system. Figure 8 Personnel Authorized to Perform Maintenance on System by
Component contains the list of the components not managed by OCIO and the personnel
authorized to perform maintenance upon these components.
Figure 8 Personnel Authorized to Perform Maintenance on System by Component
Component Authorized Personnel
<Insert any regular maintenance activities. For activities documented in vendor documentation,
simply list the activity, the frequency and the page/section of the vendor documentation.>
3.5 IT Security Related Procedures Performed by the Information Owner
On a yearly basis, the designated Information Owner reviews:
User access to information

Dissemination guidelines for the information
Laws and regulations specifically applying to information
The ISSO directs the Information Owner to perform these actions.
3.6 IT Security Related Procedures Performed by OCIO

The following sections detail IT security controls provided by the underlying Hosting
Environment and managed by OCIO for hosted applications in the Application Hosting
Environment (AHE) or Financial Hosting Environment (FHE). Systems or applications which
are not hosted by OCIO must provide all of the listed security controls.
3.6.1 Physical Security Controls
The <System Name> system is housed within OCIO facilities at the Capitol Hill Data Center
<insert if applicable: and the Alternate Computing Facility.> OCIO provides physical controls
for all hardware and backup media as well as the media for any software managed by OCIO.
3.6.2 License Management
OCIO manages the licenses for operating system software, operating system support software
(e.g., management, anti-virus, etc.) and all software listed as OCIO provided in the MOU
between OCIO and the System Owner.

3.6.3 Maintenance
OCIO provides maintenance on all hardware, operating system software, operating system
support software (e.g., management, anti-virus, etc.) and all software listed as OCIO provided in
the MOU between OCIO and the System Owner.
3.6.4 Monitoring
OCIO monitors all hardware, operating system software, operating system support software (e.g.,
management, anti-virus, etc.) and all server software listed as OCIO provided in the MOU
between OCIO and the System Owner.
3.6.5 Backup and Restore
Backup and restore are performed by OCIO per IT Security Directive 15. Appendix A Backup
Criteria contains copies of the current backup request forms.

4 Appendix A Backup Criteria
Figure 9 Backup & Retention Requirements
System Name
Description of Request
Requestor Name
Service Unit/Enabling
Infrastructure Reviewer (if
applicable)
Date of Request
Date to Begin Backups
Nature of the Data (Choose Dynamic

one)
Static
Value to the Mission of LC High

(Choose one)
Medium
Low
Required Confidentiality High

(Choose one)
Medium
Low
Required Integrity (Choose High

one)
Medium
Low
Required Availability (Choose High

one)
Medium
Low

Frequency of Backup Daily

Requested (Choose one or
more) Weekly
Monthly
Yearly
Number of Copies of the Tape

Backup Data (Specify for each
type) Disk Mirroring
BCVs
Retention Period for Each

Type of Backup

5 Appendix B Software License & Maintenance Contract Tracking
Figure 10 Software License/Maintenance Contract Information
Software Vendor Number of Maintenance Responsible Notes

Package Licenses Period Party

6 Appendix C Account Management Form
<Update account management form as necessary.>
<System Name> Account Management Form
Date
Requestor Name
Requestor Title
Requestor
Signature
Create Account Delete Account
Requested Action
Grant Role/Add to Group Role/Group Name:
Revoke Role/Remove from Group Role/Group Name:
Other Specify:
User Name
User Phone
User Email
User Badge
Number (if
applicable)
Completed by <System Name> Account Management Personnel
Date of
Verification
Badge Drivers License ID
Type of Proof of
User Identity Passport Number Bank Account
(Do not record the actual numbers with the exception of badge numbers.)
Individual has
completed
Security

Awareness
Training
Name of
Individual
Verifying
Identity
Signature of
Individual
Verifying
Identity

Systems Administration Manual Template

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Systems Administration Manual Template

Uploaded by

Copyright:

Available Formats

<Service/Infrastructure Unit>

<Month DD, YYYY>

Security Category: Moderate

Revision Date Revised By Notes

ii Security Category: Moderate

iii Security Category: Moderate

iv Security Category: Moderate

3. Address any instructions. Instructions are highlighted in blue text.

4. Delete any instructions from the final document.

Help Desk Personnel

5 Security Category: Moderate

Information System Security Officers (ISSO)2

Information Owners (IO)

1.3 Configuration Management of the Systems Administration Manual

1.4 Location of this Document

3 IT Security Related Processes

6 Security Category: Moderate

Office of the Chief Information Office Services

3.1 General IT Security Related Information

The following sections detail key operational details.

Figure 2 Outage Types, Impacts & Recovery Times5

7 Security Category: Moderate

3.1.2 Hosted Application IT Contingency Plan

3.1.3 Security Awareness

3.1.4 Rules of Behavior

3.2 IT Security Related Processes Performed by System and Application Administrators

3.2.1 Account Creation

1. To establish identity, the user must be required to submit identifying information

8 Security Category: Moderate

2. Before creating an account for an individual without a Library of Congress building

SOP to Create a New Account

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

1. Log onto the system

9 Security Category: Moderate

SOP to Create Elevated Privileged Accounts

a. The elevated account name must be prefixed with a # (e.g., #jsmith)

3.2.3 Temporary and Emergency Accounts

Temporary or emergency accounts must be created with an expiration date of no more

3.2.3.1 Temporary and Emergency Account Creation

10 Security Category: Moderate

b. Time: Any free time within normal working hours

c. Invitees: Yourself and all other account administrators

d. Subject: Reminder to remove the <User Account> account from <System

3.2.3.2 Temporary and Emergency Account Deletion

11 Security Category: Moderate

SOP to Disable an Account

<Modify or replace the following sample SOP to Disable an Account>

1. Disable the account as follows:

b. From the command line type smitty

c. Select Security & Users

e. Select Lock / Unlock a User's Account

f. Set the lock value to True

g. Enter the user name

h. 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

3. Select Security & Users

5. Select Lock / Unlock a User's Account

6. Set the lock value to False

3.2.6 Revoking System Access

12 Security Category: Moderate

Subject: Disablement and planned removal of <account name> from <System

3. Unless directed otherwise by the System Owner or designate, create a calendar