Security as a Business Enabler

I passed 7 years at Loop Secure this week and I posted to LinkedIn about opportunities, risk and a bit about my journey through the infosec space over the last two decades. The feedback was overwhelming and it was great to get comments from people from my past, but one former colleague made a comment that he remembered my default answer back in those early days being “no”, and that took me a bit by surprise. I’m hoping that was just the old Dave from 10+ years ago that wasn’t as good at expressing himself. I’ve always tried to say yes to everything I could in my security roles because I’ve always seen infosec as a business enabler rather than a disabler. So after pondering Paul’s comments for the last 24 hours, I thought I would throw together my thoughts on the subject as there is nothing more important in infosec/cyber than supporting the business and enabling them to do great things, and the last thing you want is to be seen as a business disabler.

Security That Disables the Business

I remember my first introduction to an infosec person back in 1998. This was in my first IT job before I moved into infosec. I guess he was pretty typical of security officers back at that time. Sorry if you are reading this and were different and I just lumped you in with him ?? He was a “no” man. If anything you wanted to do even slightly impacted the security posture of the organisation, it was no. No working through the problem to find a solution or how he could leverage a compensating control to reduce the risk you might be exposing, it was just no. It was up to you to walk away and work out another way to do your job that didn't impinge on his way or the highway mentality. It always felt like he didn't actually have the company's best interests at heart. It just felt like he was a control freak and loved the power trip. Thankfully people like that have (mostly) gone the way of the dinosaur.

I’m actually extremely glad I knew this person because they were a key influencer in how I perceive security and has always pushed me to not be that “no” man. Years ago I worked for another consultancy whose tagline was “Security that enables business”. That mentality has always resonated with me and is one of the reasons I applied for a job with them at that time.

As security practitioners, we are there to support the business. Enable them to do what they need to do to be successful. At the same time, we are there to protect the business from confidentiality, integrity and availability impacts that will impede their progress and the achievement of their strategic objectives. In every interaction with the business, we should be saying yes every time we possibly can, of course taking a risk-based approach when we do. We can never say yes to everything without severely impacting the organisation’s security posture, but there is always a way to do what they need while reducing the risks it exposes. This is where compensating controls come in.

Exception Management

Exceptions. This is a critical piece in security but something that is so poorly understood and implemented. I have these discussions with clients every week and very few have ever discussed exceptions let alone have a policy exception process in place. A key component of any organisation's security governance and risk management processes are policies. Take your standard security policy as an example (ignoring all the other underlying policies). It is there to provide structure, standards and guidance on how to ensure an organisation is run securely. It is best practice and a best-case scenario of what you hope will always be complied with. If you have ever developed a security policy for an organisation, when it goes through the approval process there is always pushback from someone on some component, generally along the lines of “we can't do that. It would severely impact the business”. At that point, those that don't understand exception management take that piece out, reducing the overall security of the business.

Most organisations have the misconception that policies are all or nothing. Every piece has to be complied with at all times. This is not the case. Policies are there to support the business, not stop the business from doing what it needs to do. Often business requirements will be more important than what’s in a policy, and that’s fine. We just need to work out how to reduce the risk imposed by this bypass of policy so we can support the business while minimising risk.

Using the above reaction to the policy, if at this point you drill into the actual issue with this one requirement in the policy, you often find that 95% or more of the organisation can adhere to it, but it would impact 5% of the organisation, often one business unit or group of employees. You see this quite often in development areas or IT where they require more access or freedom to perform their job function. So in this case, the policy clause can stay in because it's relevant to 95% of the business, and you create a policy exception for the 5%. This lets you define who is excepted from the requirement, why, for how long, and most importantly, what compensating control is required to reduce the risk of them not adhering to the policy. This can often be something like additional logging and monitoring to identify potential issues exposed by not adhering to another control.

“How long?” is also critical to track and shouldn’t be more than 12 months, ideally quarterly. Requirements change, business processes change, technologies change, and the threat landscape changes. Just because they need an exception now doesn’t mean they will in the future, so it’s imperative to reassess at defined intervals. Hopefully, at some point, the exception is no longer needed.

Security That Enables the Business

Information security/cybersecurity has a long history of negative perceptions that we are still trying to drag ourselves out of. The early days of security technology didn’t help. Antivirus that heavily impacted system resources still has old school sysadmins wary of putting anything security-related on their systems. Early firewalls and web filters that blocked excessive amounts of sites and applications still leave a bad taste in many people’s mouths. When you couple this with early security professionals saying no because they didn't know better and were trying to do their job and protect their organisations when the Internet was new and we had a wave of new threats, we have a dark history of disabling the business.

Be one of those security practitioners that works WITH the business to support them. Embracing new technologies, innovation and rapid growth all pose a heavy security risk but they are needed to support the business in achieving its goals. If you have ever been involved in improv, a key pillar is the acceptance principle of saying “Yes, and”. The “yes” accepts what the person has put forward, and the “and” builds on what has been stated or proposed to keep the discussion flowing. Leverage this idea when dealing with the business. Accept what they have proposed (their requirement) and build on that to ensure you are supporting their requirements but also ensuring risk is aligned to the organisation’s risk appetite.

I wrote another article the other day about working with the business to find the best way to solve their problems and how to get business buy-in. This dovetails quite well with our discussion above. You can read it here.