Template for IT Security Relevant Sections of the Systems ...



[pic]

Systems Administration Manual

Version

Revision History

|Revision |Date |Revised By |Notes |

|N/A |April 29, 2005 |Steve Elky |Created generic procedures for adoption by other system owners. |

|N/A |February 16, 2006 |Steve Elky |Updated to reflect lessons learned |

|N/A |March 13, 2007 |Steve Elky |Updated from 3/2007 review of Directives |

|N/A |April 26, 2007 |Steve Elky |Peer Review comments |

|N/A |June 4, 2007 |Kyle Hendrickson |Added sample SOPs |

|N/A |July 30, 2007 |Dawn Thompson |QA & revision. |

|N/A |August 23, 2007 |Steve Elky, Kyle |Finalized updates |

| | |Hendrickson | |

|2.0 |December 2, 2015 |Sandy Chou |Replace ITS with OCIO |

| | | | |

| | | | |

| | | | |

| | | | |

| | | | |

| | | | |

| | | | |

| | | | |

| | | | |

| | | | |

| | | | |

| | | | |

| | | | |

| | | | |

| | | | |

| | | | |

| | | | |

| | | | |

| | | | |

| | | | |

| | | | |

Table of Contents

1 Introduction 5

1.1 Scope 5

1.2 Contacts 6

1.3 Configuration Management of the Systems Administration Manual 6

1.4 Location of this Document 6

2 Operational Processes 6

3 IT Security Related Processes 6

3.1 General IT Security Related Information 7

3.1.1 IT Contingency 7

3.1.2 Hosted Application IT Contingency Plan 7

3.1.3 Security Awareness 8

3.1.4 Rules of Behavior 8

3.2 IT Security Related Processes Performed by System and Application Administrators 8

3.2.1 Account Creation 8

3.2.2 Creating Accounts with Elevated Privileges 9

3.2.3 Temporary and Emergency Accounts 10

3.2.4 Initial Passwords 11

3.2.5 Disabling Accounts 11

3.2.6 Revoking System Access 12

3.2.7 Account Deletion 13

3.2.8 Periodic Account Management Procedures 14

3.2.9 Event Based Account Management Procedures 16

3.2.10 Password Reset Procedures 17

3.2.11 Change Management 18

3.2.12 Patching 18

3.2.13 Information Handling and Dissemination 18

3.2.14 Media Controls 19

3.2.15 Incident Handling (Including Theft) 19

3.2.16 Backup and Restore 19

3.3 IT Security Related Procedures Performed by the ISSO 20

3.3.1 Monitoring 20

3.3.2 Incident Handling 20

3.3.3 Reporting 20

3.3.4 Risk Management 20

3.3.5 Annual Risk Review (Review of Security Controls) 20

3.3.6 Sanitization 21

3.4 IT Security Related Procedures Performed by the System Owner 21

3.4.1 Risk Management 21

3.4.2 Hosted Application IT Contingency Plan Testing 21

3.4.3 Sensitive System Positions 22

3.4.4 Separation of Duties 22

3.4.5 Establishing User Identity 23

3.4.6 Revoking System Access 23

Involuntary Separation 24

3.4.7 Security Awareness Training 24

3.4.8 License Management 24

3.4.9 Maintenance 24

3.5 IT Security Related Procedures Performed by the Information Owner 25

3.6 IT Security Related Procedures Performed by OCIO 25

3.6.1 Physical Security Controls 25

3.6.2 License Management 25

3.6.3 Maintenance 25

3.6.4 Monitoring 25

3.6.5 Backup and Restore 25

4 Appendix A – Backup Criteria 26

5 Appendix B – Software License & Maintenance Contract Tracking 27

6 Appendix C – Account Management Form 28

Table of Figures

Figure 1 – Contacts 6

Figure 2 – Outage Types, Impacts & Recovery Times 7

Figure 3 – Account Management Recurring Reviews 14

Figure 4 – Security Patch Tracking 18

Figure 5 – Program Library Access Control 19

Figure 6 – Sensitive Positions 21

Figure 7 – Allowable IT Security Role Combinations 22

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

Figure 9 – Backup & Retention Requirements 26

Figure 10 – Software License/Maintenance Contract Information 27

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.

1 Scope

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

• Systems Administrators

• Application Administrators[1]

• Account Management Personnel

• Help Desk Personnel

• Information System Security Officers (ISSO)[2]

• System Owner (SO)

• Information Owners (IO)

2 Contacts

Figure 1 – Contacts

|Role |Title |Address |Phone Number |Email Address |

|System Owner (SO) | | | | |

|Information Owner (IO)[3] | | | | |

|System/Application Administrator | | | | |

|(S/AA)[4] | | | | |

|Information System Security | | | | |

|Officer (ISSO) | | | | |

|Backup ISSO | | | | |

|Designated Approving Authority | | | | |

|(DAA) | | | | |

3 Configuration Management of the Systems Administration Manual

This Systems Administration Manual is under control of the Configuration Management Plan.

4 Location of this Document

Hard copies of this document are stored in .

Electronic copies of this document are stored at

Operational Processes

IT Security Related Processes

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

