Four months after the Log4Shell vulnerability was disclosed, most affected open source components remain unpatched, and companies continue to use vulnerable versions of the logging tool.

Attackers who want to exploit the critical remote code execution vulnerability disclosed in the Apache Log4j logging tool over four months ago still have a vast array of targets to go after.

In a recent scan using the Shodan search engine, Rezilion found more than 90,000 Internet-exposed servers containing a vulnerable version of the software. The security vendor believes the number represents only a small fraction of available attacker targets because it only considers publicly facing servers running open source software. If internal network servers and servers running proprietary applications are factored in, the total number of vulnerable targets is likely much higher, Rezilion said.

A Rezilion report this week that summarized the results of its study pointed to other data points that appear to bolster the company's conclusion.

Among them is data from a Google open source scanning service called Open Source Insights, which showed that just 7,140 Java packages out of a total of 17,840 affected packages have been patched for Log4Shell since the flaw was disclosed. Another data point from Sonatype found that as of Apr. 20, 2022, some 36% of Log4j versions being actively downloaded from the Maven Central Java application repository were still vulnerable to Log4Shell — a number that has remained largely unchanged since February.

"Similar to other historic high-profile vulnerabilities, even though four months have passed, there is still a huge attack surface that is vulnerable to Log4Shell," says Yotam Perkal, director of vulnerability research at Rezilion. "The 90,000 publicly accessible vulnerable servers are probably only the tip of the iceberg in terms of actual vulnerable attack surface."

The Apache Foundation disclosed the Log4Shell vulnerability (CVE-2021-44228) along with an updated and fixed version of the software on Dec. 9, 2021. The flaw is present in virtually every Java application environment, is considered trivially easy to exploit, and gives attackers a way to gain complete control over vulnerable systems. Many security experts consider the flaw to be one of the most dangerous to be disclosed in recent memory, and they have urged organizations to install the updated and fixed version of the software as soon as possible.

Despite the high concerns, there have been very few publicly reported instances of the flaw being exploited in a major breach. However, there are considerable fears that in many cases attackers may have already quietly exploited the flaw to gain access to enterprise networks and are waiting for an opportune moment to strike.

Security experts have pointed to the ubiquity of the flaw and the difficulty involved in detecting it — Java files containing the flaw can sometimes be buried deep inside applications — as potential reasons for the slow remediation pace so far.

Rezilion said one issue is that many people are unwittingly using software that relies on vulnerable versions of Log4j either because they don't have visibility into their software components or are using vulnerable third-party software. The Log4j flaw has also proven to be challenging to detect in production environments.

**Tip of the Iceberg?**  
Perkal says that the 90,000 vulnerable servers that Rezilion found via a Shodan search contained open source components with obsolete — and therefore potentially vulnerable — versions of Log4j; components with up-to-date Log4j versions that contained evidence of use of previous, potential vulnerable versions; and public-facing Minecraft servers with vulnerable Log4j versions.

"There are probably a lot of servers running these applications on internal networks and hence not visible publicly through Shodan," Perkal says. "We must assume that there are also proprietary applications as well as commercial products still running vulnerable versions of Log4j."

Significantly, all the exposed open source components contained a significant number of additional vulnerabilities that were unrelated to Log4j. On average, half of the vulnerabilities were disclosed prior to 2020 but were still present in the "latest" version of the open source components, he says. Rezilion's analysis showed that in many cases when open source components were patched, it took more than 100 days for the patched version to become available via platforms like Docker Hub.

Nicolai Thorndahl, head of professional services at Logpoint, says flaw detection continues to be a challenge for many organizations because while Log4j is used for logging in many applications, the providers of software don't always disclose its presence in software notes. "So, many companies don't actually know if it is being used in their system or not," Thorndahl says.

Often, many applications are using old versions of Log4j that are no longer being supported and are vulnerable. "Very few, if any, companies have a \[configuration management database\] so detailed that it would show where they are using Log4j," he says.

Thorndahl expects there will be more attacks exploiting the flaw, even though there have been very few so far.

