IT has to get its hands around cloud data sprawl. Another area of focus should be on ghost data, as it expands the organization's cloud attack surface.

Cloud sprawl is a big issue for organizations, with business teams to spinning up cloud systems and services on their own, often without IT oversight. That leads to cloud data sprawl as data is scattered across different environments. If IT doesn’t know about the cloud systems and services, then IT is also not managing the data being collected, processed, and stored there.

We all know about shadow IT, the systems and network devices in the organization’s environment that IT is not managing. Similarly, shadow data refers to unmanaged data store copies and snapshots or log data not part of IT’s backup and recovery strategy. Researchers at Cyera estimate that 60% of the data security posture issues present in cloud accounts stem from unsecured sensitive data.

Then there is the problem of ghost data.

When data gets deleted from cloud systems, it isn’t fully gone. Copies linger in backups or snapshots of data stores. Ghost data refers to those copies left behind after the original has been deleted, and Cyera’s recent analysis show that enterprises have quite a lot of it.

After scanning the three major cloud providers (Amazon Web Services, Azure, and Google Cloud), Cyera researchers found that over 30% of scanned customer cloud data stores are ghost data and more than 58% contain sensitive, or very sensitive, data. For example, researchers found unsecured database snapshots in non-production environments that contained sensitive customer data where the original database had been destroyed. Researchers also uncovered sensitive personal and authentication data in plain text where the production data and application were no longer in use.

Ghost data usually has no business value – the data was deleted for a reason -- and having it around unnecessarily increases business risk. Attackers don’t care if they get their hands on the original sensitive information or the copy because to them, all data has value, regardless of the form it takes. Organizations still are on the hook if the attackers get their hands on ghost data. The data security provisions of industry-specific regulations like HIPAA, PCI DSS, and the Sarbanes-Oxley Act still apply.

Organizations need to reduce cloud data exposure to reduce data sprawl. Proper data hygiene across clouds will also help clean up data when it is no longer in use.

On a final note, ghost data can increase the organization’s cloud costs: Researchers found over $50,000 in excess data store snapshots being retained in a cloud environment.

Ghost Data Increases Enterprise Business Risk

Neopets has confirmed that its IT systems were compromised from January 2021 through July 2022, exposing 69 million user accounts and source code.

Neopets has released an "Important Announcement" urging its members to update their passwords and confirming that the company's IT systems were compromised.

Neopets is a game that lets players create, and care for, virtual pets inside a fantasy world.

"It appears that email addresses and passwords used to access Neopets accounts may have been affected," the company explained. "We strongly recommend that you change your Neopets password."

The admission comes just weeks after a cyberattacker was reportedly shopping a stolen Neopets database with 69 million member records and the Neopets source code for four bitcoin (which is currently worth less than $80,000, and falling).

The company confirmed that it learned about the attack on the same day the data was put up for sale, July 20.

Compromised Neopets member information includes names, email addresses, usernames, dates of birth, gender, IP addresses, Neopets PINs, and hashed passwords, as well as data generated during game play.

"As part of our ongoing commitment to the safety and privacy of the Neopets' player information in our care, we have reset players' passwords and are working on adding multifactor authentication to better safeguard your account access," Jim Czulewicz, president and CEO of Neopets owner JumpStart Games, said in a statement.

He added, "We have also enhanced the protection of our systems, including by further strengthening our network monitoring, authentication, and system protection."

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

Neopets Hackers Had Network Access for 18 Months

"JuiceLedger" has escalated a campaign to distribute its information stealer by now going after developers who published code on the widely used Python code repository.

Security researchers have identified a previously unknown group dubbed "JuiceLedger" as the threat actor behind a recent and first-known phishing campaign specifically targeting users of the Python Package Index (PyPI).

The threat actor first surfaced early this year and is focused on distributing a .NET-based malware called JuiceStealer for searching and stealing browser and cryptocurrency-related information from infected systems.

Initially, JuiceLedger distributed the information stealer via fraudulent Python installer applications. But starting in August, researchers from SentinelOne and Checkmarx observed the attacker also engaged in attempts to poison Python packages on the PyPI repository — presumably to distribute its malware to a wider audience.

