Extra beveiligingsmaatregelen

[CAPSLOCK2000]

Bij ons loopt er een voorstel om de belangrijkheid onze servers te klassificeren in laag/middel/hoog.
Het doel hiervan is passende maatregelen kiezen bij iedere klasse.
Dat klinkt heel goed en logisch... maar...

Waar ik nu tegen aan loop is dat ik geen maatregelen kan bedenken die ik bereid ben weg te laten.
Vanuit veiligheid wil je natuurlijk altijd het maximale doen.
Ik zie drie redenen om minder te doen dan mogelijk is (let op: niet minder dan nodig is).
- het is te duur
- het kost te veel werk
- het is te gebruikersonvriendelijk

Onze servers worden geautomatiseerd beheerd en of we het nu op 3 servers doen of op 300 maakt maar weinig uit voor de hoeveelheid werk die moet worden gedaan. Ook voor de kosten maakt het dus weinig uit. Dat verschil zit hooguit in wat licenties en die kosten zijn zelden significant ten opzichte van het beheer dat er bij hoort.

Het beste dat ik kan bedenken is gebruikersgemak, bv dat je minder strenge eisen stelt aan wachtwoorden of de lengte van sessies. Dat voelt echter als gerommel in de marge. We werken trouwens met SSO dus in praktijk valt op deze onderwerpen eigenlijk niks te winnen (of te verliezen).


Heel concreet: Wat doen jullie wel/niet op jullie meest/minst belangrijke servers maar niet op de rest?

[Voor 4% gewijzigd door CAPSLOCK2000 op 09-11-2022 13:39]

[oak3]

Misschien dat meer doen ook een optie is aan de hand van de classificatie, of wordt het zuiver gezien als kostenbesparing?

Over het algemeen gaat het over drie assen Beschikbaarheid, Integriteit en Vertrouwelijkheid en dan kan ik wel wat dingen bedenken in verschillende scenario's:
- beschikbaarheid van een test omgeving hoef niet hetzelfde te zijn als van een productieomgeving, kan impact hebben op je disaster recovery scenario (minder capaciteit nodig), backup of onderhoudstijdstippen
- in een test omgeving is vertrouwelijkheid als het goed is ook minder als je geen productiedata hebt, dus hoef je misschien geen encrypt toe te passen, andere checks met authorisatiematrix
- aan de hand van de classificatie bepaal je mede welke systemen het eerste online moeten komen na een uitval
- welke type storage je gebruikt voor bepaalde systemen
- een systeem met hoge classificatie wil je misschien high available maken, en andere systemen niet
- integriteit van een erp systeem is een test heel anders dan in productie

kan nog wel wat meer dingen bedenken, maar dit is het soort dingen waar ik aan denk als je gaat classificeren.

zo kan ik nog wel doorgaan.

[CAPSLOCK2000]

Bedankt voor de suggesties. Ik voel me gesterkt in mijn mening dat dit voor ons een achteruitgang zou zijn. Alles wat je noemt doen we al voor al onze systemen. We zouden misschien geld kunnen besparen door het niet te doen maar het wordt er niet veiliger van.

Voor de duidelijkheid, mijn reactie hieronder gaat niet over "gelijk" of "ongelijk". Je doet goede algemene suggesties die alleen niet van toepassing zijn in mijn concrete situatie.

Ik hou niet van generiek beleid dat niet nodig is, dat komt vroeg of laat terug om je in de staart te bijten. Daarom stel ik dat soort regels liever pas op als we ze concreet gaan gebruiken. Dat is ook de achtergrond van deze post. Er ligt een ronkend stuk wat heel goed klinkt maar zo generiek is dat wij er niks aan hebben.

Ik probeer dat wat bij te sturen voor allerlei beheerders kunstjes moeten gaan doen waar ze zelf moet achter staan. Voor ik me er al te diep in stort zoek ik een beetje bevestiging. Dat ik zo snel geen relevante veranderingen kan bedenken die nuttig zijn in onze omgeving kan ook aan mij liggen

oak3 schreef op woensdag 9 november 2022 @ 14:08:
Misschien dat meer doen ook een optie is aan de hand van de classificatie, of wordt het zuiver gezien als kostenbesparing?

Het doel is de veiligheid te verbeteren. Het is inderdaad de bedoeling om BIV-classificaties op servers te doen.

- beschikbaarheid van een test omgeving hoef niet hetzelfde te zijn als van een productieomgeving, kan impact hebben op je disaster recovery scenario (minder capaciteit nodig), backup of onderhoudstijdstippen

Bedankt, goede suggesties.

In praktijk is onze hele omgeving redundant uitgevoerd want alles draait gevirtualiseerd en/of in de cloud. Bezuinigen is geen doel. Ik zie dus geen reden om een nieuw omgeving in te richten die minder high-available is om daar onze test-systemen op te gaan draaien.
Daarbij zul je ook je HA-oplossing ergens moeten testen.

- in een test omgeving is vertrouwelijkheid als het goed is ook minder als je geen productiedata hebt, dus hoef je misschien geen encrypt toe te passen, andere checks met authorisatiematrix

Dat zou kunnen maar wat schiet je er echt mee op?
Het scheelt misschien een heel klein beetje tijd als je na een reboot handmatig het decryptiewachtwoord moet ingeven maar dat voelt als erg klein.
Tegelijkertijd maak je het jezelf moeilijker want je moet nu extra hard gaan verzekeren dat er nooit geveolige informatie in je testomgeving terecht komt. Daarom zie ik meer in een uniforme aanpak waarbij alle systemen hun data versleutelen.

- aan de hand van de classificatie bepaal je mede welke systemen het eerste online moeten komen na een uitval

Dat is eerlijk gezegd het beste punt dusver in onze omgeving. Toevallig(?) is dit dan wel een punt waar het niet gaat om iets "wel" of "niet" doen maar alleen over de volgorde waarin je het doet.

- welke type storage je gebruikt voor bepaalde systemen
- een systeem met hoge classificatie wil je misschien high available maken, en andere systemen niet

tnx, wederom op zich goede suggesties die in /mijn/ omgeving niet van toepassing zijn, alles is HA en in storage zit alleen verschil in snelheid, niet in beveilingsmaatregelen.
Tenzij je een reden hebt waarom je systemen niet-HA zou willen maken. Wellicht spaart het hardware maar twee verschillende configuraties beheren (wel en niet HA) is ook niet gratis.

- integriteit van een erp systeem is een test heel anders dan in productie

Welke concrete maatregelen kun je dan loslaten?

kan nog wel wat meer dingen bedenken, maar dit is het soort dingen waar ik aan denk als je gaat classificeren.

Please do

[oak3]

- integriteit van een erp systeem is een test heel anders dan in productie

4-ogen principe bij het klaarzetten van een betaling bijvoorbeeld of het aanpassen van een bankrekeningnummer.

