“Security accreditation is a formal act by which the authority responsible for a system commits its responsibility to risk management.” [1]. It is of course mandatory in some cases[2], but beyond that, it is also a way of sending a strong message to users and top management: security is indeed a major topic for the organization. Agile methodology was at first designed for projects, but it can be a real opportunity for security teams to reduce security risks.

This method disrupted working habits of product teams and ISS teams (Information System Security). The latter have to find a way to go beyond adapting old accreditation method and propose a new relevant solution to still comply with the original goal of the accreditation: “Find a balance between acceptable risk and security costs, then have it formally accepted by a manager/an authority who has the power to do so[3]”.

One solution: provisional accreditation and long-term accreditation

As a famous Agile Security expert from Wavestone once said: “Agile and accreditation, it’s not rocket science”. Without denying the difficulties, explaining it is quite simple. Faced with teams that must deliver faster and provide continuous releases, the risk levels and therefore the security accreditation must be dealt with at the same pace.

What should the accreditation consider?

As always, security accreditation is all about giving thorough information on a project’s security risk level to the Accreditation Authority, for them to decide if it’s acceptable with regard to the organization ISS criteria (e.g. number of EUS still on the backlog, percentage of security baseline rules implemented on a given scope, etc.). Then, they take responsibility for the possible residual risks.

For example, only a few features are available to a few users at the beginning of a project. This small scope will display a lower level of risk (because of a low level of exposure) despite not being fully secured yet. Provisional accreditation (for a few months for example) may be issued to allow experimentation. It will have to be renewed when renewal criteria (defined in advance) are met.

Figure 1 – Product exposure to residual risk
From the ANSSI guide (in French): Digital Agility and Security, October 2018 (link to the guide)

For a project at cruising speed, accessible to its target audience with all the expected features, a firm accreditation (3 years for example) is pronounced. The criteria for renewal, leading to the issuance of a new accreditation, are also defined in advance.

When to renew the accreditation?

The criteria used to know when to renew the accreditation are closely linked to the project, the context, or the scope, but here are some examples to build these criteria. The provisional accreditation is valid until:

• New critical features are added (“critical” depending on the project),
• A new threshold for the number of users has been reached (defined in advance, depending on the associated risks),
• New personal data must be integrated and processed by the project,
• New features related to payments must be implemented,
• A new level of transaction volume is reached,
• And of course when the accreditation deadline is reached.

Long-term accreditation is valid for a longer time because less changes are expected at this stage of the project. That being said, the accreditation will have to be renewed regularly (at least every 3 years) to check on security levels and in a will of continuous improvement.

What evidence should squads bring?

Squads/feature teams should be able to bring different types of evidence/proofs (of the security level) to the Accreditation authority/responsible for the accreditation. The Evil User Stories (EUS) serve as what we used to call risks, where prioritization gives information about their criticality (see our article on how to lead a workshop on risk analysis in Agile). An extract from the backlog can be used as proof that the main EUS have been processed and that residual EUS are known (and accepted by the Accreditation Authority).

The Security Form (or Passport, detailed in this article on Agile transformation – in French -) is also a relevant way to follow-up on security levels of projects.

Code review and vulnerability scan reports can also be used (for squads that have integrated DevSecOps and have the appropriate tools).

If the X-team exists (see our article on the new ISS roles in Agile and the corresponding organization) or if an external audit team was able to perform them, the penetration test reports are also presented.

Any other existing documents can be used to give all necessary information (architecture documents, applicable regulations, etc.).

For provisional accreditation, these documents don’t have to be gathered in a proper “accreditation folder”, which would imply losing time for squads. What is necessary is to ensure they exist and are available to anyone involved in the accreditation process (accreditation authority or their delegate, ISS team, etc.).

Who are the actors in this process?

During product development, the Security Champion (see this article for definition) is in charge of organizing the risk analysis workshops (identification of EUS and associated Security Stories). The ISS team is of course involved in the process, bringing their knowledge to the squads during workshops.

The Product Owner is responsible for the creation and updates of the necessary documentation. They also make sure the ISS team is informed and asked for help when needed.