The threat actor's modus operandi has involved targeting PyPI users with a phishing email informing them about Google implementing a new validation process for packages published on PyPI. The email claimed the measure was in response to a big increase in malicious PyPI packages getting uploaded to the registry. It warned developers to expeditiously validate their code packages with Google to avoid having them removed from the registry. "Packages not validated before September will be removed promptly," the phishing email noted.

PyPI users who clicked on the link were directed to a webpage, spoofed to look exactly like PyPI's login page. When users entered their credentials there, the page was designed to send that information to a JuiceLedger-controlled domain (linkedopports\[dot\]com). The caper appears to have convinced at least two developers to part with their credentials, which gave JuiceLedger a way to access and poison their relatively widely used PyPI packages with malicious code.

One of the infected packages (version 0.1.6 of "exotel"), for instance, had more than 480,000 total downloads at the time it was infected. The other package (versions 2.0.2 and 4.0.2 of "spam") had some 200,000 downloads. PyPI administrators have since removed both packages, according to Checkmarx.

When installed in a development environment, the code can search for Google Chrome passwords, query Chrome SQLite files, and launch a Python installer contained in the zip named “config.exe," SentinelOne said. The infostealer also looks for logs that contain the word "vault," likely because it is searching for cryptocurrency vaults, and reports the information back to an attacker-controlled command-and-control server over HTTP.

**Broad Campaign**

PyPI admins have also removed "several hundred" typosquatted packages that JuiceLedger published to PyPI as part of a broader effort to distribute its infostealer via the popular Python code repository, both SentinelOne and Checkmarx noted. Their analysis showed the threat actors had inserted a short code snippet in the packages for retrieving a signed variant of JuiceStealer from an attacker-controller URL and executing it.

The code in the typosquatted packages was similar to the code that JuiceLedger had inserted into the two legitimate code packages via its phishing campaign. The attacker-controlled URL that the typosquatted packages communicated with was also the same as the same the one that the poisoned versions of "exotel" and "spam" packages communicated. This allowed researchers at SentinelOne and Checkmarx to conclude JuiceLedger was responsible for both, the PyPI phishing campaign and for uploading the typosquatted packages to PyPI.

JuiceLedger's attack on PyPI in August represents a dangerous escalation in the threat actor's efforts to distribute its information stealer, SentinelOne said. "In August 2022, the threat actor engaged in poisoning open-source packages as a way to target a wider audience with the infostealer through a supply chain attack, raising the threat level posed by this group considerably."

**Popular — but Not the Only — Target**

PyPI recently has become a popular target for attackers trying to poison software supply chains. Countless organizations use the code published in the repository to build their applications. So, by poisoning packages on the registry, attackers can potentially reach a wide audience with relatively little effort. Recent examples include threat actors inserting malicious package installation code in 10 packages published to PyPI, another incident where some 300 developers inadvertently downloaded a package for installing Cobalt Strike from the registry and one where a school-age hacker uploaded ransomware to the registry to see what would transpire.

PyPI is by far not the only code repository that attackers have targeted recently. Security vendors have reported numerous similar incidents involving other widely used registries such as npm and Maven Central. The trend has heightened attention on software supply chain security issues, especially because of the potential for nation-state backed adversaries — like the Russian threat actor behind the SolarWinds compromise — exploiting the same tactic in their attack campaigns.

Attackers are taking advantage of the fact that developers and organizations will always need to use open source packages, says Amitai Ben, threat intelligence researcher at SentinelOne.

The best way to minimize exposure for those contributing open source code to public repositories is to enable two-factor authentication (2FA) on their user account in package managers. That minimizes the risk of account takeover by malicious actors.

Users of open source packages, meanwhile, need to know that popular packages are often connected to Git repositories from which the development process is taking place. "Discrepancies between the repository and the package on the package manager can be a sign of suspicious activity and account takeover," Ben says.

Threat Actor Phishing PyPI Users Identified

The expanding Internet of Things ecosystem is seeing a startling rate of vulnerability disclosures, leaving companies with a greater need for visibility into and patching of IoT devices.

Rising numbers of documented security issues in Internet of Things (IoT) devices mean that businesses have a new patch management issue brewing, cybersecurity, experts say.

A combination of more connected products, greater scrutiny by researchers, and regulations requiring disclosure of vulnerabilities has resulted in a rising tide of disclosed bugs. Those found in products considered to be part of the Extended Internet of Things (XIoT), for example, jumped 57% in the first half of the year, compared with the prior six months, Claroty stated in a recent report.

