IT departments must account for the business impact and security risks such applications introduce.

Last month, Dark Reading released an enterprise application security survey that raised serious concerns by IT and security teams about the state of low-code/no-code applications. The survey exposed a deep lack of visibility, control, and knowledge necessary to maintain the level of security maturity expected in the enterprise. Here we will look at concrete concerns raised by the survey, examine their root causes, and offer recommendations on ways to address them today.

The following concerns were raised under the question, "What security concerns do you have regarding low-code/no-code applications?"

**Concern No. 1: Governance**  
According to 32% of respondents, "There is no governance over how these applications are accessing and using our data."

Indeed, many useful low-code/no-code applications rely on storing data either in managed storage provided by the platform or in another platform via a connector. The tricky part is that low-code/no-code platforms make it extremely easy for makers to essentially bake their identity into the applications, so that every application user ends up triggering operations on behalf of the maker. Within enterprise environments, it is not uncommon for useful business applications to store their data in the maker's Dropbox or OneDrive account. Baked-in accounts can become an even bigger issue when an honest mistake causes data to be stored in a personal rather than business account.

Another popular use of low-code/no-code are data-movers or operation-stitchers. They connect source and destination, either by moving data between multiple points or by linking together an operation in one system to another in a different system.

As an example, a popular automation flow in enterprise scenarios is email forwarding. Users build an application that monitors their professional inbox for new emails, copies their content, and pastes it in their personal email for various reasons. Note that by copying the data, users are easily able to bypass DLP controls that would have prevented email forwarding.

**Concern No. 2: Trust**  
According to 26% of respondents, "I don't trust the platforms used to create the applications."

Low-code/no-code platform vendors are increasingly directing their attention to provide strong security assurance for their platforms, but there is a long way to go. While enterprise customers have become used to the security benefits provided by public cloud vendors, with their mature security teams, vulnerability disclosure programs, and state-of-the-art SOCs, low-code/no-code platforms are just getting used to the fact that they are now business-critical systems.

Of course, vendors investing in the security of their platform is not enough. Customers have to hold their part of the shared responsibility model, too. While platform vendors are improving their security posture, enterprises using low-code/no-code platforms must figure out how to approach these applications with the same level of security vigor as they would their pro-code applications. After all, the impact of both types of applications on data, identity, and the enterprise as a whole is the same.

Take security testing, for example. To catch security issues early, pro-code applications are typically built with code and configuration scanning tools in place, as part of the CI/CD. There are a host of tools to help detect issues throughout the SDLC, including SAST, DAST, and SCA, which has become very popular in recent years with the rise in open source security issues. Low-code/no-code applications are prone to the same problems that these tools detect, such as injection-based attacks, security misconfiguration, and untrusted dependencies. However, these applications typically rely on manual processes for security assurance or try to use pro-code tools to scan artifacts generated with low-code; unfortunately, pro-code tools fail to understand the business logic of low-code/no-code applications and therefore provide little value.

**Concern No. 3: AppSec**  
According to 26% of respondents, "I don't know how to check for security vulnerabilities in these applications."

How do I make sure my code makes sense, and that it is secure and robust, without access to that code? This point is tricky, and new solutions are required to tackle it.

When public cloud providers started introducing the concept of platform-as-a-service for compute services such as managed virtual machines (VMs), managed Kubernetes clusters, or serverless functions, the same kind of concerns were raised. Our entire strategy, as a security community, to secure compute instances was based on our ability to observe and leverage the host machine running our applications. While stripping away the complexities of managing VMs, cloud providers also stripped away the ability of security teams to observe and protect them. As a result, novel solutions had to be introduced to provide the same level of security assurance with cloud-native building blocks.

The same approach is desperately needed in low-code/no-code applications. Instead of trying to apply existing tools like code scanning or web security monitoring to artifacts generated by low-code/no-code, security teams should adopt solutions that understand the language of low-code/no-code in order to identify logical vulnerabilities in those applications.

**Concern No. 4: Visibility**  
According to 25% of respondents, "The security team doesn't know what applications are being created."

