No. I’m not talking about infrastructure, vendors or kit on the ground. I’m talking about the way you *think* about security in your organization.

There’s a reason CISOs and the security professionals that work for them are overwhelmed:

They’re in the trenches, fighting the bad guys, overwhelmed with the alerts flying at them like angry bullets, and occasionally get hit by the heavy artillery of a major breach backed by some nation-state-backed APT.

History has a story to tell us about this approach:

It’s a good way to die.

And that’s the thing about history summed up by the famous quote that goes:

“Those who don’t understand history are doomed to repeat it.”

Well, now…here we are.

You see we hear things a lot like cyber warfare from a national perspective, and we certainly hear a lot of talk about security professionals “fighting the good fight” against wave after wave of attackers, so there’s no question this is an active combat zone.

But it’s not just between nation states. It’s a lot like those sci-fi thrillers where the trade guilds are fighting each other…

…there are pirates…

…and everyone’s a victim.

We all experience this every day to some degree.

But what are we trying to do about it?

Well, we have the right intention:

We try to get more visibility.

But where we’re getting it a bit wrong is not asking the question…

…visibility of what?

Most of the time, “threat discovery” and “security visibility” simply gives us more overwhelming detail. It’s not helping us…

…it’s just weighing us down even more.

Because the more we realize how many alien eggs have been planted around the place, oozing black stuff and ready to jump down our throats and explode out of our chest…

…the more overwhelmed, disheartened…and even downright panicked we become.

Even when we group them with some kind of fancy visualization tools, we’re still focusing on the details. We group by source…or type…or exploit…or whatever.

But that just gives us classes of threats and threat actors.

It’s interesting, and it’s useful for selecting your weapons and ammo for the tactical actions and hand-to-hand combat…

…but it doesn’t help you plan your strategy.

It just helps you plan how your people are going to end up dying.

Because, without a sound strategy…

…that’s exactly what they’ll keep doing.

However, unlike combat where the casualties are counted in lost lives…

…in our world, the casualties are counted in smoked servers, employee turnover due to stress and burnout and the number of compromised data records in a breach.

Which is exactly why we’re stuck doing basically the same thing over and over again.

Because since people aren’t really dying from cyber – well, at least most of the time, but that’s changing now too – we’re not as motivated to change our approach.

We think it’s working.

We just need more resources.

We need new servers (and they’re easy to get, even instant at this point).

We need new, more secure data repositories (again, thousands of vendors, thousands of upgrades and patches, and new ones every day).

And we talk about all these open vacancies that we’re trying to fill by cranking out new recruits through cyber education, degrees and certifications (and they’re going to keep coming, because the salaries look good, and who doesn’t wanna be Neo).

But it it was a draft instead of recruitment…and where 57% of those drafted were actually going to end up dead instead of just simply “burnt out” per current 2024 stats?

If customers were the citizens of your enterprise nation and they were truly dead when their data got breached, encrypted and it was disappearing off the world map instead of just “a few hours of downtime” every year?

Would we insist on using the same tactics?

Would we insist on using the same thinking?

Or would we do what we’ve always done during our darkest hours, and pull people together to invent new approaches, new ways of thinking and new ways of seeing…

…so we could do the unexpected…the unprecedented…

…and actually stand a chance of turning the tide?

We can’t see that this is EXACTLY where we are in the world of security today.

We’re well and truly stuck in outdated thinking and trying to overcome it with modern tools.

And we can’t see what we can’t see…

…because we’re looking at the wrong things.

We see what we focus on, and right now, we’re focused on stopping the threats and the bad guys first…

…and protecting our organizations second.

We think they’re the same, but they’re not.

Trying to get rid of something you don’t want gives you a 50% chance of getting something you want even less.

And we’re getting that 50% less every single day.

So, how do we stop it?

How do we turn the tide?

And how does security architecture have anything to do with it differently than you might think?

Because security architecture – when done at the right level – helps us see things we can’t see today…

…because it helps us focus on what’s important to the thing we’re trying to protect…

…so we understand how best to protect it.

As early as the US Civil War, aerial reconnaissance was used to get a better perspective on the battlefield so that commanders could make better decisions.

And who sees the most first…is the one who ends up winning.

So, does your security architecture help you better see your organization and what needs to be protected…

…or does your security architecture help you see all the weapons and defenses you’re using and the threats and bad guys you’re trying to use them on?

See the difference?

Do you see what you’re not seeing?

Once you can see your organization “from the air” you can start to understand where your real weak spots are—before someone else tells you.

It’s not just about identifying your attack surface.

It’s about understanding the implications of your attack surface and risk exposure.

And when you can do that…

…then you can finally stand a chance…

…because you can finally start thinking proactively…

…and your approach to your security strategy takes on an entirely different meaning.

So, if you’d like to turn the tables and learn to see the big picture of your organization so you can truly be proactive in your security…

…then I can help you do that.

And I can help you do it step by step, and in parallel with all the fighting in the trenches you’re currently doing…

…so that one day in the not too distant future, while the guns may not go completely silent…

…you’ll at least get to turn down the volume.

