Product SiteDocumentation Site

Documentation 0.2

security-policy

Information Technology Security Policies

Edition 1

Mike McGrath

Fedora Project Infrastructure

Legal Notice

Copyright © 2009 The Fedora Project This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/).
Abstract
This is the official security policy for The Fedora Project. Below is a list of chapters for consideration. End users (non engineers/admins) should go directly to reading chapter '3 - End User Security Introduction'.
1. CSI Introduction
1.1. Introduction
1.2. What to do
1.3. External Sources and References
2. Host Security Introduction
2.1. Prerequisites
2.2. Host General Security
2.2.1. Suggested /etc/sysctl.conf config
2.3. IPTables Configuration
2.3.1. Suggested /etc/sysconfig/iptables configuration
2.4. Host Security Categories
2.5. System Identification
2.5.1. System Identification Example
3. End User Security Introduction
3.1. End User Standards
3.1.1. Administrative Exceptions
3.2. Security Incidents
3.3. External Sources and References
4. Incident Response
4.1. Introduction
4.1.1. The Rules
4.1.2. Incident Response Team
4.1.3. Management
4.2. Prerequisite Tasks
4.3. Assessment and Communication
4.3.1. Management Chain Notification
4.3.2. Threat Assessment
4.3.3. Entry Investigation
4.3.4. Impact-Assessment
4.3.5. Partner Communication
4.3.6. Public Disclosure
4.4. Actions
4.4.1. Investigation
4.4.2. Data Integrity Plan
4.4.3. Re-secure Environment Plan
A. Revision History
Index

Chapter 1. CSI Introduction

1.1. Introduction
1.2. What to do
1.3. External Sources and References

1.1. Introduction

The Community Services Infrastructure (CSI) standards are a group of documents designed to be implemented by the largest set of technology users in the world. They focus entirely around Red Hat compatable operating systems (Red Hat Enterprise Linux, Fedora, and CentOS, among others). Unlike most documentation, CSI aims to be standards based. Often checklists can be printed and checked off one by one to ensure compliance. There are three typical target audiences for CSI: System administrators; end users; and management, legal, and other oversight entities.
CSI is developed using open source methods. Any changes or suggestions should be directed to the CSI mailing list. Any questions regarding how or why to implement these changes should be directed to fedora-infrastructure-list@redhat.com.

1.2. What to do

You have been directed to read this document because it contains instructions or procedures you are expected to follow. Read through the items below and make note of any discrepancies or confusing items. It is important that you read, understand, and follow each step carefully. Do not make assumptions about whether a procedure has been completed. Check with the appropriate contacts or responsible parties to ensure proper compliance. It is recommended that you print a copy of these checklists and mark off each step as it is completed. In the event that a response to an item indicates non-compliance, make note of it and take appropriate steps to return to compliance.

1.3. External Sources and References

Chapter 2. Host Security Introduction

Mike McGrath

Fedora Infrastructure Lead
Fedora Project
2.1. Prerequisites
2.2. Host General Security
2.2.1. Suggested /etc/sysctl.conf config
2.3. IPTables Configuration
2.3.1. Suggested /etc/sysconfig/iptables configuration
2.4. Host Security Categories
2.5. System Identification
2.5.1. System Identification Example
This chapter focuses on host security, without making any distinction between "server" or "desktop" systems. Its goal is to actively protect machines wherever possible, and automatically detect any security violations. It is a work in progress.

2.1. Prerequisites

The topics discussed in this chapter include advanced topics which may require an RHCE level of knowledge and skills. Understanding every section of this standard is not a requisite for compliance, but it is recommended.

2.2. Host General Security

