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.

May 26, 2020

Maybe it’s not every time you get some kind of project solution architecture in your inbox, but most of the time, there’s bound to be at least one stick figure in the picture. Maybe it’s labeled “customer”, maybe it’s “user”, maybe it’s even something a bit more racy…like “administrator”. But, it’s bound to be there.

And, actually, if it isn’t, you can be fairly certain you’re gonna have your work cut out for you to deliver the mission and purpose of security, because you’ve no idea who your customers are, and that makes it neigh-on impossible to figure out what their mission is and how to enable it—let alone keep them safe in the process.

Who knew a solution diagram without a stick figure was just unlabeled buckets of fail?

Well…maybe it’s only those of us who’ve had to deal with them. And if you think I’m being a bit too harsh on our friends the intrepid infrastructure modeler, maybe I am. Maybe the diagram in question (DIQ? No, probably not) is part of a dedicated architecture viewpoint labeled “Infrastructure” or, more likely, “Deployment”, because that’s the set of concerns it’s actually trying to address.

Because despite my good natured ribbing, there is most certainly a time and a place for an infrastructure diagram who can happily invite several of their friends. But more often than not, that place isn’t called a viewpoint. Nor does it even resemble one enough in passing to be accused of playing one on TV, social media or even those old vacation videos you might see shoved in your face by Flakebook as a “memory.”

The reality is that whether it’s there or whether it’s missing…either way you have a problem. And that fundamental problem is trying to figure out who is supposed to actually benefit from the solution you’re supposed to christen as “secure.”

And just because there happens to be a plucky stick figure or 7 in the diagram, don’t be lulled into a false sense that all of the recipients of value…

…and therefore all the value potentially at risk…

…is represent in what you’re given to work from.

This too is part of the hide-and-seek game of “find the business value” every security architecture needs to become a master at playing. And it’s not just once. It’s every damn day of our professional career.

It’s one of those lines in the fine print of our job description written in the 2pt font—light gray on white, of course.

But this is just one of the architecture games you’ll need to play as the security architect assigned to the support and ultimate approval of this particular new business initiative. So, wouldn’t it be kinda useful to have a robust and repeatable way to play this and all the other games so that you were not only confident that you’d identified a viable solution…

…but that you’d done it in a way that was integrated and aligned with the rest of the organization’s approach to security…

…and that you’d done it as fast as humanly possible?

I was just talking about this to someone today, but that goal was probably one of the main drivers of the development of The Agile Security System in the first place, because being able to effectively handle the development or justification of architecture from a back-of-the-napkin solution design is just so much of what we ultimately do.

That’s why we need to be better at doing it, and it’s also why we need to WAAAAAAY better at doing it in a consistent, coherent and way that’s easy to communicate and integrate with the rest of the work we’ve done…

…and the rest of the work everyone else is doing right along with us.

That’s also why I’ve decided to make the June issue another “over the shoulder” view into how I apply the 7 principles, 14 practices and 3 Baseline Perspectives to build an enterprise-enabled security architecture based on a one-off architecture diagram. As part of the journey, I’ll also walk you how to build your own physical version of the Architecture Wall, which is the system’s way of documenting security architecture in an agile and accessible way. But I’m also going to reveal some tips for building a Digital Architecture Wall using tools you probably already have integrated into your day-to-day workflow that will give you at least 80% of the benefits of the physical wall and be a lot more useful in the WFH world we’re living in right now.

But to get all this, there’s one thing you have to do: you’ll need to be a paid subscriber in good standing to Security Sanity, my monthly print newsletter delivered directly to your door – logistical gods willing – anywhere in the world at no additional cost to you. It’s just one of the many perks you get when you’re a subscriber.

And, in the case of this issue, I’m also expecting that a few people will be taking advantage of another of the perks available only to subscribers—the ability to ask me questions via email about anything I’m qualified to talk about. While I don’t expect there will be issues understanding the issue (and yes, I did that on purpose)…

…I do expect that the content will spark some ideas and further questions about how to potentially put it in practice for you—regardless if anyone’s officially given you permission to do proper architecture or not.

My motto is: if you want to do architecture, then do it—if for no other reason than to reduce your own overhead and protect your sanity.

If you can’t, then there’s something wrong, and you owe it to yourself to go figure it out. However, that’s a topic for another day.

To get this “over the shoulder” view of the application of The Agile Security System on your doorstep within the first couple of weeks of June (depending on where you live), then get thee to this link today:

https://securitysanity.com

My cute little app I now use since I was having some trouble with timezone math a few months ago tells me that as of this very moment, you have 5 days 5 hours and 23 minutes of fence-sitting time left to decide if subscribing to the newsletter is right for you. But for those of you who’ve already subscribed before and your payment has gone through, there’s nothing more you need to do. You’re on the list.

But if you have subscribed in the past and your payment isn’t received by the deadline at the end of the month, there’s no “roll-over” period. Any pending payment will result in your subscription being cancelled, and you will not receive the June issue.

I don’t expect this to happen, but if it does, then don’t come around later saying you didn’t know what would happen. That’s just the way it has to work.

I hope those who had a long weekend managed to stay safe and still have a good time. The good news from this side of the world is that the beverages of an alcoholic nature will be available for purchase for me to celebrate the delivery of the June issue for the first time in over 2 months. However, I’m glad I don’t smoke, because if I did, I still wouldn’t be allowed to buy tobacco…gotta love legislation by decree during a declared National Emergency here in South Africa.

Back to business: think all you want, but don’t think too long. The deadline is chugging along, slow and steady.

Stay safe,

ast
—
Andrew S. Townley
Archistry Chief Executive

The post Reading between the lines of the ubiquitous stick figure appeared first on Archistry.

May 24, 2020

