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.

Why We're Getting Vulnerability Management Wrong

CISA tells organizations running VMware servers without Log4Shell mitigations to assume compromise.

Organizations with public-facing VMware Horizon and Unified Access Gateway (UAG) servers without appropriate Log4Shell mitigations have been under a barrage of attacks from a range of attackers, including state-sponsored advanced persistent threat (APT) actors.

In fact, a new Cybersecurity and Infrastructure Agency (CISA) alert tells organizations running servers without Log4Shell updates to just assume they've been compromised and proceed with threat hunting and incident response. CISA added that in one instance, APT attackers were able to breach a disaster recovery network, move laterally, and steal sensitive data.

"If potential compromise is detected, administrators should apply the incident response recommendations included in this CSA and report key findings to CISA," the warning, issued along with the US Coast Guard Cyber Command (CGCYBER), said.

CISA also provides a list of indicators of compromise (IOC) and extensive technical details for threat hunters.

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

APT Groups Swarming on VMware Servers with Log4Shell

A new study says 97% of open source vulnerabilities linked to software supply chain risks are not attackable — but is "attackability" the best method for prioritizing bugs?

With vulnerability-management workloads ballooning in the era of heightened software supply chain security risks, a study out today suggests that only about 3% of today’s flaws are actually reachable by attackers. The data implies that if application security (appsec) pros and developers work to focus on fixing and mitigating what's truly attackable, they could drastically reduce the strain on their teams.

The new study by ShiftLeft, the 2022 AppSec Progress Report, suggests that appsec and development teams can more effectively sift through vulnerabilities by focusing on the "attackable" ones. Data from the report shows that developers saw a 97% reduction in false-positive library upgrade tickets once they considered attackability when examining packages in use with critically rated vulnerabilities.

If true, this would be a welcome relief to many. Vulnerability management was already hard enough as is, but the added complication of third-party flaws — especially the scale of impact of these vulnerabilities rippling across numerous pieces of software — creates an even more daunting workload that can only be managed through effective prioritization. Security and developers can only get to so many vulnerabilities in so many applications within any given time period. They need to make sure the ones they fix or mitigate with compensating controls are the ones that count.

**What Does 'Attackability' Mean for Security Vulnerabilities?**

Making the determination of what's attackable comes by looking beyond the presence of open source dependencies with known vulnerabilities and examining how they're actually being used, says Manish Gupta, CEO of ShiftLeft.

"There are many tools out there that can easily find and report on these vulnerabilities. However, there is a lot of noise in these findings," Gupta says. "For example, they do not consider how the dependency is used in the application; they don't even consider whether the app even uses the dependency."

The idea of analyzing for attackability also involves assessing additional factors like whether the package that contains the CVE is loaded by the application, whether it is in use by the application, whether the package is in an attacker-controlled path, and whether it is reachable via data flows. In essence, it means taking a simplified threat modeling approach to open source vulnerabilities, with the goal of drastically cutting down on the fire drills.

CISOs have already become all too familiar with these drills. When a new high-profile supply chain vulnerability like Log4Shell or Spring4Shell hits the industry back channels, then blows up into the media headlines, their teams are called to pull long days and nights figuring out where these flaws impact their application portfolios, and even longer hours in applying fixes and mitigations to minimize risk exposures.

To that point: The report noted that 96% of vulnerable Log4J dependencies were not attackable.

**Software Dependencies to the Fore**

Reliance on open source dependencies — both first-hand and through third-party dependencies — is growing in modern development stacks.

"For any major application that uses a large number of dependencies, it is common to have new CVEs multiple times a month," says Gupta. "Multiply that by all the apps in the organization, one can imagine it is no easy task to keep up with all the upgrades."

While updating a package might be easy, he says the associated development work surrounding such a change can often be significant. Often a single library upgrade can precipitate a battery of new tests not just for security but for functionality and quality, and it potentially could require refactoring of code.

"Any organization serious about product quality won't ship a product without thorough testing," he explains. "Also library upgrades are not always fail-safe; there's no guarantee that new versions of open source libraries will be fully backward compatible. So, sometimes teams are also required to change how their app works before they upgrade a library."

**Is Attackability Determination Feasible?**

According to Mark Curphey, founder of OWASP and a longtime appsec advocate, seeking a prioritization model like this is nothing new. However, he says that picking the dimensions of analysis to determine what's risky or attackable can be more complicated in today's application environment than what ShiftLeft proposes.

"It's true and fair to say that the vast majority of vulnerable methods in open-source libraries can't be reached and therefore are not exploitable, but we are now in a world where open-source libraries are like elaborate shop fronts offering all sorts of goodies for developers to consume," Curphey tells Dark Reading. "As an industry, we recently learned from the Log4J saga that when an issue is something like a JNDI interface that few people actually used, there were still paths to exploitation, and so we all had to face the issue."

