Tag Archive for: it security

Joseph Lee

How CSAF 2.0 Advances Automated Vulnerability Management

IT security teams don’t necessarily need to know what CSAF is, but on the other hand, familiarity with what’s happening “under the hood” of a vulnerability management platform can give context to how next-gen vulnerability management is evolving, and the advantages of automated vulnerability management. In this article, we take an introductory journey through CSAF 2.0, what it is, and how it seeks to benefit enterprise vulnerability management. 

Greenbone AG is an official partner of the German Federal Office for Information Security (BSI) to integrate technologies that leverage the CSAF 2.0 standard for automated cybersecurity advisories.

What is CSAF?

The Common Security Advisory Framework (CSAF) 2.0 is a standardized, machine-readable vulnerability advisory format. CSAF 2.0 enables the upstream cybersecurity intelligence community, including software and hardware vendors, governments, and independent researchers to provide information about vulnerabilities. Downstream, CSAF allows vulnerability information consumers to aggregate security advisories from a decentralized group of providers and automate risk assessment with more reliable information and less resource overhead.

By providing a standardized machine readable format, CSAF represents an evolution towards “next-gen” automated vulnerability management which can reduce the burden on IT security teams facing an ever increasing number of CVE disclosures, and improve risk-based decision making in the face of an “ad-hoc” approach to vulnerability intelligence sharing.

CSAF 2.0 is the replacement for the Common Vulnerability Reporting Framework (CVRF) v1.2 and extends its predecessor’s capabilities to offer greater flexibility.

Here are the key takeaways:

  • CSAF is an international open standard for machine readable vulnerability advisory documents that uses the JSON markup language.
  • CSAF aggregation is a decentralized model of distributing vulnerability information.
  • CSAF 2.0 is designed to enable next-gen automated enterprise vulnerability management.

The Traditional Process of Vulnerability Management

The traditional process of vulnerability management is a difficult process for large organizations with complex IT environments. The number of CVEs published each patch cycle has been increasing at an unmanageable pace [1][2]. In a traditional vulnerability management process, IT security teams collect vulnerability information manually via Internet searches. In this way, the process involves extensive manual effort to collect, analyze, and organize information from a variety of sources and ad-hoc document formats.

These sources typically include:

  • Vulnerability tracking databases such as NIST NVD
  • Product vendor security advisories
  • National and international CERT advisories
  • CVE numbering authority (CNA) assessments
  • Independent security research
  • Security intelligence platforms
  • Exploit code databases

The ultimate goal of conducting a well-informed risk assessment can be confounded during this process in several ways. Advisories, even those provided by the product vendor themselves, are often incomplete and come in a variety of non-standardized formats. This lack of cohesion makes data-driven decision making difficult and increases the probability of error.

Let’s briefly review the existing vulnerability information pipeline from both the creator and consumer perspectives:

The Vulnerability Disclosure Process

Common Vulnerability and Exposure (CVE) records published in the National Vulnerability Database (NVD) of the NIST (National Institute of Standards and Technology) represent the world’s most centralized global repository of vulnerability information. Here is an overview of how the vulnerability disclosure process works:

  1. Product vendors become aware of a security vulnerability from their own security testing or from independent security researchers, triggering an internal vulnerability disclosure policy into action. In other cases, independent security researchers may interact directly with a CVE Numbering Authority (CNA) to publish the vulnerability without prior consultation with the product vendor.
  2. Vulnerability aggregators such as NIST NVD and national CERTs create unique tracking IDs (such as a CVE ID) and add the disclosed vulnerability to a centralized database where product users and vulnerability management platforms such as Greenbone can become aware and track progress.
  3. Various stakeholders such as the product vendor, NIST NVD and independent researchers publish advisories that may or may not include remediation information, expected dates for official patches, a list of affected products, CVSS impact assessment and severity ratings, Common Platform Enumeration (CPE) or Common Weakness Enumeration (CWE).
  4. Other cyber-threat intelligence providers such as CISA’s Known Exploited Vulnerabilities (KEV) and First.org’s Exploit Prediction Scoring System (EPSS) provide additional risk context.

The Vulnerability Management Process

Product users are responsible for ingesting vulnerability information and applying it to mitigate the risk of exploitation. Here is an overview of the traditional enterprise vulnerability management process:

  1. Product users need to manually search CVE databases and monitor security advisories that pertain to their software and hardware assets or utilize a vulnerability management platform such as Greenbone which automatically aggregate the available ad-hoc threat advisories.
  2. Product users must match the available information to their IT asset inventory. This typically involves maintaining an asset inventory and conducting manual matching, or using a vulnerability scanning product to automate the process of building an asset inventory and executing vulnerability tests.
  3. IT security teams prioritize the discovered vulnerabilities according to the contextual risk presented to critical IT systems, business operations, and in some cases public safety.
  4. Remediation tasks are assigned according to the final risk assessment and available resources.

What is Wrong with Traditional Vulnerability Management?

