Three Key Patterns for Information Security Programs

After too many years witnessing the sham that are “security standards” and regulations, I feel like I have to be a bit of a grumpy old man. I’m not usually this way…well, I am old, but usually not terribly grumpy.

Let’s be really, really clear about something. There are some security standards that I think are quite nice, and give people the right nudge, particularly those who are growing in skills and experience. But then I watch others in the industry latch onto certain standards as if they have found the holy grail, and must bludgeon all who will not bow before this grail. Yes, you Clement Onan*, with your COSO devised SOC TSCs that are incomprehensibly obtuse. Yes, you Herbert Anchovy* with your mis-representation of the NIST CSF as a linear process instead of cyclical. And yes, you, Ernest Scribbler*, who adores the concept of merging every possible standard into an incomprehensible mess with 800 (yes, eight-hundred) individual control requirements used to bludgeon customers into sniveling gits who willingly offer up their checkbooks.

*The names of the guilty (and the innocent) have been changed, or faked, or otherwise obfuscated.

So now that you know my whipping boys, let’s talk about the proper guidance towards a solid security program:

Manage to your risks. Nearly every standard (ISO 27001, GLBA, GDPR, NIST CSF, 800-53, The Bruces…) speak about performing a risk assessment, identifying an appropriate level or risk, and what not. With one big word. RISK. Get to know it. Know what it means – its not how many vulnerabilities your scanner finds. It is about knowing what the business is trying to do to be successful, make money, take care of customers, pay employees, and pay its bills – OPPORTUNITY. It does mean that the company should be able to do those things successfully without having every Tom, Rick, and Dennis Moore running through the IT systems creating havoc, stealing information that is supposed to be secret or proprietary, and stopping productivity of employees with mounds of lupins scattered all about. Now you may have a few distractions, incidents, and lupins, but they should be at a level your executives can tolerate!

Agility to adjust to change. One thing that is certain (so we are told from the age of 12) is change. Business goals change, technology changes, attackers change, thieves change, and even tactics change as security professionals and attackers up the ante. How flexible are you? How flexible is your team? Have you bought into a system of security that you believe you can rely on for the next 300 years? Or are you smart and consider that it is probably out of date before you even buy it. (Let’s face it, all security defense is out of date since it is responding to an attack that has already happened!). Your ability to change, pivot, and adjust should be just as fast as your executive team’s tolerance for what goes wrong.

Continuous improvement. The ability to change is also coupled to the ability to know what works and what does not. Understand what threats are actually preying on your environment, what incidents will cause your executives to be upset, and when your hovercraft is full of eels. Data points like these can be very helpful to identify where your program is working, and where it is not. And with simple translation you can communicate the same to your executives by showing what (realistic) monetary impact is being avoided, and what opportunities are able to continue unabated.

Keep a very important point in mind: Standards and regulations should inform our security programs, not drive them. Our company’s needs, opportunities, and the threats to them should drive our security programs. Standards should be used only as a guide to give those programs a form – a way to order or structure them, nothing more. Trying to take a standard or regulation and say that it covers everything your program needs, is like saying a comfy cushion will get the confession you want!

About Daniel Blander

Information Security consultant who has spent twenty plus years listening, discussing, designing, and creating solutions that fit the requirements presented. President, Techtonica, Inc.
This entry was posted in Uncategorized. Bookmark the permalink.