AWS Application Load Balancer Configuration Bug Raises Questions of Shared Responsibility; Patch Available for Critical SonicWall Vulnerability; American Relay Radio League Paid Ransomware Demand

This AWS Load Balancer issue is similar to the Confused Deputy problem. This stems from the fact that many cloud services are shared between customers. Given a configuration that is not restrictive enough, you end up in this very strange situation where if the load balancer works for you, it will also work for everyone else, allowing the check of authentication to pass no matter where it is. This tends to be one of those difficult bugs because the onus is on everyone else, not Amazon, to fix the issue. How do they notify affected customers, and should they? This is a tricky one.

Secure configuration of enterprise assets and software is a critical security control. The CIS Community Defense Model documented that establishing and maintaining a secure configuration process (CIS CSC 4) is a safeguard for all five attack types discussed in the defense model. This includes cloud-based assets, for which CIS offers an AWS Foundations Benchmark. Download the benchmark for specific configuration guidance. https://www.cisecurity.org/controls: CIS Critical Security Controls¨

'Cyclomatic complexity' as measured in metrics like McCabe Complexity in the late 70s/80s proved that 'spaghetti code' (high complexity caused by many paths needing to be tested) inevitably had more errors than low complexity code. Today's equivalent is 'spaghetti code as a service' or maybe we should call in the 'spaghetti cloud' as 35 different services with hundreds of calls back and forth are used to complete a transaction. Software testing tools are starting to evolve in this direction but bad guys and smart pen testers (and bug bounty chasers) are finding the gaps.

With cloud services, or any other hosted service, you need to follow the providerÕs security best practices to ensure you're not leaving yourself vulnerable. It's also a good idea to understand what they are doing to ensure their service is secure. What's harder is that you need to watch for updates to these practices, and yeah, adjust accordingly. If you can't sign up for proactive notifications, make a calendar reminder to check regularly. If you haven't verified your ALB authentication configuration recently against best practices, today's a good day.

The language in the advisory isn't quite clear. Based on the CVSS Score of 9.8, this is not "just" a denial of service vulnerability. Patch now.

CVE-2024-40766, improper access control, CVSS score of 9.3, requires a firmware update to fix. Gen 5 - 5.9.2.14-13o, Gen 6, 6.5.8.2.8-2n or 6.5.4.15.116n (device dependent), Gen 7 install the latest firmware, at a minimum 7.0.1-5035. Additionally, restrict access to WAN management of your firewall.

As a ham radio operator (K3TN), several key applications I use are still down 3 months later. Also, the personal data exposure only impacted a small number of users but the down services impacted several hundred thousand users. Non-profits can use this one as an example of the real world costs of not preventing incidents.

As a ham operator this attack was disturbing, and while services are not all online, popular services like Logbook of The World (LoTW) - used to record and track contacts with others - is back, and ARRL is forming an Information Technology Advisory Committee to help guide future efforts to remain secure and prevent recurrence. Note to self: no matter how insignificant your organization may look to you, not-for-profit or otherwise, you need to be prepared to repel boarders. ARRL was able to leverage insurance to cover costs here; don't assume that's the magic bullet. Talk to a broker about the realities for your business in your area.

Two questions are relevant: 1. What security mechanisms were in place at ARRL at time of the attack? 2. What influence did the insurance carrier have in the negotiations? For the first, the answer helps others defend against similar attacks. It's clear that ARRL has made architecture changes to the infrastructure because of the attack. For the second, although it is ultimately the company's decision whether to pay, insurers hold a lot of sway. Should the insurer provide the option to pay the ransom? It's a hotly debated topic.

The ARRL may be our communication system of last resort in the face of catastrophe.

The issue is that while drives with sensitive data are removed for appropriate disposal/destruction, they are neither tracked nor labelled commensurate with the data on them. The systems they were removed from were both labelled and tracked. Points for special handling of sensitive data destruction, minus a bunch for tracking and controlling access to the media before it's wiped. In today's environment you really do need to track sensitive data "cradle to grave." Take a look at cryptographic erasure (NIST SP 800-88) rather than multi-pass wipe or even shredding. Regardless of how you're ensuring data is properly disposed of, make sure that you track media with sensitive data, including restricting physical access, and are validating a sample to ensure it's really not retrievable. https://csrc.nist.gov/pubs/sp/800/88/r1/final: Guidelines for Media Sanitization

Proper disposal of classified information (SBU, NSI) is a basic requirement of all agencies that handle such information. An individualÕs clearance would be pulled for leaving classified information unprotected. The FBIÕs mission requires access to such information but how do you create a culture of security, when basic security requirements are essentially ignored? Accountability has to start at the top and it can't be by simply concurring with the recommendations.

Those in the private sector should check themselves against the findings in these public reports. These findings do not make news because they are unique to one organization, or even rare, but rather because they are likely to be common.

The idea of adding cyber event to the list of travel delays to allow for is disturbing. In this case, travelers were able to check-in/obtain boarding passes and flight status through airline online (mobile/web) apps, while in-airport ticket counters had to fall back to paper tickets. The baggage handling/sorting system was also affected, resulting in warnings to passengers to only bring carry-on bags. It appears threat actors are evolving their attacks on critical infrastructure faster than security improvements can be made, which is likely exacerbated by the number of interconnected systems that come together to provide the services we expect.

In the last few months, we have seen how fragile our airport infrastructure systems are. I call it the Hospital problem. Hospitals have historically had a hard time understanding the risks of cyber, until ransomware came along and consistently disrupted hospitals' operations. Will that be what it takes for our OT operators to pay attention to things like water, power, and airports? CrowdStrike's outage was a wakeup call.

For too long we have relied on organisations and vendors to ensure appropriate levels of security are in place to protect critical infrastructure. However, we regularly see organisations fail cybersecurity audits or indeed be victims of cyberattacks. We are now at the stage where we need such organisations.

While there is still a lot of mystery here, it is clear that Halliburton executed their response plan, proactively taking sensitive systems offline to prevent further impact. Beyond having a response plan, and proactively taking systems offline to contain an incident, you also need to make sure that you're paying attention to cyber hygiene. Too often hackers are hitting unpatched vulnerabilities or systems inappropriately exposed to the Internet, or even other unsecure systems. Regardless of how you like the term ZTA, one of the core ideas is important - connections need to not only check for user trustworthiness, but also the suitability of the system. If a system doesn't meet minimum security standards, don't allow it on your net.

While it has yet to be determined a ransomware attack, it bears all the hallmarks of one. Many of the TSA security requirements speak to incident planning and notification. To be effective against ransomware attacks, review the Blueprint for Ransomware Defense, hosted by the Institute for Security and Technology. https://securityandtechnology.org/ransomwaretaskforce/blueprint-for-ransomware-defense/: Blueprint for Ransomware Defense