Säkra konfigurationsbaslinjer för NIS2 och DORA

Felkonfigurationen på fredagseftermiddagen som blev en styrelsefråga

Klockan 16.40 en fredag godkände den teknikansvarige för en fintechplattform det som såg ut som en rutinmässig brandväggsändring. En tillfällig regel öppnades för felsökning av en integration med en leverantör av betalningsanalys. I ärendet stod det: ”ta bort efter test”. Testet gick igenom. Regeln blev kvar.

Tre veckor senare hittade en extern skanning ett administrativt gränssnitt som var nåbart från internet. Servern var patchad. MFA fanns för vanliga användare. Sårbarhetsskannern flaggade ingen kritisk CVE. Men systemet var fortfarande inte säkert, eftersom konfigurationen hade avvikit från organisationens godkända härdade läge.

På måndagsmorgonen hade informationssäkerhetschefen (CISO) fyra parallella samtal:

1. Tillsynsmyndigheten ville veta om den operativa resiliensen hade påverkats.
2. Dataskyddsombudet ville veta om personuppgifter hade exponerats.
3. Styrelsen ville veta varför ”tillfälliga” ändringar inte upptäcktes.
4. Internrevisorn för ISO/IEC 27001:2022 ville se bevis på att säkra baslinjer var definierade, godkända, införda och övervakade.

Det är här många säkerhetsprogram upptäcker en obekväm sanning. Säker konfiguration är inte bara en teknisk checklista för härdning. Under 2026 är säkra konfigurationsbaslinjer en fråga om styrning, cyberhygien, IKT-risk, revisionsbevis och styrelsens ansvarsskyldighet.

En annan version av samma problem utspelar sig i många reglerade organisationer. Maria, CISO för en växande B2B-betalningsförmedlare, har kompetenta ingenjörer, patchade system och god praxis för moln. Men en beredskapsbedömning för NIS2 och DORA visar en röd iakttagelse: avsaknad av formaliserade säkra konfigurationsbaslinjer. Teamet vet hur servrar ska härdas, men mycket av den kunskapen finns i ingenjörernas huvuden, inte i godkända standarder, automatiserade kontroller eller underlagspaket.

Den luckan är inte längre försvarbar. NIS2 kräver att ledningsorgan godkänner och utövar tillsyn över åtgärder för hantering av cybersäkerhetsrisker. DORA kräver ett dokumenterat ramverk för IKT-riskhantering och resilient IKT-drift. GDPR kräver lämpliga tekniska och organisatoriska åtgärder. ISO/IEC 27001:2022 kräver riskbaserat urval av kontroller, genomförande, övervakning, revision och ständig förbättring.

Säkra konfigurationsbaslinjer kopplar samman alla dessa skyldigheter i ett praktiskt kontrollsystem: definiera baslinjen, tilldela ägarskap, tillämpa den vid åtkomsttilldelning och provisionering, styra undantag, upptäcka konfigurationsdrift, visa underlag och förbättra efter revisioner eller incidenter.

Som Clarysecs Zenith Blueprint: en revisors 30-stegs färdplan uttrycker det i fasen Controls in Action, steg 19, tekniska kontroller I:

”Många incidenter beror inte på programvarubrister, utan på dåliga konfigurationsval. Standardlösenord som lämnas oförändrade, osäkra tjänster som är aktiverade, onödiga portar som är öppna eller system som exponeras mot internet utan motivering.”

Den meningen fångar varför säkra konfigurationsbaslinjer nu är en central resilienskontroll. De definierar vad säkert betyder innan en revisor, tillsynsmyndighet, kund eller angripare frågar.

Vad en säker konfigurationsbaslinje egentligen är

En säker konfigurationsbaslinje är den godkända, dokumenterade och repeterbara uppsättningen säkerhetsinställningar för en systemtyp. Den kan tillämpas på Windows-servrar, Linux-värdar, nätverksenheter, SaaS-miljöer, molnlagring, Kubernetes-kluster, databaser, brandväggar, slutpunkter, identitetsplattformar, IoT-enheter och operativ teknik (OT).

