Newsgroup: it.lavoro.informatica
Titolo: Risk Assessments

Anche voi i clienti mandano pomposi questionari di risk assessment? 
 
Sono tipicamente pieni di paroloni, plan, program, ognuno leggermente diverso:
 
- established patch management process
- established access control process
- established information security incident response plan
 
e via dicendo...noi sinceramente abbiamo un'agenzia che ci tiene i server AWS aggiornati e patchati il piu' possibile, se i server vanno giu' intervengono per quel che possono. 
Il resto e' su di noi, e se ci sono problemi semplicemente sistemiamo i bug. Ovvio che se e' un bug di sicurezza, lo sistemiamo il prima possibile.
 
Insomma, non abbiamo plan/processi formali per cose tanto ovvie...anche perche' sembra che ognuno chieda cose differenti, quindi dovremmo averne a dozzine.
 
Voi come fate?

 abbiamo un'agenzia che ci tiene i server AWS aggiornati e patchati il piu' possibile, se i server vanno giu' intervengono per quel che possono.
 
In che senso? Avete un'agenzia?


si risponde :-) anche con tanti n/a. immagino che anche voi avrete fatto 
l'assessment (è obbligatorio) e se avete valutato che, per quel dato 
rischio e nella vostra situazione, non ritenete opportuno adottare 
particolari procedure, va bene rispondere anche così. l'importante è che 
in caso di audit sappiate mostrare che la valutazione è stata fatta e non 
è un "me ne frego" :-)

 non è un "me ne frego" :-)
 
ah e se vi avvalete di amministratori esterni in fase di assessment 
dovreste anche aver mandato il questionario a loro.
 


diciamo che abbiamo un'azienda esterna che ci gestisce l'account AWS (quindi configurazione, patch sei server, consulenza, eccetera) e risponde in caso di crash o casini vari.


diciamo che ci passano alcune informazioni utili per il questionario, che cmq dobbiamo smazzarci da noi anche perche' in gran parte richiedono conoscenze specifiche sull'applicazione.


si in effetti visto che non trattiamo dati particolarmente critici potremmo anche lasciare in bianco il piu' possibile...ho come l'impressione che siano questionari non specifici al nostro business, ma uguali per tutti.

 Voi come fate?
 
Sorridendo sui /paroloni/
Cliente=dollari/euro/Renminbi
Peso argentino da evitare.
Faccio cio' che chiede il cliente.
 
Sono bravo?
Spiego al cliente che i /paroloni/ (ohhh my gosh!)
non servono e lo educo!
 
 
P.S.
Uno dei post piu' /divertenti/ mai letti!
-- 
ac (x=y-1)
Aborro il Killfile
(La violenza e' l'ultimo rifugio degli incapaci -Salvor Hardin-)

 - established information security incident response plan
 
Veramente avere processi consolidati e formalizzati per queste attività è basilare da un decennio almeno.
 
Consiglio di partire da ITIL per avere una idea di come si gestiesce un portfolio servizi senza farsi male e con soddisfazione reciproca.
 
Ciao
   Francesco Da Riva

 Consiglio di partire da ITIL
 
Solo se si riesce a farlo convivere con Agile.


Esempio: 
https://www.scalefactory.com/
 
Sono a London Bridge, il loro CTO conosce AWS credo meglio di chi l'ha fatto.
Praticamente capita che l'azienda sia troppo piccola per dare lavoro fulltime ad un devops, assumi loro e oltre a far quello per esempio ti mettono apposto l'infra per fare CI/CD, screening di sicurezza ecc.
Molto utile, piuttosto che far roba un tanto al kg.
 
  ngw

 Molto utile, piuttosto che far roba un tanto al kg.
 
Mah... non so, a me piace che sia il team intero ad avere controllo 
sulla CI/CD pipeline. Inoltre, il fatto che si distingua tra sviluppo e 
DevOps mi sembra proprio un DevOps antipattern.


Grazie, non conoscevo ITIL. Devo dire pero' che ci ho dato un occhiata e mi pare siano cose che o non si applicano per il nostro contesto oppure le facciamo gia'.
 
Ad esempio per il test e rilascio cerchiamo di seguire le linee guida delineate in "Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation".


Si, devo dire che appoggiarsi ad un'azienda esterna solleva alcune problematiche. Inevitabilmente rende il rapport tra sviluppo e messa in test/produzione piu' farraginoso.
 
