A worsening threat landscape, increased digitization, and the long-term positive effects of modern security strategies are pushing critical infrastructure operators to do better.

Following the Colonial Pipeline hack — one of the highest-profile attacks against US critical infrastructure to date — in 2021, the Department of Homeland Security's Transportation Security Administration (TSA) released two unprecedented Security Directives, requiring owners and operators of gas and liquid pipelines to implement strict new protections against cyberattacks.

On July 21, the TSA released an update to these directives, doubling down on its efforts to ensure better protection for energy infrastructure nationwide. In particular, it has emphasized the need for access control, credential management, and the use of "compensating controls" to allow pipeline operators to embrace the latest innovations in how they protect critical systems.

While the update represents another step toward better protection for the oil and gas industry, it's important to understand that the guidelines alone aren't the only factors influencing the security postures of critical infrastructure. Pipeline operators have already been acting; in our work with some of the largest TSA-regulated energy companies in North America, we've witnessed a fundamental, positive shift in their approaches to cybersecurity, especially over the past year.

**Three Cybersecurity Motivators**

Three major factors beyond government pressure stand out as being key motivations behind the acceleration of operators' adoption plans.

**1\. Today's threat landscape is progressively worsening.** Regulations don't happen in a vacuum. Today, our threat landscape has grown more dangerous than ever. In the past two years, we've seen countless cyberattacks on critical infrastructure, including hacks on meat processor JBS and the water treatment facility in Oldsmar, Fla. Furthermore, attackers are increasingly targeting the companies that make up the backbone of the United States' supply chain and society at large: oil and gas pipelines, manufacturing plants, food processors, water suppliers, and more.

These threats are only going to grow in severity. This is due in large part to the growth of ransomware-as-a-service (RaaS), heightened collaboration between RaaS and other cybercriminal groups such as access brokers, and a troubling uptick in Russian and other state-sponsored cyber threats targeting US critical infrastructure. Government regulations aside, no operator that we've come across has been able to ignore these growing risks — or wants to try their luck against these hackers without adequate protective measures.

**2\. Digitization is exposing new and dangerous vulnerabilities.** While attacks increase, the digitization of operations is bringing new vulnerabilities to light. On-site equipment such as programmable logic controllers (PLCs), SCADA systems, distributed control systems, and Internet of Things (IoT) devices are increasingly being accessed remotely, creating a porous perimeter that hackers can easily penetrate. This trend was only exacerbated as businesses pivoted to remote work during the pandemic. Now, operators are dealing with a significantly expanded attack surface.

Several components of the TSA's new guidelines reinforce what we already knew to be true: specifically, the importance of recognizing and mitigating these digitization-driven vulnerabilities. The requirements reaffirm the need to control the interconnection of operational technology (OT), IT, and even cloud by securing the digital conduits that connect the different zones and applications. The new TSA guidelines also deepen the requirements for "compensating measures" to protect access to critical systems, many of which have limited built-in security. These protections are so important to prevent an attacker being able to progress from zone to zone, or system to system, in the event of an initial network breach.

**3\. Better security is no longer just defensive; it's also the catalyst for greater digital transformation.** Beyond the necessity of protecting against attacks, operators have begun to realize that an advanced security strategy is capable of catalyzing an accelerated digital transformation — and this has catapulted them into implementing better protective measures.

It's widely understood that a zero-trust security architecture, as defined by the National Institute of Standards in Technology (NIST), is the best approach for protecting operations from threats. The heart of this strategy requires every asset, machine, or data source to have its own identity, with interactions between them being controlled by policy authorizations. Once such a model is achieved, benefits beyond airtight security immediately become clear.

For instance, critical infrastructure cybersecurity leaders reportedly cite, in a study commissioned by Xage (registration required), improved user experience, more efficient operations, and the ability to save time or money as top benefits to adopting zero trust. What's more, with every element of the operation digitized and secured, teams can share sensitive data with one another quickly and easily, and partners can tap into appropriate data sources to better collaborate and drive new types of value across the supply chain. The result is not only defense, but also greater efficiency, collaboration, and business innovation.

**Regulations Are Important, but They're Not a Silver Bullet**

The TSA's original Security Directives, coupled with the recent updates, represent a crucial catalyst in helping operators implement better protective measures; still, they're not the only factors driving progress. A worsening threat landscape, increased digitization, and the long-term positive effects of modern security strategies are all pushing critical infrastructure operators to do better. We're pleased to see the new requirements reaffirm what we know to be best practices for security, and we're confident that critical infrastructure protection will continue moving in the right direction.

Pipeline Operators Are Headed in the Right Direction, With or Without TSA's Updated Security Directives

What issues are cybersecurity professionals concerned about in 2022? You tell us!

As many enterprises shift their operations to cloud, security teams are grappling with multiple security concerns such as visibility, data security, compliance, and data breaches.

