The latest critical bug is exploitable in dozens of ManageEngine products and exposes systems to catastrophic risks, researchers warn.

Several Zoho ManageEngine IT management products require patching against a critical unauthenticated remote code execution (RCE) that researchers warn is under active attack by malicious threat actors.

On Jan. 10, ManageEngine released an update against the bug, tracked under CVE-2022-47966, blaming it on "... an outdated third party dependence, Apache Santuario."

The security advisory adds that any of the two dozen ManageEngine products impacted are vulnerable if single sign-on is, or has ever been, enabled.

By Jan. 13, researchers at Horizon.ai provided indicators of compromise (IoCs). Now GreyNoise has observed malicious actors attempting to exploit the RCE over the past three days.

"IP addresses with this tag have been observed attempting to exploit CVE-2022-47966, an unauthenticated remote command execution vulnerability in multiple Zoho ManageEngine products," the security team reported.

Once the RCE is used to breach a system, that access could be used to create all sorts of havoc by threat actors, Horizon.ai analysts explained.

"ManageEngine products are some of the most widely used across enterprises and perform business functions such as authentication, authorization, and identity management," the Horizon.ai researchers added. "Given the nature of these products, a vulnerability such as this poses critical risk to organizations allowing attackers initial access if exposed to the internet, and the ability for lateral movement with highly privileged credentials."

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

Unpatched Zoho MangeEngine Products Under Active Cyberattack

Open source AI is lowering the barrier of entry for cybercriminals. Security teams must consider the right way to apply defensive AI to counter this threat.

In the wake of increasing concern about threat actors using open source AI tools like ChatGPT to launch sophisticated cyberattacks at scale, it's time for us to reconsider how AI is being leveraged on the defensive side to fend off these threats.

Ten years ago, cybersecurity was a different ball game. Threat detection tools typically relied on "fingerprinting" and looking for exact matches with previously encountered attacks. This "rearview mirror" approach worked for a long time, when attacks were lower in volume and generally more predictable.

Over the last decade, attacks have become more sophisticated and ever-changing on the offensive side. On the defensive side, this challenge is coupled with complex supply chains, hybrid working patterns, multicloud environments, and IoT proliferation.

The industry recognized that basic fingerprinting could not keep up with the speed of these developments, and the need to be everywhere, at all times, pushed the adoption of AI technology to deal with the scale and complexity of securing the modern business. The AI defense market has since become crowded with vendors promising data analytics, looking for "fuzzy matches": near matches to previously encountered threats, and ultimately, using machine learning to catch similar attacks.

While an improvement to basic signatures, applying AI in this way does not escape the fact that it is still reactive. It may be able to detect attacks that are highly similar to previous incidents, but remains unable to stop new attack infrastructure and techniques that the system has never seen before.

Whatever label you give it, this system is still being fed that same historical attack data. It accepts that there must be a "patient zero" — or first victim — in order to succeed.

The "pretraining" of an AI on observed data is also known as supervised machine learning (ML). And indeed, there are smart applications of this method in cybersecurity. In threat investigation, for example, supervised ML has been used to learn and mimic how a human analyst conducts investigations — asking questions, forming and revising hypotheses, and reaching conclusions — and can now autonomously carry out these investigations at speed and scale.

But what about finding the initial breadcrumbs of an attack? What about finding the first sign that something is off?

The problem with using supervised ML in this area is that it's only as good as its historical training set — but not with things it's never seen before. So it needs to be constantly updated, and that update needs to be pushed to every customer. This approach also requires the customer's data to be sent off to a centralized data lake in the cloud, for it to be processed and analyzed. By the time an organization knows about a threat, often it's too late.

As a result, organizations suffer from a lack of tailored protection, large numbers of false positives, and missed detections because this approach is missing one crucial thing: the context of the unique organization it is tasked with protecting.

But there is hope for defenders in the war of algorithms. Thousands of organizations today use a different application of AI in cyber defense, taking a fundamentally different approach to defend against the entire attack spectrum — including indiscriminate and known attacks but also targeted and unknown attacks.

Rather than training a machine on what an _attack_ looks like, _unsupervised_ machine learning involves the AI learning the _organization_. In this scenario, the AI learns its surroundings, inside and out, down to the smallest digital details, understanding "normal" for the unique digital environment it's deployed in to identify what's _not_ normal.

This is AI that understands "you" in order to know your enemy. Once considered radical, today it defends over 8,000 organizations worldwide by detecting, responding, and even preventing the most sophisticated cyberattacks.

Take the widespread Hafnium attacks exploiting Microsoft Exchange Servers last year. These were a series of new, unattributed campaigns that were identified and disrupted by Darktrace's unsupervised ML in real time across many of its customer environments without any prior threat intelligence associated with these attacks. In contrast, other organizations were left unprepared and vulnerable to the threat until Microsoft disclosed the attacks a few months later.

This is where unsupervised ML works best — autonomously detecting, investigating, and responding to advanced and never-before-seen threats based on a bespoke understanding of the organization being targeted.

