One of the things about growing up on a farm is that you kinda need to learn at least a little bit about tools, engines and basic maintenance—especially on ours. You see, my dad was into antique tractors, and while we did have a few modern pieces of equipment at the time (1970-1995), we also had about a dozen or so from the ‘40s and ‘50s. And it was the older, smaller tractors that we generally used for the day-to-day tasks like feeding the cows (that was a Farmall Model M from the late ‘40s or a Minneapolis-Moline ZA from the early ‘50s).
My dad was also a certified diesel mechanic, because he went to night school at the local community college so he would better understand how to do his own maintenance to reduce his costs and keep the farm going. In fact, to hear my mother talk about when they were first married, he’d farm all day, and then she’d bring him supper out to the shop – or to the field – so he could work on the equipment most of the night to be ready to do it all over again.
I remember as a kid that there was always at least 2-3 tractors in various states of disassembly in our machine shop at any given time because he was installing bigger pistons…or one had a bad oil leak…or there was a loud grinding sound from the transmission.
While I didn’t completely inherit my father’s mechanical skills, the general idea of ongoing and preventative maintenance did rub off on me. There’s nothing worse than trying to pick up a tool, a machine…
…or even a security architecture…
…and have it not work the way it’s supposed to when you really need it.
Sure, it takes a little bit more time to wipe down the tool you’ve been using in the water…
…or to clean off the blade of the spade you’ve been digging with and dip it into the used motor oil drum so that it doesn’t rust…
…or simply to remember to pick up what you’ve been using and put them back where they belong…
…or updating that catalog…or tweaking that architecture model so you don’t forget the subtle changes that you discovered were required in the current security solution the next time around.
But the up-front investment in making sure things are “ready to use” almost always pays off because I don’t think I’ve ever been a situation where time was budgeted for fixing the tool you’re trying to use before you’re able to use it…
…let alone building said tool from a blank sheet of paper when what you really need is something to help you guide the security decisions you and the team need to be making—
Right now. Not in two weeks.
Now obviously, if your security architecture flat-out doesn’t exist, then it needs more than a tune-up. It needs to be built—at least at a minimal level so you can enhance and extend it gradually over time.
But if you do have some kind of security architecture, you can bet the following are sure-fire indicators that you probably are spending much more of your time…
…and working a LOT harder than you really need to be working…
…every single time you need to make a security decision or answer a variant of the question:
“Are we safe?”
Even though that’s the wrong question to be asking, as you might’ve heard me say before.
To know when it’s time to give your security architecture a little bit of lovin’, here are a few of the things you should look out for:
- It’s been more than 2 months since you spoke to owners of the domains your controls are supposed to be protecting
- It takes you more than 4 hours to identify the key requirements and dependencies related to your current assignment
- It’s been more than 6 months since you’ve revisited the core strategic priorities and progress on key business initiatives that generate more than 20% of the organization’s revenue
- It takes you more than an hour to identify, catalog and document any changes, updates or missing controls in the domains relevant to your current assignment
- It’s been more than a month since your risk assessment likelihoods, impacts and frequency estimates driving your current control strategy have been updated based on feedback and hard data from your security threat management and incident response teams
Any one of these problems or situations indicates that YOU are working much harder than your security architecture is to keep your organization safe…
…and that means that you’re probably under a lot more stress than you need to be…
…and that you’re spending much more of your time focused on dealing with operational firefighting and flare-ups than you should be.
And all of these indicate that you’re simply not as effective as you COULD BE in delivering the mission and purpose of security in your organization.
Security architecture doesn’t need to be hard—either to create or to maintain. But it does need to be done.
One of the best ways I know to learn how to do it as quickly, cleanly and easily as I’ve been able to find in my 25 years of professional experience…
…is to join the next cohort of Building Effective Security Architectures that starts in just over 5 weeks. Because as part of that 7-week journey with your fellow security professionals, you’ll learn where to focus so you get the most leverage…and the most benefit…from the time you spend and the work you do.
And that means that you’re going to likely be a lot less stressed, a lot more capable, a lot more respected…
…and a whole lot more relevant to the organization you’re trying to protect.
To make sure you claim your spot, use this link to register before those 5 weeks turn into 5 days…that turn into 5 hours…and then you’ll have watched that ship just sail on by:
Stay safe,
ast
—
Andrew S. Townley
Archistry Chief Executive
