After the Raccoon Stealer Trojan disappeared, the RIG Exploit Kit seamlessly adopted Dridex for credential theft.

The cybercriminals behind the RIG Exploit Kit earlier this year traded out the credential-stealer Trojan Raccoon Stealer after its lead developer was killed in the Russian invasion of Ukraine.

According to analysts with Bitdefender, the cybercrime group behind the RIG Exploit Kit was able to quickly substitute in the tried-and-true financial Trojan Dridex, which has a range of functions, including keylogging and the ability to steal screenshots. 

"The move to Dridex was a strategic decision to save the operation," Bogdan Botezatu, director, Threat Research and Reporting at Bitdefender, tells Dark Reading. "Cybercriminals running this campaign had to move to a different option or lose the money they had already invested in renting out access to the RIG EK panel. Dridex is a powerful information-stealer that, to some extent, provides similar functionality to Raccoon. Unlike Raccoon, it is still operational and can offer 'business continuity' to the cybercriminals behind this campaign."

The RIG Exploit Kit lets cybercriminals quickly swap out payloads to avoid detection or in case of compromise, according to researchers at Bitdefender, making adaptability part of its product. 

"This once again demonstrates that threat actors are agile and quick to adapt to change," the analysts wrote in their report on the malware campaign. 

"In order to be prepared, defenders should patch the known vulnerabilities in software used across the organization and monitor for the indicators of compromise (IOCs), Botezatu counsels. "A security solution with machine-learning capabilities can detect and block the payload at various execution stages as well."

It's also worth noting that Racoon is likely to make a reappearance, Botezatu notes.

"The Raccoon group has hit a temporary stop with the death of one of its operators, but we believe the team will regroup," he says. "Usually, such groups suspend their operations when teams get arrested or when they voluntarily decide to shift to a more lucrative business. Loss of a team member is a temporary road block and we presume that they will get back online as soon as they manage to recruit a replacement."

RIG Exploit Kit Replaces Raccoon Stealer Trojan With Dridex

Experts tell teams to prepare for more regulation, platform consolidation, management scrutiny, and attackers with the ability to claim human casualties.

Security teams should prepare for what researchers say will be a challenging environment through 2023, with increased pressure from government regulators, partners, and threat actors.   

Gartner kicked off its Security & Risk Management Summit with the release of its analysts' assessments of the work ahead, which Richard Addiscott, the company's senior director analyst, discussed during his opening keynote address.

“We can’t fall into old habits and try to treat everything the same as we did in the past,” Addiscott said. “Most security and risk leaders now recognize that major disruption is only one crisis away. We can’t control it, but we can evolve our thinking, our philosophy, our program, and our architecture.”

Topping Gartner's list of eight predictions is a rise in the government regulation of consumer privacy rights and ransomware response, a widespread shift by enterprises to unify security platforms, more zero trust, and, troublingly, the prediction that by 2025 threat actors will likely have figured out how to "weaponize operational technology environments successfully to cause human casualties, the cybersecurity report said. 

The eight specific predictions are:

1.  Through 2023, government regulations requiring organizations to provide consumer privacy rights will cover 5 billion citizens and more than 70% of the global GDP.
2.  By 2025, 80% of enterprises will adopt a strategy to unify Web, cloud services, and private application access from a single vendor’s security service edge (SSE) platform.
3.  Sixty percent of organizations will embrace zero trust as a starting point for security by 2025. More than half will fail to realize the benefits.
4.  By 2025, 60% of organizations will use cybersecurity risk as a primary determinant in conducting third-party transactions and business engagements.
5.  Through 2025, 30% of nation-states will pass legislation that regulates ransomware payments, fines, and negotiations, up from less than 1% in 2021.
6.  By 2025, threat actors will have weaponized operational technology environments successfully to cause human casualties.
7.  By 2025, 70% of CEOs will mandate a culture of organizational resilience to survive coinciding threats from cybercrime, severe weather events, civil unrest, and political instabilities.
8.  By 2026, 50% of C-level executives will have performance requirements related to risk built into their employment contracts.

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

Gartner: Regulation, Human Costs Will Create Stormy Cybersecurity Weather Ahead

Open source is here to stay, and it's imperative that CIOs have a mature, open source engagement strategy, across consumption, contribution, and funding as a pillar of digital transformation.

Following the trio of the Log4J vulnerability and the more recent compromise of two open source libraries in the NPM ecosystem and one in Spring Core, supply chain security is weighing heavily on cyber defenders' minds. While the financial services sector has hardened its cyber defenses compared with other industries and become one of the earliest adopters of zero-trust security, institutions must continue to embrace open source technology while actively engaging in risk mitigation.