Data from Dark Reading's 2021 Strategic Security Survey suggests that security teams are less concerned about deploying security policies, visibility of data stored in the cloud, and the number of exploits targeting cloud service providers than they were in 2020. In contrast, the security professionals in the survey were more concerned in 2021 that cloud service providers would not be able to detect a breach and the fact that there are more cloud breaches being reported than they were in 2020.

What issues are cybersecurity professionals more concerned about in 2022? That's what Dark Reading would like to find out in this year's Strategic Security Survey (click to get to the survey).

Last year's report showed that enterprises are no longer as worried that cloud service providers won't be able to provide service-level guarantees of security. That's a good thing. Fewer people are still thinking that the cloud isn't safe. But the growing number of cloud breaches do have these enterprises concerned about how the service provider will work with them if there is an incident.

Dark Reading's 2022 Strategic Security Survey is still open — we welcome your insights.

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

What Worries Security Teams About the Cloud?

As the market for initial access brokers matures, services like Genesis — which offers elite access to compromised systems and slick, professional services — are raising the bar in the underground economy.

The growing role of so-called initial access brokers (IABs) in the underground cybercrime economy is reflected in evolution of Genesis Marketplace, one of the earliest full-fledged markets for IABs, which has grown more sophisticated and polished over time.  

A report this week from Sophos takes a comprehensive look at Genesis, which started in 2017 and offers malicious actors access to other people’s data, from credentials and cookies to digital fingerprints, through its invitation-only marketplace.

Genesis currently lists more than 400,000 bots (compromised systems) in more than 200 nations, with Italy, France, and Spain topping the list of affected countries.

The market provides not just the data itself but well-maintained tools to facilitate that data's (mis)use. Those tools extend to bespoke anti-detection offerings that help its clients stay under the radar when deploying stolen credentials to access targeted bots — including a Google Chrome extension and even a "continually maintained and upgraded" Genesium browser on offer.

"Most attackers, especially less-experienced ones, do not want to waste time or effort on the reconnaissance and infiltration phases of an attack," explains Sophos threat researcher Angela Gunn. "The maturity of Genesis, both the ease of use and the serious-inquiries-only vibe that come with restricted access, speaks to not wasting time or effort."

The service is defined by the high quality level of data on offer, as well as the site's commitment to keeping stolen info up to date.

This means hackers who pay for stolen information are kept abreast by Genesis of when that information changes or gets updated. Users are charged an according rate based on the volume of information it has on the targeted bot.

"For instance, the single set of credentials that led to the June 2021 EA data breach, which famously allowed the attackers into EA’s system through the gaming giant’s Slack, were purchased on Genesis for $10," according to the report.

Genesis also offers its clientele a level of customer service and user interface (UI) polish that Sophos describes as "far from the old days of 133tsp34k and Matrix-wannabe interfaces." This includes a slick, contemporary interface, a page of frequently asked questions (FAQs), and multilingual tech support.

Returning users also have access to a dashboard with updated information about the compromised systems they've tapped into.

"The fact that Genesis actually has a customer-service function is a statement that bolsters the operation’s seriousness," Gunn points out.

**IABs Get More Professional as Demand Rises**

The evolution of Genesis points to the "growing professionalization and specialization" of the cybercrime economy, the report notes.

Ransomware groups and affiliates are assumed to be the service's most frequent customers, particularly criminals who are looking for an IAB site that gives them expedited access and faster lateral movement to their targets.

Gunn explains that the "Dark Web" — which of course is not just one thing — has been professionalizing for a while now.

"Applicant vetting, robust search, tech support, developers, and designers — that work doesn’t happen for free," she adds. "Paying for that work evidences just how high the profits are in this realm."

A high level of organization also distinguishes the Genesis market, giving malicious actors more contextual information surrounding stolen data, and allowing them greater insights into the compromised systems. This could in fact spur even more inventive attack vectors.

"For instance, a darknet manual that we found during a recent investigation suggests to other criminals that they use complementary data from Genesis for kicking victims out of their accounts if stolen credentials are no longer valid," according to the report.

This means that even if victims attempt to neutralize the threat of stolen credentials, attackers can use the complementary data to actively extort affected users.

**The Velvet Rope Treatment**

Adding to the air of exclusivity and sophistication is the service's invite-only accessibility, which has resulted in a smaller cybercrime ecosystem of fake sites promising access to Genesis and requiring gullible criminals to make a "deposit" with a credit card to access it.

In November 2021, Digital Shadows, which has been tracking IABs since 2016, reported an increase in the use of IABs among cybercriminals.

Gunn says if organizations want to avoid landing on the IAB auction block, they first must patch all vulnerabilities, keep their systems in order, and stay vigilant.

"Even if IABs are a newer development in the threat landscape, the processes of recon and infiltration are nothing new," she adds. "Organizations should have a detection strategy in place to recognize those unusual activities, but also you need to understand your network, what’s on it, what the potential attack surfaces are, and where to prioritize patching accordingly."

