Ratings ranged from AAA to CC, with security effectiveness scores from 27% to 100%.

**AUSTIN, Texas, Dec. 1, 2022 /PRNewswire/ —** CyberRatings.org, the non-profit entity dedicated to providing transparency on cybersecurity product efficacy, has completed an independent test of eight market leading security vendors in its first-ever Cloud Network Firewall comparative evaluation. Forcepoint, Fortinet and Juniper's test reports were published earlier in the year, all with 'AAA' ratings. In this latest release of test reports, Check Point and Versa Networks received a 'AAA' rating. Palo Alto Networks received an 'AA,' Sophos an 'A,' and Cisco 'CC.'

The test covered capabilities considered essential in a firewall including basic routing, access control, SSL / TLS decryption, threat prevention (exploits), evasion, performance, stability and reliability, and management. Amazon Web Services (AWS) was the public cloud service chosen to run the test. Ratings were calculated using a scale from 0 to 800.

Key findings include:  

*   Cloud services assume a shared security model, where cloud providers are responsible for the infrastructure and customers are responsible for securing the applications running on the infrastructure.
*   Roughly 80% of web traffic is encrypted and firewall decryption is not on by default: Firewalls will not see/block attacks delivered via (encrypted) HTTPS unless configured to do so.
*   Security vendors are used to controlling the platform on which their products are installed. In the cloud, they do not have that control; vendors are learning how to operate under these new conditions and there will be challenges.
*   Supply Chain attacks are on the rise. Using the cloud means relying on third parties to maintain software supply chain integrity. APIs, code reuse, open-source libraries, not maintained code, and other shared resources introduce unknown risks.

Security effectiveness scores ranged from 27% to 100%. The security effectiveness tests verified how effectively the firewall protected control network access, applications, and users while preventing threats (exploits and evasions), blocking malicious traffic while under extended load, and remaining resistant to false positives. Exploit block rates ranged from 88.3% to 100%. All products achieved 100% for resistance to evasion techniques.

"Security is your problem, not Amazon's," said Vikram Phatak, CEO of CyberRatings.org. "If you are migrating your data center to the cloud, create a plan for securing it." Phatak added. "And if you needed a firewall for your data center, you probably need one for your cloud deployment."

There are different ways consumers can purchase security products for the cloud. The individual test reports reflect the bring-your-own-license model while the comparative report illustrates the pay-as-you-go pricing. Both pricing models provide consumers with options to compare pricing on items important to their own organizations.

The following products were evaluated:

**Check Point Cloud Network Firewall CloudGuard IaaS R81.20-581**

**AAA**

Cisco Firepower Threat Defense for AWS Version 7.2.0

CC

Forcepoint Cloud Network Firewall v6.11

AAA

Fortinet Cloud Network Firewall v7.0.5 Build 0304(GA)

AAA

Juniper Cloud Network Firewall 22.1R1.1

AAA

Palo Alto Networks Cloud Network Firewall PA-VM-AWS-10.2.2

AA

Sophos Cloud Network Firewall SFOS 19.0.0 GA-Build317

A

Versa Networks Cloud Network Firewall Versa-FlexVNF-21.2.3

AAA

To read the CyberRatings reports go to CyberRatings.org.

Cloud Network Firewall test tools were provided by Keysight (CyPerf and Breaking Point), and TeraPackets Threat Replayer.

**About CyberRatings.org**

CyberRatings.org is a non-profit 501(c)6 entity dedicated to quantifying cyber risk and providing transparency on cybersecurity product efficacy through testing and ratings programs. To become a member, visit www.cyberratings.org.

CyberRatings.org Announces Results from First-of-its-Kind Comparative Test on Cloud Network Firewall

Multiple Xiongmai NVR devices, including MBD6304T V4.02.R11.00000117.10001.131900.00000 and NBD6808T-PL V4.02.R11.C7431119.12001.130000.00000, allow authenticated users to execute arbitrary commands as root, as exploited in the wild starting in approximately 2019. A remote and authenticated attacker, possibly using the default admin:tlJwpbo6 credentials, can connect to port 34567 and execute arbitrary operating system commands via a crafted JSON file during an upgrade request. Since at least 2021, Xiongmai has applied patches to prevent attackers from using this mechanism to execute telnetd.