Traditional or manual vulnerability management processes are operationally complex and lack efficiency. Aside from the operational difficulties of implementing software patches, the lack of accessible and reliable information bogs down efforts to effectively triage and remediate vulnerabilities. Using CVSS alone to assess risk has also been criticized [1][2] for lacking sufficient context to satisfy robust risk-based decision making. Although vulnerability management platforms such as Greenbone greatly reduce the burden on IT security teams, the overall process is still often plagued by time-consuming manual aggregation of ad-hoc vulnerability advisories that can often result in incomplete information.

Especially in the face of an ever increasing number of vulnerabilities, aggregating ad-hoc security information risks being too slow and introduces more human error, increasing vulnerability exposure time and confounding risk-based vulnerability prioritization.

Lack of Standardization Results in Ad-hoc Intelligence

The current vulnerability disclosure process lacks a formal method of distinguishing between reliable vendor provided information, and information provided by arbitrary independent security researchers such as Partner CNAs. In fact, the official CVE website itself promotes the low requirements for becoming a CNA. This results in a large number of CVEs being issued without detailed context, forcing extensive manual enrichment downstream.

Which information is included depends on the CNA’s discretion and there is no way to classify the reliability of the information. As a simple example of the problem, the affected products in an ad-hoc advisory are often provided using a wide range of descriptors that need to be manually interpreted. For example:

  • Version 8.0.0 – 8.0.1
  • Version 8.1.5 and later
  • Version <= 8.1.5
  • Versions prior to 8.1.5
  • All versions < V8.1.5
  • 0, V8.1, V8.1.1, V8.1.2, V8.1.3, V8.1.4, V8.1.5

Scalability

Because vendors, assessors (CNAs), and aggregators utilize various distribution methods and formats for their advisories, the challenge of efficiently tracking and managing vulnerabilities becomes operationally complex and difficult to scale. Furthermore, the increasing rate of vulnerability disclosure exacerbates manual processes, overwhelms security teams, and increases the risk of error or delay in remediation efforts.

Difficult to Assess Risk Context

NIST SP 800-40r4 “Guide to Enterprise Patch Management Planning” Section 3 advises the application of enterprise level vulnerability metrics. Because risk ultimately depends on each vulnerability’s context – factors such as affected systems, potential impact, and exploitability – the current environment of ad-hoc security intelligence presents a significant barrier to robust risk-based vulnerability management.

How Does CSAF 2.0 Solve These Problems?

CSAF documents are essential cyber threat advisories designed to optimize the vulnerability information supply chain. Instead of manually aggregating ad-hoc vulnerability data, product users can automatically aggregate machine-readable CSAF advisories from trusted sources into an Advisory Management System that combines core vulnerability management functions of asset matching and risk assessment. In this way, security content automation with CSAF aims to address the challenges of traditional vulnerability management by providing more reliable and efficient security intelligence, creating the potential for next-gen vulnerability management.

Here are some specific ways that CSAF 2.0 solves the problems of traditional vulnerability management:

More Reliable Security Information

CSAF 2.0 remedies the crux of ad-hoc security intelligence by standardizing several aspects of a vulnerability disclosure. For example, the affected version specifier fields allow standardized data such as Version Range Specifier (vers), Common Platform Enumeration (CPE), Package URL specification, CycloneDX SBOM as well as the product’s common name, serial number, model number, SKU or file hash to identify affected product versions.

In addition to standardizing product versions, CSAF 2.0 also supports Vulnerability Exploitability eXchange (VEX) for product vendors, trusted CSAF providers, or independent security researchers to explicitly declare product remediation status. VEX provides product users with recommendations for remedial actions.

The explicit VEX status declarations are:

  • Not affected: No remediation is required regarding a vulnerability.
  • Affected: Actions are recommended to remediate or address a vulnerability.
  • Fixed: Represents that these product versions contain a fix for a vulnerability.
  • Under Investigation: It is not yet known whether these product versions are affected by a vulnerability. An update will be provided in a later release.

More Effective Use of Resources

CSAF enables several upstream and downstream optimizations to the traditional vulnerability management process. The OASIS CSAF 2.0 documentation includes descriptions of several compliance goals that enable cybersecurity administrators to automate their security operations for more efficient use of resources.

Here are some compliance targets referenced in the CSAF 2.0 documentation that support more effective use of resources above and beyond the traditional vulnerability management process:

  • Advisory Management System: A software system that consumes data and produces CSAF 2.0 compliant advisory documents. This allows CSAF producing teams to assess the quality of data being ingested at a point in time, verify, convert, and publish it as a valid CSAF 2.0 security advisory. This allows CSAF producers to optimize the efficiency of their information pipeline while verifying accurate advisories are published.
  • CSAF Management System: A program that can manage CSAF documents and is able to display their details as required by CSAF viewer. At the most fundamental level, this allows both upstream producers and downstream consumers of security advisories to view their content in a human readable format.
  • CSAF Asset Matching System / SBOM Matching System: A program that integrates with a database of IT assets including Software Bill of Materials (SBOM) and can match assets to any CSAF advisories. An asset matching system serves to provide a CSAF consuming organization with visibility into their IT infrastructure, identify where vulnerable products exist, and optimally provide automated risk assessment and remediation information.
  • Engineering System: A software analysis environment within which analysis tools execute. An engineering system might include a build system, a source control system, a result management system, a bug tracking system, a test execution system and so on.

