Palo Alto Networks har nå lansert WildFire i Europa! Datasenteret står i Amsterdam og gir oss i Norge følgende fordeler:

• Mindre latency og høyere hastighet
• De som håndterer data og drift er ansatt i ett eget selskap opprettet i EU, og de kommer alle fra EU land.
• Kundedata forlater aldri EU, og er derfor underlagt EU sin lovgivning
• Gratis å bytte til EU tjenesten

Så det er bare å bytte over!

Steg 1:

Logg på brannmuren gå deretter til Device -> Setup -> Wildfire. Trykk på konfigurasjons hjulet.

Steg 2:

Endre URL fra wildfire.paloaltonetworks.com til eu.wildfire.paloaltonetworks.com. Trykk OK.

Steg 3:

Commit. Du er nå tilknyttet skyen i EU!

NB! Alt av rapporter kommer nå også på https://eu.wildfire.paloaltonetworks.com, gamle rapporter blir liggende på gammel URL.

Jeg hadde ett innlegg om File Blocking i PAN-OS i fjor, som du kan lese her.

Kort oppsummert så ville jeg vise styrken til funksjonen da, nå vil jeg vise styrken til plattformen!

Vi logger inn på brannmuren, og hoppe til “Objects->File Blocking”, trykker Add for å lage en ny profil.

Eksemplet mitt er enkelt, men her kan man legge inn det man ønsker å blokkere fra de litt mer usikre sidene ute på internett.
For de som også lurer så dekker begrepet “PE” eller Portable Executable følgende filtyper:  exe, dll, com, scr, ocx, cpl, sys, drv, tlb.

For en fullstendig oversikt over alt som kan blokkeres se her.

Trykk OK for å lagre profilen. Neste steg er å definere en regel.

Her ser du en regel der vi tillater all trafikk, men med File Blocking profilen definert. Det betyr at vi her blokkerer alle PE filer til og fra internett. Bra for sikkerheten, men det vil nok ikke fungere i praksis. Hva kan vi da gjøre?

Innenfor sikkerhet så handler det mye om å scanne, detektere og rapportere, men det er vel så viktig å minske angreps flaten.

Og om det ikke lar seg gjøre å blokkere alle PE filer til og fra internett, så kan vi iallefall stoppe de som kommer fra de mindre sikre URL kategoriene. Kategorien “unknown” er mitt eksempel da dette er en av de litt mer usikre kategoriene som mange tillater, da alle nye domener og sub-domener havner her før de blir kategorisert for første gang.
De mer ondsinnede kategoriene er forhåpentligvis allerede satt til block, så da er det ikke nødvendig å inkludere dem i denne regelen.

Andre URL-kategorier som dere bør vurdere å gjøre det samme om de ikke er blokkert er:

• dynamic-dns
• hacking
• insufficient-content
• parked
• not-resolved

Så med noen enkle steg, så har vi blokkerte nedlasting av PE filer fra ukjente\ikke kategoriserte sider, og alt dette fikk i plass i en enkel regel..

Samtidig har vi hevet terskelen for angriperne, og mange vil bare hoppe til neste mål så fort de møter motstand. Tid er penger for dem også!

Raskt tips for dere som bruker console på Palo Alto Networks sine bokser!

Om dere ikke har gjort det så bør dere kjøre følgende kommandoer for å slippe at tekst overskriver hverandre og blir uleselig:

> set cli terminal height 500

> set cli terminal width 500

Nå vil dere oppdage at det er veldig mye lettere å lese tekst!

Settings ellers for best mulig opplevelse:

Bits per sec    :  9600

Data bits       :     8

Parity          :  none

Stop bits       :     1

Flow control    :  none

Sikkerhet.

Sikkerhet kan defineres som en tilstand; fravær av uønskede hendelser eller frihet fra fare og frykt.  Denne tilstanden er imidlertid ikke statisk, men påvirkes av endringer i faktorer som trussel og farer, sårbarhet og verdi. – Definisjon fra Store Norske Leksikon

