The conventional wisdom that virtual container environments were somehow immune from malware and hackers has been upended.

Kubernetes and container technology in general had a good run as seemingly immune to malware, but that ended when Siloscape burst onto the scene in March 2021. It was the first known threat targeting Kubernetes environments to potentially do all kinds of nefarious things, including spread ransomware. In the ensuing 16 months, Siloscape has undoubtedly provided other cybercriminals with a blueprint for attacking container environments.

It's worth reviewing the details of Siloscape. Threat researcher Daniel Prizmant, who discovered the malware, put it this way: "Siloscape is heavily obfuscated malware targeting Kubernetes clusters through Windows containers. Its main purpose is to open a backdoor into poorly configured Kubernetes clusters in order to run malicious containers.

"Compromising an entire cluster is much more severe than compromising an individual container, as a cluster could run multiple cloud applications whereas an individual container usually runs a single cloud application," he continued. "For example, the attacker might be able to steal critical information such as usernames and passwords, an organization's confidential and internal files or even entire databases hosted in the cluster. Such an attack could even be leveraged as a ransomware attack by taking the organization’s files hostage."

**A Distant Threat? No! **

It's easy to fall into the trap of thinking this is some distant threat affecting an obscure technology few companies are deploying.

_Au contraire_. Prizmant himself pointed out that "with organizations moving to the cloud, many use Kubernetes clusters as their development and testing environments, and a breach of such an environment can lead to devastating software supply chain attacks."

And recent research revealed one-third of organizations already rely on Kubernetes. Of the remaining two-thirds that do not yet use it, 86% expect to deploy the technology in the next two to three years.

Alarmingly, though, just 33% of organizations that have deployed Kubernetes so far have tools in place to protect their container environments against data loss incidents such as ransomware. That may be why it didn't take long for Prizmant's ransomware prediction to come true — the same research revealed that barely a year later, almost half of organizations that have deployed Kubernetes have already experienced a ransomware attack on their container environments, while a staggering 89% of respondents said that ransomware attacks on Kubernetes environments are "an issue" for their organizations today.

Does this mean that Kubernetes is the new weak link in data protection? The Achilles' heel in defense against ransomware?

Siloscape is undoubtedly just the first in a lineup of threats that will target Kubernetes environments as the technology continues to gain steam.

**The Simplest Solution**

Unfortunately, most organizations are overlooking the simplest solution: extending current data protection from their traditional workloads out across their containerized environments. Beyond the ability to quickly protect Kubernetes workloads, this approach has other benefits, including a simplified data restoration process and a single place to manage protection data.

Other keys to protecting Kubernetes environments against ransomware and other data loss threats are:

*   Use Transport Layer Security (TLS) for all API traffic.
*   Choose an authentication mechanism for the API servers to use that matches the common access patterns when you install a cluster.
*   Enable role-based access control.
*   Control access to the kubelet through kubelet authentication and authorization.
*   Set appropriate resource quotas and limit ranges.
*   Properly configure pod security admission.
*   Add rules to prevent containers from loading unwanted kernel modules.
*   Restrict network access.
*   Restrict cloud metadata API access.
*   Set controls for controlling which nodes pods may access.
*   Enable audit logging.
*   Restrict access to alpha and beta features.
*   Rotate infrastructure credentials frequently.
*   Review third party integrations before enabling them.

Learn more about these steps from Kubernetes here.

Kubernetes is easy for organizations to deploy, and quickly improves affordability, flexibility, and scalability — it's no wonder so many are embracing containerization. But because deployment is so simple, organizations can easily surge ahead faster with their Kubernetes implementation than their Kubernetes protection. Follow the guidance here to avoid letting that happen to you.

Protecting Against Kubernetes-Borne Ransomware

Major supply chain attacks have had a significant impact on software security awareness and decision-making, with more investment planned for monitoring attack surfaces.

Organizations are waking up to the need to establish better software supply chain risk management policies and are taking action to address the escalating threats and vulnerabilities targeting this expanding attack surface.  

These were among the findings of a Coalfire-sponsored, CyberRisk Alliance-conducted survey of 300 respondents from both software-buying and software-producing companies.