At Darktrace, we have tested this AI technology against offensive AI prototypes at our AI research center in Cambridge, UK. Similar to ChatGPT, these prototypes can craft hyperrealistic and contextualized phishing emails and even select a fitting sender to spoof and fire the emails away.

Our conclusions are clear: As we start to see attackers weaponizing AI for nefarious purposes, we can be certain that security teams will need AI to fight AI.

Unsupervised ML will be critical because it learns on the fly, building a complex, evolving understanding of every user and device across the organization. With this bird's-eye view of the digital business, unsupervised AI that understands "you" will spot offensive AI as soon as it starts to manipulate data and will make intelligent microdecisions to block that activity. Offensive AI may well be leveraged for its speed, but this is something that defensive AI will also bring to the arms race.

When it comes to the war of algorithms, taking the right approach to ML could be the difference between a robust security posture and disaster.

**About the Author**

    

Tony Jarvis is Director of Enterprise Security, Asia-Pacific and Japan, at Darktrace. Tony is a seasoned cybersecurity strategist who has advised Fortune 500 companies around the world on best practice for managing cyber-risk. He has counseled governments, major banks, and multinational companies, and his comments on cybersecurity and the rising threat to critical national infrastructure have been reported in local and international media, including CNBC, Channel News Asia, and The Straits Times. Tony holds a BA in Information Systems from the University of Melbourne.

A New Era Is Dawning in Cybersecurity, but Only the Best Algorithms Will Win

Security professionals must update their skill sets and be proactive to stay ahead of cybercriminals. It's time to learn to think and act like an attacker to cope with the cyber "new normal."

2022 was a turbulent year for cybersecurity teams. Through the pandemic, cybercriminals took advantage of misaligned networks as businesses moved to remote work environments. Attacks globally increased by 125% through 2021 and continued upward in 2022. 

It's clear old practices are no longer working. Defensive, reactive, and recovery postures aren't fit-for-purpose in the face of an ever-evolving wave of sophisticated attacks. Outmanned, underskilled, and overwhelmed security teams are at the breaking point as they struggle to cope with this cyber "new normal."

A new proactive offensive approach is needed to take the fight to cybercriminals rather than waiting to be hit. For security professionals, this means learning to think and act like a hacker.

Only by understanding the latest techniques and methods being used by bad actors, and continuously updating your skill set accordingly, can you hope to stay ahead of cybercriminals and find system vulnerabilities before they do.

The hacker mindset isn't _just_ for frontline security teams, though. It should be an organizational-wide shift in approach that's all about looking ahead, using out-of-the-box thinking, and responding to threats creatively.

So this could be the HR team "hacking" its recruitment process by removing restrictive hiring criteria to unlock a new pool of cyber talent, just as much as it could be the cybersecurity team hacking its own network to find flaws in the code.

I've identified several potential danger areas that I believe will present challenges to businesses this year.

**AI Algorithms**

AI has made it onto the front pages recently with the success of ChatGPT and social media users sharing their new Lensa avatars across platforms. It's safe to say that AI has reached consumers on all fronts and mass adoption isn't unrealistic. At the same time, AI adoption within businesses has skyrocketed and will continue to do so. The cyber-risk with AI is that it's an algorithm and, like any algorithm, it can be manipulated and hacked into.

Even a tiny change to AI can affect the output, and, generally, AI algorithms aren't able to provide the reasoning behind their conclusions. Therefore, any manipulation to AI can be very difficult to detect. On a small scale, this means tampered algorithms could overwhelm companies relying on AI-generated insights. On a larger, more dramatic scale, if cybercriminals learn how to hack into Facebook, Instagram, or Alexa algorithms, they could manipulate individuals.

**Targeting of On-Premises Data Centers**

2022 was a tough year for businesses, with the cost-of-living crisis crippling companies worldwide. One of the ways businesses are trying to cut costs is by moving back from cloud to on-premises storage. Cloud infrastructure on its own can be relatively affordable for businesses, but the cloud, configuration, architecture, and security skills required to run the infrastructure can be expensive.

However, for most smaller companies, the cloud can be more secure than on-premises data centers. But for these same companies, properly securing on-premises data centers can be overlooked, and if businesses are vulnerable, hackers will pounce. The reverse cloud migration means businesses will also need to dust off old security skills.

This year, I expect to see a growing demand for retro cybersecurity skills, as businesses revert to old, cheaper ways of working while cybercriminals use modern skills to hack into legacy technology.

**Internet of Things Devices: A Cybercriminal Playground**

This year, the number of IoT-connected devices is expected to increase to 43 billion worldwide, up by over 13% from 2022. This rate of growth is due to new sensors, more computing power, and reliable mobile connectivity across the world creating greater accessibility. In the UK alone, the average home has 10 connected IoT devices, and as adoption soars, security risks swell. This growth isn't only in the home with smart TVs, speakers, and cameras. Increasingly, business leaders are noting the power of IoT and embracing a number of new connected devices.