Decentralized Cybersecurity Information

A recent outage of the NIST National Vulnerability Database (NVD) CVE enrichment process demonstrates how reliance on a single source of vulnerability information can be risky. CSAF is decentralized, allowing downstream vulnerability consumers to source and integrate information from a variety of sources. This decentralized model of intelligence sharing is more resilient to an outage by one information provider, while sharing the burden of vulnerability enrichment more effectively distributes the workload across a wider set of stakeholders.

Enterprise IT product vendors such as RedHat and Cisco have already created their own CSAF and VEX feeds while government cybersecurity agencies and national CERT programs such as the German Federal Office For Information Security Agency (BSI) and US Cybersecurity & Infrastructure Security Agency (CISA) have also developed CSAF 2.0 sharing capabilities. 

The decentralized model also allows for multiple stakeholders to weigh in on a particular vulnerability providing downstream consumers with more context about a vulnerability. In other words, an information gap in one advisory may be filled by an alternative producer that provides the most accurate assessment or specialized analysis.

Improved Risk Assessment and Vulnerability Prioritization

Overall, the benefits of CSAF 2.0 contribute to more accurate and efficient risk assessment, prioritization and remediation efforts. Product vendors can directly publish reliable VEX advisories giving cybersecurity decision makers more timely and trustworthy remediation information. Also, the aggregate severity (aggregate_severity) object in CSAF 2.0 acts as a vehicle to convey reliable urgency and criticality information for a group of vulnerabilities, enabling a more unified risk analysis, and more data driven prioritization of remediation efforts, reducing the exposure time of critical vulnerabilities.

Summary

Traditional vulnerability management processes are plagued by lack of standardization resulting in reliability and scalability issues and increasing the difficulty of assessing risk context and the likelihood of error.

The Common Security Advisory Framework (CSAF) 2.0 seeks to revolutionize the existing process of vulnerability management by enabling more reliable, automated vulnerability intelligence gathering. By providing a standardized machine-readable format for sharing cybersecurity vulnerability information, and decentralizing its source, CSAF 2.0 empowers organizations to harness more reliable security information to achieve more accurate, efficient, and consistent vulnerability management operations.

Greenbone AG is an official partner of the German Federal Office for Information Security (BSI) to integrate technologies that leverage the CSAF 2.0 standard for automated cybersecurity advisories.

Contact Test Now Buy Here Back to Overview

/by
Elmar Geese

“Only 62 minutes”: From security provider to security problem

“Your company can be ruined in just 62 minutes”: This is how the security provider Crowdstrike advertises. Now the US manufacturer has itself caused an estimated multi-billion-dollar loss due to a faulty product update – at breakneck speed.

On 19 July at 04:09 (UTC), the security specialist CrowdStrike distributed a driver update for its Falcon software for Windows PCs and servers. Just 159 minutes later, at 06:48 UTC, Google Compute Engine reported the problem, which “only” affected certain Windows computers and servers running CrowdStrike Falcon software.

Almost five per cent of global air traffic was unceremoniously paralysed as a result, and 5,000 flights had to be cancelled. Supermarkets from Germany to New Zealand had to close because the checkout systems failed. A third of all Japanese MacDonalds branches closed their doors at short notice. Among the US authorities affected were the Department of Homeland Security, NASA, the Federal Trade Commission, the National Nuclear Security Administration and the Department of Justice. In the UK, even most doctors’ surgeries were affected.

The problem

The incident points to a burning problem: the centralisation of services and the increasing networking of the IT systems behind them makes us vulnerable. If one service provider in the digital supply chain is affected, the entire chain can break, leading to large-scale outages. As a result, the Microsoft Azure cloud was also affected, with thousands of virtual servers unsuccessfully attempting to restart. Prominent people affected reacted quite clearly. Elon Musk, for example, wants to ban CloudStrike products from all his systems.

More alarming, however, is the fact that security software is being used in areas for which it is not intended. Although the manufacturer advertises quite drastically about the threat posed by third parties, it accepts no responsibility for the problems that its own products can cause and their consequential damage. CrowdStrike expressly advises against using the solutions in critical areas in its terms and conditions. It literally states – and in capital letters: “THE OFFERINGS AND CROWDSTRIKE TOOLS ARE NOT FAULT-TOLERANT AND ARE NOT DESIGNED OR INTENDED FOR USE IN ANY HAZARDOUS ENVIRONMENT.”

The question of liability

Not suitable for critical infrastructures, but often used there: How can this happen? Negligent errors with major damage, but no liability on the part of the manufacturer: How can this be?

In the context of open source, it is often incorrectly argued that the question of liability in the event of malfunctions and risks is unresolved, even though most manufacturers who place open source on the market with their products do provide a warranty.