Genesis IAB Market Brings Polish to the Dark Web

For the right price, threat actors can get just about anything they want to launch a ransomware attack — even without technical skills or any previous experience.

The underground economy is booming — fomented by a surging and evolving ransomware sector. The Dark Web now has hundreds of thriving marketplaces where a wide variety of professional ransomware products and services can be had at a variety of price points.

Researchers from Venafi and Forensic Pathways analyzed some 35 million Dark Web URLs — including forums and marketplaces — between November 2021 and March 2022 and uncovered 475 webpages filled with listings for ransomware strains, ransomware source code, build and custom-development services, and full-fledged ransomware-as-a-service (RaaS) offerings.

**A Plethora of Ransomware Tools**

The researchers identified 30 different ransomware families listed for sale on the pages, and found ads for well-known variants such as DarkSide/BlackCat, Babuk, Egregor, and GoldenEye that previously have been associated with attacks on high-profile targets. The prices for these proven attack tools tended to be significantly higher than lesser-known variants. 

For instance, a customized version of DarkSide — the ransomware used in the Colonial Pipeline attack — was priced at $1,262, compared with some variants that were available for as low $0.99. The source code for Babuk ransomware, meanwhile, was listed at $950, while that for the Paradise variant sold for $593.

"It's likely that other hackers will be buying ransomware source code to modify it and create their own variations, in a similar way to a developer using an open source solution and modifying it to suit their company's needs," says Kevin Bocek, vice president of security strategy and threat intelligence at Venafi. 

The success that threat actors have had with variants such as Babuk, which was used in an attack on the Washington, DC, police department last year, make the source code more appealing, Bocek says. "So you can see why a threat actor would want to use the strain as the foundation for developing their own ransomware variant.”

**No Experience Necessary**

Venafi researchers found that in many instances, the tools and services available through these marketplaces — including step-by-step tutorials — are designed to allow attackers with minimal technical skills and experience to launch ransomware attacks against victims of their choice. 

"The research found that ransomware strains can be purchased outright on the Dark Web, but also that some 'vendors' offer additional services like tech support and paid add-ons such as unkillable processes for ransomware attacks, as well as tutorials," Bocek says.  

Other vendors have reported on the growing use among ransomware actors of initial access services, for gaining a foothold on a target network. Initial access brokers (IABs) are threat actors that sell access to a previously compromised network to other threat actors.

**Initial Access Brokers Thrive in the Underground Economy**

A study by Intel471 earlier this year found a growing nexus between ransomware actors and IABs. Among the most active players in this space are Jupiter, a threat actor that was seen offering access to as many as 1,195 compromised networks in the first quarter of the year; and Neptune, which listed more than 1,300 access credentials for sale in the same time frame.   

Ransomware operators that Intel471 spotted using these services included Avaddon, Pysa/Mespinoza, and BlackCat.

Often the access is provided via compromised Citrix, Microsoft Remote Desktop, and Pulse Secure VPN credentials. Trustwave's SpiderLabs, which keeps tabs on prices for various products and services on the Dark Web, describes VPN credentials as the most expensive records in underground forums. According to the vendor, prices for VPN access can go as high as $5,000 — and even higher — depending on the kind of organization and access it provides.

“I expect to see a ransomware rampage carry on as it has done for the last few years," Bocek says. "The abuse of machine identities will also see ransomware move from infecting individual systems, to taking over entire services, such as a cloud service or a network of IoT devices." 

**A Fragmented Landscape **

Meanwhile, another study released this week — a midyear threat report by Check Point — shows the ransomware landscape is littered with considerably more players than generally perceived. Check Point researchers analyzed data from the company's incident response engagements and found that while some ransomware variants — such as Conti, Hive, and Phobos — were more common than other variants, they did not account for a majority of attacks. In fact, 72% of the ransomware incidents that Check Point engineers responded to involved a variant they had encountered only once previously.

"This suggests that contrary to some assumptions, the ransomware landscape is not dominated by only a few large groups, but is actually a fragmented ecosystem with multiple smaller players that are not as well-publicized as the larger groups," according to the report.

Check Point — like Venafi — characterized ransomware as continuing to present the biggest risk to enterprise data security, as it has for the past several years. The security vendor's report highlighted campaigns like Conti group's ransomware attacks on Costa Rica (and subsequently on Peru) earlier this year as examples of how significantly threat actors have broadened their targeting, in pursuit of financial gain. 

**Big Ransomware Fish May Go Belly Up**

Several of the larger ransomware groups have grown to a point where they employ hundreds of hackers, have revenues in the hundreds of millions of dollars, and are able to invest in things like R&D teams, quality assurance programs, and specialist negotiators. Increasingly, larger ransomware groups have begun to acquire nation-state actor capabilities, Check Point warns.

