Java con sistema LIS

3

Non sono esperto di tecnologia ma ho un problema che forse voi esperti potreste rispondere. Abbiamo un'applicazione software che supporta il nostro laboratorio, ovviamente deve essere sicuro. Vogliamo essere in grado di avere parti esterne che interagiscono con l'applicazione attraverso un modulo web che abbiamo acquistato per l'applicazione. Tuttavia, i nostri esperti IT sono preoccupati perché l'applicazione richiede attualmente Java 1.6 sul server e cita molte vulnerabilità di sicurezza. Il venditore indica che non hanno completato i test per le future versioni di Java.

Questa applicazione è in uso in molti grandi sistemi ospedalieri, quindi trovo difficile credere che il venditore non avrebbe affrontato questo in qualche modo. Sta causando qualche contesa e noi utenti siamo bloccati nel mezzo.

Qualcuno può aiutarmi a capire, se possibile, in termini laici:

  1. Questa è una preoccupazione?
  2. Quali domande chiedo al venditore per determinare la nostra vulnerabilità specifica, ad es. se mantengono aggiornato il nostro sistema con patch critiche, ecc?
  3. L'unico modo per insistere è che il venditore passi a 1.8 prima di creare l'accesso alla nostra rete da entità esterne?
  4. È vero che 1.6 è al termine della vita e quindi non vengono generate più patch di sicurezza?

Non sai da dove cominciare o chi possa credere a questo ... Grazie!

    
posta Bonnie Parker 27.10.2015 - 21:24
fonte

3 risposte

1

Is this is a concern?

Non dirò di no, ma una cosa da capire è che Java viene fornito con molte cose che non sono rilevanti in nessun contesto che è probabile vederlo usato. Quasi tutte le vulnerabilità della sicurezza in Java sono lato client. Cioè, la maggior parte sono applicabili solo quando si utilizzano i plug-in Java sul browser. Pochissime delle vulnerabilità Java sono lato server. Molte persone del tipo IT-admin non riescono a capirlo ed è possibile che reagiscano in modo eccessivo.

D'altra parte, un piccolo numero di vulnerabilità (ad esempio una) può consentire exploit piuttosto significativi, quindi non c'è davvero un buon argomento per non lavorare sulla patch della JVM.

Nel complesso, tuttavia, è probabile che il fornitore abbia vulnerabilità crearizzate nel codice o abbia utilizzato librerie con vulnerabilità. Scommetto che è molto più probabile che tali problemi vengano sfruttati rispetto alle vulnerabilità JVM / JDK. Ciò è strongmente suggerito dal fatto che sembrano incapaci / non disposti a testare nuovamente il codice su una nuova versione di Java. La compatibilità all'indietro è molto ben mantenuta in Java. È davvero inaccettabile che rispondano in questo modo. Implica che abbiano processi di sviluppo molto deboli.

What questions do I ask of the vendor to determine our specific vulnerability - e.g. if they keep our system updated with critical patches, etc?

Queste sono buone domande da cui iniziare. Probabilmente avrai bisogno di aiuto. Potresti volere che qualcuno faccia un'analisi statica (tuttavia la loro licenza potrebbe vietarlo) del sistema e / o test di penetrazione.

Is the only recourse to insist that the vendor move to 1.8 before we create access into our network from outside entities?

Lo farei. Davvero non dovrebbe essere un problema. Non avranno bisogno di cambiare alcun codice, per quanto ne so. È irragionevole per loro rifiutare.

EDIT: dovrei aggiungere, se questa è un'applicazione in esecuzione sui server controllati dal tuo team IT, puoi far installare ed eseguire il tuo personale IT su una JVM aggiornata senza alcuna assistenza da parte del fornitore. È improbabile che ci siano problemi a meno che non stiano facendo qualcosa di stupido, ma potrebbero usarlo come scusa per non supportare l'applicazione. Non c'è bisogno di ricompilare o altro, un'applicazione scritta con Java 1.6 dovrebbe essere eseguita su una JVM 1.8.

Is it true that 1.6 is at end of life and therefore no more security patches are generated?