Als je commentaar zo lees, dan voegt een BIV classificatie niet veel toe. Klinkt als dat je alles op 'hoog' hebt staan en dit eerder een exercitie is om systemen naar midden of laag te krijgen een maatregelen af te schalen.

Het kan trouwens wel echt een goede denk oefening zijn. Als je er een goed proces voor bedenkt en dat doorloopt geeft het op zijn minst inzicht.

Btw, persoonlijk ben ik er ook niet zo'n fan van om BIV classificatie toe te passen. Meestal kun je toch geen onderscheid maken. Maar stel je zou alles naar public IaaS verhuizen, dan is het echt wel waardevol, want daar kun je met vinkjes aan of uit veel kosten besparen of juist beschikbaarheid verhogen.

Zoals altijd, het hangt af van de context en met dit soort dingen goed om altijd de vraag te stellen, waarom en wat is het doel.

[CAPSLOCK2000]

oak3 schreef op woensdag 9 november 2022 @ 15:09:
4-ogen principe bij het klaarzetten van een betaling bijvoorbeeld of het aanpassen van een bankrekeningnummer.

Dat is redelijk maar ik had het vooral over technische maatregelen op het niveau van de (systeem/netwerk)beheerder.

Als je commentaar zo lees, dan voegt een BIV classificatie niet veel toe. Klinkt als dat je alles op 'hoog' hebt staan en dit eerder een exercitie is om systemen naar midden of laag te krijgen een maatregelen af te schalen.

Ik probeer juist te voorkomen dat we gaan afschalen. Het wordt namelijk gebracht als dat we de veiligheid gaan verbeteren en extra maatregelen gaan toevoegen, maar als ik het uitwerk zie ik nog niks dat nieuw, extra of beter is. Ik ben dus bang dat er maatregelen aangewezen gaan worden als "niet noodzakelijk" zodat we iets weg kunnen laten. Dat zou geen doel op zich moeten zijn maar zo werkt het wel als mgmt zegt dat je onderscheid moet gaan maken.

Het kan trouwens wel echt een goede denk oefening zijn. Als je er een goed proces voor bedenkt en dat doorloopt geeft het op zijn minst inzicht.

Zeker, die probeer ik dus voor mezelf uit te voeren. Dank voor je hulp.

Btw, persoonlijk ben ik er ook niet zo'n fan van om BIV classificatie toe te passen. Meestal kun je toch geen onderscheid maken.

Idem, een erg groot deel is toch HOOG. Ik heb nog niet een systeem bij ons kunnen vinden dan Laag/Laag/Laag is, er zit altijd minimaal 1 "Midden" bij.
Voor mij is het makkelijker om alles als HOOG te behandelen dan om uitzonderingen te gaan zoeken voor systemen die dat niet zijn.

Maar stel je zou alles naar public IaaS verhuizen, dan is het echt wel waardevol, want daar kun je met vinkjes aan of uit veel kosten besparen of juist beschikbaarheid verhogen.

Voor beschikbaarheid heeft dat zin. Voor integriteit en veiligheid zie ik geen significante verschillen.

Zoals altijd, het hangt af van de context en met dit soort dingen goed om altijd de vraag te stellen, waarom en wat is het doel.

Precies, daar is het fout gegaan. Iemand is ingehuurd om beleid te schrijven en dat staat dus nogal ver af van de dingen waar wij mee zitten. Die heeft wel met een paar mensen gepraat maar niet met systeembeheer. Ik wil geen stuk onderuit halen alleen maar omdat er wat extra instaat dat we niet nodig hebben, maar imho is de gekozen richting niet nuttig voor ons.

Voor ik die discussie al te hard inzet probeer ik eerst even mijn eigen mening onderuit te halen met tegenvoorbeelden zodat ik niet voor paal kom te staan

[oak3]

Ps, deze vraag is geen systeembeheer vraag maar een business vraag. Die moet zeggen bedrijfsproces x is cruciaal voor ons bedrijf met deze BIV classificatie. Dan moet bepaald worden welke systemen daar onder hangen en die krijgen automatisch de hoogste BIV classificatie van het proces dat het ondersteund.
En de business moet aangeven wat de BIV classificatie moet betekenen. Bijvoorbeeld 99% uptime (of meer), versleuteling van data, autorisatiematrix, data mag niet in de cloud etc.

Als systeembeheer zou ik hem terug geven en zeggen, ik hoor graag wat de business vind en dan geef ik aan wat de consequenties zijn (financieel, aanpassingen etc) en dan voer ik het uit na goedkeuring van de business.
(Ik besef met dat het risico is dat ze zeggen dat het voor minder kan, maar uiteindelijk zijn zij eigenaar van die beslissing en is het alleen de taak van IT om transparant te maken wat de keuzeopties en consequenties zijn)

[Voor 26% gewijzigd door oak3 op 09-11-2022 15:35]

[CAPSLOCK2000]

oak3 schreef op woensdag 9 november 2022 @ 15:32:
Ps, deze vraag is geen systeembeheer vraag maar een business vraag. Die moet zeggen bedrijfsproces x is cruciaal voor ons bedrijf met deze BIV classificatie. Dan moet bepaald worden welke systemen daar onder hangen en die krijgen automatisch de hoogste BIV classificatie van het proces dat het ondersteund.

Bedankt voor je reactie. Mijn vraag gaat niet over het classificeren. Laten we maar even aannemen dat de servers geclassificeerd zijn. Mijn vraag gaat over welke maatregelen je daar vervolgens aan hangt.

Die vraag wil ik vooral niet door mgmt laten invullen want die hebben daar geen kaas van gegeten, die weten helemaal niks van IT-beveiliging, dat is mijn terrrein.

Uiteindelijk moet mgmt natuurlijk wel iets besluiten maar dat moet een afweging zijn tussen budget en risico's. mgmt moet zich vooral niet inhoudelijk gaan bemoeien hoe lang een wachtwoord moet zijn en welke firewall poortjes open moeten staan of zo iets.
Daar ga ik over.

En de business moet aangeven wat de BIV classificatie moet betekenen. Bijvoorbeeld 99% uptime (of meer), versleuteling van data, autorisatiematrix, data mag niet in de cloud etc.

Ja en nee. Formeel gezien moet de bussiness dat aangeven maar dat kan niet uit het niets komen. De bussiness weet immers niks van IT. De afdeling IT zal dus advies moeten geven aan de bussiness zodat die uiteindelijk kan kiezen voor een bepaald pakket aan maatregelen, kosten en risico's.
Maar de bussiness moet niet zelf gaan bedenken welke maatregelen er nodig zijn.

Als systeembeheer zou ik hem terug geven en zeggen, ik hoor graag wat de business vind en dan geef ik aan wat de consequenties zijn (financieel, aanpassingen etc) en dan voer ik het uit na goedkeuring van de business.

