Community Services Infrastructure Standards

Legal Notice

Copyright (c) 2009 by 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/).
Community Services Infrastructure Standards
1. CSI Introduction
1.1. Introduction
1.2. What to do
1.3. External Sources and References
2. Language and Terms
2.1. Introduction
2.2. External Sources and References
Security Policy
1. Host Security Introduction
1.1. Prerequisites
1.2. Host General Security
1.2.1. Suggested /etc/sysctl.conf config
1.3. IPTables Configuration
1.3.1. Suggested /etc/sysconfig/iptables config
2. End User Security Introduction
2.1. End User Standards
2.1.1. Administrative Exceptions
2.2. Security Incidents
2.3. External Sources and References
3. Incident Response
3.1. Introduction
3.1.1. The Rules
3.1.2. Incident Response Team
3.1.3. Management
3.2. Prerequisite Tasks
3.3. Assessment and Communication
3.3.1. Management Chain Notification
3.3.2. Threat Assessment
3.3.3. Entry Investigation
3.3.4. Impact-Assessment
3.3.5. Partner Communication
3.3.6. Public Disclosure
3.4. Actions
3.4.1. Investigation
3.4.2. Data Integrity Plan
3.4.3. Re-secure Environment Plan

Community Services Infrastructure Standards

1. CSI Introduction
1.1. Introduction
1.2. What to do
1.3. External Sources and References
2. Language and Terms
2.1. Introduction
2.2. External Sources and References

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 standards or CSI standards are a group of documents designed to be implemented by the biggest set of technology users in the world. They focus entirely around Red Hat compatable operating systems (Red Hat Enterprise Linux, Fedora, and CentOS for example). Unlike most documentation, CSI aims to be standards based. Often checklists can be printed up and checked off one by one to ensure compliance. There are three typical target audiences. Administrators, end users and management / legal.
CSI is developed using open source methods. Any changes or suggestions should be directed to the CSI mailing list. Any questions regarding details on how to implement these changes or why 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 and steps that you are now expected to follow. Read through the items below and make note of any confusing or less then clear steps. It is important that each step is followed carefully. Do not assume something is done just because it might be right. It is recommended to print up a copy of these checklists and mark off each one as they are completed. Should a time come that an item becomes non-compliant, make note of that and work to become compliant once again.

1.3. External Sources and References

Chapter 2. Language and Terms

2.1. Introduction
2.2. External Sources and References

2.1. Introduction

In order to avoid ambiguity, this document has been put together to explicitly define common words found throughout CSI.

2.2. External Sources and References

Security Policy

1. Host Security Introduction
1.1. Prerequisites
1.2. Host General Security
1.2.1. Suggested /etc/sysctl.conf config
1.3. IPTables Configuration
1.3.1. Suggested /etc/sysconfig/iptables config
2. End User Security Introduction
2.1. End User Standards
2.1.1. Administrative Exceptions
2.2. Security Incidents
2.3. External Sources and References
3. Incident Response
3.1. Introduction
3.1.1. The Rules
3.1.2. Incident Response Team
3.1.3. Management
3.2. Prerequisite Tasks
3.3. Assessment and Communication
3.3.1. Management Chain Notification
3.3.2. Threat Assessment
3.3.3. Entry Investigation
3.3.4. Impact-Assessment
3.3.5. Partner Communication
3.3.6. Public Disclosure
3.4. Actions
3.4.1. Investigation
3.4.2. Data Integrity Plan
3.4.3. Re-secure Environment Plan

Chapter 1. Host Security Introduction

Mike McGrath

Fedora Infrastructure Lead
Fedora Project
1.1. Prerequisites
1.2. Host General Security
1.2.1. Suggested /etc/sysctl.conf config
1.3. IPTables Configuration
1.3.1. Suggested /etc/sysconfig/iptables config
This chapter focuses on host security. It does not make the distinction between "servers" or "desktops". With this standard we want to actively protect machines where we can and automatically detect any security violations. It is a work in progress.