Sì, in 2013 . Puoi comunque acquistare un supporto esteso.

    
risposta data 28.10.2015 - 20:10
fonte
0

Personalmente, penso che tu abbia bisogno di assumere una società di consulenza sulla sicurezza per coprire adeguatamente i problemi di sicurezza qui. I tuoi problemi di sicurezza esatti saranno altamente contestuali e ci sono ulteriori implicazioni normative negli ospedali. Detto questo, proverò a coprire le tue preoccupazioni.

This application is in use in many large hospital systems, so finding it hard to believe that vendor wouldn't have addressed this somehow

Sfortunatamente, è abbastanza comune. Parla con chiunque gestisca infrastrutture IT, reti, sicurezza, software, ecc. In un ospedale (o qualsiasi altra organizzazione) e ti diranno la stessa cosa - i fornitori di solito sono lenti a risolvere i problemi, e spesso non metteranno sforzo per i prodotti legacy che sono ancora invocati.

Is this is a concern?

Molto probabilmente sì. Stai mettendo un quadro obsoleto e insicuro sui sistemi interessati. Java può essere richiamato tramite il browser a meno che non sia configurato correttamente, il che consente potenzialmente attacchi remoti contro il sistema. Un altro vettore di attacco potenziale contro il framework è tramite server Web Java come Apache Tomcat, che potrebbe esporre funzionalità sfruttabili (ad es. RMI) indipendentemente da ciò che fa l'applicazione.

What questions do I ask of the vendor to determine our specific vulnerability - e.g. if they keep our system updated with critical patches, etc?

Il problema è che, se stanno usando Java obsoleto (specialmente 1.6 o precedenti), allora non importa ciò che fanno per affrontare le singole vulnerabilità nella loro applicazione - il framework sottostante è rotto e loro non è in grado di attenuarlo individualmente.

Is the only recourse to insist that the vendor move to 1.8 before we create access into our network from outside entities?

La semplice risposta è sì. La risposta più complessa è che potrebbe sandbox fuori dal server delle applicazioni in modo che, se dovesse essere compromesso, ci sia un livello limitato di accesso che ha di nuovo nella tua rete interna, se presente. Tuttavia, se i dati del paziente sono inclusi (in particolare qualsiasi PII), allora hai i requisiti normativi con cui contestare.

Il TL; DR è che il fornitore dovrebbe aggiornare il proprio codice per lavorare con una versione più moderna di Java. Esistono due modi principali per accelerare questo processo: offrire il pagamento dei tempi di sviluppo necessari per farlo, o minacciare di disattivare il servizio e utilizzare un'alternativa più aggiornata.

Un'altra strada che hai è normativa: supponendo che tu sia negli Stati Uniti, comunica al tuo ente normativo HIPAA che il loro software utilizza una struttura vulnerabile che si traduce nell'esposizione ai rischi delle informazioni sui pazienti. Se la loro base di clienti è ampia, potrebbe essere richiesto dalla legge di aggiornare il proprio software o mitigare in qualche modo eventuali problemi.

    
risposta data 27.10.2015 - 21:44
fonte
0

Is this is a concern?

Ovviamente si perché è una vecchia versione di Java prima ancora che Oracle acquisti Sun così la tua versione manca patch di sicurezza critici.

What questions do I ask of the vendor to determine our specific vulnerability - e.g. if they keep our system updated with critical patches, etc?

Il problema è che l'intera piattaforma può essere problematica per la ragione che ho affermato nella domanda precedente. La soluzione ideale è chiedere alla società di terze parti di valutare tale applicazione all'interno della più recente versione di Java, ma ciò non è pratico in quanto ti costerà tanto in termini di tempo e denaro.

Is the only recourse to insist that the vendor move to 1.8 before we create access into our network from outside entities?

Come ho detto prima, può essere la soluzione ideale: ma allora, quanto tempo e denaro ci vorrà?

Is it true that 1.6 is at end of life and therefore no more security patches are generated?

Fai riferimento alla risposta di @JimmyJames (link aggiuntivo: Criteri di supporto a vita Oracle )

    
risposta data 28.10.2015 - 20:35
fonte

Leggi altre domande sui tag