TEL AVIV, Israel, 11th November 2024, CyberNewsWire

**TEL AVIV, Israel, November 11th, 2024, CyberNewsWire**

Customers can now easily integrate Sweet’s runtime detection and response platform into their AWS environments

Sweet Security today announced the availability of its cloud-native detection and response platform on the Amazon Web Services (AWS) marketplace. Sweet’s solution unifies threat detection across cloud infrastructure, network, workloads, and applications. It provides deep runtime context that enables security teams to quickly extract actual attack narratives from a sea of isolated incidents. Using Sweet, AWS Marketplace customers can detect active threats in real time and respond to them within minutes, enabling them to resolve threats with unprecedented speed – 2-5 minute MTTR – and maintain an agile and resilient environment.

AWS customers visiting AWS re:Invent 2024 in Las Vegas can book a meeting to learn more here.

> “Cloud environments are noisy and complex, making them fertile grounds for attackers — deterring them requires detection and response capabilities that, to date, have been aspirational, but we’ve made them table stakes,” said Eyal Fisher, Co-Founder and Chief Product Officer of Sweet Security and former head of the Cyber Operation Center, Unit 8200 (Col., retired). “We’re delighted that our solution is now available to AWS Marketplace customers and look forward to helping them simplify the burden of cloud security and do their jobs faster and better.” 

**What Makes Sweet so Sweet?**

Sweet Security offers detection and response for cloud native environments. Its approach is unique in how it unifies detection across cloud infrastructure, network, workloads, and applications, providing deep runtime context that cuts through the noise and delivers actual attack narratives.

Key Features include:

●     Advanced threat detection and incident response (IR) across infrastructure, network, application, and workload levels.

●     Vulnerability management enriched with runtime insights, reducing CVEs by 99% and putting only the critical risks in front of security personnel.

●     Lean sensor technology that requires minimal resources (50 MB RAM, 0.20% CPU per node) and take only minutes to deploy

●     30+ out-of-the-box integrations with SIEM, SOAR, notification and ticketing systems, and mor

Sweet empowers security teams to achieve a Mean Time to Detect of 30 seconds (MTTD) and a 2-5 minute Mean Time to Resolve (MTTR), transforming cloud security into a more proactive and effective discipline.

For more information, users can visit Sweet Security on the AWS Marketplace.

**About Sweet Security**

Specializing in Cloud Native Detection & Response (D&R), Sweet Security protects cloud environments in real time. Founded by the IDF’s former CISO, Sweet’s solution focuses on the relationships between cloud infrastructure, workloads and applications , as well as network, and identity components. Leveraging a lean, eBPF-based sensor and deep behavioral analysis, Sweet analyzes anomalies, generating vital insights on incidents, vulnerabilities, and non-human identities. Its GenAI-infused technology cuts through the noise and delivers actionable recommendations on critical, real-time cloud risks. Privately funded, Sweet is backed by Evolution Equity Partners, Munich Re Ventures, Glilot Capital Partners, CyberArk Ventures and an elite group of angel investors. For more information, please visit http://sweet.security.

**Contact**

**Account Director**  
**Chloe Amante**  
**Montner Tech PR**  
**\[email protected\]**

Sweet Security Announces Availability of its Cloud Native Detection & Response Platform on the AWS Marketplace

A flaw was found in moodle. Insufficient sanitizing of data when performing a restore could result in a cross-site scripting (XSS) risk from malicious backup files.

**Exploitability Metrics**

Attack Vector: This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the resulting severity) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable system. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater severity.

Attack Complexity: This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. These are conditions whose primary purpose is to increase security and/or increase exploit engineering complexity. A vulnerability exploitable without a target-specific variable has a lower complexity than a vulnerability that would require non-trivial customization. This metric is meant to capture security mechanisms utilized by the vulnerable system.

Attack Requirements: This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. These differ from security-enhancing techniques/technologies (ref Attack Complexity) as the primary purpose of these conditions is not to explicitly mitigate attacks, but rather, emerge naturally as a consequence of the deployment and execution of the vulnerable system.

Privileges Required: This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric. Generally, self-service provisioned accounts do not constitute a privilege requirement if the attacker can grant themselves privileges as part of the attack.

User interaction: This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.

**Vulnerable System Impact Metrics**

Confidentiality: This metric measures the impact to the confidentiality of the information managed by the VULNERABLE SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.

Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the VULNERABLE SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).

Availability: This metric measures the impact to the availability of the VULNERABLE SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.

**Subsequent System Impact Metrics**

Confidentiality: This metric measures the impact to the confidentiality of the information managed by the SUBSEQUENT SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.

Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the SUBSEQUENT SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).

Availability: This metric measures the impact to the availability of the SUBSEQUENT SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.

GHSA-4hjf-6pxr-549h: Moodle Cross-site Scripting vulnerability

