Heb ik een pentest waiver nodig naast mijn algemene voorwaarden als security onderzoeker?

Een lezer vroeg me:

Als IT-consultant werk ik al jaren met het systeem van contractje en algemene voorwaarden. Nu doe ik sinds een tijdje ook specifieke securityklussen, en collega’s in dit vakgebied wijzen me er nu op dat ik klanten dan een pentest waiver moet laten tekenen. Maar is gewoon een duidelijke opdracht niet genoeg?

Zowel algemene voorwaarden als een pentest waiver beschermen je als opdrachtnemer. Een pentest waiver heeft vooral het voordeel dat hij explicieter en concreter is over het specifieke onderwerp van securityonderzoek.

Als het goed is, staan in je algemene voorwaarden al de nodige bepalingen waar je je klanten aan kunt houden: ze moeten de benodigde informatie geven, ze moeten zorgen dat jij het werk ongestoord kunt doen en ze moeten je vrijwaren van claims van derden die door hun toedoen bij jou op je bordje komen. Dit is generiek genoeg om ook claims van bijvoorbeeld leveranciers te pareren, en met een beetje goede wil ook om ze te dwingen je strafrechtadvocaat te betalen om vrijgesproken te worden van computervredebreuk.

Generiek is bij juridische zaken gelijk aan twijfelachtig en daarmee gelijk aan vele dure uren van juridisch advies en gebakkelei. Een pentestwaiver heeft als voornaamste voordeel dat dit er allemaal expliciet staat, zodat er minder discussie kan ontstaan. (Discussie tot nul reduceren is bij juristen onmogelijk.)

Een typische pentestwaiver vermeldt bijvoorbeeld expliciet dat er toestemming is van alle betrokkenen om hun infrastructuur te mogen binnendringen, en dat geen aangifte zal worden gedaan van vernieling van gegevens wanneer het pentest onderzoek door onzorgvuldigheid tot gegevensverlies leidt. Zo’n harde toezegging is erg handig om een aangifte of civielrechtelijke procedure direct te laten stranden.

Zonder een pentestwaiver moet je dus terugvallen op generieke teksten uit je algemene voorwaarden, en misschien krijg je dan wel het risico dat de klant zegt die nooit gekregen of geaccepteerd te hebben. Of hij stelt dat “het werk ongestoord doen” betekent dat hij een bureau en stoel moest leveren, maar niet dat hij bij leveranciers moest melden dat jij de gehele infrastructuur ging proberen binnen te dringen. En dan heb je een fors probleem als het misgegaan is met je opdracht en er een boze hostingleverancier aangifte heeft gedaan en tachtig man personeel een schadeclaim indienen wegens AVG overtredingen.

Arnoud