All of these settings should be placed in your /etc/sysctl.conf file. Once the file is edited, run sysctl -p to enable the settings on a persistent basis.
Required Config Lines
CompleteRequirementActionService/Config
ShouldSetnet.ipv4.ip_forward = 0[1]
ShouldSetnet.ipv4.conf.all.send_redirects = 0[2]
ShouldSetnet.ipv4.conf.default.send_redirects = 0[3]
MustSetnet.ipv4.conf.all.accept_redirects = 0[4]
MustSetnet.ipv4.icmp_echo_ignore_broadcasts = 1[5]
MustSetnet.ipv4.icmp_ignore_bogus_error_responses = 1[6]
MustSetnet.ipv4.tcp_syncookies = 1[7]
MustSetnet.ipv4.conf.all.log_martians = 1[8]
MustSetnet.ipv4.conf.default.log_martians = 1[9]
MustSetnet.ipv4.conf.all.accept_source_route = 0[10]
MustSetnet.ipv4.conf.default.accept_source_route = 0[11]
MustSetnet.ipv4.conf.all.rp_filter = 1[12]
MustSetnet.ipv4.conf.default.rp_filter = 1[13]
MustSetnet.ipv4.conf.default.accept_redirects = 0[14]
MustSetnet.ipv4.conf.all.secure_redirects = 0[15]
MustSetnet.ipv4.conf.default.secure_redirects = 0[16]

2.2.1. Suggested /etc/sysctl.conf config

# Kernel sysctl configuration file for Red Hat Linux
#
# For binary values, 0 is disabled, 1 is enabled.  See sysctl(8) and
# sysctl.conf(5) for more details.

# Controls IP packet forwarding
net.ipv4.ip_forward = 0

# Controls source route verification
net.ipv4.conf.default.rp_filter = 1

# Do not accept source routing
net.ipv4.conf.default.accept_source_route = 0

# Controls the System Request debugging functionality of the kernel
kernel.sysrq = 0

# Controls whether core dumps will append the PID to the core filename.
# Useful for debugging multi-threaded applications.
kernel.core_uses_pid = 1

# Controls the use of TCP syncookies
net.ipv4.tcp_syncookies = 1

# CSI Compliance
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.log_martians = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.default.secure_redirects = 0

2.3. IPTables Configuration

Edits to the iptables configuration can be made directly to /etc/sysconfig/iptables. To enable these rules restart iptables with the command service iptables restart.
Required Config Lines
CompleteRequirementActionConfig
MustSet*filter :INPUT DROP [] :FORWARD ACCEPT [] :OUTPUT ACCEPT [][17]
ShouldSet-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT[18]
ShouldSet-A INPUT -p icmp -j ACCEPT[19]
MaySet-A INPUT -i lo -j ACCEPT[20]
MustSet-A INPUT -p tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j REJECT[21]
MustSet-A INPUT -p tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j REJECT[22]
MustSet-A INPUT -p tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j REJECT[23]
MustSet-A INPUT -p tcp --tcp-flags FIN,SYN FIN,SYN -j REJECT[24]
MustSet-A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j REJECT[25]
MustSet-A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -j REJECT[26]
MustSet-A INPUT -p tcp --tcp-flags FIN,ACK FIN -j REJECT[27]
MustSet-A INPUT -p tcp --tcp-flags PSH,ACK PSH -j REJECT[28]
MustSet-A INPUT -p tcp --tcp-flags ACK,URG URG -j REJECT[29]
ShouldUse-A INPUT -p tcp -m tcp --dport $PORT -j ACCEPT[30]
ShouldUse-A INPUT -p udp -m udp --dport $PORT -j ACCEPT[31]
ShouldUse-A INPUT -p tcp -m tcp -s $IPADDRES/$NETMASK --dport $PORT -j ACCEPT[32]
ShouldUse-A INPUT -p udp -m udp -s $IPADDRES/$NETMASK --dport $PORT -j ACCEPT[33]
ShouldSet-A INPUT -j LOG --log-prefix "FW-REJECT "[34]
MustSet-A INPUT -j REJECT --reject-with icmp-host-prohibited[35]
Should notUse-j DROP[36]

2.3.1. Suggested /etc/sysconfig/iptables configuration

The configuration below enables people to connect to SSH services via TCP port 22. 
# Firewall configuration written by system-config-firewall
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j REJECT
-A INPUT -p tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j REJECT
-A INPUT -p tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j REJECT
-A INPUT -p tcp --tcp-flags FIN,SYN FIN,SYN -j REJECT
-A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j REJECT
-A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -j REJECT
-A INPUT -p tcp --tcp-flags FIN,ACK FIN -j REJECT
-A INPUT -p tcp --tcp-flags PSH,ACK PSH -j REJECT
-A INPUT -p tcp --tcp-flags ACK,URG URG -j REJECT