"Most likely what we will see down the line, maybe four months, maybe a year, as we have seen before, is that incidents will be disclosed \[where\] companies detected they have been breached and the Log4j vulnerability was used and they probably had access for a long period of time," he says.

Log4j Attack Surface Remains Massive

If security leaders focus on visibility and metrics, they can demonstrate their programs' value to company leadership and boards.

**Question: How do I report my security program's return on investment (ROI)?**

**John Ayers, Vice President of Product, Advanced Detection and Response, Optiv:** Measuring ROI for any security program really starts by stating early and clearly what the desired outcome is that a company is looking to achieve out of said program. This obviously varies on a program-by-program and company-by-company basis. What a $40 billion financial services organization and a $500 million manufacturing organization view as ROI when it comes to security is certain to vary.

When it comes down to it, however, both of those organizations are looking to reduce and manage their risk. The fundamental goal, despite wildly different budgets and maturity levels, is the same.

How can we do that?

*   By transforming where data lives.
*   By implementing asset (devices or data sources) management.
*   By implementing new frameworks, such as zero trust or managed extended detection and response (MXDR).

But those are costs, right? How does that improve security value? Because we can measure the data, and we can report on it and the associated metrics. If you can feel more comfortable with your security program, great, but if you can't measure it or see results, then how do you know? You have to be able to validate your programs via monitoring and data detection.

Examples of these metrics can come in many forms. From a reactive perspective, we're talking about things such as the total number of security incidents over time by type, mean time to detect (MTTD), mean time to resolve (MTTR), intrusion attempts over time, and number of unidentified devices on network.

From there, we lean into what I call "proactive metrics." These are metrics established to gauge how well training and vulnerability management are performing. Examples include phishing test success rate, security awareness completion rate, average number of days to patch, percentage of fully patched devices on network, and number of security incidents reported by staff.

Too often, we get caught in the "shiny object" issue, where we expect everything new to deliver in the exact way we want it — and this goes for technology products, too. Rarely, if ever, can a technology product alone deliver a holistic ROI.

If security leaders are focused on visibility and reporting on what their teams can discover, they can demonstrate to company leadership and boards that their organizations can quickly detect and respond to potential threats with people, process, and technology and rapidly re-establish business normalcy.

How Do I Report My Security Program's ROI?

Acquisition will add Internet-facing attack surface mapping and monitoring to Tenable's internal asset management products.

Tenable today announced it will add external attack surface management to its various cybersecurity offerings with a $44.5 million acquisition of Bit Discovery.

The company said it will fold Bit Discovery's Internet-facing system security capabilities into its existing portfolio of internal asset management products to offer a more comprehensive attack surface view.

“Whatever is visible on the internet is very likely to be the first target and the hardest thing for organizations to continuously see and assess," Tenable's chief technology officer Glen Pendley said in a statement announcing the deal. "We believe attack surface management is vital to modern cybersecurity and an integral part of our vulnerability and Cyber Exposure solutions."

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Tenable Acquires External Attack Surface Management Vendor for $44.5M

The move to IaC has its challenges but done right can fundamentally improve an organization's overall security posture.

Infrastructure as code (IaC) has become a core part of many organizations' IT practices, with adoption of technologies like HashiCorp's Terraform and AWS CloudFormation increasing rapidly. The move to IaC sees companies moving away from either manually configuring servers or using imperative scripting languages to automate those changes and toward a model in which declarative code is used to outline a resource's preferred final state.

As with any change in approach to IT, there are security considerations to understand. The move to IaC presents some risks along with opportunities to improve the way companies secure their environments. Given IaC's key role in configuring the security parameters of an organization's systems and the speed at which a flawed template could be rolled out across a large number of systems, ensuring that good security practices are adhered to is vital to making the best use of this technology.

