[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Anne's comments on draft-04, 4/4: new populated template
- To: GRIP Working Group <grip-wg@UU.NET>
- Subject: Anne's comments on draft-04, 4/4: new populated template
- From: Anne Bennett <anne@alcor.concordia.ca>
- Date: Mon, 31 Mar 97 22:55:45 -0500
- Comment: grip-wg mailing list add/drop requests to Majordomo@TransSys.COM
- Reply-to: Anne Bennett <anne@alcor.concordia.ca>
OK, the part you've all been waiting for: a revised version of the
"populated template" -- appendix E.
First, general comments and questions.
I asked last July: "If we're going to propose that the SIRT's
description should be put up as a Web page, should we provide a
template in HTML form? Or should we leave that up to the SIRTs?"
I gather from the was my template was placed into the draft that, at
least for purposes of the draft, we wish to remain general and avoid
references to a specific information service such as WWW. Is that
right?
Since section 1 on contact information is rather longish, and the first
order of business when reading a SIRT description is to make sure that
we have the latest and that it is authentic, it might make sense to
swap sections 1 and 2. I've done so below, and renamed "2" from
"Document updates" to "about this document" -- see what you think.
I've left the numbering as is, since if you decide to keep my change,
you'll have to renumber 1 and 2 everywhere anyway, so I'll let you
figure it out. I've added a fourth subsection in "2" to provide
somewhere to point to the external digital signature.
Another note that occurs to me about our document (the IETF draft), is
that in many locations it was a bit unclear whether "document"
referred to the draft (future RFC), the template to be filled in, or
the resulting SIRT description document. You may have noticed that I
tried to disambiguate this where I could, and that I adopted the term
"SIRT description document" for the, well, SIRT description document. :-)
"xyz.org" actually exists, by the way, so since I am reverting to XYZ
University instead of XYZ Enterprises for our fictitious organization,
I am going to place it in Canada, to make the specific information
look a bit more believable. Also, trying to do things exactly as I'd
have to do them at my University helps iron out practical problems
which would be glossed over if I did not try to be as realistic as
possible with this description document.
I think I've completed most of this quite reasonably now, though of
course comments will be most welcome. However, I had a terrible time
with sections 4.2 (Cooperation and Interaction with Other Entities) and
4.3 (Disclosure of Information): they seem quite inseparable to me.
Is the problem simply that I have no "routine interactons" to list for
section 4.2, and am flailing away trying to make some up, or is the
problem that these two sections really ought to be merged? For now,
I've merged them. I'd be interested in hearing from other sites
(perhaps Barbara can speak for CERT, for example) as to how they'd
handle these sections.
If the consensus is that the two sections ought *not* be merged, then
perhaps I should simply put "none" for section 4.2 in my case.
Anyway, the new appendix E is appended.
Anne.
--
Ms. Anne Bennett, Computing Services, Concordia University, Montreal H3G 1M8
anne@alcor.concordia.ca (514) 848-7606
----------------------------------------------------------------------------
SIRT Description for XYZ-CERT
-----------------------------
2. About this document
2.1 Date of Last Update
This is version 1.01, published 1997/03/31.
2.2 Distribution List for Notifications
Notifications of updates are submitted to our mailing list
<xyz-cert-info@xyz-univ.ca>. Subscription requests for this
list should be sent to the Majordomo at
<xyz-cert-info-request@xyz-univ.ca>; the body of the message
should consist of the word "subscribe". Send the word "help"
instead if you don't know how to use a Majordomo list manager.
This mailing list is moderated, but anyone may subscribe.
2.3 Locations where this Document May Be Found
The current version of this SIRT description document is available
from the XYZ-CERT WWW site; its URL is
http://www.xyz-univ.ca/xyz-cert/english/sirt-descr.txt
Une version française de ce document est également disponible:
http://www.xyz-univ.ca/xyz-cert/francais/sirt-descr.txt
Please make sure you are using the latest version.
2.4 Authenticating this Document
Both the English and French versions of this document have
been signed with the XYZ-CERT's PGP key. The signatures are
also on our Web site, under:
http://www.xyz-univ.ca/xyz-cert/english/sirt-descr.asc
http://www.xyz-univ.ca/xyz-cert/francais/sirt-descr.asc
1. Contact Information
1.1 Name of the Team
"XYZ-CERT": the XYZ University Computer Emergency Response Team.
1.2 Address
XYZ-CERT
XYZ University, Computing Services Department
12345 Rue Principale
UniversityTown, Quebec
Canada H0H 0H0
1.3 Time Zone
Canada/Eastern (GMT-0500, and GMT-0400 from April to October)
1.4 Telephone Number
+1 234 567 7890 (ask for the XYZ-CERT)
1.5 Facsimile Number
+1 234 567 7899 (this is *not* a secure fax)
1.6 Other Telecommunication
None available.
1.7 Electronic Mail Address
<xyz-cert@xyz-univ.ca> This is a mail alias that relays mail
to the human(s) on duty for the XYZ-CERT.
1.8 Public Keys and Other Encryption Information
The XYZ-CERT has a PGP key, whose KeyID is 12345678 and
whose fingerprint is
11 22 33 44 55 66 77 88 88 77 66 55 44 33 22 11.
The key and its signatures can be found at the usual large
public keyservers.
Because PGP is still a relatively new technology at XYZ
University, this key still has relatively few signatures;
efforts are underway to increase the number of links to this
key in the PGP "web of trust". In the meantime, since most
fellow universities in Quebec have at least one staff member
who knows the XYZ-CERT coordinator Anne Doe, Anne Doe has
signed the XYZ-CERT key, and will be happy to confirm its
fingerprint and that of her own key to those people who know
her, by telephone or in person.
1.9 Team Members
Anne Doe of Computing Services is the XYZ-CERT coordinator.
Backup coordinators and other team members, along with their
areas of expertise and contact information, are listed in the
XYZ-CERT web pages, at
http://www.xyz-univ.ca/xyz-cert/teamlist.html
Management liaison and supervision are provided by Steve Tree,
Assistant Director (Technical Services), Computing Services.
1.10 Other Information
General information about the XYZ-CERT, as well as links to
various recommended security resources, can be found at
http://www.xyz-univ.ca/xyz-cert/index.html
3. Charter
3.1 Mission Statement
The purpose of the XYZ-CERT is, first, to assist members of XYZ
University community in implementing proactive measures to reduce
the risks of computer security incidents, and second, to assist
XYZ community in responding to such incidents when they occur.
3.2 Constituency
The XYZ-CERT's constituency is the XYZ University community,
as defined in the context of the "XYZ University Policy on
Computing Facilities". This policy is available at
http://www-compserv.xyz-univ.ca/policies/pcf.html
However, please note that XYZ-CERT services will not be
provided for home computers, even if they were purchased with
University or grant funds and are therefore included in the
definition of "XYZ Computing Facilities". Such machines, as
well as those which connect to XYZ's network via the
University's dial-in service, will be considered to be
"offsite" for the purposes of this document.
3.3 Sponsorship and/or Affiliation
The XYZ-CERT is currently completing the application process
for membership in FIRST, the Forum of Incident Response and
Security Teams. More information about FIRST is available
from
http://www.first.org/
3.4 Authority
The XYZ-CERT operates under the auspices of, and with authority
delegated by, the Department of Computing Services of XYZ
University. The Department in turn receives its authority from
the formal ruling bodies of XYZ University, as set out in the
"Policy on Computing Facilities", available at
http://www-compserv.xyz-univ.ca/policies/pcf.html
The XYZ-CERT has no direct authority over systems at XYZ
University at large. However, it benefits from the direct
authority of Computing Services with respect to systems managed
by that Department. Also, because Computing Services manages
the XYZ University Network, and is responsible for connectivity
to it, the Department has indirect authority over systems in
other departments, inasmuch as the Department can order such
systems to be disconnected from the network should
circumstances warrant it. This last measure can also be
applied to systems outside XYZ University, whose traffic may
be denied access to the XYZ University network if this is
judged necessary.
The XYZ-CERT expects to work cooperatively with system
administrators and users at XYZ University, and, insofar as
possible, to avoid authoritarian relationships. However,
should circumstances warrant it, the XYZ-CERT will appeal to
Computing Services to exert its authority, direct or indirect,
as necessary. All members of the XYZ-CERT are members of the
CCSA (Committee of Computer Systems Administrators), and have
all of the powers and responsibilities assigned to Systems
Administrators by the Policy on Computing Facilities.
Members of the XYZ University community who wish to appeal the
actions of the XYZ-CERT should contact the Assistant Director
(Technical Services), Computing Services. If this recourse is
not satisfactory, the matter may be referred to the Senate's
Computer Resources Committee (in the case of perceived
problems with existing policy), or to the the XYZ University
Office of Rights and Responsibilities (in the case of perceived
errors in the application of existing policy).
4. Policies
4.1 Types of Incidents and Level of Support
The XYZ-CERT is authorized to address all types of computer
security incidents which occur, or threaten to occur, at
XYZ University.
The level of support given by XYZ-CERT will vary depending on
the type and severity of the incident or issue, the type of
constituent, the size of the user community affected, and the
XYZ-CERT's resources at the time. The support given will vary
from a pointer to information accompanied by an expression of
sympathy, to onsite visits and real-time technical assistance.
Unfortunately, due to contraints of staffing, support will be
on a best-effort basis, and no specific service level
commitments can be made, except that in all cases some
response will be made within one working day. Resources will
be assigned according to the following priorities, listed in
decreasing order:
- Root or system-level attacks on any Management Information
System, or any part of the backbone network infrastructure.
- Root or system-level attacks on any large public service
machine, either multi-user or dedicated-purpose.
- Compromise of restricted confidential service accounts or
software installations, in particular those used for MIS
applications containing confidential data, or those used
for system administration.
- Denial of service attacks on any of the above.
- Any of the above at other sites, originating from XYZ
University.
- Large-scale attacks of any kind, e.g. sniffing attacks,
IRC "social engineering" attacks, password cracking
attacks.
- Compromise of individual user accounts on multi-user
systems.
- Compromise of desktop systems.
- Forgery and misrepresentation, and other security-related
violations of local rules and regulations, e.g. netnews
and e-mail forgery, unauthorized use of IRC bots.
- Denial of service on individual user accounts, e.g.
mailbombing.
Types of incidents other than those mentioned above will be
prioritized according to their apparent severity and extent.
Note that no direct support will be given to end users; they
are expected to contact their system administrator, network
administrator, or department head for assistance. The XYZ-CERT
will support the latter people.
While the XYZ-CERT understands that there exists great
variation in the level of system administrator expertise at XYZ
University, and while the XYZ-CERT will endeavor to present
information and assistance at a level appropriate to each
person, the XYZ-CERT cannot train system administrators on the
fly, and it cannot perform system maintenance on their behalf.
In most cases, the XYZ-CERT will provide pointers to the
information needed to implement appropriate measures.
The XYZ-CERT is committed to keeping the XYZ University system
administration community informed of potential
vulnerabilities, and where possible, will inform this
community of such vulnerabilities before they are actively
exploited.
4.2 Cooperation and Interaction with Other Entities
4.3 Disclosure of Information
(MERGED FOR NOW)
While there are legal and ethical restrictions on the flow of
information from XYZ-CERT, many of which are also outlined in
the XYZ University Policy on Computing Facilities, and all of
which will be respected, the XYZ-CERT acknowledges its
indebtedness to, and declares its intention to contribute to,
the spirit of cooperation that created the Internet.
Therefore, while appropriate measures will be taken to protect
the identity of members of our constituency and members of
neighbouring sites where necessary, the XYZ-CERT will otherwise
share information freely when this will assist others in
resolving or preventing security incidents.
In the paragraphs below, the "affected parties" refers to the
legitimate owners, operators, and users of the relevant
computing facilities. It does not refer to unauthorized
users, including otherwise authorized users making
unauthorized use of a facility; such intruders may have no
expectation of confidentiality from the XYZ-CERT. They may or
may not have legal rights to confidentiality; such rights will
of course be respected where they exist.
Information being considered for release will be classified as
follows:
- Private user information is information about particular users,
or in some cases, particular applications, which must be
considered confidential for legal, contractual, and/or ethical
reasons.
Private user information will be not be released in
identifiable form outside the XYZ-CERT, except as provided
for below. If the identity of the user is disguised, then
the information can be released freely (for example to show
a sample .cshrc file as modified by an intruder, or to
demonstrate a particular social engineering attack).
- Intruder information is similar to private user
information, but concerns intruders.
While intruder information, and in particular identifying
information, will not be released to the public (unless it
becomes a matter of public record, for example because
criminal charges have been laid), it will be exchanged
freely with system administrators and SIRTs tracking an
incident.
- Private site information is technical information about
particular systems or sites.
It will not be released without the permission of the site
in question, except as provided for below.
- Vulnerability information is technical information about
vulnerabilities or attacks, including fixes and
workarounds.
Vulnerability information will be released freely, though
every effort will be made to inform the relevant vendor
before the general public is informed.
- Embarrassing information includes the statement that an
incident has occurred, and information about its extent or
severity. Embarrassing information may concern a site or
a particular user or group of users.
Embarrassing information will not be released without the
permission of the site or users in question, except as
provided for below.
- Statistical information is embarrassing information with
the identifying information stripped off.
Statistical information will be released at the discretion
of the Computing Services Department.
- Contact information explains how to reach system
administrators and SIRTs.
Contact information will be released freely, except where
the contact person or entity has requested that this not
be the case, or where XYZ-CERT has reason to believe that
the dissemination of this information would not be
appreciated.
Potential recipients of information from the XYZ-CERT will be
classified as follows:
- Because of the nature of their responsibilities and
consequent expectations of confidentiality, members of
Computing Services management and members of XYZ University
upper management are entitled to receive whatever information
they request concerning computer security incidents. In
effect, they will be treated as though they were members of
XYZ-CERT, except that XYZ-CERT will not routinely send them
information, but will do so only upon request, or if it is
required to justify a request for intervention.
- Members of the Office of Rights and Responsibilities and
members of the Senate's Computer Resources Committee are
entitled to receive whatever information they request
concerning a computer security incident or related matter
which has been referred to them for resolution. The same is
true for the XYZ Security Department, when its assistance in
an investigation has been enlisted, or when the investigation
has been instigated at its request.
- System administrators at XYZ University who are members of
the CCSA are also, by virtue of their responsibilities,
trusted with confidential information. However, unless such
people are also members of XYZ-CERT, they will be given only
that confidential information which they must have in order
to assist with an investigation, or in order to secure their
own systems.
- Users at XYZ University are entitled to information which
pertains to the security of their own computer accounts,
even if this means revealing "intruder information", or
"embarrasssing information" about another user. For
example, if account aaaa is cracked and the intruder attacks
account bbbb, user bbbb is entitled to know that aaaa was
cracked, and how the attack on the bbbb account was
executed. User bbbb is also entitled, if she or he requests
it, to information about account aaaa which might enable
bbbb to investigate the attack. For example, if bbbb was
attacked by someone remotely connected to aaaa, bbbb should
be told the provenance of the connections to aaaa, even
though this information would ordinarily be considered
private to aaaa. Users at XYZ University are entitled to be
notified if their account is believed to have been
compromised.
- The XYZ University community will receive no restricted
information, except where the affected parties have given
permission for the information to be disseminated.
Statistical information may be made available to the general
XYZ community. There is no obligation on the part of the
XYZ-CERT to report incidents to the community, though it may
choose to do so; in particular, it is likely that the
XYZ-CERT will inform all affected parties of the ways in
which they were affected, or will encourage the affected site
to do so.
- The public at large will receive no restricted information.
In fact, no particular effort will be made to communicate
with the public at large, though the XYZ-CERT recognizes
that, for all intents and purposes, information made
available to the XYZ University community is in effect made
available to the community at large, and will tailor the
information in consequence.
- The computer security community will be treated the same way
the general public is treated. While members of XYZ-CERT may
participate in discussions within the computer security
community, such as newsgroups, mailing lists (including the
full-disclosure list "bugtraq"), and conferences, they will
treat such forums as though they were the public at large.
While technical issues (including vulnerabilities) may be
discussed to any level of detail, any examples taken from
XYZ-CERT experience will be disguised to avoid identifying
the affected parties.
- The press will also be considered as part of the general
public. The XYZ-CERT will not interact directly with the
Press concerning computer security incidents, except to point
them toward information already released to the general
public. If necessary, information will be provided to the
XYZ University Public Relations Department, and to the
Customer Relations group of the Computing Services
Department. All incident-related queries will be referred to
these two bodies. The above does not affect the ability of
members of XYZ-CERT to grant interviews on general computer
security topics; in fact, they are encouraged to do to, as a
public service to the community.
- Other sites and SIRTs, when they are partners in the
investigation of a computer security incident, will in some
cases be trusted with confidential information. This will
happen only if the foreign site's bona fide can be verified,
and the information transmitted will be limited to that which
is likely to be helpful in resolving the incident. Such
information sharing is most likely to happen in the case of
sites well known to XYZ-CERT (for example, several other
Quebec universities have informal but well-established
working relationships with XYZ University in such mattters).
For the purposes of resolving a security incident, otherwise
semi-private but relatively harmless user information such as
the provenance of connections to user accounts will not be
considered highly sensitive, and can be transmitted to a
foreign site without excessive precautions. "Intruder
information" will be transmitted freely to other system
administrators and SIRTs. "Embarrassing information" can be
transmitted when there is reasonable assurance that it will
remain confidential, and when it is necessary to resolve an
incident.
- Vendors will be considered as foreign SIRTs for most intents
and purposes. The XYZ-CERT wishes to encourage vendors of
all kinds of networking and computer equipment, software, and
services to improve the security of their products. In aid
of this, a vulnerability discovered in such a product will be
reported to its vendor, along with all technical details
needed to identify and fix the problem. Identifying details
will not be given to the vendor without the permission of the
affected parties.
- Law enforcement officers will receive full cooperation from
the XYZ-CERT, including any information they require to
pursue an investigation, in accordance with the Policy on
Computing Facilities.
4.4 Communication and Authentication
In view of the types of information that the XYZ-CERT will
likely be dealing with, telephones will be considered
sufficiently secure to be used even unencrypted. Unencrypted
e-mail will not be considered particularly secure, but will be
sufficient for the transmission of low-sensitivity data. If
it is necessary to send highly sensitive data by e-mail, PGP
will be used. Network file transfers will be considered to
be similar to e-mail for these purposes: sensitive data should
be encrypted for transmission.
Where it is necessary to establish trust, for example before
relying on information given to the XYZ-CERT, or before
disclosing confidential information, the identity and bona
fide of the other party will be ascertained to a reasonable
degree of trust. Within XYZ University, and with known
neighbor sites, referrals from known trusted people will
suffice to identify someone. Otherwise, appropriate methods
will be used, such as a search of FIRST members, the use of
WHOIS and other Internet registration information, etc, along
with telephone call-back or e-mail mail-back to ensure that
the party is not an impostor. Incoming e-mail whose data must
be trusted will be checked with the originator personally, or
by means of digital signatures (PGP in particular is
supported).
4.5 Points of Customer Contact
The preferred method for contacting the XYZ-CERT will be via
e-mail at <xyz-cert@xyz-univ.ca>; e-mail sent to this address
will "biff" the responsible human, or be automatically forwarded
to the appropriate backup person, immediately. If you require
urgent assistance, put "urgent" in your subject line.
If it is not possible (or not advisable for security reasons)
to use e-mail, the XYZ-CERT can be reached by telephone during
regular office hours. Telephone messages are checked less
often than e-mail.
The XYZ-CERT's hours of operation are generally restricted to
regular business hours (09:00-17:00 Monday to Friday except
holidays), though we will sometimes track an incident in
progress outside those hours, if staff availability permits it.
We also sometimes check our mail outside office hours, so if
you have something to report, don't delay it until the start
of office hours on the assumption that no one will see your
report until then -- this is not necessarily true.
If possible, when submitting your report, use the form
mentioned in section 6.
5. Services
5.1 Incident Response
XYZ-CERT will assist system administrators in handling the
technical and organizational aspects of incidents. In
particular, it will provide assistance or advice with respect
to the following aspects of incident management:
- Determining the extent of the incident.
- Determining the initial cause of the incident
(vulnerability exploited).
- Facilitating contact with other sites which may be
involved.
- Removing the vulnerability.
- Securing the system from the effects of the incident.
- Evaluating whether certain actions are likely to reap
results in proportion to their cost and risk, in particular
those actions aimed at an eventual prosecution or
disciplinary action: collection of evidence after the
fact, observation of an incident in progress, setting
traps for intruders, etc.
- Collecting evidence where criminal prosecution, or
University disciplinary action, is contemplated.
- Facilitating contact with XYZ University Security and/or
appropriate law enforcement officials, if necessary.
- Making reports to other SIRTs.
- Composing announcements to users, if applicable.
In addition, XYZ-CERT will collect statistics concerning
incidents which occur within or involve the XYZ University
community, and will notify the community as necessary to
assist it in protecting against known attacks.
To make use of XYZ-CERT's incident response services, please
send e-mail as per section 4.5 above. Please remember that
the amount of assistance available will vary according to
the parameters described in section 4.1.
5.2 Proactive Activities
The XYZ-CERT coordinates and maintains the following
services to the extent possible depending on its resources:
- Information services
- List of departmental security contacts, administrative
and technical. These lists will be available to the
general public, via commonly-available channels such as
the World Wide Web and/or the Domain Name Service.
- Mailing lists to inform security contacts of new
information relevant to their computing environments.
These lists will be available only to XYZ University
system administrators.
- Repository of vendor-provided and other security-related
patches for various operating systems. This repository
will be available to the general public wherever
license restrictions allow it, and will be provided via
commonly-available channels such as the World Wide Web
and/or ftp.
- Repository of security tools and documentation for
use by sysadmins. Where possible, precompiled
ready-to-install versions will be supplied. These will
be supplied to the general public via www or ftp as
above.
- "Clipping" service for various existing resources, such
as major mailing lists and newsgroups. The resulting
clippings will be made available either on the
restricted mailing list or on the web site, depending
on their sensitivity and urgency.
- Training services
- Members of the XYZ-CERT will give periodic seminars on
computer security related topics; these seminars will
be open to XYZ University system administrators.
- Auditing services
- Central file integrity checking service for Unix
machines, and for any other platforms capable of
running "tripwire".
- Security level assignments; machines and subnetworks
at XYZ University will be audited and assigned a security
level. This security level information will be available
to the XYZ University community, to facilitate the
setting of appropriate access privileges. However,
details of the security analyses will be confidential,
and available only to the concerned parties.
- Archiving services
- Central logging service for machines capable of
Unix-style remote logging. Incoming log entries will
be watched by an automated log analysis program, and
events or trends indicative of a potential security
problem will be reported to the affected system
administrators.
- Records of security incidents handled will be kept.
While the records will remain confidential, periodic
statistical reports will be made available to the XYZ
University community.
Detailed descriptions of the above services, along with
instructions for joining mailing lists, downloading
information, or participating in certain services such as the
central logging and file integrity checking services, are
available on the XYZ-CERT web site, as per section 1.10
(POSSIBLY 2.10) above.
6. Incident Reporting Forms
There are no local forms developed yet for reporting incidents
to XYZ-CERT. If possible, please make us of the Incident
Reporting Form of the CERT Coordination Center (Pittsburgh, PA).
The actual version is available from:
ftp://info.cert.org/incident_reporting_form
7. Disclaimers
While every precaution will be taken in the preparation of
information, notifications and alerts, XYZ-CERT assumes no
responsibility for errors or omissions, or for damages
resulting from the use of the information contained within.