Respect voor alle medewerkers en externen die hun kerstvakantie en vermoedelijk veel nachtrust hebben opgeofferd om de boel weer aan de praat te krijgen!

Ik hoop wel dat de UM uiteindelijk een waarheidsgetrouw kostenplaatje publiceert en dat dit een goede waarschuwing zal zijn voor organisaties die denken dat het zo'n vaart niet zal lopen...

Respect voor alle medewerkers en externen die hun kerstvakantie en vermoedelijk veel nachtrust hebben opgeofferd om de boel weer aan de praat te krijgen!

Ik hoop wel dat de UM uiteindelijk een waarheidsgetrouw kostenplaatje publiceert en dat dit een goede waarschuwing zal zijn voor organisaties die denken dat het zo'n vaart niet zal lopen...

Fraai gezien met het tussen de regels door lezen.

Dat staat er gewoon:
"Kan ik zelf controleren of de monitoringsoftware is geïnstalleerd?
Ja dat kan. Open de 'Task manager' en zoek naar het proces 'Cb Response Sensor'. Als dit proces loopt, dan is de software succesvol geïnstalleerd."

Daar kan ik het helemaal mee eens zijn Erik.

Zorgelijk vind ik het feit dat er een nieuwe Clop-variant is opgedoken die 663 processen probeert af te sluiten. Hierdoor zijn de bestanden na afsluiten gewoon te encrypten door de malware. Naar mijn bescheiden mening moet er iets op gevonden worden dat een buitenstaander (ook malware) niet zomaar processen kan afsluiten. Wie heeft daarover een goed idee? Het zou een ransomware aanval op elk OS behoorlijk kunnen frustreren.

Mijn excuses voor mijn dubbele post bovenaan (ik heb geen idee wat dat veroorzaakt heeft).

Zeker weten complimenten voor deze stress periode, dan kunnen ze nu eindelijk aan het Kerstontbijt beginnen.

Dan kunnen ze meteen brainstrormen over hoe ze een nieuwe infrastructuur op moeten gaan zetten.

Eenvoudig te reproduceren met een dubbele klik (?)

Eenvoudig te reproduceren met een dubbele klik (?) Yep. @Redactie: dat is dus een bugje.

Omdat ze alle systemen weer online hebben maar data missen na 23 december en het probleem op de 24ste was ontstaan gok ik erop dat ze een backup hebben terug gezet.
Backups terug zetten van zo'n grote omgeving kost wat man uren.

Carbon Black is multi-platform:
https://www.upguard.com/articles/carbon-black-vs.-symantec-endpoint-protection

"(CarbonBlack) uses a hash database of software trust ratings— the Carbon Black Software Reputation Service—to determine which files to whitelist (..)

Security Ratings
UpGuard's VendorRisk platform is used by hundreds of companies to automatically monitor their third-party vendors. We ran a quick surface scan on both Carbon Black and Symantec, and found them to have similar scores:
Carbon Black - 713 / 950
Symantec - 733 / 950

Our quick assessment showed that both companies carry similar risks which include:

- Increased susceptibility to man-in-the-middle attacks through incomplete support for HTTP Strict Transport Security (HSTS). Although, Symantec is in a weaker position here as they do not even enforce HSTS.
- Exposure of their web server details, such as name and version numbers. These can be run against CVE (Common Vulnerability and Exposure) lists by attackers looking for weaknesses.
- DNS being susceptible to man-in-the-middle attacks, as neither enforces DNS Security Extensions (DNSSEC) on their domain.
- Potential for emails to be fraudulently sent from their domain by spammers, as neither company enforces Domain-based Message Authentication, Reporting and Conformance (DMARC).

Based on their score, Carbon Black edged out Symantec. But both companies have work to do in maintaining good security hygiene and best practices for themselves ..."

Is dit wel een goede "Security Rating"?
Is Snort een goed alternatief?

Het hele probleem is het identificeren van buitenstaander en niet-buitenstaander. Als dat eenvoudig was, was malware niet of nauwelijks een probleem.

Nergens de naam Carbon Black en dat het tegenwoordig een Vmware product is. Overgenomen n 2019.
Vreemd is dat het nu er bij geïnstalleeerd wordt. Alsof ze wel een contract hadden of een plan, maar nog niet doorgevoerd.

