Abuse primitives have a longer shelf life than bugs and zero-days and are cheaper to maintain. They're also much harder for defenders to detect and block.

Microsoft's cloud services revenue grew 46% in the first quarter of 2022, and its cloud market share has increased by almost 9% since 2017. With Azure finally being used in earnest by the mainstream, now is the ideal time to get involved in Azure abuse research. There are many undiscovered abuse primitives out there, a lot of misconfiguration debt built up, and growing numbers of adversaries starting to target Azure more seriously.

Why spend time looking for abuse primitives rather than bugs or software exploits? Abuses have a much longer shelf life than bugs and zero-days, and they're cheaper to maintain. More importantly for attackers, they exist in nearly all implementations of the software in question and are much harder for defenders to detect and block. That's why it's vital for researchers to uncover new abuse options so they can be fixed or mitigated.

Here's my five-step process for researching a specific system within Azure and trying to find new attack primitives. Following this approach will help you save time, stay on track, and produce better results.

**Step One: Begin With the End in Mind**

First, you'll need to gain an understanding of how your system of choice works, how it interacts with other systems in Azure, and how it can be abused. Beyond that, think about what your final product will be — a blog post? A conference session? Defensive remediation guidelines or updates to an open source tool? Determine what's needed to create these assets. Consider producing audit code as well, so defenders can check for these dangerous configurations, and abuse code, too, so others can easily verify how these configurations can be abused. These are the "success criteria" for your research that will help you maintain focus, avoid unnecessary rabbit holes, and ensure a valuable end result.

**Step Two: Study the Intent and Design of the System**

Once you know exactly what you need to discover, begin research just like anyone else would — doing Google searches and reading official documentation. Look for anything that seems abusable (like the ability to reset passwords and permissions required), dig further into those, and take notes as you go.

Use LinkedIn to identify any product architects or other Microsoft staff involved in creating the subject of your study. Review their LinkedIn and Twitter feeds and look for the resources they've authored or reposted (blog posts, conference presentations, etc.). Delve into community resources like forums or GitHub repositories associated with this service, as these user groups are generally much more open in their discourse around problems and weaknesses than the Microsoft folks. Keep taking notes on the system. Once you can speak intelligently about the architecture and intent of the system and write a highly accurate, nontechnical brief about it, you're ready to move on.

**Step Three: Explore the System**

Documentation can only take you so far — it doesn't keep up with changes in Azure and there are almost always hidden connections that go undocumented. It's tempting to jump straight into this step, but without the context on the system that you built through research, you'll probably waste a lot of time.

Start exploring the system with the easiest interface — often this is the Azure portal GUI. If you bring up the Developer tools in the Chrome browser, you can see all the API requests that the browser is making. Copy them to PowerShell and you'll have a good start to building your own client. Use the official CLI tools in Azure (az binary, the Az PowerShell module, and Azure AD PowerShell module).  

When you’ve explored enough that you can build your own basic client to interact with the system, it’s time to proceed. This provides a foundation for a more mature client, and for automating the process of testing abuse capabilities.

**Step Four: Catalog Abuse Capabilities**

Now you can use your client to enumerate all the permissions that that system can assign, and test the abuse primitives you already know about against each of those permissions (e.g., can you promote yourself to global admin or change a global admin’s password?). Keep an eye out for other abuse primitives that might present themselves during your research — and test them as well to reveal any discrepancies between what the official documentation says and how things work in reality.

Realistically, you’ll need to automate this process. When I went through this research methodology examining the Azure Graph API, I had a list of about 175 permissions and a dozen abuse primitives to test against each of them … you do the math.

**Step Five: Share Findings**

The final step is to help others learn from your work. Write a blog post, do a talk and/or share your code. The point is to help others save time and expand or add on to your work. Think of it as writing the blog post you needed at the start of your research.

To learn more, watch a talk I gave on this topic (and access the accompanying deck). Inspired to start researching Azure abuses? Here are some useful websites to find technical content around Azure security: The Lazy Administrator, Good Workaround!, AZAdvertizer, Thomas Van Laere, and Microsoft Portals.

How to Find New Attack Primitives in Microsoft Azure