**IaC Security Risks and Opportunities**  
With the move to IaC, there are new security risks to consider. The first is secrets management. When creating and managing resources, credentials will often be needed to authenticate to remote systems; when IaC code is written to automate these tasks, there is a risk that credentials or API keys may be hard-coded into the code. Care should be taken to ensure that proper secrets management processes are followed to avoid this. Secrets should be held in a secure location, such as a cloud key management service (KMS), and retrieved on demand by scripts as they run.

A second risk is that misconfigurations may creep into the IaC templates — for example, if code is copy/pasted in from an external source — and then propagate throughout an environment quickly as the IaC is used. Avoiding this risk requires both automated and manual review, as with any other source code.

The opportunity inherent in moving to IaC-driving environments is that once all of your infrastructure is defined in code, it's possible to apply common automated linters and review tools to it to ensure that good practices are followed. Tooling can draw from common libraries of good practice and be supplemented with custom rules that apply organization-specific practices.

Additionally, with an IaC-based approach, all configurations should be stored in version- controlled source code repositories. This provides improved tracking of changes so that companies can track modifications over time and also ensure appropriate access control and that auditing is in place.

Lastly, IaC-based deployment means that test environments should be able to effectively mirror production, meaning that security testing can be safely conducted with higher confidence that any results will be meaningful in production.

**IaC Technology Stacks**  
There are a variety of options for IaC. Typically, large organizations will use many of these at the same time, as different tools have different strengths and weaknesses.

Terraform from HashiCorp is one of the most widely used IaC toolsets. It has the advantage of being open source and not tied to any one cloud platform or infrastructure provider, meaning that it works across a range of environments.

Unsurprisingly, the major cloud service providers also have IaC toolsets that focus on their clouds. Amazon's CloudFormation, Microsoft's ARM and Bicep, and Google's Cloud Deployment Manager all provide a means for users of that company's cloud to take advantage of the IaC paradigm.

Another popular option for cloud-native IaC is Pulumi, which allows developers to use programming languages they already know (e.g., JavaScript or Golang) to write their IaC templates.

**IaC Review Tools**  
There are a number of open source tools that can help with the process of security reviews of IaC code. These tools take a similar approach in providing a rule set of common security misconfigurations for a given set of IaC languages. In addition to the main IaC format, some of these tools will review other formats, like Kubernetes manifests and Dockerfiles. Some of the commonly used tools in this arena include the following:

*   Trivy is a vulnerability and misconfiguration scanner that includes rules from the tfsec and cfsec projects covering Terraform and CloudFormation, as well as a set of rules for Kubernetes and Docker. It can be easily integrated into a CI/CD pipeline and run by developers as part of the coding environment.
*   Checkov is a tool written in Python that covers a wide range of IAC languages, including Terraform, CloudFormation, Azure Bicep and ARM, and Kubernetes manifests. It also helps with the challenge of ensuring that IaC files don't hard-code secrets by scanning for instances where this can occur.
*   Terrascan is another popular option for IaC scanning. Despite the name, it supports a range of IaC formats in the same way as Trivy and Checkov. Similarly to Trivy, Terrascan is written in Golang and can be integrated into CI/CD pipelines and run as a standalone program.

**Smoothing the Security Path**  
The move to IaC is well underway at a variety of organizations. While it does bring challenges, the process — if well handled — can fundamentally improve organizations' overall security posture by allowing all of their system configurations to be held in version-controlled source code repositories and regularly checked for misconfigurations.

Given the power of IaC, it is vital that its adoption be accompanied by strong security practices, with scanning and validation key to those processes. By using open source review tools like the ones mentioned above, companies can help to smooth their path in adopting this technology.

The Ins and Outs of Secure Infrastructure as Code

Lord previously spearheaded security for the Democratic National Committee and held leadership roles at companies including Yahoo, Rapid7, and Twitter.

The Cybersecurity and Infrastructure Security Agency has named Bob Lord to serve as a senior technical adviser to the Cybersecurity Division. 

Lord's deep cybersecurity experience includes time as chief information security officer (CISO) at Yahoo, a CISO-in-residence role at Rapid7, and as Twitter's first hire for its information security program. Most recently, Lord was the first chief security officer (CSO) for the Democratic National Committee. 

