Sono state identificate due vulnerabilità in alcuni modelli di router Asus che, qualora venissero sfruttate, potrebbero consentire agli attori delle minacce di eludere il sistema di autenticazione ed eseguire codice dannoso sui dispositivi sensibili per prenderne il controllo. Ecco come mitigarle

L'articolo Vulnerabilità nei router Asus consente di prendere il controllo dei dispositivi: i dettagli proviene da Cyber Security 360.

La NIS 2 introduce un innovativo quadro di vigilanza, affidato alle autorità competenti, differenziato per garantire un elevato livello di cibersicurezza, stabilendo un regime di controllo completo per i soggetti essenziali e un approccio più leggero e reattivo per i soggetti importanti. Ecco le misure reattive e proattive da adottare per prepararsi efficacemente

L'articolo NIS 2: come adottare una procedura per affrontare efficacemente le azioni di vigilanza proviene da Cyber Security 360.

Nell'era digitale, la cyber security è un pilastro imprescindibile per affrontare minacce sempre più sofisticate e implementare politiche di sicurezza robuste e complete. Sono le sfide che i leader del G7 si impegnano ad affrontare per rafforzare la cyber resilienza collettiva grazie al nuovo gruppo di lavoro cyber. I punti cardine

L'articolo Cyber security, dal G7 l’impegno per un cyberspazio aperto, resiliente e sicuro proviene da Cyber Security 360.

Uno studio condotto da scienziati della New York University mette in dubbio l’influenza di Internet sui valori morali della società. Gli autori sostengono che qualità umane innate come la compassione e la sete di giustizia sono gravemente distorte nel mondo online.

Come spiegano Claire Robertson e i suoi colleghi, i nostri valori morali si sono storicamente sviluppati in piccole comunità dove le persone interagivano faccia a faccia. Nell’era moderna, Internet unisce più di 5 miliardi di utenti in tutto il mondo. Gli autori dello studio sostengono che la tecnologia ha creato un ecosistema completamente nuovo, spesso incompatibile con i modelli comportamentali innati che gli esseri umani hanno sviluppato durante l’evoluzione.

I ricercatori spiegano che il flusso illimitato di contenuti scioccanti e di notizie 24 ore su 24 su Internet espone le persone a potenti incentivi morali. La mente umana alla fine si stanca delle preoccupazioni, della cancellazione della cultura, delle proteste collettive e dei falsi moralismi.

La “fatica da compassione” si sviluppa quando la nostra limitata capacità di empatia viene esaurita dal costante assalto di informazioni. E la vergogna pubblica e il bullismo prosperano perché molti si sentono impuniti online.

Inoltre, gli autori notano che è molto facile organizzare movimenti e campagne sociali di massa su Internet. Tuttavia, la maggior parte di queste iniziative si rivelano fugaci, di breve durata e inutili poiché mancano di un supporto reale e di una solida base nel mondo offline.

Lo studio dice anche che spesso, invece di fornire un aiuto concreto alle persone in difficoltà, gli utenti si limitano a vuoti gesti simbolici come i like e i repost sui social network. Queste azioni non cambiano nulla nella pratica, ma creano in una persona l’illusione di aver adempiuto al suo dovere sociale e di aver aiutato i bisognosi.

Al termine del loro studio, gli scienziati chiedono uno studio approfondito delle politiche e dei miglioramenti nell’interfaccia delle piattaforme Internet, dei social network e di altri servizi online al fine di ridurre al minimo il loro impatto negativo sui fondamenti morali della società.

Inoltre, gli autori insistono sul fatto che gli algoritmi con cui operano i social network dovrebbero diventare più trasparenti e aperti al pubblico. Ciò consentirà agli scienziati di comprendere meglio esattamente come Internet e i social network influenzano i valori morali e il comportamento delle persone, al fine di trovare ulteriormente modi per risolvere i problemi psicologici emergenti.

L'articolo Una Verità Scomoda: Internet Sta Disturbando i Nostri Valori Morali proviene da il blog della sicurezza informatica.

Although it’s generally accepted that synthesized voices which mimic real people’s voices (so-called ‘deepfakes’) can be pretty convincing, what does our brain really think of these mimicry attempts? To answer this question, researchers at the University of Zurich put a number of volunteers into fMRI scanners, allowing them to observe how their brains would react to real and a synthesized voices. The perhaps somewhat surprising finding is that the human brain shows differences in two brain regions depending on whether it’s hearing a real or fake voice, meaning that on some level we are aware of the fact that we are listening to a deepfake.