Det er nøkkelordet som driver meg i mitt arbeid. Mitt mål er å gi kunden frihet fra fare, og for å få til det må man implementere løsninger som gir full visibilitet i nettverket.

Og med full visibilitet mener jeg at man kan se alle applikasjoner over alle porter. Hva hjelper det om man har dyre proxyer eller IPS\IDS løsninger når de kun kan inspisere ett utvalg av standard-porter?

Da blir det som bildet illustrerer, at hendelser kan skje ubemerket utenfor «synsfeltet» for de løsningene man kanskje allerede har i nettverket sitt.

Og det er her vi kommer tilbake til overskriften for denne blogg-posten.

Veldig mange bedrifter mener de allerede har gode nok løsninger og rutiner for å håndtere IT-sikkerhet.

De har ofte den klassiske oppskriften med:

• Generisk AV-klient fra en kjent leverandør
• Proxy for klient-trafikk ut mot internett, uten SSL-terminering i de fleste tilfeller
• Noen ganger en IDS eller IPS
• Generisk brannmur som opererer på port-nivå

Problemet? Med unntak av AV-klienten så forholder alle løsningene seg til porter.
Om trafikken ikke treffer noen av disse portene som er «overvåket» så er man blind i hva innholdet faktisk er i pakkene. Er det legitim trafikk? Eller var det designet på produktet som skulle redde fortjenesten de neste 10 årene som forsvant til Kina over SSL på port 999?

Noen vil argumentere at med god kontroll på den ytre brannmuren så kan man stenge for utgående trafikk over rare porter. Men hva om man bruker kjente porter som er åpne? Vil brannmuren stoppe SSL over port 21? Vil den stoppe DNS over port 443? Eller enda enklere, kan man inspisere SSL overhode?

Og tilbake sitter man igjen med en bedrift som er strålende fornøyd, for utfra deres logger så er alt helt strålende i nettverket. Ingenting er galt.

Det er ikke da lett og overbevise dem om at de må investere i ett nytt produkt som faktisk gir dem hele bildet. De tror allerede at de har det.

Dette endrer seg selvfølgelig alltid etter en Proof-of-Concept, når de faktisk ser det fulle bildet. Den blinde har plutselig fått laseroperasjon og kan endelig se på begge øyne!

Og i de fleste tilfeller er ikke bildet så pent som de hadde ønsket. BitTorrent, TOR-nettverk, SSL over ustandard porter, C&C trafikk fra gamle servere med mer.

Men det vi kan se, kan vi også stoppe.

Det er først nå vi kan snakke om frihet fra fare.

Intro

Proxy er ett produkt som har eksistert lenge i IT-verdenen, og historisk så var jobben til de første løsningene:

• Fungere som ekstern gateway for interne maskiner i ett bedriftsnettverk. (Som vi løser med NAT i dag)
• Regulere tilkoblinger via URL-filter og/eller IP-filter
• Cache for å spare båndbredde (Relevant når vi hadde ADSL på 1000+ brukere.. )
  

Illustrasjon hentet fra BlueCoat

Som illustrasjonen viser så var en av de største fordelene med proxy at man kunne spare båndbredde og samle alle klientene bak en IP-adresse mot internett. Dette var helt nødvendig når flere 100 om ikke flere 1000 brukere delte internettlinjer på 3-10Mbits. Om alle skulle da ha en «fersk» kopi av vg.no klokken 08:00 hver morgen så ville hele linjen knelt.

Dette gjorde proxy til en nødvendighet for større bedrifter og organisasjoner.

Over tid så utviklet leverandørene av proxy til å tilby flere funksjoner som:

• Anti-virus skanning av filer
  • Noen hadde «on-box» mens mange leverte via ICAP
• URL-Filter
• Applikasjonsfilter
• Stream-splitting
• Bruker-identifikasjon

Dette gjorde at proxy utviklet seg fra å være en nettverksenhet til og bli en sikkerhetsløsning som kunne filtrere bort skadevare å uønskede websider \ applikasjoner fra internett-trafikken.