“Bob’s decades of experience and unparalleled expertise will be a great asset as we further strengthen our community partnerships, expand the Joint Cyber Defense Collaborative, and continue our work as the nation’s cyber defense agency to make us more resilient," CISA Director Jen Easterly said in a statement about the appointment this week.  "Bob and I share both a passion for helping Americans stay safe online and a dedication to raising the cybersecurity baseline across the nation. I’m super excited for the creativity he’ll bring to the team." 

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

CISA Taps Veteran CISO Bob Lord for Technical Adviser Role

With Web application programming interface (API) traffic growing quickly, the average cloud-focused company sees three times more attacks.

Driven by the popularity of agile development, the usage of Web application programming interfaces (APIs) has increased dramatically, leaving software-focused companies with larger, and more vulnerable, attack surfaces that can be exploited by threat actors.

Overall, API usage has soared in the past year, tripling to about 15,600 APIs per company, with traffic quadrupling to 820 million requests per year for the average firm, according to two recent reports. And where the application developers go, attackers follow: Over the past year, malicious API traffic has surged by almost a factor of seven, according to the "State of API Security" report published in March by Salt Security, an API security firm.

Between the changes in development and growing vulnerabilities exposed by third-party software components that could be exploited through APIs, attackers will continue to increasingly target the easy-to-use interfaces, says Elad Koren, chief product officer for Salt Security.

"Attacks are growing, because the attack surface is growing," he says. "But it's not just that. It's also issues like Spring4Shell and Log4j — all those new vulnerabilities are part of this new attack surface — and they \[threat actors\] are targeting all of these vulnerable surfaces."

The trends are the latest challenge for application security. Development teams continue to move quickly, usually not fully documenting the APIs created to link different application components in the cloud or over the network. The result is that companies do not know the extent of the their API inventory and whether those application interfaces are secure, says Sandy Carielli, a principal analyst with Forrester Research.

    

Source: Salt Security

No wonder, then, that API security has become a top-five briefing topic for the business analyst firm, she says.

"The growing \[malicious traffic\] certainly doesn't surprise me," she says. "As more organizations move to using APIs, a higher percentage of application traffic is through APIs, so naturally you are going to see more malicious traffic going through that channel."

**Taming the API Attack Surface  
**Much of the impetus behind growing API inventory and traffic is the shift to cloud-native and agile development methodologies. A typical sprint for application development sprints is two to three weeks, so a development team has dozens of opportunities to introduce API misconfigurations and vulnerabilities into a service or application, says Oz Golan, CEO and co-founder at Noname Security, an API security firm.

"As organizations drive their digital transformation processes faster and harder, more API vulnerabilities will surface and become exploited," he says. "Unless they slow down their business operations and do extensive testing, they are going to release and expose their operations to risks."

The average company has nearly 15,600 APIs and has seen a 41% rate of API security incidents over the past 12 months, according to "The 2022 API Security Trends Report," published by S&P Global Market Intelligence and sponsored by Noname Security. However, those findings are complicated by the different yardsticks that API security vendors use to collect their data, including survey results, which are notoriously malleable. Salt Security, for example, found that the average customer had 135 APIs and a 95% rate of API security incidents, according to its "State of API Security" report, published in March.

While the numbers differ — sometimes significantly — both reported significant growth in relative API usage among their customers and relative growth of malicious API traffic.

**Hacking the API Security Challenge  
**For that reason, companies need to fully account for their own APIs and their employees' API usage, including API source, destination, type, data sensitivity, owner, and whether the API access requires authorization. So far, companies have not done a great job of keeping track of their API inventories, Forrester Research's Carielli says.

"In an ideal world, you would have your development team creating specification files for every API and keeping them up to date," she says. "We don't live in an ideal world. A lot of the discovery tools have to analyze traffic and do pre-release testing on APIs to make sure that you have the right controls and that they are being managed well."