The detailed findings by [Claudia Roswandowitz] and colleagues are published in Communications Biology. For the study, 25 volunteers were asked to accept or reject the voice samples they heard as being natural or synthesized, as well as perform identity matching with the supposed speaker. The natural voices came from four male (German) speakers, whose voices were also used to train the synthesis model with. Not only did identity matching performance crater with the synthesized voices, the resulting fMRI scans showed very different brain activity depending on whether it was the natural or synthesized voice.

One of these regions was the auditory cortex, which clearly indicates that there were acoustic differences between the natural and fake voice, the other was the nucleus accumbens (NAcc). This part of the basal forebrain is involved in the cognitive processing of e.g. motivation, reward and reinforcement learning, which plays a key role in social, maternal and addictive behavior. Overall, the deepfake voices are characterized by acoustic imperfections, and do not elicit the same sense of recognition (and thus reward sensation) as natural voices do.

Until deepfake voices can be made much better, it would appear that we are still safe, for now.

Iniziamo oggi una nuova serie di articoli che esplorerà il mondo della sicurezza informatica da una prospettiva unica e completa, combinando entrambi i lati della sicurezza: il Red Team e il Blue Team. Questo approccio, comunemente noto come “Purple Team”, integra le tecniche offensive e difensive per fornire una comprensione olistica delle minacce e delle soluzioni di sicurezza.

Nel primo articolo della serie, vi guideremo attraverso il processo di creazione di un Security Operations Center (SOC) domestico con un budget di circa 100 euro. Sfruttando un miniPC dotato di 16 GB di RAM e un SSD esterno ad alta velocità, costruiremo un ambiente completo e funzionale per monitorare, analizzare e rispondere alle minacce.

Componenti del SOC Domestico

Il nostro SOC sarà composto da una serie di strumenti open-source potenti e versatili, integrati tra loro per offrire una soluzione di sicurezza completa. Ecco i componenti chiave:

1. Wazuh integrato con VirusTotal: per la gestione delle informazioni di sicurezza e la rilevazione delle minacce in tempo reale.
2. Shuffle: una piattaforma SOAR (Security Orchestration, Automation, and Response) per automatizzare i processi di risposta agli incidenti.
3. Cortex: per la raccolta e l’analisi dell’intelligence di sicurezza.
4. The Hive: per il management dei casi e la collaborazione tra team (voi e voi stessi in questo caso).

Panoramica del Laboratorio

Per mettere alla prova il nostro SOC, creeremo una rete di test che includerà:

• Un container Ubuntu con Atomic Red Canary per simulare diversi tipi di attacchi basati sul framework MITRE ATT&CK.
• Due macchine Kali Linux: una all’interno della rete AD e una all’esterno, per eseguire attacchi manuali e testare le vulnerabilità da diverse prospettive.
• Un dominio Active Directory con un Domain Controller Windows Server 2019 e due membri del dominio Windows 10.

Abbiamo configurato il nostro laboratorio utilizzando Proxmox, una potente piattaforma di virtualizzazione open-source. La scelta di Proxmox è motivata dalla sua capacità di ottenere molto più di quanto sia possibile con macchine virtuali gestite in un ambiente di virtualizzazione di livello due, utilizzando anche hardware mediocre.

Differenze tra Livelli di Virtualizzazione

• Virtualizzazione di Livello Uno (Bare-Metal Hypervisor): In questo modello, l’hypervisor viene installato direttamente sull’hardware fisico, senza la necessità di un sistema operativo host. Questo tipo di virtualizzazione offre prestazioni quasi native, elevata efficienza e minore overhead. Esempi includono VMware ESXi, Microsoft Hyper-V e Proxmox VE.
• Virtualizzazione di Livello Due (Hosted Hypervisor): In questo modello, l’hypervisor viene eseguito sopra un sistema operativo host. Questo tipo di virtualizzazione è più facile da configurare ma comporta un maggiore overhead e prestazioni inferiori rispetto alla virtualizzazione di livello uno. Esempi includono VirtualBox e VMware Workstation.

Utilizzando Proxmox, possiamo gestire efficientemente diverse macchine virtuali e container con risorse hardware limitate, ottenendo prestazioni elevate grazie alla virtualizzazione di livello uno. Di seguito sono riportati alcuni screenshot che mostrano la configurazione del nostro ambiente di test:

Nella schermata sopra, è possibile vedere l’elenco delle macchine virtuali e dei container configurati nel nostro SOC. Ogni componente è etichettato chiaramente per facilitarne l’identificazione e la gestione.

La schermata delle risorse del sistema ci mostra l’utilizzo della CPU, della memoria e dello storage del nostro miniPC. Come si può notare, il nostro sistema è configurato per ottimizzare l’uso delle risorse disponibili, garantendo prestazioni efficienti. Come vediamo qui sopra abbiamo al momento attivi:

• 2 Containers Kali (uno interno alla rete di Active Directory ed uno al suo esterno)
• 2 Macchine Ubuntu Server (che non si sa mai uno non basti)
• 2 Macchine Windows di cui un Server – Domain Controller ed un Client “Batman” (più avanti , nella sezione dedicata agli attacchi ad Active Directory scopriremo che il suo local admin si chiama Bruce Wayne )

Prossimi Articoli

Nei prossimi articoli, esploreremo vari tipi di attacchi che possiamo lanciare contro questa rete e analizzeremo le tecniche di difesa implementate dal nostro SOC. Esamineremo in dettaglio sia le strategie del Red Team per compromettere la sicurezza dei sistemi, sia le tattiche del Blue Team per rilevare, mitigare e rispondere agli incidenti.

Conclusione

La costruzione di un SOC domestico non solo è una sfida interessante ma anche un modo eccellente per migliorare le proprie competenze in sicurezza informatica. Con un investimento minimo, possiamo creare un laboratorio avanzato che ci permetterà di esplorare e comprendere meglio le dinamiche di attacco e difesa.

Rimanete sintonizzati su RedHotCyber.com per il prossimo articolo della serie, dove una volta completata l’installazione degli altri componenti (Shuffle, The Hive e Cortex) costruiremo un SOC che non ha nulla da invidiare a quelli professionali ed un ambiente di test veramente completo.

L'articolo Costruiamo un “SOC domestico” con soli 100 Euro proviene da il blog della sicurezza informatica.

Gestire le integrazioni, l’implementazione, la scalabilità e tutti quegli aspetti che rendono i progetti di Machine Learning un prodotto reale è un lavoro a sé stante. C’è un motivo per cui esistono diverse posizioni lavorative che vanno dal data scientist, al Machine Learning Engineer e al MLOps expert.

Tuttavia, anche se non è necessario essere esperti di questi argomenti, è bene conoscere alcune regole fondamentali e ben definite che possono aiutarvi quando avviate un progetto. In questo articolo, illustro delle best practice di sviluppo che uso, cercando un tradeoff tra la qualità del codice e il tempo investito per implementarle.

Iniziare in modo semplice – Readme

Può sembrare banale, ma cercate di mantenere un file Readme più o meno aggiornato. Se non ci mettete troppo tempo e vi piace farlo, cercate anche di creare un Readme che sia gradevole alla lettura in senso estetico. Includete icone, immagini o altro. Questo file deve essere chiaro e comprensibile. Ricordate che in un progetto reale non lavorerete solo con altri sviluppatori, ma anche con venditori e project manager, e di tanto in tanto potrebbero dover leggere il Readme per capire su cosa state lavorando.

Qui potete trovare un template di un readme molto interessante!

Usate gli ambienti virtuali, il vostro portatile ne sarà felice

Probabilmente lo sapete meglio di me: per sviluppare un progetto di qualità abbiamo spesso bisogno di librerie esterne. Queste librerie possono avere dipendenze o conflitti.

Ecco perché è una buona idea creare ambienti virtuali. Un ambiente virtuale aiuta ad avere progetti isolati l’uno dall’altro, ad avere ambienti di sviluppo completamente diversi.
Di solito, per fare questo in Python si usa pip o conda.

Personalmente sono un fan di pip. Ecco come creare e attivare un ambiente virtuale.

#create virtual env
python3 -m venv .venv

#activate virtual env
source .venv/bin/activate

Ora potete installare tutte le librerie che desiderate!

Creare un file di requisiti, i vostri colleghi saranno contenti

Non ha senso scrivere codice, soprattutto in un campo come quello del Machine Learning, se non si consente la riproducibilità del medesimo e degli esperimenti. Il punto di partenza è sicuramente la creazione di un file requirements.txt.

