Hoe dader identificeren op bedrijfsnetwerk?

[houwimmie]

Zojuist meldde een inspecteur van de politie zich aan de receptie van het bedrijf waarvoor ik werk.
Iemand zou vanop ons netwerk strafbare feiten hebben gepleegd op het internet. Op zich hoef ik niet in detail te gaan, de probleem beschrijving is vrij generiek.

Alle syslog events die worden gegenereerd op onze Cisco ASA firewalls worden bijgehouden.
Daarin staat tijdstip, source, destination en poort. Tot op de dag van vandaag gebuikte ik de syslog messages enkel voor troubleshooting en hield niets langer bij dan een maand.

De strafbare feiten speelden zich blijkbaar 4 maanden geleden af...volgens de inspecteur duurt het soms wel meer dan een half jaar vooraleer men het nodige papierwerk heeft om een onderzoek te starten.
Goed, ik zou mijn syslog messages een jaar kunnen bijhouden, maar aan 2-3 GB per dag tikt dat aardig aan.
Hoe pak ik dit best aan? Syslog messages comprimeren of opschonen? Manueel of automatisch? Bestaat er software die dit kan automatiseren?

Een bijkomend probleem is dat een intern IP niet statisch is. Een interne laptop gebruiker krijgt vandaag via DHCP een IP adres A, morgen kan dat IP adres B zijn.
Het MAC adres blijft wel statisch, kan ik dit op een of andere manier loggen? Mogelijks op onze Cisco switches?
We gebruiken ook Citrix, op elke server zijn meestal makkelijk 20 concurrent users actief.
In dat geval ben ik met een MAC adres niets

Feit is dat ik de inspecteur vandaag niet heb kunnen helpen, de inbreuken waren niet al te zwaar..ik denk dat men het hier bij laat vandaag.
Ik wil natuurlijk wel voorbereid zijn voor mogelijkse toekomstige voorvallen.

Hoe loggen jullie alles? Hoe zouden jullie met zulke vragen omgaan?

Thx !!

[Gomez12]

Allereerst zou ik de vraag omkeren tegenover de politie agent over wat hun adviseren.

Want simpelweg alles maar opslaan over het afgelopen half jaar dan stuit je al heel snel tegen AvG maar ook simpelweg privacy regels aan. Mensen mogen een bepaalde vrijheid en privacy hebben.

Wat ik onder andere bij de politie zou neerleggen is : Wat gebeurt er als jij niemand kan aanwijzen, is dan jullie bedrijf verantwoordelijk (omdat het over jullie lijn ging) of is er opeens niemand verantwoordelijk meer?
En wat ik al zeg, laat hem maar een voorbeeld opzet geven van hoe je hier tussen de wens van de politie en AvG en privacy wetgeving heen kan laveren.
En wat wenst de agent te ontvangen, want zoals je zelf al zegt zegt een source-ip zo goed als niets bij citrix/laptops op dhcp. Dan moet je dat dus weer gaan koppelen aan inlogs in je AD etc.

En ook iets als een destination ip zegt op zichzelf bijna niets. Wat is de hostnaam waarmee je verbinding probeert te maken en het echte adres?

[MAX3400]

Hoort dit niet bij het beleid wat ICT moet uitvoeren?

Oftewel, wat vindt de directie / OR van het bezoek van de inspecteur en welke zaken zijn er op ICT-gebied dus wel/niet voor herziening vatbaar?

[BCC]

Vast wel, maar als bestuurder zou ik het direct omdraaien: Wat adviseer je ons in deze, beste hoofd-ict?

[Predator]

Logging is overal een probleem. Het neemt massa's plaats in, en afhankelijk van de omgeving neemt het ook resources weg.

Je moet met de GDPR regelgeving ook alle logging opnemen in je dataregister, de toegang tot logfiles beschrijven, en eventuele tools voor auditoren beschikbaar stellen (indien mogelijk).

Hoelang je iets kan en wil bijhouden is meestal een praktisch gegeven. Alle internet toegang van alle gebruikers loggen is vaak niet haalbaar voor langere periodes door de massa's aan data, die je dan ook nog eens off-box moet veilig opslaan en backup'n.

Ik vind het eigenlijk wel grappig die inspecteur zelf aangeeft dat 4 maand termijn voor een onderzoek normaal is. Volgens de nieuwe camerawet (België, maar NL zal vergelijkbaar zijn) is de opslag van camerabeelden beperkt tot maximum 30 dagen ...

[MAX3400]

BCC schreef op maandag 11 juni 2018 @ 13:21:
Vast wel, maar als bestuurder zou ik het direct omdraaien: Wat adviseer je ons in deze, beste hoofd-ict?

Een ICTer heeft geen mandaat om gegevens vast te leggen voor welke reden dan ook. Zeker niet als het gaat om herleidbare gegevens voor, in dit geval, een politie-onderzoek.

Directie moet mandaat en regelgeving (inclusief auditing) formuleren en ICT krijgt dan tijd en geld om het uit te voeren.

[houwimmie]

MAX3400 schreef op maandag 11 juni 2018 @ 13:27:
[...]
Directie moet mandaat en regelgeving (inclusief auditing) formuleren en ICT krijgt dan tijd en geld om het uit te voeren.

Dat mandaat heb ik, de middelen ook. Het was de Corporate Director ICT die bij me kwam aankloppen om de logging op te vragen. Als hij iets beslist (althans op zijn vakgebied) dan schaart meteen heel het management zich achter hem. In de arbeidsovereenkomst die elke werknemer tekent vooraleer bij ons aan de slag te gaan, staat duidelijk dat elke actie op onze computersystemen kan worden gemonitord om de integriteit van de systemen te waarborgen en misbruik te kunnen tegengaan.

Predator schreef op maandag 11 juni 2018 @ 13:22:
Ik vind het eigenlijk wel grappig die inspecteur zelf aangeeft dat 4 maand termijn voor een onderzoek normaal is. Volgens de nieuwe camerawet (België, maar NL zal vergelijkbaar zijn) is de opslag van camerabeelden beperkt tot maximum 30 dagen ...

Daar heb je zeker een punt, maar dat is ook letterlijk wat hij zei

[TommyboyNL]

Wat betreft historische logging aan users koppelen: Producenten van échte firewalls (Check Point, Fortinet, en vast nog heel veel meer) hebben ondersteuning voor Identity Awareness achtige zaken. Op die manier worden je log entries niet alleen voorzien van source IP/port, maar ook source user. Wellicht de moeite waard om naar te kijken.
Verder heb je vooral eerst een hoop beleidszaken om uit te zoeken en af te spreken met de mensen hogerop, alvorens na te denken over technische oplossingen.

[F_J_K]

Predator schreef op maandag 11 juni 2018 @ 13:22:
Volgens de nieuwe camerawet (België, maar NL zal vergelijkbaar zijn) is de opslag van camerabeelden beperkt tot maximum 30 dagen ...

offtopic:
Aan het taalgebruik van de TS (een NL inspecteur zal niet voor zoiets komen opdraven, dat is een hogere rang dan in BE) te zien is het Belgie.
@houwimmie heb ik dat goed gezien? Kan wellicht van belang zijn voor de wettelijke kaders, al is de GDPR vanuit haar aard voor beide landen gelijk.

Vraag 1 is wel er concreet bewaard moet worden. 'Alles van iedereen, inclusief de berichtinhoud' lijkt me niet aan de orde. Alleen IP's is zinloos, etc.
Ook een MAC adres op zich zegt niet alles, zelfs niet op individuele devices. Username lijkt me veruit het meest relevante - zie ook hierboven. Maar is de enige reden van loggen om mee te werken aan dat ene politie-onderzoek per bijv. 10 jaar?

[houwimmie]

@F_J_K klopt, het gaat over België.

Het is inderdaad niet de bedoeling om de volledige berichtinhoud bij te houden, vermoedelijk is dat in BE niet eens toegestaan.

Hoe ik de username kan loggen moet ik even bekijken. Ik vermoed dat dit op een moderne Cisco ASA wel moet kunnen, heb er alleen tot nu toe nog geen ervaring mee.

Uiteraard wil ik dit niet allemaal opzetten om eens in de 10 jaar te kunnen meewerken aan een onderzoek. Ik werk voor een beursgenoteerde multinational met enkele duizenden werknemers. Zulke vragen komen heus wel vaker voor en dat zal in de toekomst (als gevolg van de snelle groei die onze firma) zeker nog meer voorvallen..dit was wel de eerste keer dat me persoonlijk de vraag wordt gesteld en het belang zo hoog was.

[DJMaze]

houwimmie schreef op maandag 11 juni 2018 @ 12:38:
Zojuist meldde een inspecteur van de politie zich aan de receptie van het bedrijf waarvoor ik werk.
Iemand zou vanop ons netwerk strafbare feiten hebben gepleegd op het internet. Op zich hoef ik niet in detail te gaan, de probleem beschrijving is vrij generiek.

