Deepfake Fraud

Read Time:7 Second

A deepfake video conference call—with everyone else on the call a fake—fooled a finance worker into sending $25M to the criminals’ account.

Read More

firecracker-1.6.0-6.fc38 libkrun-1.7.2-4.fc38 rust-event-manager-0.4.0-2.fc38 rust-kvm-bindings-0.7.0-1.fc38 rust-kvm-ioctls-0.16.0-3.fc38 rust-linux-loader-0.11.0-1.fc38 rust-userfaultfd-0.8.1-2.fc38 rust-versionize-0.2.0-2.fc38 rust-vhost-0.10.0-2.fc38 rust-vhost-user-backend-0.13.1-2.fc38 rust-virtio-queue-0.11.0-1.fc38 rust-vm-memory-0.14.0-1.fc38 rust-vm-superio-0.7.0-4.fc38 rust-vmm-sys-util-0.12.1-2.fc38 virtiofsd-1.10.1-1.fc38

Read Time:40 Second

FEDORA-2024-f2305d485f

Packages in this update:

firecracker-1.6.0-6.fc38
libkrun-1.7.2-4.fc38
rust-event-manager-0.4.0-2.fc38
rust-kvm-bindings-0.7.0-1.fc38
rust-kvm-ioctls-0.16.0-3.fc38
rust-linux-loader-0.11.0-1.fc38
rust-userfaultfd-0.8.1-2.fc38
rust-versionize-0.2.0-2.fc38
rust-vhost-0.10.0-2.fc38
rust-vhost-user-backend-0.13.1-2.fc38
rust-virtio-queue-0.11.0-1.fc38
rust-vm-memory-0.14.0-1.fc38
rust-vmm-sys-util-0.12.1-2.fc38
rust-vm-superio-0.7.0-4.fc38
virtiofsd-1.10.1-1.fc38

Update description:

Update rust-vmm components and their consumers to address CVE-2023-50711

Read More

firecracker-1.6.0-6.fc39 libkrun-1.7.2-4.fc39 rust-event-manager-0.4.0-2.fc39 rust-kvm-bindings-0.7.0-1.fc39 rust-kvm-ioctls-0.16.0-2.fc39 rust-linux-loader-0.11.0-1.fc39 rust-userfaultfd-0.8.1-2.fc39 rust-versionize-0.2.0-2.fc39 rust-vhost-0.10.0-2.fc39 rust-vhost-user-backend-0.13.1-2.fc39 rust-virtio-queue-0.11.0-1.fc39 rust-vm-memory-0.14.0-1.fc39 rust-vm-superio-0.7.0-4.fc39 rust-vmm-sys-util-0.12.1-2.fc39 virtiofsd-1.10.1-1.fc39

Read Time:40 Second

FEDORA-2024-04877592b7

Packages in this update:

firecracker-1.6.0-6.fc39
libkrun-1.7.2-4.fc39
rust-event-manager-0.4.0-2.fc39
rust-kvm-bindings-0.7.0-1.fc39
rust-kvm-ioctls-0.16.0-2.fc39
rust-linux-loader-0.11.0-1.fc39
rust-userfaultfd-0.8.1-2.fc39
rust-versionize-0.2.0-2.fc39
rust-vhost-0.10.0-2.fc39
rust-vhost-user-backend-0.13.1-2.fc39
rust-virtio-queue-0.11.0-1.fc39
rust-vm-memory-0.14.0-1.fc39
rust-vmm-sys-util-0.12.1-2.fc39
rust-vm-superio-0.7.0-4.fc39
virtiofsd-1.10.1-1.fc39

Update description:

Update rust-vmm components and their consumers to address CVE-2023-50711

Read More

USN-6592-2: libssh vulnerabilities

Read Time:31 Second

USN-6592-1 fixed vulnerabilities in libssh. This update provides the
corresponding updates for Ubuntu 16.04 LTS and Ubuntu 18.04 LTS.

Original advisory details:

It was discovered that libssh incorrectly handled the ProxyCommand and the
ProxyJump features. A remote attacker could possibly use this issue to
inject malicious code into the command of the features mentioned through
the hostname parameter. (CVE-2023-6004)

It was discovered that libssh incorrectly handled return codes when
performing message digest operations. A remote attacker could possibly use
this issue to cause libssh to crash, obtain sensitive information, or
execute arbitrary code. (CVE-2023-6918)

Read More

USN-6622-1: OpenSSL vulnerabilities

Read Time:50 Second

David Benjamin discovered that OpenSSL incorrectly handled excessively long
X9.42 DH keys. A remote attacker could possibly use this issue to cause
OpenSSL to consume resources, leading to a denial of service.
(CVE-2023-5678)

