Postmodern Security

Why do I assert most programs are failing? Because it’s not getting any better. Just look at the 2021 holiday gift that was Log4J. Could the problem be with our approach? Some treat Information Security programs as a finite linear progression from an imperfect current state to a future improved state, or worse, a Sisyphean exercise in modern ennui. Both approaches are built on a foundation of coercive legislation that highlights failure, a corporate Crime and Punishment.

In truth, information security initiatives are exercises in change management. Security programs fail for the same reason many change initiatives fail: poor change management. The failure rate of change efforts commonly reported in books such as Paul Gibbons’ The Science of Organizational Change can range between 20% – 80%, depending on the type (2019). Even if the lower figure is more accurate, a failed change effort could still damage profitability and an organization’s reputation.  

A common theme emerges from the academic literature on successful change management approaches: the importance of collaborating with and respecting those individuals being asked to change. Most of the authors seem to agree on fundamentals such as recognizing the importance of change recipients’ emotions (Branson, 2008; Choi & Ruona, 2010; Dahl, 2011; Williams & Tobbell, 2017), engaging members of the organization to hear concerns and feedback (Choi & Ruona, 2010; de Waal & Heijtel, 2017) and fostering a continuous change environment by creating a learning culture, even when using coercive change methods (Canato et al., 2013;Choi & Ruona, 2010).

Building a continuous change culture is observed to be the greatest support to change success (Choi & Ruona, 2010; de Waal & Heijtel 2017; Hansen & Jervell, 2015). By establishing an anti-fragile organization that constantly adapts to meet new challenges, the need for large, heavy change efforts that fatigue employees is reduced.

Information Security programs could benefit from these approaches. The initiatives tend to be transformative for organizations, focusing on multiple domains of culture and technology. However, while there is information security academic literature that discusses the importance of change management planning (Ashenden, 2008) and attention to creating a security culture (AlHogail, 2015), the approaches often focus on empirical-rational strategies (Choi & Ruona, 2010) that are coercively implemented by security leadership.

BECAUSE us girls crave respect and authority in our chosen field of Information Security.

BECAUSE we wanna make it easier for girls to see/hear each other’s work so that we can share strategies and criticize-applaud each other.

BECAUSE we must infiltrate the Infosec field in order to create our own destiny.

BECAUSE I am not your mother, your sister, your wife or your girlfriend. So when I speak with authority, keep your emotional baggage and neuroses to yourself.

BECAUSE we recognize fantasies of a macho security dictatorship as a set of impractical lies meant to keep us simply dreaming instead of creating the revolution in Information Security by envisioning and creating alternatives to the bullshit military-posturing way of doing things.

BECAUSE we want and need to encourage and be encouraged in the face of all our own insecurities, in the face of beergutboyinfosec that tells us we can’t play in their sandbox, in the face of “authorities” who say our skills are the worst.

BECAUSE we don’t wanna assimilate to someone else’s (boy) standards of what is or isn’t.

BECAUSE we are unwilling to falter under claims that we are reactionary “reverse sexists” AND NOT THE TRUEINFOSECCRUSADERS THAT WE KNOW we really are.

BECAUSE we know that information security is much more than just reactivity and are patently aware that the punk rock “you can do anything” idea is crucial to the coming angry infosec grrrl revolution which seeks to promote the psychic and cultural lives of girls and women in our profession everywhere, according to their own terms.

BECAUSE we are interested in creating non-heirarchical ways of being, collaborating and working, based on communication + understanding, instead of competition + good/bad categorizations.

BECAUSE doing/reading/seeing/hearing cool things that validate and challenge the status quo can help us gain the strength and sense of community that we need in order to figure out how bullshit like racism, able-bodieism, ageism, speciesism, classism, thinism, sexism, anti-semitism and heterosexism figures in our professional and personal lives

BECAUSE we see fostering and supporting girl infosec professionals of all kinds as integral to this process.

BECAUSE we see our main goal as sharing information and supporting allies over making profits according to traditional standards.

BECAUSE we are angry at a society that tells us Girl = Dumb, Girl = Bad, Girl = Weak, Girl = Not technical.

BECAUSE we are unwilling to let our real and valid anger be diffused and/or turned against us via the internalization of sexism as witnessed in girl/girl jealousism and self defeating girltype behaviors.

BECAUSE I have run out of time, patience and f*#&s in pandering to egos.

BECAUSE I believe with my wholeheartmindbody that girls constitute a revolutionary force in information security that can, and will revolutionize our profession and the world.

*Based on the original Riot Grrrl Manifesto by Kathleen Hanna and Bikini Kill.

You may laugh at the image above, but for many of us, similar absurdities can be found in our own policy frameworks. Governance matters, because badly written, confusing policies and standards will drain the productivity of your technical teams as they run around trying to figure out what’s actually required. Cormac Herley expressed this lunacy best in his paper, So Long, And No Thanks for the Externalities: The Rational Rejection of Security Advice by Users:

“Given a choice between dancing pigs and security, users will pick dancing pigs every time.” While amusing, this is unfair: users are never offered security, either on its own or as an alternative to anything else. They are offered long, complex and growing sets of advice, mandates, policy updates and tips. These sometimes carry vague and tentative suggestions of reduced risk, never security. We have shown that much of this advice does nothing to make users more secure, and some of it is harmful in its own right. Security is not something users are offered and turn down. What they are offered and do turn down is crushingly complex security advice that promises little and delivers less.

As security and governance professionals, we are trusted stewards for our organizations. We have an obligation to ensure that individuals make good choices by clearly communicating our expectations. Otherwise, we just come off like institutional bullies.