Researchers have created a new community website for reporting and tracking security issues in cloud platforms and services — plus fixes for them where available.

Organizations traditionally have struggled to track vulnerabilities in public cloud platforms and services because of the lack of a common vulnerability enumeration (CVE) program like the one that MITRE maintains for publicly disclosed software security issues.

A new community-based database launched this week seeks to begin addressing that issue by providing a central repository of information on known cloud service-provider security issues and the steps organizations can take to mitigate them.

The database — cloudvulndb.org — is the brainchild of security researchers at Wiz, who for some time have been advocating the need for a public catalog of known security flaws on platforms and services run by the likes of AWS, Microsoft, and Google. The database currently lists some 70 cloud security issues and vulnerabilities that security researcher Scott Piper had previously compiled in a document on GitHub titled "Cloud Service Provider security mistakes." Going forward, anyone is free to suggest new issues to add to the website or to suggest new fixes to existing issues. The goal is to list issues that a cloud service provider might have already addressed.

**Centralized Vulnerability Repository**

"The centralized database can help organizations review all past security issues in their \[cloud service provider\] at any time and check if they have not applied necessary remediation actions," says Alon Schindel, director of data and threat research at Wiz. "For example, organizations can check if they were using a certain service during a critical security issue’s exploitability period and use the recommended detection methods — if available — to check if they were affected."

For now, the vulnerability database site does not have a system in place to automatically notify users when new security issues are added to it. But the goal is to add an RSS feed or mailing list for that purpose, says Schindel, one of the maintainers of the new database.

Schindel — like many other researchers — has noted how the lack of a formal and standardized system for publicly recording cloud security issues, and sharing information about them, is heightening risks for organizations. In a blog last November, Schindel and another Wiz researcher pointed to vulnerabilities — such as one dubbed ChaosDB in Microsoft Azure and another called OMIGOD in Microsoft Azure — as specific reasons why a cloud vulnerability database has become a critical industry necessity. Both vulnerabilities were serious. And unlike many cloud vulnerabilities, the responsibility for mitigating risk with both vulnerabilities rested not just with the cloud provider but also with their customers.

ChaosDB impacted four Azure services and gave users overly permissive access to storage buckets belonging to other cloud tenants. OMIGOD was a set of four flaws in OMI, a Microsoft cloud middleware technology, that enabled remote code execution and privilege escalation. Though Azure and Microsoft addressed the vulnerabilities promptly, many organizations using the affected services had limited information on the changes they needed to make to address them, the Wiz researchers said.

"Typically, cloud service provider security issues do not have a patch in the traditional sense, as issues are fixed internally by the CSP without the need for any manual user action," Schindel says. But no CVEs mean that there are no industry conventions for assessing severity, no proper notification channels, and no unified tracking mechanisms. 

"This means that it’s difficult for a cloud customer to answer otherwise simple questions like, 'Is my environment currently vulnerable to this?' or, 'Was it ever vulnerable to this?'" he adds.

**Inconsistent Practices**

Currently all major CSPs accept responsibly disclosed vulnerabilities, and some have an official bug bounty or vulnerability reward program in place. Occasionally, a cloud service provider might even publish details of a fix they might have developed for a reported security vulnerability. However, there is little consistency among the various providers, Schindel says. 

"Notification channels vary; vendors usually email affected customers only or send them a notification through a service health system," he says.

Wiz has been unable to find any consistency in the publication cadence of security issues of the different CSPs, though Microsoft usually included fixes for Azure vulnerability in its monthly patch release cycle.

Wiz will maintain the new site, though anyone is free to contribute to it. The goal is to try and get major CSPs to engage with the effort or to use the site to provide more transparency around vulnerabilities discovered in their services. This can include information such as indicating the time periods during which a security issue might have been exploitable. 

"We also hope that the value of such a database will help CSPs standardize their security issues publication processes," he says.

New Vulnerability Database Catalogs Cloud Security Issues

NIST SP800-219 introduces the macOS Security Compliance Project (mSCP) to assist organizations with creating security baselines and defining controls to protect macOS endpoints.