Most survey respondents (52%) said they are "very" or "extremely" concerned about software supply chain risks, and 84% of respondents said their organization is likely to allocate at least 5% of their AppSec budgets to manage software supply chain risk.

Software buyers are planning to invest in procurement program metrics and reporting, application pen-testing, and software build of materials (SBOM) design and implementation, according to the findings, released on Tuesday.

Meanwhile, software developers said they plan to invest in secure code review as well as SBOM design and implementation.

The survey also found 59% of software-development company customers have experienced purchase delays of up to three months due to concerns about code provenance.

As Coalfire vice president Dan Cornell explains, this statistic reflects a convergence between cybersecurity risk and more generalized business risk, indicating that organizations perceive software supply chain risks as being significant enough that they are slowing down purchases until those risks can be addressed.

"But in our modern business environment, delays add business risk because they postpone delivering value to stakeholders and open up opportunities for competitors to be first to market," he adds. "So, organizations need to look at how they’re addressing supply chain risk."

He says that if they can address that risk sufficiently but do it faster than their competitors, that means they can be quicker to market and quicker to start delivering value to their stakeholders.

"If they can’t, then the cybersecurity risk of software supply chains will increase the business risk of being late to take advantage of opportunities," he says.

**C-Suite Takes Notice of Software Supply Chain Security**

Cornell says some of the most significant findings for forward progress were around who in the responding organizations were concerned about software supply chain issues.

For software buyers, 51% of senior management (C-level) raised software supply chain concerns — this was second only to security team members raising the concerns (at 60%).

"I would expect security teams would be raising these questions, but I found it particularly interesting that these senior-level executives were also concerned with this issue," Cornell notes. "That’s fantastic, and a required precursor to making significant progress on this issue. Obviously, security teams care about this, but they don’t set corporate policy and direction — senior executives do."

He says as senior executives get on board, they will start to reflect this priority in budget allocations.

"Then — and only then — will the ball get rolling to address software supply chain issues in a structured and programmatic manner," he says.

On the software suppliers side, Cornell points out that 71% of respondents said that DevOps departments are driving software supply chain decision-making, even more than security teams (at 63%).

"This is really encouraging — I see having these initiatives being driven from outside security teams as being critical," he explains. "Security teams need to be advisers about risk, but DevOps teams are the ones who are selecting the open source components they use in their projects and making the decisions on what to upgrade and when."

He adds that seeing them take this issue seriously — and, arguably, the most seriously based on the responses — gives him hope that these issues will start to get addressed.

**DevOps Teams Build Center of Risk Management**

From Cornell's perspective, DevOps — or hopefully, DevSecOps groups — should really spearhead the management of software supply chain risk.

"They are the ones who own the software development process, and they see the code that is written," he says. "They see the components that are pulled in. They watch the software get built. And they make it available to whoever is next on down the line."

Given this vantage point, they can help to impact — in a positive way — an organization's software supply chain security status by implementing good policies and practices around what open source code is included in their software and when those open source components are upgraded.

"Forward-leaning DevSecOps teams can take advantage of their automation and testing to start pushing for more aggressive component-upgrade life cycles and other approaches that help minimize technical debt," he explains.

He says they’re also in a position and own the tooling to help generate SBOMs that they can then provide to software consumers who are in turn looking to manage their supply chain risk.

"An organization doesn’t have to adopt a DevSecOps approach to software development to address software supply chain security risks," Cornell says.

**Building Frameworks for Risk Evaluation**

In May, MITRE unveiled a prototype framework for information and communications technology (ICT) that defines and quantifies risks and security concerns over supply chain, including software.

That same month, the National Institute of Standards and Technology (NIST) updated its cybersecurity guidance for addressing software supply chain risk, offering tailored sets of suggested security controls for various stakeholders.

Meanwhile, a growing number of threat actors looking at supply chain companies as an entry point into enterprise networks, including North Korea's infamous Lazarus Group.

Software Supply Chain Concerns Reach C-Suite

Tools purporting to help organizations recover lost passwords for PLCs are really droppers for malware targeting industrial control systems, vendor says.