He's currently on a listening tour for his latest appsec startup, Crash Override, to ask what CSOs' biggest appsec problems are today, and almost all of them say prioritization is their No. 1 problem. He believes it may well be appsec's next big problem to solve.

"So the fundamental premise of the report makes total sense, but what we have also learned from interviews is that answering that question is very hard and more complex than 'am I using a particular bit of code,'" Curphey says. "It's things like business criticality, which includes how many users the system has, how much money flows through it, its public profile, what type of data it is processing, where it is physically located, and therefore what laws are applicable. It's technical things like how it is connected to other systems and what controls, monitoring, and alerts are in place, and the list goes on."

The other problematic thing about using "attackability" or "reachability" as a prioritization filter is understanding the underlying technical data that's being used to determine what is reachable by an attacker, says Stephen Magill, vice president of product innovation for Sonatype.

"Attackability and 'reachability' can be helpful ways of prioritizing vulnerabilities when the underlying vulnerability data is good. What is not helpful is relying on attackability or reachability as a means of compensating for bad vulnerability data," Magill says. "All too often, this is what we see the industry doing: Using inaccurate methods of identifying dependencies, coupling this with noisy data on which versions of which dependencies are vulnerable, and then using reachability-based prioritization to filter the long list of vulnerabilities that results down to something manageable."

In other words, an attackability prioritization is as only as good as the vulnerability data feeding into it, so it is caveat emptor for security teams to truly look into the hood as to how they source their vulnerability data.

"Does it only come from public feeds, or is it the result of in-depth research by a dedicated security team? Also investigate how dependencies are tracked," Magill says. "Are they just the declared dependencies in manifest files or does the tool support analysis of binary artifacts, archives, JARs, etc. These questions will help you determine the quality of the findings being prioritized. As they say 'garbage in, garbage out.'"

Finally, Magill says security leaders need to remember that many threats exist to software supply chains beyond the normal churn of bugs that are found incidentally within open source projects.

"The biggest threats to our software supply chains are malicious, purposeful attacks on open source," he says. "That is a much larger problem that we should be focused on, and completely unrelated to attackability."

Only 3% of Open Source Software Bugs Are Actually Attackable, Researchers Say

Continuous monitoring is key to keeping up with software-as-a-service changes, but that's not all you'll need to get better visibility into your SaaS security.

When the White House warned all businesses to be on high alert for cyberattacks earlier this year, it was a wake-up call for many. While these kinds of warnings are often directed at government agencies or even critical infrastructure companies, a blanket warning is unusual.

All organizations should take this warning as an opportunity to review and, if needed, improve their security. Software-as-a-service (SaaS) application security is often a blind spot, so give your SaaS ecosystem some extra attention. SaaS is ubiquitous, highly configurable, and continuously updated, leaving many organizations vulnerable if they aren't closely monitoring for security gaps and changes.

Continuous monitoring is key to keeping up with SaaS changes, but that's not all you'll need to get better visibility into your SaaS security. Follow these seven steps to implement improved security measures that will help minimize your risk of a breach:

**1\. Close critical configuration gaps.** Some 55% of companies have sensitive data exposed to the internet, and misconfiguration is often to blame. The configurability that makes SaaS apps so powerful is also a weakness if not closely monitored. Get better visibility into the configurations of your SaaS platforms, beginning with those that house the most sensitive data and have the largest number of users. Consult best practices from the Cloud Security Alliance and other experts and close those configuration gaps.

**2\. Disable legacy authentication methods and protocols.** The majority of compromising sign-in attempts come from legacy authentication, which does not support multifactor authentication (MFA). Even if you have an MFA policy enabled on your directory, a bad actor can authenticate using a legacy protocol and bypass MFA. The best way to protect your environment from malicious authentication requests made by legacy protocols is to block these attempts altogether.

**3\. Enforce higher security authentication requirements.** An account is 99.9% less likely to be compromised if you use MFA.

**4\. Analyze and monitor conditional access rules.** Attackers often make modifications to conditional access rules to open access permissions further or implement exception rules. Since these rules can be nested and complex, it's important to validate rules and enable continuous monitoring. Keep an eye out for any changes and IP block exceptions.

**5\. Assess third-party access.** Third-party integrations and applications are often installed with high-level permissions and can be conduits for horizontal privilege escalation to other SaaS systems. Verify that third-party access and applications have been reviewed, approved, and are actively in use. To lower your risk of a third-party compromise, grant permissions and data access to third-party apps following the principle of least privilege and withdraw access as soon as it's no longer needed.

**6\. Identify public and anonymous data access permissions.** Least privilege access offers you better protection as ransomware attacks proliferate and the tool sets to execute attacks are more broadly distributed. Data access modeling and third-party app analysis can help identify exposure points to the public internet, allowing you to better protect all datasets.