# Add enabled ports here
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

# Log and reject everything else
-A INPUT -j LOG --log-prefix "FW-REJECT "
-A INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT

2.4. Host Security Categories

Every host should be placed into a specific security category: Low, Moderate or High. The classification should be based on the impact of a total compromise of a specific host. For this we use the same classification definitions as NIST recomments. See this excerpt below as taken from SP800-123 [37]:
Required Config Lines
CategoryDescription
LowThe potential impact is LOW if the loss of confidentiality, integrity, or availability could be expected to have limited adverse effect on organizational operations, organizational assets or individuals. A limited adverse effect means that, for example, the loss of confidentiality, integrity, or availability might (i) cause a degradation in mission capability to an extent and duration that the organization is able to perform its primary functions, but the effectiveness of the functions is noticably reduced; (ii) result in minor damage to organizational assets; (iii) result in minor financial loss; or (iv) result in minor harm to individuals.
ModerateThe potential impact is MODERATE if the loss of confidentiality, integrity, or availability could be expected to have a serious adverse effect on organization operations, organizational assets, or individuals. A serious adverse effect means that, for example, the loss of confidentiality, integrity, or availability might (i) cause a significant degradation in mission capability to an extent and duration that the organization is able to performe its primary functions, but the effectiveness of the function is significantly reduced; (ii) result in significant damage to organizational assets; (iii) result in significant financial loss; or (iv) result in significant harm to individuals that does not involve loss of life or serious life threatnening injuries.
HighThe potential impact is HIGH if the loss of confidentiality, integrity, or availability could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals. A severe or catastrophic adverse effect means that, for example, the loss of confidentiality, integrity, or availability might (i) cause a severe degradation in or loss of confidentiality, integrity, or availability might (i) cause a severe degradation in or loss of mission capability to an extent and duration that the organization is not able to perform one or more of its primary functions; (ii) result in major damage to organizational assets; (iii) result in major financial loss; or (iv) result in severe or catastrophic harm to individuals involving loss of life or serious life threatning injuries.

2.5. System Identification

Every host should have a basic summary of the hosts purpose, contact info and security category. This summary should be listed, in plain text, in /etc/system_identification. This summary should contain the following information:
  • Security Category - Either Low, Moderate or High. See "Host Security Categories" above for more information.
  • Primary Contact - Primary owner of the system
  • Purpose - Basic purpose of this host
  • Environment - Environment of the system (production, staging, testing, etc)
  • Relationship - Relationship of this host to other hosts.

2.5.1. System Identification Example

Security Category: Moderate
Primary Contact: Joe Example example@example.com - (555) 322-9511
Environment: Production
Purpose: Provide web services
Relationship: This host relies on db[1-2] for it's primary data layer and is contacted by proxy[1-5] for that service.

This document is provided as part of CSI standards.  See http://infrastructure.fedoraproject.org/csi/security-policy/ for more information.

[1] Unless this host serves as a network device, do not pass traffic between networks.

[2] Unless this host serves as a network device, do not act like a network device.

[3] Unless this host serves as a network device, do not act like a network device.

[4] Do not permit outsiders to alter routing tables.

[5] Prevents this host from joining a smurf attack

[6] Protection from bad ICMP error messages

[7] Enables syncookies for protection against syn flood attacks

[8] Log any spoofed, source routed and redirect packets

[9] Log any spoofed, source routed and redirect packets

[10] Do not allow source routed packets

[11] Do not allow source routed packets

[12] Enable reverse path filtering

[13] Enable reverse path filtering

[14] Do not allow outsiders to alter routing tables.

[15] Do not allow outsiders to alter routing tables.

[16] Do not allow outsiders to alter routing tables.

[17] First 4 lines

[18] Disabling will break many network protocols, like TCP. Disable this rule only if you know what you are doing.

[19] Disable for more security, but understand that doing so creates more difficulty in network troubleshooting.

[20] Allow all localhost activity. Generally a good idea, so do not disable this unless you know what you are doing.

[21] The combination of these TCP flags is not defined. Accepting packets so marked may cause unexpected results.

