Daniel Deter is the Manager of Information Security at Green House Data. Follow him on LinkedIn.
If you’ve newly set foot on the path of an InfoSec student, you will benefit from understanding this topic. If you’ve been around awhile, you’ve lived it.
There are two basic types of Information Security engagements in terms of how they are scoped. This is most applicable to managed services providers (MSPs), though it remains relevant to a practitioner supporting an internal corporate or public sector security team. For the sake of simplicity, I’m going to call them FFP and T&M. The purpose of this blog isn’t to dig deep into financial models, but rather to discuss, in a simplified manner, how they drive the delivery of work. And then, to discuss an alternative model.
With both Fixed Firm Price and Time & Materials engagements – and really any other model of InfoSec contract scope – there are some overlapping goals and realities.
They diverge in how you approach that ongoing need for more access, control, and results as your client gains knowledge from your security work. With FFP, you’re terrified of giving your client direct access to their data, understanding what the result will be. Here are a few actual requests I’ve seen from clients:
These are all time-consuming tasks that are not likely to move the needle much on the overall security posture of the organization.
With Time & Materials (T&M) Engagements, conversely, you welcome the fact that your client(s) will always need more. You therefore advise the client of the additional hours that will be required for the task. This can be lucrative but may also eventually drive you insane should the client prove demanding.
There are pros and cons to each of these models. The purpose of this blog isn’t to comment on the viability of either, though I’ll offer a few relevant observations.
InfoSec has traditionally been about people, process, and technology. This poses a litany of challenges, including:
Let’s talk DevSecOps. If you’ve read your DevOps handbook you understand that in modern information systems, and the applications we layer on top of them, security is already an inherent component of DevOps. Thus, DevSecOps is redundant. I acknowledge this fact. Now, let’s talk about it.
InfoSec done well focuses on managing risk and on delivering value to the client. The client is anyone that you are accountable to. They may be someone you sold a service to, or it may be your boss, or your C-level, or quite often a project manager representing any of the former. Infosec is not a function of restrictions; rather it’s a function of managing risk through the tailoring of technology and controls while enabling the business/mission.
It’s important that when focusing on securing our application, environments, and data, that we don’t forget that there is a business owner who is deciding to pay for it. Being able to manage risk while quickly pivoting to add client value inherently supports managing risk. So how do you get around the limitations of FFP and T&M? You automate, you orchestrate, and you empower the client to make decisions on how they want to consume risk data.
Question: “Are you suggesting that we say yes to whatever the client asks for?”
Answer: “No. That can be counterproductive to both you and the client. I’m suggesting that we treat the client ask as representing a legitimate gap, and then help the client close that gap. Often that means helping the client to better understand how current implementations address their ask. Sometimes it means advising the client what the cost of meeting the ask is, and then letting them make a business decision.”
There is more to this idea than a single blog can cover, though here are a few examples representing core functions and reporting:
Question: “What about our security team? Are you saying we can dump them?”
Answer: “Adopting a DevOps-based mentality/approach to InfoSec doesn’t change your need for a security team. What it does is better position you to focus them on a task that humans continue to be well suited for; monitoring the environment for anomalous activity and responding to it. Also, in scope of your IA/GRC team, it aligns perfectly with their mission; to measure your InfoSec program through the collection and tracking of relevant KPI.”
Ultimately a DevSecOps (if we must use the term) approach allows you more flexibility and reactivity when it comes to client requests. Once your DevOps framework is in place you can do a better job enabling the client with relevant reporting and data. For InfoSec teams that favor T&M, you can more closely align with shifting goals and priorities, reaching levels of efficiency that enable you to take on more projects. For those that lean towards FFP, you have better ability to change within your scope constraints.