We can do a lot to make things better by tackling the problems caused by poor quality and dependence on individual large manufacturers. Of course, an open source supply chain is viewed critically, and that’s a good thing. But it has clear advantages over a proprietary supply chain. The incident is a striking example of this. It is easy to prevent an open source company from rolling out a scheduled update in which basic components simply do not work by using appropriate toolchains, and this is what happens.

The consequences

So what can we learn from this disaster and what are the next steps to take? Here are some suggestions:

  1. improve quality: The best lever to put pressure on manufacturers is to increase the motivation for quality via stricter liability. The Cyber Resilience Act (CRA) offers initial approaches here.
  2. Safety first: In this case, this rule relates primarily to the technical approach to product development. Deeply intervening in customer systems is controversial in terms of security. Many customers reject this, but those affected obviously do not (yet). They have now suffered the damage. There are alternatives, which are also based on open source.
  3. use software only as intended: If a manufacturer advises against use in a critical environment, then this is not just a phrase in the general terms and conditions, but a reason for exclusion.
  4. centralisation with a sense of proportion: There are advantages and disadvantages to centralising the digital supply chain that need to be weighed up against each other. When dependency meets a lack of trustworthiness, risks and damage arise. User authorities and companies then stand helplessly in the queue, without alternatives and without their own sovereignty.

Contact Test Now Buy Here Back to Overview

/by
Greenbone AG

Vulnerability management in 12 minutes

Why is Greenbone not a security provider like any other? How did Greenbone come about and what impact does Greenbone’s long history have on the quality of its vulnerability scanners and the security of its customers? The new video “Demystify Greenbone” provides answers to these questions in an twelve-minute overview. It shows why experts need […]

Read more
/by
Dirk Boeing

NIS2: From impending doom to effective measures

Winter is coming: The motto of House Stark from the series “Game of Thrones” indicates the approach of an undefined disaster. One could also surmise something similar when reading many articles that are intended to set the mood for the upcoming NIS2 Implementation Act (NIS2UmsuCG). Is NIS2 a roller of ice and fire that will bury the entire European IT landscape and from which only those who attend one of the countless webinars and follow all the advice can save themselves?

NIS2 as such is merely a directive issued by the EU. It is intended to ensure the IT security of operators of important and critical infrastructures, which may not yet be optimal, and to increase cyber resilience. Based on this directive, the member states are now called upon to create a corresponding law that transposes this directive into national law.

What is to be protected?

The NIS Directive was introduced by the EU back in 2016 to protect industries and service providers relevant to society from attacks in the cybersphere. This regulation contains binding requirements for the protection of IT structures in companies that operate as critical infrastructure (KRITIS) operators. These are companies that play an indispensable role within society because they operate in areas such as healthcare services, energy supply and transport. In other words, areas where deliberately caused disruptions or failures can lead to catastrophic situations – raise your hand if your household is equipped to survive a power outage lasting several days with all its consequences…

As digitalisation continues to advance, the EU had to create a follow-up regulation (NIS2), which on the one hand places stricter requirements on information security, but on the other hand also covers a larger group of companies that are “important” or “particularly important” for society. These companies are now required to fulfil certain standards in information security.

Although the NIS2 Directive was already adopted in December 2022, the member states have until 17 October 2024 to pass a corresponding implementing law. Germany will probably not make it by then. Nevertheless, there is no reason to sit back. The NIS2UmsuCG is coming, and with it increased demands on the IT security of many companies and institutions.

Who needs to act now?

Companies from four groups are affected. Firstly, there are the particularly important organisations with 250 or more employees or an annual turnover of 50 million euros and a balance sheet total of 43 million euros or more. A company that fulfils these criteria and is active in one of the following sectors: energy, transport, finance/insurance, health, water/sewage, IT and telecommunications or space is particularly important.

In addition, there are the important organisations with 50 or more employees or a turnover of 10 million euros and a balance sheet total of 10 million euros. If a company fulfils these criteria and is active in one of the following sectors: postal/courier, chemicals, research, manufacturing (medical/diagnostics, IT, electrical, optical, mechanical engineering, automotive/parts, vehicle construction), digital services (marketplaces, search engines, social networks), food (wholesale, production, processing) or waste disposal (waste management), it is considered important.

In addition to particularly important and important facilities, there are also critical facilities, which continue to be defined by the KRITIS methodology. Federal facilities are also regulated.

What needs to be done?

In concrete terms, this means that all affected companies and institutions, regardless of whether they are “particularly important” or “important”, must fulfil a series of requirements and obligations that leave little room for interpretation and must therefore be strictly observed. Action must be taken in the following areas:

Risk management

Affected companies are obliged to introduce comprehensive risk management. In addition to access control, multi-factor authentication and single sign-on (SSO), this also includes training and incident management as well as an ISMS and risk analyses. This also includes vulnerability management and the use of vulnerability and compliance scans.

Reporting obligations

