RFC 1244

Site Security Handbook

📅 published July 1991, from ietf

Site Security Handbook 🎀

RFC 1244 · FYI 8 💖

Network Working Group, FYI 8 🧚 Edited by P. Holbrook (CICNet) and J. Reynolds (ISI) 💅 Dated July 1991 📅 Category: FYI, which is informational only ✨ The title block doesn't list anything it obsoletes or updates 🙈

Status of this Memo ✨

okay so this handbook came out of the Site Security Policy Handbook Working Group (SSPHWG) 🫶 It's a team effort between the Security Area and the User Services Area of the Internet Engineering Task Force (IETF) 🔥 This is an FYI RFC, so it's giving information for the Internet community, not an actual Internet standard 💀 Distribution of this memo is unlimited 🦋

Contributing Authors 🌸

these are the people who wrote the Site Security Handbook, and it literally wouldn't exist without them 😭 Dave Curry (Purdue University), Sean Kirkpatrick (Unisys), Tom Longstaff (LLNL), Greg Hollingsworth (Johns Hopkins University), Jeffrey Carpenter (University of Pittsburgh), Barbara Fraser (CERT), Fred Ostapik (SRI NISC), Allen Sturtevant (LLNL), Dan Long (BBN), Jim Duncan (Pennsylvania State University), and Frank Byrum (DEC) 👑

Editors' Note 💜

this FYI RFC is a first attempt at helping Internet users figure out how to handle security issues on the Internet 🌈 So yeah, it's necessarily incomplete, and there are some clear shortfalls 🙈 For example, it mostly focuses on resources available in the United States 🇺🇸 Following the spirit of the "Request for Comments" series, the editors really want feedback from people using the handbook, especially anyone using it to build their own policies and procedures 🫶

This handbook is meant to be a starting point for more research 🔍 It's a useful resource, but it is not the final authority ⭐ Different organizations and jurisdictions have different resources and rules, so talk to your local organizations, consult an informed lawyer, or check in with local and national law enforcement 💅 Those groups can fill in the gaps this document can't cover 🎀

Please don't treat this as the final word. Your local people and a real lawyer know things this handbook can't.

Finally, the editors plan for this FYI RFC to grow and evolve 🦋 Send comments and suggestions to ssphwg@cert.sei.cmu.edu 💌

Table of Contents 🍓

1.  Introduction.....................................................  3
1.1  Purpose of this Work............................................  3
1.2  Audience........................................................  3
1.3  Definitions.....................................................  4
1.4  Related Work....................................................  4
1.5  Scope...........................................................  4
1.6  Why Do We Need Security Policies and Procedures?................  5
1.7  Basic Approach..................................................  7
1.8  Organization of this Document...................................  7
2.  Establishing Official Site Policy on Computer Security...........  9
2.1  Brief Overview..................................................  9
2.2  Risk Assessment................................................. 10
2.3  Policy Issues................................................... 13
2.4  What Happens When the Policy Is Violated........................ 19
2.5  Locking In or Out............................................... 21
2.6  Interpreting the Policy......................................... 23
2.7  Publicizing the Policy.......................................... 23
3.  Establishing Procedures to Prevent Security Problems............. 24
3.1  Security Policy Defines What Needs to be Protected.............. 24
3.2  Identifing Possible Problems.................................... 24
3.3  Choose Controls to Protect Assets in a Cost-Effective Way....... 26
3.4  Use Multiple Strategies to Protect Assets....................... 26
3.5  Physical Security............................................... 27
3.6  Procedures to Recognize Unauthorized Activity................... 27
3.7  Define Actions to Take When Unauthorized Activity is Suspected.. 29
3.8  Communicating Security Policy................................... 30
3.9  Resources to Prevent Security Breaches.......................... 34
4.  Types of Security Procedures..................................... 56
4.1  System Security Audits.......................................... 56
4.2  Account Management Procedures................................... 57
4.3  Password Management Procedures.................................. 57
4.4  Configuration Management Procedures............................. 60
5.  Incident Handling................................................ 61
5.1  Overview........................................................ 61
5.2  Evaluation...................................................... 65
5.3  Possible Types of Notification.................................. 67
5.4  Response........................................................ 71
5.5  Legal/Investigative............................................. 73
5.6  Documentation Logs.............................................. 77
6.  Establishing Post-Incident Procedures............................ 78
6.1  Overview........................................................ 78
6.2  Removing Vulnerabilities........................................ 78
6.3  Capturing Lessons Learned....................................... 80
6.4  Upgrading Policies and Procedures............................... 81
7.  References....................................................... 81
8.  Annotated Bibliography........................................... 83
8.1  Computer Law.................................................... 84
8.2  Computer Security............................................... 85
8.3  Ethics.......................................... 91
8.4  The Internet Worm............................................... 93
8.5  National Computer Security Center (NCSC)........................ 95
8.6  Security Checklists............................................. 99
8.7  Additional Publications......................................... 99
9.  Acknlowledgements................................................101
10.  Security Considerations.........................................101
11.  Authors' Addresses..............................................101

1. Introduction ✨

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 💻 It lists the issues and factors a site must consider when setting its own policies 📝 It also makes some recommendations and talks through the relevant areas 🧠

this guide is only a framework 🖼️ To end up with a solid set of policies and procedures, a site will have to make a lot of decisions, get everyone to agree, and then communicate and implement the policies 💪

1.2. Audience 🎯

the audience for this work is system administrators and decision makers at sites (the ones more traditionally called "administrators" or "middle management") 👩‍💼 This document is not aimed at programmers or anyone trying to build secure programs or systems 🙅 Its focus is on the policies and procedures that need to be in place to support whatever technical security features a site is using 🔐

the primary audience is sites that are members of the Internet community 🌐 But honestly, any site that lets communication happen with other sites should find this useful too 💜 And as a general guide to security policies, it may also help 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 🖥️ That can include host computers that users use, routers, terminal servers, PCs, or other devices with access to the Internet 🧸 A site can be an end user of Internet services, or a service provider like a regional network 🛰️ Most of this guide's focus is on those end users 🎀

we assume the site can set its own policies and procedures, with the agreement and support of the people who actually own the resources 🤝

The "Internet" is the set of networks and machines that use the TCP/IP protocol suite, connected through gateways and sharing a common name and address space [1] 🌍

The term "system administrator" covers everyone responsible for the day-to-day running of resources 🛠️ That might be one person or an entire organization ✨

The term "decision maker" refers to the people at a site who set or approve policy 👑 They are often, but not always, the people who own the resources 💅

the IETF Security Policy Working Group (SPWG) is working on a set of recommended security policy guidelines for the Internet [23] 📜 Regional networks or owners of other resources may adopt these guidelines as policy 🏛️ This handbook should help sites carry out those policies as they want or need to 🦋

but here's the tea: even implementing the proposed policies isn't enough to fully secure a site 🙈 The proposed Internet policies only deal with network access security 🚪 They say nothing about how sites should handle local security issues 🏠

1.5. Scope 🔍

this document covers what a computer security policy should contain, what kinds of procedures are needed to enforce security, and some recommendations for dealing with the problem 🧩 When you're developing a security policy, you should pay close attention not only to the security needs of your local network, but also to the security needs of the other networks you're connected to 🌸

this is not a cookbook for computer security 🙅‍♀️ Every site has different needs, and a corporation's needs might be totally different from an academic institution's 🎓 Any security plan has to fit the needs and culture of its site 💖

This handbook does not cover the details of how to do risk assessment, contingency planning, or physical security 📉 Those things are essential for setting and implementing effective security policy, but this document leaves them to other documents 📚 It will try to point the way to some of those 🧭

This document also doesn't talk about how to design or implement secure systems or programs 🙅

1.6 Why Do We Need Security Policies and Procedures? 🛡️

okay so for most sites, how much they care about computer security depends on how risky and threatening things feel to them 😬

The computer world has changed SO much in the last twenty-five years 🕰️ Back then, most computers lived in data centers. They sat in locked rooms, and teams of people kept them carefully managed and physically locked down 🔒 Connections to the outside world were rare. Security threats were rare too, and they were mostly about insiders: authorized users misusing their accounts, theft, vandalism, that kind of thing. Those problems were well understood, and the fix was pretty simple: keep the computers behind locked doors and keep track of every resource 🚪

Computing in the 1990s is a totally different vibe 💻 Lots of systems sit in private offices and labs, often run by individuals or by people who don't work in a computer center at all. Tons of systems are connected to the Internet, and through it to the whole world. The United States, Europe, Asia, and Australia are all connected together 🌏✨

Security threats are different now too 😳 The old advice is "don't write your password down and put it in your desk" so nobody finds it. But with worldwide Internet connections, someone on the other side of the planet could get into your system and steal your password in the middle of the night, when your building is locked up and everyone's asleep 🌙 Viruses and worms can hop from machine to machine 🦠 The Internet is basically the digital version of a thief checking for open windows and doors, except now one person can check hundreds of machines for weaknesses in just a few hours. Wild, right? 💀

System administrators and decision makers need to understand the security threats that exist. They also need to know what the risk and cost of a problem would be, and what kind of action they want to take (if any) to prevent and respond to those threats 🧠💅

To show some of the issues you have to deal with in security problems, here are some scenarios (thanks to Russell Brand [2, BRAND] for these 🫶):

A system programmer gets a call saying that a major underground cracker newsletter is being distributed from the administrative machine at his center to five thousand sites in the US and Western Europe.

Eight weeks later, the authorities call to tell you that the information in one of those newsletters was used to disable "911" in a major city for five hours. 😱

A user calls to say he can't log in to his account at 3 o'clock in the morning on a Saturday. The system staffer can't log in either. After rebooting into single user mode, he finds that the password file is empty. By Monday morning, your staff figures out that a number of privileged file transfers happened between this machine and a local university.

Tuesday morning, a copy of the deleted password file is found on the university machine, along with password files for a dozen other machines.

A week later, you find that your system initialization files have been altered in a hostile way. 🥲

You get a call saying that a breakin to a government lab happened from one of your center's machines. You are asked to provide accounting files to help track down the attacker.

A week later, you are given a list of the machines at your site that have been broken into.

A reporter calls asking about the breakin at your center. You haven't heard of any such breakin.

Three days later, you learn that there was a breakin. The center director had his wife's name as his password. 🙈

A change in system binaries is detected.

The day it gets corrected, they change again. This keeps happening for weeks. 😤

If an intruder is found on your system, should you leave the system open to monitor the situation, or should you close the holes and open them up again later?
If an intruder is using your site, should you call law enforcement? Who makes that decision? If law enforcement asks you to leave your site open, who makes that decision? 🚨
What steps should be taken if another site calls you and says they see activity coming from an account on your system? What if the account belongs to a local manager? 👀

1.7 Basic Approach 🗺️

Setting security policies and procedures really means making a plan for how to handle computer security. One way to approach this, suggested by Fites, et. al. [3, FITES], goes like this:

Look at what you are trying to protect.
Look at what you need to protect it from.
Determine how likely the threats are.
Implement measures which will protect your assets in a cost-effective manner.
Review the process continuously, and improve things every time a weakness is found.

This handbook will mostly focus on the last two steps, but the first three are super important for making good security decisions 🧐 There's an old truism in security that the cost of protecting yourself against a threat should be less than the cost of recovering if the threat strikes you. Without a good idea of what you're protecting and what the likely threats are, following that rule could be really hard 😵‍💫

1.8 Organization of this Document 📚

This document is organized into seven parts in addition to this introduction.

The basic form of each section is to talk about issues a site might want to consider when creating a computer security policy and setting procedures to carry it out. In some cases, possible options are discussed, along with some of the ramifications of those choices. As far as possible, this document tries not to dictate the choices a site should make, since those depend on local circumstances. Some of the issues raised may not apply to every site. Still, all sites should at least consider the issues raised here so they don't miss some important area 💖

The overall flow of the document goes like this: policy issues first, then the issues that come up when you create procedures to put those policies into practice 🎀

Section 2 covers setting official site policies for access to computing resources. It also gets into what happens when a policy is violated. Policies drive the procedures that need to be created, so decision makers will need to make choices about policy before many of the procedural issues in the following sections can be handled. A key part of creating policies is doing some kind of risk assessment, to decide what really needs protecting and how many resources should go toward protecting it 💅

Once policies are in place, procedures to prevent future security problems should be set up. Section 3 defines and suggests actions to take when unauthorized activity is suspected. Resources for preventing security breaches are also discussed 🦋

Section 4 covers types of procedures that prevent security problems. Prevention is the key to security. For example, the Computer Emergency Response Team/Coordination Center (CERT/CC) at Carnegie-Mellon University (CMU) estimates that 80% or more of the problems they see have to do with poorly chosen passwords 🔑😩

Section 5 covers incident handling: what kinds of issues a site faces when someone violates the security policy. Lots of decisions have to be made on the spot as an incident happens, but many of the options and issues can be discussed in advance. At the very least, responsibilities and methods of communication can be set up before an incident. Again, the choices here are shaped by the policies discussed in Section 2 🌸

Section 6 deals with what happens after a security violation has been handled. Security planning is an ongoing cycle, and right after an incident is a perfect time to improve policies and procedures 🌈

The rest of the document provides references and an annotated bibliography 📖✨

2 Establishing Official Site Policy on Computer Security 👑

2.1 Brief Overview 🎀

2.1.1 Organization Issues 🏢

Okay bestie, so the goal of a site security policy is to spell out what the org expects for proper computer and network use, plus the procedures to prevent and respond to security incidents 🚨. To pull that off you have to look at the particular org you're dealing with ✨.

First, look at the goals and direction of the organization 🧭. A military base is gonna have totally different security concerns than a university 🎖️🎓, no cap.

Second, the policy has to conform to the existing policies, rules, regulations and laws the org is subject to 📜. So you gotta identify those and factor them in while writing the policy 💅.

Third, unless the local network is completely isolated and standalone 🏝️, you need to think about security in a more global context 🌍. The policy should cover local problems that develop because of a remote site, and problems on remote systems that happen because of a local host or user 👀.

2.1.2 Who Makes the Policy? 👑

Policy creation has to be a team effort 🫶. You need technical personnel who understand the full ramifications of the policy and how it gets implemented, and decision makers who actually have the power to enforce it 💼. A policy that's neither implementable nor enforceable is literally useless 💀.

Since a computer security policy can affect everyone in the org, take some care to make sure you've got the right level of authority on the policy decisions 🔐. A group like a campus information services group might be responsible for enforcing it, but an even higher group may need to support and approve it 🙌.

2.1.3 Who is Involved? 👥

Setting a site policy can involve every computer user at the site in a bunch of different ways 🫠. Computer users may be responsible for their own personal password administration 🔑. Systems managers are obligated to fix security holes and to oversee the system 🛠️.

It's critical to get the right people involved at the start 🚦. There may already be groups concerned with security who would see a computer security policy as their area 👀. Some types of groups that might be involved include auditing/control, organizations that deal with physical security, campus information systems groups, and so forth 🧑‍🤝‍🧑. Asking these groups to "buy in" from the start can help facilitate the acceptance of the policy ✅.

2.1.4 Responsibilities 📋

A key element of a computer security policy is making sure everyone knows their own responsibility for maintaining security 🔒. A policy can't anticipate every possibility, but it can make sure each kind of problem has someone assigned to deal with it 🎯.

There may be levels of responsibility tied to a policy on computer security 🪜. At one level, each user of a computing resource may have a responsibility to protect their account 🙋. A user who lets their account get compromised increases the chances of compromising other accounts or resources 😭.

System managers may form another responsibility level: they must help to ensure the security of the computer system 🖥️. Network managers may reside at yet another level 🌐.

2.2 Risk Assessment ⚖️

2.2.1 General Discussion 💭

One of the most important reasons for creating a computer security policy is to make sure the efforts spent on security yield cost effective benefits 💸. This may seem obvious, but it's really possible to be misled about where the effort is needed 🙃. For example, there's a ton of publicity about intruders on computer 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's the process of examining all of your risks and ranking them by level of severity 📊. This process is about making cost-effective decisions on what you want to protect. The old security adage says you should not spend more to protect something than it is actually worth 🤑.

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

Identifying the assets
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 it could affect these areas 👁️.

2.2.2 Identifying the Assets 📦

One step in a risk analysis is to identify all the things that need to be protected 📝. Some things are obvious, like all the various pieces of hardware, but some get overlooked, like the people who actually use the systems 🙋‍♀️. The essential point is to list all things that could be affected by a security problem ✨.

One list of categories is suggested by Pfleeger [16, PFLEEGER, page 459]; this list is adapted from that source 📖:

Hardware: cpus, boards, keyboards, terminals, workstations, personal computers, printers, disk drives, communication lines, terminal servers, routers.
Software: source programs, object programs, utilities, diagnostic programs, operating systems, communication programs.
Data: during execution, stored on-line, archived off-line, backups, audit logs, databases, in transit over communication media.
People: users, people needed to run systems.
Documentation: on programs, hardware, systems, local administrative procedures.
Supplies: paper, forms, ribbons, magnetic media.

2.2.3 Identifying the Threats 🦹

Once the assets requiring protection are identified, it's necessary to identify threats to those assets 🎯. The threats can then be examined to figure out what potential for loss exists 📉. It helps to ask what threats you're actually trying to protect your assets from 🤔.

The following sections describe a few of the possible threats 🕵️.

2.2.3.1 Unauthorized Access 🚪

A common threat that concerns many sites is unauthorized access to computing facilities, and it takes lots of forms 😤. One means of unauthorized access is using another user's account to get into a system 🎭. Using any computer resource without prior permission may be considered unauthorized access to computing facilities 🚫.

How serious an unauthorized access is will vary from site to site 📏. For some sites, just granting access to an unauthorized user may cause irreparable harm through negative media coverage 📺💀. For other sites, an unauthorized access opens the door to other security threats 🚪➡️. Some sites may also be more frequent targets than others, so the risk from unauthorized access varies from site to site 🎯. The Computer Emergency Response Team (CERT - see section 3.9.7.3.1) has observed that well-known universities, government sites, and military sites seem to attract more intruders 🧲.

2.2.3.2 Disclosure of Information 🫣

Another common threat is disclosure of information 👀. Figure out the value or sensitivity of the information stored on your computers 💎. Disclosure of a password file might allow for future unauthorized accesses 🔓. A glimpse of a proposal may give a competitor an unfair advantage 🏃‍♀️. A technical paper may contain years of valuable research 📚✨.

2.2.3.3 Denial of Service 🚫

Computers and networks provide valuable services to their users 💻. Lots of people rely on these services to do their jobs efficiently 💼. When the services aren't available when they're needed, productivity takes a hit 📉.

Denial of service comes in many forms and can affect users in a number of ways 🌪️. A network may be rendered unusable by a rogue packet, by jamming, or by a disabled network component 📡. A virus might slow down or cripple a computer system 🦠. Each site should determine which services are essential, and for each one, determine the effect on the site if that service became disabled 🧮.

2.3 Policy Issues 📝

There are a number of issues that must be addressed when developing a security policy 🧐. These are:

Who is allowed to use the resources?
What is the proper use of the resources?
Who is authorized to grant access and approve usage?
Who may have system administration privileges?
What are the user's rights and responsibilities?
What are the rights and responsibilities of the system administrator vs. those of the user?
What do you do with sensitive information?

These issues will be discussed below 👇. You may also want to include a section in your policy about ethical use of computing resources 🌷. Parker, Swope and Baker [17, PARKER90] and Forester and Morrison [18, FORESTER] are two useful references that address ethical issues 📖💜.

2.3.1 Who is Allowed to use the Resources? 🔑

One step you must take when developing your security policy is defining who is allowed to use your system and services 🪪. The policy should explicitly state who is authorized to use what resources 🙌.

2.3.2 What is the Proper Use of the Resources? 🧼

After you've determined who is allowed access to system resources, you need guidelines for acceptable use of those resources 📋. You may have different guidelines for different types of users, like students, faculty, and external users 🎓. The policy should state what is acceptable use as well as unacceptable use, and it should include types of use that may be restricted 🚧.

Define limits to access and authority 🧱. You'll need to consider the level of access various users will have and what resources will be available or restricted to various groups of people 🗝️.

Your acceptable use policy should clearly state that individual users are responsible for their actions 🫵. That responsibility exists regardless of the security mechanisms that are in place 🛡️. It should be clearly stated that breaking into accounts or bypassing security is not permitted 🙅‍♀️.

The following points should be covered when developing an acceptable use policy 📝:

Is breaking into accounts permitted?
Is cracking passwords permitted?
Is disrupting service permitted?
Should users assume that a file being world-readable grants them the authorization to read it?
Should users be permitted to modify files that are not their own even if they happen to have write permission?
Should users share accounts?

The answer to most of these questions will be "no" 🙅‍♀️💅

You may wish to add a statement to your policies about copyrighted and licensed software 📚✨ Licensing agreements with vendors can take some effort on your part so the license doesn't get violated, and you may also want to tell users that copying copyrighted software can break copyright laws and is not permitted 🙅‍♀️

Specifically for copyrighted and/or licensed software, you may wish to include the following:

Copyrighted and licensed software may not be duplicated unless it is explicitly stated that you may do so. 💅
Methods of conveying information on the copyright/licensed status of software.
When in doubt, DON'T COPY. 🚫🫶

Your acceptable use policy is SO important 😭 If it doesn't clearly say what is not permitted, you could end up unable to prove that a user violated policy. Not a vibe 💀

There are exception cases too, like tiger teams and users or administrators who want "licenses to hack" 🕵️‍♀️ You might find that users want to "hack" on your services for security research purposes. You should come up with a policy that decides whether you will allow this kind of research on your services and, if so, what your guidelines for it will be. 🧪

Points you may wish to cover in this area:

Whether it is permitted at all.
What type of activity is permitted: breaking in, releasing worms, releasing viruses, etc..
What type of controls must be in place to ensure that it does not get out of control (e.g., separate a segment of your network for these tests). 🚧
How you will protect other users from being victims of these activities, including external users and networks. 🛡️
The process for obtaining permission to conduct these tests.

In cases where you do permit these activities, you should isolate the portions of the network that are being tested from your main network. Worms and viruses should never be released on a live network. 🙅‍♀️🦠

You may also wish to employ, contract, or otherwise solicit one or more people or organizations to evaluate the security of your services, of which may include "hacking". You may wish to provide for this in your policy. 🧑‍💻💜

2.3.3. Who Is Authorized to Grant Access and Approve Usage? 🔑

Your policy should state who is authorized to grant access to your services. Further, it must be determined what type of access they are permitted to give. If you do not have control over who is granted access to your system, you will not have control over who is using your system. Controlling who has the authorization to grant access will also enable you to know who was or was not granting access if problems develop later. 🕰️

There are many schemes that can be developed to control the distribution of access to your services. The following are the factors that you must consider when determining who will distribute access to your services:

Will you be distributing access from a centralized point or at various points?

You can have a centralized distribution point or a distributed system where various sites or departments independently authorize access. The trade off is between security and convenience. The more centralized, the easier to secure. 🏰

What methods will you use for creating accounts and terminating access?

From a security standpoint, you need to examine the mechanism that you will be using to create accounts. In the least restrictive case, the people who are authorized to grant access would be able to go into the system directly and create an account by hand or through vendor supplied mechanisms. Generally, these mechanisms place a great deal of trust in the person running them, and the person running them usually has a large amount of privileges. If this is the choice you make, you need to select someone who is trustworthy to perform this task. The opposite solution is to have an integrated system that the people authorized to create accounts run, or the users themselves may actually run. Be aware that even in the restrictive case of having a mechanized facility to create accounts does not remove the potential for abuse. 🤖👀

You should have specific procedures developed for the creation of accounts. These procedures should be well documented to prevent confusion and reduce mistakes. A security vulnerability in the account authorization process is not only possible through abuse, but is also possible if a mistake is made. Having clear and well documented procedure will help ensure that these mistakes won't happen. You should also be sure that the people who will be following these procedures understand them. 📝✨

The granting of access to users is one of the most vulnerable of times. You should ensure that the selection of an initial password cannot be easily guessed. You should avoid using an initial password that is a function of the username, is part of the user's name, or some algorithmically generated password that can easily be guessed. In addition, you should not permit users to continue to use the initial password indefinitely. If possible, you should force users to change the initial password the first time they login. Consider that some users may never even login, leaving their password vulnerable indefinitely. Some sites choose to disable accounts that have never been accessed, and force the owner to reauthorize opening the account. 🥺🔐

2.3.4. Who May Have System Administration Privileges? 👑

One security decision that needs to be made very carefully is who will have access to system administrator privileges and passwords for your services. Obviously, the system administrators will need access, but inevitably other users will request special privileges. The policy should address this issue. Restricting privileges is one way to deal with threats from local users. The challenge is to balance restricting access to these to protect security with giving people who need these privileges access so that they can perform their tasks. One approach that can be taken is to grant only enough privilege to accomplish the necessary tasks. ⚖️

Additionally, people holding special privileges should be accountable to some authority and this should also be identified within the site's security policy. If the people you grant privileges to are not accountable, you run the risk of losing control of your system and will have difficulty managing a compromise in security. 🚨

2.3.5. What Are The Users' Rights and Responsibilities? 🎀

The policy should incorporate a statement on the users' rights and responsibilities concerning the use of the site's computer systems and services. It should be clearly stated that users are responsible for understanding and respecting the security rules of the systems they are using. The following is a list of topics that you may wish to cover in this area of the policy:

What guidelines you have regarding resource consumption (whether users are restricted, and if so, what the restrictions are).
What might constitute abuse in terms of system performance.
Whether users are permitted to share accounts or let others use their accounts.
How "secret" users should keep their passwords.
How often users should change their passwords and any other password restrictions or requirements.
Whether you provide backups or expect the users to create their own.
Disclosure of information that may be proprietary.
Statement on Electronic Mail Privacy (Electronic Communications Privacy Act).
Your policy concerning controversial mail or postings to mailing lists or discussion groups (obscenity, harassment, etc.).
Policy on electronic communications: mail forging, etc.

The Electronic Mail Association sponsored a white paper on the privacy of electronic mail in companies [4]. Their basic recommendation is that every site should have a policy on the protection of employee privacy. They also recommend that organizations establish privacy policies that deal with all media, rather than singling out electronic mail. 📧🔍

They suggest five criteria for evaluating any policy:

Does the policy comply with law and with duties to third parties?
Does the policy unnecessarily compromise the interest of the employee, the employer or third parties?
Is the policy workable as a practical matter and likely to be enforced?
Does the policy deal appropriately with all different forms of communications and record keeping with the office?
Has the policy been announced in advance and agreed to by all concerned? 📣

2.3.6. What Are The Rights and Responsibilities of System Administrators Versus Rights of Users ⚖️💭

There is a tradeoff between a user's right to absolute privacy and the need of system administrators to gather sufficient information to diagnose problems. There is also a distinction between a system administrator's need to gather information to diagnose problems and investigating security violations. The policy should specify to what degree system administrators can examine user files to diagnose problems or for other purposes, and what rights you grant to the users. You may also wish to make a statement concerning system administrators' obligation to maintaining the privacy of information viewed under these circumstances. A few questions that should be answered are:

Can an administrator monitor or read a user's files for any reason?
What are the liabilities?
Do network administrators have the right to examine network or host traffic?

2.3.7. What To Do With Sensitive Information 🤫🗂️

Before granting users access to your services, you need to determine at what level you will provide for the security of data on your systems. By determining this, you are determining the level of sensitivity of data that users should store on your systems. You do not want users to store very sensitive information on a system that you are not going to secure very well. You need to tell users who might store sensitive information what services, if any, are appropriate for the storage of sensitive information. This part should include storing of data in different ways (disk, magnetic tape, file servers, etc.). Your policy in this area needs to be coordinated with the policy concerning the rights of system administrators versus users (see section 2.3.6). 💖

2.4 What Happens When the Policy is Violated 🚨

okay so, no matter how amazing your policy is, it's going to get broken at some point. bestie, it's just how it goes 💀 A violation can come from someone being careless, making an accident, not being told about the current policy, or not really understanding it. It's also possible for someone (or a whole group) to knowingly break the policy on purpose. 🙈

When a violation is detected, the first move should already be planned out so enforcement is quick and correct. Then someone should investigate how and why it happened. After that, the right corrective action gets taken. The type and severity of that action depend on what kind of violation it was ✨

2.4.1 Determining the Response to Policy Violations

Violations can come from all kinds of users. Some will be local users, and some will be from outside the local environment. It can really help for a site to decide who counts as "insiders" and who counts as "outsiders," based on administrative, legal, or political boundaries. Those boundaries shape what action is needed to correct the offending party, from a written reprimand all the way up to pressing legal charges 😬 So you don't just need actions for each type of violation. You also need a clearly defined series of actions for each kind of user who breaks your computer security policy. It all sounds kinda complicated, I know, but you should sort it out long before a violation actually happens 🎀

Here's the thing to remember: proper education is your best defense 🛡️ For outsiders who are using your computer legally, it's your job to verify that they know the policies you've set. Having that proof can really help you later if legal action ever becomes necessary.

For users who are using your computer illegally, it's basically the same deal. Who violated the policy, and how and why did they do it? Depending on what the investigation finds, you might just decide to "plug" the hole in your computer security and chalk it up to experience. But if a significant amount of loss was incurred, you may want to take more drastic action 💅

2.4.2 What to do When Local Users Violate the Policy of a Remote Site

If a local user breaks the security policy of a remote site, the local site should have a clearly defined set of administrative actions to take against that local user. The site should also be ready to protect itself from possible actions by the remote site. These situations involve legal issues, which should be addressed when the security policy is being formed ⚖️✨

2.4.3 Defining Contacts and Responsibilities to Outside Organizations

The local security policy should include procedures for talking to outside organizations. That includes law enforcement agencies, other sites, external response team organizations (e.g., the CERT, CIAC), and various press agencies 📞 The procedure should say who is authorized to make that contact and how it should be handled. Some questions to answer include:

Who may talk to the press?
When do you contact law enforcement and investigative agencies?
If a connection is made from a remote site, is the system manager authorized to contact that site?
Can data be released? What kind?

Detailed contact information should be readily available, along with clearly defined procedures to follow 🧚

2.4.4 What are the Responsibilities to our Neighbors and Other Internet Sites?

The Security Policy Working Group within the IETF is working on a document called "Policy Guidelines for the Secure Operation of the Internet" [23]. It covers the idea that the Internet is a cooperative venture, and that sites are expected to give each other mutual security assistance 🫶 This should be addressed when a site's policy is being developed. The big question is how much information should be released. The answer will vary from site to site, depending on the type of site (e.g., military, education, commercial) and on the type of security violation that occurred 🌈

2.4.5 Issues for Incident Handling Procedures

Along with the policy statements, the document being prepared should include procedures for incident handling. That's covered in detail in the next chapter 📖 There should be procedures available that cover every facet of a policy violation.

2.5 Locking In or Out 🔐

whenever a site suffers an incident that may compromise computer security, how it reacts can be pushed by two opposing pressures. It's giving tug-of-war 😭

If management fears the site is vulnerable enough, it may choose a "Protect and Proceed" strategy. The main goal here is to protect and preserve the site's facilities, and to get users back to normal as quickly as possible 🏃‍♀️ The site will try to actively interfere with the intruder's processes, stop further access, and start damage assessment and recovery right away. This might mean shutting down the facilities, closing off network access, or other drastic measures. The catch is that unless the intruder is identified directly, they may come back into the site through a different path, or attack another site instead 😵

The other approach, "Pursue and Prosecute," is the complete opposite in philosophy and goals. The main goal is to let intruders keep going at the site until the site can identify the people responsible 🕵️‍♀️ Law enforcement agencies and prosecutors endorse this approach. The downside is that those agencies can't exempt a site from possible lawsuits by users if damage is done to their systems and data 💀

Prosecution isn't the only possible outcome if the intruder is identified. If the culprit is an employee or a student, the organization may choose to take disciplinary action 📝 The computer security policy needs to spell out the choices, and how they'll be selected, if an intruder is caught.

Site management has to think carefully about its approach to this issue before the problem happens. The strategy might depend on each circumstance. Or there may be a global policy that mandates one approach in all circumstances. The pros and cons must be examined thoroughly, and the users of the facilities must be made aware of the policy so they understand their vulnerabilities, no matter which approach is taken 🌸

The following checklists can help a site decide which strategy to adopt: "Protect and Proceed" or "Pursue and Prosecute" 💖

Protect and Proceed

If assets are not well protected.
If continued penetration could result in great financial risk.
If the possibility or willingness to prosecute is not present.
If user base is unknown.
If users are unsophisticated and their work is vulnerable.
If the site is vulnerable to lawsuits from users, e.g., if their resources are undermined.

Pursue and Prosecute

If assets and systems are well protected.
If good backups are available.
If the risk to the assets is outweighed by the disruption caused by the present and possibly future penetrations.
If this is a concentrated attack occurring with great frequency and intensity.
If the site has a natural attraction to intruders, and consequently regularly attracts intruders.
If the site is willing to incur the financial (or other) risk to assets by allowing the penetrator to continue.
If intruder access can be controlled.
If the monitoring tools are sufficiently well-developed to make the pursuit worthwhile.
If the support staff is sufficiently clever and knowledgeable about the operating system, related utilities, and systems to make the pursuit worthwhile.
If there is willingness on the part of management to prosecute.
If the system administrators know in general what kind of evidence would lead to prosecution.
If there is established contact with knowledgeable law enforcement.
If there is a site representative versed in the relevant legal issues.
If the site is prepared for possible legal action from its own users if their data or systems become compromised during the pursuit.

2.6 Interpreting the Policy 🧐

It's important to define who will interpret the policy. This could be an individual or a committee. No matter how well it's written, the policy will need interpreting from time to time, and this body would review, interpret, and revise the policy as needed 💜

2.7 Publicizing the Policy 📣

Once the site security policy has been written and established, a vigorous process should be started to make sure the policy statement is widely and thoroughly shared and discussed. Mailing out the policy should not be considered enough 🙅‍♀️ A period for comments should be allowed before the policy takes effect, so all affected users get a chance to share their reactions and talk through any unforeseen ramifications. Ideally, the policy should strike a balance between protection and productivity ⚖️

Meetings should be held to collect these comments, and also to make sure the policy is correctly understood. (Policy promulgators are not necessarily known for their skill with language 😂) These meetings should include higher management as well as line employees. Security is a collective effort 🫶

Beyond the initial push to publicize the policy, it's essential for the site to keep up a continual awareness of its computer security policy. Current users may need periodic reminders. New users should have the policy included in their site introduction packet. As a condition for using the site's facilities, it may be advisable to have them sign a statement that they have read and understood the policy. If any of these users require legal action for serious policy violations, that signed statement might prove to be a valuable aid 📝✨

3. Establishing Procedures to Prevent Security Problems 🔒

The security policy defines what needs to be protected. This section talks about the security procedures that specify what steps will be used to carry out the security policy 🦋

3.1. Security Policy Defines What Needs to be Protected 🎀

okay so the security policy is where you decide the WHATs: what needs to be protected, what matters most, what the priorities are, and what the general approach to security problems should be. 💅

The policy on its own doesn't say HOW things get protected. That's the job of security procedures, which is what this section is about. ✨ The policy should be a high level document that gives the general strategy, and the procedures need to spell out, in detail, the exact steps your site will take to protect itself. 🫶

The policy should also include a general risk assessment covering the types of threats a site is most likely to face and what those threats would cost you (see section 2.2). Part of doing that assessment is making a general list of assets that need protecting (section 2.2.2). This info is critical for coming up with procedures that are actually cost-effective. 🧠

It's super tempting to start with the mechanisms, like "our site should have logging on all hosts, call-back modems, and smart cards for all users." 🙈 But that approach can leave some areas way over-protected for the risk they face while other areas are underprotected. Starting from the security policy and the risks it lays out keeps the procedures at the right level of protection for every asset. 👑

3.2. Identifing Possible Problems 🔍

To figure out risk, you have to identify the vulnerabilities first. Part of the policy's purpose is helping to shore those up, which cuts risk in as many areas as possible. 🦋 A few of the most popular problem areas are covered in the sections below. This list is by no means complete, and every site is likely to have a few unique vulnerabilities of its own. 💜

3.2.1. Access Points 🚪

Access points are typically how unauthorized users get in. The more access points you have, the higher the risk of someone reaching your organization's computer and network facilities. 😬

Network links to outside networks let everyone else connected to that external network get into your organization. A network link usually gives access to a big pile of network services, and each one is a potential way in. 💀

Dialup lines might only give access to the login port of a single system, depending on how they're set up. If a dialup line is connected to a terminal server, though, it can give access to the entire network. 😭

Terminal servers can be a problem all on their own. Lots of them don't require any kind of authentication. Intruders love using them to hide what they're doing: they dial in on a local phone, then use the terminal server to head out onto the local network. Some terminal servers are set up so intruders can TELNET [19] in from outside the network and then TELNET back out again, which makes them way harder to trace. 🕵️‍♀️

3.2.2. Misconfigured Systems ⚙️

Misconfigured systems make up a large percentage of security holes, and honestly that's not a shock. Today's operating systems and their software are so complex that understanding how the system works is basically a full-time job. 😵‍💫 And the systems managers are often non-specialists picked from the organization's current staff. 🥲

Vendors are partly to blame too. To make installation easier, they sometimes pick initial configurations that aren't secure in every environment. 🙃

3.2.3. Software Bugs 🐛

Software will never be bug free, full stop. Publicly known security bugs are a common way for unauthorized people to get in. 😤 Part of the fix is being aware of these security problems and updating the software whenever a problem is detected. When you find bugs, report them to the vendor so a solution can be built and distributed. 🫶

3.2.4. "Insider" Threats 👀

Insiders can be a serious threat to the security of your computer systems. They often have direct access to computer and network hardware, and being able to get at the components of a system makes most systems much easier to compromise. 💅 Most desktop workstations can be easily manipulated so they grant privileged access. And access to a local area network lets someone view potentially sensitive data as it moves across the network. 🫣

