This interview was first conducted and posted by our friends at CRFT
Can you give us an idea of your background?
I have spent the vast majority of my career working within mission-critical environments. My career began at Bell Canada’s Government Security Operations Centre (GSOC) in 2004, with a focus on situational awareness and threat detection. In 2008, I was seconded to help build out the Security Operations Centre (SOC) for the Vancouver 2010 Olympic Winter Games using a SIEM and a custom data enrichment toolkit. The Olympic project was my first exposure to Cloud computing and to the bleeding edge concepts of ephemeral and immutable systems.
What was your initial reaction to the Cloud computing paradigm?
I was naturally skeptical of The Cloud. Using “other people’s computers” for anything mission-critical seemed risky. However, I was more concerned with the lack of security capabilities and how our SecOps team would be able to detect and respond to attacks within such an unfamiliar architecture. We lived and died by the accuracy and availability of the log, and Cloud with its ephemeral nature turned SecOps into a shell game.
After the Olympics, I began consulting within the private sector, where many organizations were either exploring or actively adopting Cloud. At the time, I thought it was a terrible idea: native security capabilities were not there, and SecOps tooling did not translate well. The early Cloud adopters were “agents of chaos,” drunk on “business enablement” and apathetic to the practical security concerns. I advised clients against moving to the Cloud, resisted learning about the new tech, and for a time, was certain that risk-averse sectors such as government and finance would never transition.
I was wrong. Finance and eventually government gradually turned “cloud curious,” and the cloud-native security capabilities evolved. At the same time, after spending the past five years assessing security postures and capabilities of enterprises, I had realized that the legacy environments in the private sector were far from perfect. The increase in breaches had triggered enterprises to buy more security boxes, and yet the majority of these organizations were still struggling to avoid breaches. While they did increase spending on cybersecurity, they did so asymmetrically, negating to implement the ‘unsexy’ security fundamentals.
Governance was boring, network segmentation was too expensive, system hardening was, well, hard, and patch management arduous. Almost every client I assessed was missing the same foundational security capabilities and had little appetite to change, culturally. They just wanted to buy more tools. This was when I realized that the private sector was likely never going to be great at these foundational security capabilities. On the other hand, Cloud Service Providers (CSP) had been maturing their native security offerings and began providing turn-key and “managed” capabilities for many of these fundamental cybersecurity pain points.
That is when it hit me: Cloud can enable better security, if you let it.
How would you categorize or describe the majority of the Cloud projects you've been involved with?
Canada has been slow to adopt Cloud computing. A combination of our privacy protection laws and general concern over the privacy of our data on US servers created an initial adoption lag for most public and private sector organizations. However, with pseudo-sovereign AWS and Azure regions now in Canada and with the overall change in attitude, we now see organizations across all sectors embrace the Cloud.
The majority of my team’s Cloud projects have revolved around ensuring the governance, regulatory, compliance and privacy requirements. We see two camps of customers, those who want to use Cloud, but to do it right and, more commonly, those who are already in the Cloud and had an “Oh Sh!t” moment.
What have you seen as some of the more unusual drivers of Cloud security programs?
I have been genuinely surprised to see Sales teams, and not, say, SecOps or risk management, at the forefront of driving the adoption of a mature Cloud security program. In the past two to three years Sales teams frequently hit a wall. Potential clients looking to manage their supply chain risk and privacy obligations, are now asking how the suppliers manage risk. More often than not, the Sales team loses the sale because their company is unable to articulate a meaningful security program beyond some rudimentary controls.
Companies which have aggressively built out their IT and adopted Cloud without inviting security to the table are now at a disadvantage and losing business. Those, on the other hand, which have taken Cloud security seriously are gaining customer confidence and overtaking the competition.
Where do you see customers having to adapt to new practices when moving to the Cloud?
The initial adoption of Cloud was driven by developers trying to elude IT, IT trying to bypass security, and CIO/CTO trying to get out of the data centre business. This “cowboy IT” adoption of Cloud has resulted in non-existent security capabilities, shadow environments, and the migration of tech debt outside the walled garden.
As one of my mentors once said:
“If you suck at security in the data centre, you can totally suck at it in the Cloud.”
I think the first cybersecurity challenge in Cloud adoption is figuring out who is the adopter and what are the advantages that they seek. Every practitioner, cybersecurity included, will have differing incentives for this move. Cloud services, generally speaking, will meet each adopter’s requirements by managing some underlying responsibilities. However, Cloud migrations within most companies are often siloed, failing to approach the adoption from a holistic, enterprise-wide perspective.
I believe the biggest challenge we face from a risk management perspective is the conventional treatment of Cloud as if it was someone else’s data centre. CIO/CTO’s want to get out of the data centre business and save money, so new technology makes sense. However, the perceived path of least resistance is “lifting and shifting” servers into Cloud. This approach directly correlates to “Bringing Bad” and will be unlikely to realize any cost savings.
IT likes their warm blankets, and there are IaaS services that will provide that comfort: virtualized servers. However, the real power of the Cloud is the PaaS, and the server-less compute capabilities, which are usually entirely foreign to traditional IT.
Have you observed any fundamental shifts or changes in the field of Cloud security in the past 3-5 years, in terms of technology, practices, or both?
Yes, I have, in the sense that “cloud security” is now a thing.
When I was first introduced to Cloud Computing in 2009, there was no security at all. Servers were public, host firewalls were the consumers' responsibility, and logging capabilities were archaic. What has fundamentally shifted my perception on Cloud security is not so much the traditional security vendors catching up, but rather the Cloud-native capabilities that can be baked into every build and support the cybersecurity mission.
What would you consider some of the most prominent gaps in Cloud infosec today?
There is a common misconception that the CSP has your back and is monitoring for security incidents. Yes, they do have some threat detection as a service offering, and if your account is compromised and is impacting other organizations, you will be notified. But for all intents and purposes, what you would typically consider a security breach in your account, is likely to not be considered a breach by your CSP.
Can you think of any technologies or practices which Cloud security teams find particularly helpful?
What really made me “flip a bit” on Cloud was the opportunity to deploy infrastructure as code. Again, after assessing a myriad of corporate environments, I repeatedly observed the private sector building out IT like snowflakes and patchwork quilts. This lack of consistency created extreme dependencies on tribal knowledge, increased complexity from a SecOps perspective, and delayed recovery times. Cloud introduced an opportunity to deploy IT in a consistent and repeatable manner, but only if you let it.
The capability to deploy infrastructure as code meant not only consistency but also measurability. It supported the ability to standardize builds, audit code before deployment, as well as audit the running infrastructure against a golden standard. This capability does require an increase in process maturity but pays dividends when it comes to audits and maintaining compliance.
Detection and response capabilities work differently in the Cloud but are potentially even more powerful. In legacy environments, we are used to monitoring logs based on hostnames and IP addresses. However, in the Cloud, we have to give up on those data points. The systems are ephemeral, so instead, we focus in what the humans, scripts and Cloud assets are doing. Everything in Cloud communicates over a common management backplane. The API based logs have tremendous value in increasing situational awareness of the environment.
Lastly, Automation is the natural progression of the codification of IT. The primary use case is automating the deployment of infrastructure, but I am most excited about the ability to detect policy violations and breaches in real-time and having the robots respond with corrective actions. In legacy environments, an audit is performed, and for a while, the organization is compliant. However, the environment naturally drifts away from that state of compliance, putting the organization at risk. Cloud automation capabilities enable enterprises to have continuous compliance and automated remediation capabilities.
Thank you for sharing your experience with us, Alex.