[22] The combination of these TCP flags is not defined. Accepting packets so marked may cause unexpected results.

[23] The combination of these TCP flags is not defined. Accepting packets so marked may cause unexpected results.

[24] The combination of these TCP flags is not defined. Accepting packets so marked may cause unexpected results.

[25] The combination of these TCP flags is not defined. Accepting packets so marked may cause unexpected results.

[26] The combination of these TCP flags is not defined. Accepting packets so marked may cause unexpected results.

[27] The combination of these TCP flags is not defined. Accepting packets so marked may cause unexpected results.

[28] The combination of these TCP flags is not defined. Accepting packets so marked may cause unexpected results.

[29] The combination of these TCP flags is not defined. Accepting packets so marked may cause unexpected results.

[30] This rule opens specific TCP ports to the world. When using this example, replace $PORT with a TCP port number such as 80 for HTTP traffic.

[31] This rule opens UDP ports to the world. When using this example, replace $PORT with a UDP port number such as 161 for SNMP traffic.

[32] This rule opens TCP ports to specific hosts or networks. Using an IP address without a netmask is proper. If a network address is defined, the netmask is required. When using this example, replace $PORT with a TCP port number such as 80 for HTTP traffic.

[33] This rule opens UDP ports to specific hosts or networks. Using an IP address without a netmask is proper. If a network address is defined, the netmask is required. When using this example, replace $PORT with a UDP port number such as 161 for SNMP traffic.

[34] Before last line

[35] As last line

[36] This flag violates some known standards and makes troubleshooting more difficult. The security added is debatable.

[37] See http://csrc.nist.gov/publications/nistpubs/800-123/SP800-123.pdf for more information.

Chapter 3. End User Security Introduction

Mike McGrath

Fedora Infrastructure Lead
Fedora Project
3.1. End User Standards
3.1.1. Administrative Exceptions
3.2. Security Incidents
3.3. External Sources and References
End user security is a critical aspect of a total security solution. All too often security breaches are the result of human error. Every person involved in an information system must take an active role to ensure their own security and the security of the organization. High levels of technical skill are not required in all cases to maintain a secure environment. This chapter does not focus on technical details such as computer settings. Instead, it focuses on actions that can and should be taken by every individual to maintain a secure working environment.

3.1. End User Standards

Users who have questions about any of the items below should contact fedora-infrastructure-list@redhat.com for answers. Do not ignore an item because you are confused about its meaning.
Required User Actions
CompleteRequirementActionComment
Must NotPassword DisseminationAny passwords must be kept secret, known only to the person who created them. Under no circumstances should a user give a password to anyone, unless required by law enforcement. Discuss with your legal counsel in the event of a required legal dissemination. Passwords should not be given to management, technical professionals, or anyone else who asks for them.
Must NotHost authenticationDo not log in to any password- or key-protected services from any hosts that are not your personal workstation or a machine or host run by The Fedora Project.
Must NotPassword UsageUsers must not type their plain text passwords into a file on an unencrypted filesystem. Users must also ensure they do not display their passwords on a terminal using any method that records them to an alternate, unsecured location. If, for some reason, a password is displayed in this way, such as typing the password directly in a shell command, be sure to deactivate the retention of shell history, such as unset HISTFILE in the case of the bash shell. When using this method, create a new shell, deactivate the shell history retention, run your commands and log out of that shell as soon as possible. Shell history is written at logout time, so you cannot "hide" commands by temporarily turning off shell history retention.
MustPassword EntropyAll passwords must meet all of the following requirements: (1) Passwords must be at least 8 characters long. (2) Each password must have at least 1 numeric character. (3) Each password must have at least 1 lower case letter. (4) Each password must have at least 1 upper case letter. (5) Each password must have at least one non-alphanumeric character in them.
Shouldssh ProxyCommandWhen using a gateway or proxy host to access another group of machines from your workstation, the most secure option is to use the ssh command's ProxyCommand option. Refer to man ssh_config for more information on proper setup.
MustDesktop LockingAny time you physically leave your workstation or any other host that contains a user input or output device such as a keyboard, mouse, or monitor, either lock the screen or shell, or log out completely.
Should NotPassword ReuseAvoid reusing passwords in environments where there is not a single sign on capability. This is especially important in the case of password protected keys, encrypted shares, access to sensitive personal sites such as banking or other finances, and so on. Always maintain different passwords wherever possible.
Should NotSoftware installationUsers should not install any unapproved software. Contact your helpdesk for more information at fedora-infrastructure-list@redhat.com. Advanced or power users who are running programs or scripts that have not been installed by the helpdesk may be liable for any damage they do. Whenever possible scripts or programs should be run under a freshly created user account with standard privileges, to limit access to sensitive passwords or keys.
Must NotRelocate information offsiteInformation contained on file shares, or in databases on infrastructure servers should be assumed to have a non-shareable license. This information should not be transfered offsite without the express written consent of both admin fedoraproject.org and admin fedoraproject.org, including printed copies or data in any form. Exceptions to this rule may include logs that contain no private information, as defined by the applicable privacy policy.
MustKey SecurityKeys retained on any host must be readable only by the owner or group of that key, and ideally should retain file permissions that allow the user owner to read them, but prevent any other access. In UNIX parlance this is a permission setting of 0400.
MustKey passwordsAll private keys must be encrypted with unique passwords. These passwords must meet the criteria laid out above.
MustEncryption BackupsUsers who use encryption keys must retain backups of those keys in a location that can be taken offline, ideally a USB key or other detachable device. This device must be kept in a secure location and only connected to a host while a backup is being made, or while a key from that device is being used or restored. The filesystem on which this key backup exists should be encrypted.
MustStolen or Missing EquipmentAny stolen or missing equpment containing any sensitive data including passwords or keys, whether encrypted or not, must be reported as quickly as possible. When handled expediently, issues due to missing equipment can be easily mitigated.