Dette fikk stor suksess i markedet, for brannmurer var fortsatt bare port-baserte i de fleste tilfeller, ved hjelp fra proxy fikk man endelig noe innsyn i web-trafikken.

Utfordringer med tradisjonell proxy

Den største styrken til en proxy løsning, er også en av de største problemene.

Enten om man bruker eksplisitt proxy* eller transparent proxy** så er tanken at proxyen utgir seg å være serveren ovenfor klienten som sender spørringen.

Illustrasjon hentet fra Cisco

Som illustrasjonen viser så oppretter en proxyen 2 stk separate tilkoblinger, en mot klienten og en annen mot serveren som klienten spurt om tilgang til.
Dette gjorde at man fikk mulighet til å skanne, endre og blokkere trafikk før den ble sendt videre ut på internett.

Porter

Utfordringen er at de fleste proxy løsninger lytter kun på porter relatert til web-trafikk som tradisjonelt er:

• 21 (FTP)
• 80 (WEB)
• 443 (SSL)
• 8080 (Eksplisitt Proxy)

Dette gir ikke full visibilitet over nettverkstrafikken, særlig nå som applikasjoner ofte bruker «port-hopping» for å finne en vei ut av nettverket. Skype er en av mange eksempler som finner seg en port som fungerer, om så den porten er 80, 443 eller 5050.

De fleste proxyer kan heller ikke per i dag identifisere en applikasjon om den kommer over en «non-standard» port.
Som bringer oss til neste problem.

Applikasjoner

Flere proxyer støtter i dag applikasjonskontroll, og i mange tilfeller fungerer dette tilfredsstillende.

Problemet er at databasen over kjente applikasjoner ofte er liten, og omfatter sjeldent noe annet enn applikasjoner relatert til streaming, sosial media eller filoverføring.

Årsaken til dette er at det krever mye arbeid for å undersøke hvordan hver enkelt applikasjon fungerer i kommunikasjon mellom klient <-> server. Hvilke porter brukes? Er alt TCP? Er noe UDP? Går det ICMP kontroll meldinger? Sertifikat? SSL? Headere?

Dette kan ta alt fra uker til måneder og utarbeide, som igjen har ført til at de fleste leverandører har små databaser med applikasjoner.

Som fører oss til:

Web 2.0

Applikasjoner er ikke lengere Word, Excel, Kabal og PowerPoint eller andre programmer som kjører lokalt på arbeidsstasjonen til brukeren.

Applikasjoner er nå også Facebook Messenger, Google Apps, SalesForce og resten av løsningene vi kjører via web-browseren.

Flere og flere applikasjoner lever nå i skyen under paraplyen «Software as a Service (SaaS)», dette er dynamisk levende web-løsninger som oppdateres med nytt innhold flere ganger i minuttet.

Resultatet er at tradisjonelle proxy leverandører ikke klarer å kategorisere eller oppdatere applikasjonene sine fort nok, som fører til driftsforstyrrelser som igjen fører til unntak og dermed unntak fra sikkerhet.

Ytelse

Det kreves en del prosesseringskraft å håndtere AV-skanning, URL-filter, Applikasjonskontroll og SSL-dekryptering, særlig når man vet at en proxy må opprettholde 2 helt separate tilkoblinger mot klient og server.

Dette sammen med latencyen en proxy medfører gjør at man ofte kun sender klient-trafikk igjennom, og ikke annen «kritisk» trafikk man ikke vil risikere skal få problemer når proxyen er overbelastet.

Management

Det er også en utfordring og spre sikkerhet over flere løsninger, om man allerede har en «NGFW» i nettverket sitt, så virker det mot sin hensikt og flytte noe av sikkerheten over i en annen løsning.
Dette gjør at man mister kontekst på trafikken, og kan føre til at sikkerheten blir forringet.

Kostnader

Det er også en økt kostnad ved å vedlikeholde en proxy løsning.

