The company's Confidential Data Search technique relies on confidential computing to keep data secure even while it is in use.

Fortanix is bringing hardware security technology to database search with Confidential Data Search, with the goal to help organizations process highly sensitive data in databases. Fortanix's technology uses confidential computing technologies to allow data to be searched within the hardware vault.

Various encryption schemes and technologies are used to protect data while at rest and while being transported between systems. Confidential computing provides layers of hardware protection so that data remains secure even while it is being processed. Data is stored in a secure hardware vault, authorized parties need a code to unlock the vault, and the data is processed inside without ever leaving the vault.

Advancements in chip technology have made it possible to build these secure vaults directly inside chips. The chip makers have also baked in hardware mechanisms called attestation, which ensures only authorized parties can access data in secure vaults.

Homomorphic encryption is typically used when banks and other large enterprises need to offer the ability to search the database without exposing the unencrypted information, because that scheme allows users to work directly on encrypted data without turning it into plaintext. However, that form of encryption may not be the best for some types of searches, says Richard Searle, vice president of confidential computing at Fortanix. He notes that homomorphic encryption search gets slower and complicated with complex query requests.

"You need to perform that search in plaintext, and the only way to do that is within the confidential computing trusted execution environment, where it is shielded from the outside, there's no human access, no external application access, no operating system access," Searle says. "You can run the query in the same way as you would in an unsecured world."

Searle also notes that in many cases, vendors using homomorphic encryption are working with nonstandard hardware — not off-the-shelf Intel Xeon CPUs or standard server blades.

Fortanix also supports Intel's Trust Domain Extension (TDX) module, which is a confidential computing technology suited for artificial intelligence (AI) applications. Companies can feed diverse information into secure vaults to enhance proprietary AI learning models. The third-party data set can be allowed to enter and exit the vault, with no information retained or stolen.

**Developing a Market for Confidential Computing

The market will have to prove Fortanix's technology, and the company will have to show a dramatic performance improvement or dramatic cost savings to gain a foothold, says James Sanders, principal analyst at CCS Insight.

"The technology behind this is secondary to the value it must demonstrate to enterprise buyers," he says.

But Fortanix is in a solid position to educate the market about confidential computing, which is still new.

"The maxim 'don't roll your own security' applies here, " Sanders says. "Banks and hospitals are not going to write their own \[confidential computing\] stacks, and a validated third-party option will help to increase the exposure and utilization of those confidential computing technologies."

The Fortanix technology can be implemented on-premises or in the cloud with some form of confidential computing hardware enablement, including Intel Secure Guard Extension (SGX) and AMD's SEV-SNP. A tool called Data Security Manager manages the confidential computing deployment.

"We handle all of the deployment of the database at the interface for you," Searle says. "You do not need to get involved in implementation. It is an automated deployment based on the policy controls within Data Security Manager."

**

Fortanix Builds Hardware Security Wall Around Plaintext Search

Some 340,000 FortiGate SSL VPN appliances remain exposed to the threat more than three weeks after Fortinet released firmware updates to address the issue.

Researchers have written exploit code for a critical remote code execution (RCE) vulnerability in Fortinet's FortiGate SSL VPNs that the vendor disclosed and patched in June 2023.

Bishop Fox's research team, which developed the exploit, has estimated there are some 340,000 affected FortiGate devices that are currently unpatched against the flaw and remain open to attack. That number is significantly higher than the 250,000 FortiGate devices that several researchers estimated were vulnerable to exploit when Fortinet first disclosed the flaw on June 12.

**Code Not Released Publicly — but There's a GIF**

"There are 490,000 affected \[FortiGate\] SSL VPN interfaces exposed on the internet, and roughly 69% of them are currently unpatched," Bishop Fox's director of capability development, Caleb Gross, wrote in a blog post on June 30. "You should patch yours now."

The heap-based buffer overflow vulnerability, tracked as CVE-2023-27997, affects multiple versions of FortiOS and FortiProxy SSL-VPN software. It gives an unauthenticated, remote attacker a way to execute arbitrary code on an affected device and take complete control of it. Researchers from French cybersecurity firm Lexfo who discovered the flaw assessed it as affecting every single SSL VPN appliance running FortiOS.

