In previous articles, we talked a lot about how security should be organised to accompany agile projects: the change in the security paradigm to ensure Security by Design, how to organise the ISS teams in the face of these changes, the possible methodologies for continuing to analyse risks or get security approvals (and a general reminder of what security looks like in agile).

These articles were mainly about the organisational and methodological paradigm shifts that ISS teams were undergoing, to be able to best support projects, which deliver code much faster.

The links between Agility and DevOps

By shifting the focus towards the development teams, it is now a question of dealing in greater depth with software solutions and processes enabling security to be integrated directly into the development pipelines and into the daily lives of developers, where Agile and DevOps methodologies, although they aim to provide the best value to customers, will be expressed differently.

As the DevOps movement was born later than Agile methods, development teams were organised earlier than operations in an iterative and rapid mode for application and service delivery. DevOps principles bridge this gap by bringing Operations and Development teams closer together, and by offering solutions to accelerate delivery through the strong automation of the software development lifecycle, via CI/CD pipelines. In the end, the two approaches feed off and complement each other, to deliver faster and with better quality, thanks to the automation of a large number of tasks, thus avoiding human errors.

What about security?

Back to our topic of interest, it is now a question of automating security as much as possible. Just like the Agile and DevOps methods, Security in Agile and DevSecOps are also closely related. The idea is to bring security closer and closer to the development teams, but also make it as fast as possible. A key profile of the security principles in Agile is perfectly suited to DevSecOps: the Security Champion. As described in the article “How to structure SSI teams to ensure security in Agile at scale“, this is the security ambassador within the development teams. They are an integral part of the product team and are present in every sprint. Their role is to ensure that security is considered in each sprint in the development of User Stories (by integrating Evil or Security User Stories already written, or by helping to write them). The Security Champion can come from the world of development and become more skilled in security issues, with the help of the Security Guild.

To take it a step further, the Security Champion can also help their team understand automated security solutions, with the help of a specialist from the ISS team, who will help them to develop their skills in application security.

Having said that, is it because Agile Security and DevSecOps are linked that one should automatically embark on a transformation programme towards DevSecOps?

Some preparatory questions for embarking on DevSecOps.

In line with any major transformation project, it is worth asking why you are doing it, making sure you have a plan and the right sponsorship. DevSecOps is no exception to the rule, even if the questions to ask are specific.

Defining the scope and objectives

Firstly, before you start, you need to identify your motivating factors. Is it to deliver faster? Better? More securely? Will the problems encountered by the Dev, Sec and Ops teams be resolved by bringing the skills together? This is to prioritise efforts and ensure that the project can be ‘sold’ to sponsors. Next, the scope must be identified, trying to delimit it between transitional scope (short and medium term) and target scope (long term). Work can start on an application portfolio, a factory for testing, followed by creation of a roadmap for deploying the model to the full scope.

The current maturity of the organisation in terms of tooling and automation in the product development cycle should be assessed. A good knowledge of the tools used in the pipelines is a prerequisite. If there are still too many grey areas, an inventory of existing tools and an inventory of the practices and processes in place should be put together first.

Presence of the essential building blocks of the CI/CD pipeline

Before security can be integrated into development pipelines in an automated manner, it is first necessary to ensure that we have a good vision of what a state-of-the-art pipeline might look like. It is possible to embark on a DevSecOps programme without operational pipelines already installed but having a clear idea of the target is key. Here are some examples of solutions:

Figure 1 – the essential building blocks of a DevOps pipeline

The company must also be able to quantify the developments carried out internally or externally, with development agencies. Indeed, a complete pipeline will be useful for companies developing mainly in-house: it is an indispensable tool for developing quickly, with the right security tools integrated into the pipeline. In the case of external developments, the principle is different, and security is less “easy” to control: agencies will not necessarily give access to their pipelines or their source code. They may only deliver executables or images, via remote repositories for example. Integrating security is therefore done by more traditional means: via Security Assurance Plans (SAPs) for example, or by contractually obliging agencies to train their developers in application security, via training software solutions (for example CodeWarrior, which delivers ‘belts’ according to the level of training achieved).

