The Falcon's View

It's been nearly 2 years since I've written anything for my blog here, and I can't say that there's much of a good reason for it. Part of the reason has been prohibitions from past employers on doing anything public without their express approval, but the sad truth is that - despite a few ideas popping up here or there - I've just lacked the energy or wherewithal to really sitting and put word to prose.

I had resolved at the start of 2020 to reverse that trend, as well as to start giving talks at conferences again. In general, several short stints over the past 5 years have really taken a toll, not to mention dealing with the combined and last effects of pneumonia and subsequent bouts of depression. Overall, as of last January, it seemed like 2020 would be the year to turn the page on some of these issues and begin getting myself back on-track. Little did I know how the year would unfold.

I have a visceral reaction every time I encounter yet another article bemoaning the so-called "talent gap" or "labor gap" in cybersecurity. Having been in and out of the job market several times over the past decade (for better and, more often, for worse), I can honestly say this is utter nonsense. The roots of this clamor began more than a decade ago in DC as federal agencies grappled with modernizing, making use of the annual Sept/Oct budget season to decry how poor and helpless they were in order to justify demands for ever-increasing budgets. Local universities (such as UMUC) quickly caught on to the marketing plan and rapidly launched a cybersecurity degree program. Meanwhile, ISC2 helped ensure that the CISSP was a mandatory component for hiring in many positions.

While I am still in the midst of a job search (one that's a year old at this point), I find I need to speak out on the recent TechCrunch OpEd piece "Too few cybersecurity professionals is a gigantic problem for 2019" in order to address some of the nonsensical statements made that really have no business being taken seriously. The author does get a couple things right, but not enough to compensate for perpetuating many myths that need to be put to rest.

I don't know about you, but I am happy to see 2018 ended. Personally, it was a very difficult year, capping a very difficult decade. Now, as we embark into 2019, it's time to sit up and realize that we've now been in this world of e-commerce for more than 20 years (yes, really!). Many, many, many things have changed dramatically over that time, whether it be electronics (smartphones!) or communication (social media!) or transportation (electric vehicles!). However, one thing that really has not changed much is how businesses function, which is really quite sad if you think about it.

There's no shortage of guidance available today about how to structure, build, and run a security program. Most guidance comes from a standpoint of inherent bias, whether it be to promote a product class, specific framework/standard, or to best align with specific technologies (legacy/traditional infrastructure, cloud, etc.). Given all the competing advice out there, I often find it's hard to suss out exactly what one should be doing. As someone actively on the job hunt, this reality is even more daunting because job descriptions will typically contain a smattering of biases, confirmed or contradicted through interview processes. But, I digress...

At end of day, the goal of your security program should be to chart a path to an optimal set of capabilities. What exactly constitutes "optimal" will in fact vary from org to org. We know this is true because otherwise there would already be a settled "best practice" framework to which everyone would align. That said, there are a lot of common pieces that can be leveraged in identifying the optimal program attributes for your organization.

In the traditional parlance of infosec, we've been taught repeatedly that the C-I-A triad (confidentiality, integrity, availability) must be balanced in accordance with the needs of the business. This concept is foundational to all of infosec, ensconced in standards and certification exams and policies. Yet, today, it's essentially wrong, and moreover isn't a helpful starting point for a security discussion.

I started my security (post-sysadmin) career heavily focused on security policy frameworks. It took me down many roads, but everything always came back to a few simple notions, such as that policies were a means of articulating security direction, that you had to prescriptively articulate desired behaviors, and that the more detail you could put into the guidance (such as in standards, baselines, and guidelines), the better off the organization would be. Except, of course, that in the real world nobody ever took time to read the more detailed documents, Ops and Dev teams really didn't like being told how to do their jobs, and, at the end of the day, I was frequently reminded that publishing a policy document didn't translate to implementation.

Subsequently, I've spent the past 10+ years thinking about better ways to tackle policies, eventually reaching the point where I believe "less is more" and that anything written and published in a place and format that isn't "work as usual" will rarely, if ever, get implemented without a lot of downward force applied. I've seen both good and bad policy frameworks within organizations. Often they cycle around between good and bad. Someone will build a nice policy framework, it'll get implemented in a number of key places, and then it will languish from neglect and inadequate upkeep until it's irrelevant and ignored. This is not a recipe for lasting success.

Thinking about it further this week, it occurred to me that part of the problem is thinking in the old "compliance" mindset. Policies are really to blame for driving us down the checkbox-compliance path. Sure, we can easily stand back and try to dictate rules, but without the adequate authority to enforce them, and without the resources needed to continually update them, they're doomed to obsolescence. Instead, we need to move to that "security as code" mentality and find ways to directly codify requirements in ways that are naturally adapted and maintained.

There are shenanigans afoot, I tell ya; shenanigans!

I was recently contacted by an intermediary asking if I'd be interested in writing a paid blog post slamming analysts, to be published on my own blog site, and then promoted by the vendor. No real details were given other than the expectation to slam analyst firms, but once I learned who was funding the initiative, it became pretty clear what was going on. Basically, this vendor has received, or is about to receive, a less-than-stellar review and rating from one of the analyst firms and they're trying to get out in front of the news by trying to proactively discredit analyst reports.

My response to the offer was to decline, and now as I'm hearing some may take up the opportunity, I've decided it's time to myself get out ahead of this potential onslaught of misleading propaganda. Mind you, I'm not a huge fan of the analyst firms, and I found myself incredibly frustrated and disappointed during my time at Gartner when I was constantly told to write about really old and boring topics rather than being allowed to write more progressive reports that would actually help move the industry forward. But I'll get to that in a moment...

October was National Cybersecurity Awareness Month. Since today is the last day, I figured now is as good a time as any to take a contrarian perspective on what undoubtedly many organizations just did over the past few weeks; namely, wasted a lot of time, money, and good will.

Anton Chuvakin and I were having a fun debate a couple weeks ago about whether incremental improvements are worthwhile in infosec, or if it's really necessary to "jump to the next curve" (phrase origin: Guy Kawasaki's "Art of Innovation," watch his TedX) in order to make meaningful gains in security practices. Anton even went so far as to write about it a little over a week ago (sorry for the delayed response - work travel). As promised, I feel it's important to counter his arguments a bit.

Today marks the end of my first week in a new job. As of this past Monday, I am now a Manager, Security Engineering, with Pearson. I'll be handling a variety of responsibilities, initially mixed between security architecture and team management. I view this opportunity as a chance to reset my career after the myriad challenges experienced over the past decade. In particular, I will now finally be able to say I've had administrative responsibility for personnel, lack of which having held me back from career progression these past few years.

This change is a welcome one, and it will also be momentous in that it will see us leaving the NoVA/DC area next Summer. The destination is not finalized, but it seems likely to be Denver. While it's not the same as being in Montana, it's the Rockies and at elevation, which sounds good to me. Not to mention I know several people in the area and, in general, like it. Which is not to say that we dislike where we live today (despite the high price tag). It's just time for a change of scenery.

I plan to continue writing on the side here (and on LinkedIn), but the pace of writing may slow again in the short-term while I dedicate most of my energy to ramping up the day job. The good news, however, is this will afford me the opportunity to continue getting "real world" experience that can be translated and related in a hopefully meaningful manner.

Until next time, thanks and good luck!