• Hardware-kost (3-5år mellom hver gang man bytter)
• Årlig lisenskost for løsningen
• Årlig vedlikehold for løsningen
• Intern driftskostnad
  • Kurs
  • Sertifisering
  • Nedetid for oppgradering

Konklusjon

En tradisjonell proxy var svaret vi hadde for 20 år siden når behovet for internett i bedrifter og organisasjoner kom.

Det løste alle problemene vi hadde på den tiden, og med årene utviklet man proxyen til å bli en viktig komponent i nettverket for sikkerhet ved bruk av AV-skanning og avanserte URL-filtre.

Nå har landskapet endret seg, internett er ikke lenger en samling av statiske bilder og tekst, men er nå levende med facebook, twitter, linkedin, instagram og haugevis med andre integrasjoner på kryss og tvers av alle sider.

Går du på www.vg.no klokken 10:00, så er innholdet allerede endret 10:01.

Caching er dermed helt utelukket, noe som er helt greit når de fleste bedrifter og organisasjoner har 100mbit, om ikke 1Gbit linjer.

Da sitter man igjen med en løsning som kan skanne etter virus og blokkere tilgang basert på URL-kategorier.
Hvilken annen løsning kan gjøre det?

Palo Alto Networks

Løsningen til Palo Alto Networks som ofte bare blir kalt «Next Generation FireWall (NGFW)» sin store styrke er at den klassifiserer applikasjoner uansett hvilken port trafikken kommer inn på. ***

Så om f.eks DropBox bruker port 3000, 27 eller 443 så klarer Palo Alto og klassifisere applikasjonen riktig.
Om man da har blokkert DropBox så vil trafikken bli droppet, og brukeren vil ikke få brukt applikasjonen.

Dette hadde ikke vært tilfellet ved bruk av proxy i kombinasjon med portbasert brannmur som identifiserer applikasjoner etter hvilken port de bruker. Applikasjonen ville da fungert, og man kunne potensielt lekket viktig dato ut til DropBox.

Om man dermed kombinerer Palo Alto sin applikasjonskontroll som inneholder over 2000 applikasjoner, med Threat Prevention****, PAN-DB URL-filter, Content-ID,Wildfire(Advanced Malware Detection) og User-ID så har man en plattform som leverer full synlighet, sporbarhet og sikkerhet for web-trafikken i nettverket deres.

Man kan da bygge en policy som rundt de applikasjonene og URL-kategoriene man ønsker i nettverket sitt. Man slipper å måtte forholde seg til 2 eller flere løsninger for å løse ett problem som Palo Alto Networks er designet fra grunnen opp til å løse.

*Eksplisitt proxy
 Explicit proxy deployments require an IT organization to configure the web browsers on every laptop and workstation in their enterprise to ensure that web traffic is pointed to the proxy appliance or security device. Many enterprises deploy proxy auto-configuration (PAC) files using manual methods, system policies enforced by Microsoft Global Policy Object (GPO), or via web proxy auto-discovery (WPAD) protocol. However a misconfigured WPAD file could allow an attacker to redirect a user’s machine toward a malicious configuration file, while too restrictive of a GPO can result in an increase of IT trouble tickets submitted by frustrated users. Organizations face additional challenges when they don’t own or control an endpoint, like mobile devices, which can be used to bypass corporate proxy policies.

** Transparent proxy 
 Implicit, or transparent proxy deployments add complexity, latency, and include additional equipment to manage, all for a partial view of traffic on the network. Implicit proxies typically involve IT organizations that reconfigure their switches and routers to use Web Cache Communication Protocol (WCCP) for steering web traffic directly to the proxy appliance. Many proxy appliances pass off certain inspection tasks, e.g. AV scanning, via Internet Content Adaptation Protocol (ICAP) to an additional, separate appliance. Not only does this add to the complexity, it becomes yet another tool that requires another management console. The entire process impacts performance while the proxy device takes time to forward traffic to the AV scanning appliance and holds the connection open awaiting a response on whether to allow or deny that traffic