This point is particularly important because you can't protect what you can't see. Most low-code/no-code platforms have little to no capabilities for allowing admins to view applications built on these platforms. Basic questions like, "How many applications do we have?" are simply unanswerable without pervasive measures. For example, some platforms allow admins to make themselves the owners of every application separately but do not allow them to see the application otherwise. So admins must resort to an active change on the platform to take a look at the application. 

Other platforms go even further, allowing business users to create applications in a private folder that administrators cannot review, other than knowing the number of applications that exist in them. A maker could be exfiltrating data through a private application, and the admin is left with no way to even know anything besides the fact that the application exists.

Visibility becomes even trickier once companies realize that they are using more than one low-code/no-code platform. In fact, most large enterprises are already using multiple platforms. With low-code/no-code platforms becoming more popular, citizen development tools being introduced bottom-up, and software-as-a-service (SaaS) vendors becoming platforms themselves, it's clear why enterprises are suddenly finding themselves using several different platforms.

**Concern No. 5: Knowledge and Awareness**  
According to 33% of respondents, "I don't have any security concerns," "Other," or "Don't know."

Since low-code/no-code platforms often find their way into the enterprise through business units rather than top-down through IT, they can easily slip through the cracks and be missed by security and IT teams. While security teams are in most cases part of the procurement process, it's easy to treat a low-code/no-code platform as just another SaaS application used by the business, not realizing that the result of adopting this platform would be empowering a whole array of new citizen-developers in the business.

In one large organization, citizen-developers in the finance team built an expense management application to replace a manual process filled with back-and-forth emails. Employees quickly adopted the application since it made it easier for them to get reimbursed. The finance team was happy because it automated part of its repetitive work. But IT and security were not in the loop. It took some time for them to notice the application, understand that it was built outside of IT, and reach out to the finance team to bring the app under the IT umbrella.

Security and IT teams are always in a state where the backlog of concerns is much larger than their ability to invest. To make sure resources are allocated to the most critical security risks, teams must first be aware of the criticality of low-code/no-code applications to the business and the security risks that they introduce. For the former, this means that low-code/no-code applications' impact on the enterprise must be demonstrated and clear. Security teams must be part of the discussion when thinking about adopting citizen development. 

For the latter, we as a community have to research, categorize, and share concrete security risks we identify to help others to build more secure applications. Bringing IT and security into the low-code/no-code conversation would allow the adoption of these technologies to accelerate, unleashing their full potential to increase business velocity and productivity.

Why So Many Security Experts Are Concerned About Low-Code/No-Code Apps

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

The above cartoon is in a need of a caption, and we're depending on you, dear Dark Reading readers, to come up with something that tickles our collective funny bone. Here are four ways to submit your idea:  

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

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

**Last Month's Winner**  
Congratulations to Nextiva risk manager Bruce Walton, whose winning caption (below) for our March "Sleep Like a Baby" contest rose above many amusing options. A $25 Amazon gift card is on the way. 

Thank you to everyone who participated.

    

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: Helping Hands

The ongoing war in Ukraine means that defenses are only as good and as strong as those with whom we partner.

Disinformation campaigns, distributed denial-of-service attacks, wiper malware, Internet blackouts, and bot armies are just a few of the various digital attacks that Russia has aimed at Ukraine. In late February, the Cybersecurity and Infrastructure Security Agency (CISA) and the Federal Bureau of Investigation (FBI) issued a joint advisory warning US firms to prepare their defenses to defend against these kinds of attacks. As of now, at least four different kinds of wiper malware — destructive disk-wiping malware — have been released during the conflict.

For those who are still wondering where is the cyberwar in the Russian invasion, it's already here and it's imperative for organizations across the globe to be prepared. However, in a tightly integrated global economy, these preparations must not occur in isolation but, rather, must encompass an organization's partners — and their partners' partners and so forth. Collective resilience captures this notion of strengthening the defenses across an organization's entire supply chain ecosystem by pursuing strength in unity, but viewed through a realistic lens, that self-preservation requires strengthening and lifting up the weakest links within highly interdependent systems. When it comes to the growing uncertainty and instability stemming from the Russian invasion, there has been a sharp swing toward collective resilience to proactively offset and mitigate the ongoing Russian malicious cyber activity.