Threat actors are targeting systems in industrial control environments with backdoor malware hidden in fake password-cracking tools. The tools, being touted for sale on a variety of social media websites, offer to recover passwords for hardware systems used in industrial environments.

Researchers from Dragos recently analyzed one such password-cracking product and found it to contain "Sality," an old malware tool that makes infected systems part of a peer-to-peer botnet for cryptomining and password cracking.

The password-cracking tool was being hawked as software that could help users of Automation Direct's DirectLogic 06 programmable logic controllers (PLCs) recover lost or forgotten passwords. When installed on the PLC, the software did not really "crack" the password. Rather, it exploited a vulnerability in the PLC to recover the password from the system on command and send it in clear text to the user's connected engineering workstation. The sample that Dragos analyzed required the user to have a direct serial connection from their workstation to the Automation Direct PLC. However, the security vendor said it was able to develop a more dangerous version of the exploit that works over Ethernet as well.

Dragos said it reported the vulnerability (CVE-2022-2003) to Automation Direct, which issued a fix for it in June.

In addition to retrieving the password, Dragos observed the so-called password-cracking tool dropping Sality on the host system and making it a part of the botnet. The specific sample of Sality also dropped malware for hijacking the infected system's clipboard every half second and checking it for cryptocurrency address formats. If the malware detected one, it replaced the address with a threat actor-controlled address. "This in-real-time hijacking is an effective way to steal cryptocurrency from users wanting to transfer funds and increases our confidence that the adversary is financially motivated," Dragos said in a recent blog.

**Intriguing Strategy**

Dragos did not immediately respond to a Dark Reading request for clarification on who exactly the buyers for such password-cracking software would be and why they might want to buy these tools from unverified sellers on social media websites. It was also not clear why threat actors would go to the trouble of developing Trojanized password crackers for PLCs in critical infrastructure and operational technology environments if the goal is purely financial. Often attacks targeting equipment in industrial and OT environments have other motivations such as surveillance, data theft, and sabotage.

Dragos' research showed that the password cracker for Automation Direct's PLCs is just one of many similarly fake password retrievers that are available on social media websites. Dragos researchers found similar executables for retrieving passwords from more than 30 PLCs, human-machine interface (HMI) systems, and project files in industrial settings. Among them were six PLCs from Omron, two PLCs from Siemens, four HMIs from Mitsubishi, and products from an assortment of other vendors including LG, Panasonic, and Weintek.

Dragos said it only tested the password cracker for Automation Direct's DirectLogic PLC. However, an initial analysis of the other tools showed they contained malware as well. "In general, it appears there is an ecosystem for this type of software. Several websites and multiple social media accounts exist all touting their password 'crackers'," Dragos said in its blog.

Attacks targeting ICS environments have grown in number and sophistication in recent years. Since the 2010 Stuxnet attack on Iran's uranium enrichment facility in Natanz, there have been numerous instances where threat actors have gained access to critical systems in ICS and OT environments and deployed malware on them. Some of the more recent, notable examples include malware such as Industroyer/Crashoverride, Triton/Trisis, and BlackEnergy. In April 2022, the US Cybersecurity and Infrastructure Agency (CISA) warned critical infrastructure organizations to be on the lookout for three sophisticated malware tools — collectively referred to as Incontroller/PipeDream — custom-built to attack PLCs from Schneider Electric, Omron, and systems based on the Open Platform Communications Unified Architecture (OPC UA) standard.

Trojanized Password Crackers Targeting Industrial Systems

Linus Torvalds says Retbleed has been addressed in the Linux kernel, but code complexity means the release will be delayed by a week to give more time for testing.

Linux kernel developers have successfully addressed Retbleed, the latest Spectre-like speculative execution attack against older AMD and Intel processors, Linus Torvalds wrote in a message to the Linux Kernel Mailing List on Sunday. However, the difficult repair process means there will be a delay of the release for Linux version 5.19 by a week.

"I think we've got the retbleed fallout all handled (knock wood)," Torvalds wrote.