3.3. Choose Controls to Protect Assets in a Cost-Effective Way 💖

Once you've decided what needs protecting and assessed the risks those assets face, you have to decide how to implement the controls that protect them. The controls and protection mechanisms should be picked so they adequately counter the threats found during the risk assessment, and so they're implemented in a cost-effective way. ✨ There's zero point spending an exorbitant amount of money and over-constricting the user base if the risk of exposure is very small. 💸

3.3.1. Choose the Right Set of Controls 🎯

The controls you select are the physical embodiment of your security policy. They're your first and primary line of defense for your assets, so it's super important that you pick the right set. 👑 If the major threat is outside penetrators, it probably doesn't make much sense to use biometric devices to authenticate your regular system users. But if the major threat is regular system users misusing computing resources, you'll probably want very rigorous automated accounting procedures. 🧾

3.3.2. Use Common Sense 🧠

Common sense is the most appropriate tool you have for establishing your security policy. Elaborate schemes and mechanisms are seriously impressive, and they do have their place 🤩 but there's little point pouring money and time into a fancy implementation if the simple controls get forgotten. For example, no matter how elaborate a system you build on top of existing security controls, a single user with a poor password can still leave your whole system open to attack. 😭🔓

3.4. Use Multiple Strategies to Protect Assets 🛡️

Another way to protect assets is to use multiple strategies. That way, if one strategy fails or gets circumvented, another one kicks in and keeps protecting the asset. 🌈 Several simpler strategies can often make a system more secure than one very sophisticated method swapped in for them. For example, dial-back modems can be used alongside traditional logon mechanisms. Lots of similar approaches could be devised that give assets several levels of protection. 🧩 Just don't go overboard with extra mechanisms, because it's really easy to do. Always keep in mind exactly what it is that needs protecting. 💜

3.5. Physical Security 🔒

Okay, bestie, this is the section everyone skips and then cries about later 😭. It is a given in computer security that if the system itself is not physically secure, nothing else about the system can be considered secure 💀. With physical access to a machine, an intruder can halt it, bring it back up in privileged mode, replace or alter the disk, plant Trojan horse programs (see section 2.13.9.2), or take any number of other undesirable (and hard to prevent) actions. Literally the scariest plot twist 🙈.

Critical communications links, important servers, and other key machines should be located in physically secure areas. Some security systems (such as Kerberos) require that the machine be physically secure 🔐.

If you cannot physically secure machines, care should be taken about trusting those machines. Sites should consider limiting access from non-secure machines to more secure machines. In particular, allowing trusted access (e.g., the BSD Unix remote commands such as rsh) from these kinds of hosts is particularly risky 🚩.

For machines that seem or are intended to be physically secure, care should be taken about who has access to the machines. Remember that custodial and maintenance staff often have keys to rooms 🧹🔑. The people with the mop can be the problem too, so keep the list tight 💅.

3.6. Procedures to Recognize Unauthorized Activity 👀

Several simple procedures can be used to detect most unauthorized uses of a computer system ✨. These procedures use tools provided with the operating system by the vendor, or tools publicly available from other sources 🧰.

3.6.1. Monitoring System Use

System monitoring can be done either by a system administrator, or by software written for the purpose. It basically means looking at several parts of the system and searching for anything unusual 🔍. Some of the easier ways to do this are described in this section.

The most important thing about monitoring system use is that it be done on a regular basis. Picking one day out of the month to monitor the system is pointless, since a security breach can be isolated to a matter of hours ⏰. Only by maintaining a constant vigil can you expect to detect security violations in time to react to them 👁️.

3.6.2. Tools for Monitoring the System

This section describes tools and methods for monitoring a system against unauthorized access and use 🛠️.

3.6.2.1. Logging

Most operating systems store numerous bits of information in log files 📜. Examining these log files on a regular basis is often the first line of defense in detecting unauthorized use of the system 🛡️.

Compare lists of currently logged in users and past login histories. Most users typically log in and out at roughly the same time each day. An account logged in outside the "normal" time for the account may be in use by an intruder 👀.
Many systems maintain accounting records for billing purposes. These records can also be used to determine usage patterns for the system; unusual accounting records may indicate unauthorized use of the system 🧾.
System logging facilities, such as the UNIX syslog utility, should be checked for unusual error messages from system software. For example, a large number of failed login attempts in a short period of time may indicate someone trying to guess passwords 🚨.
Operating system commands which list currently executing processes can be used to detect users running programs they are not authorized to use, as well as to detect unauthorized programs which have been started by an intruder 🕵️‍♀️.

3.6.2.2. Monitoring Software

Other monitoring tools can easily be constructed using standard operating system software, by using several, often unrelated, programs together 🧩. For example, checklists of file ownerships and permission settings can be constructed (for example, with ls and find on UNIX) and stored off-line 📁. These lists can then be reconstructed periodically and compared against the master checklist (on UNIX, by using the diff utility). Differences may indicate that unauthorized modifications have been made to the system 🚩.

Still other tools are available from third-party vendors and public software distribution sites. Section 3.9.9 lists several sources from which you can learn what tools are available and how to get them 🌈.

3.6.2.3. Other Tools

Other tools can also be used to monitor systems for security violations, although this is not their primary purpose 🙃. For example, network monitors can be used to detect and log connections from unknown sites 🌐.

3.6.3. Vary the Monitoring Schedule

The task of system monitoring is not as daunting as it may seem 💖. System administrators can execute many of the commands used for monitoring periodically throughout the day during idle moments (e.g., while talking on the telephone), rather than spending fixed periods of each day monitoring the system ☎️. By executing the commands frequently, you will rapidly become used to seeing "normal" output, and will easily spot things which are out of the ordinary 👑.

Varying the timing is the real power move 🦋. By running various monitoring commands at different times throughout the day, you make it hard for an intruder to predict your actions. For example, if an intruder knows that each day at 5:00 p.m. the system is checked to see that everyone has logged off, he will simply wait until after the check has completed before logging in 🙄. But the intruder cannot guess when a system administrator might type a command to display all logged-in users, and thus he runs a much greater risk of detection 🫣.

Plot twist: some intruders will be aware of the standard logging mechanisms in use on systems they are attacking. They will actively pursue and attempt to disable monitoring mechanisms 💀. So regular monitoring is useful for detecting intruders, but it does not provide any guarantee that your system is secure. Monitoring should not be considered an infallible method of detecting unauthorized use 🚫.

3.7. Define Actions to Take When Unauthorized Activity is Suspected 🚨

Sections 2.4 and 2.5 discussed the course of action a site should take when it suspects its systems are being abused 🧐. The computer security policy should state the general approach towards dealing with these problems 📋.

The procedures for dealing with these types of problems should be written down. Who has authority to decide what actions will be taken? Should law enforcement be involved? Should your organization cooperate with other sites in trying to track down an intruder? Answers to all the questions in section 2.4 should be part of the incident handling procedures 📝.

Whether you decide to lock out or pursue intruders, you should have tools and procedures ready to apply 🧯. It is best to work up these tools and procedures before you need them. Don't wait until an intruder is on your system to figure out how to track the intruder's actions; you will be busy enough if an intruder strikes 😅.

3.8. Communicating Security Policy ✨

okay so a security policy is only useful if people actually know it exists 🙈 it has to be communicated to both the users of the system AND the system maintainers. this section is about who needs to hear what, and how to tell them 💅

3.8.1. Educating the Users 🎀

users need to know how the computer systems are supposed to be used, and how to protect themselves from unauthorized users 🫶

3.8.1.1. Proper Account/Workstation Use 💖

every user should be told what counts as "proper" use of their account or workstation ("proper" use is discussed in section 2.3.2) 📝 the easiest moment to do this is when they first get their account, by handing them a policy statement ✨

proper use policies usually decide stuff like whether the account or workstation can be used for personal things (like balancing your checkbook or writing letters), whether making a profit is allowed, whether playing games is okay, and so on 🎮 these statements can also explain how the computer facility is licensed and which software licenses the institution holds 🔐 for example, lots of universities have educational licenses that flat out ban commercial use of the system, so that's a big deal 😭 a fuller list of things to think about when writing a policy statement is in section 2.3 🧚

3.8.1.2. Account/Workstation Management Procedures 🌸

each user should be told how to manage their account and workstation properly 💅 that means explaining how to protect the files stored on the system, how to log out or lock the terminal or workstation, and more 🔒 most of this is usually already in the "beginning user" docs from the operating system vendor, though lots of sites like to add their own local info on top 🍓

if your site offers dial-up modem access to the computer systems, you've gotta be extra careful about telling users the security problems that come with it 🚨 things like making sure they log out before hanging up the modem should be covered right when they first get dial-up access 📞

local and wide-area networks come with their own set of security problems too, and users should know about them 🌐 files that give "trusted host" or "trusted user" status to remote systems and users need to be explained really carefully 🫣

3.8.1.3. Determining Account Misuse 🔍

users should be told how to spot unauthorized access to their account 🕵️‍♀️ if the system prints the last login time when someone logs in, they should check that time and see whether it matches the last time they actually logged in 👀

some command interpreters (like the UNIX C shell) keep a history of the last several commands that were run 📜 users should check these histories to make sure nobody else has run other commands using their account 😤

3.8.1.4. Problem Reporting Procedures 📣

there should be a procedure that lets users report suspected misuse of their accounts, or any other misuse they've noticed 🙋‍♀️ you can do this by giving them the name and phone number of a system administrator who handles the security of the computer system, or by setting up an electronic mail address (for example, "security") that users can send their problems to 💌

3.8.2. Educating the Host Administrators 👑

in lots of organizations, computer systems are run by a whole bunch of different people 🙌 these administrators need to know how to protect their own systems from attack and unauthorized use 🛡️ they also need to know how to tell other administrators about a successful break-in so everyone else gets a warning 🚩

3.8.2.1. Account Management Procedures 🔐

you have to be careful when setting up accounts on the system so they end up secure 🧐 when you install a system from distribution media, check the password file for "standard" accounts the vendor included 👀 lots of vendors ship accounts for system services or field service personnel, and these usually have either no password or one that's common knowledge 😬 if those accounts are needed, give them new passwords, and if they aren't, disable or delete them 🗑️

accounts without passwords are generally super dangerous since they let anyone into the system 💀 even accounts that don't run a command interpreter (like accounts that only exist to show who's logged in) can get compromised if they're set up wrong 😱 there's also "anonymous" file transfer (FTP) [20], which lets users from all over the network reach your system to grab files from (usually) a protected disk area 🌍 weigh the benefits of a password-less account against the security risks of giving that kind of access to your system, carefully ⚖️

if the operating system has a "shadow" password facility, which stores passwords in a separate file that only privileged users can access, you should use it 🫶 System V UNIX, SunOS 4.0 and above, and versions of Berkeley UNIX after 4.3BSD Tahoe (plus others) all have this feature ✨ it protects passwords by hiding their encrypted values from unprivileged users 🙈 that stops an attacker from copying your password file to their own machine and trying to crack the passwords at their leisure 🕰️

keep track of who has access to privileged user accounts (like "root" on UNIX or "MAINT" on VMS) 🗝️ whenever a privileged user leaves the organization or no longer needs the privileged account, change the passwords on all privileged accounts 🔄

3.8.2.2. Configuration Management Procedures ⚙️

when you install a system from distribution media or install third-party software, check the installation carefully 🔎 a lot of installation procedures assume you're on a "trusted" site, so they'll install files with world write permission enabled, or otherwise mess with the security of files 😤

network services should also be looked at carefully when they're first installed 👀 many vendors ship default network permission files that imply all outside hosts are "trusted", which is rarely the case once you're connected to wide-area networks like the Internet 🌐

intruders often collect info on the vulnerabilities of particular system versions 🕵️ the older a system is, the more likely it has security problems that the vendor has already fixed in a later release 🧓 so weigh the risk of not upgrading to a new operating system release (leaving security holes unplugged) against the cost of upgrading (possibly breaking third-party software, etc.) 🤔 vendor bug fixes should be weighed in a similar way, with the extra note that "security" fixes from a vendor usually address pretty serious security problems 🚑

other bug fixes, the kind you get through network mailing lists and the like, should usually be installed, but not without careful examination 📬 never install a bug fix unless you're sure what its consequences are 🙅‍♀️ there's always the chance that an intruder suggested a "fix" which actually gives them access to your system 😈

3.8.2.3. Recovery Procedures - Backups 💾

you literally cannot overemphasize how much you need a good backup strategy 😭 file system backups protect you if hardware fails or files get deleted by accident, but they also protect you against unauthorized changes made by an intruder 🛟 without a copy of your data the way it's "supposed" to be, it can be really hard to undo something an attacker has done 🥲

backups, especially if they're run daily, can also show you a history of an intruder's activities 📅 looking through old backups can reveal when your system was first penetrated 🕵️‍♀️ intruders may leave files lying around that get deleted later but still get captured on the backup tapes 📼 backups can also document an intruder's activities for law enforcement agencies if needed 🚔

a good backup strategy dumps the entire system to tape at least once a month 🗓️ partial (or "incremental") dumps should be done at least twice a week, and ideally they should be done daily 🔁 use commands made specifically for file system backups (like UNIX "dump" or VMS "BACKUP") instead of other file copying commands 🙌 those tools are designed with the express goal of restoring a system to a known state, which is exactly what you want 💖

3.8.2.4. Problem Reporting Procedures 🚨

just like users, system administrators should have a defined procedure for reporting security problems 📣 in big installations, that's often an electronic mail alias containing the names of all the system administrators in the organization 📧 other options include setting up a response team similar to the CERT, or a "hotline" run by an existing support group ☎️

3.9. Resources to Prevent Security Breaches 🧰

this section talks about the software, hardware, and procedural resources you can use to back up your site security policy 💪

3.9.1. Network Connections and Firewalls 🔥

a "firewall" is put in a building to act as a point of resistance against flames spreading into another area 🔥🧱 a secretary's desk and reception area works the same way, since it's a checkpoint that controls access to the other office spaces 🏢 this same technique can be applied to a computer site, especially when it comes to network connections 🌐✨

some sites are only connected to other sites within the same organization and can't connect to other networks at all 🏝️ those sites are less susceptible to threats from outside their organization, although intrusions can still happen through paths like dial-up modems 📞 on the flip side, lots of other organizations are connected to other sites through much bigger networks, like the Internet 🌍 those sites are susceptible to the entire range of threats that come with a networked environment 😬💀

Okay so, connecting to outside networks is a whole risk vs. reward situation 😤✨ The risks must be weighed against the benefits, and it may be smart to limit outside connections to hosts that don't store sensitive stuff 🙈 Keep the "vital" machines (the ones running payroll or inventory systems) isolated. 🔒

If you need to join a Wide Area Network (WAN), consider restricting all access to your local network through a single system. Basically, all traffic to or from your local network has to go through one host computer that acts as a firewall between you and the outside world 🧱 That firewall system should be rigorously controlled and password protected, and external users who reach it should be constrained by limiting what they can do. Once you have that, your site can relax some of its internal security controls on the local net and still be protected by a super locked-down host front end. Iconic. 💅

Note that even with a firewall, compromising the firewall could mean compromising the network behind it 💀 Some people have worked on building a firewall that still protects the local network even when it's been compromised [6, CHESWICK] 🦋

3.9.2 Confidentiality 🤫

Confidentiality, which is basically keeping things hidden or secret, is one of the main goals of computer security folks 🫶 Most modern operating systems give users several mechanisms to control who gets to see their information. It depends on where you work: you might be at a site where everything is locked down, a site where basically all info is treated as public, or something in-between. Most sites lean toward the in-between, at least until someone gets in and causes a mess 😭

Generally, information can be exposed in three situations: when it's stored on a computer system, when it's in transit to another system (on the network), and when it's stored on backup tapes 📼

The first case is handled by file permissions, access control lists, and other similar mechanisms. The last can be handled by restricting access to the backup tapes (like locking them in a safe, for example). All three cases can be helped by using encryption mechanisms 🔐

3.9.2.1 Encryption (hardware and software)

Encryption is the process of taking information that's in some readable form and converting it into a non-readable form 🪄 There are several commercially available encryption packages in both hardware and software forms. Hardware encryption engines are much faster than the software version, but because they're faster, they're also more useful to an attacker who wants to run a brute-force attack on your encrypted info 👀

The big advantage of encryption is that even if other access control mechanisms (passwords, file permissions, etc.) get compromised by an intruder, the data is still unusable 🙌 Naturally, encryption keys and the like should be protected at least as well as account passwords 🔑

Information in transit over a network may also be vulnerable to interception 😬 There are a few solutions, ranging from simply encrypting files before transferring them (end-to-end encryption) to special network hardware that encrypts everything it sends without any user intervention (secure links). The Internet as a whole doesn't use secure links, so end-to-end encryption must be used if you want encryption across the Internet 🌐

3.9.2.1.1 Data Encryption Standard (DES)

DES is perhaps the most widely used data encryption mechanism today 💖 Lots of hardware and software implementations exist, and some commercial computers come with a software version. DES turns plain text into encrypted data (or ciphertext) using a special algorithm and a "seed" value called a key 🗝️ As long as the original user keeps (or remembers) the key, the ciphertext can be restored to the original plain text.

One pitfall of every encryption system is that you have to remember the key something was encrypted under (kind of like the password problem discussed elsewhere in this document 🙃). If you write the key down, it becomes less secure. If you forget it, there's little (if any) hope of recovering the original data 😱

Most UNIX systems provide a DES command that lets a user encrypt data with the DES algorithm ✨

3.9.2.1.2 Crypt

Similar to the DES command, the UNIX "crypt" command lets a user encrypt data. Unfortunately, the algorithm "crypt" uses is very insecure 💀 It's based on the World War II "Enigma" device, and files encrypted with this command can be decrypted easily in a matter of a few hours. Generally, you should avoid using the "crypt" command for anything but the most trivial encryption tasks 🙅‍♀️

3.9.2.2 Privacy Enhanced Mail 📬

Electronic mail normally travels across the network in the clear (meaning anyone can read it) 👁️ This is obviously not the optimal solution. Privacy enhanced mail gives you a way to automatically encrypt email messages, so someone eavesdropping at a mail distribution node is not (easily) able to read them 🕵️‍♀️ Several privacy enhanced mail packages are being developed and deployed on the Internet right now.

The Internet Activities Board Privacy Task Force has defined a draft standard, elective protocol for implementing privacy enhanced mail. It's defined in RFCs 1113, 1114, and 1115 [7,8,9]. For the standardization state and status of these protocols, check the current edition of the "IAB Official Protocol Standards" (currently, RFC 1200 [21]) 📚

3.9.3 Origin Authentication 🪪

We mostly take it on faith that the header of an email message truly shows who sent it. But it is easy to "spoof," or forge, the source of a mail message 🫣 Origin authentication gives you a way to be certain of who originated a message or other object, kind of like how a Notary Public confirms a signature on a legal document ✍️ This is done with a "Public Key" cryptosystem.