• System and Application Administrators (including Help Desk and Account Management personnel)

• Information System Security Officer

• System Owner

• Information Owner

• Office of the Chief Information Office Services

1 General IT Security Related Information

The following sections detail key operational details.

1 IT Contingency

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

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

|Business Function Supported |Outage Impact |Allowable Outage Time |

| | | |

| | | |

| | | |

| | | |

| | | |

Contingency activities for are shared between 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).

2 Hosted Application IT Contingency Plan

The IT Contingency Plan is a standalone document, containing the contingency SOPs.

3 Security Awareness

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

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.

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.

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, must undergo 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 (Appendix C – Account Management Form). This Form must state the badge number[6] of the individual. The accounts management personnel must validate that the user has completed the Security Awareness Training. This information can be obtained from the Office of Management and Training.

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

1. To establish identity, the user must be required to submit identifying information consisting of the ID number from a Driver’s License, Passport or financial account.

2. Before creating an account for an individual without a Library of Congress building access badge, the Application Administrator must inspect and verify the identifying information provided by applicant through record checks either with the applicable agency or institution or through credit bureaus or similar databases, and confirms that the identifying information in records are on balance consistent with the sensitivity of the application and sufficient to identify a unique individual.

3. The identifying information (ID number from a Driver’s License, Passport or financial account) must not be backed up or otherwise stored in either electronic or paper form.

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

a. Review the account using 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

1. Log onto the system

2. From the command line type smitty

3. Select Security & Users

4. Select Users

5. Select Add a User

6. Enter the user name

7. If the user is not an administrator, change true to false

8. In HOME directory, add /home/username

9. Select false for “Another user can SU TO USER.”

10. Press the Enter button

2 Creating Accounts with Elevated Privileges

Before an administrative account can be created for anyone in the , requires the acceptance of the Privileged User Rules of Behavior. These rules serve as an agreement between the manager and the privileged users of the 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

1. Send an email to the ISSO for (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 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.

1 Temporary and Emergency Account Creation

1. Using , 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 account from ”

e. Priority: High

f. Reminder: Enabled

2 Temporary and Emergency Account Deletion

When receiving a calendar appointment notification with a subject of “Reminder to remove the from ” follow these procedures.

1. Using on , 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.

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:

• 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

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

1. Disable the account as follows:

a. Log onto the system

b. From the command line type smitty

c. Select Security & Users

d. Select Users

e. Select Lock / Unlock a User's Account

f. Set the lock value to True

g. Enter the user name

h. Press the Enter button

SOP to Re-Enable an Account

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

1. Log onto the system

2. From the command line type smitty

3. Select Security & Users

4. Select Users

5. Select Lock / Unlock a User's Account

6. Set the lock value to False

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

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 from

• Message: “The following account has been disabled on and will be removed within 30 days: ”.

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 “

• 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 (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 “ 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 on 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 on the next business day: .

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.

7 Account Deletion

This section only contains the procedures for deleting user accounts. For information on how to handle separation from the organization or removal of access permissions, see Section 3.4.4.

1. Log onto the system

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

8 Periodic Account Management Procedures

Perform account management reviews per Figure 3 – Account Management Recurring . Ensure that the Resulting Action is taken. The ISSOs will audit and report on this activity.

Figure 3 – Account Management Recurring Reviews

|Frequency |Review Type |Resulting Action |

|Weekly |Account usage activity |Ensure accounts that have been unused for 30 days are disabled |

|Weekly |Privileged User list |Ensure any accounts used by Privileged Users who were reassigned or have left the Library are |

| | |disabled immediately and deleted within 60 days |

|Quarterly |User accounts list |Ensure that you are being notified of any emergency or temporary accounts |

|Quarterly |Account usage activity |Ensure accounts that have been unused for 90 days are deleted (note that this assumes 30 days |

| | |of inactivity and 60 days of the account being disabled) |

Weekly Account Maintenance Procedures

On the first working day of every week, do the following:

1. Use on to review all accounts for inactivity.

2. Using , 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 (see section 1.2 Contacts for this information)

b. Subject: Notice: Planned Removal of Inactive Account(s) on

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 after 50-60 days of inactivity: ”.

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: will be removed from 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 (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

On the first working day of every quarter, do the following:

1. Using 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 (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 on the next business day.: ”.

• 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

d. Subject: “Remove account: from ”

e. Priority: High

4. When receiving a calendar appointment notification with a subject of “Remove 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).

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

When receiving a calendar appointment notification that contains a subject that begins “Remove from …” 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

When receiving a calendar appointment notification that contains a subject that begins “Remove from …” 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@ 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

Remove the account as directed by the System Owner or designate as indicated in 3.2.7 Account Deletion.

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

The user must identify themselves to the account management personnel and then provide the verbal authenticator before the password will be changed or the account will be locked out. The account management personnel can prompt the user by asking the “security question.”

1. From the command line type smitty

2. Select Security & Users

3. Select Users

4. Select Change a User's Password

5. Enter the user name

6. Enter the new password

7. Update the Accounts with Recently Reset Passwords document stored in to include the name of account for which the password was just reset.

SOP for Newly Reset Password Review

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download