Vai al contenuto
Home » Ho, Snaitech e quella sensibilità che ancora manca

Ho, Snaitech e quella sensibilità che ancora manca

Snaitech
e l’operatore mobile
Ho.
sono
state le ultime vittime in ordine di tempo di attacchi informatici o comunque
di fughe di dati.

Mentre nel caso di Snaitech sembra trattarsi del solito DDos, nel caso di Ho.,
la fuga di dati potrebbe essere stata realizzata attraverso un’API realizzata
in maniera poco
robusta.

Empatia

Condizionali a parte, mettiamo subito una cosa in chiaro. La community in casi
come questi dovrebbe essere più solidale con la vittima di un attacco.

Non solo potrebbe capitare a tutti, oppure è già capitato e neanche ce ne siamo
accorti, ma bisogna sempre ricordare che dall’altra parte ci sono
professionisti che tutto meritano tranne che andare alla gogna, anche perché in
molti casi sono gli ultimi a doversi prendere la colpa.

Vizi italici e non solo

Veniamo a qualcosa che vediamo spesso nei progetti IT in giro per il mondo o
per diretta esperienza o per i racconti di amici e colleghi.

  1. Il progetto ha delle scadenze irrealizzabili decise a tavolino da persone
    non tecniche, non in grado quindi di stimare lo sforzo necessario ad
    implementare un servizio webo mobile.
  2. L’appalto per lo sviluppo non viene dato ai migliori ma a chi poi mi farà un
    favore / ad un amico manager / a chi mi costa meno. Già, l’approccio del “me
    lo fa mio cugino” è purtroppo molto diffuso e i risultati a cui porta è codice
    non sviluppato adeguatamente, mal progettato e soprattutto non testato
    adeguatamente.
  3. Io non voglio disservizi, quindi apparati come Intrusion Prevention System o
    WAF li tengo spenti, sempre se esistono.
  4. I penetration test affidati a chi può uscire con tariffe da 100 euro al
    giorno. Dopotutto, il poco budget a disposizione per un progetto i cui
    penetration test sono emersi solo in corso d’opera, non permette di affidarsi a
    quelle 3/4 società italiane per i quali qualche euro in più valgono tantissimo.

Quindi, poco tempo a disposizione, pianificazioni errate e corsa al risparmio.
Questi i tre vizi capitali che portano un progetto software alla ribalta delle
cronache per essere stati oggetto di un attacco criminale.

Off by one

Quale il compito di chi fa application security in azienda? Sensibilizzare,
parlare, creare una cultura aziendale per far capire che la security ha un
costo non più negoziabile all’interno di un progetto IT.

Certo, noi abbiamo anche il dovere di pensare gli sforzi, come linee guida di
sviluppo o API robuste, in maniera tale che siano riutilizzabili in modo da
spalmare il costo per l’hardening su più progetti.
Awareness e automazione quindi. Cercare di introdurre code review light o
assessment per vulnerabilità macroscopiche, che possano essere fatte da uno
strumento, mentre l’effort insostituibile di un professionista deve essere
speso per un’analisi approfondita, per evitare che un attaccante poi possa
farvi fare una magra figura sul mercato.

Insomma, basta andare al risparmio.
Enjoy it!

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.