The Infosec Student Part 2: DevOps is the Answer to Engagement Sprawl

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. 

• You have a set budget, with specific service deliverables.  
• Your client(s), be they internal or external stakeholder(s), will always need more: more risk managed, more reporting, more access to their own InfoSec data, and to the tools used to support them. 

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: 

• “I need you to analyze and report on every firewall deny”,  
• “I need a ticket to analyze every single login failure, with the person who failed engaged to find out why they put in the wrong password” (not surprisingly, this was an IA team that had already made the commitment to the client) 
• “We noticed that an AV agent hasn’t updated its signatures in 12 hours. We need you to treat these like security incidents.” 

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. 

• In FFP you benefit from continual efficiency gains, while in T&M this ultimately reduces revenue (if an external client) and can also place you at odds with how the client wants the work performed.  
• T&M gives the client more leeway in what services they consume, and how; thus, empowering the client to more rapidly pivot based upon their business needs. In FFP new scope typically results in either an executive deciding to expand the scope within the current budget or requires a contract addendum.  
• Finally, programmers/scripters tend to excel in FFP, while those who enjoy a good SOP excel in T&M.   
   

THE PEOPLE, PROCESS, TECHNOLOGY 

InfoSec has traditionally been about people, process, and technology. This poses a litany of challenges, including:  

• The people mean well but are often given more tasks than the hours in the day can accommodate. Churn is often a challenge in InfoSec, given that there is a greater volume of jobs than people with the skill-set to fill them. Also, competencies vary, resulting in a delta in delivery; a persistent challenge for the InfoSec manager, and a persistent frustration for the customer. 
• Processes are time consuming to create, and more so to properly maintain. If adhered to too closely your processes may result in your InfoSec program being unable to quickly pivot to new threats.  
• Technology requires people capable of capitalizing on its features. We often encounter under-comprehension of our technology leading to over-complication, and thus our risk management ROI either is or is perceived to be insufficient. Additionally, your vendors sales team are probably over-selling the actual functional capabilities of the solution, or (more relevant) its ability to integrate with your existing technology.  

THE SOLUTION: DEVSECOPS? 

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:  

• Integrate your static and dynamic application security testing (SAST) and with your Continuous Integration/Continuous Delivery (CI/CD) pipeline. Each code commit results in a scan/test of your code and app.  
• Schedule vulnerability scans against your network/systems, and then consume the data through a data visualization platform (e.g., Elastic, PowerBI).  
• Leverage a configuration management tool (e.g., Puppet, Ansible, Chef, Saltstack) to manage the patch and configuration state of your information system components, while also supporting the ever-critical resiliency.  
• Create dashboards (e.g., in PowerBI) that automatically consume data, and display it for your client. This way, requests for new data points require a single update to your data feed and dashboard, rather than repetitive manual work. Your client can have persistent access to KPI that are relevant to risk management, or just relevant to them.  

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.