To get started, join me on the 12th of August for Secure by Design: Step-by-Step by registering using this link:

https://archistry.com/sbd

Because it’s not just about building and deploying more secure business software and customer solutions.

That’s just the beginning.

Because from the very first iteration you do…

…you’ll start to open your eyes – possibly for the first time – and understand the organization you’re trying to protect…

…in a whole new way.

Stay safe,

ast
—
Andrew S. Townley
Archistry Chief Executive

The post <strong>If you want better security, you’d better have a better security architecture</strong> appeared first on Archistry.

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

The cynical definition of a “hero” is one I remember spouting off in meetings not so many years ago. I was a bit more jaded then. Maybe I had a reason, but maybe I didn’t. Looking back on it now, I’m actually not sure. But I do remember what I said about heroes on more than one occasion:

“You know the thing about heroes? Well, they’re dead. Nice statue. What about the rest of us who are still around?”

I’d like to think that I’m a lot wiser now than I was then, but only looking back from a future far from now will really tell me whether I was, or I wasn’t. Either way, the thing I’m confident now about is, no matter how confident I am about what I already know…

…I’m more confident that there’s still a whole lot more I have to learn.

Tonight I was watching the 2019 version of  the Midway movie. It was good. I remember the original. And all the WWII movies I watched on TV as a kid, including a TV mini-series called The Winds of War, which I dimly remember enjoying quite a lot.

But the thing I enjoy most about this has to be down to the airplanes, because I’ve always been crazy about airplanes—as long  as  I can remember. What I don’t remember, but  what I’ve been  told by my parents, was that on my first birthday, they both took me up in the J-3 Piper Cub we had at the time. When I was older, all I remember about it was seeing it hanging in our machine shed. Just a frame, but the wings had been done.

I had an uncle who flew B-25s. Apparently, he’d get in trouble, because he’d come and buzz the farm with them, and it’d upset the neighbors so much that they’d report him. Eventually, he ended up being a Captain for American Airlines.

I had another uncle who got a Purple Heart for something he did in the Pacific. When I was maybe 7…or maybe 10. I really don’t remember. He gave me  a couple of books. One was on the Flying Tigers, and the other was the story of the  P-38 Lightning.

Were they heroes? I don’t know. I wasn’t there.

But watching the movie tonight, after having watched many dramatizations of the true stories of conflict ancient, old and of the present day, the  thing that occurred to me was probably a better definition of  what a hero really is.

A hero is actually someone who does the right thing because it’s their job to do the right thing—no matter what. Whether they have support. Whether they might live. Or whether they might die in the process. And for all the “first world” problems we have…

…and I say this as someone who enjoys beverages of the alcoholic variety, and who, *gasp*  wasn’t able to buy any for two whole months thanks to the local government’s response to a  global pandemic…

…they aren’t really all that consequential  in  most cases. I mean, it’s not like we’re going to be blown  up  on a battleship sitting in  a harbor, or we’re likely to be shot out of the sky in an airplane…at least for the majority of the people I deal with on a daily basis.

Of course, there are those in the world where this is still actually the life they live on a daily basis. And the reality is…I can’t even fathom what that must be like.

“First world” privilege, I guess.

But with the above definition of the hero…about doing what’s right because that’s the job they’ve signed up to do…

…it’s just about the one case I can think of where the end results aren’t actually as important as the intent. Sure, they want to achieve some kind of objective. But the  reality is that it’s the decisions they make – every day – about what to do that really make the difference.

And that difference is  manifest in not only what they do and who they are. That difference manifests in how they see themselves.

So…while it’s not exactly on the level of being a fighter pilot…or a crew member of a warship…or a member of the infantry…

…the things each one of us needs to ask ourselves every day are a few key questions:

Did we show up?

Did we do what was necessary—even when it was sometimes inconvenient…or when we didn’t have the support we would prefer?

And how did we respond to those challenges?

Did we get discouraged?

Did we give up?

Or did we focus on putting one foot in front of the other, because we believed in what we were doing?

Now, maybe this sounds a little grandiose to you as a security professional. Maybe you’re a security architect…maybe you’re a security manager…maybe you’re a member of the team…

…and maybe you own the whole dang shootin’ match.

But the thing we need to remember as security professionals is that the belief we  have inside ourselves that we’re doing the right things…every day…is the most important thing that will keep us going.

Get your affirmations, and, in TA terms, your “strokes”, at home—from your lovers, wives, partners, kids, friends, colleagues…whomever it may be.

But never forget that sometimes we have to be the unpopular opinion, and sometimes we’ll see the bigger picture that others won’t…

…be they project owners…

…project managers…

…technology teams…

…operations teams…

…end users…

…or even the ultimate customers of our organization.

And that’s actually ok.

Being  in security isn’t a popularity contest. It’s not who you are.

It’s what you do.

And it’s important you do the right things, every day…to make the right decisions, every day…

…to enable and protect your organization.

And, of course, that you do it in a way that earns you the credibility and trust of the people whom you’re trying to keep safe.

