template for it security relevant sections of the systems

<Service/Infrastructure Unit>

<System Name>

Systems Administration ManualVersion <X.X>

<Month DD, YYYY>

Security Category: Moderate

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

Revision History

Revision Date Revised By NotesN/A April 29, 2005 Steve Elky Created generic procedures for adoption by other system

owners.N/A February 16,

2006Steve Elky Updated to reflect lessons learned

N/A March 13, 2007 Steve Elky Updated from 3/2007 review of DirectivesN/A April 26, 2007 Steve Elky Peer Review commentsN/A June 4, 2007 Kyle Hendrickson Added sample SOPsN/A July 30, 2007 Dawn Thompson QA & revision.N/A August 23,

2007Steve Elky, Kyle Hendrickson

Finalized updates

2.0 December 2, 2015

Sandy Chou Replace ITS with OCIO

ii Security Category: Moderate


Table of Contents

1 Introduction..............................................................................................................................51.1 Scope................................................................................................................................51.2 Contacts...........................................................................................................................61.3 Configuration Management of the Systems Administration Manual..............................61.4 Location of this Document..............................................................................................6

2 Operational Processes..............................................................................................................63 IT Security Related Processes..................................................................................................6

3.1 General IT Security Related Information........................................................................73.1.1 IT Contingency............................................................................................................73.1.2 Hosted Application IT Contingency Plan....................................................................73.1.3 Security Awareness.....................................................................................................83.1.4 Rules of Behavior........................................................................................................8

3.2 IT Security Related Processes Performed by System and Application Administrators. .83.2.1 Account Creation.........................................................................................................83.2.2 Creating Accounts with Elevated Privileges...............................................................93.2.3 Temporary and Emergency Accounts.......................................................................103.2.4 Initial Passwords........................................................................................................113.2.5 Disabling Accounts....................................................................................................113.2.6 Revoking System Access...........................................................................................123.2.7 Account Deletion.......................................................................................................133.2.8 Periodic Account Management Procedures...............................................................143.2.9 Event Based Account Management Procedures........................................................163.2.10 Password Reset Procedures...................................................................................173.2.11 Change Management.............................................................................................183.2.12 Patching.................................................................................................................183.2.13 Information Handling and Dissemination.............................................................183.2.14 Media Controls......................................................................................................193.2.15 Incident Handling (Including Theft)......................................................................193.2.16 Backup and Restore...............................................................................................19

3.3 IT Security Related Procedures Performed by the ISSO...............................................203.3.1 Monitoring.................................................................................................................203.3.2 Incident Handling......................................................................................................203.3.3 Reporting...................................................................................................................203.3.4 Risk Management......................................................................................................203.3.5 Annual Risk Review (Review of Security Controls).................................................203.3.6 Sanitization................................................................................................................21

3.4 IT Security Related Procedures Performed by the System Owner................................213.4.1 Risk Management......................................................................................................213.4.2 Hosted Application IT Contingency Plan Testing.....................................................213.4.3 Sensitive System Positions........................................................................................223.4.4 Separation of Duties..................................................................................................223.4.5 Establishing User Identity..........................................................................................233.4.6 Revoking System Access...........................................................................................23

iii Security Category: Moderate


Involuntary Separation...........................................................................................................243.4.7 Security Awareness Training.....................................................................................243.4.8 License Management.................................................................................................243.4.9 Maintenance...............................................................................................................24

3.5 IT Security Related Procedures Performed by the Information Owner........................253.6 IT Security Related Procedures Performed by OCIO....................................................25

3.6.1 Physical Security Controls.........................................................................................253.6.2 License Management.................................................................................................253.6.3 Maintenance...............................................................................................................253.6.4 Monitoring.................................................................................................................253.6.5 Backup and Restore...................................................................................................25

4 Appendix A – Backup Criteria..............................................................................................265 Appendix B – Software License & Maintenance Contract Tracking....................................276 Appendix C – Account Management Form...........................................................................28

Table of Figures

