“Come on tell me who are you
Oh, I really wanna know”

If there was ever one song recorded that captured the essence of what we do as security, I’d have to give it to the classic “Who Are You” by the Who—especially after the deep dive into thinking about authentication and access control I did recently for the June newsletter I was talking about last week. It’s a song I’ve been listening to for years—well before the 1988 release of “Who’s Better, Who’s Best” that I bought around that time.

One of the things you quickly learn when you’re first exposed to SABSA is that there’s a lot more to security than the traditional CIA triad you focus on so much with the CISSP exam. Sure, those 3 things are important – and there’s generally even attributes defined for them – but at the end of the day, security comes down to decisions you make about who does what, to whom, and how often. And it’s all implemented in terms of some binary decisions based on who you claim to be, how much I believe you, and, if I’m so inclined to believe your claim, whether you’re actually allowed to drink the milk out of the big jug in the refrigerator or not.

In our house, the answer is a flat-out no—no matter who you are. But in your house, the answer may well differ.

And it differs because different things are important to you…wait for it…

…based on who you are…

…and who the other person (or thing acting on behalf of some other person) claims to be.

That’s the context of security that so many organizations I’ve encountered tend to gloss over. Maybe it’s because they don’t know how to ask. Maybe it’s because they know what to ask, but they can’t get anyone to meet with them.

Or maybe it’s because, in their organization, they have a compliance and/or control-based view of security that places more emphasis of demonstrating you’ve turned your controls up to 11 than it does on ensuring that the controls you actually do put in place are enabling and protecting the business in meaningful ways.

It’s that last bit that is why there’s more than 3 attributes in a SABSA security architecture, because there’s potentially a bunch of different things you’re going to need to measure and report to the people you support in order to earn the credibility and trust that enables security to transcend the traditional labels of the Department of No and being seen as simply the Policy Enforcement Police…

…which most definitely gives a whole other spin on getting a PEP talk, now doesn’t it?

But maybe you don’t believe me. So let’s take a walk together through some attributes. Generally, there’s a set of between 50 or 60 that’ve come up regularly enough in my own security architecture work for me to isolate and establish consistent definitions. And, depending on the threat and control frameworks you use, you might have many more.

For example, my latest analysis of the CIS20 common controls defined 47 unique attributes, 27 attributes impacted or implied by VERIS and another 48 attributes extracted from the recent CSA Enterprise Architecture analysis I did for April’s newsletter about cloud security.

However, what matters most isn’t the number of attributes you might identify—it’s how you define and use them within your security architecture.

It doesn’t change the fact that what you need to identify as security is to answer the “who are you?” question, though. The focus of the question just changes the more complex the nature of the capability you’re trying to measure and the further away from the CIA triad you get.

What’s an attribute like “Ethical” got to do with access control, you might ask?

In this case, it’s down to clearly identifying a set of whos and the specific access control decisions that need to be made to successfully deliver it:

• Who decides the definition of “ethical” behavior?
• Who’s going to enforce that definition?
• Who’s going to define the acceptable evidence of whether any instance of conduct fits the rules?
• And, ultimately, are you the who that allows you to actually do what you’re trying to do?

Because each one of those ultimately depends on a well-established access control system within the scope associated with the capability itself.

The thing is, we just don’t tend to think about it that way.

Which brings me to another question I tend to get asked from time to time:

Why do you offer a coaching and mentoring program about security leadership instead of more traditional “security consulting” types of services?

The answer is, well, Archistry does offer, from time to time, some more traditional security consulting and “done for you” types of services. But what I’ve found over more than a few years of doing that kind of work is that…

…if you don’t change or expand the way an organization’s security team fundamentally thinks about the job they’ve been hired to do first…

…then any “security work” done by anyone – me, you, or any other company you might think of – is generally only a short term solution (at best)…or quickly forgotten or replaced (at worst).

So the epiphany I had at some stage was that the real value I can add to helping you address your security problems is brining in all the myriad experience I’ve had doing it wrong, seeing it being done wrong…

…and ultimately figuring out what tends to work more often then not…

…and then helping you figure out the best way to leverage that knowledge and experience yourself, in whatever role you have, and trying to tackle the problems that stare at you with red, glowing eyes from the ceiling at night when you just can’t seem to sleep.

Because that’s how lasting change happens. It has to happen from the inside. It can’t be something someone does for you—although, clearly there’s a time and a place for that too.

But, most of the time, I’m happy to let someone else worry about that stuff.

So if you’re not getting the results you want in your security program, and you’ve been through the exercise of systematically changing the people, the processes and the technology you use…

…maybe it’s time to think a bit differently about the problem you’re trying to solve.

And maybe I can help you do just that as part of our Effective Security Leadership coaching program.

If you’d like to talk about it, you can set something up using the big, yellow button at the bottom of this page, right here:

https://securityleadershipcoaching.com

But…if it’s not for you, then that’s ok too. It’s not for everyone, nor is it for every organization. You’ve gotta be ready…

…and you’ve gotta be committed to making a change—even if that change is just in the way you, as an individual, decide to tackle the job you do.

If you’re not, then it’s going to be a disastrous waste of your money and both our time.

“I really wanna know
Oh, I really wanna know
Come on tell me who are you, you, you, you”

And who do you want to be?

Stay safe,

ast
—
Andrew S. Townley
Archistry Chief Executive

The post <strong>The ultimate security song to keep you focused on what you’re doing</strong> appeared first on Archistry.

