bind-9.18.19-1.fc37 bind-dyndb-ldap-11.10-17.fc37

Read Time:31 Second

FEDORA-2023-87502c4a93

Packages in this update:

bind-9.18.19-1.fc37
bind-dyndb-ldap-11.10-17.fc37

Update description:

BIND 9.18.19

Security Fixes

Previously, sending a specially crafted message over the control channel could cause the packet-parsing code to run out of available stack memory, causing named to terminate unexpectedly. This has been fixed. (CVE-2023-3341)
A flaw in the networking code handling DNS-over-TLS queries could cause named to terminate unexpectedly due to an assertion failure under significant DNS-over-TLS query load. This has been fixed. (CVE-2023-4236)
Upstream release notes

Read More

bind-9.18.19-1.fc38 bind-dyndb-ldap-11.10-21.fc38

Read Time:31 Second

FEDORA-2023-a2621f58a9

Packages in this update:

bind-9.18.19-1.fc38
bind-dyndb-ldap-11.10-21.fc38

Update description:

BIND 9.18.19

Security Fixes

Previously, sending a specially crafted message over the control channel could cause the packet-parsing code to run out of available stack memory, causing named to terminate unexpectedly. This has been fixed. (CVE-2023-3341)
A flaw in the networking code handling DNS-over-TLS queries could cause named to terminate unexpectedly due to an assertion failure under significant DNS-over-TLS query load. This has been fixed. (CVE-2023-4236)
Upstream release notes

Read More

“The good and the bad that comes with the growth of AI” – watch this series of webinars with Abnormal, OpenAI, and others

Read Time:24 Second

Graham Cluley Security News is sponsored this week by the folks at Abnormal. Thanks to the great team there for their support! AI and cybersecurity are colliding now more than ever. The positive power of AI is apparent with increased efficiency, cost savings, and more. Unfortunately, the same is true when those benefits get into … Continue reading ““The good and the bad that comes with the growth of AI” – watch this series of webinars with Abnormal, OpenAI, and others”

Read More

USN-6365-2: Open VM Tools vulnerability

Read Time:18 Second

USN-6365-1 fixed a vulnerability in Open VM Tools. This update provides
the corresponding update for Ubuntu 16.04 LTS and Ubuntu 18.04 LTS.

Original advisory details:

It was discovered that Open VM Tools incorrectly handled SAML tokens. A
remote attacker could possibly use this issue to bypass SAML token
signature verification and perform VMware Tools Guest Operations.

Read More

USN-6190-2: AccountsService vulnerability

Read Time:20 Second

USN-6190-1 fixed a vulnerability in AccountsService. This update provides
the corresponding update for Ubuntu 14.04 LTS, Ubuntu 16.04 LTS and
Ubuntu 18.04 LTS.

Original advisory details:

Kevin Backhouse discovered that AccountsService incorrectly handled certain
D-Bus messages. A local attacker could use this issue to cause
AccountsService to crash, resulting in a denial of service, or possibly
execute arbitrary code.

Read More

Ensuring vendor integrity: Why the cloud shouldn’t be your only backup

Read Time:5 Minute, 45 Second

Introduction

As a senior consultant I deal with customers across numerous industries and maturity levels. I am often engaged in conducting risk assessments or gap analysis aligned with common frameworks such as the National Institute for Standards and Technology’s (NIST) Cybersecurity Framework (CSF). Most, if not all, the frameworks have a few controls that focus on the organization’s backup processes and disaster recovery plans. A common response to these areas is that the client relies primarily on their cloud provider for their backups.

Often clients will have an additional form of backup as well, but occasionally the only form of recovery they have is wholly owned by their third-party cloud provider. There tends to be an assumption that since its “in the cloud” it is infinitely repeated and evenly distributed across numerous geographical locations and systems and therefor perfectly safe. While this may be the case, relying on a single backup source (in this case a cloud provider) is a recipe for disaster.

Towards the end of August, a Danish cloud provider was struck by ransomware and sent out a notice to its customers that they were unable to recover any of their systems or the data stored on them. All of the company’s emails, backups, and IT systems were affected and the company was both unable and unwilling to pay the ransom.

What’s ransomware?

