Het scannen moet geautomatiseerd plaats vinden. Strikt gecontroleerde toegang tot de logs. Communiceer aan de medewerkers dat er automatische scanning plaats vindt. Bank verkeer mag niet worden gescand (Eis van DNB).

Maar, weet waar je aan begint, meestal is het dramatisch gesteld met de ssl breek spullen. Je bent verzekerd van een grote hoeveelheid extra werk omdat er weer iets legitiems geblokkeerd wordt.

Realiseer je dat alle self-signed certificates tot problemen gaan leiden, zeker als daar ssh of openvpn tunnels overheen gestuurd worden.

Het middel is in dit geval ernstiger dan de kwaal, installeer goede virusscanners op de werkplek en zorg dat de werkplekken niet met hoge rechten worden gebruikt.

EJ

1 april is al voorbij hoor.

Interessant.

(1) Waar staat dat en hoe had ik dat moeten weten? (ik word geacht de wet te kennen, shoot me, maar ik was me er niet van bewust dat ik iets met eisen van DNB zou moeten op dit punt).

(2) Eis aan wie? DNB houdt meen ik (en/of de AFM, wie wat doet is me niet helemaal duidelijk) toezicht op banken, voor zover ik weet niet op klanten van banken (ik bijvoorbeeld) en al helemaal niet op de verbinding tussen m'n PC en de server bij een bank.

(3) Welk mandaat heeft DNB voor het stellen van eisen aan verbindingen? Hoe denkt DNB dit beleid te gaan handhaven? Stel ik ben werkgever en scan alle SSL/TLS verkeer, dus ook IP bankverkeer van m'n medewerkers, pleeg ik dan een strafbaar feit? Kan DNB me voor de rechter slepen, een medewerker, of beiden? Bestaat er jurisprudentie op dit punt?

