Deutsch | English
This blog does not contain official statements of CERT.at, only personal opinions of the individual contributors.
"National CERT" vs. "National CSIRTs"
2018/07/31

The NIS Directive built upon previous work in the space of network and information security and also tried to use the established language of the field. This worked - up to a point. I'm trying to summarize the differences and pitfalls regarding the term "national CSIRT".

"CERT" vs. "CSIRT"

Initially, a team that took care of computer and network security incidents was called a "CERT", a "Computer Emergency Response Team". That term got trademarked by Carnegie Mellon University and they give licenses to all legit teams who want to use that word.

To get around the trademark issue, the term "CSIRT - Computer Security Incident Response Team" was introduced. In the European academic and research network community, the task force dealing with this topic is thus called "TF-CSIRT".

Both terms used to mean the same thing.

CERT/CSIRT Designation/Accreditation

There is no one-fits-all answer to the question "What is the criteria according to which a security team can call itself a real CERT/CSIRT? ". Here are some indicators:

  1. The right to use the CERT trademark (granted by CMU/CERT-CC)
  2. Membership in FIRST (the global association of CSIRTs)
  3. Registration/Accreditation/Certification in the Trusted Introducer Directory
  4. Formal designation as CSIRT by a national authority according to the national implementation of the NIS-D (Article 9)
  5. Listed on the ENISA CSIRT map
  6. Membership in the CSIRTs Network
  7. Membership in regional CERT associations (e.g. German CERT-Verbund, EGC)
  8. Reputation as a valuable peer built over years of collaboration with other CSIRTs

There is, regrettably, a huge potential for misunderstanding here. Not every CSIRT fulfills point 4 from this list, but in some contexts it might be somehow implied. Perhaps it would be best if we introduce a term like "NIS-CSIRT" for such teams.

"CERT/CSIRT Taxonomy"

CERTs vary a lot: they range from small teams protecting a single company up to being a section of a large "NCSC - national cyber security center". There have been some steps to create a taxonomy of CERTs: a systematic way to describe teams. I have not seen a fully-fledged document about this, but one could start by answering the following questions:

  1. Protect what?
    • Computer Infrastructure: - CSIRT
    • Product Security: - PSIRT
  2. Relation to Constituency?
    • Part of same organization: e.g. siemens-cert
    • CSIRT services are part of some other contract: NREN-CERTs, ISP abuse teams, some GovCERTs, financed by chamber of commerce (or similar) ...
    • Outsourced/Contracted CSIRT service
    • No contractual relationship: national CERTs
    • (Maybe even CSIRT/Constituency relation defined by law)
  3. Definition of the Constituency?
    • Geographic boundary: city, state, country, region, global
    • Specific sector: government, military, academics, sectors of the critical infrastructure or operators of essential services, ...
    • Specific Company: e.g. Siemens AG
  4. Role of the CSIRT?
    • Advisory role only
    • Reporting requirements exist
    • CSIRT can order countermeasures

An overview of teams active in Europe can be found in

"National CERT"

One special type of CERT/CSIRT has always been the "national CERT". As I see it, the national CERT of a country is the team that has the broadest remit: it is supposed to take care of the whole country. That is, of course, not possible in the same way that a company CERT can take care of the infrastructure of the company. Thus, for a national CERT usually the following points apply:

  • Principle of Subsidiarity: If there is another CERT more closely associated with the affected system, then that team will take care of the incident. A national CERT is the "default" or "fallback" CERT.
  • The "national CERT" will act as information hub: both inside the country as well as a point of contact for the country for foreign CERTs.
  • Its role is usually rather hands-off: it will provide guidance, publish warnings, incident notification and will not generally provide on-site remediation help.

CERT-CC organizes a yearly meeting of such national CSIRTs (usually the weekend after the FIRST Conference). It defines a "National CSIRT" as:

A computer emergency response team (CSIRT) with National Responsibility (or "National CSIRT") is a CSIRT that is designated by a country or economy to have specific responsibilities in cyber protection for the country or economy. A National CSIRT can be inside or outside of government, but must be specifically recognized by the government as having responsibility in the country or economy.

The CERT-CC webpage also lists such teams.

ENISA wrote in the 2009 document "Baseline capabilities for national / governmental CERTs"

National CERT Informal definition: a CERT that acts as national point of contact (PoC) for information sharing (like incident reports, vulnerability information and other) with other national CERTs in the EU Member States and worldwide. National CERTs can be considered as "CERT of last resort", which is just another definition of a unique national PoC with a coordinating role. In a lot of cases a national CERT also acts as governmental CERT. Definitions may vary across the EU Member States!

There is usually just one CERT per country that claims the role of the "national CERT", but this is not set in stone. For example, SWITCH-CERT and GovCERT.ch share this role for Switzerland.

CSIRTs according to the NIS Directive