With so many foundational components of the global tech stack originating from open source code repositories like GitHub, recent exploits have heightened worries that this open ecosystem is inherently vulnerable to attack. This is especially true given the finance industry's finance industry's embrace of open source, as shown by Goldman Sachs contributing source code of several of its data modules as open source in 2020.

**Keeping Open Source Environments Protected**

First off, financial institutions must assume a more active role in the funding of open source foundations and direct-to-maintainer grants to help limit exposures from critical code dependencies, as illustrated by the Log4Shell debacle. To this end, public-private sector partnerships will be vital for financial institutions looking to harden their open source security postures. Confronting the inherent DevSecOps of the open source ecosystem requires a financial and strategic commitment from institutions willing to support the whole spectrum of open source maintainers — and not just the Apache Software Foundations of this world. Projects like the OpenSSF Alpha-Omega initiative are a great example of this approach.

Financial institutions also need to adopt a more robust software bill of materials (SBOMs), a key point highlighted in President Biden’s executive order from last June. Modern SBOMs deploy machine-readable processing, a technology that enables systems to ingest incoming structured report data, to autonomously analyze the state of SBOM readiness by organizations around the world. SBOMs can thus help financial institutions rapidly identify patterns across their industry and across borders, helping them spot critical risk issues before they metastasize into larger problems.

A table-stakes strategy for financial institutions to mitigate open source risks on the consumption side include the implementation of stronger internal license and IP controls and tools to track and monitor inbound open source projects. More granular strategic solutions start with financial institutions taking time to understand the defenders that are focused on securing the open source realm. Organizations like Mend, Sonatype, and Synk are key players in this world.

The broader sustainability of the open source ecosystem is another reason for financial institutions to assume a more hands-on role in the development of code repositories and other active-source artifacts. Institutions should consider offering secure coding training as part of their onboarding, something too often overlooked in academic curricula.

Encouraging in-house developers to contribute "sweat equity" to the ecosystem will increase the number of eyes on open source artifacts, thus enhancing the odds that financial institutions will be able to spot code vulnerabilities before they threaten a SolarWinds type of breach. This approach will effectively reduce the probability and blast radius of future vulnerabilities.

**Benefits of Open Source Outweigh the Risks**

Despite recent, worrisome supply chain attacks, financial institutions should not be deterred by these challenges. The global financial industry is now very seriously democratizing software through open source, not only as a cost reduction but as a powerful collaboration model that goes beyond code to be used to address challenges like data standardization and industrywide interoperable workflows. Open source is here to stay, and therefore it is no longer optional — it's imperative that CIOs have a mature, open source engagement strategy, across consumption, contribution, and funding as a pillar of their digital transformation endeavors.

Institutions are doing more than just implementing code that another developer has updated. Financial organizations should look to invest internal developer resources to actively contribute to code repositories. Developers should be contributing code not just in their spare time, but more appropriately, while they're on the job within the expected scope of their organizational roles.

By taking a proprietary stake in the open-innovation ecosystem, financial institutions can better mitigate vulnerabilities and exposures emanating from their tech stacks. This type of risk management also requires the articulation of companywide policies, learning, and collaboration resources throughout the firm. Naturally, financial institutions need to delegate and establish leadership roles to oversee the effort.

Whether through open source foundations or direct monetary or sweat-equity contributions to projects, financial institutions must realize the importance of professional software supply chain management. They should also understand the roles that consumers must play in securing the open source IT stack, which underpins the modern digital economy.

Why Financial Institutions Must Double Down on Open Source Investments

While there's an immediate need to improve MFA adoption, it's also critical to move to more advanced and secure passwordless frameworks, including biometrics. (Part 1 of 2)

The fact that we continue to rely on passwords this deep into the digital age is more than a bit jarring. These alphanumeric scraps, the equivalent of digital skeleton keys, once served as a valuable tool. Unfortunately, passwords are now far more trouble than they're worth. They provide little protection against identity theft, breaches, and myriad other problems.

Yet completely ditching passwords is out of the question — at least for now. While they may rank as an almost total security fail and a bane for everyone, they remain an entrenched standard. Consequently, multifactor authentication (MFA) has become a necessity, but it too presents challenges bordering on outright problems.

This is the first of a two-part series about how businesses can adopt stronger and better authentication methods. While there's an immediate need to boost MFA adoption, it's also critical to move to more advanced and secure passwordless frameworks, including those that use biometrics.

**Embarrassment of Riches**

As with every technology, an accumulation of solutions eventually becomes a new problem. Most organizations and many consumers recognize the need to move beyond password-only authentication. Yet two-factor authentication (2FA) and even many MFA techniques were never designed for today's sophisticated digital frameworks.

"When you log into six different systems during the day and each of them uses a different method ... you wind up with two-factor authentication PTSD," says Michael Engle, co-founder and chief security officer at 1Kosmos. "You spend a significant time fetching codes and launching apps."

