Forward: Security Is Still Not Considered Very Important

The first rule of business is to survive – Peter Drucker

It was the dawn of the Cloud era, the year was 2012. Software as a Service, or SaaS, was a new term. I was brought in to build a governance, risk, and compliance program at a popular streaming music platform experiencing its brief heyday. Expectations for global success were through the roof, and in hindsight, unrealistic. What we actually were was an upstart ad tech platform that streamed human-curated music according to an algorithm. We paid more in royalties to the recording industry than the revenue we brought in by serving ads to our customers, most of whom just wanted free music and weren’t ever going to pay for a monthly subscription fee.

We were also what was known at the time as “cloud-first.” This meant running lean by utilizing low-cost, cloud-based solutions to conduct company business, instead of relying on higher-cost, on-premise solutions. Theoretically, “cloud-first” provided a competitive advantage. Enterprise Internet solutions for resource planning, customer relationship management, project management, procurement, HR, sales analytics, data visualization, and collaboration were turning the tables. Suddenly there was a viable alternative to expensive on-premise solutions.

The cloud-first hype was that enterprise business software available from anywhere represented freedom from drudgery – freedom from software installations on personal computers, from application and server updates, from out-of-band security patching. And, maybe the biggest factor, cloud-based systems were the magic gateway to unlimited remote collaboration. Work from anywhere. What could go wrong? A lot, as it turned out. Cloud solutions were not turnkey, but required IT resources. And they were not designed for security. Security would be bolted on by the vendor later, if at all, sometime after the solution had gained a competitive foothold, which might never happen.

A sprawling shadow cloud was forming, organically, without our knowledge and beyond the control of our on-premise world. Product development, marketing, customer support, finance, purchasing, revenue, and engineering teams were onboarding consumer grade versions of cloud software using personal credit cards. It wasn’t clear which groups were using which cloud apps to get the work done. We needed to slow down and put guardrails in place before admitting new vendors to the party. At least, that was my take....

I shared this information with the VP of IT, thinking he’d want to hear it. 

“People are using just about any cloud app available to complete their work and meet their deliverables. They aren’t coordinating with IT, or Purchasing, or even their superiors. They are putting down personal credit cards to do company business. We find out about it when the free service they signed up for expires and they ask for help because they can’t log into the cloud app where our sensitive corporate data and customer data is stored.”

“Yeah,” he said. “They shouldn’t be doing that. Look,we both know that most security problems are caused by unpatched servers and someone’s account being compromised. Maybe focus on that."

“This is something new,” I responded, all my reasons ready. “We probably don’t know half the cloud apps in use, let alone the data being shared. People are sharing accounts, and using privileged admin accounts to do daily driver work. Legal team thinks this is going to become a liability. We need a secure front door, an authentication portal to this ad hoc business cloud. We need a vetting process for random vendors being requested and onboarded. ” 

I felt like I'd presented too much info at once. I was right.

He agreed a secure cloud portal would help, but disagreed that cloud vendor assessments were necessary. They would only slow down enterprise business objectives.

I said: “When you let people use any tool available to complete work on behalf of the company then you don’t really know how the work is getting done, who has access to sensitive corporate financial data and IP, who is eavesdropping…”

The guy who hired me into my security role interrupted me. “You should know. I don’t really believe in Security.” 

Awkward pause.

“You say you don’t believe in security, then why did you hire me?“ I responded, half joking.

“Because we need to show that we have someone in the position,“ he replied, also half-joking. “If it was up to me, I’d just hire IT people to do security, they’re cheaper.” 

Ouch. The double dig held some harsh truths. Truths that still apply today.

Security practitioners still struggle with making people understand that we do more than patch servers, push security updates to devices, and monitor for alerts. We still struggle with communicating and operating transparently. And yes it is true that security roles, especially management roles, exist at least in part so that there’s someone to blame for a security incident or data breach,

But the digs weren’t the point. The VP of IT’s message was that my team playing compliance cop would cause friction he didn’t want to deal with. Preventing ad hoc use of unsanctioned, unapproved, unknown cloud apps would inhibit work in progress, and put deliverables and SLAs at risk. We were, after all, a startup moving at “Internet speed.” 

…

A decade later I came upon a paper written by Andrew Olydzko titled, Security Is Not Very Important. One of his observations reminded me of the “I don’t believe in Security” comment from my boss: 

"It is very hard for technologists to give up the idea of absolute cybersecurity… they are not used to thinking that even a sieve can hold water to an extent adequate for many purposes."

Enforcing  secure authentication to a secure  business cloud environment was too soon for that firm in that situation at that time. A common portal requiring multi-factor authentication, and continuous monitoring and re-assessment of third-party parties, was not a priority when in perpetual survival mode.

The maturation of any Security program is going to happen when the situation allows or forces it to happen. Not at the pace we wish for, but when the situation is ready for it, which is always slower than we’d like.