The accreditation Authority should be a business manager (e.g. the Business Owner) as usual. They must have the capacity to accept residual risks and validate the product security levels. As security should not slow down any Agile processes, the signing of a provisional accreditation may be delegated to the Product Owner, as they are representative of the Business Owner in the squad. The temporary accreditation can thus be signed faster if criteria for validity are met. In some cases, where projects would pose a risk to other businesses or systems, a transversal officer/business owner must be found, to sign for both businesses or systems. If no one is found, or no compromise is achieved, the Chief Information Officer (CIO) will assume responsibility, as it is their role to ensure the operational conditions of the Information System.

As a conclusion, security accreditation remains key when speaking about integration of security into projects, in particular within the Agile framework which changes the product teams’ way of working. The ISS teams must take advantage and (re)join these product teams (through the Security Champion and the security training of the product teams) and thus work together towards the incremental reduction of risk.

More articles to come on Agile Security, stay tuned!

[1] ANSSI guide (in French): Digital Agility and Security, October 2018 (link to the guide)

[2] (French regulations only) For administrations: decree n ° 2010-112 of February 2, 2010, terms of the General Safety Reference System (RGS). For any product dealing with information coming under National Defense secrecy: Interministerial General Instruction 1300. For operators of vital importance: cyber section of the LPM (law n ° 2013-1168 of 18 December 2013 – article 22), to strengthen the security of the critical information systems they operate, carried out as part of an accreditation process.

[3] ANSSI guide (in French): The nine steps of the security accreditation, August 2014 (link to the guide)

Cet article Security accreditation for Agile projects: how to successfully do it ! 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.

The EUS & Security Stories workshop: Who, when, where?

First of all, we can only advise you to involve in this workshop the usual actors of agile ceremonies:

• The Product Owner (PO) as a representative of business needs
• The Agile Coach in his capacity as guarantor of the respect of the method
• The technical referents of the project (architect, developers, testers…)

To bring a cyber security eye, it is important to count on the presence of the Security Champion from the project team. If none is available, a member of the CISO team can replace him or her and will have the Cyber Security “mindset” to guide you and complete the workshop.

Then, one often wonders when these workshops should be conducted… To tell you the truth, there is no rule about this, as it will depend on the security requirements of each release! However, our first piece of advice on this subject is to synchronize their frequency with that of the product backlog review. So, all you need to do is extend the workshops where you work on User Stories by about 50% to devote yourself to this security study with all the right players already present and mobilized.

Finally, where should the workshop be held? Ideally in the continuity of your previous workshop, in a room with a board or a projector allowing you to share a screen and the possibility to annotate the diagrams quite easily (post-its, whiteboard markers…). However, it is also possible to do it online! At Wavestone, we regularly use solutions such as Mural or Stormboard for this purpose. Get your hands on a solution like this and see if it’s playable!

Course of the workshop

First of all, it is often necessary for the Security Champion to lead the way in the first workshops. But the idea is to coordinate with the Agile Coach and work together so that the technical referents can gradually take charge of the methodology and make it their own.

When we train our clients on the subject, we often take a use case, fictitious but concrete and realistic! WaveCare is a medical application with many innovative features such as :

• Consulting the availability of practitioners near you
• Real-time transmission of your health data thanks to your connected watch
• Realization of remote consultations in Visio (Skype conference)
• Receipt of the order after the appointment in dematerialized format

For this demonstration, let’s focus on two components in particular: the descriptive schema of the functionality allowing a patient to search and reserve a slot in his doctor’s diary and the general architecture schema.

–

Step 1: Building risk scenarios

The first questions to ask yourself are “Where am I vulnerable? “How and where can I be attacked? ». The Security Champion and the developers will have to try to answer these questions! Here, a mix of application security and development knowledge will help identify exploitable vulnerabilities. We can already see an interesting aspect of the approach: it works on both the infrastructure and application aspects!