Sverker Eriksson discovered that OpenSSL incorrectly handled POLY1304 MAC
on the PowerPC architecture. A remote attacker could use this issue to
cause OpenSSL to crash, resulting in a denial of service, or possibly
execute arbitrary code. This issue only affected Ubuntu 22.04 LTS and
Ubuntu 23.04. (CVE-2023-6129)

It was discovered that OpenSSL incorrectly handled excessively long RSA
public keys. A remote attacker could possibly use this issue to cause
OpenSSL to consume resources, leading to a denial of service. This issue
only affected Ubuntu 22.04 LTS and Ubuntu 23.04. (CVE-2023-6237)

Bahaa Naamneh discovered that OpenSSL incorrectly handled certain malformed
PKCS12 files. A remote attacker could possibly use this issue to cause
OpenSSL to crash, resulting in a denial of service. (CVE-2024-0727)

Read More

PCI DSS and penetration testing

Read Time:4 Minute, 25 Second

PCI DSS

PCI DSS (Payment Card Industry Data Security Standard) is a set of security controls created to ensure all companies that accept, process, store or transmit credit card data maintain an audit-ready environment. Version 4.0 was published in March 2022; organizations required to be compliant have until March 31, 2024, when compliance must be complete.

The most noteworthy upgrades in PCI DSS version 4.0 to Requirement 11 which are applicable to all organizations are that vulnerability scans must be conducted via authenticated scanning, and that all applicable vulnerabilities must be managed. This eliminates organizations from overlooking vulnerabilities, and selective remediation.

The PCI DSS requires penetration testing (pen testing) and vulnerability scanning as part of its requirements for compliance, to keep systems secure and to protect payment cardholder data. Pen testing must take place for any organizations or entities who store, process, or transmit cardholder data in any capacity.

Payment card service providers must conduct PCI pen tests twice annually and vulnerability scans four times annually, in addition to performing additional assessments when any significant modifications to systems occur. Specifically, organizations that process cardholder information via web applications could need additional tests & scans whenever significant system modifications take place.

PCI pen tests are security assessments that must be conducted at least twice annually and after any significant change to address vulnerabilities across all aspects of the cardholder data environment (CDE), from networks, infrastructure, and applications found inside and outside an organization’s environment. By contrast, vulnerability scans perform high-level tests that automatically search for vulnerabilities with severe scores; external IP addresses exposed within CDE must also be scanned by an approved scanning vendor at least every three months and after any significant change for potential security threats and reported on accordingly.

PCI DSS sets forth specific guidelines and requirements for companies required to run regular PCI pen tests and vulnerability scans in accordance with PCI DSS. System components, including custom software and processes, must be regularly evaluated to maintain cardholder data over time – particularly after changes are introduced into the system. Service providers must conduct PCI pen tests every six months or whenever significant modifications to their systems take place, or whenever any major upgrades or updates take place. Significant changes that would necessitate further pen tests include any addition or change to hardware, software, or networking equipment; upgrading or replacing of current equipment with any changes; storage flow changes which affect cardholder data flow or storage; changes which alter boundary of CDE or scope of PCI DSS assessment; infrastructure support such as directory services monitoring logging changes as well as changes involving third-party vendors or services that support CDE.

Vulnerability scanning is a crucial element of PCI DSS requirements for organizations. At least every 90 days, organizations must conduct internal and external PCI vulnerability scans with passing scan results (internal must not contain high-risk vulnerabilities that compromise cardholder data storage or processing; external must be free from vulnerabilities assigned a CVSS base score of at least four; for external scans that fall between CVSS base scores 4.0-4.99 are accepted); only scans with severity level scores between zero to three constitute passing scores.

Pen testing and vulnerability scanning are integral parts of PCI DSS compliance and an effective means of mitigating vulnerabilities on systems that process sensitive data. With our vulnerability and threat management services, penetration testing services to test an organization’s network security posture, web application testing as well Penetration Testing as a Service (PTaaS), we can help achieve and sustain compliance.

The 6 steps of a pen test

1) Scoping

In this first step, the target organization works with the pen testing team to define the scope of the pen test, which includes the entire CDE perimeter (both internal and external), and any critical systems. It could also include access points, critical network connections, applications that store, process, or transmit cardholder data, and other locations of such data. Any systems that don’t connect to the CDE would be considered out-of-scope for this pen test.

2) Discovery

Once the scope is defined, the pen testing team gets to work by identifying your network assets within the specified scope. In this stage, the testing team gathers as much information on the target company by performing different types of reconnaissance on the in-scope environment.

3) Evaluation

Using the information gathered so far, the tester now attempts to enter your system through the discovered entry points and uncover potential security vulnerabilities that may be lurking behind your networks and applications.

4) Reporting

The testing team compiles a complete and comprehensive report that includes the details of the test methodology, highlights the security flaws discovered, and other relevant information.

5) Remediation

The remediation team mitigates all noted exploitable vulnerabilities and security weaknesses. Keep in mind that the organization’s risk assessment as defined in PCI DSS 6.3.1 should be considered during this step.

