Objectifs du CBK (ISC)²
Les 5 domaines d'apprentissage officiels du Domaine 8. Cliquez un objectif pour le détail.
8.1 Intégrer la sécurité dans le SDLC
La sécurité doit être intégrée comme emerging property à chaque phase du SDLC (shift-left), jamais ajoutée après coup. Cela suppose de choisir une méthodologie adaptée, d'appliquer le threat modeling et de gérer change management et configuration control.
Points clés
- La meilleure sécurité est conçue dans le système, pas ajoutée plus tard ; l'essentiel n'est pas qu'un SDLC formel existe mais que tout le processus intègre la sécurité.
- Comparer les méthodologies : waterfall (phases nettes), V-shaped (verification/validation), iterative, spiral (PDCA), Agile, RAD, MPM, DevOps et DevSecOps.
- DevSecOps fusionne la revue par phases du waterfall avec DevOps pour intégrer sécurité et résilience à chaque tour de cycle.
- Le threat modeling (notamment data-centric) identifie les frontières entre système, sous-systèmes et environnement ; ses étapes sont identification, catégorisation et analyse (pas la mitigation).
- Change management et configuration control protègent les specifications, designs et source code contre l'altération dans le pipeline.
8.2 Contrôles dans les écosystèmes de développement
L'environnement logiciel englobe tous les éléments, activités, personnes et systèmes affectant la création et l'usage d'un logiciel. Il faut y appliquer des contrôles : IDE, software libraries, CI/CD, gestion du source code et automatisation sécurisée.
Points clés
- Les IDE fournissent design, codage, compilation, test et intégration ; les software libraries (vendeur, tiers, interne, open-source) doivent être vérifiées.
- CI/CD automatise communication et coordination : la continuous integration teste fréquemment le code dans un repository, la continuous delivery le pousse en production.
- Code reuse et refactoring réduisent les erreurs en réutilisant des unités déjà prouvées correctes et sûres.
- Encapsulation, code protection et data protection isolent les unités logicielles entre elles (code hiding, data hiding).
- Maturity models et software (quality) assurance encadrent l'amélioration continue de la sécurité et de la qualité.
8.3 Évaluer l'efficacité de la sécurité logicielle
Le but premier de l'évaluation est d'apprécier et d'améliorer les mesures de sécurité, en détectant les vulnérabilités tôt dans le cycle. Plusieurs techniques complémentaires existent : analyse statique, dynamique, interactive et protection à l'exécution.
Points clés
- SAST (static analysis) examine le source code sans l'exécuter pour repérer erreurs de type, bornes et code inatteignable - idéal en intégration au SDLC.
- DAST exécute le système pour le pousser à révéler des vulnérabilités ; IAST combine SAST et DAST pour localiser la source.
- RASP intègre des agents de sécurité dans l'application qui détectent et bloquent les violations à l'exécution.
- Regression testing vérifie que des modifications n'ont pas dégradé d'autres fonctions ni introduit de comportements non autorisés ; l'IV&V apporte un regard tiers objectif.
- Quatre types d'évaluation du risque : certification and accreditation, risk management frameworks, CMM, et software assurance.
8.4 Évaluer l'impact des logiciels acquis
Les logiciels acquis (COTS, open-source, libraries, services managés) introduisent des risques propres. Quatre phases structurent leur acquisition via des tiers, et chaque type appelle des contrôles d'assurance et de sécurité adaptés.
Points clés
- Quatre phases d'acquisition : planning, contracting, monitoring/acceptance/deployment, et ongoing use and support.
- COTS sont des produits finis non destinés à la modification, extensibles par scripts, macros et paramètres - leur source code reste opaque.
- L'open-source software expose son source code pour inspection et autorise souvent modification et refactoring, mais exige une software composition analysis des dépendances.
- Les citizen programmers et le code reuse non gouverné échappent au contrôle qualité, CM et sécurité, créant un risque difficile à maîtriser.
- L'acceptance est une remise formelle (test, analyse, évaluation) ; certification et accreditation valident la posture avant exploitation.
8.5 Définir et appliquer des règles de codage sécurisé
Les vulnérabilités étant auto-induites, l'organisation peut mandater par politique l'application de secure coding guidelines. Celles-ci, combinées au defensive programming et à la maîtrise des bases de données, du web et des malwares, réduisent fortement les failles exploitables.
Points clés
- Input validation et defensive programming bloquent les entrées dangereuses, prévenant buffer overflow, injection SQL et arbitrary code execution.
- Strong data typing et blocked/allowed lists renforcent le code ; les API doivent être protégées explicitement.
- Sécurité des bases de données : ACID test (isolation rend les transactions invisibles aux autres), contre aggregation, inference, query et bypass attacks via polyinstantiation et view-based access controls.
- Le mobile code et le web (XML, REST, API) circulent souvent en source code lisible et concentrent des vulnérabilités auto-infligées.
- Connaître le paysage des malwares (virus, worm, ransomware, APT, living off the land) et le software-defined security (SDS) appuyé sur la zero trust architecture.
Concepts clés
Modèles SDLC
Build & Fix, Waterfall (phases séquentielles), V-Model (V&V en miroir), Prototyping, Incremental, Spiral (risque évalué à chaque itération via PDCA), RAD, Agile. Le SDLC s'arrête à l'implémentation ; le SLC (Systems Life Cycle) couvre aussi exploitation et retrait.
Secure SDLC & shift-left
La sécurité doit être conçue dès le début, jamais ajoutée après coup : corriger une faille coûte de plus en plus cher en aval (1x à la conception, exponentiel en production). Shift-left = déplacer les activités de sécurité vers la gauche de la timeline.
Modélisation des menaces & STRIDE
Identifier, catégoriser et analyser les menaces et l'absence de safeguards en cartographiant les frontières du système (threat surface). STRIDE (Microsoft) = Spoofing, Tampering, Repudiation, Information disclosure, DoS, Elevation of privilege. Autres modèles : PASTA, LINDDUN, Trike.
Modèles de maturité (SW-CMM, SAMM, BSIMM)
SW-CMM (SEI, 1991) : 5 niveaux du chaotique à l'optimisé. OWASP SAMM : cadre ouvert en 4 fonctions (governance, construction, verification, operation), chaque pratique sur 3 niveaux. BSIMM : modèle descriptif fondé sur l'observation de programmes réels.
Écosystèmes de développement
IDE, bibliothèques de code, IPT/IPPD (équipes pluridisciplinaires), CI/CD (automatisation entre étapes), DevOps (Dev + Ops + QA en continu) et DevSecOps (sécurité intégrée à chaque étape). Mobile code (JS, JAR, applets) élargit la threat surface côté client et serveur.
SAST / DAST / IAST / RASP
SAST = analyse statique du code source (sans exécution). DAST = test dynamique de l'application en cours d'exécution. IAST = combine SAST+DAST avec analyse comportementale pour localiser la faille. RASP = agent embarqué détectant et bloquant les attaques au runtime.
Software assurance & Certification/Accreditation
Software (Quality) Assurance = vérifier que le logiciel fait ce qu'il doit, rien d'autre, sans failles connues. Certification = analyse technique complète. Accreditation = décision formelle d'une autorité (DAA) d'exploiter à un niveau de risque acceptable.
Logiciel acquis : COTS, open-source, cloud
COTS = produit fini non modifiable par l'utilisateur (extensible via scripts/macros/config). Open-source, services cloud et code tiers introduisent des risques hérités : le bouclier EULA s'érode face à la responsabilité croissante. Évaluer l'assurance avant intégration.
Chaîne logicielle : SBOM & SCA
SBOM (Software Bill of Materials) = inventaire des composants et dépendances d'un logiciel. SCA (Software Composition Analysis) = analyse de ces dépendances pour détecter vulnérabilités et licences. Clé face aux attaques de supply chain (cf. Apache Struts).
Concepts orientés objet
Object = données + méthodes encapsulées. Encapsulation = data/code hiding. Inheritance = une sous-classe hérite des caractéristiques de sa classe parente. Polymorphism = un objet prend plusieurs formes selon son usage, limitant les effets de bord.
Buffer overflow & validation d'entrées
Buffer overflow = entrée surdimensionnée accédant à la mémoire hors du buffer alloué. Parade : validation d'entrées (input validation), strong data typing et type-safe languages. « Garbage in, garbage out » : une entrée non contrôlée peut provoquer arbitrary code execution.
Menaces BDD : aggregation, inference, polyinstantiation
Aggregation = combiner des données non sensibles qui deviennent sensibles en masse. Inference = déduire du sensible à partir du visible. Polyinstantiation = parade : même clé, valeurs différentes selon le niveau de classification. Contrôles par vues (view-based access).
ACID & modèles de bases de données
ACID = Atomicity, Consistency, Isolation, Durability ; garantit l'intégrité des transactions (tout-ou-rien). Modèles : hiérarchique, réseau, relationnel (DBMS, DDL/DML), orienté objet (OO). Accès via ODBC (risque : credentials en clair) ou API REST.
OWASP Top 10 (2021)
Broken Access Control (#1), Cryptographic Failures, Injection (SQLi, XSS), Insecure Design, Security Misconfiguration, Vulnerable & Outdated Components, Identification/Auth Failures, Software & Data Integrity Failures, Logging/Monitoring Failures, SSRF.
Secure coding & sécurité des API
Secure coding guidelines (CERT, OWASP), defensive programming, code reuse contrôlé et bibliothèques de confiance. API REST : authentification par tokens/clés de session, validation, chiffrement TLS ; voir l'OWASP REST Security Cheat Sheet.
Taxonomie des malwares
Virus (action utilisateur requise, Fred Cohen 1984), worm (auto-propagation), trojan/RAT, ransomware, logic bomb, spyware/adware, botnet, trapdoor/backdoor. Living off the land = abuser d'outils légitimes. La plupart exploitent du mobile code via social engineering.
Software-Defined Security & Zero Trust
SDS (Software-Defined Security) pilote la sécurité par logiciel/policy, automatisée et adaptable à l'infrastructure. La Zero Trust Architecture (ZTA) - ne jamais faire confiance, toujours vérifier - est un prérequis et un moteur des solutions SDS.
Coupling et cohesion
Deux metriques de qualite de conception : viser un low coupling (faible dependance entre modules) et une high cohesion (chaque module a une responsabilite unique). C'est le marqueur d'un code maintenable et securisable.
Software escrow
Sequestre du code source chez un tiers de confiance, libere au client selon des conditions contractuelles (faillite du fournisseur, arret du support). Controle de continuite de supply chain pour les logiciels sur mesure.
SOAP vs REST
SOAP : protocole XML strict avec WS-Security (securite au niveau du message), stateful. REST : style leger sur HTTP/JSON, stateless, securise par TLS. Deux familles d'API a connaitre.
Frameworks & standards
| Framework | Rôle |
|---|---|
| SW-CMM / CMMI | Modèle de maturité logicielle (SEI) ; 5 niveaux du chaotique à l'optimisé. |
| OWASP SAMM | Software Assurance Maturity Model : 4 fonctions, pratiques sur 3 niveaux. |
| BSIMM | Building Security In Maturity Model : modèle descriptif fondé sur l'observation. |
| OWASP Top 10 | Liste des 10 risques majeurs des applications web (référence de test). |
| NIST SP 800-154 | Guide de modélisation des menaces centrée sur la donnée (data-centric). |
| CERT Secure Coding | Standards de codage sécurisé (SEI/CERT) par langage. |
| STRIDE | Modèle de menaces Microsoft : 6 catégories d'attaque. |
| CORBA / ORB | Standards d'interopérabilité objet entre machines via un Object Request Broker. |
| OWASP ASVS | Application Security Verification Standard : exigences de vérification applicative. |
Acronymes
| Sigle | Signification |
|---|---|
| SDLC | Software Development Life Cycle (s'arrête à l'implémentation) |
| SLC | Systems Life Cycle (couvre aussi exploitation et retrait) |
| SAST | Static Application Security Testing (analyse statique du code) |
| DAST | Dynamic Application Security Testing (test à l'exécution) |
| IAST | Interactive Application Security Testing (SAST + DAST) |
| RASP | Runtime Application Security Protection (agent embarqué) |
| CI/CD | Continuous Integration / Continuous Delivery |
| CMMI | Capability Maturity Model Integration |
| SAMM | Software Assurance Maturity Model (OWASP) |
| BSIMM | Building Security In Maturity Model |
| COTS | Commercial Off-The-Shelf (produit fini) |
| SBOM | Software Bill of Materials (inventaire des composants) |
| SCA | Software Composition Analysis (analyse des dépendances) |
| ACID | Atomicity, Consistency, Isolation, Durability |
| DBMS | Database Management System |
| ORB | Object Request Broker (interop objet) |
| CORBA | Common Object Request Broker Architecture |
| TOCTOU | Time Of Check to Time Of Use (fenêtre d'attaque) |
| TCB | Trusted Computing Base |
| OWASP | Open Worldwide Application Security Project |
| REST | Representational State Transfer (style d'API) |
| ODBC | Open Database Connectivity |
| XSS | Cross-Site Scripting (injection côté navigateur) |
| CSRF | Cross-Site Request Forgery |
| SQLi | SQL Injection |
| IPT/IPPD | Integrated Product Team / Integrated Product & Process Development |
| KDD | Knowledge Discovery in Databases |