A flaw was found in moodle. When creating an export of site administration presets, some sensitive secrets and keys are not being excluded from the export, which could result in them unintentionally being leaked if the presets are shared with a third party.

GHSA-vpq5-56jj-vf2m: Moodle admin presets export tool includes some secrets that should not be exported

A flaw was found in moodle. The cURL wrapper in Moodle strips HTTPAUTH and USERPWD headers during emulated redirects, but retains other original request headers, so HTTP authorization header information could be unintentionally sent in requests to redirect URLs.

GHSA-7wmp-2xmx-g6h8: Moodle authorization headers preserved between "emulated redirects"

A flaw was found in moodle. Some hidden user profile fields are visible in gradebook reports, which could result in users without the "view hidden user fields" capability having access to the information.

GHSA-c767-4whh-v7rw: Moodle has user information visibility control issues in gradebook reports

A flaw was found in moodle. Insufficient capability checks make it possible for users with access to restore glossaries in courses to restore them into the global site glossary.

GHSA-4gq2-x5w4-7hp8: Moodle has insufficient capability checks

A flaw was found in moodle. Matrix room membership and power levels are incorrectly applied and revoked for suspended Moodle users.

GHSA-q99x-mjmh-v8w7: Moodle's user/power level management inconsistent with suspended users

A flaw was found in moodle. External API access to Quiz can override contained insufficient access control.

GHSA-jpf2-9ppp-2c49: Moodle has insufficient access control

Companies and organizations need to recognize the importance of investing in engineers who possess both the soft and hard skills required to secure open source software effectively.

Source: Yury Zap via Alamy Stock Photo

COMMENTARY

Open source security incidents aren't going away. The reliance on open source software (OSS) increases year-over-year, with more than 95% of all software, including open source, in some capacity. From operating systems to critical libraries to Web applications and more, open source software (OSS) plays a pivotal role in the current technology landscape. However, this widespread reliance introduces significant security risks. As the use of OSS continues to evolve, so does the importance of securing it. This responsibility falls not on individual hobbyist developers, but on the companies and organizations that have the resources to dedicate engineers specifically to open source security. These organizations are the ones that benefit the most from open source and should be the ones who contribute the most back.  

**Essential Skills for Open Source Security Developers**

Securing open source is similar to securing closed source, but many of the skills required are of higher importance for open source, due to various factors. Open source is public and tends to have broader adoption than much closed source software. A closed source tool with a security vulnerability used by a handful of customers is going to have a very different impact than something like OpenSSH having a vulnerability, given its use on millions of servers worldwide. 

I hope this doesn't come as a surprise, but the most important open source skills to have are soft skills. Most software development time is spent doing things other than actually writing code. Here are a few key skills:  

*   Public collaboration: Open source projects are inherently collaborative and involve contributors from around the globe. Effective communication ensures that security practices are understood and implemented correctly. 
    

*   Preventing miscommunication: Many security bugs arise from misunderstandings. Clear documentation and open dialogues can prevent these issues from occurring. 
    

*   Proactive approach: Keeping security at the forefront of daily tasks helps in early detection of potential vulnerabilities. 
    

*   Continuous vigilance: A security-first mindset encourages constant evaluation of code for potential risks. 
    

*   Responsibility: Treating open source projects with the same seriousness as closed source commercial projects ensures higher security standards. 
    

*   Accountability: Developers who feel a sense of ownership are more likely to produce secure and reliable code. 
    

Just because soft skills are more important than hard skills for software development doesn't mean those hard skills are irrelevant. They are still important, and a few of them in particular are of focused importance for open source security. The open source community gets the benefit of a project being public, enabling the community to come together to secure the project with experts in different areas providing their expertise. However, with open source being public, it also exposes projects to malicious actors, like we saw in the XZ compromise, where a bad actor maintainer contributed innocuous-looking, but ultimately malicious, code. This is why software engineers focused on open source security need to be vigilant and experienced to know what to look for when they get contributions from anonymous developers. Here are some of the skills that are important: 

1.  Security Engineering and Threat Modeling 
    

*   Understanding attack vectors: Knowledge of how vulnerabilities are exploited is crucial. 
    

*   Techniques like STRIDE: Familiarity with threat modeling methodologies helps in identifying and mitigating risks. 
    

*   Common vulnerabilities: Awareness of issues like SQL injection, cross-site scripting (XSS), and buffer overflows is essential. 
    

*   Language-specific vulnerabilities: Each programming language has its own set of security concerns. This is especially important for languages and ecosystems that don't have built-in memory safety mechanisms. 
    

*   Ecosystem proficiency: Knowledge of the packaging ecosystem like PyPI, npm, etc., and how software is developed in that ecosystem is important to understand external risks to the project like upstream dependencies. You can write perfectly safe code and include a vulnerable or malicious dependency and ship insecure software. Knowing when to include a dependency and when it's better to write the functionality yourself is very important as well. 
    

