Defining Responsible AI; Never-ending WordPress Vulnerabilities Dictate Looking at Content Management as a Service Approaches; Move Exchange Servers to Auth2.0

Obviously criminals won’t follow safety guidelines but (like in food and drugs and vulnerability disclosures) it is important to be held to acceptable levels of behavior. AI is out of the bottle and the real move forward to be able to trust content is by having strong authentication of who created it and integrity – proof that the content has not be compromised. Moving to 2FA is a necessary first step on this journey.

Legitimate, friendly AI producers, like OpenAI, Microsoft, etc. are not the concern here, I worry there is a false assumption here that those who would do us harm, or are not bound by US regulations will follow these. Continue to explore AI offerings, be certain to understand who is offering them and where their ethical boundaries are.

We all want responsible AI innovation. Unfortunately, that may prove difficult given the global race to innovate and the ever-growing list of possible AI use cases. Just a week ago, a major consulting and tax firm announced a $1B investment over three years to expand and scale its AI offerings. Seems like everyone is getting onboard the AI train.

WordPress plugins continue to be unmaintainable even with the best efforts from WordPress itself. Just like MSFT Exchange: Stop self-hosting WordPress and opt for any of the rather affordable managed CMS solutions.

This plugin is being actively maintained and the patched version was released on April 5th. At core this was a case of not properly sanitizing input. Make sure that your developers cover all possible inputs to ensure nothing untoward can be inserted into your otherwise healthy application.

With WordPress, critical vulnerabilities most often crop up by the use of plugins; this vulnerability is no different. While XSS no longer makes the OWASP Top-10 list as a stand-out vulnerability, it is included in the ‘injection’ grouping. My advice, if you’re a WordPress shop, patch early and patch as often as apps are updated.

Before blaming Cisco for no longer supporting these devices, consider that they haven't been sold in a few years, and the EOL of these devices was announced several years ago as well. It is important that you note EOL dates for devices in your inventories and have replacement plans in place.

These devices let you connect an analog phone/fax to your VoIP system. I have used something similar to put fax machines on my Google Voice number. And they just work, so you've probably forgotten all about them. This is tough, particularly if you have a bunch of these adapters. The thing is, they are almost three years past EOL. One of the hard things to do is incorporate lifecycle planning, to include budget, up front, and we all need to get good at it, to include contingency where a particular solution/feature set is no longer available from your preferred provider.

Cisco has made a business decision to not spend the money to patch these adapters (which will have an update come out in 2024), putting customers at risk if they don’t spend to migrate to supported hardware. Customers have to make a business decision to replace the $100 device or switch to a non-Cisco VoIP approach. The bad risk decision is to just stick with the old adapters that use the vulnerable web interface without taking mitigation steps.

In this example the phone adapter reached EOL three years ago, and a business decision was made not to patch. The decision most likely tied to a smallish number of customers still using the product. With that, let’s spend a moment discussing cybersecurity using a subscription-based model. In this model, you may pay more annually but you ensure getting regular application updates to include security, and as needed hardware. This model sure beats IT and security professionals scrambling to protect their infrastructure.

For many devices and appliances, it is more efficient to replace them than to repair them.

If you're an MMC customer, verify the services are available at the location you use before heading over there. The details of the attack are not well known, except that it appears to be a ransomware attack with data loss. While MMC is currently holding their cards close, as many of us would want to do in their situation, they are obligated to notify customers and regulators of any breached data. Make sure you're aware of notification requirements for any data breach in your area, to include both scope and timing. Make sure the C-suite is not only onboard with those requirements but also determines, ahead of time, who has to put that message out.

Not much info on how the attack succeeded, but odds are high that phishing obtained reusable passwords. The security metrics of Time to Detect/Respond/Restore have been critical when reusable passwords are in use because there will always be a lot of restoring needed and down times of two weeks should have been avoidable.

Another week, another ransomware attack on the healthcare sector. In this case, the medical center went off-line for two weeks to recover from the attack. With estimated annual revenue of 36.5M, it does beg a question about the cybersecurity expenditure to protect its infrastructure. Let’s assume recover costs will be 3x its annual cybersecurity expenditure. MMC’s misfortune can be a valuable case study for boards reviewing cybersecurity practices.

The FBI continues to locate and take steps to shut down these services. Even so, booter services continue to proliferate, so while this is excellent news, you still need to be prepared for DDoS attacks. Make sure you're talking to all your service providers. Don't overlook your on-premises IT, enable and license if required, services on devices you own.

The Justice Department is continuing its switch in focus from hacker prosecution to hacker disruption. So far, it’s been a good year for law enforcement efforts in combating ransomware. Unfortunately, evil-doers are still successful – witness Murfreesboro Medical Center. Don’t forget that the end user still has to do their part by enabling essential cyber hygiene on their enterprise.

Western Digital has been working to restore services and forensicate the incident to include release of additional data sets not listed above. They restored their MyCloud service on April 13, and expect to bring the online store back around May 15th.

As the weeks pass, the impact of the cyberattack on Western Digital (WD) only grows. Between the earlier downtime of important WD services and now its online store, the costs are mounting. Yet another valuable case study for boards to review as they include cybersecurity as part of their risk management responsibility.

The report highlights the successes of public/private sector cooperation as well as the progress against their 48 recommendations. If you don't have a relationship with your local FBI or CISA offices, get going; you're going to need them both. Make sure that you're getting their bulletins and alerts; they should help round out other feeds you’re already subscribed to.

These recommendations are addressed to the collective and ranked accordingly. However, the report recognizes that those addressed to the small and medium size enterprises are not being adopted quickly or broadly enough. At this time, for those enterprises, the single most efficient measure is strong authentication. After that, network segmentation, and a backup and recovery plan that provides for restoration of mission critical applications in hours to days. These are fundamental and essential measures in any case.

Good news: they have not found indications that health/medical records were released, that only individuals' names, birthdates, addresses and Social Security numbers were affected. The bad news: individuals' names, birthdates, addresses and Social Security numbers were affected. Make sure your credit monitoring is current and active. Don't wait on a breach for someone else to provide that service to you. If you are subscribing to a service provided as a result of a breach, understand just what the duration is and what happens after that, to include what happens to your data if you take your business somewhere else.

If reusable credentials are implicated in a breach five years into widespread and highly publicized ransomware attacks, it is long since time for a management change (whether we choose to say so or not.)

Like me, many of you are saying "noooo" don't pay. Until we've walked a mile in their shoes, it's hard to be sure that wasn't the best option in this case. While I am not an advocate of paying the ransom, make sure that you've fully discussed the situations under which you may elect to pay and what that could look like, to include possible Office of Foreign Assets Control (OFAC) considerations your financial institution may impose.

While we can argue the merits of paying the ransom or not, the decision process often involves a third party – the insurance carrier. The carrier may have made a business decision that it was cheaper to pay the ransom vice to cover remediation of the network. And for the record, I’m generally against paying the ransom but then I’m not the senior county official, so my opinion doesn’t matter.

These types of “fatigue” attacks can be easily detected but a good move by Microsoft to move forward to make it harder for them to succeed.

This takes away the blind "click to approve" sign-in. You will be presented with a number as part of the login dialog and have to enter that number in the MS Authenticator app to complete the approval. While not entirely phishing resistant, it raises the bar without having to implement additional authentication services or technology.

The issue in authentication is always a balance between the inconvenience to the user and the cost to the attacker. We can always make the cost to the attacker higher than the value of his success but usually at some inconvenience to the user. Right now, Passkeys seem to be the right balance. They are more convenient than passwords and more resistant to attack than other popular forms of strong authentication.