The mix of methods — including time-based one-time password (TOTP), SMS and email 2FA, push-based 2FA, universal second factor (U2F) tokens, WebAuthn, and desktop agents — introduce an often-confusing array of options for both companies and consumers. Making matters worse, they deliver varying levels of protection, and most people aren't equipped to understand the pros and cons. For instance, widely used SMS and email codes are easily intercepted or breached when a crook has access to a device. Toolkits that facilitate man-in-the-middle attacks and other password exploits are now widely available on sites such as GitHub.

Consumer and enterprise fatigue is at a breaking point. And while significantly better MFA and passwordless systems are taking shape — Apple, Google, and Microsoft have announced they are moving to passwordless sign-ins built on the FIDO2 standard — organizations continue to struggle with adoption.

Design, usability, and functionality are all critical. There's a need to convince people to move beyond a basic password and adopt MFA, but it's also critical to deploy higher grade MFA methods while moving to passwordless. 

"This requires improved UX and education. There's a need for the process to be seamless," says Don Tait, a senior analyst at Omdia Consulting.

**Risky Business**

It's a startling and entirely disturbing fact: Despite a seemingly endless string of hacks, attacks, breaches, and breakdowns — 81% of hacking-related breaches are caused by password issues — only 29% of consumers believe that the inconvenience of 2FA is always worth the security trade-off. About 36% are willing to use 2FA in some cases, depending on the importance of the account.

The reasons for this reticence are at least partly rooted in the nature of today's online world. For better or worse, people expect Web pages to load instantaneously, and they seek access to accounts without any latency — even when dozens of APIs and servers around the world are required for a transaction. Remarkably, one study conducted by Microsoft found that the average person only has an attention span of approximately eight seconds.

Yet it's also clear that MFA frameworks can be a big hassle. Oftentimes, it's necessary to request a text code or pull out a phone and open an authenticator app from Google or Microsoft and type in a code. Meanwhile, physical tokens, such as YubiKey, offer stellar security — but they can be difficult to set up and use.

MFA participation is ticking up due to the pandemic and ominous warnings about the risks of relying on a password only; Okta found that MFA adoption rose by about 80% during the early stages of the pandemic. However, attacks are escalating and becoming more sophisticated. The net result is a relative move backward.

"There are too many companies giving too little thought to how to implement more advanced MFA and passwordless systems," says Jasson Casey, CTO for authentication vendor Beyond Identity. "You can't build a security architecture without considering design and usability. As the level of friction goes up, participation goes down."

These issues unfold in several ways. Design elements may hide MFA options or deliver confusing instructions for how to set it up. They sometimes provide confusing or ominous warnings that frighten users, or a site or service doesn't communicate the value of using MFA. Frequently, users don't see any compelling reason to adopt this additional layer of security.

"People turn to digital services because they're looking for ease of use and convenience," says Kalev Rundu, senior product manager at authentication firm Veriff. MFA must not be any different. It must fit seamlessly with the broader digital interaction and deliver a clear advantage or other forms of authentication.

**Designs on Security**

Gaining buy-in is critical. Researchers from the Max Planck Institute for Security and Privacy; the University of California, San Diego; and Facebook found that one of the keys to convincing people to turn on MFA is to present the decision as a personal empowerment choice. This might include a message like, "You can increase your protection against account hacking" or "Protect your account, pages and friends."

When researchers tested this personal responsibility approach with accompanying buttons on Facebook, it led to an uptick in MFA adoption by 33% among 622,419 participants. When users viewed a message about the advantages of being protected, they were 28% more likely to adopt MFA. On the other hand, the corporate responsibility button didn't prompt any change in behavior.

Another technique that boosts adoption revolves around an incentive or a reward — an approach that has already gained traction within gaming platforms like Fortnight and World of Warcraft. In 2019, a group of researchers from the University of Bonn and Leibniz University Hannover in Germany found that even a small incentive, such as an upgraded avatar or another small gift, can push numbers up.

Colors, placement, and design elements also matter. Delivering the request at the right moment — without interrupting the flow of an interaction or transaction — is crucial. 

"It must be so easy that doing it for the first time has nearly no friction," 1Kosmos' Engle says. QR codes and push-to-app authentications can help, especially when a user can authorize the sign-in from a separate authorized device.

Still, none of these approaches are seamless — and they aren't bulletproof. The future of MFA and full passwordless systems lies in biometrics, FIDO2, and emerging systems that not only authenticate to an account on a device, but also verify a person's identity. 

"A new era of authentication is emerging," Omdia's Tait says.

_In part 2, Dark Reading takes a look at the rapidly evolving passwordless space and what companies need to do to stamp out passwords once and for all._

Evolving Beyond the Password: It's Time to Up the Ante