Embedded IoT devices have meanwhile jumped to account for 15% of the XIoT vulnerabilities, up from 9% in the second half of 2021.

This rapidly expanding landscape of IoT devices and infrastructure means that companies need to ensure visibility, not only into their IoT devices, but all the systems that manage those devices, and be ready to quickly patch those devices, says Sharon Brizinov, director of research for Claroty.

"The networks \[have become\] much more diverse than ever before, and that goes hand-and-hand with the fact that more security researchers are looking for vulnerabilities than ever before," he says. "So, more devices and more awareness and more security researchers investigating those devices means more vulnerabilities being disclosed."

    

XIoT vulnerability classified by embedded IoT, medical IoT, IT, and OT categories. Source: Claroty

This trend is only set to continue, according to experts. Companies will need to keep track of their IoT assets and, because vulnerability remediation typically requires a software update, evaluate whether deployed devices can easily be updated.  

Fewer vendors are trying to hide their security issues and are moving away from silent patching — a good development for security but one that contributes to the "noticeable increase" in the number of IoT vulnerabilities being publicly disclosed, says Deral Heiland, principal security researcher for IoT at Rapid7.

"If no data is made available to the public, then end users can't be aware of a potentially serious risk caused by a vulnerability and may delay patching," he notes. "So, vendors publishing in this way is a positive move."

**Growing Number of XIoT issues**

Overall, 747 vulnerabilities were disclosed in XIoT devices between the start of January and the end of June, a 57% jump from the prior six months, according to Claroty's "State of XIoT Security: 1H 2022" report. The affected products came from 86 different vendors, and for the first time, proactive disclosure by vendors became the second most common way that information on vulnerabilities was published, after disclosure by third-party firms. Independent researchers and the Zero Day Initiative were the third and fourth most common sources of vulnerability information.

Vendors as a group are not necessarily better at security — the numbers are driven by a few major firms, such as Siemens, that have implemented strong security programs, says Claroty's Brizinov. Siemens represented the top disclosure of XIoT vulnerabilities, at 214, with the second being Reolink at 87, followed by Schneider at 52, according to Claroty's report.

"There were some business decisions that led to this result — some decisions makers that decide to come clean," he says. "They understand that it is an important piece of information."  

Different initiatives have also fueled the rising rate of disclosures. The Internet of Things Cybersecurity Improvement Act of 2020 has put pressure on companies that provide IoT products to the government, while a consumer-focused program for creating security "nutrition labels" for IoT devices will likely drive consumers toward more security-conscious products.

**A Moving Definition of the Internet of Things**

Vulnerability-intelligence firm Risk Based Security, now part of Flashpoint, has also noted an increase in the number of security issues in products that could be considered part of the IoT ecosystem. The company, however, has stressed that the lack of a good definition for IoT devices makes it difficult to track the category.

Industrial monitoring devices, medical imaging equipment, IP video cameras, and electronic door locks are all connected to the Internet and allow digital communications to have impacts on the physical world. In its 2020 publication, "Foundational Cybersecurity Activities for IoT Device Manufacturers," the US National Institute of Standards and Technology (NIST) defined IoT devices as those that "have at least one transducer (sensor or actuator) for interfacing directly with the physical world and at least one network interface ... for interfacing with the digital world."

Claroty calls the category the Extended Internet of Things, and puts devices from medical, industrial, and commercial applications under one umbrella. The company has acknowledged that the products included in the XIoT category may not have been there last year because new devices have been released, connectivity added to previous products, and as new products push the definition of IoT.

For instance, as manufacturing, critical infrastructure, and city management have adopted connected devices, Siemens and other operations technology (OT) companies have transformed their products from industrial control systems to industrial IoT, cybersecurity has become a critical part of that transformation, Claroty's Brizinov says.

"In the past, there was a distinct separation between IT and OT — we could circle those domains and they would be separate," he says. "And then came IoT, and those circles intersected so there were some devices in both IT and OT."

Another growing aspect of IoT is mobile devices, such as smartphones and tablets. Many companies use mobile devices as a way to monitor and control their network of IoT devices, which means that the device is not the only component of the IoT ecosystem, but mobile devices and back-end servers must also be included.

For that reason, Rapid7 considers cloud components and management software to be part of the ecosystem.

