CORI&IN 2020

Mardi 28 janvier 2020, j’ai CoRI&IN à Lille. Dit comme ça, on pourrait croire à une vulgaire escale dans le grand Nord.

J’adore ce nom mystérieux et intweetable, encore plus improbable que son cousin breton C&ESAR (plus discret que ceux de la TF Wagram). CoRI&IN, c’est LA conférence (française) sur la réponse aux incidents et l’investigation numérique.

Au programme cette année, plein de belles choses. Nouveauté de l’année, juste avant l’âge de raison, la conf du Centre Expert contre la Cybercriminalité Français (CECyf) intègre le FIC et rallie donc le Grand Palais :

 » Dans le cadre du FIC 2020 – Forum International sur la Cybersécurité, nous vous proposons de nous retrouver le premier jour de cet événement de référence (mardi 28 janvier 2020), pour la sixième conférence de ce genre en France, dédiée aux techniques de la réponse aux incidents et de l’investigation numérique. Cette journée permettra aux enquêteurs spécialisés, experts judiciaires, chercheurs du monde académique ou industriel, juristes, spécialistes de la réponse aux incidents ou des CERTs de partager et échanger sur les techniques du moment. L’ambition de cette conférence est de rassembler cette communauté encore disparate autour de présentations techniques ou juridiques de qualité, sélectionnées par notre comité de programme. « 

Lire l’original ? clic !

Trêve de palabres, j’y courre … Bortzmeyer tweette déjà.

CORI&IN est au FIC (et Patrick est aux toilettes)

Programme

• A partir de 10h – Accueil
• 11h – Début des conférences, elles se tiendront en Français
• 11h00-11h30 : L’investigateur, le Smartphone, et l’application WhatsApp, Guénaëlle De Julis (EXCELLIUM)

oui mais bof, trop de détails sur la version Androïd sur laquelle on n’est pas sur de grand chose. TP SQlite avec Pandas librairie Python. Comemnt s’appelle l’outil SOGETI (?) qui fait le taf ?

• 11h30-12h00 : Gestion d’Incidents et investigations en environnement Cloud, Philippe Baumgart et Fahim Hasnaoui

suis largué sur les CSP, je vais rester « on premise ».

• 12h00-12h30 : Fuite de données & Credential Stuffing, Sébastien Mériot – CSIRT Head (OVH) – @smeriot

j’ai adoré … more details to come

• 12h30-13h00 : Injection et discrétion avec Pastebin, François Normand (LASTINFOSEC)

mince, y’a vraiment ça sur https://pastebin.com/

• 13h00-14h00 : Déjeuner

tous ceux qui ont vécu CoRI&In 2018, vous dirons que c’était parfait ce midi

• 14h00-14h30 : A year hunting in a bamboo forest, Aranone Zarkan et Sébastien Larinier

TMP AMBER

• 14h30-15h00 : Investigations numériques avec le projet TSURUGI LINUX, Giovanni Rattaro (openMinded)

pourquoi tant de boulot pour une n-ième distro FORENSIC ?

• 15h00-15h30 : Analyse memoire de routeur CISCO IOS-XR 32bits, Solal Jacob (ANSSI)

là, j’ai pris cher … pas tout suivi

• 15h30-16h00 : Pause
• 16h00-16h30 : Mais qui est vraiment responsable de ce préfixe d’adresses IP, Stéphane Bortzmeyer (AFNIC)

du grand Bortz ! je me sauve à l’issue … dommage de louper les 2 dernières confs. Vivement les slides

GG les mecs (même si c’est des filles)

• 16h30-17h00 : DFIR-ORC, Jean Gautier
• 17h00-17h30 : Réponse à incidents suite à l’exploitation d’une vulnérabilité sur un VPN Pulse Secure possiblement par APT5 : retour d’expérience, Mathieu Hartheiser et Maxence Duchet

Une fois sur place, direction la salle Jeanne de Flandres et accueil par le Colonel Freyssinet. Le confort est sommaire (prends ta pauvre chaise bas de gamme), la distribution électrique inexistante… je regrette déjà Polytech’ Lille.

Bien aimé cet article qui m’évitera de partir from scratch quand on me re-demandera mon avis sur le sujet.

Je le reprends donc ci-dessous intégralement en y intégrant mes commentaires afin que personne ne puisse penser qu’il puisse s’agir d’un abominable plagiat.

A couple of years ago, there was some debate over the usefulness of password managers. Some argue that password managers are a bad idea, because they create one vector of attack that can breach all of your online credentials. These concerns were hightened when OneLogin was subject to a major cyber attack on May 31^st, 2017. From OneLogin:

“Our review has shown that a threat actor obtained access to a set of AWS keys and used them to access the AWS API from an intermediate host with another, smaller service provider in the US. Evidence shows the attack started on May 31, 2017 around 2 am PST. Through the AWS API, the actor created several instances in our infrastructure to do reconnaissance. OneLogin staff was alerted of unusual database activity around 9 am PST and within minutes shut down the affected instance as well as the AWS keys that were used to create it…