All companies are obliged to report “significant security incidents”: these must be reported to the BSI reporting centre immediately, but within 24 hours at the latest. Further updates must be made within 72 hours and 30 days.

Registration

Companies are obliged to determine for themselves whether they are affected by the NIS2 legislation and to register themselves within a period of three months. Important: Nobody tells a company that it falls under the NIS2 regulation and must register. The responsibility lies solely with the individual companies and their directors.

Evidence

It is not enough to simply take the specified precautions; appropriate evidence must also be provided. Important and particularly important facilities will be inspected by the BSI on a random basis, and appropriate documentation must be submitted. KRITIS facilities will be inspected on a regular basis every three years.

Duty to inform

In future, it will no longer be possible to sweep security incidents under the carpet. The BSI will be authorised to issue instructions to inform customers about security incidents. The BSI will also be authorised to issue instructions on informing the public about security incidents.

Governance

Managing directors are obliged to approve risk management measures. Training on the topic will also become mandatory. Particularly serious: Managing directors are personally liable with their private assets for breaches of duty.

Sanctions

In the past, companies occasionally preferred to accept the vague possibility of a fine rather than making concrete investments in cyber security measures, as the fine seemed quite acceptable. NIS2 now counters this with new offences and in some cases drastically increased fines. This is further exacerbated by the personal liability of managing directors.

As can be seen, the expected NIS2 implementation law is a complex structure that covers many areas and whose requirements can rarely be covered by a single solution.

What measures should be taken as soon as possible?

Continuously scan your IT systems for vulnerabilities. This will uncover, prioritise and document security gaps as quickly as possible. Thanks to regular scans and detailed reports, you create the basis for documenting the development of the security of your IT infrastructure. At the same time, you fulfil your obligation to provide evidence and are well prepared in the event of an audit.

On request, experts can take over the complete operation of vulnerability management in your company. This also includes services such as web application pentesting, which specifically identifies vulnerabilities in web applications. This covers an important area in the NIS2 catalogue of requirements and fulfils the requirements of § 30 (risk management measures).

Conclusion

There is no single, all-encompassing measure that will immediately make you fully NIS2-compliant. Rather, there are a number of different measures that, taken together, provide a good basis. One component of this is vulnerability management with Greenbone. If you keep this in mind and put the right building blocks in place in good time, you will be on the safe side as an IT manager. And winter can come.

Contact Test Now Buy Here Back to Overview

/by
Andreas Bergler

Potsdam conference for national cyber security 2024

On 19 and 20 June 2024, it’s all about the big picture: high-ranking IT specialists and decision-makers from politics, business and science will meet in Potsdam to provide an overview of “National Cybersecurity”. One of the biggest, widespread challenges is the rapid development of artificial intelligence (AI). Elmar Geese, CEO of Greenbone, will discuss its influence on IT security with Dr Christoph Bausewein (CrowdStrike), Dr Sven Herpig (Stiftung Neue Verantwortung) and Dr Kim Nguyen (Bundesdruckerei) on the podium.

  • Time: 19 June 2024; 13:45
  • Place: Hasso Plattner Institute, Potsdam, Prof.-Dr.-Helmert-Straße 2-3 (Griebnitzsee campus)
  • Topic: How is artificial intelligence changing the cybersecurity landscape?
  • Moderation: Prof Dr Sandra Wachter, University of Oxford

The Potsdam Conference on National Cybersecurity will take place on 19 and 20 June 2024. Visit us at our stand at the conference!

Registration: https://hpi.de/das-hpi/bewerbung/2024/potsdam-cybersecurity-conference/

Contact Test Now Buy Here Back to Overview

/by
Greenbone AG

PITS 2024 Public IT Security

Save the date: The “German Congress for IT and Cyber Security in Government and Administration” (June 12 to 13, 2024) provides information on current trends, strategies and solutions in IT security.

In the main program: “IT support for early crisis detection” (Moderation: Dr. Eva-Charlotte Proll, Editor-in-Chief and Publisher, Behörden Spiegel).

Participants:

  • Dr. Jan-Oliver Wagner, Chief Executive Officer Greenbone
  • Carsten Meywirth, Head of the Cybercrime Division, Federal Criminal Police Office
  • Generalmajor Dr. Michael Färber, Head of Planning and Digitization, Cyber & Information Space Command
  • Katrin Giebel, Branch Manager, VITAKO Bundesverband kommunaler IT-Dienstleister e.V.
  • Dr. Dirk Häger, Head of the Operational Cybersecurity Department, Federal Office for Information Security (BSI)

Where? Berlin, Hotel Adlon Kempinski, Unter den Linden 77
When? 13.06.2024; 9:40 a.m.

Vulnerabilities in IT systems are increasingly being exploited by malicious attackers. You can protect your IT systems with vulnerability management. Visit us in our lounge at stand 44 – we look forward to seeing you!

Registration: https://www.public-it-security.de/anmeldung/

Contact Test Now Buy Here Back to Overview

/by
Markus Feilner