CVE-2022-45045: Xiongmai IoT Exploitation - Blog - VulnCheck

Current authentication methods are based on the bearer model, but lack of visibility into the entities leveraging API secrets has made this untenable.

Today most API communication between machines is secured through API secrets — static keys, tokens, or PKI certificates that act like system passwords in order to authenticate machines and broker communication between them. These machines could be cloud workloads, pods, containers, servers, virtual machines, microservices, or physical machines like servers or Internet of Things devices.

The challenge with current mechanisms of securing authentication between machines is that they all prescribe a bearer model of authentication. As long as an API key, token, or certificate is valid, it can be held and used from anywhere, even a nefarious machine. The model does not guarantee trusted access or trust in the API client. Further adding to the risk is that these API secrets are often long-lived and cumbersome to maintain hygiene around.

Perfect security hygiene would mean each API secret is uniquely assigned to only one machine, never shared, routinely rotated. and securely distributed through development and deployment systems to the machine that needs it without the risk of being leaked along the way. The reality is API secrets are often shared across dozens or hundreds of machines and workloads. They are rarely, if ever, rotated, and provisioning and managing secrets across different applications and environments is an arduous task.

**The Cost of Secrets**

According to a 2021 report by 1Password, IT and DevOps spend an average of over 25 minutes each day managing secrets, at an estimated payroll expense of $8.5 billion annually across companies in the US. In a world where development and deployment systems are fully automated, provisioning and rotating secrets continues to be a very manual, laborious process.

Leaked infrastructure secrets come at a measurable cost. Exposed code, credentials, and keys — whether they are exposed accidentally or intentionally — cost companies an average of $1.2 million in revenue per year, according to the 1Password report.

More recently, the static nature of API secrets has made them ripe targets for adversaries. Much like passwords, secrets tend to become more vulnerable as they age — a problem that is only compounded when those secrets are being shared across dozens, sometimes hundreds of different workloads. Today, secrets are getting leaked at an alarming rate in code repositories, continuous integration (CI) systems like Jenkins or Travis, orchestration tools like Kubernetes, and cloud hosting environments like Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure. Ditto for logging tools like Splunk and Elastic and even collaboration environments like Slack. Organizations leaked more than 6 million passwords, API keys, and other sensitive data in 2021, doubling the number from the previous year, according to a recent GitGuardian review.

**Tools to Improve Things**

Enterprises can take extra steps to keep their secrets more secure. Secrets management solutions like vaults or secrets managers help organize and better secure these system passwords. But if your organization happens to be operating workloads with all three cloud providers, your team will have to leverage three proprietary secrets management systems in order to safeguard those secrets — Azure Key Vault, AWS Secrets Manager, and Secret Manager for GCP.

Tools do exist that can scan your environments to find hard-coded secrets in source code, code repositories, CI environments, and logging systems. Some tools can also scan public personal and organization repositories for secrets that may have already been exposed.

**An Unbearable Burden**

One significant blind spot for many engineering and security teams is visibility into the identities of the machines, applications, services, or workloads that are leveraging API secrets. If it isn't already broken by this point, that becomes the point where the bearer model starts to break down.

Between the manual nature of secrets management, the vulnerability of these static values, and the way the explosion of API usage has significantly increased the amount of compromised keys, tokens, and certificates, not having visibility into the entities that are leveraging API secrets has made the bearer model untenable. CISA's zero-trust framework and NIST 800-207 provide guidelines around how organizations think about machines and workloads as nonperson entities — where the user isn't a human, but rather another application or service account.