The threat actor was able to access database tables that contain information about users, apps, and various types of keys. While we encrypt certain sensitive data at rest, at this time we cannot rule out the possibility that the threat actor also obtained the ability to decrypt data. We are thus erring on the side of caution and recommending actions our customers should take, which we have already communicated to our customers.”

Troy Hunt of Have I Been Pwned fame argues that password managers are very necessary, you just need to choose a good one and practice good opsec (operational security) with your use of it. Keep in mind that he has an endorsement deal of some sort with 1Password, which is a password manager. But despite this possible conflict of interest, I think his advice is good:

“Your brain is a very bad password manager. It’s incapable of storing more than a couple of genuinely random strings of reasonable length (apologies if you’re a savant and I’ve unfairly characterised you in with the rest of our weak human brains). That leads to compromises. If you’re one of these people who says ‘I’ve got a formula that always gives me unique passwords that are strong,’ no you don’t, they probably aren’t and no they’re not. You’re making concessions on what we empirically know is best practice and you’re kidding yourself into thinking you aren’t. I’ve had this debate many times before and there’s dozens of comments raging backwards and forwards about this in my post on how the only secure password is the one you can’t remember.”

My friend John Opdenakker‍ also has good advice about password managers. He likes the password manager that’s built into Firefox. While you’re there, I recommend you check out the rest of his very informative blog. But without further ado, here’s some of what he has to say about password managers:

“The security of most browser’s built-in password managers is still inadequate. At the moment Firefox is the most secure. The built-in password managers of the discussed browsers and Google’s (cloud-based) password manager still can’t compete with the most third party password managers. Both when it comes to security and integration of necessary features.

If you want to use a built-in password manager Firefox is the best choice at the moment. If you want to use a cloud-based password manager I recommend you to do some research and choose a third-party password manager that is most suitable for you. If a password manager is nothing for you use a password book that you keep close to you.

Keep in mind that the goal is to create strong passwords and store them in a secure way. Which tool you use is irrelevant, as long as it supports you to reach that goal.”

And here’s my own general advice about password managers, in a nutshell:

• Using a password manager is better than not using a password manager. So use one! We all have dozens or perhaps hundreds of credentials for various websites and online services these days. Writing them down in a book can be vulnerable if other people can have physical access to where you keep the book at work or at home. Plus that method encourages users to come up with their own passwords. User created passwords are almost always less secure than randomly generated passwords that a password manager can create. And if your list of passwords is digital, like a text file on your local hard drive or on the cloud as a note in Evernote or Google Keep, that’s cleartext that can be exposed in a cyber attack. If you encrypt a local file with your credentials, that’s still a hassle as you need to execute your text editor or word processor each time you need a password. And the method still encourages weaker user-generated passwords. Pretty much all password managers can generate a much more secure, random password for you.
• Be careful with the opsec of the phone, tablet, and PC endpoints that you keep your password manager on. A password manager on your home or work PC should be in a user account with a password. (Damn it! Ha.) You don’t want your family members or coworkers to be able to access your password manager without your operating system user account behind a password. The same applies to mobile devices. You could lose sight of your phone or tablet, make sure your mobile endpoints with password managers are protected with a lockscreen. And have a “find my device” service set up in case you lose your phone or tablet– which is also often a means of two-factor authentication.
• On that note, have two factor authentication set up on as many of your online accounts as possible!

Alright, now here’s a brief rundown of the different password managers you could use.

• Google Chrome, Mozilla Firefox, Opera, Microsoft’s Edge, and Apple’s Safari all have built-in password managers in their most recent versions on PC and mobile devices. For convenience, you may want to use the built-in password manager in your favourite web browser. I don’t recommend Chrome these days due to Google’s tendency to profit from selling your data. Firefox’s, Opera’s, Edge’s, and Safari’s built-in password managers are all pretty good. I personally use Firefox’s password manager.
• Third-party password managers, unlike the password managers built into web browsers, tend to not be freeware. But because they are maintained by entities that are separate from the web browser platforms, that separation may be good from a security perspective. Cyber attacks to Google, Mozilla, Apple, and Microsoft’s cloud servers may put their browser-stored credentials at risk while leaving the third-party password management platforms unscathed. And pretty much all third-party password managers have web browser plugins for most popular browsers on desktop and mobile. It also occurs to me that perhaps, by paying a fee rather than using freeware, they may have extra incentive to secure their credential storage. Here are some third-party password managers for you to consider:
• 1Password has apps for macOS, iOS, Windows, Android, Linux, and Chrome OS, with 24/7 email support. Prices range from $2.99 to $7.99 per month, depending on your personal or business needs and they offer a 30 day free trial. Check it out here.
• Bitwarden has apps for Windows, macOS, Linux, Android, and iOS, with web browser plugins for Chrome, Firefox, Opera, Microsoft Edge, Safari, Vivaldi, Brave, and Tor Browser. There’s a free version, plus subscription options from $1 to $5 per month depending on your personal or business needs. Check it out here.
• Dashlane has apps for Windows, macOS, Linux, Android, and iOS. The free version can store up to 50 passwords, the paid version has Dark Web monitoring, a VPN, and unlimited password storage for $3.33 per month. Check it out here.