The BRATA Android banking Trojan is evolving into a persistent threat with a new phishing technique and event-logging capabilities.

An Android-based banking Trojan known as BRATA (short for Brazilian RAT Android) has evolved to incorporate new phishing techniques and capabilities to acquire GPS, overlay, SMS, and device management permissions.  

The Italian mobile security company Cleafy reported in a blog post this week that these changes align with an advanced persistent threat (APT) pattern of activity.

"Threat actors behind BRATA now target a specific financial institution at a time, and change their focus only once the targeted victim starts to implement consistent countermeasures against them," the blog post explained. "Then, they move away from the spotlight, to come out with a different target and strategies of infections."

The new variant, which is targeting the EU region by posing as specific bank applications, can also now perform event logging through its ability to sideload a second-stage piece of malware from its command-and-control (C2) server.

**Ability to Bypass MFA**

The threat actors operating the new malware variant (BRATA.A) are also expanding their capabilities to include a methodology for potentially bypassing SMS-based multifactor authentication (MFA).

The updated phishing technique can mimic a targeted bank's login page, part of the group's strategy to acquire personal information to be used later for social-engineering purposes.

"Once installed, the pattern of the attack is similar to other SMS stealers," according to the blog post. "This consists in the malicious app asking the user to change the default messaging app with the malicious one to intercept all incoming messages."

Credential harvesting is common in banking Trojans and stealer malware, but bypassing MFA is a bit more complicated.

"This functionality, along with BRATA's ability to remain undetected for prolonged periods of time, could potentially classify the threat actors as an APT," says Nicole Hoffman, senior cyber threat intelligence analyst at Digital Shadows.

**BRATA Actors Thinking About Future Development**

From the perspective of John Bambenek, principal threat hunter at Netenrich, the ability to request additional permissions on the device indicates what the attackers are thinking as far as future development.

"Not all the new features are actively collecting and transmitting data to the attacker, but future updates can change that," he says. "The actors are spending real effort to make sure they can maximize their success. Banks are constantly evolving, so attackers must do so also."

He adds that because mobile malware is typically still just an app, consumers can protect themselves by only installing apps from approved app stores and be wary when apps are asking for banking credentials.

"Financial institutions need to invest in behavioral analytics to detect stolen credential use against their online presence to prevent fraud against their consumers," Bambenek says.

In a statement provided to Dark Reading, the Cleafy Threat Intelligence team notes BRATA's evolution suggests the threat actors plan to diversify their business model, and consequently its income.

Cleafy's hypothesis is that BRATA is sold as malware-as-a-service (MaaS) to different groups, since the firm is tracking many variants of this malware hitting different countries across the globe.

"It has been observed that they started refactoring part of the malware, in order to tailor it according to the requests of their customers," the statement reads.

**Evolution of a Trojan**

In January, Cleafy discovered the group behind BRATA manipulating Android's factory reset to prevent victims from discovering or reporting and preventing illicit wire transfers. At that point, the malware campaigns were targeting Italian banks.

During the last year, BRATA was delivered through sideloading techniques, not through the official Google Play Store.

Cleafy recommends users pay particular attention to downloading apps from untrusted websites or whenever SMS is required to install an application.

"However, considering the Android 13 restriction for sideloaded apps, we do not exclude that in the future BRATA will be also delivered through official stores, like other famous malware have been trying to do in recent months (e.g. Sharkbot, Teabot etc.)," the statement continues.

Kaspersky first discovered BRATA in 2019 when it was simply spyware and targeted at users in Brazil.

BRATA Android Malware Evolves Into an APT

Zero trust isn’t just about authentication. Organizations can combine identity data with business awareness to address issues such as insider threat.

Zero trust is growing in popularity in enterprise security because not trusting users by default works really well to reduce risk. However, people start having unrealistic expectations when they conflate reducing risk with eliminating risk, says Nabil Zoldjalali, VP of technology innovation at Darktrace. There is a subtle difference between the two that security teams can’t overlook.  

“I can eliminate risk entirely if I have absolute no trust,” Zoldjalali says. What’s more realistic – and attainable – is to try to lower the amount of default trust to as close to zero as possible. Zero trust should be treated as “an ideal end-state,” he adds.

As long as people have access to applications, tools, and different pieces of software, there’s always going to be a level of inherent risk. The idea behind zero-trust architecture is to set up context-based access for each identity so that users only see and access the applications that are relevant to them.

Context-aware access takes into account different factors. A user logging in may see only three applications when logging in as opposed to all the applications belonging to the organization. That list may change depending on time, especially if there are certain times or dates when the user is not expected to use that application. Or a user logging in from a different location would also get a different level of access.

**Zero Trust Requires Business Visibility**