One piece of advice we can already give you: encourage developers to take ownership of the approach and to be proactive, it’s an excellent lever for raising security awareness! For the security referent, his or her role should mainly be to moderate the exchange and challenge the developers’ proposals. This position can also help you identify potential Security Champions, so don’t skimp on keeping it!

So let’s apply what we have just said to our example, in the figures below.

–

And here we are, we can finally identify quite quickly some points of attention! If we want to detail the “Code Injection” scenario of the global architecture schema, we can for example rephrase it like this: “As an attacker, I want to inject malicious code into the application’s insecure input fields“. You see, this ending is very close to that of a classic User Story, but the angle is indeed that of the attacker!

Step 2: Evaluate the business impacts of the scenarios

The second phase will be key to ensure that the team’s energy is used in the right place. This is where the Product Owner comes in! Together with the Security Champion, he will lead the debate to qualify the impact that each vulnerability can have.

Why is the PO decisive at this stage? Quite simply because he is the one who knows best both the business reality of the project and the importance of each feature. He will need to be well oriented, with questions such as “Is it serious if the data sent by the patient at this point is stolen? “What is the seriousness of the theft of the user’s account? etc.”, etc.

Next, you will need to give a score to prioritize each scenario. You then have two choices. The first is to use a classic cyber risk view, with a level of probability and impact. Personally, I recommend you rather use a point system or the Fibonacci suite, as for a classic US, it’s frankly simpler and instinctive!

Step 3: Define and prioritize Security Stories

The next step will be to build Security Stories based on each of the scenarios.

Now it’s the turn of the Security Champion and the developers to get back on stage! To continue on the previous example, here is a Security Story we can write: “As a developer, I want to make sure that code injection attacks are avoided“. Concretely, it will make us add to the product backlog actions such as escaping special characters, filtering user input or using the HttpOnly attribute to prevent the theft of session cookies.

Obviously, for each of the Security Stories, it may turn out that the security measures to be implemented are already in place. Otherwise, the Security Champion will prioritize the technical security measures, with regard to covering the risks involved, on a company-wide scale and not only on a business level. For security measures that are not purely technical, it is up to the Product Owner to prioritize them, with regard to business risks and the team’s resources.

And there you have it, you can now start your sprint more serenely!

And to help you, prepare and adapt the material to your context!

To make the workshops simpler and more fun, we have designed a generic deck of cards, consisting of cards with two sides each:

• Front side: the Evil User Stories, they describe in a very pedagogical way what can go wrong, using which vulnerabilities (ex: privilege escalation on a Web server, brute force attack, XSS, …).
• Verso: the Security Stories describe the security measures to be implemented to ensure that the Evil User Story does not occur (e.g. use of a robust AES 256/512 encryption algorithm, …).

These cards are really useful to get you started! For best results, you can even choose to adapt them to your business context. Use your security policies and integrate your requirements on encryption, password complexity, etc. Depending on the security needs of the project, you can also copy requirements related to certifications (HDS) or guidelines (LPM, NIS).

You can find the card game available for free here and don’t hesitate to give us your feedback so that we can continue to improve it!

Also, a workshop that runs smoothly is always more productive! Don’t forget to prepare the materials beforehand: architecture diagrams of the project (data flow and classification), listing and details of the next User Stories to be developed…

Cet article How to conduct an Agile Cyber Security workshop? est apparu en premier sur RiskInsight.

L’atelier EUS & Security Stories : Qui, quand, où ?

Tout d’abord, nous ne pouvons que vous conseiller d’impliquer dans cet atelier les habituels acteurs des cérémonies agiles :

• Le Product Owner (PO) en sa qualité de représentant des besoins métiers
• Le Coach Agile en sa qualité de garant du respect de la méthode
• Les référents techniques du projet (architecte, développeurs, testeurs…)

Pour apporter un œil cybersécurité, il est important de compter sur la présence du Security Champion de l’équipe projet. Si aucun n’est disponible, un membre de l’équipe du RSSI peut le remplacer et aura « l’état d’esprit » Cybersécurité pour vous aiguiller et mener l’atelier à bien.