A public key cryptosystem differs from a private key cryptosystem in a few ways. First, a public key system uses two keys: a Public Key that anyone can use (hence the name) and a Private Key that only the originator of a message uses 🔑 The originator uses the private key to encrypt the message (as in DES). The receiver, who has gotten the originator's public key, can then decrypt the message 📩

With this scheme, the public key is used to authenticate the originator's use of their private key, so the originator's identity is more rigorously proven 🥇 The most widely known implementation of a public key cryptosystem is the RSA system [26], and the Internet standard for privacy enhanced mail uses the RSA system too 🌟

3.9.4 Information Integrity 🧩

Information integrity refers to the state of information being complete, correct, and unchanged since the last time it was verified to be in an "integral" state ✅ How much this matters depends on the site. For example, military and government installations are more concerned with preventing the "disclosure" of classified information, whether it's right or wrong. A bank, on the other hand, cares far more about whether the account info it keeps for customers is complete and accurate 🏦

Lots of computer system mechanisms, plus procedural controls, affect the integrity of system information. Traditional access control mechanisms control who can access system information, but on their own they aren't always enough to give the level of integrity required. A few other mechanisms are briefly discussed below.

It should be noted that there are other aspects of keeping system integrity besides these mechanisms, like two-person controls and integrity validation procedures. Those are beyond the scope of this document 🙏

3.9.4.1 Checksums

Easily the simplest mechanism, a simple checksum routine can compute a value for a system file and compare it with the last known value. If the two match, the file is probably unchanged. If not, the file has been changed by some unknown means 🧐

Though it's the easiest to implement, the checksum scheme has a serious flaw: it isn't very sophisticated, and a determined attacker could easily add enough characters to the file to eventually get the correct value 😤

A specific type of checksum, called a CRC checksum, is considerably more robust than a simple checksum. It's only slightly more difficult to implement and does a better job of catching errors. It too, however, can be compromised by an attacker 🥲

Checksums can be used to detect changes to information, but they don't actively guard against changes being made. For that, other mechanisms like access controls and encryption should be used 🛡️

3.9.4.2 Cryptographic Checksums

Cryptographic checksums (also called cryptosealing) involve breaking a file into smaller chunks, calculating a (CRC) checksum for each chunk, and adding the CRCs together 🧮 Depending on the exact algorithm, this can result in a nearly unbreakable way to tell whether a file has been changed 🔥 The catch is that it's sometimes computationally intensive and may be prohibitive, except where the utmost integrity protection is desired.

Another related mechanism, called a one-way hash function (or a Manipulation Detection Code (MDC)), can also be used to uniquely identify a file. The idea is that no two inputs can produce the same output, so a modified file won't have the same hash value 🪞 One-way hash functions can be implemented efficiently on a wide variety of systems, which makes unbreakable integrity checks possible. (Snefru, a one-way hash function available via USENET as well as the Internet, is just one example of an efficient one-way hash function.) [10] 🌈

3.9.5 Limiting Network Access 🚧

The dominant network protocols on the Internet, IP (RFC 791) [11], TCP (RFC 793) [12], and UDP (RFC 768) [13], carry certain control information that can be used to restrict access to certain hosts or networks within an organization 👑

The IP packet header carries the network addresses of both the sender and the recipient, like a return address and a delivery address on an envelope 💌. Then TCP and UDP add the "port" 🚪, which identifies the endpoint (usually a network server) of a communications path. Sometimes you may want to deny access to a specific TCP or UDP port, or even to certain hosts and networks altogether 🛑.

3.9.5.1. Gateway Routing Tables

One of the simplest ways to block unwanted connections is to remove certain networks from a gateway's routing tables 🗺️. This makes it "impossible" for a host to send packets to those networks. (Most protocols need bidirectional packet flow even for one-way data, so breaking one side of the route is usually enough 🙌.)

This is commonly done in "firewall" systems, which stop advertising local routes to the outside world 🧱. The catch is that it often blocks too much 😩. To block access to one system on the network, you end up disabling access to every system on it.

3.9.5.2. Router Packet Filtering

Lots of commercially available gateway systems (more correctly called routers) can filter packets based on not just sources or destinations, but also source-destination combinations 🔍. You can use this to deny access to a specific host, network, or subnet from any other host, network, or subnet.

Some vendors (e.g., cisco Systems) go even further 💅 with a more complex scheme that gives finer control over source and destination addresses. Using address masks, you can deny access to all but one host on a particular network. The cisco Systems gear can also screen packets based on IP protocol type and TCP or UDP port numbers [14].

This can be dodged by "source routing" packets destined for the "secret" network 🫣. Gateways can filter out source routed packets, but that might also block other legit stuff, like diagnosing routing problems.

3.9.6. Authentication Systems

Authentication is the process of proving a claimed identity to the satisfaction of some permission-granting authority 🔐. Authentication systems are hardware, software, or procedural mechanisms that let a user get access to computing resources. At the simplest level, the sysadmin who adds new user accounts is part of the system's authentication mechanism 🧑‍💻. At the other end of the spectrum, fingerprint readers or retinal scanners are a very high-tech way to establish a potential user's identity 👁️. Without establishing and proving a user's identity before a session starts, your site's computers are vulnerable to any sort of attack 💀.

Typically, a user authenticates himself or herself to the system by entering a password in response to a prompt. Challenge/Response mechanisms improve on passwords by prompting the user for some piece of information shared by both the computer and the user (such as mother's maiden name, etc.) ✨.

3.9.6.1. Kerberos

Kerberos, named after the dog who in mythology is said to stand at the gates of Hades 🐕‍🦺🔥, is a collection of software used in a large network to establish a user's claimed identity. It was developed at the Massachusetts Institute of Technology (MIT) and uses a combination of encryption and distributed databases, so a user at a campus facility can login and start a session from any computer located on campus 🏫. This has clear advantages in environments with lots of potential users who may connect from any one of many workstations. Some vendors are now incorporating Kerberos into their systems 💜.

It should be noted that while Kerberos makes several advances in authentication, some security weaknesses in the protocol still remain [15] 🥺.

3.9.6.2. Smart Cards

Several systems use "smart cards" (a small calculator-like device) to help authenticate users 💳. These systems depend on the user having an object in their possession. One such system involves a new password procedure that requires a user to enter a value obtained from a "smart card" when the computer asks for a password. Typically, the host machine gives the user some piece of information that gets entered into the keyboard of the smart card. The smart card then displays a response, which must then be entered into the computer before the session is established. Another such system uses a smart card that displays a number that changes over time, synchronized with the authentication software on the computer ⏱️.

This is a better way of handling authentication than the traditional password approach 🙌. On the other hand, some say it's inconvenient to carry the smart card, and start-up costs are likely to be high as well 💸.

3.9.7. Books, Lists, and Informational Sources

There are many good sources of information on computer security 📚. The annotated bibliography at the end of this document can give you a good start. Information can also come from a variety of other sources, some of which are described in this section 🌸.

3.9.7.1. Security Mailing Lists

The UNIX Security mailing list exists to notify system administrators of security problems before they become common knowledge, and to provide security enhancement information 🔔. It is a restricted-access list, open only to people who can be verified as principal systems people at a site 🔒. Requests to join the list must be sent by either the site contact listed in the Defense Data Network's Network Information Center's (DDN NIC) WHOIS database, or from the "root" account on one of the major site machines. You must include the destination address you want on the list, an indication of whether you want to be on the mail reflector list or receive weekly digests, the electronic mail address and voice telephone number of the site contact if it isn't you, and the name, address, and telephone number of your organization. This information should be sent to SECURITY-REQUEST@CPD.COM 📨.

The RISKS digest is a component of the ACM Committee on Computers and Public Policy, moderated by Peter G. Neumann 🧠. It's a discussion forum on risks to the public in computers and related systems. Along with computer security and privacy issues, it has discussed things like the Stark incident, the shooting down of the Iranian airliner in the Persian Gulf (as it relates to computerized weapons systems), problems in air and railroad traffic control systems, software engineering, and so on ✈️. To join the mailing list, send a message to RISKS-REQUEST@CSL.SRI.COM. It's also available in the USENET newsgroup "comp.risks".

The VIRUS-L list is a forum for discussing computer virus experiences, protection software, and related topics 🦠. It's open to the public and implemented as a moderated digest. Most of the info is related to personal computers, though some may apply to larger systems. To subscribe, send the line:

SUB VIRUS-L your full name

to the address LISTSERV%LEHIIBM1.BITNET@MITVMA.MIT.EDU. This list is also available via the USENET newsgroup "comp.virus" 💻.

The Computer Underground Digest "is an open forum dedicated to sharing information among computerists and to the presentation and debate of diverse views." 💬 While it's not directly a security list, it does have discussions about privacy and other security-related topics. It can be read on USENET as alt.society.cu-digest, or to join the mailing list, send mail to Gordon Myer (TK0JUT2%NIU.bitnet@mitvma.mit.edu). Submissions may be mailed to: cud@chinacat.unicom.com 🦋.

3.9.7.2. Networking Mailing Lists

The TCP-IP mailing list is a discussion forum for developers and maintainers of implementations of the TCP/IP protocol suite 🛠️. It also discusses network-related security problems when they involve programs providing network services, such as "Sendmail". To join the TCP-IP list, send a message to TCP-IP-REQUEST@NISC.SRI.COM. It's also available in the USENET newsgroup "comp.protocols.tcp-ip".

SUN-NETS is a discussion list for networking on Sun systems 🌞. Much of the chat is about NFS, NIS (formally Yellow Pages), and name servers. To subscribe, send a message to SUN-NETS-REQUEST@UMIACS.UMD.EDU.

The USENET groups misc.security and alt.security also discuss security issues 🔐. misc.security is a moderated group that also includes discussions of physical security and locks 🔑. alt.security is unmoderated.

3.9.7.3. Response Teams

Several organizations have formed special groups of people to deal with computer security problems 🦸. These teams collect information about possible security holes and disseminate it to the proper people, track intruders, and assist in recovery from security violations. The teams typically have both electronic mail distribution lists and a special telephone number to call for information or to report a problem 📞. Many of these teams are members of the CERT System, which is coordinated by the National Institute of Standards and Technology (NIST) and exists to facilitate information exchange between the various teams 🤝.

3.9.7.3.1. DARPA Computer Emergency Response Team

The Computer Emergency Response Team/Coordination Center (CERT/CC) was established in December 1988 by the Defense Advanced Research Projects Agency (DARPA) to address computer security concerns of research users of the Internet 🚨. It is operated by the Software Engineering Institute (SEI) at Carnegie-Mellon University (CMU). The CERT can immediately confer with experts to diagnose and solve security problems, and also establish and maintain communications with the affected computer users and government authorities as appropriate 👑.

The CERT/CC serves as a clearing house for the identification and repair of security vulnerabilities, informal assessments of existing systems, improvement of emergency response capability, and both vendor and user security awareness 🌈. In addition, the team works with vendors of various systems to coordinate the fixes for security problems 🫶.

The CERT/CC sends out security advisories to the CERT-ADVISORY mailing list whenever appropriate 📢 They also run a 24-hour hotline you can call to report security problems (e.g., someone breaking into your system) 🚨, and to get current (and accurate) info about rumored security problems 👀

To join the CERT-ADVISORY mailing list, send a message to CERT@CERT.SEI.CMU.EDU and ask to be added 💌 Stuff sent to this list also shows up in the USENET newsgroup comp.security.announce 🫶 Past advisories are available for anonymous FTP from the host CERT.SEI.CMU.EDU 🦋 The 24-hour hotline number is (412) 268-7090 📞

The CERT/CC also keeps a CERT-TOOLS list 🧰 It exists to encourage the exchange of info on tools and techniques that make Internet systems more secure 🔐 Quick heads up: the CERT/CC does not review or endorse the tools described on the list 💅 To subscribe, send a message to CERT-TOOLS-REQUEST@CERT.SEI.CMU.EDU and ask to be added to the mailing list ✨

The CERT/CC also maintains other generally useful security info for anonymous FTP from CERT.SEI.CMU.EDU 🌸 Grab the README file for a list of what's available 📂

For more information, contact:

   CERT
   Software Engineering Institute
   Carnegie Mellon University
   Pittsburgh, PA  15213-3890

   (412) 268-7090
   cert@cert.sei.cmu.edu.

3.9.7.3.2 DDN Security Coordination Center 🛡️

For DDN users, the Security Coordination Center (SCC) does a job similar to CERT 🎀 The SCC is the DDN's clearinghouse for host/user security problems and fixes 🧹 It works with the DDN Network Security Officer 🤝 The SCC also distributes the DDN Security Bulletin, which shares info on network and host security exposures, fixes, and concerns with security and management people at DDN facilities 📰 It's available online, via kermit or anonymous FTP, from the host NIC.DDN.MIL, in SCC:DDN-SECURITY-yy-nn.TXT (where "yy" is the year and "nn" is the bulletin number) 🗂️ The SCC gives immediate help with DDN-related host security problems 🚑 Call (800) 235-3155 (6:00 a.m. to 5:00 p.m. Pacific Time) or email SCC@NIC.DDN.MIL 💜 For 24 hour coverage, call the MILNET Trouble Desk at (800) 451-7413 or AUTOVON 231-1713 🌙

3.9.7.3.3 NIST Computer Security Resource and Response Center 🏛️

The National Institute of Standards and Technology (NIST) is in charge of computer science and technology activities within the U.S. Federal Government 🇺🇸 NIST has played a strong role in organizing the CERT System and is now serving as the CERT System Secretariat 👑 NIST also runs a Computer Security Resource and Response Center (CSRC) to provide help and info about computer security events and incidents ✨ It also raises awareness about computer security vulnerabilities 👀

The CSRC team operates a 24-hour hotline at (301) 975-5200 ☎️ People with Internet access can get on-line publications and computer security info via anonymous FTP from the host CSRC.NCSL.NIST.GOV (129.6.48.87) 🌐 NIST also runs a personal computer bulletin board with info about computer viruses and other computer security stuff 🦠 To access it, set your modem to 300/1200/2400 BPS, 1 stop bit, no parity, and 8-bit characters, then call (301) 948-5717 📟 Everyone gets full access to the board right after registering 🎉

NIST has produced several special publications on computer security and computer viruses in particular 📚 Some of these are downloadable 💾 For further info, contact NIST at the following address:

   Computer Security Resource and Response Center
   A-216 Technology
   Gaithersburg, MD 20899
   Telephone: (301) 975-3359
   Electronic Mail: CSRC@nist.gov

3.9.7.3.4 DOE Computer Incident Advisory Capability (CIAC) 🔥

CIAC is the Department of Energy's (DOE's) Computer Incident Advisory Capability 💖 It's a four-person team of computer scientists from Lawrence Livermore National Laboratory (LLNL) 🧑‍🔬 Their main job is helping DOE sites that are dealing with computer security incidents (e.g., intruder attacks, virus infections, worm attacks, etc.) 🪱 This help is available to DOE sites 24 hours a day 🕰️

CIAC was formed to give a centralized response capability (including technical assistance) 🧠 It keeps sites informed about current events, deals proactively with computer security issues, and maintains liaisons with other response teams and agencies 🤝 CIAC's charter is to help sites through direct technical assistance, providing info, or referring inquiries to other technical experts 🫶 It also serves as a clearinghouse for info about threats/known incidents/vulnerabilities 🗃️ On top of that, CIAC develops guidelines for incident handling and software for responding to events/incidents 🛠️ It analyzes events and trends, runs training and awareness activities, and alerts and advises sites about vulnerabilities and potential attacks 📣

CIAC's business hours phone number is (415) 422-8193 or FTS 532-8193 📞 CIAC's e-mail address is CIAC@TIGER.LLNL.GOV 💌

3.9.7.3.5 NASA Ames Computer Network Security Response Team 🚀

The Computer Network Security Response Team (CNSRT) is NASA Ames Research Center's local version of the DARPA CERT 🌌 It was formed in August of 1989 🗓️ The team's constituency is mainly Ames users, but it also helps other NASA Centers and federal agencies 🫶 CNSRT keeps liaisons with the DOE's CIAC team and the DARPA CERT 🔗 It's also a charter member of the CERT System 🏅 The team can be reached by 24 hour pager at (415) 694-0571, or by electronic mail to CNSRT@AMES.ARC.NASA.GOV 💜

3.9.7.4 DDN Management Bulletins 📬

The DDN Management Bulletin is distributed electronically by the DDN NIC under contract to the Defense Communications Agency (DCA) 💅 It's how official policy, procedures, and other info get shared with management people at DDN facilities 📋

The DDN Security Bulletin is distributed electronically by the DDN SCC, also under contract to DCA 🔐 It's a way of sharing info on network and host security exposures, fixes, and concerns with security and management people at DDN facilities 🛡️

Anyone can join the mailing lists for these two bulletins 🙌 Just send a message to NIC@NIC.DDN.MIL and ask to be placed on the mailing lists 💌 These messages also get posted to the USENET newsgroup ddn.mgt-bulletin 📰 For additional info, see section 8.7 🌷

3.9.7.5 System Administration List 🖥️

The SYSADM-LIST is a list that's all about UNIX system administration 🐧 To get added, mail your request to SYSADM-LIST-REQUEST@SYSADMIN.COM 📨

3.9.7.6 Vendor Specific System Lists 🍓

The SUN-SPOTS and SUN-MANAGERS lists are discussion groups for users and admins of systems from Sun Microsystems 🌞 SUN-SPOTS is a pretty general list that covers everything from hardware configs to simple UNIX questions 🙈 To subscribe, send a message to SUN-SPOTS-REQUEST@RICE.EDU 💖 This list is also in the USENET newsgroup comp.sys.sun 🌈 SUN-MANAGERS is a discussion list for Sun system admins and covers all aspects of Sun system administration 🧑‍💻 To subscribe, send a message to SUN-MANAGERS-REQUEST@EECS.NWU.EDU 🫶

The APOLLO list is about the HP/Apollo system and its software 🏺 To subscribe, send a message to APOLLO-REQUEST@UMIX.CC.UMICH.EDU 💌 APOLLO-L is a similar list you can subscribe to by sending this:

   SUB APOLLO-L your full name

to LISTSERV%UMRVMB.BITNET@VM1.NODAK.EDU 📬

HPMINI-L is about the Hewlett-Packard 9000 series and the HP/UX operating system 💻 To subscribe, send this:

   SUB HPMINI-L your full name

to LISTSERV%UAFSYSB.BITNET@VM1.NODAK.EDU 🧚

INFO-IBMPC is about IBM PCs and compatibles, plus MS-DOS 💾 To subscribe, send a note to INFO-IBMPC-REQUEST@WSMR-SIMTEL20.ARMY.MIL 🌸

There are tons of other mailing lists for nearly every popular computer or workstation in use today 🤯 For a complete list, grab the file "netinfo/interest-groups" via anonymous FTP from the host FTP.NISC.SRI.COM 📂

3.9.7.7 Professional Societies and Journals 🎓

The IEEE Technical Committee on Security & Privacy publishes a quarterly magazine called "CIPHER" 🦋

   IEEE Computer Society,
   1730 Massachusetts Ave. N.W.
   Washington, DC  2036-1903

