Collaboration

I’ve had the great pleasure of collaborating with Morey Haber for more years than we both probably care to mention. Over those years, our professional paths have crossed and intersected on several fronts. As CTOs at our respective identity management companies, we partnered and collaborated on client engagements, market events, and industry initiatives. Coming from separate “legs” of the now changing “three-legged stool of IAM,” we have always shared a brotherhood of IAM orientation and a distinct passion for the delicate intricacies that surround the topics of privilege, access, and security controls. During my time at SailPoint, we counted BeyondTrust as a trusted partner, and I considered Morey a good friend.

Morey and I also shared the unique alignment of transitioning into formal CSO/CISO roles within those same companies. For us both, taking on responsibility for product and corporate security was a logical career progression and something of great value to our companies. We have since shared many stories on the significant challenges and unique opportunities that come from being responsible for security inside a security company.

Every CSO has a tough job, but being inside the “security chain” itself is a whole different story. As more recent security supply-chain vulnerabilities have shown, being a link in that chain drives a certain focus and concern for yourself and hundreds of others. Under Attack may not have been the rock band Abba’s best-known single, but the title pretty much sums up the experience of being a CSO in today’s increasingly complex and interdependent security supply chain.

Morey asked me to write the Foreword for this book because of another prior successful and rewarding joint collaboration. As I hope the reader will already know, in 2019, we co-authored the third book in this series, Identity Attack Vectors: Implementing an Effective Identity and Access Management Solution.¹ That book was both interesting to write and intellectually rewarding to work on with Morey. Our conversations during that book’s writing were always a source of inspiration and motivation.

I’ve always found that when technical specialists from opposite corners of the same InfoSec “camp” come together in the center to “warm their hands” around the embers of a good IAM campfire, interesting things happen. Our unique perspectives, kept on track through the common thread of privileged access and entitlements, lead to what has been referred to as one of the industry’s leading texts² on using IAM technologies to enhance the prevention, detection, and mitigation of cyberattacks.

Cloud Attack Vectors

In name or in concept, the cloud may seem like a distant, faraway place, both above and apart. But today, even though most significant cloud providers run separate hordes of servers in isolated server farms, in every sense, “the cloud” has become endlessly entwined with itself (from one cloud to another) and with the existing on-premise information technology (IT) operations. The cloud and “traditional on-premise compute” are common bedfellows, as comfortable as Grandpa Joe and Grandma Georgina in Charlie and the Chocolate Factory by Roald Dahl. They are now so interrelated that they can only really be thought of as a single, end-to-end system.

The average enterprise data center is a complex mix of on-premise “legacy” systems, virtualized servers, and containerized complex web applications – all connected to and integrated with shared cloud infrastructure and cloud delivered Software as a Service (SaaS) applications (more on this later). As every IT practitioner knows only too well, today’s innovation is tomorrow’s legacy – so that mix of new and old goes on. Just like the books in this series, one builds upon the next until they make a stack. Our legacy systems support a hybrid cloud stack that employs a complex combination of on-premise and public cloud service elements.

All new and old systems contain data, privilege, and access that must be secured and managed throughout their life cycle. Quite literally, the “web of complexity” now spans cloud and enterprise. Ubiquitously adopted new-school CI/CD pipelines, DevOps, microservices, and an API-first economy have introduced an exponential level of complexity. This new, complex reality is littered with identities, user accounts, passwords, proxy access, keys, secrets, privileges, and fine-grained authentication and authorization access policies.

New cloud infrastructure entitlement models are shockingly complicated to understand and manage. They inevitably have data, access, and privileges bouncing back and forth across what can accurately be described as the IT blood-brain barrier. This security configuration and resulting IAM stuff, spanning cloud and on-premise, must all be accounted for, tracked, and managed, if we have any hope of retaining control.

In this, the latest book in what can only be referred to as “Morey’s Attack Vector Series,” the authors look across that cloud stack, with an IAM-centric eye, and carefully consider the people, the process, and the technology required to mitigate a myriad of potential issues.

Cloud Attack Vectors adds to the series of asset, privilege, and identity texts to focus on the essential cloud elements that live under, over, and inside everything we now do in enterprise computing. As you will observe, the more things change, the more they stay the same. This theme undeniably links the disciples from on-premise to the cloud, but breaks away from traditional best practices to resolve the same threats we have struggled with for years.

DevOps and DevSecOps (SecDevOps)

Today, most development organizations follow core DevOps principles and best practices in their application and software development processes, especially when creating applications for the cloud. In a DevOps approach, the overall application context is not delivered as a single whole. Instead, it is developed and delivered iteratively based on “modules and dependencies” that come together on a cadence that often goes down to the hourly level. Finding security vulnerabilities in such a complex, dynamic, and modular process requires focus. It is, therefore, no wonder that security is one of the core tenets of any DevOps process or system.

Each part of the application development, test, and operations life cycle is, by convention, responsible for understanding and managing the necessary security measures that ensure minimum vulnerability, while maximizing protection, detection, and mitigation. DevSecOps logically becomes the overarching methodology that unifies and coordinates the various security tools required during the DevOps life cycle.

Any high school–level cybersecurity textbook will quote the mantra, “application development starts and finishes with security.” DevOps people, processes, and technology are intended as the unification of that directive. Hopefully, removing the potential “security silos” that inevitably develop within a dynamic, independent, but highly interdependent application delivery process results in the inclusion of security in the same model. Hence, DevSecOps is now responsible in every sense. DevSecOps teams choose the tools that track and monitor their usage. DevSecOps engineers must understand the nuances of asset, privilege, access, and identity in their “new stacks” and their “existing legacy.”