Secondly, one of the most important ideas is that the pipeline is built in stages. In line with the “test and learn” approach dear to Agile methods, a “pilot” version of the pipeline can be deployed for a volunteer product team to test it over a few weeks/months. The deployment is then carried out progressively, according to a pre-established roadmap. In most cases, companies first set up a DevOps pipeline, with a few codes analysis tools (most often quality-oriented), then, once the pipeline is considered functional, the security tools are added.

However, it could be worthwhile to consider security tools as an integral part of the CICD pipeline. They could then be integrated into it progressively, according to a prioritised roadmap, as proposed below.

Here are some examples of tools that make up the security stack:

Figure 2 – Examples of security solutions to be integrated into the CICD pipeline (DevSecOps)

According to our feedback from the field, some tools are “easier” to implement and are therefore implemented as a priority.

Static Application Security Testing (SAST) tools

As mentioned earlier, these tools are nearly always already present in the initial pipeline, in their code quality testing format. Here it is a matter of configuring them to go one step further and perform security analysis of static code. This type of tool can be integrated at several points in the pipeline, in a “shift-left” logic, i.e., integrating security as early as possible in the pipeline. It can be positioned directly on the developers’ IDEs (integrated development environment), to provide them with “real-time” feedback on errors that could introduce vulnerabilities. It can also be used at the time of code compilation.

A disadvantage of this type of tool is the high number of false positives. The configuration is scalable and improves over time. However, the governance and processes around the tool need to be thought out in advance: a vulnerability triage team can be a solution, as well as training security champions to spot false positives, with the help of an application security expert (an Application Security Engineer for example).

SCA (Software Composition Analysis) tools

These tools should logically be installed as a priority, as developers make great use of open-source libraries to develop their products. The SCA will check the components of the library, such as licences, dependencies, vulnerabilities, and potential exploits. Many attacks originate from the uncontrolled use of open-source libraries that may contain critical vulnerabilities (such as the Log4Shell exploit).

This tool can be used like SAST, on IDEs or before compiling the code.

DAST tools

DAST tools scan running application builds for security vulnerabilities. They allow the simulation of a malicious attacker’s behaviour through automated pen tests and detect common security vulnerabilities such as OWASP 10. These tools may be less easy to use in authenticated mode (authentication is difficult in automatic mode, it must be done manually before running a test). The tests also take longer than a static scan, and dedicated time must be set aside so as not to disrupt the work of developers or production.

They can be used at the time of testing, but also in production.

It is necessary to think very early on about the governance and processes to be put in place around these tools, in particular by ensuring that developers cannot ignore detected vulnerabilities (by passing them as “false positives”, for example) and to ensure that vulnerabilities are centralised in a single tool (vulnerability management tool, for example), for greater efficiency.

Checking the presence of enabling technical prerequisites

The interest in working in DevSecOps may be limited on non-configurable and non-instantiable software package type applications.

On the infrastructure side, Infrastructure as Code (management and provisioning of infrastructure via code rather than manual processes) allows the use of containers or provisioned VMs that are key to use CICD pipelines more efficiently.

Not forgetting the whole governance and change management layer around the project

Make sure you build, or already have, an operating model that meets your needs (security champions, enabler teams, tooling, processes). Working in “agile at scale” mode is not mandatory for the first iterations (depending on the scope chosen).

Using a “test and learn” method to experiment is a good way to involve the teams very early on, and to get complete and relevant feedback from the field, before starting to deploy at scale. Cybersecurity experiments have been carried out with clients to find out what types of practices or tools to implement.

Some examples:

– Purple teaming to allow developers to see the results of another team’s testing tools and attempt to exploit them (allowing developers to see the reality of an attack and the potential ease of carrying it out),

– Implementing solutions such as Cloudbees, to automate the CICD pipeline processes,

– Training Security Champions to interpret the results of security tools.

These experiments also act as change management, as most stakeholders can be involved early in the transformation programme.

In conclusion

CICD pipelines are a real opportunity for security to become automated. By integrating the right tools into the pipeline, developers are supported in their practice, kept on real security guardrails, facilitating the development of a secure product.

In addition to securing the products, it is also a question of securing the pipeline itself, in the same way as any component with broad access to the information system: it is a question of controlling access to the various tools that make up the pipeline, ensuring that secrets are properly managed, that the underlying servers are hardened, etc.

In a future article, we will detail our views on the pillars of DevSecOps, or how to achieve a sustainable and effective transformation (based on shift-left, guardrails and empowerment of the teams on security!).

