What 5,800+ pentests show us: Companies have been struggling with the same known and preventable security bugs year over year. Bandwidth stands at the heart of the problem.

Cybercrime can cause major disruption when it comes to the sustainability and long-term success of companies. Teams want to have robust security but often struggle to meet that objective. It's crucial for security professionals to leverage insights into emerging trends in cybersecurity to pinpoint which vulnerabilities put organizations at the greatest risk, and Cobalt's "State of Pentesting" reports explore how to achieve efficiency to strengthen security.

The "State of Pentesting 2022" surveyed 602 cybersecurity and software development professionals and analyzed data from 2,380 pentests conducted over the course of 2021 to pull key insights that are relevant to security and development teams when it comes to fixing vulnerabilities.

As a result of the data collected, the top five most common vulnerability categories outlined in this year's "State of Pentesting" report include:

1.  Server Security Misconfigurations
2.  Cross-Site Scripting (XSS)
3.  Broken Access Control
4.  Sensitive Data Exposure
5.  Authentication and Sessions

Surprisingly — yet predictably — these vulnerability categories have stayed at the top of the list for at least the last five years in a row. They're also recognizable to those who are familiar with OWASP Top 10 list for Web Application Security Risks.

The majority of these findings are connected to missing configurations, outdated software, and a lack of access management controls — all common and easily preventable security flaws. So, what's holding companies back from preventing well-known security flaws? Why does this come as a surprise?

Because these flaws are common and appear to be less of a major threat, they are often overlooked as teams deal with talent shortages and increased workload. Standing alone, these issues might not cause a lot of concern, but they can build up to create more critical situations that are difficult to tackle and remediate.

Security and development teams need access to more resources and talent to prevent and fix common vulnerabilities in the future. Talent shortages have impacted security programs as teams are struggling to maintain security standards and vulnerabilities are more likely to go undetected and unremedied.

Findings from the "State of Pentesting 2022" point to key strategies organizations can implement for vulnerability management and retention.

1\. **Focus on learning:** Provide the right security training and resources with teams such as the OWASP Top 10 list and the "State of Pentesting" reports_._

2\. **Review your security configurations:** Consistently monitoring access/user matrixes, SSL certificates, software versions, and security headers can help with the top vulnerabilities we see each year. 

3\. **Clearly communicate risk:** It's important to show leadership and team members how insufficient resources and open vulnerabilities of all types can turn into much bigger security problems for the broader organization.

4\. **Outsource to agile vendors:** Find vendors who help you to achieve your security goals, integrate well with your systems, and create the right efficiencies to bring to your workflows.

Security and development teams have clearly been struggling with the same vulnerabilities for five years in a row, and although this can come as a surprise, there are steps teams can take to break the trend.

In addition to these tips for vulnerability management and retention, security assessments like pentesting can be a useful additional resource for development teams to patch vulnerabilities and remediate risk. Pentesting can help defend organizations against vulnerabilities that disrupt the organizational flow, reputation, financial circumstances, and more.  

**About the Author**

    

  
Jay Paz is Cobalt's Senior Director of Delivery. He has more than 12 years of experience in information security and 19+ years of information technology experience, including system analysis, design, and implementation for enterprise-level solutions. At Cobalt, he lays the groundwork for innovation and scale as he oversees operations and day to-day management for Cobalt's pentester community.

5-Year Vulnerability Trends Are Both Surprising and Sadly Predictable

Here's how to reduce security risk and gain the benefits of open source software.

Security has long been a point of concern in the open source community. If not managed carefully, the same openness that allows innovative code contributions from global users can also present vulnerable attack surfaces for malicious actors. In fact, when asked about roadblocks preventing their organizations' use of open source, respondents to Anaconda’s 2021 State of Data Science report cited "Fear of CVEs, potential exposures, or risks" (41%) and "Open source software is deemed insecure, so it's not allowed," (26%) among other concerns.

Yet open source drives innovation, and there are ways to dramatically decrease the potential risks that arise from the use of open source software. This is why many organizations take a “best of both worlds” approach, adopting open source while prioritizing security measures.

If you think of open source security as a spectrum, with “no security controls” on one end and “locked-down controls” on the other, technically advanced organizations tend to fall somewhere in the middle. Here are some lessons you can learn from their approaches.

**1\. Everyone Should Be Involved  
**Setting up open source security parameters should not be left solely up to the IT and data science teams. To be successful, you need buy-in from the whole organization, including executive leadership. Together, leaders must consider the tradeoffs of security risks and innovation rewards, and create a framework to define an acceptable level of risk for using open source software.

In creating security frameworks across organizations, preventative and containment-based perspectives are necessary. Since open source projects are open to globally dispersed contributors, the code doesn’t have the same level of built-in security as private vendor applications. For that reason, you need to have a proactive approach to security, setting clear risk parameters and pre-emptively implementing safeguards in the event of a breach. A key aspect of the latter component is the idea of a software bill of materials (SBOM), which lists the origin of all the code running in each application or package. With an SBOM in place, when an incident like last year’s Log4j incident occurs, you can quickly identify which areas of your infrastructure are impacted.

**2\. Take a Nuanced Approach  
**If the security framework is a hard-and-fast set of nonspecific rules, you’ll likely run into two problems. First, you risk security becoming an exercise of box-checking, where practitioners aren’t necessarily thinking critically about their actions and are just crossing items off a security checklist. Second, you’ll likely miss out on the best innovation open source has to offer.

Of course, there are a few areas where you want to be very firm in your security protocols, such as implementing access controls and firewalls and using only repositories that have been built on or are being mirrored from a secure environment.

However, there are other areas where you can introduce some nuance, such as parameters around acceptable CVE scores. For example, there are tens of thousands of open source packages in the Python realm alone. If you set automated filters that allow your data scientists to use only packages with a CVE score of 6 or lower, you could miss out on a package with key functionality that has a score of 7 but whose vulnerability would not be exposed in your particular use case.

Another approach is to establish different risk tolerance levels in development and production environments. This gives developers and data scientists more freedom to explore packages in the dev environment, which can be separated behind a firewall. Then, when it comes time to move workflows into production, you can enforce stricter security protocols. If a given package doesn’t meet those requirements, it’s an opportunity to explore whether to introduce more nuance into the rules.

**3\. Give Back to the Open Source Community  
**It might be tempting to think that forking an open source project and bringing the fork inhouse would help mitigate security issues by giving you tighter control over the code distribution. However, that path has several downsides, as noted in a recent memorandum from the Department of Defense. These include increased support risk (due to the loss of several pairs of eyes checking over code), decreased access to community-driven innovations, and increased code maintenance costs.

Instead of forking a project, many industry leaders work closely with the open source community to help surface, mitigate, and patch vulnerabilities when needed. Most projects rely on volunteer effort, and any resource contributions (including developer time, monetary support, and in-kind donations like server space) will benefit everyone who uses a project.

**Conclusion**Security is a journey, and everyone progresses at a different pace. It’s important to implement systems and strategies that work for your industry, resource level, and expertise. At the same time, it’s worthwhile to continually refine your security posture and adopt more sophisticated practices. The cyber threat landscape is ever evolving, so it’s incumbent on us as technologists to evolve and adapt so that we can stay protected, secure, and one step ahead.

How Industry Leaders Should Approach Open Source Security

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.

Source

DARKReading