Vraag me af of deze kosten ook berekend zijn door Munchen en de uni toen ze weer van linux naar windows gingen omdat het zogenaamd veiliger en goedkoper was... in de meeste linux omgevingen kan een gebruiker niet zomaar processen stoppen...

Het is juist omgekeerd: Linux heeft betere mogelijkheden om processen te stoppen dan Windows. De eigen processen natuurlijk, die van het systeem - dat is hetzelfde bij Windows en Linux - kan je niet zomaar stoppen (geen rechten). Bij Linux is een kill gewoon een echte kill en bij Windows is het meer een vraag van wilt u zichzelf s.v.p. om zeep helpen.

How Signal Handling Works - https://www.memecenter.com/fun/804400/how-signal-handling-works

hmmmm


lees https://cdn.www.carbonblack.com/wp-content/uploads/2018/07/Live-Response-Datasheet.pdf

en dan

"In 2013, the company's network was broken into by malicious actors who copied a private signing key for a certificate and used it to sign malware.[10] "

op https://en.wikipedia.org/wiki/Carbon_Black_(company)


krijg nu niet een warm fuzzy gevoel zelf.

Als je een backup policy hebt, dan heb je een RPO en RTO gedefiniëerd. Meestal is dit per applicatie vastgelegd aangezien er nu eenmaal belangrijke en minder belangrijke applicaties zijn.