*   Build pipelines: Incorporating security checks into continuous integration and deployment processes ensures ongoing security. Open source developers wear multiple hats and need to understand and secure the continuous integration flow. The artificial intelligence (AI) analog would be the training pipeline. 
    

*   Contextual awareness: Understanding how software will be used by consumers helps in identifying potential security flaws. 
    

*   Automated testing: Implementing tools that automatically scan for vulnerabilities can catch issues early. 
    

*   Comprehensive test coverage: Ensuring that all parts of the code are tested reduces the risk of overlooked vulnerabilities. 
    

As the reliance on open source software continues to grow, so does the necessity for open source developers focused on security. This need is becoming even more critical with the rise of open source AI projects. Open source AI introduces new layers of complexity and opacity due to massive datasets and the probabilistic nature of trained models. The sheer volume of data and the intricacies of machine learning algorithms make it challenging to identify vulnerabilities and predict how models might behave in unforeseen circumstances. 

The "black box" aspect of AI models means that even the developers may not fully understand how inputs are being processed to produce outputs. This opacity can be exploited, leading to security breaches such as data poisoning, adversarial attacks, and unintended bias. Therefore, securing open source AI requires specialized skills and a deep understanding of both AI technologies and security principles. 

Companies and organizations must recognize the importance of investing in engineers who possess both the soft and hard skills required to secure open source software effectively, especially in the rapidly evolving field of AI. By fostering these skills, we can enhance the security of open source projects, benefiting individual organizations and the global community that relies on them. 

**About the Author**

Co-Founder & Chief Technology Officer, Kusari

Michael Lieberman is co-founder and chief technology officer (CTO) of Kusari, where he helps build transparency and security in the software supply chain. He has extensive engineering and architecture expertise with an emphasis on cloud-native technologies and security and privacy use cases. Prior to Kusari, he held engineering leadership positions with Citi, Mitsubishi UFJ Financial Group (MUFG), and Bridgewater Associates. Michael is an active member of the open source community, co-creating the GUAC and FRSCA projects and co-leading the CNCF’s Secure Software Factory Reference Architecture white paper. He is also co-chair of the Cloud Native Computing Foundation Financial Services User Group and an OpenSSF TAC and SLSA steering committee member.

Open Source Security Incidents Aren't Going Away

Bitcoin Fog operator sentenced to 12.5 years for laundering $400M in crypto. The dark web’s longest-running mixer processed…

Bitcoin Fog operator sentenced to 12.5 years for laundering $400M in crypto. The dark web’s longest-running mixer processed 1.2M bitcoin tied to illegal activities over 10 years.

Roman Sterlingov, a 36-year-old dual Russian-Swedish national, has been sentenced to 12 years and six months in prison for operating Bitcoin Fog, the longest-running cryptocurrency “mixer” on the **dark web**.

****The Bitcoin Fog Operation****

Between 2011 and 2021, Sterlingov’s Bitcoin Fog processed over 1.2 million Bitcoin transactions, valued at approximately $400 million at the time of the transactions. The majority of these transactions originated from **dark web marketplaces** and were linked to illicit activities such as narcotics trafficking, computer crimes, identity theft, and child sexual abuse material.

Bitcoin Fog’s clearnet site (Screenshot: Hackread.com)

****The Investigation and Prosecution****

Sterlingov’s operation was brought to an end in March 2024, when a jury found him guilty of money laundering conspiracy, money laundering, operating an unlicensed money transmitting business, and money transmission without a license in the District of Columbia.

The investigation, led by the IRS-CI District of Columbia Cyber Crime Unit and the FBI Washington Field Office, involved collaboration with international authorities, including those from Japan, Sweden, Denmark, Romania, and the UK, as well as Europol.

In addition to his prison sentence, Sterlingov has been ordered to pay a forfeiture money judgment of $395,563,025.39 ($395.56 million) and to forfeit seized cryptocurrencies and monetary assets valued at approximately $1.76 million. He will also forfeit his interest in the Bitcoin Fog wallet, which contains approximately 1,345 Bitcoins, currently valued at over $103 million.

“Through his illicit money laundering operation, Sterlingov helped criminals launder proceeds of drug trafficking, computer crime, identity theft, and the sexual exploitation of children,” **said** Principal Deputy Assistant Attorney General Nicole M. Argentieri.

While cybercriminals and money launderers have become increasingly sophisticated at using **advanced anonymization techniques** to conceal their operations, this case also highlights law enforcement’s enhanced capability to track and prosecute cryptocurrency-based money laundering.

1.  **United States Blacklists Tornado Cash**
2.  **Feds Bust Samourai Wallet Over BTC Money Laundering**
3.  **Major Dark Web Marketplace “Nemesis Market” BUSTED**
4.  **Crypto tumbler BestMixer.io seized for money laundering**
5.  **US Seizes Bitcoin Mixer Sinbad.io Used by Lazarus Group**

Latest News