Version: 0.92 Date: Wed, 13 Mar 2019 16:00:22 +0100 Author: Robert Waldner <firstname.lastname@example.org>
1. Document informationThis document contains a description of CERT.at according to RFC 2350. It provides basic information about the CERT, the ways it can be contacted, describes its responsibilities and the services offered.
1.1 Date of last updateWed, 13 Mar 2019 16:00:22 +0100
1.2 Distribution list for notificationsThere is no distribution list for notifications as of 2017/11.
1.3 Locations where this document may be foundThe current version of this document can always be found at https://www.cert.at/about/rfc2350/rfc2350.html . For validation purposes, a GPG signed ASCII version of this document is located at https://www.cert.at/static/rfc2350.txt. The key used for signing is the CERT.at key as listed under 2.8.
2. Contact information
2.1 Name of the teamCERT.at
Computer Emergency Response Team Austria
CERT.at nic.at GmbH Karlsplatz 1/9 1010 Vienna Austria
2.3 Time zoneWe are located in the central European timezone (CET) which is GMT+0100 (+0200 during day-light saving time).
2.4 Telephone number+43 1 5056416 78
2.5 Facsimile number+43 1 5056416 79
2.6 Other telecommunicationNone.
2.7 Electronic mail addressPlease send incident reports to email@example.com. Non-incident related mail should be addressed to firstname.lastname@example.org.
2.8 Public keys and encryption informationCERT.at uses a master signing key to sign all keys used for operational purposes. This trust anchor is:
pub rsa4096 2019-02-25 [SC] [expires: 2034-02-21] 8555 0D8D 5236 BBF1 6A49 0DEB D57E 00EA 0070 9A3D uid CERT.at master key <email@example.com> sub rsa4096 2019-02-25 [E] [expires: 2034-02-21]and can be found on most key-servers. Please DO NOT use this key for communications with us. All official communication by CERT.at will be signed by the current team key, which is as of Mar. 13th 2019:
pub rsa4096 2019-02-25 [SC] [expires: 2024-02-24] 0381BEF56694B5325BF04DDCA1DAC3EDFF4DFFB7 uid CERT.at (Incidents) <firstname.lastname@example.org> uid CERT.at (General Communications) <email@example.com> sub rsa4096 2019-02-25 [E] [expires: 2024-02-24]Encrypted communications with CERT.at should use this - and only this - operational key. All keys (including the keys of individual team members) can be found at https://cert.at/static/pgpkeys.asc. Since the team key and the master signing key expire regularly, CERT.at will always sign younger master signing keys with the older master signing keys as well. The current master signing key always signs the team key. See also the key transition document at https://www.cert.at/static/key-transition-2019.txt.
2.9 Team membersThe team leader of CERT.at is Otmar Lendl. Other team members are listed in the "About Us" / Team page on our webpage. Management, liaison and supervision are provided by Robert Schischka, Technical Manager of nic.at.
2.10 Other information-
2.11 Points of customer contactThe preferred method for contacting CERT.at is via e-mail. For incident reports and related issues please use firstname.lastname@example.org. This will create a ticket in our tracking system and alert the human on duty. For general inquiries please send e-mail to email@example.com. If it is not possible (or advisable due to security reasons) to use e-mail, you can reach us via telephone at +43 1 5056416 78. CERT.at's hours of operation are generally restricted to local regular business hours: Mon-Fri, 8 a.m. - 6 p.m. CET/CEST.
3.1 Mission statementThe purpose of CERT.at is to coordinate security efforts and incident response for IT-security problems on a national level in Austria.
3.2 ConstituencyThe constituency of CERT.at is basically the whole country of Austria. CERT.at will first try to coordinate with IT-security teams and more specific CERTs in Austria. Note that usually no direct support will be given to end users; they are expected to contact their ISP, system administrator, network administrator, or department head for assistance. CERT.at will support the latter. Pro-active and educational material are provided for the general public.
3.3 Sponsorship and/or affiliationCERT.at is an initiative of nic.at, the Austrian domain registry and the Austrian Federal Chancellery. Funding is provided by nic.at GmbH, https://www.nic.at/
3.4 AuthorityThe main purpose of CERT.at in incident handling is the coordination of incident response. As such, we can only advise our constituency and have no authority to demand certain actions. We have indirect authority over AS30971 and AS1921 and are in very close contact with the Austrian CERT Verbund (union of CERTs) and the Austrian Trust Circle (ATC).
4.1 Types of incidents and level of supportCERT.at is authorised to address all types of computer security incidents which occur, or threaten to occur, in our constituency (see 3.2) and which require cross-organisational coordination. The level of support given by CERT.at 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 our resources at the time. Special attention will be give to issues affecting critical infrastructure. CERT.at is committed to keeping its constituency informed of potential vulnerabilities, and, where possible, will inform this community of such vulnerabilities before they are actively exploited.
4.2 Co-operation, interaction and disclosure of informationCERT.at will cooperate with other organisations in the field of computer security. This cooperation also includes and often requires the exchange of vital information regarding security incidents and vulnerabilities. Nevertheless CERT.at will protect the privacy of reporters, partners and our constituents, and therefore (under normal circumstances) pass on information in an anonymised way only unless other contractual agreements apply. CERT.at operates under the restrictions imposed by Austrian law. This involves careful handling of personal data as required by Austrian Data Protection law, but it is also possible that - according to Austrian law - CERT.at may be forced to disclose information due to a court order. CERT.at treats all submitted information as confidential per default, and will only forward it to concerned parties in order to resolve specific incidents when consent is implicit or expressly given. For example: incoming report "Malware on www.example.com/malware, please get it cleaned up". In this case, we would forward the information only to the concerned parties (domain-holder, hoster/ISP) to help them quickly fix the problem. Especially we will not forward information about incidents to government authorities or the press without explicit prior permission by the submitting party.
4.3 Communication and authenticationFor normal communication not containing sensitive information CERT.at might use conventional methods like unencrypted e-mail or fax. For secure communication PGP-encrypted e-mail or telephone will be used. If it is necessary to authenticate a person before communicating, this can be done either through existing webs of trust (e.g. FIRST, TI, ) or by other methods like call-back, mail-back or even face-to-face meeting if necessary.
5.1 Incident responseCERT.at will assist IT-security teams 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:
5.1.1. Incident triage
- determining whether an incident is authentic
- assessing and prioritizing the incident
5.1.2. Incident coordination
- determine the involved organizations
- contact the involved organizations to investigate the incident and take the appropriate steps
- facilitate contact to other parties which can help resolve the incident
- send reports to other CERTs
Auto-generated reports and data-feeds will be handled as automatically as possible.
5.1.3. Incident resolution
- advise local security teams on appropriate actions
- follow up on the progress of the concerned local security teams
- ask for reports
- report back
5.2 Proactive activitiesCERT.at tries to
- raise security awareness in its constituency
- collect contact information of local security teams
- publish announcements concerning serious security threats
- observe current trends in technology
- distribute relevant knowledge to the constituency
- provide fora for community building and information exchange within the constituency