In a moment of introspection last night, it occurred to me that working from home tends to amplify any perceived slight or sources of negativity. Most of my "human" interactions are online only, which - for this extrovert - means my energy is derived from whatever "interaction" I have online in Twitter, Facebook, email, Slack, etc.
Alrighty... now that my RSA summary post is out of the way, let's get into a deeply personal post about how absolutely horrible of a week I had at RSA. Actually, that's not fair. The first half of the week was ok, but some truly horrible human beings targeted me (on social media) on Wednesday of that week, and it drove me straight down into a major depressive crash that left me reeling for days (well, frankly, through to today still).
I've written about my struggles with depression in the past, and so in the name of continued transparency and hope that my stories can help others, I wanted to relate this fairly recent tale.
If you can't understand or identify with this story, I'm sorry, but that's on you.
Now that I've had a week to recover from the annual infosec circus event to end all circus events, I figured it's a good time to attempt being reflective and proffer my thoughts on the event, themes, what I saw, etc, etc, etc.
For starters, holy moly, 43,000+ people?!?!?!?!?! I mean... good grief... the event was about a quarter of that a decade ago. If you've never been to RSA, or if you only started attending in the last couple years, then it's really hard to describe to you how dramatic the change has been since ~2010 when the numbers started growing like this (to be fair, yoy growth from 2016 to 2017 wasn't all that huge).
With that... let's drill into my key highlights...
From my NCS blog post:
Despite the rapid growth of DevOps practices throughout various industries, there still seems to be a fair amount of trepidation, particularly among security practitioners and auditors. One of the first concerns that pops up is a blurted out "You can't do DevOps here! It violates separation of duties!" Interestingly, this assertion is generally incorrect and derives from a general misunderstanding about DevOps, automation, and the continuous integration/deployment (CI/CD) pipeline.
Continue reading here...
"If you're a startup trying to get a product off the ground, you've probably been told to build an "MVP" - a minimum viable product - as promoted by the Lean Startup methodology. This translates into products being rapidly developed with the least number of features necessary to make an initial sale or two. Oftentimes, security is not one of the features that makes it into the product, and then it gets quickly forgotten about down the road."Continue reading here...
In the world of DevOps we often like to talk about rapid iteration in relationship to shortened feedback cycles, and yet oftentimes something gets lost in translation. Specifically, just because failure is ok, because failure leads to learning, it does not mean that we shouldn't be thinking at all. And, yet... it's all too common!
We all know there are problems with security. We all know that things aren't keeping pace or improving measurably and meaningfully at a rate or in a manner that most of us would deem sufficient or acceptable. Yet, all we seem to be doing is continuing to cast stones, castigate decision-makers, and pound the FUD drum. Why isn't anybody talking about addressing the core obstacles?
I've been reading a lot lately about generative culture at the suggestion of my boss. Apparently this topic has been popping up and circulating with frequency through DevOps circles in recent months, and seeing as I'm currently charged with doing "stuff" related to security and DevOps, it seemed like a good thing to research.
For those unfamiliar with generative culture, I recommend reading up on it. I found these pieces to be of particular value:
- "The Future of Generative Organizations"
- "What Makes a Culture Generative?"
- "Building Generative Cultures"
- "Safety Culture - Theory and Practice"
- "Creating a Generative Culture & Overcoming Barriers to Change"
What's most interesting about generative culture is that it really fits well with the current problems facing organizations today with respect to security. That is, infosec spend is still continuously viewed as overhead cost, infosec people are still viewed as obstacles (even when trying to play nicely with DevOps teams), and infosec tools continue to be undermined by the human element, which often sees security as an externality to their specific duties (even when it really oughtn't be).
I'm not completely sure why, but I've been holding off writing this post for a couple months now. Maybe, in part, I didn't want to jinx myself. Maybe, in part, I didn't want to open myself up to criticism or ridicule for Yet Another Job Change in such a short period of time. But... I think the time is now right to more publicly announce and talk about this transition, so here goes...
In mid-June I left Ellucian, where I'd been slamming my head against the wall for several months, and joined New Context as a "security architect" (or, as I put it on LinkedIn, "person of interest"). The title itself is somewhat irrelevant as it's not overly representative of my current responsibilities, which include biz dev, research / thought leadership, product management, and yes, likely, some consulting.
I plan to provide more updates in the coming months about some of the things I'm working on, such as around our Lean Security business management model, but I'll hold back on that for now.
In the meantime, if anybody wants to catch-up, or if there's interesting in bringing us in, please feel free to reach out! New Context has a very senior team that's very deep in areas like agile software development, DevOps engineering and infrastructure, as well as - of course - security. We have several awesome partners, too (a list that's constantly growing). If we can't help you out directly, then it's very likely we can connect you with someone who can.
In preparing for my Cloud Security World 2016 talk, "Automagic! Shifting Trust Paradigms Through Security Automation," I did a lot of thinking about what can be automated, how to automate, and how to demonstrate and measure value around all that jazz. It occurred to me. however, that perhaps I was looking at those questions all wrong. Is it really a question of whether or not something should be automated, so much as it's a question of what shouldn't be automated?
At first blush, this may seem like a silly way of thinking about things. After all, it's probably still too early to talk about automating, well, just about everything, right? As it turns out, this isn't the case. Not even close. There are so many ways to automate many of our standard development, operational, and security responsibilities that I'm actually surprised we're still hearing complaints about inadequate hirable resources and not instead hearing complaints about too much automation stealing jobs.
That said, there are certainly several areas where automation requires human involvement, either as a fail-safe, or as a manual process. Here are a few of those categories and a little information on why fully automating is at least premature, if not an outright bad idea.