At the same time, the widespread attention that such groups have begun to garner from governments and law enforcement will likely encourage them to maintain a law profile, Check Point says. The US government, for example, has offered a $10 million reward for information leading to Conti members being identified and/or apprehended, and $5 million for groups caught using Conti. The heat is thought to have contributed to a Conti group decision earlier this year to cease operations.

"There will be a lesson learned from the Conti ransomware group," Check Point says in its report. "Its size and power garnered too much attention and became its downfall. Going forward, we believe there will be many small-medium groups instead of a few large ones, so that they can go under the radar more easily."

A Ransomware Explosion Fosters Thriving Dark Web Ecosystem

With names, email addresses, and mobile numbers from underground databases, one person in five is at risk of account compromise even with SMS two-factor authentication in place.

Companies that rely on texts for a second factor of authentication are putting about 20% of their customers at risk because the information necessary to attack the system is available in compromised databases for sale on the Dark Web.  

About 1 billion records synthesized from online databases — representing about one in every five mobile phone users in the world — contain users' names, email addresses, passwords, and phone numbers. This gives attackers everything they need to conduct SMS-based phishing attacks, also known as smishing, says Thomas Olofsson, CTO of cybersecurity firm FYEO. 

Cybersecurity experts have long known that the addition of an SMS one-time password is a weak form of two-factor authentication and the simplest form of two-factor authentication for attackers to compromise. However, combining such attacks with the readily available information on users produces a "perfect storm" for attacking accounts, he says.

At Black Hat USA, Olofsson plans to go over findings from research into the problem during a session on Wednesday, Aug. 10, called "Smishmash — Text-Based 2FA Spoofing Using OSINT, Phishing Techniques, and a Burner Phone."

"The research that we have done is two parts: How do you bypass 2FA, and how many phone numbers can we tie to an email address and a password," he tells Dark Reading. "So, for about one in five — a billion — people, we can connect your email address to your phone number, and that is really bad."

The analysis found that by collecting information from known databases of compromised usernames and passwords, researchers could create a database of 22 billion credentials. Linking those credentials to a phone number reduced the exposure to a bit more than 1 billion records, of which about half have been verified.

To make use of those records, attackers can conduct an adversary-in-the-middle attack, where the smishing attack goes to a proxy. When a targeted user opens a link in a malicious SMS message on a mobile device, browsers on iOS and Android rarely show any security information, such as a the URL, since screen real estate is so small. Because of that, few — if any — signs of the attack are presented to the user, making the attacks much more effective, Olofsson says.

In addition, smishing attacks are seven times more likely to succeed than phishing attacks conducted through email, he says.

"It makes it extremely likely that someone will click on the link," Olofsson says. "I even look at our attacks, and I said, wow, I could fall for this."

Attackers have used smishing to compromise financial accounts — especially those linked to cryptocurrency exchanges — during the past two years, with more than $1.6 billion of crypto stolen so far in 2022, according to an analysis published in May. 

**SMS for 2FA: Risky Biz**

Meanwhile, the US federal government has already put additional restrictions on any use of SMS for a second factor of authentication. In 2016, the National Institute of Standards and Technology (NIST) warned against using one-time passwords sent as text messages for a second factor to authenticate users.

"An SMS sent from a mobile phone might seamlessly switch to an internet message delivered to, say, a Skype or Google Voice phone number. Users shouldn't have to know the difference when they hit send — that’s part of the Internet’s magic. But it does matter for security," NIST wrote in an explanation of the policy, adding: "While a password coupled with SMS has a much higher level of protection relative to passwords alone, it doesn't have the strength of device authentication mechanisms inherent in the other authenticators allowable" by NIST guidelines.  

To make it less likely that such attacks succeed, users should ignore any notifications that come through SMS and instead log directly into their account.

"Never trust an SMS message," Olofsson says. "If you feel something is wrong, don't click on it, don't trust it. Go on a computer, and see if you have an e-mail, because at least you can verify the headers then."

Unfortunately, many financial institutions and other companies make it hard for users to implement better security because they only offer SMS as an option for the second factor of authentication. Adding reCAPTCHA checks can give users a hint that something is wrong, Olofsson notes, because any adversary-in-the-middle attack will display the proxy server, not the user's IP address.

Stolen Data Gives Attackers Advantage Against Text-Based 2FA

Over the past few weeks, a Mirai variant appears to have made a pivot from infecting new servers to maintaining remote access.

Tracked by analysts since mid-June, RapperBot malware has spread through brute-force attacks on SSH servers. The IoT botnet targets devices running on ARM, MIPS, SCARC, and x86 architectures, researchers warn.

The malware is a Mirai variant with a few notable, novel features, including ditching the typical Telnet server brute-force approach in favor of attacking SSH servers instead. Fortinet Labs analysts said that since July, RapperBot has changed up its approach from infecting as many servers as possible to maintaining remote access to those compromised SSH servers.

The malware gets its name from a URL that led to a YouTube rap video in early versions, the researchers explained.

