RFC 2196

RFC 2196: Site Security Handbook 🎀

okay bestie, this one is the Site Security Handbook, RFC 2196, and it's basically a guide for admins on how to lock down their stuff once they're online. 💅 It's an FYI document (FYI: 8), so it's informational, not a standard. Published September 1997 by Editor B. Fraser from SEI/CMU, with a whole squad of contributing authors listed in the Introduction. It obsoletes RFC 1244, the earlier version of this handbook, and it builds on that foundation. The Network Working Group put it out, and the title block says it's Category: Informational. 🦋

---

Status of This Memo 📜

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 🌸

Abstract ✨

This handbook is a guide to developing computer security policies and procedures for sites that have systems on the Internet. The purpose of this handbook is to provide practical guidance to administrators trying to secure their information and services. The subjects covered include policy content and formation, a broad range of technical system and network security topics, and security incident response. 🫶

Table of Contents 🗂️

1.   Introduction....................................................  2
1.1  Purpose of this Work............................................  3
1.2  Audience........................................................  3
1.3  Definitions.....................................................  3
1.4  Related Work....................................................  4
1.5  Basic Approach..................................................  4
1.6  Risk Assessment.................................................  5
2.   Security Policies...............................................  6
2.1  What is a Security Policy and Why Have One?.....................  6
2.2  What Makes a Good Security Policy?..............................  9
2.3  Keeping the Policy Flexible..................................... 11
3.   Architecture.................................................... 11
3.1  Objectives...................................................... 11
3.2  Network and Service Configuration............................... 14
3.3  Firewalls....................................................... 20
4.   Security Services and Procedures................................ 24
4.1  Authentication.................................................. 24
4.2  Confidentiality................................................. 28
4.3  Integrity....................................................... 28
4.4  Authorization................................................... 29
4.5  Access.......................................................... 30
4.6  Auditing........................................................ 34
4.7  Securing Backups................................................ 37
5.   Security Incident Handling...................................... 37
5.1  Preparing and Planning for Incident Handling.................... 39
5.2  Notification and Points of Contact.............................. 42
5.3  Identifying an Incident......................................... 50
5.4  Handling an Incident............................................ 52
5.5  Aftermath of an Incident........................................ 58
5.6  Responsibilities................................................ 59
6.   Ongoing Activities.............................................. 60
7.   Tools and Locations............................................. 60
8.   Mailing Lists and Other Resources............................... 62
9.   References...................................................... 64

---

1. Introduction ✨

This document gives system and network administrators guidance on handling security issues within the Internet community. It builds on the foundation provided in RFC 1244 and is the collective work of a number of contributing authors. Those authors include: Jules P. Aronson (aronson@nlm.nih.gov), Nevil Brownlee (n.brownlee@auckland.ac.nz), Frank Byrum (byrum@norfolk.infi.net), Joao Nuno Ferreira (ferreira@rccn.net), Barbara Fraser (byf@cert.org), Steve Glass (glass@ftp.com), Erik Guttman (erik.guttman@eng.sun.com), Tom Killalea (tomk@nwnet.net), Klaus-Peter Kossakowski (kossakowski@cert.dfn.de), Lorna Leone (lorna@staff.singnet.com.sg), Edward.P.Lewis (Edward.P.Lewis.1@gsfc.nasa.gov), Gary Malkin (gmalkin@xylogics.com), Russ Mundy (mundy@tis.com), Philip J. Nesser (pjnesser@martigny.ai.mit.edu), and Michael S. Ramsey (msr@interpath.net). 🦋

In addition to the principle writers, a number of reviewers provided valuable comments. Those reviewers include: Eric Luiijf (luiijf@fel.tno.nl), Marijke Kaat (marijke.kaat@sec.nl), Ray Plzak (plzak@nic.mil) and Han Pronk (h.m.pronk@vka.nl). 🌈

A special thank you goes to Joyce Reynolds, ISI, and Paul Holbrook, CICnet, for their vision, leadership, and effort in the creation of the first version of this handbook. It is the working group's sincere hope that this version will be as helpful to the community as the earlier one was. 🥹💖

1.1. Purpose of This Work 🎯

This handbook is a guide to setting computer security policies and procedures for sites that have systems on the Internet (however, the information provided should also be useful to sites not yet connected to the Internet). This guide lists issues and factors that a site must consider when setting their own policies. It makes a number of recommendations and provides discussions of relevant areas. 📝

This guide is only a framework for setting security policies and procedures. In order to have an effective set of policies and procedures, a site will have to make many decisions, gain agreement, and then communicate and implement these policies. 🧚

1.2. Audience 👀

The audience for this document are system and network administrators, and decision makers (typically "middle management") at sites. For brevity, we will use the term "administrator" throughout this document to refer to system and network administrators.

This document is not directed at programmers or those trying to create secure programs or systems. The focus of this document is on the policies and procedures that need to be in place to support the technical security features that a site may be implementing.

The primary audience for this work are sites that are members of the Internet community. However, this document should be useful to any site that allows communication with other sites. As a general guide to security policies, this document may also be useful to sites with isolated systems. 🍓

1.3. Definitions 📚

For the purposes of this guide, a "site" is any organization that owns computers or network-related resources. These resources may include host computers that users use, routers, terminal servers, PCs or other devices that have access to the Internet. A site may be an end user of Internet services or a service provider such as a mid-level network. However, most of the focus of this guide is on those end users of Internet services. We assume that the site has the ability to set policies and procedures for itself with the concurrence and support from those who actually own the resources. It will be assumed that sites that are parts of larger organizations will know when they need to consult, collaborate, or take recommendations from, the larger entity. 💜

The "Internet" is a collection of thousands of networks linked by a common set of technical protocols which make it possible for users of any one of the networks to communicate with, or use the services located on, any of the other networks (FYI4, RFC 1594). 🌐

The term "administrator" is used to cover all those people who are responsible for the day-to-day operation of system and network resources. This may be a number of individuals or an organization.

The term "security administrator" is used to cover all those people who are responsible for the security of information and information technology. At some sites this function may be combined with administrator (above); at others, this will be a separate position.

The term "decision maker" refers to those people at a site who set or approve policy. These are often (but not always) the people who own the resources. 👑

1.4. Related Work 🔗

The Site Security Handbook Working Group is working on a User's Guide to Internet Security. It will provide practical guidance to end users to help them protect their information and the resources they use. ✨

1.5. Basic Approach 🧭

This guide is written to provide basic guidance in developing a security plan for your site. One generally accepted approach to follow is suggested by Fites, et. al. [Fites 1989] and includes the following steps:

1. Identify what you are trying to protect.
2. Determine what you are trying to protect it from.
3. Determine how likely the threats are.
4. Implement measures which will protect your assets in a cost-effective manner.
5. Review the process continuously and make improvements each time a weakness is found.

Most of this document is focused on item 4 above, but the other steps cannot be avoided if an effective plan is to be established at your site. One old truism in security is that the cost of protecting yourself against a threat should be less than the cost of recovering if the threat were to strike you. Cost in this context should be remembered to include losses expressed in real currency, reputation, trustworthiness, and other less obvious measures. Without reasonable knowledge of what you are protecting and what the likely threats are, following this rule could be difficult. 💅

1.6. Risk Assessment ⚖️

1.6.1. General Discussion 💭

One of the most important reasons for creating a computer security policy is to ensure that efforts spent on security yield cost effective benefits. Although this may seem obvious, it is possible to be mislead about where the effort is needed. As an example, there is a great deal of publicity about intruders on computers systems; yet most surveys of computer security show that, for most organizations, the actual loss from "insiders" is much greater. 🙈

Risk analysis involves determining what you need to protect, what you need to protect it from, and how to protect it. It is the process of examining all of your risks, then ranking those risks by level of severity. This process involves making cost-effective decisions on what you want to protect. As mentioned above, you should probably not spend more to protect something than it is actually worth. 🔥

A full treatment of risk analysis is outside the scope of this document. [Fites 1989] and [Pfleeger 1989] provide introductions to this topic. However, there are two elements of a risk analysis that will be briefly covered in the next two sections:

1. Identifying the assets
2. Identifying the threats

For each asset, the basic goals of security are availability, confidentiality, and integrity. Each threat should be examined with an eye to how the threat could affect these areas. 🫶

1.6.2. Identifying the Assets 🎀

Okay so step one of a risk analysis is making a list of everything that needs protecting 📝 Some stuff is obvious, like valuable proprietary info, intellectual property, and all the hardware 💻 but some things get totally overlooked, like the actual people who use the systems 🫶 The big idea is to list everything that could be affected by a security problem ✨

The author borrows a list of categories from Pfleeger [Pfleeger 1989], adapted from that source. Here it is 💅

1. Hardware: CPUs, boards, keyboards, terminals, workstations, personal computers, printers, disk drives, communication lines, terminal servers, routers.
2. Software: source programs, object programs, utilities, diagnostic programs, operating systems, communication programs.
3. Data: during execution, stored on-line, archived off-line, backups, audit logs, databases, in transit over communication media.
4. People: users, administrators, hardware maintainers.
5. Documentation: on programs, hardware, systems, local administrative procedures.
6. Supplies: paper, forms, ribbons, magnetic media.

1.6.3. Identifying the Threats 🦋

Once you know what needs protecting, you have to figure out what's coming for it 👀 That's how you see what potential for loss is out there. It helps to ask yourself what threats you're trying to protect your assets from. Here are the classic threats you should consider 🔥 Depending on your site, you'll probably find more specific ones that need their own attention too.

1. Unauthorized access to resources and/or information
2. Unintented and/or unauthorized Disclosure of information
3. Denial of service

---

2. Security Policies ✨

There are going to be tons of references to policies throughout this document 📚 Instead of repeating how to create and communicate a policy every single time, just apply the advice in this chapter whenever you're building any policy recommended later in the book. Efficient, iykyk 💖

2.1. What is a Security Policy and Why Have One? 🌸

Okay this part is so important 😭 The security decisions you make (or don't make) as an administrator basically decide how secure your network is, how much functionality it offers, and how easy it is to use. But you can't make good security decisions until you know what your security goals are 🎯 Until then, even the coolest security tools are useless, because you won't know what to check for or which restrictions to impose.

Your goals will probably look really different from a product vendor's goals 🙈 Vendors want their products to be as simple to configure and operate as possible, which means the default configurations are often as open (i.e., insecure) as possible. That makes new products easier to install, but it also leaves access to those systems, and to other systems through them, open to any user who wanders by. Not it 💀

Your goals will be shaped mostly by these key tradeoffs:

1. Services offered versus security provided: Each service you offer users comes with its own security risks. For some services, the risk outweighs the benefit, and the administrator may choose to eliminate the service rather than try to secure it.
2. Ease of use versus security: The easiest system to use would let any user in and require no passwords, which means no security at all 🙃 Requiring passwords makes the system a little less convenient but more secure. Requiring device-generated one-time passwords makes it even harder to use, but much more secure.
3. Cost of security versus risk of loss: Security costs a lot of different things: money (like buying security hardware and software such as firewalls and one-time password generators), performance (encryption and decryption take time), and ease of use (see above). Risks come in different flavors too: loss of privacy (unauthorized individuals reading information), loss of data (information getting corrupted or erased), and loss of service (data storage space filling up, computational resources getting used up, and network access getting denied). Each type of cost has to be weighed against each type of loss ⚖️

Your goals should be shared with all users, operations staff, and managers through a set of security rules called a "security policy" 📜 The author uses this broader term rather than "computer security policy" because the scope covers all types of information technology and the information that technology stores and manipulates ✨

2.1.1. Definition of a Security Policy 💜

A security policy is a formal statement of the rules that people who are given access to an organization's technology and information assets must follow.

2.1.2. Purposes of a Security Policy 🧚

The main purpose of a security policy is to let users, staff and managers know their obligatory requirements for protecting technology and information assets 📣 The policy should also specify the mechanisms through which those requirements can be met. Another purpose is to give you a baseline to acquire, configure and audit computer systems and networks for compliance with the policy. So, lowkey, using a set of security tools without at least an implied security policy is meaningless 💀

An Appropriate Use Policy (AUP) can also be part of a security policy 🍓 It should spell out what users shall and shall not do on the various components of the system, including the types of traffic allowed on the networks. The AUP should be as explicit as possible so there's no ambiguity or misunderstanding. For example, an AUP might list any prohibited USENET newsgroups. (Note: Appropriate Use Policy is referred to as Acceptable Use Policy by some sites.) 🌈

2.1.3. Who Should be Involved When Forming Policy? 👑

For a security policy to be appropriate and effective, it needs the acceptance and support of every level of employee in the organization 🫶 It's especially important that corporate management fully backs the security policy process, otherwise it's very unlikely to have the impact it's supposed to. These are the individuals who should be involved in creating and reviewing security policy documents:

1. site security administrator
2. information technology technical staff (e.g., staff from computing center)
3. administrators of large user groups within the organization (e.g., business divisions, computer science department within a university, etc.)
4. security incident response team
5. representatives of the user groups affected by the security policy
6. responsible management
7. legal counsel (if appropriate)

This list is representative of many organizations, but it isn't necessarily complete 🌸 The goal is to bring in representation from key stakeholders: management who have budget and policy authority, technical staff who know what can and cannot be supported, and legal counsel who understand the legal ramifications of different policy choices. In some organizations, it may make sense to include EDP audit personnel. Including this group matters if the resulting policy statements are going to reach the broadest possible acceptance ✨ Also, legal counsel's role varies from country to country, so keep that in mind 🌍

2.2 What Makes a Good Security Policy? ✨

okay so bestie, let's talk about what actually makes a security policy good 💅 the main character energy here is that a good policy has three core traits:

• Trait 1: It MUST be implementable through system administration procedures, publishing of acceptable use guidelines, or other appropriate methods. 🛠️
• Trait 2: It MUST be enforcible with security tools, where appropriate, and with sanctions, where actual prevention is not technically feasible. 🔒
• Trait 3: It MUST clearly define the areas of responsibility for the users, administrators, and management. 🫶

Now the components. A good security policy is lowkey a whole package deal 🎀 and it includes:

1. Computer Technology Purchasing Guidelines which specify required, or preferred, security features. These should supplement existing purchasing policies and guidelines. 🛒
2. A Privacy Policy which defines reasonable expectations of privacy regarding such issues as monitoring of electronic mail, logging of keystrokes, and access to users' files. 👀
3. An Access Policy which defines access rights and privileges to protect assets from loss or disclosure by specifying acceptable use guidelines for users, operations staff, and management. It SHOULD provide guidelines for external connections, data communications, connecting devices to a network, and adding new software to systems. It SHOULD also specify any required notification messages (e.g., connect messages SHOULD provide warnings about authorized usage and line monitoring, and not simply say "Welcome"). 🚪
4. An Accountability Policy which defines the responsibilities of users, operations staff, and management. It SHOULD specify an audit capability, and provide incident handling guidelines (i.e., what to do and who to contact if a possible intrusion is detected). 🕵️‍♀️
5. An Authentication Policy which establishes trust through an effective password policy, and by setting guidelines for remote location authentication and the use of authentication devices (e.g., one-time passwords and the devices that generate them). 🔑
6. An Availability statement which sets users' expectations for the availability of resources. It SHOULD address redundancy and recovery issues, as well as specify operating hours and maintenance down-time periods. It SHOULD also include contact information for reporting system and network failures. ⏰
7. An Information Technology System & Network Maintenance Policy which describes how both internal and external maintenance people are allowed to handle and access technology. One important topic to be addressed here is whether remote maintenance is allowed and how such access is controlled. Another area for consideration here is outsourcing and how it is managed. 🧰
8. A Violations Reporting Policy that indicates which types of violations (e.g., privacy and security, internal and external) MUST be reported and to whom the reports are made. A non-threatening atmosphere and the possibility of anonymous reporting will result in a greater probability that a violation will be reported if it is detected. 📣
9. Supporting Information which provides users, staff, and management with contact information for each type of policy violation; guidelines on how to handle outside queries about a security incident, or information which may be considered confidential or proprietary; and cross-references to security procedures and related information, such as company policies and governmental laws and regulations. 📚

Real talk on the legal side 💀: there may be regulatory requirements that affect some aspects of your security policy (e.g., line monitoring). The creators of the security policy SHOULD consider seeking legal assistance in the creation of the policy. At a minimum, the policy MUST be reviewed by legal counsel. ⚖️

Once your policy is established, it SHOULD be clearly communicated to users, staff, and management. Having all personnel sign a statement indicating that they have read, understood, and agreed to abide by the policy is an important part of the process. Finally, your policy SHOULD be reviewed on a regular basis to see if it is successfully supporting your security needs. 🌸

---

2.3. Keeping the Policy Flexible 🦋

okay so for a security policy to be viable for the long term, it needs a LOT of flexibility based upon an architectural security concept 🌈 A security policy SHOULD be (largely) independent from specific hardware and software situations, because specific systems tend to be replaced or moved overnight. The mechanisms for updating the policy SHOULD be clearly spelled out. This includes the process, the people involved, and the people who must sign-off on the changes. 📝

It's also important to recognize that there are exceptions to every rule 🙈 Whenever possible, the policy SHOULD spell out what exceptions to the general policy exist. For example, under what conditions is a system administrator allowed to go through a user's files. Also, there may be some cases when multiple users will have access to the same userid. For example, on systems with a "root" user, multiple system administrators may know the password and use the root account. 🔐

Another consideration is called the "Garbage Truck Syndrome." 🚛 This refers to what would happen to a site if a key person was suddenly unavailable for his/her job function (e.g., was suddenly ill or left the company unexpectedly). While the greatest security resides in the minimum dissemination of information, the risk of losing critical information increases when that information is not shared. It is important to determine what the proper balance is for your site. ⚖️✨

---

3. Architecture 🏗️

3.1. Objectives 🎯

3.1.1. Completely Defined Security Plans 🗺️

All sites SHOULD define a comprehensive security plan. Hmm, actually the original says "should" in lowercase here, so I'll keep it as written: All sites should define a comprehensive security plan. This plan should be at a higher level than the specific policies discussed in chapter 2, and it should be crafted as a framework of broad guidelines into which specific policies will fit. 🖼️

It is important to have this framework in place so that individual policies can be consistent with the overall site security architecture. For example, having a strong policy with regard to Internet access and having weak restrictions on modem usage is inconsistent with an overall philosophy of strong security restrictions on external access. 🙅‍♀️

A security plan should define: the list of network services that will be provided; which areas of the organization will provide the services; who will have access to those services; how access will be provided; who will administer those services; etc. 📋

The plan should also address how incident will be handled. Chapter 5 provides an in-depth discussion of this topic, but it is important for each site to define classes of incidents and corresponding responses. For example, sites with firewalls should set a threshold on the number of attempts made to foil the firewall before triggering a response? Escallation levels should be defined for both attacks and responses. Sites without firewalls will have to determine if a single attempt to connect to a host constitutes an incident? What about a systematic scan of systems? 🚨

For sites connected to the Internet, the rampant media magnification of Internet related security incidents can overshadow a (potentially) more serious internal security problem. Likewise, companies who have never been connected to the Internet may have strong, well defined, internal policies but fail to adequately address an external connection policy. 📺

3.1.2. Separation of Services 🧩

There are many services which a site may wish to provide for its users, some of which may be external. There are a variety of security reasons to attempt to isolate services onto dedicated host computers. There are also performance reasons in most cases, but a detailed discussion is beyond to scope of this document. 💻

The services which a site may provide will, in most cases, have different levels of access needs and models of trust. Services which are essential to the security or smooth operation of a site would be better off being placed on a dedicated machine with very limited access (see Section 3.1.3 "deny all" model), rather than on a machine that provides a service (or services) which has traditionally been less secure, or requires greater accessability by users who may accidentally suborn security. 🏰

It is also important to distinguish between hosts which operate within different models of trust (e.g., all the hosts inside of a firewall and any host on an exposed network). 🧱

Some of the services which should be examined for potential separation are outlined in section 3.2.3. It is important to remember that security is only as strong as the weakest link in the chain. Several of the most publicized penetrations in recent years have been through the exploitation of vulnerabilities in electronic mail systems. The intruders were not trying to steal electronic mail, but they used the vulnerability in that service to gain access to other systems. 📧⛓️

If possible, each service SHOULD be running on a different machine whose only duty is to provide a specific service. This helps to isolate intruders and limit potential harm. 🥰

3.1.3. Deny all/ Allow all 🦋

Okay bestie, there are two totally opposite vibes you can go with when you're writing a security plan 🫶 Both are legit, and which one you pick depends on your site and how much security it actually needs.

The first option is to turn off EVERYTHING and then switch on services one at a time, only when they're actually needed 🔒 You can do this at the host level or the network level, whatever fits. We're gonna call this the "deny all" model from here on. It's generally more secure than the other one (we'll get there in the next paragraph) 💅 Ngl it's more work to pull off, and you need to really understand your services. But the upside is you only allow known services, which makes it way easier to analyze a particular service or protocol and build a security mechanism that matches your site's security level 🧚