In the cloud, DevSecOps is an attack vector – every part of the application development life cycle is poised to protect against cyber threats. This leads me to some “truisms” for consideration.

Perpetual Truths

One of the greatest things about writing the Foreword to this book is that I don’t have to hunker down and cook the full course meal – only the appetizer! I get the privilege and convenience of creating an abstract.

Having been in systems administration and, more specifically, security delivery for most of my 30-plus-year career in IT, I find great significance and considerable discomfort in the fact that nothing really seems to change that much. Of course, everything changes on the ground, in practice, in tools, and in approach, but somehow, it always stays the same.

So many of the lessons I learned from the “old mainframe guys” when I first started doing system administrative work have remained true. As I myself have worked through the coming and going of client–server, everyone gets a desktop (PC), Web 2.0, and now cloud and SaaS, so much has changed, but so much of what needs to be done to create good identity and good security has changed very little.

The cyclic nature of the underlying elements of IT is fascinating. The repeating cycle of distribution and re-centralization of systems design has already played out many times. The perpetual balance of homogeneity and heterogeneity has played out time and time again over the years. And, sadly, this perpetual cycle of innovation introduces complexity that is the ultimate enemy of all security systems.

These ever-repeating “trends” and their resulting costs are a source of career stability and, ultimately, intellectual frustration for many in IT. The fact that “everything is new, but nothing ever changes” personally drives me just a little crazy! As a programmer at heart, I hate repetition without automation. I can live with “Groundhog Day” if all I do is press the “replay” button without having to do it all from scratch every time.

Unfortunately, all too often, security program design and spending learn little from their past experiences. I never like to use the sour words of recent breach reporting as a proof point, but you’ve read the tech press lately, right? The phrase “shit happens” is a universal truth, and “here but for the grace of God go I…” is a secular truism. But that said, we should always look for the “perpetual truths,” the repeating memes, or “rules to live by” that sit above the changing drivers of security program spending. Some things do stay the same.

Visibility Is a Quintessential Control

Someone early in my career, probably at Tivoli Systems before it was merged into IBM (and, as I recently learned, a competitor to Morey when he was at Computer Associates managing teams with Unicenter), once said to me, “always remember you can’t manage what you can’t see.” This has remained true for me throughout my time at Waveset, Sun Microsystems, and at SailPoint.

Visibility is the baseline for any security control. An extensive, stable, and dependable discovery and inventory process is, therefore, the cornerstone of any asset, privilege, identity, or cloud security program. Any person, process, or technology in the IT security space should always start with asset management. Understand the scope, assess the weaknesses, and plan the mitigation. Cloud Attack Vectors follows this same principle, and Chapter 6 highlights the tools and techniques that help you get there from the weakest point – the people.

Complexity: The Sworn Enemy of Security

A podcast I highly recommend tuning into is Steven Gibson’s Security Now.⁴ Steve is a long-time programmer, hacker, technologist, and security practitioner who’s been a regular on my subscription list for many years. Steve has a repeating meme that has been a mantra for me in my time designing, delivering, and securing systems: Gibson always says, and I quote, “complexity is the enemy of security.” Oh boy, that is never more true than when deploying cloud and SaaS at scale. Remember, complexity creates the doors and corners where vulnerabilities lurk. Complexity in composition, configuration, and deployment is a likely cause in most attack vectors – cloud or otherwise.

To continue the somewhat curmudgeonly theme of this Foreword, I’m horrified and perpetually amazed by the level of complexity that I see in modern systems and infrastructure design. Any application that merges on-premise, private cloud, and SaaS is an Eddie Krueger¹ poster child for complex configuration. Of course, I fully understand and appreciate the need for that configuration capability, especially in an infrastructure-to-application “as code” model like today’s cloud.

But have we now gone hog wild? Just take a look at the manual pages for a K8 (Kubernetes) control verb, read through the security model settings for a Salesforce application, or worse, crack open the complexity of the end-to-end authorization model in AWS. It’s nothing short of mind blowing.

The IAM model that spans these systems is cut from the same complex hyper-weave cloth. One would have thought that, in the post-SAML and OAuth2 world, newer applications would, at least, have a unified authentication. Sadly, this unified, seamless experience rarely exists.

For example, I recently reviewed the IAM model deployed at a major retail bank. In just one of their complex systems, I counted five different forms of authentication spanning account passwords, keys, tokens, scopes, and attribute policies. Ouch – and let the pain sink in. The picture for authorization in these systems is often worse, with profiles, groups, roles, ABAC, PBAC, and OAuth scopes all hard-coded into an end-to-end system busting at the seams with rich complexity. These IAM “crimes” are not crimes of end-user convenience; they are simply the innocent result of a multitiered cloud system that strives for flexibility and functional supremacy in architecture and implementation.

Trade-offs

The cloud is not all complexity and risk. Far from it. In many ways, it is also a unique and exceptionally powerful inflection point, a time to review, redesign, and re-implement when considering the transition.

Consolidation and simplification themes reign on the field marketing banners of just about every cloud and SaaS offering these days. I wholeheartedly subscribe to that philosophy. I will always trade reduced cost, simplification, and better security to live “inside the box” with less customization and more shared intelligence. This is where the application’s use case stays the same, but the implementation can change for the better.

During my time as the CISO at a public company (yes, I could have said “when I was in the barrel”), like everyone, I had to make trade-offs. Trade-offs between vendors and applications, infrastructure and code, and cost and complexity. For me, the most powerful tool in that selection process was always the careful consideration of risk as a direct result of measured complexity. I’ve always come back to those memes or mantras that “you can’t manage what you can’t see” and balancing functionality with simplicity and security. Hopefully, this concept will remain true and valuable to you; it always has for me.

Have fun learning from the rest of the book.

—Darran