Zo werkt het niet bij ons. Bij ons zegt de bussiness dat wij ons aan het beleid moeten houden en dat hun applicatie moet werken. Dat is niet hoe het zou moeten maar wel hoe het is en daar ga ik niks aan veranderd krijgen.
Waar ik wel invloed op heb is wat er in het beleid staat waar we ons aan moeten houden. Ik probeer daar een goed stuk van te maken in plaats van een stelle ronkende maar lege suggesties.

Maar ik wil eigenlijk weg van de formele kant van mijn vraag. Het is allemaal goed advies maar niet de vraag waar ik mee zit.
Mijn vraag is dus eigenlijk: "Welke beveiligingsmaatregelen treffen jullie wel in de categorie HOOG maar niet in LAAG?" Liefst zo concreet mogelijk.

[bw_van_manen]

Ik zou servers sowieso nooit in de categorie laag inschalen. Dan kun je ze waarschijnlijk beter uitschakelen.

Hier worden de servers (net als bij jou) allemaal hetzelfde behandeld. Ik weet wel van een organisatie waar dat niet zo is. Een maatregel die me daarvan bijgebleven is is dat ze voor servers in de categorie hoog alleen remote desktop verbindingen toestaan waarbij de volledige sessie opgenomen wordt en die sessie opslaan op een plek waar de ingelogde medewerker zelf niet bij kan. Zo zijn alle veranderingen en aanpassingen op die servers terug te halen bij een probleem/audit. Dit kost natuurlijk behoorlijk wat opslagruimte en ook tijd als je het steekproefsgewijs wil controleren, dus dat doe je alleen voor servers waar het echt belangrijk is.

[MAX3400]

Is het niet omgekeerd evenredig? Voor alle machines een "hoge technische beveiliging" zoals de best practices van een (ik geef een voorbeeld) Microsoft security baseline voor het OS op basis van Microsoft MOF, een Nessus-advisory voor je aanvullende "security & audit" afhankelijk van de specifieke requirements en dan een IAM-oplossing / inrichting of & wie erbij mag komen?

Hier is weinig gebruikers-ONvriendelijk aan; echter moet elk persoon hierdoor bewust gebruik maken van 3 of 4 specifieke & named accounts afhankelijk van het uit te voeren werk per (Microsoft)-forest.

That said, als beheerder maak ik daardoor geen onderscheid tussen welke machine 24/7/365 er moet zijn of slechts van 8 tot 5. Dat is een business-beslissing gebaseerd op kosten vs opbrengst. De business bepaalt dus de SLA per service en niet per server.

[oak3]

Misschien ook iets als volgt m.b.t. secruity:

Bij een hoog geclassificeerde server heb je strikt hardening beleid, beperkt aantal accounts wat er op mag inloggen, positionering in netwerksgementatie met zeer beperkt toegestaan netwerkverkeer. (Denk aan Tier 0 servers volgens het Microsoft model) of zelfs systemen met een data diode, geen netwerkverbinding of met een interne vpn tunnel.

Terwijl laag (of midden) een server zou kunnen zijn waar je een open fileshare op hebt om intern bestanden te delen, of een remote desktop voor mensen die remote moeten kunnen inloggen. Of een 'beheer' server waar je allerlei tooling op hebt staan om het beheer wat makkelijker te maken.

[laurens0619]

Is een lastige idd.
Bekijk het vanuit een aanvaller, wat die meestal doen is beheerdersleutels stelen (veelal domain admin) en of scripts uitvoeren vanuit compromised andere plek

Controls waar je aan kunt denken die kunnen bijdragen maar vaak te complex zijn om overal door te voeren
- Internet toegang verwijderen, alleen connectie naar whitelisted diensten
- Alle ASR regels/Credential guard volledig aan
- Application whitelisting aan (applocker)
- RDP/WMI/PSExec blokkeren
- Standaard beheersgroepen/endpoint management software verwijderen en in aparte tiering stoppen

[CAPSLOCK2000]

bw_van_manen schreef op donderdag 10 november 2022 @ 16:44:
Ik zou servers sowieso nooit in de categorie laag inschalen. Dan kun je ze waarschijnlijk beter uitschakelen.

Eens, maar zo makkelijk is het meestal niet, helemaal niet in mijn bureacratische organisatie. Helaas is er een lastige tegenstelling, namelijk dat de systemen die het minst belangrijk gevonden worden vaak ook het meest verwaarloosd zijn. Ergens zou je daar dus juist extra streng op de veiligheid moeten zijn.

Overigens is "laag" natuurlijk maar relatief. Een lage betrouwbaarheid kan betekenen dat je een applicatie best een paar weken kan missen, dan moet de bedrijfsborrel maar even zonder karaoke, maar op de operatiekamer kan "laag" betekenen dat het binnen 15 minuten gefixed of vervangen moet zijn.

Een argument wat ik eigenlijk niet mag gebruiken is ik meestal niet zo veel vertrouwen heb in (biv)-classificaties, die worden nogal eens gedaan door mensen die niet echt helemaal doorgronden én dat ze door de tijd heen nog wel eens veranderen. Zo zie ik regelmatig dat een handige applicatie voor steeds meer doeleinden gebruikt wordt zonder dat die classificatie wordt aangepakt.
Daarom zet ik liever wat te hoog in dan te laag, later verbeteren is vaak niet te doen.

Een maatregel die me daarvan bijgebleven is is dat ze voor servers in de categorie hoog alleen remote desktop verbindingen toestaan waarbij de volledige sessie opgenomen wordt en die sessie opslaan op een plek waar de ingelogde medewerker zelf niet bij kan.

Bedankt voor het concrete voorbeeld.

[CAPSLOCK2000]

MAX3400 schreef op donderdag 10 november 2022 @ 16:58:
Is het niet omgekeerd evenredig? Voor alle machines een "hoge technische beveiliging"

Ik zie het ook zo, maar, sorry dat ik zo flauw ben, als er een "hoge" technische beveiliging is dan is er ook een "lage" technische beveiliging en dan bedoel ik niet "slecht".

Hier is weinig gebruikers-ONvriendelijk aan; echter moet elk persoon hierdoor bewust gebruik maken van 3 of 4 specifieke & named accounts afhankelijk van het uit te voeren werk per (Microsoft)-forest.

Een beetje een zijspoor, maar ik vind dat in theorie in goede oplossing maar in mijn praktijk (nog) niet omdat we veel te afhankelijk zijn van wachtwoorden. Meerdere accounts betekent dan ook meerdere wachtwoorden en dus een wachtwoordmanager. Die wachtwoord manager moet ook weer goed beveiligd en geintegreerd worden anders zijn al die accounts alsnog vanuit een bron toegankelijk en zitten mensen regelmatig wachtwoorden heen en weer te kopieren. Dat is allemaal oplosbaar maar mijn omgeving is daar nog niet klaar voor.