*** https://www.paloaltonetworks.com/products/technologies/app-id.html

**** https://www.paloaltonetworks.com/solutions/initiative/threat-prevention.html

«Alle» har sett, fått eller hørt om noen som har fått en eller annen form av Crypto-ransomware.
Historien er som regel lik, en klient ble infisert, denne klienten hadde tilgang til filserveren som igjen resulterte i mengder på mengder med ubrukelige krypterte filer.

( Fra IT-sjefen sitt kontor når han får beskjeden )

For de fleste så resulterer det i full heksejakt på den infiserte klienten, før man kjører en full restore fra backup.
Noen velger også å betale, som oftest fordi de ikke har backup eller tenker det er raskere enn å kjøre en full restore.

Og det gir oss ett problem. Angriperne får betalt, og de får betalt godt.

Det er faktisk så god butikk at de kommer med egen kundeservice som i mange tilfeller er bedre enn det man får fra legitime tjenester. For så lenge de leverer det de lover ved betaling, så vil vi fortsette å betale. De er faktisk avhengig av den tiltroen. For hadde vi visst at de ikke åpnet, hadde vi aldri betalt.
Og siden vi betaler så får de mer penger til å utvikle crypto-ransomwaren enda mer, det er som enhver annen bedrift. Går det i pluss så fortsetter man. Dette er en sirkel vi ikke ser slutten på før de faktisk ikke tjener særlig penger lengre.

Mange jeg har pratet med har resignert, og tenkt at dette er noe de må leve med. Ingen av de tradisjonelle løsningene de har klarer å stoppe alle mutasjonene.

( Følelsen med enda en dag med cryptolocker )

Den tankegangen fører som oftest til investering i enda bedre backupløsninger, som gjør at de enda raskere kan rulle tilbake når den infiserte klienten har blitt tatt hånd om.

Men vi snakker fortsatt om nedetid, og får mange mange av dem i måneden så kan det bli dyrt.

Jeg mener også det er en veldig passiv tankegang, det blir litt som om vi skal legge ned Politet og heller investere pengene i helsevesenet fordi vi ikke kan stoppe alt av voldskriminalitet.

Ja, vi må ha gode løsninger for backup, men vi må ikke bare tenke retroaktivt. Vi må også være proaktive og prøve å stoppe angrepet før det skjer.

Hvordan gjør vi så det?

Vel, som vi har allerede vært inne på, så er det klientene som blir infisert.
Gjerne via e-post kampanjer som er pakket pent inn med kjente norske merkenavn, der Posten kampanjen er det mest kjente. Alle har ett forhold til posten, og mange av oss venter pakker.
Da er det ikke så rart at denne kampanjen traff bredt, og førte til at svært mange IT-avdelinger måtte bruke en del overtidstimer på å rydde opp.

( Eksemplet er på engelsk, men det kom også versjoner på Norsk )

Hadde derimot klientene vært beskyttet godt nok, så hadde det meste blitt stoppet før det fikk gjort noen skade.

Min anbefaling er at man tar en titt på det som kalles «AMD» til bedriftens klienter og servere.
«AMD» står enkelt nok for «Advanced Malware Detection», og er løsninger for å se på oppførsel av programvare fremfor av-signaturer som ofte ikke klarer å holde følge med den raske utviklingen.

Slike «AMD» løsninger ser fort at noe ikke er helt på stell når PDFen du fikk på e-post prøver å gi seg flere rettigheter, laster ned filer, oppretter SSH tuneller eller mer.

Palo Alto Networks har en løsning for dette som heter TRAPS:

Med Traps eller en annen AMD løsning på klientene dine er man mye bedre rustet til å stoppe Crypto-ransomware, og andre zero-day sårbarheter. Tiden er over der man må la seg bli infisert for deretter rydde opp, nå er tiden å bekjempe dem før de får gjort skade!

Så kan man gå på jobb og føle seg slik:

Lykke til!

Zone Protection er en viktig bit i puslespillet for å få ett godt oppsett på brannmuren. Men jeg ser ofte at dette blir glemt, noe jeg håper jeg kan endre på med denne blogg-posten!
Så hvor legger vi på Zone Protection? Jo, under Zones:

Dette er hentet fra min LAB som kjører 7.1 Beta, men det ser tilnærmet helt likt ut på 7.0.
Du ser hvor du velger profilen her. Profilen gjelder for innkommende trafikk, og ikke utgående. Derfor har vi en “External” profil på Untrust som står mot internett.

Men før vi kan legge den til her må vi lage en Zone Protection profile. Det gjør du under Network -> Network Profiles -> Zone Protection

Trykk “Add” og du får opp følgende skjermbilde:

Første valget er “Flood Protection” som beskytter deg mot akkurat den sier. Flooding av pakker. Her er info hentet fra SANS sitt dokument vedrørende “Best practice” på en Palo Alto Networks:

Recommendation:

The Alert, Activate, and Maximum settings for SYN Flood Protection depend highly on

the environment and device used. Traffic analysis should be performed on the specific

environment and firewall to determine accurate thresholds.

As a rough ballpark for most environments, an Activate value of 50% of the firewall’s

maximum “New sessions per second”/CPS is a conservative setting. The following is a list of

new sessions per second maximum for each platform:

PA-200 = 1,000 CPS

PA-500 = 7,500 CPS

PA-2000 series = 15,000 CPS

PA-3000 series = 50,000 CPS

PA-5000 series = 120,000 CPS

PA-7050 = 720,000 CPS

Les mer i dokumentet som du finner her: SANS Whitepaper Palo Alto

Så har vi “Reconnaissance Protection”, som kan være lurt å ha på Zonen som står mot internett. Sett på alert i første omgang, men så kan du vurdere å sette til Block eller Block-IP om du ser mye aktivitet fra enkelte hoster.

Siste fanen er “Packet Based Attack Protection” som har flere underfaner igjen. Den første ser vi er “IP Drop”.
Det første valget her er nok godt kjent for mange, som beskytter Zonen fra spoofete IP addresser.

Her er ett utsnitt fra hjelp (?) i høyre hjørne:

Denne typen info finner du under alle fanene, jeg tok med denne da denne er den viktigste fanen. (Merk IP Drop og TCP Drop er samme fane i 7.0).

Under “TCP Drop” har vi ett par viktige valg når det kommer til asynkron ruting. Standard verdiene for Non-SYN TCP og Asymmetric Path er “global” som betyr at den henter info fra det som er satt i CLI. Men om man har en Zone som man trenger å tillate asynkron ruting, så kan man gjøre det via denne funksjonen. På denne måten trenger du ikke å gjøre om dette for hele brannmuren via CLI.

Her bør man iallefall ha på “ICMP Large Packet”, slik at ingen sender ut masse data med hjelp fra ICMP 🙂

De siste fanene er selvforklarende om man jobber med IPv6.

MERK: Du vil ikke få logger fra Zone Protection så lenge trafikken blir stoppet\tillatt av default intra\inter-zone regler, da disse ikke logger!

Det høres enkelt ut i prinsipp, man bare skiller enhetene i nettverket fra hverandre og kun tillater trafikk som tilhører applikasjonene man trenger.

For eksempel så trenger ikke klientene til de ansatte full tilgang SQL-serveren på alle porter? Trenger de tilgang til den i det hele tatt egentlig? For det er jo web-applikasjonen på web-serveren som faktisk henter data derfra?

Og den nye fine printeren som har alle de kule funksjonene, er det så lurt at den står i samme nettverk som klientene dine? Den kjører jo Windows Embedded, og du har vel ikke akkurat kontroll på patch-nivået på den?