Municipalities, authorities and companies under pressure: serious attacks on the rise, NIS2 becomes mandatory

After experts noticed a rapid increase in cyberattacks on local authorities and government agencies in 2023, the horror stories don’t stop in 2024. The pressure to act is enormous, as the EU’s NIS2 Directive will come into force in October and makes risk and vulnerability management mandatory.

“The threat level is higher than ever,” said Claudia Plattner, President of the German Federal Office for Information Security (BSI), at Bitkom in early March. The question is not whether an attack will be successful, but only when. The BSI’s annual reports, for example the most recent report from 2023, also speak volumes in this regard. However, according to Plattner, it is striking how often local authorities, hospitals and other public institutions are at the centre of attacks. There is “not a problem with measures but with implementation in companies and authorities”, said Plattner. One thing is clear: vulnerability management such as Greenbone’s can provide protection and help to avoid the worst.

US authorities infiltrated by Chinese hackers

In view of the numerous serious security incidents, vulnerability management is becoming more important every year. Almost 70 new security vulnerabilities have been added every day in recent months. Some of them opened the door to attackers deep inside US authorities, as reported in the Greenbone Enterprise Blog:

According to the media, US authorities have been infiltrated by Chinese hacker groups such as the probably state-sponsored “Volt Typhoon” for years via serious security gaps. The fact that Volt Typhoon and similar groups are a major problem was even confirmed by Microsoft itself in a blog back in May 2023. But that’s not all: German media reported that Volt Typhoon is taking advantage of the abundant vulnerabilities in VPN gateways and routers from FortiNet, Ivanti, Netgear, Citrix and Cisco. These are currently considered to be particularly vulnerable.

The fact that the quasi-monopolist in Office, groupware, operating systems and various cloud services also had to admit in 2023 that it had the master key for large parts of its Microsoft cloud let stolen destroyed trust in the Redmond software manufacturer in many places. Anyone who has this key doesn’t need a backdoor for Microsoft systems any longer. Chinese hackers are also suspected in this case.

Software manufacturers and suppliers

The supply chain for software manufacturers has been under particular scrutiny by manufacturers and users not only since log4j or the European Cyber Resilience Act. The recent example of the attack on the XZ compression algorithm in Linux also shows the vulnerability of manufacturers. In the case of the “#xzbackdoor”, a combination of pure coincidence and the activities of Andres Freund, a German developer of open source software for Microsoft with a strong focus on performance, prevented the worst from happening.

An abyss opened up here: It was only thanks to open source development and a joint effort by the community that it came to light that actors had been using changing fake names with various accounts for years with a high level of criminal energy and with methods that would otherwise be more likely to be used by secret services. With little or no user history, they used sophisticated social scams, exploited the notorious overload of operators and gained the trust of freelance developers. This enabled them to introduce malicious code into software almost unnoticed. In the end, it was only thanks to Freund’s interest in performance that the attack was discovered and the attempt to insert a backdoor into a tool failed.

US officials also see authorities and institutions as being particularly threatened in this case, even if the attack appears to be rather untargeted and designed for mass use. The issue is complex and far from over, let alone fully understood. One thing is certain: the usernames of the accounts used by the attackers were deliberately falsified. We will continue to report on this in the Greenbone blog.

European legislators react

Vulnerability management cannot prevent such attacks, but it provides indispensable services by proactively warning and alerting administrators as soon as such an attack becomes known – usually before an attacker has been able to compromise systems. In view of all the difficulties and dramatic incidents, it is not surprising that legislators have also recognised the magnitude of the problem and are declaring vulnerability management to be standard and best practice in more and more scenarios.

Laws and regulations such as the EU’s new NIS2 directive make the use of vulnerability management mandatory, including in the software supply chain. Even if NIS2 only actually applies to around 180,000 organisations and companies in the critical infrastructure (KRITIS) or “particularly important” or “significant” companies in Europe, the regulations are fundamentally sensible – and will be mandatory from October. The EU Commission emphasises that “operators of essential services” must “take appropriate security measures and inform the competent national authorities of serious incidents”. Important providers of digital services such as search engines, cloud computing services and online marketplaces must fulfil the security and notification requirements of the directive.”

Mandatory from October: A “minimum set of cyber security measures”

The “Directive on measures for a high common level of cybersecurity across the Union (NIS2)” forces companies in the European Union to “implement a benchmark of minimum cybersecurity measures”, including risk management, training, policies and procedures, also and especially in cooperation with software suppliers. In Germany, the federal states are to define the exact implementation of the NIS2 regulations.

Do you have any questions about NIS2, the Cyber Resilience Act (CRA), vulnerability management in general or the security incidents described? Write to us! We look forward to working with you to find the right compliance solution and give your IT infrastructure the protection it needs in the face of today’s serious attacks.

To make our ecological progress even more sustainable, we keep up to date with regular internal training courses on energy efficiency. In this way, we are helping to make the world even “greener” outside of Greenbone.

Contact Test Now Buy Here Back to Overview

/by
Markus Feilner

