Data Management as a Service - Data Driven Workflows
La Solution BPM No-Code pour tous vos métiers

Quentin Adam

Software systems are prone to the build up of cruft - deficiencies in internal quality that make it harder than it would ideally be to modify and extend the system further. Technical Debt is a metaphor, coined by Ward Cunningham, that frames how to think about dealing with this cruft, thinking of it like a financial debt. The extra effort that it takes to add new features is the interest paid on the debt.

La loi de Murphy - Tout ce qui peut mal tourner va mal tourner.
Le principe de Pareto - 80% des effets sont le produit de 20% des causes.
La loi de Parkinson - Le travail se dilate jusqu'à remplir toute la durée disponible pour son accomplissement.
La loi de futilité - En réunion, plus le sujet est important, moins on y passe de temps.
La loi de Carlson - Un travail réalisé en continu prend moins de temps et d’énergie que lorsqu’il est réalisé en plusieurs fois.
La loi d'Illich - Au-delà d’un certain seuil, l’efficacité humaine décroît fortement, voire devient négative.
La loi de Laborit - Le comportement humain nous incite à faire en premier ce qui nous fait plaisir.
La loi de Hofstadter - Les choses prennent plus de temps que prévu, même en tenant compte de la loi de Hofstadter.
La loi de Fraisse - 1 heure n'est pas toujours égale à 1 heure. Faites une activité intéressante et le temps semblera passer plus vite.
La loi de Kotter - Les meilleurs changements commencent par des résultats immédiats.
La loi de Taylor - L’ordre dans lequel nous effectuons une série de tâches influe directement sur le temps qu’elles nous prennent.
La loi de Douglas - Plus on a de place, plus on étale ses affaires.
La loi de Brooks - Ajouter des personnes à un projet déjà en retard le retarde encore plus.
La loi de Conway - Tout logiciel reflète l'organisation qui l'a créée.
La loi de Wirth - Les logiciels s'alourdissent plus vite que ne progressent les performances du matériel.
La loi de Fitts - Le temps pour atteindre un objectif dépend de la distance et de la taille de celui-ci.
La loi de Golub - Un projet mal planifié prend trois fois plus de temps que prévu.
La loi de Tesler - Vous ne pouvez pas réduire la complexité d'une tâche donnée au-delà d'un certain point.
La loi de Lakein - En négligeant la stratégie, on libère peu de temps tout en augmentant drastiquement ses chances d'échouer.
La loi de Hick - Le temps nécessaire pour prendre une décision augmente avec le nombre et la complexité des choix.
La loi de Hostman - Les gens et leur attitude, ce sont eux qui produisent les résultats.
La loi d'Allen - L'efficacité de la communication diminue de manière exponentielle avec la distance physique entre les personnes.
La loi de Swoboda-Fliess-Teltscher - L'efficacité passe par la prise en compte de ses rythmes biologiques.
L'effet Zeigarnik - Une personne se souvient mieux des tâches incomplètes ou interrompues que des tâches terminées.

1. La Loi de Murphy
2. Loi de Parkinson
3. Loi de Carlson
4. Loi de Douglas
5. Loi de Illich
6. Principe de Pareto
7. Loi de Laborit
8. Loi de Hofstadter

Née en 2014 d’un projet de fin d’études, en 2016 L’Increvable devient officiellement une entreprise qui se donne pour mission de porter une autre vision de l’électroménager : plus durable car plus facilement réparable.

1/ Carrd
2/ Gumroad
3/ Canva
4/ Outseta
5/ AirTable
6/ Calendly
7/ Fathom Analytics
8/ Loom
9/ http://Testimonial.to
10/ HypeFury
11/ Typeshare
12/ Notion
13/ BlackMagic
14/ Zapier

Geoffroy Couprie is a consultant in software security and an independent developer. He teaches development teams how to write safe software.

This is the most seducing approach in IT security. This is also the worst. For more than 20 years now, people have believed that their network was a fortress, protected from the outside world by firewalls, NAT and DMZ. This idea is obsolete, we must change now.

20 years ago, it was still possible to see internal networks totally open, with every machine directly addressable from Internet. There were enough IPv4 addresses for everybody, the networks were small, life was good. But the security was atrocious: TCP stacks were remotely exploitable, worms were reproducing on corporate networks, internal file servers were publicly available, so people found the easiest way to secure everything on the cheap: isolate the network from the outside world. There’s nothing wrong with that approach: it made sense at the time.

As usual when someone finds a small, temporary hack instead of fixing everything, people kept improving it, approaching the local optimum. This led to firewalls on every machine, every network. People discovered that NAT could hide IP addresses, instead of simply allowing IP reuse, and thought it was a security feature. All of the nonsense about DMZ and airgapped networks appeared. Companies were actually selling hardware which would get packets from one network, disconnect (physically) from it, connect to another network, then send the packets. Airgap, yup.

It worked for a time, since a lot of exploits in the 90s focused on remote exploits in operating systems and servers. If you cannot exploit the public face of the network, everything is alright.

Unfortunately, we cannot think that way anymore. Web applications give too much entry points to your servers. Pivoting from a DMZ server to the internal network is easy, since internal users will also access those web applications. The attacker is only one wrong click on a lovingly crafted PDF file away from your network. Why would you concentrate on firewall rules when phishing is so effective?

Once the attacker is in your network, it is over. Listen to traffic, elevate your privilege, pivot to another machine, impersonate users, traverse the whole network…

Traditional IT infrastructure

The fortress metaphor, where everything behind your firewall is safe and trusted, is dead. Your walls are useful, but not that much when the attacker can get insiders to help him, willingly or unknowingly.

The goal is not to keep the attacker out of your system. It is to detect the threat, isolate it, find the attacker’s path and heal the system. The attacker may have been in your network for months. How would you be sure he is not there anymore?

There is a much better metaphor than the fortress, now. Think of your system as a city. The city can have walls, but to function properly, it should let people enter and get out. You cannot know precisely if everything in your city is legit. Chances are, someone uses his personal USB key. Someone else connected a WiFi router in his office. People are talking on Facebook, watching porn, using forbidden applications, like modern browsers. You will not be able to catch them, unless repression is your main tool, and this will not help them work. You want to reduce criminality in your city, but you will not eradicate it. You cannot prevent fires, but you can prevent them from spreading too far and too fast.

If you imagine the attacker as already present on your network, you go from plugging holes in one wall, to verifying dependencies and access control between systems. The trusted network approach is flawed, you have to think in terms of authorization from one user/app/machine to the other. The attacker will explore your network from one node to the next connected one, from one access level to the upper one, and try to combine them. Defenders think in lists, attackers think in graphs. You must assume that the internal network is as dangerous as the Internet.

Assuming that servers will be safer if they are on your own network leads to a false sense of security.

This is also why the nonsense around private cloud has to die. Assuming that servers will be safer on your own network leads to a false sense of security. A system built from scratch to handle the worst of internet has a better chance to survive. What matters is access control granularity around data, users and applications. The network is not a security boundary anymore.

Software engineers go crazy for the most ridiculous things. We like to think that we’re hyper-rational, but when we have to choose a technology, we end up in a kind of frenzy — bouncing from one person’s Hacker News comment to another’s blog post until, in a stupor, we float helplessly toward the brightest light and lay prone in front of it, oblivious to what we were looking for in the first place.