While CISA and NIST guidelines assist organizations in handling identity and access, the solution to this problem has already been established for human-to-machine interactions: multifactor authentication (MFA). If we think about the genesis of MFA as it relates to applications and services human users are accessing, the purpose is to validate the user identity with a set of credentials. Many companies require employees to enable MFA to ensure that it is indeed Jane who is trying to access the CRM application with her username and password, just in case her user credentials were compromised. The static nature of passwords, coupled with how long they tend to age well past most security guidelines, makes them ripe targets for adversaries, which is why many organizations mandate MFA to access applications that contain sensitive data.

The bearer model is no different — keys, tokens, and certificates are static values that act as system passwords. The challenge many organizations face is having visibility into the identities of the machines, applications, workloads, or services that are ultimately leveraging those credentials.

API Secrets: Where the Bearer Model Breaks Down

Red Hat has issued patches for a bug in an open source Java virtual machine software that opens the door to drive-by localhost attacks. Patch now, as it's easy for cyberattackers to exploit.

A critical remote code execution (RCE) bug in an open source Java virtual machine (JVM) framework threatens enterprise environments by giving attackers an easy way to compromise development teams — thus gaining access to production systems.

That's according to Joseph Beeton, senior application security researcher at Contrast Security, who discovered the vulnerability in Quarkus, a Red Hat-managed, Kubernetes-native Java framework that's optimized for JVMs.

The bug is tracked as CVE-2022-4116 and has been given a rating of 9.8 on the CVSS.

The relatively new Quarkus framework is used as a platform for serverless, cloud, and Kubernetes environments — the last of which is the de facto container management platform for cloud-native environments, and has had numerous security issues of its own.

The Quarkus flaw is present in the framework's Dev UI Config Editor, making it vulnerable to drive-by localhost attacks that could lead to RCE, Beeton wrote in a blog post published Nov. 29. Moreover, "exploiting the vulnerability isn’t difficult, and can be done by a malicious actor without any privileges," he noted in the post.

Beeton discovered the vulnerability some weeks ago while preparing a talk for the recently held DeepSec conference, but says that he waited to disclose his findings until after Red Hat published details of the flaw on its customer support portal Nov. 21. Beeton also published a proof of concept exploit for CVE-2022-4116 in his post.

Patched versions of Quarkus, available now, are 2.14.2.Final and 2.13.5.Final (LTS); anyone using the framework is encouraged to update immediately.

**'Dangerous' Security Flaw**

The vulnerability affects the "quarkus\_dev\_ui" package, according to Red Hat, which means it impacts developers building services using Quarkus, not actual services running in production.

However, it's still dangerous for several reasons — for one because it's fairly easy to exploit, and for another because developers often have direct access to an enterprise's production environment, Beeton tells Dark Reading.

"Developers generally have access to production systems, and even if they don't, they do have the ability to make code changes," he says. "A compromised developer's machine could be leveraged to push malicious code changes to production.”

For example, if a developer running Quarkus locally visits a website with malicious JavaScript, that JavaScript can silently execute code on the developer’s machine, which can lead to all kinds of trouble on any network or assets attached to it.

In enterprise cloud-based environments, developers also often have to code bases, Amazon Web Services keys, server credentials, and other assets, Beeton said in his posting.

"Access to the developer's machine gives an attacker a great deal of scope to pivot to other resources on the network, as well as to modify or to flat-out steal the codebase," he wrote.

**The Bug in a Cloud-Security Context**

The flaw must be understood in the context of cloud-based footprints that have numerous hosted services running in a larger environment, Beeton explained. One misconception about this type of architecture is that "services that are only bound to localhost are not accessible from the outside world," he noted in his post.

"Because of this misplaced belief, developers, for the sake of convenience, will run services they are developing that are configured in a less secure way compared with how they would \[typically\] do it," he wrote.

There's no problem with this scenario in the case of accessing normal JavaScript in a browser and loaded from a nonmalicious domain, he said. In that case, the JavaScript would not be able to make requests to other domains, including localhost, without a preflight request that is used to check the server's Cross-Origin Resource Sharing (CORS) settings. This is a standard check to see if the server allows requests from the domain being accessed.

However, in the case of a certain type of request that does not require a preflight request — called Simple Requests — the flaw comes into play, Beeton said.