"Typically, a mobile device as a standalone device would not be considered IoT," says Rapid7's Heiland. "When running software designed to interact, control, and/or manage an IoT solution, it does become part of the IoT products ecosystem and should be considered when evaluating the security of the IoT product."

Skyrocketing IoT Bug Disclosures Put Pressure on Security Teams

The proposed AMTSO guidelines offer a roadmap for comprehensive testing of IoT security products.

The Anti-Malware Testing Standards Organization (AMTSO) unveiled a list of proposed publishing standards for testing the efficacy of IoT security solutions.

AMTSO’s guidelines are intended to help organizations evaluate which tools are most effective and best suited to their environment. The document outlines six key areas:

*   **General principles:** All tests and benchmarks should focus on validating the end result and performance of protection delivered, instead of how the product functions on the backend.
*   **Sample selection:** For a relevant test of IoT security solution benchmarking, testers need to select samples that are still active, and that actually target the operating systems smart devices are running on.
*   **Determination of "detection":** Because of the differences between IoT security and traditional cybersecurity solutions, the guidelines suggest to use threats with admin consoles that can be controlled by the tester or to use devices where the attack will be visible if it happens.
*   **Test environment:** If the tester decides against using real devices in the testing environment, they should validate their approach by running their desired scenario with the security functionality of the security device disabled and checking the attack execution and success.
*   **Testing of specific security functionality:** The guidelines provide advice on different attack stages, including reconnaissance, initial access, and execution, and suggest testing each stage individually rather than going through the whole attack at once.
*   **Performance benchmarking:** The guidelines suggest differentiating between various use cases such as consumers vs. businesses, or the criticality of latency or reduced throughput per protocol, which depends on its purpose.

There's a lot of diversity in IoT devices, making it difficult to create a one-size-fits-all approach to security, says Tony Goulding, cybersecurity evangelist at Delinea. Some devices lack computational capacity, and not being able to deploy security agents or clients on the devices makes it difficult to enforce a centralized and consistent set of security policies.

"Threat actors recognize this and exploit the fact that these devices are particularly vulnerable to malware," he says. "As a security community, we strive to eliminate or choke vectors of attack that can give adversaries illicit access to our infrastructure, resulting in a data breach, ransomware attack, or taking critical OT infrastructure offline."

Industry regulations like PCI, HIPAA, and SOX focus on security and privacy guidelines in order to protect access to sensitive data and systems in traditional IT environments, Goulding says. Organizations should prioritize IoT products from vendors who have undergone such testing to help ensure such risks are mitigated in their product.

"Similarly, it's important to protect access to IoT devices that are used in sensitive environments," he says. "With no equivalent set of regulations, the AMTSO guidelines represent a step in the right direction to help IoT vendors test their products' ability to detect and prevent attacks."

**Secure IoT Critical for Organizations**

Many cybercriminals target IoT devices as their point of entry because they enable lateral movement within corporate networks, says Bud Broomhead, CEO at Viakoo. While security for vulnerable IoT devices is critically important for enterprises, the fact remains that IoT devices often lack automated methods for patching vulnerabilities, updating the firmware and digital certificates, or changing built-in passwords.

"Breached IoT devices are having devastating impacts, such as ransomware, data loss, changing the chemical balance in a municipal water supply, replacing real camera footage with deepfakes, or disrupting transportation systems," he says.

Because devices are so distributed and often of different makes and models, manually managing device security across multiple locations for cameras, kiosks, intercoms, and other equipment can be very difficult to accomplish at scale.

Goulding says while the proposed guidelines are a step in the right direction, more and stronger standards, widely enforced, are required. There's some progress, with Europe's ETSI EN 303 645 and California's "Security of Connected Devices" law. NIST in the US has pilot programs for cybersecurity labeling of consumer IoT devices.

"Until then, vendors and industry sectors will have different priorities," Goulding says.

New Guidelines Spell Out How to Test IoT Security Products

The insecurities exist in CI/CD pipelines and can be used by attackers to subvert modern development and roll out malicious code at deployment.

A pair of security vulnerabilities discovered in the GitHub environments of two very popular open source projects from Apache and Google could be used to stealthily modify project source code, steal secrets, and move laterally inside an organization.

