Welke overeenkomst ? Natuurlijk mag je als bedrijf een bedrijfslaptop scannen op kwetsbaarheden. Je bent immers eigenaar van de apparatuur. En je bent verantwoordelijk voor de beveiliging van je IT infrastructuur. Geen overeenkomst voor nodig.

Indien het zou gaan om een privelaptop (bring your own device), dan is dit een vraagstuk.


Reden te meer om dit soort zaken in de gaten te houden.

Je mag je eigen computers op kwetsbaarheden scannen, een bedrijf mag dat ook doen.
Het bedrijf zal wel even na moeten gaan in hoeverre een dergelijke scan een inbreuk op de privacy van de werknemers kan zijn (ik verwacht "bijna niet") en proberen de gevolgen daarvan te minimaliseren. Een groter risico van zo'n scan is productieverstoring, het is verstandig om de werknemers te informeren.

Dat is zo'n beetje verplicht. Werknemers moeten het tevoren weten. Doe je het niet en er ontstaat een rechtszaak, dan de kans op verlies groot. Met name van toepassing als er de laptop ook voor privedoeleinden wordt gebruikt.

Volstrekte onzin. Je moet van te voren laten weten indien bijvoorbeeld email wordt gescreened. Het scannen op vulnerabilities heeft niets van doen met de privacy van de medewerker, en hoeft niet gemeld te worden. Ontstaat er een rechtzaak, dan win je deze zeker (of sterker nog, deze zal niet-ontvankelijk verklaard worden, omdat er simpelweg geen zaak is).


Geheel irrelevant, bij het scannen van de laptop op vulnerabilities.

Zo'n vulnerability scan kijkt naar instellingen en het al dan niet geïnstalleerd zijn van patches. De scanner kijkt niet naar data zoals bedrijfs- of privé-informatie.

Als je het goed doet kijk je ook naar remote access tools en file sharing programma's. Dat kan gevoelige informatie opleveren.

Volstrekte onzin. Als er gekeken wordt die kijkt of bijvoorbeeld shares te benaderen zijn is er sprake van een schending van de privacy als daar privemateriaal op staat. Hetzelfde met het onderscheppen van netwerkverkeer. Etc. etc.

Vroeger zeiden we dan "MISmanagement en WANbeheer".
Het was eigenlijk een inside grapje maar het beschrijft wel de situatie...

Hoe gaan we het doen met de "verplichte" virusscanners? Deze kijken ook naar elk bestand en zoeken soms zelfs online naar een checksum.

Gaat leuk worden bij het ACM als dit valt onder een data lek.

Mee eens. Er wordt geen data processed.

Inderdaad wat je zegt is volstrekte onzin. Er wordt niet gekeken naar wat er mogelijkerwijs in de data staat, maar welke vulnerabilities er worden geconstateerd. Sterker nog, indien de scan goed gedaan wordt, zal er inderdaad naar boven komen dat er open shares zijn en dat deze een risico vormen voor de omgeving.

Volstrekte onzin. Ik heb het niet over open shares gehad, maar over shares. Veel scanners proberen bijvoorbeeld automatisch een aantal wachtwoorden uit. Je projecteert je eigen geidealiseerde werkwijze en daar maak je een fatale vergissing dat je jezelf superieus waant en oncorrupteerbaar, want zo gaat het in werkelijkheid niet. Gebruikers gaan niet uit van jouw onkreukbaarheid. Alle scans zijn in principe privacy gevoelig als het over persoonlijke systemen gaat die mensen ook prive gebruiken. Dan kun je nog zoveel claims maken van het tegendeel. Dit is zoals het is. Als je zonder informeren scant bega je een fout.

Ja dat mag gewoon, zit geen juridische beperking op.

Daarnaast:

1. Stop met gebruik van local admin
2. Stop met gebruik van local admin
3. Stop met gebruik van local admin

Je kunt investeren tot je een ons weegt, maar als je systeem volledig toegankelijk is door de eindgebruiker (en dus ook voor alle bestanden en scripts die worden geactiveerd) heb je een verkeerde risico inschatting gemaakt.

P.s. had ik al gezegd dat je moet stoppen met het gebruik van local admin?

Ik ben programmeur en moet mijn device drivers debuggen en testen!

Ok, in het bericht geef je aan “de medewerkers zijn over het algemeen local admin”, derhalve mijn opmerking.

Aangepast advies:
- Ontwikkel in een afgesloten ontwikkelomgeving.
- Test in een afgesloten testomgeving.
- Accepteer in een afgesloten acceptatieomgeving.
- Stop het gebruik van local admin in productieomgeving.

;-)

