The CSIRT methodology

If you have read my blog carefully, the article about the C4ISR Methodology will surely stick in your mind. Many of the military procedures we can take for our plan – to build a functioning SOC / CSIRT / forensics team of course with some changes.

Let’s define the necessary elements:

SOC (according to English Wikipedia, italic: according to my methodology)

A Security Operations Center (SOC) is a central unit that deals with security issues at the organizational and technical levels. An SOC in a building or facility is a central location from which personnel monitor the site using data processing technology. Typically, an SOC is equipped for access control and control of lighting, alarms and vehicle barriers.

An Information Security Operations Center (ISOC) is a dedicated site that monitors, evaluates, and defends enterprise-wide information systems (Web sites, applications, databases, data centers, and servers, networks, desktops, and other endpoints).

The SOC analyzes the events made available by the IT security assets and identifies incidents that need to be processed. In a multi-stage escalation procedure, these are processed by the SOC with the help of best-practices, own knowledge or with the help of a knowledge base and transferred to the appropriate departments for elimination by means of a ticket system. If the SOC does not manage to solve the incident on its own, the SOC hands over the incident to the CSIRT for further analysis and resolution.

 

CSIRT or CERT (according to German Wikipedia, according to my methodology)

A Computer Emergency Response Team (CERT), (German: Computersicherheits-Ereignis- und Reaktionsteam) basically does not differ from a Computer Security Incident Response Team (CSIRT). Both are a group of IT security professionals involved in resolving specific IT security incidents (such as computer security incidents) When new vulnerabilities in certain applications or operating systems, novel virus spreads, PCs sending spam, or targeted attacks become known, they act as coordinators or, more generally, deal with computer security (sometimes industry-specific), provide security vulnerability warnings, and provide solutions. advisories “,” advice “). In addition, some CERTs help to eliminate security risks for specific addressee groups (eg Citizen-CERT). The information flow is usually done via mailing lists. There safety-critical topics are discussed, discussed and current warnings issued.

The CSIRT consists of top-class specialists who analyze, evaluate and then make finely-tuned incidents as well as information and artifacts available to the SOC, the company or other important players.

 

Forensics (according to English Wikipedia, according to my methodology)

Forensic science is the application of science to criminal and civil law, especially on the criminal side during the criminal investigation, as regulated by the legal standards of admissible evidence and criminal proceedings.

Forensic scientists collect, preserve and analyze scientific evidence during an investigation. While some forensic scientists travel to the scene of the crime to collect the evidence themselves, others take a laboratory role and perform analysis on objects brought to them by other people.

In our case, the term forensics refers to digital forensics, which under this umbrella term network, mobile and computer forensics summarizes. That the investigation of data streams in networks, the content of mobile phones and the evaluation of hard disk or memory contents of computers. In a later blog post I will go into the specifics of digital forensics.

 

Finally, to make sure that the terms are not wildly messed up and thus clarity in this article, we agree on the following:

 

• SOC: In our case it is the ISOC described above, but here we only use the term SOC.
• CSIRT / CERT: Here we limit ourselves to CSIRT. A CERT in my methodology is the highest instance that controls all CSIRTs, if there are more than one CSIRT. Why I make this distinction, I explain later.
• Forensics: Refers to computer forensics, mobile forensics, and network forensics (as it covers a wide range).

 

As you can probably already see from the above definitions, the CSIRT is the heart of the IT security department. The SOC is used for fast “mass processing” of events to detect whether it is “noise”, false positives or real incidents. Incidents are handled accordingly, “noise” and false positives are registered and must be kept to a minimum by the specialist department that operates the IT security assets (firewalls, proxies, antivirus, etc.).

While there is some pressure in the SOC to quickly handle events and incidents, the CSIRT is relatively free of pressure (unless an incident has a high urgency or high impact), so that analytical tasks can be performed conscientiously and accurately.

Graphically, a SOC / CSIRT looks like this:

 

Let’s start building the core…..

The CSIRT methodology

This methodology has been developed in practice in the construction and optimization of some SOCs and CSIRTs and using guidelines and recommendations from ENISA (European Union Agency for Network and Information Security) and Carnegie-Mellon University / Software Engineering Institute (CMU-SEI) , as well as being developed for an organization alone, a group of organizations from a division, at national and international level, as it supports top-down communication as well as bottom-up, and also incorporating every level of a cascaded system Lateral information allowed. It is simply universal.

CSIRT services

 

 

Basically, a CSIRT consists of 5 pillars, which represent the basic activities

 