"Due to some significant and curious changes that RapperBot has undergone, its primary motivation is still a bit of a mystery," the Fortinet advisory on RapperBot said. "Regardless, since its primary propagation method is brute forcing SSH credentials, this threat can easily be mitigated by setting strong passwords for devices or disabling password authentication for SSH (where possible)."

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

Fresh RapperBot Malware Variant Brute-Forces Its Way Into SSH Servers

This Tech Tip outlines how DevOps teams can address security integration issues in their CI/CD pipelines.

DevOps teams are familiar with the ways security concerns and process issues can stall CI/CD operations. Operational hurdles that lead to miscommunication between team members and the broader organization are all too common in DevOps pipelines. One of the leading operational issues DevOps teams encounter are permission issues.

Permission issues are a seemingly small, yet significant, roadblock to smooth CI/CD pipelines. If you fail to address them, the result is a lack of cohesion between development and organizational objectives.

Here's how to streamline these processes, boost security integration within the broader CI/CD framework, and maintain robust security postures.

**Review Pipeline Tools**

The DevOps cycle contains several tools with different access needs and permissions. Jeremy Hess, head of developer relations at secrets management platform Akeyless, calls this a "secrets sprawl."

"The combination of proliferation and decentralization of secrets creates an operational burden, if not a nightmare," Hess says. "For organizations that operate in both a cloud-native environment and classic IT infrastructure, a duplication issue is created due to having their own secrets managed with different tools and cloud-native solutions."

There is also the risk of these tools exposing user credentials and permissions to malicious actors. For instance, configuration tools like Jenkins use plugins to determine access and artifact deployment. Thanks to communicating with other pipeline tools, credential details can be present in configuration details.

Developer passwords are not visible on the front end but are accessible from the system. Any user with "configure" permissions can request a credential and inject them into agents. The result is that AWS keys, git credentials, and passwords are at risk.

What to Do:

*   The first step is to delete hardcoded secrets from CI/CD tool files.
*   Distributing secrets between multiple tool config files also reduces the possibility of attack while easing developer and engineer access.
*   Password managers are also a good choice, but validate them for security before implementing a solution.

**Practice Least-Privilege Access**

Access issues often create a lot of frustration among DevOps teams as they are forced to assign blanket access to the majority irrespective of the member's role or job function. While this situation encourages rapid development, it creates massive security issues.

Balancing security with CI/CD needs is tough to get right. That's where the principle of least privilege comes in. Team members receive access to secrets on a need-to-know basis. Note that this principle applies to everything from apps to systems and connected devices.

While most teams put this principle into practice, they leave their process intact. The lack of access audits, not the level of access, creates DevOps frustration.

What to Do:

*   CISOs should regularly involve DevOps teams when reviewing access to mitigate issues quickly. Embedding a security role within every delivery team will mitigate access-related risks quickly. The security team member will have insights into risk-based access needs and can quickly approve or reject requests.
*   Creating an access management repository will also remove any confusion related to role-based access. In addition, record time-based and task-based access permissions in the repository. The result is every DevOps team member will understand their access paths before projects get started. It allows them time to offer feedback and request one-off access to sensitive secrets.
*   Review segmentation rules within your systems when assigning role-based access. Often, these rules will have to change depending on delivery timelines. Involving all stakeholders in these discussions is good practice and prevents frustration down the road.

Implementing one-time passwords (OTPs) and other authentication factors is also a good idea when validating user access to secrets.

**Review OSS Projects**

Open source projects are essential to industry growth but might pose security risks if access is mismanaged. Zan Markan, developer advocate at CI platform CircleCI, summarizes the problem aptly.

"Often the company that initiated and owns a popular OSS project continues to employ the core contributors," Markan writes. "They will probably be joined by other regular contributors and maintainers that are not part of that company. And then there is everyone else — anyone who occasionally might contribute a fix or a feature."

As user access grows, security concerns grow exponentially. Enforcing rigid user-based access is unrealistic and detrimental to an OSS project.

What to Do:

*   CISOs or other security-focused managers must review whether sensitive secrets are being passed during builds for pull requests. Monitoring who can place requests and the roles that review them will ensure a good level of security.
*   Establishing machine identity is also critical, given the degree of non-human access pipelines require. Authentication can be based on verifying whether client runtime container attributes match the characteristics of the valid container. Once authenticated, role-based access can take over, limiting access to secrets.
*   It's also a good policy to destroy containers and virtual machines (VMs) after they've been used.

**Streamlining DevOps Operations Is a Top Priority**

DevOps is critical to every organization's success. Access and permission-related issues are common occurrences that are easily avoided. Reviewing access and establishing a balance between delivery and operational needs is essential to maintaining a competitive edge.

How to Resolve Permission Issues in CI/CD Pipelines

Development of digital gateways to protect the places where we live, work, and converse need to be secure and many doors need to offer restricted access.