De strafbare feiten speelden zich blijkbaar 4 maanden geleden af...volgens de inspecteur duurt het soms wel meer dan een half jaar vooraleer men het nodige papierwerk heeft om een onderzoek te starten.
Goed, ik zou mijn syslog messages een jaar kunnen bijhouden, maar aan 2-3 GB per dag tikt dat aardig aan.

Eigenlijk vind ik de misdaad best een essentieel gegeven.
Als diegene bijvoorbeeld een SSH Brute Force attack heeft gedaan kan je de firewall daar prima op inregelen.
Als diegene chinese ray ban zonnebrillen met 80% korting verkocht of geweren via een anoniem forum, dan wordt het inderdaad lastig en zou logging een manier zijn.
Als diegene via HTTPS een SQL exploit heeft uitgevoerd kom je er toch niet achter mits je een MitM plaatst.

Het is dus gewoon afwegen hoe je wat doet en of het überhaupt relevant is.

Je zou ook kunnen overwegen om alleen unieke DNS en externe IP's te loggen per dag en welke interne PC's dat deden. Dan weet je nog steeds niet precies wie, maar neem aan dat niet alle 1000 medewerkers de zelfde externe IP's bezoeken.

[ Voor 8% gewijzigd door DJMaze op 11-06-2018 16:10 ]

[TommyboyNL]

houwimmie schreef op maandag 11 juni 2018 @ 15:19:
@F_J_K klopt, het gaat over België.
Ik werk voor een beursgenoteerde multinational met enkele duizenden werknemers. Zulke vragen komen heus wel vaker voor en dat zal in de toekomst (als gevolg van de snelle groei die onze firma) zeker nog meer voorvallen..dit was wel de eerste keer dat me persoonlijk de vraag wordt gesteld en het belang zo hoog was.

Oef, zo'n groot bedrijf en dan zó weinig/slecht loggen? Wees blij dat je geen forensisch onderzoek hebt hoeven doen na een breach, dan ben je écht de sjaak.
Mijn advies zou zijn om hier HEEL snel werk van te maken, maar dat is wellicht wat gekleurd omdat ik in de securitybranche werk.

[Predator]

TommyboyNL schreef op maandag 11 juni 2018 @ 17:10:
[...]

Oef, zo'n groot bedrijf en dan zó weinig/slecht loggen? Wees blij dat je geen forensisch onderzoek hebt hoeven doen na een breach, dan ben je écht de sjaak.
Mijn advies zou zijn om hier HEEL snel werk van te maken, maar dat is wellicht wat gekleurd omdat ik in de securitybranche werk.

Dat is zeer kort door de bocht. Als je geen authentificatie op je uitgaande HTTP(s) verkeer doet, dan is de waarde van die informatie niet zo groot. Uiteraard kan je de informatie uit je DCs halen (zoals je bv de Identity awareness blade van Checkpoint noemt), maar zo'n dingen zijn niet voor iedereen haalbaar. Denk je dat een dergelijke setup gaat zien in een KMO ? Die vallen nochtans onder exact dezelfde GDPR wetgeving ...
Wil je ook alle requests correct loggen, dan moet je ook al je HTTPS inspecteren, wat weer extra load op je firewalls en/of proxy servers geeft.

Je opmerking van onderzoek bij een breach is hier niet van de toepassing. De breach zit niet bij hem, maar ergens anders. Het gaat om uitgaande requests vanuit het netwerk beheert door de TS. Dat zijn 2 verschillende zaken.

Heel dit verhaal is juist wat me zoveel ergert in heel deze nieuwe actualiteit rond privacy en security ivm de GDPR normen. Je dient een breach te detecteren, melden, aan te tonen hoe de breach veroorzaakt is.
Dat betekent erg veel logging, op alle niveau's. Maar dan moet je volgens diezelfde regels ook al die info in je dataregister uitgebreid documenten en terug verdedigen waarom je al die persoonsgegevens in de eerst plaats bijhoudt !
In het eerste geval ben je prutser die geen security heeft, en in het 2de geval de grote BOFH die iedereen bespioneert....

Maar de politie vindt het wel prima van 4 (!!!) maand later onderzoek te doen, terwijl je als bedrijf wel slechts 72 uur hebt om een breach te melden. Wat een nonsense

In the case of a personal data breach, the controller shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the supervisory authority competent in accordance with Article 55, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons. 2Where the notification to the supervisory authority is not made within 72 hours, it shall be accompanied by reasons for the delay.

[TommyboyNL]

Predator schreef op maandag 11 juni 2018 @ 17:29:
--Veel--

Voor KMO/MKB is dit inderdaad niet haalbaar. TS geeft echter aan voor een naar BeNeLux maatstaven groot bedrijf te werken. Dan is het plotseling een heel ander verhaal. Op die schaal moet je gewoon goed loggen in combinatie met Identity Awareness (laten we dat even gebruiken als algemene naam), en HTTPS inspectie toepassen. HTTPS inspectie hoef je niet per sé op je firewall te doen, maar daar kan je ook een proxy server voor inzetten (welke je naar mijn mening óók dient te hebben).
Een favoriete entry point van malware is tegenwoordig privémail die mensen via webmail op hun werk openen. Als je dat niet al bij de poort kan scannen (of helemaal blokkeren), sta je meteen 1-0 achter.

[Verwijderd]

"In de arbeidsovereenkomst die elke werknemer tekent vooraleer bij ons aan de slag te gaan, staat duidelijk dat elke actie op onze computersystemen kan worden gemonitord om de integriteit van de systemen te waarborgen en misbruik te kunnen tegengaan."

In Nederland zou dit punt een juridisch ding kunnen worden omdat het grootschalig bijhouden van internet gebruik een inbreuk is op de privacy van de werknemer zonder vooraf kennisgeving en voor een langdurige periode.

[Verwijderd]

houwimmie schreef op maandag 11 juni 2018 @ 12:38:
De strafbare feiten speelden zich blijkbaar 4 maanden geleden af...volgens de inspecteur duurt het soms wel meer dan een half jaar vooraleer men het nodige papierwerk heeft om een onderzoek te starten.

Simpelgezegd: Dat is hun probleem. Ik ben echt niet bereid om jarenlang gegevens bij te houden omdat er mischien ooit wel eens iemand van de politie zou kunnen komen aankloppen. Het is hun taak om bewijs te leveren, en je zou zelfs kunnen zeggen dat logs ophoesten telt als "meewerken aan eigen veroordeling". Dit nog naast de verdere wettelijke eisen om juist niet teveel en niet te lang te bewaren.

Goed, ik zou mijn syslog messages een jaar kunnen bijhouden, maar aan 2-3 GB per dag tikt dat aardig aan.
Hoe pak ik dit best aan? Syslog messages comprimeren of opschonen? Manueel of automatisch? Bestaat er software die dit kan automatiseren?

Natuurlijk. En als niet dan bouw je het zelf. Daar ben je automatiseerder voor.

Een bijkomend probleem is dat een intern IP niet statisch is. Een interne laptop gebruiker krijgt vandaag via DHCP een IP adres A, morgen kan dat IP adres B zijn.
Het MAC adres blijft wel statisch, kan ik dit op een of andere manier loggen? Mogelijks op onze Cisco switches?

De uitgegeven leases kun je natuurlijk bijhouden, evenals de loginnamen en vanaf welke IPadressen dat gebeurd is. (Je bent chef netwerk en je weet niet hoe dat werkt? Wat?)

Ik wil natuurlijk wel voorbereid zijn voor mogelijkse toekomstige voorvallen.

Kun je helder uitleggen waarom?

Hoe loggen jullie alles? Hoe zouden jullie met zulke vragen omgaan?

Ik log precies dat wat ik zelf nodig acht en als ik dat moet ophoesten doe ik dat. Andermans eventualiteiten zijn niet mijn probleem. Is er acuut iets dan kan ik natuurlijk wel de logging opschalen en zelfs alerts zetten om er snel achter te komen als er weer iets gebeurt. Maar of ik dat blijf doen nadat de dader gevonden is is nog maar helemaal de vraag.

Achtergrond: Ik was ooit sys/net/etc.-beheerder bij een bedrijf met een hoop vrijgevochten nerds; dat moet je vrij hands-off doen want anders gaan ze kakelen over onderdrukking en censuur enzo. Niet helemaal onterecht maar soms wat overtrokken. Meer in het algemeen kun je stellen dat teveel opslaan zijn eigen risicos meedraagt ("data is toxic" dixit Bruce Schneier) dus daar moet je duidelijke keuzes maken op duidelijke gronden. "Nou eventueel mischien ooit" of zelfs "voor de volgende mogelijke keer" is niet echt duidelijk. Als er NU iets aan het handje is dan natuurlijk, maar mischien, nee.

houwimmie schreef op maandag 11 juni 2018 @ 15:19:
Uiteraard wil ik dit niet allemaal opzetten om eens in de 10 jaar te kunnen meewerken aan een onderzoek. Ik werk voor een beursgenoteerde multinational met enkele duizenden werknemers. Zulke vragen komen heus wel vaker voor en dat zal in de toekomst (als gevolg van de snelle groei die onze firma) zeker nog meer voorvallen..dit was wel de eerste keer dat me persoonlijk de vraag wordt gesteld en het belang zo hoog was.