En stark baslinje besvarar praktiska frågor:

• Vilka tjänster är inaktiverade som standard?
• Vilka portar får exponeras externt?
• Vilka inställningar för autentisering och MFA är obligatoriska?
• Vilka loggningsinställningar ska vara aktiverade?
• Vilka krypteringsinställningar krävs?
• Vilka administrativa gränssnitt är begränsade?
• Vilka molnresurser får vara publika, och enligt vems godkännande?
• Vilka avvikelser kräver riskacceptans?
• Hur ofta kontrollerar vi konfigurationsdrift?
• Vilket underlag visar att baslinjen fungerar?

Det vanligaste felet är att behandla baslinjer som tekniska preferenser i stället för styrda kontroller. En Linux-administratörs checklista, en molnarkitekts wikisida och en nätverksingenjörs brandväggskonvention kan alla vara användbara, men de blir inte granskningsbara förrän de har godkänts, kopplats till risk, tillämpats konsekvent och övervakats.

Det är därför ISO/IEC 27001:2022 är en så användbar förankring. Avsnitt 4.1 till 4.3 kräver att organisationer förstår interna och externa frågor, intressenter och ISMS-omfattning, inklusive rättsliga, regulatoriska, avtalsmässiga och tredjepartsrelaterade krav. Avsnitt 6.1.2 och 6.1.3 kräver riskbedömning för informationssäkerhet, riskbehandling, kontrollurval, en tillämpbarhetsförklaring och godkännande från riskägare. Avsnitt 8.2 och 8.3 kräver att riskbedömningar och riskbehandling upprepas med planerade intervall eller efter betydande ändringar.

Bilaga A gör därefter den tekniska förväntan konkret genom A.8.9 Konfigurationshantering, med stöd av tillgångsförteckning, hantering av sårbarheter, ändringshantering, loggning, övervakning, åtkomstkontroll, kryptografi, användning av molntjänster och dokumenterade driftrutiner.

Resultatet är ett enkelt men kraftfullt styrningsuttalande: om organisationen inte kan visa vad säkert betyder för varje större systemtyp kan den inte övertygande visa cyberhygien enligt NIS2, kontroll av IKT-risk enligt DORA, ansvarsskyldighet enligt GDPR eller kontrolleffektivitet enligt ISO/IEC 27001:2022.

Varför NIS2, DORA och GDPR gör baslinjer oundvikliga

NIS2, DORA och GDPR använder olika språk, men de möts i samma operativa krav: system ska konfigureras säkert, övervakas kontinuerligt och styras genom ansvarsskyldig riskhantering.

NIS2 Article 20 kräver att ledningsorgan i väsentliga och viktiga entiteter godkänner åtgärder för hantering av cybersäkerhetsrisker, övervakar genomförandet och får utbildning i cybersäkerhet. Article 21 kräver lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder. Säkra konfigurationsbaslinjer stöder Article 21(2)(a) policyer för riskanalys och informationssystemsäkerhet, Article 21(2)(e) säkerhet vid anskaffning, utveckling och underhåll av nätverks- och informationssystem, inklusive sårbarhetshantering, Article 21(2)(f) policyer och rutiner för att bedöma effektivitet, Article 21(2)(g) grundläggande cyberhygien och cybersäkerhetsutbildning, Article 21(2)(h) kryptografi, Article 21(2)(i) åtkomstkontroll och tillgångshantering samt Article 21(2)(j) flerfaktorsautentisering och säker kommunikation.