Early drafts of the directive used the term "CERT", the authors switched to "CSIRT" to avoid the trademark issue.

Here are some of the relevant quotes from the NIS-D:

Recital (34)

[...] In order for all types of operators of essential services and digital service providers to benefit from such capabilities and cooperation, Member States should ensure that all types are covered by a designated CSIRT. Given the importance of international cooperation on cybersecurity, CSIRTs should be able to participate in international cooperation networks in addition to the CSIRTs network established by this Directive.

Article 9

1.Each Member State shall designate one or more CSIRTs which shall comply with the requirements set out in point (1) of Annex I, covering at least the sectors referred to in Annex II and the services referred to in Annex III, responsible for risk and incident handling in accordance with a well-defined process. A CSIRT may be established within a competent authority.

[...]

4.Member States shall inform the Commission about the remit, as well as the main elements of the incident- handling process, of their CSIRTs.

5.Member States may request the assistance of ENISA in developing national CSIRTs.

To summarize: There are a number of relevant industries (Operators of Essential Services [OES] + Digital Service Providers [DSP]) that a group of CSIRTs in each Member State collectively need to cover. There can be a single CSIRTs covering all, or the responsibility can be split over multiple CSIRTs. The only requirement from the NIS-D is that every identified OES/DSP must have a CSIRT (which is qualified according to Annex I) assigned to it.

The term "national CSIRT" appears here for the first time in the whole directive. I've talked to the Austrian team that was involved in the negotiations of the directive, and I asked them if the text is referencing the concept of the "National CERT" as described above. The clear answer I got is "no, this is just shorthand for a designated (according to Art 9 1.) CSIRT in a Member States".

There are two clear indications that this is the correct interpretation:

  • There is no definition of a "national CSIRT" in the NIS-D, nor a reference to an external definition.
  • The NIS-D is exclusively concerned about the critical infrastructure (OES+DSP), it does not cover the security of the rest of a country: other industries, small and medium enterprises, or private citizens. Those are covered by the old definition of a "national CERT's constituency".

Another data-point here are the FAQs to the Connecting Europe Facilities Call "CEF TELECOM - 2018-3", when discussing the interpretation of "national CSIRTs". See e.g. the answer to question 17:

Yes, it is possible for CSIRTs that cover a specific sector or service to be funded under this call, if they have been designated by a Member State as a CSIRT pursuant to Article 9 of the NIS Directive.

Or the answer to question 18:

A CSIRT is considered eligible in the sense of the call if it has been designated by a Member State as a CSIRT pursuant to Article 9 of the NIS Directive.

The CSIRTs Network

The NIS Directive also establishes a network of CSIRTs:

Article 12:

1.In order to contribute to the development of confidence and trust between the Member States and to promote swift and effective operational cooperation, a network of the national CSIRTs is hereby established.

2.The CSIRTs network shall be composed of representatives of the Member States' CSIRTs and CERT-EU. The Commission shall participate in the CSIRTs network as an observer. ENISA shall provide the secretariat and shall actively support the cooperation among the CSIRTs.

If we take the definition "national CSIRTs" as "NIS CSIRTs in the Member States" then the two paragraphs fit together nicely:

  • Each Member State creates or appoints one or more CSIRTs that cover the NIS constituency (OES + DSP)
  • All of these CSIRTs are members of the CSIRTs Network

If we take the "national CSIRTs" in 1. to mean the special role of the "National CERT", then paragraph 2. is inconsistent, as it talks about the Member States' CSIRTs, and not just the one special national CSIRT.

Summary

The language of the NIS Directive regarding "national CSIRTs" does not reflect the meaning of the term as it was used in the years prior to the NIS Directive and how it is still being used outside the NIS context.

In the context of the NIS Directive, "national CSIRT" needs to read as shorthand for "CSIRT in a Member State that has been designated under the national transposition of the NIS-D's Article 9".


This blog post is part of a series of blog posts related to our CEF-Telcom-2016-3 project, which also supports our participation in the CSIRTs Network.

Author: Otmar Lendl

Mac OS X tip: how to protect your mail client
2018/05/14