The issues are continuous integration/continuous delivery (CI/CD) flaws that could threaten many more open source projects around the world, according to researchers at Legit Security, who found them affecting a Google Firebase project and a popular integration framework project run by Apache.

Researchers dubbed the vulnerability pattern "GitHub Environment Injection." It allows attackers to take control of a vulnerable project's GitHub Actions pipeline by creating a specially crafted payload written to a GitHub environment variable called "GITHUB\_ENV." 

Specifically, the issue exists in the way GitHub shares environment variables in the build machine, which can be manipulated to extract information, including the repository ownership credentials.

"The concept is that the build action itself trusts the code that is submitted for review in a way that you don't need anybody to review it," explains Liav Caspi, CTO and co-founder of Legit Security. "The mere fact that somebody makes a contribution tricks the build system into executing something about the code. There is a kind of automated test that runs, and you can make the test execute whatever you put there."

He adds: "The problem there is that anybody that makes a contribution could trigger that without the need for somebody to review it. So, that's very powerful."

**Don't Ignore Security for CI/CD Pipelines**

According to Caspi, his team found the flaws as a part of an ongoing investigation into CI/CD pipelines. With a surge in SolarWinds-style supply chain flaws, they'd particularly been seeking out weaknesses in the GitHub ecosystem, since it's one of the most popular source code management (SCM) systems in the open source world and in enterprise development — and thus a natural vehicle for injecting vulnerabilities into software supply chains.   

He explains that these flaws manifest both a design weakness in the way that the GitHub platform is designed and how different open source projects and enterprises use the platform.

"You could potentially write a very safe build script if you are super aware of the risks and circumvent a lot of risky operations," he explains. "But I think nobody is really aware of that, and there are a couple of mechanisms within GitHub Actions that are very dangerous that are used in everyday build operations."

He says that enterprise development teams should always assume zero trust with GitHub Action and other build systems.

"They should assume that the components they're using to build — whether it is a build plug-in or anything submitted to them — that an attacker could leverage that," he says. "And then they should isolate the environment and also review code in a way that it doesn't execute code submitted for you."

As Caspi explains, these flaws illustrate not only that the open source project itself a potential vector for supply chain vulnerabilities, but so is the code that makes up the CI/CD pipeline and its integration.

Both bugs have been patched.

Code-Injection Bugs Bite Google, Apache Open Source GitHub Projects

Apple continues a staged update process to address a WebKit vulnerability that allows attackers to craft malicious Web content to load malware on affected devices.

Apple has quietly rolled out more updates to iOS to fix an actively exploited zero-day security vulnerability that it patched earlier this month in newer devices. The vulnerability, found in WebKit, can allow attackers to create malicious Web content that allows remote code execution (RCE) on a user's device.

An update released Wednesday, iOS 12.5.6, applies to the following models: iPhone 5S, iPhone 6, iPhone 6 Plus, iPad Air, iPad mini 2, iPad mini 3, and iPod touch 6th generation.

The flaw in question (CVE-2022-32893) is described by Apple as an out-of-bounds write issue in WebKit. It was addressed in the patch with improved bounds checking. Apple acknowledged that the bug is under active exploit, and is urging users of affected devices to update immediately.

Apple had already patched the vulnerability for some devices — alongside a kernel flaw tracked as CVE-2022-32894 — earlier in August in iOS 15.6.1. That's an update that covered iPhone 6S and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation).

The latest round of patches appears to be Apple covering all its bases by adding protection for iPhones running older versions of iOS, noted security evangelist Paul Ducklin.

"We're guessing that Apple must have come across at least some high-profile (or high-risk, or both) users of older phones who were compromised in this way, and decided to push out protection for everyone as a special precaution," he wrote in a post on the Sophos Naked Security blog.

The dual coverage by Apple to fix the bug in both versions of iOS is due to the change in which versions of the platform run on which iPhones, Ducklin explained.

Before Apple released iOS 13.1 and iPadOS 13.1, iPhones and iPads used the same operating system, referred to as iOS for both devices, he said. Now, iOS 12.x covers iPhone 6 and earlier devices, while iOS 13.1 and later versions run on iPhone 6s and devices released after.

The other zero-day flaw that Apple patched earlier this month, CVE-2022-32894, was a kernel vulnerability that can allow for entire device takeover. But while iOS 13 was affected by that flaw — and thus got a patch for it in the earlier update — it does not affect iOS 12, Ducklin observed, "which almost certainly avoids the risk of total compromise of the operating system itself" on older devices, he said.

