In plaats van die enquete opnieuw in te vullen zal ik je een waargebeurd verhaal vertellen over security-vermoeidheid.
Ik werkte destijds als Linux-beheerder bij een groot internationaal bedrijf, de naam en specifieke details laat ik vanzelfsprekend achterwege. Hoewel de nederlandse tak van het bedrijf een eigen (in Nederland gevestigde) IT afdeling had, kwam er steeds meer invloeden vanaf de Amerikaanse (management) en Indiaase (ICT) takken en vooral op security werden bepaalde bijzondere keuzes gemaakt. Eerst even een voorbeeldje om te illustreren hoe de verhoudingen zijn...
Zo moest ineens alle logging naar Splunk gestuurd worden, dus we moesten verplicht op alle Linux VM's een splunk-agent zetten en op onze VMWare omgeving kwamen Splunk-forwarders te staan die alle logging doorstuurde. De reden: "Als er iets mis gaat op de omgeving dan kunnen we aan de hand van de logging zien wat er mis is en hoe het zich verspreidt." Prima reden op zich, ware het niet dat wij als Linux beheerders 'for security reasons' geen toegang kregen tot de Splunk-omgeving. Zelfs de forwarders waren voor ons black-boxes waarvan het beheer compleet bij onze Indiaase collega's lag. Onze eigen logging moest er naartoe, maar we mochten het zelf niet meer inzien. Wel kwamen we er uiteindelijk bij toeval achter dat het OS van de forwardes al langere tijd niet meer supported was. Er werd dus geen onderhoud op gepleegd.
Op dezelfde manier werd ook CyberArk door geduwd. Waar wij voorheen een eigen LDAP omgeving hadden en inlogden met public/private keys, en waar gebruikers net genoeg rechten hadden om hun taken te kunnen uitvoeren, moest ineens CyberArk de dienst uit gaan maken. Met de Splunk ervaring in het achterhoofd hebben wij van alles uit de kast getrokken om dat tegen te gaan, maar dat mocht niet baten. En inderdaad, history repeats itself. Ik kan hier een heel uitgebreid over de inrichting uitweiden maar die rant zal ik jullie besparen. Kort samengevat, door CyberArk of de gebrekkige implementatie daarvan is onze security op bepaalde vlakken verlaagd in plaats van verbeterd. Zonder dat het mijns inziens echt tot een verbetering heeft geleid. Bijvoorbeeld:
- Cyberark 'does not support publik key', dus we moesten wachtwoordauthenticatie over de gehele linie inschakelen. Dat gaat machine-breed, dus niet per gebruiker. Voorheen kon een gebruiker alleen inloggen met een public/private key en had zijn wachtwoord nodig voor geprivileerde sudo-acties. Na deze change kon iedere gebruiker met zijn wachtwoord inloggen.
- Cyberark 'does not support ldap, only windows'. Als CyberArk kan verbinden met Active Directory dan kan hij dat ook met LDAP. Bovendien konden wij een trust opzetten met de AD of desnoods de machines in AD hangen. Maar meedenken mocht niet en zo waren er op elke machine 3 lokale cyberark users die root mochten worden en waarbij CyberArk de credentials beheerde. ELKE gebruiker die inlogt werd automatisch root en mocht ALLES.
- 'Don't worry, Cyberark logs everything!'. Ons bezwaar dat we nu niet meer konden zien wie wat op de machines had uitgevoerd werd van tafel geveegd. Cyberark zou alles loggen, via een MITM-bastion-host werden SSH verbindingen in de gaten gehouden en als je via het portal verbond dan kreeg je een mooie RDP-sessie met Putty. In overleg met het management heb ik een scriptje geschreven die eerst de tekstkleur en achtergrond beide op zwart zette om vervolgens de machine finaal te slopen en uiteindelijk de history te wissen. Even een testservertje gepakt en dat script in de putty-sessie geplakt. Er leek niets te gebeuren, maar die machine werd onzichtbaar vakkundig gesloopt. Daarop heeft mijn manager een verzoek ingediend om te onderzoeken wat er met die server aan de hand was. India kon daar geen goed antwoord op geven, maar wezen wel meteen mij aan als schuldige. Maar WAT ik heb gedaan bleef voor hun een raadsel. En nee, de history-files werden niet naar Splunk gestuurd en de audit-log was default geconfigureerd. Hadden ze dus ook niets aan. Gelukkig was het een doelbewuste test op een speciaal daarvoor opgezette testserver, in de (helaas vergeefse) hoop dat ze er iets uit zouden leren.
- Ook kwamen we er achter dat de bastion-hosts nog DSA-hostkeys uitstuurden. Na wat gepiel kregen we toegang tot zo'n bastion-host en bleek dat die ook verouderd was. Wederom geen onderhoud.
Zo kan ik nog vele voorbeelden bedenken waardoor ons security-level achteruit is gegaan met de introductie van CyberArk. Waarmee ik niet wil zeggen dat het aan CyberArk ligt; helaas heb ik er alleen als gebruiker ervaring mee. Maar zoals CyberArk bij ons werd neergezet, daar lusten de honden geen brood van.
Met die voorbeelden in het achterhoofd, zal ik je vertellen hoe onze werkdag er ongeveer uit zag:
- 's ochtends als je je laptop aanzet log je in met het Windows account op je laptop.
- Vervolgens ga je naar CyberArk instance 1 voor je dagelijkse wachtwoord van je admin-account. Die CyberArk portal heeft een timeout van 30 minuten. Dat wachtwoord is nodig voor toegang tot verschillende admin-portals en... CyberArk instance 2.
- Want met dat admin-wachtwoord uit CA-instance 1, log je in op CA-instance 2. Die portal kan je toegang verschaffen tot de servers. Normaliter zie je enkel je eigen servers daar. En als je een nieuwe server inricht (dagelijkse kost) kon het een week duren voor hij daar zichtbaar werd.
- Als alternatief op het tweede portal konden we ook verbinding maken met een SSH-bastion-server die ons dan doorlogde naar de Linux-server. Maar dat kon alleen naar de servers die je ook in het portal zag. Wederom werd je meteen root.
- Eenmaal ingelogd op de server (of het nu via de portal of de SSH-bastion was), werd de server na 15 minuten inactiviteit verbroken.
- Als de verbinding verbroken was, was het onwaarschijnlijk dat je het dagelijkse admin-password nog in je klembord had zitten. Dus je mocht weer inloggen op portal 1, weer naar portal 2, weer naar de server....
Even koffie halen, lunchen, naar het toilet... of zelfs even op een andere server bezig zijn zorgde er gewoon voor dat een andere sessie afbrak en je weer opnieuw kon beginnen. Moest je dus meerdere zaken op verschillende machines tegelijk uitvoeren, dan moest je wel zorgen dat een machine niet langer dan 15 minuten moest wachten. Want anders gaf die een timeout, verween het venster (inclusief alle output, dus was die vorige actie nu gelukt of niet?) en had je grote kans dat tijdens al het inloggen andere sessies er ook uit klapten. Andere software gebruiken was uit den boze en kon ook vaak niet. Via RDP zat je sowieso vast aan (een verouderde) Putty en SSH kon alleen met de ingebouwde SSH-client op de macbook. Maar omdat alle wachtwoorden dagelijks werden veranderd kon je ook niet goed iets verscripten. Bedenk ook dat elk account op elke machine een ander random-wachtwoord had. Je kon dus niet gemakkelijk van user1@server1 doorloggen (of een bestand versturen) naar user1@server2.
Je was continu aan het vechten tegen de timeouts en slimme manieren aan het bedenken om (bijvoorbeeld) file X van server Y naar server Z te verplaatsen. Een nieuwe server inrichten? VMWare template uitrollen en het IP-adres doorgeven aan India. Dan een week wachten voor de server zichtbaar werd in de CyberArk portal en je eindelijk verder kunt.. Oh ja, en bij voorbaat een paar servers uitrollen 'voor de toekomst' ging niet; de hostname moest aan een stricte conventie voldoen en mocht niet meer gewijzigd worden.
Dus omwille van een paar managers die niet gehinderd door enige vorm van technische kennis hun zin naar beneden doordrukken is het werk bijna ondoenlijk geworden. En als het nu nut zou hebben he, dan kan ik daar nog enigsins inkomen. Maar we zijn er security technisch enorm op achteruit gegaan en het levert alleen maar ellende op. Oh en had ik al gezegd dat die CyberArk portals 'in the cloud' draaien en dat de EU portal buiten EU-kantoortijden wordt afgeschaald? Succes om 's nachts 4 sessies tegelijk te openen. Gaat echt onwerkbaar traag. Zeker om 3 uur als de backup ook nog eens intrapt. Ook dat af- en bijschalen ging wel eens mis waardoor die portals er gewoon even uitlagen.
Je zou voor minder security moe worden... Deze idioterie heeft er overigens wel toe geleid dat ik mij conclusie heb getrokken en een andere baan heb gezocht. Als ik geen plezier meer in mijn werk heb, niet de kwaliteit en snelheid kan leveren die ik wil dan heb ik daar niets meer te zoeken.
Al mis ik het soms wel hoor, die discussies met India waarom een VM binnen VMWare geen redundante netwerkpaden met de Virtual Switch kan leggen. 'Yes, but according to my MoP we have to do it'. India; ik zou er echt niet kunnen werken.
/u/28468/librarian2.png?f=community)
:strip_icc():strip_exif()/u/132250/d1ca484677dbb1382705e67689809639.jpeg?f=community)
:strip_exif()/u/26632/dosprompt2.gif?f=community)
:strip_icc():strip_exif()/u/373702/crop5e4e5f1810483_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/11942/001.jpg?f=community)
:strip_exif()/u/310429/gif_70x53_c2f20f.gif?f=community)
/u/590360/crop646f4f0d1d2aa.png?f=community)
/u/161146/crop59d7c7d153cce.png?f=community)
:strip_icc():strip_exif()/u/145751/check-in-minion-small2.jpg?f=community)
:strip_icc():strip_exif()/u/8430/logo.jpg?f=community){kind=logo}
/u/365254/crop62e2919a741c0.png?f=community)
:strip_icc():strip_exif()/u/18112/avatar.jpg?f=community){kind=avatar}