Any comments or corrections? Do not hesitate to contact us!

Cet article Security in Agility and DevSecOps: linked fates? est apparu en premier sur RiskInsight.

Historically, the Agile approach is a set of practices used for IT development projects. 

The Manifesto published in 2001 proposes 4 main values to revolutionise the performance of companies:

This emphasis on human interaction between the development team and business teams aims at reducing the time to market of the products developed, as opposed to projects conducted in V-model which, once delivered, may no longer satisfy changing business requirements.

Today, this practice is applied in most companies at all levels. In the latest State of Agile Report, out of more than 4,000 companies surveyed worldwide, 95% declared that they use agile and 65% of them have been practising it for at least 3 years.  In addition to IT, the methodology is also used in marketing, human resources, sales, and finance departments. 52% of the companies surveyed stated that at least half of their company’s departments adopt agile processes and therefore the scalability of such practices should not be ignored.

Beyond a project management method, it is a new philosophy with gamified elements. We no longer speak of meetings but of ceremonies, with new roles appearing such as product owner and scrum master. Using this philosophy, the desire is to create an atmosphere of co-construction and to make maximum use of collective intelligence to improve the company’s performance.

Although the concept of security is present in the manifesto, the integration of such measures into product development is not properly addressed. The method by which security is implemented in V-model projects does not apply to the agile philosophy and thus new ways of implementing security should be identified for it.

What are the trends and challenges of this field?

One of our challenges is to provide our clients with a global view of their problems. Adopting an agile approach requires a change in all levels of the business from security, to quality teams and as such the effect on all levels of the business must be considered.

In terms of organisation, the ISS must reposition itself as a service to the business and thus shift its image from a ‘policeman’ to a support function. The role of Security Champion (a member of the feature team such as a developer) becomes the point of contact for the ISS teams. In doing this a connection can be created with each feature team, thus increasing autonomy over security integration. This is not something that can be achieved overnight, it requires training to highlight cybersecurity issues and share knowledge (particularly the basics of ISS and secure development). In addition to this, a security Guild should be created, bringing together ISS experts, security champions as well as security enthusiasts. This allows members to exchange information on the latest security news, good practices as feedback and lessons learned from the field. This Guild must be set-up in such a way to allow easy communication between members (such as on an internal wiki).

After the security champion receives training from the ISS team, they become the security referent and thus developers can turn to them for questions and advice. Therefore, the role in itself is fairly technical. In adopting an agile approach, the ISS experts will keep their role, but the relationship will change from that of control and audit to support and facilitative. Audits can still be carried out (such as penetration tests) at the request of the feature team or on the initiative of the security experts. Methodological tools must also be available to help the Champions in their tasks and this includes rewriting risks in conversational format. To adapt to the use of User Stories by feature teams, the ISS team could try writing Evil User Stories, which correspond to an action carried out from the point of view of an attacker. For example:

Faced with these risks, there are Security User Stories, proposing remediation solutions for EUS, with ready-to-use acceptance criteria. All this can be integrated into a security baseline (also in backlog format, in a product management tool, such as JIRA for example), proposing a minimum-security base to be integrated into the products.

In addition to organisational support for the teams, technical support must be provided by optimising the continuous integration and deployment chain (CI/CD) with tools aimed at automating security as much as possible, which can be called the Security Stack or Security Pipeline: code review, vulnerability scans, detection of secrets, security of the Infrastructure as Code, etc.).  Particular attention must be paid to its own security, so as not to produce the opposite effect… From a shift-left security perspective, security is integrated into the product by default, right from the start. It therefore adapts its velocity to that of an agile approach and enables a shift from a DevOps logic to that of DevSecOps. 

Another role can be created, that of AppSec Manager. This is part of the ISS team and is an expert in software security as well as an expert in the security stack. Their role is to help the developers to prioritise and remedy the vulnerabilities reported by the Stack. They work in tandem with the Risk Manager/IS expert, who provides them with knowledge of the risks associated with the product, which enables a more detailed analysis of the vulnerabilities to be dealt with as a priority. All this helps to create a culture of security by design.

What do customer expect?

CISO customers expect to be reassured that security in agile mode will not cause them to “lose control” over the proper implementation of security. The model we propose empowers the feature teams, gives them tools, but security retains control by centralising the performance indicators, by having the capacity to carry out random checks/according to predefined criteria, via bug bounty for example or an envelope of pentester days, to be distributed over the various products.