DORA gäller från den 17 januari 2025 och fungerar som den sektorsspecifika regelboken för digital operativ resiliens för omfattade finansiella entiteter. Articles 5 och 6 kräver styrning och ett dokumenterat ramverk för IKT-riskhantering. Article 8 kräver identifiering av IKT-tillgångar, informationstillgångar, IKT-stödda verksamhetsfunktioner och beroenden. Article 9 kräver skydds- och förebyggande åtgärder, inklusive säkerhetspolicyer, rutiner, protokoll och verktyg för IKT-system, säker dataöverföring, åtkomstkontroll, stark autentisering, skydd av kryptografiska nycklar, ändringshantering, patchning och uppdateringar. Articles 10 till 14 utvidgar modellen till detektering, respons, återhämtning, säkerhetskopiering, återställning, lärande och kommunikation.

GDPR tillför dataskyddsperspektivet. Articles 5 och 32 kräver riktighet, konfidentialitet, säkerhet i behandlingen och ansvarsskyldighet genom lämpliga tekniska och organisatoriska åtgärder. Publika molnbuckets, överexponerade databaser, osäkra standardinställningar och överdriven administrativ åtkomst är inte bara infrastruktursvagheter. De kan bli brister i skyddet av personuppgifter.

Ett enda program för säkra konfigurationsbaslinjer kan stödja alla tre regelverken utan att skapa dubbla underlagsflöden.

Clarysecs baslinjemodell: policy, rutin och plattformsunderlag

Clarysec behandlar säker konfiguration som ett repeterbart kontrollsystem, inte som ett engångsprojekt för härdning. Baslinjen ska vara auktoriserad genom policy, omsättas i rutiner, införas genom tekniska kontroller och styrkas med underlag.

Informationssäkerhetspolicyn fastställer denna förväntan på organisationsnivå:

”Organisationen ska upprätthålla en minsta kontrollbaslinje som härrör från ISO/IEC 27001 bilaga A, vid behov kompletterad med kontroller från ISO/IEC 27002, NIST SP 800-53 och COBIT 2019.”
Från avsnittet ”Riskbehandling och undantag”, policyklausul 7.2.1.

Denna klausul förhindrar att konfigurationshärdning blir en samling personliga preferenser. Den förankrar den lägsta kontrollbaslinjen i erkända ramverk.

För molnmiljöer preciserar Policy för användning av molntjänster kravet:

”Alla molnmiljöer ska uppfylla en dokumenterad baskonfiguration som har godkänts av molnsäkerhetsarkitekten.”
Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.3.1.

Policy för revision och efterlevnadsövervakning gör därefter baslinjen till en övervakad kontroll:

”Automatiserade verktyg ska driftsättas för att övervaka konfigurationsefterlevnad, hantering av sårbarheter, patchstatus och privilegierad åtkomst.”
Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.4.1.

Konfiguration är också oskiljbar från hantering av sårbarheter och patchning. Policy för sårbarhets- och patchhantering anger:

”Åtgärdande av sårbarheter ska vara förenligt med baskonfiguration och standarder för systemhärdning.”
Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.4.1.

Den punkten är viktig. Ett system kan vara patchat och ändå vara osäkert om SMBv1 är aktiverat, administrativa gränssnitt är exponerade, loggning är inaktiverad eller svaga autentiseringsinställningar finns kvar. I Zenith Controls: guiden för korsvis efterlevnad behandlas konfigurationshantering som en förebyggande kontroll som skyddar konfidentialitet, riktighet och tillgänglighet, med operativ förmåga inom säker konfiguration. Zenith Controls förklarar också beroendet mellan konfigurationshantering och hantering av sårbarheter:

”Hantering av sårbarheter är beroende av kända konfigurationer. Utan en definierad baslinje är det omöjligt att säkerställa att patchar tillämpas konsekvent.”

Det är denna underlagsberättelse som revisorer och tillsynsmyndigheter i allt högre grad förväntar sig: ett kontrollsystem, inte isolerade tekniska uppgifter.

Kartläggning av ISO/IEC 27001:2022 A.8.9 till stödjande kontroller

ISO/IEC 27001:2022 bilaga A, kontroll A.8.9 Konfigurationshantering, är ankaret, men den ska inte behandlas som ett litet fristående dokument. Den är beroende av en bredare kontrollfamilj.

