Date: Thu, 28 Mar 2024 13:22:56 +0100 (CET) Message-ID: <1639516565.7562.1711628576843@wiki01p.surfnet.nl> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_7561_1361015795.1711628576843" ------=_Part_7561_1361015795.1711628576843 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Below, you will find the SURFcert Service Description, which states= , among other things, the services that SURFcert provides.
Author/Source: Wim Biemolt
Distribution: World
Classification : Unclassified External
Subject : RFC 2350 formatted SURFcert Service Description
Index : R-16-01
Page : 1
Version : 7
Date: 19-09-2023
This is version 7, published 19 September 2023.
Notifications of updates are submitted to our mailing list. Site Securit= y Contacts of SURF customers are automatically added to this list. Subscrip= tion to this list is limited to Site Security Contacts of SURF customers. O= nly SURFcert can post messages to this list.
The current version of this CSIRT description document is available from= the SURFcert wiki site; its URL is https://wiki.sur= fnet.nl/display/SURFcert/Dienstbeschrijving+SURFcert. Please make sure = you are using the latest version.
Currently, no PGP-signed version of this document is available.
"SURFcert": the SURF Computer Emergency Response Team.
Visiting address
SURFcert
Hoog Overborch
Moreelsepark 48
3511 EP Utrecht
the Netherlands
Post address
SURFcert
P.O. Box 19035
3501 DA Utrecht
the Netherlands
UTC+0100 in winter and UTC+0200 in summer (DST). Daylight savings time i= s according to EC rules, central European time.
+31 622923564, outside business hours emergencies only, attended at all = times.
Not available.
None available.
cert [at] surfcert.nl; This is a mail alias that relays mail to all SURF= cert kernel members. There is always one kernel member on duty. This kernel= member handles all incoming mail.
SURFcert uses PGP for encryption and signing. The PGP key can be found o= n the PGP-keyserver: https://keys.openpgp.or= g/search?q=3Dcert@surfcert.nl.
SURFcert consists of 10 members; currently 6 from SURF and 4 for the con= nected institutions:
General information about SURFcert can be found at https://surf.nl/su= rfcert.
The preferred method for contacting SURFcert is via e-mail at ; e-mail s= ent to this address will be acted upon by the officer on duty. Response tim= e for normal priority is within 1 working day.
If it is not possible (or not advisable for security reasons) to use e-m= ail, SURFcert can be reached by telephone during regular office hours.
Normal SURFcert service hours are 09:00 until 17:00 on working days (exc= ept on public holidays). In case of a real emergency SURFcert has a 24/7 at= tended emergency phone number (please check 2.4).
SURFcert operates under a charter. This charter can be found at: R-=C2=AD92-=C2=AD01 Operational Framework SURF cert. D= etails on SURFcert operation can be found in this operational framework.
The primary purpose of SURFcert is to provide a mechanism for institutio= ns within the Netherlands, connected to SURF, to deal with computer securit= y problems and their prevention.
The goals of SURFcert are:
The SURFcert Constituency are those sites that are connected to SURF.
SURF bv will fund the work of SURFcert and will fund the technical provi= sions needed in order to gain and maintain maximum reachability.
SURFcert is affiliated with FIRST (http://www.first.org), the Forum = on Incident Response and Security Teams and maintains affiliations with var= ious other CSIRTs around the world on an as needed basis. SURFcert is also = Trusted Introducer Certified tea= m
SURFcert operates under the auspices of, and with authority delegated by= , the directors of SURF bv.
SURFcert expects to work cooperatively with system administrators, netwo= rkmanagers and users of SURF connected institutions, and, insofar as possib= le, to avoid authoritarian relationships. However, should circumstances war= rant it, SURFcert has the authority to take the measures it deems appropria= te to properly handle a computer security related incident.
SURF connected institutions who wish to appeal the actions of SURFcert s= hould contact the SURFcert chair, Wim Biemolt.
If this recourse is not satisfactory, the matter may be referred to the = SURF director through your SURF account manager.
SURFcert is authorized to address all types of computer security inciden= ts which occur, or threaten to occur, at its constituency (see 3.2). SURFce= rt may act upon request of one of its constituents, or may act if a constit= uent is, or threatens to be, involved in a computer security incident.
The level of support given by SURFcert will vary depending on the type a= nd severity of the incident or issue, the size of the user community affect= ed, and the SURFcert's resources at the time, though in all cases some resp= onse will be made within one working day. Resources will be assigned accord= ing to the following priorities, listed in decreasing order:
Types of incidents other than those mentioned above will be prioritized = according to their apparent severity and extent. These incidents will be as= sessed as to their relative severity at SURFcert's discretion.
SURFcert will, in principle, accept any incident report that involves an= incident with one of the constituents either as a victim or as a suspect. = Henceforth, reports filed by individual end users within the constituency w= ill also be dealt with. However, SURFcert encourages the engagement of qual= ified security staff at the involved organisation in an early stage. Whenev= er feasible, SURFcert will contact the relevant Site Security Contact or th= e Security Entry Point of the organisation alledgedly involved, even if the= end user has chosen not to do so.
While SURFcert understands that there exists great variation in the leve= l of system administrator expertise at its constituency, and while SURFcert= will endeavor to present information and assistance at a level appropriate= to each person, SURFcert shall not train system administrators on the fly,= and it cannot perform system maintenance on their behalf. In most cases, S= URFcert will provide pointers to the information needed to implement approp= riate measures.
SURF, as the organisation under whose sole jurisdiction SURFcert is oper= ating, offers the possibility to the constituency for consultancy projects = on an ad-hoc basis. In security related matters, SURFcert may at its own di= scretion suggest to embark on a consultancy project, which will provide for= more resources where necessary in order to do a full analysis and remedial= of an observed security breach.
While there are legal and ethical restrictions on the flow of informatio= n from SURFcert, all of which may also be outlined in policies at the organ= isations of its constituency, and all of which will be respected, SURFcert = acknowledges its indebtedness to, and declares its intention to contribute = to, the spirit of cooperation that created the Internet. Therefore, while a= ppropriate measures will be taken to protect the identity of members of our= constituency and members of neighbouring sites where necessary, SURFcert w= ill otherwise share information freely when this will assist others in reso= lving or preventing security incidents.
In the paragraphs below, "affected parties" refers to the legitimate own= ers, operators, and users of the relevant computing facilities. It does not= refer to unauthorized users, including otherwise authorized users making u= nauthorized use of a facility; such intruders may have no expectation of co= nfidentiality from SURFcert. They may or may not have legal rights to confi= dentiality; such rights will of course be respected where they exist. SURFc= ert may release information to any third party or to governing authorities = whenever there is a legal obligation to do so. However, SURFcert may in som= e cases delay this action until such a circumstance has been established ir= revocably, e.g. by court order. SURFcert will in such cases always notify t= he affected persons or organisations.
Information being considered for release will be classified as follows:<= /p>
Private site information is technical information about particular s=
ystems or sites.
It will not be released without the permission of the site in question, ex=
cept as provided for below.
Vulnerability information is technical information about vulnerabili=
ties or attacks, including fixes and workarounds.
Vulnerability information will be released freely, though every effort wil=
l be made to inform the relevant vendor before the general public is inform=
ed.
Embarrassing information includes the statement that an incident has=
occurred, and information about its extent or severity. Embarrassing infor=
mation may concern a site or a particular user or group of users.
Embarrassing information will not be released without the permission of th=
e site or users in question, except as provided for below.
Statistical information is embarrassing information with the identif=
ying information stripped off.
Statistical information will be released at the discretion of SURFcert.
Contact information explains how to reach system administrators and = CSIRTs.
Contact information will be released freely, except where the= contact person or entity has requested that this not be the case, or where= SURFcert has reason to believe that the dissemination of this information = would not be appreciated.
Potential recipients of information from SURFcert will be classified as = follows:
Because of the nature of their responsibilities and consequent expec= tations of confidentiality, members of the constituency's management are en= titled to receive whatever information is necessary to facilitate the handl= ing of computer security incidents which occur in their jurisdictions.
<= /li>System administrators at organisations that are members of the const= ituency are also, by virtue of their responsibilities, trusted with confide= ntial information. However, unless such people are also members of SURFcert= , they will be given only that confidential information which they must hav= e in order to assist with an investigation, or in order to secure their own= systems.
Users within the constituency are entitled to information which pert= ains to the security of their own computer accounts, even if this means rev= ealing "intruder information", or "embarrassing information" about another = user. For example, if account aaaa is cracked and the intruder attacks acco= unt 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 the= y request it, to information about account aaaa which might enable bbbb to = investigate the attack. For example, if bbbb was attacked by someone remote= ly connected to aaaa, bbbb should be told the provenance of the connections= to aaaa, even though this information would ordinarily be considered priva= te to aaaa. Users within the constituency are entitled to be notified if th= eir account is believed to have been compromised.
The constituency community will receive no restricted information, e= xcept where the affected parties have given permission for the information = to be disseminated. Statistical information may be made available to the ge= neral community. There is no obligation on the part of SURFcert to report i= ncidents to the community, though it may choose to do so; in particular, it= is likely that SURFcert will inform all affected parties of the ways in wh= ich they were affected, or will encourage the affected site to do so.
= li>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 SURFcert recognizes that, for all intents and purposes, information= made available to its constituency community is in effect made available t= o the community at large, and will tailor the information in consequence.= p>
The computer security community will be treated the same way the gen= eral public is treated. While members of SURFcert may participate in discus= sions within the computer security community, such as newsgroups, mailing l= ists (including the full-disclosure list "bugtraq"), and conferences, they = will treat such forums as though they were the public at large. While techn= ical issues (including vulnerabilities) may be discussed to any level of de= tail, any examples taken from SURFcert experience will be disguised to avoi= d identifying the affected parties.
The press will also be considered as part of the general public. SUR= Fcert will generally not interact directly with the Press concerning comput= er security incidents, except to point them toward information already rele= ased to the general public. However, SURFcert acknowledges the role of the = Press as a vehicle to inform the broad public in general and its own consti= tyency in particular. To properly accomodate this function, the SURF Public= Relations department acts as the focal point in Press contacts. The SURF P= ublic Relations department will call in SURFcert in case a SURFcert stateme= nt is needed. Only SURFcert can make statements on behalf of SURFcert. The = Chief Information Officer and the Chair are responsible for making public s= tatements on behalf of SURFcert. The above does not affect the ability of i= ndividual members of SURFcert to grant interviews on general computer secur= ity topics; in fact, they are encouraged to do so, as a public service to t= he community. Note that all SURFcert members are committed to absolute conf= identiality pertaining specific incidents.
Other sites and CSIRTs, when they are partners in the investigation =
of a computer security incident, will in some cases be trusted with confide=
ntial information. This will happen only if the other 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 SURFcert (for =
example, several other European CSIRTs have informal but well-established w=
orking relationships with SURFcert in such matters).
For the purposes of resolving a security incident, otherwise semi-private =
but relatively harmless user information such as the provenance of connecti=
ons to user accounts will not be considered highly sensitive, and can be tr=
ansmitted to a foreign site without excessive precautions. "Intruder inform=
ation" will be transmitted freely to other system administrators and CSIRTs=
. "Embarrassing information" can be transmitted when there is reasonable as=
surance that it will remain confidential, and when it is necessary to resol=
ve an incident.
In its contact with other CSIRTs, SURFcert will see to it that the informa=
tion which is made available to others, will be signed (so as to provide fo=
r non-repudiation), and, whenever deemed necessary, crypted. See also 4.3 f=
or more details.
Vendors will be considered as foreign CSIRTs for most intents and pu= rposes. SURFcert wishes to encourage vendors of all kinds of networking and= computer equipment, software, and services to improve the security of thei= r products. In aid of this, a vulnerability discovered in such a product wi= ll be reported to its vendor, along with all technical details needed to id= entify and fix the problem. Identifying details will not be given to the ve= ndor without the permission of the affected parties.
Law enforcement officers will receive full cooperation from SURFcert= , including any information they require to pursue an investigation, notwit= hstanding the earlier statements made about confidentiality.
In view of the types of information that SURFcert will likely be dealing= with, telephones will be considered sufficiently secure to be used even un= encrypted. Unencrypted e-mail will not be considered particularly secure, b= ut will be sufficient for the transmission of low-sensitivity data. If it i= s necessary to send highly sensitive data by e-mail, PGP will be used. Netw= ork file transfers will be considered to be similar to e-mail for these pur= poses: sensitive data should be encrypted before transmission.
Where it is necessary to establish trust, for example before relying on = information given to SURFcert, or before disclosing confidential informatio= n, the identity and bona fide of the other party will be ascertained to a r= easonable degree of trust. Within the constituency, and with known neighbou= r sites, referrals from known trusted people will suffice to identify someo= ne. 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 part= y is not an impostor. Incoming e-mail whose data must be trusted will be ch= ecked with the originator personally, or by means of digital signatures (PG= P in particular is supported).
SURFcert keys can be found on https://key= s.openpgp.org/search?q=3Dcert@surfcert.nl.
SURFcert will assist system administrators in handling the technical and= organisational aspects of incidents. In particular, it will provide assist= ance or advice with respect to the following aspects of incident management= :
SURFcert provides no incident resolution services.
SURFcert coordinates and maintains the following services to the extent = possible depending on its resources:
It is no longer supported to submit portscan/probe incidents through spe= cial forms. All incidents can be reported by any of the in previous chapter= s mentioned methods.
While every precaution will be taken in the preparation of information, = notifications and alerts, SURFcert assumes no responsibility for errors or = omissions, or for damages resulting from the use of the information contain= ed within.