**7\. Monitor for anomalous user activity.** Watch for password spraying and excessive failures. Monitor for compromised accounts in threat intelligence feeds. The faster you can spot unusual activity, the faster and better you can respond and limit the damage.

SaaS applications run business-critical functions in many organizations, and SaaS security should be considered as critical as the security measures in place for other technologies. Continuously monitoring your SaaS ecosystem, addressing misconfigurations quickly, and keeping a close eye on third-party access to your systems can help keep your data safe and your business running smoothly.

7 Steps to Stronger SaaS Security

We have a tech innovation problem, not a staff retention (or recruitment) problem.

Over 47 million Americans voluntarily quit their jobs in 2021. This unprecedented mass workforce exit was dubbed the "Great Resignation." Spurred by the COVID-19 pandemic and the long-term trend of workers rethinking their relationships with the labor market, those who quit cited low pay, a lack of advancement opportunities, and feeling disrespected as their top reasons for leaving, according to Pew Research. 

The cybersecurity industry was not immune to this wave of disruption. Despite the fact that the US added more than 250,000 people to the cybersecurity workforce between 2020 and 2021, the need for cybersecurity professionals increased by 30% in that same time. The demand for workers in cybersecurity is growing, driven by unprecedented levels of cyberattacks on governments, Fortune 500 companies, local businesses, and everywhere in between. But the supply of cybersecurity expertise is coming up short.

The cybersecurity talent shortage clearly has real impact, but it may not be as tied to retention strategies or the Great Resignation as many people think. We have a shortage of staff because we are not using security staff efficiently. Better technology that leads to better utilization of the people we have can ease the problem.

**New Solutions, Stronger Workforce**

Weak cybersecurity leaves organizations vulnerable to breaches, data loss, and regulatory penalties. Organizations tap vendors for a robust array of cybersecurity technologies to alleviate these evolving issues. Vendors consume massive budgets to cultivate, hire, and retain an army of workers with the right innovative mindset and technical capabilities to create solutions that address sophisticated, next-generation cyber threats.

But cybersecurity vendors can't create those solutions because they're having trouble retaining enough people in the workforce, right? Well, not exactly.

The superficial reason for the workforce shortage is the booming labor market. In industries where low pay, few promotion opportunities, burnout, general work/life inflexibility, and poor job benefits are the reason workers are fleeing, there is an absolute need for comprehensive solutions to address those new-normal problems. For cybersecurity, however, the reality of the talent shortage is that technology isn't meeting the moment.

The talent pool may, in fact, be dwindling. But the technology platforms and solutions we have need to be better at making life easier — both for current talent and to enhance the capabilities of customers vulnerable to a host of attacks. Automation is key to meeting those goals.

What if cybersecurity vendors solved the issue and helped talented people out there right now by unlocking the ability to embrace true innovation? What if vendors make it easier for everyday users to operate products for effective cybersecurity? The tools themselves need to be simplified and reliable. If there were no need for an overly specialized and multitudinous amount of effort in the workforce, then there would be no technical debt.

Let's be clear: We're not suggesting taking away the expertise of cybersecurity professionals. This is about innovating enough to alleviate the complexities of the solutions and give every customer control during a threat situation. Adopting security automation is the core of cybersecurity democratization.

So what would that look like?

**Automation and Democratization**

It's on industry leaders to facilitate new tools for the everyday user. Think about it from the perspective of the type of tech that regular workers take for granted each day.

Google's G-Suite gives users easy, intuitive access to products like Docs and email; Wix helps users drag, drop, and easily create an entire personalized website; Canva turns anyone into a designer, not just people with hours of Photoshop experience; and so on. These were previously cumbersome processes and difficult-to-use sets of products before innovation tipped the balance toward everyday, intuitive use. This is what needs to be done for cybersecurity.

To be proficient, companies need to develop technology that's going to help empower the everyday user with tools and knowledge that give them understandable visibility into cyberattacks. Here are the elements such automated and democratized technology would need to cover.

*   **Detection:** By automating proactive threat detection and prevention capabilities, people can stay a step ahead of cybercriminals without the need for specialized security skills.
*   **Response:** Ideally when you identify a cyber alert, you need to know what to do with it. Normally the reaction is panic. Incident responses via automated tools need to tell users step by step what to do to mitigate the spread of the attack and improve their cyber resilience over time.
*   **Integration:** Security architectures may be unique, but new solutions must be open source enough to connect any tool in an existing security stack with additional out-of-the-box integrations as threats evolve.

The talent shortage will continue if we don't look at the problem in a different and radical way. Making advanced tools more accessible for all businesses and verticals will foster innovation and solve the talent shortage that is leaving business and consumer data vulnerable. Solutions should become as easily accessible as sending and receiving an email or swiping through your iPhone. The tools and ability to innovate are already here — they just need to be distributed.

Source

DARKReading