Juridische vraag: Is hoster ook eigenaar van applicatie?
Heb jij een uitdagende vraag over beveiliging, recht en privacy, stel hem aan ICT-jurist Arnoud Engelfriet en maak kans op zijn boek
"De wet op internet".
Arnoud is van alle markten thuis, maar vindt vooral in technische / hacking vragen een uitdaging. Vragen over licenties worden niet behandeld, aangezien die geen raakvlak met beveiliging hebben. De Juridische vraag is een rubriek op Security.nl, waar wetgeving en security centraal staan. Elk kwartaal kiest Arnoud de meest creatieve vraag, die dan zijn boek zal ontvangen.
Vraag: Een klant heeft me gevraagd om een securitytest op zijn webapplicatie uit te voeren. Daarbij wordt alleen gekeken naar de werking van de applicatie zelf: is deze gevoelig voor Cross-Site scripting of SQL injection en dat soort zaken. De site zelf wordt extern gehost. De vraag kwam naar boven of de applicatie nog steeds juridisch eigendom is van deze kennis, of dat deze eigendom is van de hoster. En als deze nog steeds eigendom is van de kennis, is het dan wel nodig om de toestemming van de hoster te vragen om dergelijke webapplicatie tests uit te voeren?
Antwoord: Een applicatie wordt geen eigendom van de hostingpartij alleen maar omdat die hem online zet. De (auteurs)wet bepaalt dat degene die de applicatie maakt, de eigenaar daarvan is. Dat is dus meestal het bedrijf zelf, hoewel het zomaar zou kunnen dat de ingehuurde freelancer eigenaar is van de applicatie en de opdrachtgever alleen een licentie (gebruiksrecht) heeft. De applicatie is dus alleen "van de hoster" als deze de applicatie gebouwd heeft, en dat lijkt me een uitzonderlijke situatie.
Hoe dan ook, een securitytest uitvoeren op een hosted applicatie lijkt me iets om niet te doen zonder de hoster in te lichten. Dat heeft niets te maken met eigendom maar met gewone voorzichtigheid. Licht je hem niet in, dan is de kans groot dat je securitytest bij hem alarmbellen laat afgaan. Hij kan bv. screenen op bepaalde code die via de webserver binnenkomt, op bepaalde types requests enzovoorts.
Krijgt hij zo'n alarm, dan staat hij in zijn recht om maatregelen te nemen om de 'aanval' af te weren. Hij weet immers niet dat het een test is, en heeft de zorgplicht om aanvallen op zijn klanten te verhinderen voor zover dat binnen zijn macht ligt. De site zou dan ook zomaar ineens op zwart kunnen gaan, of je wachtwoorden gewijzigd, of je database op read-only. Ik denk niet dat je daarop zit te wachten. En op een aangifte van computervredebreuk al helemaal niet.
Ik zou als securitytester dus nooit zo'n test uitvoeren zonder schriftelijke verklaring van de opdrachtgever dat a) hij de hoster en andere relevante partijen heeft ingelicht, b) hij mij vrijwaart van alle schadeclaims van iedereen die last heeft van mijn test en c) hij al het mogelijke gaat doen om mij vrij te krijgen (en mijn computers terug) als mijn test tot arrestatie/vervolging wegens computervredebreuk leidt.
Arnoud Engelfriet is ICT-jurist, gespecialiseerd in internetrecht waar hij zich al sinds 1993 mee bezighoudt. Hij werkt als partner bij juridisch adviesbureau ICTRecht. Zijn site Ius mentis is één van de meest uitgebreide sites van Nederland over internetrecht, techniek en intellectueel eigendom. In 2008 verscheen zijn boek "De wet op internet".
Tenzij je een blackbox test uitvoert, maar dan kun je beter een simulatie van de omgeving maken en daarop de applicatie gaan penetreren. Een hoster zal namelijk in 99% van de gevallen niet akkoord gaat met een online blackbox pentest tenzij de opdrachtgever de hoster zelf is
Een ander puntje waar je op moet letten is het volgende: stel dat de applicatie eigendom is van een derde partij maar jou opdrachtgever een licentie heeft bij die partij en gebruik maakt van hun software en deze wil laten testen. In dat geval zou je naar lekken kunnen zoeken in die applicatie (officieel zelfs strafbaar volgens mij, maar wat niet weet wat niet deert) Als je dan een lek gevonden hebt dan zou je deze kunnen melden bij jou opdrachtgever maar absoluut niet bij de vendor (je zult waarschijnlijk een geheimhoudingsverklaring hebben getekend met je opdrachtgever en deze staat niet toe dat je de vendor inlicht. Het is een moeilijk punt omdat de vendor een patch uit kan brengen die alle andere gebruikers beschermd, maar door jou contract met je opdrachtgever is dat dus niet mogelijk ...
Nogmaals gewoon om de sourcecode vragen, dat is wel zo makkelijk dan ben je de hosting partij iig kwijt in het verhaal
Maar zoals arnoud zegt je hoster is nevernooit eigenaar tenzij je een product van hen koopt.
Maar wie eigenaar is heeft niks te maken met wie je moet inlichten.
Je moet je hoster en de gene die het gemaakt heeft (mogelijk) inlichten afhankelijk wat je gaat doen.
code lezen moet je de maker inlichten of dat mag want het is zijn eigendom.
De hoster moet je inlichten voor pentesting
...wat bij een willekeurige hoster in de AV staat. Dat kun je ook van buiten naar hen toe vertalen. Kortom, duik inderdaad even in de voorwaarden en geef zeker een seintje. Kan me voorstellen dat als je een rack/firewall omver trekt of overhead-activiteiten veroorzaakt dat ze niet blij gaan zijn.
Dat zou kunnen wanneer het gaat om application hosting, waarbij je dus niet alleen de server en/of rackspace huurt, maar waarbij de applicatie zelf ook door de hoster wordt geleverd. Indien je klant zelf de applicatie heeft geschreven of gekocht, dan is hij natuurlijk ten alle tijde zelf eigenaar.
Maar zoals arnoud zegt je hoster is nevernooit eigenaar tenzij je een product van hen koopt.
Maar wie eigenaar is heeft niks te maken met wie je moet inlichten.
Je moet je hoster en de gene die het gemaakt heeft (mogelijk) inlichten afhankelijk wat je gaat doen.
code lezen moet je de maker inlichten of dat mag want het is zijn eigendom.
De hoster moet je inlichten voor pentesting
zo te zien mag jij nog een terug naar school, want je hebt er totaal geen kaas van gegeten.
Ik zou iig nooit mijn apps bij jou laten controleren omdat jij een pentest uitvoert terwijl er jou gevraagd wordt een app te auditen. Iets wat totaal verschillende dingen zijn, in dit geval vraagt met om o.a. SQL injection te zoeken in een. wtf zou jij dan een pentest uitvoeren, als je toegang hebt tot de source? dat is echt het meeste domme wat ik ooit gehoord heb.
Vervolgens zitten er wel degelijk haken en ogen aan de eigenaar van de software, je mag namelijk niet zomaar bugs gaan zitten zoeken in een applicatie, in sommige landen is dat strafbaar en in nederland is het net wel of net niet strafbaar (dat kun je beter aan arnoud vragen) Feit blijft wel het bedrijf een overeenkomst heeft met de eigenaar van de software en jij als source auditer/pentester een overeenkomst met de gebruiker van de software.
Bij sourcecode-audit hoeft je de hoster niet in te ligten terwijl je het zelfde doel na streeft, men wil opzoek naar SQL injection dus download men de source en gaat deze auditen, vervolgens schrijft men een rapport en levert dat op aan de opdrachtgever. Wanneer jij gaat pentesten ga je o.a. de services op de machines van de hoster penetreren iets wat je wel degelijk moet afstemmen met de hoster omdat het zo kan zijn dat bepaalde applicatie stoppen met functioneren wanneer schadelijke code toestuurt, helemaal wanneer je besluit de aanwezig applicatie nog even te fuzzen met een leuk dataset. Gezien je de basis nog niet kent zal dit wel te hoog gegrepen voor je zijn ...
1. een vrijwaringsbewijs waar in de eigenaar van de applicatie / website aangeeft dat hij niet alleen aangeeft dat hij accoord gaat maar waarin ook staat opgenomen dat:
- de periode dat de k.a. wordt uitgevoerd
- om welk IP adres of range het gaat
- dat zij onderschrijven het risico te onderkennen die met een K.A. of penetratietest gepaard kan gaan (dus dat bij het eventueel down gaan eventuele kosten niet kunnen worden verhaald op uitvoerende partij) Het liefste van de applicatie owner bij opdrachtgever dus niet alleen de IT afdeling (bijvoorbeeld bij banken
2. Een vrijwaringsbewijs / accoord van de ISP/Hoster. het liefst ondertekent bij de verantwoordelijke bij de hoster en niet een gewone medewerker
Verstandig is ook in je leveringsvoorwaarden het e.e.a. mee tenemen en te deponeren bij de KvK.
Hou een log bij van tijden dat de K.A. of penetratietest plaatsvind, wat je op dat moment aan het doen was en welke tooling je gebruikte EN niet onbelangrijk vanaf welk IP adres of adressen de K.A. werd uitgevoerd.
Better safe than sorry. ook oogt het wat professioneler als het er uit ziet dat je nagedacht hebt over die zaken.
interessanter wordt als er meerdere providers betrokken zijn bij een webapplicatie....maar dat is een ander verhaal.
TH
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