"For a Simple Request, the browser makes the request, receives the response, but that data — including the HTTP Status Code — is not returned to JavaScript," he wrote. "It is possible, however, to infer whether the request was successful based on how long it took to return. Within those constraints, it is possible to access localhost and, in certain circumstances, to trigger arbitrary code execution."

**Multiple Ways Developers Can Be Targeted**

If this is the case, threat actors can compromise websites that developers use by injecting malicious JavaScript into ads served on the sites. For an attack on the Quarkus flaw to be successful in this scenario, someone who is running Quarkus in developer mode would have to visit a website containing the malicious JavaScript, Beeton said.

In this way, attackers can access developer code via non preflighted HTTP requests to those services bound to localhost, he explained.

"It just requires that Quarkus is running in developer mode at the same point the browser tab is open," he noted. "No other interaction is required for this vulnerability to be exploited."

Attackers also can exploit the flaw by launching a phishing attack that convinces a developer to open a web browser on a compromised page. "If they happen to be running Quarkus in developer mode, compromising them would merely entail getting them to click the link; the page containing malicious JavaScript will then be loaded, and they would be compromised," Beeton explained.

Other ways the flaw can be exploited are through common misconfigurations in the Spring framework, which provides a comprehensive programming and configuration model for modern Java-based enterprise applications, he said. Alternatively, an attacker can exploit known vulnerabilities to generate an RCE on the developer's machine or on other services on their private network.  

**Potential Impact and Fix**

There are two bits of good news surrounding the status of the flaw, Beeton acknowledged. One is that Red Hat's Quarkus team, as mentioned before, already has issued a fix that requires the Dev UI to check origin headers for "origin : localhost" — which is set by the browser itself and not modifiable by JavaScript — and only accept these requests, he said.

The other reassuring aspect is that Quarkus is a young framework, having been launched in 2019, so it's not likely to be used as extensively as, say, the open-source Spring Boot framework, he said.

And while Quarkus is gaining in popularity, particularly for Kubernetes enthusiasts, "given its ease of use and significantly lighter demand on hardware resources to run and to run applications," it still is not as widely used as Kubernetes itself, Beeton said.

"Therefore, the number of developers affected by this drive-by localhost attack is probably small," he said.

**Squashing the Attack Vector**

Even with the Quarkus flaw fixed, developers using open-source frameworks still should be wary as they develop services via the localhost, as there are likely more vulnerabilities equivalent to CVE-2022-4116 that have yet to be found, Beeton warned.

A solution for the entire attack vector is on the horizon with W3C’s new Private Network Access (PNA) specification, which eventually will be integrated into browsers to squash this mode of exploit altogether, he said.

Currently, however, only the team supporting the Chromium framework — the basis for the Chrome and Edge browsers — is actively working to implement the new spec, Beeton said. In fact, the targeted mid-December release of Chrome 109 should include support for PNA.

Firefox, meanwhile, has PNA support on its backlog, but has not yet scheduled a release date, while plans to add the spec to Safari or Edge remain unclear, though the Chromium update may bode well for its upcoming addition in Edge, he added.

Critical Quarkus Flaw Threatens Cloud Developers With Easy RCE

A malicious Android SMS application found on the Google Play Store has been found to stealthily harvest text messages with the goal of creating accounts on a wide range of platforms like Facebook, Google, and WhatsApp.
The app, named Symoo (com.vanjan.sms), had over 100,000 downloads and functioned as a relay for transmitting messages to a server, which advertises an account creation service.

A malicious Android SMS application found on the Google Play Store has been found to stealthily harvest text messages with the goal of creating accounts on a wide range of platforms like Facebook, Google, and WhatsApp.

The app, named Symoo (com.vanjan.sms), had over 100,000 downloads and functioned as a relay for transmitting messages to a server, which advertises an account creation service.

This is achieved by using the phone numbers associated with the infected devices as a means to gather the one-time password that's typically sent to verify the user when setting up new accounts.

"The malware asks the phone number of the user in the first screen," security researcher Maxime Ingrao, who discovered the malware, said, while also requesting for SMS permissions.

