Platform based development
What technological and legal prerequisites must be fulfilled or must first be established?
What can (and must) the automotive and supplier industries do now to set the course for the future – a future that belongs to autonomous driving?
A key feature, and also a key benefit, of cloud-based, digital native operations is the rapid growth in use of collaborative development platforms. This not only dramatically shortens time to market, it also enables better testing in virtual environments, while supporting agile ecosystem working. In this way, enterprises can extend the DevOps method, which has transformed the efficiency of software development, giving access to richer sources of innovation and expertise, leading to improved quality, customization and time to market.
These benefits are highly attractive to enterprises in almost every sector, but there is another side to this story: the need to ensure that security keeps pace with ecosystem DevOps, and that the move to co-development in the cloud remains not just fast but completely secure, as well.
In practice, we need to embed security leadership, methods, processes and human expertise at the heart of online development. By integrating security into software development lifecycle processes, enterprises can identify possible security vulnerabilities and mitigate them at the earliest stages. This saves time and money in the otherwise inevitable requirement to resolve problems when they appear later in the process.
The goal must be, in fact, to engineer security issues out from day one. It is easier and much less costly to prevent vulnerabilities from happening than to solve the problems when they appear. We at NTT DATA would also say it is not just wiser but necessary to be proactive in this way. We believe that most software/service development processes will be cloud-based and ecosystem-enabled in the near future. Now is the time to make sure they remain secure at all times.
From DevOps to DevSecOps
It is clear that leading software and solution developers take the same view as us, which is why we are seeing a rapid rise in the demand for design and implementation of secure software development life cycle models (Secure SDLC or S-SDLC). These projects integrate security tasks in every phase of the SDLC, while also automating as many of these tasks as possible. That is the key to implementing what is known as DevSecOps.
The trend towards S-SDLC is helping to ensure that software development becomes more security aware and also more mature. Making this happen successfully and fast, however, is not simple and requires significant investment, not just in terms of finance but in human expertise. As is all too common when discussing advanced technology-based concepts, not enough time and attention is given to the people related aspects of change. To make the move from DevOps to DevSecOps takes leadership and know-how. That’s the reason for the growth in importance of Security Champions inside large organizations.
The need for a Security Champion
Taking the decision to embed security considerations into software development is easy in principle, but making it work can be complex. The natural first step is to require an organization’s security analysts and architects to take a lead role, which requires them to become expert at company projects from a functional perspective.
This not only requires security specialists to expand their scope of expertise, it also implies a rapid growth in the size of security teams. Now they have to be directly involved in all development projects, quite apart from doing their core tasks (policy setting, threat evaluation, oversight and intervention).
To free security teams from direct involvement in day-to-day activities of all development teams, A new concept is required: the Security Champion. In practice, this reverses the previous model by nominating an individual within each development team to be responsible for security in that project. They are responsible for interacting with the corporate security expert team, seeking input, support, specialist insights and troubleshooting as and when needed.
This approach makes it possible to restrict the growth of the central security function, while nevertheless maintaining the continuous, end to end security focus needed by every project. The Security Champion role is, therefore, a key factor in enabling the move from DevOps to DevSecOps.
Capabilities and role
In the world of rapid platform-based development, the role of Security Champion is critically important. It also requires a wide range of skills and experience:
- Extensive experience and technical knowledge in software and solution development.
- A good working knowledge of security issues and security management techniques. This does not imply that the Security Champion must be a “career” cybersecurity expert. It is possible to develop a sufficient level of capability through targeted training.
- A position of authority in the team, enabling them to mandate revisions and mitigations when they identify potential failings (it is not enough simply to “recommend”).
Security Champions must therefore combine capability with seniority, as this is the only way to ensure they can fulfil their mission, which is to make sure that enterprise security requirements are achieved by ensuring full compliance at development stage. To do this, they will need to:
Collect security defect information provided by architects and security analysts (Security Brokers) following analysis and audits. They then need to interpret the security reports based on output from DevSecOps tools.
Analysis then leads to effective action, as the Security Champion defines clear vulnerability mitigation tasks and ensures these are included in the development team workflow, backed by guidance and education where needed to ensure that team members know what they need to do to improve the security level of the software.
These tasks will then be Monitored by the Security Champion, who remains engaged and responsible for ensuring that defects are fully resolved. They will then promote security awareness, backed by training for the development team, leading to progressive improvements in output, with a steady reduction in defects over time.
Evolution and continuous improvement
The Security Champion role was created to give security mitigation a higher profile in development without the need to extend the size of specialist security functions, nor for embedding individual specialists within development teams. This ensures that DevSecOps activities remain as agile and efficient as possible, while correcting faults and vulnerabilities easily and fast.
We expect the role and scope of activities to evolve in the following ways:
1. Incorporate the Security Champion profile into projects. This frees the security specialists within the business from time-consuming and costly direct involvement in development. It recognizes the fact that it is far simpler and less costly to train a developer in security as a supplementary skill, rather than recruit new security specialists.
2. As a direct result of these developments, we can see the rise of a Security Champions Program within the software development community. This will provide a constant stream of suitable profiles, normally made up from senior developers with extensive knowledge of key projects, who are trained to be future Security Champions. Such programs are likely to include incentives and recognition (based on weaknesses detected and incidents resolved…), aimed at motivating engagement in an activity positioned as contributing to personal advancement.
3. Promotion of security awareness at a global level, based around corporate programs to promote knowledge and training in secure development. This is simple corporate self-interest, as early detection reduces time lost and costs written off. Embedding security from the start cuts disruption and enhances profitability and competitive advantage.
4.Automation through industrialized processes is increasingly important. Automating security analysis processes and tasks reduces time, allowing better adaptation of security tasks to agile environments, with consequent reduction in economic costs. This also implies rethinking of current (now obsolescent) manual processes, which will require an initial investment in tools and training.
In time we are certain that the approach outlined in this article will evolve into different forms. The key is always to provide the right approach for a change market.