The ACM SigSAC (Special Interest Group on Security, Audit, and Controls) publishes a quarterly magazine called "SIGSAC Review" 🌟

   Association for Computing Machinery
   11 West 42nd St.
   New York, N.Y.  10036

The Information Systems Security Association publishes a quarterly magazine called "ISSA Access" 💜

   Information Systems Security Association
   P.O. Box 9457
   Newport Beach, CA  92658

"Computers and Security" is an "international journal for the professional involved with computer security, audit and control, and data integrity." 🧐

   $266/year, 8 issues (1990)

   Elsevier Advanced Technology
   Journal Information Center
   655 Avenue of the Americas
   New York, NY 10010

The "Data Security Letter" is published "to help data security professionals by providing inside information and knowledgable analysis of developments in computer and communications security." 💅

   $690/year, 9 issues (1990)

   Data Security Letter
   P.O. Box 1593
   Palo Alto, CA 94302

3.9.8 Problem Reporting Tools 🚩

3.9.8.1 Auditing 🔍

Auditing is an important tool for boosting the security of your installation 🔐 It doesn't just tell you who has accessed your system (and may have done something to it) 👀 It also gives you a sense of how your system is being used (or abused) by authorized users and attackers alike 🫣 And if your system ever gets penetrated, the audit trail that computer systems traditionally keep can become an invaluable piece of evidence 🕵️‍♀️✨

3.9.8.1.1 Verify Security 🕵️‍♀️

okay so an audit trail is basically the receipts of your system 🧾✨ it shows how the system gets used day to day. depending on how your site's audit log is set up, your log files should show a range of access attempts that tell you what normal usage looks like. 💅 if you spot something that doesn't match that normal vibe, it could mean someone's sneaking in from outside using an old or stale user account 👀 ngl, noticing a weird pattern in logins could be your very first clue that something unusual is going on 🚨

3.9.8.1.2 Verify Software Configurations 🐴

bestie, the Trojan Horse is giving sneaky villain 😤 attackers love using one to get into a system. it can be a program that does something useful, or one that's just kinda interesting 🎀 but it ALWAYS does something unexpected, like stealing passwords or copying your files without you knowing [25] 💀 picture a fake login program that asks for your username and password like normal, but quietly writes them to a secret file the attacker can come back and read whenever 🙈 or picture a fake editor that makes copies of everything in your directory space even though you set your file permissions 🫠 no thank you!!

this is why you need configuration management for the software running on a system 🧚 and not just while it's being developed, but while it's actually in operation 💜 there are different ways to do this. you could check every command each time it runs against some criterion (like a cryptoseal, described above), or you could just check the date and time stamp of the executable 🌸 another option is to check each command in batch mode at midnight 🌙

3.9.8.2 Tools 🧰

okay, COPS is a security tool for system administrators that checks for a bunch of common security problems on UNIX systems [27] 🦋 it's a collection of shell scripts and C programs that run on almost any UNIX variant, so it's super accessible ✨ among other things, it checks the following and sends the results to the system administrator:

Checks /dev/kmem and other devices for world read/writability.
Checks special or important files and directories for "bad" modes (world writable, etc.).
Checks for easily-guessed passwords.
Checks for duplicate user ids, invalid fields in the password file, etc..
Checks for duplicate group ids, invalid fields in the group file, etc..
Checks all users' home directories and their .cshrc, .login, .profile, and .rhosts files for security problems.
Checks all commands in the /etc/rc files and cron files for world writability.
Checks for bad root paths, NFS file systems exported to the world, etc..
Includes an expert system that checks to see if a given user (usually root) can be compromised, given that certain rules are true.
Checks for changes in the setuid status of programs on the system.

the COPS package is available from the comp.sources.unix archive on ftp.uu.net, and also from the UNIX-SW repository on the MILNET host wsmr-simtel20.army.mil 🎀

3.9.9 Communication Among Administrators 🫶

3.9.9.1 Secure Operating Systems 🔐

okay so this list of products and vendors is adapted from the National Computer Security Center's (NCSC) Evaluated Products List 👑 it's the companies that either got an evaluation from the NCSC or are in the middle of one 💅 the list isn't complete, BUT it's representative of the operating systems and add-on components you can actually buy on the commercial market ✨

if you want the full scoop on what's in the NCSC EPL right now, contact the NCSC at:

   National Computer Security Center
   9800 Savage Road
   Fort George G. Meade, MD  20755-6000
   (301) 859-4458

                                      Version    Evaluation
Evaluated Product               Vendor            Evaluated  Class
-----------------------------------------------------------------------
Secure Communications           Honeywell Information    2.1         A1
Processor (SCOMP)               Systems, Inc.

Multics                         Honeywell Information    MR11.0      B2
                                Systems, Inc.

System V/MLS 1.1.2 on UNIX      AT&T                     1.1.2       B1
System V 3.1.1 on AT&T 3B2/500and 3B2/600

OS 1100                         Unisys Corp.             Security    B1
                                                         Release 1

MPE V/E                         Hewlett-Packard Computer G.03.04     C2
                                Systems Division

AOS/VS on MV/ECLIPSE series     Data General Corp.        7.60       C2

VM/SP or VM/SP HPO with CMS,    IBM Corp.                    5       C2
RACF, DIRMAINT, VMTAPE-MS,
ISPF

MVS/XA with RACF                IBM Corp.                 2.2,2.3    C2

AX/VMS                          Digital Equipment Corp.      4.3     C2

NOS                             Control Data Corp.         NOS
                                                           Security  C2
                                                       Eval Product

TOP SECRET                      CGA Software Products       3.0/163  C2
                                Group, Inc.

Access Control Facility 2       SKK, Inc.                    3.1.3   C2

UTX/32S                         Gould, Inc. Computer          1.0    C2
                                Systems Division

A Series MCP/AS with            Unisys Corp.                  3.7    C2
InfoGuard Security
Enhancements

Primos                          Prime Computer, Inc.    21.0.1DODC2A C2
Resource Access Control         IBM Corp.                     1.5    C1
Facility (RACF)

                                                  Version      Candidate
Candidate Product            Vendor               Evaluated    Class

-----------------------------------------------------------------------
Boeing MLS LAN                  Boeing Aerospace                  A1 M1

Trusted XENIX                   Trusted Information
                                Systems, Inc.                     B2

VSLAN                           VERDIX Corp.                      B2

System V/MLS                    AT&T                              B1

VM/SP with RACF                 IBM Corp.              5/1.8.2    C2
Wang SVS/OS with CAP            Wang Laboratories, Inc.  1.0      C2

3.9.9.2. Obtaining Fixes for Known Problems ✨

okay bestie, it goes without saying that computer systems have bugs 💀. even operating systems, the ones we depend on to protect our data, have bugs 😭. and since bugs exist, things can get broken, both on purpose and by accident. so it's super important that whenever a bug is discovered, a should fix gets identified and implemented asap 🫶. that should minimize any exposure the bug caused in the first place 💅.

the next question is: where do I get the fixes from? 🤔 most systems have some support from the manufacturer or supplier, and fixes from that source tend to get implemented quickly once they arrive 🔥. fixes for some problems are often posted on the network, and then it's up to the system administrators to add them as they can. the vibe is that you want faith that the fix will close the hole and won't introduce any new ones 🙈. so ngl, we tend to trust the manufacturer's fixes more than the ones posted on the net 💜.

3.9.9.3. Sun Customer Warning System 🌸

Sun Microsystems has established a Customer Warning System (CWS) for handling security incidents. this is a formal process which includes:

Having a well advertised point of contact in Sun for reporting security problems.
Pro-actively alerting customers of worms, viruses, or other security holes that could affect their systems.
Distributing the patch (or work-around) as quickly as possible.

they've created an electronic mail address, SECURITY-ALERT@SUN.COM, so customers can report security problems 📧. a voice-mail backup is available at (415) 688-9081 📞. each customer site can designate a "Security Contact," and this person will be contacted by Sun in case of any new security problems 🧚. for more information, contact your Sun representative ✨.

3.9.9.4. Trusted Archive Servers 🦋

several sites on the Internet maintain large repositories of public-domain and freely distributable software, and make this material available for anonymous FTP 📂. this section describes some of the larger repositories. note that none of these servers implements secure checksums or anything else guaranteeing the integrity of their data 👀. so the notion of "trust" should be taken as a somewhat limited definition 🙃.

3.9.9.4.1. Sun Fixes on UUNET

Sun Microsystems has contracted with UUNET Communications Services, Inc., to make fixes for bugs in Sun software available via anonymous FTP 🎀. you can access these fixes by using the "ftp" command to connect to the host FTP.UU.NET. then change into the directory "sun-dist/security", and obtain a directory listing. the file "README" contains a brief description of what each file in this directory contains, and what is required to install the fix 📖.

3.9.9.4.2. Berkeley Fixes

the University of California at Berkeley also makes fixes available via anonymous FTP 🐻. these fixes pertain primarily to the current release of BSD UNIX (currently, release 4.3). but even if you aren't running their software, these fixes are still important, since many vendors (Sun, DEC, Sequent, etc.) base their software on the Berkeley releases 💖.

the Berkeley fixes are available for anonymous FTP from the host UCBARPA.BERKELEY.EDU in the directory 4.3/ucb-fixes. the file INDEX in this directory describes what each file contains. they are also available from UUNET (see section 3.9.9.4.3).

Berkeley also distributes new versions of "sendmail" and "named" from this machine. new versions of these commands are stored in the "4.3" directory, usually in the files sendmail.tar.Z and bind.tar.Z, respectively 🧁.

3.9.9.4.3. Simtel-20 and UUNET 🌈

the two largest general-purpose software repositories on the Internet are the hosts WSMR-SIMTEL20.ARMY.MIL and FTP.UU.NET 👑.

WSMR-SIMTEL20.ARMY.MIL is a TOPS-20 machine operated by the U.S. Army at White Sands Missile Range (WSMR), New Mexico. the directory pd2:<unix-c> contains a large amount of UNIX software, primarily taken from the "comp.sources" newsgroups. the directories pd1:<msdos> and pd2:<msdos2> contain software for IBM PC systems, and pd3:<macintosh> contains software for the Apple Macintosh 🍎.

FTP.UU.NET is operated by UUNET Communications Services, Inc. in Falls Church, Virginia. this company sells Internet and USENET access to sites all over the country (and internationally). the software posted to the following USENET source newsgroups is stored here, in directories of the same name:

comp.sources.games
comp.sources.misc
comp.sources.sun
comp.sources.unix
comp.sources.x

numerous other distributions, such as all the freely distributable Berkeley UNIX source code, Internet Request for Comments (RFCs), and so on are also stored on this system 📚.

3.9.9.4.4. Vendors 🛍️

many vendors make fixes for bugs in their software available electronically, either via mailing lists or via anonymous FTP. you should contact your vendor to find out if they offer this service, and if so, how to access it. some vendors that offer these services include Sun Microsystems (see above), Digital Equipment Corporation (DEC), the University of California at Berkeley (see above), and Apple Computer [5, CURRY] 🍓.

4. Types of Security Procedures ✨

4.1. System Security Audits 🔍

most businesses undergo some sort of annual financial auditing as a regular part of their business life 💼. security audits are an important part of running any computing environment 🛡️. part of the security audit should be a review of any policies that concern system security, as well as the mechanisms that are put in place to enforce them 💅.

4.1.1. Organize Scheduled Drills 🎯

although it isn't something that would be done each day or week, scheduled drills may be conducted to determine if the procedures defined are adequate for the threat to be countered. if your major threat is natural disaster, then a drill would be conducted to verify your backup and recovery mechanisms 🌪️. on the other hand, if your greatest threat is from external intruders attempting to penetrate your system, a drill might be conducted to actually try a penetration to observe the effect of the policies 🕵️‍♀️.

drills are a valuable way to test that your policies and procedures are effective 💜. on the other hand, drills can be time-consuming and disruptive to normal operations. it is important to weigh the benefits of the drills against the possible time loss which may be associated with them ⏰.

4.1.2. Test Procedures 🧪

if the choice is made to not to use scheduled drills to examine your entire security procedure at one time, it is important to test individual procedures frequently. examine your backup procedure to make sure you can recover data from the tapes. check log files to be sure that information which is supposed to be logged to them is being logged to them, etc.. 📝

when a security audit is mandated, great care should be used in devising tests of the security policy. it is important to clearly identify what is being tested, how the test will be conducted, and results expected from the test. this should all be documented and included in or as an adjunct to the security policy document itself 🎀.

it is important to test all aspects of the security policy, both procedural and automated, with a particular emphasis on the automated mechanisms used to enforce the policy. tests should be defined to ensure a comprehensive examination of policy features. that is, if a test is defined to examine the user logon process, it should be explicitly stated that both valid and invalid user names and passwords will be used to demonstrate proper operation of the logon program 🔐.

keep in mind that there is a limit to the reasonableness of tests 🌙. the purpose of testing is to ensure confidence that the security policy is being correctly enforced, and not to "prove" the absoluteness of the system or policy. the goal should be to obtain some assurance that the reasonable and credible controls imposed by your security policy are adequate ✨.

4.2. Account Management Procedures 🪪

procedures to manage accounts are important in preventing unauthorized access to your system 🚪. it is necessary to decide several things: who may have an account on the system? how long may someone have an account without renewing his or her request? how do old accounts get removed from the system? the answers to all these questions should be explicitly set out in the policy 💖.

in addition to deciding who may use a system, it may be important to determine what each user may use the system for (is personal use allowed, for example). if you are connected to an outside network, your site or the network management may have rules about what the network may be used for. therefore, it is important for any security policy to define an adequate account management procedure for both administrators and users 🫶. typically, the system administrator would be responsible for creating and deleting user accounts and generally maintaining overall control of system use 👑.

to some degree, account management is also the responsibility of each system user in the sense that the user should observe any system messages and events that may be indicative of a policy violation 👀. for example, a message at logon that indicates the date and time of the last logon should be reported by the user if it indicates an unreasonable time of last logon 🚨.

4.3 Password Management Procedures ✨

Okay bestie, password management is a whole vibe 🔐. A policy on this may be important if your site wants to enforce secure passwords 💅. The procedures can range from asking or forcing users to change their passwords every so often, all the way to actively trying to crack users' passwords and then telling them how easy it was 😭. Another part of the policy covers who gets to distribute passwords. Can users give their passwords to other users? 🙈

Section 2.3 walks through some of the policy questions you need to settle for proper password management 📝. No matter what your policies say, the password management procedures need to be set up carefully so they don't disclose passwords 🫶. The choice of initial passwords is critical 🔥. Some users may never log in to activate their account, so the initial password should not be easily guessed 💀. Default passwords should never be assigned to accounts: always create new passwords for each user 🌸. If there are any printed lists of passwords, keep them off-line in secure locations. Even better, don't list passwords at all 🧚.

4.3.1 Password Selection

The most vulnerable part of any computer system is honestly the account password 🥺. A system can be locked down against network and dial-up attacks, Trojan horse programs, and so on, and an intruder can still take over everything if they get in with a poorly chosen password 💔. It's important to define a good set of rules for password selection and share them with all users 📜. If possible, the software that sets user passwords should be modified to enforce as many of the rules as it can ✨.

A sample set of guidelines for password selection is below:

DON'T use your login name in any form (as-is, reversed, capitalized, doubled, etc.).
DON'T use your first, middle, or last name in any form.
DON'T use your spouse's or child's name.
DON'T use other information easily obtained about you. This includes license plate numbers, telephone numbers, social security numbers, the make of your automobile, the name of the street you live on, etc..
DON'T use a password of all digits, or all the same letter.
DON'T use a word contained in English or foreign language dictionaries, spelling lists, or other lists of words.
DON'T use a password shorter than six characters.
DO use a password with mixed-case alphabetics.
DO use a password with non-alphabetic characters (digits or punctuation).
DO use a password that is easy to remember, so you don't have to write it down.
DO use a password that you can type quickly, without having to look at the keyboard.

Here are some ways to pick a password that follows these guidelines 🎀:

Choose a line or two from a song or poem, and use the first letter of each word.
Alternate between one consonant and one or two vowels, up to seven or eight characters. This gives you nonsense words that are usually pronounceable, so they're easy to remember 🦋.
Choose two short words and stick them together with a punctuation character between them.

Users should also be told to change their password periodically, usually every three to six months 🗓️. This makes sure that an intruder who has guessed a password will eventually lose access, and it also invalidates any list of passwords they may have picked up 👑. Many systems let the system administrator force users to change their passwords after an expiration period, and this software should be enabled if your system supports it [5, CURRY] 💜.

Some systems provide software that forces users to change their passwords on a regular basis. Many of these also include password generators that offer the user a set of passwords to pick from, and the user isn't allowed to make up their own password 🙅. There are arguments both for and against systems like these ⚖️. On the one hand, generated passwords stop users from picking insecure ones. On the other hand, unless the generator is good at making up easy-to-remember passwords, users will start writing them down just to remember them 📝💀.

4.3.2 Procedures for Changing Passwords

How password changes are handled is a big deal for keeping passwords secure 🔒. Ideally, users should be able to change their own passwords on-line. (Heads up: password changing programs are a favorite target of intruders. See section 4.4 on configuration management for more info 👀.)

There are exception cases that need to be handled carefully, though 😬. Users may forget their passwords and get locked out. The standard procedure is to assign the user a new password. Care should be taken to make sure the real person is the one requesting the change and getting the new password. One common trick intruders use is to call or message a system administrator and request a new password. Some external form of verification should be used before a password is assigned. At some sites, users have to show up in person with ID 🪪.

There may also be times when many passwords need to be changed at once 🌪️. If a system is compromised, an intruder may be able to steal a password file and take it off the system. In that situation, one course of action is to change all passwords on the system. Your site should have procedures for how to do this quickly and efficiently ⚡. Which course you pick may depend on how urgent the problem is. For a known attack that has caused damage, you may choose to forcibly disable all accounts and assign users new passwords before they come back onto the system 🚫. Some places send users a message saying they should change their passwords, maybe within a certain time period. If the password isn't changed before that period expires, the account is locked 🔐.

Users should know the standard procedure for passwords when a security event has happened 📣. One well-known spoof reported by the Computer Emergency Response Team (CERT) involved messages sent to users, supposedly from local system administrators, asking them to immediately change their password to a new value provided in the message [24]. Those messages weren't from the administrators at all. They came from intruders trying to steal accounts 😱. Users should be warned to immediately report any suspicious requests like this to site administrators 🚨.

4.4 Configuration Management Procedures 🛠️

Configuration management is generally applied to the software development process. But it's totally applicable in an operational sense too 💖. Since many of the system-level programs are intended to enforce the security policy, it's important that they be "known" as correct. In other words, you shouldn't let system-level programs (like the operating system, etc.) get changed arbitrarily 🙅‍♀️. At the very least, the procedures should state who is authorized to make changes to systems, under what circumstances, and how the changes should be documented 📚.

In some environments, configuration management is also desirable for the physical configuration of equipment 🖥️. Keeping a valid and authorized hardware configuration should be given due consideration in your security policy ✅.

4.4.1 Non-Standard Configurations

