Cybersecurity Requirements & Controls: 5 Tips to Getting them Right

Cybersecurity requirements - Knowing what's most important

We’ve probably all heard what’s important when buying a house, “Location, Location, Location”, but what’s most important when buying a cybersecurity product? It’s the requirements you assess the products against. In this blog, I will give you some tips to help you in getting those right.

Top 5 Tips for Good Cybersecurity Requirements Gathering

Tip 1 – Know Your Stakeholders

This is important regardless of the type of project you are embarking on, but doubly, or even triply, for cybersecurity projects. All projects have sponsors and stakeholders. The sponsors are those team members who are providing the money, resources, and support, that will enable you to deliver the project. The stakeholders are those who have a real interest in the outcome of the project. This will include everyone who is impacted in any way by the project’s delivery, both during and after implementation.

As we know, cybersecurity is everyone’s responsibility, meaning the stakeholders are effectively everyone in your organisation. This could extend even further as changes to your cybersecurity requirements are likely to impact your supply chain too. We can’t have everyone involved with a project, certainly not if we want it to reach completion, but we can identify individuals to represent groups within the organisation. Those champions will be our proxy stakeholders and, the sooner they are involved with the project and supportive of the goal, the more chance we have of a successful implementation.

Cybersecurity can be a sensitive subject. We need to remind people that we all work for the organisation, not each other. The real value for everyone is in what they do, not the ‘responsibility’ they hold – I’m looking at you IT (Information Technology) Admins. Being responsible for a directly accessed superuser account (or 10) is infinitely less important than keeping the systems they are used with operational.

Tip 2 – Focus on the Problem, not the Solution

While it’s common to want to show that you understand the technology being purchased, chances are that the vendors you are sending your RFx documents to know the space even better. What you know far more extensively than any vendor is your organisation.

No one starts any project without a problem to solve. In cybersecurity, an audit finding is often the starting point, but it’s important to recognise the finding as the catalyst, not the cause. Failing in this regard will result in a box-checking exercise that will be poorly defined, overly expensive, and ultimately fails to deliver real value into the organisation.

The audit finding highlights a problem. Your goal is to understand how the business will benefit from solving that problem, beyond the audit finding itself. An example of a common finding is that the organisation has poor control over the use of privileged accounts. If that’s you, don’t feel like you are doing badly or that everyone else has this sorted – you aren’t and, for the most part, they don’t.

This situation is generally the result of two major problems:

• Too many people have uncontrolled access to privileged accounts
• Your security model is too complex

The first problem is obvious, the second is probably causing some furrowed brows. Too many superuser accounts means your security model is significantly more complex. The lifecycle of those accounts needs managing, the activity on those accounts needs monitoring, and the sheer number of those accounts can make it impossible to reliably find malicious activity. All of that contributes to a complex cybersecurity model.

This is a good example of the problem not always being the issue in front of you. It’s also a good example of where your knowledge of the organisation is vital in digging for and identifying the real problem.

Certain people need access to privilege to do their jobs. We need to enable them in that without unnecessarily increasing the risk to the business. With the problem identified, it’s become the requirement. Vendors can propose effective solutions to that problem, and you can link the outcome directly back to a business benefit of risk reduction. Satisfying the audit finding is the ultimate outcome and is a natural result of solving the real business problem.

It's also important to focus on solving ‘the problem’ and not letting scope-creep explode the project into something that becomes too big to address. I’m a huge fan of fewer dashboards, but I’m a bigger fan of the right solution to the problem. When your boat is springing leaks everywhere, sealing the holes is far more important than finding a way to do it with a single plank of wood.

Tip 3 – Change means Change

When we are under attack, both from cybercriminals and the stresses of our jobs, it’s a natural response to look for quick fixes to our problems. Technology is often where we look to solve those problems. The cry of “there must be a tool or app for that,” is heard in offices across the world—constantly. Technology is rarely the whole of the solution.

When you change your toolset, you will need to change the process as well. When we change process, we need to educate our people so they can effectively use the new tool and the new process.

Three elements, people, process, and technology are involved in any significant business change. This is why I say, “change means change”. Missing out any of these areas will result in a less effective solution and a lower return on investment. And in the worst cases, the project may utterly fail, and you’ll possibly be left further back than where you started.