That said, als beheerder maak ik daardoor geen onderscheid tussen welke machine 24/7/365 er moet zijn of slechts van 8 tot 5. Dat is een business-beslissing gebaseerd op kosten vs opbrengst. De business bepaalt dus de SLA per service en niet per server.

Server of applicatie of service doet er inderdaad niet zo heel veel toe, het komt min of meer op hetzelfde neer.

[CAPSLOCK2000]

oak3 schreef op donderdag 10 november 2022 @ 17:18:
Bij een hoog geclassificeerde server heb je strikt hardening beleid,

Wat zou jij in ee strict hardening beleid zetten wat je elders weglaat?

beperkt aantal accounts wat er op mag inloggen, positionering in netwerksgementatie met zeer beperkt toegestaan netwerkverkeer.

Waarom zou je dat niet doen voor minder belangrijke servers/diensten?

(Denk aan Tier 0 servers volgens het Microsoft model) of zelfs systemen met een data diode, geen netwerkverbinding of met een interne vpn tunnel.

Terwijl laag (of midden) een server zou kunnen zijn waar je een open fileshare op hebt om intern bestanden te delen, of een remote desktop voor mensen die remote moeten kunnen inloggen. Of een 'beheer' server waar je allerlei tooling op hebt staan om het beheer wat makkelijker te maken.

Mijn probleem met deze benadering is dat je de classificatie nu laat afhangen van de hardening en dat is een beetje de omgekeerde wereld. De fileservers waar onze bestanden op worden gedeeld zitten juist in de hoogste categorie. We kunnen eigenlijk geen dag zonder, en er staat zeer gevoelige en zeer kostbare data op.
Een fileserver die niet bereikbaar is daar heb je echter niks aan.
Ook remote desktops en beheerservers zijn (in mijn organisatie) juist de systemen die extra streng beveiligd moeten worden.

Toch bedankt voor je voorbeelden, het laat me iets verder kijken dan mijn organisatie groot is. De voorbeelden die je geeft sluiten aan bij het beleidsvoorstel dat er ligt en het bevestigd mijn gevoel dat dit niet past bij mijn organisatie.

[CAPSLOCK2000]

laurens0619 schreef op donderdag 10 november 2022 @ 21:08:
Is een lastige idd.
Bekijk het vanuit een aanvaller, wat die meestal doen is beheerdersleutels stelen (veelal domain admin) en of scripts uitvoeren vanuit compromised andere plek

Zo zie ik het ook, iedere zwak punt is een potentieel aanknopingspunt om vanuit verder te werken. Dat een applicatie onbelangrijk is betekent dus niet dat security ook onbelangrijk is. Daarbij geloof ik erg in geautomatiseerd beheer. Als ik dingen aan kan zetten doe ik het dus.

Controls waar je aan kunt denken die kunnen bijdragen maar vaak te complex zijn om overal door te voeren
- Internet toegang verwijderen, alleen connectie naar whitelisted diensten
- Alle ASR regels/Credential guard volledig aan
- Application whitelisting aan (applocker)
- RDP/WMI/PSExec blokkeren
- Standaard beheersgroepen/endpoint management software verwijderen en in aparte tiering stoppen

Tnx, dit zijn veruit de beste voorbeelden die ik dusver heb. Dingen die je wil maar zo intensief zijn dat je ze gewoon echt niet overal kan doen. Want als je het wel makkelijk kan doen dan zie ik geen reden om het te laten.

[Voor 21% gewijzigd door CAPSLOCK2000 op 10-11-2022 21:43]

[laurens0619]

+ je detect en response opkrikkeb:
Edr (maar dat heb je overal hoop ik) met tagging erop zodat de soc analys direct weet dat t critical spul is.
Automation erbij dat alles wat op sensitive bak mis gaat dmv soar resonse doet (tm automated lockdown/isolation)
Sysmon erbij icm slootje custom Use cases

[Bor]

CAPSLOCK2000 schreef op woensdag 9 november 2022 @ 13:38:
Bij ons loopt er een voorstel om de belangrijkheid onze servers te klassificeren in laag/middel/hoog.

...

Heel concreet: Wat doen jullie wel/niet op jullie meest/minst belangrijke servers maar niet op de rest?

Zit hier misschien ook een onderscheid in uptime garanties en daarmee de inrichting?

[CAPSLOCK2000]

Bor schreef op donderdag 10 november 2022 @ 22:13:
Zit hier misschien ook een onderscheid in uptime garanties en daarmee de inrichting?

Nee, eigenlijk niet.
Impliciet wel, zeker als je Beschikbaarheid als deel van security ziet, maar in mijn praktijk is beschikbaarheid niet waar het nu over gaat, het gaat vooral over (netwerk)toegang en hardening.

Iets meer context is dat er een plan bestaat om servers ook op grond van BIV-classificatie in aparte vlans te gaan zetten, bovenop de onderverdeling die er al is. Het idee is om servers van verschillend niveau van elkaar te scheiden en daar dan "passende maatregelen" aan te hangen. Klinkt goed maar ik voorzie dat we heel veel extra vlans gaan maken en lange discussies voeren over welke server in welk vlan moet komen, om vervolgens te constateren dat alles overal precies hetzelfde is geconfigureerd omdat we niet bereid zijn om beveiligingsmaatregelen op te geven terwijl meer doen ook niet echt realistisch is.

Voor de duidelijkheid, kleine vlans zijn natuurlijk een goed idee op zich, we werken zelfs naar microsegmentatie toe. Maar ik heb geen zin om zinloos onderscheid te maken. Ik ga geen 4-letterige wachtwoorden toestaan omdat deze server niet zo belangrijk is.

<rant>
Wij kopen beleid tegenwoordig in (begin er niet aan) en daardoor krijg je soms stukken die prachtig klinken niet uitvoerbaar zijn, niet nuttig zijn voor onze organisatie, of zo generiek zijn dat je er nog niks mee kan. "Het bevoegd gezag neemt passende maatregelen voor de actuele situatie". no shit sherlock, dat is de default als er geen beleid is.

Het ergste zijn de stukken die met copy & paste zijn samengesteld uit andere documenten door mensen die het vakgebeied en het jargon niet echt kennen en dus niet zien dat er definities of situaties door elkaar lopen.
</rant>

<intermezzo>
Zo zit ik nu met een document dat op het eerste gezicht heel redelijk klinkt tot ik me af ga vragen hoe zich dat concreet naar onze organisatie toe moet vertalen. Ik tel nu al 108 categorieen. De bedoeling is dat voor al die categorieen "passende" maatregelen worden getroffen. Ik heb al moeite om 3 categorieen zinnig in te vullen. Ik kom niet veel verder dan vrij theoretische maatregelen die we niet kunnen betalen of waarvan het weglaten niks oplevert.