Yet, IoT devices are an easy target for cybercriminals, as they're vulnerable to network attacks. A threat actor could exploit an IoT device as an entry point, using it as a stepping-stone to launch a more sophisticated ransomware attack. More worryingly, cybercriminals could use IoT devices to inflict physical harm. For example, if solutions like smart locks or electronic doors are tampered with, this could represent a real risk to human life.

In short, if left unprotected, IoT devices could become a cybercriminal playground in 2023. That's why we'll see the emergence of IoT penetration testing and a greater effort to educate consumers on the vulnerability of their own devices.

**Cyberattacks Will Focus on Smaller Enterprises**

While high-profile ransomware attacks always make the headlines, I believe small to midsize enterprises (SMEs) will bear the brunt of cybercriminals' malice this year. The fact is many SMEs lack the budget for standard enterprise security practices. As recession looms, it's unlikely there will be further investment to resolve it this year, leaving businesses more vulnerable than ever.

SMEs are already an easy target for socially engineered phishing attacks, but this year cybercriminals will spot the weak links. This could cripple SMEs and lead to a domino effect among smaller businesses.

**Staff Training Is Key**

2023 has the potential to be a dark year for cybersecurity, which is why it's important for companies of all sizes to make sure their teams are trained with the latest skills (old and new) to fight cybercriminals. As the cyber-professional shortfall stands at 3.4 million, businesses must focus on reskilling and upskilling existing as well as new staff, and this training needs to be practical. Cybersecurity professionals must prevent and respond to attacks with real-life experience to be prompt and effective in their work. With hands-on training that goes beyond theory, they can evaluate attacks in real time, and know what needs to be done to prevent it.

Although budgets are tight, this isn't the time to cut back on security. Instead, more investment is desperately needed to prepare the cyber workforce of the future and protect businesses now.

Why Businesses Need to Think Like Hackers This Year

Standalone product provides permission insights for Active Directory security and compliance.

**MIAMI****,** **Jan. 17, 2023** **/PRNewswire-PRWeb/ --** Cygna Labs, a highly specialized software developer with a focus on serving enterprises worldwide and a leading provider of DDI, cloud security, and compliance technology, announced today the launch of a new standalone product Entitlement and Security for Active Directory, providing the ability to gather and report on the latest or historical point in time collections of Active Directory (AD) entitlements and group membership. Request a trial license key at https://cygnalabs.com/en/free-trial/ to evaluate the product.

Key benefits of Entitlement and Security for Active Directory include:

*   User and Group Access – Identify users or groups that have access rights in the environment and enable the verification of the appropriate permissions set for their role. Ensures permissions have been revoked for role changes or when someone leaves the organization.
*   Powerful Search Tools – Leverage the built-in Security Audit Reports to answer common inquiries or use the Entitlement Browser to search or create security audit reports interactively. The Security Permissions Search identifies permissions that are set too broad, such as everyone with full control permissions.
*   Permissions on AD Objects – Identifies the true effective permissions on AD objects and what has been set directly or expanded to all trustees.

Christian Ehrenthal, CEO, Cygna Labs, said, "Active Directory is the primary method to provide authentication and authorization at 90 percent of the Global Fortune 1000 companies and most organizations of all sizes. With Entitlement and Security for Active Directory, our customers worldwide can now take advantage of this critical insight to ensure continuous data protection and minimize the risk of business disruptions."

Morgan Holm, VP of security and compliance products, Cygna Labs, said: "AD security issues can result in costly service disruptions and potential data breaches or even non-compliance. Providing insight on entitlements, security and activities is key to our customers. Entitlement and Security for Active Directory provides complete visibility on access and activities to keep key on-prem and cloud systems operational and secure."

About Cygna Labs 

Cygna Labs is a software developer and one of the top three global DDI vendors. Many Fortune 100 customers rely on Cygna Labs' DDI products and services, in addition to its industry-leading security and compliance solutions, to detect and proactively mitigate data security threats, affordably pass compliance audits, and increase the productivity of their IT departments. For more information, visit https://cygnalabs.com.

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

Cygna Labs Introduces Entitlement and Security for Active Directory

Two of the vulnerabilities — in Azure Functions and Azure Digital Twins — required no account authentication for an attacker to exploit them.

Microsoft has fixed vulnerabilities in four separate services of its Azure cloud platform, two of which could have allowed attackers to perform a server-side request forgery (SSRF) attack — and thus potentially execute remote code execution — even without authentication to a legitimate account, researchers have found.

Researchers from Orca Security identified four Azure services vulnerable to SSRF — Azure API Management, Azure Functions, Azure Machine Learning, and Azure Digital Twins, they revealed in a blog post published Jan. 17. Further, they were able to exploit the flaws in Azure Functions and Azure Digital Twins by sending requests in the server's name even without having to authenticate to an Azure account, they said.

An SSRF allows an attacker to abuse a server-side application by making requests to read or update internal resources as well as submit data to external sources. This can allow for a host of disruptive activity on the network, including for threat actors to launch various attacks.  