Bishop Fox has not released its exploit code publicly. But its blog post has a GIF of it in use. Gross described the exploit that Bishop Fox has developed as giving attackers a way to open an interactive shell they could use to communicate with an affected FortiGate appliance.

"This exploit very closely follows the steps detailed in the original blog post by Lexfo, though we had to take a few extra steps that were not mentioned in that post," Gross wrote. "The exploit runs in approximately one second, which is significantly faster than the demo video on a 64-bit device shown by Lexfo."

Fortinet issued firmware updates that addressed the issue on June 12. At the time, the company said the flaw affected organizations in government, manufacturing and other critical infrastructure sectors. Fortinet said it was aware of an attacker exploiting the vulnerability in a limited number of cases.

Fortinet cautioned about the potential for threat actors like those behind the Volt Typhoon cyber-espionage campaign to abuse CVE-2023-27997. Volt Typhoon is a China-based group that is believed to have established persistent access on networks belonging to US telecom companies and other critical infrastructure organizations, for stealing sensitive data and carrying out other malicious actions. The campaign so far has primarily used another, older Fortinet flaw (CVE-2022-40684) for initial access. But organizations should not discount the possibility of Volt Typhoon — and other threat actors — using CVE-2023-27997 either, Fortinet warned.

**Why Security Appliances Make Popular Targets**

CVE-2023-27997 is one of numerous critical Fortinet vulnerabilities that have been exposed. Like that of almost every other firewall and VPN vendor, Fortinet's appliances are a popular target for adversaries because of the access they provide to enterprise networks.

The US Cybersecurity and Infrastructure Security Agency (CISA), the National Security Agency (NSA), and others have issued multiple advisories in recent years about the need for organizations to promptly address vulnerabilities in these and other network devices because of the high attacker interest in them.

In June 2022, for instance, CISA warned of China-sponsored threat actors actively targeting unpatched vulnerabilities in network devices from a wide range of vendors. The advisory included a list of the most common of these vulnerabilities. The list included vulnerabilities in products from Fortinet, Cisco, Citrix, Netgear, Pulse, QNAP, and Zyxel.

Systems administrators should patch as quickly as possible, even though patching firmware can be a bit more cumbersome when dealing with appliances that run application gateways, says Timothy Morris, chief security adviser at Tanium. Often, appliances such as those from Fortinet face the perimeter and have very high-availability requirements, meaning they have tight windows for change.

"For most organizations, a certain amount of downtime is probably inevitable," Morris says. Vulnerabilities such as CVE-2023-27997 require the full firmware image to be reloaded, so there is a certain amount of time and risk involved, he adds. "Configurations have to be backed up and restored to make sure they are working as expected."

Researchers Develop Exploit Code for Critical Fortinet VPN Bug

Attribution for the cyberattack on Dozor-Teleport remains murky, but the effects are real — downed communications and compromised data.

Russian satellite Internet provider Dozor-Teleport was knocked offline in the early hours of June 29, dealing a communications blow to the company's customers, which according to reports include Russian military and energy interests.

The Wagner Group, the mercenary army once fighting for Russia, and now seemingly turned against Putin's government, claimed it was behind the cyberattack against the satellite communications provider. But experts aren't convinced.

Russian reports say full recovery of Dozor-Teleport could take up to two weeks. The company's general director Alexander Anosov confirmed the breach to Russian media, adding that early investigations show the company was breached through a third-party cloud provider.

The threat actors behind the compromise explained on Telegram they were able to deliver malware to several satellite terminals to take them offline, reports said. For additional proof, the threat actors posted internal data stolen from the Dozor-Teleport network.

"The whole world watched our actions, listened to our every word. We showed how easily we can reach Moscow in a day without meeting any resistance," the cyber attackers said in their Telegram message.

The reference seems to add to the narrative that the cyberattack was launched by Wagner Group, which, under the command of the now-exiled Yevgeny Prigozhin, marched on Moscow in protest of the Putin government's execution of the Russian invasion of Ukraine.

**Was This a False Flag?**

But the Wagner Group's Telegram channel has made no mention of the cyberattacks so far, according to reports on the incident.

Cybersecurity and international relations expert Oleg Shakirov has been monitoring the breach and assessed in a June 29 tweet that "Wagner's involvement is very unlikely."