1.1. Prerequisites

The topics discussed in this chapter include many advanced topics. RHCE knowledge or greater is strongly recommended. Understanding of every piece of this standard is not a requisite to compliance, but it is recommended.

1.2. Host General Security

All of these settings should be placed in your /etc/sysctl.conf. Once the file is editied please run sysctl -p to enable those settings.
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]

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

1.3. IPTables Configuration

IPTables edits can be made directly to /etc/sysconfig/iptables. To enable these rules restart iptables with 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 $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]

1.3.1. Suggested /etc/sysconfig/iptables config

The below config enables people to connect to ssh (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

[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] Don't allow outsiders to alter routing tables.

[5] Prevents joining a smurf attack

[6] Protection from bad icmp error messages

[7] enables syncookies for protection against syn flood attacks

[8] Log spoofed, source routed and redirect packets

[9] Log spoofed, source routed and redirect packets

[10] Don't allow source routed packets

[11] Don't allow source routed packets

[12] Enable reverse path filtering

[13] Enable reverse path filtering

[14] Don't allow outsiders to alter routing tables.

[15] Don't allow outsiders to alter routing tables.

[16] Don't allow outsiders to alter routing tables.

[17] First 4 lines

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

[19] Disable for more security but more difficult network troubleshooting.

[20] Allow all localhost activity. Generally a good idea, don't disable this unless you know what you are doing.

[21] This combination of these TCP flags is not defined. By accepting packets from them, the results may be unexpected.

[22] This combination of these TCP flags is not defined. By accepting packets from them, the results may be unexpected.

[23] This combination of these TCP flags is not defined. By accepting packets from them, the results may be unexpected.

[24] This combination of these TCP flags is not defined. By accepting packets from them, the results may be unexpected.

[25] This combination of these TCP flags is not defined. By accepting packets from them, the results may be unexpected.

[26] This combination of these TCP flags is not defined. By accepting packets from them, the results may be unexpected.

[27] This combination of these TCP flags is not defined. By accepting packets from them, the results may be unexpected.

[28] This combination of these TCP flags is not defined. By accepting packets from them, the results may be unexpected.

[29] This combination of these TCP flags is not defined. By accepting packets from them, the results may be unexpected.

[30] To open specific tcp ports to the world. The example above should replace $PORT with a tcp port number, like 80 for http.

[31] To open udp ports to the world. The example above should replace $PORT with a tcp port number, like 161 for snmp.

[32] To open tcp ports to specific hosts or networks. Using just IP address without a netmask is proper. If a network address is defined, netmask is required. The example above should replace $PORT with a tcp port number, like 80 for http.

[33] To open udp ports to specific hosts or networks. Using just IP address without a netmask is proper. If a network address is defined, netmask is required. The example above should replace $PORT with a tcp port number, like 161 for snmp.

[34] Before last line

[35] As last line

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

Chapter 2. End User Security Introduction

Mike McGrath

Fedora Infrastructure Lead
Fedora Project
2.1. End User Standards
2.1.1. Administrative Exceptions
2.2. Security Incidents
2.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 and as such everyone must take an active role to ensure their own security and the security of the organization. High levels of technical skill are not required to keep a secure environment. This chapter does not focus on computer settings or the like. It instead focuses on actions that should be taken by every individual in order to keep a secure working environment.

2.1. End User Standards

Users who have questions about any of the below items should contact fedora-infrastructure-list@redhat.com for answers. Do not ignore an item because of confusion about what it is.
Required User Actions
CompleteRequirementActionComment
Must NotPassword DisseminationAny and all 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 law enforcement requires it. Discuss with your lawyer in the event of a required legal dissemination. Passwords should not be given to management, technical professionals, or anyone else who asks for it.
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. It should also not be echoed in any way to the terminal. If, for some reason, it is needed, be sure to unset your bash history with unset HISTFILE. When using this method, create a new shell, unset the histfile, run your commands and log that shell out. Go for as short of a time as you can without a histfile set, it only gets written on logout so unsetting it, running commands, and setting it again won't work.
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 integer. 3) All passwords must have at least 1 lower case letter. 4) all passwords must have at least 1 upper case letter. 5) all passwords must have at least one non letter / non number character in them.
Shouldssh ProxyCommandWhen using a gateway or proxy host to get from your workstation to another group of machines, the most secure option is to use ssh's ProxyCommand. See 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 user output device (like keyboard, mouse and monitor for example), either lock the screen, shell, or log out completely.
Should NotPassword ReuseYou should not reuse passwords in environments where there is not a single sign on for everything. This is especially the case with password protected keys, encrypted shares, access to personal sites like retirement sites, bank, etc. Always maintain different passwords where possible.
Should NotSoftware installationUsers should not install any software that is not approved. Contact your helpdesk for more information - 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. When possible scripts or programs should not be run as your normal user if possible. Especially if this user account has access to sensitive passwords or keys.
Must NotRelocate information offsiteInformation contained on file shares, or in databases on our servers should be assumed to have a non-sharable license. As such it should not be transfered offsite without the express written consent of both admin fedoraproject.org and admin fedoraproject.org. This includes printed copies or data in any form. Exceptions to this include logs that contain no private information (which is defined by our privacy policy).
MustKey SecurityAny keys kept on any host must be readable only by the owner or group of that key. It should have permissions as close to 0400 as possible.
MustKey passwordsAll private keys must be encrypted with unique passwords. These passwords must meet the same criteria as any other password.
MustEncryption BackupsUsers who use encryption keys must have those keys backed up to a location that can be taken offline. Ideally a usb key or other such 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 / restored. The filesystem this key backup exists on should be encrypted.
MustStolen / Missing EquipmentAny stolen or missing equpment containing any sensitive data including passwords or keys (even encrypted) must be reported as quickly as possible. When handled quickly, missing equipment is often a minor issue.

