Efter intrånget: Tietoevry anser att de har hög säkerhet

Jag har arbetat med införande av nya it-system inom vården. Alla it-system jag kom i kontakt med där var gamla, eländiga och dyra. Det enda som uppfyllde användarnas behov var ett vb6-hack som skulle skrivas om till dotnet, vilket skulle ta 15 år.

Jag har full förståelse att vården använder fax. Det är nog ett av få tillförlitliga sätt att överföra information mellan system. Trots allt onödigt dubbelarbete.

Det är nog inte ett rykte längre; "Många patientuppgifter kommer inte att gå att återställa alls."
https://www.svt.se/nyheter/lokalt/skane/efter-hackerattacken-...

Den kan ju bli lite jobbig, då kommunen har ett ansvar att ha ordentliga backuper så att sånt i ska försvinna. Är väll lagkrav på hur länge vissa saker ska finnas kvar och hur synd detta än är så bör ju kommunen faktiskt ha ett litet ansvar i att veta så att man har säkra backuper, även om man lämnar över driften. Försvarar inte TE, detta är ju något som kommer kosta dom mycket och det kommer vara svårt att återhämta sig, men det är samtidigt inte första gången som dom får generalknas.

Jag kan ju bara hoppas att TE inte vinner nästa upphandling med kammarkollegiet.

Jodå, det går om man gör dumma saker som sånt här:

vdc-repo.vmware.com/vmwb-repository/dcr-public/d1902b0e-d479-46bf-8ac9-cee0e31e8ec0/07ce8dbd-db48-4261-9b8f-c6d3ad8ba472/vim.vm.guest.AliasManager.html

VMware har också haft en strid ström av säkerhetshål i sitt automationslager de senaste månaderna, vilket kan men inte behöver vara relaterat.

Jag kan på ett sätt förstå att någon som bara stirrar på ekonomin säkert kan resonera så, men samtidigt haltar ju resonemanget så mycket att jag tycker det i sig borde verka något avskräckande.

Framförallt då hur det i liknelsen isf fungerar så att försäkringsnivå/premie är hårt sammankopplat med det egna risktagandet. Att välja en sämre försäkring ger alltså inte sämre förutsättningar OM något skulle hända, det ökar sannolikheten ATT något ska hända.
Och där rämnar ju en viktig del i resonemanget som slutklämmen byggde på; att "vi vet hur man undviker dem" (i den mån det var sant) inte skulle inkludera arbetet som man väljer bort.

Jag håller med dig. Avsikten med mitt inlägg var att försöka ge en lite mer nyanserad bild som svar på ”konsulter är inkompetenta”-budskapet i inlägget jag svarade på.

Det ”kan” vara så att ingen på TietoEvry har en susning om vad de pysslar med, men jag tror det är större chans att den som bestämmer vad teknikerna till syvende och sist får lägga tid på bestämde att det scenario man precis råkat ut för var så osannolikt att man inte ”i onödan” behövde göra det för jobbigt för sig till vardags.

Ja, det kan ju absolut finnas buggar i själva vSphere-sidan av detta, men det borde ju absolut inte påverkas av att man inte patchat VMware Tools *inuti* VM:en.

Aha, jag fattar, VMware Tools-buggen är något som man exploaterat *efter* man ägt ESXi-burken? Lite bakvänt alltså.

Bagdad Bob.

När det gäller hantverkare så är dom skyldiga att ge kunden råd på ett sätt som är rimligt och resurseffektivt. Om kunden ber om att få bygga ett trädäck men sen ändrar sig och vill skippa plankorna och istället bygga i papier-mache då kan inte hantverkaren bara säga ok och fortsätta. Dom är skyldiga att säga stopp. Så borde det vara inom IT också kan jag tycka.

Så är det inom IT också, fast där är leverantören (om de är smarta) noga med att ta fram ett risk avtal där det tydligt står vad kunden har valt - och valt tvärs emot rekommendation och därmed skapat en risk (om det är en sådan situation).

Men företaget kan inte gå ut i media och säga att Kund X var dumsnåla och har sig själva att skylla. Det går aldrig.
(och det verkar inte heller vara denna situation hos TE iom denna incident)

I början av kommentarstråden är det många som ställer sig frågande kring backuper, något jag själv också reagerade på.
Som jag förstått det så har den skadliga koden spritt sig i systemet tidigare och sedan varit passiv i månader innan den aktiverades.
Det betyder att alla backuper som inte är tillräckligt gamla också är infekterade så att en återställning med dessa inte hjälper. Backa verksamhetens data tre(?) månader är något som de flesta varken kan eller vill göra.

Ett sätt som jag varit med om är att maskinerna återställs till en fungerande version.
Detta göras på isolerade nät där NIC är avaktiverade i de virtuella maskinerna och inte anslutna på fysiska (förutom ILO)

På detta sättet kan man exportera data:t och titta på vilka inställningar som är satta i applikationen och sedan installera applikationen på en helt fräsch server, lägga över data:t - klart (grovt förenklat).

Utmaningen är att hantera alla servrar i ett sådan scenario på ett säkert sätt så att ingen infekterad körbar kod läggs över på de nya servrarna.

Sedan så har TE problemet med att tekniker behöver sova och hantera sin vardag så de kan inte jobba 18 timmar per dag. Det är ett maraton inte en sprint på 100 meter.

Har dom gjort rätt så har de tagit in extern hjälp då de inte har tillräckligt egna resurser att jobba 24/7. Ex.vis Microsoft har särskilda sådana här team som de kan flyga in och som då hjälper till med att titta på vad som verkligen hänt och hur det ställs tillrätta på bästa sätt.

Så här uselt blir det inte av skit bakom spakarna eller någon enstaka internetsladd, det måste vara felbyggt från början.

Jag börjar se ett samband.. #20370202

Fyfan vilken tragisk läsning. Man mår illa av att läsa om hur dåligt detta sköts.