Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

On April 9, 2024, Japan's Ministry of Economy, Trade and Industry (METI) announced its intention to implement a cybersecurity rating system for companies by fiscal year 2025.

When a new major CVE gets released, cybersecurity companies race to discover ways of detecting the new vulnerability and organizations scramble to determine if they are impacted or not. Developing high-confidence techniques to scan the public-facing Internet assets for newly published vulnerabilities can potentially take weeks or even months as vulnerability researchers discover and test various detection methods.

The path to NIS2 compliance is less about ticking boxes and more about fostering a resilient, proactive cybersecurity culture across the organisation and its extended network. While the challenges pertaining to third-party and supply chain risk management are significant, they are not insurmountable—especially if we break them down. Today we will focus on understanding a very specific NIS2 requirement: Coordinated Risk Assessments.

Organizations register domains for many reasons, the obvious one being to use as their primary online presence. In many cases organizations also register domains that they might not use but want to prevent others from using.

You may not know it, but much of your daily life depends on Industrial Control Systems(ICSs). From the power you're using right now to the water you drink, it all depends on Programmable Logic Controllers (PLCs) and other ICS tech to be delivered. In fact, nearly any time something in the physical world needs to be automated, there will be an ICS involved.

Let’s talk technical debt. It’s that silent, creeping problem many of us have faced—those quick fixes and shortcuts we took to keep things running smoothly. They accumulate over time, leaving us with a tangled web of outdated systems and patchwork solutions. In cybersecurity, this isn’t just a minor annoyance—it’s a ticking time bomb. So, what’s technical debt consolidation?

Before Crowdstrike caused the world to melt down for a few days, the talk of the security town was a recent OpenSSH vulnerability (CVE-2024-6387). Dubbed by its celebrity name regreSSHion, it is a Remote Code Execution vulnerability in some versions of OpenSSH discovered by the Qualys Threat Research Unit on July 1, 2024. Specifically, versions of OpenSSH compiled against the glibc library, which is to say “probably most of them”, were impacted.

Most organizations now recognize that even if they have a strong internal security posture, a security lapse by any one of their many third-party vendors or partners can be just as catastrophic to their business as a direct breach. Industry and government regulators are increasingly focused on this topic as well, resulting in a wave of new compliance requirements that extend to third-party risks.

As we are all very aware, being a technical person or layman, the recent CrowdStrike outage caused disruptions on a myriad of systems worldwide, affecting multiple industry sectors and millions of people in some way, shape, or format.

In today’s interconnected business environment, organizations rely heavily on third parties, and while third party relations are critical for success in most businesses, they also leave data more vulnerable to exposure from bad actors. This makes vendor risk management (VRM) a critical component of any company's overall risk management strategies. Effective VRM practices help protect sensitive data and maintain robust security postures, minimizing the potential risks introduced by vendors.