Als ontwikkelaar heb ik geen toegang nodig tot de acceptatie- en productieomgeving. In de ontwikkelomgeving is het handig tot nodig om systeembeheerderstoegang te hebben, afhankelijk van waar je mee bezig bent en op welk platform. Op de testomgeving helpt het met debuggen als je daar toegang toe hebt als "applicatiebeheerder".

Het is juist HEEL BELANGRIJK dat jij jouw code test zonder admin rechten zodat dit testwerk niet
bij de klant komt te liggen. Met name bij hobbyistisch prutswerk zijn soms local admin rechten vereist
terwijl vergelijkbare professionele software daar geen last van heeft.

Dit is hetzelfde als "ik ben ontwikkelaar dus ik moet de snelste machine hebben die je kunt krijgen".
NEEEEE. Geef ontwikkelaars een langzaam apparaat zodat de klant goede performance op normale
hardware krijgt, en het broddelwerk van de ontwikkelaar niet verhuld wordt door zijn snelle machine.

Volstrekt irrelevant. Een vulnerability scan kijkt naar technische zwakheden, en niet naar de inhoud van je prive materiaal. Indien een medewerker vervolgens handmatig daarin kijkt is er een schending van de privacy; die handeling heeft echter *niets* van doen met vulnerability scanning, of vulnerability management. Wel met onprofessioneel gedrag, en integriteitsproblemen.

Ga je eerst eens verdiepen in de vraag wat vulnerability scanning is. Je kunt rustig scannen op vulnerabilities, zonder de gebruiker hierover te informeren. Ga je vervolgens grasduinen in hun data, dan schendt je hun privacy, en hebben ze zeker recht om te klagen. Echter heeft dat *niets* van doen met vulnerability management. Ook niet wanneer de medewerker, die de privacy schendt, anders zou pretenderen.

Blijkbaar iemand die ver van de werkelijkheid staat?
Er zijn soms hele goede business requirements voor local admin rechten. Sterker nog bij ons dit dit standaard. Aantal tickets is drastisch verlaagt sinds we dit hebben.

Je ontwikkeld op je eigen hardware/configuratie, maar je voert je tests uit op een acceptatie omgeving.

Auw.... Wat een denk fout zit hier in, duidelijk iemand die eigenlijk geen idee heeft hoe men effectie kan en moet werken...... Juist wel de snelste machine, want hoe langer een developer moet wachten, minder effectief hij is. Hij staat voornamelijk te wachten op zijn machine. Ik heb omgeving gezien, waar gewoon men ieder jaar de computers verving (of doorschoof), dat de ontwikkelaars de snelste machines hadden. Kon soms een uur je dag schelen in wachttijd, van laden en compile. Dat is in eens 2 dagen extra werk per maand.

En je test op development hardware als je geluk hebt een test omgeving, maar vaak maar met een hele kleine subset van data van de productie. Die is vaak helemaal niet gelijk aan de klant specificaties. Daar moet je dus wel heel goed over nadenken, en in je ontwikkel proces tijd en energie in steken.
Dit is echt een broddeladvies.

Nee, dat kun je rustig niet omdat je aan iemand zijn privedata komt. Of je dat met een tool doet of niet is irrelevant, je gaat rammelen aan de deur en je loopt binnen. Je zegt dat je doet met een blinddoek op. Daarvoor moet je tevoren gebruikers informeren. Het is echt niet zo moeilijk. Als je gebruikers niet informeert ben je niet goed bezig, je hebt dan onvoldoende inzicht in hoe de sociale verhoudingen liggen en de wet- en regelgeving.

Deel van de taak is te beoordelen of er sprake is van een datalek. Dat kan niet zonder te kijken. Als je niet kijkt ben je niet alleen niet professioneel, maar ook nog eens niet compliant. Gebruikers moeten altijd vooraf worden geinformeerd bij privacyzaken. Dus niet eerst scannen en dan informeren, maar eerst informeren en daarna scannen.

Wanneer je een device driver wilt vervangen in een draaiend systeem heb je daar systeembeheersrechten voor nodig. Ik geef toe dat een heleboel ander ontwikkel- en testwerk prima met normale gebruikerspermissies gedaan kan worden. (Ik verwacht dan wel dat de systeembeheerder mij een computer met alle benodigde tools geïnstalleerd levert!) Ik wil graag een VM om de installer op te testen.
Geef een ontwikkelaar een nette machine. (Ik merk dat een javac meer kloc/s doet dan een c++ compiler; wat netjes is is afhankelijk van computertaal en hoeveelheid code.) Zorg er voor dat performance tests op een relevant (niet bijzonder snel) systeem gedaan worden.