This type of attack can be particularly dangerous in a cloud environment if attackers can use it to access the host’s Cloud Instance Metadata Service, or IMDS, "which exposes detailed information on instances — including host name, security group, MAC address, and user-data," explained Lidor Ben Shitrit, cloud security researcher at Orca Security, in the blog post. This allows attackers to retrieve tokens, move to another host, and even execute code, he added.

**Built-In SSRF Mitigations**

Fortunately in the case of the SSRF vulnerabilities discovered in Azure, the researchers could not exploit them to reach IMDS endpoints thanks to various SSRF mitigations — including setting specific requirements for accessing the IMDS endpoint and requiring an "Identity Header" for the App Service and Azure Functions — that Microsoft already has put in place on their cloud environment, they said.

"By implementing these measures, Microsoft has significantly reduced the potential damage of SSRF attacks on its Azure platform," Shitrit wrote.

However, the flaws still could have been exploited to perform other threat activity, he said. This includes scanning local ports and finding new services, endpoints, and files, thus "providing valuable information on possibly vulnerable servers and services to exploit for initial entry and the location of potential information to target," Shitrit wrote in the blog post.

"The biggest takeaway ... is that a cloud service, if not properly secured, could be exploited by malicious actors as a means to discover sensitive internal endpoints and other services," he tells Dark Reading. This can result in a significant cloud security breach, Shitrit says.

The researchers discovered the four flaws separately over a two month period between mid-October and mid-December, and disclosed each of them to Microsoft soon after they were discovered. In each case, the company responded quickly, taking between days or weeks to mitigate them individually. At this time, no further customer action is required, and researchers have seen no sign that the flaws were exploited in the wild, Shitrit said.

**Full SSRF Potential**

There are three types of SSRF flaws, the researchers said. Blind SSRF allow an attacker to manipulate a server to make requests but do not elicit a response from a server — making it difficult to determine the success of an attack. Semi-blind SSRF is similar in its ability to make server requests, but an attacker does receive some response from the server that allows for limited information-gathering on the target system.

The four Azure SSRF flaws identified by the researchers fall into the third category of SSRF, called non-blind or full SSRF — the most potent type of attack scenario for a threat actor, the researchers said.

This type of attack occurs when an attacker can manipulate a server to make requests and receive the full response from the server, allowing an attacker to gather more information about the target system to potentially launch further attacks, Shitrit said.

"To give you an idea of how exploitable these vulnerabilities are, non-blind SSRF flaws can be leveraged in many different ways — including SSRF via XXE, SSRF via SVG file, SSRF via proxy, SSRF via PDF rendering, SSRF via vulnerable query string in the URL — and many more," he wrote in the blog post.

**Protection and Mitigation**

No matter what type of SSRF vulnerability is present on a server, each must be treated seriously by organizations because any type can be used to gain unauthorized access to sensitive information or launch further attacks against a target, the researchers said.

"Therefore, it is important for organizations to properly secure their servers and networks to prevent these types of attacks," Shitrit wrote in the blog post.

Shitrit made two specific recommendations for security teams to mitigate risks from SSRF vulnerabilities. The first is to "never trust user input," he says, because it could be an attempt to commit SSRF, he said.

"In this case, I saw that the internal requests sent by the server could be manipulated by the user in order to reach the internal requests/endpoints so they could reach undesired locations," Shitrit tells Dark Reading.

The second mitigation is to set and define an allow list/whitelist of URLs that can join a server, he advises. This will ensure that if a user with nefarious intent is tapping an unauthenticated SSRF to manipulate a request, the endpoint will return a "not allowed" error, Shitrit says.

Microsoft Patches 4 SSRF Flaws in Separate Azure Cloud Services

Following these basic cybersecurity hygiene policies can help make data more secure and protect colleges and universities from becoming the next ransomware headline. The steps aren't complicated, and they won't break the bank.

Colleges and universities have recently seen a striking increase in cyberattacks, especially ransomware attacks. A study by Sophos (PDF) conducted in January and February 2022 found that 64% of higher education organizations had been hit by ransomware attacks during the previous year, a significant jump from 44% the year before. Why was there such an increase?

For starters, higher-ed institutions hold a lot of sensitive data, including personal and financial information on students and their parents. Many universities also work with government agencies on cutting-edge research, which draws the interest of nation-state actors. Part of the vulnerability problem also stems from the collegial nature of higher ed, where information is meant to be shared.

But one of the biggest reasons educational organizations have become such a popular mark is that they are easy targets. Institutions often struggle with cybersecurity basics in terms of weak policies, procedures, and defensive tools. Smaller colleges and universities often don't have dedicated information-security staff, security budgets are slim, and, in at least one institution, there was faculty resistance to endpoint detection and response (EDR) software due to privacy concerns. Higher ed also struggles with the IT talent-retention problem seen in other industries.

Weak security practices, a wide range of vulnerabilities, and slow remediation times combine to make higher education institutions a potentially profitable target for attackers. According to that same Sophos report, ransomware attacks against higher education organizations pay off attackers at a higher rate than targets in other sectors — with 74% of ransomware attacks succeeding in encrypting data, as opposed to less-successful attacks on sectors such as healthcare (61%) or financial services (57%).

