venerdì 13 gennaio 2023

Snyk, come accontentare Developers e Security officers

Per lavorare nella cybersecurity serve conoscenza della materia, attenzione ai dettagli ed un buon portfolio di tools ai quali affidarsi.

Uno dei tools con cui ho avuto il piacere di lavorare negli ultimi mesi è Snyk.




Chiamarlo tool è riduttivo perchè Snyk è una security plattform che comprende una serie di tools atti a rendere sicuro tutto il codice che potete produrre:

Negli ultimi anni le righe di codice sono cresciute esponenzialmente, le librerie open ed i container a disposizione dei developers hanno aumentato la quantità di codice prodotto semplificando il lavoro, ma a che prezzo?

In che modo  si può essere sicuri che oltre ad aver prodotto codice sicuro, non si vada ad incappare in vulnerabilità prodotte da queste risorse? I reparti che si occupano di sicurezza come possono controllare e validare grandi moli di lavoro senza diventare colli di bottiglia che rallentano la "produzione"?

Snyk risponde a queste esigenze, andandosi ad inserire ad esempio in IDE, repository git o pipeline CI/CD e riuscendo a fornire risposte rapide ed efficaci.

Ad esempio Snyk è in grado di aprire pull request dopo scansioni su repository git in modo automatico, andando ad evidenziare le vulnerabilità e proponendo una soluzione.

Per venire incontro alle esigenze degli uffici sicurezza, queste funzionalità sono configurabili centralmente tramite policy che allineano il comportamento dei tools alle specifiche esigenze e è possibile avere report e dashboard per capire rapidamente lo stato della sicurezza dei vari progetti.

Snyk inoltre ha generato il proprio db delle vulnerabilità, che oltre a catalogare i CVE con le varie severity, fornisce quando possibile, esempi e suggerimenti per i developers.

Provarlo è semplice perchè è stato previsto un piano limitato gratuito!


Vi lascio inoltre il link all'articolo pubblicato dal mio collega Luca Bandini che racconta la nostra esperienza con Snyk, utilizzato anche per controllare il codice di Fury, la distrubuzione Kubernetes svilluppata da SIGHUP.


lunedì 21 novembre 2022

CyberArk Conjur follower, system error e reboot in fase di configurazione: come risolvere (verificare connettivita postgres in modo corretto)

Lavorando con CyberArk Conjur, mi sono trovato in una condizione anomala del comportamento dei follower, che ha necessitato di un pò di debug per venirne a capo.


I follower su Kubernetes erano in grado di contattare le API del nodo leader di Conjur in modo corretto, quindi si inizializzava la configurazione del follower, ma poi questa non finiva andando in un generico System Error e il pod del follower iniziava a riavviarsi.


Dopo alcune analisi abbiamo capito che il problema era lato network load balancer che esponeva la porta Postgres in modo non corretto.


In prima fase di troubleshooting avevamo verificato la connettività dal follower al leader tramite il comando nc. ma questo non è ovviamente sufficente perchè verifica la connettività TCP fra follower e loadbalancer.


Per vedere se in effetti la connettività Postgres può funzionare, è necessario utilizzare questo comando openssl:


echo "" | openssl s_client -starttls postgres -connect <lb_DNS>:5432 -showcerts



In caso di successo, fornisce il certificato del server. 
Ringrazio il supporto CyberArk per avercelo girato (noi avevamo fatto la verifica in altro modo meno elegante con stesso risultato). 

Per altre opzioni e spiegazioni aggiuntive sul comando  openssl s_client, vi rimando a questo blogpost che trovo ben fatto e completo.

venerdì 30 settembre 2022

CyberArk Vault Synchronizer - CASVM035E Vault name is missing , come risolvere

Una delle componenti di Cybeark Conjur è il Synchronizer che serve a ricevere i secrets dal Vault.

Nei giorni scorsi mi sono imbattuto in un CyberArk Vault Synchronizer 11.7 in stato di "abbandono" che necessitava comunque di un aggiornamento alla 12.7.


Dopo aver effettuato l'aggiornamento seguendo la documentazione, il servizio non partiva, con il seguente errore nei log


[5] [main] FATAL VaultConjurSynchronizer.Service.SynchronizerService - VCSS006F Failed to start CyberArk Vault-Conjur Synchronizer Service: CASVM035E Vault name is missing.


Da una ricerca nella documentazione si trovava l'errore della componente CASOS però riferita al Vault server e come internal error suggerisce di contattare il supporto.


Nel caso del Synchronizer, ho risolto valorizzando, all'interno del file

C:\Program Files\CyberArk\Synchronizer\VaultConjurSynchronizer.exe.config