Je bereikt veel meer als je die developers die de hele tijd zitten te wachten op een compile vervangt door mensen
die eerst nadenken, dan code schrijven en aan het eind een compile doen waarbij het vrij snel goed is.
Met name die we-proberen-dit-eens-oh-nee-dat-werkt-ook-niet developers die kosten je bakken met geld!
Plus dat je met wat nadenken en ontwerpen een hoop fouten voorkomt die er door sluipen als je zo'n ridder van
de IDE als developer hebt. Die lui die denken dat je een programma foutloos kunt krijgen met testen een schaven.

Precies, om zo nu en dan een driver te testen heb je geen systeembeheer rechten nodig en al helemaal niet in je
login sessie. Dan start je een VM ofzo. Je gewone werk (editen, compileren, daarnaast browsen om dingen op te
zoeken doe je NIET met local admin rechten. gewoon NIET. doe je dat wel dan is dat gemakzucht en/of onkunde.

Verder is zijn het niet de goede developers die de hele dag aan het compileren en testen zijn. Je kunt beter eerst
nadenken dan achteraf tijdens testen alles goed moeten maken met vele compilatie slagen.

Dat is natuurlijk mogelijk. Maar dan moet jij wel al je tools laten packagen, zodat ze geïnstalleerd kunnen worden. Even een nieuwe tool die gemakkelijker werkt, dat is een nieuwe applicatie.

En verwacht dan ook niet dat je meteen de nieuwste en laatste versie hebt draaien.
Dat iedere update / service pack een (nieuwe/her/update) intake kan zijn, met de benodigde doorloop tijd. Terwijl jij er misschien op zit te wachten.

Dat is natuurlijk mogelijk... Maar heeft ook de nodige afhankelijkheden.

Goede mogelijkheid om te testen.

Je kunt C vrij snel zonder optimalisatie compileren. Dat is het probleem niet.

Pas bij een release compile met optimalisatie kost het veel tijd. Verder is het meer theorie dan werkelijkheid. Ik denk niet dat jij een developer bent.


Je kunt als gewoon gebruiker ook malware starten. Onder Windows werkt tegenwoordig niemand meer rechtstreeks als admin (want UAC). Vroeger, toen NT domeinbeheerders die met hun beheeraccount gingen browsen op een server terwijl Java geinstalleerd was, dat was een reëel risico: bemetting gegarandeerd. Ik heb destijds een paar virtuele tikken om de oren uitgedeeld. Onder Linux kan het wel nog zoals jij beschrijft.

Dat kun jij denken maar ik was al bezig met het maken van software toen er nog geen PC'tjes waren.
Mijn eerste software maakte ik op "schrapkaarten" (een soort ponskaarten) en die leverde je dan in en je kreeg een of
twee dagen later het resultaat. Weet je, dan leer je het op een andere manier. Dan leer je dat je eerst moet denken
over het probleem wat je wilt oplossen en dan pas aan het programmeren gaat. En als het resultaat niet klopt dan zet
je er niet blind ergens +1 bij en drukt op compile and run, maar dan ga je uitzoeken waarom het niet werkt.

Dat is ook hoe ik het (later) geleerd heb van mensen die in die tijd software development doceerden. Geen gepruts
om zichtbare probleempjes op te lossen maar nadenken over het algorithme en over loop-invarianten. Iets maken
waarvan het bij doorlezen duidelijk is waarom het wel of niet werkt, niet door het steeds maar te "testen".

Het werk wat ik de eerste jaren deed was op systemen waar echt niet genoeg capaciteit was om de hele dag te
compileren. Als je een "make" deed dan keek na een tijdje iedereen om omdat de editor trager was. Compilaties
van het hele pakket werden in de nacht gedaan.

Maar parallel daaraan ontstonden de eerste IDE's zoals UCSD Pascal, Turbo Pascal e.d.
Daar zag je een heel ander soort programmeur. Degene die twee of drie statements veranderde en weer compile
deed. En daar zat een totaal eigen soort bugs aan vast, want die mensen snapten niet dat je met testen nooit kon
garanderen dat een programma foutvrij is.

Jij informeert zeker iedere ochtend dat je naar kantoor komt. Voor het geval je daar wat gaat stelen, of de privacy van een collega gaat schenden. Nee, als je professioneel een vulnerability scan uitvoert, dan ga je *niet* grasduinen in enige prive data.


Tja, da's jouw mening. Je kan vervolgens wel iets roepen over wet- en regelgeving, maar er bestaan geen wetten en regels met deze verplichting. En sociale verhoudingen ? Als jij integer bent, kom je bij een vulnerability scan niet in prive gegevens van je collega. Ben je niet integer, dan kan je beter direkt ontslag nemen, nadat je dit gemeld hebt aan je collega's.

Onzin. Doel van een vulnerability scan is het vaststellen van technische kwetsbaarheden; niet het opsporen van datalekken.

Verdiep je eens in wat vulnerability scanning is, alvorens je met allerlij van dit soort incorrecte uitspraken komt.

Je kent het verschil tussen vulnerability scanning, pentesting, forensisch onderzoek ? Indien je in gebruikers data aan het grasduinen bent, dan ben je *niet* bezig met vulnerability scanning, je bent *wel* onprofessioneel, *niet* integer, en met compliancy heeft het niets van doen. Er bestaat geen compliancy framework wat zegt dat je bij vulnerability scanning moet gaan zitten grasduinen in data van collega's, om zodoende hun privacy te schenden.

Ga eerst eens in de praktijk je bezig houden met vulnerability management, en kom ons daarna maar vertellen hoe het zit. Ik ben er al jaren mee bezig, en het is mij duidelijk dat je nog nooit met vulnerability scanning bezig bent geweest, gezien het aantal foutieve aannames.

Onzin discussie dit.

Je druk maken om je privacy terwijl de meeste mensen local admin zijn.

De mens is de grootste veroorzaker van datalekken, geef ze daarbij ook nog eens local admin en ze kunnen zowel bewust als onbewust programma’s, backdoors en alle varianten van malware op systemen installeren.

Iets met risk management...

Succes met je privacy en beveiliging!

Mee eens.

Dus? Beide kunnen goed samen, en staat voor een gedeelte los van elkaar.

Natuurlijk... De mens maakt meestal foute configuraties of installeerd de updates niet.

Kan ook gebeuren zonder local admin rechten.

Juist... Goed definiëren, en uitwerken. Maar je vooral niet blindstaren.

Done.

MIS = "management information system";
WAN = "wide area network";

uitzonderingen daargelaten. Ik ben wel benieuwed waarom jij als programmeur device drivers moet debuggen? Tenzij je zelft schrijft kan je het ongetwijfeld in een virtual met escalated privileges die afgeschermd zijn voor de rest van de infrastructure?

User account = is NOOIT local admin. Ga anders eens met Emotet praten en vraag wat er bij een bedrijf gebeurt als er local admin accounts zijn en ze krijgen een infectie om hun oren?

Over een Vulnerabity assessment. Het melden hoeft te gebeuren bij een verwerking van gegevens. Een scan verwerkt geen gegevens maar controlleert een patch niveau tegen zijn eigen database. Het heeft helemaal niets te maken met opgeslagen data. Tenminste als wij het hier hebben over de default Nexpose, OpenVAS, of Nessus hebben.

Daarnaast is het zo dat een ieder die hier denkt dat er helemaal niets meer gezien/gecontrolleerd mag worden op data gebied echt van een koude kermis thuiskomt. Tenzij er aangegeven staat op een locatie dat het gaat om 'prive' data (in een outlook map bijv.) mag jij nog steeds heel veel. Het is en blijft company data op company assets en aangezien jij als security (red team) kan aantonen dat er een noodzakelijkheidsbeginsel is, kan je veel maken. Wel moet je zorg dragen voor reële bewaartermijnen.

Eminus

Dat jij mensen niet vertrouwt, wil nog niet zeggen dat ze de fout in gaan. Of dat de fouten die je noemt betrekking hebben tot werkzaamheden die vallen onder vulnerability scanning. Verder zou ik iemand die zich zo zou gedragen tijdens een vulnerability scan ontslaan, vanwege zijn gedrag.

Als ik jou was op je werk iedere keer dat je een ruimte in komt dit van te voren aankondigen. Zo kunnen jouw collega's, die niet uitgaan van jouw onkreukbaarheid, je tenminste in de gaten houden, om te kijken of je niets steelt. En of je zelf meent onkreukbaar te zijn, dat boeit kennelijk niet.

Je moet immers van het slechtste uit gaan ? ;)

Het zelfde kan gebeuren als je niet local admin bent.

Uit eindelijk komt er een rapport uit, wat bepaalde privacy / security informatie kan bevatten.

Dat kan je nog wel eens heel erg tegenvallen, zeker zonder goede meldingsplicht.

Vulnerability scanning, zelfs op BYOD devices met mogelijke prive data mag gewoon, mits:

- Je het doel duidelijk kunt verantwoorden.
- De communicatie duidelijk en helder is.
- Je niet meer persoonsgegevens registreert dan noodzakelijk
- Je de informatie niet langer bewaard dan noodzakelijk
- Je de informatie nadat deze niet meer noodzakelijk is, ook echt wist/onleesbaar maakt.
- Enz, enz.

In de gehele Privacy Wet staat niets over wat wel of niet mag, alles moet een relatie hebben tot het doel en het doel moet verantwoord kunnen worden.

Met in 2017 meer dan 14714 geregistreerde Vulnerabilities en de nummer 1 oorzaak van de in 2017 ontdekte datalekken, heb je wettelijk gezien al een hele goede verantwoording voor Vulnerability Scanning.