Ensuite, on se demande souvent à quel moment ces ateliers doivent être conduits… Pour tout vous avouer, il n’y a pas de règle à ce sujet, car cela dépendra des exigences sécurité de chaque release ! Toutefois, notre premier conseil à ce sujet est de synchroniser leur fréquence avec celle de revue du backlog produit. Ainsi, il vous suffit de prolonger les ateliers où vous travaillez sur les User Stories d’environ 50% pour vous consacrer à cette étude sécurité avec déjà tous les bons acteurs présents et mobilisés.

Enfin, où réaliser l’atelier ? Idéalement dans la continuité de votre atelier précédent, dans une salle avec un tableau ou un projecteur permettant de partager un écran et la possibilité d’annoter les schémas assez facilement (post-its, feutres pour tableau blanc…). Néanmoins, il est également tout à fait envisageable de le faire en ligne ! Chez Wavestone, nous utilisons régulièrement des solutions comme Mural ou Stormboard à cet usage. Faites-vous la main sur une solution de ce genre et vous verrez si c’est jouable !

Déroulement de l’atelier

Tout d’abord, il est souvent nécessaire que le Security Champion mène la barque dans les premiers ateliers. Mais l’idée est de se coordonner avec le Coach Agile et travailler de concert pour que les référents techniques puissent petit à petit prendre en main la méthodologie et se l’approprier.

Quand nous formons nos clients sur le sujet, nous prenons souvent un cas d’usage, fictif mais concret et réaliste ! WaveCare est une application médicale avec de nombreuses fonctionnalités innovantes telles que :

• Consultation des disponibilités de praticiens près de chez vous
• Transmission en temps réel de vos données de santé grâce à votre montre connectée
• Réalisation de consultations à distance en Visio (conférence Skype)
• Réception de l’ordonnance après le RDV en format dématérialisé

Pour cette démonstration, intéressons-nous à deux composants en particulier : le schéma descriptif de la fonctionnalité permettant à un patient de rechercher et réserver un créneau dans l’agenda de son médecin et le schéma d’architecture générale.

–

Etape 1 : Construire les scénarios de risque

Les premières questions à se poser sont « Où-suis-je vulnérable ? », « Comment et par où peut-on m’attaquer ? ». Le référent sécurité (Security Champion) et les développeurs vont devoir essayer de répondre à ces questions ! Ici, c’est donc un mélange de connaissances en sécurité applicative et en développement qui va permettre d’identifier les vulnérabilités exploitables. Nous pouvons déjà noter un aspect intéressant de l’approche : elle fonctionne aussi bien sur l’aspect infrastructure qu’applicatif !

Un conseil que nous pouvons déjà vous donner : encouragez les développeurs à s’approprier l’approche et à être force de proposition, c’est un excellent levier pour les sensibiliser à la sécurité ! Pour le référent sécurité, son rôle doit majoritairement être de modérer l’échange et challenger les propositions des développeurs. Cette posture peut en plus vous permettre d’identifier des potentiels Security Champions, ne lésinez pas à la conserver !

Appliquons donc ce que nous venons de nous dire à notre exemple, dans les figures ci-dessous.

–

Et voilà, on peut finalement identifier assez rapidement quelques points d’attention ! Si nous voulons détailler le scénario « Injection de code » du schéma d’architecture globale, nous pouvons par exemple le reformuler comme cela : « En tant qu’attaquant, je veux injecter du code malveillant dans les champs de saisie non sécurisés de l’application ». Vous voyez, cette terminaison est très proche de celle d’une User Story classique, mais l’angle est bien celui de l’attaquant !

Etape 2 : Evaluer les impacts métiers des scénarios

La seconde phase va être clef pour s’assurer d’utiliser l’énergie de l’équipe au bon endroit. C’est à ce moment que le Product Owner entre en jeu ! Avec le Security Champion, il va mener les débats pour qualifier l’impact que peut avoir chaque vulnérabilité.

Pourquoi le PO est-il décisif sur cette étape ? Toute simplement car c’est lui qui connaît le mieux à la fois la réalité métier du projet et l’importance de chaque fonctionnalité. Il s’agira de bien l’orienter, avec des questions comme « Est-ce grave si les données envoyées à ce moment par le patient sont volées ? », « Quelle est la gravité du vol du compte de l’utilisateur ? », etc.