Zelfs dan. Voorbeeldje: De banken hebben zich laten verleiden te verworden tot grote datapijp naar de macht toe dmv "ongewone transacties rapporteren", KYC/AML/..., en dat kost bijvoorbeeld de ABN 60 mio/jaar (bron: verhaal ABN op de recente privacy/security meet-up), terwijl het enige wat het echt doet is klanten wegjagen, en echt niet alleen maar "terroristen" (die toch al hun eigen financieele en andere dienstverlening hebben). Dat is dus netto vooral verlies, en is een langzaamaan steeds duurder wordende "cost of doing business" die makkelijk voorkomen had kunnen worden als ze op tijd hun poot stijf gehouden hadden. Met een heel simpel "als er nou echt wat is, dan natuurlijk, maar niet speculatief."

Dus nog steeds, ik zou echt alleen maar loggen wat ik zelf nodig heb en wat er op dit moment speelt. De recherche zorgt maar dat ze hun papieren bijtijds op orde hebben en dan mogen ze me gelijk bellen dat ik begin met loggen, maar voordien hou ik daar echt geen rekening mee. Jammer joh.

Bij een grootbedrijf komt daar dan nog een ronde "compliance" overheen, en eventueel het aanpassen van het gebruiksreglement en weet ik het, maar dat is de essentie. Meestal staat er iets als "wat nodig is" dus bij iedere (tijdelijke) opschaling moet je alweer een duidelijk verhaal hebben waarom dan. Doe je dat niet dan is dat een tweevoudige zwakheid: Log je teveel dan is dat een overtreding cq inbreuk op privacy en log je "want makkelijk" of "want eventualiteit" dan is er de verwachting dat je dat blijft doen. En als die twee samenkomen zit jij dubbel knel. Vandaar dus de focus op "wat jij nodig hebt", niets meer en niets minder.


Samenvattend: Zorg dat je een duidelijk en helder verhaal hebt wat je waarom en wanneer wil loggen. En dan doe je precies dat.

[DiedX]

Interessante vragen, ook vanuit AVG / Bedrijfsstandpunt.

Als eerste: 5 * 365 = 1825 GB per jaar. Als je een servertje ophangt met daarop Linux, rsyslog en 2 x 2 TB Schijven heb je je loghost in orde (daarop doe je alléén loggen, niet inloggen met SSH, gewoon laten loggen)

Stap 2: álles luistert naar je NTP-server op je AD-servers. Óok je switches en routers, anders ben je dagen bezig om time-skew recht te trekken

Stap 3: proxy installeren, alles loopt alleen daar over heen. De rest dichttimmeren.

Vervolgens krijg je wél een juridische vraag. Ik ben van mening dat je een boel mag loggen - ZOLANG MENSEN DAARVAN OP DE HOOGTE ZIJN. De vraag is of je het moet willen, en hoe ver je daar in gaat, en hoe lang je het op slaat...

Já, je kan MitM SSL-interceptie doen op je proxy, maar wíl je dat écht? Zou jij willen dat bankzaken in je logs terecht komen? Die discussie moet je doen met een grote partij mensen.

[TommyboyNL]

DiedX schreef op maandag 11 juni 2018 @ 18:15:
Já, je kan MitM SSL-interceptie doen op je proxy, maar wíl je dat écht? Zou jij willen dat bankzaken in je logs terecht komen? Die discussie moet je doen met een grote partij mensen.

Ja, dat wil je écht. Anders kan je net zo goed niet filteren. Een significant deel van het internetverkeer gaat tegenwoordig over SSL.
Je kan er overigens zeker van zijn dat als je SSL inspectie laat inrichten door iemand die dat vaker doet, één van de eerste vragen zal zijn wat er NIET geïnspecteerd mag/moet worden. Meestal gaat het dan om banking/financial en health.

[DiedX]

TommyboyNL schreef op maandag 11 juni 2018 @ 18:43:
[...]

Ja, dat wil je écht. Anders kan je net zo goed niet filteren. Een significant deel van het internetverkeer gaat tegenwoordig over SSL.
Je kan er overigens zeker van zijn dat als je SSL inspectie laat inrichten door iemand die dat vaker doet, één van de eerste vragen zal zijn wat er NIET geïnspecteerd mag/moet worden. Meestal gaat het dan om banking/financial en health.

Maar dan noem je er ook 3. We wéten niet welk bedrijf TS voor werkt. Voor health en banken lijkt het mij verplicht om SSL-interceptie te doen, maar als ik hoor dat er géén logging is, dan zie ik SSL-interceptie ook nog niet gebeuren....

[HyperBart]

Zeg maar draai het eens even om, als er een inspecteur bij je aan de deur staat is het toch "erg genoeg" om gewoon een block er op te gooien, niet? Als er een block op staat ga je snel genoeg hits op die rule zien en het bijhouden van die logs is bijgevolg ook niet zo zwaar. Een beetje next-gen firewall kan dit toch.

[Gomez12]

Verwijderd schreef op maandag 11 juni 2018 @ 18:00:
[...]

Simpelgezegd: Dat is hun probleem. Ik ben echt niet bereid om jarenlang gegevens bij te houden omdat er mischien ooit wel eens iemand van de politie zou kunnen komen aankloppen. Het is hun taak om bewijs te leveren, en je zou zelfs kunnen zeggen dat logs ophoesten telt als "meewerken aan eigen veroordeling". Dit nog naast de verdere wettelijke eisen om juist niet teveel en niet te lang te bewaren.

Tja, dat is heel leuk en populistisch gezegd, maar veelal heeft de politie zijn bewijslast wel op orde hoor.
En als jij ze niet verder kan helpen dan blijven ze dus hangen op het feit dat jouw bedrijf die overtreding heeft begaan. En of je dat nu moet willen...

Dus nog steeds, ik zou echt alleen maar loggen wat ik zelf nodig heb en wat er op dit moment speelt. De recherche zorgt maar dat ze hun papieren bijtijds op orde hebben en dan mogen ze me gelijk bellen dat ik begin met loggen, maar voordien hou ik daar echt geen rekening mee. Jammer joh.

Jammer voor het bedrijf bedoel je, want die heeft zijn logging niet op orde. Waardoor die de boete niet kan doorgeven en bij het bedrijf blijft liggen.

DiedX schreef op maandag 11 juni 2018 @ 18:15:
Als eerste: 5 * 365 = 1825 GB per jaar. Als je een servertje ophangt met daarop Linux, rsyslog en 2 x 2 TB Schijven heb je je loghost in orde (daarop doe je alléén loggen, niet inloggen met SSH, gewoon laten loggen)

Yikes, ik dacht dat we in PNS zaten en niet in hobby networking & servers, dit is dus geen loghost op orde hebben. Dit is gewoon ergens wat hardware neerdumpen en bidden dat het blijft werken.

Je moet het zooitje nog backuppen, je moet het zooitje nog fatsoenlijk ontsluiten en testen, je moet er nog monitoring op plaatsen etc etc etc.

TommyboyNL schreef op maandag 11 juni 2018 @ 18:43:
[...]
Je kan er overigens zeker van zijn dat als je SSL inspectie laat inrichten door iemand die dat vaker doet, één van de eerste vragen zal zijn wat er NIET geïnspecteerd mag/moet worden. Meestal gaat het dan om banking/financial en health.

En een beetje serieus persoon zal je vertellen dat dat niet uitgefilterd kan worden en dat je dat dus of meekrijgt of je moet besluiten geen MitM te doen.

Een paar "blacklists" met banken /financial en health institutes betekent totaal niet dat je het niet meer inspecteert hoor. Je inspecteert het hooguit niet meer voor die partijen.
Filterlijsten bestaan er al sinds het begin van het internet en het effectieve nut ervan is altijd nul geweest qua bewust misbruik.

[TommyboyNL]

Gomez12 schreef op maandag 11 juni 2018 @ 20:17:
En een beetje serieus persoon zal je vertellen dat dat niet uitgefilterd kan worden en dat je dat dus of meekrijgt of je moet besluiten geen MitM te doen.

Een paar "blacklists" met banken /financial en health institutes betekent totaal niet dat je het niet meer inspecteert hoor. Je inspecteert het hooguit niet meer voor die partijen.
Filterlijsten bestaan er al sinds het begin van het internet en het effectieve nut ervan is altijd nul geweest qua bewust misbruik.

Dat kan prima. Als je proxy server een verzoek krijgt voor https://www.randombank.nl/ kan hij prima besluiten om voor die datastroom de SSL interceptie uit te schakelen. De lijsten voor de relevante categorieën zijn naar mijn ervaring uitstekend; alle Nederlandse banken staan er bijvoorbeeld in, net als elke zorgverzekeraar die ik maar kon bedenken.

[Gomez12]