The complexity of the fix wasn't the only reason for the release; there were two other development trees that independently asked for an extension. The other trees that needed the extension involve the btrfs filesystems and firmware for Intel GPU controllers.

"When we've had one of those embargoed \[hardware\] issues pending, the patches didn't get the open development, and then as a result missed all the usual sanity checking by all the automation build and test infrastructure we have," Torvalds explained. "So, 5.19 will be one of those releases that have an additional rc8 next weekend before the final release."

Last week, researchers at ETH Zurich announced the discovery of Retbleed, an addition to the family of speculative execution attacks that began with Meltdown and Spectre. The researchers named the family of these vulnerabilities Spectre-BTI after the attack method: via a branch target injection.

Unlike its siblings, Retbleed does not proceed via indirect jumps or calls, but instead uses return instructions. This is significant because it undermines some of the current Spectre-BTI protections, the researchers wrote.

In response, Intel and AMD issued advisories describing mitigations for CVE-2022-29901 (Intel CPUs) and CVE-2022-2990 (AMD CPUs).

**Speculative Execution Exploits Here to Stay**

The discovery follows Hertzbleed, discovered in June, which exploited a side-channel flaw in Intel and AMD processors, allowing remote attackers with low privileges to infer sensitive information by observing power-throttling changes in the CPU.

The attacks leverage weaknesses in the speculative execution process, a performance optimization technique in modern CPUs.

Other major speculative execution vulnerability exploits uncovered in recent years include Meltdown, Spectre, and SWAPGS.

A team of Google researchers published a deep analysis of the issue back in 2019, positing that chip makers' focus on performance has left microprocessors open to numerous side-channel attacks that cannot be fixed by software updates.

Some experts believe exploits like Spectre and Meltdown will force customers to make tradeoffs between performance and security of applications. They predict these types of threats will become much more dangerous in cloud and virtual environments.

A 2019 survey from Login VSI found patches negatively impacted performance for a fifth of those who applied them, with at times substantial performance reductions.

Retbleed Fixed in Linux Kernel, Patch Delayed

Law enforcement estimates campaign has already bilked cryptocurrency investors out of $42.7 million.

Would-be cryptocurrency investors are being targeted in a scam that has already stolen more than $42.7 million from 244 victims, according to the latest private industry notification from the Federal Bureau of Investigation. 

According to the FBI, scammers have used phishing attacks to convince victims to download fake mobile cryptocurrency investment apps impersonating legitimate investment apps. The victims then deposit cryptocurrency into wallets associated with their accounts on the app, giving the scammers control of the funds. One campaign between December and May used the name and logo of a legitimate company (unnamed in the alert) and defrauded 28 victims of $3.7 million.

When victims attempted to withdraw funds from these accounts, they received messages stating that they needed to pay taxes on their investments first.

The advisory warns legitimate cryptocurrency financial institutions to be on the lookout for these scams and alert the FBI about any attempts to lure investors with fake solicitations. 

"While cryptocurrency steals headlines, the fraudsters are out in force trying to steal them too," Ryan McCurdy of Bolster.ai said in reaction to the FBI alert. "Scammers are becoming more sophisticated in researching companies and targeting employees." 

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

FBI: Beware of Scam Cryptocurrency Investment Apps

An ongoing campaign is actively targeting the vulnerability in the Kaswara Modern WPBakery Page Builder Addon, which is still installed on up to 8,000 sites, security analysts warn.

Although the plug-in is no longer available, the Kaswara Modern WPBakery Page Builder Addons is still running on as many as 8,000 WordPress sites, according to analysts who warn the app's unpatched file upload vulnerability is under active attack. 

The WordPress bug, tracked under CVE-2021-24284, can be used to upload malicious PHP files to an affected website, according to the research team at Wordfence. The vulnerability could lead to code execution and complete site takeover, the researchers warn. The plug-in was closed without a patch and the Wordfence team says all versions are affected by the bug.

Wordfence raised the alarm that it has seen nearly a half-million daily attacks since the beginning of July. The campaign has used the NDSW Trojan to inject code into legitimate JavaScript files and redirect users to malicious domains.

