Esiintyessäni Cisco Studio 2021 tapahtumassa totesin palomuurin olevan lähitulevaisuudessa historiaa. Monessa yrityksessä tähän skenaarioon on matkaa, mutta roadmap työskentelyssä keskustelu on vahvasti läsnä. Pilvinatiiviin SaaS toimintaympäristöön perinteinen palomuuriajattelu soveltuu huonosti, mutta uusiakin haasteita löytyy kuten HTTP3-prokolla.

Akilleen kantapää on vakoilu- ja kiristyshaittaohjelmistojen tunnistaminen salatusta liikenteestä

Cisco Systems tutkimusten mukaan 70 % haittaohjelmista käytti salausta torjunnan ohittamiseen vuonna 2018. Vuonna 2021 90 % haittaohjelmista hyödynsi salausta toiminnan piilottamiseen.  Internet (HTTPS) lisäksi Microsoft LDAP, MS-RPC ja SMBv3 ja monet muut yritysverkon protokollat kulkevat verkossa salattuna. Havainnointi ja torjunta ei ole helppoa.

Markkinoilla on torjuntateknologiaa, jonka kerrotaan toimivan myös salatulle liikenteelle. Keskustellessani salatun liikenteen analysointiin erikoistuneen yrityksen kanssa, he kuitenkin myöntävät ”parempaan tulokseen” päästävän salaus purkamalla. Lisää haasteita on tulossa, mutta avaan torjunnan historiaa.

Stateful Firewall ja AntiVirus Gateway (90-luku)

Stateful Firewall-teknologian (TCP istunnon tilatieto) vallatessa 90-luvulla palomuurimarkkinat oli reaaliaikainen haittaohjelmatorjunta tuntematon käsite. Internet-verkon leviämisen myötä haittaohjelmistojen leviäminen kasvoi merkittäväksi ongelmaksi. Työasemien jatkuva siivoaminen virustorjunnan pettäessä oli kallista ja hidasta. Ongelmaa yritettiin lieventää ohjaamalla Internet/Web-liikenne palomuurista erillisille palvelimille ”pestäväksi” ICAP-protokollalla ja segmentoimalla verkkoa.

Eräs innovaatioista oli Willie Ositis kehittämä Transparent Proxy AV silta, jonka toimme Suomen markkinaan 2000-luvun alussa. Internet-liikenne ajettiin laitteen läpi ja haittaohjelmat poistettiin. Ratkaisu on nopea ja helppo toteuttaa.  Salattua liikennettä emme pystyneet ”pesemään”, mutta sitä oli vähän.

Ositis myytiin vuonna 2003 proxy-teknologian valmistajalle (BlueCoat). Tästä syntyi BlueCoat Proxy ja Proxy AV yhdistelmä, joka ainakin teoriassa mahdollisti SSL-salauksen purkamisen ja haittaohjelmien paremman tunnistamisen. Ratkaisun merkittävänä haasteena oli hinta. Harvalla yrityksellä oli varaa toteuttaa statefull palomuuri klusteri (2 laitetta) + BlueCoat Proxy klusteri (2 laitetta) + Proxy AV klusteri (2 laitetta) + 4 Ethernet LAN-kytkintä + 10 laitteen kokonaisuuden vaatima konfigurointi ja ylläpito varalaitteineen.  Siihen päälle sähköpostiliikenteen virus- ja roskapostitorjunnan klusteri (2 laitetta). Räkillinen palvelimia ja ohjelmistoja oli järjestelmämyyntiä hienoimmillaan, mutta aivan liian kallis 95 % Suomalaisista yrityksistä.

Next-Generation Firewall (2000-luvun alku)

Ratkaisu löytyi vuonna 2000 perustetun Fortinet™ Fortigate™ palomuurista, joka yhdisti palomuurin, virus- ja hyökkäystorjunnan sekä Web URL kategoriasuodatuksen yhteen fyysiseen laitteeseen. Vuosia perässä tulivat Palo Alto Networks™ (perustettu 2005) ja perinteiset palomuuriteknologiayhtiöt.

Next Generation Firewall (NGFW) termin lanseerasi Gartner ™ vuonna 2003/2004, joskin sen määritelmää on tarkennettu myöhemmin useaan kertaan. Vuonna 2016 Gartner™ totesi NGFW termin joutavan eläkkeelle.

Next-Generation Firewall ja SSL-inspection (2010 luku)