3.1.1. Administrative Exceptions

At times, engineers and administrators will need to work in systems where passwords or keys must be shared. In these instances the following exceptions apply.
Required User Actions
CompleteRequirementActionComment
MustPassword SharingWhen a password is not directly tied to a human-user (for example, a mail management software password or network device password), the shared password must be stored and shared in an encrypted format accessible only by an assigned group. When any user is removed from this group, that password must be changed. Shared passwords should be avoided wherever feasible.
MustRole AccountsAccounts that provide access to resources for purpose of automation or other system related access must be tied to an individual user and not shared. The person associated with that account may change, but no more then one person at a time should be responsible for a role based account.
MustData Access PasswordsPasswords that provide access to data resources, such as a database for a web application, are considered shared passwords. See the exception on "Password Sharing" for details.
Must NotSelf AccessAdministrators and users must not give themselves access to resources unless there is an extant emergency or a setup issue. Follow normal procedures to obtain group membership or sponsorship.

3.2. Security Incidents

Security incidents are serious matters. Any detection of a security breach or malicious behavior should immediately be reported. Users should contact the security team directly at admin fedoraproject.org. Please do not share any details related to the incident with anyone other than the initial contact. Maintaining confidentiality protects you and The Fedora Project from further internal attacks. A potential attacker that becomes aware of detection may cover tracks or change behavior suddenly, which makes investigation more difficult. On the other hand, if the security team is aware of and tracking an attack in progress, the chances of catching the attacker greatly increases.

3.3. External Sources and References

Chapter 4. Incident Response

Mike McGrath

Fedora Infrastructure Lead
Fedora Project
4.1. Introduction
4.1.1. The Rules
4.1.2. Incident Response Team
4.1.3. Management
4.2. Prerequisite Tasks
4.3. Assessment and Communication
4.3.1. Management Chain Notification
4.3.2. Threat Assessment
4.3.3. Entry Investigation
4.3.4. Impact-Assessment
4.3.5. Partner Communication
4.3.6. Public Disclosure
4.4. Actions
4.4.1. Investigation
4.4.2. Data Integrity Plan
4.4.3. Re-secure Environment Plan

4.1. Introduction

This document sets out the procedures that are to be followed in the event of a security-related incident. Each incident will have an acting incident coordinator at all times. The incident coordinator is charged with coordinating task responsibilities, and with finding another coordinator in the event that he or she becomes unavailable.

4.1.1. The Rules