The steps for securing APIs track closely with application security overall. Focusing on secure design and threat modeling means heading off vulnerabilities before they grow into significant — and expensive-to-fix — issues. Testing and monitoring API usage following deployment is just as important to gather data on attackers and to protect against issues not discovered during development, says Salt Security's Koren.

Fixing as many of the security issues as possible by considering API security during the design phase is important, but runtime security is just as necessary, because it gives application owners peace of mind and visibility into attackers' tactics, he says.

"Today, it is very important to have that pipeline security for the left side — the development side — but it is not interchangeable with runtime security," Koren says. "You will never ever, no matter how good your tools are, catch all the issues you have during the development phase. You have to have the runtime, because they are not interchangeable."

API Attacks Soar Amid the Growing Application Surface Area

The FBI warns that ransomware targets are no longer predictably the biggest, richest organizations, and that attackers have leveled up to victimize organizations of all sizes.

As the cyber dimension of the Ukraine conflict erupted, demonstrating the ungoverned and unstable nature of full-on cyberwar, a parallel ransomware alert from the US government got comparatively scant coverage. But it, too, merits attention.

The alert served as a reminder of the two species of cyber threat: the unpredictable, spinning-pinball threats that can lurch out of control and pulverize innocents in random fashion — and the intricately designed, coolly targeted threats meant to ransack a particular organization's servers and perhaps its bank account.

The Ukraine clash may generate plenty of damage of the first type. Indeed, it may already be doing so. But while that conflict progresses, the second type of threat, epitomized by ransomware, is taking no holidays.

**A Formal Alarm**  
Issued in February, days before hostilities broke out between Russia and Ukraine, the Joint Cybersecurity Advisory from the FBI, CISA (the Cybersecurity and Infrastructure Security Agency), and the NSA sounded a formal alarm about "an increase in sophisticated, high-impact ransomware incidents against critical infrastructure organizations globally."

Attack targets are no longer predictably the biggest, richest organizations, according to the report. Ransomware groups have learned to infiltrate enterprise SaaS platforms and exploit them as hubs for firing off waves of malevolent executables at scale, victimizing platform clients, both large and small. According to the advisory, the FBI in 2021 "observed some ransomware threat actors redirecting ransomware efforts away from 'big-game' and toward mid-sized victims to reduce scrutiny." The FBI’s counterpart agencies in the UK and Australia, the National Cyber Security Centre (NCSC-UK) and Australian Cyber Security Centre (ACSC), concurred that organizations "of all sizes" suffered ransomware attacks throughout the year.

On the one hand, in this national security sphere, any additional recognition or investment at the top of government is overdue and cannot hurt. On the other, recognition does not mean the government has the reach or means to protect you — something the two species of cyber threat have in common.

**Who's in Charge?**  
One early, grim lesson of the Ukraine cyberwar is that no authority is firmly in charge and no government agency can consistently shield its citizens from blowback. Governments aren't even supervising some of the cyber combatants: freelance hacktivists like Anonymous, jamming Russian broadcast channels and the Kremlin website, answer to their own moral code, not a central command in Kyiv. And Ukraine's own "I.T. Army" is a barely directed worldwide corps of digital adepts connecting via Telegram to wreak cyber havoc.

What could go awry in that woolly, infinitely multilateral conflict sphere? No national cyber defense framework can keep innocent parties from becoming collateral damage.

The thing is, no government ransomware policy can unilaterally create a safer, more secure environment either.

Government cannot remake the trend throughout the private sector toward hybrid compute workloads. With a thoughtful hybrid strategy, an enterprise hosts its more sensitive workloads on-premises, and deploys less critical resources to a more economical third-party public cloud provider. The practice may yield savings, but with the simultaneous concern that roles and responsibilities once firmly controlled by data center operators may be much less clearly delineated. Involving cloud providers makes evaluating risk and modeling effective security controls more complex. It must be done, but it is up to individual organizations.

Government can recommend private interests perform overdue software updates or implement dual-factor authentication protocols. But those best practices will never be mandated by act of Congress; they are up to individual organizations.

