Attackers use HTML smuggling to spread the PlugX RAT in the campaign, which has been ongoing since at least December.

A Chinese threat group has adopted a sneak HTML technique long-used by its counterparts to target European policy-makers, in a campaign aimed at spreading the PlugX remote access Trojan (RAT).

Over the course of the last two months, Check Point Research (CPR) analysts have been tracking the activity, which they've dubbed SmugX because it uses an attack vector called HTML Smuggling — a technique for planting malicious payloads inside HTML documents, the researchers revealed in a report published earlier this week.

The campaign has been ongoing since at least December and appears to have a direct link to a previously reported campaign attributed to Chinese APT RedDelta, as well as the work of Chinese APT Mustang Panda (aka Camaro Dragon or Bronze President), although there is "insufficient evidence" to definitively link SmugX to either group, according to the research.

Moreover, while Check Point separates Mustang Panda and Camaro Dragon into two separate entities, other researchers refer to the two as one and the same; RedDelta, meanwhile, appears to have links to both groups, according to Check Point researchers.

SmugX represents a shift in targeting for Chinese threat actors, which in the past have primarily focused on Russia, Asia, and the US in their threat campaigns, they added. However, a recent campaign linked to Mustang Panda to use USB drives to spread self-propagating espionage malware already indicated that these groups already engaged in threat activity in Europe as part of their global intent.

SmugX targets mainly governmental ministries in Eastern European countries — including Ukraine, the Czech Republic, Slovakia, and Hungary — as well as in Sweden, France, and the UK. Document lures used to dupe victims focus on European domestic and foreign policies, typically impersonating key agencies in the respective country to appear authentic.

**SmugX Cyberattack Details**

SmugX uses as its malware-delivery mechanism HTML documents that contain diplomatic-related content. In more than one case, this content is directly related to China — including an article about two Chinese human rights lawyers sentenced to more than a decade in prison.

Other documents used in the campaign are a letter originating from the Serbian embassy in Budapest; a document stating the priorities of the Swedish Presidency of the Council of the European Union; an invitation to a diplomatic conference issued by Hungary's Ministry of Foreign Affairs.

The malware is embedded within these HTML documents, which allows them to evade network-based detection measures, according to the research.

Opening one of the malicious HTML documents results in the decoding of a JavaScript that includes the embedded payload — which in this case is PlugX, a RAT that has been used by Chinese threat actors since 2008. This sets off a chain of events that eventually leads to the deployment of the RAT, which employs a modular structure that accommodates several diverse plugins with distinct functionalities.

"This enables the attackers to carry out a range of malicious activities on compromised systems, including file theft, screen captures, keystroke logging, and command execution," according to the report.

The PlugX payload ensures its persistence in a process that first copies the legitimate program and the DLL and then stores them within a hidden directory it creates, with the encrypted payload stored in a separate hidden folder. The malware then adds the legitimate program to the Run registry key.

**Defensive Maneuvers Against PlugX, RATs**

Though neither the techniques nor the malware used in the campaign are new, SmugX does present a challenge for targeted organizations because of how it combines different tactics and its likelihood of not easily being detected. This allows "threat actors to stay under the radar for quite a while," according to Check Point.

To help organizations identify if they've been compromised, the report includes an extensive list of indicators of compromise (IoCs) that span HTML addresses, archives, JavaScript snippets, encrypted payload files, IPs and domains, and more.

Employees should always be wary of clicking on unknown links or files when using a corporate network, and check with IT departments before downloading anything new from the Internet. Moreover, a comprehensive combination of threat emulation and endpoint detection strategies also can defend against attacks such as SmugX, according to Check Point.

China's Mustang Panda Linked to SmugX Attacks on European Governments

You can't encrypt a file you can't open — Microsoft could dramatically impact ransomware by slowing it down.

Recently, I was at a private event on security by design. I explained that Microsoft could fix ransomware tomorrow, and was surprised that the otherwise well-informed people I was speaking to hadn't heard about this approach.

Ransomware works by going through files, one by one, and replacing their content with an encrypted version. (Sometimes it also sends copies elsewhere, but that turns out to be slow, and sometimes sets off alarms.) Software on Microsoft Windows uses an application programming interface (API) called "CreateFile" to access files. Somewhat confusingly, CreateFile not only creates files but is also the primary way to open them.

Microsoft should rate-limit the CreateFile() API. That is to say, it should limit how often a given program can use the API. Because you can't encrypt a file until you can open it, this would have a dramatic impact on ransomware. It would slow it down, and help defensive tools catch it in time for humans to react.

Now, I say Microsoft _should_ do this, and I hope it does.

Also, I made this suggestion to help show the complexity of maintaining compatibility. On the surface, it's very simple and elegant. In practice — and I say this as the person who drove the Autorun fix into Windows Update — there's going to be both practical complexities and concerns that we don't know what all the effects will be.

**What Rate Is Reasonable?**

The first question is, what rate is reasonable? Pick low and you break applications; pick high and you lessen the protective value. For a lot of cases, one open per second seems fine, but when we get to things like compilers, which are going to open a lot of files, we see that we may need both a general limit and allow bursts. When we get to backup software, it gets even more complicated. The backup software needs to open all the files, or at least all the changed files, which, if you think about it, is really similar to what ransomware wants to do. We can't allow an exception for read-only opens. The ransomware will open a file, encrypt the contents, write it to a new file or append it to a database, and delete the original.

So, Windows will probably need multiple rate limits. There will need to be a way to exempt programs (like compilers and backup tools), and maybe that needs to be issued globally, which means a process for software creators to get a special certificate. There needs to be logging and alerts created, tested, internationalized, etc. There'll need to be new GPOs (a tool used to administer Windows) created and documented. There needs to be a local way to allow more CreateFile calls for software that is locally developed or obscure, or whose makers are no longer around. We need to make sure that ransomware can't abuse those mechanisms. (On recent Macs, there's a complex process of reboots needed to make certain changes to the system; perhaps something similar is warranted?)

That last is tricky: The administrator has power, by design, and it's hard to limit that power. Even logging file opens would make it easier to see what software is opening lots of new files, and make it harder for ransomware to be stealthy. (And yes, there are too many alarms already.)

As long as we are not hyperfocused on the details, attackers change slowly. They still phish, through more and more channels. Over 20 years, break-ins have gone from abusing software that's listening on open ports to other problems. That was the result of a breaking change of turning the Windows Firewall on by default, in response to 2003's "summer of worms."

Hyrum's law states roughly that somebody will depend on every observable behavior of your system. And change becomes complex. The simple statement "Microsoft should rate-limit the CreateFile() API" is a can of worms.

Given the exceptional cost of ransomware today, I think that can of worms is worth opening. I think my former colleagues are up to the challenge.

Microsoft Can Fix Ransomware Tomorrow

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

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

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

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.

Source

DARKReading