Sometimes it can be useful to have a slightly non-standard configuration to thwart the "standard" attacks some intruders use 🕵️‍♀️. The non-standard parts of the configuration might include different password encryption algorithms, different configuration file locations, and rewritten or functionally limited system commands 🧩.

Non-standard configurations also come with drawbacks, though 😤. By changing the "standard" system, these modifications make software maintenance harder. They require extra documentation, software changes after operating system upgrades, and usually someone with special knowledge of the changes 🥴.

Because of those drawbacks, non-standard configurations are often only used in environments with a "firewall" machine (see section 3.9.1) 🧱. The firewall machine is modified in non-standard ways since it's susceptible to attack, while the internal systems behind the firewall are left in their standard configurations 🫡.

5. Incident Handling 🚨

5.1. Overview ✨

okay bestie, this section is gonna give you some guidance for when a computer security event is actively happening on a machine, network, site, or multi-site environment 🚨 The big philosophy when there's a breach, whether it's an external intruder attack or a disgruntled employee, is to plan for adverse events in advance 💖 There is literally no substitute for creating contingency plans for the types of events described above, no cap.

Traditional computer security is super important in the overall site security plan 🛡️ but it usually goes all in on protecting systems from attack, and maybe watching systems to detect attacks. Like, how to actually handle the attack when it happens? Barely anyone talks about that 😭 So when an attack is in progress, people make decisions in a total panic, and those choices can wreck things like tracking down the source of the incident, collecting evidence for prosecution, preparing to recover the system, and protecting the valuable data on the system. Not it 💀

5.1.1. Have a Plan to Follow in Case of an Incident

Part of handling an incident is being ready to respond before it happens 🎀 That includes setting up a suitable level of protections, so if things get severe, the damage is limited. Protection includes preparing incident handling guidelines or a contingency response plan for your organization or site. Written plans wipe out a ton of the ambiguity that shows up during an incident and lead to a more appropriate and thorough set of responses ✨ Second, part of protection is preparing a method of notification, so you'll know who to call and the relevant phone numbers 📞 It's important, for example, to conduct "dry runs," where your computer security personnel, system administrators, and managers simulate handling an incident. Main character rehearsal energy 🎭

Learning to respond efficiently to an incident matters for lots of reasons 🌸 The most important benefit goes straight to human beings: preventing loss of human life 🫶 Some computing systems are life critical systems, meaning human life depends on them (e.g., by controlling some aspect of life-support in a hospital or assisting air traffic controllers). Serious stakes, bestie 😭

An important but often overlooked benefit is an economic one 💅 Having both technical and managerial personnel respond to an incident takes considerable resources, resources that could be used more profitably if an incident didn't need their services. If these people are trained to handle an incident efficiently, less of their time gets eaten up by it 🧚

A third benefit is protecting classified, sensitive, or proprietary information 🔐 One of the major dangers of a computer security incident is that information may be irrecoverable, and efficient incident handling minimizes that danger. When classified information is involved, other government regulations may apply and must be integrated into any plan for incident handling.

A fourth benefit is related to public relations 📰 News about computer security incidents tends to be damaging to an organization's stature among current or potential clients. Efficient incident handling minimizes the potential for negative exposure. Reputation protected, iconic behavior 👑

A final benefit of efficient incident handling is related to legal issues ⚖️ It's possible that in the near future, organizations may be sued because one of their nodes was used to launch a network attack. Similarly, people who develop patches or workarounds may be sued if those patches or workarounds are ineffective and result in damage to systems, or if the patches or workarounds themselves damage systems. Knowing about operating system vulnerabilities and patterns of attacks, then taking appropriate measures, is critical to circumventing possible legal problems 🌈

5.1.2. Order of Discussion in this Session Suggests an Order for a Plan

This chapter is arranged so a list can be generated from the Table of Contents, giving you a starting point for creating a policy for handling ongoing incidents 📝 The main points to include in a policy for handling incidents are:

Overview (what are the goals and objectives in handling the incident).
Evaluation (how serious is the incident).
Notification (who should be notified about the incident).
Response (what should the response to the incident be).
Legal/Investigative (what are the legal and prosecutorial implications of the incident).
Documentation Logs (what records should be kept from before, during, and after the incident).

Each of these points is important in an overall plan for handling incidents 🦋 The rest of this chapter breaks down the issues in each topic and gives some guidance on what to include in a site policy for handling incidents.

5.1.3. Possible Goals and Incentives for Efficient Incident Handling

As with any set of pre-planned procedures, you have to focus on a set of goals to hit when handling an incident 🎯 These goals get put in order of importance depending on the site, but one possible set of goals might be:

Assure integrity of (life) critical systems.
Maintain and restore data.
Maintain and restore service.
Figure out how it happened.
Avoid escalation and further incidents.
Avoid negative publicity.
Find out who did it.
Punish the attackers.

It's important to prioritize actions during an incident well in advance of when one happens 💜 Sometimes an incident is so complex that you can't do everything at once, so priorities are essential. Priorities will vary from institution to institution, but the following suggested priorities are a good starting point for defining an organization's response:

Priority one -- protect human life and people's safety; human life always has precedence over all other considerations. 🫶
Priority two -- protect classified and/or sensitive data (as regulated by your site or by government regulations). 🔒
Priority three -- protect other data, including proprietary, scientific, managerial and other data, because loss of data is costly in terms of resources. 💾
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. 🛠️
Priority five -- minimize disruption of computing resources; it is better in many cases to shut a system down or disconnect from a network than to risk damage to data or systems. 🔌

An important implication of these priorities is that once human life and national security considerations have been addressed, it's generally more important to save data than system software and hardware 🧠 It's undesirable to have any damage or loss during an incident, but systems can be replaced. The loss or compromise of data (especially classified data), however, is usually not an acceptable outcome under any circumstances. Data is the main character, periodt 💅

Part of handling an incident is being prepared to respond before it occurs 🌷 This includes establishing a suitable level of protections so that if the incident becomes severe, the damage is limited. Protection includes preparing incident handling guidelines or a contingency response plan for your organization or site. Written plans eliminate much of the ambiguity during an incident and lead to a more appropriate and thorough set of responses. Second, part of protection is preparing a method of notification so you know who to call and how to contact them. For example, every member of the Department of Energy's CIAC Team carries a card with every other team member's work and home phone numbers, as well as pager numbers 📇 Third, your organization or site should establish backup procedures for every machine and system. Having backups eliminates much of the threat of even a severe incident, since backups preclude serious data loss 💾✨ Fourth, you should set up secure systems. This involves eliminating vulnerabilities, establishing an effective password policy, and other procedures, all of which will be explained later in this document 🔐 Finally, conducting training activities is part of protection. It's important, for example, to conduct "dry runs," where your computer security personnel, system administrators, and managers simulate handling an incident. Yes, we're repeating it, because it's that important 🙈

5.1.4. Local Policies and Regulations Providing Guidance

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 they must follow.

The policies your site makes about how it responds to incidents (as discussed in sections 2.4 and 2.5) will shape your response 🌟 For example, it may make little sense to create mechanisms to monitor and trace intruders if your site doesn't plan to take action against them if 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 📱

Section 5.5 also notes that if any legal action is planned, there are specific guidelines that must be followed to make sure any information collected can be used as evidence. This is a big deal, so take notes, bestie 📚⚖️

5.2. Evaluation 💅

5.2.1. Is It Real? 🔍

Okay so this stage is all about figuring out the exact problem 🕵️‍♀️ Ngl, a LOT of the stuff that looks like a virus infection, a system intrusion, etc. is literally just anomalies, like hardware failures 💀 So first you gotta check whether there's actually an incident. Using any detection software that might be available is super helpful! For example, widely available software packages can really help someone who thinks there might be a virus in a Macintosh computer 🍎 Audit information is also extremely useful, especially for figuring out whether there's a network attack 🔥 It is extremely important to get a system snapshot the second you suspect something is wrong 📸 Lots of incidents set off a dynamic chain of events, and an initial system snapshot can do more good for identifying the problem and any source of attack than most other things you can do at this stage 🧠 Finally, start a log book 📖 Recording system events, telephone conversations, time stamps, etc. leads to a faster, more systematic identification of the problem, and it's the basis for the later stages of incident handling ✨

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

System crashes 💥
New user accounts (e.g., the account RUMPLESTILTSKIN has unexplainedly been created), or high activity on an account that has had virtually no activity for months 🫣
New files (usually with novel or strange file names, such as data.xx or k) 📁
Accounting discrepancies (e.g., in a UNIX system you might notice that the accounting file called /usr/admin/lastlog has shrunk, something that should make you very suspicious that there may be an intruder) 🚨
Changes in file lengths or dates (e.g., a user should be suspicious if he/she observes that the .EXE files in an MS DOS computer have unexplainedly grown by over 1800 bytes) 📏
Attempts to write to system (e.g., a system manager notices that a privileged user in a VMS system is attempting to alter RIGHTSLIST.DAT) ✍️
Data modification or deletion (e.g., files start to disappear) 😱
Denial of service (e.g., a system manager and all other users become locked out of a UNIX system, which has been changed to single user mode) 🙅‍♀️
Unexplained, poor system performance (e.g., system response time becomes unusually slow) 🐢
Anomalies (e.g., "GOTCHA" is displayed on a display terminal or there are frequent unexplained "beeps") 👻
Suspicious probes (e.g., there are numerous unsuccessful login attempts from another node) 🔎
Suspicious browsing (e.g., someone becomes a root user on a UNIX system and accesses file after file in one user's account, then another's) 👀

None of these indications is absolute "proof" that an incident is occurring, and not all of them are normally observed when an incident occurs 🙃 But if you observe any of these indications, it is important to suspect that an incident might be occurring and act accordingly 🫡 There is no formula for determining with 100 percent accuracy that an incident is occurring (possible exception: when a virus detection package indicates that your machine has the nVIR virus and you confirm this by examining contents of the nVIR resource in your Macintosh computer, you can be very certain that your machine is infected 💯). It is best at this point to collaborate with other technical and computer security personnel and make a decision as a group about whether an incident is occurring 🫶

5.2.2. Scope 🗺️

Along with identifying the incident, you also have to evaluate its scope and impact, and this is where it gets real 😤 It is important to correctly identify the boundaries of the incident so you can deal with it effectively 🎯 The impact of an incident also determines its priority when allocating resources to deal with the event, so without an indication of the scope and impact, it's hard to pick a correct response 💭

In order to identify the scope and impact, a set of criteria should be defined that fits the site and the type of connections available 📋 Some of the issues are:

Is this a multi-site incident? 🌐
Are many computers at your site effected by this incident? 💻
Is sensitive information involved? 🔐
What is the entry point of the incident (network, phone line, local terminal, etc.)? 🚪
Is the press involved? 📰
What is the potential damage of the incident? 💥
What is the estimated time to close out the incident? ⏰
What resources could be required to handle the incident? 🧰

5.3. Possible Types of Notification 💌

okay so once you've confirmed an incident is actually happening, the right people need to hear about it, bestie 🫶 Who gets told and how they get told is a BIG deal for keeping things under control, both technically and emotionally 😭✨

5.3.1. Explicit

First things first, any notification to people inside or outside the site has to be explicit 💅 That means whatever you send (an email, a phone call, or a fax) needs info about the incident that is clear, concise, and fully qualified. If you're pinging people who are gonna help you handle it, a "smoke screen" just splits the effort and creates chaos 💀 If you're dividing up the work, it helps to tell each group what the other groups are doing too. This not only cuts down on duplicate work, it also lets people know where to find the info they need to fix their part of the problem 🧩

5.3.2. Factual

Another big one is being factual 💯 Trying to hide parts of the incident by giving false or incomplete info can not only block a successful fix, it can actually make things worse 😬 This is especially true when the press is involved. If an incident is big enough to get press attention, any false info you gave out is probably not going to be backed up by other sources, and that will make the site look bad and may create enough bad blood with the press to damage the site's public relations 📉

5.3.3. Choice of Language

The words you pick when telling people about the incident can totally change how the info is received 🎀 If you use emotional or inflammatory terms, people expect more damage and worse outcomes, and nobody needs that drama 🙈 It's important to stay calm, both in writing and out loud 🌸

Talking to non-technical or off-site folks is its own thing too. You need to describe the incident accurately without causing undue alarm or confusing messages 💖 Yes, it's harder to explain it to a non-technical crowd, but it's often more important. Upper-level management, the press, or law enforcement liaisons might need a non-technical description, and getting this right can be the difference between handling the incident properly and escalating it to a higher level of damage 🚨

5.3.4. Notification of Individuals

Point of Contact (POC) people (Technical, Administrative, Response Teams, Investigative, Legal, Vendors, Service providers), and which POCs are visible to whom.
Wider community (users).
Other sites that might be affected.

Last but definitely not least, you have to figure out who should be notified during and after the incident 👑 There are several classes of people to think about: technical personnel, administration, appropriate response teams (like CERT or CIAC), law enforcement, vendors, and other service providers 🧚 This matters a LOT for the central point of contact, since that person is the one actually doing the notifying (see section 5.3.6 for further information). Keeping a list of people in each of these categories is a total time saver for the POC during an incident 📝 Finding the right person is so much harder when a bunch of urgent stuff is happening at once 😩

Besides the people handling part of the incident, other sites might be affected by it (or might just be at risk from it) 🌈 A wider community of users may also benefit from knowing about it. Often, a report on the incident once it's closed out is appropriate to publish for the wider user community 📰

5.3.5. Public Relations - Press Releases

One of the most important questions is when, who, and how much to release to the general public through the press 📣 There are a lot of things to weigh here. First and foremost, if the site has a public relations office, use that office as the liaison to the press 💅 The PR office is trained in the type and wording of released info, and will help protect the site's image during and after the incident (if possible) 🫧 They're also great because you can be totally candid with them, and they act as a buffer between the constant press attention and the POC, who needs to stay in control of the incident 🛡️

If there's no PR office, you have to be extra careful about what goes to the press 👀 If the info is sensitive, it may be a good idea to give only minimal or overview info. It's quite possible that anything given to the press will be quickly reviewed by the perpetrator of the incident 😳 But, plot twist, we also said that misleading the press can backfire and cause more damage than releasing sensitive info. Iconic dilemma, honestly 🥲

It's hard to know in advance how much detail to share, so here are some guidelines to keep in mind 🍓

Keep the technical level of detail low. Detailed info about the incident may give enough info for copy-cat events, or even damage the site's ability to prosecute once the event is over.
Keep the speculation out of press statements. Speculating about who is causing the incident or why is very likely to be wrong and may inflame the view of the incident 🔥
Work with law enforcement professionals to make sure evidence is protected. If prosecution is involved, make sure the evidence collected is not divulged to the press 🔒
Try not to be forced into a press interview before you're prepared. The popular press is famous for the "2am" interview, where the goal is to catch the interviewee off guard and get info they otherwise wouldn't give 🌙😭
Don't let press attention detract from handling the event. Always remember that successfully closing the incident is the primary goal 🏁

5.3.6. Who Needs to Get Involved?

There are now a bunch of incident response teams (IRTs) like the CERT and the CIAC. (See sections 3.9.7.3.1 and 3.9.7.3.4.) Teams exist for lots of major government agencies and large corporations 🏢 If a team like that is available for your site, 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 bigger entities, so even if the incident seems contained to one site, the info a response team has could help close it out 🦋

When you're setting up a site policy for incident handling, it may be a good idea to create an incident handling team (IHT) 🧑‍💻 It's like the teams that already exist, and it would be responsible for handling computer security incidents for the site (or organization) 💜 If you make one, it's essential that communication lines are opened between your IHT and other IHTs 🤝 Trying to build a trusted dialogue with other IHTs in the middle of an incident is really hard if you never talked before, so set that up early, bestie ✨

5.4. Response 💖

okay bestie, the big question nobody has touched yet is how you actually respond when something happens 🙈 responses fall into four main vibes: containment, eradication, recovery, and follow-up ✨

Containment 🛑

the whole point of containment is to limit how far an attack gets. it's SO important to stop a worm from spreading across a network as fast as humanly possible 🏃‍♀️ a big part of containment is decision making (aka deciding whether to shut a system down, disconnect it from the network, monitor system or network activity, set traps, disable stuff like remote file transfer on a UNIX system, etc.). sometimes it's a no-brainer: shut it down if the system is classified or sensitive, or if proprietary info is at risk!! 😭 other times it's actually worth risking some damage to the system if keeping it up might help you identify an intruder 🕵️‍♀️

the third stage, containment, should involve carrying out predetermined procedures 📋 your org or site should, for example, define acceptable risks in dealing with an incident ahead of time, and prescribe specific actions and strategies to match. and notifying the cognizant authorities should happen during this stage too 🫶

Eradication 🧹

once an incident has been detected, first think about containing it. once it's contained, it's time to eradicate the cause 🔥 software may be available to help, like eradication software that can eliminate most viruses infecting small systems 💻 if any bogus files were created, delete them at this point. for virus infections, clean and reformat any disks holding infected files. and ensure that all backups are clean ✨ lowkey so many systems keep getting reinfected because people never systematically eradicate the virus from their backups 💀

Recovery 🌱

once the cause has been eradicated, the recovery phase is the next stage. the goal is to return the system to normal 🌸 in the case of a network-based attack, install patches for any operating system vulnerability that was exploited 🩹

Follow-up 🔍

this is one of the most important stages of responding to incidents and also the most often omitted (it's the follow-up stage, bestie, don't skip it!!) 😤 it helps the people handling the incident develop a set of "lessons learned" (see section 6.3) so they level up next time 📈 it also provides information that justifies an organization's computer security effort to management, and it yields info that may be essential in legal proceedings ⚖️

the most important element of follow-up is performing a postmortem analysis 🍓 exactly what happened, and at what times? how well did the staff involved perform? what kind of information did the staff need quickly, and how could they have gotten it as soon as possible? what would the staff do differently next time? a follow-up report is valuable because it's a reference for other similar incidents. creating a formal chronology of events (including time stamps) is also important for legal reasons. it's also important to quickly get a monetary estimate of the damage in terms of lost software and files, hardware damage, and manpower costs to restore altered files, reconfigure affected systems, and so forth. this estimate may become the basis for subsequent prosecution activity by the FBI, the U.S. Attorney General's Office, etc.. 💼

5.4.1. What Will You Do? 🤔

Restore control.
Relation to policy.
Which level of service is needed?
Monitor activity.
Constrain or shut down system.

5.4.2. Consider Designating a "Single Point of Contact" 📣

when an incident is under way, a major issue is deciding who is in charge of coordinating the activity of the multitude of players 🎀 a major mistake is having a bunch of "points of contact" (POC) that aren't pulling their efforts together. that only adds to the confusion of the event, and will probably lead to even more confusion and wasted or ineffective effort 🙃

the single point of contact may or may not be the person "in charge" of the incident. there are two distinct rolls to fill when deciding who shall be the point of contact and the person in charge of the incident. the person in charge makes decisions about how policy applies to the event, and is responsible for handling the event. the point of contact, in contrast, must coordinate the effort of all the parties involved with handling the event 👑

