1100 words, 4 1⁄2 minutes.
Introduction
“Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity.” - George S. Patton
If you’ve read my previous post you’ll know that to get beneficial, long lasting, low-maintenance results in Information Security, you need winning systems. Not skills. If you like grinding monotony punctuated by periods of extreme stress and being able to tell people how busy you constantly are, you can safely return to your to-do list. If on the other hand, you like the sound of devising and implementing robust security systems which are resistant to attack whether or not you are outnumbered or outgunned then read-on.
You will always be outnumbered and outgunned.
Disclaimer: I’m not anti-skills. Skills are great but probably overrated. I say this as someone who has spent more than 20 years working in Cyber Security. I’ve attended countless training programs and vendor courses. I even have a semi-related degree. At the start of my career I was lucky enough to spend 5 years at the world’s largest ISP, and got some schooling in security from one of the greats. On their own, skills aren’t enough. Even highly skilled people need winning systems to succeed against the odds we face. Skills without systems can only triumph on a small scale for a brief moment in time. I’d back someone with mediocre skills and superior systems (or doctrine) above a more skilled colleague with inferior systems. So would the army. So would you, because the first thing a skilled and smart person does when facing difficult odds, is develop winning systems.
I’m going to explain why Information Security product companies and practitioners are wasting much of their money and their time trying to beat malaria with turbo-charged fly swats. Then I’ll tell you what to do about it.
Winning Systems For Management
At management level the Information Security industry already embraces winning systems like ISO/IEC 27001:2013. Other completely different industries have their own systems for identification and treatment of risk. You might be surprised at how much these standards have in common.
- Closed loop, feedback is incorporated automatically.
- Iterative, looping and improving beats doing it “rarely but perfectly”.
- Control points and clear demarcation between stages.
- Auditable because evidence is a natural by-product of the system.
- Understandable by business people (mostly).
Winning Systems For Software Engineers
Down at the opposite end of the stack, near the code, software is written according to systems. Developers might not consciously realise they adhere to these systems; they’re just the accepted wisdom.
- Simple standards maximise interoperability, compliance is easy, not hard.
- Loosely coupled beats tightly coupled, APIs and protocols not libraries.
- Failure is accepted to a degree, asynchronous calls, error codes, retries.
- Defensive coding, design by contract, SDLC (you know this right?)
- Scaling considerations impact everything.
We’ve eventually discovered good management systems at the top, and software engineers are diligent people using well thought-out systems at the bottom, so what’s the problem?
The Middle
Somewhere between management and code, sits the messy world of implementation. Implementation is where the rubber meets the road. It’s where we take good software design practices and wise management doctrine and do something stupid with them. It’s the middle where products and services are built and deployed. This is where engineers spend time thinking about architectures, tweaking rules, editing policy GUIs, and responding to alerts. It’s where all the maintenance happens. Patching, upgrades, rebuilds.
It’s where your AI-driven simulacrum failed to detect that malware.
It’s where your $1.8M 200Gbps DPI firewall (with big data dynamic-threat force field) was completely transparent to hackers with an SSL vulnerability.
It’s where your entire Email security complex was bypassed.
It’s where your Information Security budget is
wastedspent swatting flies, trying to eliminate malaria.
In the middle, we invest time and money hiring skilled people, funding their continued learning, managing them and replacing them when they quit. It’s the place where we buy state of the art “next-generation” security products and services. It’s where we pay subscriptions for signature and information feeds. It’s where you buy or build the better mousetrap customers said they wanted. It’s the painkiller business model.
Just keep taking those tablets.
The middle is messy because it is where the beautiful logic of your Information Security policy meets a chaotic tangle of networks, suppliers, products, services, staff, and business practices. This is why you don’t see vendor-neutral guidance on winning systems in the middle.
It’s probably worth developing such guidance, because the middle is where most of the money goes.
From Product Thinking to Systems Thinking
We don’t see vendors pushing this kind of a systems-thinking approach. The painkiller business model is just too good for them. Don’t misunderstand me, I don’t believe there’s a grand conspiracy condemning customers to endless signature updates and new “next-gen” products. AV companies aren’t writing viruses. It’s just that the subscription painkiller products are what the market wants, and what vendors want to sell them.
I could describe all the bad ideas and product architectures that the industry fixates on, but someone else already did that. Nothing much has changed. Instead I’d like to be positive and wean you off the vendor marketing. I’d like you to think about what you want to accomplish first before thinking about the products and services you need to accomplish it. I’d like you to think about enduring systems (systems in the broadest sense of the word) you might employ to secure your data.
Products and services come and go. Over a long enough time so do devices, Operating Systems, and applications. Threats are ever-present. Wouldn’t it be nice to employ enduring systems to counter those threats? If you settled on some winning systems then you’d be in a stronger position to demand better products. You’d find it quicker to screen new vendors against your requirement. You’d know what value you need from a purchase. You’d find it easier to demand evidence from vendors of that value.
- How does product/service X help me implement system Y?
- What evidence is there of its efficacy compared to what I do now?
- We had 12 incidents in 2017, how many would product X have prevented?
So what are these systems? I’ll begin at the end, with automation.
“There is nothing so useless as doing efficiently that which should not be done at all.” - Dr. Peter F. Drucker.
Automation is something that you do once you’ve eliminated the unnecessary and simplified the residual. That which remains is ready to be “automated away”. This eliminate-simplify-automate system is one you can apply to everything else you do in Information Security. Before we get there though, we’ve got all the other systems to implement. You don’t become smart by prematurely automating things that were stupid to begin with.