One of the first things we talked about in that interview was how confusing security architecture seems to be, and how everyone seems to have a different definition.

In this episode of the podcast, I answer Ed’s questions:

1. What is my definition of security architecture?
2. What is the value proposition of security architecture?

I also give you a brief bit of background on me and why I have strong opinions on the subject—opinions that, to the very point of this podcast, are contrarian to the way the majority of our security, technology and business colleagues see security itself.

The post The definition and value proposition of security architecture appeared first on Archistry.

One of the things I saw recently was a clip from the 2017 Royal Ascot race where a horse called Growl somehow unseated his jockey in the starting gate, yet he ended up running the whole race solo. It’s kind of an amusing story, and one that shows the power of constant training, repetition and building habits in helping us do what we need to do, no matter what might happen.

But what struck me about this was somewhat related to a conversation I had yesterday with someone about the discipline of security architecture. It was a good chat, but the conversation clearly confirmed that a lot of what I’ve been saying in these emails over the last year or so has been echoed far and wide by people other than the few hundred folks I’ve managed to speak with about it in that time.

The gist is: there’s not a whole lot of people who understand much about the real purpose of architecture and how to go about it successfully anyway, and, as an ofter under-represented subset of the “architecture” discipline, that means that there’s an awful lot of “security architects” that aren’t really sure about what they should be doing either.

And, unfortunately, a lot of the certification programs out there just reinforce all that’s bad about “architecture” because they focus on the details of the things being produced – or they get overloaded in the pompous pretentiousness of their “architecture development process” and forget that…

…just like training a racehorse to run a race…

…you can train anyone to execute the steps of the process.

But it’s a lot harder to train them how to think about what the process is supposed to accomplish.

The reality is that whether you’re paying attention to it or not, everything has an architecture—even your security program. And, as the leader of the cybersecurity function, the information security function, the IT security function or whatever it is your own organization chooses to put on the name badges you wear…

…you have a choice about architecture.

You can let it grow, wild and unfettered – kinda like the way kudzu has invaded, smothered and otherwise hogged out the sunlight, driving the other, more native species of plants in the state of Mississippi to near total disappearance…

…or, you can chose to focus on it, nurture it and care for it – like a Bonsai – in a way that ends up making something both beautiful, and, in this case, highly functional, in delivering the overall mission and purpose of security: to enable the organization to deliver its mission as quickly and safely as possible.

A nurtured and planned architecture is the most fundamental indicator of the overall success of your security program. It isn’t your cyber “health and hygiene”…it’s not playing cybersecurity bingo with maturity models and control libraries…and it’s not drinking the DevSecOps Kool-Aid so that you can kick arse, move fast and take names with your iteration after iteration of Misuse Scenarios, Threat Modeling card games and embedding security deeply into your infrastructure as code.

Do you need those things?

Probably. At least some of them.

But if you don’t have them organized into a coherent system designed to ultimately enable the business instead of endlessly looking over your shoulder trying to stay one step of the bad guys, then, I hate to tell you…

…but you’re playing the wrong game.

Today’s email was originally intended to talk about something else, but yesterday’s conversation has stuck in my mind.

We need more “real” security architects.

And by “real”, I don’t necessarily mean “certified,” although there are things out there like SABSA that try to help you become “real” architects—and get the piece of paper to prove it.

The thing is, *knowing* how to do architecture and not actually doing it is actually worse than being ignorant of it in the first place. In the case of ignorance, by definition, you don’t know any better.

However, in the case of abstinence, which is really what you’re doing if you “know” how to do real security architecture…

…and yet, for whatever reason that seems justifiable enough…

You don’t.

You’re not only selling yourself short. You’re actually being disingenuous to the rest of your security team. Because having the right architecture is one of the biggest ways you can help them do their jobs—from strategy to risk to operations.

Maybe you don’t know how, or maybe you don’t know how to get started. And if that’s the case…

…maybe I can help.

So, you can consider these 700+ words as a bit of both a warning and a PSA, because if you didn’t already manage to get your ducks in a row for the next round of the Building Effective Security Architectures program because of budget issues, management issues, procurement issues…

…or even procrastination issues…

…then I wanted to remind you that registration for the next cohort starting on the 6th of July is still open, and you can still save $1,000 off the normal registration fee.

That is, IF…which, I realize might be a pretty big “if”…

…if, you get those aforementioned approval and procurement ducks in a row before the 23rd of May. Because, there aren’t any invoices, there aren’t any POs, there aren’t any refunds, and, if you’re not paid in full prior to the program, those seats are going to go to someone else who can actually get their act together before a well-published deadline.

Or, they’re gonna be empty. And that’s totally fine with me too.

You either want to be a better security architect – or your boss wants you to be a better security architect – or you don’t. I’m not going to convince you of that. Nor would I even try.

My job is to help you decide whether you think that I’m the right person to help you—assuming you’ve already made the decision to get better.

Maybe I am, and maybe I’m not. To butcher the classic quote from Henry Ford, whatever answer you decide is going to be the right one for you.

If you want my help to get you there, there’s still space in the cohort. And you now have 23 days more before any hint, whiff or tangible and detectible trace of a discount for the 2020 BESA program disappears forever.

But you have to decide, and this here link isn’t going to click itself:

https://archistry.com/besa

