• L’unica Certificazione di Prodotto Hardware e/o Firmware e/o Software esistente è Common Criteria (CC), che discende da ISO15408, ISO17799, BS7799 e ITSEC.
• La Certificazione Common Criteria è obbligatoria per prodotti militari, aerospazio, nucleare ecc.
• I Livelli di Certificazione (denominati EAL, Evaluation Assurance Level) sono sette. Quelli obbligatori partono dal quarto.
• Lo scenario è molto simile a quello di PCI-DSS (Payment Card Industry Data Security Standard), nel quale solo entità al di sopra di una certa dimensione necessitano di una Certificazione formale da parte di un certificatore accreditato (detto QSA, Qualified Security Assessor), mentre tutte le altre ricorrono alla auto-certificazione e al libero uso di essa anche per motivi di Marketing.
• E’ quindi perfettamente lecito affermare di essere CC-Compliant fino al terzo Livello.
• Tutti gli Standard in ambito IT (si pensi ad esempio a PA-DSS, Payment Application Data Security Standard) soffrono pesantemente la velocità di crescita e cambiamento delle tecnologie che essi stessi vorrebbero certificare. Molti fra essi però (come CC o appunto PA-DSS), in un contesto di auto-certificazione, sono facilmente modificabili o (meglio) estendibili al fine di coprire anche le più recenti novità tecnologiche (si pensi ad esempio a tutto il mondo Mobile o a tecnologie come AI, IoT e Blockchain o ai nuovi modelli di sviluppo Software).

• Il soggetto target di questa proposta è una entità (una azienda, una parte di essa come una Business Unit o simili, un Team ecc.) che realizzi prodotti HW e/o FW e/o SW.
• La proposta qui descritta è costruita per essere integrabile con tutte le principali metodologie di sviluppo e/o di gestione del Ciclo di Vita, quali ad esempio:
  • Waterfall
  • Agile
  • Fast Prototyping
  • Rapid Application Development
  • Scrum
  • Continuous Integration
  • ecc.
• Si assume che il soggetto adotti già un modello o una metodologia formale o pseudo-formale per i propri processi di produzione HW, FW e SW.
• Si assume in questo contesto una quasi totale sovrapposizione dei concetti di Qualità e di Sicurezza.

• HW: Hardware
• FW: Firmware
• SW: Software
• CC: Common Criteria
• ToE: Target of Evaluation
• ST: Security Target
• PP: Protection Profile
• EAL: Evaluation Assurance Level
• FSR: Functional Security Requirements
• FQSR: Functional Quality & Security Requirements
• ASR: Assurance Security Requirements
• AQSR: Assurance Quality & Security Requirements
• PCI-DSS: Payment Card Industry Data Security Standard
• PA-DSS: Payment Application Data Security Standard
• VA: Vulnerability Assessment – Questa terminologia e la sua definizione formale sono nate con ITSEC
• PT: Penetration Test – Questa terminologia e la sua definizione formale sono nate con ITSEC

• Risposte a Bandi di Gara o simili che includano evidenza formale (se non addirittura Compliance verso Standard, Normative, Best Practice, Linee Guida ecc.) delle relative metodologie di sviluppo / produzione;
• Due Diligence o Audit da parte di:
  • enti normativi o di certificazione ecc.
  • possibili acquirenti
  • entità interne alla medesima organizzazione
  • eccetera
• Propria autonoma verifica interna nei confronti dei suddetti Standard ecc., che sia spontanea (ad esempio per motivi di Marketing) o a seguito di un incidente.

• l’utilizzo di un “mix custom” delle azioni previste da Common Criteria nei sette EAL, soprattutto per garantire la presenza (almeno in parte) di ciò che ITSEC chiama Correctness Analysis (comunemente detta White-box Analysis), cioè delle azioni (quali la revisione formale del codice e della documentazione) che garantiscono il massimo livello di sicurezza possibile;
• l’utilizzo dei formalismi ST, PP, SFR e ASR di Common Criteria per le Specifiche dei Requisiti e per la definizione dei Test;
• l’utilizzo delle Checklist di Common Criteria come wrapper di tutto ciò;
• l’inserimento in tutto ciò (ove utile e pertinente) dei concetti proposti e mantenuti da OWASP, PCI, NIST, ISO2500X, ISO2700X, anche se detti Standard si applicano tipicamente a processi di gestione e/o a infrastrutture e non a prodotti.

• aumentare e definire quantitativamente il valore degli asset immateriali e del know-how aziendale nel tempo grazie a una maggiore copertura formale tramite CC
• presentare quindi i suddetti asset a una certicazione ISO 55001, che già garantisce:
  • di non avere fuoriuscite di know-how
  • di non avere perdite di valore del know-how per non adeguata secretazione...
  • ... o per sottostime dovute ad accordi commerciali e/o di partnership
• inquadrare tutto nel concetto di innovazione tecnologica per arrivare alla deduzione del 100% del costo della certificazione
• usare opzionalmente una Blockchain eIDAS-compliant per le problematiche di anti-contraffazione

• Perchè la proposta abbia una utilità, il team di sviluppo deve essere coinvolto.
• Si consiglia di sfruttare CC (e tutti i suoi predecessori) per uno dei suoi principali valori aggiunti, cioè quello di contenere una dettagliata definizione di tutte le possibili funzionalità e/o attributi di sicurezza che un prodotto possa avere, fino a darne anche un esempio in meta-codice. Anche la Documentazione può attingere alle ottime definizioni di ST e PP. In generale CC è un ottimo punto di riferimento e di confronto per capire a che livello di qualità e sicurezza si stia operando e ovviamente per migliorarlo.
• Come da sottotitolo, la proposta viene di solito erogata nelle fasi di:
  • Assessment (di solito inclusivo di VA/PT a supporto)
  • Gap Analysis
  • Action Plan
  • Compliance
  • Report che costituisce il deliverable delle attività

STANDARD CC FSRs

• CLASS FAU: SECURITY AUDIT
• CLASS FCO: COMMUNICATION
• CLASS FCS: CRYPTOGRAPHIC SUPPORT
• CLASS FDP: USER DATA PROTECTION
• CLASS FIA: IDENTIFICATION AND AUTHENTICATION
• CLASS FMT: SECURITY MANAGEMENT .
• CLASS FPR: PRIVACY
• CLASS FPT: PROTECTION OF THE TSF
• CLASS FRU: RESOURCE UTILISATION
• CLASS FTA: TOE ACCESS
• CLASS FTP: TRUSTED PATH/CHANNELS

A BLOCKCHAIN CC FSRs EXTENSION

• CLASS FCN: Consensus
• CLASS FID: ID Create and manage Self Sovereign Identity SSI, eIDAS Compliance
• CLASS FSI: E-SIGNATURE Electronically sign PDF and XML documents
• CLASS FDL: E-DELIVERY Notarizes the exchange of documents between parties
• CLASS FKC: E-KYC Manage KYC procedures for AML purposes
• CLASS FPY: E-PAY Request a Certified SEPA Payment
• CLASS FMI: E-MINT Issue and exchange Certified NFT tokens
• CLASS FNT: Non Fungible Token

1.Quotazione mirata tramite pre-analisi di max 3 giornate

2.Quotazione a corpo:

a)con eventuale pool di giornate per supporto / estensioni / imprevisti

b)omnicomprensiva

3.Time & Material con obbligo di fatturazione mutuamente concordato

4.Canone annuo

In ogni caso è possibile separare la sotto-attività di VA/PT.