Information security now!
In this fourth part of our series of articles on vulnerabilities, we take a look at the National Cyber Security Centre Finland’s vulnerability coordination through example cases.
The purpose of the NCSC-FI’s vulnerability coordination is to help the discoverers of vulnerabilities and severe software bugs engage in better cooperation with software manufacturers and system integrators. To this end we accept and review reports of vulnerabilities discovered in software and websites, for example. Our goal is to ensure that all relevant parties, including the end users of the affected products, are informed of reported vulnerabilities and the appropriate fixes.
Discovered vulnerabilities must be processed responsibly, as they can have far-reaching negative impacts on personal privacy, assets, the business operations of organisations and even national security. As a vulnerability coordinator, we promote the responsible processing of vulnerability information in all the stages of a vulnerability’s life cycle. For severe vulnerabilities and ones with extensive impacts, we also write vulnerability articles (External link).
In some cases, we are also informed of vulnerabilities in advance, before they are officially made public. In these cases, we assess the general situational picture in Finland in regard to the vulnerability. We share information about vulnerabilities based on their classification (External link).
The following examples are general descriptions of the kinds of vulnerability reports that we receive. You can report vulnerabilities to us using the form available on this page (External link). You can also subscribe to our newsletters and vulnerability digest (External link).
Example 1: A researcher has detected a database vulnerability in an online service
The vulnerability allows an attacker to steal user data from a public service with a simple query, as long as the attacker is in possession of a username and password or able to crack them. The situation is critical because anyone can detect the vulnerability using various scanners and attempt to retrieve data from the database.
However, the researcher does not want to personally report the vulnerability to the service provider, so they report it using the form available on the NCSC-FI’s website instead.
The NCSC-FI deems that the vulnerability is critical and immediately notifies the service provider about it. In urgent situations, a phone call to the person responsible for the service provider’s information security can also help to more effectively convey the severity of the vulnerability and thus improve the service provider’s response speed.
With these kinds of vulnerabilities, we emphasise confidentiality. It is essential to make sure that the party who discovered the vulnerability does not report it to anyone else besides the authorities or the affected organisation.
Example 2: An organisation expresses their need for coordination assistance
A company has discovered or been informed by an external party about a vulnerability in their product. This is the organisation’s first time dealing with an issue like this, so they ask the NCSC-FI’s vulnerability coordination team for assistance.
The first step is to review the situation and discuss what kind of vulnerability we are dealing with and what kind of potential impacts it has. What kinds of services are affected by the vulnerability? Does the case have impacts on society? Is there a need to apply for a CVE (Common Vulnerabilities and Exposures) identifier for the vulnerability at this point? CVE identifiers are issued by the non-profit organisation MITRE. You may also notice CVE identifiers that companies have supplied in the NCSC-FI’s vulnerability bulletins. They help identify vulnerabilities and assign CVSS (Common Vulnerability Scoring System) scores that describe the severity of vulnerabilities. You can try calculating CVSS scores on the website of the American organisation NIST (External link), for example.
Communicating about the vulnerability is an important part of vulnerability coordination. How will the company make the vulnerability public? Is it possible to determine how many copies of the vulnerable product are currently in use? Is there a customer contact list available, or will customers be informed via websites and social media channels, for example? The NCSC-FI can help with these issues in accordance with its normal operating procedures by communicating about the vulnerability on its website, social media and international networks and by informing stakeholders or specific sectors about the vulnerability.
The users of the affected product should be notified of the vulnerability as soon as possible and openly informed of the situation. If you need to discuss the matter confidentially, do not hesitate to contact the NCSC-FI!
Example 3: A researcher reports a vulnerability in a network device
A researcher has procured a new WiFi router. Following some testing, they have discovered multiple vulnerabilities in the router that should be reported to the manufacturer. However, the researcher does not want to report their findings to the manufacturer personally, so they report them to the NCSC-FI instead. This ensures that the vulnerability coordination is carried out by a public authority, who handles the communication between the reporter and the manufacturer as an impartial intermediary. Network device vulnerabilities can also affect large numbers of users, so at this point the discovered vulnerability should be kept between the discoverer, the authority and the manufacturer.
The NCSC-FI reviews the reported vulnerability and then reports it to the manufacturer. Reporting a vulnerability can sometimes be a surprisingly laborious process; vulnerability information should be sent to the company in as secure a manner as possible, and sometimes finding the right contact information can take some time. By taking care of this, the NCSC-FI vulnerability coordination team frees the researcher from having to carry out the coordination and contacting. If necessary, the manufacturer may ask clarifying questions about the reported vulnerability. These include questions about the operating system, versions and hardware used in the testing and the time of testing.
Upon being informed of a vulnerability, most contemporary organisations will state that they will immediately start working on addressing it and, if possible, have it fixed within 30 days, for example.
The reporting of a vulnerability can be complicated by various issues, such as foreign manufacturers whose contact information is difficult to find. In such cases, the NCSC-FI can consult foreign colleagues about the matter and see if they could help with finding the right contact details.
Example 4: Online home automation device
A researcher has discovered home automation devices that should not be connected to the internet. The researcher has reported the issue to the manufacturer, but nothing has been done about it. The researcher thinks that the NCSC-FI could coordinate the matter.
The issue may be that the manufacturer’s default settings for the device are weak, allowing users to sign in using a generic username and password provided in the manual, for example. If this kind of device is connected to the internet, anyone can easily access it. Nowadays all new devices should be protected by a unique username and password by default. Ideally the user should also be forced to change the default password when signing in for the first time.
Home automation and other devices capable of connecting to the internet should be well protected if they actually need to be connected to the internet. We map the number of unprotected automation devices connected to the internet in Finland on an annual basis. Read the results of the mapping carried out in 2020 (External link).
Terminology related to vulnerability coordination statistics
The vulnerabilities reported to the NCSC-FI are often related to the data protection of a website or service. For example, a website may provide easy access to data that should not be visible to everyone, such as personal data or various types of customer data.
Outdated or weak password practices are another common phenomenon. For example, an otherwise secure product may have a hard-coded default password. Various online services can also have room for improvement in regard to password practices, such as the requirements set for passwords or password change features. The NCSC-FI also regularly receives vulnerability reports from information security researchers who test IoT and network devices. Improving the security of IoT and network devices is essential as the numbers of devices used online and at home continues to rise.
The NCSC-FI receives approximately 50 vulnerability coordination cases annually. This figure only includes reports that have required the NCSC-FI to take action. The general categories of vulnerability reports are: ‘for your information,’ ‘request for assistance’ and ‘request for vulnerability coordination.’ Reports are submitted by individual citizens, researchers and organisations. We also accept anonymous reports.