Last updated at Mon, 19 Mar 2018 13:50:14 GMT

As a follow up to our webinar on Defense in Depth – Embracing the Attacker Mindset, I'd like to post my slide notes for the first section after Wade's intro. I apologize again for the audio issues. We did an hour of sound check beforehand, but of course the signal interference gremlins waited until the curtain went up. We've nailed down what caused it and it won't be an issue for any future webinars in this series. Thank you for sticking with us, and as promised here's the full transcript of the first third:

Defining Defense and Depth

So if we're going to build a defense in depth architecture we need to get an idea of what we mean by defense, what depth is, and what it isn't.

As Wade and I were building this webinar, he brought up a concept that nailed down the crux of what we're trying to do:  Raise the walls high enough that the unmotivated threat finds an easier target, and raise the visibility enough to catch the motivated threat as they attempt to scale the walls.

Regarding depth, there are times when we see an organization has purchased all of the security products from a single vendor, and all of those products run on the same underlying architecture. When a vulnerability is exposed for that architecture, it may be possible for an attacker to pierce all of the layers of that defense using the same or very similar techniques. You need to be careful what you buy and from whom; you want variation so that your layers aren't lined up perfectly for an attacker.

Defense in depth aims to place varied structures and processes throughout the environment to ensure the Confidentiality, Integrity, and Availability of your assets.

It's widely believed that an attacker only needs to be right once, and a defender needs to be right all the time. With a proper defense in depth strategy, we force the attacker to be right a lot more of the time.  The emphasis then is on detection and the speed of our response.

Defense Without Understanding

If you want to build good depth in your defense, a lot of organizations immediately look to what's on the market. There's a lot of products branded with “Next Generation” that purportedly aim to make your life easier, require less staff, pretty much everything you want to hear. A lot of them are expensive. I've used a few of them and they are great, but only if they fit your organization's needs.

We see a lot of organizations that go to purchase solutions that don't have a map of their environment, or have many disparate maps. The departments doing the purchasing haven't had in-depth conversations with each other, and there's only siloed understanding of what's going on. And so partial knowledge builds partial solutions, and partial defense. Then you've got whack-a-mole. You need to look inside first, to get a clearer handle on those needs before you go to market.

Depth begins with in-depth conversations that span departments and functions, comprehensive understanding that manifests in shared maps and documents that span teams in IT and IS and outside of it.

In the coming months we'll do a webinar to highlight the processes and common pitfalls of these in-depth exercises, and how you can get the most out of them to build your maps.

Exceeding Compliance

A lot of people look at defense in depth through the lens of regulatory compliance. Frameworks like PCI, Sarbanes Oxley, ISO, HIPAA can help provide cues to necessary structures and processes. It's important to realize that it's a minimum bar, it's not where security should end.

Organizations often buy to fulfil a specific compliance requirement, and the list of products they implement reads in order of the requirements. The policies do too. It ends up being 20 solutions when a more methodical approach would have revealed that 10 better-implemented products would have covered all of the requirements. These frameworks need to inform your decisions but not drive them.

Recently there was a great article by Christophe Veltsos on that quotes the Federal Trade Commission. Even the FTC admits that PCI isn't the be all and end all of a reasonable security program. You need to plan on exceeding compliance.

It may seem ironic that a consultant is telling you this, but no one can do the first steps of this program better than you can. You know all the moving parts of your business better than anyone. And if you don't you should. You need to take a concerted effort to know the who/what/when/where/why/how of all of the information that is stored and transmitted.

If you buy and build before you develop that catalog of knowledge and map it out, you'll likely end up with shelfware or at the very least unused features. Organizations that use 10% of the features of the software that they buy are going to be constantly fighting budget battles, administrative staffing burden, and can't be nimble. Find something that fits you in features and functionality.

But sometimes you can't. Sometimes the product just isn't there, or the timing doesn't support it. That's life. What you can do is license appropriately and plan to rip and replace as you learn and as the product space matures. Build your processes around it but watch your dependencies so that you can move that solution out without drastically upsetting the others.

Your goal should be to understand every data flow from start to finish, and all the network objects that are transited, then buy tools that address the security needs in those flows and those structures.

Organizations often give compliance needs their primary focus, but you should make sure to focus on your needs as a business as well. The things that make your value proposition unique should be protected just as much if not more. What are your detection and response goals? What data flows are you prioritizing and why? What structures are you prioritizing and why?

While not a technical consideration, a lot of organizations simply don't have budgets that line up to these requirements and priorities. Or if they have the budget today, they don't have budgeting processes that adapt to changes in the security landscape. A case in point: Mobile device management with Bring Your Own Device wasn't a thing just a few years ago and now it's a budget item for many organizations. If it takes a few years to alter your budget structures, you get caught flat footed as far as exposure.

Likewise, how are you licensing products in consideration for building a flexible security program? The longer term licensing helps keep costs down, but how do you exit from those without incurring large penalties?

Lastly, when risk conversations happen at the upper levels of the organization, they rarely get communicated to the people who feel those risks. This can lead to some dangerous improvisation with budgeting and with solutions. Those on the front lines are seeing risks that aren't acknowledged or addressed and they take a best guess at how to handle them. While that initiative is good, it often comes at the expense of other solutions or priorities.

When you evaluate the cost associated with losing a particular structure or data flow because it cannot be budeted or prioritized, who's aware of that decision?  All parties don't necessarily need to be part of the conversation and decision, but they absolutely need to know the approach.

Check out the recording of the webinar here for the rest.