Non posso eseguire il codice scritto da qualcun altro se non so quali librerie ha installato per eseguire il codice. Per questo motivo, si dovrebbe tenere un file di testo chiamato requirements.txt in cui inserire i nomi di tutte le librerie. È possibile modificare questo file manualmente, cioè ogni volta che si installa una libreria con pip, si inserisce anche il nome della libreria nei requirements. Oppure si può usare un utile comando di pip, per inserire automaticamente tutte le librerie installate nell’ambiente virtuale direttamente nei requisiti. Vediamo come fare.

Se si esegue il seguente comando

pip freeze

si vedrà apparire nel terminale un elenco di tutte le librerie installate. A questo punto basta usare un trucchetto del terminale per reindirizzare l’output di questo comando al file requirements.txt invece che al display.

pip freeze > requirements.txt

Se controllate ora i vostri requirements, vedrete che sono stati aggiornati automaticamente!

Se si desidera installare automaticamente tutti i requirements in un nuovo ambiente virtuale, è possibile eseguire il seguente comando:

pip intall -r requirements.txt

Formattare il codice con Black

Molte delle librerie di cui parlo questo articolo fanno molto di più di quello che ho descritto. Ma come ho anticipato, il mio scopo è solo quello di avere una sorta di routine da seguire quando sviluppo.

Uso Black per formattare il codice in modo chiaro e ordinato. Ecco il comando da usare per eseguire Black:

find src -name '*.py' -exec black {} +

Nel comando, abbiamo specificato di modificare tutti i file python (*.py) all’interno della cartella src.

Analizzare il codice con PyLint

PyLint è un’altra libreria estremamente utile che vi consiglio di iniziare a usare.

PyLint controlla automaticamente la presenza di errori nel codice, impone l’uso di standard e verifica anche la presenza di codice non ottimizzato, come ad esempio degli import che non sono mai stati utilizzati. PyLint assegna anche un punteggio da 1 a 10 alla qualità del codice.

