Waarom attesten slechts één onderdeel zijn van uw programma voor cloudbeveiliging

Waarom attesten slechts één onderdeel zijn van uw programma voor cloudbeveiliging

Waarom attesten slechts één onderdeel zijn van uw programma voor cloudbeveiliging

Jul 5, 2017

Gepubliceerd door

Gepubliceerd door

Steven Murray

Steven Murray

-

Categorie:

Categorie:

E-mail

E-mail

Ready to see Bird
in action?

Ready to see Bird
in action?

Why Attestations Are Just One Part of Your Cloud Security Program

Attesten meten niet altijd uw defensieve houding

An attest, per definitie, 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. De 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” naar de government. As I will outline however, just because the standards are set doesn’t mean implementation is always stellar.


De inzet van een instrument betekent niet dat het waarde toevoegt.

Controles bieden ruimte voor flexibiliteit bij de uitvoering en operationele groei en innovatie in de loop der tijd. Helaas gebruiken sommige organisaties de flexibiliteit om het hokje aan te vinken, maar beschikken zij niet over echte verdedigingsmechanismen.


Een goed voorbeeld van dit probleem zijn inbraakdetectie-/beschermingssystemen (IDS of IPS). Net als virusscanners investeren de meeste organisaties in IDS/IPS als onderdeel van de standaard beveiligingspraktijken om zich te beschermen tegen kwaadaardig verkeer en exfiltratie van gegevens. De industrie zit vol met verkopers van verschillende vormen van IDS/IPS-systemen. Sommige organisaties bouwen echter systemen in plaats van ze te kopen.


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.


Een slimme controleur zou het probleem niet hebben opgemerkt, omdat de attesten niet zoeken naar "operationele" informatie over alle systemen - de norm is letterlijk één laag van vraag en antwoord. In feite meten de meeste attesten gewoon of het instrument bestaat, niet de operationele levensvatbaarheid. Bovendien zijn de meeste auditors niet technisch genoeg om een functioneel IDS/IPS te onderscheiden van een niet-functioneel. De kern van de audit is dat het bedrijf zijn beste beentje voorzet in plaats van moeilijke vragen te beantwoorden. Auditors moeten tijdens een audit ook een groot aantal controles bestrijken, dus de tijd is een grote factor in de kwaliteit van hun analyse.


Een attest alleen zal u vertellen dat een bedrijf een volwassen beveiligingsprogramma met controles heeft. Een potentiële partner vragen een leveranciersonderzoek in te vullen zal u ook geen vertrouwen geven. Enquêtes schetsen slechts dezelfde informatie in een ander formaat. Dus hoe beoordeelt u een volwassen beveiligingsprogramma?


Evalueer het gehele programma voor cloudbeveiliging

Ten eerste moet u ten minste de attesten en het verslag van de bevindingen bekijken, niet de samenvatting. Dat geeft u een overzicht van het programma dat door een derde partij is beoordeeld. Ten tweede moet u zeker nagaan of het bedrijf een penetratietest door derden of een bug bounty-programma ondergaat. Persoonlijk ben ik geen fan van bug bounty's, maar wel van penetratietesten door derden op jaarbasis. Pentesting biedt u een gestructureerde test van uw verdediging en echte feedback over kwetsbaarheden. Bekijk ten slotte de beveiligingsdocumenten (meestal inhoudsopgave) die het bedrijf gebruikt als basis voor de implementatie. Dit omvat (maar is zeker niet beperkt tot) een beveiligingsbeleid, incident response en vulnerability management. Een ervaren beveiligingsteam zal aanbieden die documenten en artefacten te delen als onderdeel van de normale bedrijfsvoering.


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.

Your new standard in Marketing, Pay & Sales. It's Bird

De right message -> naar de right person -> aan de right time.

Your new standard in Marketing, Pay & Sales. It's Bird

The right message -> to the right person -> aan de right time.