"Then it pretends to load the application but remains all the time on this page, it is to hide the interface of the received SMS and that the user does not see the SMS of subscriptions to the various services."

Some of the major services illegally signed up using the phone numbers include Amazon, Discord, Facebook, Google, Instagram, KakaoTalk, Microsoft, Nike, Telegram, TikTok, Tinder, Viber, and WhatsApp, among others.

Additionally, the data collected by the malware is exfiltrated to a domain named "goomy\[.\]fun," which was previously used in another malicious application called Virtual Number (com.programmatics.virtualnumber) that has since been removed from the Play store.

The app's developer, Walven, has also been linked to another Android app known as ActivationPW - Virtual numbers (com.programmatics.activation) that claims to offer "virtual numbers to receive SMS verification" from more than 200 countries for less than 50 cents.

According to Ingrao, Symoo and ActivationPW represent the two ends of the fraudulent scheme, wherein the phone numbers of the hacked devices that have the former installed are employed to help users buy accounts through the latter.

Google told The Hacker News that the two apps have been removed from the Play Store and that the developer has been banned.

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

This Malicious App Abused Hacked Devices to Create Fake Accounts on Multiple Platforms

A malicious Android SMS application discovered on the Google Play Store has been found to stealthily harvest text messages with the goal of creating accounts on a wide range of platforms like Facebook, Google, and WhatsApp.

The app, named Symoo (com.vanjan.sms), had over 100,000 downloads and functioned as a relay for transmitting messages to a server, which advertises an account creation service.

This is achieved by using the phone numbers associated with the infected devices as a means to gather the one-time password that's typically sent to verify the user when setting up new accounts.

"The malware asks the phone number of the user in the first screen," security researcher Maxime Ingrao, who discovered the malware, said, while also requesting for SMS permissions.

"Then it pretends to load the application but remains all the time on this page, it is to hide the interface of the received SMS and that the user does not see the SMS of subscriptions to the various services."

Some of the major services illegally signed up using the phone numbers include Amazon, Discord, Facebook, Google, Instagram, KakaoTalk, Microsoft, Nike, Telegram, TikTok, Tinder, Viber, and WhatsApp, among others.

Additionally, the data collected by the malware is exfiltrated to a domain named "goomy\[.\]fun," which was previously used in another malicious application called Virtual Number (com.programmatics.virtualnumber) that has since been taken down from the Play Store.

The app's developer, Walven, has also been linked to another Android app known as ActivationPW - Virtual numbers (com.programmatics.activation) that claims to offer "virtual numbers to receive SMS verification" from more than 200 countries for less than 50 cents.

According to Ingrao, Symoo and ActivationPW represent the two ends of the fraudulent scheme, wherein the phone numbers of the hacked devices that have the former installed are employed to help users buy accounts through the latter.

Google told The Hacker News that the two apps have been removed from the Play Store and that the developer has been banned.

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Expect to see attackers expand their use of current consumer-targeting tactics while exploring new ways to target Internet users — with implications for businesses.

A combination of maturing and emerging consumer-facing cyber threats could add to the many challenges that enterprise security teams will need to contend with in 2023.

Researchers at Kaspersky, looking at how the cyber threat landscape will likely evolve over the next year, expect that threat actors will expand use of many of their current tactics while exploring new avenues for attack via social media, streaming services, and online gaming platforms.

For business admins, the expansion of brands into the world of the metaverse (the theoretical universal and immersive virtual world of the Internet, facilitated by the use of virtual reality and social media) could open them up to attack. And in the era of remote work and bring-your-own-device (BYOD), any consumer threat is potentially an enterprise one, so IT security teams would do well to follow the trends in this space.

**Attacks Using Current Techniques Will Grow...**

The security vendor for example expects that cybercriminals will continue to take advantage of the post-pandemic surge in consumer interest around online streaming services to try to distribute malware, steal data, and execute other malicious activity.