The team stresses this is a "serious vulnerability that can lead to complete site takeover" and that the "developer has not been responsive regarding the patch" in their advisory on the WordPress plug-in. Since it is unlikely the plug-in will ever receive a patch for this critical vulnerability, "the best option is to fully remove the Kaswara Modern WPBakery Page Builder Addons plugin from your WordPress website," the researchers advise. 

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

WordPress Page Builder Plug-in  Under Attack, Can't Be Patched

Feeling creative? Submit your caption and our panel of experts will reward the winner with a $25 Amazon gift card.

We provide the carrot — the chance to win a $25 Amazon gift card — and you provide a possible caption for the cartoon above. It's that simple (and no worries about a stick). Here are four convenient ways to submit your idea:

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

The contest ends Wednesday, August 11, 2022. We look forward to your submissions.

**Last Month's Winner**  
We had a record number of submissions for our "Cuter Than a June Bug" caption contest. But, of course, only one person can win, and that person happens to be the very clever Kenny M. Congratulations! A $25 Amazon gift card is on the way.

    

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 Toon: Modern-Day Fable

Telecom and business services see the highest level of attacks, but the two most common ransomware families, which continue to be LockBit and Conti, are seen less often.

Attempted ransomware attacks declined in the first quarter of 2022, as companies continued to be less likely to pay requested ransoms and the war between Russia and Ukraine disrupted the Eastern European groups responsible for a significant share of attacks, endpoint detection-and-response firm Trellix states in a new report. 

Companies continued to encounter the two most common ransomware families — LockBit and Conti — more than a third of the time, but both ransomware attacks are seen far less often, with detections for LockBit dropping by 44% and Conti by 37%, according to Trellix's "Summer 2022 Threat Report." Globally, ransomware targeted the telecom sector in more than half of attacks, but business services dominated the targeting of US organizations, accounting for 64% of detections.

While cybercriminals often avoid politics, the decline likely comes as a result of Russia's invasion of Ukraine, which has led to more geopolitical-related attacks but fewer ransomware campaigns, says Christiaan Beek, lead scientist at Trellix.

"The attacks are shifting," he says. "While we saw some wipers and some other malware, which continued in April and May, they remain fairly low activity, but we are seeing more activity from hacktivism and \[patriot\] groups."

    

Globally, the telecommunications sector is most targeted by ransomware, but in the US, business services are favored. Source: Trellix's Summer 2022 Threat Report

The report from Trellix's Threat Labs is the first analysis from the company to combine data and telemetry from two acquisitions — McAfee Enterprise and FireEye's product business — bought by Symphony Technology Group in 2021. In January, STG renamed the combined businesses Trellix.

The company also includes references to data from a third party — incident response firm Coveware — that shows only 46% of companies paid a ransom in the first quarter of 2022, down from 85% for the same quarter three years ago. The average victim's payment to ransomware groups also declined to $74,000, down more than a third from the fourth quarter of 2021, Coveware stated in a May blog post.

"This is what progress looks like against ransomware. It is slow," the company stated.

**Harder to Compromise Systems**

Nation-state activity continues to be a major threat, according to Trellix's report. Following Russia's invasion of Ukraine — two countries that are thought to be home to several ransomware groups — attacks have focused on a goal of data exfiltration while using cybercrime as a way to fund the effort.

In February, for example, the Conti group publicly posted a statement supporting the Russian government. The following month, a Ukrainian researcher leaked years of Conti's internal chats, showing that the group had dozens of coders, operated like a business, and maintained separate sets of tools to hide the actual size of their operations.

"\[W\]e should consider we might be witnessing the formation of a hybrid group, one that can attack targets chosen by the government, but maintaining the plausible deniability of a crime group after financial gain," Trellix's report states. "The ransomware might have a dual purpose, on the one hand being disruptive in nature and on the other hand serving as a distraction for a data exfiltration operation."

Other major trends include the continued adoption of living-off-the-land (LotL) techniques. While a red-team tool, Cobalt Strike, continues to be the most popular attack tool by far — used in a third (32%) of campaigns — attackers continue to use tools resident on the targeted systems, including Windows Shell, PowerShell, and the Windows Management Interface (WMI), Trellix's report states.