Palomuurilaitteisto mahdollistaa SSL-salauksen purkamisen.  Mahdollisuudet tietoturvariskien havainnointiin paranevat huomattavasti. Valitettavasti ratkaisu on harvassa yrityksessä käytössä. Näen kuusi syytä vallitsevaan tilanteeseen:

  1. SSL-inspection konfigurointi edellyttää asiantuntijalta enemmän ponnisteluita ja yhteistyötä kuin oletusasetukseen jääminen. Mennään siitä, missä aita on matalin. Lisenssit on laskutettu vuosittain, mutta hyöty asiakkaalle on sulanut kahdessa vuosikymmenessä ilman salauksen purkamista.
  2. SSL-inspection vaatii paljon laskentatehoa, joka edellyttää suurempaa laiteinvestointia. Sen lisäksi tarvitaan laskentakapasiteettia uhkien tunnistamiseen. Jos 10 % sijasta tutkitaan 90 % liikenteestä, jää vanha palomuuriklusteri auttamatta liian pieneksi.
  3. Internet SD-WAN (NGFW) ratkaisussa myyjä haluaa toteuttaa SSL-Inspection jokaiseen toimipisteeseen erikseen. Sen toteuttaminen asiantuntijalta vaatisi 10 x määrän ponnisteluita verrattuna keskitettyyn ratkaisuun. Suurin osa hajautetusta kapasiteetista on tyhjän panttina nykyisessä etätyökulttuurissa. Myyjälle hieno kokonaisuus, asiakkaalle ei.
  4. Salausteknologian kehittyessä on salauksen purkaminen ja yhteensopivuuden hallinta työaseman selaimen kanssa yhä haastavampaa. Ajatellaan, että jos ei tehdä kaikelle liikeneelle, niin ei kannata tehdä lainkaan.
  5. SSL-Inspection ja sisällön tarkistaminen aiheuttaa siirtoviiveen kasvun. Soveluksen käyttäjäkokemus heikkenee.
  6. Tietoturvayhteisön näkemyserot salatun liikenteen purkamisesta (man-in-the-middle) sekä pitkälle kehitetyt hyökkäysmenetelmät, jotka ohittavat 1., 2. ja 3. polven torjunnan salauksen purkamisesta huolimatta.

2022 Sovelluksen nopeus vs. tietoturva?

Sovellusten heikko vasteaika yritysverkossa on useimman 5FN verkkoanalysoinnin toimeksiannon peruste. Lähes aina sovelluksen siirtoviiveen suuruusluokka yllättää sen noustessa 500–800 ms tasolle. (valokuitu/Ethernet tai mobiiliverkon osuus e2e viiveestä on murto-osa kokonaisuudesta).

Suurin haaste on 70-luvulla kehitetty TCP-protokolla, joka on suunniteltu luotettavan tiedonsiirron menetelmäksi epäluotettavassa dataverkossa. Kun tähän lisätään kaukana lähiverkosta sijaitsevat pilvipalvelut, palomuurien ja kuormantasaajien TCP ja TLS session kättelyyn kuluva aika, nousee vasteaika kohtuuttoman korkeaksi. SSL-inspection toiminnon lisääminen palomuuriin lisää viivettä ja heikentää käyttäjäkokemusta.

HTTP/3 – Uusi ja nopea salattu Internet-protokolla

HTTP kolmas versio tunnettiin aiemmin nimellä HTTP-over-QUIC. Se perustuu UDP-protokollaan (connection less), jolloin hidasta ”TCP kättelyä” ei tarvita. Kaikki selaimet tukevat protokollaa ja nykyiset tietoverkot ovat riittävän luotettavia sen käyttämiseen. Sovelluksen vasteaika voidaan puolittaa.

HTTP3

HTTP3 käyttökohteita ovat Web-keinotodellisuus, IoT, micropalvelut sekä reaaliaikasovellukset

Google™, Facebook™, Microsoft™, Amazon™ käyttävät HTTP3/QUICK:ia kuluttajien palveluiden käyttökokemuksen parantamiseen. IETF standardoinnin myötä protokolla on tuettu Windows 2022-palvelimilla sekä monessa Web-alustassa.  Valitettavasti NGFW-palomuurien arkkitehtuuri ja CPU optimointi perustuu enemmän tai vähemmän ”TCP deep packet analysis” käsitteeseen. HTTP3 (UDP)  on niille ongelmallinen sekä suorituskyvyn, että uhkien analysoinnin näkökulmasta.  Sama tilanne on useimmilla DDoS ja SLB/WAF (Kuormantasaaja/Web Application Firewall) tuotteilla.

Toistaiseksi NGFW-teknologiavalmistajien suositus yrityksille on kieltää HTTP3 (QUICK) protokolla, ellei sen käyttöön ole painavaa syytä. Suositus on yhä ongelmallisempi käytön laajentuessa ja ihmisten verratessa yritysratkaisun käyttökokemusta kuluttajana.

Tarvitsemme New Generation Network Security ratkaisuja 2022

Historia osoittaa, että sen kustannustehokkaan tietoturvan toteuttaminen verkossa ei ole helppo yhtälö. Osin tästä syystä roadmap on kulkenut tasaisesti kohti Cloud Security ratkaisuja. Haluamme paremman näkyvyyden, paremman kontrollin sekä turvallisemman ratkaisun kaikille käyttäjäryhmille ja IoT-laitteille paikasta riippumatta. Onnistuneella projektilla saavutetaan parempi tietoturva pienemmillä kustannuksilla.  Suurimmalle osalle yrityksistä Cloud Security onkin erinomainen vaihtoehto, mutta HTTP3 on haaste niillekkin.

Pilvipalveluiden skaalautuvuus, suorituskyky ja nopea kehittyminen ovat olleet pitkään sen vahvuuksia. Toivottavasti ne ratkaisevat HTTP3-protokollan tuomat tietoturvahaasteet ja pääsemme nauttimaan myös yrityksissä nopeista ja turvallisista sovelluspalveluista.

 

Hannu Rokka, Senior Advisor

5Feet Networks Oy