Influencers from security agencies can keynote one conference after another, emphasizing today's key challenge for CISOs everywhere: threat visibility across the environments they're laboring to secure. CISOs can't defend against threats they can’t see. Total, real-time visibility into IT and cloud infrastructure is the ideal; the reality is, almost all organizations lack it. They're unaware of what devices and individuals are connected, with what access to sensitive systems and data. Visibility into third-party access to company systems also remains poor. To spot ransomware before it digs in and does damage, CISOs should be adopting security solutions that visualize an entire attack surface. But the initiative to make such visibility a top priority must come from CISOs themselves.

**Familiar Advice**  
The conclusions drawn by the Joint Cybersecurity Advisory are recommendations, not directives — and if you've been tracking the rise of ransomware, they feel familiar: Keep systems and software up to date. Train workers to spot phishing links and dodgy attachments. Implement 2FA. Back up your data. We have heard this advice before; the advisory simply delivers it from a higher-echelon source.

That doesn't mean it's dismissible — quite the contrary. But what is really important is how organizations everywhere react. The Ukraine conflict is erasing the last vestiges of complacency about the destabilizing, out-of-control threat of cyber weapons. We should do all we can to see that this cybersecurity advisory does the same for the threat of well-controlled, ruthlessly targeted cyber piracy.

Cyber Conflict Overshadowed a Major Government Ransomware Alert

Apostro's system will monitor all transactions to identify malicious behavior that can cause damage to DeFi protocols.

WARSAW, Poland, April 26, 2022 /PRNewswire/ -- Apostro is a recently established European startup building a risk management platform to improve the economic security of DeFi protocols. It offers a fresh approach to DeFi security by implementing proven risk management practices and tools from traditional finance.

Many DeFi projects have become victims of exploits, losing millions of USD worth of crypto every year. The first quarter of 2022 is already setting a new record with $1.3 billion stolen in illicit transactions. While the total value locked in DeFi has already surpassed $200 billion, loopholes in the infrastructure and deficiency of risk management tools allow bad actors to steal money. This stalls DeFi adoption as institutions and big players want more security assurances before considering the space as a safe portfolio diversification option.

Currently, DeFi protocols rely on audits of their smart contracts, but this practice is insufficient when dealing with economic threats. Stress testing and formal verification can simply miss a potential logic backdoor, which gives hackers a way to steal funds by exploiting economic opportunities rather than technical weaknesses.

To deal with such threats, Apostro is building a system that will analyse smart contracts' business logic and typical interactions with the protocol by an average user. It will monitor all transactions to identify malicious behaviour that can cause damage to the protocol.

Apostro can also prevent or delay an exploit by complicating its execution by setting limits on the amount of available liquidity in one block or transaction. Simultaneously, it will alert the developers of any threats to a protocol's security, allowing them to take necessary measures to mitigate the negative impact.

_'We help minimise the impact of economic attacks on DeFi systems. Technical attacks are more or less sorted out by now: there are many good auditors, and most issues are relatively easy to catch. With economic issues, however, there are no ideal solutions available yet,'_ \- states Tim Ismiliaev, founder and CTO at Apostro.

**About Apostro**

Apostro is a risk management platform designed to track, mitigate and prevent economic smart contract exploits. Headquartered in Warsaw, Apostro utilises proven risk management practices with onchain and market data analysis to enhance security of Web3 protocols.

Introducing Apostro: A Risk Management Platform for Web3 Security

SecurityScorecard's Cyber Risk Quantification portfolio helps customers understand the financial impact of a cyber-attack.

NEW YORK, April 26, 2022 /PRNewswire/ -- SecurityScorecard, the global leader in cybersecurity ratings, today introduced its Cyber Risk Quantification (CRQ) capabilities that will enable customers to understand cyber risk in financial terms, enabling organizations to bring cyber risk into holistic business risk analysis, and assisting organizations in a cost-benefit analysis of cyber investment options. SecurityScorecard's CRQ capabilities help customers understand the financial impact of a cyber-attack, gain insight into the probability of incidents over time and quantify the reduction in expected losses if issues are resolved. The SecurityScorecard CRQ capabilities will be included in the company's risk intelligence platform, the industry's first holistic offering that proactively protects organizations from every angle.