Denna relation mellan kontroller är skälet till att Clarysec rekommenderar att säker konfiguration hanteras som en ISMS-förmåga med ägare, underlag, mätetal och rapportering till ledningen.

En bredare korsreferens hjälper till att översätta samma baslinjeprogram till andra ramverk.

En praktisk baslinjestruktur som kan införas denna månad

Det vanligaste misstaget är att försöka skriva en perfekt 80-sidig härdningsstandard innan något tillämpas. Börja med en minimal men granskningsbar baslinje för varje större teknikfamilj och utveckla den sedan genom automatisering och granskning.

För en baslinje för molnlagring kan den första versionen omfatta att publik åtkomst är inaktiverad som standard, kryptering i vila är aktiverad, åtkomstloggning är aktiverad, administrationsåtkomst är begränsad till godkända grupper, MFA krävs för privilegierad konsolåtkomst, versionshantering är aktiverad där återställningskrav kräver det, replikering är begränsad till godkända regioner och ändringar görs endast via godkända infrastructure-as-code-pipelines.

För en Windows Server 2022-baslinje som stöder betalningshantering kan den första versionen omfatta att SMBv1 är inaktiverat, icke nödvändiga tjänster är inaktiverade, RDP är begränsat till en härdad hoppvärd, Windows Defender Firewall är aktiverad med standardmässigt nekande, lokala administratörskonton är kontrollerade, händelseloggar vidarebefordras till SIEM, slutpunktsskydd är aktiverat och administrativa ändringar är kopplade till godkända ärenden.

Bygg ett litet underlagspaket för varje baslinje:

1. Det godkända baslinjedokumentet.
2. En skärmbild eller exporterad policy som visar den tillämpade konfigurationen.
3. En lista över tillgångar som omfattas av baslinjen.
4. Ett ändringsärende som visar hur uppdateringar godkänns.
5. En rapport om konfigurationsefterlevnad eller ett manuellt granskningsprotokoll.

Detta ligger direkt i linje med Zenith Blueprint, fasen Controls in Action, steg 19, där Clarysec rekommenderar organisationer att etablera konfigurationschecklistor för större systemtyper, tillämpa inställningar konsekvent vid provisionering genom automatisering där det är möjligt och därefter regelbundet granska driftsatta system. Blueprint ger också en praktisk revisionsmetod:

”Välj några representativa system (t.ex. en server, en switch, en slutanvändar-PC) och validera att deras konfiguration motsvarar er säkra baslinje. Dokumentera avvikelser och åtgärdande.”

För små och medelstora företag är den representativa stickprovsmetoden ofta den snabbaste vägen från informell härdning till revisionsklart underlag.

Härdningsexempel för små och medelstora företag som snabbt minskar risk

Säker konfiguration är inte bara en molnfråga för stora företag. Små och medelstora företag får ofta störst riskreducering från ett fåtal tydliga baslinjeregler.

Nätverkssäkerhetspolicy – SME anger:

”Endast nödvändiga portar (t.ex. HTTPS, VPN) får exponeras mot det publika internet; alla andra ska stängas eller filtreras.”
Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.1.3.

Den kräver också disciplin vid ändringar:

”Alla ändringar av nätverkskonfigurationer (brandväggsregler, switch-ACL:er, routningstabeller) ska följa en dokumenterad ändringshanteringsprocess.”
Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.9.1.

Och den skapar ett granskningsintervall:

”IT-supportleverantören ska genomföra en årlig granskning av brandväggsregler, nätverksarkitektur och trådlösa konfigurationer.”
Från avsnittet ”Styrningskrav”, policyklausul 5.6.1.

Slutpunktsbaslinjer kräver lika stor uppmärksamhet. Clarysecs Policy för slutpunktsskydd och skadlig kod – SME anger:

”Enheter ska inaktivera föråldrade protokoll (t.ex. SMBv1) som kan utnyttjas av skadlig kod.”
Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.2.1.3.

För IoT- och OT-miljöer är osäkra standardinställningar fortsatt en återkommande exponering. Policy för säkerhet i Internet of Things (IoT) / Operational Technology (OT) – SME anger:

”Standardlösenord eller hårdkodade lösenord ska ändras innan enheter aktiveras.”
Från avsnittet ”Styrningskrav”, policyklausul 5.3.2.

Dessa policyklausuler är inte abstrakta uttalanden. De är baslinjekrav som kan testas, styrkas med underlag och följas upp. För ett mindre eller medelstort företag som förbereder sig för kunders leverantörsgranskning, NIS2-leverantörsgranskningar, cyberförsäkring eller ISO/IEC 27001:2022-certifiering skapar de omedelbart värde.

Undantagshantering: kontrollen som skiljer mognad från pappersarbete

Varje baslinje kommer att ha undantag. En äldre applikation kan kräva ett äldre protokoll. En leverantörsappliance kanske inte stöder den föredragna krypteringsinställningen. En tillfällig brandväggsöppning kan behövas för migrering. Frågan är inte om undantag finns. Frågan är om de styrs.

En mogen undantagsregistrering omfattar:

• Baslinjekravet som bryts.
• Den verksamhetsmässiga motiveringen.
• Den berörda tillgången och ägaren.
• Riskbedömningen.
• De kompenserande kontrollerna.
• Godkännandeinstans.
• Utgångsdatum.
• Övervakningskravet.
• Åtgärdsplanen.

Det är här ISO/IEC 27001:2022 riskbehandling och DORA-proportionalitet samverkar. ISO/IEC 27001:2022 kräver att kontrollbeslut motiveras genom riskbedömning, riskbehandling, tillämpbarhetsförklaringen och godkännande från riskägare. DORA tillåter proportionerligt genomförande baserat på storlek, riskprofil och tjänsternas art, omfattning och komplexitet, men förväntar sig fortfarande dokumenterad IKT-riskstyrning, övervakning, kontinuitet, testning och medvetenhet.

Proportionalitet är inte ett tillstånd att hoppa över baslinjer. Det är ett krav på att skala dem intelligent.

För en mikroentitet eller mindre finansiell entitet enligt ett förenklat IKT-riskramverk kan baslinjen vara kortfattad och stödjas av manuella stickprov. För en större finansiell entitet kommer samma område sannolikt att kräva automatiserade konfigurationskontroller, involvering av internrevision, årlig testning och rapportering till ledningsorganet.

Ändringshanteringspolicyn påminner också organisationer om att bevaka:

”Konfigurationsdrift eller manipulation efter godkända ändringar.”
Från avsnittet ”Efterlevnad och tillämpning”, policyklausul 8.1.2.3.

Den formuleringen kopplar ändringsstyrning till detektering av konfigurationsdrift. En ändring kan vara godkänd och ändå skapa risk om det införda tillståndet avviker från det godkända tillståndet, eller om en tillfällig inställning finns kvar efter att ändringsfönstret har stängts.

Bygg ett revisionsspår för många efterlevnadskrav

En säker konfigurationsbaslinje ska inte skapa fem separata efterlevnadsflöden. Clarysecs modell använder ett revisionsspår som kartläggs mot flera krav.

Nyckeln är spårbarhet. Zenith Blueprint, fasen Audit, Review and Improvement, steg 24, instruerar organisationer att uppdatera tillämpbarhetsförklaringen och korsverifiera den mot riskbehandlingsplanen. Om en kontroll är tillämplig behöver du en motivering. Den motiveringen bör kopplas till risk, rättslig skyldighet, avtalskrav eller verksamhetsbehov.