De "Recovery Point Objective" is de maximale tijd ("Point in time") dat de data oud mag zijn en bepaald de frequentie van je backups. (Wil je dat data maximaal 24h oud is, dan dien je minstens elke 12 uur een backup te maken.

De "Recovery Time Objective" is de maximale tijdsduur die nodig is om data te restoren. vb: 4h, 8h, 48h.
Dit bepaalt natuurlijk hoe lang je downtime zal zijn en welke SLA je logisch gezien kan aanbieden aan je klanten als je zelf een service aanbied.
(Dit heeft niets te maken met clustering of failover. Als iemand per ongeluk data wist of manipuleert, is een restore noodzakelijk.)

Het probleem is dat deze RTO/RPO waardes mischien wel bepaald werden, maar dat de implementatie van het achterliggende backup/restore process vaak kinderachtig is.
Je moet namelijk niet per "applicatie" denken als in de situatie dat "alles goed gaat". Het terugzetten van een backup is nu net voor in het geval dat het niet allemaal goed gaat.
Je moet deze RTO/RPO namelijk proberen te halen tijdens een disaster als alle systemen down zijn, of terwijl je nog actief aangevallen wordt. Dit heeft rechtstreeks invloed op de gebruikte infrastructuur, processen en chain-of-command in dergelijke noodsituaties.

Wat is er vreemd aan dat het (CB) er nu bij geïnstalleeerd word? Er kan tijdens de calamiteit een team bezig geweest zijn met het nemen van maatregelen om herhaling te voorkomen?

Precies, dat zei ik ook. Dus mijn vraag blijft: wie bedenkt iets tegen het zomaar afsluiten van processen?

Dit lijkt me niet je grootste zorg. Integendeel, het kan ook helpen bij vroegtijdige detectie van malware.

Het doel van de criminelen is zelden het kunnen versleutelen van programmabestanden (want daar zijn altijd wel originelen van te vinden), maar van databestanden (Word files, Outlook local cache etc.) en configuratiebestanden die "gelocked" zijn zolang de applicatie draait.

Ik zie alweer iemand Linux vs Windows liegen. Zowel onder Windows als onder Linux kan een gewone gebruiker geen systeemprocessen afsluiten (anders dan door een shutdown of reboot uit te voeren). Als de gebruiker, die de malware heeft opgestart, root- of administrator privileges heeft, of als de malware die privileges weet te verkrijgen via een exploit, kan die malware ook systeemprocessen afsluiten (inclusief virusscanner en andere beveiligingssoftware zoals firewall). Dit is niet anders onder Linux dan onder Windows.

Het is heel simpel: malware mag wat jij mag. Ik zou het heel vervelend vinden als ik processen, die ikzelf gestart heb, niet mag stoppen (desnoods geforceerd, zoals nodig zou kunnen zijn bij aanvallen zoals deze https://www.bleepingcomputer.com/news/security/fake-windows-10-desktop-used-in-new-police-browser-lock-scam/) of een applicatie die hangt - om welke reden dan ook.

Belangrijk vind ik wel dat we privilege escalation kwetsbaarheden voorkomen, en anders ze vinden en patchen voordat criminelen er misbruik van kunnen maken. M.i. worden dergelijke kwetsbaarheden veel te vaak gevonden in productiecode, en krijgen ze een te lage "risicoindex". Ze worden zowel in Windows- als in Linux code gevonden (kijk maar eens hier, Duitstalig: https://www.cert-bund.de/overview/AdvisoryShort).

Het is juist omgekeerd: Linux heeft betere mogelijkheden om processen te stoppen dan Windows. De eigen processen natuurlijk, die van het systeem - dat is hetzelfde bij Windows en Linux - kan je niet zomaar stoppen (geen rechten).

Als je bovenstaande opmerking bedoeld: Hij schrijft ook niet dat een gebruiker systeemprocessen af kan sluiten.

@Sjef van Heesch Denk dat het over de passage ging waar mijn opmerking een antwoord op was. Te weten: in de meeste linux omgevingen kan een gebruiker niet zomaar processen stoppen.... [N.B.: je hebt noch onder Linux, noch onder Windows als gewone gebruiker de rechten om systeemprocessen te stoppen].

Ook draaien de meeste applicaties draaien er ook niet op.

RTO/RPO worden normaal gesproken bepaald voor afzonderlijke applicaties, voor het geval die applicatie, en/of de data, teruggezet moet worden.

RTO/RPO bepaling als alles kapot is, is niet te doen. Dat heeft veel te veel afhankelijkheden. Wat tel je dan mee? Ransomware, waarbij je alleen de data terug hoeft te zetten? Of houdt je er ook rekening mee dat je eigenlijk ook al je systemen schoon moet opbouwen? En hoeveel? Als je de RTO/RPO bepaling hebt gedaan, moet je dan die iedere maand herzien, omdat het aantal systemen en applicaties wijzigt.
Wat als het geen ransomware is, maar een brand. Houd je dan rekening met de levertijd van de systemen? En de opbouw van het netwerk, inclusief routers en de internetaansluiting. Misschien zelfs de nieuwbouw van de computerruimte.

Voor grootschalige problemen heb je geen RTO/RPO bepaling. Dan werk je met herstel- en calamiteitenplannen.

Peter

Als het nu er bij geïnstalleerd moet worden dan hadden ze het voorheen niet. Inderdaad bij de calamiteit lijkt dit een van de vele veranderingen te zijn die is doorgevoerd. Vragen:
- Wat hadden ze dan voor die tijd.
- De opmerking dat het zelf gecontroleerd moet worden duidt er op dat die niet centraal beheerd/gemonitored worden.
- De athena desktop lijkt wel een centraal beheerd iets te zijn. Je mag zelf controleren, maar IT support komt op je af.
- Het lijkt me niet iets voor de byods (studenten) of dat zou nu daar als aparte download (licentie thuisgebruik) vrijgegeven moeten zijn.

Eens kijken naar: https://www.carbonblack.com/products/ dan zie ik een compleet framework voor een in huis SOC center. Logisch als ze Vmware virtualisatie gebruiken. Het is niet hetzelfde als een thuissituatie met een virusscanner.
Dan geloof ik dat je een teken hebt dat ze het al wel in huis hadden. Vermoedelijk al een plan voor de uitrol klaar hadden liggen, maar er nog niet aan toe gekomen waren.

Eens, het uitbranden van een enkele server door een fysiek probleem dan wel verkeerde uitrol van een release kan je met RTO/RPO doen. Een grote calamiteit niet, je moet dan van alle betrokken hardware alles wat er boven zit opnieuw gecontroleerd schoon opbouwen. Een beperkte DR oefening laat gewoonlijk al vele problemen zien. Het is zeer kostbaar.

Welke downtijd is acceptabel?
Als de computer bij de balie van een garagebedrijf weg is dan zullen echt wel verder kunnen.
De bediening in een restaurant zou ook zonder techniek nog moeten kunnen werken. Toch twijfel ik daar met reden aan.
Ooit zou een verzekeringsmij rusting de computers twee weken kunnen missen zonder dat het opgemerkt wordt.

Dat er nu in die tijd weer iets werkbaars draait daar bij het UM is een positief punt. Zij hoeven geen gegarandeerde beschikbaarheid te hebben. Bij andere organisatie kan dat anders liggen.

en daarom heb je een BIA. Het is nooit ons (IT/security) feestje; de business geeft financiën

Eminus