La sicurezza informatica esiste davvero oppure è sempre un transitorio ?

[TheVice]

Mi chiedo:

se questi vengono aggrediti con successo, allora noi comuni mortali come ce la possiamo scansare ?

RSA Hacked: RSA SecurID Hacked By "Extremely Sophisticated" Attack

[FlameNetworks]

È semplice: non ce la scansiamo, a meno che non si torni ad usare strumenti "obsoleti".

Ciao,

F.

[TheVice]

Meglio prevenire o curare ?
Perchè a ben guardare nel gioco di "guardie e ladri" i ladri sembrano stare sempre un passo avanti.
Lasciamo stare la sicurezza di infrastrutture critiche che dovrebbe essere un capitolo a se, ma molte aziende pretendono sicurezza dai loro responsabili IT (in genere sistemisti e sysadmin) manco questi fossero i guru della sicurezza ed avessero realmente i mezzi per garantirla.
Sia chiaro, mettere in sicurezza un sistema informatico è importante, ma in quanti investono in figure professionali dedicate ?
Basta mettere in sicurezza i propri server aziendali e i terminali ?
Che intendiamo poi col termine mettere in sicurezza ?
Basta tenere aggiornati e ben configurati i propri sistemi per garantire la sicurezza di un'azienda medio-grande ?

[FlameNetworks]

Ovviamente è sempre meglio prevenire.

Sono pochissime le realtà italiane che investono in sicurezza. Posso dirti, per esperienza diretta, che è di scarso un anno fa l'obbligo, per chi detiene dati di carte di credito (in particolare il CVV), di essere PCI-DSS compliant e ti posso garantire che Verizon è molto seria sulle tematiche legale alla sicurezza.

I ladri, come dici tu, spesso stanno avanti perchè corrompono le guardie oppure perchè quest'ultime si lasciano corrompere, il risultato comunque non cambia.

Chi mi garantisce che quel casino non sia stato voluto, oppure che sia riuscito perchè avevano una talpa all'interno?

Nell'articolo si parla di spionaggio industriale, ci saranno sicuramente degli interessi enormi alle spalle.

Ciao,

Fabrizio

[TheVice]

Sicuramente meglio prevenire ...
Ma è il concetto stesso di sicurezza che impone certe scelte. Nell'articolo la società in questione adotta delle policies di sicurezza che sicuramente tengono in conto aggressioni dall'interno (spionaggio industriale) ma il fatto grave è che la "profilassi" applicata non è riuscita a prevenire il danno ma solo a constatarlo (il che è già moltissimo!) .
Sappiamo che il sistema di sicurezza perfetto non esiste ma simili episodi non è che dimostrano anche che c'è un certo adagiarsi sugli allori quando si investe X% del proprio utile in sicurezza ? (ovviamente meglio investire quell'X% che non investir nulla!)

[FlameNetworks]

Certo, mai adagiarsi in queste situazioni.
Credo che il responsabile della sicurezza di turno, debba essere pagato profumatamente soprattutto per essere sempre vigile.

Mi rendo conto che spesso non è così, ovvero non esiste proprio un settore interno che si occupi di sicurezza.

La maggior parte delle PMI non si curano minimamente di questo aspetto. Solo poche grandi aziende hanno un SOC.

[usu]

Visto che siamo in tema: PHP: News Archive - 2011

[FlameNetworks]

Visto...dicono che il codice non è stato alterato...
La cosa comunque è piuttosto grave.

[usu]

Ahhh la famosa sicurezza militare

Usare Google per “violare” un sito militare

[DonChisciotte]

premessa: ho lavorato 6 mesi presso un SoC di una grande azienda italiana, dove mi occupavo di prevenzione e gestione incidenti.
la sicurezza e' sempre un divenire e non si puo' stare tranquilli al 100%; bisogna essere sempre attenti ad ogni situazione anomala che deve essere gestita per capire il meccanismo dell'eventuale attacco e prendere le contromisure adeguate.
inoltre nelle grandi aziende sono presenti team dei partner, come Microsoft, TrendMicro, Cisco, Checkpoint etc etc, che si occupano di fornire anche delle pre-patch rilasciate appositamente.
i ladri sono sempre un passo avanti alle guardie? la risposta e' si, purtroppo, anche solo per il semplice fatto che la prima mossa la fanno loro e per quanto si possa effettuare un'opera di prevenzione c'e' sempre lo 0day di turno (e li' scatta il panico dei capoccia ) o il virus per cui non esiste ancora la relativa firma con risultati ben prevedibili.

nelle PMI avere un team di monitoraggio H24 con gestione degli incidenti e' troppo costoso e spesso il gioco non vale la candela: e' piu' conveniente avere una valida politica di backup e disaster recovery e delegare la sicurezza a chi si occupa anche di altro, come il team di sistemistica (che quando va bene e' formato da 3 persone).