You have been directed to read this policy because you are either involved in an incident, or because you have been asked to be part of an investigation related to a security incident. While performing the tasks below please keep the following in mind.
Incident Rules
CompleteRequirementActionComment
Must NotMake ChangesUnless it is part of a task that is assigned to you, do not make any changes to a host without permission from the incident coordinator. This includes shutting services down, logging in or out, and other configuration changes.
Must NotTask AssignmentIncident team members must not work on tasks that have not explicitly been assigned to them without discussing it with the incident coordinator or the task leader. [38]
MustInformation DisclosureDiscussion of the incident must only happen between the members of the team chosen by the incident coordinator. Before discussing any incident with someone, make sure they are on the list of team members. [39]
MustAssumptionsDo not make any assumptions about task assignments or completion. Discuss any concerns you have with the incident coordinator.

4.1.2. Incident Response Team

Anyone specifically contacted and assigned responsibility for a task related to this incident automatically becomes a member of the incident response team. The team may include non-technical members involved with marketing or legal tasks.

4.1.2.1. Incident Coordinator

The incident coordinator is accountable for all technical issues related to the incident. If a compromise is involved, the incident coordinator is ultimately charged with discovering the nature of the incident; assessing the extent of any damage or risk to services, users, or data; concluding the incident as quickly and efficiently as possible; and creating and implementing a plan for mitigation and prevention of future damage or risk. This role is largely technical, but the incident coordinator must also work with team members to coordinate and delegate tasks. This coordination includes, but is not limited to, working with hosting providers, providing or summarzing information for reporting or dissemination, and ensuring that team members are following the incident respose plan.
The tasks below must be completed in an order determined by the incident coordinator. Tasks that require or depend on another task are to be explicitly so defined. As each task is completed it should be marked completed on the task list. Some tasks require written answers to questions. Coordinate the answers to these questions for factual correctness among chosen parties via a secure communications channel.

4.1.2.2. Task Coordinator

Each task is to be assigned to a task coordinator. Each task must be completed and the results (if any) should be given back to the incident coordinator. Do not work on tasks that have not been assigned to you. Multiple team members may be working on one task, though only one of them is to be designated the coordinator of that task. Many tasks can be accomplished in parallel, but some tasks must be processed sequentially. Tasks are to be labeled if they must be completed sequentially. Any assignment with a "sign off" field must be signed off by the task coordinator to ensure it has been completed and verified.
It is also the responsibility of the task coordinator to ensure that once a task is done, the task is marked as completed along with the identity of the team member who completed it. If a team member is unable to complete a task, it is the team member's responsibility to inform the incident coordinator. The team member should then attempt to find a replacement from the incident response team, and must notify the incident coordinator whether a replacement has been found. The incident coordinator is ultimately responsible for ensuring that all tasks are assigned properly.

4.1.3. Management

Generally the incident coordinator reports to or works with one or more further managers. Although managers may not be involved directly in specific tasks, it is important to keep them informed of the plan for investigation and recovery, and the overall progress. Managers are responsible for ensuring the technical members of the incident response team are able to work as unfettered as possible, and that the appropriate entities outside the team are kept informed properly. For instance, it should not be the responsibility of the technical team to also manage communication with end users.

4.2. Prerequisite Tasks

The tasks in this listing must be started prior to any other tasks. Some tasks, like the time line, will be ongoing.
Prerequisite Tasks
Sign offTaskDescription
SnapshotIf possible, take two LVM snapshots of all volumes on affected systems. If possible, take a snapshot at the disk level to get an entire disk image, as opposed to logical volume images. If LVM is not being used, try to dd the block device somewhere piping through ssh.
Snapshot CopyWork with the incident coordinator to copy the images from the "Snapshot" task above to an agreed secure location. Provide a size estimate. Include basic details about the images, including the architecture and the requirements to restore these images to a running state.
Log CopyMake an off-site copy of any relevant logs.
Incident Response Team ListCreate and maintain a list of people who are aware of the compromise and its details. Once the list is made, it must not grow without the approval of the incident coordinator unless already specified in this incident response plan.
Time lineCreate and maintain a time line, sorted by the actual time an event took place. The timeline should indicate the actual time of events and not simply the time of discovery.
Disabling AuthenticationAside from the incident response team, disable access to any hosts that are suspected as compromised. In extreme cases this may involve disabling central authentication altogether.

