Mijn adviezen;
- Draai externe programmatuur niet onder een generiek account met zeer hoge rechten (geldig voor elk is)
- Isoleer de software in een eigen container en draai dat niet met generieke accounts met zeer hoge rechten en gebruik hiervoor niet de zelfde als waar je de verwerking mee draait.

- Geef beheerders een eigen account zonder bijzondere rechten.
Alleen bij de onderhoud beheer werkzaamheden een vastgesteld bewaakt proces wie wat wanneer en waar vandaan de acties doet.

Het is minder makkelijk al die drempels juist dat is het doel om het misbruik niet zo eenvoudig te maken.

Uit de Cisco analyse kan worden afgeleid dat er geen beperking was van de IP's die toegang hebben tot de server. Dat is de grootste fout. Duidelijke gegevens ontbreken, maar het lijkt erop dat inlog mogelijk was met alleen een wachtwoord. Dat kan worden voorkomen door remote inloggen te beperken tot gespecificeerde public keys.

Jammer dat Cisco niet meer details geeft en zich verlaat op het draaien van een analysetooltje die alleen interpretaties geeft. Je kunt waarschijnlijk meer uit de logs halen dan ze hier hebben gepresenteerd.

@Karma4
Het is duidelijk dat je vanuit Windows beheer kijkt. Het gaat hier over Linux of een Unixachtige. Beheerders moeten sowieso een prive account hebben, dat is standaard zo bij alle betrouwbare Linux/BSD-distributies voor servers.

De rest van de adviezen hebben geen effect op het probleem, maar er is wel wat over te zeggen. Services moeten draaien onder accounts met beperkte rechten. Ook dat is meestal al zo onder Linux, maar niet altijd. Rechten onder Linux zijn standaard tamelijk beperkt, je kunt niet zonder meer tot in detail alles instellen. Changeroot draaien is hier geen oplossing omdat root login credentials al bekend waren.

Nope ik heb niets met Windows desktops van doen. Ik zit meer in de big data hoek waar Linux de boventoon voert.
Het beheer is daar zwaar onder de maat. Er zijn namelijk geen beheerders maar wel heel gevoelige data.
Waarom er geen beheerders zijn? Dat snap ik niet, de data moet goed beheerd worden, de analyse omgevingen eveneens. Het lijkt er op de doosjes beheerders dat soort beheer niet willen zien en daarmee de boel frustreren.

Alsof die doosjesbeheerders als doel hebben dat gebruikers met excel op desktops met de gevoelige data moeten werken. Dan is de verleiding heel groot om dat thuis te gaan te doen en even daarheen te mailen.

Je kunt goed met functionele privileged accounts werken heel toegesneden om de onderliggende informatie.
Ik moet de eerste omgeving nog tegenkomen die door een leverancier zo ingericht is en dat ook uitdraagt.
Met de DAC setuid en sticky-bit op directories kun je echt het meeste wel voor elkaar krijgen.

BSD is een van de faals daarvoor https://www.j3e.de/ngroups.html maar 16 groepen in het systeem en je krijgt een cut-off effect. Daarmee ga je het niet redden. Je moet wel een nemen die voldoende groepen ondersteund.
Ga dan meteen voor cgroups met een worlkloadbalancing.

De omschrijving van de hack suggereert dat geen van je adviezen geholpen zou hebben in deze situatie .

Ook al draai je je processen als een aparte user, en in een container, en is het beheer account geen generieke systeemuser
, op de een of andere manier moeten er mensen in staat zijn die de webserver configureren, de containers bouwen en de server configs te wijzigen.

Het gestolen beheeraccount was niet root (de aanvaller gebruikte 'su' - ongetwijfeld net als de echte beheerder) .

Wat wel (meer) geholpen zou hebben is als de server niet vanaf 'overal' toegankelijk geweest zou zijn - dat zou de aanvaller gedwongen hebben om via/vanaf een beheer machine te werken . Op z'n minst geeft dat een grotere kans op ontdekking.

De update server werd feitelijk omgeconfigureerd tot een reverse proxy om de geinfecteerde versie van elders op te halen.

Een (strakke) DMZ firewall voor de update server zou het de aanvaller ook lastiger gemaakt hebben om deze methode te gebruiken, omdat de update server normaal geen downloads vanaf "ergens bij OVH" hoeft te doen.
(door de 'reverse proxy' truuk kan de aanvaller op elk moment de software veranderen zonder te hoeven inloggen op de feitelijke server. Verder kan de aanvaller verschillende versies uitleveren (bv op basis van client ip - alleen besmette versies voor doelwit-IPs ? ) zonder dat alle software daarvoor op de echte update server hoeft te staan. En de files op de update server worden niet gewijzigd . )