Russian malware has a history of making organizations across the globe collateral damage, even if they are not the intended target. In 2017, a destructive supply chain attack propagated across the globe in a matter of hours. Maersk, Merck, and FedEx were just a few of the global victims, as the cyberattack disrupted ports, hindered vaccine distribution by the Centers for Disease Control and Prevention, and crippled manufacturing sales. This history, coupled with Russia's ongoing deployment of a range of malicious cyber activity during the fog of war, elevates the risk and potential for collateral damage across the globe due to cyberattacks. CISA's Shields Up campaign attests to the growing risk to organizations stemming from the Russian invasion.

**Third-Party Risks  
**However, Shields Up should not just apply to an organization's own systems but to its partners as well. Third-party risks remain a core attack vector targeting the weakest link within an organization's supply chain. More than 2,000 US-based firms had suppliers in Ukraine and Russia prior to the invasion; a number which exponentially increases to hundreds of thousands of suppliers when integrating their second- and third-tier suppliers. Even if these suppliers are not the intended targeted, they may become collateral damage in the war.

An organization's digital supply chain similarly must be part of this extended defense. Just as NotPetya exploited the digital supply chain, the US and UK have warned that the Russian-linked Cyclops Blink botnet is targeting ASUS, a Taiwanese electronics company. Coupled with the Lapsus$ Group's ongoing attacks, supply chain attacks remain on the rise and are a core component of Russia's strategy of preparatory installation and reconnaissance. The Cyclops Blink campaign has been active since at least 2019, illustrating Russia's ongoing efforts to embed and prepare for future exploitation. FBI Director Christopher Wray explained how cyberattacks do not occur instantaneously, but rather, "There's activity that leads up to it. ... There's developing access to those systems. So, there's a whole range of preparatory work, which is what we've been seeing." This access increasingly occurs through the digital supply chain.

**Collective Resilience  
**Furthermore, the growing list of approximately 400 sanctioned Russian companies introduces an additional cyber and supply chain risk for organizations. For instance, the March 24 US Department of Treasury sanction targets almost 50 Russian defense-industrial base organizations, including Joint Stock Company Russian Helicopters. This company alone has hundreds of tier-1 and tier-2 suppliers and is in the supply chain of many technology and aerospace and defense companies as it accounts for 10% of the global helicopter market. Many in the aerospace and defense sector rely on the same suppliers, exacerbating the potential for a single sanctioned company to propagate risk throughout the industry. 

These companies are not only at risk of noncompliance fines but need to consider the degree to which the hundreds of restricted companies have access to their data or networks. More sanctions are also likely, including secondary sanctions that target third-party relationships — a step that would yet again stress the necessity of collective resilience across an organization's entire supply chain.

Some are adhering to CISA's warnings and strengthening their own defenses, while others still debate the absence of malicious cyber activity in the Russian invasion. While fortunately there has yet to be the major attacks many feared, Russia continues "to undermine, coerce, and destabilize," according to Anne Neuberger, Deputy National Security Advisor for Cyber and Emerging Technology. As we've seen in the past, these destabilization efforts are unlikely to remain contained to Ukraine. Organizations should seek a collective resilience approach in preparation for the growing geopolitical instability across the globe. Defenses are only as good and as strong as those with whom we partner.

Strength in Unity: Why It's Especially Important to Strengthen Your Supply Chain Now

Upgrading and fixing the vulnerability in the Spring Framework doesn't seem to have the same level of urgency or energy as patching the Log4j library did back in December.

The maintainers of the popular Spring framework patched the critical remote code execution flaw (CVE-2022-22965) on March 31. Two weeks later, the majority of Spring downloads are still using vulnerable versions with the flaw unpatched, suggesting developers are not in a rush to upgrade.  

As of April 15, 77% of Spring downloads were for vulnerable versions, according to the charts posted by Sonatype on its Exploit Resource Center. That is a small drop from April 4, when 82% of Spring downloads were for vulnerable versions of the framework. There was a quick jump to about 20% of downloads adopting the latest versions, but since then the figure has leveled off. One reason why the vulnerable versions of Spring are still being downloaded may be tied to the fact that many companies do not have a clear understanding of all the dependencies for each business application.