**WebKit: A Wide Cyberattack Surface**

WebKit is the browser engine that powers Safari and all other third-party browsers that work on iOS. By exploiting CVE-2022-32893, a threat actor can build malicious content into a website. Then, if someone visits the site from an affected iPhone, the actor can remotely execute malware on his or her device.

WebKit in general has been a persistent thorn in Apple's side when it comes to exposing users to vulnerabilities because it spreads beyond iPhones and other Apple devices to other browsers that use it — including Firefox, Edge, and Chrome — putting potentially millions of users at risk from a given bug.

"Remember that WebKit bugs exist, loosely speaking, at the software layer below Safari, so that Apple's own Safari browser isn't the only app at risk from this vulnerability," Ducklin observed.

Moreover, any app that displays Web content on iOS for purposes other than general browsing — such as in its help pages, its _"About"_ screen, or even in a built-in "minibrowser" — uses WebKit under the hood, he added.

"In other words, just 'avoiding Safari' and sticking to a third-party browser is not a suitable workaround \[for WebKit bugs\]," Ducklin wrote.

**Apple Under Attack**

While users and professionals alike have traditionally considered Apple's Mac and iOS platforms as more secure than Microsoft Windows — and this has generally been true for a number of reasons — the tide is beginning to turn, experts say.

Indeed, an emerging threat landscape showing more interest in targeting more ubiquitous Web technologies and not the OS itself has widened the target on Apple's back, according to a threat report released in January, and the company's defensive patching strategy reflects this.

Apple has patched at least four zero-day flaws this year, with two patches for previous iOS and macOS vulnerabilities coming in January and one in February — the latter of which fixed another actively exploited issue in WebKit.

Moreover, last year 12 of 57 zero-day threats that researchers from Google's Project Zero tracked were Apple-related (i.e., more than 20%), with issues affecting macOS, iOS, iPadOS, and WebKit.

Apple Quietly Releases Another Patch for Zero-Day RCE Bug

After a rigorous pilot program, the association's newest certification is officially operational. More than 1,500 pilot participants who passed the exam are on the path to full certification.

**ALEXANDRIA, Va., Aug. 31, 2022 /PRNewswire** -- (ISC)² – the world's largest nonprofit association of certified cybersecurity professionals – today announced a landmark expansion of its membership and the global cybersecurity workforce. With the official launch of the (ISC)² Certified in Cybersecurity℠ certification, (ISC)² is delivering on its commitment to address the global cybersecurity workforce gap by creating new pathways into the profession for those interested in a cybersecurity career. Anyone earning the (ISC)² Certified in Cybersecurity certification demonstrates they have the foundational knowledge, skills, and abilities to take on entry- and junior-level cybersecurity roles, enabling employers to more confidently build resilient teams across all experience levels.

"We are facing a growing global cybersecurity workforce gap of more than 2.7 million people. One of the most persistent cybersecurity staffing challenges organizations around the world experience is being able to identify entry- and junior-level candidates with the right skills and aptitude to learn and grow on the job. At the same time, early career hopefuls are unable to demonstrate their understanding of cybersecurity concepts and gain the attention of hiring managers," said Clar Rosso, (ISC)² CEO. "Our Certified in Cybersecurity certification bridges that gap and connects employers to qualified entry-level candidates backed by the world's largest association of certified cybersecurity professionals. (ISC)² Certified in Cybersecurity is one of several impactful solutions underway at (ISC)² to reduce the cybersecurity workforce gap, remove barriers to entering the field and deliver a positive, long-term opportunity for individuals and employers alike."

**Certifying the Next Generation of the Cybersecurity Workforce**

The (ISC)² Certified in Cybersecurity certification was created to support and nurture a new generation of cybersecurity practitioners entering the field – from recent university graduates to career changers to IT professionals – seeking to validate their security skills and access a new career and professional development pathway.

The (ISC)² Certified in Cybersecurity certification exam evaluates candidates across the following subject areas:

*   Security Principles
*   Business Continuity (BC), Disaster Recovery (DR) & Incident Response Concepts
*   Access Controls Concepts
*   Network Security
*   Security Operations