Zo wordt er hier gesuggereerd dat belangrijke servers alleen via VPN bereikbaar mag zijn. Voor de management kant geldt dat nu al voor onze servers. Aan de gebruikerskant kan dat meestal niet wat we hosten vooral publieke diensten maar er zijn er wel een paar die achter VPN (kunnen) staan. Het probleem is dat je dat niet aan de BIV-classificatie kan zien, dat zit daar gewoon niet in.
Daar moet dus nog een classificatie naast.

Ook maak ik me zorgen om het psychologische effect. Als je mensen vraagt om dingen in drie categorieen in te delen dan zullen ze gaan proberen om ze gelijkmatig te verdelen. Het is psychologisch heel moeilijk om te zeggen "nee, alles moet in de hoogste/laagste categorie" als je baas je de opdracht heeft gegeven om onderscheid te maken.
Als de organisatie al overwerkt is verwacht ik alleen maar voorstellen om dingen weg te laten, niet om meer veiligheid toe te voegen. Dat is precies het omgekeerde van wat we proberen te bereiken.

Ik wil voorkomen dat we heel veel werk gaan veroorzaken terwijl we er netto niet beter maar slechter van worden (nog even los van de "opportunity cost").

Daarom benader ik het even van de andere kant: eerst eens kijken waar we concreet en zinnig onderscheid kunnen maken tussen beveilingsmaatregelen die we wel of niet treffen en dingen die we meer of minder kunnen doen en dan kijken volgens welke criteria we systemen gaan indelen.

Als we (bijvoorbeeld) toch geen OpenBSD servers hebben moeten we vooral geen tijd steken in het opstellen van verschillende security profielen voor OpenBSD. Als we wel dat soort profielen gaan opstellen moeten we rekening houden met de mogelijkheden van dat OS en dus niet voorschrijven dat je alleen via RDP mag inloggen want dat is niet de manier waarop je BSD beheert. Je moet sowieso wel van heel goede huizen komen om iets te verbeteren aan de beveiliging van OpenBSD en bij twijfel kun je er dus beter vanaf blijven dan maar lukraak best-practices toepassen die voor een ander OS zijn geschreven.
(Dit is een theoretisch voorbeeld, we hebben geen OpenBSD).
</intermezzo>

Dus, vandaar dat ik op zoek ben naar informatie over welke concrete maatregelen mensen meer of minder doen om de beveiliging af te stemmen op de situatie en een beetje ook wat dat oplevert.

[CAPSLOCK2000]

laurens0619 schreef op donderdag 10 november 2022 @ 21:55:
+ je detect en response opkrikkeb:
Edr (maar dat heb je overal hoop ik) met tagging erop zodat de soc analys direct weet dat t critical spul is.
Automation erbij dat alles wat op sensitive bak mis gaat dmv soar resonse doet (tm automated lockdown/isolation)
Sysmon erbij icm slootje custom Use cases

De monitoring hebben we al voor alles (modulo wat systemen die nog niet zijn aangesloten). Ik kan geen goede reden bedenken om dat weg te laten op minder belangrijke systemen, onze licentie wordt er niet significant goedkoper van en het werk om het te installeren op 2 of 200 systemen maakt ook weinig verschil. De AI-systemen die we gebruiken voor de verwerking zullen er niet oververmoeid van raken en die hebben waarschijnlijk vooral profijt van meer data.

Automatische response hebben we niet echt, dat zou ik wel willen en vind ik een mooi voorbeeld. De volgende vraag voor mij is welke systemen je wel doet en welke niet. Het simpele antwoord is kijken naar "beschikbaarheid", als die hoog is moet je niet automatisch de deur dicht laten gooien, tenzij de "vertrouwelijkheid" ook hoog is, dan moet je een afweging maken of je beschikbaarheid belangrijker vindt dat vertrouwelijkheid. Als een systeem "hoog, hoog, hoog" is of juist "laag, laag, laag" kun je alle kanten op redeneren, van agressief ingrijpen tot terughoudend afwachten.

Het is een beetje een gewetensvraag hoeveel rekening ik houd met de praktijk. Als ik een maatregel voorschrijf die 1 miljoen per server kost dan gaat het gewoon niet gebeuren. Dan kan ik voor alle systemen een escalatie- of acceptatie-traject starten maar daar wordt niemand beter van, het kost alleen maar tijd die beter gebruikt had kunnen worden. Wij hebben niet de ruimte om theoretische noten te kraken.
Minder beveiliging configureren heeft alleen zin als het concreet geld, tijd of gemak oplevert.

[laurens0619]

@CAPSLOCK2000
helemaal eens hoor

De (security) industrie is heel goed om op papier logische zaken op te schrijven zoals de extra security op critical assets. Als je dan tot de kern komt en concreet wil maken wat is die extra security dan? Dan blijft het stil en/of krijg je een lijstje met onzinnige compliance controls of blijft het high level....

Dat is het stomme ook eraan. Je krijgt waarschijnlijk een betere rating als je controls van non-critical afhaalt (en dus onderscheid hebt) dan als je overal de juiste controls hebt.

Er zijn wel zaken die je additioneel kunt doen hoor, op alle schijven. Ik heb wat voorbeelden genoemd voor protect en detect/response maar dat kan net zo goed op recover (immutable storage bv).
Maarja, waarom zou je die controls niet overal toepassen (tenzij ze echt mega intrusive zijn).

De complexiteit zit hem inderdaad ook in critical en available. Eigenlijk wil je de critical assets zo scherp mogelijk beveiligen en via automation zoiets direct in isolatie gooien zodra je rook ziet. Mrja tegelijk is die asset zo belangrijk dat je dan onterechte downtime krijgt als het een false positive was.

[Voor 17% gewijzigd door laurens0619 op 11-11-2022 12:41]

[oak3]

Er zijn intussen al heel wat concrete punten genoemd en bedacht me er nog eentje. Niet gecontroleerd, maar dacht dat je bij de CIS hardening guidelines onderscheid wordt gemaakt tussen streng en heel streng. Zo ja, dan is dat nog een route die je kan nemen.

Ik heb echt wel omgevingen gezien waar de classificatie op BIV een wezenlijk verschil maakte. Van mag internetnet naar buiten hebben tot aan er mag geen netwerkkabel in zitten. Maar ook verschil in fysieke toegang, een serverruimte in een serverruimte met extra maatregelen tegen inbraak door insiders. Beheerders mogen wel in de gewone ruimte, maar voor de gevoelige systemen heb je een 'werkvergunning' nodig en kijkt er iemand constant mee.
Alleen als dat van toepassing is op jullie, dan had je dat al wel geweten en was dat al uitgewerkt. En dit klinkt als compliance / beleid oefening waar theorie en praktijk elkaar niet aanvullen. En daarbij is alleen een BIV classificatie dan niet het enige, er hoort dan ook een risicoanalyse bij om tot maatregelen te komen. Maakt nogal uit of je beveiligt tegen een hacker uit het oosten die zijn land niet uit gaat of een insider die omgekocht wordt.