"\[The\] fact that we continue to see these downloads is indicative that organizations haven’t made the decision to upgrade,” says Brian Fox, Sonatype’s CTO.

In the above stacked area chart, the red region represents the vulnerable versions and the green region is the updated version with the fix patched. In this case, the higher the number, the more applications with the vulnerable component being built.

The needle toward the majority of developers using the updated version is moving very slowly.

**Preparing for the Future  
**The vulnerability’s exploitability can change at any time: Someone may develop an attack vector that is repeatable and doesn’t require as many specific conditions to be present or may figure out a way to get around security mitigations. It would be better to get the environment updated now before a newer exploit is developed and the situation becomes more serious.

“\[The\] danger is, when the cone of attention moves on, there will be plenty of unpatched estate that might later become a risk,” notes Iikka Turunen, Sontaype's field CTO. “It's not a  Spring thing, it's a how are we managing our dependencies thing.”

The vulnerability exists in Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older. The issue has been fixed in Spring Framework version 5.3.18 and 5.2.20 and Spring Boot 2.5.12 and 2.6.6.

“This seems to indicate that those who know they need to upgrade — and are able to — tend to do so very quickly,” Fox says. “The rest of the long tail, however, is very long, leaving lots of room for attackers to find new ways to exploit the existing vulnerabilities and to work around the mitigations that may be in place.”

**Not “as Bad” as Log4j  
**Back in December, when the vulnerability in Log4j was disclosed, there was a big push to get people to update as soon as possible. Sonatype says its latest numbers show that 34% of Log4j downloads are still the vulnerable version. The majority of new downloads are for the latest – safe – version.

Despite its severity, the issue in Spring isn’t viewed as being just as urgent because exploitation requires a nonstandard setup (packaged as a traditional WAR file when most modern applications have switched to Spring Boot executable jar files) and exploitation is currently very limited.

“Spring4Shell does give us a unique opportunity to understand what happens in the software industry when ‘Critical’ but not ‘The Internet is on Fire’-level vulnerabilities appear,” Turunen says.

To underscore the rarity, vulnerability scanning and penetration testing services company Intruder scanned over 25,000 client assets since the disclosure of the vulnerability. “We have yet to find a vulnerable application,” writes Benjamin Marr, a security engineer with Intruder.

Security teams should not get complacent or delay the upgrades. “There will inevitably be more ways to exploit through adjacent methods,” Fox says. “The safest thing to do in these scenarios, almost always, is upgrade.”

Upgrades for Spring Framework Have Stalled

Google patches a critical flaw in its Chrome browser, bringing its count of zero-day vulnerabilities fixed in 2022 to four.

Google fixed two vulnerabilities in its Chrome web browser as part of an emergency update this week, including a type confusion vulnerability that is already being exploited in the wild.

The type confusion vulnerability (CVE-2022-1364) impacts the JavaScript and WebAssembly engine in the browser. With this kind of flaw, a program will allocate a resource (such as a pointer or object) using one type but will later try to access the resource using an incompatible type. The vulnerability can be exploited to cause the browser to crash, trigger logical errors, or even execute arbitrary code.

"Google is aware that an exploit for CVE-2022-1364 exists in the wild," the company wrote in the alert. Details will be restricted until a majority of users have updated to Chrome version 100.0.4896.127 across the Windows, Linux, and Mac platforms.

The issues also affect other Chromium-based browsers, such as Microsoft Edge, Brave, and Vivaldi.

The second issue that was fixed appears to be related to issues that were uncovered internally. The alert calls it "various fixes from internal audits, fuzzing, and other initiatives."

This is the third emergency update for Chrome in 2022, and the third zero-day vulnerability patched so far this year. In March, Google (along with Microsoft) fixed a critical flaw to the Chromium v8 JavaScript engine (CVE-2022-1096) that was being actively exploited.

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

Google Emergency Update Fixes Chrome Zero-Day

IT professionals worry most about cloud security, but other questions arise about training, functionality, and performance.

The biggest concern IT staff has about their organization's use of cloud computing is far and away security. Almost three-quarters (73%) of survey respondents cited security as the greatest worry about the cloud. But half also cited cost (58%) and reliability (50%) as areas of concern.