But, what I will say is that this is the last time I’m going to mention it for about 2 weeks, so I don’t want to have anyone coming to me at the last minute trying to “sneak in” past the deadline because they didn’t know the Pre-Registration period ended on the 23rd of May. If you need the next 2 weeks to organize the payment machine, then consider this your big, giant, glowing…

RED FLARE.

Do with it what you will.

Stay safe,

ast
—
Andrew S. Townley
Archistry Chief Executive

The post The horse called Architecture is gonna race, no matter what appeared first on Archistry.

Two of the potentially challenging things about doing information and cyber security risk assessments are being able to easily leverage any existing risk assessments done by other areas of the organization and being able to integrate the risk assessments we do with the existing risk ratings already being compiled and aggregated by the ERM team—assuming you have one.

Basically, there’s often two camps of “risk” children. The “good little boys and girls” who follow the ERM guidance and directives to brush their teeth before they go to bed, look both ways before crossing the street…

…and do their functional or departmental risk assessments every year, whether they need them or not.

And then, there’s us, the delinquent, unruly hell-raisers in cybersecurity who think they actually run the business, and everyone exists for the simple purpose of following the security policies.

At least, that’s what the non-security people often think—especially when it comes to dealing with our risk assessments. Quite often, they literally don’t know what to do with us. We come to them with our mountains of risk assessments (which are often completely divorced from those in-line, DevSecOps threat modeling exercises), and we’re talking about risk levels due to cybersecurity like we’re Sammy Hagar singing “9 on a 10 scale.”

But…they aren’t. In fact, in the context of the overall organizational risk appetite (which we’ve often blissfully ignored), the overall net impact to the organization of the problem we’re talking about would be like sitting on a stray piece of popcorn as we take our seat in the cinema sometime, hopefully in the near future, to catch the new Matt Reeves take on the Dark Knight of Gotham City.

That’s right. Unless it was hot, sticky and covered in gooey caramel…

…we probably wouldn’t even notice it.

It helps if we’re using SABSA, and it helps even more if we realize that there’s potentially 4 types of risk assessments we can perform across the Strategy & Planning, Design and Manage & Measure phases of the lifecycle that help us place the risks we do analyze squarely within the context of what the organization is trying to accomplish.

However, there’s still often of the tiny problem of discovering and integrating with the organization’s defined risk appetite…

…and then there’s the issue of figuring out how to aggregate (or decompose) those high-level enterprise consequence scales into the RAG reporting defined one we establish our Primary and Secondary KRI performance targets for each attribute in our super-secksy Attribute Profile.

Oh, and then there’s the issue we have faced nearly every day by Chief Engineer Montgomery Scott when he says, “We’re given ‘er all she’s got, Captain.”

And Captain Kirk has the audacity to respond, “Well, Mr. Scott, I need more. How much more can you give me since we’re already in the red?”

How do we know how much beyond that Primary KRI we can actually take before we go out of business…or someone loses their job?

All of these are questions we’re going to need to answer if we’re going to be able to seamlessly and effortlessly – once-and-for-all – integrate our SABSA-based risk assessment and operational monitoring objectives with the organizational risk appetite, consequence scales and ERM risk management guidelines and their oh, so precious…

…and oh, so colorful…

Enterprise Risk Matrix.

Have you ever found yourself asking those questions?

Do you have those answers today?

Are you likely to have them tomorrow…or next week…or even next year?

Well, what I can tell you is that the people who are already subscribed to Archistry’s print Security Sanity newsletter before the May issue goes to the printer sometime tomorrow after the harder-than-granite deadline in exactly 11 hours and 4 minutes from when I write this very sentence…

…will only need to turn their very own crisp, white – and full color – copy to page 7, where the discussion on how to do exactly that begins. And, in the pages before that, they’ll have a deep understanding of the business view of risk, key terminology critical to the success of your cybersecurity risk assessments (even if you call them “Threat Modeling” and do them as part of your Dev[Sec]Ops delivery iterations).

And there’s even a handy sample of how to turn the typical ERM risk management guidance into an actionable, measurable enterprise Attribute Profile, fully dressed in all the white-tie-and-tails goodness of the SABSA Performance Management Framework.

Not to mention detailed discussions of each of the 4 types of risk assessments I mentioned above and what you’re supposed to end up with after each one.

But maybe this isn’t anything that interests you, or maybe it isn’t anything you need because “risk assessments” aren’t part of your job description, and the head of your security program has no interest whatsoever of integrating business strategy with security strategy and the operational prioritization and assessment of those tidal waves of daily threat and vulnerability reports.

Or, maybe you’ve already got it all figured out. I mean, it isn’t that hard. But you do have to think about it…a lot, in some cases, to make sure everything fits together into a complete and comprehensive system for integrating real, business-driven risk assessments into your security program.

Either way, the time is now to make the decision of whether you’re in our out of the club who’ll be devouring this print edition in just a few short days, barring no delivery hiccups (because, yes, I did figure out a pandemic-proof physical logistics solution since last month).

If you want to be in, but you’re not already, then here’s the link to make sure it ships to you too:

https://securitysanity.com

If you’re not already in and you’re not gonna be, then that’s totally cool with me too. At least you’ve made the decision.

If you’re on the fence…tick, tock.

Stay safe,

ast
—
Andrew S. Townley
Archistry Chief Executive

The post Playing well with the good little ERM children appeared first on Archistry.

