Kort sagt: Sårbarhedshåndtering i mellemstore virksomheder og SMV er et slankt, tilbagevendende kredsløb: kende sine systemer, følge meldinger målrettet, vurdere efter risiko, beslutte, gennemføre og dokumentere. Det afgørende er ikke dyre værktøjer, men klare ansvarsområder og en prioritering, der tager højde for tilgængelighed, data og angrebssituation. PHP2Shell er et godt øvelseseksempel, fordi alle trin indgår i det.
Hundredvis af meldinger, få medarbejdere
Hver uge offentliggøres nye sikkerhedshuller i styresystemer, programmeringssprog, applikationer og plugins. En koncern har et team til det. En mellemstor virksomhed har ofte én it-chef, en eller to administratorer og flere eksterne leverandører. Ingen kan læse hver eneste melding, og det behøver heller ingen.
Det, der skal til, er et filter: Hvilke meldinger berører vores systemer, hvilke af dem haster, og hvem tager sig af dem? Mangler dette filter, sker der en af to ting. Enten ignoreres alt, indtil der sker noget, eller også udløser hver melding uro, og den virkelig kritiske drukner i støjen.
Sårbarhedshåndteringens kredsløb
Et bæredygtigt forløb for SMV kan beskrives i seks trin:
- Registrere, hvad der kører. Uden en oversigt intet sammenligningsgrundlag. Hvilke websites, servere, PHP-versioner og applikationer driver I, og hvor? Hvordan det lykkes, viser Vid, hvad der kører: oversigt over alle websites og servere.
- Følge meldinger. Abonnér på få, pålidelige kilder: advarsler fra BSI (det tyske forbundsagentur for informationssikkerhed), meldinger fra producenterne af jeres software, sikkerhedssiderne for jeres Linux-distribution og for PHP forsiden på php.net.
- Vurdere. Berører meldingen os? Hvis ja, hvor meget haster den? Mere om det nedenfor.
- Beslutte. Udbedre, midlertidigt sikre, isolere systemet eller bevidst bære risikoen. Hvem må beslutte hvad?
- Gennemføre. Indspille en opdatering, sætte en midlertidig foranstaltning, bestille en leverandør.
- Dokumentere og følge op. Er sårbarheden virkelig lukket? Hvornår afløses en midlertidig løsning?
Kredsløbet begynder derefter forfra. Nye systemer kommer til, gamle falder væk, og nye meldinger dukker op.
Ved trin 2 hjælper en enkel regel: hellere læse få kilder regelmæssigt end mange en gang imellem. Til et typisk mellemstort webmiljø er CERT-Bunds advarsler hos BSI (den tyske regerings CERT) som regel nok, sammen med sikkerhedsmeddelelserne fra den anvendte Linux-distribution, siderne hos CMS- og shopproducenterne og forsiden på php.net. Fastlæg, hvem der læser disse kilder, og opret en fælles postkasse eller en kanal, som ikke hænger på en enkelt person.
Som supplement er et blik udefra umagen værd. En regelmæssig sårbarhedsscanning af de offentligt tilgængelige systemer viser, om forældet software eller unødvendigt åbne tjenester er synlige. Den erstatter hverken oversigt eller opdateringer, men afslører systemer, som ikke står på nogen liste.
Vurdere: Hvad der kommer først
CVSS-værdien, en standardiseret vurdering af alvorsgraden, er et godt udgangspunkt. Til rækkefølgen i jeres eget hus rækker den dog ikke. Tre yderligere spørgsmål er afgørende:
| Spørgsmål | Øger hastegraden | Mindsker hastegraden |
|---|---|---|
| Kan systemet nås fra internettet? | offentligt website, shop, portal | kun internt, bag VPN |
| Kræves der login for at udnytte sårbarheden? | nej, uden godkendelse | ja, kun for administratorer |
| Hvilke data behandler systemet? | kundedata, betalinger, adgange | offentligt indhold uden konti |
| Er der rapporter om angreb? | angrebsforsøg meldt | ingen kendte forsøg |
| Findes der en midlertidig foranstaltning? | nej | ja, med dokumenteret virkning |
PHP2Shell viser, hvordan det hænger sammen. Begge sårbarheder har en CVSS-v4.0-værdi på 9,2, tillader kodeudførelse uden login og berører offentligt tilgængelige webservere. Cloudflare og Patchstack rapporterede ifølge medierne om angrebsforsøg, og BSI vurderede situationen som advarselsniveau 3. De midlertidige foranstaltninger fra php.net giver udtrykkeligt ingen fuldstændig beskyttelse. Alle spørgsmål peger i samme retning: handl straks. Hvad BSI konkret anbefalede, står under Hvad BSI anbefaler om PHP2Shell.
Beslutte og dokumentere
Ikke enhver sårbarhed kan lukkes med det samme. Et ældre system kører på PHP 8.1, som der ikke længere findes officielle opdateringer til (se PHP 8.1 og ældre: Hvad der nu gælder), og en fagapplikation kan endnu ikke klare opdateringen. Så kræves der en beslutning, og den hører ikke udelukkende hjemme i it-afdelingen.
En god beslutningsnotits indeholder det berørte system, sårbarheden, vurderingen, den valgte mulighed, midlertidige foranstaltninger, den ansvarlige person og en dato for fornyet kontrol. Bæres en risiko bevidst, afgør ledelsen det og ikke administratoren alene. OWASP's Cheat Sheet om håndtering af sårbare afhængigheder anbefaler ligeledes, at risikoaccept udtrykkeligt forankres på ledelsesniveau.
Før én enkelt liste over åbne sårbarheder med status, ansvarlig og frist. En tabel er nok. Det vigtige er, at den gennemgås regelmæssigt, f.eks. på det månedlige møde med direktionen.
Hvad NIS2 og leverandører har med det at gøre
For virksomheder, der er omfattet af NIS2, er håndteringen af sårbarheder en del af pligterne til risikostyring. Enkeltheder beskrives i NIS2 og webserversikkerhed. Men også uden lovkrav er et dokumenteret forløb en fordel, f.eks. over for kunder, forsikringsselskaber og egen ledelse.
Mange trin kan lægges ud, f.eks. at følge meldinger eller indspille opdateringer. Beslutningen om risici og det samlede overblik bør dog blive i huset. Den, der afgiver hele kredsløbet til en leverandør, ved i en nødsituation ikke længere, hvilke systemer vedkommende overhovedet har. Hvordan gennemførelsen organiseres som rutine, beskriver Patch management som proces i stedet for brandslukning.
Hvordan hjælper PHP SOS konkret?
- Vi udarbejder sammen med jer oversigten over jeres websites og servere som grundlag for ethvert afstemningsarbejde.
- Vi følger de relevante meldinger for jeres systemer og leverer en vurdering i klart sprog med en anbefaling.
- Vi forbereder beslutningsnotitser til de tilfælde, hvor en opdatering ikke er mulig med det samme.
- Via sikkerhedsovervågning kontrollerer vi løbende, om systemer bliver påfaldende, mens en sårbarhed endnu er åben.
Konklusion: Sårbarhedshåndtering i mellemstore virksomheder behøver ikke være stor, men den skal være forpligtende. Den, der kender sine systemer, læser få gode kilder og får beslutninger skrevet ned, reagerer hurtigt og rigtigt på den næste kritiske melding.
Ofte stillede spørgsmål
Hvad er sårbarhedshåndtering?
Et tilbagevendende forløb, hvor en virksomhed får kendskab til sikkerhedshuller i sine systemer, vurderer dem, udbedrer dem eller bevidst accepterer dem og dokumenterer resultatet. Det handler ikke om et værktøj, men om ansvar og beslutninger.
Er CVSS-værdien nok til at prioritere?
Den er et godt udgangspunkt, men ikke nok. Det afgørende er desuden, om det berørte system kan nås fra internettet, hvilke data det behandler, og om der allerede er observeret angreb. En sårbarhed med høj værdi på et internt testsystem kan vente, en på shoppen kan ikke.
Har en lille virksomhed brug for et eget værktøj til det?
Ikke i begyndelsen. En vedligeholdt liste over systemerne, abonnerede sikkerhedsmeddelelser og en tabel med åbne punkter er nok. Sårbarhedsscannere kan betale sig, når antallet af systemer vokser, eller når kontroller regelmæssigt skal dokumenteres.
Må man bevidst lade være med at udbedre en sårbarhed?
Ja, hvis risikoen er vurderet, beslutningen er truffet af den ansvarlige ledelse og er skrevet ned, helst med midlertidige foranstaltninger og en dato for fornyet kontrol.