CISA warning: Serious Security Vulnerability in MS Sharepoint

Two security vulnerabilities in Sharepoint – both from last year – are currently causing trouble for Sharepoint administrators. Because attackers are increasingly exploiting a combination of the two vulnerabilities, the Cybersecurity Infrastructure Security Agency CISA is now also issuing a warning. Affected customers of the Greenbone Enterprise Feed have been warned since June 2023.

Tracking-News: Critical Vunerability in MS Sharepoint

Remote Privilege Execution

The two vulnerabilities CVE-2023-29357 and CVE-2023-24955 together allow attackers to remotely gain administrator rights in a company’s SharePoint server. Details of the attack were published back in September 2023 at the Pwn2Own conference in Vancouver 2023 and can be found on the Singapore Starlabs blog, for example.

Massive attacks have now led to CISA recently issuing a warning about these vulnerabilities and including CVE-2023-29357 in its catalog of known exploited vulnerabilities. However, Greenbone has already had authenticated version checks for both CVEs since around June 2023 and an active check for CVE-2023-29357 since October 2023. Customers of the enterprise products have been receiving these CVEs as a threat for several months – in authenticated and unauthenticated scan mode.

Microsoft advises its customers on its website to update to the SharePoint Server 2019 version of June 13, 2023, (KB5002402), which fixes five critical vulnerabilities, including the first CVE mentioned by CISA. Furthermore, all administrators should install the antivirus software AMSI and activate Microsoft Defender in the SharePoint server. Otherwise, attackers could bypass authentication with fake authentication tokens and gain administrator rights.

Recognising and detecting vulnerabilities in the company at an early stage is important, as the many reports of damaging vulnerabilities show. Greenbone products can take on a lot of work here and ensure security – as a hardware- or as a virtual appliance. The Greenbone Enterprise Feed, which feeds all Greenbone security products, receives daily updates and therefore covers a high percentage of risks.

Contact Test Now Buy Here Back to Overview

/by
Greenbone AG

Tracking News: Juniper Junos Vulnerabilities

5 Known Juniper Junos Vulnerabilities Being Actively Exploited

CISA has added 5 CVEs relating to Juniper Junos (aka Junos OS), to its Known Exploited Vulnerabilities (KEV) catalog. The full exploit chain involves combining several lower-severity CVEs to achieve pre-authentication remote code execution (RCE). The 5 CVEs range in severity from CVSS 9.8 Critical to CVSS 5.3 Medium. Greenbone is equipped with vulnerability tests to identify affected systems.

Understanding the timeline of events should help network defenders grasp how rapidly cyber threats can escalate. In this case a proof-of-concept (PoC) was published just 8 days after the vendor Juniper released its security advisory. Security researchers observed active exploitation just 12 days after the disclosure. Still, it was not until several months later that CISA acknowledged active exploitation. Greenbone Enterprise vulnerability feed added detection tests [1][2] for all impacted versions of the two affected product lines (EX Series Series Ethernet Switches and SRX Series Series Services Gateways) on August 18, 2023, immediately after they were disclosed.

Here is a brief description of each CVE:

  • CVE-2023-36844 (CVSS 5.3 Medium): A PHP External Variable Modification [CWE-473] vulnerability exists in J-Web, a tool used for remote configuration and management of Junos OS. The vulnerability allows an unauthenticated, network-based attacker to modify sensitive PHP environment variables. CVE-2023-36844 allows chaining to other vulnerabilities that lead to unauthenticated RCE.
  • CVE-2023-36845 (CVSS 9.8 Critical): A PHP External Variable Modification vulnerability [CWE-473] in J-Web allows an unauthenticated, network-based attacker to remotely execute code. Using a crafted request that sets the variable PHPRC an attacker is able to modify the PHP execution environment to inject and execute code.
  • CVE-2023-36846 (CVSS 5.3 Medium): A Missing Authentication for Critical Function [CWE-306] vulnerability in Juniper Networks Junos OS allows an unauthenticated, network-based attacker to impact file system integrity with a specific request to user.php via J-Web. Without authentication, an attacker is able to upload arbitrary files [CWE-434] which allows chaining to other vulnerabilities including unauthenticated RCE.
  • CVE-2023-36847 (CVSS 5.3 Medium): A Missing Authentication for Critical Function [CWE-306] vulnerability in Juniper Networks Junos OS allows an unauthenticated, network-based attacker to impact file system integrity. With a malicious request to installAppPackage.php via J-Web an attacker is able to upload arbitrary files [CWE-434] without authentication, which may allow chaining to other vulnerabilities that lead to RCE.
  • CVE-2023-36851 (CVSS 5.3 Medium): A Missing Authentication for Critical Function [CWE-306] vulnerability in Juniper Networks Junos OS allows an unauthenticated, network-based attacker to impact file system integrity. With a specific request to webauth_operation.php that doesn’t require authentication, an attacker is able to upload arbitrary files via J-Web [CWE-434], leading to a loss of integrity for a certain part of the file system and chaining to other vulnerabilities.