(4) Welke eisen stelt DNB aan hardware en software voor en achter de tunnel (of denk je dat een beetje modern "Internet Security" pakket op PC's niet in de gaten houdt wat er die tunnel in gaat en er weer uitkomt)? Stelt DNB eisen aan het OS, webbrowser-fabrikant, versie, aanwezige plugins, simultane tabs of vensters naar andere websites (XSS)? Mag ik als werkgever wel een keylogger op PC's van m'n werknemers installeren, of moet die stoppem met loggen zodra het om "bankverkeer" lijkt te gaan?

(5) Stelt DNB eisen aan de beveiliging van servers bij banken, en van de gebruikte encryptie/hashing/certificaten technologie (zie bijv. http://www.security.nl/artikel/19151/1/Bijna_helft_banken_gebruikt_geen_SSL.html en http://www.security.nl/artikel/30362/%22Websites_Nederlandse_banken_onvoldoende_beveiligd%22.html)? Moet op die servers juist wel of juist niet een virusscanner draaien? En bijv. een Web Application Firewall, mag dat wel?

(6) Als het openbreken van SSL/TLS bedoeld is om verkeer aan de klant zijde op illegale activiteiten (waaronder malware) te scannen, waarom zou dat niet mogen (en 4 wel?)

(7) Stel je breekt SSL/TLS by default open bijv. op een Astaro UTM appliance. Op basis waarvan zou die UTM dan moeten besluiten om "Bank verkeer" niet te MITM-en? IP-adressen vam banken of zo? Publiceert DNB een lijst daarvan?

(8) Als DNB dan zo nodig toezicht wil houden elektronisch bankieren, waarom treden ze dan niet eens op tegen banken die weigeren versneld niet-zo-eenvoudig-te-skimmen-pinautomaten in te voeren?

Toen het bijna 1 april was kon je hier: http://www.security.nl/artikel/32871?version=normal lezen dat het bedrijf Packet Forensics apparatuur aanbiedt om SSL/TLS verbindingen te MITM-en. In mijn bijdrage daaronder van 27-03-2010, 00:31 kun je lezen hoe dat werkt, en dat bijv. SonicWall zoiets voor de "klant-zijde" verkoopt. Astaro kan dit trouwens ook. En nee, dit was en is geen 1 april grap.

ad 1 zoek en denk na. En nee, het verhaal dat jij de wet hoort te kennen staat sinds het NBW al niet meer in de wet. Broodje aap.
ad 2 DNB houdt toezicht op bancair verkeer, dus ook verkeer _naar_ banken.
ad 3 ja, je pleegt een strafbaar feit, je doorbreekt een beveiliging. Had je zelf kunnen bedenken.
ad 4 DNB gaat niet over de inhoudelijke invulling. nee, dat mag niet en weet je best. Zie 3.
ad 5 Ja, er worden eisen gesteld, maar alleen in algemene termen. Wordt afgedwongen met audits (waarbij een bank de licentie zou kunnen kwijtraken).
ad 6 je zegt het zelf al, zie 4 en 5
ad 7 dat is een zaak van astaro utm appliance en niet de zorg van DNB. Ook dat weet je best. SSL verkeer mag nu eenmaal niet zomaar gebroken worden, zie 3.
ad 8 omdat ze dat op basis van europese afspraken niet kunnen. Zie SEPA.Er is een uitgebreid (nu verkort) traject ingevoerd om alle automaten aan de chip te krijgen. Dat moet op europese schaal gebeuren en is niet 1,2,3 klaar.

Niet goed ingevoerd in deze materie Bitwiper? Dat valt me een beetje tegen, had echt meer van je verwacht... Zaken zijn wel eens abstracter dan jij ze tegen bent gekomen.

EJ

Wat een ongelofelijk flauw antwoord nadat jij "Eis van DNB" roept (en dus kennelijk weet waar dat staat) en ik vraag waar ik dat kan vinden.Nou, dan zal ik de virusscanner op Exchange ook maar uitzetten, die schendt het briefgeheim!!! Wat een onzin.
Ik probeer als techneut bedrijven/organisaties en medewerkers daarvan, ook als ze elektronisch bankieren, te (helpen) beschermen, en te voorkomen dat abstractelingen maatregelen als "laat in de UK als test eerst maar eens vrachtwagens rechts rijden" een poot aan de grond krijgen met onzinnige, idealistische en verouderde maatregelen. Waarschijnlijk een verassing voor je, maar het dichtzetten van 6667/tcp in je firewall is al geruime tijd niet meer voldoende.

Ad 1 Nee ik weet niet 1,2,3 waar dat staat, maar het is impliciet in de bankwet opgenomen. Weinig zin om die wetten uit te gaan pluizen. Daarnaast kun je op je vingers natellen dat het niet mag.

Ad 3 Nee, want de rechter in Nederland heeft al lang geleden verzonnen dat email (niet encrypted) gelijk staat aan een briefkaart. Een briefkaart valt niet onder het briefgeheim. Dat argument vervalt. En bovendien, ik gaf duidelijk aan dat _alleen_ geautomatiseerd scannen mag, en zelfs dat zit al op of misschien wel over de grens van de wet bij het breken van een encrypted protocol. (Arnoud, case?)

Ik probeer techneuten te weerhouden van het roepen van technische oplossingen die wettelijk gezien niet mogen. De OP heeft een zeer goed punt dat hij zich probeert te orienteren _voordat_ hij iets doet dat niet mag.

Je mag even aangeven in mijn posts waar je denkt dat ik zeg dat je niet moet scannen, ik kan het niet vinden. Je mag ook even aangeven waar ik denk dat firewalls ueberhaupt voldoende zijn. En misschien een verrassing voor je, maar DNB heeft bij banken al geruime tijd geleden de eis gesteld dat verkeer, ook ssl verkeer, virus gescand moet worden. Misschien een nog grotere verrassing voor je technische kennis, maar niet iedere bank gebruikt windows, of pc'tjes voor afhandeling van transactieverkeer. Sun anyone? Tandem anyone? IBM anyone?

Leer als techneut het onderscheid te maken tussen wat _kan_ en wat _mag_.

Ik begrijp niet hoe jij aan kunt geven je op feiten te baseren, die niet terug kunt vinden en vervolgens als escape stelt dat je "het op je vingers kunt natellen" dat MITM-en van SSL niet mag: dat laatste kan ik dus niet en ga ik ook niet doen, want ik vind het onredelijk.

Desalniettemin goed dat dit soort discussies worden gevoerd, want als er al wetgeving zou bestaan (wat ik niet geloof) of overwogen wordt, die het MITM-en van SSL/TLS om verkeer geautomatiseerd te scannen op ongewenst verkeer zou verbieden, dan wil ik best argumenten aandragen waarom zo'n stompzinnige regel -waar alleen criminelen bij gebaat zijn- ASAP van tafel moet.

Overigens is het maar helemaal de (juridische) vraag of je met het openbreken van SSL/TLS in een UTM zoals van SonicWall en Astaro "een beveiliging doorbreekt"; ik vind van niet. Immers dit werkt alleen goed (d.w.z. zonder waarschuwing aan de gebruiker dat de verbinding mogelijk niet secure is) als het root certificaat van die UTM als trusted CA in de webbrowser van die gebruiker is opgenomen, iets dat elke gebruiker zelf kan constateren (ik raad gebruikers sowieso aan zich te verdiepen in hoe SSL/TLS werkt, en ook wat de consequenties kunnen zijn van het stellen van het vertrouwen in de enorme lijst van CA's van wie vaak meerdere root certificaten standaard in webbrowsers aanwezig zijn).

Wel vind ik het netjes en verstandig als je de gebruikers over zo'n MITM-maatregel informeert, maar ik twijfel er aan of je dat als werkgever verplicht bent - mits je de MITM uitsluitend toepast voor het geautomatiseerd scannen op kwaadaardig verkeer (dus niet met de bedoeling om het internetgedrag van 1 of meer werknemers te monitoren).

Leuke non-discussie over de DNB en SSL.... SSL inspectie vind al sinds jaar en dag plaats op diverse ministeries. Het is gewoon een kwestie van communiceren met je gebruikers.

Ik heb overigens ook een case aan de hand gehad, waarbij de beheerders banken en andere specifieke zaken gewoon niet onderscheppen. De 'grote' banken werden meteen toegevoegd en iedereen heeft ruim van te voren te horen gekregen dat men websites door kon geven belangrijke persoonlijke/financiële zaken over heen gaan.
Daarnaast zijn de meeste appliances e.d. er vaak niet op ingericht om ruwe data te verzamelen waar je door heen kan snuffelen. Die SSL inspection werkt verder net als een gewone IPS. Het verkeer wordt alleen even uitgepakt en daarna weer ingepakt... en daar hoor ik niemand over roepen dat het een inbreuk is op de privacy.

Je maakt wederom een aantal fouten:

Het is geen discussie of je ssl verkeer al dan niet geautomatiseerd mag breken, het mag ten principale niet. Je schendt de vertrouwelijkheid. Daar is geen andere wet voor nodig dan de huidige wetgeving. Zie diverse reacties van Arnoud hieromtrent. Net zo min is jouw _mening_ interessant of een UTM een beveiliging doorbreekt, feit is _dat_ het gebeurt. Daar hoef je niet over na te denken. Er is een een encrypted verbinding die wordt geopend, dus een vertrouwelijkheid die wordt beschadigd. Wat wil je nog meer? http://www.iusmentis.com/beveiliging/hacken/computercriminaliteit/computervredebreuk/ laat daar niets aan onduidelijkheid over bestaan.

Tenslotte is er geen enkele discussie of je al dan niet je werknemers moet inlichten. Dat is een _verplichting_, ook dat is redelijk recent door Arnoud nog aangestipt. Je mag als werkgever vrijwel niets, in ieder geval niet zonder je personeel op de hoogte te brengen (bijvoorbeeld door middel van gebruiksvoorwaarden die je laat tekenen). http://www.iusmentis.com/maatschappij/privacy/wet/ geeft je extra info.

O, en in http://www.dnb.nl/openboek/extern/id/nl/all/40-197671.html wordt verwezen naar het toezicht. Een van de effecten van dat toezicht is dat zij een en ander verplicht kunnen stellen. Je kunt vast wel bedenk wat. Zonder verder in details te mogen, willen of kunnen treden: http://www.hogewoning.info/page/2/ waar verwezen wordt naar banken die ssl inspection doen, tevens zie je daar de vraag over de rechtmatigheid naar voren komen. http://www.iusmentis.com/maatschappij/privacy/persoonsgegevens/...

Kernwoorden: 'Voorafgaande toestemming', 'Informatieplicht'. Die zijn ook van toepassing op persoonlijk verkeer of _jij_ het nu wel of niet leuk vindt.

Het feit dat iets technisch kan betekent echt niet dat het mag. Dat is jouw grootste denkfout. Ik ben het helemaal met je eens dat het fijn zou zijn als je al het verkeer zou kunnen scannen. Maar de wetgever stelt hier toch echt de bescherming van de persoonlijke levenssfeer boven het 'fijn zijn'.

EJ

"Ik zou zeggen: De organisatie inlichten, daarna WatchGuard gebruiken het SSL-verkeer scannen. Dat is alles."

Zegt de wet dat ook, of kijk je daar niet naar ?

Precies, waarom installeer je niet gewoon goede virusscanners?

Erg vreemd verhaal verder...

Je kunt alle SSL verbindingen openen met de CompuWall de firewall van Compumatica, een Nederlands bedrijf.
De gebruiker geeft hier uitdrukkelijke toestemming voor en als organisatie moet je aangeven dat je de scan enkel gebruikt om te controleren op virussen en malware. De virusscanner kan dan het werk doen.
Een bijzonder prettige en eenvoudige oplossing die goed werkt en volgens de wetgeving ingesteld kan worden.
Wij werken er al jaren mee.

Misschien dat je watchguard appliance source destination verkeer kan blokkeren als er bv in eens SSL verkeer van jou netwerk naar china gaat of iets dergelijks maar de inhoud zal je niet kunnen lezen want dat is versleuteld.

De mogelijkheid bestaat wel om een MITM uit te voeren door het certificaat af te vangen waardoor het lijkt dat de bron te vertrouwen is maar watchguard heeft niet zo'n product.

Er bestaan wel apparaten die het zouden kunnen:

http://www.wired.com/threatlevel/2010/03/packet-forensics/

All,

SSL verkeer mag geïnspecteerd word, mits je gebruikers erop attendeert dat je hun verkeer monitoort.
Het is fatsoenlijk om financieel verkeer niet te bekijken, maar er is naar mijn beste weten geen enkele richtlijn van DNB dat dit niet mag worden gedaan. er URL filtering systemen die obv de categorie SSL inspectie aan of uit zet.

DNB en AFM zijn verantwoordelijk voor de beveiliging van de financiële systemen bij de banken, en hebben geen mandaat bij "gewone" bedrijven, dat zou te gek voor woorden zijn.

Wanneer een organisatie, niet zijnde een bank oid, hun netwerk verkeer wil inspecteren is volgens mij het goed recht van deze organisatie om dit te doen, nogmaals met medeweten v/d gebruikers.

het is en blijft een informatie systeem van de organisatie, en SSL interceptie is te vergelijken met Email archivering.

anyway, my 2ct on the issue.

Wat een onzin dat dit wettelijk niet zou mogen. Zoals eerder gezegd is het een kwestie van met de gebruikers communiceren. Als je van te voren aangeeft dat AL het verkeer, ook SSL verkeer, gescand wordt door automatische systemen dan is het aan de gebruiker zelf om te beslissen of hij die verbinding dan nog vertrouwelijk genoeg vindt om zijn bankzaken te doen. Onze Bluecoats doen dat al jaren. We zijn zelfs verplicht omdat we de werkplekken te beschermen tegen ongeauthoriseerd meekijken door diensten zoals logmein. Aangezien dat soort diensten een SSL tunnel via de proxies opzetten is een MITM die controlleerd of er wel daadwerkelijk HTTP in de tunnel gesproken wordt de enige manier om dat te stoppen.

Ten eerste bestaan er geen "goede" virusscanners, alleen slechte en waardeloze (wel kunnen ze je PC goed om zeep helpen, McAfee heeft dat in relatief korte tijd 2x gepresteerd). De makers van virusscanners geven steeds vaker zelf aan dat de stroom gewijzigde malware niet meer bij te benen valt en dat door het grote aantal virusdefinities 1) de kans op false positives toeneemt en 2) de belasting van de PC soms onwerkbare vormen aanneemt (geheugengebruik, vertragingen in file-I/O maar ook in het openen van kleine mails in MUA's als Outlook, netwerk I/O voor het meerdere keren per dag bijwerken van geheugen definities, extra lange bootfase, en -minder belangrijk- schijfgebruik). Zie http://www.security.nl/artikel/33595/1/SoftPerfect_Netscan%3A_Trojan_of_false_positive%3F.html voor een voorbeeld dat laat zien dat virusscanners totaal onbetrouwbaar zijn (ik kan je nog wel meer vooorbeelden geven als dat nodig is).

Ten tweede: doordat virusscanners altijd met een zekere vertraging werken kun je nooit 100% uitsluiten dat er malware op PC's gestart wordt. Zelfs onder een ordinary user account bestaat er vervolgens een risico dat de malware een bruikbare privilege escalation kan toepassen en vervolgens een rootkit installeert en/of de virusscanner uitschakelt, waarmee je de alsnog-detectie door de virusscanner in de dagen erna wel kunt vergeten.

Belangrijk is te weten dat er vaak allerlei andere bestanden naar de PC worden geupload door de aanvallers; de kans op detectie van die bestanden is vaak groter dan van de dropper en de eerste "echte" malware die gedraaid wordt. Echter, omdat in de meeste gevallen de virusscanner is uitgeschakeld of om de tuin wordt geleid, kun je niet meer rekenen op de PC. Derhalve zul je naar de communicatie tussen de PC en de buitenwereld moeten kijken. Echter aanvallers zijn ook niet stom, die gebruiken daar versleutelde connecties voor. De remedie is om uitsluitend versleutelde connecties tot te staan die je kunt "openbreken" (wat het feitelijk niet is, zie de discussie hierboven) en vervolgens op malware of andere ongewenste patronen te doorzoeken, en de overige versleutelde verbindingen te blokkeren.

Het hoeft daarbij niet alleen om malwaredetectie te gaan: je kunt ook zoeken naar patronen van vertrouwelijke gegevens die je pand verlaten (het kan daarbij om jouw persoonsgegevens of creditcardnummer gaan). Afhankelijk van het type organisatie genoeg redenen om zo'n scanner te installeren.

*Proest* Eerst betoog je dat er geen goede virusscanners bestaan en vervolgens betoog je dat diezelfde virusscanners wel goed zijn in een ssl sniffer? En dan ook nog een verhaal over vertraging? Dat geldt net zo hard voor de ssl sniffer hoor, voor het geval het je nog niet was opgevallen. Je argumentatie wordt steeds zwakker.

Let op: ik betoog helemaal nergens dat je _niet_ moet scannen, maar geef een aantal randvoorwaarden. Verlies niet de uitgangspunten uit het oog.

EJ

Nee, dat betoog ik niet. Sterker, virusscanners in netwerkapparatuur zijn altijd zwakker dan op desktops; het uit netwerkpakketjes samenstellen van een bestand is gewoon lastig en niet zo moeilijk te omzeilen (het is gebuikelijk om in de configuratiegegevens een max. te scannen bestandsgrootte aan te treffen). Bovendien, met een scanner in zo'n UTM bedoel ik niet alleen een "virusscanner" (zie de onderste alinea in m'n bijdrage) maar een op het scannen van netwerkverkeer geoptimaliseerd softwarepakket zoals bijvoorbeeld SNORT.

Desalniettemin neemt de kans op detectie van malware toe als je twee verschillende scanners (in dit geval op verschillende plaatsen) toepast. Toegegeven, de kans op false positives neemt daar ook mee toe (maar dat staat los van het "openbreken" van SSL). Denk er aan dat, op het moment dat malware op een gecompromitteerde PC de virusscanner (of de updatefunctionaliteit ervan) heeft uitgezet, die scanner in je netwerk-appliance mogelijk je laatste strohalm om te signaleren dat er een PC aan je netwerk "van eigenaar is veranderd".
Klopt. Malwaremakers prutsen net zo lang aan hun "droppers" totdat deze niet meer door de meestgebruikte virusscanners worden herkend. Daarmee is de kans groot dat zo'n dropper noch door de UTM (in het geval van webmail via SSL dus opengebroken door die UTM) als door de desktopvirusscanner wordt herkend. Laten we er gemakshalve maar even van uitgaan dat ook andere functionaliteit in de UTM die dropper niet herkend.

Die dropper zal dus ongehinderd op de PC belanden en starten. Over het algemeen zullen deze proberen de virusscanner op de desktop PC uit te schakelen en te voorkomen dat andere beveiligingssofware wordt geinstalleerd. E.e.a. om te voorkomen dat de malware die daarna naar de PC gestuurd wordt wordt (om bijv. mee te spammen, DDOS attacks uit te voeren, game-keys en/of bankgegevens te stelen) wordt gehinderd door beveiligingssoftware op de PC.

Vanaf dat moment zal de PC zelf niets meer detecteren (hooguit kan de gebruiker alarm slaan dat de PC traag is geworden). Echter, de UTM virusscanner (en IDS zoals SNORT) werkt natuurlijk nog wel, die kan al het verkeer tussen de PC en het internet monitoren. Als de UTM versleuteld verkeer via de poorten 80/tcp en/of 443/tcp voorbij ziet komen dat hij wel kan openbreken (omdat het SSL/TLS, dus certificaat-gebaseerd is) kan dat verkeer inhoudelijk worden gescanned; als het daarbij om semi-random data gaat (bijv. SSH over die poorten) dan kan de UTM daarover alarm slaan.
Volgens mij was jouw uitgangspunt waar ik op reageerde:Dat het daarbij om een eis van DNB zou gaan heb je niet aan kunnen tonen. Het enige DNB document waar je naar refereert is http://www.dnb.nl/openboek/extern/id/nl/all/40-197671.html (PDF!) met als subtitel: "Beleidsvisie en aanpak gedrag en cultuur bij financiele ondernemingen 2010-2014" dat zo te zien richtlijnen beschrijft voor financiele instellingen en niet voor hun klanten.