TommyboyNL schreef op maandag 11 juni 2018 @ 20:24:
[...]
De lijsten voor de relevante categorieën zijn naar mijn ervaring uitstekend; alle Nederlandse banken staan er bijvoorbeeld in, net als elke zorgverzekeraar die ik maar kon bedenken.

Lol, ik vind het een goed criteria om het uitstekend te noemen... Als je doelgroep 5 tuinders uit het groene hart zijn die samenwerken achter 2 computers.

Voor een bedrijf met duizenden medewerkers ga je echt iets kritischer moeten zijn hoor, dan ga je opeens te maken krijgen met mensen uit het buitenland die "ergens" rekeningen hebben lopen.
Maar je gaat bijv ook te maken krijgen met dat iemand iets over een SOA nazoekt op maandag, valt ook gewoon onder health en heb jij geen barst mee te maken, veel plezier met nakijken of jouw lijstje wel alle SOA-voorlichtingssites bevat.
Maar Cryptocoin valt ook onder financing, die dingen bestaan zo ongeveer per dag en jij hebt ze allemaal in jou blacklist staan. Gefeliciteerd, dat betekent dat jij weet welke ICO ik morgen ga opstarten.

En in Nederland is dit allemaal toegestaan voor elke werknemer met internet en jij gaat dat nooit allemaal kunnen blokkeren met je lijstjes.
Want in de praktijk heb jij er al niets meer mee te maken als iemand in google een c intikt om te zoeken naar chlamidia en googles autosuggest in werking gaat op 1 letter.

[TommyboyNL]

@Gomez12 Nou, dat mag wel wat vriendelijker.. discussieren prima, maar we gaan elkaar niet voor rotte vis uitmaken..

[ Voor 74% gewijzigd door Equator op 13-06-2018 06:42 ]

[Verwijderd]

Gomez12 schreef op maandag 11 juni 2018 @ 20:17:
Tja, dat is heel leuk en populistisch gezegd, maar veelal heeft de politie zijn bewijslast wel op orde hoor.

Als ze vier maanden later nog eens komen aankakken met een informatievraag? Niet dus.

En als jij ze niet verder kan helpen dan blijven ze dus hangen op het feit dat jouw bedrijf die overtreding heeft begaan. En of je dat nu moet willen...

Dat is een omkering van het principe "schuldig tot het tegendeel bewezen", en zo werkt het strafrecht toch nog net nog even niet.

De overtreding mag dan nog zo hard van dit netwerk komen, dat wil niet zeggen dat de eigenaar dan ook direct juridisch verantwoordelijk gehouden kan worden voor alles wat er op gebeurt. Anders konden bijvoorbeeld ISPs, bibliotheken, iedereen met een "courtesy"-wifi, etc. ook wel gelijk inpakken.

Jammer voor het bedrijf bedoel je, want die heeft zijn logging niet op orde. Waardoor die de boete niet kan doorgeven en bij het bedrijf blijft liggen.

Zo werkt het strafrecht ook al niet. "Hier boete, geef maar door aan wie het wel gedaan heeft." Nuh-uh, een beetje advocaat maakt er onmiddelijk gehakt van, mocht de politie dat voorstellen, en als grootbedrijf heb je er toch wel een stel rondlopen, hebben die ook weer wat te doen.

Je bent nergens verplicht om bij te houden wat je werknemers (en je gasten) allemaal precies uitvreten en al helemaal niet om dat uitentreure ook nog eens te bewaren. Sterker, dat mag je nou juist niet, want privacyverwachting, óók op het werk. Dan kun je niet zeggen, "ja maar nu was het wel handig geweest als je nog even dertien maanden terug kon gaan in je logs" en ook nog verwachten dat die logs netjes opgehoest worden. Dat strookt niet.

Dus nee, zowel de omkering bewijslast als de doorgifteboete houden geen stand. Waarmee internettoegang toch net iets anders werkt dan bedrijfswagens.

[ik222]

Ik zou het inderdaad eerst even omdraaien, wat ben je verplicht te loggen volgens de wet en / of om schade / aanprakelijkheid van het bedrijf te voorkomen? Tel daarbij nog de zaken op die je zelf nodig hebt voor troubleshooting en / of de bescherming van je netwerk en data en je weet wat je moet loggen.

Het feit dat het in dit geval de politie goed uit zou komen dat je iets logt betekent niet dat je het dan per definitie ook had moeten loggen.

[TheGhostInc]

TommyboyNL schreef op maandag 11 juni 2018 @ 15:01:
Wat betreft historische logging aan users koppelen

Wat wil je hiermee bereiken?

Het bewijst namelijk niet dat de fysieke persoon daadwerkelijk iets heeft gedaan.
Als er een backdoor op de machine staat kan iemand anders ook acties uitvoeren onder de username. En als je een machine remote kunt overnemen moet dat 100% waterdicht & gelogd zijn. Anders kan een sysadmin de machine hebben overgenomen.
En dat is nog los van een eventuele gebruiker die zijn wachtwoord heeft gedeeld.
(En dat is niet altijd grond voor ontslag)

Praktische vraag, als 2 users op 1 systeem zijn ingelogd... wie staat er dan in de log?
Daarnaast is een logbestand gewoon 'plain text'. Dat is eenvoudig te manipuleren. 'Find and replace'. Een pissige sysadmin kan dus zo iemand erbij naaien.

Normaal heb je dan ook meer bewijs nodig dan een simpele access log.
Het liefst pak je ze als ze er mee bezig zijn, want dan is er geen mogelijkheid om er onderuit te komen.
Anders kan het een hele dure ervaring worden.

[Renegade666]

TheGhostInc schreef op maandag 11 juni 2018 @ 22:34:
[...]


Praktische vraag, als 2 users op 1 systeem zijn ingelogd... wie staat er dan in de log?
Daarnaast is een logbestand gewoon 'plain text'. Dat is eenvoudig te manipuleren. 'Find and replace'. Een pissige sysadmin kan dus zo iemand erbij naaien.

.

Als je bv een watchuard FW/UTM met AD integratie, kun je prima zien wie wat doet. Incl mensen op een RDS/Citrix server.
Samen met Dimension(loggin/rapportage server) kun je veel data onthouden in een relatieve kleine database.

[TheBorg]

ik222 schreef op maandag 11 juni 2018 @ 22:04:
Ik zou het inderdaad eerst even omdraaien, wat ben je verplicht te loggen volgens de wet en / of om schade / aanprakelijkheid van het bedrijf te voorkomen? Tel daarbij nog de zaken op die je zelf nodig hebt voor troubleshooting en / of de bescherming van je netwerk en data en je weet wat je moet loggen.

Het feit dat het in dit geval de politie goed uit zou komen dat je iets logt betekent niet dat je het dan per definitie ook had moeten loggen.

Ik heb het hele topic gelezen en het is vet interessant en technisch ook nog wel tof als je 4 weken niks beters te doen hebt maar ik vraag me gewoon af, wat de neuk heb ik er aan? Wat moet je met al die data? Volgensmij niks. Mensen mogen in de pauze praktisch alles op het internet doen wat ze willen. Juridisch gezien mag iemand zelfs tijdens werktijd naar een SOA Googlen. En je kan ook niet op de stoel van de rechter gaan zitten. Want wie bepaald of de iPadjes die Pietje op Marktplaatst heeft gezet van de vrachtwagen zijn gevallen of niet? En wat wil je doen met de kennis dat Pietje gejatte iPadjes verkoopt? Vanwege de privacy kun je er niet zoveel mee. Dus ga je dan loggen voor die inspecteur die één keer in de 3 jaar langs komt? Misschien kan @houwimmie er iets over zeggen hoe de directie van een groot bedrijf dat ziet.

[TommyboyNL]

TheGhostInc schreef op maandag 11 juni 2018 @ 22:34:
Praktische vraag, als 2 users op 1 systeem zijn ingelogd... wie staat er dan in de log?
Daarnaast is een logbestand gewoon 'plain text'. Dat is eenvoudig te manipuleren. 'Find and replace'. Een pissige sysadmin kan dus zo iemand erbij naaien.

Dat is afhankelijk van de implementatie. Een type proxyserver die ik veel implementeer trekt via NTLM je credentials uit je browser. De log entries worden dus gekoppeld aan de user namens wie de browser opgestart is (niet namens wie ingelogd is, dat zijn twee heel verschillende zaken).
Sommige firewalls koppelen in het geval van fat clients jouw username aan een IP adres aan de hand van de WMI logging. Nieuw logon event vanaf het betreffende systeem betekent eventueel een nieuwe user aan het IP koppelen.
Andere firewalls hebben een agent nodig die op je OS draait, om jouw identiteit door te geven.
Zat mogelijkheden, met variërende niveau's van complexiteit om te implementeren en bijpassende nauwkeurigheid.