That's according to State of the Cloud: A Security Perspective, a report from Dark Reading released in March 2022. The research surveyed decision-makers with IT job titles at organizations that use cloud services. Those organizations include companies of all sizes from a variety of industries, including technology, healthcare, financial services, manufacturing, and education.

Reliability looms large both because of its importance — employees and customers need to be able to access a company's tools in order for it to stay open for business — and because for cloud applications, reliability is largely outside the control of the organization. That lack of control can certainly raise anxiety levels.

The only other concerns that rise into the double digits are staff skills in cloud computing (26%), inadequate cloud functionality (10%), and putting too much data in the cloud (10%). Like reliability, these all tie back in with security, the responsibility for which is shared between the data owner and the cloud provider. As cloud implementation grows and matures across all industries, IT staff are learning how to secure data and configure cloud access for maximum security, which may alleviate the stress enough to keep "too much data" worries down to 10% of respondents.

To end on a positive note, only 6% of respondents say their service level agreements are inadequate or that their service providers try to upsell them on unwanted cloud services. Indeed, a full 2% of respondents say they have no concerns and are fully content with their cloud services. That's one response we'd all like to see grow.

For more data and insights, download the full report.

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

Cloud Cost, Reliability Raise IT Concerns

Chemical companies are the latest to be targeted by the well-known North Korean group, which has targeted financial firms, security researchers, and technology companies in the past.

The North Korean-linked Lazarus group sent fake job offers to targets in the chemical sector and information technology firms, which — when opened — install Trojan horse programs to collect information and send it back to the attackers, technology provider Broadcom's security arm Symantec stated in an advisory on April 14.

The attack is part of a long-running campaign — dubbed Operation Dream Job — that sends targets in specific industries malicious Web files disguised as job offers, which when opened attempts to compromise the system. While the current set of attacks focuses on South Korean chemical companies and their IT service providers, other targets have included industries and government agencies in Europe, Asia, and the United States. This campaign marks a shift, as Lazarus in the past targeted the defense, government, and engineering sectors.

The attacks have, at various times, targeted defense contractors, engineering firms, government agencies, and even pharmaceutical companies during the height of the pandemic, says Dick O’Brien, principal intelligence analyst for Symantec's threat-hunting team.

"North Korea-linked attackers have a long history of targeting intellectual property, presumably to assist strategically important engineering or technology projects," he says, adding: "Across all attacks, we’ve seen a range of data theft \[and\] data exfiltration tools deployed on infected computers. We’re assuming that they take what they need before moving on."

Other security and technology firms have also documented Lazarus's involvement in Operation Dream Job, which some researchers track as Operation AppleJeus. In early 2021, the Lazarus group targeted security researchers with similar offers of high-level jobs in the industry. And, earlier this year, the attackers targeted more than 250 individuals working for news media, software vendors, and Internet infrastructure providers, using job offers that appeared to come from Disney, Google, and Oracle, according to Google, which tracked the campaign.

A related campaign targeted cryptocurrency and financial technology and services firms, Adam Weidemann, a researcher with Google's Threat Analysis Group, stated in a late March blog post.

"We suspect that these groups work for the same entity with a shared supply chain, hence the use of the same exploit kit, but each operate with a different mission set and deploy different techniques," he wrote. "It is possible that other North Korean government-backed attackers have access to the same exploit kit."

**Long-Running Campaign  
**The April 14 advisory from Symantec noted that the campaign started at least as early as August 2020, albeit with a different set of targets. While the current campaign targets the chemical sector, campaigns discovered in 2020 had focused on government agencies and defense contractors, the company stated in its advisory.

"Operation Dream Job involves Lazarus using fake job offers as a means of luring victims into clicking on malicious links or opening malicious attachments that eventually lead to the installation of malware used for espionage," the company said.

Symantec's threat team outlined the steps in a successful attack in January 2022, which completed less than four days after the target received the file until the final execution of a program that collected and exfiltrated system data. After the targeted user opened the fake job offer, the attack exploited a vulnerability in one of two software packages, the INISAFE Web EX Client for system management or MagicLine, a gym management program, says Symantec's O'Brien.