You don’t need to be a dickhead to deliver the mission and purpose of security…

…but you don’t need to be popular either.

You just need to be respected.

And, most importantly, you need to respect yourself.

If you want some more detailed guidance and support in actually doing this, it’s something I help security professionals all over the world with nearly every day. To find out more, just go here:

https://securityleadershipcoaching.com

If you don’t, then, hey, that’s cool too. But either way, I urge you to think about what you’ve just read. You don’t need to do anything for me. There’s a much more important question you need to answer:

What are you doing for you?

Just think about it. And…as always…

Stay safe,

ast
—
Andrew S. Townley
Archistry Chief Executive

The post Security heroes appeared first on Archistry.

One of the key skills you really need to have if you’re going to be able to excel in any kind of strategic role, and I don’t care if that means you’re building a business, building a security program or building security architecture—it’s all related. And that relationship is something  that many people fail to see. They fail to see that it’s not about achieving the *specific* outcome…

…although that is most  certainly important.

But to excel at something, whatever it is, is being able to recognize the core skills underneath whatever it was you did to solve the specific problem…

…so you can put those skills to use in solving *any* problem that has the same shape.

Of course, this means you have to be pretty adept at recognizing patterns and structures of things – something  any good architect is bound to know  how to do – but one of the things you’ll  notice after a while is that the whole world is based on the way structures are created, the way they work together, and the ultimate efficiency and effectiveness of any given structure in achieving whatever it is that it was built to achieve.

I realize I’m getting a bit abstract here, but, if you’re reading this, there’s a good chance that you’re a security architect, or your the head of a security program in an organization with multiple 10’s of billions in annual revenue—or at the very least, you’re the manager of a function within security.

And, in all those cases, being able to think abstractly is something that’s actually an essential success criteria—even if you started life in IT or security operations (as many people do).

What I’m talking about – those structures, connections and relationships – is, of course, what we call architecture. But it’s what the discipline of Systems Thinking calls a system.

The thing about systems is that they’re all around us. Some are designed. Some evolve naturally…

…and some are forced to evolve earlier – and under higher stakes of success or failure – than was originally intended.

And others…well, there are others that just get stuck. Formally, those are called “balancing loops”, and it’s the tendency of a  system to seek “balance” after a period of time. Of course, “balance” is in the eye of the beholder, so my balance might not be the same as  yours.

But it’s important to recognize the systems around us, every day, in every aspect of what we do. Because the understanding of these systems allows us to find leverage points that allow us to influence their behavior.

And, yes, by “behavior” I mean the behavior of people as much  – or probably more so – than than I do the behavior of the technical and business systems we deal with every day.

Our society as a whole is ultimately just a system—even if it often feels like one that is out of control, and where we, as individuals, often small and sometimes even insignificant in the face of things that happen where we don’t agree.

It can be the complex system of delivering a project we think is security risk.

It can be the complex organizational dynamics of office politics that might not seem fair.

And it can be the behavior of those around us as humans to each other that we feel isn’t as noble, as compassionate or as understanding as it probably ought to be.

In the face of  these challenges, both small and large, the thing we can never forget is that we too are nodes in this complex, messy, unpredictable and endlessly fascinating system of our world. Which means that, because we’re a part of the system, that there are things we can do to influence it’s ultimate behavior…

…but, as you’ve heard me  harp about before, there are limits to what we can ultimately control.

Fundamentally, what we control boils down to just two things: how we spend our time and how  we respond to events. That’s what’s called our activity and our behavior.

Any change that you want…

…whether it’s to be shifted left in the delivery cycle as security and/or architecture…

…whether it’s to be more respected and trusted by those around you…

…or even whether it’s for  people to  be treated  differently in this world…

The truth is: it all comes down to the decisions we make about our activity and our behavior. What we choose to do. What the  choose not to  do. What we choose to support. What we choose to ignore.

If all you can think about is “I can’t do security architecture.” Then, that’s probably what’s really going to happen.

Instead, if all you can think about is “How can I do security architecture—even in the environment I’m in, and under the constraints I have, and limited by the resources at my disposal?”

My guess is that you’ll make a whole lot more progress.

Apply that to the way you engage with your fellow humans and stay focused on the outcomes you want…

…rather than getting sucked into the black hole of anger, fear and hatred.

My guess again is that you’ll make a lot more progress there too.

I can help you figure out and practice what I believe  is the right activity and behavior to build a more effective security team as part of the Effective Security Leadership Coaching program, no matter where you are in the organization. And I can do this, because I’ve been there, I’ve done it, and the answers are pretty straightforward. The details, if you’re interested in talking about what you want to solve are right here:

https://securityleadershipcoaching.com

However, what I can’t do is tell you what’s the right activity and behavior for you, based on where you are, who you are, and your own personal beliefs. Of course, I have some suggestions…but I’m not you.

But the biggest suggestion I will share is to remember the psychological power of what’s called “target fixation”. On a sport bike, it’s where you’re looking at the ditch instead of the line you want to take through the curve, you panic, and…guess what?

You end up in the ditch with your beautiful machine bent to bits and lots of broken plastic.

