Nel dialetto milanese, che ormai purtroppo in pochi conoscono e ancor meno usano¹, c’è un modo di dire che riassume bene il post che sto scrivendo oggi che, a ridosso del weekend, non può essere altro che un post di meditazione da leggersi, rigorosamente, questa sera con un buon bicchiere di vino o di grappa o di passito².

Ogni ofelè al fa el so mestè

Mi ricordo signora mia, quando ero giovane…

Era l’estate del 1997 e stavo finendo il biennio della Laurea in Informatica all’Università Statale di Milano. Allora le lauree non erano brevi e specialistiche; erano lauree e dopo 5 anni sudati eri orgoglione del titolo di dottore. Alla fine del biennio comune, il nostro corso di laurea portava comunque ad un triennio di specializzazione nelle varie aree dell’IT.

Ci sono corsi e professori che ti rimangono dentro a vita e ricordo precisamente, anche se potrei far confusione con gli anni, che ci furono 2 corsi che mi spinsero con forza nelle braccia dell’IT Security: il corso di Sistemi Operativi tenuto, magistralmente, dal professor Gianfranco Prini ed il corso di Architetture degli elaboratori 2 (questo mi pare fosse il primo semestre del terzo anno), tenuto dal professor Gian Paolo Rossi.

Ci sono 2 libri che ogni specialista IT nel campo della sicurezza deve tenere sul comodino perché fondamentali:

• Modern Operating Systems del Tanenbaum (sì quello di Minix, dal quale Torvalds si è inspirato per creare Linux);
• TCP/IP Illustrated Vol. 1 dello Stevens

Mettete insieme 2 professori che amano la loro materia, due pietre miliari della bibliografia in campo informatico, due materie veramente interessanti, gli ampex, il vi (non il vim… il vi) e se quella è la vostra strada, allora inizierete a spippolare di raw socket, di buffer overflow e di shellcode.

Poi vennero i corsi di sicurezza vera e propria con il professor Bruschi che chiusero il cerchio. Venne la mia tesi che mi portò nel kernel di linux e imparai, non solo a scrivere codice C e leggere codice altrui ma a relazionarmi con hackers anni luce più bravi di me: buffer e belch tra tutti.

Era il 2001, il 2 luglio e diventavo dottore. Ma più importante, avevo capito in campo lavorativo cosa volevo fare e quali erano le cose fondamentali dalle quali non discostarmi mai:

• studiare
• leggere qualsiasi cosa in rete (attinente)
• leggere il codice di altre persone
• spippolare
• scrivere, scrivere tanto
• essere umile, tanto umile
• farmi un culo così.

Aneddoto. Io ho sempre desiderato rimanere in ambito accademico e ricordo che Bruschi lo chiese a me e Aldo. Tuttavia quello che ci veniva offerto³ era meno di quanto offerto da importante società di consulenza informatica. All’epoca purtroppo mi portavo dietro un senso di colpa dovuto al fatto che mia madre spendeva soldi per la mia formazione e che non c’era altro reddito in casa. La mia scelta fu quindi dettata più dal dover portare qualche soldo a casa e avere un contratto più sicuro di quello da ricercatore.

Posto che ora nel 2014 sono riuscito a fare veramente quello che amo, quella fu la peggiore scelta della mia vita.

Stay hungry, stay foolish

Fare IT security, o fare l’hacker secondo la visione semplistica di alcuni, è qualcosa che, per come la vedo io, ti porta ad essere lavorativamente parlando un eterno ragazzino.

A parte il fatto che farei effettivamente ridere a fare review del codice in giacca e cravatta come se stessi andando ad un matrimonio, intendo dire che è un mestiere che va fatto con la stessa curiosità e voglia di imparare e sperimentare tipica di un bambino.

Se io facessi ogni giorno un penetration test nello stesso modo, usassi sempre lo stesso tool, usassi sempre gli stessi pattern d’attacco, sarei uno specialista finito in partenza.

Se io accettassi passivamente che il mio strumento di vulnerability assessment o portscan mi dicesse che c’è un IIS con la sua pagina di default su un server linux, più precisamente una debian, e lo mettessi annoiato in un report, non commetterei solo un madornale errore⁴ ma darei l’impressione di fare qualcosa tanto per fare.