More details about the exam subject matter are available through the (ISC)² Certified in Cybersecurity exam outline.

Since the (ISC)² Certified in Cybersecurity certification exam pilot program began earlier this year, more than 1,500 individuals have passed the exam and are now beginning their journey to full certification and (ISC)² membership. As members of the association, they will gain access to continuing education, thought leadership, peer support, industry events and other professional development opportunities. (ISC)² supports cybersecurity practitioners in their immediate and future careers as they gain experience and work toward more advanced and specialized certifications, such as the globally renowned (ISC)² CISSP®.

Learn more about the (ISC)² Certified in Cybersecurity certification at www.isc2.org/Certifications/CC.

**About (ISC)²**

(ISC)² is an international nonprofit membership association focused on inspiring a safe and secure cyber world. Best known for the acclaimed Certified Information Systems Security Professional (CISSP®) certification, (ISC)² offers a portfolio of credentials that are part of a holistic, pragmatic approach to security. Our membership, more than 168,000 strong, is made up of certified cyber, information, software and infrastructure security professionals who are making a difference and helping to advance the industry. Our vision is supported by our commitment to educate and reach the general public through our charitable foundation – The Center for Cyber Safety and Education™. For more information on (ISC)², visit www.isc2.org, follow us on Twitter or connect with us on Facebook and LinkedIn.

© 2022 (ISC)² Inc., (ISC)², CISSP, SSCP, CAP, CSSLP, HCISPP, CISSP-ISSAP, CISSP-ISSEP, CISSP-ISSMP and CBK are registered marks, and CC is a service mark of (ISC)², Inc.

SOURCE: (ISC)2

(ISC)² Launches 'Certified in Cybersecurity' Entry-Level Certification to Address Global Workforce Gap

Cloud breaches are inevitable — and so is cloud ransomware. (Second of two parts.)

In Part 1 of our tales of real-world cloud attacks, we examined real-world examples of two common cloud attacks. The first starting from a software-as-a-service (SaaS) marketplace, demonstrating the breadth of potential access vectors for cloud attacks and how it can enable lateral movement into other cloud resources, including a company's AWS environment. The second cloud attack demonstrated how attackers take over cloud infrastructure to inject cryptominers for their profit.

As we have witnessed, more attacks have moved onto the cloud, so it was only a matter of time before ransomware attacks did, too. Let's look at two scenarios where attackers leveraged ransomware to gain profits, and how unique cloud capabilities helped victims avoid paying the ransom.

**MongoDB Ransomware Demand Mitigated**

The first case (or rather cases, as this attack has appeared numerous times) is the notorious MongoDB ransomware, which has been ongoing for years. The attack itself is simple— attackers use a script to scan the internet (and now, common cloud vendor address spaces) for hosts running MongoDB exposed to the internet. The attackers then try to connect to the MongoDB with the empty admin password. If successful, the attack erases the database and replaces it with a double ransomware note: _pay, and your data will be returned; don't pay, and your data will be leaked._

Intervention was necessary to address the second part of the extortion scheme: data leakage. Luckily, the company had data backups, so recovery was easy, but the database contained considerable amounts of personally identifiable information (PII), which, if leaked, would be a major crisis for the company. This forced them into the position of either paying a hefty ransom or dealing with the press. MongoDB default logging, unfortunately, cannot provide a definitive answer regarding the data accessed, as not all potential types of data collection commands are logged by default.

This is where the cloud infrastructure became an advantage. While MongoDB may not log every command, AWS logs the traffic going in and out of servers, because it charges for network costs. Correlating the network traffic going out of the attacked server with the times when the attackers were connected to the compromised MongoDB server provided proof that the data could not have been downloaded by the attackers.

    

AWS traffic log over 10 day period. The marker represents the incident time. Source: Mitiga

This allowed the company to avoid paying the ransom _and_ ignore the threat. As expected, nothing further was heard from the attackers.

**Mitigating Ransomware in a Cloud Environment**

Another company experienced an attack on its main servers running on AWS EC2, where it was hit by a ransomware Trojan, not unlike those seen on on-premises servers. As often occurs these days, this was another double-extortion ransomware attack and the company needed help dealing with both issues.