Figure 1 – Contacts..........................................................................................................................6Figure 2 – Outage Types, Impacts & Recovery Times...................................................................7Figure 3 – Account Management Recurring Reviews...................................................................14Figure 4 – Security Patch Tracking...............................................................................................18Figure 5 – Program Library Access Control..................................................................................19Figure 6 – Sensitive Positions........................................................................................................21Figure 7 – Allowable IT Security Role Combinations..................................................................22Figure 8 – Personnel Authorized to Perform Maintenance on System by Component.................24Figure 9 – Backup & Retention Requirements..............................................................................26Figure 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 AddressSystem Owner (SO)Information Owner (IO)3

System/Application Administrator (S/AA)4

Information System Security Officer (ISSO)Backup ISSODesignated 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 Supported

Outage Impact Allowable Outage Time

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

Damage Assessment Recovery Operations

Return to Operations

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

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 AwarenessThe 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 Driver’s 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 Driver’s License, Passport or financial account) must not be backed up or otherwise stored in either electronic or paper form.

4. Once an account is created, the identifying information (ID number from a Driver’s License, Passport or financial account) must be purged from the system as follows:

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

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 system2. From the command line type smitty3. Select Security & Users4. Select Users5. Select Add a User6. Enter the user name7. If the user is not an administrator, change true to false8. In HOME directory, add /home/username9. 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 user’s LOC badge to validate identity Delivering it to an authenticable repository (e.g., an active LOC voice mail or email box.) Directly to the supervisor that signed the account request form, checking the user’s LOC

badge to validate identity

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

1. Log onto the system2. 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 person’s departure



Inactive accounts must be deleted after 60 days of inactivity unless linked to personnel activity or the inactivity was initiated by the System Administrator due to a user’s leave or duty status

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

1. When notified of departing personnel, disable the account according to the SOP indicated in section 3.2.5 Disabling Accounts

2. Notify the System Owner, ISSO and other administrators as follows. Send an email with the following details:

Recipients: System Owner, ISSO and System Administrators (see section 1.2 Contacts for the names and email addresses of these persons)

Priority: High

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

Message: “The following account has been disabled on <System Name> and will be removed within 30 days: <User Account>”.

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 DeletionThis 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 system2. From the command line type smitty

3. Select Security & Users

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 ReviewsFrequency Review Type Resulting ActionWeekly 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 daysQuarterly User accounts list Ensure that you are being notified of any emergency or temporary accountsQuarterly 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 today’s 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>



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 [email protected] 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


mailto:[email protected]


<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 smitty2. Select Security & Users3. Select Users4. Select Change a User's Password5. Enter the user name6. Enter the new password7. 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 Designation

Link Date Release Summary of Vulnerability

Decision to Implement or Reason Patch Not Implemented

Decision Date

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 ControlCategory 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 MonitoringThe <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 HandlingThe 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 system’s 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 SanitizationOCIO 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)

OCIO’s 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 owner’s 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 PositionsPosition Reason for SensitivityISSO/Backup ISSOSystem AdministratorApplication AdministratorHelp 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 CombinationsDAA8 CO CISO OCIO

PMISSO SO IO SA

DAA N/A No No No No Yes Yes NoCO No N/A Yes Yes Yes No No NoCISO No Yes N/A Yes No No No NoOCIO PM

No Yes Yes N/A Yes No No No

ISSO No Yes No Yes N/A No No NoSO Yes No No No No N/A Yes NoIO Yes No No No No Yes N/A NoSA 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 [email protected] with following information:

Please add <insert names of account management personnel> to Terminators List. I am the System Owner for <System Name>.

Involuntary SeparationUnlike 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 TrainingThe 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 byComponent 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 OCIOThe 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 one)

Dynamic

Static

Value to the Mission of LC (Choose one)

High

Medium

Low

Required Confidentiality (Choose one)

High

Medium

Low

Required Integrity (Choose one)

High

Medium

Low

Required Availability (Choose one)

High

Medium

Low



Frequency of Backup Requested (Choose one or more)

Daily

Weekly

Monthly

Yearly

Number of Copies of the Backup Data (Specify for each type)

Tape

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 Package

Vendor Number of Licenses

Maintenance Period

Responsible Party

Notes



6 Appendix C – Account Management Form

<Update account management form as necessary.>

<System Name> Account Management Form

Date

Requestor Name

Requestor Title

Requestor Signature

Requested Action□Create Account □Delete Account

□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

Type of Proof of User Identity

□Badge □Driver’s License ID

□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


template for it security relevant sections of the systems

Documents