Ecoute attentive ce jour du dernier podcast hebdomadaire de « No Limit Secu » consacré au(x) Cyber Range(s)

Parmi les invités on retrouve :

• Guillaume Prigent (Président et Co-fondateur Diateam / BlueCyForce);
• Olivier Franchi (Owner, Sysdream);
• Arnaud Kopp (Président de CyberTest System).

Diateam

Sysdream

Cyber Test System

Ces trois spécialistes sont interrogés par les animateurs habituels Hervé Schauer, Nicolas Ruff et Johan Uloa.

Définition officielle du cyber range ?

3′ : Juste une infrastructure ?

GP : c’est pas nouveau … Très variable selon les moyens que l’on veut y mettre : copie d’un système réel dans lequel on vient s’entraîner. Champ de tir numérique ?

Histoire : 2008, idée de faire tests d’un système complet (National Cyber Range de la DARPA) au delà du simple tests « unitaires » d’équipements.

7′ : HS : les Arc-en-Ciel Team ?

AK : Au départ seulement attaque-défense entre 2 équipes (Red vs Blue) puis d’autres acteurs ont rejoint l’environnement.

Read Team : équipe d’attaquants. Soit ils ont leurs propres outils soient ils activent des générations automatiques d’attaques et de trafic.

Greeen Team : simulation de trafic légitime pour faire fonctionner le système

Yellow Team : l’équipe qui participe involontairement au scénario de l’attaquant. Ils prennent part à une activité malicieuse sans forcément s’en rendre compte.

Blue Team : elle assure la supervision, ce n’est pas seulement la défense (SOC, NOC, Réponse à incident). Elle assure le bon fonctionnement de la Blue Team => les experts ne sont pas forcément exactement en phase sur le sujet.

White Team : ils ont le contrôle de l’exercice global

Purple Team : relais d’info, legal, communication.

OF : bonne analogie entre cyber range et simulateur de vol.

17′ : Formation avant entraînement ?

OF : Le cyber range est un prolongement de la formation. La formation ce sont de petits exercices courts avant de passer en environnement complexe qui ressemble à son environnement réel.

NR : s’inquiète de la possibilité de reproduire, ne serait-ce qu’en termes de licences (ou dongles) dans l’environnement réel

GP : la formation c’est du video training +  slide + labo exercice sur sa VM. Petit rappel de Confucius et du constructivisme par GP : Tout ce qu’on voit on oublie, tout ce qu’on fait, on retient ! Puis GP nous fait une petite analogie avec les Centre d’Entrainement en Zone UrBaine (CENZUB – Centre de l’armée de terre à Sissone). A ne pas confondre avec l’eunuque (SansZob) (Note du rédacteur pour vérifier si tout le mode suit). Entraînement en environnement urbain des forces.

Un cyber range c’est un environnement qui permet d’opposer des défenseurs et des opposants. Il faut qu’il y ait de la vie dans le système. Les partenaires technologiques de BlueCyForce permettent l’

NR : Concernant toujours la représentativité du système, comment fait-on pour simuler Virus Total ?

GP propose un faux Virus Total, Twitter (basé sur Mastodont), AFP … et on regénère la plateforme à chaque séquence. Malgré tout, on grille ses touches et ses backdoors à chaque jeu.

NR : Pas possible de faire du passive DNS sur 3 ans ou rapports publiques et indicateurs de compromission => on travaille en vase clos.

AK : mise en place d’un système de QuarksLab et applications de vie spécifiques

25′ NR : Quid de la qualité de scenario, qui les écrit ? (le client qui ne connaît pas ses risques ou le fournisseur qui ne connaît pas le métier)?

GP nous perd un peu… mais ajoute que c’est un peu des deux et qu’il existe à la fois une Blue Team Teachnique et une Blue Team management. Exemple : 22 pages de timeline et 32 pages de plateforme reçreçues du client. Cela dépend du niveau d’exigence du client.

NR : est-ce que vous simulez des consultants ?

GP : si c’est demandé (quand cela permet de rajouter des éléments de contexte), on le fait. Un exercice de gestion de crise, c’est une utilisation du Cyber Range. Exemple du cameraman qui intervient au milieu de la nuit …

(outre le fait de savoir à quel moment ils allaient parler de l’ENSIBS … je voulais connaître le point de vue de chacun sur le sujet et cela faisait écho à la présentation d’Eric Weber de Thales Communication and Security sur le sujet à C&ESAR 2017 : Problématique de formation des opérateurs face aux menaces Cyber : utilisation des Cyber Range )