It hasn’t happened to me, but I have come close a few times when I was riding regularly.

Many people call it different things, but the underlying principle is the same. With any problem we face, it’s always ultimately a people problem. And often, that “people” is us. So, at the end of the day, we need to remember to ask ourselves…

…what is it you’re focusing on right now?

And are you getting closer to it…or further away?

If you’re not happy about it, then what’s the next decision you need to make to get back to moving in the direction you want to go?

I don’t know the answers to those questions. But I bet you do.

Stay safe,

ast
—
Andrew S. Townley
Archistry Chief Executive

The post There’s always a people problem appeared first on Archistry.

May 31, 2020

If there was a popularity contest among all artifacts you might happen to unearth if you went digging for some glimpses of the architecture in your organization, the data flow diagram (DFD) would probably be the star of the High School football team, driving the red-orange Camaro with the T-tops, and dating the captain of the cheerleading squad. Because, like High School football stars, cheerleaders and Camaros in America, the DFDs are everywhere it seems.

And especially if you start talking about cybersecurity in the context of the modern, agile CI/CD delivery teams, you’re probably going to find at least traces of them rubbed out on the whiteboards of offices everywhere—even hanging around longer than the germs of COVID-19 after the place has been covered in industrial-grade disinfectant.

I get it. It  seems like a really great idea to build up a layered diagram that helps people focus on the communications and connections in an ecosystem, because that’s how things really happen. Information is exchanged along those connections, each node plays its part – even the ones with the pom-poms – and, naturally, if you want to try and corrupt the nodes, a good strategy is to try and unduly influence their view of the world or drive a 40’ big-rig through the doggie door and just take over the place, leaving all the subtleties to the wanna-be script kiddies.

However, the titillating temptation of building the “one diagram to rule them all” generally fails to deliver in the long run. Sure, there are true stories how a DFD put on ice between the Mesozoic Era and today informed the security control decisions of a re-implementation of said system with more modern technologies…

…and Microsoft  even has a tool  to automatically build them for you, so, if Microsoft does it – not to mention makes it easy to automate – you can bet development teams out there are going to use it, whether they really know why or how, just because it’s there.

I’m not saying they can’t be useful. And I’m certainly not saying that I can’t read them…or use them…

…or even run them through the View-O-Matic to slice and dice them into  something that I feel is far, far more useful in the long run from a security perspective, not to mention ending up with a better, overall architecture artifact to boot.

Meaning…the ol’ DFD racehorse has run his races, brought home the trophies, and can now spend his days chasing fillies and frolicking with the butterflies in the lush, grassy pastures of retirement.

I actually wasn’t going to go there with the June issue of the print, delivered-to-your-door Security Sanity newsletter when I’d  started to map out how to say what I wanted to say…

…but then a couple of conversations with some of my coaching clients in the security leadership program made me think that maybe it was time to tackle this beast, because it highlights how we’re often abducted in our architecture sleep by the space aliens of complexity…

…before being returned slightly brainwashed about the most effective, efficient and easy-to-integrate tasks into a DevSec-sec-sec-secOp-op-opzzzzss delivery model.

You might not agree with me, and that’s totally fine. But you also probably won’t understand exactly what I’m talking about if you don’t manage to be subscribed in time to get the June issue. Because the time to do that is approaching more rapidly than even I would like, since I’m having to re-jig the content and structure of the issue at the last minute to cover what I want to cover.

If you haven’t already done it, and you’ve been sitting on the fence waiting for a butterfly to tickle your nose and give you the sign from the universe  as to whether or not it’s worth it…

…well, it probably isn’t. Because if it’s taken you this long to figure it out, it’ll probably take you even longer to read it and try to put it into practice—which pretty-much defeats the whole point of me going to the trouble to write the things the first  place.

But if you’re late to the party, and you’re only now digging this email out of your spam folder…AND you’re ready to get serious about putting the “architecture” into your security architecture practice, then you’ve still just about 8 hours or so before the deadline to subscribe in time to get the June issue.

But don’t dilly-dally around if you want in, because who knows what kinds of gremlin hiccups might happen between now and then with the interwebs, shopping carts  and payment processors.

If you want in, and you haven’t yet done it, then this is the link that will lead your DFDs to a quiet and retiring – yet long and still rewarding – life on the greener, grassier side of the fence:

https://securitysanity.com

Stay safe,

ast
—
Andrew S. Townley
Archistry Chief Executive

The post Putting your data flow diagrams out to pasture…for good appeared first on Archistry.

May 30, 2020

I don’t know about you, but just a few short minutes ago, I was glued to the NASA livestream watching the first human spaceflight to depart US soil gracefully take to the sky. It was absolutely beautiful, and it made me remember the day, many, many years ago when all of us were gathered in the library at school to watch the launch of STS-1. Both were historic achievements by a team of literally thousands of people, and both can’t be understated for the inspiration and motivation they can bring to people who witness them. Kudos all around to both NASA and SpaceX for pulling this off.

It was also great to see something positive that can happen against the backdrop of the train wreck that’s happening globally, and in the US in particular.