4.3. Assessment and Communication

These tasks are designed around threat assessment and communication. Communication tasks include apprising appropriate management chains of the problem and assembling correct information for dissemination to the public.

4.3.1. Management Chain Notification

This section sets out the method by which the management chain is to be informed that an incident has been discovered, and reports and updates are to be sent as investigation, mitigation, and repairs are completed.
Management Chain Notification
Sign offTaskDescription
Notify ManagementThis is the initial contact through which management is notified that an incident has either occurred or is in progress. Contact is to be made by phone, and all contact numbers should be used until either the manager has been reached, or the list of contact numbers has been exhausted. A message is to be left at each number if no one answers. Phone contact must be followed up by email, whether or not the manager was reached directly. Ensure the following people have been contacted: legal@fedoraproject.org, fpl@fedoraproject.org
Threat AssessmentComplete the Threat Assessment below, and email it to: legal@fedoraproject.org, fpl@fedoraproject.org. Inform the recipients that until the final assessment has been completed, the information provided should be considered preliminary. Additionally include a copy of the time line in its current state.

4.3.2. Threat Assessment

The Threat Assessment is to be written for dissemination to management and communication personnel listed as team members. Provide high level technical details, and remember the people reading this assessment may not be technical. Include appropriate explanations for all technical terms used in the assessment.
Threat Assessment Sign off
Sign offTaskDescription
Threat AssessmentAnswer the questions below.
For each of the following questions, provide an answer that takes into account each of the hosts that have been affected and the information on those hosts.
Threat Assessment
CompleteQuestionAnswer
Could this incident impact end users or customers?
Could this incident impact contributors, contractors, co-workers, or partners?
Could private data have been read or written to by the attacker?
Has private data been read or written to by the attacker?
Provide an estimate of how long the incident has been occurring.

4.3.3. Entry Investigation

In the event that the incident involves a compromise of security such as an intrusion, it is important to determine the point of entry. Below are questions that should be answered in the event of such a compromise, prior to any mitigation efforts such as rebuilding or repairing services.
Entry Investigation Sign off
Sign offTaskDescription
Entry InvestigationAnswer the questions below.
Entry Investigation
CompleteQuestionAnswer
How did the attacker gain entry to the services?
What is the likelihood the incident was caused by (1) a malicious associate, or (2) someone without any prior association with The Fedora Project?
Did the attacker use a known or unknown vulnerability in software installed on the system?
Did the attacker use physical access to any of the host(s) covered by this plan to gain additional access?
Did the attack appear to come from other machines operated by The Fedora Project?
Did the attack appear to come from machines operated by any of our hosting providers?

4.3.4. Impact-Assessment

The impact assessment is closely related to the threat assessment but measures in greater detail what services and servers are are affected by this incident. Include as much specificity as possible at the time of the assessment. As new facts or details emerge, updates of the impact assessment are to be emailed to the incident response team.
Impact Assessment Sign off
Sign offTaskDescription
Impact AssessmentAnswer the questions below.
Impact Assessment
CompleteQuestionAnswer
Which hosts are impacted?
Which services are potentially impacted?
Which databases or other data stores require auditing to ensure their integrity?

4.3.5. Partner Communication

Partners include any hosting providers, contractors, or other professionals that are impacted by or involved with this incident. Partner involvement may arise from co-ownership of equipment, provision of services, or shared connections of network hardware. For example, an incident that involves unauthorized physical access to a console may involve the hosting provider responsible for the security of that console.
Any incident that involves a previously undisclosed software vulnerability should include the upstream software provider as a partner.
Any partner notified as part of this incident response plan is considered part of the incident response team.
Partner Notification
Sign offTaskDescription
Partner NotificationAt the discretion of the incident coordinator, contact partner with details about the incident for further investigation.

4.3.6. Public Disclosure