He instead suspects the Dozor-Teleport compromise is the work of the Ukrainian military. "Some Russian websites have also been defaced presumably on behalf of Wagner (disgruntled that Russia didn't fulfill its part of the bargain)," Shakirov added. "But again this looks like Ukrainian false flag trolling."

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

Russian Satellite Internet Downed via Attackers Claiming Ties to Wagner Group

Israel's cyber head points finger at Iran-backed MuddyWater APT group as the perpetrator of a recent attack against a university.

Israel earlier this year aided the United Arab Emirates (UAE) in helping repel a major distributed denial-of-service (DDoS) attack.

Speaking at last week's Cyber Week in Tel Aviv, UAE head of cybersecurity Mohamed Al Kuwaiti said that attacks "continuously come and go" and praised the Abraham Accords, which were ratified in 2020 to strengthen Middle East relations. "Thank God for the partnership, with the relationship that we have; it helped us elevate as well as to prepare an early warning system," he said.

According to Jewish Press, Gaby Portnoy, director general of the Israel National Cyber Directorate, joined Al Kuwaiti onstage at the conference, as did national cyber representatives from Bahrain, Morocco, and the US.

Al Kuwaiti noted that "cybersecurity is an important aspect for us all" and that many of Israel's startups are "helping us as a matter of fact to build up that cyber dome or to extend that cyber dome to defend against cyberattacks," a report by All Israel said.

The DDoS attack declaration by Al Kuwaiti came in the same week as a formal announcement was made to increase intelligence sharing between the UAE and Israel with the so-called Crystal Ball project, a partnership between Israel and the UAE's cyber teams and backed by private industry. Crystal Ball is intended to detect and repel hackers via collaboration and knowledge sharing around national-level cyberthreats.

"It is a well-known fact that criminal gangs are working together to victimize individuals and companies, any improvements in international cooperation between nation-states to tackle these threats is a welcome move," says Brian Honan, CEO of BH Consulting.

**No Clarity in MuddyWater?**

At CyberWeek, Portnoy reportedly mentioned cyberattacks the group MuddyWater initiated against Israel. He said the MuddyWater group has ties to Iran's Islamic Revolutionary Guard Corps (IRGC), and blamed it for a cyberattack against the Technion Institute of Technology in Haifa. Technion was forced to disconnect its systems to prevent security damage and lose data.

According to a new blog from Deep Instinct's Simon Kenin, a custom-made command and control server was detected in the attack against Technion, and MuddyWater have been using that server since 2021.

"The group doesn't just work against Israel, but rather also hacks civilian targets in many other countries, including Turkey, Saudi Arabia, Egypt, Morocco, India, Bahrain, Oman, Kuwait, and others," Portnoy said.

The MuddyWater group has previously been linked to spear phishing campaigns against employees of Middle East telecom operators, as well as with cyber surveillance activities.

Israel Aided UAE in Defending Against DDoS Attack

Cybercriminals employ obfuscated script to stealthily hijack victim server bandwidth for use in legitimate proxy networks.

Threat actors are exploiting vulnerable secure shell protocol (SSH) servers to launch Docker services that take advantage of an emerging and lucrative attack vector that hijacks a victim's network bandwidth for money.

Researchers from the Akamai Security Intelligence Response Team (SIRT) in June discovered the currently active campaign, which employs an emerging type of attack called proxyjacking, the researchers revealed in a blog post last week.

Threat actors use SSH for remote access and then run malicious scripts that enlist victim servers into a legitimate peer-to-peer (P2P) proxy network, such as Peer2Proxy or Honeygain, without their knowledge, the researchers said. These networks — which use companion apps or software installed on Internet-connected devices — allow someone to share Internet bandwidth by paying to use the IP address of the app users.

"This allows for the attacker to monetize an unsuspecting victim's extra bandwidth, with only a fraction of the resource load that would be required for cryptomining, with less chance of discovery," Allen West, an SIRT security researcher, wrote in the post.

In a nutshell, that is proxyjacking, an emerging attack model that takes advantage of these services and, on a grand scale, potentially can earn cybercriminals hundreds of thousands of dollars per month in passive income, the researchers found.

While the idea of proxyjacking is not new — think of cryptojacking, an entirely illegal endeavor, as a distant cousin — the ability to easily monetize piggybacking on someone's bandwidth as affiliates of mainstream companies is new, which explains why security researchers are seeing more proxyjacking in the threat landscape, West warned.

