Hvorfor Cisco Secure Firewall version 7.2.4 er vigtig og sætter en ny standard
Hvordan adskiller Cisco Secure Firewall version 7.2.4 sig fra de tidligere udgivelser?
For et par uger siden fik jeg æren af at blive inviteret af Cisco til Fulton, Maryland i USA (faktisk i selv samme bygning, hvor Sourcefire holdt til, før de blev opkøbt af Cisco) for at høre nærmere omkring udviklingen af Cisco Secure Firewall version 7.2.4, samt fremtiden.
Det var en super fed oplevelse, og Cisco havde virkelig formået at samle et drømmehold bag både Cisco Secure Firewall-udviklingsholdet/Engineering samt fra Cisco TAC. Selvom der var nogle skarpe spørgsmål, så kunne de give gode tekniske forklaringer, men samtidig var det tydeligt, at Ciscos udviklingshold lyttede til den feedback, de fik igennem panelet samt ønsker til at forbedre gamle og nye funktioner i produktet.
Det er vist ikke nogen hemmelighed, at der tidligere har været udfordringer med FMC og FTD-software, der desværre til tider har gjort os alle frustreret fra tid til anden.
Dog var det tydeligt på denne tur, at Cisco erkender disse udfordringer, men også var meget indstillet på, at fremtiden skal være anderledes. Der er ingen i Ciscos bagland der har syntes det har været sjovt, hverken at skulle fikse fejl i koden, samtidig med et større antal TAC sager hele tiden har banket på døren.
Cisco valgte derfor at trække en streg i sandet, for at fokusere på at få stabiliseret platformen – hvilket også var den primære årsagen til turen.
Da vi begyndte at høre om mængden af penge, tid og ikke mindst ressourcer, man har puttet ind i denne udgivelse, var det ret tydeligt, at Cisco kender de problemer, der har været, og man ønsker at gøre en ende på dette – en slags ”frisk-start” eller som jeg selv har omtalt det blandt kollegaerne: ”Make Cisco Secure Firewall Great Again”.
Der er gjort rigtig meget for at bygge et godt nyt fundament. Nedenstående er kun et lille udpluk blandt de mange ting og investeringer, som Cisco har gjort:
- Rettet over 1000 bugs – både kendte, men også opdagelser under tests (~3x så mange som et normalt maintenance-udgivelse)
- Testet 2.5x flere opgraderingsmuligheder – totalt set 230 opgraderingstrin
- 300% mere testtid brugt i forhold til tidligere MR-udgivelser (16640 timer)
- 10x så mange test enheder brugt til validering – en investering på over $6 millioner
– 500 fysiske + 2000 virtuelle enheder – det svare til over 100 racks af udstyr! - Højnet mængden af tests baseret på kunders konfigurationer og kørt intensive tests på disse – både rigtig store opsætninger og mindre
- Simulering af rigtig trafik under test og presset platformen op til 90% ydelse – mix af forskellige protokoller og VPN
- Database stress-testing (3x så meget som tidligere), udvidet mulighederne for ”self-fix” ved DB-korruption og hærdning heraf – desværre et meget velkendt problem
- Overvågning af ressourcer før og efter en opgradering (CPU, hukommelse, logrotation mv.) – hvem har ikke fejlsøgt fulde diske eller log rotationsfejl? Vigtigt punkt!
- Både SNORT2 og SNORT3 er intensivt testet på kryds og tværs
- 24 Petabyte trafikmængde er brugt i test
Samtidig med disse store ændringer og investeringer, har man forbedret rapporteringsmåden, hvorpå disse test systemer sender alarmer og beskeder til udviklerne.
Dette sker igennem en udvidet proaktiv overvågning kombineret med bedre helbredschecks, blandt andet på SNORT-crashes/restarts, databasekorruption mv.
Helbredelseschecks er blevet udvidet og har nu en større indsigt i eventuelle fejl, som er observeret i testscenarier og derved en større mulighed for, at vores installationer kan ”reparere-sig-selv”.
Ifølge Cisco har man i 7.2.4 håndteret over 85% af alle åbne TAC-sager, der blev klassificeret som defekter, og 80% af disse er samtidig blevet løst.
Dertil er det vigtigt at påpege, at mange af de resterende defekter ofte er nogle mere avancerede problemstillinger, som kræver mere tid at løse og teste samt større systemmæssige ændringer. I stedet har man valgt at fokusere på at fikse så mange defekter som muligt, og ikke at lave store ændringer som kræver mere testtid og potentielt kan give flere fejl, hvis ikke det bliver testet nok. Dertil skal det selvfølgelig nævnes, at det ikke er fordi man ikke vil løse disse fejl, men det er vigtigt, at vi få et godt fundament og stabil platform først.
Dertil har Cisco ændret deres udgivelses fokus, hvilket betyder, at man gerne vil reducere MTTR (mean-time-to-release). Bugs bliver ofte hurtigt fundet samt tilknyttet en fremtidig løst version, dog kan denne version tage lang tid om at blive udgivet – til stor frustration for os og kunderne.
Dette ønsker Cisco nu at gøre op med og i stedet sørger for, at disse udgivelser kan komme relativt hurtigt ud til platformene.
Senest er der blandt andet d. 27. juli 2023 blevet udgivet en hotfix-patch (7.2.4.1) som retter også en fin mængde bugs, hvoraf nogle af dem var ret kritiske for funktionaliteten – men Cisco har reageret kvikt og udgivet denne patch hurtigt, som tidligere nævnt også er målet. (Sørg endelig for at få smidt denne hotfix på jeres installationer hurtigst muligt, vi taler af erfaringer).
Alle disser rettelser og ændringer bliver også indenfor den næste tid bagud-rettelser til de andre aktive softwareudgivelser.
Personligt ville jeg anbefale alle brugere af softwaren at få opgraderet jeres infrastruktur til denne 7.2.4 udgivelse hurtigst muligt. Ikke nok med, at det er en anbefalet udgivelse af Cisco, så står det klart for mig, at man virkelig har ydet en stor indsats her for at skabe en højere kvalitet og standard fremadrettet.
Hvis i allerede kører 6.6.x, kan i gå direkte op på 7.2.4
(Husk at dobbeltchecke matrix-kompatibilitet baseret på jeres FMC/FTD-hardware. Ræk endelig ud til mig eller mine kolleger, hvis I vil have hjælp).
Afslutningsvis så tænker jeg, vi kan slutte af med et obligatorisk rejsefoto – ”SNORTie” og jeg… 😉