The other option is the "allow all" model. This one is SO much easier to set up 😭 You just turn everything on (usually the default on hosts) and let every protocol cross network boundaries (usually the default on routers). Then whenever a security hole pops up, you restrict it or patch it at the host or network level. Lowkey it's giving reactive 💀 It's generally less secure than "deny all," so keep that in mind 🌸

Here's the tea: you don't have to pick just one for the whole site. Each model can be applied to different portions of it, depending on functionality requirements, administrative control, site policy, and so on ✨ Like, the policy might be "allow all" for setting up regular workstations, but "deny all" for information servers like an email hub 🍓 And "allow all" for traffic between internal LANs is totally fine, while the site-to-Internet boundary can get "deny all" 🛡️

Be careful when you mix these!! 🚨 A lot of sites do the "hard crunchy shell, soft squishy middle" thing. They're willing to pay the cost of strong security for external traffic, but they're unwilling or unable to provide similar protections internally 🥖 That works fine... as long as the outer defenses are never breached and the internal users can be trusted 🙈 But once the outer shell (the firewall) is breached? Subverting the internal network is trivial. No cap. 💀

3.1.4. Identify Real Needs for Services 💖

There's a huge variety of services you could provide, both internally and out on the Internet at large 🌈 Managing security is, in a lot of ways, managing access to services inside your site AND managing how your internal users access information at remote sites 👑

Services tend to rush over the Internet like waves 🌊 Over the years, tons of sites have set up anonymous FTP servers, gopher servers, wais servers, WWW servers, etc. as they became popular, even though they weren't particularly needed at all sites 😭 So be skeptical! Evaluate every new service you set up with a critical eye and ask: is this actually needed, or is it just the current fad sweeping the Internet? 🙄

Also, security complexity can grow exponentially with the number of services provided 📈 Filtering routers need to be modified to support new protocols. Some protocols are inherently difficult to filter safely (e.g., RPC and UDP services), which means more openings into the internal network 🕳️ And services on the same machine can interact in catastrophic ways!! 💥 For example, allowing anonymous FTP on the same machine as the WWW server might let an intruder drop a file in the anonymous FTP area and cause the HTTP server to execute it. Unhinged but real 😱

3.2. Network and Service Configuration 🎀

3.2.1. Protecting the Infrastructure 🏗️

Many network administrators go to GREAT lengths to protect the hosts on their networks 💅 But few make any effort to protect the networks themselves. Honestly there's some logic to that 🤷‍♀️ It's way easier to protect a host than a network, and intruders are usually after the data on hosts, so damaging the network wouldn't serve their purposes. BUT there are still reasons to protect networks!! For example, an intruder might divert network traffic through an outside host in order to examine the data (i.e., to search for passwords) 👀 Also, infrastructure includes more than just the networks and the routers that interconnect them. It also includes network management (e.g., SNMP), services (e.g., DNS, NFS, NTP, WWW), and security (i.e., user authentication and access restrictions) 🧠

The infrastructure also needs protection against human error 🙃 When an administrator misconfigures a host, that host may offer degraded service. This only affects users who require that host and, unless it's a primary server, the number of affected users stays limited. But if a router is misconfigured, ALL users who require the network will be affected. Obviously that's a way bigger crowd than anyone depending on one host 📉

3.2.2. Protecting the Network 🕸️

There are several problems networks are vulnerable to 🥺 The classic one is a "denial of service" attack, where the network gets brought to a state where it can no longer carry legitimate users' data. There are two common ways to do this: by attacking the routers, and by flooding the network with extraneous traffic. Quick note: in this section, "router" is just an example of a larger class of active network interconnection components, which also includes stuff like firewalls, proxy-servers, etc. ✨

An attack on a router is designed to make it stop forwarding packets, or forward them improperly. The stop-forwarding case may come from a misconfiguration, the injection of a spurious routing update, or a "flood attack" (aka the router gets bombarded with unroutable packets and its performance degrades) 📉 A flood attack on a network is similar, except the flood packets are usually broadcast 📢 The ideal flood attack would be injecting a single packet that exploits some known flaw in the network nodes and causes them to retransmit the packet, or generate error packets, each of which gets picked up and repeated by another host 🔁 A well-chosen attack packet can even generate an exponential explosion of transmissions 🤯

Another classic problem is "spoofing" 🎭 In this case, spurious routing updates are sent to one or more routers, causing them to misroute packets. This differs from a denial of service attack only in the purpose behind the spurious route. In denial of service, the goal is to make the router unusable, a state users will quickly notice. In spoofing, the spurious route sends packets to a host where an intruder can monitor the data, and then those packets get re-routed to their correct destinations. The intruder may or may not have altered the contents 👀

The solution to most of these problems is to protect the routing update packets sent by the routing protocols in use (e.g., RIP-2, OSPF). There are three levels of protection: clear-text password, cryptographic checksum, and encryption 🔐 Passwords offer only minimal protection against intruders who don't have direct access to the physical networks, but they also offer some protection against misconfigured routers (i.e, routers which, out of the box, attempt to route packets) 🙈 The perk of passwords is that they have a very low overhead, in both bandwidth and CPU consumption.

Checksums protect against the injection of spurious packets, even if the intruder has direct access to the physical network 🛡️ Combined with a sequence number or other unique identifier, a checksum can also protect against "replay" attacks, where an old (but valid at the time) routing update gets retransmitted by either an intruder or a misbehaving router 🔁 The most security comes from complete encryption of sequenced or uniquely identified routing updates 🔐👑 This stops an intruder from determining the topology of the network. The catch is the overhead involved in processing the updates 😤

RIP-2 (RFC 1723) and OSPF (RFC 1583) both support clear-text passwords in their base design specifications 📜 In addition, there are extensions to each base protocol to support MD5 encryption ✨

Unfortunately, there's no adequate protection against a flooding attack, or a misbehaving host or router that's flooding the network 😔 Fortunately, this type of attack is obvious when it occurs and can usually be terminated relatively simply 🌈

3.2.3. Protecting the Services

okay bestie, let's talk services 🎀 every service has its own security vibe and it depends on what it's for. like, a service that only people inside the site should use (NFS, for example) might be fine with different protection than something for the whole internet. sometimes it's enough to just keep the internal server away from outsiders 🔒 but a WWW server with a homepage for literally anyone on the internet? it needs built-in protection. so the service/protocol/server itself has to provide whatever security is needed to stop unauthorized access and changes to the Web database 💅

internal services (only for people inside the site) and external services (deliberately open to people outside) usually have different protection needs, as we just covered 🦋 so it's smart to put internal services on one set of server hosts and external services on another set. internal and external servers should NOT be on the same host computer 🙅‍♀️ lots of sites even go further and have one set of subnets (or totally different networks) that outsiders can reach and another set that only the inside can reach. there's usually a firewall between those partitions, and it is SUPER important to make sure that firewall is working properly 🔥

people are getting really into intranets to connect different parts of an organization (like divisions of a company) 🌈 this doc mostly talks about external vs internal (public vs private), but sites using intranets should know they'll need to think about three separations and handle them when designing and offering services ✨ a service offered on an intranet isn't really public, but it isn't fully private to one org subunit either. so it needs its own supporting system, separated from both the external and internal services and networks 🧚

one special kind of external service deserves extra attention: anonymous or guest access 👀 that can be anonymous FTP or guest login with no authentication. it is extremely important to keep anonymous FTP servers and guest login userids carefully isolated from any hosts and file systems that outside users should NOT be able to reach 😭 another thing to watch is anonymous writable access. a site may be legally responsible for publicly available content, so careful monitoring of what anonymous users deposit is advised 💜

next up are some of the most popular services: name service, password/key service, authentication/proxy service, electronic mail, WWW, file transfer, and NFS 🍓 these are the most frequently used, so they're the most obvious targets, and a successful attack on one of them can cause disaster way out of proportion to how innocent the basic service seems 💀

3.2.3.1. Name Servers (DNS and NIS(+))

the Internet uses the Domain Name System (DNS) to resolve host and network names into addresses 🌸 NIS and NIS+ aren't used on the global Internet, but they face the same risks as a DNS server. name-to-address resolution is critical to secure operation of any network 🫶 if an attacker can control or impersonate a DNS server, they can reroute traffic to get around security protections. routine traffic could get diverted to a compromised system to be monitored, or users could be tricked into handing over authentication secrets 😱 a good move is to create well-known, protected sites to act as secondary name servers, and to protect your DNS masters from denial of service attacks using filtering routers 🛡️

traditionally DNS had zero security features ngl 😩 the info returned from a query couldn't be checked for modification, and there was no way to verify it actually came from the name server in question. work has been done to add digital signatures to the protocol, which when deployed will let the integrity of the info be cryptographically verified (see RFC 2065) ✨

3.2.3.2. Password/Key Servers (NIS(+) and KDC)

password and key servers usually protect their vital info (the passwords and keys) with encryption algorithms 🔐 but even a one-way encrypted password can be figured out with a dictionary attack, where common words get encrypted to see if they match the stored value 🙈 so it is necessary to make sure these servers are NOT accessible by hosts that don't plan to use them for this service. even those hosts should only be able to reach the service, and general services like Telnet and FTP should NOT be allowed by anyone other than administrators 👑

3.2.3.3. Authentication/Proxy Servers (SOCKS, FWTK)

a proxy server gives you a bunch of security perks 🎀 it lets sites funnel services through one specific host so they can monitor traffic, hide internal structure, and more. but that funneling also makes a juicy target for a potential intruder 🍯 how much protection a proxy server needs depends a lot on the proxy protocol in use and the services being proxied. a good starting point is the general rule of limiting access to only the hosts that need the services, and limiting those hosts to only the services they need 💖

3.2.3.4. Electronic Mail

email systems have been a source of intruder break-ins for ages, because email protocols are among the oldest and most widely deployed services 📬 and by its very nature, an email server needs access to the outside world, since most email servers accept input from any source 🌍 an email server generally has two parts: a receiving/sending agent and a processing agent. since email gets delivered to all users and is usually private, the processing agent typically needs system (root) privileges to deliver the mail 🔑 most email implementations do both parts, which means the receiving agent also ends up with system privileges. that opens several security holes this document won't describe 🙃 some implementations let you separate the two agents. those are generally considered more secure, but they still need careful installation so you don't create a security problem 🦋

3.2.3.5. World Wide Web (WWW)

the Web is growing exponentially because it's so easy to use and can concentrate information services in such a powerful way 🌈 most WWW servers accept some kind of direction and action from the people accessing them. the most common example is taking a request from a remote user and passing the info to a program on the server to process it 🖥️ some of those programs weren't written with security in mind, and they can create security holes 😬 if a Web server is available to the Internet community, it is especially important that confidential info is NOT co-located on the same host as that server. in fact, it's recommended that the server have a dedicated host that is not "trusted" by other internal hosts 🏠

many sites want to co-locate FTP with their WWW service 🤔 but this should only happen for anon-ftp servers that just provide information (ftp-get). anon-ftp puts combined with WWW might be dangerous (they could modify the info your site publishes to the web) and they make the security considerations for each service different on their own 🫣

3.2.3.6. File Transfer (FTP, TFTP)

FTP and TFTP both let users receive and send electronic files point-to-point 📁 but FTP requires authentication while TFTP requires none. for this reason, TFTP should be avoided as much as possible 🚫

improperly configured FTP servers can let intruders copy, replace, and delete files at will, anywhere on a host 😱 so it is very important to configure this service correctly. access to encrypted passwords and proprietary data, and the introduction of Trojan horses, are just a few of the potential security holes that show up when the service is misconfigured 🐴 FTP servers should reside on their own host. some sites choose to co-locate FTP with a Web server since the two protocols share common security considerations. however, the practice isn't recommended, especially when the FTP service allows files to be deposited (see the WWW section above) 🙅‍♀️ as mentioned in the opening paragraphs of section 3.2.3, services offered internally to your site should NOT be co-located with services offered externally. each should have its own host 💅

TFTP doesn't support the same range of functions as FTP and has no security whatsoever 💀 this service should only be considered for internal use, and then it should be configured in a restricted way so the server only has access to a set of predetermined files (instead of every world-readable file on the system). probably the most common use of TFTP is downloading router configuration files to a router 🌐 TFTP should reside on its own host and should NOT be installed on hosts supporting external FTP or Web access 🧚

3.2.3.7. NFS