"They’re not household names for us but our working assumption is they’re widely used in the industry or sector they’re currently targeting," he says. "An alternative hypothesis is they installed the software themselves in order to inject into it, but we haven’t seen any evidence of that."

While companies not running either application may not have to worry about this particular attack, cyber-espionage groups such as Lazarus are very good at tailoring attacks to match their target's environment, he says.

For that reason, no single solution will help prevent cyber-espionage attacks, O'Brien stressed. Instead, companies should take a layered approach to defense, using network detection, endpoint security, and hardening technologies — such as multifactor authentication — to protect against multiple vectors of attack, he says.

"We’d also advise implementing proper audit and control of administrative account usage, \[and\] you could also introduce one-time credentials for administrative work to help prevent theft and misuse of admin credentials," O'Brien says. "We’d also suggest creating profiles of usage for admin tools, \[because\] many of these tools are used by attackers to move laterally undetected through a network."

Lazarus Targets Chemical Sector With 'Dream Jobs,' Then Trojans

Omdia Senior Analyst Hollie Hennessy says the new threat to multiple ICS and SCADA devices underscores the importance of a rapid response to IoT and OT security risks.

On April 13, the Department of Energy (DoE), the Cybersecurity and Infrastructure Security Agency (CISA), the National Security Agency (NSA), and the Federal Bureau of Investigation (FBI) released a joint Cybersecurity Advisory to warn that certain industrial control systems (ICS) and supervisory control and data acquisition (SCADA) devices can be targeted by advanced persistent threat (APT) actors who have the capability to gain full system access.

The alert warned that vulnerable products include Schneider Electric programmable logic controllers, OMRON Sysmac NEX PLCs and Open Platform Communications Unified Architecture (OPC UA) servers.

Once on the operational technology (OT) network, APT actors can utilize certain custom-made tools to scan for vulnerable devices, and then exploit and subsequently take control of them.

The advisory also noted a critical issue with Windows-based engineering workstations. Systems in the OT environment, or even on the IT side, can be compromised using an exploit targeting vulnerable motherboard drivers.

Utilizing these techniques, importantly and worryingly, could allow APT actors to elevate their privileges, move laterally within the OT environment to other devices, and disrupt or crash critical devices.

With recent events, such as the Colonial Pipeline attack, which saw the entire OT environment shut down (despite not even originating with OT devices), plus the rise of ransomware and the threat of politically motivated national state actors, those in critical national infrastructure need to act fast.

DoE, CISA, NSA, and the FBI urge organizations, especially those in the energy sector, to implement detection and mitigation recommendations to detect APT activity and harden their ICS/SCADA devices.

The advisory credited security firms including Dragos, Mandiant, and Palo Alto Networks for contributions leading to the advisory. Dragos revealed it’s been analyzing the malware (dubbed PIPEDREAM) since early 2022.

**Conclusions  
**It goes without saying that threat actors will continually find a way to penetrate IoT and OT networks; this advisory is not the first of its kind, nor will it be the last.

The tricky issue with OT networks is their average age (often spanning decades), complex history (evolving organically with minimal planning), and the demanding nature of devices. Traditionally, OT environments did not connect to the IT network in the way they do today — they were physically segregated and disconnected from the outside world, as well as the enterprise and any IT-related functions. This is what’s called an "air gap" but is now a thing of the past.

Digital transformation and the connection of OT systems and other devices to the network broadens the attack surface and opens up industrial environments to attackers. But the business priorities driving this transition, plus the nature of legacy systems and devices that need to be constantly available, mean security is often left behind.

The alert underscores how important it is for enterprises to prepare to address these kinds of IoT and OT security advisories quickly and thoroughly, before adversaries can take advantage of them.

It may seem trivial, but first points of call include changing all passwords and maintaining offline backups — which can help to mitigate brute-force attacks and aid fast recovery in the event of an attack. Those in industrial environments need to ensure they have a robust cybersecurity posture in place — including adequate visibility and monitoring, alongside perimeter and access controls.

The alert notes the importance of collaboration between stakeholders across IT, cybersecurity and operations, which is especially important to ensure cybersecurity is effectively applied in these complex IoT and OT environments with their own unique requirements.

