Contatta il reparto vendite 800 13.40.41 | Richiedi il Supporto Partner

Articoli

Icona delle News




Vuoi che la tua sicurezza sia costruita su scuse?

rischi e misure di sicurezza

14/07/21 CoreTech Blog

Opinione: Lasci le chiavi della macchina nel quadro solo perché è più facile che mettere in sicurezza il tuo veicolo? In caso contrario, perché ti vengono in mente scuse simili quando prendi decisioni sulla sicurezza dei tuoi dati sensibili e sulla reputazione della tua azienda?

Nel mondo della sicurezza informatica, è naturale bilanciare rischi e misure di sicurezza. Dopotutto, non c'è modo di ottenere una sicurezza assoluta e quindi devi dire fermati da qualche parte. Tuttavia, se ti affidi alle scuse e sottovaluti le minacce, è molto probabile che tu diventi vittima di un attacco serio. I criminali informatici sono intelligenti: attaccano coloro che rendono loro le cose facili.

Ho visto le aziende trattare la sicurezza delle applicazioni web come meno importante, ad esempio, di avere un antivirus. Posso capire un tale approccio se un'azienda ha solo un semplice sito di marketing su WordPress. Tuttavia, non riesco a capire una tale disattenzione se l'azienda sviluppa applicazioni Web B2B professionali per grandi aziende, che utilizzano queste applicazioni Web per elaborare tonnellate di informazioni sensibili! Eppure, sì, succede!

Ecco alcune delle scuse che ho sentito quando si tratta di sicurezza delle applicazioni web. Li sto includendo per aiutarti a evitare insidie ​​simili quando decidi come procedere con il tuo viaggio.

"Il nostro software è solo per uso interno, quindi non c'è rischio di attacco"

Il presupposto che gli hacker malintenzionati attacchino solo le applicazioni web che sono esposte al pubblico è uno dei motivi principali delle principali violazioni dei dati. Non solo i lavori interni sono abbastanza comuni nel mondo della sicurezza informatica, ma gli aggressori possono trovare un modo per entrare nella rete interna e accedere da lì alle applicazioni web interne.

Dovresti sempre trattare la sicurezza delle tue applicazioni web allo stesso modo, indipendentemente dal fatto che siano esposte al pubblico, utilizzate solo tramite reti interne e VPN o protette da filtro IP e autenticazione. Ciò significa che, ad esempio, se la tua applicazione è accessibile solo da un intervallo selezionato di IP e richiede l'autenticazione, non significa che sia sicura in base alla progettazione. Ancora peggio, i criminali possono effettivamente cercare di accedere a tali applicazioni, in particolare, sapendo che i loro creatori spesso trattano le vulnerabilità come una minaccia minore e quindi non le controllano nemmeno.

In conclusione, scansiona ogni applicazione alla ricerca di vulnerabilità di sicurezza, non importa quanto bene sia protetta dalle misure di sicurezza e dall'autenticazione della rete!

“La nostra implementazione rende impossibile avere vulnerabilità”

Ho sentito questo argomento da un'azienda, che utilizza Hibernate ORM per il suo sviluppo Java. La costruzione di Hibernate elimina presumibilmente le vulnerabilità di SQL injection perché il database restituisce sempre un singolo set di risultati. Sfortunatamente, non è vero. Solo alcuni attacchi SQL injection vengono eliminati da questa funzionalità di Hibernate, ma non tutti. Questa funzionalità inoltre non ha alcun impatto sulle vulnerabilità che non sono correlate a SQL.

Sebbene i moderni ambienti di sviluppo e implementazione rendano più difficili alcuni attacchi, non esiste un ambiente che possa aiutarti a prevenirli tutti o anche la maggior parte di essi. Se pensi che il modo in cui hai progettato lo sviluppo e l'implementazione sia sufficiente senza alcun test di sicurezza incluso, ripensaci.

In conclusione, testa tutte le tue applicazioni per le vulnerabilità della sicurezza, indipendentemente dagli ambienti di sviluppo e implementazione che utilizzi (anche se presumibilmente eliminano gli errori di sicurezza).

"Eseguiamo una scansione di sicurezza di tanto in tanto e non abbiamo mai trovato nulla di serio"

Alcune aziende ritengono che sia sufficiente eseguire la scansione delle proprie applicazioni ogni pochi mesi, ad esempio solo prima di una versione principale. Non vedono la necessità di verificare la sicurezza di ogni release candidate e sono ancora meno desiderosi di includere la scansione della sicurezza come parte delle loro normali pipeline DevOps. L'argomento è che le scansioni non hanno prodotto grossi problemi fino ad oggi.

Un simile approccio può essere paragonato a lasciare la portiera dell'auto aperta (e le chiavi nell'accensione) di fronte al supermercato. Certo, nella maggior parte dei casi non succederà nulla perché non ci saranno ladri d'auto in giro. Tuttavia, se solo un ladro è in giro e nota che la tua auto non è chiusa a chiave, il tuo veicolo cambierà proprietario abbastanza rapidamente. Lo stesso in questo caso: solo una vulnerabilità importante che non viene rilevata tra le versioni principali può comportare una violazione della sicurezza che espone tutti i tuoi dati sensibili e rovina la reputazione della tua azienda.

