Compliance @ the Speed of Thought

Patrick S. Kelso, Head of DevOps Consulting – ANZ Region, UST Global

I was 18 years old and just starting out in my IT career when Bill Gates released his second book Business @ the Speed of Thought and to my shame I ignored it. Despite Gates being undisputedly the most successful geek ever at the time I was a UNIX user and ignore his book for many years. When I finally did read it, it invoked many “ahah!” moments and combined with The Phoenix Project by Gene Kim, Kevin Behr & George Spafford was largely responsible for me moving from the tech side of IT to the business side. What does this have to do with compliance you ask? Everything! It is in the business fable style of The Phoenix Project that I’ve written this article.

DevOps, cloud, automation, digital and containers, all the buzzwords that get anyone who uses them a barrage of recruiter messages on LinkedIn, but also the foundation of compliance at many of the banks I’ve worked at in the last decade. When I first moved into the finance world compliance was a dirty word, it invoked an urge to hide under the desk until the auditors had passed. We could definitely tell you who had access to a system now, but not who might have had access three days ago, let alone three months ago. Following our processes step by step never produced the same results no matter how many Change Approval Boards (CABS) we sat through who approved our changes and worst of all, a change scheduled for 5pm on a Friday evening meant cancelling all plans for that weekend because odds were you’d be spending it trying to unbreak the systems before business opened on Monday. (Heaven forbid you worked in a global bank and systems were expected to be online 24/7).

By adopting the same tools and processes the developers used to manage their code we could have a complete history of every change on any system and review it at any time

By automating the processes using tools such as Puppet, Jenkins and good old fashioned UNIX scripts automation changed compliance from a headache to an invisible layer of protection that we could trust. If everyone used the same Jenkins job to deploy applications and all they could change was the version, we knew that no one could change code in production servers, read the database without us knowing or install bitcoin mining code into our systems or applications.

By adopting the same tools and processes the developers used to manage their code we could have a complete history of every change on any system and review it at any time. “Who changed the web server to use version X of this application on June 22nd 2011”? “Glad you asked, that was Bob’s change, and approved by Jane and Anne and here is the reason it was changed”. All changes are immutable as future changes have their own unique ID that can be referenced globally.

One last anecdote to show the power of speed in responding to compliance risks. On the 7th of April 2014 I was flying from Sydney to Vancouver, a trip of about 14 hours. Not long after takeoff a vulnerability was disclosed in OpenSSL, a software package used by virtually every website and many other components of the web. When I landed in Vancouver and read about this I immediately contacted my team in Sydney to understand how this impacted our systems. “It’s solved” I was told. We pushed a new Puppet manifest to every server to upgrade OpenSSL and restart the affected services on all 5000 of our servers - that seemed like a large number in 2014 - we are up to date. Behind the scenes the team had contacted the bank’s risk team and explained the seriousness of the issue, an emergency change was approved, and the work performed immediately, such was the confidence the risk team had in our tools because time and time again we’d updated packages without outages since adopting automation. Some companies I know still had unpatched systems monthslater.

By automating we can move faster, share information faster and truly operate all aspects of our ‘business @ the speed of thought’.

If your risk/compliance team doesn’t understand the tools they can’t trust them, have a conversation today to make sure that both IT and Risk understand what is and isn’t possible to maintain compliance with whatever regulations or industry codes you need to and remove the manual steps, every manual step is an opportunity for a mistake to creep into a process, after all, we are only human.