Tuttavia nel nostro caso il rilascio dell'applicazione la facciamo noi. Inoltre siamo noi che diamo le specifiche per la configurazione AWS (specialmente quando si tratta di configurare servizi, non server), quindi effettivamente seguiamo la parte infrastrutturale. Solo che non la eseguiamo operativamente, se non nel nostro account di sviluppo (e qui' in effetti c'e' un ovvio problema).
 
L'alternativa era portarsi in casa uno o due esperti AWS in grado di configurare tutta l'infrastruttura dalla A alla Z in modo professionale usando terrraform e/o cloudformation, e allora stesso tempo fare formazione al team. Il che sarebbe stato parecchio piu' costoso.
 
Inoltre sono in grado di intervenire anche quando nessuno del team e' disponibile (ad es. di notte) e riavviare i server se necessario.

 Ad esempio per il test e rilascio cerchiamo di seguire le linee guida >delineate in "Continuous Delivery: Reliable Software Releases Through Build, >Test, and Deployment Automation".
 
Il che è una eccelente cosa ma che non basta nè a livello normativo nè per evitare i guai di integrazione con il resto del mondo.
 
Ciao
  Francesco

 Uno dei post piu' /divertenti/ mai letti!
 
Anch'io non ho capito niente circa il tema del thread. Ma ho il buon 
gusto di tacere.
 
-- 
The three most dangerous things in the world are a programmer with a 
soldering iron, a hardware type with a program patch and a user with an 
idea.
 
“Alles hat ein Ende, nur die Wurst hat zwei”


boh a me pare tanta fuffa, sinceramente. 
 
https://www.itil-italia.com/itilincidentmanagement.htm
 
 
Non mi serve "assicurarsi della volonta' dell'organizzazione di farlo", neppure che ci siano le risorse umane disponibili, e tanto altro.
 
Vado oltre:
 
- Definire i livelli di servizio da rispettare (andrebbero negoziati con gli utenti/clienti) per ogni tipo di incidente.
 
non ho una SLA e ai clienti non frega niente di negoziare una cosa del genere.
 
- Definire le priorita' degli incidenti in base a criteri obiettivi (matrice urgenza/impatto)
 
non mi serve definire una priorita' in maniera formale. Se e' grave si interrompono altre cose e si risolve, altrimenti ne discutiamo e si apre un ticket che verra' gestito come gli altri.
 
- Monitorare i livelli di servizio in maniera periodica (giornaliera o almeno settimanale)
 
Mi pare il minimo.
 
- Formalizzare accordi con gruppi esterni qualora gli incidenti vadano scalati (OLA o Operating Level Agreement)
 
gia' detto.
 
- Definire il ciclo di vita degli incidenti per evitare che vi siano "zone morte" in cui non si sa chi e' responsabile.
 
Roba per aziende medio/grandi.
 
 
Era solo un esempio, ma formalizzare questi processi nel nostro caso non mi pare minimamente basilare e preferisco spendere tempo e risorse sulle funzionalita' dell'applicazione.

 funzionalita' dell'applicazione.
 
In realtà trent'anni di esperienza collettiva del settore vanno in direzione esattamente opposta ma ovviamente è una tua scelta.
 
Ciao
  Francesco
 

 
 
Il settore e' piuttosto ampio e la tua realta' non e' quella di tutti.

 
 
Fai bene.
Magari non lo ho capito nemmeno io ma la tua /certezza/ che il
sottoscritto non abbia capito rende vano il tuo /buon/ gusto di tacere.
Ti amo nello stesso modo in cui amo Salvini!


On 26/08/2019 08:21, Francesco Da Riva wrote:
 
 > Non è un sciocchezza impostare bene un ambiente ed un processo di 
continuo miglioramente
 
Non serve necessariamente ITIL per quello. Con un qualunque framework 
Agile (vedi Scrum) ci riesci lo stesso. Che poi, come dicevo, ITIL puo` 
convivere con Agile.
 
 > Il che è una eccelente cosa ma che non basta nè a livello normativo 
nè per evitare i guai di integrazione con il resto del mondo.
 
Ovvero?

 boh a me pare tanta fuffa, sinceramente.
 
Alla fine, si tratta di non-functional requirements. Non serve ITIL per 
guidarti. Monitoring&Alerting, Auditing, SLA per uptime o performance, 
ecc... ecc.. sono roba che, almeno noi, integriamo gia` nel lavoro di 
tutti i giorni.

 In realtà trent'anni di esperienza collettiva del settore vanno in direzione esattamente opposta 
 