ciau

[usu]

Hacker Got Personal Data on PlayStation Users - WSJ.com

:\

[andrea.paiola]

Ahhh la famosa sicurezza militare

Usare Google per “violare” un sito militare

che coacervo di burocrazia

https://aepubs.army.mil/pdfpubs/CM2010-090.htm

[ITactive78]

Certo, mai adagiarsi in queste situazioni.
Credo che il responsabile della sicurezza di turno, debba essere pagato profumatamente soprattutto per essere sempre vigile.

Mi rendo conto che spesso non è così, ovvero non esiste proprio un settore interno che si occupi di sicurezza.

La maggior parte delle PMI non si curano minimamente di questo aspetto. Solo poche grandi aziende hanno un SOC.

Sono d’accordo che in molte aziende (PMI in testa) la sicurezza IT sia perlomeno – e uso un eufemismo – non tra la priorità. Sulla community con cui collaboro è stato postato un test di autovalutazione della sicurezza aziendale – sottoposto anche ai partecipanti di eventi/worskshop ecc… - e i primi risultati che ho potuto vedere non sono certo incoraggianti (nonostante il livello sia piuttosto basilare).
Per farvene un’idea è qui Infoboom: Per sapere se la tua azienda è sicura ti bastano 5 minuti.

[andrea.paiola]

The Cracking of Kernel.org | Linux.com

https://www.kernel.org/

• Security breach on kernel.org
  
  
  Earlier this month, a number of servers in the kernel.org infrastructure were compromised. We discovered this August 28th. While we currently believe that the source code repositories were unaffected, we are in the process of verifying this and taking steps to enhance security across the kernel.org infrastructure.
  
  
  What happened?
  
  
  
  
  
  • Intruders gained root access on the server Hera. We believe they may have gained this access via a compromised user credential; how they managed to exploit that to root access is currently unknown and is being investigated.
  • Files belonging to ssh (openssh, openssh-server and openssh-clients) were modified and running live.
  • A trojan startup file was added to the system start up scripts
  • User interactions were logged, as well as some exploit code. We have retained this for now.
  • Trojan initially discovered due to the Xnest /dev/mem error message w/o Xnest installed; have been seen on other systems. It is unclear if systems that exhibit this message are susceptible, compromised or not. If developers see this, and you don't have Xnest installed, please investigate.
  • It *appears* that 3.1-rc2 might have blocked the exploit injector, we don't know if this is intentional or a side affect of another bugfix or change.
  
  
  
  What Has Been Done so far:
  
  
  
  
  
  • We have currently taken boxes off line to do a backup and are in the process of doing complete reinstalls.
  • We have notified authorities in the United States and in Europe to assist with the investigation
  • We will be doing a full reinstall on all boxes on kernel.org
  • We are in the process of doing an analysis on the code within git, and the tarballs to confirm that nothing has been modified
  
  
  
  The Linux community and kernel.org take the security of the kernel.org domain extremely seriously, and are pursuing all avenues to investigate this attack and prevent future ones.
  
  
  However, it's also useful to note that the potential damage of cracking kernel.org is far less than typical software repositories. That's because kernel development takes place using the git distributed revision control system, designed by Linus Torvalds. For each of the nearly 40,000 files in the Linux kernel, a cryptographically secure SHA-1 hash is calculated to uniquely define the exact contents of that file. Git is designed so that the name of each version of the kernel depends upon the complete development history leading up to that version. Once it is published, it is not possible to change the old versions without it being noticed.
  
  
  Those files and the corresponding hashes exist not just on the kernel.org machine and its mirrors, but on the hard drives of each several thousand kernel developers, distribution maintainers, and other users of kernel.org. Any tampering with any file in the kernel.org repository would immediately be noticed by each developer as they updated their personal repository, which most do daily.
  
  
  We are currently working with the 448 users of kernel.org to change their credentials and change their SSH keys.
  
  
  We are also currently auditing all security policies to make kernel.org more secure, but are confident that our systems, specifically git, have excellent design to prevent real damage from these types of attacks.

[usu]

Researchers break WC3 XML encryption algorithm, push for new standard olè