Simplify with Cyber Security Fundamentals

One of the biggest, most consistent traps I’ve seen organizations fall into is making security overly complicated. It’s understandable—security as an industry is still relatively new and most of us feel like we are making the rules up as we go. And one of the cruxes of not understanding cyber security fundamentals is to make it more complex than it needs to be.

So, today, I want to give you permission to simplify and a powerful tool to help you do it. Ready for it?

Ask WHY.

  

“Why?” so you better understand the purpose and intent of what you are being asked to do so you can act upon it appropriately (and more simply).

Once you’ve done that, it becomes much easier to figure out how whatever it is fits into your environment. And that’s big.

I think it’s important to remember that rule makers are often either 1) writing rules based on a specific type of organization and hoping the rules will apply equally across all organizations or 2) trying to write rules for a broad swath of organization sizes and industries. Neither is perfect and neither produces very universally applicable rules. You should always consider the intent of the rule and make sure it is right-sized for you (and yes, except for very specific circumstances, this is acceptable to do).

Want to see how easy – and awesome – this is in practice? Let’s run through some common security concepts.

You Need to Create Information Security Policies

At Secure IT, we do a lot of assessments and because of that, we see a lot of policy. We READ a lot of policy. We feel the pain your end users feel when you talk about policy.

BUT IT DOESN’T HAVE TO BE LIKE THAT!

So, WHY do we need policies? At the end of the day a policy is a rule about what you can or can’t do.

For information security we need to lay down the expectations for both the organization as a whole and the users who make up the organization. Your policies, once defined, should almost seem like common sense – because they are. But it’s the act of writing them down and adopting them that makes them official (and oh so important).

The more simply and clearly you communicate your policies, the easier it will be for your reader to understand. Here is an example policy around Clean Desk:

It shall be the policy of COMPANY that all workforce members shall maintain clean and orderly office work areas and desks that are clutter-free in order to protect paper documents that might contain sensitive information about our patients, customers and vendors. A clutter-free office and desk projects a positive image when customers visit our facilities and reduces the threat of a security incident as confidential information will be locked away when unattended.  Sensitive documents containing PHI or proprietary information should not be left unattended and in the open as these documents could be stolen.

That’s a mouthful… Now, let’s simplify:

• Computer workstations must be locked when workspace is unoccupied.
• Sensitive information must be removed from the desk and locked in a drawer when the desk is unoccupied and at the end of the work day.

Both policies said essentially the same thing – which was easier for you to read and understand?

As an experiment, the next time you visit your gym stop by the pool. Notice how their pool policies are posted in an easy to read, bulleted sign that you can easily make sense of. Try that with your policies: narrow your policies down to the most basic, simplest statements you can; use bullets instead of paragraphs for easier reading; take out the narratives around the statements and save those for training or conversation, whenever possible.

You Need to Implement Change Management

I’ve yet to encounter a technology or cybersecurity professional whose eyes light up when I bring up change management. And yet, nearly every regulation asks for it. So, let’s figure out WHY.

Why is change management such an important cyber security fundamental? From my vantage point, change management is great for:

1. Ensuring that you aren’t breaking someone else’s fix (aka wasting a whole bunch of time)
2. Ensuring that the change was made by someone who was supposed to do it (aka making sure a bad guy isn’t on your network)
3. Ensuring that those “temporary” fixes don’t become accidentally permanent (aka “Oops, Port 3389 was only supposed to be open while we were troubleshooting”)

You may have other really good reasons for change management too—believe it or not, there are more than what I’ve noted! The key to this beast is determining what your WHY is (I promise there is one) and then building a change management process around it.

If your biggest concern is not replicating (or ruining) work then create a ticket for every major change you make so someone knows what has already been done. If your concern is protecting your firewall, get approval from your manager or set up a quick weekly meeting to review changes so you have an OK (and documentation) to make the changes.

ITIL is great – for some organizations… Just like music theory is great – if you are aiming to be a composer. For the rest of us, learning enough cords on a guitar to play “Stairway to Heaven” is perfectly sufficient.

You Need Procedures

“We’re too small to document our procedures.” “Procedures require more upkeep than they are worth.”

But, you’re not.

Why are procedures so important? They ensure that everyone (even if it’s just 2 of you) are doing things the same way. They ensure that if one of your key players leaves you can still get important things done. They ensure that when you bring someone new on they aren’t stuck standing around waiting for you to find time to explain how to do everything.

AND they ensure you get to take a vacation (or even just a day off) once in a while.

People get quickly overwhelmed when we talk about procedures. They think that they must write documents of significant length that are hard to write and hard to upkeep (and likely don’t get referenced very often). And of no one is looking at them or updating them (and probably doesn’t understand them) then they aren’t very valuable.

But if our WHY is consistency and redundancy let’s focus on creating procedures that cover it. The best way to write a procedure, in my opinion, is to ask the person who does the thing to explain the steps they take to do it – high level, simple. And write that down. You can always add more as you go (or include who to contact if more information is needed) but that is all you need to start to build your procedures. Really.

And THEN Add Complexity

And, of course, I don’t mean to imply that you can ignore all the complexity that may come your way, but if you start simple, you can add in layers as appropriate instead of having to muddle through something you barely understand and try to add more to it.

Take, for instance, policies. Start basic (this is why frameworks like ISO 27001/27002 and NIST CSF are so great to leverage) and make sure you are covering all of your bases. Then, as you incorporate other requirements – think PCI DSS, HIPAA, etc. – you can build out more structure, more definition, or more detail where necessary without overcomplicating the whole program.

There Is A Why

At the core, it’s worth remembering that for much of information security, there is going to be a legitimate WHY. I encourage you to find out what that is and then make it work for you. This will help ensure you have a simple, yet meaningful, cyber security fundamentals!

For assistance building or simplifying your cyber security and information security fundamentals and program, visit secureits.ca to learn more.

* * * * * *

Author: Lyle Melnychuk