För säker konfiguration bör posten i tillämpbarhetsförklaringen (SoA) för A.8.9 hänvisa till standarden för säkra konfigurationsbaslinjer, omfattade tillgångskategorier, baslinjeägare, ändringshanteringsrutin, övervakningsmetod, undantagsprocess, granskningsintervall och tvärgående efterlevnadskrav såsom NIS2 Article 21, DORA Articles 6, 8 och 9, GDPR Article 32 och kundåtaganden.

Hur revisorer testar säkra konfigurationsbaslinjer

Säker konfiguration är attraktivt för revisorer eftersom området är rikt på underlag. Det kan testas genom dokument, intervjuer, stickprov och teknisk inspektion.

De praktiska frågorna är förutsägbara:

• Använder ni en härdningschecklista när nya servrar installeras?
• Hur förhindrar ni att osäkra tjänster som Telnet körs på routrar?
• Är molnlagringsresurser privata som standard?
• Vem kan godkänna en avvikelse från baslinjen?
• Hur upptäcker ni konfigurationsdrift efter en ändring?
• Kan ni visa en nyligen genomförd konfigurationsgranskning?
• Kan ni visa att en upptäckt avvikelse har korrigerats?
• Säkerhetskopieras och versionshanteras nätverks- och molnkonfigurationer?
• Är återställningsrutiner dokumenterade och testade?

De starkaste organisationerna upprätthåller ett baslinjeunderlagspaket för varje större systemkategori. Det förkortar revisioner, förbättrar svaren vid kunders leverantörsgranskning och hjälper ledningen att förstå faktisk kontrollprestanda.

Gör konfigurationsdrift till ett cyberhygienmått för styrelsen

Styrelser behöver inte varje brandväggsregel. De behöver veta om cyberhygienen förbättras eller försämras.

En användbar panel för säker konfiguration omfattar:

• Andel tillgångar som är kartlagda mot en godkänd baslinje.
• Andel tillgångar som klarar baslinjekontroller.
• Antal kritiska baslinjeavvikelser.
• Genomsnittlig ålder för öppna avvikelser.
• Antal utgångna undantag.
• Antal upptäckta obehöriga konfigurationsändringar.
• Andel privilegierade konfigurationsändringar med godkända ärenden.
• Undantag för publik molnexponering.
• Baslinjernas granskningsstatus per teknikfamilj.

Dessa mätetal stöder ISO/IEC 27001:2022 utvärdering av prestanda, NIS2-ledningens tillsyn och DORA-rapportering av IKT-risk. De kan också naturligt mappas till styrningsutfall i NIST CSF 2.0 och COBIT 2019:s mål för övervakning och efterlevnad.

En enkel regel på ledningsnivå hjälper: inget kritiskt system tas i produktion utan baslinjeunderlag. Detta kan genomdrivas genom ändringshantering, CI/CD-grindar, kontroller av molnpolicy, granskning av infrastructure-as-code, MDM-efterlevnad, GPO-tillämpning eller granskning av nätverkskonfiguration. Mognadsnivån kan variera, men kontrollogiken ska inte göra det.

90-dagars handlingsplan för säkra konfigurationsbaslinjer

Om ni börjar från noll ska ni inte försöka lösa varje konfigurationsfråga på en gång. Använd en 90-dagarsplan.

Dag 1 till 30: definiera minsta baslinje

Identifiera kritiska tillgångskategorier. För varje kategori ska ni tilldela en teknisk ägare, riskägare och godkännandeinstans. Skapa en första baslinje för de inställningar som är mest relevanta för resiliens mot ransomware, molnexponering, privilegierad åtkomst, loggning, kryptering och dataskydd.

Skapa baslinjeregistret och mappa det till ISMS-omfattningen, riskregistret och tillämpbarhetsförklaringen. Om ni omfattas av NIS2 ska ni identifiera om ni är en väsentlig eller viktig entitet, eller om kunder förväntar sig NIS2-anpassad cyberhygien. Om ni är en finansiell entitet enligt DORA ska ni identifiera vilka IKT-tillgångar som stöder kritiska eller viktiga funktioner. Om ni behandlar personuppgifter ska ni mappa system till GDPR-behandlingsaktiviteter och datakategorier.