Ensuite, il vous faudra donner une note pour prioriser chaque scénario. Deux choix s’offrent alors à vous. Le premier est d’utiliser une vue risque cyber classique, avec un niveau de probabilité et d’impact. Personnellement, je vous recommande plutôt d’utiliser un système de point ou la suite de Fibonacci, comme pour une US classique, c’est franchement plus simple et instinctif !

Etape 3 : Définir et prioriser les Security Stories

La prochaine étape consistera à construire des Security Stories basées sur chacun des scénarios.

Au tour du Security Champion et des développeurs de remonter sur scène ! Pour continuer sur l’exemple précédent, voici une Security Story que nous pouvons rédiger : « En tant que développeur, je veux m’assurer que les attaques par injection de code sont évitées ». Concrètement, elle nous fera ajouter au backlog du produit des actions comme l’échappement des caractères spéciaux, le filtrage des entrées utilisateurs ou encore l’usage de l’attribut HttpOnly pour éviter le vol des cookies de session.

Evidemment, pour chacune des Security Stories, il peut s’avérer que les mesures de sécurité à mettre en œuvre le sont déjà. Dans le cas contraire, le Security Champion se charge de prioriser les mesures de sécurité techniques, au regard de la couverture des risques induits, à l’échelle de l’entreprise et pas uniquement du métier. Pour les mesures de sécurité n’étant pas uniquement techniques, c’est au Product Owner de les prioriser, au regard des risques business et des moyens de l’équipe.

Et voilà, vous pouvez maintenant démarrer votre sprint plus sereinement !

Et pour vous aider, préparez et adaptez le matériel à votre contexte !

Pour rendre les ateliers plus simples et ludiques, nous avons conçus un jeu de cartes génériques, constitué de cartes ayant chacune deux faces :

• Recto : les Evil User Stories, elles décrivent de façon très pédagogique ce qui peut mal se passer, en utilisant quelles vulnérabilités (ex : élévation de privilèges sur un serveur Web, attaque par force brute, XSS, …)
• Verso : les Security Stories décrivent les mesures de sécurité à implémenter pour s’assurer que l’Evil User Story ne se produit pas (ex : utilisation d’un algorithme de chiffrement robuste AES 256/512, …).

Ces cartes sont vraiment utiles pour vous lancer ! Pour de meilleurs résultats, vous pouvez même choisir de les adapter à votre contexte d’entreprise. Utilisez vos politiques de sécurité et intégrez vos exigences sur le chiffrement, la complexité des mots de passe, etc. Suivant les besoins de sécurité du projet, vous pouvez aussi calquer de exigences liées à des certifications (HDS) ou des directives (LPM, NIS).

Retrouvez le jeu de carte disponible gratuitement ici (et en anglais ici)et n’hésitez pas nous faire vos retours pour que nous continuions à l’améliorer !

Également, un atelier qui se déroule avec fluidité est toujours plus productif ! N’oubliez pas de préparer les supports en amont : schémas d’architecture du projet (flux et classification des données), listing et détail des prochaines User Stories à développer…

Cet article Comment conduire un atelier Cybersécurité agile ? est apparu en premier sur RiskInsight.

A travers cette série d’articles, nous présenterons nos convictions pour permettre aux équipes SSI de mener cette transformation en profondeur.

La transformation numérique implique l’usage d’une nouvelle méthode de delivery IT

A l’heure des transformations numériques, les organisations doivent faire face à 3 principaux défis :

• Innover plus rapidement pour faire face à la compétition.
• S’adapter rapidement au changement avec plus de flexibilité afin de mieux gérer l’incertitude et la complexité.
• Mieux combiner les compétences IT et métier pour maximiser la valeur produit.

Dans ce contexte, les méthodes agiles représentent par leur approche de développement itératif, incrémental et adaptatif, la promesse d’une organisation plus fluide en permettant de :