Mijn adviezen waren dan ook niet bedoeld voor de M.E.DOC beheerders. Je kan niet 100% voorkomen dat er iets mis gaat.

De adviezen zijn bedoeld hoe je applicaties bij de gebruikers er van (dus de andere kant) inricht. Het doel daar moet zijn dat als er iets mis gaat zoals bij een externe leverancier de impact minimaal is. Als je externe leveranciers software laats draaien met local/domain admin root dan zal die software wel werken. Makkelijk implementeren maar zodra er iets mis gaat is de impact hoog. Zet alles zo veel mogelijk bij je zelf dicht zodat het niet verder kan als er iets mis mocht gaan.

De BSI geeft nu de zelfde soort adviezen voor software die je achteraf niet meer vertrouwt.
Zie nu ook een NCSC advies op deze site dat je de betreffende systemen niet meer kan vertrouwen dus maar alles moet gaan herinstalleren (uhh achteraf en je weet niet wat?)

Je zou het moeten doen met nette compartimenten voordat er maar iets aan de hand is. Zeg maar een permanente fail-safe.

Het Probleem met M.E.Doc als installatie bij de klanten is het ontbreken van elke security (shared generiek account). Die methode was in de oertijd van ICT normaal nu zwaar verouderd. En dan heb je het over een trusted strorage omgeving.
Jouw link gaat over untrusted storage en daarbij niet relevant.
De clou (zoek het kwartje): Je kan niet volledig uitsluiten dat er buiten wat mis gaat. Je kan wel zo veel mogelijk doen om de mogelijke impact te beperken. Het is leuk om M.E.DOC verder tegen het licht te houden. Belangrijker is de verspreidingsmogelijkheid structureel in te perken.
Gewoon eerst de verouderde goedkope (want het werkt) aanpak bij het vuil zetten en prio de aangewezen richtlijnen (ISo27k) gaan doen. Je die zijn ook al oud maar nooit goed geïmplementeerd, want het zou te duur.moeilijk/lastig zijn.

Lees voor dat je wat over big data zegt even https://www.wrr.nl/publicaties/rapporten/2016/04/28/big-data-in-een-vrije-en-veilige-samenleving.

Je ziet meerder fases.
- De eerste daarvan is een data ware house opbouwen. Dat kun je nog steeds met trusted storage doen (geen cloud). Kimball Inmon Lindsted geven richtingen voor datamodellering. Het wezenlijkste bij al die richtingen is het ontbreken van een security aanpak.
- De analyse fase, zeker met R, heeft het zelfde de security houvast ontbreekt want dat zou het OS wel doen. Gewoon eerst de aangewezen richtlijnen (ISO27k) gaan doen. Je die zijn ook oud maar nooit geïmplementeerd want het zou te duur zijn.
- De gebruiksfase met terugkoppeling van het model vraagt in andere insteek dan dat ouderwetse gedoe cobol C Java (3gl). Je moet het model nog monitoren dat met het inpassen in operationele omgevingen. Ook hier weer een security richting ontbreekt. Gewoon eerst de aangewezen richtlijnen (ISO27k) gaan doen. Ook hier gaat het om gewoon trusted storage

Het lijkt haast wel 3 keer is scheepsrecht (big data).
Met de goedkope oude snel klaar klassieke aanpak staat de teller op 4 voor het niet invullen van security. Niets nieuws nodig gewoon de zaakjes eerst eens een keer goed doen. Voordat je gaat rennen moet je kunnen lopen.

Het gedoe met cloud en unstrusted storage dan zie je al de datalekken met open dataabases mongodb rsh etc. (shodan).
Je kunt dat YU terugvinden als http://nos.nl/artikel/2135155-big-data-onderzoek-naar-parkinson-met-respect-voor-privacy.html. (Zou Bart Jacobs het idee gestolen hebben?) Met 650 mensen met heel specifieke kenmerken kun je encrypten wat je wil de onderzoekers die de data hebben voor analyses zullen best in staat de terugkoppeling in principe te kunnen doen. Het beste is dat ze daar totaal geen interesse in hebben en die gegevens negeren. Dat heet ethiek.

Lees je eigen link referentie maar door. Die problème toekomst en context is bekend.
Als j ik j vind dat operators beheerders per definitie onbetrouwbaar zijn en dat je al het mogelijke moet doen om dat werk onmogelijk te maken ga je gang. Het is nu net een van ds issue die opspelen oa bij apm.

Ik fa er voor om naar werkbare oplossingen te zoeken. Niet zo heel verrassend is daar best het nodige over te vinden.
Wat heb je er op tegen om met iets werkbaars te starten. Kom een met een argument waarom het goed overwogen invullen van iso27k nen7510 etc onjuist zou zijn. Nu is er ... niets.

Bedenk dromen zij bedrog met een doosjes aanpak kom je er niet.