"Providing a simple path to financial gain makes this vector a threat to both the corporate world and the average consumer alike, heightening the need for awareness and, hopefully, mitigation," he wrote.

Proxyjacking also makes it easy for threat actors to hide their tracks by routing malicious traffic through a multitude of peer nodes before it reaches its final destination, according to the research. This makes the origin of the nefarious activity difficult for victims or researchers to pinpoint — another attractive option for attackers looking to monetize their activity without consequence.

**How the Attack Works**

The first indication of the attack that Akamai researchers identified came when an attacker established multiple SSH connections to one of the company's honeypots using a double Base64-encoded Bash script to obscure the activity. They successfully decoded the script and were able to observe the proxyjacking method of the threat actor down to the exact sequence of operations.

The script transformed the compromised system into a node in the Peer2Profit proxy network, using the account specified by $PACCT as the affiliate that will profit from the shared bandwidth, according to Akamai SIRT. The same process was seen being employed for a Honeygain installation awhile later.

"The script was designed to be stealthy and robust, attempting to operate regardless of the software installed on the host system," West wrote.

The script goes on to execute various functions, one of which is to download an actual, unmodified version of cURL, a command-line tool that enables data exchange between a device and a server through a terminal.

This tool seems to be all the attackers need for the scheme to work, and, "if it is not present on the victim host, then the attacker downloads it on their behalf," West wrote.

The executable cancels any containers running on the node to install a Docker container to handle the proxyjacking process and, once everything is in place, the attacker can exit the network without a trace.

**How Do You Defend Against Proxyjacking?**

Because of the growing prevalence of and the relative ease with which attackers can set up proxyjacking attacks, and inability to identify original perpetrators, organizations need to maintain vigilance on their networks so as to notice abnormal behavior in how their resources are being used to avoid compromise, the researchers recommend.

For the particular attack that the Akamai team observed, attackers used SSH to gain access to a server and install a Docker container. To avoid this type of attack, organizations can check their locally running Docker services to locate any unwanted resource sharing the system, according to Akamai. If they find one, the intrusion should be investigated and a determination of how the script was uploaded and run should be made, after which organizations should perform a thorough clean-up.

Also unique to the attack is that the executable in the form of the cURL tool would likely go overlooked by most companies, since that tool can be used legitimately. However, in this case, it was the initial artifact in the attack that led the researchers to investigate deeper, West said.

"It was the ability to look at the source of the artifact that took it from a harmless piece of code to what we now know is part of a proxyjacking scheme," he explained, which "highlights the importance of being able to isolate all unusual artifacts, not just those that are considered malicious."

Moreover, because proxyjacking attackers also use vulnerabilities to mount attacks — that was the case in a recent attack that leveraged the infamous Log4j flaw — organizations should maintain updated assets and apply patches to applications whenever available, particularly when vulnerabilities already have been exploited, the research recommends.

West added: "Users with deeper knowledge of computer security can additionally remain vigilant by paying attention to the containers currently running, monitoring network traffic for anomalies, and even running vulnerability scans on a regular basis."

SSH Servers Hit in 'Proxyjacking' Cyberattacks

When you just keep filing it away to handle "someday," security debt typically rears its head when you are most vulnerable and can least afford to pay it.

There has always been a tradeoff in IT between shipping new features and functionality versus paying down technical debt, which includes things like reliability, performance, testing … and yes, security. 

In this "ship fast and break things" era, accumulating security debt is a decision that organizations voluntarily make. Every organization has security tasks stuffed in their Jira backlogs for "someday" — things like deploying security patches and running the newest, most stable versions of programming languages and frameworks. Doing the right thing takes time, and teams willfully postpone these tasks because they are prioritizing new features. A big part of the CISO's job is recognizing those moments when security debts must be paid.

One thing that made the Log4j exploit so alarming for CISOs was the realization that there was this huge accumulated debt that wasn't even on their radar. It exposed a hidden class of security gaps between open source projects and the ecosystems of creators, maintainers, package managers, and organizations who use them. 

Software supply chain security is a unique line item on the security debt balance sheet, but CISOs can put together a coherent plan for paying it down.

**A New Class of Vulnerability**

Most companies have gotten really good at locking down their network security. But there's a whole class of exploits that are possible because developer build systems and the software artifacts they leverage to write applications do not have a trust mechanism or secure chain of custody. 