2.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 must be followed.
Required User Actions
CompleteRequirementActionComment
MustPassword SharingWhen a password is not directly tied to a human-user (for example, mailman password or network device password), the shared password must only be stored and shared in an encrypted format among an assigned group. When any user is removed from this group, that password must be changed. Shared passwords should be avoided where 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 never more then one person at a time should be responsible for a role based account.
MustData Access PasswordsPasswords that provide access to data resources, like that of a database for a web application, are considered shared passwords. See the section on "Password Sharing" for details.
Must NotSelf AccessAdmins and users must not give themselves access to resources unless it is an emergency or a setup issue. Follow normal steps to get in a group and sponsored by someone.

2.2. Security Incidents

Security incidents are serious business. Any detection of a security breach or malicious behavior should immediately be reported. Users should contact the security team directly - admin fedoraproject.org. Please do not share any details related to the incident with anyone other than who you have initially contacted. The reason for this is to protect yourself and The Fedora Project from further internal attacks. If the attacker is aware that they have been caught, they may cover their tracks and stop attacking. If the security team is aware, and can track the attacker while they are attacking, the chances of catching who is at fault greatly increases.

2.3. External Sources and References

Chapter 3. Incident Response

Mike McGrath

Fedora Infrastructure Lead
Fedora Project
3.1. Introduction
3.1.1. The Rules
3.1.2. Incident Response Team
3.1.3. Management
3.2. Prerequisite Tasks
3.3. Assessment and Communication
3.3.1. Management Chain Notification
3.3.2. Threat Assessment
3.3.3. Entry Investigation
3.3.4. Impact-Assessment
3.3.5. Partner Communication
3.3.6. Public Disclosure
3.4. Actions
3.4.1. Investigation
3.4.2. Data Integrity Plan
3.4.3. Re-secure Environment Plan

3.1. Introduction

Upon identification of a possible compromise the following steps should be followed. The way this chapter should be followed is that of a task list. Each incident will have an acting incident coordinator at all times. This person is charged with coordinating who does what tasks and finding another coordinator in the event that he/she becomes unavailable.

3.1.1. The Rules