Nel suo discorso a Stanford, Steve Jobs pronuncia la famosa esortazione che da il titolo a questa sezione: siate affamati (di sapere) e siate folli. La follia di cui si parla, in realtà ci si dovrebbe fare un bagno nella sottocultura degli anni 70, visto che la frase è presa dall’ultimo numero del Whole Earth Catalog per capirla a fondo, è quella che ti porta a pensare fuori dagli schemi, a spremere la mente per portarla su sentieri nuovi, possibilmente senza acidi.

La fame e la follia per un application security specialist sono quelle caratterstiche che ti fanno crescere. Di fronte ad un’attività, provare cose nuove e non fermarsi ad un risultato perché output di un tool.

Come si raggiunge questa follia dato che, difficilmente tutti noi saremo colpiti da una folgorazione come San Paolo sulla via di Damasco? La si raggiunge leggendo. Tanto.

Il web è pieno di risorse, ben più autorevoli di questa forse. Ci sono application security specialist senior che mettono a disposizione degli altri quello che hanno imparato. Non sfruttare questa conoscenza è semplicemente da idioti.

Pensare di essere arrivati, a 37 anni è da spocchiosi saccenti. Imparo costantemente qualcosa, giorno per giorno. Un nuovo trick, un nuovo linguaggio, un nuovo paradigma di programmazione, un nuovo software. E non sono più bravo di altri o più speciale. Ho semplicemente fame⁵.

Caro amico ti scrivo

Si dice che una persona abbia veramente capito un concetto se è in grado di esprimerlo chiaramente e di farlo capire agli altri. Quale miglior forma di espressione se non quella scritta.

Scrivere, e anche partecipare a conferenze come relatore, ti permette di raggiungere un sacco di obiettivi:

• relazionarti con altre persone
• farti nuovi amici
• girare il mondo (se ne hai la possibilità) e vedere posti nuovi
• approfondire e fare tuoi temi di tuo interesse

Non solo tenere un blog, scrivere un paper, scrivere il materiale per uno speech può essere utile… ma anche scrivere del codice è fondamentale per una persona che fa questo lavoro.

I motivi, sostanzialmente due.

Il primo motivo è che i tool esistenti sono scritti secondo esigenze che non sono necessariamente le mie, quindi posso voler scrivere un particolare strumento che realizza un particolare scopo. Bonus: anche così posso imparare qualcosa di nuovo.

Il secondo motivo è che se vuoi avere la presunzione di correggere il codice altrui, devi prima sapere cosa significa scrivere del codice e metterlo in produzione. Fare una code review non vuol dire eseguire il tool, vuol dire fare threat modeling, capire il ciclo di vita del software e come migliorarlo senza stravolgerlo e vuol dire come inserire la patch di security con esempi mirati e calati nel codice che si è appena testato.

Essere umile e farsi un culo così

C’è gente per la quale il successo è arrivare al titolone di manager e preparare bei diagrammi visio o gantt (senza un senso pratico) o presentazione con mille effetti ed animazioni. C’è anche gente che invece ama lavorare e farsi il mazzo tanto.

Io penso che se scegli di occuparti di sicurezza applicativa, le mani sporche le avrai sempre e soprattutto ci sarà sempre qualcuno più bravo di noi dal quale imparare.

Non solo, per raggiungere l’eccellenza l’unico ingrediente concreto è star zitti e lavorare tanto, magari emulando una o più persone senior delle quali parlavo prima.

Non è che trovare un po’ di SQL Injection con Owasp ZAP fa di una persona uno specialista di application security… soprattutto quando fa tutto ZAP.

Off by one

Purtroppo quello dell’application security specialist, o dell’hacker che dir si voglia, non è un lavoro per tutti. E’ un lavoro che ha le radici così profonde nelle attitudini personali che o ci sei portato o non lo diventerai mai. Eventuali certificazioni dimostreranno solo che sai studiare per un esame, ma se ti manca quel qualcosa dentro… bhé ti manca quel qualcosa dentro.

Quello che ho scritto può essere applicato per tutti i lavori di questa bella Terra, ovviamente cambiando i tecnicismi ma il concetto di fondo rimane. Se nella vita riuscirai a fare non quello che hai studiato, non qualcosa che pensi sia cool, non qualcosa che pensi ti possa portare soldi, non qualcosa che pensi ti faccia diventare un manager a bordo di una A4, ma riuscirai a fare quello per il quale sei nato allora avrai sia il successo che la felicità.

E spesso scopriremo se siamo riusciti solo alla fine.