But that accomplishment can’t happen in a vacuum. It takes a team.

And, it should be no surprise this is a common factor of success in both spaceflight and your organization’s security program. That being able to come together as a team is something I talked about more than once since I’ve started writing these emails…

…however, I can’t really stress enough how critical it is to staying focused and truly adding value. This is even more important as a Security Architect, who’s also often balancing literally dozens if not scores of projects, highly stressed, and often feeling like you’re dancing on the edge of the Grand Canyon.

In many, many situations, that establishing a shared focus on value and common purpose when dealing with getting the right security done for a project – or the organization as a whole – comes down to you.

It comes down to the attitudes you have.

It comes down to the awareness of yourself, your customers and your organization.

And it comes down to the decisions you make about who to include and how to do it when you’re working with a project or strategic team. Literally, the words you use and the questions you ask can either create an avalanche of credibility and trust with your security customers…

…or it can cause an explosion that sets you and your project back several steps and ends up costing your organization money and puts a pretty hefty dent in your credibility as security.

Some of those questions and the specific mindset and guidance you need to bring with you into every project you touch are going to be covered in the upcoming June edition of the print Security Sanity newsletter so that you can rally and align the whole team around your specific recommendations for keeping the organization safe…

…whether your decisions are to work within the existing security policy framework, or whether you believe a different path is necessary.

If this is something you find more difficult than you’d like it to be, then the information in the newsletter should give you some critical guidance in this regard…guidance you can rely on and internalize so that your confidence – and that of your security customers – is where it needs to be.

To make sure you get it, you’ll need to make sure you’re subscribed before the deadline at the end of the month—in just over one day from now. And to do that, you’ll need this link right here:

https://securitysanity.com

A common vision and being able to align an incredibly large and diverse set of people just put two astronauts into orbit. Imagine what being able to do the same kind of thing could do to in the work you do every day in your organization.

Godspeed, Dragon, and also to you in your future security architecture adventures.

Stay safe,

ast
—
Andrew S. Townley
Archistry Chief Executive

The post The key to “stellar” success in security architecture appeared first on Archistry.

May 30, 2020

Strategy, architecture, architecture/design, design, artifacts, elements, activities…the questions swirling around what each of them really is, where they start and stop, what purpose they’re supposed to serve and just how they all fit together can sometimes almost escalate to fisticuffs. And our human, psychological need to draw boundaries and establish our “territory” and area that we control often works against the greater good of our teams and our organizations…

…and even our society, as you can see playing out right now in about a gazillion different ways, no matter which news, social, or experiential source you happen to choose.

Fortunately, there are solutions that can be found within the security team, but you’ve gotta be willing to be flexible. Unsurprisingly, the best way to do this is to focus on a common objective. Because once everyone has a focus, the default barriers of “it’s not my job” tend to come down almost automatically.

The astute reader would also realize yet again, that this is proof that knowing the theory and tactics of security architecture – or anything, for that matter – is only the price of entry into actually doing it. If you want to actually do it, and if you want to do it well, you’re going to have to understand the murky mess of human interactions, because using policies, procedures and other organization politics to force people into caring about – or acknowledging the necessity of – architecture and security just doesn’t work.

Here’s a couple of freebie tips included in the upcoming June issue of the Security Sanity print newsletter that might help you get things done better in your own teams, although they’re said a bit differently in the pages this month:

First, a lot of the confusion people have about the differences between design, architecture and what is and isn’t part of it comes from the same issue plaguing effective governance: a lack of understanding and awareness that a lot of the definitions depend on the context of the observer. Just like one person’s accountability is another person’s responsibility once they’ve agreed to do the task, one person’s architecture drives the other person’s design…

…but given that the best definition of architecture talks about “carefully designed structures” that work together to achieve an objective, you can see how it’s somewhat recursive and tends to spark context-specific arguments about who does what.

But what about the rest of it? What about the things you produce? What about, in SABSA terms, the components you buy, and the operational tasks it takes to manage them?

If we take that architecture is the decisions that are hard or expensive to change later, then even these too are relative, so it all ultimately gets, to quote the Fifth incarnation of The Doctor, “a bit wibbly-wobbly, timey-wimey” when you put it under the microscope.

And those structures?

They’re made of elements, and elements, architecturally speaking, can be…anything, including decisions, artifacts, expressions, mental models, and the components and activities people use and perform every day.

Architecture is the decisions that drive the creation of something that gives value and solves a problem, tangible or abstract tho that creation can be. So, you see, academically, the whole architecture argument tends to quickly devolve into a bit of abstract, navel-gazing and seemingly arbitrary boundaries that are permeable once you poke them.

I guess that means it must be hard, huh?

Well, not really. Harkening back to a favorite analogy:

You don’t have to know how to build a car to drive it safely…

…and so it goes with security architecture. You don’t have to know and be able to properly pontificate about the theory of architecture and how to do it, to be able to do it well.

You just need to stay focused on what value you’re trying to enable—while recognizing that everything that’s ultimately created as part of working towards that end will become a part of the living architecture you must maintain the moment it manifests itself.