6) Retest

The pen test process is repeated regularly and/or every time there is a change in your infrastructure. Retesting is the best way to ensure that your previous remediation efforts are effective.

Conclusion

We offer consulting services for PCI-DSS compliance and pen testing. Start here to see the broad scope of cybersecurity services we offer.

Read More

PCI DSS and penetration testing

Read Time:4 Minute, 25 Second

PCI DSS

PCI DSS (Payment Card Industry Data Security Standard) is a set of security controls created to ensure all companies that accept, process, store or transmit credit card data maintain an audit-ready environment. Version 4.0 was published in March 2022; organizations required to be compliant have until March 31, 2024, when compliance must be complete.

The most noteworthy upgrades in PCI DSS version 4.0 to Requirement 11 which are applicable to all organizations are that vulnerability scans must be conducted via authenticated scanning, and that all applicable vulnerabilities must be managed. This eliminates organizations from overlooking vulnerabilities, and selective remediation.

The PCI DSS requires penetration testing (pen testing) and vulnerability scanning as part of its requirements for compliance, to keep systems secure and to protect payment cardholder data. Pen testing must take place for any organizations or entities who store, process, or transmit cardholder data in any capacity.

Payment card service providers must conduct PCI pen tests twice annually and vulnerability scans four times annually, in addition to performing additional assessments when any significant modifications to systems occur. Specifically, organizations that process cardholder information via web applications could need additional tests & scans whenever significant system modifications take place.

PCI pen tests are security assessments that must be conducted at least twice annually and after any significant change to address vulnerabilities across all aspects of the cardholder data environment (CDE), from networks, infrastructure, and applications found inside and outside an organization’s environment. By contrast, vulnerability scans perform high-level tests that automatically search for vulnerabilities with severe scores; external IP addresses exposed within CDE must also be scanned by an approved scanning vendor at least every three months and after any significant change for potential security threats and reported on accordingly.

PCI DSS sets forth specific guidelines and requirements for companies required to run regular PCI pen tests and vulnerability scans in accordance with PCI DSS. System components, including custom software and processes, must be regularly evaluated to maintain cardholder data over time – particularly after changes are introduced into the system. Service providers must conduct PCI pen tests every six months or whenever significant modifications to their systems take place, or whenever any major upgrades or updates take place. Significant changes that would necessitate further pen tests include any addition or change to hardware, software, or networking equipment; upgrading or replacing of current equipment with any changes; storage flow changes which affect cardholder data flow or storage; changes which alter boundary of CDE or scope of PCI DSS assessment; infrastructure support such as directory services monitoring logging changes as well as changes involving third-party vendors or services that support CDE.

Vulnerability scanning is a crucial element of PCI DSS requirements for organizations. At least every 90 days, organizations must conduct internal and external PCI vulnerability scans with passing scan results (internal must not contain high-risk vulnerabilities that compromise cardholder data storage or processing; external must be free from vulnerabilities assigned a CVSS base score of at least four; for external scans that fall between CVSS base scores 4.0-4.99 are accepted); only scans with severity level scores between zero to three constitute passing scores.

Pen testing and vulnerability scanning are integral parts of PCI DSS compliance and an effective means of mitigating vulnerabilities on systems that process sensitive data. With our vulnerability and threat management services, penetration testing services to test an organization’s network security posture, web application testing as well Penetration Testing as a Service (PTaaS), we can help achieve and sustain compliance.

The 6 steps of a pen test

1) Scoping

In this first step, the target organization works with the pen testing team to define the scope of the pen test, which includes the entire CDE perimeter (both internal and external), and any critical systems. It could also include access points, critical network connections, applications that store, process, or transmit cardholder data, and other locations of such data. Any systems that don’t connect to the CDE would be considered out-of-scope for this pen test.

2) Discovery

Once the scope is defined, the pen testing team gets to work by identifying your network assets within the specified scope. In this stage, the testing team gathers as much information on the target company by performing different types of reconnaissance on the in-scope environment.

3) Evaluation

Using the information gathered so far, the tester now attempts to enter your system through the discovered entry points and uncover potential security vulnerabilities that may be lurking behind your networks and applications.

4) Reporting

The testing team compiles a complete and comprehensive report that includes the details of the test methodology, highlights the security flaws discovered, and other relevant information.

5) Remediation

The remediation team mitigates all noted exploitable vulnerabilities and security weaknesses. Keep in mind that the organization’s risk assessment as defined in PCI DSS 6.3.1 should be considered during this step.

6) Retest

The pen test process is repeated regularly and/or every time there is a change in your infrastructure. Retesting is the best way to ensure that your previous remediation efforts are effective.

Conclusion

We offer consulting services for PCI-DSS compliance and pen testing. Start here to see the broad scope of cybersecurity services we offer.

Read More