**Five Steps to Improve Defenses**

Security budgets and the realities of academic life may not change for organizations anytime soon, but that doesn't mean institutions can't implement changes that will make their data more secure. Here are five solid steps schools can take now to improve their defenses.

**

**1\. Implement Multifactor Authentication**

One of the most important steps organizations can take is implementing multifactor authentication (MFA), particularly considering the increased use of remote access in the pandemic era. Widely available tools make it trivially easy for a criminal group to find soft targets that only require a username and password to gain entry to a network. By using stolen credentials, guessing commonly used passwords, or successfully phishing faculty and staff, they can look like an authorized user and bypass many controls.

**2\. Test and Protect Your Backups**

Reliable backup systems are essential these days, especially with the rise in ransomware attacks. Before ransomware operators let an organization know they've been attacked, they look to find and destroy backup data. By encrypting or corrupting backup data, they reduce the likelihood of the target successfully surviving the attack without paying the ransom.

Protected backup systems, maintained separately from the rest of the network, enable effective recovery strategies and can (in some scenarios) allow organizations to refuse to pay a ransom. Immutable storage is also available from the major cloud providers, which prevents data from being modified or destroyed — even by administrators — over a set period.

**3\. Prioritize Patch Management**

Applying updates and security patches in a timely manner is a basic step that organizations often overlook, leaving gaps in their network protection.

Bad patch management can be blamed on several factors, such as overburdened IT teams or a reluctance to deal with downtime ("we'll do it over the break"). But the biggest cause of bad patch management is that many teams simply don't have a routine process for patching. In many cases, teams apply and manage patches on an emergency basis, which is often too little, too late.

Establishing a patch management schedule — and sticking to it — can reduce security risk and provide greater stability for your environment.

**4\. Eliminate Local Admin Rights, Manage Global Admin Rights**

Giving administrator rights to users who don't need them is a widespread problem that makes life easier for attackers. Compromising super-users' credentials gives attackers free rein to move about the network, install applications, change configurations, and steal or encrypt data.

Maintain good management of user accounts with powerful permissions across the network (e.g., Domain Admins in a Microsoft domain). This includes monitoring membership of powerful groups and changing passwords of powerful accounts when someone who knows those passwords is terminated.

**5\. Know What Your Network Looks Like**

A good way to assess your security posture is to understand how your network looks to an attacker. They should only see websites — not file servers, admin consoles, databases, or anything else that might be on an internal network. Regularly scanning Internet-facing systems can help organizations know and limit their exposure. Universities can find myriad open source tools and commercial solutions that do an excellent job of assessing network risk factors. Vulnerability scanning is also freely available from some state governments and the US Cybersecurity & Infrastructure Security Agency.

****Good Cybersecurity Hygiene Isn't Expensive**

Higher-education institutions are a big target primarily because they have a lot of sensitive information and are usually underresourced. But colleges and universities can protect themselves by following basic cybersecurity hygiene. The five steps listed above aren't complicated or expensive, but they're often ignored. Following those steps can help schools avoid becoming the next ransomware headline.

5 Cybersecurity Tips for Higher Education Institutions

In 2022, multiple high-profile vulnerabilities like Log4j and OpenSSL provided important takeaways for future public reporting.

As we pass the first anniversary of the Log4j vulnerability disclosure, it's a timely reminder that when a vulnerability is serious, it deserves our utmost attention. Organizations taking vulnerability disclosure more seriously is a net positive for the industry, especially because patching is so vital for basic cyber hygiene and accountability.

But, when a vulnerability is overblown or overpromoted, it can misguide the security community and distract from other more serious incidents — or cause other serious problems, like alert fatigue.

As public vulnerability disclosure becomes more commonplace for researchers, vendors, and the broader security community, the question of "when to panic or not panic?" is important. Here are some key lessons for approaching vulnerability management.

**1\. Distinguish Between Noise and Necessity**

For security experts and the media alike, it's imperative to determine when something is critical and when an issue might be overblown. According to research, the Log4j vulnerability Log4Shell could potentially impact 72% of organizations, and it was coined an "endemic vulnerability" by the US Cybersecurity and Infrastructure Security Agency.

Months later, the Text4Shell vulnerability was disclosed. Media and researchers alike wondered if it was "the next Log4Shell." But the vulnerability was proven to have a much lower impact and was much less severe.

This is one example of a gray area between ensuring something is well-broadcast and its actual impact. Being able to make this distinction can help prevent alert fatigue, which has been associated with security staff burnout and is costly to a company due to direct expenditures spent responding to these alerts, including initial triage.

In another case, if a vulnerability is originally thought to be more severe, it could be overblown. For example, a vulnerability in OpenSSL disclosed in December generated significant attention due to the ubiquity of OpenSSL inside many products to enable Transport Layer Security (TLS).

