SecDevOps: good security practices from the development phase

For a long time, the areas responsible for information security management have developed audits of various kinds on the applications and services deployed in the organization in order to identify vulnerabilities that could allow the materialization of certain threats and, consequently, to cause a security incident, as well as to assess the potential impact of such incidents on the organization's assets and on the business processes that support these assets.

These risk analysis processes have traditionally focused on applications and services already in production environments or, at best of the cases, in pre-production integration environments.

Fortunately, the logic of efficiency has led us to base the management of risks associated with applications and services on the analysis of these risks from the design and development phases. The different rules and legal regulations that, for a long time, have been recommending (if not imposing) the need to manage security and privacy from those initial phases have helped to do it.

However, we would make a mistake if we designed the security strategy in application development by delegating that function to the development teams themselves, to the programmers.

In other areas, for example, we have assumed that the employee is responsible for following internal regulations and good practices in the management of the information they handle, without understanding that it is their responsibility to decide which controls to apply or which risks to manage in a priority way; we have defined with the technological areas in charge of the implementation and operation of systems the regulations and controls that they must implement in their activities and in the systems in their functional scope, without understanding that it is their responsibility to decide the scope of these controls, the type of threats to be managed, or the way to scale technological risk to corporate risk management.

For this reason, defining, managing, monitoring and evaluating the "Sec" component when added to "DevOps" can only be one more piece of the corporate security management strategy, aligned with the business objectives of the organization, integrated in the management, evaluation and treatment of risks, and, ultimately, contribute, from its scope, to maintain the integrity, availability, privacy, control and authenticity of the entity's information.

How to implement SecDevOps?

Once defined as another area of ​​information security management, Sec + DevOps, we must also address it in the same lines of action that we use in other areas: people, processes, technology and government.

In the action line related to people, it is obvious to remember that they constitute the greatest asset for the efficiency (or inefficiency) of the rest of the lines of action. In many cases, development teams have been solely focused on reducing the time required to build new applications (or the adaptation of existing ones) that support changes in business processes. We must, within its scope, create shared goals with those responsible for safety management and enrich their culture of innovation, always present in development areas, with the proposal of a secure development framework that, far from making it more difficult, improve it.

In the field of processes, we must consider that current development strategies have reached a high level of efficiency by combining the objectives of speed and quality, so we must try to simplify the security controls model as much as possible without sacrificing corporate risk management. The best approach to this objective will undoubtedly be the automation of the application of most of the controls and their implementation in the development processes already established. Take advantage of existing processes and incorporate thinking, from design, into hazard modelling. The Shift left approach that many development teams have been using can be used to move security requirements to the stage where a line of code has not yet been written.

In technology, there are a number of tools, many cloud-based, that development teams can use to maximize code security without penalizing release delivery cycles. Lines of work such as security as a code and compliance as a code practices allow to include the appropriate controls from the design of the applications and throughout the development of their code.

The technological approach covers the analysis models necessary for the prevention, mitigation and resolution of vulnerabilities that could remain resident in the code:

• SAST analysis (Static Application Security Testing) or static analysis, aimed at analysing the source code to identify security vulnerabilities that can allow the success of attacks directed at the application layer, offering developers notifications in development time that they can apply before the code moves to the next phase of its life cycle.
• DAST analysis (Dynamic Application Security Testing) or dynamic analysis, aimed at analysing the security of applications at runtime in development, pre-production or integration environments. DAST is applied systematically, integrating with the functional validation processes already established in the development life cycle.
• IAST analysis (Interactive Application Security Testing) or interactive analysis, which allows the monitoring of applications at runtime, collecting information on their work model and behaviour and performing automated tests using agents or sensors during the quality assessment phase of the applications.

When these types of tools are implemented in the appropriate processes, the action of the security and development teams is unified, the costs associated with security problems are reduced or eliminated and the quality of the developments improves in consistency.

Finally, in the field of corporate security governance, there is no doubt that embedding security in development cycles, in the design of applications, requires a set of tools and controls consistent with the processes already defined, and will favour enormously the task of the teams in charge of regulatory and legal compliance. Like any other area of ​​security governance, the security strategy in development must be aligned with the rest of the security strategy, and this, with the objectives of the organization and its business focuses.

The digital transformation, the metamorphosis as we propose from Izertis, that every organization is addressing, or must address at some point to ensure its survival, transforms the way in which organizations will work in the future. Corporate governance, especially in the areas of security and information technology, will mark the success of a company.

The appropriate strategy, taking advantage of the knowledge of specialized companies and having, with their collaboration, a critical roadmap, with defined milestones and metrics that allow evaluating its development, will be the key factors for the success of the implementation of security and privacy by design: Sec + DevOps.