Technology is a tool. Tools are used by people to execute processes. Simply adopting a new technology is the IT version of papering over the cracks. The cracks remain and over time, the cracks will grow – hidden behind the paper – until they cause the paper to split and the wall to fall. If you want to get the best value out of your tools, ensure they are right for the changes you are making to your business processes.

Referring to our example in Tip #2, certain people need access to privilege to be productive in their role(s). The primary business problems, in this example, are an overly complex cybersecurity model and no control over or visibility into when or how the privilege is being used. This points to the solution being a process change in how access to privilege is managed and monitored. This expands into a series of actions as follows:

• Moving away from individual access to privilege (simplifying the model)
• Implementing technology to control access to privilege effectively and efficiently
• Developing process to guide and direct users who need access to privilege
• Training those users in the technology and the process

As you can see, you need to do all these things to realise the value in the solution. Missing a step is going to create friction and frustration. Change means Change and we must embrace that.

Tip 4 – Validate the Cybersecurity Requirements

It’s not unusual for the person running a project to lack expertise in the problem area. A common approach to requirements gathering is to solicit a list of requirements from project stakeholders. These lists are then provided to the project manager. who collates the responses and generates a final requirements list.

Depending on when requirements gathering happens, the list of requirements will tend to include items that are one of the following:

• Features that a respondent would like to see, or has seen, in technology currently available
• Ways in which the solution should work or be implemented
• ‘Depth-charges’ designed to derail the project

The last item is usually the result of engaging the stakeholders too late in the project. I’ve been involved in many cybersecurity projects that involved meetings with confused individuals who didn’t know why they’d been invited. That confusion turns to anger when they are told their working practices are changing, and the technology is already being evaluated. These stakeholders then present ‘requirements’ for the solution that they know are either impossible or highly impractical, though they may, in fact, sound reasonable to the project manager.

The first two items in the list are often the result of stakeholders being briefed late in the project and, thus, having inadequate time to digest the impact to their part of the business. A short timeframe for responses will also often result in a list of features harvested from a vendor website, especially if the respondent is familiar with a particular solution. Familiarity with a solution is undoubtedly a boon with regard to training, and a personal recommendation must not be undervalued. but both must be considered within the context of the current organisation.

The project manager shouldn’t be asked to assess the requirements, even if they are knowledgeable in the subject matter. A proven best practice is to collate the responses and then send them back out to the respondents so everyone can all evaluate all the responses and, ideally, be able to articulate how each will benefit the business. This process also produces a good set of measures with which you can evaluate the chosen solution’s effectiveness.

Sending the raw list to vendors isn’t going to end well, or at least, not as well as it could.

Tip 5 – Make Cybersecurity a core part of your Business Fabric

Cybersecurity isn’t an extra function within your organisation. It’s not an add-on to any system or process you are using, it’s fundamental to doing business in today’s market.

We’ve all seen the headlines over the past 5-10 years, businesses brought to their knees because of a cyber-breach. It’s important to bear in mind that those headlines only tend to cover the larger, more well-known companies impacted.

We are dependent on the technology we use. We are almost entirely dependent on it, in fact. Certainly, to the point that maintaining the operation of those systems is essential for our business resiliency and continuity. When you consider cybersecurity in those terms, it’s clear that every system, and every project to implement a system, must be secure. It’s no longer an option, it’s the first consideration.

We need to change our thought process from “how do we implement this system and secure it”, to “how do we securely implement this system”. That means baking cybersecurity into our processes, everywhere—it should become part of the fabric of the business, the cloth the company is woven from.

Doing this will involve combining new projects with existing and planned cybersecurity solutions. Every time we do this, we add more value to those solution by deriving more business benefits from them. That may be as simple as just easing the implementation of a new system because the environment is already well-secured and prepared for expansion. By using every cybersecurity project to move toward that ‘baked in’ approach to cybersecurity, we increase the value of those projects and make business run smoother.

Any solution we implement needs to work well within our organisation and, in achieving this, becomes a fundamental part of the process of business itself. The more solutions we implement that enable our colleagues to be as, if not more, productive in their roles, the more they’ll be willing to be a part of the cybersecurity journey.