Today, anyone with common sense knows not to pick up a random thumb drive and plug it into their computer due to the security risks. But for decades, developers have been downloading open source packages with no way to verify that they're safe. 

Bad actors are capitalizing on this attack vector because it is the new low-hanging fruit. They realize that they can gain access through these holes, and once inside, pivot to all the other systems that have dependencies on whatever insecure artifact they used to gain entry. 

**Stop Digging by Locking Down Build Systems **

The fundamental starting point for CISOs, endorsed in materials like the developer guide "Securing the Software Supply Chain," is to start using open source frameworks like NIST's Secure Software Development Framework (SSDF) and OpenSSF's Supply Chain Levels for Software Artifacts (SLSA). These are basically prescriptive steps for locking down your supply chain. SLSA Level 1 is to use a build system. Level 2 is to export some logs and metadata (so you can later look things up and do incident response). Level 3 is to follow a series of best practices. Level 4 is to use a really secure build system. By following these first steps, CISOs can create a strong foundation for building a software supply chain that is secure by default. 

Things get more nuanced as CISOs think about policies over how developer teams acquire open source software in the first place. How do developers know what their company's policies are for what's considered "secure"? And how do they know that the open source they are acquiring (which constitutes the great majority of all software used by developers these days) is indeed untampered with?

By locking down build systems and creating a repeatable method to verify provenance of software artifacts before bringing them into the environment, CISOs can effectively stop digging a deeper hole for their organization in security debt. 

**What About Paying Down Old Software Supply Chain Security Debt?**

After you've stopped digging by locking down your base images and build environments, now you need to update your software and patch your vulnerabilities, including base image versions.

Updating software and patching CVEs is super tedious. It's boring, it's time consuming, it's a chore — it's work. It's the "eat your veggies" of cybersecurity. Paying down this debt requires a deep collaboration between CISOs and development teams. It is also an opportunity for both teams to agree on more secure, productive tooling and processes that can help make an organization's software supply chain secure by default. 

Just like some people don't like change, some software teams don't like updating their container base images. The base image is the first layer of container-based software applications. Updating a base image to a new version can sometimes break the software application, especially if there is inadequate test coverage. So, some software teams prefer the status quo, essentially loitering indefinitely on a working base image version that is likely accumulating CVEs daily.

To avoid this accumulation of vulnerabilities, software teams should as update images frequently with small changes and use "testing in production" practices like canary releases. Using container images that are hardened, minimal in size, and built with critical software supply chain security metadata, like software bills of materials (SBOMs), provenance, and signatures, can help alleviate the time-consuming pain of daily vulnerability management in base images. These techniques strike the right balance between staying secure and making sure production doesn't go down.

**Start Paying as You Go**

What's uniquely unpleasant about security debt is that when you just keep filing it away for "someday," it typically rears its head when you are most vulnerable and can least afford to pay it. The Log4j vulnerability struck right before the busy holiday e-commerce cycle and crippled many engineering and security teams well into the following year. No CISO wants to have hidden security surprises lurking.

Every CISO should be making a minimum investment into more secure build systems, software signing methods to establish the provenance of software before developers bring it into the environment, and hardened, minimal container base images that reduce the attack surface at the foundation of software and applications. 

Deeper into this massive software supply chain security debt payoff, CISOs face a conundrum of how much they are willing to have their developers pay as they go (by continually updating base images and software with vulnerabilities) versus postponing that debt and achieving an acceptable level of vulnerability.

A CISO's Guide to Paying Down Software Supply Chain Security Debt

Come up with a clever caption, and our panel of experts will reward the winner with a $25 Amazon gift card.

Let's see you tame this contest beast! Come up with a witty cybersecurity-related caption to explain the scary scene above, and our favorite submission will win a $25 Amazon gift card.

The contest ends on July 26, 2023. Here are four easy ways to send your ideas:

*   Email \[email protected\] with the subject line "The Edge July 2023 Toon."
*   Via social media: Twitter, Facebook, and LinkedIn.

**Last Month's Winner**

The most eggcellent caption for our June "Spring Chickens" contest came via Twitter from Gerald Benischke, a debugger, breaker and fixer of software. Congratulations, Gerald, and thanks to everyone for playing!

    

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

Name That Edge Toon: Three-Ring Circus