Edit: @TheBorg Ik kan je uit ervaring vertellen dat een groot advocatenkantoor gewoon lang de firewall logs bewaart (waarin de metadata van elke connectie staat, inclusief user), en een webproxy gebruikt met SSL interceptie waar medische en financiële sites (voor de duidelijkheid: crypto's vallen hier NIET onder) in de bypass staan (dus geen SSL interceptie), en ook gewoon de logging van bewaard wordt. Dit alles is in principe WORN data, die alleen as needed bekeken wordt; hier wordt niet door een verveelde sysadmin in gegrasduind.

[ Voor 20% gewijzigd door TommyboyNL op 11-06-2018 22:44 ]

[Gomez12]

TommyboyNL schreef op maandag 11 juni 2018 @ 21:14:
@Gomez12 S[knip]

Tja, het probleem is een beetje dat ik weet hoe het er in de echte wereld aan toe gaat en daar heb je niets aan je blacklists.
Omdat men daar kijkt naar de intentie en niet naar de benaming.

Wat is het doel achter niet banking gegevens in willen zien? En zou het dan niet raar zijn als je wel CryptoCoin bedragen kan inzien van medewerkers?
Wat is het doel achter niet health gegevens in willen zien? En zou het dan niet raar zijn als je diezelfde gegevens gewoon uit hun google-gegevens gaat plukken?

Gefeliciteerd dat je zorgverzekeraars blokkeert, alleen de gegevens die daar staan heeft 90% van de werkgevers al bij de arbo-arts liggen en dat is al een gepasseerd station, het is veel interessanter (en problematischer) om te zien waarop men zoekt.

Maar wat je anders ook kan doen, hebben wij in het verleden ook wel eens gedaan. Gewoon aan je blacklist leverancier vragen of die je 1000 euro wil geven bij elke site die niet in de blacklist staat maar wel erin hoort (volgens hun conditities). Wij zijn nog nooit 1 leverancier tegengekomen die dat aandurfde en daar waren 1001 redenen voor.

[ Voor 11% gewijzigd door Equator op 13-06-2018 06:43 ]

[TommyboyNL]

Gomez12 schreef op maandag 11 juni 2018 @ 22:49:
[...]

Tja, het probleem is een beetje dat ik weet hoe het er in de echte wereld aan toe gaat en daar heb je niets aan je blacklists.
Omdat men daar kijkt naar de intentie en niet naar de benaming.

Wat is het doel achter niet banking gegevens in willen zien? En zou het dan niet raar zijn als je wel CryptoCoin bedragen kan inzien van medewerkers?
Wat is het doel achter niet health gegevens in willen zien? En zou het dan niet raar zijn als je diezelfde gegevens gewoon uit hun google-gegevens gaat plukken?

Gefeliciteerd dat je zorgverzekeraars blokkeert, alleen de gegevens die daar staan heeft 90% van de werkgevers al bij de arbo-arts liggen en dat is al een gepasseerd station, het is veel interessanter (en problematischer) om te zien waarop men zoekt.

Maar wat je anders ook kan doen, hebben wij in het verleden ook wel eens gedaan. Gewoon aan je blacklist leverancier vragen of die je 1000 euro wil geven bij elke site die niet in de blacklist staat maar wel erin hoort (volgens hun conditities). Wij zijn nog nooit 1 leverancier tegengekomen die dat aandurfde en daar waren 1001 redenen voor.

Je hebt duidelijk niet gelezen wat ik schreef. Nergens heb ik het over blacklists of blokkeren, ik heb het over niet-inspecteren van bepaalde SSL encrypted verkeersstromen.
De enige reden dat deze niet decrypted worden is voor het idee dat gebruikers erbij krijgen. De inhoud van geen enkel request zal ooit door een mens bekeken worden, alleen door computers. Mensen zien hooguit de URLs bij forensische activiteiten.
Je wilt echter hard kunnen maken dat je je best doet om de integriteit medische gegevens en bankgegevens te bewaren.

[Kabouterplop01]

AD logging, DHCP logging, firewall logging, netflow (van elke internet facing interface) en een groot storage cluster met ELK oid en correlatie van die 4 soorten messages. En dan zul je moeten bepalen hoe lang je retentie moet worden, van je gecomprimeerde gearchiveerde messages en van de messages die je on the fly wilt kunnen doorzoeken.
(En dat is een duur project)
edit: wat @Rolfie hieronder zegt: Al je internet facing (webtraffic) via een proxy laten lopen en dat ook naar je loghost laten loggen.
De reden om buiten lokaal te loggen, ook dit naar een remote logging host te sturen is puur voor de integriteit van logfiles. Mocht 1 van die machines geowned worden dan kun je de betrouwbaarheid van die local log niet garanderen, dan is er ook nog remote logging!

Om te zorgen dat je niet besmet wordt via privé mail, zou je een software restriction policy kunnen bouwen.
deze laat je de meest voorkomende zaken blokkeren die nergens op slaan.
vb: Ik mag hopen dat geen enkele beheerder, zonder te kijken een bijvoorbeeld powershellscript dubbelclicked, etc

[ Voor 51% gewijzigd door Kabouterplop01 op 12-06-2018 11:12 ]

[Rolfie]

DiedX schreef op maandag 11 juni 2018 @ 18:15:
Interessante vragen, ook vanuit AVG / Bedrijfsstandpunt.

Als eerste: 5 * 365 = 1825 GB per jaar. Als je een servertje ophangt met daarop Linux, rsyslog en 2 x 2 TB Schijven heb je je loghost in orde (daarop doe je alléén loggen, niet inloggen met SSH, gewoon laten loggen)

Stap 2: álles luistert naar je NTP-server op je AD-servers. Óok je switches en routers, anders ben je dagen bezig om time-skew recht te trekken

Stap 3: proxy installeren, alles loopt alleen daar over heen. De rest dichttimmeren.

Vervolgens krijg je wél een juridische vraag. Ik ben van mening dat je een boel mag loggen - ZOLANG MENSEN DAARVAN OP DE HOOGTE ZIJN. De vraag is of je het moet willen, en hoe ver je daar in gaat, en hoe lang je het op slaat...

Ik hoop werkelijk dat je dit niet zo geimplementeerd hebt. Leuk voor een hobby thuis, maar in een bedrijf zou ik het toch iets professioneler aanpakken. Dit is een hobby bob oplossing implementatie, die juist op de AVG wel eens een groot risico kan zijn.

TommyboyNL schreef op maandag 11 juni 2018 @ 18:43:
Ja, dat wil je écht. Anders kan je net zo goed niet filteren. Een significant deel van het internetverkeer gaat tegenwoordig over SSL.
Je kan er overigens zeker van zijn dat als je SSL inspectie laat inrichten door iemand die dat vaker doet, één van de eerste vragen zal zijn wat er NIET geïnspecteerd mag/moet worden. Meestal gaat het dan om banking/financial en health.

Eigenlijk wil je dat niet hebben. Privacy en Juridisch gezien een lastige, en ik ook zeker niet specifiek nodig.
En is ook niet direct nodig, je kan op andere manieren ook de heel veel van de wenste functionaliteit krijgen. Ik zit bij best grote bedrijven, en ik denk dat niemand daar even een MITM gaat doen op de proxy servers. Zelfs Informtie beveiliging zou hier niet zomaar mee komen,

TommyboyNL schreef op maandag 11 juni 2018 @ 17:39:
Voor KMO/MKB is dit inderdaad niet haalbaar. TS geeft echter aan voor een naar BeNeLux maatstaven groot bedrijf te werken. Dan is het plotseling een heel ander verhaal. Op die schaal moet je gewoon goed loggen in combinatie met Identity Awareness (laten we dat even gebruiken als algemene naam), en HTTPS inspectie toepassen. HTTPS inspectie hoef je niet per sé op je firewall te doen, maar daar kan je ook een proxy server voor inzetten (welke je naar mijn mening óók dient te hebben).

Ik dit nog niet direct waarom dit dan een ander verhaal is. Zou het mooi zijn, zeker, maar zolang er geen functionele requirements voor zijn die dit eisen, zou ik hier echt niet aan beginnen. En zelfs dan is MITM niet direct noodzakelijk en moet het de laatste mogelijkheid zijn. Technisch gezien zijn er alternatieven genoeg om dit uit te voeren, zonder MITM uit te voeren.

Een favoriete entry point van malware is tegenwoordig privémail die mensen via webmail op hun werk openen. Als je dat niet al bij de poort kan scannen (of helemaal blokkeren), sta je meteen 1-0 achter.

Je zegt het hier zelf al... PRIVE mail.... Daar heeft het bedrijf dus helemaal niets mee te maken, en moeten ze dus ook van afblijven. Als je dat gaat scannen, begeef je je al op gladijs.

[Predator]

Rolfie schreef op dinsdag 12 juni 2018 @ 08:01:
krijgen. Ik zit bij best grote bedrijven, en ik denk dat niemand daar even een MITM gaat doen op de proxy servers. Zelfs Informtie beveiliging zou hier niet zomaar mee komen,


[...]
Ik hoop [...]
werkelijk dat je dit niet zo geimplementeerd hebt. Leuk voor een hobby thuis, maar in een bedrijf zou ik het toch iets professioneler aanpakken. Dit is een hobby bob oplossing implementatie, die juist op de AVG wel eens een groot risico kan zijn.


[...]

Eigenlijk wil je dat niet hebben. Privacy en Juridisch gezien een lastige, en ik ook zeker niet specifiek nodig.
En is ook niet direct nodig, je kan op andere manieren ook de heel veel van de wenste functionaliteit
Ik dit nog niet direct waarom dit dan een ander verhaal is. Zou het mooi zijn, zeker, maar zolang er geen functionele requirements voor zijn die dit eisen, zou ik hier echt niet aan beginnen. En zelfs dan is MITM niet direct noodzakelijk en moet het de laatste mogelijkheid zijn. Technisch gezien zijn er alternatieven genoeg om dit uit te voeren, zonder MITM uit te voeren.


[...]
Je zegt het hier zelf al... PRIVE mail.... Daar heeft het bedrijf dus helemaal niets mee te maken, en moeten ze dus ook van afblijven. Als je dat gaat scannen, begeef je je al op gladijs.

Euhm, wij doen SSL decryptie op onze proxy servers, samen met multi layered malware scanning. Je moet decrypten en opnieuw encrypteren wil je kunnen de malware scannen. En uiteraard voor privémail ?
Hoe gaat die malware via HTTP(s) binnenkomen denk je ? Je logt helemaal geen POST data hiermee, enkel URL's. Het is niet zo dat je dan zomaar de privé mails zit te loggen. Daar is niets glad ijs aan. Ik begrijp niet waarom je daar zo verbaasd over bent ? Voor sommige zaken doen we geen decryptie, maar dat heeft eerder met performantie redenen te maken, of problemen met applicaties.
Daarnaast moet je ook decrypteren als je specifieke access rules wil zetten op velden in het url pad.
Anders zie je gewoon tcp <hostname> voorbijkomen.

Onze dedicated anti-DDOS apparatuur heeft trouwens ook een dedicated cavium kaart onboard voor SSL decryptie, anders kan je de HTTPS requests naar je webapps niet inspecteren...

[ Voor 4% gewijzigd door Predator op 12-06-2018 08:54 ]

[DiedX]

Rolfie schreef op dinsdag 12 juni 2018 @ 08:01:
[...]

Ik hoop werkelijk dat je dit niet zo geimplementeerd hebt. Leuk voor een hobby thuis, maar in een bedrijf zou ik het toch iets professioneler aanpakken. Dit is een hobby bob oplossing implementatie, die juist op de AVG wel eens een groot risico kan zijn.

Doe eens wat concrete voorstellen dan? TS gaat van níets naar íets. Uiteraard kan je het gaan hebben over Splunk en consorten, maar zorg eerst maar eens er voor dat je uberhaupt íets logt.

Ik zie even geen problemen hierin, maar wellicht kan je mij verder inlichten in wat jij zou doen...

[Rolfie]

Predator schreef op dinsdag 12 juni 2018 @ 08:50:
Euhm, wij doen SSL decryptie op onze proxy servers, samen met multi layered malware scanning. Je moet decrypten en opnieuw encrypteren wil je kunnen de malware scannen. En uiteraard voor privémail ?
Hoe gaat die malware via HTTP(s) binnenkomen denk je ? Je logt helemaal geen POST data hiermee, enkel URL's. Het is niet zo dat je dan zomaar de privé mails zit te loggen. Daar is niets glad ijs aan. Ik begrijp niet waarom je daar zo verbaasd over bent ?

Zodra je met privemails aan de slag gaat, begeef je je op een zeer privacy gevoelig stukje. Immers in de attachment kan ook vertrouwelijke informatie zitten, idem in de URL. Dat je zegt dat je geen post informatie bewaard. Maar je kan er wel degelijk toegang tot hebben.
Je ondermijnd hiermee volledig de achterliggende gedachte van HTTPS. Ik zou hier namelijk nooit meer een HTTPS website kunnen vertrouwen indien ik de root CA geladen heb van je MITM appliance. Een compleet goed ingerichte PKI met hardware security module en offline roots, kan daar wel verbetering inbrengen. Maar je kan er niet meer vanuit gaan dat HTTPs verkeer betrouwbaar is.

Proxy server logging is vanuit Privacy al een hele gevoelige, want zelfs vanuit http verkeer, kan je als dingen zien, die al heel erg vertrouwelijk zijn. Je gaat hier nog een paar stappen verder.

Ik begrijp vanuit security dat je dit heel graag wilt. De achterliggende gedachte is ook heel logisch.
Vanuit malware bestrijding wil je dit heel erg graag actief hebben. HTTPS is hierin een zeer lastige en steeds meer gaat over https verkeer, ik zie dat steeds vaker.

Maar ik zou dit bij geen enkel bedrijf durven te adviseren. Informatie beveiliging en de privacy officiers zouden beide meteen hiervoor gaan steigeren. En er zijn eigenlijk diverse alternatieven, dus voor een groot gedeelte het zelfde doen, zonder deze privacy issues. Zijn ze perfect, helaas niet. Maar wel een stuk gemakkelijker te implementeren.

Mij verbaast het juist, hoe jij op deze punten reageert, en hoe gemakkelijk je over de mogelijke issues heen stapt.

De privacy punten zijn wel kort te slaan, maar ik menige bedrijf zouden hier hele zware discussies overgevoerd worden tot op het hoogste niveau. En iedereen zou hier heel duidelijk mee akkoord moeten gaan.

Daarnaast moet je ook decrypteren als je specifieke access rules wil zetten op velden in het url pad.

Ook hier zit je al op een privacy raakvlak. Immers je kan in eens in de https URL kijken als beheerder, en zijn er dus mogelijk logfiles van.

Anders zie je gewoon tcp <hostname> voorbijkomen.

Voor veel doeleinde meer dan genoeg, om eventueel blokkades op te werpen, of voor security logging.

Onze dedicated anti-DDOS apparatuur heeft trouwens ook een dedicated cavium kaart onboard voor SSL decryptie, anders kan je de HTTPS requests naar je webapps niet inspecteren...

Daar heb je geen dedicated SSL kaart voor nodig. Het werkt wel een stuk beter, maar is zeker geen requirement. normale CPU's kunnen dit ook gewoon uitvoeren, performance technisch alleen verre van optimaal. Dedicated SSL cards doen dit dit vele malen sneller. Echter daarna gaat de normale CPU verder met de analyse.

[Rolfie]

DiedX schreef op dinsdag 12 juni 2018 @ 10:50:
[...]

Doe eens wat concrete voorstellen dan? TS gaat van níets naar íets. Uiteraard kan je het gaan hebben over Splunk en consorten, maar zorg eerst maar eens er voor dat je uberhaupt íets logt.

Ik zie even geen problemen hierin, maar wellicht kan je mij verder inlichten in wat jij zou doen...

Ik zou eerst de requirements willen weten waaraan je moet voldoen, voordat ik aan technische oplossing zou gaan denken. Zodra ik weet wat voor een (procedure en technische) requirements ik heb, kan ik eens gaan kijken naar de techniek van hoe ik dit zou gaan implementeren.

Niet even een doos inrichten die de logging verwerkt en hopen dat de machine blijft draaien. Nu zet je juist een risico neer, wat mogelijk AVG non compliant is, privacy gevoelige informatie kan lekken.

[Predator]

Rolfie schreef op dinsdag 12 juni 2018 @ 11:03:
[...]
Zodra je met privemails aan de slag gaat, begeef je je op een zeer privacy gevoelig stukje. Immers in de attachment kan ook vertrouwelijke informatie zitten, idem in de URL. Dat je zegt dat je geen post informatie bewaard. Maar je kan er wel degelijk toegang tot hebben.
Je ondermijnd hiermee volledig de achterliggende gedachte van HTTPS. Ik zou hier namelijk nooit meer een HTTPS website kunnen vertrouwen indien ik de root CA geladen heb van je MITM appliance. Een compleet goed ingerichte PKI met hardware security module en offline roots, kan daar wel verbetering inbrengen. Maar je kan er niet meer vanuit gaan dat HTTPs verkeer betrouwbaar is.

Niet akkoord. De ICT van het bedrijf is verantwoordelijk voor de correctheid van de trusted root CA store, net als die dat is voor de proxy servers. Integendeel zelfs, wij blokkeren niet trusted roots, waardoor interne browsers ook niet met toestemming van de gebruikers toegang hebben tot vervalste sites.
Anders hebben ze dat wel, want een gebruiker is zo gewoon om op doorgaan te klikken

Proxy server logging is vanuit Privacy al een hele gevoelige, want zelfs vanuit http verkeer, kan je als dingen zien, die al heel erg vertrouwelijk zijn. Je gaat hier nog een paar stappen verder.

Ik begrijp vanuit security dat je dit heel graag wilt. De achterliggende gedachte is ook heel logisch.
Vanuit malware bestrijding wil je dit heel erg graag actief hebben. HTTPS is hierin een zeer lastige en steeds meer gaat over https verkeer, ik zie dat steeds vaker.

Maar ik zou dit bij geen enkel bedrijf durven te adviseren. Informatie beveiliging en de privacy officiers zouden beide meteen hiervoor gaan steigeren. En er zijn eigenlijk diverse alternatieven, dus voor een groot gedeelte het zelfde doen, zonder deze privacy issues. Zijn ze perfect, helaas niet. Maar wel een stuk gemakkelijker te implementeren.

Al onze security partners zijn niet akkoord met jouw stelling onze DPO ook niet. Mag ik weten wat jouw ervaring en bedrijfsfunctie is ? Ben jij ergens DPO bv ?

Mij verbaast het juist, hoe jij op deze punten reageert, en hoe gemakkelijk je over de mogelijke issues heen stapt.

De privacy punten zijn wel kort te slaan, maar ik menige bedrijf zouden hier hele zware discussies overgevoerd worden tot op het hoogste niveau. En iedereen zou hier heel duidelijk mee akkoord moeten gaan.

Al onze logging is volledig beschreven in het dataregister en gemeld bij onze DPO.

Voor veel doeleinde meer dan genoeg, om eventueel blokkades op te werpen, of voor security logging.

Toch niet, want met de URL hostname alleen kan je niets aantonen.

Daar heb je geen dedicated SSL kaart voor nodig. Het werkt wel een stuk beter, maar is zeker geen requirement. normale CPU's kunnen dit ook gewoon uitvoeren, performance technisch alleen verre van optimaal. Dedicated SSL cards doen dit dit vele malen sneller. Echter daarna gaat de normale CPU verder met de analyse.

Bedankt voor de informatie, maar ik denk dat ik meer ervaring op dat vlak heb dan jij

[Rolfie]

Predator schreef op dinsdag 12 juni 2018 @ 11:29:
Niet akkoord. De ICT van het bedrijf is verantwoordelijk voor de correctheid van de trusted root CA store, net als die dat is voor de proxy servers. Integendeel zelfs, wij blokkeren niet trusted roots, waardoor interne browsers ook niet met toestemming van de gebruikers toegang hebben tot vervalste sites.
Anders hebben ze dat wel, want een gebruiker is zo gewoon om op doorgaan te klikken

Hele goede insteek om non trusted roots te blockeren.

Echter een goede PKI neerzetten doet niet veel bedrijven, waardoor die niet goed ingericht is, waardoor het een security issue kan worden.

Persoonlijk zou ik bij een MITM op HTTPS oplossing, niets meer prive doen op dat netwerk. Sterker nog, ik zou een stuk minder internetten, zelf werk gerelateerd. Ik zou eerder een alternatief zoeken. Maar dat zou mijn mening zijn.


Dat jullie het goed neer zetten, met alles goed geregeld, wil niet zeggen dat andere dit ook doen, of moeten doen. Je zet dit soort oplossingen niet even neer, en zeker niet vaak bij MKB klanten. Je past dit soort oplossingen toe bij Enterprise netwerken, of waar security van groot belang is. Ofwel de requirements zijn er vanuit het bedrijf. Dan is dit zeker een mogelijkheid om te implementeren, technieken zijn er ook.

Maar het is niet zo "Vanuit ICT willen we dit al het https verkeer via MITM gaan analyseren" dus gaan we dit even implementeren.

Al onze logging is volledig beschreven in het dataregister en gemeld bij onze DPO.

Zoals ik melde zijn de problemen zeker op te lossen. Wil niet zeggen dat dit gemakkelijk is. Ik zeg ook niet dat het verboden is, maar je begeeft je wel op gladijs, waar je heel goed over na moet denken. Je doet dit niet even, en vaak technisch ook niet direct noodzakelijk. Hangt er vanaf wat je wilt bereiken en hoe je het wilt bereiken. Wat je adviseert is ook zeker een mogelijkheid, maar dit is niet de standaard bij menig bedrijf.

Toch niet, want met de URL hostname alleen kan je niets aantonen.

Hangt van je requirements af. Voor veel doeleinde is dit voldoende en voor sommige niet.

Bedankt voor de informatie, maar ik denk dat ik meer ervaring op dat vlak heb dan jij

Dat kan en mag. Ik wil niet zeggen dat ik alles weet.
Maar ik zou wel kritische vragen stellen, en dat doe ik vaak met een redenen... En dat kan het vaak ook zijn, dat de antwoorden heel bevredigend zijn, maar soms komen er ook in eens problemen naar voren, waar men niet over gedacht had.

Ik zie ook nog steeds niet de noodzaak om dit bij ieder bedrijf te implementeren.

[ Voor 6% gewijzigd door Rolfie op 12-06-2018 11:53 ]

[Predator]

Rolfie schreef op dinsdag 12 juni 2018 @ 11:43:
[...]

Hele goede insteek om non trusted roots te blockeren.

Echter een goede PKI neerzetten doet niet veel bedrijven, waardoor die niet goed ingericht is, waardoor het een security issue kan worden.

Persoonlijk zou ik bij een MITM op HTTPS oplossing, niets meer prive doen op dat netwerk. Sterker nog, ik zou een stuk minder internetten, zelf werk gerelateerd. Ik zou eerder een alternatief zoeken. Maar dat zou mijn mening zijn.

Dit is geen aanval op jou, maar in mijn ervaring zijn diegene die het hardste hun eigen privacy verdedigen, ook diegene die de privacy van andere niet respecteren. IT'ers die duckduckgo gebruiken, maar wel elke keer de schoonmaakster thuis volgens op de homecamera's....

Er zijn ook meer aspecten. Aan de ene kant heb je privacy van medewerkers van het bedrijf, maar bedrijven die erg veel gevoelige persoonsgegevens bijhouden (zoals wij) moeten die ook beschermen.
Laat het nu de eerste groep (medewerkers) die de andere schenden. Zo vinden medewerkers het geen probleem om gevoelige persoonsgegevens op een USB mee te pakken, achter te laten op printers, of via privémail door te sturen ...

Iedereen is vooral geïnteresseerd in zijn eigen privacy.

[houwimmie]

Zeer interessante discussie hier, voer tot nadenken!
Wel even ter verduidelijking; het is niet dat er niets wordt gelogd, syslog genereert alles bij elkaar een kleine 3 GB aan data per dag. Met de huidige opzet kunnen we de logs niet koppelen aan effectieve users.
Als ik user awareness wil activeren op onze NG Cisco ASA's, moet ik wel de agent gaan installeren op alle client OS'en en Citrix servers.
Het lijkt me, zoals al meermaals aangegeven, makkelijker om er een proxy tussen te plaatsen.

[Rolfie]

houwimmie schreef op dinsdag 12 juni 2018 @ 16:44:
Zeer interessante discussie hier, voer tot nadenken!
Wel even ter verduidelijking; het is niet dat er niets wordt gelogd, syslog genereert alles bij elkaar een kleine 3 GB aan data per dag. Met de huidige opzet kunnen we de logs niet koppelen aan effectieve users.
Als ik user awareness wil activeren op onze NG Cisco ASA's, moet ik wel de agent gaan installeren op alle client OS'en en Citrix servers.
Het lijkt me, zoals al meermaals aangegeven, makkelijker om er een proxy tussen te plaatsen.

Proxy maakt het wel een stuk gemakkelijker. Extra mogelijkheden. DHCP Logging en eventueel Windows Authenticatie logs vanuit je Domain Controllers. Al wordt dit lastig met Terminal servers. Dan is Authenticatie eigenlijk de enige oplossing. Maar hou er rekening mee, niet alle applicaties ondersteunen dit.

[Bl@ckbird]

Je kan alles loggen, maar de vraag is wat je met die info allemaal wil doen.. Welk probleem wil je oplossen? Wil je verdachte handelingen kunnen terugleiden naar een user? Wil je geïnfecteerde hosts van je netwerk bannen? Wil je malware of botnet op je netwerk voorkomen?

Wil je user awareness gebruiken, dan kan je een AD agent installeren, die communiceert met de ASA. Verkeer wordt geblokt en je ziet er ook een AD naam bij. Als je je netwerk wil segmenteren, dan kan je naar Identity Services Engine (ISE) kijken. ISE integreert met AD en hiermee kan je dot1x inregelen. Sales mensen komen in het sales VLAN, engineers in het engineers VLAN. Dus role-based toegang. ISE kan ook posture assessment doen: Is de virusscanner niet up-to-date, of zijn de laatste patches niet gedraaid, dan wordt de host in een quarantaine VLAN gezet met internet only. (waar hij/zij updates kan draaien.) ISE integreert ook met MDM oplossingen zoals Mobile Iron of Meraki System Manager. Met MDM kan je bijvoorbeeld het gebruik van de camera op smartphones en tablets dicht zetten, of het gebruik van apps. Een arts in het ziekenhuis kan bijvoorbeeld bij een elektronisch patiënten dossier op een iPad. Gebruikt hij diezelfde iPad thuis (dus buiten het ziekenhuis netwerk) kan het EPD niet raadplegen. Op basis van rol, locatie, tijd, etc. (dus de context) kan je netwerk toegang beperken. Alles wat een gebruiker doet wordt standaard gelogd. ISE werkt ook met een API genaamd pxGrid. Detecteert de IPS engine op de ASA verdacht botnet verkeer van/naar een host, dan communiceert de ASA dit naar ISE en ISE zal deze host automatisch in een quarantaine VLAN plaatsen.

L3 apparaten kunnen vaak netflow genereren. (Dan bedoel ik volledige netflow records, dus niet sampled netflow van Catalyst 2960X of sFlow van HP switches, want sampled is sampled.. dus niet volledige informatie. Handig voor bandwidth sizing van uplinks, maar niet als security tool.) StealthWatch verzameld deze flows en doet er analyse op. Wijkt verkeer af van de baseline, dan gaat er een alarm af. Een download bijvoorbeeld is niet bijzonder, maar een download van 1Mbps die een maand duurt kan duiden op het wegsluizen van data. Verdacht verkeer van botnets kan je er ook mee detecteren. Heb je ISE draaien, dan kan Stealthwatch een geïnfecteerde host communiceren naar ISE en ISE kan deze host in een quarantaine VLAN plaatsen. Een NextGen ASA blokkeert actief verkeer, Stealthwatch monitort alleen (zonder ISE integratie).

Een ASA kan tegenwoordig ook SSL decryption doen. Het probleem is dat de performance van de firewall behoorlijk inzakt als je al het HTTPS verkeer wil decrypten. Je moet dus keuzes maken in welk verkeer je wil decrypten en welk verkeer niet. Daarnaast is decrypten van HTTPS verkeer vanwege privacy issues vaak onwenselijk. Aan de andere kan is steeds meer verkeer HTTPS. (Denk aan clouddiensten maar zelfs video als Youtube is standaard HTTPS.) Het je Stealthwatch samen met ISR4000 routers met security licentie of Catalyst 9000 switches, dan kan je Encrypted Traffic Analytics doen. Daarbij wordt naar de TLS info in de eerste (non-encrypted) IP packet gekeken. Daarnaast worden alle IP packets ge-timestamped. Ransomware heeft een ander signature dan bijvoorbeeld een Google zoekopdracht. Zo kan je m.b.v. metadata met 99% zekerheid bepalen of HTTPS verkeer malware bevat, zonder het te decrypten. Heb je ISE, dan wederom het quarantaine verhaal.

Het probleem van bovenstaande dingen is dat ze prima het interne netwerk beveiligen, maar dat users hun mobiele apparaten uiteraard ook buiten het bedrijfsnetwerk gebruiken. Je kan een verplichte “always-on” VPN naar de firewall afdwingen, maar het blijft tricky. Cisco heeft een proxy in de vorm van de Web Security Appliance (WSA) maar dit zie ik eigenlijk nooit meer voorbij komen. Daarvoor in de plaats wordt vaak Umbrella (het voormalige OpenDNS) gebruikt, eventueel aangevuld met AMP for Endpoints. Beiden zijn cloud services en werken ongeacht waar de user zich bevindt. De meeste communicatie gebruikt DNS en Umbrella is eigenlijk een big data security analytics op basis van DNS info. Het logt alle URLs. (Na een paar maanden kan je dit exporteren naar een Amazon AWS S3 bucket.) Het blokkeert phishing linkjes, malware downloads, ransomware, certificaten om data met ransomware te encrypten, etc. Twee IP adressen configureren als DNS servers is voldoende voor de configuratie. Installeer je een lichtgewicht client, dan zie je ook user data in je logging. (Ook al gebruikt een user z’n apparaat buiten het bedrijfsnetwerk.) Umbrella / OpenDNS doet alleen prevention.

AMP for Endpoints is een lichtgewicht client die je op hosts installeert. Het maakt van alle bestanden een hash en vergelijk die met de cloud. (clean/malware of unknown) Daarnaast monitort het applicaties op de host. Als een applicatie bepaalde system-calls doet kan dit duiden op malware. Blijkt een bestand achteraf toch malware te zijn, dan kan je op basis van de hash op alle endpoints blokkeren en uit het memory halen. AMP draait op het endpoint, dus malware via HTTPS blokkeert het ook.

Het hele ISE / Encrypted Traffic Analytics / Stealthwatch zie ik voornamelijk bij grote bedrijven.
Umbrella / OpenDNS (eventueel samen met AMP for Endpoints) en een goede NextGen firewall met IPS om de serverfarm te beschermen is in de meeste gevallen vaak voldoende.

Bovenstaande oplossingen genereren alleen een alarm als er ook daadwerkelijk wat aan de hand is. Je hoeft dus niet logging door te spitten om een security event te vinden. De tooling doet dat voor jou en automatiseert de afhandeling van security events. Logbestanden / netflow records zijn beschikbaar, maar 9 van de 10 keer heb je dit niet nodig. ISE zet een geïnfecteerde host in een quarantaine VLAN en met AMP for Endpoints kan je een host opschonen. (Zonder hem opnieuw te hoeven reimagen.)

[Equator]

Even de discussie in de juiste richting sturen.. Prima dat er gediscussieerd wordt over het hele AVG component bij logging, maar we blijven wel normaal reageren tegen elkaar. We gaan elkaar niet verwijten zaken niet te weten, maar je legt het netjes uit - zoals Professionals moeten kunnen. Accepteer de ander zijn mening, of agree to disagree.


Mijn mening:
Soms moet je - in het kader van traceerbaarheid - gegevens opslaan die privacy gevoelig zijn. Daar moet je in grote organisaties met de OR om de tafel, en tegenwoordig heb je ook nog een DPO die je erbij kan betrekken. Dat zijn lastige discussies, en ja, soms moet 1 van de partijen water bij de wijn doen. Als het belang van het bedrijf groot genoeg is, dan kan dat dus inhouden dat er zaken worden gelogd die gebruikers eigelijk niet zouden willen.

Dit valt allemaal onder Risico Management. Wat is het risico, en hoever ga je om dit risico te verkleinen tot een acceptabel risico, en wat mag dat kosten.

Deze informatie is echter (zeer) gevoelig, en dient dan ook alleen inzichtelijk te zijn voor diegene die er toegang toe zou moeten hebben. Dat kan zomaar alleen de Security Officer zijn, en alleen op het verzoek van het Management omdat er iets onderzocht moet worden. De rest van de tijd heb je er gewoon niets in te zoeken. Zolang dat vast ligt, en er op gecontroleerd wordt, is er in mijn ogen niets mis met het loggen van netwerkverkeer.

En ja in het kader van een stukje vertrouwen naar je gebruikers is het niet verkeerd om de websites van banken uit te filteren. Maar dat is een lijst met bekende websites, die bijgehouden wordt door IT Security, of de Information Security Officer en geaccordeerd door het Management.

---

Welnu, terug naar de vraag van de topicstarter:

Hoe loggen jullie alles? Hoe zouden jullie met zulke vragen omgaan?

Ik kan over mijn huidige opdracht niet te ver uitwijden, maar alle interessante zaken worden centraal gelogd en geïndexeerd in Splunk. Alleen geautoriseerd personeel heeft toegang tot specifieke indexes. Zaken worden voor minimaal 1 jaar, en ik geloof maximaal 3 jaar bewaard (afhankelijk van het type log informatie).
Ik geloof dat er ongeveer 800GB aan logdata per dag wordt geïndexeerd, dus dat zegt wel iets over de grootte van de omgeving.

[kristofv]

Bl@ckbird schreef op woensdag 13 juni 2018 @ 00:49:
Bovenstaande oplossingen genereren alleen een alarm als er ook daadwerkelijk wat aan de hand is. Je hoeft dus niet logging door te spitten om een security event te vinden. De tooling doet dat voor jou en automatiseert de afhandeling van security events. Logbestanden / netflow records zijn beschikbaar, maar 9 van de 10 keer heb je dit niet nodig. ISE zet een geïnfecteerde host in een quarantaine VLAN en met AMP for Endpoints kan je een host opschonen. (Zonder hem opnieuw te hoeven reimagen.)

Modbreak:

Als je geen nuttige toevoeging hebt op het topic, blijf dan weg. Offtopic reageren op een waardevolle reactie is niet nodig.

[ Voor 30% gewijzigd door Equator op 13-06-2018 11:13 ]

[VHware]

M.b.t. bv malware / security threats maken wij gebruik van de Qmanage oplossing van Quarantainenet. Devices die ongewoon gedrag vertonen worden geïsoleerd.

Qmanage kan echter ook toegangscontrole doen (zowel draadloos als LAN) zodat er bekend is wie welk apparaat gebruikt.

[ Voor 28% gewijzigd door VHware op 13-06-2018 08:47 ]

[kristofv]

kristofv schreef op woensdag 13 juni 2018 @ 08:12:
[...]

Modbreak:

....

Reageren op moderatie doen we niet in het topic. Je mag mij een DM sturen of je meldt je in I&N Feedback-topic

[ Voor 57% gewijzigd door Equator op 13-06-2018 11:13 ]