31′ : NR : qui fait quoi avec des Cyber Range ? Quel est l’état du marché ? Formation au pentest ?

GP : Prestation d’entraînement et de formation, vente de cyber range avec +/- de prestation.

OF : on cherche à suivre les performances des joueurs. Etablir un ranking / score gobal. L’idée est que chaque année cela s’améliore

AK : ….

HS : Le Cyber Range n’est-il pas plus utile pour la défense que dans l’attaque que NR transforme en une question sur le glissement des plateformes de cyber range avec un bout d’ANSIBLE et trois clics dans le Cloud ?

GP : Au contraire les gens veulent avoir leur plateforme … même si BluecyForce a annoncé au FIC du cyber range as a service (30% des usages). Un hyperviseur avec des VMs ne font pas un CyberRange. Compliqué d’aller mettre dans le Cloud, ton routeur chiffreur de l’OTAN. Le cyber range c’est : Mon infra, mes vulns, mon chemin ! Comme au CENZUB c’est un environnement le plus réaliste possilbe pour s’entraîner à répondre aux cyber-attaques

OF : le cyber range permet de faire de la formation, de la gestion de crise mais aussi du challenge qui permet de se former en s’amusant (Coucou Malice ???)

AK : les directives telles NIS obligent à suivre des entraînement continus. Déjà le cas en zone Asie-Pacifique les entreprises critiques sont obligés d’envoyer ses salariés suivre des entraînements à l’extérieur

HS : Si on s’entraine pas régulièrement, en trois ans on a tout oublié de la formation

GP n’est pas nostalgique mais nous raconte l’évolution de son cyber range depuis SSTIC 2005 : Simulation hybride de la sécurité des systèmes d’information : « vers un environnement virtuel de formation ».  SPLUNK (pseudo SIEM… so right !), QRadar, Prelude Keenaï : on ne fera pas d’entraînement pertinent à des gens s’ils n’y croient pas, s’il n’est pas représentatif. L’important c’est d’y croire. Eh Guillaume, y’a plus de carburateurs depuis longtemps 🙂

JU : Comment simule-t-on la pression psychologique de la crise ?

GP nous met en garde sur la multiplicité des Teams mais le besoin d’avoir une équipe d’acteurs crédibles

NR : simuler une équipe de l’ANSSI qui débarque c’est possible ?

Mot de la fin :

49′ HS : l’entrainement c’est ce qui fait le succès de ce qu’on a enseigné au départ. La formation c’est bien, l’entrainement c’est mieux. Teddy Riner s’entraine tous les jours

(outre le fait de savoir à quel moment ils allaient parler de l’ENSIBS … je voulais connaître le point de vue de chacun sur le sujet et cela faisait écho à la présentation d’Eric Weber de Thales Communication and Security sur le sujet à C&ESAR 2017 : Problématique de formation des opérateurs face aux menaces Cyber : utilisation des Cyber Range)

en goody : Un bon doc d’Airbus DS sur le sujet.

Offre Cyber Range (merci Airbus DS)

Arrivera-t-on un jour à supprimer l’authentification p identifiant / mot de passe ? Je découvre ce jour FIdO.

Qui l’implémente aujourd’hui ? Le site de l’Alliance FIdO recence au  19/02/2018, 18 implémentation commerciales du standard parmi lesquelles DropBox, Pypal, Facebook …

FIDO (Fast ID Online) is a set of technology-agnostic security specifications for strong authentication. FIDO is developed by the FIDO Alliance, a non-profit organization formed in 2012.

FIDO specifications support multifactor authentication (MFA) and public key cryptography. Unlike password databases, FIDO stores personally identifying information (PII), such as biometric authentication data, locally on the user’s device to protect it. FIDO’s local storage of biometrics and other personal identification is intended to ease user concerns about personal data stored on an external server in the cloud. By abstracting the protocol implementation with application programming interfaces (APIs), FIDO also reduces the work required for developers to create secure logins for mobile clients running different operating systems on different types of hardware.

FIDO supports the Universal Authentication Framework (UAF) protocol and the Universal Second Factor (U2F) protocol. With UAF, the client device creates a new key pair during registration with an online service and retains the private key; the public key is registered with the online service. During authentication, the client device proves possession of the private key to the service by signing a challenge, which involves a user-friendly action such as providing a fingerprint, entering a PIN, taking a selfie or speaking into a microphone.