the Network File Service lets hosts share common disks 💾 NFS is frequently used by diskless hosts that depend on a disk server for all their storage needs. unfortunately, NFS has no built-in security 😭 so it is necessary that the NFS server be accessible ONLY by the hosts that are using it for service. this is done by specifying which hosts the file system is exported to and in what manner (e.g., read-only, read-write, etc.) 🎀 filesystems should NOT be exported to any hosts outside the local network, since that would require the NFS service to be accessible externally. ideally, external access to NFS service should be stopped by a firewall 🔥

3.2.4. Protecting the Protection

it is amazing how often a site overlooks the most obvious weakness in its security by leaving the security server itself open to attack 🙈 based on what we've already discussed, it should be clear that the security server should NOT be accessible from off-site 🚪 it should offer minimum access to users on-site, except for the authentication function, and it should NOT be co-located with any other servers 👑 further, all access to the node, including access to the service itself, should be logged to provide a "paper trail" in the event of a security breach 📜✨

3.3. Firewalls ✨

okay so one of the most hyped and widely deployed security measures on the Internet is the "firewall" 🔥 People have basically crowned it the cure-all for pretty much every Internet security problem, and bestie, it's not. A firewall is just another tool in the security toolbox 🧰 It gives you a certain level of protection and is generally a way of carrying out your security policy at the network level. How secure a firewall is can vary as much as how secure any single machine is, and you're always juggling the usual trade-offs: security vs. ease of use vs. cost vs. complexity, etc. 💅