Zero trust makes sense for security practitioners because they focus on attacker behavior and all the way things can go wrong, Zoldjalali says. But focusing on the attacker too much can make it easy to forget to think about what is being protected. 

“We’re saying, ‘I don’t want to inherently trust anyone in my business because if something goes wrong, I want to lower the blast radius that’s associated to it,’ and that’s meaningful to us,” he says. “But it sounds funny to a nonsecurity person when we say, ‘Listen, the company doesn’t trust anyone.’”

For zero trust to really work, both approaches – lowering trust and developing a strong understanding and awareness of the business – are critical. Having that business awareness and wall-to-wall visibility gives security teams the context necessary for zero trust. It also allows them to verify that the zero-trust architecture is working as planned. For instance, if the organization’s rules for conditional access aren’t working when they should be, it would be hard for security teams to even know that is the case if they don’t understand the business, Zoldjalali says.

**Zero Trust Beyond Authentication**

The beauty of zero trust is that its effects go beyond authentication. Security teams can combine identity data with information about what happened in the environment _after_ authentication to detect and actually stop attacks, Zoldjalali says. Security teams can look at incidents and trace digital activity back to see what the authentication prompt looked like and how the user was identified. Based on that information, security staff can make changes to the group policy or adjust permissions.

Darktrace’s self-learning artificial intelligence (AI) learns the business so that it knows what activities would be considered part of normal operations, Zoldjalali explains. Because the AI technology looks for deviations from the norm, it doesn’t need to know what historic attacks looked like or understand what kind of attacks are currently ongoing. It just looks for something that is different. 

“With zero trust, we allow people to do what they normally do,” he says. The AI assesses significant deviations from the person’s normal behavior to determine whether there is a threat to the business. If there is, the AI takes action to address the threat.

This mindset is extremely useful when considering the insider threat. 

“Insiders don’t just wake up one morning and say, ‘Today I’m going to be a big threat to the business.’ There’s usually some kind of context and back story,” Zoldjalali says. There may be a specific incident that acts as a trigger or a pattern of issues that contributes to a sense of unhappiness. 

So at that point, the user action – such as an act of sabotage or data theft – looks “very, very different from how they normally behave,” he says. The user may be logging in at unusual hours, using different devices, going down different folder paths, or downloading more data than usual.

“Having an approach that’s fundamentally based on understanding the business is one of the best ways to have accurate anomaly detection,” Zoldjalali says. And with early detection, security teams can adjust context-based access policies to block the user’s activities.

“When you combine different approaches, that's where you start getting closer and closer to an ideal state \[for zero trust\]," he adds.

Reducing Risk With Zero Trust

Deep-dive study unearthed security flaws that could allow remote code execution, file manipulation, and malicious firmware uploads, among other badness.

A new analysis of data from multiple sources has uncovered a total of 56 vulnerabilities in OT products from 10 vendors, including notable ones such as Honeywell, Siemens, and Emerson.

Many of the vulnerabilities are the result of device vendors not including basic security mechanisms, such as authentication and encryption, in their technologies. Often they exist in older products that asset owners are continuing to use even though more secure options are available. Significantly, the vulnerabilities are present in products that have gone through some sort of auditing process and were certified as being safe for OT networks, a new study by Forescout found.

Researchers from Forescout’s Vedere Labs discovered the vulnerabilities from data they gathered via open source intelligence, Shodan search-engine queries, and customer networks. The vulnerabilities exist in widely used products and protocols in a range of critical infrastructure sectors, such as oil and gas, chemical, nuclear, and power generation. The security vendor released a report Tuesday highlighting the main findings from its study.

The vulnerabilities — collectively labeled “OT: Icefall” — stemmed from four primary reasons: insecure engineering protocols, weak cryptography or broken authentication mechanisms, insecure firmware updates, and native functions that enabled remote code execution. The bugs enabled a variety of malicious activity, including remote code execution, denial-of-service attacks, file and configuration manipulation, authentication bypass, and credential theft. Affected devices included programmable logic controllers, remote terminal units, engineering workstations, distribute control systems, and one supervisory control and data acquisition (SCADA) system.

**Insecure by Design**

The flaws were not introduced by programming and coding errors, says Daniel dos Santos, head of security research at Forescout. Rather, the technologies are vulnerable to attack because they are insecure by design, Santos says. They often lack critical controls like those needed to authenticate users and actions, encrypt data, and verify whether firmware updates and software are signed and verified. When these mechanisms are present, they are often weak and easily hacked or seriously undermined by other issues, like the presence of hard-coded and plaintext credentials on the device, insufficient randomness and broken crypto, or features that allow arbitrary file writes, he says.

“While it’s a semantic difference and ends up with the same vulnerabilities, it’s not so much they are 'insecure by design' as they are designed without security as a consideration,” says Mike Parkin, senior technical engineer at Vulcan Cyber. “Stronger security has been baked into newer OT equipment, but there is still a lot of kit out there where it just wasn’t a consideration." 

