You are on page 1of 32

<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


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

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


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

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


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

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


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

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.

6 Security Category: Moderate


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

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.

7 Security Category: Moderate


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

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.

8 Security Category: Moderate


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

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

9 Security Category: Moderate


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

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:

10 Security Category: Moderate


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

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.

11 Security Category: Moderate


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

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>

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

12 Security Category: Moderate


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

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:

13 Security Category: Moderate


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

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>

1. Log onto the system


2. From the command line type smitty

3. Select Security & Users

4. Select Users

14 Security Category: Moderate


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

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

15 Security Category: Moderate


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

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

16 Security Category: Moderate


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

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

<Modify or replace the following sample SOP to indicate how accounts are removed due to
voluntary separation>

17 Security Category: Moderate


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

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

<Modify or replace the following sample SOP to indicate how accounts are removed due to
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

18 Security Category: Moderate


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

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

1. From the command line type smitty


2. Select Security & Users
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).

19 Security Category: Moderate


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

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

20 Security Category: Moderate


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

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.

21 Security Category: Moderate


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

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

22 Security Category: Moderate


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

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.

23 Security Category: Moderate


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

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

24 Security Category: Moderate


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

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.

25 Security Category: Moderate


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

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.

26 Security Category: Moderate


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

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.

27 Security Category: Moderate


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

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

28 Security Category: Moderate


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

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

29 Security Category: Moderate


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

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

30 Security Category: Moderate


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

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

31 Security Category: Moderate


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

Awareness
Training

Name of
Individual
Verifying
Identity

Signature of
Individual
Verifying
Identity

32 Security Category: Moderate