Why old techniques don’t work now
The situation in terms of security vulnerabilities and the security workforce is known to be an issue. According to the Common Vulnerabilities and Exposures website https://www.cve.org/about/Metrics the number of published CVE has risen from 25,059 in 2022, through 28,961 in 2023 to 40077 in 2024. At the same time the 2024 survey International Information System Security Certification Consortium claimed the workforce gap grew from 3.4m in 2022, through 2m in 2023 to 4.8m in 2024. Old techniques dictate the answer is to have more dedicated security people, working faster, than attackers.
The time when that will address our issues is in the past, yet we see many organisations continue to try this approach or worse cause progress bottlenecks. It simply cannot cope with current demand:
Customers demand for faster product evolution
Attacker evolving to embrace new technologies including AI
Our services, technologies, and supply chain evolution in ways and at a pace we rarely control
Most security decisions are made by non-security staff as part of their daily role through risk, code, tool and configuration decisions, with many made in our supply chain.
Failing to recognise this reality results in poor decision making including a poor understanding of the risks we are subject to.
Mobilisation of wider workforce
Our experience is that many find security, as a topic, to be daunting and impenetrable where scary words like threat and compliance are used resulting in teams actively avoiding engagement.
The most effective security people and teams we have worked with are those who understand that people are trying to do the job they have been given in the best way possible and are pragmatic about helping them do that.
Failure to do so leads to situations such as ungoverned SaaS solutions or using unmaintained open-source products. Frameworks e.g. TOGAF stress the importance of tailoring for your audience, and we must use similar approaches for security information.
Our goal is to understand and protect our organisations, but the key is not doing it alone. For example, changing a conversation on resiliency to one of the efforts to recreate data helps make it a business issue and a shared goal.
If we take this highly complex, organisation wide, security workload and effectively share security responsibility across the workforce we can achieve far better results. There are challenges, a developer, engineer or product owner is not going to possess all the skills and experience of the security professional, but this is about risk management. Is one person doing 100% security on 3% of the workload a greater risk than doing 90% security on 90% of the workload.
3 Gs – Guidance / Governance / Guardrails
The key to mobilising the wider workforce is giving clear guidance, putting governance in place and setting appropriate guardrails.
Guidance – Help and advice about how to do things securely
Governance – The framework for direction and control
Guardrails – A protective edge to help keeping within the bounds of what is considered secure
In this way we can effectively share the responsibility for security, use our limited resources where they have the greatest impact and maximise our ability to reduce risks.
Guidance needs to be made contextually relevant to the audience. Don’t talk about NIST and ITSHC instead take time to relate it to library selection, code quality scanning in IDE, security scanning in CI/CD pipelines. Guidance is not just static information either - coaching, hackathons and brown bag lunches are highly effective. Take lessons from user research and service design in terms of articulating what we are trying to achieve and then collaborating, prototyping and evolving what works best for our individual organisations.
Governance is not about governing people's output because the rate of output is too high, from annually to daily. In our experience it is critical to secure the process not the product as this ensures every iteration of the product is secure. Assurance, design authority, vulnerability testing etc. should focus on “how” something is created and tested. Security professionals should not be worried about individual vulnerabilities in code, that should be delegated to the development team, they should be worried about the trends in the creation process and how late vulnerabilities are found. Then ensuring root causes for these issues are addressed by product teams.
Guardrails empower teams to make good security choices within risk appetite based on all the other factors they can be given ranges in which to work. Guardrails such as:
AWS services audited for PCI are approved
Azure databricks approved except for PII
Approval from a security perspective should avoid making fixed point decisions and set acceptable ranges instead to empower teams to evolve/adapt within those ranges.
Conclusion
In conclusion we must accept the world the way it is and mobilise a guided and governed organisational wide workforce with guardrails.
Cognizant consulting has helped many organisations through our forward-looking, resilient, strategies. Through our Enterprise Architecture transformation work we can ensure that security remains a critical part of this strategic initiative. Cognizant Architecture Assessment services help balance compliance in a pragmatic and sustainable manner to help you remain secure as your architecture evolves.