Luckily, due to the company's cloud architecture and preparedness, there were AWS snapshots of the environment going back 14 days. The attackers were unaware of the snapshots and had not disabled them in their attack. This allowed the company to immediately revert to the day before the data encryption, resolving the first part of the attack with minimal effort. That still left two challenges to deal with: the potential data leak and the eradication of the attackers from the environment.

To address these challenges, there was a full investigation of the breach, which turned out to be quite complex due to the hybrid nature of their environment. The attackers compromised a single account with limited access, used by an IT person. They then identified a legacy on-premises server where that individual was an admin and used it to take over the Okta service account, allowing privilege escalation. Finally, using a decommissioned VPN service, they were able to hop to the cloud environment. Using the elevated privileges, they took over the EC2 servers and installed the malware.

The investigation yielded two significant findings. The first was the attack timeline. It showed that the compromise of all hosts occurred before the earliest snapshots were taken, indicating that the recovered servers were compromised and could not be used. New servers were installed, the data was transferred to them, and the original affected servers were purged.

The second finding was even more surprising. Malware analysis identified that the attackers used _rclone.exe_ to copy the files to a remote location. The connection credentials were hardcoded in the malware, so the company was able to connect to the same location, identify, and remove their files, eliminating the attackers' access to the files, eradicating the extortion aspect of the attack.

**Cloud Breaches Are Here to Stay**

As these real-life scenarios reveal, attackers are infiltrating the cloud and cloud breaches are on the rise. It's time for organizations to prepare for cloud incidents. Cybercriminals are leveraging cloud capabilities in attacks, and you should use them, too, to protect your organization and prevent a crisis from hitting the headlines.

Real-World Cloud Attacks: The True Tasks of Cloud Ransomware Mitigation

No-code startups such as Mine PrivacyOps say they offer best of both worlds — quick development and compliance with privacy laws.

As part of the digital transformation reshaping the global business landscape, no-code/low-code tools are on the rise. Gartner projects the use of no-code/low-code tools will grow from almost 25% of applications in 2020 to 70% in 2025.

In a recent Dark Reading survey of 136 IT professionals on the state of no-code/low-code tools and implementation in their businesses, only 39% said they don't use no-code/low-code tools or intend to use them in the near future. The no-code/low-code market is a robust one, valued at nearly $13 billion in 2020 and estimated to reach over $47 billion in 2025 and $65 billion in 2027.

While no-code/low-code tools hold promising potential, they also come with a big challenge: security. The security concerns associated with using no-code/low-code tools are numerous. In the Dark Reading survey, only 7% of respondents said they aren't concerned about the security of no-code/low-code applications.

Malicious actors are constantly spinning new tactics and attack models, and no-code/low-code tools leave huge backdoors for them to exploit. An assessment by the Open Web Application Security Project (OWASP) reveals several no-code/low-code security risks — from account impersonation, to authorization misuse, to credential sharing, and more. For some observers, no-code/low-code tools sacrifice security on the altar of improved productivity.

**Building Privacy Ops With No-Code/Low-Code Tools**

Although no-code/low-code tools present data security challenges, several companies are working on ways enterprises can use these tools to actually improve security. Israel-based Mine PrivacyOps says its no-code platform helps enterprises automate and streamline their privacy operations by securing data and meeting data privacy regulations like the GDPR and CCPA.

One of the privacy-accommodating features Mine PrivacyOps offers is automatic fulfillment of privacy requests via data subject requests and data subject access requests (DSR/DSAR), a requirement of the GDPR under the right of access. The software also handles consent management and third-party risk assessment. No-code integrations with Salesforce, HubSpot, Shopify, Klaviyo, Zendesk, and other data sources allow clients to automate privacy and deletion requests concerning those systems. The data mapping tool creates GDPR-compliant Records of Processing Activity (ROPA) and tracks all personally identifiable information (PII) collected in the client's systems.

"Our no-code approach … means that we have the fastest implementation time in the market, allowing companies to set up in less than 30 minutes with no engineering resources needed," says Gal Ringel, CEO of Mine PrivacyOps. Mine PrivacyOps claims over 2,000 customers use its platform. The company has competition in cloud-based governance, risk, and compliance software makers Hyperproof, Netwrix Auditor, Egnyte, and others.

While security concerns continue to be a major conversation around no-code/low-code tools, there are still bright spots to consider. Companies like Mine PrivacyOps show that no-code tools can factor security into their core functionalities.

Source

DARKReading