Het is een beetje een gewetensvraag hoeveel rekening ik houd met de praktijk. Als ik een maatregel voorschrijf die 1 miljoen per server kost dan gaat het gewoon niet gebeuren. Dan kan ik voor alle systemen een escalatie- of acceptatie-traject starten maar daar wordt niemand beter van, het kost alleen maar tijd die beter gebruikt had kunnen worden. Wij hebben niet de ruimte om theoretische noten te kraken.
Minder beveiliging configureren heeft alleen zin als het concreet geld, tijd of gemak oplevert.

Het is soms ook kunnen verantwoorden van de maatregelen die er al zijn, of discussie voeren met de business. En wat je hier noemt is ook juist een risicoanalyse. Maak je 1 miljoen aan kosten voor de kans dat je 1x in de 5 jaar een ton aan schade hebt. Met een goede risicoanalyse zou je dat waarschijnlijk nooit doen.

Ik snap dat je graag concrete maatregelen hoort, maar die zijn in mijn ogen nooit generiek. Afhankelijk van de context zou je juist per (groep) systemen met een hoge classificatie een risico analyse moeten doorlopen om tot maatregelen te komen. En dat is altijd specifiek voor jouw situatie.

[oak3]

Ik bedacht me er nog eentje: de ABDO norm van defensie, die geeft verschillende niveaus (4) van beveiliging aan: https://www.defensie.nl/o...ta-s/2020/02/04/abdo-2019

Zomaar een voorbeeld: links is het meest gevoelige niveau:

Maar ook daar zie je betrekkelijk weinig verschil in de niveuas.

[Orangelights23]

Dit vraagstuk kan het beste beantwoord worden met een risico assessment. Daar bespreek je de elementen waar je naar zoekt. Zonder de hele context de weten, kunnen wij ook weinig nuttigs zeggen om te helpen.

[CAPSLOCK2000]

oak3 schreef op vrijdag 11 november 2022 @ 13:43:
Er zijn intussen al heel wat concrete punten genoemd en bedacht me er nog eentje. Niet gecontroleerd, maar dacht dat je bij de CIS hardening guidelines onderscheid wordt gemaakt tussen streng en heel streng. Zo ja, dan is dat nog een route die je kan nemen.

Bedankt voor de tip, dat was een goede. Ik voel me redelijk in mijn mening bevestigd dat dit voor ons vooral betekent dat we dingen gaan laten die we nu overal doen. Natuurlijk zijn er wel een (flink) aantal punten waar we iets te verbeteren hebben maar dan denk ik meestal dat we het dan net zo goed op alle systemen kunnen doen.

Ik heb echt wel omgevingen gezien waar de classificatie op BIV een wezenlijk verschil maakte. Van mag internetnet naar buiten hebben tot aan er mag geen netwerkkabel in zitten. Maar ook verschil in fysieke toegang, een serverruimte in een serverruimte met extra maatregelen tegen inbraak door insiders. Beheerders mogen wel in de gewone ruimte, maar voor de gevoelige systemen heb je een 'werkvergunning' nodig en kijkt er iemand constant mee.
Alleen als dat van toepassing is op jullie, dan had je dat al wel geweten en was dat al uitgewerkt.

Precies, dat laatste. Dit is ook een aardig voorbeeld. Onze servers staan in een flink beveiligde ruimte. We kunnen een categorie systemen toevoegen die niet in een beveiligde ruimte hoeven te staan maar waarom zouden we? Er is eigenlijk geen voordeel te behalen door ruimte te maken met minder sloten op de deur. De paar mensen die ooit in zelf in die ruimte hoeven te komen zijn toch dezelfde mensen die de andere ruimtes ook beheren.
Omgekeerd gaan we ook geen aparte ruimte bouwen die nog zwaarder beveiligd is. Een extra kooi in de huidige ruimte zou op zich wel kunnen, of maatregelen als nooit alleen aanwezig zijn. Maar vrijwel alles draait op één groot cluster, dat moeten we dan ook gaan opsplitsen.
Dan is het makkelijker om het beveiligingsniveau van de bestaande ruimtes te verhogen en maar gewoon alle systemen er onder te laten vallen.
Natuurlijk kan het in de toekomst weer anders worden en dan zou het wel relevant kunnen worden, maar er is al genoeg werk te doen. Ik acht de kans groter dat we alles in de cloud gaan hosten dan dat we nog nieuwe severruimtes gaan bouwen. Dat zien we dus wel als het zo ver is.

En dit klinkt als compliance / beleid oefening waar theorie en praktijk elkaar niet aanvullen.

Dat klopt, vanuit compliance moet er nieuwe beleid worden opgesteld. Dat klopt op zich maar de uitvoering is nog niet optimaal.

Het is soms ook kunnen verantwoorden van de maatregelen die er al zijn, of discussie voeren met de business. En wat je hier noemt is ook juist een risicoanalyse. Maak je 1 miljoen aan kosten voor de kans dat je 1x in de 5 jaar een ton aan schade hebt. Met een goede risicoanalyse zou je dat waarschijnlijk nooit doen.

Dat klopt natuurlijk maar ik wil er wel voor zorgen dat er ook echt iets af te wegen valt. Als ik bij voorbaat al weet dat iets niet haalbaar is dan wil ik het ook niet meegeven als realistische optie. Niks wat onze organisatie doet zal ooit vereisen dat we een gewapende bewaker met een vlammenwerper voor de deur zetten.

Ik probeer te voorkomen dat we allemaal vakjes gaan maken waarvan we er maar eentje echt gebruiken.

Ik snap dat je graag concrete maatregelen hoort, maar die zijn in mijn ogen nooit generiek. Afhankelijk van de context zou je juist per (groep) systemen met een hoge classificatie een risico analyse moeten doorlopen om tot maatregelen te komen. En dat is altijd specifiek voor jouw situatie.

Begrijp me niet verkeerd, ik ben vooral op zoek naar concrete maatregelen als tegenvoorbeeld tegen mijn eigen vooroordelen en onderbuikgevoelens. We doen een risicoanalyse van alle systemen. Daarmee kun je in specifieke situaties soms iets extra's doen (of laten) wat niet van toepassing is op andere systemen. Dat is dan typisch heel applicatie/situatie-specifiek. Alles wat algemeen genoeg is om standaardlijstjes op te nemen (filepermissies, minimale configuraties, toegangsbeheer, logging, auditting, monitoring) kun je net zo goed overal toepassen. Als je het eenmaal uitgezocht/gebouwd/gekocht hebt is het makkelijker om overal te doen dan per systeem/groep te gaan beoordelen of iets nodig is.