• Réduire les délais entre l’expression de besoin métier et l’ouverture du service idoine (« Time to Value ») : les fonctionnalités développées à chaque étape (sprint) sont opérationnelles et potentiellement utilisables.
• Maitriser les risques et le niveau de qualité: l’approche itérative et incrémentale de l’agile permet de récolter un maximum d’apprentissage (« test and learn ») en un minimum d’effort.
• Augmenter la productivité et la collaboration entre les différentes équipes en donnant du sens à leur travail : en cassant les silos organisationnels, les interactions entre l’IT et les métiers s’intensifient et améliorent l’engagement autour du projet et les boucles d’amélioration continue.
• S’adapter rapidement aux changements: avec la possibilité de changer à tout moment en cas d’évolution des besoins ou de mauvais feedbacks.

Parce que les méthodes agiles bouleversent les façons de prendre des décisions et l’organisation, de nouvelles questions se posent autour de l’articulation de la sécurité dans des organisations agiles :

• Comment réinventer l’intégration de la sécurité dans les projets pour s’adapter à une livraison itérative ?
• Comment soutenir le passage à l’échelle ? Comment structurer les équipes de sécurité pour assurer la sécurité dans l’agile à l’échelle ?
• Au-delà du support sur les projets, comment l’organisation et les processus majeurs SSI évoluent-ils pour fonctionner dans le nouveau modèle opérationnel agile de l’entreprise ?

L’adoption des méthodes agiles impose une refonte du processus d’intégration de la sécurité dans les projets

L’adoption des méthodes agiles représente une véritable rupture dans l’organisation du travail. Le cycle itératif de développement et la fréquence de livraison exigent que toutes les équipes qui gravitent autour du produit soient alignées et impose donc au RSSI de trouver l’articulation idéale entre agilité et sécurité.

Dans les méthodes de gestion de projets traditionnelles, la sécurité est implémentée de manière monolithique à travers 3 piliers :

• Evaluation des risques : évaluation des besoins sécurité et du niveau d’accompagnement SSI consenti pour gérer les risques identifiés.
• Accompagnement : accompagnement des équipes de développement et d’infrastructure dans la conception et l’implémentation des mesures de sécurité.
• Contrôle : réalisation de recette sécurité pour valider la résorption des risques de sécurité et valider la mise en production.

L’intégration de la sécurité dans les processus agiles doit pouvoir s’appuyer sur ces 3 piliers mais il est nécessaire que les équipes SSI revoient leur approche pour s’adapter aux nouvelles méthodes de delivery.

Vous trouverez dans cet article, 4 facteurs clés de succès pour réussir à transposer le processus d’ISP dans une démarche agile.

1. Evaluer le niveau d’accompagnement SSI tout au long du cycle de développement agile

L’appréciation de la sensibilité d’un projet est une première étape incontournable pour prioriser et optimiser les efforts des équipes SSI. Dans une démarche agile, cette évaluation ne doit plus uniquement être réalisée en amont du projet, mais bien tout au long du cycle de développement. Chaque produit doit donc posséder un passeport sécurité, qui sera mis à jour sur une base régulière (ex : tous les 3-6 mois) et lors de développement de fonctionnalités induisant de nouveaux besoins en sécurité.

Le niveau d’accompagnement des équipes SSI sera déterminé en tenant compte de la sensibilité SSI des fonctionnalités développées lors des prochains sprints et du niveau de maturité de la Squad en matière de cybersécurité.

2. Adopter une approche Security by Design

Pour faciliter l’approche Security by Design, les exigences SSI devront être intégrées le plus tôt possible dans la conception du produit.

Pour y parvenir, les équipes SSI vont devoir traduire les mesures de sécurité (référencées dans des politiques et des standards SSI souvent méconnus des équipes de développement) en « security baseline », c’est à dire en un socle de bonnes pratiques applicables de façon systématique et conférant un niveau de protection minimum.

Cela se traduit par une liste de « security user stories », facilement manipulable par les développeurs, qui sera intégrée dans tous les backlogs produit.

3. Traduire les scénarios de risques en Evil User Stories

