Opdateringer og vejen til helvede

Lige nu er den perfekte storm af opdateringer. Ud over den tilsyneladende uendelige strøm af operativsystemopdateringer (OS) er der opdateringer til applikationer og nu opdateringer til din hardware. Vi er alle blevet vant til den månedlige frigivelse af programrettelser til Microsoft Windows, til det punkt, hvor vi forventer Patch tirsdag hver måned. Men nu er der mere.

Sikkerhedsforskere afslørede problemer med Intels Management Engine, der lever i sit eget lille OS inde i Intel-processorer. Derefter fandt forskere alvorlige problemer med den måde processorer planlægger programudførelse, hvilket førte til sårbarheder mærket Specter og Meltdown. Meltdown påvirker sikkerhedsgrænser i processorcache, mens Specter er involveret i spekulativ eksekvering og påvirker alle processorer, ikke kun dem fra Intel. (For en komplet beskrivelse, skal du læse Tom Brant's Sådan beskyttes dine enheder mod Meltdown, kolonnen Specter Bugs.)

Så ud over de sædvanlige opdateringer til Windows og Linux og de mindre hyppige opdateringer til MacOS, ser vi nu opdateringer til de processorer, der understøtter dem. I efteråret 2017 leverede Intel opdateringer til Management Engine til pc-producenter, som derefter udstedte firmwarepatcher. Derefter kom patches til firmware og processormikrokode for at fikse Meltdown på Intel-processorer og til en vis grad Specter på næsten enhver processor.

Specter- og Meltdown-programrettelserne vises også i OS-software, så der blev udstedt en vigtig Windows Update den 3. januar ud af den normale Patch Tuesday-sekvens. Og selvfølgelig var der stadig den almindelige patch tirsdag.

At opdatere eller ikke opdatere

Pludselig flyver der en masse opdateringer. Anvender du dem lige så hurtigt, som de dukker op? Svaret er: sandsynligvis ikke. Intel adresserer allerede problemer med nogle ældre processorer, der begyndte at genstarte, når patches blev anvendt. Nu er der rapporter om, at nogle industrielle kontrolsystemer ikke fungerer som et resultat af programrettelserne.

Det er klart, du skal tænke to gange om blot at anvende programrettelser, som de dukker op. Men du skal også bekymre dig om konsekvenserne, hvis du ikke gør det. Hvordan skal man beslutte?

Konsekvenserne af at vælge ikke at udføre en opdatering er kendt. Til sidst åbner en ikke-udsendt sårbarhed dine systemer for en af ​​mange udnyttelser, og det vil medføre datatab og alle de dårlige ting, der følger. Men der er konsekvenser, der også opstår ved at vælge at lappe. Ud over de problemer, der er relateret til Intels rettelser, er der tidspunkter, hvor opdateringer til dine operativsystemer kan forårsage problemer. Du skal overveje dem.

For eksempel er det muligt, at lokalt skrevne eller nogle brugerdefinerede apps muligvis ikke fungerer korrekt, når du har anvendt en patch til Windows. Dette er meget sjældent i disse dage, men muligheden findes. Hvis du har en sådan app, skal du teste opdateringen, før du anvender den til alle dine systemer.

Problemer er mere sandsynligt, når opdateringen er en stor opdatering, som når mange computersystemer blev opdateret fra Windows 7 til Windows 10. Derefter er det trods det faktum, at kommerciel software skal håndtere overgangen, stadig at teste ved at foretage ændringen på et par computere, før de går hele vejen.

Under normale omstændigheder, når du beskæftiger dig med kontormaskiner, der kører office-apps, er der lille grund til ikke at lade opdateringen ske, så snart arbejdsbyrden for den person, der bruger den, tillader det. Der er lidt risiko ved opdateringen, og risikoen for, at brugere gør noget, de ikke burde, er ret høje.

Særlige overvejelser med servere

Computere, der bruges som servere, er et andet problem. Der er risikoen fra brugere noget lavere, men de risici, der kan komme fra en opdatering med problemer, er højere. Derudover er der omkostningerne ved nedetid, hvis serveren er vigtig for din virksomhed. I et sådant tilfælde skal processen med at anvende opdateringen overvejes nøje.

Den bedste måde at opdatere servere er måske en ad gangen, der starter med en ekstra. Du opdaterer en ekstra server og test det. Når du er sikker på, at den kører som den skal, skal du skifte en server ud med den opdaterede. Hold på det gamle i et stykke tid, hvis opdateringen ikke spiller godt sammen med resten af ​​netværket og derefter opdateres. Afhængig af hvor mange servere du har, kan du muligvis gøre dette én ad gangen, eller du kan automatisere det ved hjælp af din programrettelseshåndteringssoftware.

Det centrale er, at du ikke blot udsætter dig for at gøre dine opdateringer for evigt. Mange af de dataovertrædelser, der lykkedes i 2017 og tidligere, var mulige, fordi hackerne brugte udnyttelser, der var afhængige af uudgivne sårbarheder, der har haft opdateringer og programrettelser tilgængelige i måneder eller år, men som aldrig blev anvendt. Den klare tilgængelighed af udnyttelser udviklet af efterretningsfællesskabet - og siden lækket - gør risikoen for ikke at lappe endnu større.

Hvis du deler op beslutningsprocessen, bliver det lettere. Først skal du straks lappe de systemer, hvor risikoen for at lappe er lav, og risikoen for ikke at lappe er størst, hvilket inkluderer dine kontormaskiner og alle offentligt modstående computere. Anvend derefter programrettelser og opdateringer til systemer, hvor du har råd til en kort periode med nedetid, f.eks. Servere, der kan gå offline natten over.

Endelig skal du overveje patch-and-erstatte tilgang til resten af ​​dine systemer, hvor du har mere tid til at teste og nedetid minimeres. Giv igen systemer, du udveksler tid til at sikre, at de spiller godt på netværket.

Men uanset hvad du gør, skal du ikke anvende kritiske programrettelser. Planlæg dem til at arbejde med dine krav, men lad dem ikke blot udsættes. Du ønsker ikke at være det næste firma, der rammer forsiderne på grund af et angreb.