Eller enda verre, hva med kaffe-maskinen som du har koblet i nettverket slik at den kan si ifra automatisk når den trenger service til leverandøren? Hvordan gjør den det? Mest sannsynlig ett UNIX-basert OS. Vet du sikkerheten på den? «Admin/kaffe123» er ikke sikkerhet på toppnivå. Og tror du ikke den kan kjøre en FTP server?

Som sagt, tanken er enkel, men ikke alltid så lett å følge opp i prinsipp.

Ofte blir nye løsninger og enheter innført uten mye tanke på sikkerhet, men at «dette må vi bare ha nå!». Over lang tid ender man opp med uoversiktlige nettverk, der man ikke har full kontroll på hva som prater med hva.

Når man da skal begynne å ta tak i problemet, så kan det ofte bli ett veldig omfattende prosjekt.
Det er ikke alltid så lett å bare endre IP på en haug med servere eller printere, ikke alt av tjenester bruker DNS som oppslag.

Så hvor starter man? Etter min mening er den beste strategien å starte med det viktigste i nettverket, og jobbe seg nedover.

For mange vil det være database serverne, det er de som ofte har sensitiv informasjon som man absolutt ikke vil se ute på internett i en ZIP fil.

Og det er her en av de største styrkene til Palo Alto Networks ligger!

Ett vanlig flatt nettverk som mange mange bedrifter i det norske land har:

Dette er en angripers drøm, ett helt flatt nett der man ikke har noen barrierer, og der man ikke har noen barrierer har man heller ikke noe visibiltet. Noe som igjen betyr at angriperen kan være i nettverket nesten så lenge han ønsker.
Noe må gjøres! Men hva kan man gjøre uten å måtte endre hele nettet? Hva kan man gjøre NÅ?

Man kan innføre en Palo Alto Networks brannmur inn i nettverket, og sette den opp på Lag 2, man kan da si at all trafikk som kommer inn eller ut fra ethernet1/2 er Servere, ethernet1/3 er klienter og ethernet1/4 er Printere.

På den måten har man raskt laget soner, som man igjen kan legge regler på. Uten og faktisk endre en eneste IP-adresse i nettverket.
Styrken som jeg vil komme frem til er at Palo Alto Networks støtter Lag 2, Lag 3, Virtual-Wire og TAP om hverandre, dette gjør det mulig å beskytte hele nettverket ditt med de metodene du trenger.

Så kan segmentere videre når man har anledning for nedetid, og prosjektplanen er spikret.

Lykke til 🙂

Mitt første mål når jeg startet i Arrow ECS var at jeg skulle bli instruktør på Palo Alto Networks sine produkter.
Det har jeg jobbet målrettet mot i 4 måneder, og det hele ble avsluttet med en tur til Amsterdam fra 18-20 januar for det Palo Alto Networks kaller for “ICW” (Instructor Certification Workshop).

Palo Alto Networks har endret kurset etter de ansatte en ny sjef for opplæring som heter David Day, som kommer fra VMware. Det er nå mye mer krevende, og noe man absolutt ikke skal ta lett på.
Palo Alto Networks sin innstilling er at instruktørene som jobber rundt i verden representerer dem, og må dermed holde den absolutt høyeste kvalitet. (Slik som produktet deres gjør.. 🙂 )

For å si det mildt ble det 3 harde dager, hvor vi ble testet og korrigert på alt som har med det å være instruktør.
Øyekonktakt, bevegelser, “fillerwords” (hummm, aaahh etc), whiteboard bruk, eksempler fra virkeligheten, og sist men ikke minst spørsmål fra studentene.
Her fikk vi høre at man kan høre det meste. En av favrittene mine var “So what happened with IPv5? Why the jump to IPv6?”.

Gleden var dermed stor når jeg fikk beskjed om at jeg stod, og jeg nå er klar til å lære bort 201 og 205 kursene til Palo Alto Networks!
Jeg gleder meg veldig, og tror det blir en morsom opplevelse for alle parter som kommer på ett kurs hos meg!

Håper å se deg snart, på ett kurs på Palo Alto Networks hos Arrow!