Date: Wed, 08 Nov 2017 13:42:02 +0100
Author: Robert Waldner <firstname.lastname@example.org>
1. Document information
This 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 update
Wed, 08 Nov 2017 13:42:02 +0100
1.2 Distribution list for notifications
There is no distribution list for notifications as of 2017/11.
1.3 Locations where this document may be found
The current version of this document can always be found at
. 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 team
Computer Emergency Response Team Austria
2.3 Time zone
We 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 telecommunication
2.7 Electronic mail address
Please 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 information
CERT.at uses a master signing key to sign all keys used for operational
purposes. This trust anchor is:
pub 4096R/998C1CC6C2E0E6A7 2014-03-19 [expires: 2019-03-18]
Key fingerprint = FB59 8F2F 6B68 0211 F85D 2A0C 998C 1CC6 C2E0 E6A7
uid CERT.at master key <email@example.com>
sub 4096R/9D1B02A6B0454903 2014-03-19 [expires: 2019-03-18]
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 2014/03:
pub 4096R/8D2F23E111334B61 2014-03-19 [expires: 2019-03-18]
Key fingerprint = AD35 20E5 2CE8 8BA2 50B2 8507 8D2F 23E1 1133 4B61
uid CERT.at (General Communications) <firstname.lastname@example.org>
uid CERT.at (Incidents) <email@example.com>
sub 4096R/CC28457FA810F7AA 2014-03-19 [expires: 2019-03-18]
Encrypted communications with CERT.at should use this - and only this -
All keys (including the keys of individual team members) can be found at
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-2014.txt
2.9 Team members
The 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 contact
The 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 statement
The purpose of CERT.at is to coordinate security efforts and incident response
for IT-security problems on a national level in Austria.
The 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 affiliation
CERT.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/
The 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
4.1 Types of incidents and level of support
CERT.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
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 information
CERT.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
4.3 Communication and authentication
For 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 response
CERT.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
- facilitate contact to other parties which can help resolve the incident
- send reports to other CERTs
We mainly see ourselves as information hub which knows where to send the right
incident reports to in order to help and facilitate the clean-up of IT security
CERT.at will always strive to react to incoming incident reports from humans within
one business day.
Due to current staffing levels this can not be guaranteed, though. If you haven't received
feedback to an incident report after two business days, we ask that you contact us again.
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
CERT.at will also collect statistics about incidents within its constituency.
5.2 Proactive activities
CERT.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
6. Incident reporting forms
There are no local forms available.
While every precaution will be taken in the preparation of information, notifications and
alerts, CERT.at assumes no responsibility for errors or omissions, or for damages resulting
from the use of the information contained within.