You've been directed to read the rules because you either broke the rules, or because you've 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, no one is to make any changes to a host without permission from the incident coordinator. This includes shutting services down, logging in or out, etc.
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. [37]
MustInformation DisclosureDiscussion of the incident must only happen between the team chosen by the incident coordinator. Before talking to someone, make sure they are on the list first. [38]
MustAssumptionsDo not make any assumptions that something is being done, is already done, etc. Work with the incident coordinator.

3.1.2. Incident Response Team

Anyone who is brought in to work on issues related to this incident are automatically members of the incident response team. This includes non technical members like those involved with marketing or legal.

3.1.2.1. Incident Coordinator

The incident coordinator is in charge of all things technical related to the incident. If a compromise is involved this person is charged with finding out how they got in, making sure it doesn't happen again, making sure it's not still happening, etc. This role is largely technical but must also work with many different members to coordinate and delegate tasks. This includes, but is not limited to, working with hosting providers, working with the marketing/PR for information dissemination, etc.
The tasks below must be completed in an order determined by the incident coordinator. Tasks that require or depend on another task will be explicitly defined as such. Each task should be marked as complete as it becomes complete. Some tasks require written answers to questions. Coordinate the answers to these questions for factual correctness among chosen parties via a secure / safe medium.

3.1.2.2. Task Coordinator

Each task will be assigned to a task coordinator. Each task should be completed and the results (if any) should be given back to the incident coordinator. Don't work on tasks that have not been assigned to you. It's possible multiple people will be working on one task though only one of them will be designated the coordinator of that task. Many tasks can be done in parallel but some tasks must be done in order, such tasks are labeled as such. Any assignment that has a 'sign off' field requires sign off by the task coordinator to ensure it has been completed and verified.
It is also the job of the task coordinator to ensure that once a task is done that the incident coordinator marks that task as done and who completed it. If you are unable to complete a task or stop working on it, let the incident coordinator know and try to find a replacement from the incident response team.

3.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 making sure that the technical parts of the incident response team are able to work as unfettered as possible, and that the appropriate people and groups 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.

3.2. Prerequisite Tasks

The Below tasks 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 and not 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 to an agreed secure location. Provide a size estimate. Include basic details about the images including the architecture and what would be required to get these iamges up and running again.
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, not 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 invovle disabling central authentication altogether.

3.3. Assessment and Communication

These tasks are designed around threat assessment and communication. Communication tasks include letting appropriate management chains know of the problem as well as putting together the correct information for marketing/PR dissemination.

3.3.1. Management Chain Notification

This section is designed to make the management chain aware that an incident has been discovered as well as sending reports and updates as investigation and ultimately repairs are completed.
Management Chain Notification
Sign offTaskDescription
Notify ManagementThis is the initial "we have a problem" contact. It should be by phone, leave a message if no one answers and send an email. Ensure the following people have been contacted: legal@fedoraproject.org, fpl@fedoraproject.org
Threat AssessmentOnce the Threat Assessment has been completed (below) email it to: legal@fedoraproject.org, fpl@fedoraproject.org. Ensure to let them know 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.

3.3.2. Threat Assessment

The Threat Assessment is to be written for various management and communication teams. Provide high level technical details and remember the people reading this assessment may not be technical.
Threat Assessment Sign off
Sign offTaskDescription
Threat AssessmentAnswer the questions below.
With the questions below, keep in mind the hosts that have been affected and what information is 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?
Best initial guess, how long have we been compromised?

3.3.3. Entry Investigation

It is important to determine the point of entry for any compromise. Below are questions that should get answered prior to rebuilding or fixing any services.
Entry Investigation Sign off
Sign offTaskDescription
Entry InvestigationAnswer the questions below.
Entry Investigation
CompleteQuestionAnswer
How did the attacker gain entry to our services?
Did the attacker have stolen credentials to gain access to our services?
Is it possible / likely this was done by a malicious associate or by 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 the host(s) to gain access to our systems?
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?