What our homes mean to us has been redefined over the COVID era. We now work, rest, and play within its boundaries, not only with family, but also with friends and colleagues in real life or through our computers and connected devices. This "open door" policy, spurred by the pandemic, shows no signs of abating. As a result, our homes are vulnerable in several new ways, and we need to ensure our "new normal" doesn't take advantage of our hospitality.

Homes are also becoming smarter; we're inviting in more technology that is viewing, analyzing, and understanding our daily lives: Think Ring doorbells, Alexas, Zoom, Teams, and banking apps. We are giving technology permission to have some amount of control over and insight into our lives — to do this, they need to be connected and therefore we are introducing more open doors for potentially uninvited guests.

For these reasons, Home Gateways are vital to homes in order to ensure the four walls we live in are protected from digital thieves in the same way that our front doors protect our homes. However, these Home Gateway systems will only work within the Internet of Things (IoT) if the systems and standards that link them enable clarity, comprehension, and collaboration between providers and end users. Unlike our physical homes, there are many ways into our digital home networks, and we only want invited guests.

**Building on the Baseline**

The growing concern regarding the increasing number of Internet-connected devices prompted a number of ETSI members to bring their experience in national guidance and security development together to develop EN 303 645 to act as a baseline for all IoT devices. The aim was to bring all IoT devices to the market with a level of security that started to take away uncertainty for the end user, to offer a device that provides a level of security and helps police the open doors.

However, as our homes become a more complex environment, which moves beyond the IoT, this baseline needs to be built upon. This is why ETSI created TS 103 848 to provide the opportunity to build higher and deeper defenses for now and in the future. Developed by the CYBER Technical Committee, it builds out guidance and examples of the application of the baseline and beyond, most recently encouraging a formal template to make it clear where the baseline is extended or, in rare cases, where it doesn't apply. The first related standard addressed smartphones and was released at the end of last year; the next one will focus on smart door locks. The technical specifications will secure physical devices between the in-home network and the public network, as well as the traffic between these networks, which is vital to home security.

What has been developed with this new Home Gateway security document is important in that it makes it possible to achieve a high level of baseline security at the border of the Internet and home, which is integral to our new digital homes staying secure. It also strengthens the idea that simple security models developed to be universal can be extended and applied to vertical domains without invalidating the universal model. During the entire development of the Home Gateway requirements, and continuing in the development of test and validation of the requirements, there has been involvement from all parts of the stakeholder community. This means developers, manufacturers, operators, regulators, and testers have all come together to make the common baseline and set up for the future.

**Staying Secure**

Home Gateways are the first line of security defense for connected IoT and other home devices. While a secure Home Gateway does not remove the need for strong security of local devices connected to the gateway, it can provide protection against vulnerability for legacy devices or for those devices that cannot otherwise be secured. A secure Home Gateway is therefore a key security layer of the connected home. In a world where IoT devices are in every room of our households, measures to secure them and protect citizens from malicious attacks are of the essence.

Protecting our home is something we can never be complacent about and the Home Gateway addresses and keeps secure the gateways and windows into our lives that the digital world offers. Thus, the age-old promise of the ideal work-life balance has been brought closer with the hybrid of work from home, the occasional commute, flexible working hours, and a secure Internet starting with the basics of a secure Home Gateway.

**Further Information**

The ETSI consumer cybersecurity standard is supplemented by a test specification to help manufacturers pass certification schemes, a guide to facilitate implementation, and a template to better develop future vertical standards, within the committee or other standardization bodies.

*   To help manufacturers and other stakeholders, the ETSI CYBER technical committee has also released a Technical Report, ETSI TR 103 621 **\[Note: PDF download\],** to provide guidance to implement the provisions in ETSI EN 303 645.
*   To help develop other vertical standards, ETSI has created a template **\[Note: Word doc download\]** providing a structured way to extend EN 303 645 for the vertical domain.

A Digital Home Has Many Open Doors

At Black Hat USA, Igal Gofman plans to address how machine identities in the cloud and the explosion of SaaS apps are creating risks for IAM, amid escalating attention from attackers.

Cybercriminals always look for blind spots in access management, be they misconfigurations, poor credentialing practices, unpatched security bugs, or other hidden doors to the corporate castle. Now, as organizations continue their modernizing drift to the cloud, bad actors are taking advantage of an emerging opportunity: access flaws and misconfigurations in how organizations use cloud providers' identity and access management (IAM) layers.

In a talk on Wednesday, Aug. 10 at Black Hat USA entitled "IAM The One Who Knocks," Igal Gofman, head of research for Ermetic, will offer a view into this emerging risk frontier. "Defenders need to understand that the new perimeter is not the network layer as it was before. Now it's really IAM — it's management layer that governs all," he tells Dark Reading.

**Complexity, Machine Identities = Insecurity**

The most common pitfall that security teams step into when implementing cloud IAM is not recognizing the sheer complexity of the environment, he notes. That includes understanding the ballooning amount of permissions and access that software-as-a-service (SaaS) apps have created.