In many cases OT technology was designed with the idea that it would be isolated, protected from outside access, and not exposed to anything but its operational environment. “Unfortunately, the real world wasn’t quite so cleanly defined,” he says.

Foresight found numerous instances of vulnerabilities tied to poor design. For instance, 38% of the vulnerabilities that Forescout discovered allowed for credential compromise, and 21% gave attackers a way to introduce poisoned firmware into the environment. Fourteen percent of the flaws stemmed from native functionality — such as logic downloads, firmware updates, and memory read/write operations — that gave attackers a way to execute malicious code remotely on OT systems. 

For example, none of the affected systems supported logic signing, 62% accepted firmware downloads via Ethernet, and 51% authenticated such downloads. Nine of the 56 flaws that Forescout discovered were related to unauthenticated protocols.

**(Not) Certifiably Secure  
**

Disturbingly, nearly three-quarters — 74% — of the vulnerable product families had some sort of certification regarding their suitability for use in critical OT environments. Examples of such certifications included ISASecure Component Security Assurance, ISASecure System Security Assurance (SSA), GE Achilles Communications Certification, and ANSSI Certification de Sécurité de Premier Niveau. 

The fact that vulnerable products were certified as compliant with these standards suggests product evaluations were likely limited in scope, were too focused on functional testing, or were hobbled by opaque security definitions, Forescout said.

The presence of vulnerabilities stemming from insecure design in OT devices and protocols is troubling because of the growing attacker interest in these environments, Santos says. He points to ICS- and OT- specific malware such as Industroyer, Triton and Incontroller as evidence of the increasingly sophisticated capabilities that attackers have begun to deploy in attacking ICS and OT facilities. 

“There is still this lingering notion that attackers don’t understand the environment or proprietary OT technology,” Santos says. 

That is simply not true, he says. Nation-state actors and even well-resourced ransomware groups have demonstrated their ability to access OT environments. Detailed information on OT environments is also available in the public domain and equipment for testing out attacks are easily available in markets for used technology products, he notes.

“OT/ICS and IoT environments are becoming the preferred targets by cybercriminals, for many reasons,” says Bud Broomhead, CEO at Viakoo. 

Among them is the growing use of vulnerable open source components — such as Log4j — in OT/ICS environments and the fact that the systems are often managed outside the IT department. 

“Often OT/ICS teams lack the IT skills to maintain complete cyber hygiene” and are focused on operational issues instead, Broomhead says. As a result, there is little oversight over patching practices and password management. OT/ICS devices are often also not visible to IT, or sometimes to the organizations managing them. 

Another issue is that devices are often used well past the manufacturer's support time frame. 

“Many OT/ICS devices are in operation past the time the manufacturer is supporting patches or updates,” Broomhead says. “Security solutions used for IT systems do not work for OT/ISC environments. OT/ICS devices do not accept agents, and therefore organizations must implement solutions, such as for patching, certificate management, and password rotations specifically designed for OT/ISC environments.”

Parkin also urges organizations to pay attention to the fundamental security practices such as keeping patches up to date and implementing proper network segmentation and isolation to keep OT and ICS environments away from public access. 

“The management and control platforms should have proper isolation and authentication, including multi-factor authentication, and there should be some kind of traffic monitoring in place to make sure \[OT\] is only being accessed by authorized users from authorized locations,” he says.

56 Vulnerabilities Discovered in OT Products From 10 Different Vendors

AI can help companies more effectively identify and respond to threats, as well as harden applications.

Much has been made of the use of artificial intelligence in security. Some experts will tell you it is the single biggest key to success, while others will tell you that AI is little more than marketing jargon without any real-world value. I think the truth is somewhere in the middle. AI absolutely has a place in security, but it is not a silver bullet. With that said, there are three primary ways that organizations should be using AI to act as a force multiplier for security teams.

**1\. Attack Prevention**

The use of AI in security should be very focused on multiplying the efforts of security teams, especially considering the current shortage of security skills.

A recent report from JupiterOne found that security teams are responsible for more than 165,000 cyber assets across cloud workloads, devices, network assets, applications, data assets, and users. Trying to defend that many assets is a daunting task. In fact, according to a report by Capgemini Research Institute, 61% of organizations said they would not be able to identify critical threats without AI.

AI and machine learning can reduce the workload for analysts by automatically sifting through data logs and identifying relevant threats. When used effectively, artificial intelligence will not only alert security professionals to threats but also will classify types of attack, allowing security teams to prepare appropriate responses. With this type of ongoing, comprehensive analysis of behavior patterns, analysts can manage even complex threats with far less manual effort, reducing mistakes made due to burnout and exhaustion.