No operating system is immune to threats, and a thorough endpoint security strategy accommodates the requirements for each one. Toward that end, the National Institute of Standards and Technology (NIST) has published the final version of its guidance on securing macOS endpoints. 

NIST SP 800-219 provides system administrators, security professionals, security policy authors, information security officers, and auditors with resources to secure and assess macOS desktop and laptop system security in an automated way. NIST derived the guidance from the open source macOS Security Compliance Project, born out of a collaboration between NIST, NASA, the Defense Information Systems Agency, and Los Alamos National Laboratory.

The goal of the mSCP is to simplify the macOS security development cycle by reducing the amount of effort required to implement security baselines, NIST says. Security baselines refers to "groups of settings used to configure a system to meet a target level or set of requirements or to verify that a system complies with requirements." The project is intended to help IT and security staff create customized security baselines of technical security controls by leveraging a library of rules, with each rule mapped to requirements from security standards, regulations, or frameworks, NIST says in the guidance document.

The mSCP provides scripts that can be used with baselines to create scripts and profiles for configuring macOS; generate a mapping between security standards, regulations, and frameworks; produce human-readable documentation in a variety of formats; customize existing baselines; and generate Security Content Automation Protocol (SCAP) content for use in automated security compliance scans.

Security baselines and associated rules for configuring and managing macOS endpoint devices can be found on mSCP’s GitHub page. Organizations should take a risk-based approach for selecting the appropriate settings and defining values that consider the context under which the baseline will be used, NIST says.

**Make It Easier to Upgrade**

Agencies and organizations typically delay deploying the new macOS release because they are waiting for guidance. The mSCP is intended to provide guidance of the security features in new operating system releases at the earliest availability. Instead of having to produce a new guidance document for each macOS release, NIST will focus on continually curating and updating the information in mSCP, giving organizations one consistent reference point.

"Generally, the technical security settings in macOS do not drastically change from release to release, with only a handful of new settings being introduced. By pursuing a rules-based approach, mSCP rules that remain applicable can be reused and incorporated into guidance for the latest macOS version. This enables quicker adoption of new security features that are not offered in prior versions of macOS," NIST says.

NIST Finalizes macOS Security Guidance

Balancing public service with fraud prevention requires rule revisions and public trust.

If a person loses their state ID or their driver's license, they may — depending on the regulations of their state — need to take a trip to the Secretary of State's office or Department of Motor Vehicles and wait in line with a handful of significant documents proving their identity in order to replace it.

That is, until COVID-19.

As states closed their government buildings in the early stages of the coronavirus pandemic, government agencies were forced to reckon with how unprepared their antiquated systems were to provide digitized services during a once-in-a-lifetime pandemic requiring the public to shelter in place. Simultaneously, the public and the private sector faced cyberattacks that left valuable, sensitive information in the hands of threat actors.

So, how do government agencies administering public benefits prevent fraud and protect valuable personal data? That question was the subject of "Future of Identity Fraud Roundtable," an online panel hosted on June 17 by Socure and Venable. During the discussion, experts weighed in on the unique challenges government agencies face when verifying people's identities, providing government assistance, and preventing synthetic identity fraud, in which cybercriminals combine real information with fabricated information to build a fake identity

"I think pretty much every state and government entity is seeking to deliver good quality digital experiences to our constituents," said J.R. Sloan, CIO for the State of Arizona, during the panel. "During the pandemic phase ... this was a public safety issue. We needed to be able to deliver no-touch experiences."

Estimates on just how much fraud occurred during the coronavirus pandemic vary. An academic paper published by researchers at the University of Texas — Austin found $64.2 billion worth of potentially misreported loans. A higher estimate from the Small Business Administration (SBA) identified at least $78.1 billion in possibly fraudulent loans and grants. Excluding data on coronavirus fraud cases brought by the Justice Department, the Secret Service reportedly said that nearly $100 billion had been stolen from coronavirus relief programs for businesses and individuals, a conclusion it reached using its own cases and data from the US Department of Labor and the SBA.

Over the past two years, federal government agencies' public benefit programs have been under attack from cybercriminals in other countries, as well as domestic cybercriminals using synthetic identities to intercept benefits meant for the American public, said Jordan Burris, senior director for product market strategy at Socure.

