While security remains an important topic, most discussions focus on the tactical benefits of security. If we change our mindset and vocabulary to focus on the business value that security brings, the efforts to integrate security in the development process can be more effective and successful.
Ultimately, any business decision comes down to return on investment. From a business executive’s point of view, there must be buy-in that investment in security measures, like instituting a new set of controls, will drive business value. The easiest way to explain what is meant by “driving business value through security” is to provide an example — has a security team ever considered that a security tool can introduce risk for rapid delivery teams and ultimately result in lost revenue or market share to a competitor?
In this blog, we will explore how an open standard like IT4IT from The Open Group can help us drive the conversation around the business value of security. This standard takes the entire IT business unit and breaks down the key value streams.
What does a security perspective mean in value stream mapping?
- Strategy to Portfolio: Security teams contribute to business strategy and planning, enabling security alignment with business plans.
- Requirement to Deploy: Security teams help control the quality, utility, schedule, and cost of services they deploy.
- Request to Fulfill: Security teams facilitate knowledge sharing, self-service support, and collaboration between communities of interest.
- Detect to Correct: Security teams integrate Service Monitoring, Event, Incident, Problem, Change Control, Configuration Management, Service Remediation, and Service Level functions for their own services.
Let’s explore these value streams in detail.
Strategy to Portfolio
This value stream takes us from strategy development, through service portfolio generation, then looks at demand, and ultimately derives a selection of security projects that make sense for the business value and risk.
From an IT point of view, roadmaps need to be built together and with security in mind — as security standards and policies are based on the business strategy. Next, the security service portfolio should be mapped to the enterprise architecture and evaluated against the same rubric other IT services are measured, with the customers being the IT unit itself.
Finally, this complete architecture is mapped against demand and a risk benefits analysis is created. This is likely done informally or anecdotally today but capturing the cost of security events can help to shape this analysis.
Requirement to Deploy
In the Requirement to Deploy value stream, it’s all about planning, designing, developing, testing, and deploying. This is often a strong point in organizations today, where most of the funding and personnel time is spent by security to implement and augment security controls within these IT practices.
What oftentimes isn’t done is applying these same principles to security services themselves, with clear requirements gathered from more than just the security team and knowledge management of the services built and made available to IT teams. Following similar methodologies for requirements gathering and project management helps demystify security services and provides defensible history for why certain decisions were made.
Request to Fulfill
In the Request to Fulfill value stream, security teams try to address business requests in a more automated way, similar to how IT departments have streamlined access requests or support ticket triage. Security teams should follow these same IT Service Management concepts: think of Threat Modeling as a Service, or Security Architectural Reviews, or Forensics Investigation requests.
The goal is to provide meaningful transparency and service information that helps meet the needs of speed vs. security. By standardizing the inputs and outputs of a security service, and making it easily accessible to IT stakeholders, security teams can improve adoption and measure key performance indicators of their own services.
Detect to Correct
In this value stream, security teams are often familiar with looking at log files or alerting on anomalies. Our security operations runbooks are quite detailed, but the same rigor isn’t normally performed for other security domains and services.
However, when it comes to application security or vulnerability management, these areas tend to be harder to ascertain historical data and perform detection and response. Tracing root causes or best-fix locations is often quite difficult due to the lack of relevant data. Instrumenting and collecting this data is the first step in this value stream, with the goal of generating business and security decisions from this data.
Conclusion
Security needs to prove its value to the overall organizational goal. In this short blog, we introduced the idea of using an open enterprise framework (IT4IT) to see how different value streams can contribute toward the business need for balancing security and time to market.
The right trade-offs happen during the design of these services so that the business knows the value of security measures. Over time, security teams can build on top of existing services to offer better capabilities, and even offer new ones, that are aligned with business value.
Authors: This blog was contributed by Spencer Koch, an offensive security expert, and Altaz Valani, Director of Insights Research, Security Compass.
Disclaimer: We have sourced all value stream images from The Open Group.