A firewall is any one of several mechanisms used to control and keep an eye on access to and from a network, all to protect it 👀 It acts as a gateway that all traffic going to and from the protected network and/or systems has to pass through. Firewalls put limits on how much and what kind of communication can happen between the protected network and another network (like the Internet, or another part of the site's own network) 🚧

Basically a firewall is a wall between one part of a network, like a company's internal network, and another part, like the global Internet 🧱 The iconic thing about this wall is that some traffic with particular characteristics still needs to get through, using carefully monitored doors ("gateways") 🚪 The hard part is figuring out the criteria for deciding which packets get let through the doors and which get turned away. Books on firewalls use all kinds of different terminology for the different forms of firewalls, which can be super confusing if you're a system administrator who isn't familiar with them 🙈 Just know that there is no fixed terminology for describing firewalls, so don't panic when the words change.

Firewalls are not always, or even usually, a single machine 😭 They're often a combination of routers, network segments, and host computers. So for the purposes of this discussion, the term "firewall" can cover more than one physical device 🫶 Firewalls are typically built from two different components: filtering routers and proxy servers.

Filtering routers are the easiest firewall component to wrap your head around 🎀 A router moves data back and forth between two (or more) different networks. A "normal" router takes a packet from network A and "routes" it to its destination on network B. A filtering router does the same thing, but it also decides whether it should route the packet at all, not just how 🧐 It does this by installing a series of filters that tell the router what to do with any given packet of data.

A discussion of what a particular brand of router can do, running a particular software version, is outside the scope of this document 🙅‍♀️ That said, when you're evaluating a router to use for filtering packets, these criteria can be important when you set up a filtering policy: source and destination IP address, source and destination TCP port numbers, state of the TCP "ack" bit, UDP source and destination port numbers, and direction of packet flow (i.e., A->B or B->A). Other info you need to build a secure filtering scheme includes whether the router reorders filter instructions (it does this to optimize the filters, but it can sometimes change the meaning and cause unintended access 😬), and whether it's possible to apply filters to inbound and outbound packets on each interface. If the router only filters outbound packets, then the router is "outside" of its own filters and may be more vulnerable to attack 💔 Beyond the router itself being vulnerable, this difference between inbound and outbound filtering is especially relevant for routers with more than 2 interfaces. Other important issues are being able to create filters based on IP header options and the fragment state of a packet. Building a good filter can be super difficult and really requires a solid understanding of the types of services (protocols) you're going to filter 🧠

For better security, the filters usually restrict access between the two connected networks to just one host, the bastion host 🏰 You can only reach the other network through this bastion host. Since only this one host, instead of a few hundred hosts, can get attacked, it's way easier to maintain a certain level of security, because only this host has to be protected really carefully 🛡️ To make resources available to legitimate users across this firewall, services have to be forwarded by the bastion host. Some servers have forwarding built in (like DNS servers or SMTP servers), and for other services (e.g., Telnet, FTP, etc.), proxy servers can be used to allow access to resources across the firewall in a secure way 🌸

A proxy server is a way to concentrate application services through a single machine ✨ There's typically one machine (the bastion host) acting as a proxy server for a variety of protocols (Telnet, SMTP, FTP, HTTP, etc.), but there can also be individual host computers for each service. Instead of connecting directly to an external server, the client connects to the proxy server, which then starts a connection to the requested external server. Depending on the type of proxy server, internal clients can be set up to do this redirection automatically, without the user ever knowing about it 🪄 Others might require the user to connect directly to the proxy server and then start the connection using a specified format.

Proxy servers come with some serious security perks 💜 You can add access control lists to protocols, so users or systems have to provide some level of authentication before they get access. Smarter proxy servers, sometimes called Application Layer Gateways (ALGs), can be written to understand specific protocols and can be configured to block only subsections of a protocol 🧠 For example, an ALG for FTP can tell the difference between the "put" command and the "get" command. So an organization might want to let users "get" files from the Internet while not letting them "put" internal files on a remote server 🙅‍♀️ A filtering router, by contrast, could either block all FTP access or allow all of it, but it couldn't block just a subset.

Proxy servers can also be configured to encrypt data streams based on a variety of parameters 🔐 An organization might use this to allow encrypted connections between two locations whose only access points are on the Internet.

Firewalls are usually thought of as a way to keep intruders out, but they're also often used to let legitimate users in 🫶 Lots of times, a valid user needs to regularly reach the "home" site while traveling to trade shows and conferences, etc. Internet access is often available, but it may be through an untrusted machine or network 😳 A correctly configured proxy server can let the right users into the site while still denying access to everyone else.

The current best effort in firewall techniques is a combination of a pair of screening routers with one or more proxy servers on a network between the two routers 👑 This setup lets the external router block any attempts to use the underlying IP layer to break security (IP spoofing, source routing, packet fragments), while the proxy server handles potential security holes in the higher layer protocols. The internal router's purpose is to block all traffic except traffic going to the proxy server. If this setup is rigidly implemented, a high level of security can be achieved 💖

Most firewalls provide logging, which can be tuned to make security administration of the network more convenient 📋 Logging may be centralized, and the system may be configured to send out alerts for abnormal conditions. It's important to regularly monitor these logs for any signs of intrusions or break-in attempts 👀 Since some intruders will try to cover their tracks by editing logs, it's desirable to protect the logs. A variety of methods is available, including: write once, read many (WORM) drives; paper logs; and centralized logging via the "syslog" utility. Another technique is to use a "fake" serial printer, but have the serial port connected to an isolated machine or PC that keeps the logs 🧚

Firewalls come in a wide range of quality and strength 💸 Commercial packages start at approximately $10,000US and go up to over $250,000US. "Home grown" firewalls can be built for smaller amounts of capital. Just remember that setting up a firewall correctly (commercial or homegrown) takes a significant amount of skill and knowledge of TCP/IP 🤓 Both types need regular maintenance, installation of software patches and updates, and regular monitoring. When you're budgeting for a firewall, these additional costs should be considered on top of the cost of the physical elements of the firewall 🧾

As an aside, building a "home grown" firewall requires a significant amount of skill and knowledge of TCP/IP. It should not be trivially attempted, because a perceived sense of security is worse in the long run than knowing that there is no security 🚨 As with all security measures, it's important to decide on the threat, the value of the assets to be protected, and the costs to implement security.

A final note about firewalls, bestie 💕 They can be a great aid when you're implementing security for a site, and they protect against a large variety of attacks. But keep in mind that they are only one part of the solution. They cannot protect your site against all types of attack 🌈

---

4. Security Services and Procedures 🦋

This chapter guides the reader through a number of topics that should be addressed when securing a site 📚 Each section touches on a security service or capability that may be required to protect the information and systems at a site. The topics are presented at a fairly high level to introduce the reader to the concepts.

Throughout the chapter, you'll notice a lot of mention of cryptography 🔐 It's outside the scope of this document to dive into the details of cryptography, but the interested reader can find more information in the books and articles listed in the reference section of this document 📖 Let's keep going, bestie! 💜

4.1 Authentication ✨

okay so for ages the go-to way to prove who you are has been standard reusable passwords 🔑 back then there were basically no networks. people typed a password at a terminal to log into one central computer, so the risk of someone reading it in clear text was pretty much zero 🙈 fast forward and systems are wired together through local networks, those networks are wired to each other and to the Internet, and people log in from literally everywhere 🌍 those reusable passwords often cross the same networks in clear text, just sitting there for anyone in the middle to grab 😭 the CERT* Coordination Center and other response teams are seeing a tremendous number of incidents with packet sniffers capturing clear text passwords. it's giving danger 💀

newer tools like one-time passwords (e.g., S/Key), PGP, and token-based authentication devices mean people are now using password-like strings as secret tokens and pins 🦋 and if those secret tokens and pins aren't picked and protected properly, the authentication will be easily subverted. so not me being the one who ends up on the news 🙅‍♀️

4.1.1 One-Time passwords

okay so given how networked everything is now, it is recommended that sites worried about the security and integrity of their systems and networks consider moving away from standard, reusable passwords 🌸 there have been tons of incidents with Trojan network programs (e.g., telnet and rlogin) and network packet sniffing programs. these programs capture clear text hostname/account name/password triplets, and intruders can use that info to get back into those hosts and accounts later 😤 it's possible because 1) the password is used over and over (hence the term "reusable"), and 2) the password crosses the network in clear text. both of those are the problem bestie 💔

a few authentication techniques have been developed to fix this. among them are challenge-response technologies that provide passwords that are only used once (commonly called one-time passwords) ✨ there are a number of products out there that sites should consider using. the decision to use a product is the responsibility of each organization, and each organization should perform its own evaluation and selection. it's giving "do your own research" energy 🔍

4.1.2 Kerberos

Kerberos is a distributed network security system that provides authentication across unsecured networks 🎀 if the application requests it, integrity and encryption can also be provided. it was originally developed at the Massachusetts Institute of Technology (MIT) in the mid 1980s. there are two major releases, version 4 and 5, which are, for practical purposes, incompatible. so they don't really talk to each other, sis 🙃

okay so Kerberos runs on a symmetric key database with a key distribution center (KDC), which is known as the Kerberos server. a user or service (known as "principals") gets electronic "tickets" after properly talking to the KDC, and those tickets are what principals use to authenticate to each other 🫶 every ticket has a time stamp that limits how long it's valid. which means Kerberos clients and server MUST have a secure time source and must be able to keep time accurately ⏰ no cap, time is literally the whole thing here

the practical side is how Kerberos plugs into the application level. apps like FTP, telnet, POP, and NFS have been integrated with the Kerberos system, and there are a variety of implementations with varying levels of integration 🧚 for the latest info, check out the Kerberos FAQ at http://www.ov.com/misc/krb-faq.html 🌈

4.1.3 Choosing and Protecting Secret Tokens and PINs

when you're picking secret tokens, take care to choose them carefully 💅 like passwords, they should be robust against brute force guessing. so they should not be single words in any language, or any common, industry, or cultural acronyms, etc. ideally they'll be longer rather than shorter and be pass phrases that mix upper and lower case characters, digits, and other characters ✨

once they're chosen, protecting them is super important 🔒 some are used as pins for hardware devices (like token cards), and those should not be written down or stored in the same place as the device they belong to. others, like a secret Pretty Good Privacy (PGP) key, should be protected from unauthorized access. bestie, guard those like your diary 📔

one last thing 👑 when you use cryptography products like PGP, take care to figure out the proper key length and make sure your users are trained to do the same. as technology advances, the minimum safe key length keeps growing, so make sure your site keeps up with the latest knowledge. that way you can be sure any cryptography in use is actually providing the protection you think it is 🧐

4.1.4 Password Assurance

ngl the need to kill off standard, reusable passwords cannot be overstated 😤 but it is recognized that some organizations may still be using them. while it's recommended that these organizations move to better technology, in the meantime here's some advice for picking and maintaining traditional passwords 🍓 but remember, none of these measures protects against disclosure due to sniffer programs. so this is damage control, not a full fix 💀

1. The importance of robust passwords - in many (if not most) cases of system penetration, the intruder needs to get into an account on the system. one way that usually happens is by guessing a legitimate user's password. this is often done by running an automated password cracking program, with a very large dictionary, against the system's password file. the only way to guard against passwords being disclosed this way is careful selection of passwords that can't be easily guessed (i.e., combos of numbers, letters, and punctuation characters). passwords should also be as long as the system supports and users can tolerate 💖
2. Changing default passwords - many operating systems and application programs ship with default accounts and passwords. these must be changed immediately to something that cannot be guessed or cracked 🚨
3. Restricting access to the password file - a site really wants to protect the encrypted password portion of the file so would-be intruders don't have them to crack. one effective technique is shadow passwords, where the password field of the standard file holds a dummy or false password. the file with the legit passwords is protected somewhere else on the system 🕵️‍♀️
4. Password aging - when and how to expire passwords is still a hot topic in the security community 🌪️ it's generally accepted that a password should not be kept once an account is no longer in use. but whether a user should be forced to change a good password that's in active use is hotly debated. the case for changing passwords is about stopping continued use of penetrated accounts. however, the other side says frequent changes lead users to write passwords down in visible places (like sticking them to a terminal), or to pick super simple passwords that are easy to guess 🙄 it should also be said that an intruder will probably use a captured or guessed password sooner rather than later, in which case aging provides little if any protection.

there's no definitive answer to this dilemma, so a password policy should directly address it and give guidelines for how often a user should change their password. an annual change is usually not hard for most users, and you should consider requiring it 📅 it is recommended that passwords be changed at least whenever a privileged account is compromised, there's a critical personnel change (especially if it's an administrator!), or an account has been compromised. and if a privileged account password is compromised, all passwords on the system should be changed. big yikes, but that's the deal 😭

5. Password/account blocking - some sites find it useful to disable accounts after a predefined number of failed authentication attempts. if your site goes this route, it is recommended that the mechanism not "advertise" itself 🤫 after disabling, even if the correct password is presented, the message shown should still be the one for a failed login attempt. the downside is legit users will have to contact their system administrator to get their account reactivated 🥲
6. A word about the finger daemon - by default, the finger daemon shows a lot of system and user info. for example, it can list every user currently on a system, or all the contents of a specific user's .plan file. intruders can use that to find usernames and guess passwords. it is recommended that sites consider modifying finger to restrict what it displays 🙈

4.2 Confidentiality

there's info your site will want to keep away from unauthorized entities 🔐 operating systems often have built-in file protection that lets an admin control who on the system can access, or "see," a file's contents. a stronger way to get confidentiality is encryption. encryption scrambles data so it's super difficult and time consuming for anyone other than the authorized recipients or owners to get the plain text 🧩 the recipients and owner have the matching decryption keys to unscramble it back into readable clear text. we recommend that sites use encryption to protect confidentiality and valuable info 💜

the use of encryption is sometimes controlled by government and site rules, so we encourage admins to learn about the laws and policies that regulate it before using it ⚖️ it's outside the scope of this document to go through the various algorithms and programs out there, but we do caution against casual use of the UNIX crypt program because it's been found to be easily broken 💀 everyone should also take time to understand how strong the encryption in any algorithm or product is before using it. most well-known products are well documented in the literature, so this should be a fairly easy task 📚🫶

4.3. Integrity 🎀

okay bestie, as an admin you wanna be sure that stuff like OS files and company data hasn't been changed in a way nobody approved 🧚. so you need to give some assurance about the integrity of the info on your systems ✨. one way to do it is to make a checksum of the unaltered file, store that checksum offline, and periodically (or whenever you want) check that the checksum of the online file hasn't changed, since a change would mean the data was modified 💅.

Some operating systems come with checksum programs, like the UNIX sum program 🍓. ngl, these may not give you the protection you actually need 🙈. files can be modified in a way that keeps the UNIX sum program's result the same!! so we suggest that you use a cryptographically strong program, such as the message digesting program MD5 [ref], to produce the checksums you'll use to assure integrity 🔥.

There are other places where integrity needs assuring, like when you send an email message between two parties 💌. there are products out there that can provide this. once you figure out that this is a capability you need, you can go identify technologies that will provide it 🦋.

4.4. Authorization 👑

Authorization is the process of granting privileges to processes and, ultimately, users 💖. it's different from authentication, because authentication is the process used to identify a user. once someone is identified (reliably), their privileges, rights, property, and permissible actions get decided by authorization ✨.

Explicitly listing the authorized activities of each user (and user process) for all resources (objects) is impossible in a reasonable system 😭. so in a real system, certain techniques are used to simplify granting and checking authorization(s) 🫶.

One approach, popularized in UNIX systems, is to give each object three classes of user: owner, group and world 🌸. the owner is either the creator of the object or the user assigned as owner by the super-user. the owner permissions (read, write and execute) apply only to the owner. a group is a collection of users who share access rights to an object. the group permissions (read, write and execute) apply to all users in the group (except the owner). the world means everybody else with access to the system. the world permissions (read, write and execute) apply to all users (except the owner and members of the group) 🌈.

Another approach is to attach to an object a list that explicitly contains the identity of all permitted users (or groups). this is an Access Control List (ACL) 🧚. the advantage of ACLs is that they're easy to maintain (one central list per object), and it's very easy to visually check who has access to what 💜. the disadvantages are the extra resources needed to store these lists, plus the vast number of lists required for large systems 🥺.

4.5. Access 🦋

4.5.1. Physical Access

Restrict physical access to hosts, and only let in the people who are supposed to use them 🔐. hosts include "trusted" terminals (i.e., terminals that allow unauthenticated use, like system consoles, operator terminals, and terminals dedicated to special tasks), plus individual microcomputers and workstations, especially the ones connected to your network 💻. make sure people's work areas mesh well with access restrictions, or they'll find ways to get around your physical security (e.g., jamming doors open) 🙈.

Keep original and backup copies of data and programs safe 💾. apart from keeping them in good condition for backup purposes, they MUST be protected from theft 🔒. it's important to keep backups in a separate location from the originals, not only for damage considerations but also to guard against theft 🫶.

Portable hosts are a particular risk 💼. make sure it won't cause problems if one of your staff's portable computers gets stolen. consider developing guidelines for the kinds of data that should be allowed on the disks of portable computers, and how that data should be protected (e.g., encryption) while it's on a portable computer ✨.

Other areas where physical access SHOULD be restricted are the wiring closets and important network elements like file servers, name server hosts, and routers 🚪.

4.5.2. Walk-up Network Connections

By "walk-up" connections, we mean network connection points set up so users can easily connect a portable host to your network 🚶‍♀️.

Think about whether you really need to offer this, because it lets any user attach an unauthorized host to your network 😬. that raises the risk of attacks via techniques like IP address spoofing, packet sniffing, etc. users and site management must appreciate those risks. if you decide to provide walk-up connections, plan the service carefully and define exactly where you'll provide it, so you can make sure the necessary physical access security is in place 🧐.

A walk-up host SHOULD be authenticated before its user is permitted to access resources on your network 🔑. as an alternative, it MAY be possible to control physical access. for example, if the service is going to be used by students, you might only provide walk-up connection sockets in student laboratories 🎓.

If you're providing walk-up access so visitors can connect back to their home networks (e.g., to read e-mail) in your facility, consider using a separate subnet that has no connectivity to the internal network 🌐.

Keep an eye on any area that has unmonitored network access, like vacant offices 👀. it may be sensible to disconnect those areas at the wiring closet, and consider using secure hubs and monitoring attempts to connect unauthorized hosts 🚨.

4.5.3. Other Network Technologies

The technologies considered here include X.25, ISDN, SMDS, DDS and Frame Relay 📡. all of them are provided via physical links that go through telephone exchanges, which means they could be diverted. crackers are definitely interested in telephone switches as well as data networks 👀!

With switched technologies, use Permanent Virtual Circuits or Closed User Groups whenever this is possible 🦋. technologies that provide authentication and/or encryption (such as IPv6) are evolving rapidly, so consider using them on links where security is important 🌈.

4.5.4. Modems 📞

4.5.4.1. Modem Lines Must Be Managed

Modems give your users convenient access to the site, but they can also provide an effective detour around the site's firewalls 😱. for this reason, it is essential to keep proper control of modems 🔐.

Don't let users install a modem line without proper authorization. this includes temporary installations (e.g., plugging a modem into a facsimile or telephone line overnight) 🙅‍♀️.

Keep a register of all your modem lines and make sure it stays up to date 📒. run regular (ideally automated) site checks for unauthorized modems 🔍.

4.5.4.2. Dial-in Users Must Be Authenticated

A username and password check SHOULD be completed before a user can access anything on your network 🔑. normal password security considerations are especially important here (see section 4.1.1) 💅.

Remember that telephone lines can be tapped, and it's pretty easy to intercept messages to cellular phones 📱. modern high-speed modems use more sophisticated modulation techniques, which makes them somewhat harder to monitor, but it's prudent to assume that hackers know how to eavesdrop on your lines 👀. for this reason, you SHOULD use one-time passwords if at all possible 🔐.

It's helpful to have a single dial-in point (e.g., one large modem pool) so that all users are authenticated the same way 🫶.

Users will occasionally mistype a password 🙈. set a short delay (say, two seconds) after the first and second failed logins, and force a disconnect after the third. this will slow down automated password attacks 🐢. don't tell the user whether the username, the password, or both were incorrect 🤐.

4.5.4.3. Call-back Capability

Some dial-in servers offer call-back facilities (i.e., the user dials in and is authenticated, then the system disconnects the call and calls back on a specified number) 📲. call-back is useful because if someone guesses a username and password, they get disconnected, and then the system calls back the actual user whose password was cracked. random calls from a server are suspicious, at best 🕵️‍♀️. this does mean users may only log in from one location (where the server is configured to dial them back), and of course there may be phone charges associated with there call-back location 💸.

This feature SHOULD be used with caution, because it can easily be bypassed 🚧. at a minimum, make sure the return call is never made from the same modem as the incoming one 🔁. overall, although call-back can improve modem security, you SHOULD NOT depend on it alone 🙅‍♀️.

4.5.4.4. All Logins Should Be Logged

All logins, whether successful or unsuccessful, SHOULD be logged 📝. however, do not keep correct passwords in the log. rather, log them simply as a successful login attempt 🤫. since most bad passwords are mistyped by authorized users, they only vary by a single character from the actual password. therefore, if you can't keep such a log secure, don't log it at all 🔐.

If Calling Line Identification is available, take advantage of it by recording the calling number for each login attempt 📞. be sensitive to the privacy issues raised by Calling Line Identification 💜. also be aware that Calling Line Identification is not to be trusted (since intruders have been known to break into phone switches and forward phone numbers or make other changes), so use the data for informational purposes only, not for authentication 🚫.

4.5.4.5. Choose Your Opening Banner Carefully

Many sites use a system default in a message of the day file for their opening banner 📜. unfortunately, this often includes the type of host hardware or operating system on the host, which can give a would-be intruder valuable information 🎯. instead, each site SHOULD create its own specific login banner, taking care to only include necessary information 🎀.

Display a short banner, but don't offer an "inviting" name (e.g., University of XYZ, Student Records System) 🙈. instead, give your site name, a short warning that sessions may be monitored, and a username/password prompt ✨. verify possible legal issues related to the text you put in the banner ⚖️.

For high-security applications, consider using a "blind" password (i.e., give no response to an incoming call until the user has typed in a password). this effectively simulates a dead modem 👻.

4.5.4.6. Dial-out Authentication

Dial-out users SHOULD also be authenticated, particularly since your site will have to pay their telephone charges 💸.

Never allow dial-out from an unauthenticated dial-in call, and consider whether you will allow it from an authenticated one 🚫. the goal here is to prevent callers from using your modem pool as part of a chain of logins. this can be hard to detect, especially if a hacker sets up a path through several hosts on your site 🕸️.

At a minimum, don't allow the same modems and phone lines to be used for both dial-in and dial-out 🔐. this is easy to implement if you run separate dial-in and dial-out modem pools 🌸.

4.5.4.7. Make Your Modem Programming as "Bullet-proof" as Possible 🔒

Okay bestie, your modems can't be reprogrammed while they're in service!! 😭 At the very least, make sure that three plus signs won't put your dial-in modems into command mode! 🙅‍♀️

Program your modems to reset to your standard configuration at the start of each new call. If that isn't possible, make them reset at the end of each call. This precaution protects you against accidental reprogramming of your modems 🛡️ Resetting at both the end and the beginning of each call gives an even higher level of confidence that a new caller won't inherit a previous caller's session. It's giving "fresh start every time" ✨

Check that your modems terminate calls cleanly 📞 When a user logs out from an access server, verify that the server hangs up the phone line properly. It's equally important that the server forces logouts from whatever sessions were active if the user hangs up unexpectedly. No ghost sessions allowed, periodt 💀

4.6. Auditing 🔍

This section covers the procedures for collecting data generated by network activity, which may be useful in analyzing the security of a network and responding to security incidents. Think of it as your network's diary 📓

4.6.1. What to Collect

Audit data should include any attempt to achieve a different security level by any person, process, or other entity in the network. This includes login and logout, super user access (or the non-UNIX equivalent), ticket generation (for Kerberos, for example), and any other change of access or status. It is especially important to note "anonymous" or "guest" access to public servers 👀

The actual data to collect will differ for different sites and for different types of access changes within a site. In general, the information you want to collect includes: username and hostname, for login and logout; previous and new access rights, for a change of access rights; and a timestamp. Of course, there is much more information which might be gathered, depending on what the system makes available and how much space is available to store that information 🗂️

One very important note: do not gather passwords! 🚫 This creates an enormous potential security breach if the audit records should be improperly accessed. Do not gather incorrect passwords either, as they often differ from valid passwords by only a single character or transposition. 😩

4.6.2. Collection Process

The collection process should be enacted by the host or resource being accessed. Depending on the importance of the data and the need to have it local in instances in which services are being denied, data could be kept local to the resource until needed or be transmitted to storage after each event 🧚

There are basically three ways to store audit records: in a read/write file on a host, on a write-once/read-many device (e.g., a CD-ROM or a specially configured tape drive), or on a write-only device (e.g., a line printer). Each method has advantages and disadvantages, so pick your fighter wisely 🥊

File system logging is the least resource intensive of the three methods and the easiest to configure. It allows instant access to the records for analysis, which may be important if an attack is in progress. File system logging is also the least reliable method. If the logging host has been compromised, the file system is usually the first thing to go, and an intruder could easily cover up traces of the intrusion. Not ideal, bestie 😬

Collecting audit data on a write-once device is slightly more effort to configure than a simple file, but it has the significant advantage of greatly increased security, because an intruder could not alter the data showing that an intrusion has occurred. The disadvantage of this method is the need to maintain a supply of storage media and the cost of that media. Also, the data may not be instantly available. 💿

Line printer logging is useful in systems where permanent and immediate logs are required. A real time system is an example of this, where the exact point of a failure or attack must be recorded. A laser printer, or other device which buffers data (e.g., a print server), may suffer from lost data if buffers contain the needed data at a critical instant. The disadvantage of, literally, "paper trails" is the need to keep the printer fed and the need to scan records by hand. There is also the issue of where to store the, potentially, enormous volume of paper which may be generated. 🖨️📄 Literally a whole vibe

For each of the logging methods described, there is also the issue of securing the path between the device generating the log and the actual logging device (i.e., the file server, tape/CD-ROM drive, printer). If that path is compromised, logging can be stopped or spoofed or both. In an ideal world, the logging device would be directly attached by a single, simple, point-to-point cable. Since that is usually impractical, the path should pass through the minimum number of networks and routers. Even if logs can be blocked, spoofing can be prevented with cryptographic checksums (it probably isn't necessary to encrypt the logs, because they should not contain sensitive information in the first place) 🔐

4.6.3. Collection Load

Collecting audit data may result in a rapid accumulation of bytes, so storage availability for this information must be considered in advance. There are a few ways to reduce the required storage space. First, data can be compressed, using one of many methods. Or, the required space can be minimized by keeping data for a shorter period of time, with only summaries of that data kept in long-term archives. One major drawback to the latter method involves incident response. Often, an incident has been ongoing for some period of time when a site notices it and begins to investigate. At that point, it's very helpful to have detailed audit logs available. If these are just summaries, there may not be sufficient detail to fully handle the incident 😤

4.6.4. Handling and Preserving Audit Data

Audit data should be some of the most carefully secured data at the site and in the backups. If an intruder were to gain access to audit logs, the systems themselves, in addition to the data, would be at risk 🔐

Audit data may also become key to the investigation, apprehension, and prosecution of the perpetrator of an incident. For this reason, it is advisable to seek the advice of legal counsel when deciding how audit data should be treated. This should happen before an incident occurs ⚖️

If a data handling plan is not adequately defined prior to an incident, it may mean that there is no recourse in the aftermath of an event, and it may create liability resulting from improper treatment of the data. Plan ahead, bestie 📋

4.6.5. Legal Considerations

Due to the content of audit data, there are a number of legal questions that arise, which might need to be addressed by your legal counsel. If you collect and save audit data, you need to be prepared for consequences resulting both from its existence and its content 🧾

One area concerns the privacy of individuals. In certain instances, audit data may contain personal information. Searching through the data, even for a routine check of the system's security, could represent an invasion of privacy 🙈

A second area of concern involves knowledge of intrusive behavior originating from your site. If an organization keeps audit data, is it responsible for examining it to search for incidents? If a host in one organization is used as a launching point for an attack against another organization, can the second organization use the audit data of the first organization to prove negligence on the part of that organization? That's a lot, fr fr 😵

The above examples are meant to be comprehensive, but they should motivate your organization to consider the legal issues involved with audit data 💜

4.7. Securing Backups 💾

The procedure of creating backups is a classic part of operating a computer system. Within the context of this document, backups are addressed as part of the overall security plan of a site. There are several aspects to backups that are important within this context:

1. Make sure your site is creating backups 📦
2. Make sure your site is using offsite storage for backups. The storage site should be carefully selected for both its security and its availability 🏢
3. Consider encrypting your backups to provide additional protection of the information once it is off-site. However, be aware that you will need a good key management scheme so that you'll be able to recover data at any point in the future. Also, make sure you will have access to the necessary decryption programs at such time in the future as you need to perform the decryption 🔑
4. Don't always assume that your backups are good. There have been many instances of computer security incidents that have gone on for long periods of time before a site has noticed the incident. In such cases, backups of the affected systems are also tainted 🫠
5. Periodically verify the correctness and completeness of your backups ✅

5. Security Incident Handling ✨

okay bestie, this chapter is the "what do we do when everything is on fire" guide 🔥 it's for before, during, and after a computer security incident, whether that's on a single host, a network, a whole site, or a multi-site setup. the big vibe is: react according to a plan 📋 that's true whether the chaos comes from an outside intruder, accidental damage, a student poking at a new program to exploit a software bug, or a disgruntled employee 💀 every type of event like that should be covered in advance by solid contingency plans, no exceptions.

Traditional computer security is super important in the overall site security plan, but it usually doesn't spend much time on how to actually handle an attack once it's happening 😭 so when an attack is in progress, people make decisions in a panic, and those panic decisions can wreck the trail back to whoever did it, mess up evidence that could be used in prosecution, make recovery harder, and put the valuable data on the system at risk 🙈

One of the most important (and most overlooked) perks of efficient incident handling is economic 💰 having both technical and managerial people respond to an incident takes a lot of resources. If your team is trained to handle incidents efficiently, less staff time is needed when one happens. iconic efficiency 💅

Because of the world-wide network, most incidents don't stay in one site 🌍 operating systems vulnerabilities can apply (in some cases) to several millions of systems, and lots of vulnerabilities get exploited within the network itself. So it is vital that every site with involved parties is informed as soon as possible 🫶

Another perk is public relations 🎀 news about computer security incidents tends to damage an organization's reputation among current or potential clients. Efficient incident handling keeps the potential for negative exposure as low as possible ✨

A final perk is legal stuff ⚖️ in the near future, organizations may be held responsible because one of their nodes was used to launch a network attack. Similarly, people who develop patches or workarounds may get sued if those patches or workarounds don't work and the systems get compromised, or if the patches or workarounds themselves damage systems 😳 so knowing about operating system vulnerabilities and attack patterns, and then taking appropriate measures to counter those threats, is critical for dodging possible legal problems. main character responsibility 👑

The sections in this chapter give you an outline and starting point for writing your site's policy on handling security incidents. The sections are:

1. Preparing and planning (what are the goals and objectives in handling an incident).
2. Notification (who should be contacted in the case of an incident).
   • Local managers and personnel
   • Law enforcement and investigative agencies
   • Computer security incidents handling teams
   • Affected and involved sites
   • Internal communications
   • Public relations and press releases
3. Identifying an incident (is it an incident and how serious is it).
4. Handling (what should be done when an incident occurs).
   • Notification (who should be notified about the incident)
   • Protecting evidence and activity logs (what records should be kept from before, during, and after the incident)
   • Containment (how can the damage be limited)
   • Eradication (how to eliminate the reasons for the incident)
   • Recovery (how to reestablish service and systems)
   • Follow Up (what actions should be taken after the incident)
5. Aftermath (what are the implications of past incidents).
6. Administrative response to incidents.

The rest of this chapter goes deep on each of these topics and gives some guidance on what should go into a site policy for handling incidents 🦋

---

5.1. Preparing and Planning for Incident Handling

Part of handling an incident is being ready to respond before it ever happens 🌸 that includes setting up a suitable level of protections, like we covered in the earlier chapters. Doing this helps your site prevent incidents AND limit the damage when they do happen. Protection also includes writing incident handling guidelines as part of a contingency plan for your org or site. Written plans clear up a lot of the confusion that happens mid-incident and lead to a more appropriate, thorough set of responses 📝 it is vitally important to test the proposed plan before an incident happens through "dry runs" 🏃‍♀️ a team might even consider hiring a tiger team to act in parallel with the dry run. (Note: a tiger team is a team of specialists that try to penetrate the security of a system. 🐯)

Learning to respond efficiently to an incident matters for a bunch of reasons:

1. Protecting the assets which could be compromised
2. Protecting resources which could be utilized more profitably if an incident did not require their services
3. Complying with (government or other) regulations
4. Preventing the use of your systems in attacks against other systems (which could cause you to incur legal liability)
5. Minimizing the potential for negative exposure

Like any pre-planned procedure, you've got to pay attention to a set of goals for handling an incident 🎯 these goals will be prioritized differently depending on the site. A specific set of objectives you can identify for dealing with incidents:

1. Figure out how it happened.
2. Find out how to avoid further exploitation of the same vulnerability.
3. Avoid escalation and further incidents.
4. Assess the impact and damage of the incident.
5. Recover from the incident.
6. Update policies and procedures as needed.
7. Find out who did it (if appropriate and possible).

Due to the nature of the incident, there might be a conflict between analyzing the original source of a problem and restoring systems and services 😬 overall goals (like keeping critical systems' integrity intact) might be the reason for not analyzing an incident. Of course, that's an important management decision, BUT everyone involved has to know that without analysis, the same incident may happen again 🔁

It's also important to set the order of actions for an incident well before one happens 📊 sometimes an incident is so complex that it's impossible to do everything at once, so priorities are essential. Priorities will vary from institution to institution, but these suggested priorities can serve as a starting point for your org's response:

1. Priority one -- protect human life and people's safety; human life always has precedence over all other considerations. 🫶
2. Priority two -- protect classified and/or sensitive data. Prevent exploitation of classified and/or sensitive systems, networks or sites. Inform affected classified and/or sensitive systems, networks or sites about already occurred penetrations. (Be aware of regulations by your site or by government)
3. Priority three -- protect other data, including proprietary, scientific, managerial and other data, because loss of data is costly in terms of resources. Prevent exploitations of other systems, networks or sites and inform already affected systems, networks or sites about successful penetrations.
4. Priority four -- prevent damage to systems (e.g., loss or alteration of system files, damage to disk drives, etc.). Damage to systems can result in costly down time and recovery. 💸
5. Priority five -- minimize disruption of computing resources (including processes). It is better in many cases to shut a system down or disconnect from a network than to risk damage to data or systems. Sites will have to evaluate the trade-offs between shutting down and disconnecting, and staying up. There may be service agreements in place that may require keeping systems up even in light of further damage occurring. However, the damage and scope of an incident may be so extensive that service agreements may have to be over-ridden.

an important implication: once human life and national security considerations are handled, it is generally more important to save data than system software and hardware 🚨 systems can be replaced, but the loss or compromise of data (especially classified or proprietary data) is usually not an acceptable outcome under any circumstances. Not on my watch 😤

Another big concern is the effect on others beyond the systems and networks where the incident happens 🌈 within the limits set by government regulations, it is always important to inform affected parties as soon as possible. Because of the legal implications here, it should be included in the planned procedures to avoid further delays and uncertainties for the administrators 🧚

Any plan for responding to security incidents should be guided by local policies and regulations. Government and private sites that deal with classified material have specific rules that they must follow 🔐

The policies your site chooses for how it reacts to incidents will shape your response 💜 for example, it may make little sense to build mechanisms that monitor and trace intruders if your site doesn't plan to take action against them when they're caught. Other organizations may have policies that affect your plans too. Telephone companies often release information about telephone traces only to law enforcement agencies 📞

Handling incidents can be tedious and involve a bunch of routine tasks that support personnel could take care of. To free up the technical staff, it may be helpful to identify support staff who will help with tasks like photocopying, faxing, etc. 🖨️💖

5.2 Notification and Points of Contact ✨

okay bestie, so it is SO important to set up your contacts before a real incident happens 💖 Lowkey, most incidents aren't real emergencies 🙈 Often you can handle the activities internally, no drama. But there will also be plenty of times when people outside your immediate department need to jump in, like local managers and system administrators, administrative contacts for other sites on the Internet, and various investigative organizations 🕵️‍♀️ Getting to know these contacts before incidents occur will make your incident handling process way more efficient, periodt 💅

For each type of communication contact, you should define specific "Points of Contact" (POC) 📇 These can be technical or administrative, and they may include legal or investigative agencies as well as service providers and vendors 🫶 When you set these up, decide how much information gets shared with each class of contact. This is especially important to define ahead of time for what gets shared with the users at a site, with the public (including the press), and with other sites 📣

Settling these issues matters a LOT for the local person handling the incident, since they're the one actually notifying everyone else 😭 A list of contacts in each of these categories is a huge time saver, because it can be really hard to find the right person mid-incident when a bunch of urgent stuff is happening at once 🌪️ It is strongly recommended that all relevant telephone numbers (also electronic mail addresses and fax numbers) be included in the site security policy 📞 Put the names and contact info of everyone who will be directly involved in handling an incident at the very top of that list, main character energy ✨

---

5.2.1 Local Managers and Personnel 👑

okay so when an incident is under way, a major issue is deciding who is in charge of coordinating all the different players 🎀 A big mistake is having a bunch of people each working independently but not working together. That just adds to the chaos, and it will probably lead to wasted or ineffective effort 😩

The single POC may or may not be the person responsible for handling the incident 💁‍♀️ There are two distinct roles to fill here. The person in charge of the incident makes decisions about how policy gets interpreted for the event. The POC, on the other hand, has to coordinate the effort of all the parties involved in handling the event 🧚

The POC needs to be a person with the technical expertise to successfully coordinate the efforts of the system managers and users who are monitoring and reacting to the attack 🔥 Be careful about who you pick for this. It should not necessarily be the same person who has administrative responsibility for the compromised systems 👀 Those admins often only know enough for day-to-day use of the computers and lack in-depth technical expertise, which is a no-go here 💀

Another important job for the POC is maintaining contact with law enforcement and other external agencies, so that multi-agency involvement actually happens 🚔 How much involvement there is will be determined by management decisions as well as legal constraints ⚖️

A single POC should also be the single person in charge of collecting evidence 🔍 As a rule of thumb, the more people who touch a potential piece of evidence, the greater the chance it will be inadmissible in court, so it's literally giving "too many cooks" 🍳 To make sure evidence will be acceptable to the legal community, collecting it should follow predefined procedures that match local laws and legal regulations 📜

One of the most critical tasks for the POC is coordinating all the relevant processes 💜 Responsibilities may be spread across the whole site and involve multiple independent departments or groups, which requires a well coordinated effort to achieve overall success 🤝 It gets even more complex when multiple sites are involved 🌐 When that happens, rarely will a single POC at one site be able to adequately coordinate handling of the entire incident. Instead, appropriate incident response teams should be involved 🦋

The incident handling process should provide some escalation mechanisms ⬆️ To define one, sites will need to create an internal classification scheme for incidents. Each level of incident will have an appropriate POC and procedures attached 🗂️ As an incident gets escalated, the POC may change, and that change needs to be communicated to everyone else involved in handling the incident 📢 When a change in the POC occurs, the old POC should brief the new POC on all background information 🫶

Lastly, users must know how to report suspected incidents 🙋‍♀️ Sites should establish reporting procedures that work both during and outside normal working hours ⏰ Help desks are often used to receive these reports during normal working hours, while beepers and telephones can be used for out-of-hours reporting 📟 bestie, you've got this 🌈

5.2.2. Law Enforcement and Investigative Agencies 🚨

Okay bestie, if an incident has legal consequences, you need to get in touch with investigative agencies (like the FBI and Secret Service in the U.S.) asap 🕵️‍♀️. Local law enforcement, local security offices, and campus police departments should also be looped in where it makes sense. This section covers a lot of the issues you'll run into, but every organization has its own local and government laws and regulations that shape how it works with law enforcement and investigators. So the biggest takeaway is that each site needs to work through this stuff itself 💅.

Why sort out your contacts way ahead of time? Once a major attack is happening, there's zero time to call around and figure out who the right person is 😭. Also, you want to build a good working relationship with these agencies, and that means playing by their working procedures. Knowing how they operate and what they expect from your point of contact is a huge step toward that 🫶. For example, you need to collect evidence that will hold up in any later legal proceedings, and that takes prior knowledge of how to gather it properly. And finally, you can't know in advance which agency will take jurisdiction over a particular incident. Making contacts and finding the right channels early means the response goes way more smoothly 🦋.

If your organization or site has a legal counsel, notify that office soon after you find out an incident is underway 📣. At a minimum, your legal counsel needs to be involved so your site's or organization's legal and financial interests are protected. There are a bunch of legal and practical questions in play, and here are a few:

1. Whether your site or organization is willing to risk negative publicity or exposure in order to cooperate with legal prosecution efforts.
2. Downstream liability--if you leave a compromised system as is so it can be monitored, and another computer is damaged because the attack originated from your system, your site or organization may be liable for damages incurred.
3. Distribution of information--if your site or organization distributes information about an attack in which another site or organization may be involved, or about a product vulnerability that may affect the ability to market that product, your site or organization may again be liable for any damages (including damage to reputation).
4. Liabilities due to monitoring--your site or organization may be sued if users at your site or elsewhere discover that your site is monitoring account activity without informing users.

Honestly, there aren't clear precedents yet on the liabilities or responsibilities of organizations involved in a security incident, or of organizations that might support an investigation 🤷‍♀️. Investigators often encourage organizations to help trace and monitor intruders. In fact, most investigators can't pursue computer intrusions without extensive support from the organizations involved. BUT investigators can't protect you from liability claims, and these efforts may drag on for months and take a lot of effort 😩.

On the flip side, an organization's legal council might advise extreme caution and suggest halting tracing activities and shutting the intruder out of the system. That alone may not protect you from liability, and it may stop investigators from identifying the perpetrator 🙈.

Balancing support for investigations against limiting liability is tricky, no cap 🎀. You'll need to weigh your legal counsel's advice against the damage the intruder is causing (if any) when you decide what to do during a particular incident.

Your legal counsel should also be involved in any decision to contact investigative agencies when an incident happens at your site 📞. The call to coordinate with investigative agencies is really up to your site or organization. Involving legal counsel also builds multi-level coordination between your site and the investigative agency involved, which leads to an efficient division of labor 👑. Plus, you're likely to get guidance that helps you avoid future legal mistakes.

Last but not least, your legal counsel should review your site's written procedures for responding to incidents. It's essential to get a "clean bill of health" from a legal perspective before you actually carry those procedures out 💖.

It's vital, when dealing with investigative agencies, to verify that the person calling for information is a legitimate representative of that agency 🚫. Sadly, many well-intentioned people have unknowingly leaked sensitive incident details or let unauthorized people into their systems because a caller pretended to be a government agency representative 💀. (Note: this word of caution actually applies to all external contacts.)

Using a secure means of communication matters too 🔐. Lots of network attackers can easily re-route electronic mail, so avoid using email to communicate with other agencies (and anyone else dealing with the incident). Non-secured phone lines (the regular phones used in the business world) are also frequent targets for tapping by network intruders, so be careful! 😤

There isn't one established set of rules for responding to an incident when the local government gets involved 🏛️. Normally (in the U.S.), except by legal order, no agency can force you to monitor, disconnect from the network, avoid telephone contact with suspected attackers, etc. Each organization has a set of local and national laws and regulations that must be followed when handling incidents. It's recommended that each site get familiar with those laws and regulations, and identify and get to know the contacts for agencies with jurisdiction well in advance of handling an incident 🌸.

5.2.3. Computer Security Incident Handling Teams 🦸‍♀️

There are currently a number of Computer Security Incident Response teams (CSIRTs) out there, like the CERT Coordination Center, the German DFN-CERT, and other teams around the globe 🌍. Teams exist for lots of major government agencies and large corporations. If one of these teams is available to you, notifying it should be a top priority in the early stages of an incident ⭐. These teams coordinate computer security incidents across a range of sites and larger entities. Even if the incident seems contained to a single site, a response team's information might help fully resolve it 🧩.

If it turns out the breach happened because of a flaw in the system's hardware or software, notify the vendor (or supplier) and a Computer Security Incident Handling team as soon as possible 🚨. This matters a lot because many other systems may be vulnerable, and vendors and response teams can help spread help to other affected sites 🫶.

When you're setting up a site policy for incident handling, it may be a good idea to create a subgroup, kind of like the teams that already exist, that's responsible for handling computer security incidents for the site (or organization) 🎀. If you make one, it's essential to open communication lines between this team and other teams. Once an incident is underway, it's really hard to build a trusted dialogue with other teams if none existed beforehand 😬.

5.2.4. Affected and Involved Sites 🌐

If an incident affects other sites, it's good practice to let them know 💌. It might be obvious from the start that the incident isn't limited to your site, or it might only show up after further analysis 🔍.

Each site can choose to contact other sites directly, or pass the information to an appropriate incident response team 📨. Finding the responsible POC at a remote site is often really hard, and the incident response team can make contact easier by using channels that are already established 🧚.

The legal and liability issues from a security incident will be different from site to site ⚖️. It's important to define a policy for sharing and logging information about other sites before an incident happens.

Information about specific people is super sensitive and may be covered by privacy laws 🙈. To avoid problems here, delete irrelevant information and include a statement about how to handle whatever remains. A clear statement of how this information will be used is essential 📜. Nobody who tells a site about a security incident wants to read about it in the public press 😳. Incident response teams are valuable here: when they pass information to responsible POCs, they can protect the anonymity of the original source. But be aware that in many cases, analyzing logs and information from other sites will reveal addresses of your site too 👀.

All of the problems above should NOT be taken as reasons to skip involving other sites 🙅‍♀️. In fact, experience from existing teams shows that most sites told about security problems aren't even aware their site had been compromised 😱. Without timely information, other sites are often unable to take action against intruders 🏃‍♀️.

5.2.5. Internal Communications 📢

During a major incident, it's crucial to communicate why certain actions are being taken, and how users (or departments) are expected to behave 💜. In particular, make it super clear to users what they are allowed to say (and not say) to the outside world, including other departments 🤐. For example, it would NOT be good for an organization if users replied to customers with something like, "I'm sorry the systems are down, we've had an intruder and we are trying to clean things up." It would be much better if they were told to respond with a prepared statement like, "I'm sorry our systems are unavailable, they are being maintained for better service in the future." ✨

Communications with customers and contract partners should be handled in a sensible but sensitive way 🫶. You can prep for the main issues by making a checklist. When an incident happens, use the checklist and add a sentence or two for the specifics of that incident 📝.

Public relations departments can be a huge help during incidents 💅. They should be involved in all planning, and they can write well-constructed responses for when contact with outside departments and organizations is necessary 🌈.

5.2.6 Public Relations - Press Releases ✨

okay so media coverage of computer security incidents in the United States has absolutely exploded 📰😭 and it's bound to spread to other countries as the Internet keeps going global 🌍. If you're in a country where this hasn't really happened yet, bestie, learn from what's happened in the U.S. so you get forwarned and prepared 🫶.

One of the biggest questions is when, who, and how much to tell the general public through the press 🎤. There's a lot to think about here. First and foremost, if your site has a public relations office, use that office as your liaison to the press 💅. PR people are trained in the type and wording of what gets released, and they'll help protect the site's image during and after the incident (if that's possible) 🌸. Another perk is that you can be super candid with them, and they act as a buffer between the nonstop press attention and the POC's need to stay in control of the incident 🛡️.

If there's no PR office, the stuff you release to the press has to be carefully considered 🧐. If the information is sensitive, it can be a good move to share only minimal or overview info 🤫. Keep in mind that anything you give the press could be reviewed really fast by the perpetrator of the incident 👀. Also, misleading the press can totally backfire and cause more damage than releasing sensitive information would have 💀.

It's hard to know ahead of time how much detail to give, but here are some guidelines to keep in your back pocket 🎀:

1. Keep the technical level of detail low. Detailed information about the incident may give others enough to launch similar attacks on other sites, or even hurt the site's ability to prosecute the guilty party once the event is over 🙅‍♀️.
2. Keep the speculation out of press statements. Speculating about who is causing the incident or why is very likely to be wrong, and it can make people's view of the incident way more inflamed 🔥.
3. Work with law enforcement professionals to make sure evidence is protected. If prosecution is involved, make sure the evidence collected is not leaked to the press 🔒.
4. Try not to be forced into a press interview before you're prepared. The popular press is famous for the "2 am" interview, where they hope to catch you off guard and get information they otherwise wouldn't have 😴📸.
5. Don't let press attention distract from handling the event. Always remember that successfully closing out the incident is of primary importance 🏁💖.

---

5.3 Identifying an Incident 🔍

5.3.1 Is It Real? 🤔

this stage is all about figuring out whether a problem actually exists 🕵️‍♀️. Of course, many if not most of the signs that get linked to virus infections, system intrusions, malicious users, and so on are just anomalies, like hardware failures or suspicious system or user behavior 🔧. To figure out if there's really an incident, it's usually super helpful to grab and use any detection software you have access to 🛠️. Audit information is also extremely useful, especially for figuring out whether there's a network attack 📊. It is extremely important to take a system snapshot as soon as you suspect something's wrong 📸. Lots of incidents set off a dynamic chain of events, so an initial system snapshot can be the most valuable tool for spotting the problem and any source of attack 🎯. Last but not least, start a log book 📓✨. Recording system events, phone conversations, time stamps, and so on can get you to a faster, more systematic identification of the problem, and it's the foundation for the later stages of incident handling 🧠💜.

There are certain indications, or "symptoms," of an incident that deserve special attention 👀🚨:

1. System crashes.
2. New user accounts (the account RUMPLESTILTSKIN has been unexpectedly created), or high activity on a previously low usage account 😳.
3. New files (usually with novel or strange file names, such as data.xx or k or .xx) 🗂️.
4. Accounting discrepancies (on a UNIX system you might notice the shrinking of an accounting file called /usr/admin/lastlog, which should make you very suspicious that there may be an intruder) 🧐.
5. Changes in file lengths or dates (a user should be suspicious if .EXE files on an MS DOS computer have unexplainedly grown by over 1800 bytes) 📈.
6. Attempts to write to the system (a system manager notices that a privileged user on a VMS system is trying to alter RIGHTSLIST.DAT) 😱.
7. Data modification or deletion (files start to disappear) 🫥.
8. Denial of service (a system manager and all other users get locked out of a UNIX system, which is now in single user mode) 🙅‍♀️.
9. Unexplained, poor system performance 🐌.
10. Anomalies (GOTCHA gets displayed on the console, or there are frequent unexplained "beeps") 👻.
11. Suspicious probes (there are numerous unsuccessful login attempts from another node) 🚪.
12. Suspicious browsing (someone becomes a root user on a UNIX system and accesses file after file across many user accounts) 🕵️.
13. Inability of a user to log in due to modifications of his or her account 🔐.

This list is by no means comprehensive. We've just listed a number of common indicators 📝. It's best to collaborate with other technical and computer security personnel and make the call as a group about whether an incident is actually happening 🫶👑.

5.3.2 Types and Scope of Incidents 🗺️

Along with identifying the incident comes evaluating its scope and impact 💅. It's important to correctly pin down the boundaries of the incident so you can deal with it effectively and prioritize your responses 🎯.

To figure out the scope and impact, you should define a set of criteria that fits your site and the types of connections available to it 📋. Some of the issues include:

1. Is this a multi-site incident?
2. Are many computers at your site affected by this incident?
3. Is sensitive information involved?
4. What is the entry point of the incident (network, phone line, local terminal, etc.)?
5. Is the press involved?
6. What is the potential damage of the incident?
7. What is the estimated time to close out the incident?
8. What resources could be required to handle the incident?
9. Is law enforcement involved?

5.3.3 Assessing the Damage and Extent 🩺

Analyzing the damage and extent of the incident can be pretty time consuming, but it should give you insight into the nature of the incident and help with the investigation and prosecution 🕰️🔎. As soon as the breach has happened, the entire system and all of its components should be considered suspect 🚩. System software is the most probable target 💻. Preparation is key if you want to be able to detect all changes to a possibly tainted system 🔑. This includes checksumming all media from the vendor using an algorithm that's resistant to tampering 🔐 (See sections 4.3).

If the original vendor distribution media are available, an analysis of all system files should begin, and any irregularities should be noted and referred to all parties involved in handling the incident 📂. It can be really hard, in some cases, to decide which backup media are showing a correct system status 😵‍💫. Think about it: the incident may have continued for months or years before anyone discovered it, and the suspect may be an employee of the site, or otherwise have intimate knowledge of or access to the systems 👀. In all cases, your pre-incident preparation will determine what recovery is possible 💖.

If the system supports centralized logging (most do), go back over the logs and look for abnormalities 📜. If process accounting and connect time accounting are enabled, look for patterns of system usage ⏱️. To a lesser extent, disk usage may shed light on the incident 💽. Accounting can provide a lot of helpful information for analyzing an incident and for prosecution afterward 🧾. Your ability to address every aspect of a specific incident really depends on how well this analysis goes 🫡✨.

---

5.4 Handling an Incident 🛠️

There are certain steps that are necessary during the handling of an incident 📋. In all security related activities, the most important point is that all sites should have policies in place 📜🎀. Without defined policies and goals, activities will be unfocused 🌀. Management and legal counsel should define the goals in advance 👑.

One of the most fundamental objectives is to restore control of the affected systems and to limit the impact and damage 🫶. In the worst case scenario, shutting down the system, or disconnecting it from the network, may be the only practical solution 🔌💀.

The activities involved are complex, so try to get as much help as you need 🤝. If you try to solve the problem alone, real damage might happen because of delays or missing information 😬. Most administrators take the discovery of an intruder as a personal challenge 😤. But if you go this route, other objectives outlined in the local policies may not always get considered 🙈. Trying to catch intruders may be a very low priority compared to system integrity, for example 🛡️. Monitoring a hacker's activity is useful, but it might not be considered worth the risk of allowing continued access 🧐💅.

5.4.1 Types of Notification and Exchange of Information

Okay so once you've confirmed that an incident is actually happening 🚨, the right people need to be notified, and ngl HOW you do it matters SO much for keeping things under control, both technically and emotionally 🫶. Describe the situation in as much detail as you can so people can acknowledge it quickly and actually understand the problem 💅. Be super careful about WHICH groups get the deep technical stuff. Sharing it with an incident handling team is a whole vibe because they can give you helpful hints for wiping out the vulnerabilities involved 🧚. But dumping that critical knowledge into the public domain (think USENET newsgroups or mailing lists) can put a large number of systems at risk of intrusion 💀. It's invalid to assume that every admin reading a particular newsgroup has access to operating system source code, or can even understand an advisory well enough to take adequate steps 🙈.

First things first, any notification to local or off-site personnel must be explicit 📣. That means any statement (an email, a phone call, a fax, a beeper, or a semaphone) giving info about the incident has to be clear, concise, and fully qualified ✨. When you're notifying people who will help you handle the event, a "smoke screen" only divides the effort and creates confusion 😵‍💫. If a division of labor gets suggested, it's helpful to tell each participant what's being accomplished in the other efforts 🫶. This not only cuts down on duplicated work, it also lets the people working on parts of the problem know where to get info relevant to their piece 🧩.

Another big one is being factual 💯. Trying to hide parts of the incident by giving false or incomplete info might not only block a successful resolution, it could even make things worse 📉.

The language you pick when notifying people can totally change how the info lands 🎀. Using emotional or inflammatory terms raises the potential for damage and negative outcomes, so it's important to stay calm in both written and spoken communications 🧘‍♀️.

Also, not everyone speaks the same language 🌍. That can cause misunderstandings and delays, especially if the incident is multi-national. Other international concerns include differing legal implications of a security incident and cultural differences. And honestly, cultural differences don't only exist between countries, they exist within countries too, between different social or user groups 👀. For example, an administrator of a university system might be very relaxed about attempts to connect to the system via telnet, but the administrator of a military system is likely to consider that exact same action a possible attack 🚩.

Notifying non-technical or off-site people is its own challenge 🧠. You have to describe the incident accurately without causing undue alarm or confusion. It's harder to explain it to a non-technical audience, but it's often MORE important 😤. A non-technical description may be needed for upper-level management, the press, or law enforcement liaisons, and these communications can make the difference between resolving the incident properly and escalating it to some higher level of damage 💥.

If an incident response team gets involved, you might need to fill out a template for the information exchange 📝. It can feel like extra work and adds a bit of delay, but it helps the team act on a minimum set of information ✅. The response team may also be able to respond to aspects of the incident that the local administrator doesn't even know about 👑. If information is given out to someone else, the following minimum information should be provided:

1. timezone of logs, ... in GMT or local time
2. information about the remote system, including host names, IP addresses and (perhaps) user IDs
3. all log entries relevant for the remote site
4. type of incident (what happened, why should you care)

If local information (like local user IDs) is included in the log entries, you'll need to sanitize the entries beforehand to avoid privacy issues 🙈🔒. In general, all information which might help a remote site resolve an incident should be given out, unless local policies prohibit this 🦋.

---

5.4.2 Protecting Evidence and Activity Logs

When you respond to an incident, document ALL the details 📖. This will be valuable info for yourself and everyone else trying to unravel what happened ✨. Documenting everything will ultimately save you time, because if you don't write down every relevant phone call, you're likely to forget a big chunk of info you got, and then you have to go back to the source and ask again 😩. At the same time, your records become evidence for prosecution, provided the case is heading that way ⚖️. Documenting the incident also helps you do a final assessment of the damage (which your management and law enforcement officers will absolutely want to know 👀), and it provides the basis for the later phases of handling: eradication, recovery, and follow-up "lessons learned" 📚. Since it's often infeasible to tell early on whether prosecution is viable, you should document as if you're gathering evidence for a court case 🕵️‍♀️. At a minimum, you should record:

1. all system events (audit records)
2. all actions you take (time tagged)
3. all external conversations (including the person with whom you talked, the date and time, and the content of the conversation)

The most straightforward way to keep documentation is a log book 📓. It gives you one centralized, chronological source of info when you need it, instead of making you flip through individual sheets of paper 🗂️. Much of this info is potential evidence in a court of law, so when a legal follow-up is possible, follow the prepared procedures and don't jeopardize it by mishandling possible evidence 🙅‍♀️. If appropriate, the following steps may be taken:

1. Regularly (e.g., every day) turn in photocopied, signed copies of your logbook (as well as media you use to record system events) to a document custodian.
2. The custodian should store these copied pages in a secure place (e.g., a safe).
3. When you submit information for storage, you should receive a signed, dated receipt from the document custodian.

⚠️ Failure to observe these procedures can result in invalidation of any evidence you obtain in a court of law. Seriously, follow the steps! 😭

---

5.4.3 Containment

The whole point of containment is to limit the extent of an attack 🛑. A big part of it is decision making, like figuring out whether to shut a system down, disconnect from a network, monitor system or network activity, set traps, or disable functions such as remote file transfer 🤔.

Sometimes the decision is trivial 🙌. For example, shut the system down if the information is classified, sensitive, or proprietary. But bear in mind that removing all access while an incident is in progress obviously tells ALL users, including the alleged problem users, that the administrators know there's a problem, and that can have a deleterious effect on an investigation 🫣. In some cases, it's prudent to remove all access or functionality ASAP and then restore normal operation in limited stages 🪜. In other cases, it's worth risking some damage to the system if keeping it up might help you identify an intruder 🕵️.

This stage should involve carrying out predetermined procedures 📋. Your organization or site should, for example, define acceptable risks when dealing with an incident, and should prescribe specific actions and strategies to match 💅. This matters most when a quick decision is needed and there's no time to contact all the involved parties first 🏃‍♀️. Without predefined procedures, the person in charge of the incident often won't have the power to make tough management calls (like losing the results of a costly experiment by shutting down a system) 😬. And a final activity that should happen during this stage is notifying the appropriate authorities 📞.

---

5.4.4 Eradication

Once the incident has been contained, it's time to eradicate the cause 🧹. But BEFORE you eradicate it, take great care to collect all the necessary info about the compromised system(s) and the cause of the incident, because it will likely be lost when you clean up the system 🗃️.

Software may be available to help with the eradication process, such as anti-virus software 🦠. If any bogus files have been created, archive them before deleting them 📦. For virus infections, it's important to clean and reformat any media containing infected files 💻. Finally, make sure ALL backups are clean 🔍. Lots of systems infected with viruses keep getting re-infected because people don't systematically eradicate the virus from their backups 🙄. After eradication, take a new backup 💾.

Removing ALL vulnerabilities after an incident is hard 😤. The key is knowledge and understanding of the breach 🧠.

It may be necessary to go back to the original distribution media and re-customize the system 🔄. To prep for this worst case scenario, keep a record of the original system setup and each customization change 📒. In the case of a network-based attack, it's important to install patches for each operating system vulnerability that was exploited 🩹.

As discussed in section 5.4.2, a security log can be SUPER valuable during this phase of removing vulnerabilities 🔥. The logs showing how the incident was discovered and contained can later help determine how extensive the damage from a given incident was 📊. The steps you took can be used in the future to make sure the problem doesn't resurface 🔁. Ideally, you should automate and regularly apply the same test that was used to detect the security incident 🤖.

If a particular vulnerability is isolated as having been exploited, the next step is finding a mechanism to protect your system 🛡️. The security mailing lists and bulletins are a good place to search for this info, and you can get advice from incident response teams 🫶.

---

5.4.5 Recovery

Once the cause of an incident has been eradicated, the recovery phase kicks off the next stage of action ✨. The goal of recovery is to return the system to normal 🌈. In general, bringing up services in order of demand, so users have a minimum of inconvenience, is the best practice 👑. And understand that the proper recovery procedures for the system are extremely important and should be specific to the site 💜.

5.4.6 Follow-Up ✨

okay so once you think a system is back to a "safe" state, it's still possible that holes, and even traps, are lurking in there 😭 this is the stage everyone skips and it's literally one of the most important ones 💅 in the follow-up stage, you keep monitoring the system for stuff that might have been missed during cleanup. it's smart to start with some of the tools from chapter 7 🔍 but remember, those tools don't replace constant system monitoring and good sysadmin habits 🫶

the most important part of follow-up is the postmortem analysis 🎀 ask yourself: exactly what happened, and when? how did the staff who handled the incident do? what info did they need fast, and how could they have gotten it ASAP? what would the staff do differently next time? 🤔

after an incident, it's a good idea to write a report that covers the exact sequence of events: how it was discovered, how it got fixed, how it's being monitored, and a summary of the lessons learned 📝 this helps everyone clearly understand the problem 💖 making a formal timeline with timestamps is also a big deal, because it matters for legal reasons ⚖️

a follow-up report is valuable for lots of reasons 👑 it gives you a reference in case similar incidents happen later 🧚 you also want to get a monetary estimate of the damage as quickly as possible 💸 that estimate should cover lost software and files (especially the value of proprietary data that might've been disclosed), hardware damage, and manpower costs for restoring altered files, reconfiguring affected systems, and so on. this estimate might become the basis for later prosecution 😤 and the report can help justify your org's computer security effort to management, which is iconic for getting the budget 🌸

5.5 Aftermath of an Incident 🌈

after an incident, a few things should happen. here's the quick version:

1. an inventory should be taken of the systems' assets (aka a careful look should figure out how the system was affected by the incident) 🔎
2. the lessons learned from the incident should be built into a revised security plan so it doesn't happen again 📋
3. a new risk analysis should be developed based on the incident 📊
4. if it's deemed desirable, an investigation and prosecution of the people who caused the incident should start 🚨

if an incident comes from bad policy, and the policy doesn't change, then you're literally doomed to repeat the past 💀 once a site has recovered, its policies and procedures should be reviewed to cover changes that prevent similar incidents 🛡️ even without an incident, it's smart to review policies and procedures on a regular basis. reviews are imperative because computing environments keep changing, periodt 🔄

the whole point of this postmortem process is to improve all security measures so the site is protected against future attacks 💜 a site or org should come out of an incident with real, practical knowledge 🧠 a concrete goal of the postmortem is to develop new proactive methods ⭐ and another big part of the aftermath can be educating end users and admins so the same security problem doesn't happen again 🫶

5.6 Responsibilities 💅

5.6.1 Not Crossing the Line 🚧

protecting your own network is one thing, but assuming you should protect other networks is a whole different vibe 🙈 while handling an incident, you might spot vulnerabilities in your own systems and in other people's systems. it's super easy, and even tempting, to go after the intruders to track them down 👀 but keep in mind that at a certain point you can "cross the line" and, even with the best intentions, become no better than the intruder 😬

the golden rule for propriety is to not use any facility of a remote site that isn't public 🚫 this clearly rules out getting onto a system (like a remote shell or login session) that you haven't been expressly permitted to access 🙅‍♀️ after a security breach is detected, an admin might have the means to "follow it up" and see what damage is being done to the remote site. this is so tempting, but don't do it! 💀 instead, try to reach the appropriate point of contact for the affected site 📞

5.6.2 Good Internet Citizenship 🦋

during a security incident you've got two choices 🤷‍♀️ first, a site can choose to watch the intruder in the hopes of catching them. or, the site can clean up after the incident and shut the intruder out of its systems. this decision has to be made really thoughtfully, because there may be legal liabilities if you leave your site open while knowing an intruder is using it as a launchpad to reach other sites 😨 being a good Internet citizen means you should try to alert other sites that may have been impacted by the intruder 🌍 those affected sites may be pretty obvious after a thorough review of your log files 🧾

5.6.3 Administrative Response to Incidents ⚖️

when a security incident involves a user, the site's security policy should describe what action to take 📜 the transgression should be taken seriously, but it's super important to be sure of the role the user played. was the user just naive? could the security breach be wrongly attributed to them? 🤔 admin action that assumes the user intentionally caused the incident might not be right for someone who just made a mistake 🙃 it may be appropriate to include sanctions that fit that situation in your policies (like education or a reprimand) alongside stricter measures for intentional intrusion and system misuse 🫶

6. Ongoing Activities 🔄

at this point, your site has hopefully developed a complete security policy and procedures to help configure and manage your tech in support of those policies 🎉 how nice would it be to sit back, relax, and know you're finished with security? unfortunately, that isn't possible 😭 your systems and networks aren't static, so you'll need to review policies and procedures on a regular basis. there are a bunch of steps you can take to keep up with the changes around you, so you can start corresponding actions to address them 🧚 the following is a starter set, and you can add others as fits your site 💖

1. subscribe to advisories issued by security incident response teams, like those of the CERT Coordination Center, and update your systems against the threats that apply to your site's technology 📣
2. monitor security patches produced by your equipment's vendors, and get and install all the ones that apply 🩹
3. actively watch the configurations of your systems to identify any changes that may have happened, and investigate all anomalies 👀
4. review all security policies and procedures annually (at a minimum) 📅
5. read relevant mailing lists and USENET newsgroups to keep up with the latest info fellow admins are sharing 📬
6. regularly check for compliance with policies and procedures 🔍 this audit should be done by someone other than the people who define or implement the policies and procedures. no grading your own homework 💅

7. Tools and Locations 🧰

this chapter gives a brief list of publicly available security tech that you can download from the Internet ✨ lots of the items below will undoubtedly be surpassed or made obsolete before this document is published, so keep that in mind 😅

some of the tools are applications, like end user programs (clients) and their supporting infrastructure (servers) 💻 others are tools a general user will never see or need to use, but applications may use them, or admins may use them to troubleshoot security problems or guard against intruders 🛡️

a sad fact is that there are very few security-conscious applications out there right now 😔 this is mostly because a security infrastructure has to be put in place first before most applications can operate securely 🏗️ there's a ton of effort going into building that infrastructure so applications can take advantage of secure communications 🔐

most of the tools and apps below can be found at one of these archive sites:

1. CERT Coordination Center: ftp://info.cert.org:/pub/tools 🦋
2. DFN-CERT: ftp://ftp.cert.dfn.de/pub/tools/ 🌸
3. Computer Operations, Audit, and Security Tools (COAST): coast.cs.purdue.edu:/pub/tools 🧚

it's important to note that many sites, including CERT and COAST, are mirrored throughout the Internet 🪞 be careful to use a "well known" mirror site to retrieve software, and use verification tools (md5 checksums, etc.) to validate that software ✅ a clever cracker might advertise security software that's been intentionally designed to provide access to data or systems 🚩

Heads up, bestie: a clever cracker might advertise fake security software, so always verify what you download with checksums like md5 🙈

Tools 🧰

COPS
DES
Drawbridge
identd (not really a security tool)
ISS
Kerberos
logdaemon
lsof
MD5
PEM
PGP
rpcbind/portmapper replacement
SATAN
sfingerd
S/KEY
smrsh
ssh
swatch
TCP-Wrapper
tiger
Tripwire*
TROJAN.PL

8. Mailing Lists and Other Resources 🎀

okay bestie, the list of places to hang out for site security is basically endless 😭 so this section just gives you some "jump-points" to start from. every single one of these is for the "INTERNET" crowd, and if you want more specific vendor or regional stuff, you can dig deeper from these starting spots 🔥

Mailing Lists 💌

(1) CERT(TM) Advisory

Send mail to: cert-advisory-request@cert.org Message Body: subscribe cert <FIRST NAME> <LAST NAME>

okay so a CERT advisory tells you how to get a patch or a workaround for a known computer security problem 🫶 the CERT Coordination Center works with vendors to cook up a workaround or patch, and it does NOT publish vulnerability info until that fix is actually available. a CERT advisory can also be a heads-up to the community about attacks that are happening right now, like "CA-91:18.Active.Internet.tftp.Attacks" 💀

CERT advisories also get posted on the USENET newsgroup:

comp.security.announce

and the CERT advisory archives are available via anonymous FTP from info.cert.org in the /pub/cert_advisories directory 🌸

(2) VIRUS-L List

Send mail to: listserv%lehiibm1.bitnet@mitvma.mit.edu Message Body: subscribe virus-L FIRSTNAME LASTNAME

VIRUS-L is a moderated mailing list all about computer virus stuff 🦋 if you want more info, including a copy of the posting guidelines, check out the file "virus-l.README", which you can grab by anonymous FTP from cs.ucr.edu ✨

(3) Internet Firewalls

Send mail to: majordomo@greatcircle.com Message Body: subscribe firewalls user@host

the Firewalls mailing list is a discussion forum for firewall administrators and implementors 🧱💜

USENET newsgroups 📰

(1) comp.security.announce

the comp.security.announce newsgroup is moderated and is used solely for distributing CERT advisories 👑

(2) comp.security.misc

comp.security.misc is a forum for discussing computer security, especially as it relates to the UNIX(r) Operating System 💅

(3) alt.security

alt.security is also a forum for computer security discussion, plus other stuff like car locks and alarm systems 🚗🔐 very wide range, iykyk 😭

(4) comp.virus

comp.virus is a moderated newsgroup focused on computer virus issues. for more info, including a copy of the posting guidelines, see the file "virus-l.README", available via anonymous FTP on info.cert.org in the /pub/virus-l directory 🦠

(5) comp.risks

comp.risks is a moderated forum on the risks to the public in computers and related systems ⚠️🌈

World-Wide Web Pages 🕸️

(1) http://www.first.org/

the Computer Security Resource Clearinghouse! the main focus is crisis response information, plus info on computer security threats, vulnerabilities, and solutions. at the same time, it tries to be a general index to computer security info on a whole bunch of subjects, including general risks, privacy, legal issues, viruses, assurance, policy, and training 🧚

(2) http://www.telstra.com.au/info/security.html

this Reference Index is a list of links to info sources on network and computer security. there is no implied fitness to the Tools, Techniques and Documents in this archive. many if not all of these items work well, but nobody guarantees that they will 🙈 this info is for education and legitimate use of computer security techniques only 🍓

(3) http://www.alw.nih.gov/Security/security.html

this page has general info about computer security, organized by source, with each section organized by topic. recent changes are noted on the What's New page 🌷

(4) http://csrc.ncsl.nist.gov

this archive, on the National Institute of Standards and Technology's Computer Security Resource Clearinghouse page, has a bunch of announcements, programs, and documents related to computer security 💜

CERT and Tripwire are registered in the U.S. Patent and Trademark Office ™

9. References 📚

the following references may not be available in all countries, so heads up on that 🌍

[Appelman, et. al., 1995] Appelman, Heller, Ehrman, White, and McAuliffe, "The Law and The Internet", USENIX 1995 Technical Conference on UNIX and Advanced Computing, New Orleans, LA, January 16-20, 1995.

[ABA, 1989] American Bar Association, Section of Science and Technology, "Guide to the Prosecution of Telecommunication Fraud by the Use of Computer Crime Statutes", American Bar Association, 1989.

[Aucoin, 1989] R. Aucoin, "Computer Viruses: Checklist for Recovery", Computers in Libraries, Vol. 9, No. 2, Pg. 4, February 1989.

[Barrett, 1996] D. Barrett, "Bandits on the Information Superhighway", O'Reilly & Associates, Sebastopol, CA, 1996.

[Bates, 1992] R. Bates, "Disaster Recovery Planning: Networks, Telecommunications and Data Communications", McGraw-Hill, 1992.

[Bellovin, 1989] S. Bellovin, "Security Problems in the TCP/IP Protocol Suite", Computer Communication Review, Vol 19, 2, pp. 32-48, April 1989.

[Bellovin, 1990] S. Bellovin, and M. Merritt, "Limitations of the Kerberos Authentication System", Computer Communications Review, October 1990.

[Bellovin, 1992] S. Bellovin, "There Be Dragon", USENIX: Proceedings of the Third Usenix Security Symposium, Baltimore, MD. September, 1992.

[Bender, 1894] D. Bender, "Computer Law: Evidence and Procedure", M. Bender, New York, NY, 1978-present.

[Bloombecker, 1990] B. Bloombecker, "Spectacular Computer Crimes", Dow Jones- Irwin, Homewood, IL. 1990.

[Brand, 1990] R. Brand, "Coping with the Threat of Computer Security Incidents: A Primer from Prevention through Recovery", R. Brand, 8 June 1990.

[Brock, 1989] J. Brock, "November 1988 Internet Computer Virus and the Vulnerability of National Telecommunications Networks to Computer Viruses", GAO/T-IMTEC-89-10, Washington, DC, 20 July 1989.

[BS 7799] British Standard, BS Tech Cttee BSFD/12, Info. Sec. Mgmt, "BS 7799 : 1995 Code of Practice for Information Security Management", British Standards Institution, London, 54, Effective 15 February 1995.

[Caelli, 1988] W. Caelli, Editor, "Computer Security in the Age of Information", Proceedings of the Fifth IFIP International Conference on Computer Security, IFIP/Sec '88.

[Carroll, 1987] J. Carroll, "Computer Security", 2nd Edition, Butterworth Publishers, Stoneham, MA, 1987.

[Cavazos and Morin, 1995] E. Cavazos and G. Morin, "Cyber-Space and The Law", MIT Press, Cambridge, MA, 1995.

[CCH, 1989] Commerce Clearing House, "Guide to Computer Law", (Topical Law Reports), Chicago, IL., 1989.

[Chapman, 1992] B. Chapman, "Network(In) Security Through IP Packet Filtering", USENIX: Proceedings of the Third UNIX Security Symposium, Baltimore, MD, September 1992.

[Chapman and Zwicky, 1995] B. Chapman and E. Zwicky, "Building Internet Firewalls", O'Reilly and Associates, Sebastopol, CA, 1995.

[Cheswick, 1990] B. Cheswick, "The Design of a Secure Internet Gateway", Proceedings of the Summer Usenix Conference, Anaheim, CA, June 1990.

[Cheswick1] W. Cheswick, "An Evening with Berferd In Which a Cracker is Lured, Endured, and Studied", AT&T Bell Laboratories.

[Cheswick and Bellovin, 1994] W. Cheswick and S. Bellovin, "Firewalls and Internet Security: Repelling the Wily Hacker", Addison-Wesley, Reading, MA, 1994.

[Conly, 1989] C. Conly, "Organizing for Computer Crime Investigation and Prosecution", U.S. Dept. of Justice, Office of Justice Programs, Under Contract Number OJP-86-C-002, National Institute of Justice, Washington, DC, July 1989.

[Cooper, 1989] J. Cooper, "Computer and Communications Security: Strategies for the 1990s", McGraw-Hill, 1989.

[CPSR, 1989] Computer Professionals for Social Responsibility, "CPSR Statement on the Computer Virus", CPSR, Communications of the ACM, Vol. 32, No. 6, Pg. 699, June 1989.

[CSC-STD-002-85, 1985] Department of Defense, "Password Management Guideline", CSC-STD-002-85, 12 April 1985, 31 pages.

[Curry, 1990] D. Curry, "Improving the Security of Your UNIX System", SRI International Report ITSTD-721-FR-90-21, April 1990.

[Curry, 1992] D. Curry, "UNIX System Security: A Guide for Users and Systems Administrators", Addision-Wesley, Reading, MA, 1992.

[DDN88] Defense Data Network, "BSD 4.2 and 4.3 Software Problem Resolution", DDN MGT Bulletin #43, DDN Network Information Center, 3 November 1988.

[DDN89] DCA DDN Defense Communications System, "DDN Security Bulletin 03", DDN Security Coordination Center, 17 October 1989.

[Denning, 1990] P. Denning, Editor, "Computers Under Attack: Intruders, Worms, and Viruses", ACM Press, 1990.

[Eichin and Rochlis, 1989] M. Eichin, and J. Rochlis, "With Microscope and Tweezers: An Analysis of the Internet Virus of November 1988", Massachusetts Institute of Technology, February 1989.

[Eisenberg, et. al., 89] T. Eisenberg, D. Gries, J. Hartmanis, D. Holcomb, M. Lynn, and T. Santoro, "The Computer Worm", Cornell University, 6 February 1989.

[Ermann, Willians, and Gutierrez, 1990] D. Ermann, M. Williams, and C. Gutierrez, Editors, "Computers, Ethics, and Society", Oxford University Press, NY, 1990. (376 pages, includes bibliographical references).

[Farmer and Spafford, 1990] D. Farmer and E. Spafford, "The COPS Security Checker System", Proceedings of the Summer 1990 USENIX Conference, Anaheim, CA, Pgs. 165-170, June 1990.

[Farrow, 1991] Rik Farrow, "UNIX Systems Security", Addison-Wesley, Reading, MA, 1991.

[Fenwick, 1985] W. Fenwick, Chair, "Computer Litigation, 1985: Trial Tactics and Techniques", Litigation Course Handbook Series No. 280, Prepared for distribution at the Computer Litigation, 1985: Trial Tactics and Techniques Program, February-March 1985.

[Fites 1989] M. Fites, P. Kratz, and A. Brebner, "Control and Security of Computer Information Systems", Computer Science Press, 1989.

[Fites, Johnson, and Kratz, 1992] Fites, Johnson, and Kratz, "The Computer Virus Crisis", Van Hostrand Reinhold, 2nd edition, 1992.

[Forester and Morrison, 1990] T. Forester, and P. Morrison, "Computer Ethics: Tales and Ethical Dilemmas in Computing", MIT Press, Cambridge, MA, 1990.

[Foster and Morrision, 1990] T. Forester, and P. Morrison, "Computer Ethics: Tales and Ethical Dilemmas in Computing", MIT Press, Cambridge, MA, 1990. (192 pages including index.)

[GAO/IMTEX-89-57, 1989] U.S. General Accounting Office, "Computer Security - Virus Highlights Need for Improved Internet Management", United States General Accounting Office, Washington, DC, 1989.

[Garfinkel and Spafford, 1991] S. Garfinkel, and E. Spafford, "Practical Unix Security", O'Reilly & Associates, ISBN 0-937175-72-2, May 1991.

[Garfinkel, 1995] S. Garfinkel, "PGP:Pretty Good Privacy", O'Reilly & Associates, Sebastopol, CA, 1996.

[Garfinkel and Spafford, 1996] S. Garfinkel and E. Spafford, "Practical UNIX and Internet Security", O'Reilly & Associates, Sebastopol, CA, 1996.

[Gemignani, 1989] M. Gemignani, "Viruses and Criminal Law", Communications of the ACM, Vol. 32, No. 6, Pgs. 669-671, June 1989.

Okay, the reading list keeps going, bestie 📚✨

[Goodell, 1996] J. Goodell, "The Cyberthief and the Samurai: The True Story of Kevin Mitnick-And The Man Who Hunted Him Down", Dell Publishing, 1996.

[Gould, 1989] C. Gould, Editor, "The Information Web: Ethical and Social Implications of Computer Networking", Westview Press, Boulder, CO, 1989.

[Greenia, 1989] M. Greenia, "Computer Security Information Sourcebook", Lexikon Services, Sacramento, CA, 1989.

[Hafner and Markoff, 1991] K. Hafner and J. Markoff, "Cyberpunk: Outlaws and Hackers on the Computer Frontier", Touchstone, Simon & Schuster, 1991.

[Hess, Safford, and Pooch] D. Hess, D. Safford, and U. Pooch, "A Unix Network Protocol Security Study: Network Information Service", Texas A&M University.

[Hoffman, 1990] L. Hoffman, "Rogue Programs: Viruses, Worms, and Trojan Horses", Van Nostrand Reinhold, NY, 1990. (384 pages, includes bibliographical references and index.)

[Howard, 1995] G. Howard, "Introduction to Internet Security: From Basics to Beyond", Prima Publishing, Rocklin, CA, 1995.

[Huband and Shelton, 1986] F. Huband, and R. Shelton, Editors, "Protection of Computer Systems and Software: New Approaches for Combating Theft of Software and Unauthorized Intrusion", Papers presented at a workshop sponsored by the National Science Foundation, 1986.

[Hughes, 1995] L. Hughes Jr., "Actually Useful Internet Security Techniques", New Riders Publishing, Indianapolis, IN, 1995.

[IAB-RFC1087, 1989] Internet Activities Board, "Ethics and the Internet", RFC 1087, IAB, January 1989. Also appears in the Communications of the ACM, Vol. 32, No. 6, Pg. 710, June 1989.

[Icove, Seger, and VonStorch, 1995] D. Icove, K. Seger, and W. VonStorch, "Computer Crime: A Crimefighter's Handbook", O'Reilly & Associates, Sebastopol, CA, 1995.

[IVPC, 1996] IVPC, "International Virus Prevention Conference '96 Proceedings", NCSA, 1996.

[Johnson and Podesta] D. Johnson, and J. Podesta, "Formulating A Company Policy on Access to and Use and Disclosure of Electronic Mail on Company Computer Systems".

[Kane, 1994] P. Kane, "PC Security and Virus Protection Handbook: The Ongoing War Against Information Sabotage", M&T Books, 1994.

[Kaufman, Perlman, and Speciner, 1995] C. Kaufman, R. Perlman, and M. Speciner, "Network Security: PRIVATE Communication in a PUBLIC World", Prentice Hall, Englewood Cliffs, NJ, 1995.

[Kent, 1990] S. Kent, "E-Mail Privacy for the Internet: New Software and Strict Registration Procedures will be Implemented this Year", Business Communications Review, Vol. 20, No. 1, Pg. 55, 1 January 1990.

[Levy, 1984] S. Levy, "Hacker: Heroes of the Computer Revolution", Delta, 1984.

[Lewis, 1996] S. Lewis, "Disaster Recovery Yellow Pages", The Systems Audit Group, 1996.

[Littleman, 1996] J. Littleman, "The Fugitive Game: Online with Kevin Mitnick", Little, Brown, Boston, MA., 1996.

[Lu and Sundareshan, 1989] W. Lu and M. Sundareshan, "Secure Communication in Internet Environments: A Hierarchical Key Management Scheme for End-to-End Encryption", IEEE Transactions on Communications, Vol. 37, No. 10, Pg. 1014, 1 October 1989.

[Lu and Sundareshan, 1990] W. Lu and M. Sundareshan, "A Model for Multilevel Security in Computer Networks", IEEE Transactions on Software Engineering, Vol. 16, No. 6, Page 647, 1 June 1990.

[Martin and Schinzinger, 1989] M. Martin, and R. Schinzinger, "Ethics in Engineering", McGraw Hill, 2nd Edition, 1989.

[Merkle] R. Merkle, "A Fast Software One Way Hash Function", Journal of Cryptology, Vol. 3, No. 1.

[McEwen, 1989] J. McEwen, "Dedicated Computer Crime Units", Report Contributors: D. Fester and H. Nugent, Prepared for the National Institute of Justice, U.S. Department of Justice, by Institute for Law and Justice, Inc., under contract number OJP-85-C-006, Washington, DC, 1989.

[MIT, 1989] Massachusetts Institute of Technology, "Teaching Students About Responsible Use of Computers", MIT, 1985-1986. Also reprinted in the Communications of the ACM, Vol. 32, No. 6, Pg. 704, Athena Project, MIT, June 1989.

[Mogel, 1989] Mogul, J., "Simple and Flexible Datagram Access Controls for UNIX-based Gateways", Digital Western Research Laboratory Research Report 89/4, March 1989.

[Muffett, 1992] A. Muffett, "Crack Version 4.1: A Sensible Password Checker for Unix"

[NCSA1, 1995] NCSA, "NCSA Firewall Policy Guide", 1995.

[NCSA2, 1995] NCSA, "NCSA's Corporate Computer Virus Prevention Policy Model", NCSA, 1995.

[NCSA, 1996] NCSA, "Firewalls & Internet Security Conference '96 Proceedings", 1996.

[NCSC-89-660-P, 1990] National Computer Security Center, "Guidelines for Formal Verification Systems", Shipping list no.: 89-660-P, The Center, Fort George G. Meade, MD, 1 April 1990.

[NCSC-89-254-P, 1988] National Computer Security Center, "Glossary of Computer Security Terms", Shipping list no.: 89-254-P, The Center, Fort George G. Meade, MD, 21 October 1988.

[NCSC-C1-001-89, 1989] Tinto, M., "Computer Viruses: Prevention, Detection, and Treatment", National Computer Security Center C1 Technical Report C1-001-89, June 1989.

[NCSC Conference, 1989] National Computer Security Conference, "12th National Computer Security Conference: Baltimore Convention Center, Baltimore, MD, 10-13 October, 1989: Information Systems Security, Solutions for Today - Concepts for Tomorrow", National Institute of Standards and National Computer Security Center, 1989.

[NCSC-CSC-STD-003-85, 1985] National Computer Security Center, "Guidance for Applying the Department of Defense Trusted Computer System Evaluation Criteria in Specific Environments", CSC-STD-003-85, NCSC, 25 June 1985.

[NCSC-STD-004-85, 1985] National Computer Security Center, "Technical Rationale Behind CSC-STD-003-85: Computer Security Requirements", CSC-STD-004-85, NCSC, 25 June 1985.

[NCSC-STD-005-85, 1985] National Computer Security Center, "Magnetic Remanence Security Guideline", CSC-STD-005-85, NCSC, 15 November 1985.

[NCSC-TCSEC, 1985] National Computer Security Center, "Trusted Computer System Evaluation Criteria", DoD 5200.28-STD, CSC-STD-001-83, NCSC, December 1985.

[NCSC-TG-003, 1987] NCSC, "A Guide to Understanding DISCRETIONARY ACCESS CONTROL in Trusted Systems", NCSC-TG-003, Version-1, 30 September 1987, 29 pages.

[NCSC-TG-001, 1988] NCSC, "A Guide to Understanding AUDIT in Trusted Systems", NCSC-TG-001, Version-2, 1 June 1988, 25 pages.

[NCSC-TG-004, 1988] National Computer Security Center, "Glossary of Computer Security Terms", NCSC-TG-004, NCSC, 21 October 1988.

[NCSC-TG-005, 1987] National Computer Security Center, "Trusted Network Interpretation", NCSC-TG-005, NCSC, 31 July 1987.

[NCSC-TG-006, 1988] NCSC, "A Guide to Understanding CONFIGURATION MANAGEMENT in Trusted Systems", NCSC-TG-006, Version-1, 28 March 1988, 31 pages.

[NCSC-TRUSIX, 1990] National Computer Security Center, "Trusted UNIX Working Group (TRUSIX) rationale for selecting access control list features for the UNIX system", Shipping list no.: 90-076-P, The Center, Fort George G. Meade, MD, 1990.

[NRC, 1991] National Research Council, "Computers at Risk: Safe Computing in the Information Age", National Academy Press, 1991.

[Nemeth, et. al, 1995] E. Nemeth, G. Snyder, S. Seebass, and T. Hein, "UNIX Systems Administration Handbook", Prentice Hall PTR, Englewood Cliffs, NJ, 2nd ed. 1995.

[NIST, 1989] National Institute of Standards and Technology, "Computer Viruses and Related Threats: A Management Guide", NIST Special Publication 500-166, August 1989.

[NSA] National Security Agency, "Information Systems Security Products and Services Catalog", NSA, Quarterly Publication.

[NSF, 1988] National Science Foundation, "NSF Poses Code of Networking Ethics", Communications of the ACM, Vol. 32, No. 6, Pg. 688, June 1989. Also appears in the minutes of the regular meeting of the Division Advisory Panel for Networking and Communications Research and Infrastructure, Dave Farber, Chair, November 29-30, 1988.

[NTISSAM, 1987] NTISS, "Advisory Memorandum on Office Automation Security Guideline", NTISSAM COMPUSEC/1-87, 16 January 1987, 58 pages.

[OTA-CIT-310, 1987] United States Congress, Office of Technology Assessment, "Defending Secrets, Sharing Data: New Locks and Keys for Electronic Information", OTA-CIT-310, October 1987.

[OTA-TCT-606] Congress of the United States, Office of Technology Assessment, "Information Security and Privacy in Network Environments", OTA-TCT-606, September 1994.

[Palmer and Potter, 1989] I. Palmer, and G. Potter, "Computer Security Risk Management", Van Nostrand Reinhold, NY, 1989.

[Parker, 1989] D. Parker, "Computer Crime: Criminal Justice Resource Manual", U.S. Dept. of Justice, National Institute of Justice, Office of Justice Programs, Under Contract Number OJP-86-C-002, Washington, D.C., August 1989.

[Parker, Swope, and Baker, 1990] D. Parker, S. Swope, and B. Baker, "Ethical Conflicts: Information and Computer Science, Technology and Business", QED Information Sciences, Inc., Wellesley, MA. (245 pages).

[Pfleeger, 1989] C. Pfleeger, "Security in Computing", Prentice-Hall, Englewood Cliffs, NJ, 1989.

[Quarterman, 1990] J. Quarterman, J., "The Matrix: Computer Networks and Conferencing Systems Worldwide", Digital Press, Bedford, MA, 1990.

[Ranum1, 1992] M. Ranum, "An Internet Firewall", Proceedings of World Conference on Systems Management and Security, 1992.

[Ranum2, 1992] M. Ranum, "A Network Firewall", Digital Equipment Corporation Washington Open Systems Resource Center, June 12, 1992.

[Ranum, 1993] M. Ranum, "Thinking About Firewalls", 1993.

[Ranum and Avolio, 1994] M. Ranum and F. Avolio, "A Toolkit and Methods for Internet Firewalls", Trustest Information Systems, 1994.

[Reinhardt, 1992] R. Reinhardt, "An Architectural Overview of UNIX Network Security"

[Reinhardt, 1993] R. Reinhardt, "An Architectural Overview of UNIX Network Security", ARINC Research Corporation, February 18, 1993.

[Reynolds-RFC1135, 1989] The Helminthiasis of the Internet, RFC 1135, USC/Information Sciences Institute, Marina del Rey, CA, December 1989.

[Russell and Gangemi, 1991] D. Russell and G. Gangemi, "Computer Security Basics" O'Reilly & Associates, Sebastopol, CA, 1991.

[Schneier 1996] B. Schneier, "Applied Cryptography: Protocols, Algorithms, and Source Code in C", John Wiley & Sons, New York, second edition, 1996.

[Seeley, 1989] D. Seeley, "A Tour of the Worm", Proceedings of 1989 Winter USENIX Conference, Usenix Association, San Diego, CA, February 1989.

[Shaw, 1986] E. Shaw Jr., "Computer Fraud and Abuse Act of 1986", Congressional Record (3 June 1986), Washington, D.C., 3 June 1986.

[Shimomura, 1996] T. Shimomura with J. Markoff, "Takedown:The Pursuit and Capture of Kevin Mitnick, America's Most Wanted Computer Outlaw- by the Man Who Did It", Hyperion, 1996.

[Shirey, 1990] R. Shirey, "Defense Data Network Security Architecture", Computer Communication Review, Vol. 20, No. 2, Page 66, 1 April 1990.

[Slatalla and Quittner, 1995] M. Slatalla and J. Quittner, "Masters of Deception: The Gang that Ruled Cyberspace", Harper Collins Publishers, 1995.

[Smith, 1989] M. Smith, "Commonsense Computer Security: Your Practical Guide to Preventing Accidental and Deliberate Electronic Data Loss", McGraw-Hill, New York, NY, 1989.

[Smith, 1995] D. Smith, "Forming an Incident Response Team", Sixth Annual Computer Security Incident Handling Workshop, Boston, MA, July 25-29, 1995.

   [Spafford, 1988] E. Spafford, "The Internet Worm Program: An
   Analysis", Computer Communication Review, Vol. 19, No. 1, ACM SIGCOM,
   January 1989.  Also issued as Purdue CS Technical Report CSD-TR-823,
   28 November 1988.

   [Spafford, 1989] G. Spafford, "An Analysis of the Internet Worm",
   Proceedings of the European Software Engineering Conference 1989,
   Warwick England, September 1989.  Proceedings published by Springer-
   Verlag as: Lecture Notes in Computer Science #387.  Also issued as
   Purdue Technical Report #CSD-TR-933.

   [Spafford, Keaphy, and Ferbrache, 1989] E. Spafford, K. Heaphy, and
   D. Ferbrache, "Computer Viruses: Dealing with Electronic Vandalism
   and Programmed Threats", ADAPSO, 1989. (109 pages.)

   [Stallings1, 1995] W. Stallings, "Internet Security Handbook", IDG
   Books, Foster City CA, 1995.

   [Stallings2, 1995] W. Stallings, "Network and InterNetwork Security",
   Prentice Hall, , 1995.

   [Stallings3, 1995] W. Stallings, "Protect Your Privacy: A Guide for
   PGP Users"  PTR Prentice Hall, 1995.

   [Stoll, 1988] C. Stoll, "Stalking the Wily Hacker", Communications of
   the ACM, Vol. 31, No. 5, Pgs. 484-497, ACM, New York, NY, May 1988.

   [Stoll, 1989] C. Stoll, "The Cuckoo's Egg", ISBN 00385-24946-2,
   Doubleday, 1989.

   [Treese and Wolman, 1993] G. Treese and A. Wolman, "X Through the
   Firewall, and Other Applications Relays", Digital Equipment
   Corporation, Cambridge Research Laboratory, CRL 93/10, May 3, 1993.

   [Trible, 1986] P. Trible, "The Computer Fraud and Abuse Act of 1986",
   U.S. Senate Committee on the Judiciary, 1986.

   [Venema] W. Venema, "TCP WRAPPER: Network monitoring, access control,
   and booby traps", Mathematics and Computing Science, Eindhoven
   University of Technology, The Netherlands.

   [USENIX, 1988] USENIX, "USENIX Proceedings: UNIX Security Workshop",
   Portland, OR, August 29-30, 1988.

   [USENIX, 1990] USENIX, "USENIX Proceedings: UNIX Security II
   Workshop", Portland, OR, August 27-28, 1990.

   [USENIX, 1992] USENIX, "USENIX Symposium Proceedings: UNIX Security
   III", Baltimore, MD, September 14-16, 1992.

   [USENIX, 1993] USENIX, "USENIX Symposium Proceedings: UNIX Security
   IV", Santa Clara, CA, October 4-6, 1993.

   [USENIX, 1995] USENIX, "The Fifth USENIX UNIX Security Symposium",
   Salt Lake City, UT, June 5-7, 1995.

   [Wood, et.al., 1987] C. Wood, W. Banks, S. Guarro, A. Garcia, V.
   Hampel, and H. Sartorio, "Computer Security:  A Comprehensive
   Controls Checklist", John Wiley and Sons, Interscience Publication,
   1987.

   [Wrobel, 1993] L. Wrobel, "Writing Disaster Recovery Plans for
   Telecommunications Networks and LANS", Artech House, 1993.

   [Vallabhaneni, 1989] S. Vallabhaneni, "Auditing Computer Security: A
   Manual with Case Studies", Wiley, New York, NY, 1989.

Security Considerations ✨

Okay bestie, the entire document is about security issues 🔒💀. Like, every single page, no cap. Security is the whole vibe here 💅

Editor Information 🎀

Meet the editor, Barbara Y. Fraser 👑 She's at the Software Engineering Institute, Carnegie Mellon University, and you can find her here:

   Barbara Y. Fraser
   Software Engineering Institute
   Carnegie Mellon University
   5000 Forbes Avenue
   Pittsburgh, PA 15213

   Phone: (412) 268-5010
   Fax:   (412) 268-6989
   EMail: byf@cert.org