Onderhoud software zolang die in gebruik is

Maak iemand verantwoordelijk voor onderhoud

Bruikbare software blijft na de eerste release veranderen. Dependencies krijgen oplossingen. De ondersteuning voor runtimes stopt. Certificaten verlopen. Bedrijfsregels veranderen. Toegang die tijdens de inrichting is verleend, kan langer blijven bestaan dan bedoeld.

Houd een inventaris bij van services, verantwoordelijken, gedeployde versies, dependencies en ondersteuningsdatums. Neem gepland werk op en werk dat door een nieuwe bevinding ontstaat. Reserveer capaciteit voor beide. Een onderhoudsbacklog zonder verantwoordelijke beschermt de service niet.

Scheid onderhoud van directe incidentrespons. Uitgelekte toegangsgegevens of bewijs van een actieve inbraak kunnen indamming vereisen voordat een gewone ontwikkelcyclus klaar is. Verwijs zulke gevallen naar het beveiligingsresponsproces.

Beoordeel de werkelijke blootstelling

Ernst beschrijft mogelijke gevolgen. De prioriteit hangt ook af van misbruik, bereikbaarheid, gegevens, bestaande controles en de kosten van uitstel. Ook een interne service met weinig verkeer kan belangrijke toegangsgegevens bevatten.

De Known Exploited Vulnerabilities-catalogus van CISA bevat kwetsbaarheden waarvoor bewijs van misbruik bestaat. Gebruik dit bij het bepalen van prioriteiten. Afwezigheid uit die catalogus bewijst niet dat een kwetsbaarheid ongevaarlijk is. CISA-catalogus.

Bekijk deze fictieve bevindingen. De termijnen horen bij de voorbeeldorganisatie; het zijn geen universele deadlines.

Maak niet van elke bevinding automatisch een grote upgrade. Kies een ondersteunde correctie, controleer de compatibiliteit en test het belangrijke gedrag. Leg tijdelijke maatregelen vast met een verantwoordelijke en een vervalvoorwaarde.

Volg de correctie tot in productie

Gebruik een traceerbare reeks: bevinding, beslissing, wijziging, review, deployment en verificatie. Leg de identificatie vast van het artefact dat productie daadwerkelijk gebruikt. Scan het relevante artefact of de omgeving opnieuw na de wijziging.

Bij een fictief kwetsbaar PDF-pakket merget een team om 10:00 een upgrade. Om 11:00 draait productie nog de image van gisteren. De correctie in de repository is klaar. Het herstel in productie is nog niet afgerond.

Controleer na de deployment zowel de pakketversie als het genereren van PDF’s. Een kwetsbaarheidsscan toont niet aan dat de export nog werkt. Een functionele test toont niet aan dat de kwetsbare component is verwijderd.

Het SSDF van NIST omvat doorlopende identificatie van en respons op kwetsbaarheden. Pas deze werkwijzen gedurende de hele levenscyclus toe, ook op software waarvoor weinig nieuwe functies worden gevraagd. NIST SSDF.

Automatiseer met zichtbare grenzen

Taiga Maintaining scant gekoppelde repositories en kan bevindingen omzetten in initiatieven voor herstel. Controleer de laatste geslaagde scanronde, de getroffen versie en de resulterende wijziging. Een repositoryscan toont geen bereikbaarheid in productie aan. Maintaining.

Automatisering kan herhaald werk verminderen, maar de service heeft nog steeds iemand nodig die verantwoordelijk is voor deployment en verificatie. Houd releasebeslissingen, noodtoegang en het verlopen van uitzonderingen expliciet.

Onderhoud omvat ook uitfasering. Verwijder ongebruikte routes, toegangsgegevens, integraties en infrastructuur via een gecontroleerd proces. Controleer bewaareisen en afhankelijke services vóór verwijdering. Neem de draaiende service buiten gebruik en wijs resterende bewaar- of audittaken toe.

De volgende les behandelt doorlopende kwetsbaarheidsscans en herstel in detail.