With U2F, authentication requires a strong second factor such as a Near Field Communication (NFC) tap or USB security token. The user is prompted to insert and touch their personal U2F device during login. The user’s FIDO-enabled device creates a new key pair, and the public key is shared with the online service and associated with the user’s account. The service can then authenticate the user by requesting that the registered device sign a challenge with the private key.

The history of the FIDO Alliance

In 2007, PayPal was trying to increase security by introducing  MFA to its customers in the form of its one-time password (OTP) key fob: Secure Key. Although Secure Key was effective, adoption rates were low — it was generally used only by few security-conscious individuals. The key fob complicated authentication, and most users just didn’t feel the need to use it.

In talks exploring the idea of integrating fingerscanning technology into PayPal, Ramesh Kesanupalli (then CTO of Validity Sensors) spoke to Michael Barrett (then PayPal’s CISO). It was Barrett’s opinion that an industry standard was needed that could support all authentication hardware. Kesanupalli set out from there to bring together industry peers with that end in mind.

The FIDO Alliance was founded as the result and went public in February 2013. Since that time, many companies become members, including Google, Microsoft, ARM, Bank of America, Master Card, Visa, Microsoft, Samsung, LG, Dell and RSA. Today, FIDO authentication is guided by three mandates: ease of use, standardization and privacy/security.

strong authentication
multifactor authentication
public key
PII
biometric authentication
one-time password
strong password

Read today on WhatIs.com :

« Rugged DevOps is an approach to software development that places a priority on making sure code is secure before it gets to production. Rugged DevOps takes the lean thinking and Agile mindset that DevOps embraces and applies it to « ruggedizing » software and making sure that security is not a post-development consideration. Rugged DevOps is often used in software development for cloud environments.

The approach requires programmers and operations team members to possess a high degree of security awareness and have the ability to automate testing throughout the software development lifecycle. Despite a large percentage of the IT industry adopting agile and DevOps processes, security testing cycles are still often based on the traditional and cumbersome waterfall approach. This means many organizations forget to do security qualifications tests, such as PCI compliance checks and risk assessments, until it’s almost too late.

To sync security with DevOps cycles, a rugged DevOps team must log integration and delivery processes at a very granular level, so security issues can be identified as they arise. The more granular the records are, the easier it becomes to identify security holes. Both Jira and Cucumber are popular tools for keeping logs in rugged DevOps environments.

For automated DevOps and security testing, there’s a large portfolio of product types, including static application security testing, dynamic application security testing, interactive application security testing and runtime application security testing. Vendors include Contrast Security, Fortify, Veracode and Waratek »

That beein said, what’s the Difference Rugged DevOps and DevSecOps ?

Here is an answer from Sumologic :

In traditional software development environments, security has always been considered a separate aspect – even an afterthought – but now the two practices have emerged to produce safer software in the form of Rugged DevOps and DevSecOps.

A Rugged approach to development and deployment produces applications that stand up to the rockiest tests

Rugged DevOps is an emerging trend that emphasizes a security first approach to every phase of software development. DevSecOps, which combines traditional DevOps approaches with more a more integrated and robust approach to security. These approaches are not mutually exclusive, and take slightly different paths toward the same goal of shifting security leftward and continually focusing on it through the production pipeline.

As today’s environments evolve toward continuous delivery models that can see multiple production releases per day, any miscalculation or error in security can clog the production pipeline. Below is a look at how both Rugged DevOps and DevSecOps approaches can help your organization achieve state of the art design security.

What Is Rugged DevOps?

Rugged DevOps takes the traditional view of security teams as an obstacle and turns it upside down, engineering security into all aspects of design and deployment. Instead of security playing the role of traffic cop slowing down progress, a Rugged DevOps approach makes security a kind of police escort, helping the delivery process proceed with speed and safety.

Rugged DevOps starts with creating secure code. In traditional models code is developed, then penetration testing and automated tools are used to deem the software ‘safe.’ Secure code development involves a different approach, where previously separate teams (development, Q/A, testing, etc.) interact throughout the entire software lifecycle, addressing not just security holes but industry trends and other factors to develop ‘defensible’ code through communication, collaboration, and competition.

The key components of a successful rugged development culture are outlined in the Rugged Manifesto, the definitive document on the subject:

I am rugged and, more importantly, my code is rugged.
I recognize that software has become a foundation of our modern world.
I recognize the awesome responsibility that comes with this foundational role.
I recognize that my code will be used in ways I cannot anticipate, in ways it was not designed, and for longer than it was ever intended.
I recognize that my code will be attacked by talented and persistent adversaries who threaten our physical, economic and national security.
I recognize these things — and I choose to be rugged.

