One fundamental theme won’t change: the threat – the starting point for all thinking about cybersecurity. In our view, unsurprisingly, ransomware will remain the major threat facing businesses. Since the end of 2019, and the exploits of Maze, Sodinokibi, and, more recently Egregor, these destructive attacks have been paired with massive data exfiltration – adding a new dimension to criminal blackmail operations. All types of organizations are affected: from local authorities, through SMEs, to large international groups – wherever they are in the world.

In addition, as we recently discussed in Le Monde, cybercriminal operations have become highly professionalized, ensuring the perpetrators reap a return on their considerable investments. These investments will enable them to mount increasingly deep, and technically sophisticated, attacks in the future – attacks that will have no qualms about targeting activities that are core to business functions (such as industrial networks, payment systems, etc.). In 2021, the stakes in the tug of war over the payment of ransoms are likely to be raised – with a determined effort by criminal groups to achieve higher profile attacks. We saw some early signs this year with the use of sophisticated procedures: from an attack being announced via Facebook advertisements, through direct negotiation with patients in healthcare-sector attacks, to the printing of ransom demands via in-store cash registers… There will be a need to anticipate such situations to the maximum extent possible, either by simulating them in crisis exercises or by tailoring specific, well-thought-out responses in advance.

In addition to the many-headed beast of ransomware, our teams out in the field anticipate strong growth in two other threat areas in 2021. First, indirect attacks, using third-party services: cybercriminals are heavily focused on circumventing the security arrangements of major players by exploiting vulnerabilities in their less-protected partners or targeting their IT service providers. In addition, attacks that target cloud-based systems are expected to accelerate and manifest new types of compromise. Exploiting vulnerabilities in identity and access management (IAM), in particular via supplier APIs to compromise ever more critical areas of business, will be one of the hallmarks of incidents in 2021. Today, this area represents a real challenge for IT teams, who are still much too unfamiliar with the fast-developing particularities of these platforms.

Faced with such a range of threats, CISOs will need to be both agile and robust, especially in their mastery of security fundamentals (in particular, the Active Directory, the application of patches, and multi-factor authentication) and in solidly demonstrating their cyber-resilience capabilities (with ever-more demanding commitments in terms of reconstruction times and the ability of business functions to be resilient without IT capacity).

In parallel, there are several areas that will be central to developments in IT departments, and CISOs can turn them into opportunities to improve cybersecurity within their organizations. In particular, we have in mind “Digital Workplace” projects – and the work to optimize available security measures, which will have to be done against the current backdrop of constrained budgets. Previous years’ investments in cybersecurity have often added new functionalities that are little known or used, especially when it comes to the cloud. Looking to these may offer a way to improve cybersecurity at lower cost.

From a regulatory perspective, 2021 will see another increase in issues linked to cyber borders or even cyber-protectionism. It will mean considering demanding isolation and protection requirements, and also the issue of the interconnection of new and little-known systems (for example, Alibaba in China, Yandex in Russia, etc.) with organizational networks.

In terms of technological developments to keep in mind, we have identified three trends: Zero-trust, Confidential Computing, and Quantum Computing. We discuss these in more detail below and set out the minimum level of monitoring that you should plan for.

Threats are becoming more complex and resources increasingly limited… CISOs will need to demonstrate their agility in 2021, by addressing a range of issues while still maintaining a clear strategic direction: they’ll need to be able to protect their organizations against cyber criminals while supporting, or even developing, new digital uses.

Cet article CISO, between post-COVID world and persistent threats, what are the priorities for 2021? 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.

But these projects are not only the work of systems security managers. These projects also come from executive committees who seek a 360 view of the security of their institution to better evaluate potential risk. So, what are key success factors that we have seen in the field?

Step 1: Know the purpose and expectations of your evaluation

Evaluations can be entirely different levels of depth. From a high-level interview with the Chief Security officer to an in-depth assessment of the security mechanisms and processes of all the subsidiaries of a multinational group, everyone can choose their areas of focus and advance step-by-step.