And to prove that security architecture, design and actually delivering value doesn’t have to be hard, overly bloated and stilted in detailed process, even when you’re given only a glimpse of the whole problem you need to ultimately, I give you exhibit A:

The June issue of the Security Sanity newsletter, printed on real paper and with pages you must actually turn with your fingers and arms rather than an electronic swipe.

Because in its pages, I’m going to walk you through the security architecture development typical to where many of our customers and clients start in their role as security architects every day, so that you too can apply this, practically and quickly, to your ongoing projects…

…while increasing your individual skills and effectiveness as a security architect at the same time.

However, if you want it, you’d better get moving if you’re not already a subscriber, because the deadline to get it is just over a day away. Any subscriptions created after 11:59pm US/Eastern will NOT receive the June issue. Instead, they will start with the July issue.

So procrastination isn’t your friend. It’s just going to make you wait.

And if you’ve already decided that the whole print newsletter thing isn’t for you, then that’s totally cool as well. It’s not for everyone. It’s only for people who are ready to rip it open, devour its contents, and start trying to apply what they learn immediately—sometimes, even before they’ve finished reading the whole thing.

If that’s you, and you’re not already subscribed, this is the link you’ll need:

https://securitysanity.com

Stay safe,

ast
—
Andrew S. Townley
Archistry Chief Executive

The post Design, architecture and the murky mess it makes appeared first on Archistry.

May 29, 2020

If you’ve ever seen any footage of the American West, you’ve probably seen one or more pictures or videos of prairie dogs popping out of their holes. This is often followed by something scientifically described as “jump-yipping”.

The science behind this says that it’s basically a group-based security control – of the assurance category of the SABSA MTCS if you’re really getting technical – that assesses the readiness and alert levels of the rest of the colony. If the “wave” of responses is quite extensive, then generally, the rest of the colony is paying attention, and the confidence levels of the individual little buggers can be high that they’re safe to go about their business.

The key point is that they’re always assessing and validating what they’re doing in the context of the environment they’re in. And it’s a pretty good thing to keep in mind as you go about your security architecture work—perhaps without the jumping and the yipping, however.

It’s especially necessary to avoid one of the biggest traps you’re likely to fall into when you’re given one of those rough-n-ready solution architecture sketches accompanying your typical business software project. It’s essential to resist your urge to tear into it like a hungry hyena and start STRIDING around the place drawing attack trees and identifying the “security objectives” because you’re putting the cart about 100 miles ahead of the horse.

Instead, you’re going to need to use what you have to start asking some intelligent questions, but the ones that are most important aren’t the 4 standard Shostack questions. Those come later, and the answers – and the activities – need to be appropriately prioritized by the answers to the questions you ask BEFORE the standard threat modeling questions.

However, since Threat Modeling has generally become integrated into the security vocabulary, and since there’s such a big emphasis on it place in the CI/CD delivery models of DevOps…

…it’s likely that we’re sucked into that black hole too, thinking we’re doing architecture, when we’re most certainly not.

Pop up, little prairie dog! Pop up and make sure you’re doing the right things!

What I’m talking about could be thought of as a process, and, in some cases, it has been documented as such—including by me for some of our consulting engagements in the past.

But processes have problems, and especially if you’re struggling to get architecture established in your security program, the last thing you need is to bring along a Louis Vuitton steamer trunk of a process when you’re trying to establish a beachhead in an organization that’s most likely has an archive of said vintage luggage that would fill the warehouse at the end of the original Raiders of the Lost Ark.

Sure, eventually…you’re going to need something for everyone who comes in afterwards and keeps things going. These are the “infantry” soldiers of Cringley’s Accidental Empires fame you might’ve heard me talk about before.

But right now, no. It’s the surest way to get cut off at the knees before you even have a chance to prove value. You need something lighter. You need something faster.

You need a system, guided by principles that always apply, and which you can rely on once you’ve repeated a few simple practices enough to make them habits. Of course, in this case, I’m talking about The Agile Security System, because that’s exactly what it is.

And in the upcoming June issue of the print, delivered-to-your-door-anywhere-in-the-world Security Sanity newsletter, I’m going to show you how to apply those principles, practices and Baseline Perspectives to help you develop enough architecture to enable the right security decisions to be made when you’re starting from a picture that might be everything from two boxes and a line between them…

…to an image that looks like someone barfed the rainbow slurpee and network infrastructure shaped Valentines candy they were gorging on when they were hammering out the solution design until 4am.

However, if you’re not already subscribed, the window to get this hands-on, over-the-shoulder view of applying the system in action to develop SABSA security architectures you can then build on as a foundation of revitalizing your security program’s perceived value to the business…

…will be closing in just over 2 and a half days, at 11:59pm US/Eastern on Sunday.

After that, even if you subscribe at 12:00am Monday morning, you’ll just have to wait a whole 30 more days until I ship you the July issue—which will be about something entirely different.

To make sure you’ll get your copy, just go to this link ASAP:

https://securitysanity.com