the POC must have the technical expertise to successfully coordinate the effort of the system managers and users involved in monitoring and reacting to the attack 🧠 often, the management structure of a site means the administrator of a set of resources isn't a technically competent person when it comes to the details of operating the computers, but is ultimately responsible for how those resources are used 🤷‍♀️

another important job of the POC is maintaining contact with law enforcement and other external agencies (such as the CIA, DoD, U.S. Army, or others) to make sure multi-agency involvement happens 🦋

finally, if legal action in the form of prosecution is involved, the POC may be able to speak for the site in court 👩‍⚖️ the alternative is having multiple witnesses who will be hard to coordinate in a legal sense, and that will weaken any case against the attackers 😬 a single POC may also be the single person in charge of evidence collected, which keeps the number of people accounting for evidence to a minimum. as a rule of thumb, the more people that touch a potential piece of evidence, the greater the possibility that it will be inadmissible in court. the section below (Legal/Investigative) will provide more details for consideration on this topic 🌈

5.5. Legal/Investigative ⚖️✨

5.5.1. Establishing Contacts with Investigative Agencies 💼

bestie, it is so important to get in touch with people at investigative agencies like the FBI and Secret Service as soon as you can, and there are a few reasons why 🫶. Local law enforcement and local security offices or campus police orgs should also be looped in when it makes sense.

The first reason is that once a major attack is already happening, there is zero time to start calling around to figure out who the right point of contact is 😭. The second reason is that you want to cooperate with these agencies in a way that builds a good working relationship and matches how they actually operate. Knowing their working procedures and what your point of contact expects ahead of time is a huge step in that direction 💅. For example, it's important to gather evidence that will be admissible in a court of law. If you don't already know how to gather admissible evidence, all your effort to collect evidence during an incident might be totally useless to the agency you're working with 💀. The third reason is that you can never know in advance which agency will end up with jurisdiction over a given incident. Making contacts and finding the proper channels early will make responding to an incident go way more smoothly ✨.

If your organization or site has legal counsel, you need to notify that office soon after you learn an incident is in progress 🎀. At a minimum, your legal counsel needs to be involved to protect the legal and financial interests of your site or organization. There are a lot of legal and practical issues, and here are a few of them:

Whether your site or organization is willing to risk negative publicity or exposure in order to cooperate with legal prosecution efforts.
Downstream liability: if you leave a compromised system as is so it can be monitored, and another computer gets damaged because the attack came from your system, your site or organization may be liable for the damages incurred 😬.
Distribution of information: if your site or organization shares information about an attack that another site or organization may be involved in, or about a product vulnerability that could affect how well that product sells, your site or organization may again be liable for any damages, including damage to its reputation 📉.
Liabilities due to monitoring: your site or organization may get sued if users at your site or elsewhere find out that you're monitoring account activity without telling them 🙈.

Unfortunately, there are no clear precedents yet on the liabilities or responsibilities of organizations involved in a security incident, or of organizations that might help support an investigation. Investigators will often encourage organizations to help trace and monitor intruders. Honestly, most investigators can't pursue computer intrusions without a lot of 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 ton of work 🥲.

On the flip side, an organization's legal counsel may 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 anyone 🚫.

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

Your legal counsel should also be involved in any decision to contact investigative agencies when an incident happens at your site. The decision to coordinate with investigative agencies is most properly up to your site or organization. Involving your legal counsel also helps build multi-level coordination between your site and the investigative agency involved, which leads to an efficient division of labor 🧚. It also tends to get you guidance that helps you avoid future legal mistakes 🙌.

Finally, your legal counsel should evaluate your site's written procedures for responding to incidents. It is essential to get a "clean bill of health" from a legal perspective before you actually carry out those procedures 🩺.

5.5.2. Formal and Informal Legal Procedures 📜

One of the most important things when dealing with investigative agencies is verifying that the person calling for information is a legitimate representative of that agency 🕵️‍♀️. Unfortunately, lots of well-intentioned people have unknowingly leaked sensitive information about incidents, or let unauthorized people into their systems, because a caller pretended to be an FBI or Secret Service agent. Using a secure means of communication is a similar consideration. Because many network attackers can easily reroute electronic mail, avoid using electronic mail to communicate with other agencies (and with others dealing with the incident at hand) 📧. Non-secured phone lines (like the phones normally used in the business world) are also frequent targets for tapping by network intruders, so be careful!

There is no established set of rules for responding to an incident when the U.S. Federal Government gets involved 🇺🇸. Except by court order, no agency can force you to monitor, disconnect from the network, avoid telephone contact with the suspected attackers, and so on. As discussed in section 5.5.1, you should consult with your legal counsel, especially before taking an action your organization has never taken 📞. The particular agency involved may ask you to leave an attacked machine on and to monitor activity on it, for example. Complying with that request keeps the agency cooperating with you, which is usually the best route to finding the source of the network attacks and, ultimately, ending them 🦋.

You may also need some information or a favor from the agency involved in the incident, and you're most likely to get what you need if you've been cooperative 🎁. Above all, avoid unnecessary or unauthorized disclosure of information about the incident, including any information the agency gave you. The trust between your site and the agency depends on your ability to avoid compromising the case the agency is building, so keeping "tight lipped" is imperative 🤐.

Sometimes your needs and the needs of an investigative agency will differ. Your site may want to get back to normal business by closing an attack route, while the agency may want you to keep that route open 🚪. Similarly, your site may want to shut down a compromised system to avoid negative publicity, but the agency may want you to keep monitoring it. When there's a conflict like this, there may be a complex set of tradeoffs to think through, such as your site's management interests, how many resources you can put into the problem, jurisdictional boundaries, and so on 🧩. An important guiding principle here is what's sometimes called "Internet citizenship" [22, IAB89, 23] and its responsibilities 🌐. Your site can shut a system down, and that will relieve you of the stress, resource demands, and danger of negative exposure. The attacker, however, is likely to simply move on to another system, which leaves others blind to the attacker's intentions and actions until another attack path is detected 👀. As long as there's no damage to your systems or others, the most responsible move is to cooperate with the participating agency by leaving your compromised system on. This allows monitoring and, ultimately, the possibility of ending the threat to systems just like yours 💜. On the other hand, if there is damage to computers that were illegally accessed through your system, the choice gets more complicated. Shutting down the intruder may prevent further damage to systems, but it might make it impossible to track the intruder down 😵. If there has been damage, the decision about whether it's important to leave systems up to catch the intruder should involve all the organizations affected. Adding to the complexity, if you don't cooperate with the agency involved, you'll be less likely to get help from that agency in the future 🥀.

5.6. Documentation Logs ✨

Okay bestie, when you respond to an incident, you have to document EVERYTHING related to it 📝 This gives you (and everyone else trying to figure out what actually happened) valuable info. Documenting everything literally saves you time 💅 If you skip logging a phone call, for example, you'll forget a good chunk of what you learned and have to contact the source all over again. That wastes your time AND everyone else's, and nobody can afford that 😭 Detailed records also count as evidence for prosecution, if the case goes that way 👑 They help you do a final damage assessment (management and law enforcement will both want that, iykyk), and they give you the basis for a "lessons learned" session later 🦋

Early on, it's often impossible to tell whether prosecution is even on the table, so document like you're gathering evidence for a court case 🫶 At minimum, you should record:

All system events (audit records).
All actions you take (time tagged).
All phone conversations (including the person with whom you talked, the date and time, and the content of the conversation).

The most straightforward way to do this is keeping a log book 📖 It gives you one centralized, chronological source of info, so you don't have to dig through a pile of loose sheets of paper. A lot of this info is potential evidence in a court of law, so when you first suspect an incident will lead to prosecution, or an investigative agency gets involved, you need to regularly (e.g., every day) turn in photocopied, signed copies of your logbook (plus any media you used to record system events) to a document custodian. That custodian stores the copied pages somewhere secure (e.g., a safe) 🔐 When you hand stuff over, you should get a signed, dated receipt back from the custodian 🧾 Not following these procedures can get any evidence you collected thrown out in a court of law. Yikes 💀

6. Establishing Post-Incident Procedures ✨

6.1. Overview

After an incident, several actions should happen 🌸 They can be summarized like this:

An inventory should be taken of the systems' assets, i.e., a careful examination should determine how the system was affected by the incident,
The lessons learned as a result of the incident should be included in revised security plan to prevent the incident from re-occurring,
A new risk analysis should be developed in light of the incident,
An investigation and prosecution of the individuals who caused the incident should commence, if it is deemed desirable.

All four steps should feed back into the site security policy committee, which leads to prompt re-evaluation and amendment of the current policy 🔥

6.2. Removing Vulnerabilities

Getting rid of ALL vulnerabilities after an incident is hard 😩 The key is knowing and understanding the breach. Sometimes it's smart to remove all access or functionality ASAP, then bring normal operation back in limited stages 🎀 Just keep in mind that cutting off all access mid-incident obviously tells every user, including the alleged problem users, that the admins know something's up. That could seriously mess with an investigation 🙈 But letting the incident keep going might also mean more damage, loss, aggravation, or liability (civil or criminal), so it's a tough call.

If it turns out the breach came from a flaw in the systems' hardware or software, the vendor (or supplier) and the CERT should be notified ASAP 📣 Putting relevant phone numbers (plus electronic mail addresses and fax numbers) in the site security policy is strongly recommended 💜 To help get a quick acknowledgment and understanding, describe the flaw in as much detail as possible, including how to exploit it.

The second the breach happens, the entire system and all its components should be treated as suspect 🕵️‍♀️ System software is the most likely target. Prep is everything when it comes to recovering from a possibly tainted system 🧚 This includes checksumming all tapes from the vendor using a checksum algorithm which (hopefully) is resistant to tampering [10]. (See sections 3.9.4.1, 3.9.4.2.) If the original vendor distribution tapes are available, an analysis of all system files should start, and any irregularities should be noted and referred to all parties involved in handling the incident 🔍 Picking which backup tapes to recover from can be really hard, honestly. Remember the incident may have been going on for months or years before anyone found it, and the suspect might be an employee or otherwise have intimate knowledge of or access to the systems 😬 In every case, your pre-incident preparation decides what recovery is possible. In the absolute worst case, restoring from the original manufactures' media and reinstalling the systems will be the most prudent solution 🫠

Look back at the lessons learned from the incident and always update the policy and procedures to reflect the changes the incident made necessary ✨

6.2.1. Assessing Damage

Before cleanup can start, you need to figure out the actual system damage 🔎 This can take forever, but it should give you some insight into what kind of incident this was, and help with investigation and prosecution. It's best to compare against previous backups or original tapes when you can, since advance preparation is the key again 🔑 If the system supports centralized logging (most do), go back through 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 might shed some light too. Accounting can give you SO much helpful info for analyzing an incident and any later prosecution 📊

6.2.2. Cleanup

Once you've assessed the damage, you need a plan for system cleanup 🧹 In general, bringing services back up in the order of demand, so users are inconvenienced as little as possible, is the best practice 💖 Understand that the proper recovery procedures are extremely important and should be specific to the site.

You might have to go back to the original distributed tapes and recustomize the system 😤 To prepare for this worst-case scenario, keep a record of the original system setup and each customization change, kept current with every change to the system 📚

6.2.3. Follow up

Once you think a system is back in a "safe" state, holes and even traps could still be lurking in there 👀 In the follow-up stage, monitor the system for stuff that might have been missed during cleanup. It would be smart to use some of the tools mentioned in section 3.9.8.2 (e.g., COPS) as a starting point 🛠️ Just remember, these tools don't replace continual system monitoring and good systems administration procedures 💅

6.2.4. Keep a Security Log

Like we covered in section 5.6, a security log is seriously valuable during this vulnerability-removal phase 📓 There are two things to think about. First, keep logs of the procedures you used to make the system secure again. This should include command procedures (e.g., shell scripts) that can be run on a periodic basis to recheck security. Second, keep logs of important system events. You can reference these when you're trying to figure out how far the damage from an incident went 🔥

6.3. Capturing Lessons Learned

6.3.1. Understand the Lesson

After an incident, it's smart to write a report covering the incident, the method of discovery, the correction procedure, the monitoring procedure, and a summary of the lesson learned 📝 This helps everyone clearly understand the problem. Remember, it's really hard to learn from an incident if you don't understand its source 🧐

6.3.2. Resources

6.3.2.1. Other Security Devices, Methods

Security is a dynamic process, not a static one 🦋 What works depends on the kind of security available at each site and the whole array of devices and methods that help promote security. Keep up with the security side of the computer industry and its methods, and a security manager will make sure they're taking advantage of the latest tech 🚀

6.3.2.2. Repository of Books, Lists, Information Sources

Keep an on-site collection of books, lists, information sources, etc., as guides and references for securing the system 📚 Keep this collection up to date too. As systems change, so do security methods and problems 🌈

6.3.2.3. Form a Subgroup

Form a subgroup of system administration personnel to be the core security staff 👯‍♀️ This lets you discuss security problems and get multiple views on the site's security issues. The subgroup can also develop the site security policy and suggest changes as needed to keep the site secure 💜

6.4. Upgrading Policies and Procedures

6.4.1. Establish Mechanisms for Updating Policies, Procedures, and Tools

If an incident is based on poor policy, and the policy doesn't change, then you're doomed to repeat the past 😭 Once a site has recovered from an incident, its policy and procedures should be reviewed to include 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 🌸

6.4.2. Problem Reporting Procedures

Set up a problem reporting procedure to describe, in detail, the incident and its solutions 📋 Each incident should be reviewed by the site security subgroup, so everyone understands it and can make suggestions for the site policy and procedures 🫶

7. References ✨

okay bestie, this is the receipts section 🧾💅 every source the spec leans on is listed here with all its details, so you can go find the originals if you want to dig in 🔍

[1] Quarterman, J., "The Matrix: Computer Networks and Conferencing Systems Worldwide", Pg. 278, Digital Press, Bedford, MA, 1990.
[2] Brand, R., "Coping with the Threat of Computer Security Incidents: A Primer from Prevention through Recovery", R. Brand, available on-line from: cert.sei.cmu.edu:/pub/info/primer, 8 June 1990.
[3] Fites, M., Kratz, P. and A. Brebner, "Control and Security of Computer Information Systems", Computer Science Press, 1989.
[4] Johnson, D., and J. Podesta, "Formulating a Company Policy on Access to and Use and Disclosure of Electronic Mail on Company Computer Systems", Available from: The Electronic Mail Association (EMA) 1555 Wilson Blvd, Suite 555, Arlington VA 22209, (703) 522-7111, 22 October 1990.
[5] Curry, D., "Improving the Security of Your UNIX System", SRI International Report ITSTD-721-FR-90-21, April 1990.
[6] Cheswick, B., "The Design of a Secure Internet Gateway", Proceedings of the Summer Usenix Conference, Anaheim, CA, June 1990.
[7] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I -- Message Encipherment and Authentication Procedures", RFC 1113, IAB Privacy Task Force, August 1989.
[8] Kent, S., and J. Linn, "Privacy Enhancement for Internet Electronic Mail: Part II -- Certificate-Based Key Management", RFC 1114, IAB Privacy Task Force, August 1989.
[9] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part III -- Algorithms, Modes, and Identifiers", RFC 1115, IAB Privacy Task Force, August 1989.
[10] Merkle, R., "A Fast Software One Way Hash Function", Journal of Cryptology, Vol. 3, No. 1.
[11] Postel, J., "Internet Protocol - DARPA Internet Program Protocol Specification", RFC 791, DARPA, September 1981.
[12] Postel, J., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", RFC 793, DARPA, September 1981.
[13] Postel, J., "User Datagram Protocol", RFC 768, USC/Information Sciences Institute, 28 August 1980.
[14] Mogul, J., "Simple and Flexible Datagram Access Controls for UNIX-based Gateways", Digital Western Research Laboratory Research Report 89/4, March 1989.
[15] Bellovin, S., and M. Merritt, "Limitations of the Kerberos Authentication System", Computer Communications Review, October 1990.
[16] Pfleeger, C., "Security in Computing", Prentice-Hall, Englewood Cliffs, N.J., 1989.
[17] Parker, D., Swope, S., and B. Baker, "Ethical Conflicts: Information and Computer Science, Technology and Business", QED Information Sciences, Inc., Wellesley, MA.
[18] Forester, T., and P. Morrison, "Computer Ethics: Tales and Ethical Dilemmas in Computing", MIT Press, Cambridge, MA, 1990.
[19] Postel, J., and J. Reynolds, "Telnet Protocol Specification", RFC 854, USC/Information Sciences Institute, May 1983.
[20] Postel, J., and J. Reynolds, "File Transfer Protocol", RFC 959, USC/Information Sciences Institute, October 1985.
[21] Postel, J., Editor, "IAB Official Protocol Standards", RFC 1200, IAB, April 1991.
[22] Internet Activities Board, "Ethics and the Internet", RFC 1087, Internet Activities Board, January 1989.
[23] Pethia, R., Crocker, S., and B. Fraser, "Policy Guidelines for the Secure Operation of the Internet", CERT, TIS, CERT, RFC in preparation.
[24] Computer Emergency Response Team (CERT/CC), "Unauthorized Password Change Requests", CERT Advisory CA-91:03, April 1991.
[25] Computer Emergency Response Team (CERT/CC), "TELNET Breakin Warning", CERT Advisory CA-89:03, August 1989.
[26] CCITT, Recommendation X.509, "The Directory: Authentication Framework", Annex C.
[27] Farmer, D., and E. Spafford, "The COPS Security Checker System", Proceedings of the Summer 1990 USENIX Conference, Anaheim, CA, Pgs. 165-170, June 1990.

8. Annotated Bibliography 📚

okay so this bibliography is basically a curated reading list 🌸 It's meant to give you a starting point for digging deeper into security stuff, and it points at other sources for anyone who wants to go full rabbit hole 🐇 Think of it as a friendly map of the computer security world 🗺️✨

8.1. Computer Law ⚖️

[ABA89] 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.
[BENDER] Bender, D., "Computer Law: Evidence and Procedure", M. Bender, New York, NY, 1978-present.
- Kept up to date with supplements. Years covering 1978-1984 focus on: Computer law, evidence and procedures. The years 1984 to the current focus on general computer law. Bibliographical references and index included.
[BLOOMBECKER] Bloombecker, B., "Spectacular Computer Crimes", Dow Jones-Irwin, Homewood, IL. 1990.
[CCH] Commerce Clearing House, "Guide to Computer Law", (Topical Law Reports), Chicago, IL., 1989.
- Court cases and decisions rendered by federal and state courts throughout the United States on federal and state computer law. Includes Case Table and Topical Index.
[CONLY] Conly, C., "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.
[FENWICK] Fenwick, W., 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.
[GEMIGNANI] Gemignani, M., "Viruses and Criminal Law", Communications of the ACM, Vol. 32, No. 6, Pgs. 669-671, June 1989.
[HUBAND] Huband, F., 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.
[MCEWEN] McEwen, J., "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.
[PARKER] Parker, D., "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.
[SHAW] Shaw, E., Jr., "Computer Fraud and Abuse Act of 1986, Congressional Record (3 June 1986), Washington, D.C., 3 June 1986.
[TRIBLE] Trible, P., "The Computer Fraud and Abuse Act of 1986", U.S. Senate Committee on the Judiciary, 1986.