Quale sarebbe la "direzione" di cui parli?

 Il settore e' piuttosto ampio e la tua realta' non e' quella di tutti.
 
+1

 
 
P.S.
A me e' capitato di assistere (in religioso silenzio) ad un paio
di riunioni sul "Risk" che poi ci fosse "Assessment" era cosa relativa.
......ahhhhh erano strutture non esattamente di condominio!


 Ti amo nello stesso modo in cui amo Salvini!
 
Sei un imbecille naturale. E' una diagnosi.


 ......ahhhhh erano strutture non esattamente di condominio!
 
Confermo la diagnosi.


 Il settore e' piuttosto ampio e la tua realta' non e' quella di tutti.
 
La mia assolutamente no ma esiste qualche tonnelta di studi in materia: poi ovviamente puoi fare quello che vuoi ci mancherebbe.
 
Per la serie meglio sbagliare da soli che fare giusto ascoltato l'esperienza degli altri.
 
Ciao
  Francesco

 Quindi scarichi la responsabilità su di loro se qualcosa va male, senza nessuna rete nè per te nè per loro quando finisci davanti ad un giudice.
 
 
Ah ecco, di questo si parlava. Dipende da come scrivi il contratto con il clienete. Personalmente non me ne occupo.

 clienete. Personalmente non me ne occupo.
 
Il contratto con il cliente, interno od esterno che sia, è alla base di qualunque rapporto professionale. Esso può venire tradotto di modo più o meno legalese ma esso serve a tutti:
1)Indica cosa il cliente si aspetta da noi ed in che tempi
2)Indica cosa noi ci aspettiamo dal cliente perchè lui ottenga ciò che abbiamo concordato
 
Lavorare senza avere ben chiari questi elementi vuol dire essere continuamente in conflitto con cliente.
 
Dato che credo che voi lavoriato bene con ogni probabilità siete abbastanza piccoli e con un numero ristretto da far si che il contratto venga negoziato informalmente di volta in volta.
 
Il problema è che questo è un grosso rischio ed un serio ostacolo nel crescere: se all'azienda e a voi va bene così è una scelta ma non stupirti se ti taglia fuori da molti clienti\mercati o se un giorno esploerà una rogna mortale.
 
Ciao
  Francesco
 


noi offriamo lo stesso servizio per tutti i clienti. L'azienda per modus operandi non mi coinvolge minimamente nel discorso contratti. Per quanto concerne la mia posizione non sono emerse fino ad ora specificita' e neppure casini. 
 
A volte un approccio ottimistico e' molto meglio di altri e consente di ridurre i costi e procedere spediti. Soprattuto se non si percepiscono rischi (i nostri clienti sono particolari, la piattaforma non e' critica, ecc..),  e in ogni caso non e' il mio lavoro farlo. Sarei il CEO altrimenti.
 
Poi certo se dovessimo cambiare modello di business (c'e' una piccola probabilita' che accada) e di diventare un fornitore di servizi per terze parti, allora sicuramente mettere in piedi SLA e formalizzare meglio alcuni processi diventera' necessario.

 il clienete. Personalmente non me ne occupo.
 
ni. nel senso, ci sono norme di legge e queste hanno forza maggiore 
rispetto ai contratti. per esempio: se eroghi un servizio ad un cliente e 
in questo servizio gestisci dei dati di sua proprietà, sei tenuto ad avere 
procedure adeguate contro una eventuale perdita o data breach. per questo 
mandano i questionari. se dimostri di non avere procedure adeguate in 
linea neanche tanto teorica possono dirti "mi spiace ma non puoi essere 
un nostro fornitore, il contratto è nullo" anche se nel contratto non è 
specificato nulla a riguardo. 
 
ovviamente se avviene davvero la perdita o la violazione peggio mi sento, 
lì son cazzi a prescindere. ma all'atto pratico le procedure formali 
servono proprio a ridurre quando non a eliminare questo rischio, perché è 
ovvio le politiche di backup piuttosto che le policy di sicurezza non 
formalizzarle e demandarle al giudizio arbitrario di chi le implementa 
(per quanto bravissimo) per l'azienda vuol dire stare col culo alla 
finestra.