Researchers have discovered a new attack technique that exploits the speculative execution feature of modern CPUs to leak potentially sensitive information from the kernel’s memory. The attack circumvents some of the software defenses some operating systems put in place to prevent previous exploits of this nature.

The attack, dubbed Retbleed by researchers from Swiss university ETH Zurich, works against both Intel and AMD CPUs. On Intel it’s tracked as CVE-2022-29901 and impacts CPU generations 6, 7 and 8 although to different extents and depending on the mitigations used by the operating system. On AMD it’s tracked as CVE-2022-29900 and impacts AMD Zen 1, Zen 1+ and Zen 2 CPUs.

To read this article in full, please click here

Read More

The ICO found that the use of WhatsApp and other messaging services in government carries significant risks

Read More

A new low-code security automation platform designed for ease of use was introduced Tuesday by Flashpoint, a threat intelligence company. Called Automate, the platform aims to lower the barriers typically associated with security automation.

“Automation solutions can be great, but oftentimes they require a team of engineers or developers, sometimes both,” explains Flashpoint Executive Director of Automation Robert D’Aveta.

As everyone in the tech industry knows, engineers and developers can be tough to find. “Unless your organization has a staff of unicorns that can do automation work, that leaves it to ordinary people,” D’Aveta says. “That’s a barrier to entry for typical automation solutions that low-code automation can help solve.”

To read this article in full, please click here

Read More

This is the first part of a three-blog series on startup security.

Software vulnerabilities are the bane of every security team. A newly discovered vulnerability can turn a crucial software product into a ticking timebomb waiting to be exploited. Security practitioners and IT teams tasked with protecting their organizations must identify and mitigate a constant stream of new vulnerabilities before their presence results in a breach.

The importance of vulnerability and patch management is well understood in the field of information security. Less understood, however, are the factors contributing to the continuous introduction and proliferation of software vulnerabilities that plague nearly every software product and the organizations that depend on them.

Specifically, current startup culture and the incentives and expectations surrounding newer, smaller software projects have created deeply rooted flaws in how software is developed and brought to market. These flaws not only lead to otherwise avoidable vulnerabilities in software produced by small teams, but they also end up broadly impacting the entire technology industry and force users to accept data and privacy breaches as a fact of life.

The software industry has evolved dramatically over the past decade and much of the change has focused on one aspect: speed. Software and business concepts such as Agile development, sprints, the lean startup, and even “fail fast” are employed as the norm by many teams and as their names suggest, they all aim to speed up product development. In the highly competitive software industry where barriers to entry are lower than ever and seemingly everyone has a startup idea, getting products and features to market before a competitor can make or break a company.

Security struggles to find a place in the race for companies to acquire funding, find product-market fit, and gain initial traction. Simply put, startups are incentivized internally and externally to spend as little time and effort as possible on software security.

Few startups have the luxury of bringing their founders’ vision to market without relying on external funding and resources. Founding teams often work for sweat equity, foregoing a lucrative salary at a more established company and dipping into personal savings to get the company started. For unfunded startups, 100% of resources are focused on obtaining initial funding.

The point at which a startup can start to raise capital varies wildly depending on the qualifications of the founders. For a startup created by young and unknown entrepreneurs, this often means that the founding team must have a functioning product with a growing userbase before they are able to acquire the investment needed to grow their development team beyond a few founding members.

Internally, the rapid development requirements push engineers to take shortcuts, often relying on unvetted libraries and copy/pasted code. For a lean startup, having a dedicated security engineer is not an option. Product security is therefore typically the responsibility of the most experienced software engineer, who may not have the expertise or bandwidth to make it a priority. For a founding team that needs existing users before it can acquire funding, this can mean putting user data at risk.

Externally, early investors in the startups are unequivocally uninterested in software security and are not incentivized to learn or be concerned about software security. Initial users may ask questions about a product’s security, but these are typically limited to privacy concerns. For B2B products, initial enterprise customers with robust supplier security policies may scrutinize a product’s security design. However, they will stop short of investing their own capital in making a promising software product more secure.

The lack of incentives to make early investments in software security hold true not just for commercial startups but also for developers of open-source libraries. Even the most widely used and well-known open-source libraries are most often supported by a very small team with limited resources. In theory, the open-source community is invited to evaluate and improve the security of the libraries, but results vary widely without financial incentive to do so. In the past decade, some of the most widely proliferated vulnerabilities were tied to open-source libraries used by a large percentage of commercial products.