This one may have been overhyped because of the last significant vulnerability in the software in 2014: Heartbleed. Given this past, when it was announced that the new vulnerability's severity level was critical, people were understandably concerned.

But the hype around the latest OpenSSL vulnerability turned out to be kind of a non-event. At the time of release, the two CVEs (common vulnerabilities and exposures) were downgraded from critical to high. This hype wound up being a distraction because it actually led to a more complicated ConnectWise vulnerability being under-covered. The ConnectWise vulnerability had the potential to be more harmful and impact nearly 5,000 servers.

**2\. Communicate and Mitigate Risk**

Communicating risk will always have to be a collaborative effort because it happens in so many channels. Organizations post on their own websites and forums, the government issues bulletins, and the InfoSec community is particularly active on social media — researchers sometimes "scoop" vendors before they can release details about the vulnerability or mitigations themselves.

Often, there exists an educational gap between deeply technical security researchers and IT professionals and the broader business community. This disconnect results in organizations not knowing the right steps to take when a vulnerability is publicly disclosed.

**3\. Follow the Data**

The Common Vulnerability Scoring System provides a qualitative measure of the severity of cybersecurity vulnerabilities, and ratings can range from 0 to 10. It is one resource that can help us compare the vulnerability at hand to the rate of "noise" in the community. Leaning on data and hard numbers can help ensure we're paying attention to what really matters.

There are other risk-scoring models to help organizations prioritize vulnerabilities. To address the specific needs of cyber-insurance underwriting, Coalition offers the Coalition Exploit Scoring System (CESS) to help organizations prioritize vulnerability mitigation. CESS is powered by a set of machine learning models that assign severity scores to vulnerabilities based on multiple features — the description, social mentions, incident data, honeypot exploitation, and similarity to previous vulnerabilities — and measures the potential, or how likely it is, that attackers will actually exploit the CVE. This way, organizations can prioritize responses and resources according to their threat level.

Think of the CESS score as a percentile regarding severity and likelihood of exploitation. Our threshold of deeming an exploit "critical" is 0.7 or 70%. For example, CESS ranked the new OpenSSL vulnerability as 0.66 in our percentile scale, with a 1.0 being 100%. Our threshold for significance to notify policyholders is 0.7 or 70%. This slight 0.4 decile difference is actually really helpful in understanding the thousands of vulnerabilities that exist and helps cut through the noise of the hundreds publicized daily. Coalition uses CESS to prioritize which vulnerabilities policyholders should address first based on a two-pronged data approach: which vulnerabilities are the most severe and which are most likely to be exploited. Other security organizations will likely implement similar data-driven risk-scoring systems.

**How Vendors Fit In**

Vendors have a role to play in ensuring customers have a trusted source, whether communicating vulnerability severity scores or providing a balanced perspective with clear mitigation advice and updates. Vulnerability management is twofold, and the onus to resolve issues is just as much on the vendor side to communicate them properly as on the organization side to patch them efficiently.

All organizations have a responsibility when it comes to incident response and vulnerability management. Spending time educating on the technicality of how a vulnerability works and the potential exposure around technologies vulnerabilities often target can go a long way in seeing trouble before it starts.

Not everything is the "next Heartbleed" or "next Log4shell," but having the right resources in place can ensure we are ready for new security challenges without being distracted by the newest shiny object.

3 Lessons Learned in Vulnerability Management

Default settings can leave blind spots but avoiding this issue can be done.

When you hear "default settings" in the context of the cloud, a few things can come to mind: default admin passwords when setting up a new application, a public AWS S3 bucket, or default user access. Often, vendors and providers consider customer usability and ease more important than security, resulting in default settings. One thing needs to be clear: Just because a setting or control is default doesn't mean it's recommended or secure.

Below, we'll review some examples of defaults that can leave your organization at risk.

**Azure**

Azure SQL Databases, unlike Azure SQL Managed Instances, have a built-in firewall that can be configured to allow connectivity at the server or database level. This gives users a lot of options to ensure the right things are talking.

For applications inside Azure to connect to an Azure SQL Database, there is an "Allow Azure Services" setting on the server that sets the starting and ending IP addresses to 0.0.0.0. Called "AllowAllWindowsAzureIps," it sounds harmless, but this option configured the Azure SQL Database firewall to not only allow all connections from your Azure configuration but from _any_ Azure configurations. By using this feature, you open your database to allow connections from other customers, putting more pressure on logins and identity management.

One thing to note is whether there are any public IP addresses allowed to the Azure SQL Database. It is unusual to do so and, while you can use the default, it doesn't mean you should. You’ll want to reduce the attack surface for an SQL server — one way to do this is by defining firewall rules with granular IP addresses. Define the exact list of available addresses from both data centers and other resources.

**Amazon Web Services (AWS)**

EMR is a big-data solution from Amazon. It offers data processing, interactive analytics, and machine learning using open source frameworks. Yet Another Resource Negotiator (YARN) is a prerequisite for the Hadoop framework, which EMR uses. The concern is that YARN on EMR's main server exposes a representational state transfer API, allowing remote users to submit new apps to the cluster. Security controls in AWS are not enabled by default here.