pylint --disable=R,C src/*.py

Noterete che ho modificato il comando, disabilitando due flag (R e C). In questo modo, PyLint non emetterà avvisi o segnalazioni per problemi legati al refactoring e alle convenzioni.

L’output dovrebbe apparire come questo:

Eseguire i test per assicurarsi che il codice funzioni

Come fate a sapere che il vostro codice funziona sempre se non usate i test? Prendete l’abitudine di creare semplici unit test, che potete sempre estendere quando scrivete qualche funzione. Uno unit test non è altro che una funzione che passa una sequenza di input alla funzione che si vuole testare e vede se l’output è quello previsto.

È possibile implementare degli unit test in diversi modi; una libreria molto utilizzata in Python è PyTest.

Di solito creo una cartella sorella di src, chiamata test, in cui raccolgo tutti i miei unit test.Per lanciare tutti i test in modo automatico, potete eseguire il seguente comando:

python -m pytest -vv --cov=test

Sono pigro, userò un Makefile

A questo punto, abbiamo visto molti file e molti comandi da terminale. Direi che utilizzare queste best practice come routine è un po’ pesante. Vorrei qualcosa di più semplice. Personalmente non ho un’ottima memoria per ricordarmi tutti questi step 😅.

Bene, allora possiamo creare un Makefile, che è un file in cui scriviamo alcune istruzioni, e questo lancerà i comandi visti in precedenza per noi. Nel Makefile voglio scrivere le istruzioni per installare i requisiti, formattare il codice con black, controllare gli errori del codice con PyLint e lanciare i test con PyTest. Ecco quindi come è fatto un Makefile:

install:
#install
pip install --upgrade pip&&\
pip install -r requirements.txt
format:
#format
find src -name '*.py' -exec black {} +
lint:
#lint
pylint --disable=R,C src/*.py
test:
#test
python -m pytest -vv --cov=test

In questo modo, ogni volta che si utilizza questo comando dal terminale:

make test

Verrà effettivamente eseguito:

python -m pytest -vv --cov=test

E la stessa cosa vale per tutti gli altri comandi in modo simile. Ora la nostra repo ha già un aspetto molto più professionale!

Eseguire tutto a ogni push con le GitHub Actions

Spero che tutto sia chiaro finora. A questo punto, ogni volta che vogliamo apportare modifiche al nostro codice prima di eseguire il commit e il push su GitHub, eseguiamo i seguenti comandi per assicurarci che tutto funzioni nel modo più fluido possibile: make install, make format, make lint, make test.

Ma agli sviluppatori piace automatizzare tutto. Quindi, non c’è un modo per eseguire automaticamente l’intero processo su ogni push di git? Ebbene sì, esiste, basta utilizzare GitHub Actions!

Con le GitHub actions, possiamo impostare i trigger, cioè specificare gli eventi che attiveranno i comandi, e i comandi nel nostro caso sono tutti nel Makefile.

Per creare le GitHub actions, dobbiamo creare la cartella .github/workflows nella nostra directory di lavoro. All’interno di questa nuova cartella, creiamo un file YML che possiamo chiamare, per esempio, mlops.yml.

In questo file possiamo specificare diverse cose. Innanzitutto, un nome a piacere.

Poi, specifichiamo l’evento (o gli eventi) che attiveranno i comandi, in questo caso [push]. Poi, ci occupiamo dei passi (di cui la prima parte non ricordo nemmeno esattamente cosa sia, ma per fortuna ci sono Google e ChatGPT da cui possiamo copiare e incollare 😅).

name: Python application with Github Actions

on:
[push]jobs:
build:
runs-on: ubuntu-latest

steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v4
with:
python-version: "3.10"

- name: Install dependencies
run: |
make install

- name: Lint with pyLint
run: |
make lint

- name: Test with pytest
run: |
make test

- name: Format code
run: |
make format

- name: Build container
run: |
make build

Questa dovrebbe essere la struttura del codice dell’intero progetto.

-.github/workflows
- mlops.yml
-.venv
-src
-test
-requirements.txt
-Makefile
-Readme.md

Ecco fatto!

Ora dovreste essere in grado di controllare su GitHub tutti i comandi in esecuzione a ogni push nella tab “actions”.

Conclusioni

In questo articolo vi ho mostrato alcune best practice che utilizzo quando sviluppo progetti in Python per garantire una certa qualità del codice e proteggere il mio repository GitHub da commit poco funzionali. Ognuno di questi argomenti può ancora essere approfondito enormemente, ma essere in grado di strutturare almeno in parte il proprio codice in modo rapido e semplice credo possa essere di grande aiuto per migliorare il proprio lavoro!

💼 Linkedin ️| 🐦 Twitter | 💻 Website

L'articolo Best Practice per Progetti di Machine Learning di Successo proviene da il blog della sicurezza informatica.

This is the Central Scrutinizer...
It is my responsibility to enforce all the laws
That haven't been passed yet
It is also my responsibility to alert each
And every one of you to the potential consequences
Of various ordinary everyday activities
You might be performing which could eventually lead to
The Death Penalty (or affect your parents' credit rating)
Our criminal institutions are full of little creeps
Like you who do wrong things...
And many of them were driven to these crimes
By a horrible force called music!

Our studies have shown that this horrible force
Is so dangerous to society at large that laws
Are being drawn up at this very moment to stop it forever!
Cruel and inhuman punishments are being carefully described
In tiny paragraphs so they won't conflict with the Constitution
(Which, itself, is being modified in order to accommodate the future)

I bring you now a special presentation
To show what can happen to you if you choose a career in music...
The white zone is for loading and unloading only...
If you have to load or unload, go to the white zone...
You'll love it... it's a way of life... Ha, ha, ha, ha, ha...
Hi, it's me, I'm back
This is the Central Scrutinizer...
The white zone is for loading and unloading only...
If yah gotta load, or if yah gotta unload, go to the white zone
You'll love it... it's a way of life
That's right, you'll love it, it's a way of life
That's right, you'll love it, it's a way of life
You'll love it
This, is, the Central Scrutinizer!
- Frank Zappa

iv.datura.network/watch?v=IgG8…

Since Android uses Linux, you’d think it would be easier to run Linux apps on your Android phone or tablet. There are some solutions out there, but the experience is usually less than stellar. A new player, Lindroid, claims to provide real Linux distributions with hardware-accelerated Wayland on phones. How capable is it? The suggested window manager is KDE’s KWIN. That software is fairly difficult to run on anything but a full-blown system with dbus, hardware accelerations, and similar features.

There are, however, a few problems. First, you need a rooted phone, which isn’t totally surprising. Second, there are no clear instructions yet about how to install the software. The bulk of the information available is on an X thread. You can go about 4 hours into the very long video below to see a slide presentation about Lindroid.

While it appears Linux is running inside a container, it looks like they’ve opened up device access, which allows a full Linux experience even though Linux is technically, in this case, an Android app.

We are interested in seeing how this works, and when the instructions show up, we might root an old phone to try it out. Of course, there are other methods. Termux seems to be the most popular, but running GUI programs on it isn’t always the best experience. Not that we haven’t done it.

youtube.com/embed/7vF5647gNbo?…