As with open-source libraries, code developed by startups eventually makes its way into mature software products sold by a large company. It is often at this point that vulnerabilities originally introduced during rapid development by a small team become a problem that affects global enterprises. The lack of incentives to invest in security as a small team is not fixed until too late, if at all.

The market pressures keeping software companies from improving the security of their products will ensure that preventable vulnerabilities continue to be a threat until there is a major culture shift. Developers, investors, users, and M&A stakeholders must all better understand their exposure and responsibilities regarding software vulnerabilities.

The single most powerful driver for this change will likely be the degree to which the market holds companies responsible for compromises resulting from vulnerabilities in their software. By this metric, a shift is already happening. Whereas in previous years a high-profile vulnerability would have at most caused a momentary dip in a company’s share price, recently we have seen companies suffer a substantial and seemingly permanent drop in market cap or have M&A negotiations fall through due the compromise of their software product.

As breaches and critical vulnerabilities become increasingly mainstream, we can hope that more small companies and their investors take an active role addressing security questions at an earlier stage. As we improve, secure development practices must become a differentiator and business enabler before ultimately becoming the norm for early-stage startups.

This article is part 1 of a 3-part series on startup security. Parts 2 and 3 will focus on the anatomy of a software vulnerability and how to approach security at the earliest stages of a new company.

Read More

Learn about well-known vulnerabilities and attacks and how they affected critical infrastructure — from Phone Phreaking to recent ransomware.

Cyberattacks against critical infrastructure are on the rise. The FBI’s Internet Crime Complaint Center (IC3) highlighted in its 2021 Internet Crime Report that 649 complaints of ransomware attacks were received from organizations in the critical infrastructure sector, a 7% increase over the prior year. Organizations in the healthcare, public health, financial services and information technologies sectors — which are among the 16 critical infrastructure sectors identified by the U.S. Cybersecurity and Infrastructure Security Agency (CISA) — are the most frequent victims of ransomware, according to the study. And the IC3 anticipates a surge of attacks against critical infrastructure in 2022.

The Colonial Pipeline ransomware attack serves as an example of how the surge in vulnerabilities in IT systems can severely impact operations and, potentially, the overall U.S. economy at large.

Industries are investing more into Supervisory Control and Data Acquisition (SCADA) systems, with a market forecast reach of $15 billion USD by 2030 with a CAGR of 7% according to a recent research report by Market Research Future. While recognizing that otherwise simple security measures like patching can have impact on operations for OT systems like SCADA systems, neglecting it leaves the door wide open for substantial consequences.

While IT and OT systems have common touch points each faces a diverse set of challenges. For example, patching vulnerabilities in OT systems is challenging because small errors can shut down entire plants and facilities. OT often involves legacy systems that require specialized know-how that, if not consistently shared and passed to future employees, can add to the complexity of both operating devices as well as patching them.

However, the effects of security incidents on the supply chain can be overwhelming.

Back to the future

The need to protect critical infrastructure certainly is not new. First attacks date back to the 1960s when the first phone hacking mechanisms exploited the public phone systems.

ARPANET, the first public packet-switched computer network, was first used in 1969. Shortly after, in 1971, the first instance of a “worm” (CREEPER) was created and the first Denial of Service attacks were born. During the early 1980s, the 414s marked the hacking scene’s break into computer systems at several institutions.

As internet connectivity became ubiquitous, organizations needed a way to easily share relevant vulnerability data across organizations and industries. In 1999, MITRE introduced the Common Vulnerabilities and Exposures (CVE) list system. In 2005, CVEs were followed by the National Institute of Standards and Technologies’ (NIST) National Vulnerability Database (NVD). Meanwhile, vulnerabilities and threats continued to proliferate.

Heartbleed left its mark on industrial control systems in 2014. More recently, vulnerabilities such as the Ripple20 set — which affects a software library widely used in OT, IoT and IT devices — remain a significant concern. Attacks against the software supply chain, such as the 2020 breach of the SolarWinds Orion platform, have upped the ante by targeting the auto-update features of a vendor’s software. And, attacks don’t always need to target OT systems directly to have a significant impact on critical infrastructure. The 2021 ransomware attack against the IT systems of Colonial Pipeline is a case in point: although the organization’s OT systems were not compromised, the decision was made to take the pipeline out of service out of an abundance of caution, causing fuel shortages up and down the densely populated East Coast of the United States.