However, attackers do have to work harder to compromise systems, with improving defenses requiring longer attack chains, says Beek. In the past, a victim might click on a link in an email or open an untrusted attachment and have a malicious program installed.

"Now, you see an email with an attachment still, but it has a little script in there that is a URL, for example, and it goes to one website, downloads a little bit of code," Beek says. "There are more stages that are happening before something is definitely being put on the system."

While telecommunications companies and business services are currently the most popular targets of attacks, among the most worrisome trends is the vulnerability of the healthcare industry and the continued ransomware attacks on the organizations that provide medical care, Beek says.

He warns that the trend will likely continue, given the anemic funding for cybersecurity in healthcare.

"This is not just the a ransomware perspective — it's also about the level of vulnerability," he says. "For me, that is a concern. You want to go to a hospital to get treated, and you don't want delays because of ransomware."

Ransomware Attempts Flag as Payments Also Decline

How a well-meaning employee could unwittingly share their identity with other users, causing a whole range of problems across IT, security, and the business.

Last month I wrote an article about the way low-code/no-code platforms are offering credential-sharing as a service, why they are doing it, and how this looks from an attacker's perspective. In this article, I'll focus on the implications of that compromise and how it affects enterprises today.

Here's why sharing your enterprise credentials with somebody else is bad practice. Say I want to pass my credentials to a colleague in order to query production logs for some one-off user-behavior analysis. In a typical enterprise, granting someone permissions to query a new data source could mean a long access review process, especially when it comes to production or sensitive data. My colleague could easily get frustrated. "All I wanted is to do this tiny one-off query, and I've already been waiting for a month!" they could say. I could just run the query for them, but I'm swamped with my own day-to-day tasks, and one-off queries tend to get complicated.

I am left with one quick solution: I could just share my username/password with my colleague. If they get an MFA challenge, I'll gladly approve. I don't have to spend the time running the query, and my colleague gets unblocked. Everybody wins! Right?

Well, you would be right in your analysis, but you are missing the bigger picture. While it's important for the enterprise that your colleague gets their user behavior analysis done, it is equally, if not more, important that your enterprise remains compliant with a whole host of privacy and security standards and maintains customer trust by upkeeping the company's commitment to security.

If high-level enterprise goals do not convince you, consider the central management teams in IT or security. Those teams base their operations and security strategies on the fact that each user has their own unique identity. IT teams are setting up networking and access policies that assume each user would be logged in from one corporate IP or corporate laptop at once; security teams are correlating events based on user ID; finance teams could be aggregating cost reports per user and their personal cloud environment. Credential sharing undermines all of those assumptions, among others. It strips away the basic meaning of an online identity.

**A Real-World Example**

Let's turn to the world of low-code/no-code and examine a real-world scenario. In a large enterprise, Jane, an inspired employee from the customer care team, realized that when employees across the organization take part in a customer case, they are usually missing key information about the customer, such as their support case history and latest purchases. This degrades the customer's experience, since they have to explain their issue again and again while the case gets routed to the right employee who can address the issue.

To improve this, Jane created an app that allows company employees to view this key information about customers when those employees are part of the team responsible for addressing the customer's support case. First, let's take a moment to acknowledge the power of low-code/no-code, which allows Jane to identify a need and address it on her own, without asking for a budget or waiting for IT resource allocations.

While building the application, Jane had to work around multiple issues, the biggest one being permissions. Employees across the organization don't have direct access to query the customer database to get the information they need. If they did, then Jane wouldn't have to build this application. To overcome this issue, Jane logged into the database and embedded her authenticated session directly in the application. When the application receives a request from one user, it will use Jane's identity to execute that query and then return the results to the user. This credential-embedding feature, as we explored last month, is a key feature of low-code/no-code platforms. Jane made sure to set up role-based access control (RBAC) in the application such that every user can only access customer cases they are assigned to.

The application solved an important business problem, and so it quickly gained user adoption across the enterprise. People were happy that they could provide better service to their customers by having the right context for the conversation. Customers were happy, too. A month after Jane created the application, it was already used by hundreds of users across the organization, with customer satisfaction rates rising.