CISA Alert on ICS, SCADA Devices Highlights Growing Enterprise IoT Security Risks

The act contains a loophole added late in the process that will impede progress toward the goal of increasing US cybersecurity: a complete carve-out of DNS from the reporting requirements and other obligations outlined in the bill.

During the past few years, we have witnessed an alarming increase in the volume and sophistication of cybercrime and cyberattacks. It is both understandable and necessary that the US Congress has taken measures to strengthen our country’s cybersecurity. The Strengthening American Cybersecurity Act of 2022, for example, was recently passed by the Senate and is currently in review by the House of Representatives. The cybersecurity community is pleased to see action by Congress on this important issue, but, unfortunately, the act contains a significant loophole added late in the legislative process that will impede progress toward the goal of increasing US cybersecurity: a complete carve-out of DNS from the reporting requirements and other obligations outlined in the bill.

The Domain Name System, of course, registers domain names and translates them into digital addresses that route traffic through the global Internet. DNS is at the heart of the Internet and represents the exact type of information that needs to be reportable to proactively protect our cyber assets.

For decades, DNS and the data concerning individuals and organizations that register and use domain names — known as WHOIS data — have been critical to law enforcement agencies and private cybersecurity companies to protect the US and its citizens from cyberattacks and cybercrime.

As stated in written testimony to Congress by the FBI Cyber Division in 2003, “Cyber Division investigators use the WHOIS database almost every day. Querying of domain name registries is the first step in many cybercrime investigations. Anything that limits or restricts the availability of WHOIS data to law enforcement agencies will decrease its usefulness in FBI investigations …” This was true in 2003, and it is true now. In 2020, DHS reaffirmed, “Homeland Security Investigations (HSI) views WHOIS information, and the accessibility to it, as critical information required to advance HSI criminal investigations, including COVID-19 fraud.”

**Gone Dark**  
Despite the unambiguous statements from governments and law enforcement agencies expressing the critical importance of DNS and open and immediate access to accurate WHOIS data for cybersecurity, WHOIS data has essentially gone dark since May 2018. This can be traced to the enactment of policies put in place by the Internet Corporation for Assigned Names and Numbers (ICANN) as the organization attempted to comply with the European Union’s General Data Protection Regulation (GDPR). But GDPR applies to people, not to companies or governments. Yet nearly all useful registration data has been hidden — even the data not subject to GDPR.

It is not only US-based law enforcement agencies that emphasize the critical role of the DNS and WHOIS data for cybersecurity. In 2018, the European Cybercrime Centre (EC3) Advisory Group on Internet Security stated, “Almost all cyberattacks … require infrastructure which is subject to DNS registration at some point in the attack life cycle. As such, the international Whois protocol plays a critical role in identifying malicious infrastructure and thus defending against or preventing attacks. Accessing Whois registrant information is an essential element of the cybersecurity community’s efforts to maintain the overall security and stability of the global Internet. …”

Passing cybersecurity legislation while exempting DNS and ignoring the lack of WHOIS data accessibility is like trying to improve banking security while removing the know-your-customer (KYC) requirements. Doing so leaves the country increasingly vulnerable and unable to identify, track, and prevent malicious behavior.

**Restore Access to WHOIS Data**  
Given these circumstances, it is contrary to the goal of improving security for the federal government and the American people for Congress to give a “pass” on mandatory reporting to the DNS and the current lack of availability of WHOIS data. It would be more beneficial for Congress to restore access to WHOIS data and require that all domain name registries and registrars that have any business nexus to the US be able to verify the accuracy of the WHOIS data of their customers. Such data should also be made publicly accessible. The three top-level domains —.com, .org, and .net — are all administered by US companies and, as of April 2021, comprised 60% of all domain names used by websites around the world.

As explained by the Anti-Phishing Working Group at a Cooperation Against Cybercrime international conference, “Restricted access to WHOIS data by GDPR regulation under its initial interpretation (by ICANN) hampers Internet security; law enforcement activities; security research; anti-money laundering activities; and programmatic suppression of criminal infrastructure.” Turning a blind eye to this critical component of cybersecurity and relegating these DNS and WHOIS data issues to the exclusive provenance of ICANN’s multistakeholder organization, which has failed to serve the public interest, will impede rather than improve the cybersecurity of the US.