Mijn insteek is dus meer "Er is één standaardpakket met (nader vast te stellen) maatregelen. Dat pakket doe je overal, tenzij je een goede reden hebt om een uitzondering aan te vragen. Als de risicoanalyse iets laat zien dat nog niet gedekt is kijken we daar specifiek naar".

[CAPSLOCK2000]

Orangelights23 schreef op vrijdag 11 november 2022 @ 15:24:
Dit vraagstuk kan het beste beantwoord worden met een risico assessment. Daar bespreek je de elementen waar je naar zoekt. Zonder de hele context de weten, kunnen wij ook weinig nuttigs zeggen om te helpen.

Dank, hoewel het niet is wat ik vroeg steunt jouw reactie mijn gevoel dat onze huidige aanpak niet handig is.

[martijn.vw]

Het kan op zich best hoor, dat je basismaatregelen over de hele linie hetzelfde zijn. Is geen probleem.

Ik denk aan onderscheid in:

- Wie kan waarbij en waarom? Kan jij als domain admin bij elke server? Waarom? Hoe zijn servers gegroepeerd? Zijn er admins voor finance machines en admins voor HR machines?
- Er gaat een server down, of een service plat. Is dat belangrijk genoeg om jou voor wakker te bellen?

[Orangelights23]

CAPSLOCK2000 schreef op vrijdag 11 november 2022 @ 16:34:
[...]


Dank, hoewel het niet is wat ik vroeg steunt jouw reactie mijn gevoel dat onze huidige aanpak niet handig is.

Ik zie veel bedrijven worstelen met dergelijke vraagstukken, waarbij ze vaak de belangrijkste stap (risico assessments) overslaan en zelf willen bedenken wat wel/niet werkt. Ik heb dit bij tientallen bedrijven wereldwijd geïmplementeerd en daar zie je dat dit soort vraagstukken veel eenvoudiger en gesteund door onderzoek beantwoord kunnen worden. Dus goed dat je aangeeft dat mijn reactie je hierbij helpt!

[martijn.vw]

oak3 schreef op vrijdag 11 november 2022 @ 13:48:
Ik bedacht me er nog eentje: de ABDO norm van defensie, die geeft verschillende niveaus (4) van beveiliging aan: https://www.defensie.nl/o...ta-s/2020/02/04/abdo-2019

Zomaar een voorbeeld: links is het meest gevoelige niveau:
[Afbeelding]
Maar ook daar zie je betrekkelijk weinig verschil in de niveuas.

Betrekkelijk weinig, die is wel humor. Wat je daar ziet is wat TS ook mee worstelt: elk systeem moet zo goed mogelijk beschermd worden. De organisatorische maatregelen er omheen zijn veel belangrijker. Een simpele procedurele maatregel die zeer veel impact heeft is deze:

Het is niet toegestaan om gebruik te maken van groepsaccounts om gegevens te wijzigen
in bedrijfskritieke applicaties die zelf geen Identi=catie-, Authenticatie- en
authorisatiemechanisme hebben.

Technisch niet moeilijk, maar dan moet je ineens altijd en overal persoonlijke accounts gaan managen en dat kan best impact hebben.

[sOid]

Boeiende discussie, interessant om te lezen!

oak3 schreef op woensdag 9 november 2022 @ 15:09:
[...]

Btw, persoonlijk ben ik er ook niet zo'n fan van om BIV classificatie toe te passen. Meestal kun je toch geen onderscheid maken.

Dit hangt natuurlijk wel van een hoop factoren af. Om hoeveel applicaties/diensten het bijvoorbeeld gaat, maar ook met mogelijke wetgeving. Het is bijvoorbeeld belangrijker om uitgifte van paspoorten of het betalen van uitkeringen na een incident te kunnen hervatten dan het verstrekken van een bouwvergunning.

Of in een andere organisatie: het hervatten van de productielijn zal een hogere BIV-classificatie krijgen dan de systemen van de marketingafdeling weer online krijgen.

Een nuance die ik nog even wou toevoegen. Is volgens mij nog niet genoemd

[CAPSLOCK2000]

martijn.vw schreef op vrijdag 11 november 2022 @ 16:43:
Technisch niet moeilijk, maar dan moet je ineens altijd en overal persoonlijke accounts gaan managen en dat kan best impact hebben.

<leuk zijspoortje>
Dat is inderdaad een leuke waar ik veel ervaring mee heb. We zijn daar redelijk succesvol in, in ieder geval voor wat we zelf beheren, daar zijn gedeelde accounts al jaren uitgesloten en doe je alles met je eigen persoonlijke account(s). Bij diensten die we inkopen hebben we het helaas niet altijd voor het kiezen.

Een van de eerste eisen die wij stellen is ondersteuning voor (onze) Single Sign On. Als je dat hebt dan verdwijnt het gedeelde account probleem vanzelf.
</leuk zijspoortje>


<backontrack>
In een van de hardening-lijsten die ik heb bestudeerd kwam SSO voor als punt dat je kan weglaten op het laagste niveau. Dan zijn "lokale" accounts wel toegestaan. Maar als de applicatie SSO ondersteunt ben je gek als je dat niet gebruikt. Ieder alternatief kost eigenlijk altijd meer moeite en tijd om te beheren. Als de applicatie geen SSO ondersteunt dan zou je zo'n applicatie misschien moeten weigeren op hogere niveau's maar die keuze heb je niet altijd. Dan kom ik dus weer uit op één maatregel voor iedereen: "Je gebruikt altijd SSO".
Ik kan er allerlei voorwaarden aanhangen maar als puntje bij paaltje komt moeten uitzonderingen toch met mij worden besproken en dan wordt het maatwerk.

Ook hier weer kom er dus op uit dat ik één set regels wil hanteren. Uitzonderingen blijf je toch altijd houden en praktische redenen (zoals afwezige features) winnen het uiteindelijk van algemeen beleid.

[Voor 8% gewijzigd door CAPSLOCK2000 op 11-11-2022 17:14]

[Prx]

Risico analyses en afwegingen zijn toch wel echt het codewoord veelal. Single Sign-On geeft je de mogelijkheid om identificatie en authenticatie centraal te regelen, wat voordelen geeft voor use cases zoals termination, maar ook risico's omdat het gewoon toch veelal een comfortfunctie is zoals het vaak wordt geïmplementeerd. Alleen met het forceren van 2FA bij de inlogpoging zou ik het bij de High Secure systemen toepassen, omdat je echt zeker wilt weten dat de juiste persoon naar binnen gaat. Niet gewoon iemand die toegang heeft verkregen tot een systeem (op wat voor manier dan ook) waar je nu lekker door kunt klikken.

Je zit blijkbaar in de luxe positie bij de organisatie dat alles goed ingeregeld lijkt te zijn (conform jullie huidige wensen en eisen) en dat er geen onderscheid gemaakt hoeft te worden. Dit zal hoogstwaarschijnlijk dan alleen gaan veranderen als er ooit een kostenafweging gemaakt moet gaan worden. Dan leiden sommige eisen toch vaker tot een risico acceptatie, en die moet je goed uitvoeren en vastleggen.