Many of the attacks will target individuals looking for alternate sources for downloading a legitimate streaming app, or a particular episode of a show. Expect to see cybercriminals use widely anticipated titles and streaming service provider names such as Netflix, Hulu, and Amazon Prime Video as lures to get users to download malware or to direct them to phishing sites, according to Kaspersky.

Consumers will also face more gaming subscription fraud and scams that involve online currencies and artifacts. Attackers will primarily target games that use currencies and allow sale of in-game items and boosters because they give threat actors a way to process money obtained from other illegal activities.

In a report earlier this year, Kount, an Equifax-owned fraud protection service, also identified online currencies as offering a plethora of opportunities for adversaries to launder money and carry out payment card fraud. "For example, a fraudster creates a free account for an online multiplayer game then uses stolen credit cards to fill up the account with in-game currency and skins," Kount researchers had noted, adding, "Once the account is loaded, the fraudster sells it on a trading site," for anywhere between several hundreds to several thousands of dollars.

Kaspersky expects that attackers will also try to exploit a continuing shortage in the availability of popular gaming consoles via fake pre-sale offers as well as fraudulent giveaways and discounts from online stores purporting to sell hard-to-find consoles.

**...Even as Threat Actors Explore New Attack Avenues**

Meanwhile, the metaverse, online education platforms, and certain categories of health-related apps will all become new avenues for attack in 2023, Kaspersky said.

Privacy will emerge as a major concern in the metaverse, Kaspersky predicted. "As the metaverse experience is universal and does not obey regional data protection laws, such as GDPR, this might create complex conflicts between the requirements of the regulations regarding data breach notification," Kaspersky said.

Others have also expressed concern over the increased amount of personal information that will be collected in fully immersive environments via VR headsets and their collection of cameras, microphones, and motion trackers. Many expect the data will reveal a lot about a user's location, appearance, and other private information while also enabling attackers to carry out more sophisticated phishing and social engineering scams.

At least some of the attacks in virtual reality and augmented reality environments will involve virtual abuse and sexual assault — such as that involving cases of avatar rape, Kaspersky said.

The security vendor pointed to an incident where an avatar associated with a researcher at a nonprofit advocacy group was raped on a metaverse platform owned by Meta as one example of the kind of issues consumers can increasingly run into.

Despite efforts by technology companies to build protection mechanisms into metaverses, "virtual abuse and sexual assault will spill over into metaverses," Kaspersky said. "As there are no specific regulation or moderation rules, this scary trend is likely to follow us into 2023."

"The metaverse represents an area where consumer threats will be different from years past," says Anna Larkina, a security expert at Kaspersky. "Fake, malicious VR and AR apps, as well as privacy risks and potential abuse associated with this new frontier, will account for threats we haven't necessarily seen before," she says.

Certain kinds of apps — such as those related to meditation or those where a consumer might offer a hint of their current emotional state — could become another new attack avenue, Larkina says.

"It is easy enough to imagine a variety of applications for meditation, in which you indicate your current state/emotions, and they select the appropriate course for you," she explains. "Such data can easily be collected and stored in order to track the state of the user and offer them suitable meditation practices." An attacker that gains access to such data could execute successful spear-phishing and social engineering scams in a highly targeted manner, she notes.

Attacks targeting consumers should matter to enterprise security teams because attacks on companies quite often involve the human factor, Larkina says. "If the system is technically secure enough, then you can get inside the system by 'hacking' employees of the company."

The Metaverse Could Become a Top Avenue for Cyberattacks in 2023

The enterprise's shift to the cloud means digital forensics investigators have had to adopt new remote techniques and develop custom tools to uncover and process evidence off compromised devices.

With more organizations moving to the cloud for storage, applications, and processing, digital forensics investigators increasingly require new tools and techniques capable of conducting investigations on systems where they have no physical access.

Gone, for the most part, are the days when the forensics investigator could pop out the hard drive of an on-premises server for a forensic image and simply analyze it for clues on what happened. Hands-on evaluations of physical evidence, formerly the norm in forensic investigations, are now the exception. Today’s cloud-based network could be located almost anywhere — for European Union cloud infrastructures, servers generally have to be in the same country as where the data was created, but that’s as specific as the law gets. For the most part, investigators have no direct access to the servers.