https://www.peerlyst.com/posts/so-you-need-a-password-manager-kimberly-crawley

Ars Technica

Bug in French government’s WhatsApp replacement let anyone join Élysée chats

Researcher found bug in email validation that let him log in and join « rooms » in Tchap app.

Sean Gallagher – 4/22/2019, 11:55 PM

_____________________________________

fzn

France : le lancement de l’application Tchap entaché par un bug

______________________________________

« Les retours des experts vont nous aider à améliorer Tchap »

Tchap

Liens vers les sources :

(From Tchap with love)

______________________________________

Bortz on Twitter

______________________________________

@fs0c131y

Elliot Alderson

 

@fs0c131y

 

Gros site opportuniste

 

A ne pas confondre avec le site officiel https://www.tchap.gouv.fr/ qui présente en particulier sa rubrique FAQ.

Tchap

New Vector

Thales

An Application Program Interface aka API is code that allows two software programs to communicate with each another. The API spells out the proper way for a developer to write some code requesting services from an operating system or other applications. In a web context, APIs allow communication between two webapps (or a web app and a client that is not always a brose) without any browser.

A RESTful API, also referred to as a RESTful web service, is an Application Program Interface that uses HTTP requests to GET, PUT, POST and DELETE data.

A RESTful API  is based on REpresentational State Transfer (REST) technology, an architectural style and approach to communications often used in web services development.

REST technology is generally preferred to the more robust Simple Object Access Protocol (SOAP) technology because REST leverages less bandwidth, making it more suitable for internet usage.

The REST used by browsers can be thought of as the language of the internet. With cloud use on the rise, APIs are emerging to expose web services. REST is a logical choice for building APIs that allow users to connect and interact with cloud services. RESTful APIs are used by such sites as Amazon, Google, LinkedIn and Twitter.

A la base, j’aimais bien cet article pour une partie de son contenu mais pas pour le plan de construction et comme j’avais besoin d’expliquer pourquoi certaines API ne respectaient pas les concepts REST, j’ai eu besoin de ré-écrire cette introduction.

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/

09h30 – 10h30 – Accueil – Café

10h30 – 10h50 – Introduction, Éric Freyssinet

250 pax cette année. amphi complet, changement d’ami l’an prochain

Environ 1/3 de résents ne vont pas au FIC, environ 10% son des locaux

10h50 – 11h30 – L’investigation numérique saisie par le droit des données personnelles, Eve Matringe

Première intervention par @evematringe pour des regards croisés loi/judiciaire et technique

RGPD : « Règlement n°2016/679 du Parlement Européen et du Conseil du 27 avril 2016 relatif à la protection des personnes physiques à l’égard du traitement des données à caractère personnel et à la libre circulation de ces données »

+ Directive 2016/680 : Directive (UE) 2016/680 du Parlement européen et du Conseil du 27 avril 2016 relative à la protection des personnes physiques à l’égard du traitement des données à caractère personnel par les autorités compétentes à des fins de prévention et de détection des infractions pénales, d’enquêtes et de poursuites en la matière ou d’exécution de sanctions pénales, et à la libre circulation de ces données, et abrogeant la décision-cadre 2008/977/JAI du Conseil

11h30 – 12h10 – Full packet capture for the masses, Xavier Mertens – @XMe

Moloch = Full Packet Capture Framework : https://github.com/aol/moloch

les sondes (sensors) sont installées sur les serveurs dans un docker et envoient leur capture via cron over ssh

#balancetonpcap

12h10 – 12h50 – Analyse des jobs BITS, Morgane Celton et Morgan Delahaye (ANSSI)

https://github.com/ANSSI-FR/bits_parser (bientôt)

12h50 – 14h00 – Pause déjeuner

14h00 – 14h40 – CCleaner, Paul Rascagnères

14h40 – 15h20 – Retour d’expérience – Wannacry & NotPetya, Quentin Perceval et Vincent Nguyen (CERT-W)

15h20 – 16h00 – Pause Café

16h00 – 16h40 – Comment ne pas communiquer en temps de crise : une perspective utile pour la gestion d’incident cybersécurité, Rayna Stamboliyska

16h40 – 17h20 – Wannacry, NotPetya, Bad Rabbit: De l’autre coté du miroir, Sébastien Larinier

17h20 – 18h00 – Forensic Analysis in IoT, François Bouchaud

18h00 – Mot de clôture