De la même façon que le Product Owner rédige des User Stories pour décrire de façon conversationnelle une attente exprimée par un utilisateur, les équipes sécurité vont devoir s’adapter aux méthodes agiles en exprimant les risques de façon conversationnelle à travers des Evil User Stories (EUS).

Les Evil User Stories permettent à la sécurité d’exprimer les intentions d’un utilisateur malveillant.

Une Evil User Story décrit la réalisation d’un scénario de risque à travers l’identification d’une source de risque (attaquant externe / collaborateur malveillant), exploitant une vulnérabilité, occasionnant un impact sur la valeur métier.

Pour chaque EUS, des mesures de sécurité (Security User Stories) permettant de mitiger les risques sont identifiées et intégrées au backlog.

Les Security User Stories peuvent être définies à plusieurs étapes du cycle :

• Lors de l’évaluation initiale des risques au lancement du produit.
• Au fil des itérations : dès lors qu’une user story métier induisant des risques SSI est identifiée.
• Lors des phases de contrôle : dès qu’une vulnérabilité est détectée.

Par rapport à une analyse des risques en cycle en V, les Evil User Stories apportent des avantages clés en termes de sécurité :

• Les risques sont facilement compréhensibles, car ils sont énoncés de manière conversationnelle : aujourd’hui lorsqu’on réalise une analyse de risques, les risques que l’on formalise ne vont pas forcément parler à un métier ou à un développeur. De cette façon, les risques sont compréhensibles par tous les acteurs du projet et sont intégrés dans leur quotidien.
• Les risques sont régulièrement mis à jour chaque fois que le produit évolue : la prise en compte des enjeux sécurité doit être à la fois continue et pragmatique et permettre ainsi une démarche de réduction incrémentale du risque. Les Security User Stories sont priorisées en fonction du risque réel et le risque résiduel reste acceptable tant que le produit est exposé à une poignée d’utilisateurs.
• Le processus de remédiation est facilement contrôlable en examinant le backlog : la liste des Security User Stories est embarquée dans le backlog et tracée dans un outil (ex : Jira). C’est un vrai gain par rapport aux méthodes traditionnelles qui ne permettaient pas toujours de suivre la bonne application des mesures de sécurité.

4. Intégrer la sécurité dans les critères d’acceptation des User Stories

Dans un monde idéal, où la sécurité serait systématiquement embarquée, les équipes sécurité n’auraient pas forcément besoin d’intégrer des Security User Stories au backlog produit.

En effet, dans les méthodes agiles, des critères d’acceptation accompagnent chaque user story. Ils représentent un ensemble de conditions (utilisabilité, performance, etc…) que la story doit satisfaire pour être considérée comme complète et terminée. Ils sont rédigés par le Product Owner, en collaboration avec l’équipe de développement.

Ainsi l’équipe sécurité pourrait profiter de ces conditions de satisfaction pour ajouter la liste des mesures de sécurité à intégrer pour assurer la sécurité de chaque fonctionnalité développée.

Dans la réalité, ce n’est jamais réalisé de cette façon (trop contraignant pour la Squad), d’où la nécessité de rédiger et intégrer des Security User Story au backlog produit.

5. Fournir des outils ludiques pour favoriser la prise en compte des enjeux SSI

Parce que les membres au sein des Squad qui vont devoir identifier les Evil User Stories, n’ont pas forcément toutes les compétences pour le faire, nous avons développé un jeu de cartes qui permet de rendre l’exercice d’analyse de risques plus concret et ludique.

Le jeu est composé de cartes, chacune ayant 2 faces :

• Recto : les Evil User Stories décrivent de façon très pédagogique ce qui peut mal se passer, en utilisant quelles vulnérabilités (ex : élévation de privilèges sur un serveur Web, attaque par force brute, XSS, …)
• Verso : les Security User Stories décrivent les mesures de sécurité à implémenter pour s’assurer que l’Evil User Story ne se produise pas (ex : utilisation d’un algorithme de chiffrement robuste AES 256/512, …).

Comment jouer :

