Het cyberbeveiligingsraamwerk van het Amerikaanse National Institute of Standards and Technology (NIST) is een van ’s werelds belangrijkste richtlijnen voor het beveiligen van netwerken. Het kan worden toegepast op een willekeurig aantal applicaties, inclusief SaaS.
Een van de uitdagingen waarmee degenen die belast zijn met het beveiligen van SaaS-applicaties worden geconfronteerd, zijn de verschillende instellingen die in elke applicatie voorkomen. Het maakt het moeilijk om een configuratiebeleid te ontwikkelen dat van toepassing is op een HR-app die werknemers beheert, een marketing-app die inhoud beheert en een R&D-app die softwareversies beheert, en dat alles terwijl het in lijn is met de NIST-compliancenormen.
Er zijn echter verschillende instellingen die op vrijwel elke app in de SaaS-stack kunnen worden toegepast. In dit artikel onderzoeken we enkele universele configuraties, leggen we uit waarom ze belangrijk zijn en begeleiden we u bij het instellen ervan op een manier die de beveiligingspositie van uw SaaS-apps verbetert.
Begin met beheerders
Op rollen gebaseerde toegangscontrole (RBAC) is een sleutel tot naleving van NIST en moet op elke SaaS-app worden toegepast. Er zijn twee soorten machtigingen binnen een SaaS-applicatie. Functionele toegang omvat zaken als het aanmaken van accounts en het navigeren door de applicatie. Toestemmingen voor gegevenstoegang bepalen daarentegen welke gebruikers gegevens kunnen ophalen en wijzigen. Het beheerdersaccount (of het superbeheerdersaccount in sommige apps) is het meest gevoelig binnen de app, omdat het volledige toegang heeft tot beide soorten machtigingen.
Voor bedreigingsactoren is het hacken van een beheerdersaccount vergelijkbaar met het winnen van de loterij. Ze hebben toegang tot alles. Organisaties moeten er alles aan doen om de controle over deze accounts te behouden. Deze controle wordt beheerd via configuraties en best practices.
Implementeer beperkte redundantie
Het is belangrijk om voor elke toepassing minimaal twee beheerders te hebben. Deze redundantie maakt het moeilijk voor een beheerder om alleen te handelen in strijd met de belangen van de organisatie, omdat beheerders elkaar kunnen controleren op tekenen van een inbreuk.
Elke beheerder vergroot echter het aanvalsoppervlak van de applicatie. Organisaties moeten een evenwicht vinden tussen het hebben van voldoende beheerders om de applicatie adequaat te kunnen bedienen en het beperken van de blootstelling. Een geautomatiseerde beoordeling van het aantal beheerders zou waarschuwingen moeten activeren wanneer het aantal beheerders buiten het gewenste bereik valt.
Elimineer externe beheerders
Externe beheerders introduceren een nieuwe laag van onzekerheid in SaaS-beveiliging. Omdat ze buiten de organisatie zitten, heeft het beveiligingsteam geen controle over het wachtwoordbeleid of de authenticatietools die ze gebruiken.
Als een bedreigingsacteur bijvoorbeeld probeert in te loggen op uw applicatie en op Wachtwoord vergeten klikt, is er geen manier om te weten of de bedreigingsacteur het e-mailaccount van de externe beheerder kan binnendringen. Dat gebrek aan toezicht op externe gebruikers zou kunnen leiden tot een diepe inbreuk op uw SaaS-applicatie. Daarom raadt NIST af om externe beheerders in te schakelen. Afhankelijk van de applicatie kunt u voorkomen dat externe beheerders beheerdersrechten krijgen of kunt u externe gebruikers met beheerdersrechten identificeren en deze bevoegdheden verwijderen.
Voor bedrijven die een extern IT-bedrijf inhuren of uitbesteden aan MSSP’s, mogen deze personen niet als extern worden beschouwd. Ze moeten echter blijven controleren of andere externe gebruikers beheerdersrechten krijgen.
Vereist beheerders-MFA
Om te voldoen aan de NIST-standaarden moeten alle beheerdersgebruikersaccounts toegang hebben tot de applicatie met behulp van multi-factor authenticatie (MFA), zoals een eenmalig wachtwoord (OTP). MFA vereist dat gebruikers minimaal twee vormen van ID presenteren voordat de gebruiker wordt geverifieerd. Een bedreigingsacteur zou twee authenticatiesystemen moeten compromitteren, waardoor de moeilijkheidsgraad van de compromittering toeneemt en het risico voor het account wordt verkleind. Zorg ervoor dat u MFA voor beheerders naar wens instelt (we raden MFA ook aan voor alle gebruikers, maar het is een must-have voor beheerders).
Download deze checklist en leer hoe u uw SaaS-beveiliging kunt afstemmen op NIST
Voorkom datalekken
SaaS-datalekken vormen aanzienlijke risico’s voor organisaties en hun gebruikers, waardoor gevoelige informatie die is opgeslagen in cloudgebaseerde applicaties mogelijk in gevaar komt. SaaS-applicaties worden op de markt gebracht als samenwerkingstools. De configuraties waarmee gebruikers kunnen samenwerken, kunnen echter ook bestanden en gegevens in gevaar brengen. NIST pleit op zijn beurt voor het monitoren van de toestemmingen van elke bron.
Een zichtbare agenda kan werknemers blootstellen aan sociaal ontworpen phishing-aanvallen, terwijl gedeelde opslagplaatsen ertoe kunnen leiden dat de interne broncode van een bedrijf openbaar wordt gedeeld. E-mail, bestanden en borden bevatten allemaal gevoelige gegevens die niet toegankelijk mogen zijn voor het publiek. Hoewel de volgende configuraties in elke toepassing vaak iets anders worden genoemd, heeft bijna elke app waarin inhoud wordt opgeslagen dit soort controle.
Stop met openbaar delen
Het verschil tussen Deel met iedereen en Deel met een gebruiker is groot. Wanneer items met iedereen worden gedeeld, heeft iedereen met een link toegang tot de materialen. Delen met een gebruiker voegt daarentegen een extra authenticatiemechanisme toe, omdat de gebruiker moet inloggen voordat hij toegang krijgt tot het materiaal.
Om de inhoud die wordt weergegeven te verminderen, moeten app-beheerders het delen via openbare URL’s (“Iedereen met de link”) uitschakelen. Bovendien bieden sommige toepassingen gebruikers de mogelijkheid de toegang tot URL’s in te trekken die al zijn aangemaakt. Indien beschikbaar moeten organisaties deze instelling aanzetten.
Stel uitnodigingen in op Verlopen
Bij veel applicaties kunnen geautoriseerde gebruikers externe gebruikers uitnodigen voor de applicatie. De meeste toepassingen implementeren echter geen vervaldatum voor uitnodigingen. In die omstandigheden kunnen uitnodigingen die jaren geleden zijn verzonden toegang bieden tot een bedreigingsacteur die zojuist het e-mailaccount van een externe gebruiker heeft gehackt. Door een automatische vervaldatum op uitnodigingen in te schakelen, wordt dat soort risico geëlimineerd.
Het is vermeldenswaard dat in sommige apps configuratiewijzigingen met terugwerkende kracht gelden, terwijl andere pas in de toekomst van kracht worden.
Stem uw SaaS-beveiliging af op NIST-standaarden – download de volledige handleiding
Wachtwoorden versterken om de applicatiebeveiliging te verbeteren
Wachtwoorden vormen de eerste verdedigingslinie tegen ongeoorloofde toegang. NIST pleit voor een sterk en goed beheerd wachtwoordbeleid, dat essentieel is voor de bescherming van gevoelige gebruikersgegevens, vertrouwelijke bedrijfsinformatie en eigendommen die zijn opgeslagen in de cloudgebaseerde infrastructuur. Het unieke karakter, de complexiteit en het regelmatig bijwerken van wachtwoorden zijn cruciale aspecten van een robuust beveiligingsbeleid.
Wachtwoorden dienen als een fundamenteel element in een gelaagde beveiligingsaanpak en vormen een aanvulling op andere beveiligingsmaatregelen zoals multi-factor authenticatie (MFA) en encryptie. Gecompromitteerde wachtwoorden kunnen een toegangspoort zijn voor kwaadwillende actoren om kwetsbaarheden in de SaaS-omgeving te misbruiken. Het effectieve beheer van wachtwoorden vergroot de algehele veerkracht van SaaS-systemen en draagt bij aan een veiliger en betrouwbaarder digitaal ecosysteem voor zowel bedrijven als hun gebruikers.
Voorkom wachtwoordspray-aanvallen
Bij een sprayaanval voeren bedreigingsactoren een gebruikersnaam en algemene wachtwoordtermen in, in de hoop geluk te hebben en toegang te krijgen tot de applicatie. Het vereisen van MFA is de aanbevolen manier om wachtwoordspray-aanvallen te voorkomen. Voor degenen die er niet op aandringen dat werknemers MFA gebruiken als onderdeel van het authenticatieproces: veel apps bieden organisaties de mogelijkheid om te verbieden dat woorden als wachtwoord worden gebruikt. Deze lijst met woorden bevat termen als wachtwoord1, letmein, 12345 en de namen van lokale sportteams. Bovendien zou het termen bevatten zoals de naam van de gebruiker, bedrijfsproducten, partners en andere zakelijke termen.
Door naar de configuraties te gaan en een aangepaste lijst met verboden woorden toe te voegen, kunt u het risico op een succesvolle wachtwoordspray-aanval aanzienlijk verminderen.
Wachtwoordcomplexiteit
Met de meeste SaaS-applicaties kan de organisatie de complexiteit van wachtwoorden aanpassen. Deze variëren van het toestaan van elk wachtwoord tot het vereisen van alfanumerieke tekens, hoofdletters en kleine letters, symbolen of een wachtwoordlengte. Update de wachtwoordvereisten in de app zodat deze overeenkomen met het beleid van uw organisatie.
Als uw organisatie geen wachtwoordbeleid heeft, kunt u overwegen de NIST-richtlijnen te volgen:
- Voer geen verplichte wachtwoordwijzigingen door, aangezien gebruikers vaak gemakkelijk te onthouden wachtwoorden kiezen.
- Gebruik lange wachtwoorden in plaats van complexe wachtwoorden. Combinaties van cijfers, speciale tekens en kleine/hoofdletters volgen meestal het volgende formaat: Wachtwoord1!. Deze zijn gemakkelijk te brute kracht. Een lang wachtwoord zoals MyFavoriteDessertIsPecanPie is gemakkelijk te onthouden, maar met 27 tekens moeilijk te brute kracht.
- Beperk wachtwoordpogingen tot niet meer dan 10.
- Scherm wachtwoorden af tegen gepubliceerde wachtwoorden en andere gemakkelijk te raden woorden met een lijst met verboden woorden.
Configuraties zijn echt belangrijk
Ongeveer 25% van alle cloudgerelateerde beveiligingsincidenten begint met een verkeerd geconfigureerde instelling. Naast de hier genoemde met betrekking tot toegang, wachtwoord en datalekken, die redelijk universeel zijn, worden configuraties gebruikt voor sleutelbeheer, mobiele beveiliging, operationele veerkracht, phishing-bescherming, SPAM-bescherming en meer. Verkeerde configuraties op elk van deze gebieden kunnen direct tot inbreuken leiden.
Het lijkt misschien onwaarschijnlijk dat dreigingsactoren hun tijd besteden aan het zoeken naar verkeerde configuraties die ze kunnen uitbuiten. Toch is dat precies wat de Russische, door de staat gesponsorde groep Midnight Blizzard deed toen het dit jaar inbreuk maakte op Microsoft. Als er bij Microsoft verkeerde configuraties kunnen voorkomen, is het de moeite waard om te controleren of uw applicaties allemaal veilig zijn.
Bekijk hoe u NIST-standaarden kunt toepassen op uw SaaS-stack