3.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 specific of details as are available at the time of the assessment. As new facts or details come out, update the impact assessment and email those updates 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 / data stores do we need to audit?

3.3.5. Partner Communication

Partners include any hosting providers, contractors, or other professionals which may be impacted or otherwise involved with this compromise. For example, if there is evidence that someone physically logged into a console, the hosting provider and/or security of that co-location should be notified.
If the partner is notified, they should be considered part of the incident response team. They are to be worked with, not against or for.
Partner Notification
Sign offTaskDescription
Partner NotificationAt the discretion of the incident coordinator, contact partner with details about the incident for further investigation.

3.3.6. Public Disclosure

The below sign off should be completed by fpl@fedoraproject.org unless he/she delegates this task to someone else. These tasks can be completed should be completed as soon as is feasible and may consist of multiple emails or combined into one if the incident is discovered and fixed quickly. Each of the below tasks must be completed.
Notification Tree
Sign offTaskDescription
Initial NotificationLet everyone know that an incident has happened.
Partner IntegrityIf a partner has been determined to be affected / notified (see section: "Partner Communication"), ensure notifications going out do not jeopardize the integrety of any investigations they may be doing.
Service RepairOnce a service repair plan is put in place notify everyone which services will be unavailable during rebuild and repair.
CredentialsOnce the environment is deemed secure, notify all affected parties and have them change their password.
EntryOnce the entry point has been found and fixed, let everyone know what the problem was and how it was fixed. If this was an unknown software vulnerability, work with upstream to fix the issue before sending this notification out.
Time line/PostmortemOnce the rebuild/repair phase is complete and services are back online 100% send a summary of what was done and why. This should include the same time line used by the incident response team to let people know what was done and when.

3.4. Actions

The following actions must be taken to correct issues related to the incident and ultimately bring things back online. Work with the incident coordinator or task manager to complete the below tasks.

3.4.1. Investigation

This section of the incident response plan includes some techniques that should be used to determine entry to a system and to determine if entry is ongoing.
Investigation
Sign offTaskDescription
InvestigationIntrusion entry point discovered, summary and details sent to incident coordinator, entrypoint is closed / secured.
Investigation Tasks
CompleteTaskDescription
Increase LoggingIncrease logging of any and all services suspected of being involved in the attack.
File MotificationsCompare files to known good copies, as well as backup copies. rpm -V is telling. Additionally look at ctime, mtime and atimes.

3.4.2. Data Integrity Plan

Data integrity Plan is designed to do a couple of things. First is to find out what data was or may have been read from. Second is to find what data may have been altered or changed. Third is to ensure that the data that is there is safe for further use, for example, did the attacker upload a virus to the wiki's images directory?
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 unaltered with. Compare to off site backups if necessary.
Database DataVerify databases. Both the physical machines and the data in them. Depending on the level of access this may just be verifying a single database, it may mean looking at several.
Shared dataVerify shared data is as it should be. This includes removing any malicious files that had been left behind. Make a list of files that have changed during the incident window and verify them.
Temp/Cache DataRemove any temporary or cached data and rebuild from scratch. Alternatively it may be more feasible to verify the local cache with remote cache.

3.4.3. Re-secure Environment Plan

The Re-secure Environment Plan is designed to make sure the attacker has not left any back doors or other malicious software on our hosts. Even if the intruder has been blocked from getting back in the way they came, there's no promise the files on the file system have not been altered. Verification of each file is an incredibly time consuming process, as such it's much faster to just rebuild. Everything should be in configuration management already.
Secure Environment Sign off
Sign offTaskDescription
Secure EnvironmentEnsure the below tasks 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 come up with a strategic order to the rebuilds if one is needed.

[37] This is mostly to make sure people can work independently and not step on each others toes.

[38] Due to the sensitive nature of a security event, it's generally important to keep additional information from being exposed to the attacker(s). This restriction has the unfortunate side effect of decreasing openness about the handling of the event. Timely communication to the service's' users and resolution of the problem can help decrease the effect.