"Executives and boards of directors lack the ability to connect cybersecurity budgets to business outcomes, hindering the CISO's ability to justify their cybersecurity budgets. By grounding risk quantification in SecurityScorecard's expansive data, we are bringing cyber security to the forefront of daily decision making," said Prashant Pai, Senior Vice President and General Manager Strategic Initiatives, SecurityScorecard. "Our goal is to help our customers make informed decisions on how to raise the bar on their cybersecurity defenses with optimized investments, and we will continue to partner with leading CRQ thought leaders to provide the options they are looking for."

To deliver the combined insights of SecurityScorecard's cybersecurity ratings data and leading risk models, SecurityScorecard is partnering with a number of leading CRQ thought leaders and developers including ThreatConnect, and RiskLens, which created Factor Analysis of Information Risk (FAIR™). With multiple views of risk available through the lens of different CRQ frameworks, risk managers can determine which framework is the best fit for their business.

With cyber risks becoming increasingly prevalent, boards of directors and executives need to evaluate those risks and become more involved with cybersecurity. Effectively reporting to the board is a key component of every security leader's job.

According to Gartner® The 2022 Board of Directors Survey, 88% of respondents viewed cybersecurity as a business risk, while 72% stated they are focused on aligning risk, strategy and performance to drive business resilience.1

"The CRQ integration between RiskLens and SecurityScorecard will finally give organizations of all sizes what they need to effectively understand and manage cyber risk: an automated, 'dollars and cents' view of cyber risk," said Nick Sanna, CEO, RiskLens. "Based on the FAIR cyber risk quantification standard, on industry benchmark data and on their SecurityScorecard security rating, organizations can now make risk-informed business decisions."

"ThreatConnect is excited to partner with SecurityScorecard as the combination of their external cybersecurity risk posture and the power of ThreatConnect Risk Quantifier (RQ) connects the outside and inside views for an organization, giving them a 360 degree perspective of the risk to their organizations," said Jerry Caponera, Vice President of Cyber Risk Strategy for ThreatConnect. "Applying ThreatConnect's statistical and machine learning algorithms to the SecurityScorecard data enables customers to easily visualize their risk and, more importantly, prioritize which factors should be improved based on financial risk reductions."

SecurityScorecard's CRQ portfolio enables executives, CISOs and risk managers to obtain a comprehensive view of their cyber risk that enables them to define cyber risk in a universally understood metric and embed those insights into decisions across the organization.

SecurityScorecard's CRQ capabilities also offer:

*   **Scalable risk quantification methodology -** With continuous monitoring of over 12 million companies, SecurityScorecard grounds its analysis in a consistent cybersecurity data-driven approach to deliver a real-time view of risk.
*   **Contextualized view of cyber risk -** SecurityScorecard directly ties financial impact to the security issues that drive losses.
*   **Multiple risk quantification frameworks–** Multiple risk frameworks are integrated into the CRQ capabilities to ease the evaluation and implementation of CRQ.

SecurityScorecard enterprise customers can learn more and gain early access to SecurityScorecard's CRQ capabilities by clicking here.

**About SecurityScorecard  
**Funded by world-class investors including Evolution Equity Partners, Silver Lake Waterman, Sequoia Capital, GV, Riverwood Capital, and others, SecurityScorecard is the global leader in cybersecurity ratings with more than 12 million companies continuously rated. Founded in 2013 by security and risk experts Dr. Aleksandr Yampolskiy and Sam Kassoumeh, SecurityScorecard's patented rating technology is used by over 30,000 organizations for enterprise risk management, third-party risk management, board reporting, due diligence, cyber insurance underwriting, and regulatory oversight. SecurityScorecard is the first cybersecurity ratings company to offer digital forensics and incident response services, providing a 360-degree approach to security prevention and response for its worldwide customer and partner base. SecurityScorecard continues to make the world a safer place by transforming the way companies understand, improve and communicate cybersecurity risk to their boards, employees and vendors. Every organization has the universal right to their trusted and transparent Instant SecurityScorecard rating. For more information, visit securityscorecard.com or connect with us on LinkedIn.