And, if for some reason you’re an existing subscriber who’s payment hasn’t been processed before the deadline, your subscription will be cancelled at the end of the month, and you won’t be allowed to subscribe again in the future. So, if you’re in this boat, don’t come to me on Monday and ask for an exception. It won’t happen. Don’t say you didn’t know.

Otherwise, enjoy your Friday evening, and, most importantly…

Stay safe,

ast
—
Andrew S. Townley
Archistry Chief Executive

The post What prairie dogs can teach you about building security architecture appeared first on Archistry.

May 27, 2020

If you look at the stats on who’s making all the noise in the DevOps/DevSecOps space – at least those who care to comment on some of the industry surveys – 60% of the adoption of DevOps is in organizations with under $1 billion in revenue. Now, you might be wondering why I bring this up, but there’s a method to my money-focused madness.

The poster children for DevOps are large, deep-pocketed organizations predominately built around a single service, e.g, Netflix. Even then, Neflix’s revenue was around $16 billion, squeaking it in the $10B+ plus rank in the adoption surveys…

…but from the perspective of the Global 500, that’s chump change since the bottom of the global ranking is around $26 billion. Not quite twice, but almost.

That means that while the largest adopters of DevOps are small, fast-moving organizations, members of the Global 500 generally aren’t the organizations that have the luxury of being brainwashed to think that CI/CD of a single family of apps (or even a single app) is the biggest information and cybersecurity problem they have.

Sure, there may be cutting-edge teams in some of these large organizations, and they may think that their app’s importance makes Tony Stark look like a brainless, 98 pound weakling walking around in a reject Halloween costume in comparison…

…but the harsh reality is, you’re not Netflix. And, the even harsher reality is that your organization’s got a lot more to worry about than just AppSec, which, let’s face it, is all that DevOps and DevSecOps tend to worry about. That is, unless you like just chasing threats and vulnerabilities all day as the end rather than as part of an integrated and effective enterprise security program.

If you’re like the majority of the organizations I work with, you’re sitting somewhere well above the $20B+ revenue bracket, and you’ve been around for a rather lengthy amount of time, have a heavy investment in legacy systems, and are probably subject to few pretty prescriptive sets of regulations. And that means, unlike some of the smaller, DevOps shops built primarily around single service family…

…failing to take a comprehensive, enterprise-wide view of security is going to land you in a heap o’ trouble. And because of all this, it’s pretty important that you make figuring out what the state of the world is, how it connects and what it’s really supposed to be doing for your organization and its customers.

That, my friend, requires a proper security architecture effort. And it’s even more of a necessity because many of these types of organizations are filled with, dare I say it, average to midling development and delivery teams who aspire to do something beyond connect yet another SAP information service to some kind of web interface just like the previous 10 they’ve done for the last 5 years—but who can’t, so they generally invent exciting excuses for playing with the latest and greatest toys and methodologies.

Mind you, I’m not trying to be critical here. I’m just going on what I’ve seen firsthand in many different organizations and consulting organizations. And, as a result, there’s not a high degree of architecture skills around. Maybe the team’s had TOGAF training, or maybe Zachman, or maybe something else along the way, and maybe they try to do their best.

But that’s still going to be Goldilocks territory more often than not, and the level of documentation around the architecture and design of any solution security is supposed to approve is going to be basic. So, even if we’re working with a highly unique, outlier team who’s leading the pack in terms of DevOps and CI/CD…

…the stats say that even the leaders only have security involved during the design of the solution about half the time, and security’s involvement at the requirements-gathering stage is even less.

And that’s the leaders, not the majority. The majority are damn close to sitting in the corner and wearing a dunce cap after school because the just haven’t quite figured out how to get security involved at all.

Oh, and I’ll leave it to you to ponder why distinct phases are articulated in a DevOps adoption survey…but then that’d get us off on a tangent about the precise nature of security involvement in each of the standard DevOps delivery steps, and today’s not the day for that one.

So…since your typical app doesn’t generally deserve Tony Stark levels of self-importance…

…and since your typical business project implementation design generally isn’t that solidly connected into architecture of any kind, not the least of which is security architecture…

…then being able to catch any kind of crazy design document you’re thrown and turn it into something firmly grounded in the business and security priorities of the organization is a pretty necessary skill to have. And yet, it’s often a pretty big gap in the security team, because a good many people on the security team are a lot more comfortable playing in the infrastructure world than they are in the architecture world.

To fix this, I’ve dedicated the entirety of the upcoming June issue of the print Security Sanity newsletter to showing you how to take these kinds of solution sketches and link them to the existing security requirements of your organization, both traceably…and really, really quickly.

And as part of this process, you might find some conflicts, you might find some gaps, and you might find some areas where you really don’t yet know what the definition of security is supposed to be. Far from being a problem, that’s actually the whole point.

So if you want to be confident and quick about doing these things, then you’re going to also need to be confident that subscribing to the newsletter is the right thing to do…

…and quick about doing it before the upcoming deadline at the end of the month. To get all the details, caveats and cautions to make sure your confidence is justified, you’ll need to go here:

https://securitysanity.com

