I'll play. I worked at a financial institution for several years. On the one hand you'd think we were secure because we used a relational database, but we also had a heavily segmented network with all of the databases in their own VLAN's with highly restrictive permissions. On top of that each application was locked down to exactly which data it could use and what could be done with that data.
So if you buy the premise of the article, it wasn't NoSQL, so it must have been secure. In reality we were very secure from external breaches, at least as secure as you can reasonably be.
Personal information was secured to the maximum extent possible. Encrypted, backed up to multiple independent tapes stored in separate locations etc. On the other hand, the overall complexity of the system was very high and if someone breached our network there would have been a very large surface area to attack. I didn't feel like the article addressed this aspect of security in the least. Security just isn't one of those things that are easy or are ever done. It takes constant vigilance and continuous adjustment and improvement.
Did your institution go the seldom traveled route of encrypting sensitive information? Typically all the effort is spent trying to avoid breaches instead of protecting against them when they occur.
Initially it was not encrypted and was stored in plain text in the database. Then we started encrypting sensitive information at rest, both the database files and the backups. We also encrypted certain sensitive information with a secondary encryption. The next massive undertaking was to find all of the processes that use the data, how they use it - both internally and externally, and then ensure the data was protected throughout the entire process. The company was still working through that process when I left. They had identified many places that were problematic and were actively working on fixing them. The team I managed was the payment processing and cash management team. There were a number of legacy systems written in access, fox pro, DTS, Excel even. Many of those were the most painful, and frankly the most problematic.
Many people were put in a situation where the requirements for getting something implemented through the IT teams would take months, yet they were still held accountable for getting things done, so they would build an Excel process to get the job done. They would build some fantastic process, and get promoted, then that Excel system would get dumped on either someone in IT or someone replacing them.
I'm getting off track, but looking at it superficially the data was encrypted. If, however, you watch the data through it's entire value stream, there are many places it is vulnerable. Given the state of affairs in most companies and how few of them think in terms of managing value streams, I expect my observations are fairly widely applicable.
So if you buy the premise of the article, it wasn't NoSQL, so it must have been secure. In reality we were very secure from external breaches, at least as secure as you can reasonably be.
Personal information was secured to the maximum extent possible. Encrypted, backed up to multiple independent tapes stored in separate locations etc. On the other hand, the overall complexity of the system was very high and if someone breached our network there would have been a very large surface area to attack. I didn't feel like the article addressed this aspect of security in the least. Security just isn't one of those things that are easy or are ever done. It takes constant vigilance and continuous adjustment and improvement.