1 _Gartner, "Roadmap to Renewal: The 2022 Board of Directors Survey", Partha Iyengar, published October 28, 2021, ID G00728156._

_GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved._

SOURCE Security Scorecard

SecurityScorecard Launches Cyber Risk Quantification Portfolio

This Tech Tip reminds developers and security teams to check what version of Java they are running. Whether they are vulnerable to the ECDSA flaw boils down to the version number.

Oracle has patched a critical vulnerability in newer versions of Java that adversaries could exploit to forge security certificates, digital signatures, two-factor authentication messages, and authorization credentials. The security fix was included in the April 2022 Critical Patch Update released last week.

The issue (CVE-2022-21449) exists in the way the Elliptic Curve Digital Signature Algorithm (ECDSA) is implemented in Java versions 15, 16, 17, and 18. Defenders should check what version of Java they are running and update. Java 15 and 16 are no longer supported, and the issue has been fixed in Java 17.0.3 and 18.0.1.

**1\. Check and update:** Check what version of Java is running with the command _java -version_ (or _java.exe -version_ on Windows).

It’s worth checking manually because it’s possible to have multiple Java versions installed on the system simultaneously, since there could be different versions of the Java Development Kit (JDK) and Java Runtime Environment (JRE).

For many organizations, the fact that the vulnerability exists in only the latest versions may be good news, since the adoption for Java 15 and newer remains fairly low.

**2\. Pay attention to advisories:** Java is widely used, so enterprise teams will need to keep an eye out for advisories from app and device manufacturers on whether they are affected and update as needed. The vulnerability doesn't just affect Internet-accessible Java servers and client software – any device that relies on digitally signed data is potentially affected, even if it is an internal device.

**Details of the Flaw**  
ECDSA uses elliptic curve cryptography to authenticate messages. A missing sanity check in ECDSA means that adversaries can pass the signature check by presenting a memory buffer filled entirely with zeros. This means adversaries can easily forge TLS certificates and handshakes, which would result in communications being intercepted and potentially modified, wrote Neil Madden, the ForgeRock researcher who discovered the vulnerability. There is no need for an attacker to try to figure out the private key in order to match the valid digital signature.

The vulnerability affects "almost all WebAuthn/FIDO devices in the real world," Madden wrote. "Many OIDC providers also use ECDSA-signed JWTs."

**Limited to Newer Versions**  
Back in November, when Madden reported the flaw to Oracle, ForgeRock provided customers with two workarounds – to deploy products with Java 11 or to configure the Java Virtual Machine to use Bouncy Castle as the preferred cryptographic provider.

The fact that the vulnerability is present only in the newer versions may mean the impact of this flaw may be blunted, as adoption rates for Java 15 and newer remain fairly low. The fifth Developer Ecosystem Survey, released in July 2021, found that just 14% of developers were using Java 15 (the most recent version at the time of the survey). The most widely used version is Java 8 (72%), followed by Java 11 (42%). Java 11 was the long-term-support version.

Even though Oracle assigned a severity rating of 7.5 out of 10, Madden said the severity should be a 10, "due to the wide range of impacts on different functionality in an access management context." There are claims of the flaw being the "crypto bug of the year."

_Editor’s Note: This piece was updated to remove the reference that some Yubikeys may be affected. Yubico sent the following statement to Dark Reading:_

_"Yubico is aware of this issue and how it affects Oracle Java 15+ and OpenJDK, including other JDKs derived from OpenJDK. This vulnerability is not in the YubiKey firmware or the WebAuthn protocol, and we recommend organizations and individuals patch their Java deployments. Yubico will continue to provide further guidance on best practices as appropriate in the future."_

Source

DARKReading