Meanwhile at the SOC, a high-severity alert showing abnormal activity around the production customer database was triggered and assigned to Amy, an experienced security analyst. Amy's initial investigation showed an internal user was trying to scrape the entire database, querying information about multiple customers from multiple IP addresses across the organization. The query pattern was very complex; instead of a simple enumeration pattern you would expect to see when a database is being scraped, the same customer's data was queried multiple times, sometimes through different IP addresses and on different dates. Could this be an attacker trying to confuse the security monitoring systems?

After a quick investigation, Amy uncovered a crucial piece of information: All of those queries across all IP addresses and dates were using a single user identity, someone named Jane from the customer care team.

Amy reached out to Jane to ask her what's going on. At first, Jane didn't know. Were her credentials stolen? Did she click on the wrong link or trust the wrong incoming email? But when Jane told Amy about the application she recently built, they both realized there might be a connection. Amy, the SOC analyst, wasn't familiar with low-code/no-code, so they reached out to the AppSec team. With Jane's help, the team figured out that Jane's application had Jane's credentials embedded within it. From the database's perspective, there was no application — there was just Jane, executing a whole lot of queries.

Jane, Amy, and the AppSec team decided to shut down the application until a solution was found. Application users across the organization were frustrated since they had come to rely on it, and customers were feeling it, too.

While Amy closed the issue and documented their findings, the VP of customer care was not happy seeing customer satisfaction rate drop, so they asked Jane to look for a permanent solution. With the help of the platform's documentation and the organization's Center of Excellence team, Jane removed her embedded identity from the application, changed the app to use each user's identity to query the database, and ensured users gain permissions only to customer cases they are associated with. In its new and improved version, the application used each user's identity to query the customer database. Jane and the application users were happy that the application is back online, Amy and the AppSec team were happy that Jane's identity is no longer shared, and the enterprise saw customer satisfaction rate starting to climb up again. All was well.

Two weeks later, the SOC received another alert on abnormal access to the production customer database. It looked suspiciously similar to the previous alert on that same database. Again, IP addresses from across the organization were using a single user's identity to query the database. Again, that user was Jane. But this time, the security team and Jane knew that the app uses its user's identities. What's going on?

The investigation revealed that the original app had implicitly shared Jane's authenticated database session with the app's users. By sharing the app with a user, that user got direct access to the _connection_, a wrapper around an authenticated database session provided by the low-code/no-code's platform. Using that connection, users could leverage the authenticated session directly — they no longer had to go through the app. It turns out that several users had found this out and, thinking that this was the intended behavior, were using Jane's authenticated database session to run their queries. They loved this solution, since using the connection directly gave them full access to the database, not just for customer cases that they are assigned to.

The connection was deleted, and the incident was over. The SOC analyst reached out to users who had used Jane's connection to ensure they discarded any customer data they have stored.

**Addressing the Low-Code/No-Code Security Challenge**

The story above is a real-life scenario from a multinational B2C company. Some details were omitted or adjusted to protect privacy. We've seen how a well-meaning employee could unwittingly share their identity with other users, causing a whole range of problems across IT, security, and the business. As we explored last month, credential-sharing is a key feature of low-code/no-code. It's the norm, not the exception.

As low-code/no-code continues to bloom in the enterprise, consciously or not, it is crucial for security and IT teams to join the business development conversation. Low-code/no-code apps come with a unique set of security challenges, and their prolific nature means those challenges become acute faster than ever before.

Watch Out for User Impersonation in Low-Code/No-Code Apps

AI's potential for automating security has promise, but there are miles to go in establishing decision-making boundaries.

Would you let a child drive a car? I imagine that most people would think that is reckless and dangerous. However, what if the car were affixed to guardrails that limited its movement so that it can only move within certain bounds inside an amusement park?  

Allowing the current generation of artificial intelligence (AI) technologies to make decisions and take actions on our behalf is like having a 5-year-old take a car out for a joyride, but without the appropriate guardrails to prevent a terrible accident or an incident with potentially irreversible consequences.