Cybercriminals have been sharing information and digital guides on using stolen personal information to apply for government benefits, said Linda Miller, principal of advisor services at Grant Thornton and former deputy executive director of the US Pandemic Response Accountability Committee, during the panel.

"The game has completely changed. And it's not going to change back," Miller said during the panel. "They're only going to get more and more sophisticated and more skilled as the government continues to be challenged to effectively deal with this problem."

**Hurdles to Going Digital**

Unlike the private sector, government agencies have to serve the public, which often entails reaching people who don't have addresses or bank accounts, Miller said. Verifying the identities of these vulnerable groups could prove to be harder, because there are fewer data points available for the government to cross-check, she explained.

While government agencies can use some basic indicators, such as a foreign IP address, to screen out fraudsters, there is no one-size-fits-all solution for agencies to manage populations of people who are harder to authenticate, she said.

"These problems around how do we solve this identity proofing problem in a way that is going to ensure equity across a lot of different types of groups that need government benefits, is not going to create a ton more problems for the constituents, and sell to the citizens as they're trying to get access to their benefits," Miller said. "What we need to think about is using data in a smarter way, and meeting people where they are in terms of how much data do we have on an individual."

Though sharing data between government agencies could allow them to verify benefit applicants' identities easily, one challenge government agencies face is the regulations for what data they can and cannot share with each other, Burris said. For some pieces of information to be shared — including a Social Security number, a taxpayer identification number, alien registration numbers, or passport numbers — permission to share data among various government agencies could require Congress to pass federal laws allowing it.

**Recent Progress in Data Policy**

Though regulations currently bar government agencies from sharing certain personal information, there are proposals to change agency processes that could allow them to test safe data sharing, Suzette Kent, CEO of Kent Advisory Services and former US CIO, said during the panel. Such proposals could allow, for example, military to share and recover veteran or retirement data following a disaster, Kent said.

"We have to look at what information agencies are authorized to gather, and how they may use it, and ensure that those things are fit \[for\] purpose for the types of things that we're doing," Kent said. "That may require law, policy, technology, and engagement with the particular citizen set that you're serving."

A recent example of biometric authentication gone wrong was the IRS' attempt to implement facial recognition technology for verifying the identities of people opening new online accounts. The agency announced on Feb. 7 that it abandoned its plans to use a third-party facial recognition company for authenticating new accounts.

With remote biometric identity proofing came issues around privacy, access, and equity, which was met with immediate backlash, Miller said. As government agencies try to use this technology, they're also required to comply with the National Institute of Standards and Technology's "highest level of identity authorization." But it has become clear that many federal and state government agencies aren't ready to address the numerous complexities of NIST compliance and the other issues that emerge, she said.

Regardless of the remote authentication tool, government agencies need to maintain public trust and be transparent about how they're using biometric technologies, Burris said.

Failing to maintain public trust "erodes the ability to leverage innovation in order to combat what we're seeing from a fraud standpoint," Burris said. "I would say any vendor working in this space, again, needs to be transparent with practices, so that we don't have that erosion."

Federal, State Agencies' Aid Programs Face Synthetic Identity Fraud

LockBit 3.0 promises to 'Make Ransomware Great Again!' with a side of cybercrime crowdsourcing.

The LockBit ransomware group just released its latest ransomware-as-a-service offering, LockBit 3.0, and along with it a first for the Dark Web: a bug-bounty program.

The bounty program offers up rewards for personal identifiable information (PII) on high-value targets, security exploits, and more, according to screen grabs of messages that appear to have been shared by LockBit actors.

"We invite all security researchers, ethical and unethical hackers on the planet," the group reportedly posted, offering payments for website bugs, locker bugs, TOX messenger exploits, and information to fuel doxxing campaigns, with payments starting at $1,000. The group is even willing to pay for fresh cybercrime ideas, the ad say.

LockBit is on a roll. In the wake of Conti's shutdown, LockBit 2.0 emerged as the dominant ransomware-as-a-service group in May, with the dubious distinction of being behind 40% of all ransomware attacks during the month. LockBit operators seem poised to capitalize with a new, malicious twist on bug-bounty programs.

