Apple Removes ADP E2EE in UK; Gmail MFA Moves to QR over SMS; Google Debuts Quantum-Safe Digital Signatures

In many sci-fi worlds, tech companies become more powerful than governments. This story would be one small prologue to such a future. See also: Signal leaving Sweden (https://swedenherald.com/article/signals-ceo-then-were-leaving-sweden). It will be interesting to see what pressure consumers/citizens will place on their elected officials in cases such as these. Do they let it go, or do they push their governments to relent to the tech provider?

If Apple had acceded to this request it would have meant any backdoor they introduced would impact all of their global users, not just those in the UK. By removing the service from its UK customers Apple has been forced to reduce the security of its UK customer base, but retain the security for the rest of its users. That is, until other governments introduce similar laws and make similar demands from Apple. We are moving back into the era of encrypting data under your own control rather than relying on services provided by third parties.

This doesn't eliminate encryption of Apple's iCloud data; it reduces the items Apple cannot access for UK users. Given that UK users already using ADP will be contacted at a future date about turning that off, this feels like a stopgap; hold off on disabling until required or an alternate solution is available. In today's risk climate, you should be working to encrypt your data wherever stored, using available mechanisms, particularly when storing personal data in someone else's system. You should not only encrypt it, but also, if possible, control access to that encryption. ADP does that for iCloud services.

The increased local fragmentation of data protection laws makes it more and more important to identify the location of customers and where the data the customers are accessing are stored. To simplify compliance, many organizations will have to carefully map customer-data location relationships and, in some cases, move data closer to customers. For iCloud, customers may opt to exit iCloud and instead use premise services. In particular, iCloud backups are relatively easy and affordable to host on premise.

As expected, and AAPL standing on principle given the difficulty in complying without putting all customer data at risk. AAPL had already given a small win to Government by making E2EE an 'opt-in' feature. The real losers in this brouhaha are the UK citizens.

This is going to get messy. This sends the message that Apple will remove more advanced controls from countries that demand them. This will probably be a patchwork of items. The question is, if you are traveling or residing for a portion of time in the UK but have this control enabled, are you violating the law? I am not sure yet how to decipher this.

Where to begin? First, we have yet to hear from His Majesty's subjects on this issue. It is much broader than Apple; Apple is merely the Canary in The Coal Mine. Second, it is about the money, about the cost of surveillance to His Majesty and the cost of Freedom and Security to his subjects. However, it is clear that His subjects will pay more for less effective and convenient security. Workarounds will be available but, almost by definition, workarounds are less convenient and efficient.

GOOG's intent is a little about security but more, much more about fraud. The real test is if the banking industry moves in this direction, as opposed to forcing you to use their app. Time will tell.

Back in 2016, NIST 800-63 advised against using SMS for MFA, largely due to sim-swapping and SS7 redirection risks. Today add the telecom provider (Salt Typhoon) attacks, and it's not any better. If the only choice of MFA is SMS, select it, but it's time to retire SMS / phone call verification and move to alternate options. Google is keeping the specifics of the change close, only indicating this change will be rolled out in the next few months. If you're already using a non-SMS verification mechanism, you will continue to use that mechanism.

"Nothing useful can be said about the security of a mechanism except in the context of a particular application and environment." --Robert H. Courtney, Jr. His First Law Google's approach, when they first offered strong authentication to their users, was to offer choices and leave them to the users. They should continue to offer OTPs via messaging, while adding QR tags as one more alternative. A better choice for Google users is Passkeys, secure and convenient.

I've been reading a ton into Quantum Computing over the last few weeks to try and get my head around how a Quantum Computer will defeat encryption. This is all about algorithm and how quantum superposition works. I recommend that if you have not been planning on Quantum safe algorithms, you start looking closely into them. It's best to take care of it now and not later. Who amongst us still doesn't support TLS 1.0?

As your signature/certificate issuing systems - such as Google's Cloud KMS and Cloud HSM Ñ start supporting PQC algorithms, you should be testing them to see where you have compatibility issues. It's far easier to change your issuing process to use a new algorithm, issuing updated certificates as they expire, than to do a mass re-issuance process. This is also a good time to make sure you're using the strongest non-PQC options available where compatibility is an issue.

The sad part is that I doubt Hirsch blaming their customers for purchasing their product will negatively impact their business. This is probably cheaper than fixing the issue, given the increased support cost. After all, Hirsch is not liable for any impact of its negligence.

And the blame game begins. Company: "It's the stupid users' fault." Users: "Did you really expect me to read the manual, why not just ship the product secure?" The question for judge and jury is, was the standard of reasonableness upheld in the design of the product? Methinks not, given that security best practices have talked about default hardwired credentials being a poor practice over the last few decades and it being flagged in Secure by Default/Secure by Design guidance.

For years it's been expected to change default passwords on installation, and for years, that has failed to happen. The new SOP is becoming a forced change on install; regrettably that isn't the case universally, so you still need to include verifying they are changed in your procedures for installing new software and hardware. Moreover, your network scanners should be able to check for default credentials; you should be leveraging this capability, think trust-but-verify.

Users of this system should implement the simple and obvious workaround. One may not like it but there is always a workarounds.

In short, governments are evaluating the ties between Kaspersky and the Russian government and how the extrajudicial directions from a foreign government can affect them (meaning threats of foreign government influence, espionage and sabotage), in this case deciding those actions would violate Australian law. This sort of assessment should be made when selecting products, and reviewed regularly, particularly after any mergers or acquisitions.

Psst. Quick, snarf up the data before April 1st. All joking aside, it does look like we are entering an age of bifurcated technologies that are available to some, banned to others, and highly suspect. Feels reminiscent of the cold war era in some regards.

Surely there are governments that bar products from companies that are associated with Five Eyes. If not, there ought to be. Long before AT&T was compromised by Salt Typhoon, Ma Bell was cooperating with NSA.

Turn off Smart Install. Every penetration test we are on, we test for smart install, and eight out of ten times, we find it on Cisco infrastructure. Not only do we see it, but we also find that most people are not testing for Smart Install, and we are the first to report it. This does not even include the fact that this bug is an RCE. We typically find the open Smart Install that gives us all the goods. Now, as far as credentials are used, how difficult was it to guess those credentials? Is it a single factor?

The takeaway is to not only make sure your boundary control devices are updated in a timely fashion (note the exploited flaw here is from 2018) but also make sure you're using best practices with the credentials, such as MFA and strong passwords which are rotated when compromised. Don't forget to limit where the management interfaces can be accessed from.

Unfortunately, we will never have confidence that the Chinese have been eliminated from our telecoms. The US Government is right in recommending alternative security. His Majesty's government has other priorities.