Category Archives: video

Business Must Change: InfoSec in 2019 – The Falcon’s View

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 is tons of research and evidence that shows we're now clearly within the 4th industrial age. We all know about the 1st and 2nd industrial revolutions, with the first lasting about 100 years and ending around WWI, and the second being slightly shorter and ending around the end of WWII, but many people don't realize that the 3rd age - of analog-digital transformation, mechanical automation, and industrial transformation - occurred up until sometime in the 1980s or 1990s (dividing lines are always fuzzy with such things). That said, there was definitely a watershed moment in the mid-1990s marking a clear transition from the old Deming-era industrial ways to this modern digital era.

That brings us to 2019... and the imperative for drastic changes across the board, and in particular with how businesses are structured and function (vs. the current dysfunction). More importantly, these changes are also necessary if we have any hope of fixing our organizations to be more secure and to quit hemorrhaging cash at alarming rates, whether it be from massive breaches or insane spending on pointless tools or simply just being wasteful. Here's what I believe needs to happen ASAP, and is especially important in this fragile and declining (American) economy:

1) Flat, Agile, Lean, Empowered, Generative

First and foremost, organizations need to reinvent themselves. I'm a huge proponent of Frédéric Laloux's Reinventing Organizations ( in which he talks about a better way to structure and manage. Specifically, he advocates for a flatter structure in which people are empowered to make decisions and take actions in the best interests of the whole. No, this does not mean outright anarchy and chaos, but instead advocates for nurturing a caretaker attitude within all employees such that they truly care. This is a very difficult thing to do! Especially for large enterprises, can you imagine a culture-shift that makes people care about the org and the missions and the products/services being created/provided? Daunting, to say the least.

One of the ways to get there, however, is to start adopting practices from Agile and Lean and start applying them to business management. Small teams should operate in a manner that is reasonably autonomous and empowered. You're asking people to do a task, so let them do it! However, what they do should be within a framework that emphasizes the greater good, lean principles (like eliminating waste), and - most importantly - thinking about generativity (that is, the lasting impact and sustainability of the work for and on future generations). I would submit that this seemingly small (but not trivial) change in management can have HUGE impact overall, including on the security of the organization.

Consider, if you will, that fundamentally we in infosec want people to make better decisions. Truly, that's at the core of much that we do. Those "better decisions" might equate to not falling for (spear)phishing attacks, choosing hardened environments over default installs, or following reasonable secure coding practices in the development process (to name a few). However, when people are empowered to make their own decisions and are held accountable for the lasting impacting, then and only then will they start adopting more of a caretaker mentality and start considering long-term impacts. BUT!!! - and this is very important - it also means breaking from the micromanagement techniques that have become so prevalent in business over the past 20 years. Because so much work is intangible (not physical products being produced), it is vastly more difficult to monitor and manage for quality. As such, part of this reinvention of business operations is to completely throw away factory-style TQM practices (including those created by Deming) in favor of digital-style TQM practices that better measure modern-day business functions and outputs. Ergo, what seems so small is in no way trivial or easy.

2) DevOps, Automation, and Outsourcing

This conversation naturally brings is to the DevOps movement, which is singularly the most important "invention" of the past decade. It provides a roadmap for how organizations should function overall. Key within DevOps is the notion of automation, but also equally important is the notion of outsourcing, whether that be to cloud providers or consultants/specialists or other "*-as-a-Service" providers (e.g., mainframes-as-a-service). No matter how you look at it, DevOps is the way that business should operate, and that is - interestingly enough - exactly matched to the org management model that Laloux describes (without ever getting into technology or DevOps!).

First and foremost, let's talking about what DevOps is: it's a cultural movement designed to fundamentally alter how business functions. It is not just about agile or automation or tools/toolchains or anything so simple or crass. It is a broad-scale change in business model and operation; and, it applies to everyone! Know what else parallels this target audience of *everyone*? That's right, it's infosec. Further, just as DevOps advocates applying agile and lean principles (among other things) to business operations, so does infosec advocate applying better security and risk mgmt principles to everything in the organization, too. How do you get people to make better decisions? You educate them, you help them optimize their flow, you provide timely and relevant feedback (preferably as quickly as possible), and you structure in resilience such that when failures happen (they will), they don't bring down the entire organization. Those are the Three Ways of DevOps as introduced within The Phoenix Project way back in 2013.

From a functional perspective, this means a few very specific things for infosec: 1) We must continue to work in a collaborative and consultative manner with everyone else in the organization. 2) We must heavily emphasize ways to automate much of what we're doing to minimize the overhead and functional impact on business operations while trying to achieve our desired goals (e.g., through federated identity with MFA, through deployment of SOAR tools to automate much of otherwise-wasteful SOC practices, through extensive process automation around all forms of access control/mgmt). 3) Similarly, we should continually push decision-makers within projects to ask, first and foremost, the "build or buy?" question, with an emphasis on outsourcing where possible. Our architectures should be built around APIs, integrations, and interoperability such that we avoid vendor lock-in as much as possible, have data portability (or, perhaps more accurately, application portability while we retain control to our own data), and find ways to optimize security and business by leveraging and integrating specialized resources.

3) InfoSec Bifurcation: Functional vs. Strategic

All of this discussion then brings us to a core challenge: we must change how infosec is structured, operates, and performs. Going forward, it's essential to bifurcate infosec between functional and strategic roles. Most functional roles should be directly embedded within technical teams, and should emphasize use of specialized resources. For example, we should not see large infosec/CISO organizations any more, but instead should see functional technical security resources, such as firewall engineers and appsec engineers, directly embedded into their closest related teams (e.g., network teams, dev/DevOps teams, etc.). Functional roles are specialists who are expert at particular operations.

