template for it security relevant sections of the systems
Post on 16-Jan-2017
215 Views
Preview:
TRANSCRIPT
<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
<SYSTEM NAME> SYSTEMS ADMINISTRATION MANUAL <Month DD, YYYY>
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
<SYSTEM NAME> SYSTEMS ADMINISTRATION MANUAL <Month DD, YYYY>
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
<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 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.
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 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.
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 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.
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 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
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 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.
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 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
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 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:
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 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
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 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
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 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>
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 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).
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 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
20 Security Category: Moderate
<SYSTEM NAME> SYSTEMS ADMINISTRATION MANUAL <Month DD, YYYY>
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.
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 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
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)
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.
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 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.)
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 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.
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 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.
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 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
28 Security Category: Moderate
<SYSTEM NAME> SYSTEMS ADMINISTRATION MANUAL <Month DD, YYYY>
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
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 Package
Vendor Number of Licenses
Maintenance Period
Responsible Party
Notes
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
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
31 Security Category: Moderate
top related