Maar zolang dus alles superstreng kan en is... geniet er van!

En als je als organisatie eens wilt toetsen hoe goed je het doet, kijk dan eens naar de ISF Maturity Assessments. Dan kun je eens beoordelen hoe mature het er echt aan toe gaat. Wel eerlijk zijn dan, want het is en blijft een self-assessment.

[Voor 10% gewijzigd door Prx op 12-11-2022 23:00]

[CAPSLOCK2000]

Prx schreef op zaterdag 12 november 2022 @ 22:58:
Je zit blijkbaar in de luxe positie bij de organisatie dat alles goed ingeregeld lijkt te zijn (conform jullie huidige wensen en eisen) en dat er geen onderscheid gemaakt hoeft te worden.

Nee, zo is het ook weer niet. Maar het gaat er om dat er weinig maatregelen zijn die kan nemen die ik niet net zo makkelijk overal kan toepassen. Het gaat me dus eigenlijk om maatregelen niet niet goed schalen. Een voorbeeld is de maatregel "bel iedere maand de baas van alle gebruikers om te controleren dat ze nog in dienst zijn en de zelfde functie hebben". Dat kost veel tijd, zo iets kun je alleen bij ze zwaarts beveiligde servers doen. Maar dat is dan al eigenlijk geen technische eis meer maar vooruit, dat is een beetje waar ik tegenaan loop. Vrijwel alle technische eisen schalen wel dus dan is er weinig reden om het niet te doen.

Mijn boodschap is niet dat het bij ons zo geweldig is, maar dat het efficienter is om security kamerbreed uit te rollen zonder te kijken naar wat je nu aan het beschermen bent. In de IT zitten kosten in bouwen en onderhoud, niet in in installatie en configuratie want die zijn (als het goed is) toch al geautomatiseerd.

Ik wil geen lijstjes maken met 'deze maatregel op server wel en op die server niet wat het is niveau 2'. Ik wil het liefst 1 set maatregelen voor alles waar we dan in specifieke gevallen uitzonderingen op maken. (hosts groeperen in vlans op grond van welke security maatregelen er getroffen worden is al helemaal de omgekeerde wereld).

De reden om dat niet te doen is omdat het te duur, moeilijk of onhandig is. Maar van dat soort maatregelen zijn er niet zo veel.
Het is niet zo dat wij de luxe hebben dat we alles als doen en dus ook een paar ontzettende dure maatregelen hebben. Het komt meer van de andere kant, er is zo veel te winnen dat het niet veel hoeft te kosten. Doe het dan maar overal. Liever (bv) een uur extra software installeren dan bij iedere systeem 3 uur vergaderen of we de extra software gaan installeren.

En als je als organisatie eens wilt toetsen hoe goed je het doet, kijk dan eens naar de ISF Maturity Assessments. Dan kun je eens beoordelen hoe mature het er echt aan toe gaat. Wel eerlijk zijn dan, want het is en blijft een self-assessment.

Ik ken die Maturity levels en onze score. Laat ik het er op houden dat ik die niet ga delen.

De waarschuwing voor self-assesement komt me bekend voor. Wij hebben iemand ingehuurd om ons eerlijk te houden in deze "self"-assesment. Toch kan ik aan de hand van de resultaten zo vertellen wie de input voor welk stuk heeft gegeven, of in ieder geval welke afdeling en of het een manager was of iemand van de vloer. Of het doel was om eerlijk te zijn over de stand van zaken of dat het doel was om te "winnen" in het "examen".

[Voor 6% gewijzigd door CAPSLOCK2000 op 13-11-2022 12:04]

[CAPSLOCK2000]

Prx schreef op zaterdag 12 november 2022 @ 22:58:
maar ook risico's omdat het gewoon toch veelal een comfortfunctie is zoals het vaak wordt geïmplementeerd.

<zijspoor SSO>
Onderschat de waarde van comfort niet. Goede maatregelen moeten niet alleen technisch correct zijn maar ook uitvoerbaar. Mensen leren om goed met wachtwoorden om te gaan is bijzonder moeilijk. Zowel aan de kant van de gebruiker als aan de kant van de ontwikkelaar.

Ik kan nog zoveel vertellen over wachtwoordbeleid en passwordmanagers maar er is altijd een flinke groep die zich er onderuit werkt. Als die mensen toen kunnen met slechts 1 wachtwoord dat ze echt van buiten kennen dan heeft dan flinke voordelen.

Minstens zo belangrijk is dat applicaties zelf geen wachtwoorddatabase bij hoeven te houden. Iedere extra applicatie met een eigen lijstje wachtwoorden is een extra zwak punt dat beveiligd moet worden. Daarbij houd ik in het achterhoofd dat veel mensen nog steeds overal (ongeveer) hetzelfde wachtwoord gebruiken. Het lekken van 1 zo'n wachtwoorddatabase betekent dan al snel dat andere applicaties ook lek zijn.

Door het centraal te regelen voorkom je dat mensen wachtwoorden op briefjes schrijven of voortdurend copy/pasten (en af en toe op de verkeerde plek plakken), dat iedere applicatie z'n eigen wachtwoorddb heeft die aparte beveiligd en gemonitored moet worden of dat wachtwoorden gedeeld worden tussen applicaties.

Dit soort voordelen tellen extra hard bij applicaties die extern worden beheerd. Hoe minder data ze van ons hebben hoe minder er kan lekken.

Je hebt uiteraard gelijk dat het niet het enige moet zijn wat je doe en dat 2fa nodig blijft.

</zijspoor>

Alleen met het forceren van 2FA bij de inlogpoging zou ik het bij de High Secure systemen toepassen, omdat je echt zeker wilt weten dat de juiste persoon naar binnen gaat. Niet gewoon iemand die toegang heeft verkregen tot een systeem (op wat voor manier dan ook) waar je nu lekker door kunt klikken.

Dat is een mooi pad terug naar mijn kernvragen.
Waarom zou je 2FA weglaten bij minder belangrijke systemen? Als je eenmaal hebt vastgesteld dat inloggen wenselijk is dan is de meerprijs van 2fa in mijn ogen triviaal. Zeker als je authenticatie al centraal geregeld hebt (bv via SSO) zodat de nieuwe applicatie kan aanhaken bij bestaande infrastructuur.

Ik snap dat je geen 2fa in je organisatie gaat introduceren voor een onbelangrijke test-applicatie, maar als je het toch al in huis hebt, waarom niet? Voor mij is het "al onze webbservers draaien deze configuratie en authenticatie met 2fa hoort daar bij". Het gedoe van het beheren van meerdere divergerende configuraties is een grotere belasting dan 2fa gebruiken op systemen die dat strict genomen niet nodig hebben.