Organisations need not look at security as a cost but, rather, as strategic investment. Here’s a blueprint for security — from organisational vision to practical tools — that will help them build that perspective.
Recent technological advancements have significantly improved software security. Yet, a critical challenge persists — the gap between security strategies devised in boardrooms and their real-world implementation. Often, these strategies lack the practical insights needed for seamless execution. This disconnect not only jeopardises an organisation’s security but also its foundation.
To build secure software that remains so throughout its life cycle, organisations need a stakeholder-driven perspective in security strategy design, which acknowledges their feedback loops and aligns security objectives, actions and principles with technical and cultural challenges.
In this article, we present a transformative, yet simple and practical, depiction of the security strategy design that addresses these issues head-on. The ‘security perspectives framework’ explores the four fundamental layers that form an organisation’s software engineering landscape. Understanding these layers allows organisations to redefine asset protection, improve resilience, and transform security from a mere cost into a strategic investment.
So let’s explore the layers of an organisational security strategy, covering policies and guidelines to the tools and training needed for execution. Understanding these layers helps organisations lay their assets in a logical flow that governs the next layer of actions.
Layer 1: Building a vision to define how things need to be done
The vision for organisational security forms the foundation of strategy design. It should articulate how the entire organisation approaches security to safeguard business assets, resources, functions/units, and stakeholders.
Who are the stakeholders?
The stakeholders at this layer are executives, CXOs and leaders who define organisational-level priorities.
What are the objectives?
The objectives of this layer are to define security core principles, establish a global and regional security vision, and outline compliance-related security awareness plans.
What are the intended outcomes?
Involving leaders early in security strategy design helps avoid the pitfalls of isolated decision-making. It helps leaders devise policies and garner community support at the topmost level, cultivating a security-focused culture and fostering shared ownership of security objectives. This empowers business units to embed security into their work, making it an inherent part of everyday activities and creating a sense of collective responsibility for security goals.
Layer 2: Making the vision a reality by outlining the business unit security journey
The business unit security journey acknowledges the unique security needs of each business unit, guiding it to effectively implement the organisational security vision.
Who are the stakeholders?
Here, stakeholders feature leaders from product lines, accounts, or functional departments who hold accountability for business units.
What are the objectives?
The objectives at this layer are to define business unit-level risk management frameworks as well as business continuity plans and ensure health monitoring. An additional aim is to provide resources and direction on security best practices for projects under each unit.
What are the intended outcomes?
This layer ensures that security strategies are not imposed in a top-down manner and that ground-level practicalities are also considered. Risk assessments and plans should align organisational security initiatives with the needs and risk profiles of individual business units. The feedback loops that are initiated by the ground-level implementation should help refine the overall security vision and goals. This will ensure a more practical and effective approach to security.
Layer 3: Bridging the strategy-execution gap with effective project engineering practices
The project engineering practices layer bridges the gap between high-level security objectives and the hands-on work done by development and project teams. It ensures that the strategy properly informs every part of the engineering machine.
Who are the stakeholders?
The stakeholders include team leads, security analysts, and project communities who integrate security into every stage of the project life cycle.
What are the objectives?
We want to define the practice model, implement technical guidelines and architectural reviews, and ensure training for each team member. Additionally, we need to set up the right metrics to track and recalibrate the security posture regularly.
What are the intended outcomes?
This layer applies the organisational security vision to the practice of software engineering. Metrics such as vulnerability density, mean time to detect (MTTD) and mean time to remediate (MTTR) enable feedback on the effectiveness of project engineering practices, and help to further refine the overall security strategy and promote a proactive approach to security. These then act as guideposts for engineering teams to make informed security decisions and follow best practices.
Layer 4: Ensuring sustainable security practice with the right tools and frameworks
At the innermost circle lie tools and frameworks. These support secure system development and maintenance, and include everything from automation tools and learning paths to the frameworks and assessments necessary to implement security effectively.
Who are the stakeholders?
The stakeholders here are the development teams who face and overcome the everyday challenges of software implementation.
What are the objectives?
The objectives here are actionable resources like secure pipelines, coding guides, toolkits, and checklists. Additionally, we want to create metrics for the tools and frameworks too. These should include automation coverage statistics and the percentage of false positives; they should be refined regularly to ensure they remain up-to-date and relevant.
What are the intended outcomes?
These tools and frameworks help operationalise the security vision, building consistency in the software development process. They should enable continuous improvement by staying on top of evolving trends and providing insights from the organisational grassroots to the other layers — while remaining true to core values and principles.
Mapping the economics of security
Before concluding, it is pivotal to recognise the delicate balance between security and the economic foundations governing organisational decision-making. This model highlights a paradigm shift — from perceiving security solely as a cost to recognising its potential as an investment, and allows for adaptable economic adjustments.
Costs, investments and trade-offs: Every security decision has an associated economic cost. For example, consider Layer 1, where the vision for organisational security is formulated. Setting a vision involves defining core security principles. But what’s the cost of not incorporating feedback from grassroots levels, as highlighted in Layer 4? Perhaps it is the expense incurred when remedying a security breach that could have been avoided with a tool flagged by a grassroots team. Using the economics of security, such costs can be quantified, guiding organisations in understanding the trade-offs between immediate costs and potential future savings.
Investment valuation: Allocating resources to ensure security is an investment, not merely an expense. Consider Layer 2, which delves into the security journey of business units. If a particular unit is at a higher risk due to the nature of its data, would the return on investment (ROI) not justify a greater security allocation here? The economics of security helps frame such decisions by projecting the value of proactive security measures against potential losses.
Economic metrics for strategy refinement: At Layer 3, we discuss bridging strategy and execution. Here, metrics such as vulnerability density can be associated with direct and indirect economic costs, such as system downtime or loss of customer trust. By associating each metric with its economic consequence, organisations can prioritise areas that offer the most value in terms of risk mitigation.
Operational efficiency with tools and frameworks: In Layer 4, the tools and frameworks are the workhorses that operationalise security vision. The efficiency of these tools can be measured in economic terms too. For instance, an automation tool that reduces manual hours and error rates has a direct ROI, while a framework that prevents a major security breach safeguards potential revenue loss.
Embracing the economics of security provides organisations with a tangible, quantifiable method to understand, measure, and enhance their security posture. It allows for better resource allocation, clearer understanding of ROI on security investments, and most importantly, a more secure and economically viable future.
No organisation is a monolith. Yet organisations still often manage security centrally, removing accountability from several stakeholders and leaving the security team understaffed. This opens them up to risks and vulnerabilities that cannot, ironically, be resolved by centralised decision-makers.
To change this, it’s imperative to approach security as a layered problem. The ‘stakeholder driven security perspectives’ framework offers a practical and simplified approach to decentralising security accountability and guidance. It ensures security objectives, actions, and principles align with the realities of the organisation’s people, processes, technology, and culture, as well as the evolving demands of the industry and domain. It helps weave security into the organisation’s DNA, building preparedness for threats in an ever-changing threat landscape.