**'No Honor Among Ransomware Operators'**

"I wish this surprised me," Mike Parkin, senior technical engineer at Vulcan Cyber, said in reaction to the LockBit bug-bounty launch. "But malware gangs have reached a level of maturity that they are, literally, professionally run businesses."

While the innovation is noteworthy as a development in the ransomware business, John Bambenek, principal threat hunter at Netenrich, said he doubts anyone would actually submit something and expect to collect the bounty.

"This development is different; however, I doubt they will get many takers," Bambenek said in a statement provided to Dark Reading. "I know that if I find a vulnerability, I'm using it to put them in prison. If a criminal finds one, it'll be to steal from them because there is no honor among ransomware operators."

LockBit 3.0 Debuts With Ransomware Bug Bounty Program

Cerby platform emerges from stealth mode to let users automate security for applications outside of the standard IT purview.

One in every three cybersecurity attacks is the result of unsecured unmanageable applications, researchers say, while only 15% of cloud-based services are actively managed by IT departments.

The new Cerby Zero Trust platform lets business users download and operate their preferred applications with an added layer of automated security that previously wouldn't have existed for tools not directly visible to IT teams, the company said.

The platform already has an impressive list of business customers, including Fox, L'Oréal, MiSalud, Dentsu, Televisa, and Wizeline, Cerby said in announcing the zero trust platform. It added that securing preferred employee apps often pits employees against corporate security.

"Our goal at Cerby is simple but sweeping: To increase productivity for enterprises by empowering employees to use the technologies they prefer while automating compliance and security," Cerby co-founder and CEO Belsasar Lepe said in a statement about the platform's release. "In this era of IT consumerization, employee choice and enterprise security are not mutually exclusive — with the right tools and strategies, they go hand-in-hand."

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

Shadow IT Spurs 1 in 3 Cyberattacks

DSM is now the third acquisition by Thrive in Florida in the past six months.

FOXBOROUGH, Mass., June 24, 2022 /PRNewswire/ -- Thrive, a premier provider of NextGen Managed Services, announces today that it has acquired DSM, a Florida-based provider of managed IT services to State, Local, and Education (SLED) government agencies. The acquisition will enable DSM's existing government and corporate clients to benefit from Thrive's next-generation managed cybersecurity, global Cloud footprint, and Microsoft collaboration services while strengthening Thrive's offering to SLED agencies across the US.

Founded in 1986, DSM has been helping clients achieve their IT goals by providing innovative solutions for data protection, disaster recovery, and managed cloud services bolstered by their CJIS compliant data centers. Focusing on data assurance, DSM offers clients the ability to survive and recover quickly from a data breach or ransomware attack, ensuring business continuity. DSM's expert team of highly qualified professionals develop flexible and cost-effective solutions that address the challenges of customers that serve commercial, government, and CJIS-bound agencies.

"DSM is a leader in the SLED space with significant traction in the state of Florida. With this partnership, they'll be able to augment their Cloud-based service offerings via Thrive's SOC and comprehensive suite of cybersecurity services," said Rob Stephenson, Thrive's CEO. "DSM's talented engineers and experienced management team will help to greatly enhance our rapidly growing Florida presence, as well as position the SLED vertical to go national under their leadership."

"For over three decades, DSM's primary objective for our clients has been to optimize their digital transformation and their journey to the Cloud," said David Robinson, CEO and Founder of DSM. "We are delighted to be the newest members of the Thrive family as their dedication to providing a personalized IT path towards customer satisfaction complements our commitment to total IT peace of mind for our clients."

Robinson and Greg Madden, DSM's COO, will assume senior leadership roles and helm the newly established Thrive SLED group as a special unit focusing on existing government business in Florida, Alabama, and Massachusetts. In addition, Robinson and Madden will assist in Thrive's expansion of state and local contracts up and down the East Coast.

DSM is now the third acquisition by Thrive in Florida in the last six months and builds upon its established presence in the Southeast region. Thrive is a security-first MSP that delivers comprehensive managed services and unmatched expertise to drive secure digital transformation for small to mid-sized enterprises across multiple industries. For more information on Thrive, visit thrivenextgen.com.