Understanding The Attack Trajectory

Several of the CVEs listed above are classified as Missing Authentication for Critical Function [CWE-306] vulnerabilities meaning that various functions of the J-Web device management web application do not implement proper authentication checks.

Here is a summary of how these vulnerabilities were chained together for unauthenticated RCE:

The J-Web application is written in PHP which, as the watchTowr researchers noted, is known for its usability at the cost of security. In the case of CVE-2023-36846, J-web’s `webauth_operation.php` file implemented a different method for authentication than the rest of the application. This file instead invokes the `sajax_handle_client_request()` function and submits the value of ‘false’ as the `doauth` parameter, resulting in no authentication being performed. The aforementioned `sajax_handle_client_request()` function is designed to execute J-web’s built-in functions by specifying them as a $_POST variable, including the `do_upload()` function, used to upload files.

CVE-2023-36845 is a vulnerability in the Junos web server that allows system environment variables to be set via the `name` field of an HTTP POST request when a`Content-Type: multipart/form-data` header is used. Two exploits matching the description of CVE-2023-36845 were previously disclosed for the GoAhead IoT web server and tracked as CVE-2017-17562 and CVE-2021-42342, indicating that the Junos web server likely implements the GoAhead proprietary web-server.

Executing the uploaded file is possible by setting the PHPRC environment variable, using it to load an unauthorized PHP configuration `php.ini` file also uploaded via CVE-2023-36846 that contains a malicious `auto_prepend_file` setting directing PHP to execute the first uploaded file every time a page is loaded. Here is the complete example chain

Mitigation Of Recent Juniper Junos Vulnerabilities

The 5 new CVEs affect Juniper Networks Junos OS on EX Series Series Ethernet Switches and SRX Series Series Services Gateways. Specifically Junos OS version 20.4 and prior, 21.1, 21.2, 21.3, 21.4, 22.1, 22.2, 22.3, 22.4 and 23.2 on the EX and SRX Series appliances.

The best mitigation option is to install the security patches to Junos OS. If you cannot install the official provided security patches, completely disabling the J-Web interface, or configuring firewalls with an accept list to restrict access to only trusted hosts can prevent exploitation. In general, strictly limiting access to critical servers and network appliances to only client IP addresses that require access can prevent exploitation of similar yet undiscovered remotely exploitable zero-day vulnerabilities.

Contact Test Now Buy Here Back to Overview

/by
Greenbone AG

The Confluence of Open Source and Cybersecurity in companies: Insights from Greenbone at #OSXP2023 in Paris

International panel discussion on effective cybersecurity at #OSXP2023

At the esteemed #OSXP2023 event, that took place in Paris, our participation in the “Cybersécurité et open source” roundtable brought forward critical discussions on improving cybersecurity in companies. The panel, including distinguished experts from the academic and governmental sectors, delved into strategies and points of vigilance essential for robust cybersecurity.

Panel discussion at the Open Source Experience 2023 in Paris on 'Cybersécurité et open source' with international experts and audience.

1. The Mindset of Security

Security by Design: A Leadership Commitment

  • The panel emphasized the importance of incorporating security from the initial stages of development. This approach requires a commitment from the top management to prioritize security in all business operations.

A Mentality Focused on Secure and Protected Solutions

  • Companies must cultivate a culture where security is an integral part of the thinking process, aiming to deliver solutions that are inherently secure and protected.

2. Implementing Key Processes

Adherence to Standards and Automation

  • The importance of adhering to established cybersecurity standards was underscored, with a recommendation to automate processes wherever possible to ensure consistency and efficiency.

No Deployment Without Security Compliance

  • It was strongly advised that no deployments or actions should proceed without meeting the necessary security requirements.

3. Resources: Empowering Teams and Enhancing Vigilance

Dedicated Security Teams and Training

  • Having specialized security teams and conducting regular training sessions were identified as crucial for maintaining a high level of security awareness and preparedness.

Vigilance as a Continuous Effort

  • Continuous vigilance was highlighted as a key resource, ensuring that security measures are always up-to-date and effective.

4. Essential Tools and Technologies

Mandatory Multi-Factor Authentication (MFA)

  • Implementing MFA as a compulsory measure we recommend enhancing account security significantly.

Vulnerability Scanners and Dependance Management

  • Utilizing vulnerability scanners and managing dependencies and configurations were suggested as vital tools. While platforms like GitHub Enterprise may be costly, they offer comprehensive solutions for these needs.

Conclusion: Education, Awareness, and the Use of Open-Source Tools

In conclusion, the panel at #OSXP2023, including our expert Corentin Bardin, a cyber security specialist and pen tester, highlighted the importance of continuous education and staying updated in the rapidly evolving cybersecurity landscape. They advocated for the use of open-source tools to bolster security measures.

The key takeaway from the discussion is the commitment to offering secure services. It’s not just about the tools and processes; it’s about the mindset and ongoing effort to stay vigilant and informed.


Contact Free Trial Buy Here Back to Overview

/by