Yada, yada, yada…AI…big data…security tools…ever increasing threats…AI for good and evil…keeping ahead of the bad guys…yada, yada, yada. That’s a pretty good summary of the security “news” I get in my inbox most days, but on this particular day, I was told that “advanced, AI-based security tools are the only way to plan your defense when the cyber-threats are nebulous.”

Yeah. Right.

And, given the whole load of people locked in small apartments, the lure of some “beachfront” property in the Florida Everglades seems like a good deal, right? Oh, and the ‘gators? Shoot. They’re just like dogs. They’re just coming to say hello, never mind chew your leg off. Stuff like that only happens in horror movies—and, well, the occasional newspaper.

I find this whole notion of “nebulous cyber threats” pretty amusing—especially since I’ve spent the last couple of weeks planning and writing the upcoming May issue of the Security Sanity newsletter all about how to deal with making pretty potent plans for your cybersecurity defense…

…but with nary a mention of “AI” or “security automation” on any of its pages.

How is this possible, you might ask? All those new threats. All those new exploits? Surely, it’s too much for a human brain to deal with—I mean, just look how exhausted and stressed-out my SOC team is. See?

I believe there are some scientifically precise terms I can use in response to this, but one of the ones that suddenly just popped into my head was:

Balderdash.

Now, my classification of the above premise as “senseless talk” doesn’t deny the obvious facts that, yes, SOC teams and front-line security professionals are overwhelmed. Yes, they’re dropping like flies in some cases—especially with the uncertainty and dread of living through a “work”-from-home, “teach”-from-home new normal giving them an extra kick in the teeth each day right now.

And the reason for this sorry state of affairs isn’t the fault of the “bad guys.” It’s ours.

However, as I’ve said before, our job as security is actually pretty simple at the fundamental level: draw a box, understand what’s inside it and the value they provide to things outside the box, and then make sure we manage the access and use of what’s inside by those outside.

Of course, it’s simpler to say than it is to do, because the trick is in drawing the right boxes, identifying the right value, and then prioritizing and classifying all the ways the things inside deliver that value so we know what “access” we’re trying to control.

From this elemental operation, we can then go forth to deliver value that protects and enables a number of higher-level concepts like profitability, safety, compliance, reputation and any other form of value we’d care to build from those lower-level constructs.

The thing is, everything looks hard – or even impossible – until you know how to do it. Once you do, it’s pretty easy to forget there was a time when the task wasn’t “obvious” to you fairly quickly.

Such is the skill of building a risk-based, business-driven security architecture and using it as the foundation of your security program. In some circles, you might as well be talking about hippogriffs, unicorns, leprechauns and other magical and mystical beasts, because the belief that such a thing is not only possible…

…but can be relatively straightforward – if you have a reliable and repeatable system – is 10,000 shades beyond the pale.

Which is why we have crazy-arsed assertions that “only super AI defense mechanisms” can deal with an ever-more ambiguous cyber threat.

If you understand what you have, you know what it’s worth, and you understand how it delivers value, then you should damn-well know the majority of ways it can all disappear in a fiery ball of BOOM.

And once you do, it’s about making some informed decisions based on investment vs. return against the overall priorities of the organization you’re trying to protect.

But to do this, you need to have a pretty robust and reliable method for finding all of the ways things go off the rails. That’s what a risk assessment is for, and far too often, there’s a lot more magic than method involved in most of them. And sure, you can go down the FAIR or OCTAVE or ISO31000 or whatever method…

…but you don’t have to.