**About Thrive**

Thrive is a leading provider of NextGen managed services designed to drive business outcomes through secure application enablement and optimization. The company's Thrive5 Methodology utilizes a unique combination of its Application Performance Platform and strategic services to ensure each business application achieves peak performance, scale, uptime, and the highest level of security. For more information, thrivenextgen.com.

Thrive: LinkedIn, Twitter, Facebook, YouTube and Instagram

**About DSM**

DSM redefines our client's business outcomes that they consider possible from their IT infrastructure ensuring that their data is protected and available when and where they need it, saving time and money. As our clients embark on their journey to trusted data availability, DSM guides them, allowing them to focus on their core business, rather than the technology that runs it.

Thrive Acquires DSM

If you haven't properly addressed the issue, you're already behind. But even if you've had a false start, it's never too late to get back up.

The digital world is ever-increasing in complexity and interconnectedness, and that's nowhere more apparent than in software supply chains. Our ability to build upon other software components means we innovate faster and build better products and services for everyone. But our dependence on third-party software and open source increases the complexity of how we must defend digital infrastructure.

Our recent survey of cybersecurity professionals found one-third of respondents monitor less than 75% of their attack surface, and almost 20% believe that over half of their attack surface is unknown or not observable. Log4Shell, Kaseya, and SolarWinds exposed how these statistics can manifest as devastating breaches with wide-reaching consequences. Cybercriminals already know supply chains are highly vulnerable to exploitation.

**Why Insecure Software Supply Chains Are Everyone's Problem**

Last year, a threat actor exploited a vulnerability in Virtual System Administrator (VSA) provider Kaseya to inject REvil ransomware into code for VSA. Kaseya supported thousands of managed service providers (MSPs) and enterprises, and its breach compromised a critical network within thousands of organizations. Consequently, these organizations' internal systems were also compromised.

The ripple effect that Kaseya had on its customers can happen to any organization that uses a third-party software vendor. The European Union Agency for Cybersecurity (ENISA) analyzed 24 recent software supply chain attacks and concluded that strong security protection is no longer enough. The report found supply chain attacks increased in number and sophistication in 2020, continued in 2021, and, based on recent attacks by Lapsus$, is likely to carry over through 2022.

Similar to third-party software vendors but at an even-greater magnitude, open source code has a devastating impact on digital function if left insecure — the havoc wreaked by Log4Shell illustrates this. These consequences are partly because open source software remains foundational to nearly all modern digital infrastructure and every software supply chain. The average application uses more than 500 open source components. Yet limited resources, training, and time available for the maintainers who voluntarily support projects mean they struggle to remediate the vulnerabilities. These factors have likely contributed to high-risk open source vulnerabilities remaining in code for years.

This issue demands immediate action. That's why the National Institute of Standards and Technology (NIST) released its security guidelines in February. But why are we still so slow to try and secure the software supply chain effectively? Because it's tough to know where to start. It's challenging to keep up with security updates for your own software and new products, let alone police other vendors to ensure they match your organization's standards. To add more complexity, many of the open source components that underpin digital infrastructure lack the proper resources for project maintainers to keep these components fully secure.

**Get Started**

So, how do we secure it? It all looks pretty daunting, but here's where you can start.

First, get your house in order and identify your attack resistance gap — the space between what organizations can defend and what they need to defend. Know your supply chain and implement strategies that set teams up for success:

*   **Require a software bill of materials (SBOM)** and maintain an accurate inventory of your organization's software licenses to know what vendors, programs, and networks could put you at risk. Open source software components are especially challenging to document; the Linux Foundation and International Organization for Standardization (ISO) have resources to help organizations determine an approach to track and identify open source for their SBOMs.

*   **Get a clear understanding of how your software (current or future purchases) supports or otherwise relates to your critical processes.** Knowledge of this relationship empowers security teams to make the business case for prioritizing security and better understand what elements of the business will be put at risk depending upon the vulnerable vendor or component.