• Il faut rassembler à minima les membres de la Squad ayant une connaissance fonctionnelle de la solution (Product Owner) et une connaissance technique et des risques (référents sécurité, développeurs, architectes).
• Les architectes dessinent l’architecture applicative sur une grande affiche A3 sur une table en faisant apparaitre les flux de données et la classification des données et le Product Owner liste les prochaines User Stories qui devront être développées.
• Le référent sécurité (Security Champion) et les développeurs répartissent les vulnérabilités exploitables sur le schéma d’architecture.
• Le Product Owner et le Security Champion qualifient l’impact que peut avoir chaque vulnérabilité.
• Le Security Champion et les développeurs vérifient si les mesures de sécurité permettant de contrer les vulnérabilités identifiées sont déjà implémentées.
• Si des mesures de sécurité ne sont pas encore en production : Le Security Champion priorise les mesures techniques à implémenter permettant de couvrir les risques induits (risque pour l’entreprise, pas seulement au niveau business).
• Le Product Owner priorise les autres mesures de sécurité au regard des risques business / et des moyens de l’équipe.

Ce type de jeu permet de mobiliser l’ensemble des parties prenantes dans l’analyse des risques et d’identifier les mesures de sécurité à injecter dans le backlog.

A travers cet article, nous avons identifié 4 premiers leviers pour intégrer la cybersécurité dans une démarche agile :

1. Le Passeport Sécurité pour évaluer le niveau d’accompagnement SSI tout au long du cycle de développement agile
2. La traduction opérationnelle de la Security Baseline pour assurer un niveau de protection minimum
3. Les Evil User Stories pour exprimer de façon simple et compréhensible les scénarios de risques
4. Des outils ludiques pour favoriser la prise en compte des enjeux SSI

Dans les prochains articles, nous répondrons aux questions suivantes :

• Comment soutenir le passage à l’échelle ? Comment réorganiser l’équipe SSI ?
• Comment assurer un bon niveau de contrôle sécurité ?
• Au-delà du support sur les projets, comment l’organisation et les processus majeurs SSI doivent-ils évoluer pour fonctionner dans le nouveau modèle opérationnel agile de l’entreprise ?

Cet article Transformations agiles des organisations: vers un changement structurel d’approche pour la cybersécurité est apparu en premier sur RiskInsight.

1)     Analyse des opérations

L’analyse dynamique permet la surveillance de nombreuses informations : les registres, le système de fichiers et les processus. Cette étape est au début assez fastidieuse étant donné que de nombreuses informations sont accessibles. Il existe différents outils permettant d’accéder à ces informations. ProcessMonitor est l’un de ces outils qui a l’avantage de permettre à l’analyste de filtrer ses recherches sur un exécutable, ce qui est très pratique pour l’analyse de malwares.

Figure 1 : Résultat d’une analyse de ProcessMonitor sur un malware appelé mm32.exe

Figure 2 : Résultat de Process Explorer sur un exécutable

Dans ce résultat, le premier constat est la création d’un mécanisme de persistance HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run par le programme ckr.exe, le deuxième est la modification de la valeur de la seed pour le générateur de nombre aléatoire, ce qui représente un bruit habituel.

2)     Analyse réseau

Figure 4 : Interception des requêtes DNS et simulation des réponses par ApateDNS en utilisant l’IP 192.168.120.1

Figure 5 : Résultat renvoyé par Netcat lors de l’exécution de RShell en redirigeant les requêtes vers l’hôte grâce à ApateDNS

Figure 6 : Capture d’écran d’une analyse Wireshark

Figure 7 : Fonctionnalité Follow TCP Stream de Wireshark

3)     Analyse via débogueur

• Les software breakpoints : ces points d’arrêt sont utilisés pour faire en sorte que le programme s’arrête lorsque l’instruction sur laquelle ils sont placés est appelée. Pour réaliser cela, le débogueur remplace le premier octet de l’instruction par 0xCC, l’instruction pour INT3.

Cet article Reverse Engineering – focus sur l’analyse dynamique de malware est apparu en premier sur RiskInsight.