This is a default configuration that may not be noticed because it sits at a couple of different crossroads. This issue is something we find with our own policies looking for open ports open to the Internet, but because it is a platform, customers can get confused that there is an underlying EC2 infrastructure making EMR work. Moreover, when they go to check the configuration, confusion can occur when they notice that in the configuration for EMR, they see the "block public access" setting is enabled. Even with this default setting enabled, EMR exposes port 22 and 8088, which can be used for remote code execution. If this isn't blocked by a service control policy (SCP), access control list, or on-host firewall (e.g., Linux IPTables), known scanners on the Internet are actively looking for these defaults.

**Google Cloud Platform (GCP)**

GCP embodies the idea of identity being the new perimeter of the cloud. It utilizes a powerful and granular permissions system. However, the one pervasive issue that affects people the most concerns Service Accounts. This issue resides in the CIS Benchmarks for GCP.

Because Service Accounts are used to give services in GCP the ability to make authorized API calls, the defaults in the creation are frequently misused. Service Accounts allow other Users or other Service Accounts to impersonate it. It's important to understand the deeper context of concern, which could be fully unfettered access in your environment, that could be surrounding these default settings. In other words, in the cloud, a simple misconfiguration can have a greater blast radius than what meets the eye. A cloud attack path can start at a misconfiguration, but end at your sensitive data through privilege escalations, lateral movement, and covert effective permissions.

All user-managed (but not user-created) default Service Accounts have the Editor role assigned to them to support the services in GCP they offer. The fix isn't necessarily a simple removal of the Editor role, as doing so might break functionality of the service. This is where a deep understanding of permissions becomes important because you must know exactly which permissions the Service Account is using or not using, and over time. Due to the risk that a programmatic identity is potentially more susceptible to misuse, leveraging a security platform to get at least privilege becomes vital.

While these are just a few examples within the major clouds, I hope this will inspire you to take a close look at your controls and configurations. Cloud providers aren't perfect. They are susceptible to human error, vulnerabilities, and security gaps, just like the rest of us. And while cloud service providers offer exceptionally secure infrastructure, it's always best to go the extra mile and never be complacent in your security hygiene. Often, a default setting leaves blind spots, and achieving true security takes effort and maintenance.

The Dangers of Default Cloud Configurations

About three-quarters of Java and .NET applications have vulnerabilities from the OWASP Top 10 list, while only 55% of JavaScript codebases have such flaws, according to testing data.

More than three-quarters of applications written in Java and .NET have at least one vulnerability from the OWASP Top 10, a list of software weaknesses that developers typically use as a baseline for application security.

That's according to software-testing firm Veracode, which found in an analysis of nearly 760,000 applications that about one in five applications using those two programming ecosystems had at least one high-severity or critical-severity vulnerability.

Overall, the average application had a 27% chance to have at least one vulnerability introduced every month, with poorly written apps and infrequently scanned apps likely to be more flawed, while applications with a longer history of security processes and being written by well-trained developers less likely to introduce new flaws, the data showed.

The analysis highlights the importance of integrating security into the development pipeline, says Tim Jarrett, vice president of strategic product management at Veracode.

"The data consistently shows that if you build a habit of security into your process, you have a better outcome, both in terms of fixing overall flaws, and ... you also slow the flood of stuff coming in, and that makes a big difference," he says.

Meanwhile, software companies and development teams continue to struggle to eliminate defects and vulnerabilities from application code. While developers and open source projects are fixing software flaws more quickly, the half-life of the average vulnerability continues to be measured in months, not days or weeks, according to Veracode's "State of Software Security" report, published on Jan. 11. 

For example, Java and .NET applications, which accounted for 71% of total applications analyzed by the study, saw half of flaws still impacting the applications after 243 days and 158 days, respectively.

    

Source: Veracode's "State of Software Security" report

Application bloat and age both had a significant negative impact on their security. The average application accumulated about 40% more code and is more likely to have vulnerabilities. About 54% of two-year old applications have flaws, while 69% of five-year-old applications flaws, the analysis found.

**JavaScript's Surprising Security**

Surprisingly, applications written in JavaScript or using one of the JavaScript frameworks tended to fare better in vulnerability scans. While about 80% of Java and .NET applications had a vulnerability, only 56% of JavaScript applications did. And while about 20% of Java and .NET applications had a high-severity vulnerability, less than 10% of JavaScript applications did.

JavaScript frameworks are newer, have more security, and have the benefits of an open source ecosystem, from which Java has only relatively recently benefited, Jarret says.

"JavaScript is a newer language, so applications written in it \[are\] newer, and there is a correlation we have established in previous reports between the age of the application and flaw remediation time," he says. "A lot of the tooling for JavaScript \[is\] mature and it's a well supported language."

Moreover, where a vulnerability in a Java application is a first-party problem — leaving the developer to fix the issues — in JavaScript and the Node.js framework, vulnerabilities are often a third-party issue, because the vulnerability has occurred in a component on which the software depends.