Security professionals are often led to believe that AI, machine learning, and automation will revolutionize our security practices and allow us to automate security, perhaps even achieve a state of "autonomic security." But what does that really mean and what unintended consequences might we encounter? What guardrails should we consider that are commensurate with the "age" of AI?

To understand what we are getting ourselves into and the appropriate guardrails for security use cases, let us consider the following three questions.

*   How do AI/ML, decision-making, and automation relate to one another?
*   How mature are our AI/ML and automated decision-making capabilities?
*   How mature do they need to be for security?

To answer each of these questions, we can examine a combination of three frameworks: the OODA loop, DARPA's Three Waves of AI, and Classical Education.

**OODA Loop  
**The OODA loop stands for Observe, Orient, Decide, Act, but let's use a slightly modified version:

*   Sensing
*   Sense-making
*   Decision-making
*   Acting

Within this framework, AI/ML (sense-making) is distinct from automation (acting) and connected by a decision-making function. Autonomic means involuntary or unconscious. In the context of this framework, autonomic could mean either skipping sense-making and decision-making (e.g., involuntary stimulus-response reflexes) or skipping just decision-making (e.g., unconscious breathing). In either case, something that is autonomic skips decision-making.

**DARPA's Three Waves of AI  
**DARPA's framework defines the advancement of AI through several waves (describe, categorize, and explain). The first wave takes handcrafted knowledge of experts and codifies it into software to provide deterministic outcomes. The second wave involves statistical learning systems, enabling pattern recognition and self-driving cars. This wave produces results that are statistically impressive but also individually unreliable.

For the errant results, these systems have minimal reasoning capabilities and thus they cannot explain why it produces incorrect results from its sense-making. At DARPA's third wave, AI is able to provide explanatory models that enable us to understand how and why any sense-making mistakes are made. This understanding helps increase our trust in its sense-making capabilities.

According to DARPA, we haven't reached this third wave yet. Current ML capabilities can give us answers that are often correct, but they're not mature enough to tell us how or why they arrived at their answers when they're incorrect. Mistakes in security systems leveraging AI can have consequential outcomes, so root cause analysis is critically important to understand the reason behind these failures. However, we do not get any explanation of the "how" and "why" with results produced by the second wave.

**Classical Education  
**Our third framework is the Classical Education Trivium, which describes three learning stages in child development. At the elementary school stage, children focus on memorizing facts and learning about structures and rules. At the dialectic stage in middle school, they focus on connecting related topics and explaining how and why. Finally, in the rhetoric stage of high school, students integrate subjects, reason logically, and persuade others.

If we expect children to be able to explain how and why at middle school (somewhere around the ages of 10 to 13), that suggests that the current generation of AI, which lacks the ability to explain, isn't past the elementary stage! It has the cognitive maturity of a child that is less than 10 years old (and some suggest significantly younger.)  

With autonomic security, we're skipping decision-making. But if we were to have the current generation of AI do the decision-making for us, we must recognize that we're dealing with a system that has the decision-making capacity of an immature child. Are we ready to let these systems make decisions on our behalf without proper guardrails?

**Need for Guardrails  
**The march toward automated and autonomic security will undoubtedly continue. However, with some guardrails, we can minimize the carnage that would otherwise ensue. Here are points for consideration:

*   **Sensor diversity**: Ensure sensor sources are trustworthy and reliable, based on multiple sources of truth.
*   **Bounded conditions**: Ensure decisions are highly deterministic and narrowly scoped.
*   **Established thresholds**: Know when the negative repercussions of action might exceed the costs of inaction when something goes wrong.
*   **Algorithmic integrity**: Ensure that the entire process and all assumptions are well-documented and understood by the operators.
*   **Brakes and reverse gear**: Have a kill switch ready if it goes beyond the scope and make the action immediately reversible.
*   **Authorities and accountabilities**: Have pre-established authorities for taking action and accountabilities for outcomes.

Allowing a child to drive a car without proper guardrails would be irresponsible. Let's make sure that we have well thought-out guardrails for AI-driven security before we let our immature machines take the wheel.

Source

DARKReading