CSIRTs and CERTs
2. CERT/CSIRT teams
2.3. How a CERT/CSIRT team is formed
An organisation that decides to set up a CERT/CSIRT team must initially define clearly and comprehensibly what it wants to achieve by creating the team, what role it requires from the team (i.e. it specifies its scope, powers, responsibilities and services operated) and must also secure it in an appropriate way in the organisation.
Scope of activity
The scope of activity is usually the area of cyberspace in which the team is qualified to act and over which it has the relevant powers and responsibilities defined by the founder. Based on the declared scope of activity, the team is then contacted, for example, by those attacked, and addresses problems in the sphere of their influence. The scope of a team’s activity can be defined as a specific network(s), autonomous system(s), name domain(s), but there are also teams that list their expertise, specific service, etc. as the scope of activity.
Services
In order for a team to be officially called a CERT/CSIRT, it needs to primarily offer a security incident resolution or coordination service within its defined scope, thus fulfilling the “response” idea used in CERT/CSIRT acronyms, i.e. this team needs to be able to respond to a security incident. However, the team can offer a number of other services from many areas, such as training, warning of current attacks, OS vulnerabilities, security audits, SW consultations, recommendations of basic security rules, development and operation of tools for monitoring network and service traffic and much more.
Team members
The area that has a decisive influence on the quality of the team is its staffing. In each network operated, there is usually a department or group of technicians who are in charge of the operation and development of the network and services and also deal with security aspects (generally “IT staff”, “security staff”, “administrators”, etc.). These are usually the right people to join a CERT/CSIRT team or to be assigned to build it. However, it is advisable to have other types of experts in the team (such as a lawyer, or, in the case of national and government teams, a media liaison officer, a manager, a sociologist, etc. can be useful). It depends on the focus, environment, services offered and the role of the team.
From an “external” point of view, a team becomes a CERT/CSIRT team when it is accepted as such by other existing global CERT/CSIRT teams. The path to obtaining CERT/CSIRT team status is not complicated, at the beginning it is enough to clearly declare the following:
1. Basic contact information – name of the team, name of the organisation running the team, e-mail address(es) of the team where security incidents can be reported or the team can be contacted, telephone number(s) of the team, address of the headquarters, names of team members, working hours for which the team can be reached, etc.
2. Scope of activity of the team – defines what the team is responsible for and what its role is. This, of course, depends on what team it is. It is possible to set up teams of roughly the following types:
· internal – it serves and is responsible for a specific network (e.g. for a specific range of IP addresses, domains), usually set up by the network operator,
· coordinating – a team whose main task is to coordinate the resolution of security incidents, it does not have to address them in a targeted manner,
· vendor – a team dealing with the resolution of security incidents that affect a specific product (SW),
· national, governmental – special cases based on the principles of the first two mentioned teams (internal and coordination), their scope and role depend on the founder and often also on the legislation of a particular country.
3. Services offered – the CERT/CSIRT team must provide at least a security incident resolution service.
Once a newly established CSIRT/CERT team has dealt with the above steps and established a basic team policy for dealing with security incidents, which includes incident severity classification, incident response rules, contactability of team members, rules for communication with the author of the security incident report, etc., it is well on its way to being accepted by the adjacent teams. A natural and necessary part is the need to get acquainted with the basic rules agreed by the CSIRT community and to follow them.
At the very beginning of creating a team of the CERT/CSIRT type is also the creation of its technical and organisational background, without which no team can function effectively.
Technical background means, for example, a tool for effective management of security incident reports, which allows monitoring of its entire life cycle, i.e. when the report was sent, by whom, at what stages of the incident, why, how it proceeded, who asked whom to cooperate, how serious the incident was and what escalation procedures were applied to it, etc. For this area, teams usually use various so-called ticketing systems, e.g. RTIR[1], OTRS[2]. Other important aids in the field of technical tools are various IDS (Intrusion Detection System), systems for security audits of networks and equipment, systems for forensic analysis, network traffic monitoring (netflow), etc.
The organisational background represents precisely the mentioned “readiness” for the problem, i.e. defining the basic rules for the operation of the team so that each team member knows his/her role, duties and responsibilities, the policy of security incident resolution, rules for communication, information sharing and exchange, cooperation, etc. The basis in this area is generally well-managed incident management.
At the moment when the newly forming team manages the above, i.e. it is able to describe itself and its activities and carry them out. It can participate in cooperation at the national and international level.
[1] RTIR – Request Tracker for Incident Response. For more details, see e.g.: http://www.bestpractical.com/rtir/.
[2] OTRS – Open Source Ticket Request System. For more details, see e.g.: http://www.otrs.org/.