Guideline Hardening
* Concept version: (NL. to be completed and translated)
** Aanvankelijk verplichte referenties naar de (disfunctionele) BIO/ISO-2700x verwijderen!
** Safeguard architectuur info toevoegen.
< Inhoudsopgave toevoegen >
Inleiding:
Hardening is de gebruikelijke term voor het uitvoeren van een aantal handelingen om een computersysteem beter te beveiligen. Deze handelingen zijn gericht op het beperken van de kwetsbaarheden in een systeem, en omvatten onder meer het verwijderen van onnodige gebruikersaccounts, het kiezen van waarden voor parameters, en het verwijderen of stoppen van overbodige services, applicaties en stuurprogramma’s. Door services, applicaties en stuurprogramma’s, die niet strikt nodig zijn voor het functioneren van het systeem, niet op te nemen in de configuratie wordt de kans op kwetsbaarheden op het systeem gereduceerd. Door standaard accounts en privileges uit te sluiten en te minimaliseren wordt misbruik beperkt.
Wikipedia: In computing, hardening is usually the process of securing a system by reducing its surface of vulnerability.
Er is door de ******* organisatie gekozen om het “secure by design” principe te gebruiken.
Dit betekend in essentie dat als eerste getracht moet worden om zwakke plekken en structurele tekortkomingen bij voorbaat te voorkomen.
Dit kan door allereerst systemen en technieken te kiezen waarvan bekend is dat die aantoonbaar op basis van het “secure by design” opgebouwd zijn. En daarmee afstand te nemen van producten, systemen en technieken waarvan algemeen bekend is dat die zeker niet “secure by design” zijn.
* De preventieve “secure by design” aanpak, lijkt deels een andere insteek te hebben dan de “risk assement based, security measures” aanpak die meer op symptoombestrijding gericht lijkt te zijn.
Notities:
Het is van essentieel belang dat:
1. Er één korte en overzichtelijke basis lijst is met welke informatiebeveiligingseisen er gesteld worden aan nieuwe informatiesystemen. En welke eisen aan uitbereiding of aanpassing van bestaande.
2. Dat bij nieuwe systemen de lijst gebruikt is bij het maken van keuzes vóór de inrichting van de services.
Voorbeeld draaiboek:
Er is gekozen om een nieuwe service applicatie te gaan realiseren voor verwerking van aanvragen.
Gestelde Randvoorwaarden:
. De applicatie moet toegankelijk zijn via het publieke internet.
. De aanvragen mogen alleen gedaan worden door geïdentificeerde personen i.v.m. de vertrouwelijkheid van informatie.
. De nieuwe service applicatie moet daarvoor gegevens doorgeven naar, en ophalen van, interne centrale verwerkingssystemen waar van buiten de ******* organisatie geen toegang toe mogelijk mag zijn.
Om aan de randvoorwaarden te kunnen gaan voldoen moet er een gedegen basis fundament zij om een en ander te kunnen gaan waarborgen.
Daarvoor kunnen de volgende stappen doorlopen worden.
-
Daarbij is het K.I.S.S. principe van essentieel belang om zo min mogelijk kwetsbaarheid te veroorzaken tijdens het ontwikkelen en in gebruik nemen van een service.
Als een applicatie bijvoorbeeld standalone kan gaan functioneren, zonder dat daar allerlei lagen en afhankelijkheden aan toegevoegd worden. Dan heeft dat de sterke voorkeur.
Een service dient zo veel mogelijk geïsoleerd te kunnen functioneren, om bij voorbaat te voorkomen dat er ongewenste functionaliteit aangesproken kan worden.
Een voorbeeld:
Optie a)
Om een web service applicatie te realiseren, zou men kunnen kiezen om te ontwikkelen op basis van Java (AOT) of andere naar machine code compileerbare programmeer taal.
Daaruit kan dan een op zichzelf staande applicatie komen, waar geen ontwikkel fase overblijfselen en afhankelijkheden meer in zitten zoals debug of OS.process.start() functies en libraries die niet door de applicatie gebruikt worden.
De service applicatie kan dan vervolgens geplaatst worden in een Micro Jail, waardoor er gewoon geen mogelijkheden meer zijn om via eventuele kwetsbaarheden in de applicatie zelf toegang te kunnen krijgen tot het onderliggende besturingssysteem.
Eventueel nodige extra componenten kunnen specifiek toegevoegd worden aan de Micro Jail.
Dit heeft ook velen voordelen voor vereenvoudiging van systeembeheer (o.a. dat OS en andere security patching minimaal relevant is).
Waardoor er gesproken kan worden over "in control" zijn.
Voor de Hardening van werkstations, smart-phones en tablets kan een soortgelijke aanpak gebruikt worden.
Waarbij er een "secure by design" Operating System (OS) ingezet word, waarop gebruikers applicatie processen binnen separate proces jails functioneren.
Daarmee kan malware, virussen, en dergelijke ongewenste toegang tot het OS en andere processen bij voorbaat volledig worden voorkomen. Maar ook voorkomen worden dat 3rd party applications onopgemerkt vertrouwelijke informatie doorgeven naar systemen buiten het apparaat.
Optie b)
Om een web service applicatie te realiseren, zou men kunnen kiezen om te ontwikkelen op basis van leesbare code die pas run-time omgezet word naar machine code zoals bijvoorbeeld ASPX, PHP, Java-Script, etc.. of applicatie containers zoals Java.war, DotNet.Core, OpenShift, Docker, enz.
Daarvoor zou dan directe of indirecte Operating System (OS) toegang beschikbaar zijn voor de applicatie; om daar binnen een Web-Service zoals bijv. IIS of Apache+Tomcat, etc... te laten functioneren; om daarmee de eigenlijke service applicatie uit te laten voeren.
Daarbij worden dan ook veel (extra) programma's en libraries beschikbaar gesteld, waarvan een groot deel niet nodig is maaar wel aangeroepen kan worden door kwaadwillende.
Al die verknoopte componenten moeten ook beheerd, bijgewerkt en gemonitord worden.
Er kan dan natuurlijk geen spraken zijn van "in control" zijn, als gevolg van een te ontastbare complexiteit met een evenredig groot aanvals-oppervlak.
Als er onverhoopt optie (b) gekozen word, dan is het natuurlijk van belang om het gecreëerde aanvalsoppervlak alsnog zo ver mogelijk te trachten te verkleinen.
Daarvoor kan eventueel een van de normenkaders als leidraad genomen worden.
3rd party Applicatie / Service Hardening:
Voor gebruik van applicaties die niet zelf ontwikkeld zijn, en waarvan algemeen bekend is dat ze niet "secure by design" gemaakt worden, waardoor er regelmatig ernstige kwetsbaarheden (CVE's) gevonden worden.
Is het zaak om die niet alleen in een micro jail omgeving te plaatsen, maar daarbij ook een aantal maatregelen te treffen om zo veel mogelijk te voorkomen dat die services aangevallen worden.
Hiervoor zijn de volgende samenhangende mogelijkheden.
. Configuratie opties helemaal doorgronden om de beschikbare security opties te benutten.
Er word helaas te veel voor een "default install" gekozen, waarbij de opties die er zijn om betere bescherming te realiseren niet of onvoldoende in overweging genomen worden.
Het is de moeite waard om daar de nodige aandacht aan te besteden, om vervolgens als organisatie zelf een degelijke configuratie "baseline" in te richten.
. Verwijderen en/of uitzetten van functionaliteit die niet nodig is.
Sommige service applicaties zijn modulair opgebouwd, waarbij men zelf kan bepalen welke modulus er wel/niet gebruikt kunnen worden. En of er extra modules beschikbaar zijn die de beveiliging verbeteren.
Het is de moeite waard om daar de nodige aandacht aan te besteden, om vervolgens als organisatie zelf een degelijke configuratie "baseline" in te richten.
. Onjuiste (meta) data informatie publiceren. Om aanvallers te misleiden.
Bijvoorbeeld bij gebruik van een Apache web service, er voor te zorgen dat de service zich niet naar buiten bekend maakt als "Server: Apache/2.3.4 (RedHat) Mod_SSL(1.2)"
Maar door aanpassing in de configuratie er voor te zorgen, dat in plaats daarvan naar buiten gemeld word "Server: nginx v2.3b (QNX v7.1:UltraSPARC-T2)"
. Exploit attempt triggers.
Men kan "exploit attempt triggers" toevoegen. Waardoor pogingen tot misbruik van een service/systeem direct gedetecteerd worden, om verdere acties van aanvallers direct automatisch te blokkeren.
Om deze preventieve methode in te richten zijn de volgende punten van belang:
- [restricted information]
- ...
- ...
Database / Data bron service hardening
(Frontend) Applicaties maken vaak gebruik van (Backend) data bron services op separate servers, zoals database en file servers om informatie verder te verwerken.
Die data bronnen kunnen vertrouwelijke informatie bevatten, vaak grote hoeveelheden informatie waar onder geen enkele omstandigheid toegang toe mag worden verleend aan de eindgebruiker van de gebruikersapplicatie. Zoals bijvoorbeeld dat er via de web applicatie https://mijnstrafdossiers.rechtspraak.nl/ geen toegang mogelijk mag zijn tot alle dossiers data die opgeslagen is in de achterliggende systemen.
Notitie: Er zijn een aantal wegen bekend om, via een frondend applicatie service stack, volledige toegang te kunnen krijgen tot de backend systemen.
Zoals bijvoorbeeld SQL injection, Buffer overflow, Configuration flaw, Logic flaw, OS shell execution functionaliteit (1) (2) (3), etc.
Dit geld niet alleen voor Database servers maar ook voor content delivery backends.
Het is daarom natuurlijk van cruciaal belang om de backend services te beschermen tegen al die vormen van ongeautoriseerde toegang.
De volgende methodes kunnen gebruikt worden om de backend services te beschermen.
- Het backend proces plaatsen in een micro jail.
Waardoor er geen extra processen gestart kunnen worden.
- Geen directe data verbinding tussen het frontend systeem en de backend data verwerking systemen.
Door gebruik te maken van een separate tussenstap server, waarmee alleen via Common Gateway Interface (CGI) / Application Programming Interface (API) gecommuniceerd word met de data backend systemen.
Web service gebruiker <=> Web service server <=> CGI/API gateway <=> Backend service server ↔ Data.
Hierbij is het van essentieel belang dat het frontend systeem niet het zelfde soort instructies en data formaat gebruikt als door het backend systeem uitgevoerd kan gaan worden. Waarbij de gateway er ook voor zorgt dat de datavelden door "Sanitizing"<link> geen enkele vorm van door een backend uitvoerbare instructies (commands / overflows / other tricks) meer kan bevatten.
Bijvoorbeeld voor SQL services: Als een gebruiker zijn/haar wachtwoord wil aanpassen.
- Dan kan er in een frontend applicatie een database opdracht gemaakt en naar de backend verstuurd worden. Zoals:
UPDATE Gebruikers SET ContactPassword = 'Welkom2022?', LatestChange= '2022-04-01 11:11h CET' WHERE GebruikerID = 1001;
+ Of kan er in een frontend applicatie een data verwerking verzoek opdracht gemaakt worden dat door een separate CGI/API gateway server vertaald word naar bovenstaande opdracht.
<req: ChangePass> <user: 1001> <data: 'Welkom2022?', '2022-04-01 11:11h CET'>
... Stored procedures
... exploit attempt triggers- .. [restricted information]
..