il valore di INTEGRATION_VAULT_NAME. con il nome del vault present all'interno del vault.ini .


una volta valorizzato il servizio è partito correttamente.

mercoledì 21 settembre 2022

CyberArk Impact 2022 world tour, io ci sarò e tu?

Come probabilmente già sapete CyberArk ha un grande evento annuale chiamato Impact, che quest'anno è stato organizzato a Boston.

Durante le scorse settimane CyberArk ha annunciato una importante iniziativa, chiamata Impact world tour che porterà la conferenza, in diverse città, in tutto il mondo!

Se siete interessanti, in questa pagina potete trovare:

  • elenco delle città e delle date
  • agenda
  • registration form


Io sarò presente alla data di Milano 11 Ottobre 2022.

Sono contento dell'opportunità di poter incontrare le persone di CyberArk di persona e di poter assistere ad interessanti sessioni dal vivo: a presto ! 

venerdì 5 agosto 2022

CyberArk Conjur , authenticators e integrazioni

Nei precedenti blogpost vi ho parlato di cosa è un secrets manager (e del motivo per cui  dovreste averne la necessità) ed ho fatto una overview dell'architettura di Conjur e dei suoi system requirements.


Un secrets manager non può fare il suo lavoro se non può parlare con chi ha bisogno di chiedergli i segreti ed è qui che arriva la "magia" di Conjur, gli "authenticator" a cui Conjur demanda le sue funzionalità di autenticazione. 


Questa che vi metto qui sotto  la lista "grezza" degli authenticators disponibili:

authnDefines the Conjur default authenticator. Authentication for both users and hosts is based on an ID and API key. 
authn-oidcLeverages the identity layer provided by OIDC to allow applications to authenticate with Conjur and retrieve secrets needed for connecting to services such as a database.
authn-iamEnables an AWS resource to use its AWS IAM role to authenticate with Conjur.

authn-azure

Enables an Azure resource to authenticate with Conjur

authn-jwt

Enables an application to authenticate to Conjur using a JWT from a JWT Provider.

authn-gcp

Enables a Google Cloud Platform resource to authenticate with Conjur

authn-k8sAuthenticates hosts that are Kubernetes resources, such as a Kubernetes namespace, deployment, stateful set, and others. Authentication is certificate-based using a mutual TLS connection.
authn-ldapAuthenticates users based on an LDAP directory.

come si può intuire Conjur è integrabile nativamente con molte delle tecnologie moderne che potete utilizzare a vostro piacimento , per gestirne i secrets in modo sicuro!

Di default dopo l'installazione di Conjur, l'unico authenticator attivo è authn che è in grado di fornire accesso a Conjur ed ai suoi secrets tramite username o API key (generate random fra i 51 e 56 caratteri). 

Se però ad esempio dovete però fornire accesso ad applicazioni che risiedono su un cluster Kubernetes attivando authn-k8s potete farlo in modo sicuro tramite una connessione sicura stabilita in mTLS , utilizzando Spiffie secondo lo schema sottostante (qui per approfondire) :


analogamente a quanto fatto per Kubernetes se poi doveste aver la necessità di integrare un identità di qualunque tipo ( ad esempio Google Apigee ) potete ricorrere all'authenticator authn-jwt che lavora come descritto qui secondo lo schema sottostante: 




Come potete capire dalla lista sopra degli authenticator , le possibilità che ha Conjur di servire la vostra applicazione o meglio identità verificata in modo sicuro coprono praticamente la totalità dei casi possibili.

Quindi se  dovete quindi fornire secrets in una o più dei seguenti esempi 

  • Kubernetes (locali o cloud) 
  • API gateway
  • Jenkins
  • Ansible
  • Puppet
  • Terraform
  • Cloud services
in modo sicuro e nativo non potete che considerare Conjur rivolgendovi a CyberArk o al vostro partner CyberArk di riferimento.

domenica 24 luglio 2022

CyberArk Conjur - panoramica su system requirements e architettura

Continua la serie su CyberArk Conjur, nel post precedente ho spiegato a cosa serve un secrets manager enterprise, in questo post parlerò di architettura e system requirements. 

Conjur è disponibile in versione Enterprise, opensource (chiamata OSS) ed a breve lo sarà anche in versione cloud in soluzione SAAS.

I miei post fanno riferimento alla versione enterprise, che è comunque molto simile alla OSS.

Architettura

Conjur è distribuito come appliance in forma di docker image, quindi il suo setup dell'infrastruttura risulta semplice e veloce.

