The Glut of Repetitive “Cyber Security” Webinars

I like to be informed on whats hot in cyber security. Most of the time, it’s in the form of webinars. However, after this week, I realize after attending five “How To Improve Your Cyber” events, exactly the same advise was repackaged and presented:

  1. Patch Your Systems
  2. Backup Your Systems
  3. Harden Your Systems

Let’s Take Colonial Pipeline

Anyone doing a webinar on how exactly Colonial Pipeline got hacked? What tools were they using? What security framework? How big was their security team? Outsourced or SOC? SIEM? EDR? Automation?

“Disclosing these technologies would be a security vulnerability in itself. No company is going disclose security details”

I totally get it. But let me challenge you on this: Are you teaching people how to fish or just telling them to fish?

Most of these cybersecurity webinars are telling people… not teaching.

Be prepared for harsher feedback, because educating cyber leaders and pros with arguments substantiating the same advice is repetitive and making me want to not click “register”.

\\ JMM

Hosting Upgrades 2020

This week, we’ve moved the website from NameSilo hosting over to Greengeeks.com

Deployment of Let’s Encrypt SSL certificates to the website was the big reason for the move. I am very surprised by the web hosting orgs that don’t provide this solution for the one website customer.

\\ JMM

Why Are Some MS SQL DBAs Resistant To RBAC?

A question for education purposes.  Historically, MS SQL DBAs are resistant to RBAC strategies involving integration with Active Directory (AD). In other words, controlling permissions to DBs via a AD role based access control groups is met with considerable resistance by DBAs. And some legacy application owners, to be fair.

Why?

Some context:  Microsoft released a video in 2011 during TechDays outlining an RBAC strategy that has worked in previous organizations, both small and large.  Very popular video.  Once decided that is the strategy, getting that philosophy into practice has not been easy.  It usually starts with the on staff seasoned IT pros looking at RBAC with suspicious and doubtful eyes.  “I’ve never done it this way” and “I doubt this will make our jobs any easier”.

Nevertheless, once the concept takes hold RBAC begins to see fulfillment.  Foremost adding predetermined resources to roles accelerates onboarding, easier to audit resources, and scales elegantly as we grow as roles are the focus.  Typically, architects and server teams get on board first.  A standard is born and acceleration begins to be felt, including shifting left where DBAs are doing less security permissions requests as those are now handled by the helpdesk.  In the meantime, slowly and begrudgingly, outliers come on slowly as this strategy does shift stances from caring for the security of their apps like pets to managing access to resources by role.

I posit these reasons, given to me as why DBAs (or application owners) want to go it alone:

5. Microsoft isn’t always right.  “There is more than one way to do it and the “video” isn’t applicable to SQL”.

4. The amount of work to shift to resource-based groups.  “Lots of groups.”

3. The complexity.  “Easier to troubleshoot when I own the DB or application’s security intimately.”

2. Fear what they don’t understand.  “I’ve never done security permissions like this, so it must be wrong.”

1. Territorial control.  “Don’t touch my DBs”.  Uncomfortable shifting left.

This is very much a pets vs. cattle conversation.  I acknowledge and appreciate SQL must be tweaked and tuned to operate at it’s best performance.  However, I disagree that treating ‘access control to resources’ like pets accelerates IT service delivery, provides uniformed information security governance, and ultimately is healthy for the organization.  Especially as organizations’ scale.

What is your opinion?

\\ JMM

PS. More and more companies are using automated access control oversight tools such as Sailpoint. And at a previous company, guess who fought the hardest against that move? DBAs… Why?