#ssl

What is Continuous Attack Surface Penetration Testing or CASPT? Continuous Penetration Testing or Continuous Attack Surface Penetration Testing (CASPT) is an advanced security practice that involves the continuous, automated, and ongoing penetration testing services of an organization's digital assets to identify and mitigate security vulnerabilities. CASPT is designed for enterprises with an

Ubuntu Security Notice 6944-2 - USN-6944-1 fixed CVE-2024-7264 for Ubuntu 20.04 LTS, Ubuntu 22.04 LTS, and Ubuntu 24.04 LTS. This update provides the corresponding fix for Ubuntu 14.04 LTS, Ubuntu 16.04 LTS, and Ubuntu 18.04 LTS. Dov Murik discovered that curl incorrectly handled parsing ASN.1 Generalized Time fields. A remote attacker could use this issue to cause curl to crash, resulting in a denial of service, or possibly obtain sensitive memory contents.

The National Public Data breach includes the Social Security Numbers of many US citizens. Find out about yours.

Cisco Talos has uncovered a new remote access trojan (RAT) family we are calling “MoonPeak.” This a XenoRAT-based malware, which is under active development by a North Korean nexus cluster we are calling “UAT-5394.”

In the Linux kernel, vulnerabilities in netfilter, tls, and tty have been resolved.

In today's rapidly evolving cyber threat landscape, organizations face increasingly sophisticated attacks targeting their applications. Understanding these threats and the technologies designed to combat them is crucial. This article delves into the mechanics of a common application attack, using the infamous Log4Shell vulnerability as an example, and demonstrates how Application Detection and

Cybersecurity researchers have disclosed a security flaw impacting Microsoft Azure Kubernetes Services that, if successfully exploited, could allow an attacker to escalate their privileges and access credentials for services used by the cluster. "An attacker with command execution in a Pod running within an affected Azure Kubernetes Services cluster could download the configuration used to

One of the key components of a container-based architecture is security.There are many facets to it (just have a look at the list of topics in the official OpenShift documentation here), but some of the most basic requirements are authentication and authorization. In this article, I explain how authentication and authorization work in Kubernetes and Red Hat OpenShift. I cover interactions between the different layers of a Kubernetes ecosystem, including the infrastructure layer, Kubernetes layer, and the containerized applications layer.What is authentication and authorization?In simple terms,

During account assignment in the Talk2M platform, a Cosy+ device generates and sends a certificate signing request (CSR) to the back end. This CSR is then signed by the manufacturer and used for OpenVPN authentication by the device afterward. Since the common name (CN) of the certificate is specified by the device and used in order to assign the OpenVPN session to the corresponding Talk2M account, an attacker with root access to a Cosy+ device is able to manipulate the CSR and get correctly signed certificates for foreign devices.

Confidential containers are containers deployed within a Trusted Execution Environment (TEE), which allows you to protect your application code and secrets when deployed in untrusted environments. In our previous articles, we introduced the Red Hat OpenShift confidential containers (CoCo) solution and relevant use cases. We demonstrated how components of the CoCo solution, spread across trusted and untrusted environments, including confidential virtual machine (CVM), guest components, TEEs, Confidential compute attestation operator, Trustee agents, and more, work together as part of the soluti