10 reacties

  1. Als werknemer (onbepaalde tijd) heb ik in het verleden ook beveiligingstesten gedaan. Ik had dit toen van tevoren bij mijn werkgever getoetst en hier is toen ook door meerdere mensen mee akkoord gegaan. Dat heeft in de maanden daarna best wel een grote stapel aan fouten blootgesteld. Sommige lagen politiek wat gevoelig, maar uiteindelijk was het wel goed en heeft mij werkgever mij er hartelijk voor bedankt.

    Als aannemer van een klus, (ZZP of anders) lijkt het mij net zo goed verstandig om dit van tevoren te bespreken en om dit dan ook goed vast te leggen in een contract. Niet in de algemene voorwaarden, want een spelletje van staat-er-toch is misschien wel juridisch goed genoeg, maar het zal zeker betekenen dat je er nooit meer binnen komt.

  2. Ik schreef eens een intranet applicatie met een hoge veiligheidsrestrictie met SLA. Toen ik na een week de logs bekeek schrok ik mij een hoedje: Barstensvol met SQL injectie – , XSS – , brute force -, buffer overflow – pogingen. Heel de dag en nacht bezig geweest om te kijken of men ergens was geweest waar men niet mocht zijn, of het intranet zelf was gehacked, of ik zelf dan misschien een logger had.

    Volgende ochtend, met zes bakken koffie in de mik, dat nare belletje met kloppend hart: “we hebben inbraakpogingen op het systeem gedetecteerd. Initieel onderzoek toont geen lekken aan. Maar de pogingen zelf ligt in de honderden.”. Maar de reactie was nonchalant: “Oh dat is gebruiker X, die heeft daar een handje van.”. Blijkens achtte meneer zichzelf een amateurhacker en was “gewoon” bezig met due diligence op het softwarepakket: “Even kijken of het wel werkelijk veilig is en of het systeem ook gebruikersnamen van 4096 characters of meer accepteerd”.

    Pentest door de gebruiker zelf, zeg maar. Misschien ook een idee om daar iets over op te nemen in de algemene voorwaarden (“Dit supermanpak maakt u niet werkelijk een held” / “probeer alstublieft onze software niet moedwillig te breken zonder vooraf melding te geven”.)

    1. Ik ben het met je eens dat een bedrijf je even een waarschuwing hoort te geven als ze een pentest plannen voor de applicatie die je beheert. Spaart je een nacht overwerk. Aan de andere kant vind ik dat je een pentest, ook al is het door een amateur gedaan, niet kunt verbieden.

        1. Als je wilt dat beveiligingsgaten hersteld worden zul je ze eerst moeten vinden… Een pentest is een methode om het bestaan van gaten aan te tonen en daarmee een nuttig hulpmiddel in je beveiliging.

          Als een externe leverancier mij ronduit zou verbieden een pentest te doen op de door hem geleverde applicatie dan zou ik me sterk gaan afvragen of die applicatie wel aan de basale beveiligingseisen voldoet. Je weet nooit of zo’n applicatie de springplank kan worden waarmee criminelen verder je netwerk inkomen.

          1. Ik zou het wel redelijk vinden als jij vooraf ovrleg moet voeren over het hoe en wat van die pentest. Het verhaal van Thorvald hierboven klinkt mij als zeer waarschijnlijk in de oren en had voorkomen kunnen worden met één belletje. En mogelijk heeft de leverancier al een externe pentest laten uitvoeren en kan hij daar een rapport van laten zien. Dat scheelt iedereen dan een hoop moeite, toch?

            1. Enig overleg over hoe en wanneer bij een pentest (met name voor applicaties waarbij externe beheerders betrokken zijn) lijkt me, zoals ik al gezegd heb, gewenst. Dan zet je de afspraken even op een A4-tje, zodat iedereen weet waar ze aan toe zijn.

              Een verbod op pentests voor software is zoiets als een verbod om remmen te testen bij een auto. (Je doet ook geen remmentest op een drukke snelweg.)

              1. Er is een verschil tussen het verbieden van een pentest door de leverancier van de software (niet gewenst) en het verbieden door degene die de software in productie heeft (wel gewenst).

                Natuurlijk moet de software goed getest worden maar niet zomaar door iedereen die (digitaal) langs loopt.

                Als je al een auto analogie wil doen, dan is het vergelijkbaar met dat ik niet wil dat je met mijn geleende auto een elandtest doet op de openbare weg. Dat laat ik liever aan professionals over die het op een gecontroleerde manier doen met een zelfde soort auto ipv met mijn auto.

                1. Analogieën zijn altijd gevaarlijk. Ik had er net ook eentje: mag de huurder van een woning zijn voordeurslot aan een inbraaktest onderwerpen? Het slot zegt immers politiekeurmerk++ en is volgens de documentatie bestand tegen diamantboren. En het raakt zijn veiligheid direct, want als die documentatie niet klopt dan wordt je huis leeggeroofd.

                  1. Zodra je redelijkerwijze kan vermoeden dat je schade gaat toebrengen zou het niet moeten mogen of ben je gewoon aansprakelijk voor de schade.

                    Je gaat toch ook niet je aardlekschakelaar testen door in bad te zitten en je broodrooster er in te gooien?

                    Producten testen op veiligheid doe je zorgvuldig en gecontroleerd en bij voorkeur door mensen die weten waar ze mee bezig zijn. Jouw slot kan je prima testen door een soortgelijk slot te kopen en die te testen.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.