Instead, companies need to work with their cloud providers in advance to articulate clearly what access they can have before an event occurs, says Thomas Brittain, former managing director of cyber risk at Kroll who recently joined Amazon Web Services as a security leader for cloud response.

For example, ask the cloud provider up front about any limitations during an investigation, Brittain recommends. Questions include: What logging or log sources are available from each of your cloud vendors? How do you ensure that your personnel have the training and the understanding to do an investigation in that cloud environment?

Considering that investigators will not have physical access to compromised disk drives, enterprises need to ensure ahead of time that the investigators will have the ability to obtain a forensic image of the hard disk even without having actual physical access. That may mean the provider’s staff would need to create and provide the image to the investigators, or the provider would allow the investigators virtual access to the compromised devices.

**Cloud-Ready Forensics Tools**

New digital forensics tools and techniques are necessary to uncover electronic evidence for processing into actionable intelligence for cloud-based data breaches, ransomware attacks, and other cases of malfeasance.-

Because there are no standardized tools designed to meet every cloud vendors’ network needs, many forensics teams develop custom applications. But there is still a problem. “It's insane, trying to figure out standardized training, there is no, there are no standardized tools,” Brittain says.

“We've had to adapt from more of a forensic standpoint to more of a live-by-instant-response in triage,” concurs Aaron Crawford, senior security consultant with NCC Group’s North America Incident Response. “The lines between triage and forensics have absolutely blurred with the introduction of the cloud. It's even more complicated because you have several flavors of clouds out there and providers such as Tencent, Google, Amazon, and Microsoft — the primary Big Four out there.”

Crawford also acknowledges the lack of industry-standard tools. “We've had to become our own tool smiths now. We've had to write our own tools \[and\] create our own custom solutions to address a lot of these issues to help relieve the burden for our clients,” he says. “One of the biggest things that's changed is that immediacy for information and updates is absolutely critical. And that's because the threat landscape changed. The threat landscape got significantly more malicious, and the repercussions are even greater than they were before.”

While forensics teams are creating tools for the various environments, they also need to ensure that their tools will interoperate with existing security tools. Custom tools need to be “sustainable, explainable, \[and\] repeatable. If I go to court as an expert witness, I have to make sure that those tools are repeatable, and you can understand them, and someone else other than me can use them.”

Wayne Johnson, director of Global Cyber Incident Response and leader of the forensics practice at Protiviti, also sees challenges and possibilities with custom forensic tools. “From an interoperability perspective, I think that's incumbent on those that are that are making those one-off tools, \[that\] as the different coding languages change, as the different coding capabilities increase, the digital forensics domain has to be able to move with them right and be able to understand those," he says.

“Even with traditional architectures that are that are on-prem, there are many organizations that still have their own custom code and custom applications. So be those in the cloud or on prem., the same concept applies.”

**Soliciting Board Support**

As the attack surface grows, in part due to the explosion of internet of things (IoT) devices, cybersecurity experts need a place at the table with the board of directors and general counsels, Johnson notes. Ultimately, combining the digital forensics capabilities with incident response is “an area where we've really seen the board's taking notice and realizing that there's definitely a conversation there.”

The added benefit to having a cyber-savvy board member is to help the other board members “understand and interpret what’s coming from the CISO and the CIO.” The addition of cybersecurity experts on the board, combined with a cyber-knowledgeable general counsel, will further bolster the board’s understand on what cybersecurity and forensics can do to protect corporate assets.

“I think we're seeing, we're seeing a much more sophisticated and cyber-savvy boards starting to emerge as you start looking across various industries,” Johnson says.

How the Cloud Changed Digital Forensics Investigations

The /device/acceptBind end-point for Ourphoto App version 1.4.1 does not require authentication or authorization. The user_token header is not implemented or present on this end-point. An attacker can send a request to bind their account to any users picture frame, then send a POST request to accept their own bind request, without the end-users approval or interaction.