“Whaddya mean, ‘That’s not architecture’? What else could you possibly need to know, Mr. Smarty-pants Security Architect?”

If not the words, we’ve probably all seen the diagrams. Often PowerPoint, sometimes Visio, and only very rarely created in some kind of formalized automation tools, in some organizations, this is, literally, the state of the art when it comes to architecture documentation. And God help you if you actually wanted to get any kind of even remotely vague idea of how this particular bit of architecture depiction related to the 15 you’ve already seen across your desk this week.

It’s just not gonna happen.

It’s all too close to the part of the story where poor little tired and hungry Goldilocks stumbles upon the cozy little house in the middle of the forest, invites herself in and samples the suppers of it’s inhabitants:

“This one’s too detailed. Look at all those lines and boxes! Do those lines cross? Is that the same one?”

“This one’s almost a blank page. So, basically, you’re telling me that there’s 3 solution components, and that’s the extent of the changes required for a $15 million project?”

“Ah…this one’s just right. Separation of concerns. Accountable stakeholders. And, oh…layers!”

Regardless of which we actually end up eating, the odds are, it isn’t going to be anywhere near what we’d really like to see—especially as far as any security concerns go. If the world has a hard time understanding what the real purpose of architecture is…

…it has an even harder time trying to draw something many couldn’t actually describe in the first place—at least, certainly in relation to being effective in communicating anything useful to anyone else.

Still, our job needs to get done, and we’re going to need to have some kind of reliable and repeatable plan to turn someone’s impressionistic interpretation of the classic scene from Lady and the Tramp into something that allows us to not be overwhelmed by more lines than in the aforementioned plate of pasta and lost in the avalanche of assumptions that are required to actually understand whatever said “solution diagram” is attempting to convey.

Fortunately, there is a systematic way to do this based on the 7 principles, 14 practices and 3 Baseline Perspectives of The Agile Security System, not the least of which is Principle #5: violently encapsulate complexity. And since turning “boxes and line” IT solution diagrams into something we can use to assess how much work is required before the thing can see the light of day is such a common problem for security architects…

…I’m going to devote the entirety of the 20+ pages of the upcoming June issue of the Security Sanity print newsletter to helping you do just that.

Based on an initial idea from twitter I wrote about a few months ago, I’ve added some meat to the scenario, and we’ll be walking through how to deftly guide the stakeholders through the journey that often starts with the “simple” question of:

“Are we secure?”

And gives you the guidance you need to build the models and have the confidence to move the conversation to the much more useful and meaningful question of:

“How secure are we?”

And along the way, I’ll be showing you how to prepare for a stakeholder interview, use the Baseline Perspectives to prioritize your architecture efforts and complete the worksheets that will form the basis of The Architecture Wall containing the living, breathing – and 100% agile-compatible – security architecture documentation.

But you’ll only get held by the hand on this walk through Security Architecture Park if you’re are a paid subscriber in good standing, e.g., up to date, before Midnight on the 1st of June. That gives you over 7 full days to decide whether a subscription to the print newsletter is right for you based on what I talk about between now and then raitch hear in these li’l ol’ emails.

On the other hand, if you’re rootin’, tootin’ and rearin’ to go already, then just ride on over to this hear link, and giddyap:

https://securitysanity.com

And if you’re anywhere that tomorrow’s a holiday, lift a glass of the beverage of your choice for all the ones that can’t and remember who they were, what they did, and what that sacrifice might’ve meant for you.

Stay safe,

ast
—
Andrew S. Townley
Archistry Chief Executive

The post Some stick figures, a cloud, a cylinder and a brick wall appeared first on Archistry.

But at $4.19 for a Dave’s Hot ’n Juicy 1/4lb Single with Cheese, that’s exactly how many hamburgers disappear from Wendy’s top-line revenue thanks to a $50M settlement they agreed yesterday.

Those 12 million burgers represent about 4% of the company’s 2018 revenue, and would roughly equate to the kind of impact GDPR fines threaten.

As a bit of history, the incident impacted over 1,000 locations in the US and involved malware installed on their cash registers. According to the reports at the time, this was due to compromised remote administration services operated by a service provider supporting franchise locations.

Thanks to the terms of the card companies insulating the fraudulent transactions from their customers, the financial institutions ended up with the bill for 12 million burgers, and they understandably wanted their money back.

The root cause of the attack seems to be related to successful social engineering attacks against the employees operating the remote admin tools, and these attacks resulted in the 3rd-party service provider employees installing the malicious software.

And this kind of attack is quite common in the retail space, so I ask you: if you’re a retail Security Leader, how do you have confidence that you’re not going to be accountable for a 4% revenue hit by the same type of attack?

Do you know what your real risk exposure is?

Can you measure it on a daily, weekly and monthly basis?

Do you know how much your control investments are going to change that risk exposure in practical terms?

Do you know which of your security strategy components cover you in this particular scenario?

So you might be able to answer a resounding “yes!” to some or all of the above. And that’s fantastic!

If you did, I bet you can also draw a traceable line from the social engineering risk event back through everything you’re doing and connect it clearly to business objectives from the executive team that say things like:

“Grow our top-line revenue”…”Maintain and enhance our reputation and customer base”…and ”Avoid visible public litigation” right?

That’s amazing! Not many people can do that today.

If you didn’t, and you want to change that situation, check out our Security Leadership coaching program here: https://archistry.com/go/SecurityLeader

The whole point of it is to help you build the capabilities so you know exactly where you stand in relation to these kinds of incidents and that you also understand each link in the control chain, the value it brings you and prove you have the means to prevent, detect and recover gracefully if it does.

Cheers,

ast
—
Andrew S. Townley
Archistry Chief Executive

The post When cybersecurity gobbles 11,933,175 hamburgers appeared first on Archistry.