Before I dive into the meat of this post, I wanted to have a quick segue to explain what ransomware is. Put simply, ransomware is simply maliciously applied encryption. An attacker will gain access to an organization’s systems through any number of means, and then launch an attack which encrypts all accessible files the attacker can get at. The attacker will also include a note that explains how the victim can direct payment to receive the key needed to decrypt their files. The attacker may also threaten to leak the files as well if the ransom is not paid.

If the organization pays up, the attacker will almost always deliver on their end of the agreement and release the encryption key. If they won’t (or can’t) pay, the situation I described in the introduction is not a wholly uncommon result. New types of ransomware and new mechanisms for delivery and spread are created daily, but the core functionality is the same. Systems are breached, files are encrypted, and ransom is demanded. These attacks can come at any time and are not specific to any one industry market.

Verify, trust, and plan for failure

By this point you’re likely wondering (at least I hope you are) what you can do to prevent the damage from one of your critical vendors being unable to recover from a ransomware attack. I have good news, and bad news. The good news is there is something you can do about it. The bad news is that it’s going to take time, skill, and money, all things you had hoped to save by bringing on a third-party to begin with.

The first thing you’ll want to do is ensure you have some fallback plan. Ideally this would be a well-planned and documented business continuity plan alongside a disaster response and incident response plan. At the very least, however, you must have some ability to replicate the service provided by your vendor. This may be a manual process you can activate, a copy of the server/device configurations they host, or a copy of the data they hold or process on your behalf.  

While it would be nice if we could trust that another business, group, or person would handle things in the same way we would, it is irresponsible to blindly assume that they will. After you’ve confirmed (or implemented) your ability to operate in the event of a vendor failure you will need to verify whether your provider is doing all they need to do to keep your business safe. It is not possible to prevent every failure, nor can you guarantee assessing a vendor will reveal all potential gaps, but it is your responsibility to take every reasonable measure to reduce the likelihood of a catastrophic vendor failure from effecting your business.

For assessing cloud vendors, current or future, one of the best ways is through the Cloud Security Alliance’s Cloud Control Matrix. Their offering, available for free online, includes a detailed questionnaire that you can use to gain a better understanding of your vendor’s security practices. They also offer guidelines for how to implement the controls they are looking at, guidance on how to audit the provided controls, and even map their controls to the following frameworks:

CIS v8.0
PCI DSS v3.2.1
AICPA TSC 2017
ISO 27001/02/17/18
NIST 800-53 r5

Conclusion

In our interconnected world, threats aren’t always just from internal sources; they can come from numerous external sources including from the very vendors the business relies on. Managing these vendor-originated threats is of critical importance and must be handled with the same rigor as all other cybersecurity risks. Third-party risk management encompasses a suite of activities from policy creation and detailed assessment procedures to stringent enforcement of security requirements.

Starting a vendor management program presents challenges – from its complexity to time-intensive nature. However, rather than simply shrugging and assuming it is too much work to accomplish, it’s prudent instead to prioritize. Begin with your most critical vendors – those whose disruption can have maximum operational impact or those handling the most sensitive data. The criteria for prioritizing vendors can include their significance to daily operations, relevant financial implications, or the sensitivity of the data they store, collect, or process.

A resilient organization is one that identifies and secures its vulnerabilities, be it people, processes, or technology. This includes recognizing single points of failure that, if disrupted, could jeopardize the organization’s functioning. Relying on a vendor doesn’t negate the risk, nor does it transfer responsibility. The onus remains with the organization to mitigate risks stemming from vendor relationships. Remember, vendor selection is just the starting point. Vigilance, regular assessments, and robust risk management processes are what ensure the integrity of the vendor relationship and, by extension, the organization’s cybersecurity posture.

After all, if a breach occurs at a vendor that effects your data or your operations it is not the vendor’s customers that will be upset, nor will theirs be the only reputation damaged. Their success, or failure, is tied to your organization’s brand and overall security and must be treated accordingly.

Resources & additional reading

https://www.theregister.com/2023/08/23/ransomware_wipes_cloudnordic/

https://cloudsecurityalliance.org/research/cloud-controls-matrix/

https://cybersecurity.att.com/blogs/security-essentials/defending-against-ransomware-the-basics

https://cybersecurity.att.com/blogs/security-essentials/why-vendor-management-is-a-cornerstone-of-security

Read More