Secondly, as a consultant, I think that clients expect us to share our convictions and very concrete examples of what we have been able to achieve for other clients. To meet this demand, Wavestone’s Cybersecurity and Digital Trust (CDT) practice has created several methodological accelerators based on feedback from the field, ready to be shared and adapted. Being able to carry out the mission in Agile mode was also part of the expectations, favouring co-construction rather than providing fixed and almost finalised deliverables from the first draft. In this gamification perspective, which is very important from an agile approach, we offer original co-construction workshops based on collective intelligence, thanks to our Creadesk asset, which trains consultants and provides them with tools for remote collective work.

Any final advice for our readers?

Implementing a true test & lean approach is crucial. In order to extract the most benefit from using co-constructing tools, we must regularly test and verify them in the field. While anticipating problems is crucial, significant value can be achieved when one we confront the problems as they arise. It allows us to be in direct contact with the business and feature teams, to show them that concrete actions are being implemented. The approach is agile, flexible, and scalable. The accelerators, methodologies and tools proposed evolve during the pilots and become even more relevant for the second wave of pilots, until all the feature teams are integrated.

At the same time, it is important to remember that change management is essential. A real communication plan is needed – building communities of practice/guilds from the beginning of the pilots and identifying early adopters who will be valuable drivers of change within the teams. Agile has a real and rapid impact in everyday life and at all team levels: implementing this change is essential.  

Cet article Agile Security, Emma Barféty interview est apparu en premier sur RiskInsight.

Agile methodologies are becoming more common within organisations and security teams must adapt to be part of the new operational model.

However, when security is scaled up from a few Agile projects supported to hundreds, the scarcity of security expertise becomes a major obstacle. The consequence? Security teams become overloaded and unable to support all the feature teams. Therefore, feature teams are required to resolve issues with new functionalities and release without a security review.

In order to to support this transformation, CISO teams must thoroughly review their operating model to be relevant and enable and effective security environment. What does this mean? They must review their organisation, processes and tools.

How can we enable this transition?

 Define new ISS roles for a transition to a new operating model

The first step is to understand the different roles that security must play in the new operating model to support this move to scale:

• The Security Guild: in order to share knowledge between teams, it is important to build a community of people, who have an interest for security and help them build the best practices. This community of Security Champions, which is described in the following paragraph (and anyone who is interested in security subjects), also has to implement a common framework of references on the methodologies (Security KM, Evil User Stories, Security Baseline, Level 1 control, described in our previous article – in French –).

• The Security Champion: this is the security ambassador within the Feature Teams. He/she is fully part of the team and present in every sprint planning His/her role is to ensure that security is considered at every sprint during the development of User Stories. The Security Champion may be from the developing world and develop skills on security subjects, with help from the Security Guild and the Enabler Squad.

• The Enabler Squad: if we look into Spotify’s model, it is the engine of all Guilds. A group of people from the CISO team who will steer the Security Guild while building methods, processes, products, services and standards for development, which will help Security Champions gain autonomy. When starting the industrialization of the model, they can play the role of a Security Champion, before training them. They also provide security expertise on the most critical perimeters and support the less mature teams.

• The X-Team(“cross team”): If the Enabler Squad’s role is to assist the Feature Teams in the security integration, the X-Team’s is to control the security level and guarantee risk coverage. This team performs targeted technical tests (penetration tests, code review, etc). Obviously, performing a penetration test in every Feature Team and for every sprint is not possible as it is really time consuming. Therefore, tests could be done through sampling and/or randomly (thereby playing the “Chaos Monkey’s” role in the organisation[1]), by focussing on the most sensitive and less mature perimeters. As long as enough security KPIs are received from the Feature Teams, the X-Team can perform controls on all teams, especially those where the security maturity is drifting from the targeted level.

• CISO: his/her role evolves and is now a checkpoint and provides them with the ability to reject a particular change if the appropriate security controls are not in place (E.g. based on the X-Team findings or according to a “security score” at application or infrastructure level, scored by the ISS team). Given that they cannot be present during all Agile discussions, they must rely on the Security Guild to point out where a strategic decision must be taken. However, they could participate in PI planning and other infrequent discussions, to have an overview on all the ongoing projects and decide which one should be supported more closely. Dedicated committees can also be set up, allowing projects to sign up and have subjects arbitrated, with a call to the CISO if final arbitration is required.