These 5 columns require validated information for their daily work (if it comes from outside) and use this information for the processing of events, e.g. Incident Response, Artifact Handling and Vulnerability Management. That Information needed to process incidents must be validated and weighted, incidents are not always validated, and are often re-weighted based on the CSIRT knowledge or information received.

The methodology provides for 4 bus systems, 3 of which are operational and one bus is used to relay public information.

Service bus

The service bus (knowledge exchange, service bus and ticket system) is the backbone of the organization. Standardized information flows through a ticket system into the columns or is forwarded to the output bus.

Input and output bus

Input and output bus are the ingress and egress points from a variety of sources according to various communication standards and protocols, which must be standardized and made human readable for transport on the service bus, or on the output bus to Transmission to others, be converted into the appropriate communication standard or protocol (otherwise cascading would not be possible). For this the following models are processed:

Personal communication by phone, email and fax.

Communication via ticket system from and into the connected SOC.
Information from ‘trusted sources’ (input bus only), the output bus provides information as ‘trusted source’ to others.

Public Information System

Information from the columns to the Warning / Alert, Editional and Report Publishing Service is processed there (eg white papers, advisories, presentations, reports, statistics, etc.) and published publicly by the Public Information System (Announcement and Public Relation Bus) – according to the target group. This information can / must also be used for the awareness program.

Technical implementation of the methodology

The basic requirement is – if possible – that information is processed confidentially and safely and archived, marked for various weightings (urgency, severity, level of confidentiality which affect the processing), and can be checked for authenticity using checksums.

In addition, the entire infrastructure (hardware, software, protocols, interfaces, etc.) must be built to the requirements of increased security.

The basic framework of the technical implementation of the methodology is based on existing software technologies, which are matched by additional in-house developments, or allow first the exchange of SOC and CSIRT, several CSIRT’s among themselves and CSIRT to CERT. In addition, it is required:

• multi-client capability (information can / may only be made accessible to specific persons or groups)
• Multi-level document classification (public, internal, confidential, secret, top secret)
• Encryption of sensitive information
• Exchange of confidential protocols and mechanisms
• Strong user authentication
• checksum generation and testing
• …

 

Technical requirements

For the CSIRT to work, different technologies are necessary, which I will not describe in detail here, as the article would otherwise be too detailed and slip into the technical.

Asset and Change Management Database

This should already exist in the company and be well maintained. Both SOC and CSIRT need to know what their (hardware / software) is in an incident for their analysis, so that they can inter alia. Urgency, escalation, and recovery, as well as locate the contacts.

Ticket System

For SOC and CSIRT, a common, autonomous ticket system must be set up and administered, which has an interface to the existing ticket system of the company. The rationale lies in the sensitive nature of the data processed by the SOC and CSIRT. Only an instance in an existing ticket system would result in administrators who are not SOC or CSIRT members which could have access to the data and thus the confidentiality would not exist.

Intranet server

This is the platform that can consist of one or more servers (CMS, WiKi or whatever seems to make the most sense). For example, the CMS publishes the awareness program or other important public information regarding IT security in the company. On the wiki, for example are internal SOC and CSIRT documents, shift schedules, etc.

Cyber ​​Threat Intelligence (CTI) search engine

This scans IT security relevant web-pages of manufacturers, feeds, advisories and maybe also the Darknet for information interesting to SOC and CSIRT. Unlike Google, the results are unweighted as they do not follow a commercial principle and relevance is not distorted by paid content.

Knowledge Base

The absolutely necessary common knowledge base consists of the CTI search engine, the asset and CMDB system, ticket system, intranet server (s) and other information, that all makes the knowledge base. This helps tremendously in handling incidents in SOC and CSIRT. Here, for reasons of effectiveness, search masks may have to be programmed, which query all systems in parallel or one after another.

Tools

The CSIRT will use a variety of tools, some self-programmed and commercial programs to do the job. These depend strongly on the preferences CSIRT employees have, the tasks they are assigned to, and which IT security products are used in the company.

Necessary documentation

Both, SOC and CSIRT (and possibly CERT) need a document framework whose most important part is the common dictionary. It may be hard to believe, but without this dictionary, an almost Babylonian jumble of different terms for the same thing will soon take hold.

Of course, the CSIRT documentation is not just a dictionary, but a set of documents that fully describe the CSIRT and how it works and how to do it. This framework was designed according to best practice from the methodology and implemented several times and looks like this:

Of course, the document framework will need to make small changes from company to company, because the framework has to fit the company rather than the other way round, and it still has to be integrated into the company’s disaster planning.

In my next blog entry, I will explain the SOC Methodology, stay tuned !