**2\. Intrusion Detection**

Prevention and detection go hand in hand because, as all security professionals know, a determined and skilled attacker will get in eventually. Identifying such a breach is highly dependent on anomaly detection, and this is another security area where AI shines. AI doesn’t get bored and tired like humans do while scanning through the never-ending tedium of operations logs looking for odd behavior.

AI can be even more help when it comes to alert fatigue, a boogeyman of our own creation. Our efforts to identify every possible threat has resulted in an overwhelming number of security alerts. However, most of the alerts that hit the security operations center are false positives that security teams have to wade through to find actual threats. AI can be used to help security teams spend their time and energy wisely by identifying which alerts need immediate attention, which can wait, and which can be ignored entirely.

**3\. Application Security and Developer Productivity**

One of the often-overlooked use cases for AI is application security. In today's competitive climate, companies are constantly launching new apps and updates. It's easy for AppSec teams to fall behind, and these challenges only snowball when vulnerabilities within code are discovered and both AppSec and development teams must divert their time and attention to remediating the issue.

As with attack prevention and intrusion detection, the key value proposition for AI in AppSec is acting as a force multiplier by taking on repetitive and menial tasks. Ensuring the delivery of a secure application involves going through hundreds or thousands of security findings to uncover relationships and gain insight into the risk a vulnerability represents. AI can significantly reduce the time AppSec teams sit with each new application launch or update so that they can focus on more intensive and important tasks.

**Conclusion**

There may be a day when AI is a security savior, but, for the time being, it can be incredibly valuable in helping security teams make sense of the mountains of data an enterprise generates and in ensuring that applications are launched securely.

AI Is Not a Security Silver Bullet

Only about half of firms have an open source software security policy in place to guide developers in the use of components and frameworks, but those that do exhibit better security.

Companies that have an open source software (OSS) security policy in place tend to perform much better in self-assessed measures of readiness. They also tend to have dedicated teams in charge of driving software security, according to a survey published on June 21.

The survey — published by software-security firm Snyk and the Linux Foundation on Tuesday — found that seven out of 10 companies that have an OSS security policy in place consider their application development to be highly or somewhat secure. Comparatively, just 45% of companies that failed to institute such a policy consider themselves at least somewhat secure.

Open source software has significant benefits for application development, but companies also have to recognize and prepare for the downsides, says Matt Jarvis, director of developer relations for Snyk.

"While open source is a proven mechanism for innovation and building high-quality software, it's becoming somewhat a victim of its own success in that its ubiquity has made it a target for supply-chain attacks," he says. "Companies need to build a stronger understanding of both the mechanisms by which open source works, and this includes governance as well as code, and strengthen their approach to supply chain management through adopting developer-first security tooling and methodologies."

**Smaller Firms Lag in OSS Policies**

Overall, only about half of firms have an open source security policy in place to guide developers in the use of components and frameworks, with a greater number of small companies, 60%, either having no policies or not knowing whether they have one, according to the report.

The economics of security tends to reduce the priority of creating a formal policy for startups and smaller firms, the report states.

"Small organizations have small IT staffs and budgets, and the functional needs of the business often take precedence so that the business can remain competitive," the report states. "Lack of resources and time were the leading reasons why organizations were not addressing OSS security best practices."

    

Source: "Addressing Cybersecurity Challenges in Open Source Software" report

Different programming languages also brought different security considerations, according to the study. Applications written in .NET, for example, had the longest average time to fix flaws at 148 days, followed by JavaScript, Meanwhile, those written in Go had the speediest time-to-patch, and were typically fixed in a third of that time, or 49 days.

**JavaScript Dependencies Abound**

JavaScript application have the most dependencies — an average of 174 per project, according to Snyk — or about seven times the language with the fewest dependencies, Python, which averages 25 per project.

While large transitive dependency trees can result in circuitous paths to fix vulnerabilities, having a large number of dependencies is not necessarily a disadvantage, if an organization has ways to track the relationships between projects, says Jarvis.

"JavaScript packages tend to have a smaller scope than other ecosystems, so whilst there are more of them, there may be less code to audit for potential weaknesses," he says. "The most important issue is to understand the dependencies which you are using, particularly the transitive ones brought in as dependencies of dependencies, and that comes down to using the appropriate security tooling to scan things."  

However, the data also shows that different languages tended to have different severities of flaws. The average project written in Java, for example, had more than 47 high-severity vulnerabilities and 28 medium-severity vulnerabilities, much higher than the second-ranked JavaScript, which had an average of 18 and 21 vulnerabilities, respectively. However, Python had the most low-severity vulnerabilities, an average of 20 per project.