fpl@fedoraproject.org must sign off on these tasks unless he/she delegates one or more of them to someone else. These tasks should be completed as soon as is feasible, and may consist of multiple notifications and updates, or be combined into one notification if the incident is discovered and fixed quickly. Each of the tasks listed below must be completed.
Notification Tree
Sign offTaskDescription
Initial NotificationLet everyone know that an incident has happened.
Partner IntegrityWhen a partner has been determined to be affected and therefore notified (refer to Section 4.3.5, “Partner Communication”), outgoing notifications must not jeopardize the integrety of any investigations underway by those partners.
Service RepairOnce a service repair plan is formulated, notify all affected parties about any service availability changes during rebuild and repair.
CredentialsOnce the environment is deemed secure, notify all affected parties and institute a system-wide password change by all account holders.
EntryOnce the entry point has been located, assessed, and repaired, and investigations are completed, notify all affected parties of the cause of the incident and the specific repairs undertaken to prevent recurrence.
Time line/PostmortemOnce the rebuild/repair phase is complete and services are returned to normal, send a summary of the repairs undertaken and, if appropriate, the rationale for these actions. This communication should include the same time line used by the incident response team.

4.4. Actions

The following actions must be taken to correct issues related to the incident and ultimately restore service to nominal levels. Work with the incident coordinator or task manager to complete the tasks listed below.

4.4.1. Investigation

This section of the incident response plan includes some techniques that should be used in the event an incident involves an intrusion or other unauthorized access, to determine the nature of the access and whether it is ongoing.
Investigation
Sign offTaskDescription
InvestigationOnce the intrusion entry point discovered, send a summary and details to the incident coordinator.
MitigationEnsure the point of entry is closed or properly secured.
Investigation Tasks
CompleteTaskDescription
Increase LoggingIncrease logging of any and all services suspected of being involved in the attack to a level sufficient to determine that no unauthorized access is ongoing.
File NotificationsCompare files to known good copies, as well as backup copies. Use best practices such as the rpm -V command to ensure the integrity of system contents. If appropriate, examine file metadata such as change, modify, and access times to develop information about the nature of the incident.

4.4.2. Data Integrity Plan

The data integrity plan is designed to identify data that may have been accessed in an unauthorized fashion, to identify data that may have been changed as a result of that access, and to ensure that all impacted data is safe for continued use.
Data Integrity Plan
Sign offTaskDescription
Data IntegrityEnsure the below table has been completed and is accurate.
Data Integrity Plan
CompleteTaskDescription
Configuration ManagementEnsure the configuration management repository is intact and has not been altered as a result of an unauthorized access. Compare to off-site backups if necessary.
Database DataVerify hosts containing any databases, and the data that resides therein. The nature of this task depends on the extent of any unauthorized access. The incident response team must reach an informed consensus on the procedures required.
Shared dataVerify shared data has not been altered as a result of an unauthorized access. Malicious files that may have been left behind during the incident should be listed and removed from the system. Make a list of files that have changed during the incident window and verify them.
Temporary or Cached DataRemove any temporary or cached data and rebuild from scratch. If this procedure is not feasible, verify the local cache against a known good remote cache.

4.4.3. Re-secure Environment Plan

The Re-secure Environment Plan is designed to ensure the attacker has not left back doors or other malicious software on covered hosts. Even if the intruder has been blocked from re-entry through the original unauthorized access point, it is possible for an intruder to leave alternate re-entry points using certain files on the file system. Verification of each file is a time-consuming process. Therefore simply rebuilding hosts is often a faster and more reliable alternative. This possibility is one of the reasons for a robust configuration management policy.
Secure Environment Sign off
Sign offTaskDescription
Secure EnvironmentEnsure the tasks below have been completed successfully.
Secure Environment
CompleteTaskDescription
Host RebuildsRebuild any hosts that have been compromised or are suspected of compromise. Work with the incident coordinator and task coordinator to develop a strategic order for rebuilding if necessary.

[38] Maintaining strict task separation ensures that team members can work independently and not step on each others toes.

[39] Due to the sensitive nature of a security event, additional information should not be exposed to the attacker(s). This restriction has the unfortunate side effect of decreasing openness about the handling of the event. Timely communication to service users and efficient resolution of the problem can help decrease this effect.

Revision History

Revision History
Revision 1Wed Apr 28 2010Mike McGrath
Initial movement from the old publican format to 1.6

Index

E

External Sources and References, External Sources and References