Questi sono i componenti principali dell'appliance: 

  • nginx   - garantisce l'accesso web per GUI amministrativa e API per fruizione secrets
  • postgres database - contiene tutti i dati di conjur, secrets e policies. Inoltre c'è un secondo db per. i log funzionali e di audit
  • conjur appliance - il prodotto 
  • syslog-ng - viene utilizzato per collezionare log e audit di funzionamento

La configurazione minima tipica in ambito enterprise è di 3 nodi, configurati in cluster con auto-failover:


Il funzionamento del cluster come si può intuire dalla figura, è active-passive e si basa su un nodo principale , "leader", che eroga i servizi mantiene i db in read write e fornisce accesso tramite API rest ai secrets. 

Oltre al leader vengono tipicamente installati 2 o più nodi inattivi, chiamati "standby", che possono essere sync o async . 

I dati sono replicati fra i vari nodi sfruttando la postgres replication.

In caso di fail del nodo principale , viene eseguita la promozione di un nodo Standby utilizzando etcd e Raft consensus algorithm ed il load balancer garantirà l'accesso al nuovo nodo leader.

In caso il cluster non sia configurato con una policy di auto-failover, va eseguita una promozione manuale di un altro nodo. 

E' possibile avere ad esempio una configurazione con un site primario in auto-failover ed un nodo di disaster recovery con standbys async da promuovere manualmente in caso di necessità.


Oltre ai nodi che costituiscono il cluster, esiste la possibilità di installare dei nodi passivi chiamati follower, che possiedono una replica dei db in read-only e garantiscono accesso ai secrets alle applicazioni. 

Un caso tipico di utilizzo di un follower è su un cluster Kubernetes, dove viene installato garantire la minor latenza possibile nella risposta alle applicazioni locali.


L'architettura finale quindi aggiungendo follower e applicazioni al disegno sopra diventa qualcosa di simile al seguente: 



System requirements

La configurazione suggerita per i nodi di produzione è la seguente: 

  • 4 core
  • 8 GB ram
  • 50 GB hd
Per un ambiente di dev/test
  • 2 core
  • 4 GB ram
  • 20 GB hd
per quanto riguarda il container runtime sono supportati  i seguenti

  • docker 1.13 or later
  • Mirantis Container runtime (MRC) 19.x, 20.10 su RHEL 8.x
  • Kubernetes e Openshift ( solo per i follower ) 
  • podman 3.3 e 3.4 
mentre OS host deve essere uno di quelli supportati dai container runtime (tipicamente RHEL e derivate o Ubuntu server LTS) .

Nel caso in cui disponiate di un server CyberArk Vault e vogliate sincronizzare i secrets verso Conjur per espanderne l'adozione , è necessario installare un server per il componente Vault Synchronizer  
  • 4 core
  • 8 GB ram
  • OS Windows 2012 R2 o superiore

martedì 19 luglio 2022

CyberArk Conjur , alcuni motivi per cui un enterprise secrets manager deve essere adottato

Quando ci si occupa di security , uno dei temi che non si possono ignorare è la gestione dei secrets , tema che può impattare a 360° il destino di un azienda.

Per secrets ad esempio possiamo considerare ad esempio:

  • username
  • database passwords
  • SSL certificates e keys
  • SSH Keys
  • credenziali cloud

potete capire quindi che la gestione di questi dati diventa fondamentale per salvaguardare sicurezza , funzionamento e reputazione.

Alcuni dei problemi di gestione più diffusi dei secrets includono :
  • hardcoded secrets nel codice
  • data-breach
  • password leak
  • secrets presenti in repository pubblici
un secrets non gestito in modo corretto grazie a fenomeni come lateral movement, può portare a danni importanti.
 

Per poter gestire al meglio i secrets è necessario rivolgersi ad un secrets manager ed una delle possibili soluzioni è CyberArk Conjur.

Conjur , grazie ad un set di API rest è programmabile ed accessible tramite URL.
La sicurezza garantita da policy, rende disponibile l'accesso ai secrets in modo rapido e semplice per i developers, senza renderli partecipi in modo diretto del valore dei secrets coinvolti nel loro codice.

La sicurezza aziendale può essere migliorata tramite la rotazione automatica dei secrets utilizzando i rotators, ed ovviamente si integra alla perfezione con gli altri componenti dell'ecosistema di Cyberark come il Pas Vault, rendendo la sicurezza garantita da Cyberark  anche al mondo Cloud Native.

Conjur è disponibile in 2 versioni, una enterprise ed una opensource che si differenziano in alcune funzionalità

Questo post vuole essere una introduzione al tema e nei prossimi post vi parlerò di requisiti, architettura (semplice e veloce grazie al rilascio sw come container images) e sulle modalità di accesso ai secrets.