Reflection on Working From Home

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.

Introspection on a Recent Downward Spiral

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.

RSA USA 2017 In Review

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?

The Heart of DevOps Is Cooperation

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:


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).

It's Time For (A) New Context

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.

My Other Pages

Support Me

Support EFF


Bloggers' Rights at EFF

Recent Comments

  • Danniel: SANS Top 20 controls are not controls. Its like a read more
  • Ben: I hope that it's not so dire. I think there read more
  • Tunde: The question at the back of mind now is: How read more
  • Dan Raywood: I met you at the Barracuda party, introduced myself with read more
  • Ben: Hi Jack, Thanks for the comment. I've read the context read more
  • Jack Whitsitt: Ben - while you're correct in almost all of your read more
  • Ben: Hi Amith, This review is now near 4 years old. read more
  • Amith Sarma: Hi Ben, A very valuable feedback on the book. Thanks. read more
  • Ben: Hmmm, thanks for catching that, Rob! I was going off read more
  • Robert David Graham: Minor correction: Dell was founded in 1984, not 1994. read more

Archives

Creative Commons License
This blog is licensed under a Creative Commons License.
Powered by Movable Type 5.2.10