A responsible enterprise invests in a software product only if it has been secured with the proper measures at the appropriate time within the software’s product life cycle. Organizations must understand how these security measures work, are implemented and behave—and under which circumstances they fail. The most promising route to impressing this knowledge upon software development teams is the designation of full-time security experts.
There are many papers, guidelines and manuals that explain considerations for building secure products. Thus, the security community knows (or should know) what must be done to create a secure product. It is also apparent who should take care of these tasks: the teams building and operating the software.
So, the objective seems simple: Embed security expertise into product teams so that they can build secure products. In general, the basic means of knowledge development are guidelines and training that can be referenced when designating security roles on the team.
There is one caveat: The development of knowledge must be successful. Will the team absorb the input and implement security measures according to best practices? Some do. They follow the rules and produce above-average secure products. Many, however, do not, for several reasons, ranging from pressure to get to market to competing priorities to complete ignorance. The ratio of good to bad products is dependent on many factors. However, the ratio of diligent to negligent projects leaves much to be desired, even if having a completely secure product is ambitious.
Common Security Methods Are Not Always Enough
Secure development processes are not a new concept. One would expect the challenge of how to instill security knowledge to have already been addressed. There are indeed some existing solutions, but it is worth examining under which circumstances they succeed—and where they fail.
Guidelines
Writing guidelines for secure design and coding is relatively straightforward. However, convincing people to read the guidelines is trickier. Achieving security through guidelines is challenging because readers must understand the intent of the guidelines’ author(s) and be able to translate it into concrete measures during a product’s life cycle.
Training
While dispersing security documents is helpful, it should be supplemented by directly targeting the security knowledge of product teams via training. The main idea behind training is that those who know well, do well, similar to the proverb “If you give a man a fish, you feed him for a day. If you teach a man to fish, you feed him for a lifetime.”1
But a security mindset cannot be achieved in mere hours or days of training. The complexity and broadness of the topic demand continuous learning efforts.
Security Champions
Certain personnel may be designated as security champions and educated via longer, more in-depth training opportunities. As a result, these individuals are better equipped to perform security tasks.
Some may ask, “Will they have time to do the job right and be powerful enough to enforce essential security measures?”
Of course, security champions can and should be part of a more holistic, organizationwide cybersecurity strategy. Yet this alone is not sufficient. There is always an upcoming deadline that is more important or the discussion with the central security team is unproductive or there is no appropriate expertise available.
On their own or combined, these security education methods do not make promising candidates for solving the security knowledge gap. Sustainable security success for all projects requires a more comprehensive method.
Introducing Full-Time Product Security Experts
The solution to the challenge of creating secure products is to hire and train engineers fully dedicated to security. They should serve as vehicles to foster a strong sense of security within the product teams. A security engineer should possess a combination of security knowledge, development skills (e.g., coding, design, architecture), infrastructure security insights and other relevant qualifications. Ideally, the security engineer is someone who can configure and code the product’s security characteristics. Security is inherently the engineer’s primary objective, not merely a bonus to be considered after finishing more important tasks.
While there is still a need for compliance and audit checklists and trainings (e.g., for secure coding), insourcing power, knowledge and drive helps product teams implement the right security practices in the right context.
Insourcing power, knowledge and drive helps product teams implement the right security practices in the right context.Several factors enable this role to address the challenges discussed herein:
- Adding a security engineer to a product team ensures that someone who inherently understands security guidelines and requirements is available.
- The ideal security engineer continuously hones their skills to become more qualified over time so that seldom-used knowledge and concepts do not fade.
- A dedicated security engineer has fewer competing priorities and can, therefore, dedicate work to product security. There may still be a need to compromise (i.e., consider security in comparison to other priorities), but with security at the forefront at all times, transparent, risk-based decisions can be made more easily.
The Counterargument
Unfortunately, on many occasions, this technique does not scale. Often, the scaling argument is a synonym for the proposed strategy being too expensive or requiring more resources than the organization has available. But this may not be the case.
Consider a proper security job that takes X amount of time across all projects. Does it matter if X activities are performed by a smaller group of security engineers or a larger group of developers? From a high-level view, surely not, for several reasons:
- A smaller team of experts—each working on more projects, having more experience, and being better trained—is more efficient. They know the tools and are better equipped to verify results and eliminate vulnerabilities.
- A security engineer with the mission of supporting all projects’ security is likely to have more power and objectivity.
- A security engineer supporting the security of several products can potentially align and enforce standards across all products or services.
- The security engineer is much less pressured by the notion of the “train leaving the station” as that person is incentivized differently (e.g., by receiving directives not from the project leader, but from a department head or central security chief).
- An engineer can better judge must-dos because they bring broader experience, meaning they can tune efforts for security up or down per project based on its context. (Anyone who has ever written guidelines knows how challenging it is to include contextual information in a one-size-fits-all document).
Even if a security engineer is designated, the product team may still need to perform some security tasks because the security engineer likely cannot write all security-relevant code or configurations. The final decision as to whether a security measure should be applied or not is up to the project and budget owner.
Enterprises must also consider that utilizing security engineers may also have certain challenges:
- Finding experts can be painstaking. The market is tight, though the global cyberworkforce is bigger than ever.2
- The scaling argument may be applicable if one has a significant number of small projects to complete. The limitation arises from experts’ ability to switch contexts. Supporting 5 projects in parallel likely works, but supporting 20 may not.
- While the suggested approach makes security much more transparent, which is a good thing, if scaling is merely an excuse for a lack of willingness to invest in security, this approach may fail when the cost of hiring the security engineers is made apparent.
Conclusion
If an enterprise wishes to get product security right, a qualified person must be designated to perform security tasks in development. It cannot be broadly assumed that project teams can (or will) ensure secure products themselves. Many members of central security teams concentrate primarily on process design, guidelines and governance, which is not sufficient. Merely reviewing security concepts or checklists provided by development teams is not the solution, either. Rather, a Going to Gemba3 approach to security should be adopted, wherein flaws are fixed directly in the production area on the shop floor as soon as they arise.
Endnotes
1 Wann, B.; “Teach a Man to Fish—Lessons on Leadership,” BenjaminWann.com, 13 May 2021
2 Poremba, S.; “The Cybersecurity Talent Shortage: The Outlook for 2023,” Cybersecurity Dive, 5 January 2023
3 BTOES, “What Is Gemba: Definitions and Tools”
Oliver Kling, CISA
Is an experienced IT professional with more than 30 years of experience. He specializes in information security and its role in software development. Currently, Kling is a senior manager at adesso SE, a listed consulting and IT services company. He leads a team of dedicated security engineers and penetration testers, supporting clients with security expertise.