Because the majority of the success you’re ever going to have doing a risk assessment for information and cyber security comes from understanding the worlds in which your customers actually operate (which is Principle #2 of The Agile Security System for those playing along at home).

It’s time to dispel the mysticism of the risk assessment, establish agreed definitions for qualitative terms and be able to easily and quickly evolve and align both qualitative and quantitive risk assessments any way they need to go.

Oh, and you should also be able to do it defensibly—whether you’re doing it in 10 minutes on a quick conference call or you spend 10 or more days doing detailed modeling and analysis.

At the heart, it should all be the same.

And, more importantly, from an operational perspective—how you arrived at the assessment shouldn’t make any difference, because it’s only the starting point. You’re augmenting and enhancing that initial assessment based on regular operational intelligence about the internal and external world—whether it’s with a pen and a piece of paper or a full-blown operational dashboard.

Of course, this is the ultimate promise of a SABSA security architecture. And, yes, it’s not only possible, there are practical ways to do it—without taking months and months of slogging through mountains of documentation and endless meetings.

It’s just most people don’t know how—and they don’t know how everything fits together as a system…a system for actively managing information, cyber and even operational risk. Because that’s what SABSA’s for.

It’s also what the upcoming May issue of the print Security Sanity newsletter is for, because it goes through where you head needs to be to be effective at performing risk assessments—without complex tooling, without getting lost…

…and without gee-whiz, AI-based, Riskenator-9000s.

And to do it even in the face of, gasp, nebulous cyber threats.

But if you want it, you’d better make a decision, because in just under a day and a half from when I write this, the deadline to subscribe will be more nebulous than the promises of a gaggle of AI-enhanced security control vendors.

It’s neigh-on time to make a choice if you haven’t already. If you have – either to become a subscriber or not – that’s most excellent. What isn’t excellent is letting the clock make the decision for you.

Here’s the link you’ll need if you decide to subscribe:

https://securitysanity.com

Stay safe,

ast
—
Andrew S. Townley
Archistry Chief Executive

The post Man vs. machine: where are you going to put your faith? appeared first on Archistry.

A long time ago, I heard someone say: “Lottery tickets are a tax for people who are bad at math.”

Which is pretty accurate. Have I ever bought one? Well, yeah—but as a conscious choice in a game of “Wow, wouldn’t it be really funny if I won $18 gazillion,” rather than, “I can’t pay my rent, so I know that this time, I’m going to win. I just know it!”

Come to think of it, there’s a lot more in common between buying lottery tickets and risk assessments than you might think. But the biggest one is a bit of an understanding of statistics and probability.

I have to admit, for a guy with a Computer Science degree and being only 1 course shy of getting a Math minor, statistics is one of the things I’ve had to work pretty hard to overcome an aversion the size of the Moon. It wasn’t always this way. In grade school all the way up to High School, I thought it was really cool. I had some great teachers, but then, I got to university, and ended up in a Stat 101 class with Dr. Mumbles.

Every day, he would walk up to the board, brace the book between it and his belly, and mindlessly copy verbatim from the book as he mumbled what he was writing into his chest. It was terrible! And it made me want to get as far away from him – and, unfortunately, statistics – as I wanna be right now from the front-lines of COVID-19.

In fact, I ended up failing the course—at least the first time. So, I’m probably one of the last people you should listen to about how to do risk assessments properly, because it ultimately all boils down to statistics.

But what I’ve noticed is that I must not be the only risk and security professional with an historic aversion to statistics, because there’s an awful lot more qualitative risk assessments done every day than there are ones based on hard probabilities. Of course, there’s a reason for this. And it’s a reason that technology people – and even a few psychology people – will disagree with:

Decisions are fundamentally based on emotion, not logic. And, yes, I know this may imply that everything is just confirmation bias, but I think that’s a bit simplistic.

There’s actually been a lot of clinical research with people with brain injuries to the areas responsible for emotion and their ability to make rational decisions. What this actually means is that it’s virtually impossible to make a decision “strictly based on the numbers” because we can’t avoid how each of those potential outcomes represented by “the numbers” is going to make us feel.

You wanna make “rational” decisions based on only numbers, then let the computers do it. I’m sure the YouTube suggestion algorithm can manage running the world just fine, not to mention your security program investments.

Even when I used to teach the official SABSA Foundation course, I used to say that because humans make the decisions, everything ultimately boils down to a qualitative scale—even when presented with quantitative evidence. Until the last couple of years, I just didn’t have access to the science to prove my theory.

But, since this goes against our Mr. Spock ideal of the logical, rational decision, we want to reject the validity of qualitative data—especially in risk assessments. Of course, because it’s so subjective, and it’s also very difficult to get reliable and repeatable results, when there’s millions of currency units on the table with each decision, people want to either:

1. be able to justifiably cover their arse, or
2. be able to effectively blame someone else if the decision goes pear-shaped.

Two sides of the same coin.

So, we’re scared of labels – with good reason, which I cover briefly as part of Module 3 the BESA program (which is still open for registrations, BTW) – and because we don’t want to be deemed an “emotional decision-maker”…

…we invent “new math” that might prop up our subjective assessments with more upstanding numerical values.

So instead of “Very Likely”, we call that a 5 on a 5 point scale. And then we do the same for impact, giving the “Moderate” label (whatever that really means) a value of 3/5.

We’ve just taken a giant leap down the slippery slope that will land us squarely in the ice cave of the Wampa on Hoth without our lightsaber (let’s face it, we’re not Luke Skywalker).

Because the very next thing we do in our beady little brains is go:

“Hey, we have two numbers, but *two* numbers are really hard to track, because then you need to explain each one and that opens the door to many questions I can’t really answer…so, I know! I’ll combine them together, and then we get only one!”

And hence, the single value “risk rating” is born: (3 + 5)/2 => 4

So, there you have it, the risk exposure went from something that we needed to talk about because it was qualitatively represented to a “hard number” that’s 4. And since 4’s awfully close to the top of our scale, then we need to mitigate it immediately!

Yeah…sure.

And the risk of monkeys flying outta my butt is 4.398.

So, the “bad math” of risk assessments is much, much more dangerous than the intelligence tax of buying lottery tickets—because if you buy a lottery ticket, you’re mostly exposing yourself and your family to the consequences of getting it wrong.

If you present a whole host of recommendations to the executive management team based on “bad math” risk assessments, the consequences can be much more far-reaching indeed.

There are solutions, however—even when you’re faced with a “risk rating” of “cucumber”. But you need to have a reliable way to untangle the mess and be able to highlight the real factors involved in the real decisions to be made.

The decision to be made is not, what should we do with this risk rated at 4.398. The decision to be made is buried far, far deeper and is about a business choice rather than making numbers smaller.

If you want to know how to do that, then you might find the forthcoming May issue of Archistry’s Security Sanity newsletter useful. If you’re happy with single-value risk ratings driving the security decisions and investment of your organization, then you can probably give it a miss. What I’m going to be talking about will most certainly fall into the “too much work” bucket for you.

Obviously, existing subscribers will get it automatically, but if you’re not one, then the only way you’re going to get it is to get on the bus before the end of the month using this link:

https://securitysanity.com

Stay safe,

ast
—
Andrew S. Townley
Archistry Chief Executive

The post “Good math” vs. “bad math” in risk assessments appeared first on Archistry.

There’s a pretty big divide between “risk managers” and people who actually take risks about the whole “risk and opportunity management” vibe at the heart of ISO 31000 and everything related to it—including SABSA. We spend time in the Foundation course talking about you need to have a balanced view of risk, and without taking risk, it’s impossible to seize or exploit opportunities.

This is true…as far as the words go, but, like most things:

The devil’s in the details (and the execution).

Every time I hear someone talking about “the upside”, for some reason I’m instantly transported back to the time I first watched Monty Python’s Life of Brian at my friend Kevin’s house when we were kids.

“Some things in life are bad
They can really make you mad
Other things just make you swear and curse.
When you’re chewing on life’s gristle
Don’t grumble, give a whistle
And this’ll help things turn out for the best…

And…always look on the bright side of life…
Always look on the light side of life…”

Don’t forget to whistle indeed.

However, the way people tend to think about the “upside” of risk is normally almost as misguided as singing a jolly old song when you’ve been sentenced to die a slow death by dehydration and starvation while the wind whistles softly through your dry, dust-filled hair.

In the movie, we laugh, because the juxtaposition is the whole point of comedy.

In the real world of risk assessments, getting this wrong gives you a false sense of complacency that could potentially have some pretty dire consequences.

The reality I see in my work with risk and security professionals, in the courses, consulting, mentoring – and even in random conversations over pints – is that most organizations still do a really, really bad job in identifying, quantifying and managing their traditional or downside risks.

I mean, really, really bad.

So, if you come to someone and say, “Look, Johnny, you need to think about both risks and opportunities when you’re doing this, because they’re connected.”

What happens is poor little Johnny’s head explodes, because you’re asking him to do more than he could do originally—further reinforcing any fears of inadequacy and imposter syndrome he already has. And, if this whole COVID thing has taught us anything, it’s that when we’re scared, stressed and anxious…

…it’s pretty damn hard to make good decisions—about risk or whether you’ve already turned off the oven.

The danger with the way “taking a balanced view of risk” is often interpreted is that for every downside risk, you need to find the upside of that downside risk. That there’s a yin and yang kinda vibe going on, so you see things like:

The risk of me jaywalking to get the coffee I mentioned yesterday is that I won’t see the truck coming, and I’ll end up in the hospital.

The opportunity of me jaywalking to get the coffee I mentioned yesterday is that I have the opportunity to see and avoid the truck that ran the red light so I can avoid ending up in the hospital.

Of course, this is a bit contrived, but I have seen this kind of thing before.

So, what’s the problem?

The problem is that if we’re trying to find the “opportunity” in the downside risk, e.g., the threat, then we’re missing the point.

Yes, businesses take risk so they can capitalize or realize opportunities, but those opportunities are – at least from the business perspective – the objectives they had in the first place.

The realization of the opportunity is the objective they want to achieve.

In the example above, getting the coffee is the objective. And that objective is a means to an end of some larger strategy.

How long it takes me to get that coffee may or may not have an impact on the bigger picture objective, so there’s surely an opportunity to be next to certain that I don’t get delayed by 6 weeks being in the hospital because I broke my pelvis (or end up dead) by taking longer to achieve that intermediate objective.

Or, I might want it quicker because I need to make sure I’m both alert and on time for the meeting where we sign the big contract that ensures my organization’s future success.

It’s the context that matters.

True opportunities are a lot more subtle to articulate and relate to the architecture we’ve engineered than it looks on paper, so, heretical as it might sound, I think you can’t really even consider taking the balanced view of risk the way most people understand it…

…until you figure out how to properly understand and deal with “downside” risk, or, as the business executives consider it, “just risk.”

While this may seem to contradict what I said yesterday, you don’t establish context through complicated risk scenarios. You establish context for making risk decisions through understanding the context in which the entities making those decisions operate.

And that, uncoincidentally, leads us back to Principle 2 of The Agile Security System:

Understand the worlds of your customer.

Because if you don’t have that understanding…and you don’t have it articulated in a way you can communicate, validate and use so you don’t get lost in the complexity of the problem you’re trying to solve…

…then you might as well save your mental CPU cycles for thinking about how you’re going to build Lego spaceships or race cars with your children…

…or what you’re going to cook for dinner…

…or wondering how long it’ll take someone to launch a COVID lockdown version of Big Brother to give people an outlet so they see their current situation isn’t nearly as bad as what they see on TV.

Now, on the other hand, if’n you’d like to figure out how to properly integrate risk into architecture so you build the skills and understanding so you CAN eventually look on the bright side of life without getting your loincloth in a twist, you’ve still a few days to make sure you’re subscribed to the print Security Sanity newsletter where I talk about the right way to do it.

Here’s the link:

https://securitysanity.com

Apart from everything else I said above, given that most of us are simply confined with our loved ones, friends and family (who may or may not tick all the above boxes) rather than tied to a cross in the middle of nowhere, it’s ok (and absolutely necessary) to “look on the bright side” and appreciate the things you have and can do because you’re healthy and safe—even if you’re ready to get out the duct tape and rope to tie people down so you get some peace and quiet. (Not that this thought has ever crossed my mind…er…nope. Not at all. Ever.)

We all need to do whatever we can to get through this mess and come out the other side. Because it’s pretty clear that there’s gonna be a whole heap of work to do once we’re able to actually go out and do it so we can shape the post-COVID-19 world into whatever we want it to be.

Stay safe,

ast
—
Andrew S. Townley
Archistry Chief Executive

The post Should we really “always look on the bright side” of risk? appeared first on Archistry.

It always kinda surprises me when I meet a new security team, or even a new security professional, who balks at the notion that risk assessment is a core part of what they do. In some cases, this attitude is institutionalized as team dynamics, so that if the designated “risk  team” gets even the slightest whiff that someone other than them are doing a “risk assessment” then the skies open and fire and brimstone start pelting the countryside.

Or, then there’s the harried, overworked SOC analyst who adamantly claims they don’t have time to do a risk assessment because they have all of this threat intelligence to classify.

Or, maybe it’s the security engineering team who waves you away because they’re too busy doing threat models of their latest DevOps iteration.

Hmmmm…..

Yeah. Ok.

The point is that risk assessments are done by everyone, every day of their life. They don’t have to be some sort of heavyweight process that takes weeks just to decide whether or not jaywalking across the street to get your Starbucks fix is a “safe enough” trade-off rather than walking 10 minutes out of your way, fidgeting with caffeine withdrawal jitters, so you can square-corner it and follow the rules to the letter.

Yes, it’s not “formal”, and no, you don’t have the documentation of what’s in your head at the time…

…but that doesn’t mean it’s not a risk assessment just the same.

Of course, that’s not good enough when you’re asked to prove your assessments because your findings are potentially going to send an organization of 30,000 people into a tizzy and drop a minimum of $5 million on mitigations. People want proof.

I get that, and I also agree with it.

That’s why our job as security architects needs to be to creating all the “tools” necessary in order to allow the busy people – including us – focus on the risk decisions we get paid to make…

…while at the same time minimizing – or even eliminating entirely – the rigorous work it takes to document, justify and communicate our rationale, findings and choice of mitigations.

How do we do that?

Yes, you, there in the back waving their hand so hard it’s likely to fall off your wrist. What do you think?

Correct.

It’s by having a clear, usable and well understood security architecture we can use as the foundation for anyone, anywhere in the security team, to make justifiable and accurate risk-based decisions as quickly as possible.

Funnily enough, if you have an architecture development method that’s so integrated with your risk assessment methodology that…

They. Are. The. Same…

…then it becomes shockingly easy to accomplish both things at the same time. All the information you need (or at least most of it), is there, ready to go. You do your thing, and then everyone else automatically gets the cumulative benefit – and ongoing adjustments and corrections – of your work.

It’s actually pretty cool, not to mention fantastically powerful.

And, unfortunately, seeing it in the wild is also nearly as rare as hen’s teeth. Because:

1. people don’t build the right kinds of architecture (if they build them at all), and
2. people think “risk assessment” is a dirty word, relegated solely to specialized teams, and who, in most cases aren’t “them.”

Now, maybe you don’t think this is a bad thing, and that’s ok. Everything’s a process, and, assuming you’re around long enough, you’ll get there too—or maybe you’ll decided you’d rather focus more on breaking things. It’s fine. We need people to do that too.

But, if you want to learn about the different ways risk assessment appears when you’re developing SABSA security architectures, that’s what I’m going to cover in the May print edition of the Security Sanity newsletter. It might not be physically delivered on time given the global logistics challenges, but you’ll still be given special access to it if required so you’re not waiting around forever to get your hands on the printed page.

The thing is, you’ll only get this issue if you’re subscribed by the deadline at the end of the month—just 8 days from now. And, unlike some of the other things I do, the price of this one is probably less than you’d ordinarily spend on your daily caffeine intake, so it’s not likely to break the bank.

To subscribe, just visit this link:

https://securitysanity.com

Stay safe,

ast
—
Andrew S. Townley
Archistry Chief Executive

The post Risk assessments: not my job appeared first on Archistry.

One of the things I haven’t talked too much about over the last year or so I’ve been writing these emails is risk assessments. Hopefully, just because I haven’t talked about them much hasn’t led you to believe I don’t think they’re important.

They are.

And, they’re firmly at the heart of the whole SABSA methodology, because you can’t deliver business-driven, risk-proportional security solutions without, well…understanding what the definition of “risk proportional” actually is.

Unfortunately, what I’ve generally found when working with people in their security programs – with or without SABSA as part of the mix – is how poorly understood, and, indeed, how poorly connected the concept of risk and risk management is for a lot of security programs.

At best, you kinda get a, “We have a team for that,” or, you might get people who have jumped into the Threat Modeling community with gusto, STRIDE-ing around the place with their misuse cases, card games and doing their best to identify all the threats they find, prioritize them, and mitigate them as best they can.

We’ll get to the TM issues later over the next few days, but right now, I want to come back to one of the biggest misconceptions I’ve ever seen about SABSA, which, since the whole Archistry Execution Framework and The Agile Security System are fundamentally either based on SABSA or about how you apply SABSA in practice, depending on how you see them, it means it applies to them as well.

That misconception is that for all SABSA’s talk about risk, it doesn’t include an approach for actually conducting a risk assessment, so you have to call out to some external method in order to perform the mechanics that tell you anything useful about what “risk proportional” is going to mean.

Um…thank you for playing, but…wrong answer.

If you remember in either Foundation or A1, there’s a slide that shows you the Architecture Framework’s primary matrix, a.k.a., “the Architecture Matrix”, and it’s shaded in 6 different colors to identify the “things” you’re actually doing when you create all of the artifacts and elements referenced in it.

Now, I know I dog the matrix pretty hard most of the time, and that’s true. But I never said it wasn’t useful. All I said was that it wasn’t the entirety of SABSA that people tend to think it is.

What the matrix is really for is finally revealed with this slide. If you only have the book, you’re a bit SOL because it’s not in there in graphical form, though the content is covered in the text. However, if you have either the Foundation F1 materials or the A1 materials, then you at least have the breakdown. In F1, it’s in the Time section (slide 278 or 302 in the 2 versions I used when I taught it), and in A1, it’s right at the beginning of Section 1 (slide 30 for me).

The breakdown of what you get if you follow the method is:

1. The assets at risk,
2. The risks themselves,
3. The factors affecting risk,
4. Your control and enablement targets,
5. Your risk treatment solution blueprint, and
6. The overall risk management process that ensure’s they’re all connected.

Now, if that doesn’t equate to your definition of a risk assessment – at least on some level – then, friend, we need to have a serious talk.

Which is why that the upcoming May issue of Archistry’s paid, print Security Sanity newsletter is going to peek under the covers of how risk assessment fits in to the overall creation, implementation and operation of the security architecture underpinning the effective security program.

If you attended my 2018 COSAC presentation, you may remember I had some things to say on the topic, so you might’ve already seen some of what I’m going to cover—however, I’m not really sure, because I only have the slides, and almost 2 years later, I have no idea what I actually said. That being the case, if you saw the talk and you’re not already a subscriber, you’ll need to make the call to see if it’s going to be worth it to see it in print vs. on the screen in 2018.

If you’d like to do a better job integrating risk into your (cyber) security program and just don’t know how – or you’re not happy with your current approach – then this one’s for you.

To subscribe before the issue deadline of the 30th of April, you’ll need to use this link:

https://securitysanity.com

Stay safe,

ast
—
Andrew S. Townley
Archistry Chief Executive

The post Sorting sacred risk assessment cows appeared first on Archistry.

This weekend, as you do after 5 weeks of the whole family under one roof, my wife decided that it was time to clean out the garage. And, apart from needing to do a bit of real-world architecture archaeology on my son’s disassembled Hot Wheels garage to get it back together correctly, things generally went pretty well.

And, by “pretty well”, I mean I was able to mostly stay far, far away from this project.

But, today, as the final toys were being organized so there was actually a new play area for the kids come rain or shine since we’re heading into winter shortly, my daughter had hit her limit of patience to help. And her definition of “helping” turned into basically throwing her brother’s Hot Wheels cars into the garage from the middle of the driveway.

My son, rather expectedly, was getting a bit upset. Shouting at his sister to stop doing that.

However, I reminded him that if he’d picked up his own cars the 6 times his mother and I had already asked him, they wouldn’t be still sitting in the middle of the driveway as a tempting target for a toddler.

“Ohhhhh. Now I see, Papa,” was his reply, as he finally raced around getting his cars before his sister grabbed them.

It’s no different in security. Sometimes, the things we really don’t want to happen are relatively easy to prevent…

…but we first have to see the full picture.

And, given everything we face as security professionals every day – and the fact that there’s often a huge divide between the “architecture”, “engineering” and “operations” teams (and, no, this isn’t the time to start talking about Dev[Sec]Ops. We can argue about that one later).

That divide, plus the fact that we often don’t have any good way to organize and really examine the tacit knowledge that’s often only in the heads of the people on our team…

…can prevent us from seeing – and quickly solving – the easy ones, because, from where we sit, they all pretty-much look the same, given the 5 seconds we steal to actually look at them.

How do you see that full picture?

Well, the only way I’ve ever found in 25 years of professional experience solving real-world problems involving people, processes and technology is that you need to have an architecture. But not just any kind of an architecture.

A *usable* archtiecture.

One that isn’t imprisoned within hundreds pages of documentation and locked in a drawer or sitting on an open shelf, collecting decades of dust.

It needs to be available and accessible. It needs to be actionable…

…and it probably needs YOU to build it.

While it’s not always easy to figure out the best way to do it, that doesn’t mean that it isn’t straightforward once you have. And after all the time I’ve spent doing it – including 14 years of hard time in the SABSA salt mines – I truly believe that that best way is to use the 7 principles, 14 practices and 3 Baseline Perspectives of The Agile Security System.

With it, you can easily build that “big picture” to identify and classify the hard vs. the easy problems and make conscious decisions about which ones to solve in what order. Because in addition to being able to classify them, you’ve also got a pretty good way to prioritize them based on their relative importance and risk impact.

Maybe this sounds too good to be true. But as you work through the 7 weeks of material in the Building Effective Security Architectures program, you’ll quickly see how seemingly little things – sometimes even as simple as the security equivalent of picking up your own toys before your sister tries to break them – can make a big difference…

…to your own sanity and effectiveness…

…to the credibility and trust of your team within your organization…

…and your overall ability to demonstrate the way you protect and enable the business.

Right now the registration is open for the July cohort of the program, and, if you register before the stoke of midnight tonight – around 9 hours from now – you can learn how to be a better security architect for $2,000 less than the people who wait until the regular registration rolls around.

Only you can decide if it’s right for you. And if you do, here’s the link you’ll need:

https://archistry.com/besa

Stay safe,

ast
—
Andrew S. Townley
Archistry Chief Executive

The post How to avoid bad things happening appeared first on Archistry.