*   **Shift ownership of software security to the earliest stages of development**.**** Known as "shifting left," this makes developers aware of security standards, so security and development teams collaborate to build secure products and reduces the amount of patching insecure products already deployed.

Then, enforce your strategies and standards to maintain security for your organization and the collective security of the Internet:

*   **Evaluate every software vendor based on incident readiness** and establish accountability. Including a vendor in your supply chain is an expression of trust, and you should only extend this trust when you believe that partner is worthy. Transparency across your organization and supply chain is key to excellent incident response. You can also use language from successful pre-existing programs for incident response and disclosure to inform guidelines.

*   **Adopt a clear integrity framework** and a detailed vendor onboarding process. The framework should include documentation of how each supplier's software license supports your organization and the security tools they leverage internally.

*   **Develop a strategy to improve the security** **of open source components** and contribute to their security through organizations dedicated to supporting project maintenance. Contributing to open source projects reduces the risk to your organization and everyone who uses open source code.

Most in the cybersecurity community are familiar with Murphy's Law: "Everything that can go wrong, will" — it defines the mindset of anyone working in this field. And if my experience in this industry has taught me anything, you just have to do your best to keep up with the inevitable increase in challenges, risks, and complexity of securing digital assets. Part of staying ahead of these challenges is remaining highly proactive when it comes to your security best practices, and if you haven't properly secured your software supply chain yet, you're already behind. But even if you've had a false start, the good news is that it's never too late to get back up.

It's a Race to Secure the Software Supply Chain — Have You Already Stumbled?

Most of those surveyed are concerned about AI-based attacks and deepfakes, but suggest that their organization is ready.

Almost all IT professionals believe that threat intelligence services and feeds will help their company get ready for and repulse malware attacks. Only 6% somewhat disagree with that idea, while 94% agree (44% strongly agree and 50% somewhat agree) that such tools are useful. Zero percent strongly disagree.

That's just one of the takeaways from the June 1 report from Dark Reading, "The State of Malware Threats." Dark Reading surveyed 153 IT and security professionals across industries including healthcare, financial services, information technology, manufacturing, telecommunications, and retail. The report aims to sketch out the malware landscape, see how it's affecting companies, and discover what security teams are doing to fight it.

Threat intelligence services and threat intelligence feeds distribute information such as IP addresses and URLs associated with known threats. Potentially the most prominent is the US Federal Bureau of Investigation's InfraGard, but many private companies offer informational feeds for free alongside their paid offerings. Feeds are useful for incorporating into security information and event management (SIEM) and other tools to keep up-to-date on the latest threats. Threat intelligence services will incorporate the data for a client so that they can take action, with various levels of defensive activity from the service.

Other questions garnered similar levels of agreement among respondents. For example, 86% either strongly (38%) or somewhat (48%) agreed that they would see artificial intelligence-powered attacks in the next year; 13% somewhat disagreed, and 1% strongly disagreed. Concerns about malicious use of deepfakes was a little more split, with 79% agreeing (26% strongly, 53% somewhat) and 21% disagreeing (17% somewhat, 4% strongly).

Attitudes among respondents' colleagues generated more discordance. Considering the statement that discovering a new vulnerability would change their security team's plans for the week, 73% agreed (24% strongly, 48% somewhat), but 28% (23% somewhat, 5% strongly) disagreed. That disagreement could come down to confidence in their organization's plan for handling a crisis rather than its lack of urgency.

The only statement that garnered more disagreement than agreement was the idea that the organization is less concerned about malware than it was last year. Only 44% agreed with that (15% strongly agree, 29% somewhat agree), and 56% disagreed (39% somewhat, 17% strongly). Again, the people who agreed might just be expressing confidence in the new tools and techniques their organization put into place after a rough 2021. After all, the Verizon Data Breach Investigations Report (DBIR) 2022 found that 40% of data breaches were due to malware, so nobody can really be resting easy.

For more, download the full report.

Threat Intelligence Services Are Universally Valued by IT Staff

Security is wasting time and resources patching low or no risk bugs. In this post, we examine why security practitioners need to rethink vulnerability management.