To this end, we need to get away from these "everything but the kitchen sink" roles, whether they be called "security managers" or "security architects" or "DevSecOps engineers." These titles have become so buzzword-overloaded as to be completely meaningless! I have interviewed extensively over the past year+, and the one universal principle is that organizations are trying to find one magical, perfect hire with expert-level experience in anything and everything, which is just patently wrong and stupid and mythological. If you think you need someone who is expert in infosec AND development AND systems AND automation AND incident response AND AND AND... just stop. Please. You're seeking the impossible, setting yourself up for failure and disappointment, and - more importantly - you're causing pain (for yourself and others). Focus on the true functional requirements needed and go hire for that. Nobody can do it all (certainly not well), and there is incredible value in hiring a diverse set of personnel, whether they be FTEs or - far more likely these days - contractors. In fact, I would even go so far as to challenge people to stop thinking about full-time resources for all these functional roles, and instead think about DevOps and the gig culture and how to grab specialist contract resources as needed to perform project work and then move on. Truly, change your thinking and divert from the old, broken models.

Lastly, do invest in strategic resources. For example, a true security architect will have a broad background within strength of vision, the ability to run an entire project from start to finish (including: problem definition, solution identification and evaluation, solution testing/POC, and solution deployment). Managers and executives should also be strategic overall, focusing on ways to ensure that everything is agile, everything is lean (waste-reducing), and not micromanaging anything. For example, instead of riding a project hard to drive to completion, instead ask "Why is this project spec'd to take so long?" or "What are the obstacles to progress, completion, and success?" When looking at projects strategically, you will then find that you are instead looking at ways of working, how to be more agile, how to be more efficient and effective, and overall how to help empower people to work smarter. It's amazing the difference when you let people do their jobs and focus instead on helping them achieve their goals. Also, in doing this, it allows management ranks to thin and flatten, fewer managers can manage more projects and personnel, and so on. For infosec, this means finding and developing leaders and - of equal importance - not forcing people to leave their specialty behind simply to "move up the ranks." There shouldn't be ranks so much as effective leadership and the division between strategic and functional actors. Making this change will further the first two points above in reforming how the organization operates, while also allowing infosec progress to truly be made in a reformational matter.

I hope to write in more depth about all of these points in the coming weeks and months. First thing's first, though: I need a steady source of income! Yes, 2018 was rough, and it ended just as it had been going all along; on a major note of disappointment. But... a new year means the opportunity to turn the page, find something better. In the meantime, please take this message out to everyone and let's see if we can finally hit a tipping point in how businesses function and finally instigate meaningful change.

Cheers & Happy New Year!

Forget C-I-A, Availability Is King – The Falcon’s View

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.

The simple fact is this: availability is king, while confidentiality and integrity are secondary considerations that rarely have a default predisposition. We've reached this point thanks in large part to the cloud and the advent of utility computing. That is, we've reached a point where we assume uptime and availability will always be optimal, and thus we don't need to think about it much, if at all. And, when we do think about it, it falls under the domain of site reliability engineering (SRE) rather than being a security function. And that's a good thing!

If you remove availability from the C-I-A triad, you're then left with confidentiality and integrity, which can be boiled down to two main questions:
1) What are the data protection requirements for each dataset?
2) What are the anti-corruption requirements for each dataset and environment?

In the first case you quickly go down the data governance path (inclusive of data security), which must factor in requirements for control, retention, protection (including encryption), and masking/redaction, to name a few things. From an overall "big picture" perspective, we can then more clearly view data protection from an inforisk perspective, and interestingly enough it now makes it much easier to drill down in a quantitative risk analysis process to evaluate the overall exposure to the business.

As for anti-corruption (integrity) requirements, this is where we can see traditional security practices entering the picture, such as through ensuring systems are reasonably hardened against compromise, as well as appsec testing (to protect the app), but then also dovetailing back into data governance considerations to determine the potential impact of data corruption on the business (whether that be fraudulent orders/transactions; or, tampering with data, like a student changing grades or an employee changing pay rates; or, even data corruption in the form of injection attacks).

What's particularly interesting about integrity is applying it to cloud-based systems and viewing it through a cost control lens. Consider, if you will, a cloud resource being compromised in order to run cryptocurrency mining. That's a violation of system integrity, which in turn may translate into sizable opex burn due to unexpected resource utilization. This example, of course, once again highlights how you can view things through a quantitative risk assessment perspective, too.

At the end of the day, C-I-A are still useful concepts, but we're beyond the point of thinking about them in balance. In a utility compute model, availability is assumed to approach 100%, which means it can largely be left to operations teams to own and manage. Even considerations like DDoS mitigations frequently fall to ops teams these days, rather than security. Making the shift here then allows one to more easily talk about inforisk assessment and management within each particular vertical (confidentiality and integrity), and in so doing makes it much easier to apply quantitative risk analysis, which in turn makes it much easier to articulate business exposure to executives in order to more clearly manage the risk portfolio.

(PS: Yes, I realize business continuity is often lumped under infosec, but I would challenge people to think about this differently. In many cases, business continuity is a standalone entity that blends together a number of different areas. The overarching point here is that the traditional status quo is a failed model. We must start doing things differently, which means flipping things around to identify better approaches. SRE is a perfect example of what happens when you move to a utility computing model and then apply systems and software engineering principles. We should be looking at other ways to change our perspective rather than continuing to do the same old broken things.)