Les attestations ne mesurent pas toujours votre posture défensive

An l'attestation, par définition, is an indication that makes something evident. In the case of the security, specifically security programs it means to certify in an official capacity.

People often ask me what makes a good security program. As much as I would like to point to one aspect of my security perimeter to use as an example, there are multiple items to highlight. Le industry relies on attestations and certifications to measure your security defenses. Engineers and operators will tell you that your actual security perimeter and threat assessment capabilities define your security program. I will tell you it is both compliance attestations as a measurement and the operational capabilities of your security team that define your program. Though attestations alone are not an accurate benchmark to measure a program.

Attestations are an industry necessity to ensure compliance with federal, local and state statutes as well as industry best practices. ISO, NIST or DoD standards form the baseline of most attestations. NIST, for example, publishes a set of standards and technical guides to help organizations build perimeter defenses that are “acceptable” à la government. As I will outline however, just because the standards are set doesn’t mean implementation is always stellar.

Le déploiement d'un outil ne signifie pas qu'il apporte une valeur ajoutée

Les contrôles permettent une certaine souplesse dans la mise en œuvre, ainsi qu'une croissance et une innovation opérationnelles au fil du temps. Malheureusement, certaines organisations utilisent cette flexibilité pour cocher la case, mais n'ont pas de véritables défenses en place.

Les systèmes de détection et de protection contre les intrusions (IDS ou IPS) constituent un excellent exemple de ce problème. À l'instar des scanners de virus, la plupart des organisations investissent dans des IDS/IPS dans le cadre de pratiques de sécurité standard afin de se prémunir contre le trafic malveillant et l'exfiltration de données. L'industrie regorge de fournisseurs proposant diverses formes de systèmes IDS/IPS. Toutefois, certaines organisations préfèrent construire des systèmes plutôt que de les acheter.

I recently left one such organization that “built” their own intrusion detection system from open source tools. Auditors were told the system was a “fantastic tool”, and even given examples of traffic. When I dug deeper into the telemetry the tool was providing, I realized that traffic was not being analyzed at all. Rather, passing through the sensor as it was not configured to capture any traffic or alert at all. Furthermore, the credentials used to administer the tool were set up by a previous employee and were never updated after his departure. So essentially, the tool was sitting idle for months without any human intervention. Not only does this put the company at risk, but it also compromises the perimeter.

Un auditeur avisé n'aurait pas détecté le problème car les attestations ne recherchent pas d'informations "opérationnelles" sur tous les systèmes - la norme est littéralement une couche de questions et de réponses. En fait, la plupart des attestations mesurent simplement si l'outil existe, et non la viabilité opérationnelle. De plus, la plupart des auditeurs ne sont pas assez techniques pour discerner un IDS/IPS fonctionnel d'un non fonctionnel. L'essentiel de l'audit repose sur la capacité de l'entreprise à se mettre en valeur plutôt que de répondre à des questions difficiles. Les auditeurs doivent également couvrir un large éventail de contrôles au cours d'un audit, le temps est donc un facteur important dans la qualité de leur analyse.

Une attestation seule vous dira qu'une entreprise a un programme de sécurité mature avec des contrôles. Demander à un partenaire potentiel de remplir une enquête sur les fournisseurs ne vous donnera pas non plus confiance. Les enquêtes ne font que présenter les mêmes informations dans un format différent. Alors comment évaluer un programme de sécurité mature ?

Évaluer l'ensemble du programme de sécurité du cloud

Tout d'abord, vous devez examiner au minimum les attestations et le rapport de conclusions, et non le résumé. Cela vous donnera un aperçu du programme examiné par une tierce partie. Deuxièmement, vous devez absolument vérifier si l'entreprise est soumise à un test de pénétration ou à un programme de primes aux bugs par une tierce partie. Personnellement, je ne suis pas un fan des primes de bogues, mais je suis un fan des tests de pénétration effectués par des tiers sur une base annuelle. Le test de pénétration vous fournit un test structuré de vos défenses et un véritable retour d'information sur les vulnérabilités. Enfin, examinez les documents de sécurité (généralement la table des matières) que l'entreprise utilise comme base pour la mise en œuvre. Cela inclut (mais ne se limite certainement pas à) une politique de sécurité, la réponse aux incidents et la gestion des vulnérabilités. Une équipe de sécurité expérimentée proposera de partager ces documents et artefacts dans le cadre de ses activités normales.

I make it a matter of course to evaluate every vendor and partner from the perspective of access to company data. Meaning if the partner or vendor manages company data, they’re subject to more scrutiny than a vendor that does not. Keep in mind the business purpose when evaluating a security program. I review the business purpose and type of information involved, then evaluate from that perspective, rather than handle all partners and vendors the same. When in doubt, always ask for more information.