Företaget bakom Coops kassahaveri anklagas för åratal av bristande säkerhet

Jotack, har tyvärr erfarenhet av precis det där, i fler än ett bolag.

Alltså, jag vet inte... Att köra servern i molnet är väl litet att lägga alla ägg i samma korg, och hur mycket mer jobb är det att administrera en server när man ändå har ett gäng kassor? Personligen tror jag mer på en struktur typ Kassa/Butik/Konsumentförening eller whatever de kallar det/HK Sverige/HK.

Då behöver varje nivå inte vara beroende av att den över är igång just för tillfället. Då kan man köra en kassa om butiken tillfälligt är nere, butiken om konsumentföreningen är nere litet längre o.s.v. Det behövs naturligtvis graceful degradation för vissa funktioner.

Jag antar dock att problemet i det här fallet var att man ansåg att allt behövdes installeras om från början, för man kan väl aldrig ha litet på att kassorna inte var infekterade efter en sådan här attack? Då måste ju hela butiken stängas ner, servern återställas och först efter det kan man dra igång kassorna för att få igång försäljningen.

Dessutom så skall den server som tillhandahålla gränssnitt mot användare ha minimal funktionalitet och endast använda väl definierade anrop mot back-end samt i övrigt bara hantera presentationen.

Back-end skall sedan ha ett tydligt gränssnitt mot SQL och andra tjänster som används just för att hantera saker som SQL injection.

Personligen så skulle jag endast lagra mitt data i molnet som en drive krypterad med Veracrypt eller liknande som backup och hålla hårt i min data.

Jag litar inte på någon molntjänst för viktig data längre än jag kan kasta en Volvo FH.

jag tycker leverantören som säljer Saas tjänsten ska ha utfört korrekta säkerhetstester innan man 1) säljer tjänsten 2) säger att man har utfört säkerhetstester - när det är uppenbart att man inte gjort det

// LZ

Ofta har man dessutom hyrt in någon utifrån som inte har en blekaste aning om lämplig mjukvaruarkitektur eller programmeringsspråk för den aktuella tillämpningen utan bara kan granska i generella termer.

Så där blir det ofta "sätt in en brandvägg" så löser det sig. Men för att applikationen skall funka så körs hela applikationen i klienten i Javascript som sen kör JSon mot ett gränssnitt som sen kör direkt mot en SQL-databas. Eller ännu värre - skapar SQL-anrop som sedan skickas till databasen direkt över nätet från klienten. (nu överdriver jag nog, men jag skulle inte bli ett smack förvånad om någon skulle skapa en sådan lösning)

Och bygger man webbsidor så bör varje individuell sida dynamiskt kolla användarens behörighet innan tillgång ges. Inte bara en gruppering av liknande sidor.

Helt rätt.
En sårbarhet är inte farlig innan den kan nyttjas. Hade inte VSA servern varit nåbar från publikt internet så hade detta troligen inte inträffat. Dock har de flesta bommat denna lilla punkt

Meningen med att köra Kaseya verkar ju ha varit att inte köra VPN, så att leverantörer som Visma EssCom (som hade tagit över hela driften vid det läget) kommer in utan VPN...

Att inte leverera dessa tjänster där det inte finns lite brandväggar och tunnlar vore nog en bra idé.

Jo de verkar ha valt att implementera det så tyvärr. Effekten av att bara ha ett lager skydd (inloggningen i VSA) är nu känd.
iom att det var fler butikskedjor som drabbades så får vi väl misstänka att det var en delad lösning hos leverantören men borde fortfarande inte ha varit så svårt att sätta en ip-sec tunnel (räcker med auth, behöver inte krypto) från endpoint till vsa

Nu är ju inte coop som "ägde" kaseya utan deras POS försäljare. Så coop var en kund, till en kund, som var kaseyas kund.

Det var fler företag än COOP som drabbades i sverige. Coop norrbotten var tämligen odrabbad, men deras snabbkassor var döda dock.

Coop kände säkert till att deras POS körde kaseya, men det är inte coops huvudsakliga driftansvar. Dom har virtualisering osv osv men kassasystemet är helt utanför deras kontroll.