Vulnerability landscape: Behind the scenes

Securing critical infrastructure requires accounting for the complexities of IT and OT systems, understanding their diverse challenges and being prepared to overcome the obstacles stemming from their integration.

The recent attacks and threats discussed in this blog are critical and sophisticated. The table below is a selected list of widely covered vulnerabilities which have implications for critical infrastructure operators.

CVE

Description

CVE Rating

CVE-2014-0160

Heartbleed

High

CVE-2020-11896, CVE-2020-11897, CVE-2020-11901 (out of 19)

Ripple20

Medium to Critical

CVE-2021-35211

Remote code execution (RCE) vulnerability in the SolarWinds Serv-U

Critical

CVE-2021-20016

SonicWall SSLVPN Vulnerability – attack initiation

Critical

CVE-2020-1472

Netlogon Elevation Privilege Escalation- privilege escalation

Critical

As previously noted, each vulnerability in the above table affected critical infrastructure in different ways.

Colonial Pipeline: From IT systems to OT shutdown

The ransomware attack against the IT system of Colonial Pipeline, one of the biggest U.S. fuel pipeline operators, is an example of how an attack on IT systems can also have significant impact on critical infrastructure.

Two known CVEs were at the forefront of the attack against Colonial Pipeline:

CVE-2021-20016, a zero-day vulnerability affecting SonicWall Secure Mobile Access (SMA100), used for attack initiation; and
CVE-2020-1472, a Zerologon vulnerability that — when successfully exploited — allows for privilege escalation by establishing a Microsoft Netlogon secure channel connection to a domain controller, using the Netlogon Remote Protocol (MS-NRPC).

The attack led to a ransom payment of roughly $4.4 million and, while the OT systems controlling the pipeline itself were not breached, the organization opted to shut down operations for five days out of an abundance of caution. The case exemplifies how the convergence of IT/OT systems, and the related pursuit of digital transformation as a business driver, affects critical infrastructure operators.

Conclusion

While vulnerability management remains a powerful tool to integrate into the overall business lifecycle, it’s not without its challenges in critical infrastructure environments. Among the challenges:

In many cases, devices running on OT networks are no longer supported. The companies behind them may have long gone out of business. 
In other cases, there’s a lack of a clear update mechanism, such as an interface or software update utility, so even if an OT vendor wanted to release a patch, it would be difficult to deploy.
Without an effective way to patch or remediate, an organization is left to figure out how to reduce or mitigate an attack surface by isolating network traffic and devices, firewalls and VPNs and unique routing tables.

Critical infrastructure providers are also heavily focused on uptime above all else, which introduces several challenges for patching OT systems, including:

The potential for patching to cause downtime of critical operational technologies,
A lack of fixes for legacy systems,
A lack of staff with the right expertise on how to secure legacy systems.

Resolving these and other challenges related to critical infrastructure security requires a concerted effort by operators, vendors and government agencies around the world. Finding and fixing vulnerabilities in the IT and OT systems used in these environments is just the first step.

Get more information

Read our blog posts:

The State of OT Security a Year Since Colonial Pipeline
Securing Critical Infrastructure: It’s Complicated 
Colonial Pipeline Ransomware Attack: How to Reduce Risk in OT Environments

Listen to the The State of OT Security, a Year Since Colonial Pipeline podcast

Download the whitepaper Prediction of an OT Attack.

Read the report A look inside the ransomware ecosystem.

We recently held a transport-focused OT webinar – Unpacking Some of the Most Common Cybersecurity Challenges Facing Your Transportation-Sector Business. The session included panelists from the U.S. Transportation Security Administration (TSA) and two of our partners. If you missed it make sure you catch the recording and keep an eye on our list of future webinars as we’ve more planned around this topic.

Read More

As CISOs look to prepare their 2023 security budgets, some might be asking themselves, “where do I begin?” There are such varied and rapidly changing facets of defending organizations against cyber threats that the task of sorting out which risks need the most attention can seem overwhelming.

Nevertheless, security leaders need to begin thinking about how much funding they will need and how they will allocate their budgets. “At a macro level, when defining strategic goals and developing budgets for security, CISOs should know that the status quo will likely leave security leaders with an impossible mission ahead—constrained to maintain operations and new initiatives,” says David Chaddock, director of cybersecurity for consultancy West Monroe.

To read this article in full, please click here

Read More