"There are a lot of factors at play in the data — the complexity of projects, the number of developers, and the popularity will all have an impact on the number and types of vulnerabilities," Jarvis says. "Many developer eyes on projects that are extremely popular are likely to surface more bugs."

**Automation = Security Maturity**

Despite the importance of identifying vulnerabilities in dependencies, most security-mature companies — those with OSS security policies — rely on industry vulnerability advisories (60%), automated monitoring of packages for bugs (60%), and notifications from package maintainers (49%), according to the survey.

Automated monitoring represents the most significant gap between security-mature firms and those firms without a policy, with only 38% of companies that do not have a policy using some sort of automated monitoring, compared with the 60% of mature firms.

Companies should add an OSS security policy if they don't have one, as a way to harden their development security, says Snyk's Jarvis. Even a lightweight policy is a good start, he says.

"There is a correlation between having a policy and the sentiment of stating that development is somewhat secure," he says. "We think having a policy in place is a reasonable starting point for security maturity, as it indicates the organization is aware of the potential issues and has started that journey."

Open Source Software Security Begins to Mature

After bragging in underground forums, the woman who stole 100 million credit applications from Capital One has been found guilty.

The 36-year-old Seattle tech worker behind the infamous 2019 Capital One data breach has been convicted on seven charges related to the data theft — which are punishable by up to 20 years in jail.

In the incident, Paige Thompson, who operated under the hacker handle "erratic," made off with more than 100 million credit applications that were held in a misconfigured Amazon Web Services storage bucket in the cloud. She was arrested shortly thereafter, after the banking giant traced the malicious activity back to her and alerted the FBI.

"Ms. Thompson used her hacking skills to steal the personal information of more than 100 million people, and hijacked computer servers to mine cryptocurrency," said US Attorney Nick Brown, in a statement. "Far from being an ethical hacker trying to help companies with their computer security, she exploited mistakes to steal valuable data and sought to enrich herself."

Prosecutors noted that Thompson specifically used a scanner to look for AWS misconfigurations, in which databases are left open to the Internet without authentication required for access. In all, she managed to infiltrate the databases of 30 entities, including Capital One — stealing data and in some cases planting cryptocurrency miners.

According to a Department of Justice statement, Thompson "spent hundreds of hours advancing her scheme, and bragged about her illegal conduct to others via text or online forums."

After a seven-day trial and 10 hours of deliberation, a jury in US District Court in Seattle found Thompson guilty of wire fraud, five counts of unauthorized access to a protected computer, and damaging a protected computer. The jury found her not guilty of access-device fraud and aggravated identity theft.

Thompson is scheduled for sentencing by US District Judge Robert S. Lasnik on Sept. 15.

"She wanted data, she wanted money, and she wanted to brag," Assistant US Attorney Andrew Friedman said in closing arguments.

"We are pleased with the outcome of the trial and remain thankful for the tireless work of the US Attorney's Office in Seattle and the FBI's Seattle Field Office in prosecuting this important case," Capital One said in a media statement.

**Cloud Misconfigurations Remain Rampant**

While Thompson was bent on malicious activity, the incident also brought cloud-security responsibility and the issue of misconfigurations to the fore. Capital One was found to be negligent for leaving sensitive financial data open to the public, resulting in an $80 million fine. It also settled customer lawsuits for $190 million — not an inexpensive result.

"The Capital One breach really put cloud security at the forefront of many enterprises," says John Bambenek, principal threat hunter at Netenrich. "Prior to that, there was a misconception that the cloud companies would handle security and that default settings were 'secure enough.' The reality is, the shared-security model requires users to make sure that their cloud environments are secure and that data does not accidentally leak."

In its recent report on cloud misconfigurations, security firm Rapid7 noted that breaches stemming from cloud misconfigurations continue to happen with "distressing frequency."

"First and foremost, you should now be keenly aware that there are individuals actively seeking out cloud service misconfigurations on a daily basis," researchers warned in the report. "Given the right tooling, it's almost trivial for any moderately clever person to hunt for these cracks in the cloud at scale, and they don't even need to be targeting your organization specifically to come across that unintended misconfiguration which ends up exposing sensitive data in your care."

As an example, earlier this month researchers from Secureworks Counter Threat Unit (CTU) found that cyberattackers are targeting misconfigured Elasticsearch cloud buckets for extortion purposes. After finding data exposed on the public Internet, the attackers then steal the wide-open data and replace it with a ransom note. At the time, nearly 1,200 instances had been affected.

Thus, enterprises should dedicate resources to cloud security, including planning for safe and resilient configurations and automated processes to monitor for mistakes and oversights, researchers noted.

Bambenek says there's evidence that things are getting better.

"It's taken a few years, however we are making real strides in not only having default-secure settings, but for security tools to start detecting misconfigurations and malicious behavior in cloud environments," he tells Dark Reading.

Source

DARKReading