Sometimes, too much information is a mixed blessing. Security teams use multiple vulnerability scanners in an attempt to cope with a significant rise in both attack surface diversity and software vulnerabilities.

But they soon find themselves overwhelmed with results, which leads to a growing backlog of bugs that need to be fixed. This backlog has multiple negative impacts. It slows the development process because the flaws take time to patch, and ignoring them leads to an excessive amount of tech debt.

Many teams are using outdated practices and limited data, which studies find do not lead to a reduction in risk to an organization's attack surface. In fact, a recent analysis from RAND Corporation found no notable reduction of breaches in organizations with mature vulnerability management programs.

There has to be a better way to handle vulnerability management. I propose a rethink on vulnerability management.

**Too Much Noise, Too Few Signals  
**The new way forward in vulnerability management requires changing the perception that vulnerability management is simply about scanning your software for threats. Why? Because the information scanners give you lack context for any meaningful next steps that reduce risk.

Rezilion's own runtime research analysis finds, on average, only 15% of discovered vulnerabilities are loaded into memory, which makes them exploitable. That means, on average, only 15% of flaws require priority patching — or patching at all. There is more value to be had from applying risk context. Security teams must be able to glean how those gaps could be exploited and the consequences that could occur if they are not addressed.

Most significantly, vulnerabilities must be prioritized based on their severity. But I am not talking about severity based on the common vulnerability scoring system (CVSS). With traditional approaches, security teams are often spinning their wheels scanning and then remediating vulnerabilities that may not pose a serious or immediate threat simply because the scoring system deems them to be critical.

This lack of understanding on criticality can also cause added friction between security and DevOps teams, which typically spar over the need for speed and business agility while maintaining security.

**Patch What Matters  
**Rezilion conducted an analysis of 20 of the most popular container images on DockerHub along with several base operating system images from the three major cloud providers: Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). The idea was to assess how many vulnerabilities are not relevant and which ones pose a real risk.

The findings showed more than 4,347 known vulnerabilities. Of those, 75% of those rated as critical or high in severity did not load to memory and posed no risk. Of course, it would be time-consuming and nearly impossible to patch all of these at once. The takeaway is that organizations can use runtime analysis to prioritize remediation of vulnerabilities — and not be daunted by the growing backlog. A vulnerability in a package that isn't being loaded to memory can't be exploited by an attacker.

With this new approach, organizations can utilize their limited resources to remediate the vulnerabilities that _actually_ pose a real threat of exploitation and patch them accordingly. This level of knowledge and prioritization also saves development time and prevents time-to-market delays.

When a risk-based approach is implemented to prioritize vulnerability remediation, the work shifts to containing the threats that pose a significant threat. That in turn reduces overhead and the vulnerability backlog. It also shrinks the software attack surface, making it more manageable to apply patches appropriately.

**It's Time for a Change in Vulnerability Management**

It's time for a new vulnerability management strategy and it's appropriate to reiterate a few things to think about as you do. Instead of applying static, score-based, or manual policy-driven allow or block decisions, use more context and runtime visibility to make risk-based decisions that are continuous and adaptive.

We are advocating for a rethink in which security teams don't just prioritize vulnerability remediation by using CVSS severity scores alone. Instead, look to tools that allow you to concentrate on the vulnerabilities that pose the greatest risk to _your_ organization. Rezilion provides tools to see into your software environment and determine which vulnerabilities pose a risk and which do not require patching. Security teams should utilize real-time contextualized security controls to understand their true software attack surface. But in order to apply context, you need data that will help identify weak spots in order to refocus remediation efforts on the most critical risks. Otherwise, you're just wasting valuable time finding signals in the noise.

**About the Author**  

    

  
Liran Tancman, CEO and co-founder of Rezilion, is one of the founders of the Israeli cyber command and spent a decade in Israel's intelligence corps. In 2013, Liran co-founded CyActive, a company that built a technology capable of predicting how cyber threats could evolve and offer future-proof security. Liran served as CyActive's CEO and led it from its inception to its acquisition by PayPal in 2015. Following the acquisition, Liran headed PayPal's global Security Products Center responsible for developing cutting-edge technologies to secure PayPal's customers.

Source

DARKReading