As in every change project, the effectiveness of acculturation lies more in practice than in theory. It’s better to start small and initiate a progressive handling of the new operating model by the ISS team. It will then be easier to expand the perimeter to the whole company.

Mobilising security experts to start the transition in 2 or 3 Feature Teams

Integration of security must be carried out continuously. The goal of Feature Teams is to be mature and competent in cybersecurity and to have autonomy regarding risk management. But in the interim period, the presence of security experts in a position support support is crucial in order to ease the integration of security into projects, while Security Champions are embedded in every Feature Team. These security experts must prioritise projects (e.g. critical projects, Feature Teams facing difficulties…) as they will not have the capacity to support every project.

The objective is to start the transition, using security experts from the ISS team to “do” with the teams, learn by doing and use this knowledge to build the first bricks of the security methods required by the Agile team.

It is at that point that the first useful tools and methodologies must be built, used and upgraded:

• The Security Passport: it must be completed at every step of a project’s life (and beyond). It’s completed at the beginning of the project (at the same time as the PI Planning) to identify the project sensitivity, then set up and monitor the appropriate security measures.

• The Security Baseline: this is a set of basic security rules and standards, translated into “Agile language” (e.g. “as a developer I want to implement security measures to prevent attacks”) for easy integration into the backlogs of the Feature Teams and subsequently implementation during sprints. They are represented as Security Stories:

To reach a minimum level of security, projects (critical or not) must at the very least comply with this Security Baseline.

• Training for the Security Champion-to-be
• • Presentation of the job description, roles and responsibilities.
  • Training on evil user stories (EUS), security stories due to the gamification often used in Agile. Security Champions can get familiar with the Agile Card Game built by Wavestone (to learn more, have a look at that article – in French –).
  • Learning how to use the knowledge management (KM) to share information, keep the community alive and know the key personnel.

• Securing team production
• • Controlling development: training about secure development, securing the CI/CD pipeline, setting up control over the code, etc.
  • Defining rules for separation of roles and responsibilities in DevOps: start of production, tests edition, production changeover, etc.

A more complete article will be dedicated to this last part.

What’s next? How do we transform to be able to scale?

This interim period where ISS experts are working in Feature Teams is key for building the different roles, tools and processes.

Once the model is well known by the ISS teams, it is time to deploy this methodology to the entire Agile perimeter.

Communicate

Celebrating successes of the first set of Feature Teams involved in the pilots can trigger adoption by the rest of the teams.

Once the first projects have demonstrated the benefit of the approach and the tools and methods have been developed, it will just be a matter of spreading these best practices throughout the company.

Train

Security Experts could be used as coaches to spread good practices within Feature Teams, which will be trained progressively.

A good solution is to use half of the security experts to share tools and train the teams. That half is known as the Security Enabler Squad.

The other half is then focused on risk mitigation for the critical or less mature areas, supporting them to achieve a good maturity level of the Security Champions of the other Feature Teams.

Communication and animation of the security community must go on around the transformation to support the change of scale.

Control and steer the maturity of the Security Champions

 Finally, once Feature Teams are trained to use the security tools and methods, the ISS team, consisting of security experts can focus their efforts on controlling important releases and steering the Security Guild. As it is a space for information sharing, it has to be up to date, to pace up the maturity level of the entire Guild.

How long does it take to achieve full Agile Security?

Initial feedback shows a 3-year transition from the beginning of the intermediate state, when the security team work closely with a few Feature Teams, to a completely autonomous team of Security Champions. It may seem long, but the transition to Agile is much more than a simple change of methodology. It is a real paradigm shift that requires significant change in ways of working and methods to ensure that change can be sustained in the future

In the next article, we will answer the following questions:

• How to ensure security controls in Agile?
• Beyond projects support, how should the organisation and major ISS processes evolve to operate in the new Agile operating model of the company?

[1] https://netflix.github.io/chaosmonkey/

Cet article How can we structure cybersecurity teams to better integrate security in Agile at scale? est apparu en premier sur RiskInsight.

Cet article Cybersecurity in an agile world est apparu en premier sur RiskInsight.