"The way that you fix a security problem in a Java application is still largely \[where\] you make a change to a class file and you compile it," he says. "Where in a JavaScript application, it\['s\] more of a package management problem. And that is a different thing for a developer to learn, which may be easier."

**New Programming Languages Languish**

The report's data also highlights the difference between the programming languages that developers are learning and those language actually used in the majority of enterprises. The top languages and ecosystems — Java, .NET, and JavaScript — seen by Veracode are not developers' choice of programming technology.

While JavaScript and JS-based frameworks — such as Node.js, React.js, and Angular — dominate the lists of developer-preferred technology, Java is one of the least liked programming languages, with 54% of respondents dreading the language, compared with 46% who loved it, according to Stack Overflow's 2022 Developer Survey. 

Yet Java dominated the share of applications scanned by Veracode clients (44%) compared with 14% for JavaScript. 

In addition, the most loved programming language, Rust, does not even show up in Veracode's data, while developers' No. 6, Python, only accounts for less than 4% of scanned applications.

Part of the reason for the disconnect is that established applications are written in established programming languages, says Veracode's Jarrett.

"You have the full universe of all the code that is out there, and then you have the kind of the foam on the crest of the wave of new development is happening, and that is where you see people picking up Go and Rust and Dart and Flutter," he says.

Because of the aggregated codebases of applications written in those languages, that situation likely will not change.

"Old applications never die, unfortunately, so there is a lot of critical mass in enterprises with these big Java codebases and .NET codebases," he says.

Java, .NET Developers Prone to More Frequent Vulnerabilities

Analyzing and learning from incidents is the ideal path to finding more insightful data and metrics, according to the VOID report.

Security teams have traditionally used _mean time to repair_ (MTTR) as a way to measure how effectively they are handling security incidents. However, variations in incident severity, team agility, and system complexity may make that security metric less useful, says Courtney Nash, lead research analyst at Verica and main author of the Open Incident Database (VOID) report.

MTTR originated in manufacturing organizations and was a measure of the average time required to repair a failed physical component or device. These devices had simpler, predictable operations with wear and tear that lent themselves to reasonably standard and consistent estimates of MTTR. Over time the use of MTTR has expanded to software systems, and software companies began using it as an indicator of system reliability and team agility or effectiveness.

Unfortunately, Nash says, its variability means that MTTR could either lead to false confidence or cause unnecessary concern.

"It's not an appropriate metric for complex software systems, in part because of the skewed distribution of duration data and because failures in such systems don't arrive uniformly over time," Nash says. "Each failure is inherently different, unlike issues with physical manufacturing devices."

**Moving Away From MTTR**

"\[MTTR\] tells us little about what an incident is really like for the organization, which can vary wildly in terms of the number of people and teams involved, the level of stress, what is needed technically and organizationally to fix it, and what the team learned as a result," Nash says.

MTTR falls victim to the oversimplification of incidents because it is calculating an average — the average time, says Nora Jones, CEO and co-founder of Jeli. Simply measuring this single average of reported times (and those reported times have also been proven to not be reliable in the first place) inhibits organizations from seeing and addressing what's going on within the infrastructure, what's contributing to that recurring incident, and how people are responding to incidents.

"Incidents come in all shapes and size — you'll see them span the complete range in severity, impact to customers, and resolution complexity all within one organization," Jones explains. "You really have to look at the people and tools together and take a qualitative approach to incident analysis."

However, Nash says moving away from MTTR isn't an overnight shift — it's not as simple as just swapping one metric for another.

"At the end of the day, it's being honest about the contributing factors, and the role that people play in coming up with solutions," she says. "It sounds simple, but it takes time, and these are the concrete activities that will build better metrics."

**Broadening the Use of Metrics**

Nash says analyzing and learning from incidents is the ideal path to finding more insightful data and metrics. A team can collect things like the number of people involved hands-on in an incident; how many unique teams were involved; which tools people used; how many chat channels there were; and if there were concurrent incidents.

As an organization gets better at conducting incident reviews and learning from them, it will start to see traction in things like the number of people attending post-incident review meetings, increased reading and sharing of post-incident reports, and using those reports in things like code reviews, training, and onboarding.

David Severski, senior security data scientist at the Cyentia Institute, says when working on the Verizon DBIR, Cyentia created and released the Vocabulary for Event Reporting and Incident Sharing to expand the types of metrics used to measure an incident.

"It defines data points we think are important to collect on security incidents," he says. "We still use this basic template in Cyentia research with some updates, for example identifying ATT&CK TTPs utilized."

The metrics for measuring an incident is not a one-size-fits-all across organization sizes and types. "Teams understand where they are today, assess where their priorities are within their current constraints, and understand their focus metrics might even evolve over time as their organization develops and scales," Jones says.

Additionally, it's about shifting focus to learnings, and then continuously improving based on those learnings, for example shifting to assessing trends and if things are trending in the right direction over time, as opposed to single-point-in-time metrics.

Source

DARKReading