Dag 31 till 60: tillämpa och samla in underlag

Tillämpa baslinjen på ett urval av högrisksystem. Använd automatisering där det är möjligt, men vänta inte på perfekta verktyg. Exportera konfigurationer, ta skärmbilder, spara policyinställningar och registrera ändringsärenden.

Skapa en riskpost med utgångsdatum för varje undantag. Skapa ett åtgärdsärende för varje avvikelse.

Dag 61 till 90: övervaka, rapportera och förbättra

Genomför en konfigurationsgranskning. Ta stickprov på en server, en slutpunkt, en nätverksenhet och en molnmiljö. Jämför faktiska inställningar med den godkända baslinjen. Dokumentera avvikelser och korrigerande åtgärder.

Rapportera baslinjeefterlevnad till ledningen. Uppdatera tillämpbarhetsförklaringen och riskbehandlingsplanen. För in återkommande avvikelser i rotorsaksanalys. Om en felkonfiguration orsakade eller bidrog till en incident ska den relevanta baslinjen uppdateras som en del av erfarenhetsåterföringen.

Detta ger revisorer något testbart, tillsynsmyndigheter något begripligt och ledningen något styrbart.

Slutlig tanke: säker konfiguration är cyberhygien med bevis

NIS2 använder språket kring åtgärder för hantering av cybersäkerhetsrisker och grundläggande cyberhygien. DORA använder språket kring IKT-risk, resiliens, övervakning, kontinuitet och testning. GDPR använder språket kring lämpliga åtgärder och ansvarsskyldighet. ISO/IEC 27001:2022 använder språket kring riskbehandling, kontroller, dokumenterad information, utvärdering av prestanda och ständig förbättring.

Säkra konfigurationsbaslinjer kopplar samman dem alla.

De visar att system inte driftsätts med osäkra standardinställningar. De visar att ändringar är kontrollerade. De visar att konfigurationsdrift upptäcks. De visar att undantag riskaccepteras. De visar att underlag finns innan revisorn frågar.

Viktigast är att de minskar verklig operativ risk. Fredagseftermiddagens brandväggsregel, den publika molnbucketen, den bortglömda SMBv1-inställningen, standardlösenordet i IoT-enheten och den ologgade administrationskonsolen är inte teoretiska revisionsiakttagelser. De är praktiska felpunkter.

Clarysec hjälper organisationer att omvandla dessa felpunkter till kontrollerade, övervakade och granskningsbara baslinjer.

Nästa steg

Om organisationen behöver visa säker konfiguration för ISO/IEC 27001:2022, NIS2-cyberhygien, DORA IKT-riskhantering, GDPR-ansvarsskyldighet eller kundförsäkran, börja med Clarysecs verktygslåda:

• Använd Zenith Blueprint: en revisors 30-stegs färdplan för att införa konfigurationshantering i fasen Controls in Action, steg 19, och validera den genom fasen Audit, Review and Improvement, steg 24.
• Använd Zenith Controls: guiden för korsvis efterlevnad för att mappa konfigurationshantering till stödjande kontroller i ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST SP 800-53, COBIT 2019 och revisionsmetoder.
• Använd Clarysec-policyer såsom Informationssäkerhetspolicy, Policy för användning av molntjänster, Policy för revision och efterlevnadsövervakning, Policy för sårbarhets- och patchhantering, Nätverkssäkerhetspolicy – SME, Policy för slutpunktsskydd och skadlig kod – SME och Policy för säkerhet i Internet of Things (IoT) / Operational Technology (OT) – SME för att definiera, tillämpa och styrka era baslinjekrav med underlag.

En säker baslinje är inte bara en checklista för härdning. Den är beviset på att organisationen vet hur ett säkert läge ser ut, tillämpar det konsekvent och kan visa det när det är avgörande.