8.2. Computer Security 🔐

[CAELLI] Caelli, W., Editor, "Computer Security in the Age of Information", Proceedings of the Fifth IFIP International Conference on Computer Security, IFIP/Sec '88.
[CARROLL] Carroll, J., "Computer Security", 2nd Edition, Butterworth Publishers, Stoneham, MA, 1987.
[COOPER] Cooper, J., "Computer and Communications Security: Strategies for the 1990s", McGraw-Hill, 1989.
[BRAND] Brand, R., "Coping with the Threat of Computer Security Incidents: A Primer from Prevention through Recovery", R. Brand, 8 June 1990.
- As computer security becomes a more important issue in modern society, it begins to warrant a systematic approach. The vast majority of the computer security problems and the costs associated with them can be prevented with simple inexpensive measures. The most important and cost effective of these measures are available in the prevention and planning phases. These methods are presented in this paper, followed by a simplified guide to incident handling and recovery. Available on-line from: cert.sei.cmu.edu:/pub/info/primer.
[CHESWICK] Cheswick, B., "The Design of a Secure Internet Gateway", Proceedings of the Summer Usenix Conference, Anaheim, CA, June 1990.
- Brief abstract (slight paraphrase from the original abstract): AT&T maintains a large internal Internet that needs to be protected from outside attacks, while providing useful services between the two. This paper describes AT&T's Internet gateway. This gateway passes mail and many of the common Internet services between AT&T internal machines and the Internet. This is accomplished without IP connectivity using a pair of machines: a trusted internal machine and an untrusted external gateway. These are connected by a private link. The internal machine provides a few carefully-guarded services to the external gateway. This configuration helps protect the internal internet even if the external machine is fully compromised.
- This is a very useful and interesting design. Most firewall gateway systems rely on a system that, if compromised, could allow access to the machines behind the firewall. Also, most firewall systems require users who want access to Internet services to have accounts on the firewall machine. AT&T's design allows AT&T internal internet users access to the standard services of TELNET and FTP from their own workstations without accounts on the firewall machine. A very useful paper that shows how to maintain some of the benefits of Internet connectivity while still maintaining strong security.
[CURRY] Curry, D., "Improving the Security of Your UNIX System", SRI International Report ITSTD-721-FR-90-21, April 1990.
- This paper describes measures that you, as a system administrator, can take to make your UNIX system(s) more secure. Oriented primarily at SunOS 4.x, most of the information covered applies equally well to any Berkeley UNIX system with or without NFS and/or Yellow Pages (NIS). Some of the information can also be applied to System V, although this is not a primary focus of the paper. A very useful reference, this is also available on the Internet in various locations, including the directory cert.sei.cmu.edu:/pub/info.
[FITES] Fites, M., Kratz, P. and A. Brebner, "Control and Security of Computer Information Systems", Computer Science Press, 1989.
- This book serves as a good guide to the issues encountered in forming computer security policies and procedures. The book is designed as a textbook for an introductory course in information systems security.

That's the whole bibliography, bestie! 🌈💖

Okay so this part picks up mid-blurb, and bestie, the book is giving structure 🎀. It's split into five sections: Risk Management (I), Safeguards: security and control measures, organizational and administrative (II), Safeguards: Security and Control Measures, Technical (III), Legal Environment and Professionalism (IV), and CICA Computer Control Guidelines (V).

The vibe is super straight-forward 💅. It's all about common sense being the first thing you consider when you design a security program 🧠. The authors call out how people tend to jump straight to fancy technical fixes and totally overlook organizational controls, which are often cheaper and way more effective 💖. 298 pages, including references and index 📚.

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

Approx 450 pages, $29.95. Orders: 1-800-338-6887 (US & Canada), 1-707-829-0515 (Europe), email: nuts@ora.com 🦋

This one is literally one of the most useful books out there on Unix security 🔥. Part one covers standard Unix and Unix security basics, with major focus on passwords 🔑. Part two is all about enforcing security on the system 🛡️. The network security sections are a must for Internet Unix users, because they tackle the common problems that keep hitting those systems 😭. Four chapters are about handling security incidents, and it wraps up with encryption, physical security, and checklists plus lists of resources 🌸. It lives up to its name, ngl. It's packed with specific references to possible security holes, files to check, and things to do to level up your security 👑. This book is an excellent complement to this handbook 🫶.

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

A manager's guide to computer security 💼. It's got a sourcebook of key reference materials, including access control and computer crimes bibliographies 🧚.

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

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

A white paper prepared for the EMA, written by two experts in privacy law ⚖️. It gives background on the issues and presents some policy options 🍓.

Available from: The Electronic Mail Association (EMA) 1555 Wilson Blvd, Suite 555, Arlington, VA, 22209. (703) 522-7111.

[KENT] Kent, Stephen, "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. 📰

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

[LU1] Lu, W., 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. 🧩

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

The NSA catalogue has chapters on the Endorsed Cryptographic Products List; NSA Endorsed Data Encryption Standard (DES) Products List; Protected Services List; Evaluated Products List; Preferred Products List; and Endorsed Tools List 🕵️‍♀️.

The catalogue is available from the Superintendent of Documents, U.S. Government Printing Office, Washington, D.C. You can place telephone orders by calling: (202) 783-3238 📞.

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

This report was prepared for a congressional committee looking at Federal policy on protecting electronic information, and it's so interesting because of the issues it raises about how the technology used to protect information actually affects things 🤯. It's also a reasonable intro to the different encryption and information protection mechanisms 🔒. 185 pages. Available from the U.S. Government Printing Office 🖨️.

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

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

A general textbook in computer security, and it's an excellent, super readable intro to classic computer security problems and solutions 📖✨. It puts a particular emphasis on encryption, and that coverage is a good intro to the subject 🔐. It also covers building secure programs and systems, security of databases, personal computer security, network and communications security, physical security, risk analysis and security planning, and legal and ethical issues 💜. 538 pages including index and bibliography.

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

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

This is a good general reference on computer viruses and related concerns 🦠. Besides describing viruses in detail, it also covers broader security issues, legal recourse when security problems happen, and includes lists of laws, journals focused on computer security, and other security-related resources 📚🎀.

Available from: ADAPSO, 1300 N. 17th St, Suite 300, Arlington VA 22209. (703) 522-5055.

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

This article describes some of the technical means used to trace the intruder that was later chronicled in "Cuckoo's Egg" (see below) 🕵️‍♀️💻.

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

Clifford Stoll, an astronomer turned UNIX System Administrator, recounts an exciting, true story of how he tracked a computer intruder through the maze of American military and research networks 🔭🌈. It's easy to understand and can be an interesting intro to the world of networking 🦋. Jon Postel says in a book review, "[this book] ... is absolutely essential reading for anyone that uses or operates any computer connected to the Internet or any other computer network." 💅

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

8.3. Ethics 🫶

Okay bestie, this is the ethics shelf of the reading list 📚💜 Lowkey the most important part of the whole thing, so let's go.

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

This one is a statement on the Internet Computer Virus from the Computer Professionals for Social Responsibility (CPSR). Short, sharp, and very on point 💅

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

This is a collection of 40 pieces split into six sections. It covers the rise of worldwide computer networks, electronic break-ins, worms, viruses, and counterculture (articles about the world of the "hacker"). The last section looks at social, legal, and ethical considerations. It's a thoughtful read about attacks on computers, mixing older published articles with some new ones. The older pieces are well chosen and include references that are otherwise hard to find. It's basically a key reference for the computer security threats that have caused so much worry in recent years 🔥

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

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

The preface says the book has two goals 🎀 First, it describes problems that computers create for society. Second, it shows how those problems turn into ethical dilemmas for computer professionals and computer users. The problems come from two main places: hardware and software malfunctions, and misuse by humans. The authors argue that computer systems are insecure, unreliable, and unpredictable by their very nature, and that society hasn't really caught up with what that means. They also show how society has become newly vulnerable to people misusing computers, through things like computer crime, software theft, hacking, creating viruses, and invasions of privacy.

The eight chapters are "Computer Crime", "Software Theft", "Hacking and Viruses", "Unreliable Computers", "The Invasion of Privacy", "AI and Expert Systems", and "Computerizing the Workplace." It also has extensive notes on sources and an index 📖✨

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

[IAB89] 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.

This is a statement of policy from the Internet Activities Board (IAB) about using the Internet's resources properly. It's giving official guidance energy 🧚 You can grab it on-line from host ftp.nisc.sri.com, directory rfc, filename rfc1087.txt. It's also on host nis.nsf.net, directory RFC, filename RFC1087.TXT-1.

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

[MIT89] 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.

This is MIT's policy statement on the responsible use of computers. Very principled, very iconic 🌸

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

[NSF88] 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.

This is the National Science Foundation (NSF) laying down its policy on the ethical use of the Internet. Main character energy 👑

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

Additional publications on Ethics:

The University of New Mexico (UNM) has a collection of ethics documents 🦋 It includes legislation from several states and policies from many institutions. You can get it by FTP at IP address ariel.umn.edu. Look in the directory /ethics.

8.4. The Internet Worm 🐛

Okay, this section is the "what actually happened" tea ☕ Every one of these is about the Internet worm.

[BROCK] Brock, J., "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.

This is the testimony of Jack L. Brock, Director, U. S. Government Information, before the Subcommittee on Telecommunications and Finance, Committee on Energy and Commerce, House of Representatives. Very official, very serious 🧐

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

This one is a detailed dissection of the worm program 🔬 It goes through the main points of the worm, then reviews strategies, chronology, lessons and open issues, and Acknowledgments. There's a detailed appendix going through the worm subroutine by subroutine, another appendix on the cast of characters, and a reference section. Bestie, it's so thorough it's unhinged in the best way 😭

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

This is a Cornell University report given to the Provost of the University on 6 February 1989 about the Internet Worm.

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

This 36 page report (GAO/IMTEC-89-57) from the U.S. Government Accounting Office describes the Internet worm and what it did. It gives a great overview of the different U.S. agencies involved with the Internet today, and their concerns vis-a-vis computer security and networking. 🧚

You can get it on-line from host nnsc.nsf.net, directory pub, filename GAO_RPT. It's also on nis.nsf.net, directory nsfnet, filename GAO_RPT.TXT.

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

This report looks back at the helminthiasis (infestation with, or disease caused by, parasitic worms) of the Internet that was unleashed on the evening of 2 November 1988 🪱 It covers the infection, its festering, and the cure. It also discusses the impact of the worm on the Internet community, ethics statements, the role of the news media, crime in the computer world, and future prevention. There's a documentation review of four publications that describe this particular parasitic computer program in detail, plus reference and bibliography sections.

You can get it on-line from host ftp.nisc.sri.com, directory rfc, filename rfc1135.txt. It's also on host nis.nsf.net, directory RFC, filename RFC1135.TXT-1.

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

This paper is a "walk thru" of this particular worm program 🚶‍♀️ It opens with an abstract and an introduction, then gives a detailed chronology of events after the worm was discovered. After that comes an overview, the internals of the worm, personal opinions, and a conclusion.

[SPAFFORD88] Spafford, E., "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.

This one describes the infection of the Internet as a worm program that exploited flaws in utility programs on UNIX based systems. It gives a detailed description of the worm's components: its data and functions. Spafford's study focuses on two completely independent reverse-compilations of the worm, plus a version disassembled to VAX assembly language 🧠

[SPAFFORD89] Spafford, G., "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.

That's the whole ethics and worm shelf, bestie 💜✨

8.5. National Computer Security Center (NCSC) 🔐✨

Okay bestie, all NCSC publications that are approved for public release are available from the NCSC Superintendent of Documents 📚

NCSC = National Computer Security Center
9800 Savage Road
Ft Meade, MD 20755-6000

CSC = Computer Security Center:
an older name for the NCSC

NTISS = National Telecommunications and
Information Systems Security
NTISS Committee, National Security Agency
Ft Meade, MD 20755-6000

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

Okay so the security of a password system depends on passwords staying secret at all times 😭 That means a password is vulnerable to compromise whenever it's used, stored, or even known. In a password-based authentication mechanism on an ADP system, passwords are at risk because of five essential aspects of the password system: 1) a password has to be initially assigned to a user when they enroll on the ADP system; 2) a user's password has to be changed periodically; 3) the ADP system has to maintain a 'password database'; 4) users have to remember their passwords; and 5) users have to enter their passwords into the ADP system at authentication time. This guideline lays out steps to minimize the vulnerability of passwords in each of these situations. It's giving careful, it's giving prepared 💅

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

Audit trails are used to detect and deter penetration of a computer system and to reveal usage that identifies misuse. At the discretion of the auditor, audit trails may be limited to specific events or may cover all of the activities on a system. Although not required by the criteria, it should be possible for the target of the audit mechanism to be either a subject or an object. In other words, the audit mechanism should be able to monitor every time John accessed the system, as well as every time the nuclear reactor file was accessed, and likewise every time John accessed the nuclear reactor file. Main character energy for the audit log 👀🔥

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

Discretionary control is the most common type of access control mechanism in computer systems today. The idea is that an individual user, or a program running on the user's behalf, is allowed to explicitly specify the types of access other users (or programs running on their behalf) may have to information under the user's control. [...] Discretionary controls are not a replacement for mandatory controls. In any environment where information is protected, discretionary security gives a finer granularity of control within the overall constraints of the mandatory policy. Layers, bestie, layers 🧁

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

Configuration management has four separate tasks: identification, control, status accounting, and auditing. For every change made to an automated data processing (ADP) system, the design and requirements of the changed version of the system should be identified. The control task is handled by putting every change to documentation, hardware, and software/firmware through review and approval by an authorized authority. Configuration status accounting is responsible for recording and reporting on the configuration of the product throughout the change. Finally, though the process of a configuration audit, the completed change can be verified to be functionally correct and, for trusted systems, consistent with the security policy of the system. Verified, certified, iconic ✨

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

This document gives guidance to users, managers, security officers, and procurement officers of Office Automation Systems. The areas it covers are: physical security, personnel security, procedural security, hardware/software security, emanations security (TEMPEST), and communications security. That's for stand-alone OA Systems, OA Systems used as terminals connected to mainframe computer systems, and OA Systems used as hosts in a Local Area Network (LAN). It also separates Office Automation Systems that only have removable storage media (e.g., floppy disks, cassette tapes, removable hard disks) from those with fixed media (e.g., Winchester disks). Thorough, bestie, thorough 🫶

Additional NCSC Publications:

[NCSC4] National Computer Security Center, "Glossary of Computer Security Terms", NCSC-TG-004, NCSC, 21 October 1988. 📖
[NCSC5] National Computer Security Center, "Trusted Computer System Evaluation Criteria", DoD 5200.28-STD, CSC-STD-001-83, NCSC, December 1985. 🏆
[NCSC7] 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. 🌸
[NCSC8] National Computer Security Center, "Technical Rationale Behind CSC-STD-003-85: Computer Security Requirements", CSC-STD-004-85, NCSC, 25 June 85. 🧠
[NCSC9] National Computer Security Center, "Magnetic Remanence Security Guideline", CSC-STD-005-85, NCSC, 15 November 1985. 🧲

This guideline is tagged as a "For Official Use Only" exemption under Section 6, Public Law 86-36 (50 U.S. Code 402). Distribution is authorized to U.S. Government agencies and their contractors to protect unclassified technical, operational, or administrative data relating to operations of the National Security Agency. Very classified energy 🤫

[NCSC10] 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. ✅
[NCSC11] 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. 📚
[NCSC12] 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. 🐧
[NCSC13] National Computer Security Center, "Trusted Network Interpretation", NCSC-TG-005, NCSC, 31 July 1987. 🌐
[NCSC14] Tinto, M., "Computer Viruses: Prevention, Detection, and Treatment", National Computer Security Center C1 Technical Report C1-001-89, June 1989. 🦠
[NCSC15] 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. 🎤

8.6. Security Checklists 📋💜

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

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

8.7. Additional Publications 🌈

Defense Data Network's Network Information Center (DDN NIC)

The DDN NIC keeps DDN Security bulletins and DDN Management bulletins online on the machine NIC.DDN.MIL. You can grab them via anonymous FTP. The DDN Security bulletins live in the directory SCC, and the DDN Management bulletins live in the directory DDN-NEWS. 📂

If you want more info, you can send a message to NIC@NIC.DDN.MIL, or call the DDN NIC at 1-800-235-3155. 📞

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

This is a Defense Data Network Management Bulletin announcement about the 4.2bsd and 4.3bsd software fixes for the Internet worm. Worm arc, closed 🐛

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

IEEE Proceedings

[IEEE] "Proceedings of the IEEE Symposium on Security and Privacy", published annually. 🗞️

IEEE Proceedings are available from:

Computer Society of the IEEE
P.O. Box 80452
Worldway Postal Center
Los Angeles, CA  90080

Other Publications:

Computer Law and Tax Report
Computers and Security
Security Management Magazine
Journal of Information Systems Management
Data Processing & Communications Security
SIG Security, Audit & Control Review

9. Acknowledgments 💌🫶

Huge thanks to the SSPHWG's illustrious "Outline Squad", who got together at USC/Information Sciences Institute on 12-June-90: Ray Bates (ISI), Frank Byrum (DEC), Michael A. Contino (PSU), Dave Dalva (Trusted Information Systems, Inc.), Jim Duncan (Penn State Math Department), Bruce Hamilton (Xerox), Sean Kirkpatrick (Unisys), Tom Longstaff (CIAC/LLNL), Fred Ostapik (SRI/NIC), Keith Pilotti (SAIC), and Bjorn Satdeva (/sys/admin, inc.). The squad is iconic 👑

Many, many thanks to Rich Pethia and the Computer Emergency Response Team (CERT). Much of the work by Paul Holbrook was done while he was working for CERT. Rich also gave a very thorough review of this document. Thanks also to Jon Postel and USC/Information Sciences Institute for contributing facilities and moral support to this effort. 🙏

Last, but NOT least, we'd like to thank members of the SSPHWG and Friends for their extra contributions: Vint Cerf (CNRI), Dave Grisham (UNM), Nancy Lee Kirkpatrick (Typist Extraordinaire), Chris McDonald (WSMR), H. Craig McKee (Mitre), Gene Spafford (Purdue), and Aileen Yuan (Mitre). Typist Extraordinaire, no cap 💅🎀

10. Security Considerations 🚨

If security considerations had not been so widely ignored in the Internet, this memo would not have been possible. 😭🔥

11. Authors' Addresses ✨

okay so this is the contact card section, bestie 📇💅 it's where the two authors leave their addresses, phone numbers, and emails so people can reach them. no cap, the vibe is very "here's my number, text me" 🫶

J. Paul Holbrook 🌸 CICNet, Inc. 2901 Hubbard Ann Arbor, MI 48105

Phone: (313) 998-7680 EMail: holbrook@cic.net

Joyce K. Reynolds 🦋 University of Southern California Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292

Phone: (213) 822-1511 EMail: JKREY@ISI.EDU

and that's the whole document, periodt! 🎀💖

📦 where this page comes from

ietf: rfc1244 1991-07
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms