Your management gets a great demo from a cloud vendor and decides that the organization needs to implement the new service/application/etc. quickly. Your team tries to comply, furiously learning and experimenting with integrations, software changes, infrastructure configuration, and more. Things get deployed are working. Clients and management are happy with the new capabilities and you breathe a sigh of relief.

After a bit of time there's a security issue and all of a sudden there's blame pouring down on everyone. The vendor takes a hit because it's a public security problem, but the reality might be that your organization didn't completely understand how to configure strong security. The public doesn't blame your organization, but internally your team don't know how to make changes to ensure future security.

That's a bit of what happened with the Snowflake customer hacks, and a good description of some of the issues is in this piece from Joey D'Antoni. Snowflake didn't necessarily have bad security, but they allowed customers to have bad security and also limited the options for customers to implement stronger security.

I think about this all the time as I look at the challenges of security that many organizations face. In my decades of working in different situations, the one thing I know is that pressure to move fast often creates security shortcuts. Much of the early security problems with SQL Server could easily be traced to a) allowing installs with no password, b) developers not understanding the security model and granting sysadmin (or using sa) in their applications, and c) management agreeing that this was OK because a deadline needed to be met.

In all these situations, workers had the best of intentions to go fix things later, but there was rarely the time or energy to do so. As someone who forced apps to change away from sa in a large org, and required separate accounts and passwords for servers, I can tell you no one liked me and I got a lot of pressure to leave things alone. That is until I could explain the risks to managers with security people present. Even then there was no shortage of people who wanted me to assume the risk of apps using sa and let things be.

Cloud security is pretty good from the major vendors. Most of the smaller co-location facilities I've worked with in the past also had good security. It was the clients that caused problems, often because of a lack of knowledge or the desire to hurry.

Joey says Entra is a great system. I agree, and I love the SSO capabilities I've seen implemented. I also know that trying to set things up and configure them has been difficult for me, and I think I can be pretty sharp about lots of technology. Joey has patiently answered many of my ignorant questions because I didn't understand how some part of Entra (AAD) works. I think lots of tech people don't understand this and don' t necessarily have a Joey to call on.

Most of us working in technology need more security education, better habits, and the patience to implement strong security. That includes management. At the same time, I wish that the solutions out there were easier to understand, or maybe better explained for those of us who need to use some portion of the authorization and authentication systems in our software.

Unfortunately, security software is still software and those vendors push out changes and updates quickly as well, leaving education and documentation to the user. This is a bad situation that continually arises with regular issues in many organizations.