"Adversaries continue to put their hands on tokens or credentials, either via phishing or some other approach," explains Gofman. "At one time, those didn't give much to the attacker beyond what was on a local machine. But now, those security tokens have much more access, because everyone in the last few years moved to the cloud, and have more access to cloud resources."

The complexity issue is particularly piquant when it comes to machine entities — which, unlike humans, are always working. In the cloud context, they're used to access cloud APIs using API keys; enable serverless applications; automate security roles (i.e., cloud access service brokers or CASBs); integrate SaaS apps and profiles with each other using service accounts; and more.

Given that the average company now uses hundreds of cloud-based apps and databases, this mass of machine identities presents a highly complex web of interwoven permissions and access that underpin organizations' infrastructures, which is difficult to gain visibility into and thus difficult to manage, Gofman says. That's why adversaries are seeking to exploit these identities more and more.

"We are seeing a rise in the use of non-human identities, which have access to different resources and different services internally," he notes. "These are services that speak with other services. They have permissions, and usually broader access than humans. The cloud providers are pushing their users to use those, because at the basic level they consider them to be more secure. But, there are some exploitation techniques that can be used to compromise environments using those non-human identities."

Machine entities with management permissions are particularly attractive for adversaries to use, he adds.

"This is one of the main vectors we see cybercriminals targeting, especially in Azure," he explains. "If you don't have an intimate understanding of how to manage them within the IAM, you're offering up a security hole."

**How to Boost IAM Security in the Cloud**

From a defensive standpoint, Gofman plans to discuss the many options that organizations have for getting their arms around the problem of implementing effective IAM in the cloud. For one, organizations should make use of cloud providers' logging capabilities to build a comprehensive view of who — and what — exists in the environment.

"These tools are not actually used extensively, but they're good options to better understand what's going on in your environment," he explains. "You can use logging to reduce the attack surface too, because you can see exactly what users are using, and what permissions they have. Admins can also compare stated policies to what is actually being used within a given infrastructure, too."

He also plans to break down and compare the different IAM services from the top three public cloud providers — Amazon Web Services, Google Cloud Platform, and Microsoft Azure — and their security approaches, all of which are slightly different. Multi-cloud IAM is an added wrinkle for corporations using different clouds from different providers, and Gofman notes that understanding the subtle differences between the tools they offer can go a long way to shoring up defenses.

Organizations can also use a variety of third-party, open source tools to gain better visibility across the infrastructure, he notes, adding that he and his co-presenter Noam Dahan, research lead at Ermetic, plan to demo one option.

"Cloud IAM is super-important," Gofman says. "We're going to speak about the dangers, the tools that can be used, and the importance of understanding better what permissions are used and what permission are not used, and how and where admins can identify blind spots."

Cyberattackers Increasingly Target Cloud IAM as a Weak Link

A month after the algorithms were revealed, some companies have already begun incorporating the future standards into their products and services.

A month after the National Institute of Standards and Technology (NIST) revealed the first quantum-safe algorithms, Amazon Web Services (AWS) and IBM have swiftly moved forward. Google was also quick to outline an aggressive implementation plan for its cloud service that it started a decade ago.

It helps that IBM researchers contributed to three of the four algorithms, while AWS had a hand in two. Google contributed to one of the submitted algorithms, SPHINCS+.

A long process that started in 2016 with 69 original candidates ends with the selection of four algorithms that will become NIST standards, which will play a critical role in protecting encrypted data from the vast power of quantum computers.

NIST's four choices include CRYSTALS-Kyber, a public-private key-encapsulation mechanism (KEM) for general asymmetric encryption, such as when connecting websites. For digital signatures, NIST selected CRYSTALS-Dilithium, FALCON, and SPHINCS+. NIST will add a few more algorithms to the mix in two years.

Vadim Lyubashevsky, a cryptographer who works in IBM's Zurich Research Laboratories, contributed to the development of CRYSTALS-Kyber, CRYSTALS-Dilithium, and Falcon. Lyubashevsky was predictably pleased by the algorithms selected, but he had only anticipated NIST would pick two digital signature candidates rather than three.

Ideally, NIST would have chosen a second key establishment algorithm, according to Lyubashevsky. "They could have chosen one more right away just to be safe," he told Dark Reading. "I think some people expected McEliece to be chosen, but maybe NIST decided to hold off for two years to see what the backup should be to Kyber."

**IBM's New Mainframe Supports NIST-Selected Algorithms**

After NIST identified the algorithms, IBM moved forward by specifying them into its recently launched z16 mainframe. IBM introduced the z16 in April, calling it the "first quantum-safe system," enabled by its new Crypto Express 8S card and APIs that provide access to the NIST APIs.

IBM was championing three of the algorithms that NIST selected, so IBM had already included them in the z16. Since IBM had unveiled the z16 before the NIST decision, the company implemented the algorithms into the new system. IBM last week made it official that the z16 supports the algorithms.