Our first advice is to keep in mind the objectives of your evaluation. This will allow you to orient yourself toward the right security benchmarks and ultimately define the depth of the evaluation. Do you only want to measure the security maturity of your subsidiary’s information systems or also its efficiency? Perfectly documented security processes and an ISO 27001 certification can unfortunately hide problems on the ground that can expose you to vulnerabilities. It can be judicious to combine a technical test (pentest, red team, etc.) to the evaluation in order to avoid situations that seem fine on the surface but hide underlying issues.

Step 2: Find and mobilize the right people at the right level, easy to say but harder to do…

The next difficulty that you can encounter in your assessment is to succeed at meeting the right people. From experience, we advise you to confirm your list of the necessary collaborators as soon as possible.

Logically, this list will certainly depend on the granularity of the analysis but also on the organization of the business. For example, the necessary people will differ if the security staff are at the group level and function as a service center or if they are merged into each entity and service. Consequently, if you want to have a high-level estimate first, it could suffice to only have a half day exchange with the Chief Security Officer, who generally has a sufficient and global vision of the subject.

The second stage of analysis can be performed in gathering information from all actors involved in cybersecurity at the group level. In this group, it can be interesting to meet a large group of people involved in information systems and the cloud.

Finally, when the assessment must be thorough and exhaustive, it becomes necessary to widen the list of collaborators to all of the concerned entities. Obviously, you should expect a larger workload, so do not skimp on preparation and tools to help you in your work. It can also be the right moment to think about your presentation format: face-to-face, distance, strategic, operational, etc.

Step 3: Equipment, finding the right balance between too much and not enough

Choosing the right tools is one of the main assessment challenges that you will face. The more complete the assessment, the more it will require tools that ensure simplification and understanding of the whole project. Indeed, for large evaluations, the consolidation and restitution of results are two of the great challenges that you will encounter. In particular, commonly used tools don’t take into account the organizational complexity of large groups or the effectiveness of allocated resources. It is for these reasons that, from our side, we have chosen to develop a specific tool.

A good tool also allows you to position yourself against your competitors and understand your exposure to current attack trends and points where your COMEX is particularly sensitive, ensuring you can legitimize the assessment.

So it begins! It’s time to get your hands dirty and start the work of collecting information! There is a classic phrase that applies to these situations: entirely feasible from a distance. Be aware and transparent about the limits of the exercise: those questioned will sometimes have the impression that the assessment is too theoretical and this is normal, according to their objectives. During this phase, it will also be necessary to be able to juggle between the various unknowns because it is not uncommon to have people who are ultimately absent for long periods of time, added parameters, changes in methodology. Make it a point of honor to remain agile.

Step 4: Reforming at the right level to act, everything is a question of the point of view

A good habit to keep is to honestly adapt each reform to each person. From the managerial summaries where we talk about trends without much detail to presentations for technical teams that are highly detailed, adapting the discourse to the necessary format is important to convey the right messages to the right people.

Usually, we start the reforms in terms of the organization’s budget and workforce dedicated to cybersecurity. These very concrete points allow you to attract attention and be able to then analyze the situation from four different angles:
· Compliance with different global benchmarks (ISO/NIST)
· Assessment of the level of maturity of different entities compared to others in the same sector or market
· Quantification of the effort reach the market level and/or the required level according to cybersecurity benchmarks
· Evaluation of the level of robustness of the organization against the last known cyberattacks

With senior management, the restitution is often going to focus on organizational and governance matters. However, there can always be surprises. In cases where businesses have already been hit by serious cyber attacks, we have had surprisingly precise and technical questions from executive committees. For example, we have been asked for details on encryption algorithms and “How secure is my active directory?”

Get started

As mentioned earlier, the maturity assessment is an effective means for measuring the effectiveness and progress of your cybersecurity roadmap. Consequently, even if you don’t want to immediately begin an assessment involving all security systems and dozens of teams at your business, we advise you to familiarize yourself with the approach and its usefulness in starting out with more modest goals.

At Wavestone, with years of experience and expertise, we have developed the W-Cyber-Benchmark, a multi-use tool that has been implemented by dozens of clients. We know that just writing about it isn’t enough, so don’t hesitate to contact us to discuss further!

Cet article How to effectively evaluate your cybersecurity 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.