CSIRTs and CERTs

The title of this subchapter is also a frequent lament of an Internet user who got into trouble (e.g. someone attacks him/her, stole his/her identity, hacked a Facebook profile or e-mail account, or witnessed the spread of child pornography). What should such a user do? Contact the Police of the Czech Republic? Or the Internet service provider, e.g. their helpdesk? Or contact the National Cyber and Information Security Agency when it is responsible for cybersecurity? The National Safer Internet Center hotline? Or some CSIRT team when they're still being talked about? But which one?

The process of reporting and resolving security incidents (or in other words “who to contact if I want to report or resolve a security incident”) can be viewed from two perspectives. From the perspective of technicians (network and service administrators, members of security teams) and from the perspective of users.

For technicians (network and service administrators, members of security teams), the answer to the question “who to actually contact with a request for action” is quite clear, but this is due to drill, experience and above all a very good knowledge of the Internet environment and its basic principles, as well as knowledge of where contact information for individual existing networks, services, domains, etc. is available.

For members of CERT/CSIRT teams, the basic sources of contact information are the RIR databases, the database of top-level domain operators and the catalogues of CERT/CSIRT teams.

RIR (Regional Internet Registry) holds and makes available information on to whom a block of IP addresses has been assigned. The world is divided into regions and each RIR (currently RIPE, ARIN, APNIC, LACNIC, AFRINIC) assigns IP addresses for its region. The Europe, Middle East and Asia region is administered by RIPE NCC (https://www.ripe.net/). RIRs operate publicly accessible databases that contain data on assigned Internet networks and their administrators. These databases allow you to find information about which organisations and which administrators are responsible for specific IP addresses.

Another source of useful information is data on domains operated and made available by top-level domain administrators; for the TLD domain .cz, it is the CZ.NIC association.

And then there is the area of CERT/CSIRT teams, which usually define their scope using Internet identifiers, name domains, or just verbally. Due to their number, the way they define their scope and especially the differences in their level, it is not always easy to find a team that is able to help. To facilitate orientation between teams, some kinds of “catalogues” have been created, which are taken care of by FIRST and the Trusted Introducer. These catalogues contain basic information about CERT/CSIRTs, contacts, their scope, etc.

The process of reporting and resolving security incidents (incident handling) is not an exact process, on the contrary, and a lot depends on the experience and sometimes the creativity of the person who performs this process. The exchange of information between teams usually takes place quickly and efficiently, although even this often does not guarantee a quick solution to the problem, because the whole infrastructure is still relatively “sparse”, and unfortunately it must be noted that the level of teams is different.

The optimal state of the infrastructure would be if each IP address were within the scope of an official CSIRT team. This is, however, by far not the situation of the infrastructure of CERT/CSIRT.

From the point of view of a normal user, the situation is very unclear and, in fact, confusing. So what should a user do if a security incident is detected and who should they contact? It is difficult for the user to want to orientate himself/herself in the issues of CERT/CSIRT teams, to be able to find the right one, to study its security incident reporting policy and take action. A user should first contact the administrator of his/her network or services (if he/she has someone like that), or he/she should cooperate with the Internet service provider, i.e. his/her ISP's helpdesk or its user support. On the part of the ISP or service provider, there should be a clearly described entry point (contact) which users could and should contact if they become the target of an attack, detect a security incident, or feel that something is not all right. This is why the environment of ISPs is one of the most important areas where an official CERT/CSIRT team should be constituted and provide security services to the users of their network.

Of course, there may be situations where both a technician and a user do everything right, and the solution to the problem is still not in sight. A person or team does not react to the reported problem, or even refuses to address it (saying that it is not their problem, or it is not so serious), etc. This is the moment when either the Police of the Czech Republic comes in (the user can contact it with the filing of a criminal complaint), or a top team comes in (national or government) that the user can contact as the last resort from which help and response can be expected.

There is a very close cooperation and exchange of information and relevant data between the national and government team, and thus the transfer of the reported problem to be addressed from one team to another or directly to the solution.

In general, the national and government team should be a place for network providers, service providers (and, if necessary, users) where, in case of problems, ambiguities, etc., it is possible to ask for help and consultation, e.g. finding a suitable counterpart for communication (foreign CERT/CSIRT team), mediation of communication (yes, sometimes the “leverage” of the top team is useful, the counterpart is then more willing), and a source of know-how and information.

In general, however, it would be desirable for network and service administrators and members of security teams to master and apply the principles of the incident handling process and to maximise communication directly (not through top teams). This makes the incident handling process fast and efficient, and other intermediate stages can introduce unpleasant delays and, unfortunately, distortions. But as already mentioned, it depends on the severity of the situation and the problem being addressed.

CERTs/CSIRTs and their infrastructure are generally not omnipotent and do not ensure security “in a nutshell”.

Their existence is just one of the little blocks in the field of building Internet security, in which all stakeholders play an important role, i.e. network administrators, service managers, managers who decide on the background for effective network and service security, ISPs, critical service operators, security forces, state, and last but not least we, users.

The current list of CSIRT/CERT teams can be found at:

https://www.enisa.europa.eu/topics/csirts-in-europe/csirt-inventory/certs-by-country-interactive-map.