Well there's not really going to be much in there that's not pretty much industry standard, that is to say there's a database of our data, enciphered with an appropriate symmetric cryptographic algorithm (Likely AES256), where the key is protected by an asymmetric key pair of a modern algorithm (probably an elliptic curve), where the private key was generated in an HSM (Hardware Security Module), where the HSM may or may not be FIPS-140-2 (or now possibly even level 3) validated. All of this is pretty run of the mill for military, government, financial services.
Access to the data centre itself should be mandating multifactor authentication and likewise they mention logical system access via multifactor tokens and also a large part of the overall security will be implemented not only by technical constraints but also by policy and procedure. Again, all standard operating practice for this sort of scenario.
So just to throw some darts at the board...
"Our engineers created a new “personal information vault” project. This vault uses modern algorithms to encrypt sensitive information in a way that would require both enormous computing power and an enormous amount of memory for an attacker to crack… if they could even get a copy of the encrypted data."
We're using standard AES256 cipher for block encryption and Elliptic Curve cipher for the Asymmetric key. Private key marked as non exportable and held in an HSM.
"And all of this new encryption is wrapped around the encryption we already used - encryption which was the industry standard at the time."
Yeah, that's the "We already encrypted the database with standard ciphers such as AES256 but in SL we only stored the key in software".
"These are entire new layers using encryption technologies which didn’t exist when Second Life was new. "
Well hmm... https://en.wikipedia.org/wiki/Elliptic-curve_cryptography
The use of elliptic curves in cryptography was suggested independently by Neal Koblitz and Victor S. Miller in 1985. Elliptic curve cryptography algorithms entered wide use in 2004 to 2005.
"Even after all of these changes, the old protection remains in place at the bottom of that stack. Figuratively speaking, we locked the old vault inside a bigger, stronger vault. We chose an approach where we didn’t need to decrypt information in order to enhance your protection. "
This is consistent in my mind as to "vault within a vault" being an encrypted database with a better protection for the block cipher key. No need to decrypt what was already there, just provide stronger key protection, the symmetric block cipher key remained the same.
"There is another key part of this project: Our storage mechanisms for sensitive customer information are now isolated from Second Life. The information isn’t stored at the same physical location anymore, and hasn’t been for a while. But the difference is more than physical. "
Means "We had to buy a bigger USB stick to throw it across the room"
"Second Life’s servers do not have direct access to Tilia information that isn’t required for daily Second Life usage. Even developers who have worked at the company for a dozen years - developers who have full access to every last Second Life server - do not have access to the servers that store and protect the most sensitive information. A policy of least privilege means fewer opportunities for mistakes. "
Did those developers EVER have full access to our data and if so why? That should never have been a requirement. Even in the case of development, that should be on a development environment without live data, the live data shouldn't ever be accessible - period!
"This means that compromising one database inside of Tilia is insufficient to decrypt and correlate sensitive data without compromising a different service."
A segmented architecture, multiple databases, each with its own symmetric key, protected by own key pair thus would require compromise of multiple keys/systems, yes normal stuff here.
"We have deployed numerous commercial products which help monitor for access, abuse, or data copying attempts for data that is made available to Tillia employees. This means that even an attacker with all employee access credentials, access to employee multifactor authentication tokens, and all Tilia access permissions would still face some challenges in avoiding early detection. "
We've installed Splunk because it's free! Joking aside, they've deployed one or more SIEMs (Security Information and Event Management software) and some IDS (Intrusion Detection System) software to monitor along with probably some agent based software to monitor PC behaviour and possibly thrown in some CASB (Cloud Access Security Broker) software just for fun.
What I haven't seen is any mention of how they'd handle the situation where a family member or two is kidnapped and the attackers have set up a live feed of the electric drill being held to the eyeball of the staff members youngest child. Which when the prize is rich enough is the upgraded version of:-
Overall, what Soft Linden describes and what I believe (I also believe in aliens), is distilable to pretty much standard good operating practice for the service being operated.
There are also existing services which allow a user to scan government documents, take a selfie, have that validated and a confidence factor returned to the calling service. No data is stored, there's no need once the ID result is validated. I'd be curious to know why LL hasn't gone down this route.
I note that Soft Linden didn't explicity call out blockchain anywhere but they may or may not be playing with that too, because some people feel it's trendy!
All of the above is based upon supposition and interpretation of the end user facing blurb posted below and I have no further insight other than the ability to read and interpret based upon experience.