In conclusione, testate le vostre applicazioni presumibilmente sicure in modo ancora più approfondito di quelle che pensereste non sicure.

Meglio prevenire che curare

La frase "meglio prevenire che curare" è molto applicabile alla sicurezza informatica (e alla sicurezza in generale). A mio parere, qualunque decisione tu prenda in materia di sicurezza per la tua attività, dovresti confrontarla con la sicurezza delle tue risorse personali. Ad esempio, se il tuo appartamento si trova in un condominio con la sicurezza alla porta d'ingresso, significa che puoi lasciare la porta aperta? Se di recente non si è verificata alcuna intrusione nel tuo quartiere, significa che puoi lasciare la finestra spalancata quando vai al lavoro?

Se invece di cercare scuse provi a ipotizzare gli scenari peggiori, è molto meno probabile che tu sia l'eroe della prossima notizia principale su una violazione dei dati.

Banner

Articoli su Sicurezza

La cattiva comunicazione è al centro delle sfide di AppSecImpostazione e raggiungimento degli obiettivi di sicurezza delle applicazioniMetriche di sicurezza informatica per le applicazioni WebCome evitare attacchi alla supply chainPerché la maggior parte delle misure di sicurezza delle applicazioni fallisceVuoi che la tua sicurezza sia costruita su scuse?Cos'è SCA e perché ne hai bisognoLa scansione ad hoc non è sufficienteEsposizione dei dati sensibili: come si verificano le violazioniHai paura dei test di sicurezza nell'SDLC?Vantaggi di Web Asset DiscoveryStrumenti di scansione delle vulnerabilità: perché non open source?Protezione WAF - Ottieni il massimo dal tuo firewall per applicazioni webL'errore di comunicazione è al centro delle sfide di AppSecDebugger remoti come vettore di attaccoDAST è una parte essenziale di un programma completo per la sicurezza delle applicazioniCome difendersi dagli attacchi recenti su Microsoft Exchange5 principali vantaggi dei primi test di sicurezzaTecniche di attacco Denial-of-Service con avvelenamento della cacheQuali principali attacchi web possiamo aspettarci nella nuova top 10 di OWASP?Hack di SolarWindsPillole di Sicurezza | Episodio 38Pillole di Sicurezza | Episodio 37Perché gli sviluppatori evitano la sicurezza e cosa puoi fare al riguardoPillole di Sicurezza | Episodio 36Cos'è l'attacco RUDYCos'è la navigazione forzataCome gli scanner trovano le vulnerabilitàPillole di Sicurezza | Episodio 34Pillole di Sicurezza | Episodio 35Come eseguire il benchmark di uno scanner di vulnerabilità Web?Pillole di Sicurezza | Episodio 33Pillole di Sicurezza | Episodio 325 proposte di vendita comuni sulla sicurezza delle applicazioni web5 motivi per non fare affidamento sui programmi BountyPillole di Sicurezza | Episodio 315 motivi per cui la sicurezza web è importante quanto la sicurezza degli endpointPillole di Sicurezza | Episodio 305 motivi per cui la sicurezza web è importante per evitare il ransomwarePillole di Sicurezza | Episodio 293 motivi per cui DAST è il migliore per la sicurezza delle applicazioni WebPillole di Sicurezza | Episodio 28Pillole di Sicurezza | Episodio 27Pillole di Sicurezza | Episodio 24Pillole di Sicurezza | Episodio 25Pillole di Sicurezza | Episodio 21Pillole di Sicurezza | Episodio 22Pillole di Sicurezza | Episodio 20Pillole di Sicurezza | Episodio 17Il flag HttpOnly: protezione dei cookie da XSSPillole di Sicurezza | Episodio 16Il Bug Heartbleed – I vecchi Bug sono duri a morirePillole di Sicurezza | Episodio 15Pillole di Sicurezza | Episodio 14Pillole di Sicurezza | Episodio 13Pillole di Sicurezza | Episodio 12Pillole di Sicurezza | Episodio 11Pillole di Sicurezza | Episodio 10Sicurezza delle reti: gli hacker puntano CitrixCyber hacking: la Germania chiede l’intervento dell’UESicurezza informatica: Cisco rilascia aggiornamentiOcchio al cryptojacking: malware infiltrato in Docker HubSIGRed: bug di sistema in Windows Server scovato dopo 17 anniPillole di Sicurezza | Episodio 9Summit Live - Disponibili le registrazioni delle live di MonteleoneCriminalità informatica: Schmersal sventa un cyber-attaccoPillole di Sicurezza | Episodio 8Pillole di Sicurezza | Episodio 7Analisi pratica dei rischi per il SysAdmin, DevOps e Dev | Summit LivePillole di Sicurezza | Episodio 6Pillole di Sicurezza | Episodio 5Pillole di Sicurezza | Episodio 4Pillole di Sicurezza | Episodio 3Pillole di Sicurezza | Episodio 2Pillole di Sicurezza | Episodio 1Pillole di Sicurezza | Episodio 23
Ripe Ncc Member
vmware
CloudLinux
Plesk
HP
Microsoft