XDR can lower platform costs and improve detection, but it requires committing to a few principles that go against the established way of thinking about SOC.

The cyber security operation center (SOC) model's focus has shifted to extended detection and response (XDR). Architected correctly, XDR puts less pressure and cost on the security information and event management (SIEM) system to correlate complex security alerts. It also does a better job as a single pane of glass for ticketing, alerting, and orchestrating automation and response.

XDR is a real opportunity to lower platform costs and improve detection, but it requires committing to a few principles that go against the established way of thinking about SOCs.

**Intelligent Data Pipelines and Data Lakes Are a Necessity**

_**Takeaway: A security data pipeline can remove log waste prior to storage and route logs to the most appropriate location.**_

Managing your security data pipeline intelligently can have a massive impact on controlling spending by preprocessing every log and eliminating excess waste, especially when your primary cost driver is GB per day. Consider the following example showing the before and after size of Windows Active Directory (AD) logs.

    

The average inbound event had 75 fields and a size of 3.75KB. After removing redundant and unnecessary fields, the log has 30 fields and a size of 1.18KB. That is a 68.48% reduction of SIEM storage cost.

Applying similar value analysis for where you send each log is equally important. Not all logs should be sent to the SIEM! Only logs that drive a known detection should be sent to SIEM. All others used in supporting investigations, enrichment, and threat hunting should go to the security data lake. An intelligent data pipeline can make on-the-fly routing decisions for each log and further reduce your costs.

    

    

**Focus Detection and Prevention Closest to the Threat**

_**Takeaway: Product-native detections have gotten dramatically better; the SIEM should be a last line of defense.**_

The SIEM used to be one of the only tools that could correlate and analyze raw logs and identify alerts that need to be addressed. This was largely a reflection of other tools being single-purpose and generally bad at identifying issues by themselves. As a result, it made sense to ship everything to the SIEM and create complex correlation rules to sort the signal from the noise.

Today's landscape has changed with endpoint detection and response (EDR) tools. Modern EDR is essentially SIEM on the endpoint. It has the same capabilities to write detection rules on endpoints as the SIEM has, but now there is no need to ship every bit of telemetry data into the SIEM.