The Rugged DevOps approach was developed to address problems in the traditional delivery method, which handled security by finding problems in the existing software, reporting them, and fixing them. As production releases come to market with ever increasing speed, this system quickly gets overwhelming, and organizations often resort to building out compliance systems that slow development to a crawl.

The rugged approach inverts that model, fixing the slowdown effect of applying security as an afterthought by attacking security at every level of development. Dan Glass, the chief information security officer (CISO) at American Airlines, outlines his company’s approach to using Rugged DevOps to improve and streamline delivery. Their R.O.A.D approach keys on four focus areas.

Rugged Systems. American Airlines (AA) builds security in at all development stages, resulting in systems that resilient, adaptable, and repeatedly tested.

Operational Excellence. The AA culture produces teams that build reliable, sustainable, and fast software, with each team owning quality control near the source and empowered to make improvements.

Actionable Intelligence. Glass stresses the need for telemetry that efficiently processes logs and reveals data that is correct, meaningful and relevant. This data is communicated to teams in as close to real-time as possible, empowering them to address issues.

Defensible Platforms. AA develops and maintains environments that are hardened and capable of surviving sustained attacks. Security teams are involved at every step of the R.O.A.D process, ensuring that adequate defenses are in the software’s DNA.

The Rugged DevOps approach focuses on security through every stage of the development and delivery process, resulting in systems that can endure the rigors of a production environment full of potential hostility. But Rugged isn’t a stand-alone approach to safety. It overlaps with the emerging trend of DevSecOps, which takes a similar approach to securing and hardening applications from inception forward.

What Is DevSecOps?

Wrap security into every step of development to safely deliver product

DevSecOps is the new philosophy of completely integrating security into the DevOps process. It calls for previously unprecedented collaboration between release engineers and security teams, resulting in a ‘Security as Code’ culture. From the DevSecOps Manifesto:

“By developing security as code, we will strive to create awesome products and services, provide insights directly to developers, and generally favor iteration over trying to always come up with the best answer before a deployment. We will operate like developers to make security and compliance available to be consumed as services. We will unlock and unblock new paths to help others see their ideas become a reality.”

The DevSecOps movement, like DevOps itself, is aimed at bringing new, clearer thinking to processes that tend to bog down in their own complexity. It is a natural and necessary response to the bottleneck effect of older security models on modern, continuous delivery cycles, but requires new attitudes and a shuffling of old teams.

What Is the ‘Sec’ in ‘DevSecOps’?

SecOps, short for Security Operations, is an approach for bridging the traditional gaps between IT security and operations teams in an effort to break silo thinking and speed safe delivery. The emerging practice requires a sea change in cultures where these departments were separate, if not frequently at odds. SecOps builds bridges of shared ownership and responsibility for the secure delivery process, eliminating communications and bureaucratic barriers.

Tools and processes are powerful, but it’s people who deliver constant security

Rugged DevOps and DevSecOps: The Shift to Continuous Security

Rugged DevOps and DevSecOps may sound like the latest tech industry buzz phrases, but they are critical considerations in contemporary business. In a market where software can change and respond to customers’ needs multiple times per day, old security models do not work. Potential is lost behind fear of flaws, stifling the continuous delivery process. This cultural shift is helping organizations address security in a continuous delivery environment.

In this great resource from White Hat Security, the authors outline seven habits for successfully adopting Rugged DevOps:

1. Increase Trust And Transparency Between Dev, Sec, And Ops.
2. Understand The Probability And Impact Of Specific Risks
3. Discard Detailed Security Road Maps In Favor Of Incremental Improvements
4. Use The Continuous Delivery Pipeline To Incrementally Improve Security Practices
5. Standardize Third-Party Software And Then Keep Current
6. Govern With Automated Audit Trails
7. Test Preparedness With Security Games

By incorporating these practices, organizations can deliver better product faster, find and fix problems more efficiently, and automated audit trails to take master-level control of your Rugged DevOps environment.

Get More Help

For more resources and the help you need to help your teams embrace and manage security and safely steer the wild new waters of continuous delivery. To learn more, contact us today!

Keep on playing !

Victime de son succès mon hackMeIfYouCan a tenu une bonne dizaine de mois. On va essayer de faire mieux 🙂

Tomcat 9.0.4 : http://vps305886.ovh.net:8080/

Apache2 over Debian : http://vps305886.ovh.net/