Just remember, the clock is ticking, and if you somehow manage to sneak in and your subscription payment is processed after 11:59pm US/Eastern on Sunday the 31st, you’re gonna miss this issue completely. Your subscription will start with the July issue, and there’s no way to get the one I’m talking about here, because back issues of the newsletter aren’t available.

Do with the above what you will. But whatever you do, you’re running out of time to decide.

Stay safe,

ast
—
Andrew S. Townley
Archistry Chief Executive

The post The app with a bigger ego than Tony Stark appeared first on Archistry.

May 25, 2020

You heard me talking about it yesterday. Those lov-er-ly “solution architecture” one-pagers that generally are either highly abstracted so as to fit on a single 16:9 slide or so detailed, the largest font size used on an A0 sheet would be 4 points. Either way, the one thing you can count on is you’re gonna have to drop everything, hit the garage and dig out the weed-whacker…

…because we’re gonna need to do a good bit of “trimming” before we will be able to identify very much that we’d consider “architecturally significant”—you know, it’s those things that it’s either going to be damn hard or damn expensive to change later.

Wanna buy a Dell vs. HP server?

I’m an Architect. I don’t normally care, thanks very much.

Care to revive the old Oracle vs. IBM database wars from the heady days of dueling billboards down Highway 101?

Nope. Been there, and I still have some of the Informix swag in my closet.

Want to play “What’s the browser YOU love to hate?”

Nah. They all have issues. It just depends on what we’re really trying to do with them.

The thing I’ve noticed over the years now that I really don’t care that much about the implementation details is that there’s a great deal of IT and security time consumed with arguments about which shade of green each blade of grass should be and which exactly how many of them there should be. And that’s often time better spent worrying about bigger problems that might make it actually easier to do your job rather than what label’s on the box.

Of course, like most things, it doesn’t matter…until it does.

If you’re going to tell me that we have 500 different, unique information classification schemes in the average organization, then yeah, that’s a problem. And it’s an architecturally significant one because there’s far too much complexity in the system to enable people to operate it correctly, reliably and predictably.

And if we can’t do that, then we have somewhere south of zero-levels of confidence that anything worthwhile’s going to get done at all…

…let alone trying to demonstrate how much value’s ultimately delivered by the security team.

Or, if you tell me we have 25 separate versions of operating systems running in our environment, I’m at least going to ask the question why. Maybe it’s necessary…but many times it’s not.

See the thing about “architecturally significant” is that it’s a slippery little devil, and he can sneak around for months – and sometimes even years – before he finally ends up sitting in your chair the one time you don’t think to preemptively peer precisely where your posterior will be planted. When you don’t, then you’re gonna probably end up with some 6” rattlesnake fangs in your butt, and the equivalent of someone dropping the first 10 volumes of the old print encyclopedia Britannica on your desk with a grumpy:

“Well? You’re the architect. What’re you waiting for? Fix it!”

Unfortunately, at this point, people tend to dive in with the weed-whacker of their choice – machete, electric or 2-cycle, gas powered – and start waving it around just enough to get their bearings, cut a path outta the problem, and high-tail it back to the safety and security of their inbox.

At least the dragons there might not be quite so big, quite so scary, and not quite so ancient.

I know how this goes, because for 2 years of my life I will never get back, I found myself digging through 6+ years of project documentation to try and figure out why in the hell someone would possibly think what I’d inherited was a good idea.

Sure, it was a good idea…on paper.

But why, oh why did someone hit with the literal-stick end up being put in charge of the solution design that implemented – concept directly into code – the high-level abstraction that was meant to explain the overall value to the business project sponsors?

And had I known then what I know now about doing architecture archaeology…and about where to focus…and about how to get the most leverage out of my documentation…and how to do it with the least possible amount of effort…

I dare say, I’d have a good fewer white hairs on my head.

Whether we like it or not, being able to take a half-baked view of a complex solution as a starting point – be it on a slide, in a binder or on a whiteboard – and turn the crank on our architecture development engine and burp out a security strategy and supporting architecture to give it the best chance of success is one of the “essential skills” of the modern security architect.

But that doesn’t just mean taking some infrastructure kit and control icons out of the bag and dumping them all over the diagram. It means actually trying to understand all the background, intent, context and business value that’s supposed to be delivered…

…and then integrating it – or not – with your existing enterprise security program.

While it’s not technically hard, it can be overwhelming. And that’s why for the upcoming June issue of the print Security Sanity newsletter, I’m going to walk you through a hypothetical example of the kinds of stuff I’ve seen in project charters and show you a reliable and reputable plan of attack that gives you a good view of what “security” should mean in that instance and how near or far you might be from already having those requirements in place in your existing control environment.

If you want it, you’ll need to be a paid subscriber to the newsletter before the deadline at the end of the month. And to do that, you’ll need to go here:

https://securitysanity.com

Stay safe…and try not to wrap the trimmer string around your ankle or something this holiday weekend.

ast
—
Andrew S. Townley
Archistry Chief Executive

The post Weed-whacking your way to security architecture appeared first on Archistry.