Anne Dames, an IBM distinguished engineer who works on the company's z Systems team, explained that the Crypto Express 8S card could implement various cryptographic algorithms. Nevertheless, IBM was betting on CRYSTAL-Kyber and Dilithium, according to Dames.

"We are very fortunate in that it went in the direction we hoped it would go," she told Dark Reading. "And because we chose to implement CRYSTALS-Kyber and CRYSTALS-Dilithium in the hardware security module, which allows clients to get access to it, the firmware in that hardware security module can be updated. So, if other algorithms were selected, then we would add them to our roadmap for inclusion of those algorithms for the future."

A software library on the system allows application and infrastructure developers to incorporate APIs so that clients can generate quantum-safe digital signatures for both classic computing systems and quantum computers.

"We also have a CRYSTALS-Kyber interface in place so that we can generate a key and provide it wrapped by a Kyber key so that could be used in a potential key exchange scheme," Dames said. "And we've also incorporated some APIs that allow clients to have a key exchange scheme between two parties."

Dames noted that clients might use Kyber to generate digital signatures on documents. "Think about code signing servers, things like that, or documents signing services, where people would like to actually use the digital signature capability to ensure the authenticity of the document or of the code that's being used," she said.

**AWS Engineers Algorithms Into Services**

During Amazon's AWS re:Inforce security conference last week in Boston, the cloud provider emphasized its post-quantum cryptography (PQC) efforts. According to Margaret Salter, director of applied cryptography at AWS, Amazon is already engineering the NIST standards into its services.

During a breakout session on AWS' cryptography efforts at the conference, Salter said AWS had implemented an open source, hybrid post-quantum key exchange based on a specification called s2n-tls, which implements the Transport Layer Security (TLS) protocol across different AWS services. AWS has contributed it as a draft standard to the Internet Engineering Task Force (IETF).

Salter explained that the hybrid key exchange brings together its traditional key exchanges while enabling post-quantum security. "We have regular key exchanges that we've been using for years and years to protect data," she said. "We don't want to get rid of those; we're just going to enhance them by adding a public key exchange on top of it. And using both of those, you have traditional security, plus post quantum security."

Last week, Amazon announced that it deployed s2n-tls, the hybrid post-quantum TLS with CRYSTALS-Kyber, which connects to the AWS Key Management Service (AWS KMS) and AWS Certificate Manager (ACM). In an update this week, Amazon documented its stated support for AWS Secrets Manager, a service for managing, rotating, and retrieving database credentials and API keys.

**Google's Decade-Long PQC Migration**

While Google didn't make implementation announcements like AWS in the immediate aftermath of NIST's selection, VP and CISO Phil Venables said Google has been focused on PQC algorithms "beyond theoretical implementations" for over a decade. Venables was among several prominent researchers who co-authored a technical paper outlining the urgency of adopting PQC strategies. The peer-reviewed paper was published in May by Nature, a respected journal for the science and technology communities.

"At Google, we're well into a multi-year effort to migrate to post-quantum cryptography that is designed to address both immediate and long-term risks to protect sensitive information," Venables wrote in a blog post published following the NIST announcement. "We have one goal: ensure that Google is PQC ready."

Venables recalled an experiment in 2016 with Chrome where a minimal number of connections from the Web browser to Google servers used a post-quantum key-exchange algorithm alongside the existing elliptic-curve key-exchange algorithm. "By adding a post-quantum algorithm in a hybrid mode with the existing key exchange, we were able to test its implementation without affecting user security," Venables noted.

Google and Cloudflare announced a "wide-scale post-quantum experiment" in 2019 implementing two post-quantum key exchanges, "integrated into Cloudflare's TLS stack, and deployed the implementation on edge servers and in Chrome Canary clients." The experiment helped Google understand the implications of deploying two post-quantum key agreements with TLS.

Venables noted that last year Google tested post-quantum confidentiality in TLS and found that various network products were not compatible with post-quantum TLS. "We were able to work with the vendor so that the issue was fixed in future firmware updates," he said. "By experimenting early, we resolved this issue for future deployments."

**Other Standards Efforts**

The four algorithms NIST announced are an important milestone in advancing PQC, but there's other work to be done besides quantum-safe encryption. The AWS TLS submission to the IETF is one example; others include such efforts as Hybrid PQ VPN.

"What you will see happening is those organizations that work on TLS protocols, or SSH, or VPN type protocols, will now come together and put together proposals which they will evaluate in their communities to determine what's best and which protocols should be updated, how the certificates should be defined, and things like things like that," IBM's Dames said.

Dustin Moody, a mathematician at NIST who leads its PQC project, shared a similar view during a panel discussion at the RSA Conference in June. "There's been a lot of global cooperation with our NIST process, rather than fracturing of the effort and coming up with a lot of different algorithms," Moody said. "We've seen most countries and standards organizations waiting to see what comes out of our nice progress on this process, as well as participating in that. And we see that as a very good sign."

Source

DARKReading