Cybersecurity Act of 2022: A Step in the Right Direction With a Significant Loophole

Elsewhere Partners invests in proven service mesh and API management innovator as it grows team and breaks into new markets.

ALEXANDRIA, Va.--(BUSINESS WIRE)--greymatter.io Inc., an enterprise microservices platform provider, today announced the close of a $7.1 million Series A round. Led by Elsewhere Partners, the funding will fuel greymatter.io’s global growth as demand intensifies for its comprehensive microservices platform, which includes service mesh and API management for enterprise-scale IT environments.

“Organizations are quickly realizing that they must future-proof their IT infrastructures. The distribution of software, APIs, data, and users across hybrid, multi-cloud, and on-premise systems has created dramatically more complex networks that large organizations (both public and private) are struggling to control, secure and monitor,” said Chris Pacitti, founder and partner of Elsewhere Partners. “We have been watching greymatter.io execute on their vision for an enterprise microservices platform for more than three years. They have proven the strength and scalability of their platform to effectively manage the explosion of configuration sprawl, security, governance, and risk needs.”

In enterprise hybrid and multi-cloud operations, it is more important than ever for IT leaders to control complexity, trust nothing, and see everything. The global service mesh market continues to surge with some analysts predicting it will top $2.3 billion by 2028 to support the complexities introduced by service-based architectures, and greymatter.io has been a leading innovator in the space since 2015. Helping large organizations cut their operational costs by upwards of 30 percent, greymatter.io allows DevSecOps and NetSecOps teams to easily manage increasing complexity, secure application networking with zero-trust and see everything happening across their IT environment. Recognized as an industry outperformer by GigaOm, the Grey Matter platform offers cloud- and platform-agnostic solutions to uncover and relieve the top issues plaguing enterprises as their application networking, API security and IT operations evolve – from misconfigurations, unvetted configurations and unpatched vulnerabilities, to data leaks, failed audits and more.

“greymatter.io has become a proven industry force thanks to our talented team and steadfast commitment to ease our customers’ top infrastructure burdens,” said greymatter.io CEO Chris Holmes. “Working with an investment partner as dedicated as we are to customer-driven, product-led company growth, there are no limits to what the coming months/years hold. We will continue to provide the most comprehensive modern microservices platform based on a service mesh purpose built to help large public organizations and private enterprises overcome complexity sprawl and tackle all governance, analytic and zero-trust security needs regardless of the number of clouds, on-premise systems, applications or endpoints involved.”

After years successfully serving the complex needs of massive, globally distributed government and defense organizations, greymatter.io will use the funding to expand the reach of its proven microservices platform in both the public and private sector by rapidly building out its team. In addition, greymatter.io will accelerate its pipeline of platform enhancements, add support for key open source community projects, and cultivate new partnerships in advanced areas of zero-trust security and data mesh to support its continued market leadership.

Timed with the investment, seasoned enterprise B2B software industry executives Mike Kushin and Michele Perry (an Elsewhere Partners operating advisor) will join the Board to help support the company’s market expansion and recruiting efforts.

**About greymatter.io Inc.  
**A venture-backed microservices platform provider, greymatter.io is driving the next era of intelligent service mesh and API management to solve complex challenges flowing from enterprises’ DevSecOps and NetSecOps pipelines through production operations. Led by a team of experts, the company builds infrastructure intelligence solutions to help its customers better manage, secure, and operate enterprise software. The platform has a rapidly growing user base that includes some of the largest, most security-conscious, globally decentralized organizations in the world. Learn more at greymatter.io.

**About Elsewhere Partners  
**Elsewhere Partners is a growth-stage venture capital firm that invests in Elsewhere Outliers – business software companies that are located outside of traditional venture capital hubs and have achieved substantial customer traction and revenue growth without significant outside funding. Elsewhere Partners combines transitional capital with transformational expertise to help companies achieve exit readiness on their own terms. To learn more, visit www.elsewhere.partners.

Source

DARKReading