When I start a new position with an organization, the very first thing I do is review the policy framework and its contents. I don’t dig into the network diagrams. I don’t pester security engineers for current vulnerability findings or pentesting reports. I don’t even look at the strategy content first. Why would I spend time reading documents that are basically the digital equivalent of a sleeping pill? Because policies, standards and procedures represent the manual of an organization. Spend time reviewing it and you’ll soon discover how mature the security program really is.

Maybe I developed this habit from my time as a Unix engineer. In the days before Google and ubiquitous wireless, you had to know how to read man pages and use them to solve problems quickly. There were many times I would be sitting in an icy server room at midnight without a network connection, trying to figure out why a volume wouldn’t mount or a NIC wasn’t working, but apropos or man -k saved me. The CLI was the way through those troubleshooting sessions by uncovering various arguments and switches found in the man pages. It made me a better technologist, because I learned that good engineering is as much about documentation as it is about delivering a solution.

And yes, I was that person who when asked by a junior tech how to do something in *nix would respond with, “Man $insert_command_here.” I even threatened to change my middle name to RTFM at one point. While there was a part of me that reveled in the superiority of having pierced the highest levels of esoteric knowledge, I also genuinely wanted people to appreciate the elegance of a system that allowed you to have all the tools you needed to troubleshoot it.

Recently, I realized that an organization’s policy framework and its contents function in a similar way. You can learn how leadership prioritizes risk and empowers its governance team (or doesn’t). You can uncover processes and the inner workings of different business units. You’ll also find out quickly how dysfunctional the security program is based on the breadth of the content and how well it’s organized. Tedious, circuitous and often bloated, policy documents can be a challenging source to mine for intelligence, but it’s the best place to start. So, RTFM your organization by reviewing its policies and standards, otherwise you’ll struggle to separate the valuable elements of your program from pure security theater.

Lately, possibly as an outcome of the neuroscience-light infusing our mainstream culture, corporate-speak has started including some disturbing expressions into the jargon. One of the most egregious, “assume positive intent,” has become ubiquitous with both leadership and human resource departments. The underlying notion is that in our interactions with others, we shouldn’t assume negative intentions, only positive ones. But given the difficulties surrounding diversity and inclusion efforts across corporate America, isn’t this notion of assuming intent dangerously ingenuous and possibly conflict-avoidant?

The roots of this notion of assuming intent likely arise from the well-publicized concept of the psychological negativity bias. It’s part of human evolution, this self-protection mechanism in our biology that seeks to identify threat and push it away. While our threat response system is useful in life-or-death situations, it’s not always helpful in our day jobs. How do we learn to circumvent strong emotional protection responses in order to allow us to make better choices in the corporate world? The thought is that if we can scrub the interaction clean of any negative emotions, then we can propel a more positive conversation. This is based on a cognitive bias called the “framing effect” and the psychological technique of “cognitive reframing.”

However, humans’ emotions and their interactions are far more complex and nuanced. While this reframing can be useful, it doesn’t take into account factors such as individuals’ predisposition for positive or negative affect, socio-economic context, how the negativity bias tends to attenuate with age or even the limitations of reframing. Moreover, when speaking to a disenfranchised person or group, ideas like “assume positive intent” can quickly turn into gaslighting and conflict-avoidance, a way to short circuit an important conversation about real inequity that could resolve and prevent a bigger conflict. It’s imprudent to think reframing alone can be used as a shortcut around the critical practice of conflict resolution.

What we really need in our interactions are cognitive placeholders in our conflict resolution playbook. Cues that allow us to stop, evaluate and reconsider the emotional undercurrent in an exchange with another person. Reminders for when it’s time to step back and recalibrate. Maybe the better approach is to assume no intent, but when hearing something that gives rise to concern, be ready for a professionally intimate conversation rooted in authenticity.

I’ve been working in the DevOps space for a few years now and there’s no better way to send me into an episode of nerd rage than to encounter tragically misguided attempts to implement DevSecOps. Generally, this is due to security people who are uneducated in the basics of good DevOps practices and a misunderstanding of the collaboration necessary to be successful with integrating security into the process.

The following is a list of some common DevSecOps myths I’ve encountered:

• Special tools or software. While DevOps-friendly tools are nice, you generally don’t have to go out and buy a lot of new security software. Often, you can integrate existing controls or even (gasp) use open source. No amount of vendor hype is going to magically add that dash of DevSecOps to your pipelines. To the people going on buying sprees, I have one thing to say: Please.Stop.
• A separate software development initiative. One of the core values of DevOps is COLLABORATION. If the security team isn’t working with and actively engaged with the DevOps platform team, then you won’t get DevSecOps. These should be aligned and complimentary initiatives.
• Models, frameworks, lingo or buzzwords. Security people love this stuff, but DevOps is a practical effort to make software delivery faster to support the business. The goal of DevSecOps is to add validation to this process. Period. Stop overcomplicating things.
• Agilefall, i.e. Waterfall dressed as DevOps/Agile. Agile and DevOps are reality. Both approaches are more than a decade old and for security professionals to be in denial or unfamiliar with their workings is deluded.

What is DevSecOps? It’s an approach that focuses on Security as a Product Feature, not a checkbox. An initiative that includes people, processes and technology to align with Agile/DevOps efforts to match its delivery methods and desired velocity. But let’s take a cue from the DevSecOps Manifesto.

Through Security as Code, we have and will learn that there is simply a better way for security practitioners, like us, to operate and contribute value with less friction. We know we must adapt our ways quickly and foster innovation to ensure data security and privacy issues are not left behind because we were too slow to change.