EDR vendors have gotten markedly better at building and maintaining out-of-the-box detections. We have consistently seen a sizable decrease in detections and preventions attributed to the SIEM during our purple team engagements in favor of tools like EDR and next-generation firewalls (NGFW). There are exceptions like Kerberoasting (which on-premises AD doesn't have much coverage for). As you move to pure cloud for AD, even those types of detections will be handled by "edge" tools like Microsoft Defender for Endpoint.

**Play to Your SIEM Strong Suit**

_**Takeaway: Having a deliberate process to consistently measure and improve your detection capabilities is far more valuable than having any specific SIEM tool on the market.**_

Purple teaming across industries and detection ecosystems has allowed us to understand the efficacy of many modern EDR, NGFW, SIEM, and other tools. We score and benchmark purple team results and trend the improvements over time. We have found over the past five years that the SIEM you buy has no measurable correlation to purple team scores. Process, tuning, and testing are what matter.

SIEM tools have architectural differences that can make one a better or worse fit for your environment, but buying a specific SIEM to significantly improve your detection capabilities will not prove out. Instead, focus your efforts on dashboards and correlations that support threat-hunt and incident-response efforts.

**Align EDR, SIEM, and SOAR in Your XDR Architecture**

_**Takeaway: Security automation and artificial intelligence (AI)-enhanced triage is the future but should be approached with caution. Not all automation needs to exclude all human involvement.**_

The future of XDR is coupled with tightly integrated security orchestration, automation, and response (SOAR) technologies. XDR concepts recognize that what really matters is **not how fast you can detect a threat, but how fast you can neutralize a threat.** _"If this – then that"_ SOAR automation methodologies aren't effective in real-world scenarios. One of the best approaches we've seen in XDR automation is:

*   Conduct a purple team exercise to identify which current detection events are optimized (very low false positive rates) and can be trusted with an automated response.
*   Create an automated response playbook but insert human intervention steps to gain confidence before you turn it fully over to automation. We call this "semi-automation," and it's a smart first step.

XDR is a buzzword, but when viewed in a technology-agnostic fashion, it is based on good foundations. Where organizations are most likely to fail is applying legacy SIEM management philosophies to modern XDR architectures. These program design philosophies will likely improve your capabilities and reduce your costs.

**About the Author**

    

Mike Pinch joined Security Risk Advisors in 2018 after serving 6 years as the Chief Information Security Officer at the University of Rochester Medical Center. Mike is nationally recognized as a leader in the field of cybersecurity, has spoken at conferences including HITRUST, H-ISAC, and has contributed to national standards for health care and public health sector cybersecurity frameworks. Mike focuses on GCP, AWS, and Azure security, primarily in helping SOC teams improve their capabilities. Mike is an active developer and is currently enjoying weaving modern AI technologies into common cybersecurity challenges.

Architecting XDR to Save Money and Your SOC's Sanity

The group has given one of Apple's biggest semiconductor suppliers until Aug. 6 to pay $70 million or risk having its data and "points of entry" to its network publicly leaked.

Taiwan Semiconductor Manufacturing Company (TSMC) — one of Apple's biggest semiconductor suppliers — on Friday blamed a third-party IT hardware supplier for a data breach that has exposed the company to a $70 million ransom demand from the LockBit ransomware group.

In an emailed statement to Dark Reading, TSMC confirmed multiple reports about the security incident but did not say what data specifically LockBit actors might have accessed from its systems and is holding for ransom. The statement, however, described the incident as not affecting any of TSMC's business or customer information.

**Third-Party Breach**

"TSMC has recently been aware that one of our IT hardware suppliers experienced a cybersecurity incident, which led to the leak of information pertinent to server initial setup and configuration," the statement noted. It identified the third-party supplier as Kinmax Technology, a Hsinchu, Taiwan- based systems integrator that claims to work with numerous other major technology players, including Aruba, Checkpoint, Cisco, Citrix, Fortinet, Hewlett-Packard Enterprise, Microsoft, and VMware. It's unclear if any other customers are affected by the attack.

Meanwhile, a subgroup within the LockBit operation that calls itself the National Hazard Agency claimed that it has given TSMC up to Aug. 6 to pay the multimillion-dollar ransom or risk having the company's stolen data publicly leaked. The threat actor claimed that it would also publish what it described as "points of entry" into TSMC's network as well as passwords and login information for gaining access to it. The latter is catnip to cyberattackers given that TSMC is a juicy target: It reported a net income of some $34 billion on consolidated revenue of $75.8 billion in 2022.

TSMC said it had conducted a review of its hardware components and security configurations used in its systems, after Kinmax reported the incident, to determine the scope of the breach. "After the incident, TSMC has immediately terminated its data exchange with this supplier in accordance with the company’s security protocols and standard operating procedures," the statement noted. The chipmaker said it remained committed to enhancing security awareness among its suppliers and in ensuring they complied with the company's security requirements.

**IT Supplier Downplays Incident**

Kinmax said it discovered the intrusion into its systems on June 29. The company described the attacker as having breached the company's engineering test environment and accessing system installation preparation information. 

"This is the system installation environment prepared for customers," Kinmax said in a statement on the incident. "The captured content is parameter information such as installation configuration files."

The statement appeared to downplay the seriousness of the breach. "The \[breached\] information has nothing to do with the actual application of the customer. It is only the basic setting at the time of shipment," the company said. The statement did not identify TSMC by name. But it somewhat bewilderingly claimed that the chipmaker (or others) had not experienced any negative consequences. "At present, no damage has been caused to the customer and the customer has not been hacked by it," the June 30 statement noted.

In the statement shared with Dark Reading, the systems integrator expressed regret over the incident. "We would like to express our sincere apologies to the affected customers, as the leaked information contained their names which may have caused some inconvenience. The company has thoroughly investigated this incident and implemented enhanced security measures to prevent such incidents from occurring in the future," the Kinmax statement said.

TSMC is the latest among a rapidly growing number of organizations that has experienced a data breach via a third-party compromise. News of the company's predicament comes even as reports continue to pour in about numerous organizations falling victim to the Cl0p ransomware gang because of a vulnerability in Progress Software's widely used MOVEit Transfer app. Victims of that campaign so far include biopharma giant AbbVie, Siemens, Schneider Electric, the University of California at Los Angles (UCLA).

Such breaches have brought IT supply chain security into sharp focus in recent years and made it a top priority in the Biden administration's May 2021 cybersecurity executive order.

Chip Giant TSMC Blames $70M LockBit Breach on IT Hardware Supplier

The number of malware samples is up as attackers aim to compromise users where they work and play: Their smartphones.

Attackers are increasingly targeting users through their mobile devices, attacking vulnerabilities in services that are built into applications and mounting increasing numbers of SMS phishing attacks.

That's according to mobile security firm Zimperium's 2023 "Global Mobile Threat Report," which also found that the average number of unique mobile malware samples grew 51% in 2022, totaling an average of 77,000 unique malware samples found every month. About a quarter of application samples submitted to public repositories — 23% of Android apps and 24% of iOS apps — were malicious, according to data in the report.

In total, that all contributed to the number of compromised devices nearly tripling (up 187%) in the time period, because the tactics are working: The company saw an average of four malicious phishing links clicked per device, for instance.

The trend comes as companies and their workers rely increasingly on mobile devices, with a majority of firms seeing more workers (58%) using mobile devices for business than in 2021 and most users (59%) doing more work with their mobile devices, according to the 2022 "Verizon Mobile Security Index" report. 

"Businesses and users need to mostly be concerned about mobile phishing and spyware today, and mobile ransomware will become increasingly concerning in the near future," says JT Keating, senior vice president of strategic initiatives at Zimperium. 

**Android, iOS Devices See Different Levels of Cyber Threats**

About 80% of phishing sites specifically target mobile devices with content suited to those platforms, Zimperium stated in its 2023 "Global Mobile Threat Report." But, as has been the case for many years, the Android platform tends to attract more threats. One of the reasons for that could be that the Android operating system has seen between about 500 and 900 vulnerabilities disclosed per year that threat actors can target; iOS meanwhile saw a little more than 300 vulnerabilities in five of the last eight years, according to Zimperium. 

Another reason that Android is a bigger target? App development mistakes. The firm found that there are more mistakes made in the process of developing apps when it comes to Android, particularly when it comes to how those apps interact with cloud storage instances. Only about 2% of iOS applications access unprotected cloud instances, while 10% of Android apps do so. These include database instances accessed through Google Firebase and Cloud Platform, Amazon Simple Storage Service (S3), and Microsoft Azure Cloud Storage, according to Zimperium's report. As a corollary, developers also tend to access the same poor resources, too: Only 1% of unprotected cloud instances accounted for 60% of applications at risk, the company said.

Georgy Kucherin, a security expert at Kaspersky's Global Research and Analysis Team (GReAT), says his firm's research bears out the finding that Android attracts more overall threats, though he notes that when it comes to spyware the targeting is evenly split between the two ecosystems; the recent Triangulation cyber espionage campaign for instance shows the value in targeting the iOS platform.

"Mobile users should worry about both cybercrime threats and nation-state espionage, \[but\] it is correct to say that Android faces more general threats," he says. "Android devices are more likely to become infected with malware distributed by cybercriminals. As for top-notch espionage spyware, both iOS and Android are vulnerable to it."

The lack of jailbreaking utilities for the latest version of iOS is also lowering the number of attacks for that platform, according to Zimperium. Jailbreaking allows users to add non-Apple-sanctioned software to their mobile devices, but it also removes significant security guardrails in the process. 

**Threats Up, or Leveling Off?**

In terms of the types of mobile malware that's circulating out there, Kaspersky saw fewer mobile malware installers and less ransomware in the past year, but more banking Trojans, it stated in "The Mobile Malware Threat Landscape in 2022" report.

"Cybercriminals are still working on improving both malware functionality and spread vectors," according to the report. "Malware is increasingly spreading through legitimate channels, such as official marketplaces and ads in popular apps. This is true for both scam apps and dangerous mobile banking malware."

To put all of this into perspective, it should be noted that traditional computing platforms still attract the lion's share of the cybercrime pie. Kaspersky, for example, blocked more than 20 million malicious installers, spyware, and adware attacks on mobile devices over the last four quarters, but blocked more than 20 times that number against more common work platforms, such as Windows. However, the mobile threat vector is not as well protected. 

"In most cases, mobile devices represent a significant, unaddressed attack surface for enterprises," Zimperium's Keating says. "No matter if they are corporate-owned or part of a BYOD strategy, the need to implement appropriate security controls, and educate end-users about potential threats, is critical."

Source

DARKReading