CVE-2022-24190: Automating Unsolicited Richard Pics; Pwning 60,000 Digital Picture Frames

BYOK was envisioned to reduce the risk of using a cloud service provider processing sensitive data, yet there are several deficiencies.

Let’s start with some basics: Your data can, and should, be encrypted at rest and in motion.

Data can be encrypted on the client side or on the server side. In the security realm, we have well-known best practices, which include defense in depth (i.e., not relying on a single security protective measure), and security by obscurity, which really isn’t security.

Here's what the cloud industry is doing, along with some underlying gaps. Most cloud service providers (CSPs) offer bring your own key (BYOK) in one way or another. Amazon Web Services, for instance, supports the following key management service (KMS) options:

*   **KMS only:** Customer-managed keys (CMKs) stored in the KMS.

*   **KMS with customer key store and CMK:** Again, managed by the customer and stored in the cloud hardware security module (HSM ).

*   **KMS with third-party HSM:** Customer-provided KMS with a direct connection to the KMS.

The keys are retained in the volatile KMS memory, meaning once the data encryption keys (DEKs) are decrypted, they are accessible within the CSP environment without requiring the key encrypting key (KEK) for each decryption or encryption.

In all implementation options listed, the data encryption keys are generated by the CSP's KMS and may or may not be exportable. The DEK is used to encrypt defined scopes of data (e.g., per bucket, day, file, etc.) and these DEKs are encrypted with the KEK.

**BYOK Benefits and Risks**

BYOK is meant to provide cloud customers more control over their hosted data. In reality, when BYOK is used, it actually works more like share your own key (SYOK), since once the key is provided to the CSP, customers have no control over the key use. The only benefit of SYOK, in my view, is ensuring the key randomness if you don't trust their random number generator. Otherwise, you may as well let the CSP generate the key.

BYOK is also offered by some CSPs in another model and connects to the customer’s hardware, which stores and controls the KEK. There are several outstanding issues with this model.

The DEKs may still be accessible to the service provider, purposely or otherwise, in addition to a malicious actor capable of succeeding in breaching the CSP's protective measures technically, or via social engineering, thus gaining access to the DEKs, whether in memory, cache, log files, or a malicious codebase. Retaining the KEK in memory is a double-edged sword, since you're effectively performing SYOK for better performance. But then why not just perform SYOK, in that case?

Another issue is that the service provider may not use the customer KEK to secure the DEK. And the CSP architecture, code, and various offerings may have security lapses that allow interception points. Even if DEKs are decrypted on the fly, which isn't usually supported or recommended, a communication issue could bring your business to a grinding halt, preventing existing data from being decrypted and new DEKs from being encrypted.

Trust is also a key element when working with a CSP. Trust should stem from certifications and third-party audits. Reference customers using the CSP for their sensitive data or production may also be an important factor in strengthening this trust. You also have to decide if you trust the CSP's authentication and authorization security. Even with federated security, that doesn't mean there aren't additional authentication and privilege escalation means.

In short: BYOK does not solve the problem nor reduce the risk!

**What Else Can We Do?**

Most CSPs offer customers self-service capabilities to revoke, rotate, and otherwise control the KEK. Enhanced security may be achieved by protecting the data prior to moving or granting the CSP access to it. But this is rarely beneficial and mostly recommended for securing PII/PHI or other strongly regulated data.

The most important factor is to consider all ingress and egress routes, including APIs and file transfers, as well as various privileged access needs. This also extends to authentication and authorization that uses role- or attribute-based access control to ensure non-repudiation, data sanitation, and industry best practices like zero trust**.**

****The Bottom Line****

My goal here is to raise awareness, not to reflect negatively on CSPs. But BYOK, for the most part, is snake oil. It’s often misunderstood as a panacea to working in the cloud while not requiring trust for the CSP.

SYOK is worthless. If you assume the CSP cannot generate sufficiently random keys for the KEK, why rely on it for the DEK? It's important to ensure there’s a well-designed security architecture in place that is constantly reassessed, tested, and monitored.

Tag

#amazon