Based on some background knowledge that we received (update 2018/5/14 14:00 UTC+1: we now know it's the efail.de bug. The researchers went forward with the public release today), I am taking the liberty to document a setup which protects an Apple Mail installation that I have.

The security measure is simple: disable remote content on Apple Mail. Go to Preferences -> General and uncheck the checkbox "Load Remote content in messages".

However, there is an even stricter mechanism which does not rely on Apple Mail directly. Think of it as a second, very secure safety net. The idea: should any software component get hacked in my Apple Mail or should it leak information (such as encrypted Mail content), I want to make sure that my Apple Mail talks to one and only one single point of enforcement: the IMAP server it should talk to. And nothing else. Therefore, data exfiltration gets much harder.

Luckily there is a good tool for this: Little Snitch (and as far as I know, this is the only tool of its kind on OS X). With Little Snitch, which acts as an outgoing firewall, I am able to protect and filter the communication flows.

My Little Snitch setup only allows port 25 (SMTP) as well as IMAPs (port 993) connection for Apple Mail. HTTP(s) connects are definitely forbidden. That means that , yes, I won't see all images which reside on some web server. But in practice this does not matter. Either such a mail was spam / marketing in the first place or it was legit and is also visible via a browser if really needed (remember those "can't see this in your mail client? click here..." links in mails?).

In other words: this is a super simple trick to get rid of a whole class of exfiltration attacks. I'd appreciate it if we had such a tool on Linux. Though... hang on... there is an initial attempt by @evilsocket: https://github.com/evilsocket/opensnitch. Haven't tested that yet. Eager to hear some feedback from you if it works on Linux.

Anyway, thanks to Little Snitch (and maybe opensnitch), mail client hacking data exfiltration is not a threat anymore.

 

Author: L. Aaron Kaplan

Successful MISP workshop
2018/02/20

Last week, Alexandre and Andras from CIRCL.lu gave a MISP workshop to a packed crowed of ~ 60-70 people in Vienna.

Infosharing FTW!

MISP stands for "Malware Information Sharing Platform". See also misp-project.org. It allows us to synchronise IoCs with those who need the relevant information about attacks against their information systems.

entrance MISP workshop - lots of interest MISP map


This blog post is part of a series of blog posts related to our CEF-Telcom-2016-3 project. en_cef

Author: L. Aaron Kaplan

Heartbleed: (Almost) three years later
2017/01/27

Shodan recently published a report on the state of Heartbleed which was picked up by lots of media outlets.

I took this as an opportunity to have a look at our statistics. Shodan performs its scan based on IP-addresses and makes the results searchable. CERT.at also runs daily scans, but these are based on the list of domains under the Austrian ccTLD .at. We published a first report on these results in the summer of 2014. We're close to the three year mark now, which is a very long time the Internet. So how do our numbers look like in January 2017?

We start by a list of domains under .at and look for web and mail servers as found by MX and A records. For web servers, we use either the domain itself, or www.$domain. This gives the following frame for the rest of the graphs: the roughly 1.5 million domains under .at are served by 200 thousand web servers and 100 thousand mail servers.

2017-01-hb-basics

Looking a the best TLS support these servers offer, we see that both for HTTPS (web) and SMTP (mail) about half of the servers support encrypted connections.

2017-01-hb-tlssupport

As the larger mail-servers are much more likely to support TLS than smaller ones, the percentage of domains who can receive emails over TLS is actually about 90%.

Testing all those servers for the Heartbleed vulnerability gives the following result:

2017-01-hb-ip-status

The vulnerable server barely show on the graph, for both protocols they are about 0.12% of all servers and about 0.22% of all servers offering TLS.

Over time, the numbers have fallen in the usual long-tail drop-off curve. As the domain-list and domain to IP-address mappings are not refreshed daily, these refreshes show up as upward spikes in the graph. This implies that a part of the decline in vulnerable servers was caused by IP and domain churn.

2017-01-hb-ip-timeline

What does this mean for Domains?

It's pointless to graph vulnerable vs. not-vulnerable domains, the bar for vulnerable servers is not visible. In numbers: 1557 domains (0.29% of all TLS-enabled ones) are still vulnerable on HTTPS, and 320 on SMTP (0.05%). Graphing the development yields:

2017-01-hb-domain-timeline

This graph is a rough approximation as the historical domain to IP mappings are not kept in the system. Anyway, something weird is going on. Lets have a closer look with regards to how important single servers are for the overall domain score. For that we'll use a combined graph showing the contributions of each server to the total number as well as the cumulative distribution function showing how many servers you need to fix to achieve x% of the vulnerable domains (Excel calls it the "Pareto Line").

Let's start with the domains:

2017-01-hb-smtp-cdf

The largest mailserver contributes about a third of the vulnerable domains, take the first three and they cover half of the heartbleed-affected Domains. Those are run by a small ISP, a PR/web agency and a private person, respectively.

The same graph for HTTPS looks like this:

2017-01-hb-https-cdf

This is far more concentrated: The first server hosts 809 domains (about half of the total), the second one 480 and third one 11. About 100 server comprise the long tail of vulnerable servers hosting just one .at domain. Checking some of the domains on these servers shows that the first one is run by a local ISP/registrar and is used for domains that are not in use. The second one only serves "this domain is for sale".

Summary: While Shodan still found a good number of vulnerable servers on the Austrian Internet, these are mostly not the servers that host relevant content.

Author: Otmar Lendl

Next >>
Last Change: 2018/8/1 - 17:21:34
Haftungsausschluss / Data Protection & Privacy Policy