In primo luogo, potrebbe essere meglio comprendere appieno le esigenze del cliente (il tuo capo). È possibile che abbia bisogno di accedere solo a un piccolo sottoinsieme dei dati su questo server da qualsiasi luogo e non necessariamente tutto.

Dove possibile, invece di dire no in questa situazione torna con alcune opzioni.

1. VPN in modo che le persone che viaggiano, possano accedere ai dati ovunque si trovino. Se possibile, aggiungi ulteriori controlli di sicurezza come firewall interni e Data Loss Prevention (DLP), se necessario. Rafforzare e aggiungere ulteriori controlli di sicurezza qui, se necessario.

2. Autenticazione e crittografia avanzate su un server separato che contiene un piccolo sottoinsieme di dati ma forse non tutti i dati sensibili. Rafforzare e aggiungere ulteriori controlli qui, se necessario. Solo consentire al server con i dati sensibili di inviare i dati a quello a cui è possibile accedere pubblicamente e bloccare tutti i pacchetti dal server accessibile pubblicamente che tornano a quello contenente i dati sensibili può essere un trucco utile (regola del firewall unidirezionale).

3. Creare un server front-end sicuro a cui è possibile accedere da qualsiasi luogo e con accesso controllato al server backend. Rafforzare e aggiungere ulteriori controlli qui, se necessario.

4. Rafforzare il server stesso e, se applicabile, distribuire un WAF o altri controlli di fronte ad esso.

5. Pensa ad altre soluzioni creative a seconda delle effettive esigenze del tuo capo (la tua domanda non è specifica sulle effettive esigenze).

Indipendentemente dall'opzione scelta, assicurati di registrare e monitorare l'accesso al sistema. Sarebbe saggio contattare il tuo capo dopo che il sistema inizia a ricevere connessioni da altri paesi (o almeno IP che ovviamente non provengono da persone che lavorano con te) e mostrargli le connessioni globali al sistema. A volte questo feedback del mondo reale è necessario affinché le persone comprendano il rischio.

Usa questa come un'opportunità per istruire il tuo capo ma fallo in modo molto umile attenendoti strettamente ai dati reali, potrebbe aver avuto troppe persone che gli vendevano sicurezza con Paura, Incertezza e Dubbi (FUD) e potresti semplicemente non ascoltare nulla che suoni simile indipendentemente da quanto siano legittime queste informazioni. Fai attenzione alla stanchezza da FUD. Se lui o lei ha raggiunto il loro limite, qualsiasi cosa tu dica in questo senso avrà l'effetto opposto che desideri. Quando ciò si verifica, la soluzione migliore è fornire dati concreti e consentire a lui o lei di giungere alle proprie conclusioni.

Sii un risolutore di problemi qui, fornisci al tuo capo soluzioni, piuttosto che semplicemente motivi per dire no. Non aver paura di proporre soluzioni costose che ritieni siano troppo costose per l'azienda, il tuo capo potrebbe essere a posto se sposta rapidamente in avanti le funzionalità per lui o lei. Detto questo, quando possibile, mantieni sempre la sicurezza il più economica possibile a lungo termine (evita i costi ricorrenti che potrebbero essere ridotti durante un disagio economico). Considera questa come un'opportunità per ottenere maggiore sicurezza abilitando l'attività piuttosto che contrastarla. Se dimostri che puoi potenziare l'attività e definire le esigenze in termini di ciò che fa progredire l'attività o come le cose potrebbero influenzare il business otterrai una risposta molto migliore da persone come il tuo CEO. Capire quando l'attività è di fretta è importante, non è raro che un'azienda paghi più soldi per una soluzione o approvi cose che altrimenti non potrebbero approvare se può aggiungere valore ed essere implementata rapidamente. A tal fine, anche sapere quando a tempo richieste e comprendere l'urgenza dei progetti in volo vi aiuterà.

Pensa a questa parte degli affari come a un'arte marziale, vuoi sfruttare l'energia dei tuoi avversari e reindirizzarla verso un luogo in cui desideri che vadano riducendo al minimo il tuo dispendio energetico. Se riesci ad afferrare rapidamente il suo desiderio di renderlo accessibile, ora potrebbe essere un ottimo momento per ottenere molta più sicurezza. La velocità è importante qui e devi ottenere il buy-in finché fa caldo, per così dire.

Infine, riconosci che farai molto meglio ad affrontare questo problema come un problema aziendale che puoi aiutare con , piuttosto che un semplice problema di sicurezza tecnica. Allo stesso modo, inizia a cercare e ad anticipare ulteriori esigenze di sicurezza in futuro e portali al tuo capo fin dall'inizio in modo da sembrare qualcuno che aiuta l'azienda piuttosto che un ostacolo al progresso. Questo frammento di inquadratura raggiunge lo stesso obiettivo ma ottiene la sicurezza più velocemente e con meno conflitti.

Aggiunta dopo il post originale: una cosa che potrebbe essere utile anche per te è creare una roadmap di sicurezza a lungo termine e condividerla con la tua organizzazione. Ciò che ciò comporta sarà diverso per ogni organizzazione, ma è molto importante mostrare il lavoro che non stai attualmente facendo e anche il lavoro che potrebbe essere cose che la tua organizzazione non farà mai internamente (le piccole start-up hanno meno probabilità di avere team forensi interni ). La ragione di ciò è aiutare a educare e anche a definire le aspettative con il tuo team di leadership. Questo è qualcosa che molti team di sicurezza hanno in testa, ma formalizzare un piano e mostrare un percorso da seguire può aiutarti a ottenere più buy-in per il tuo programma di sicurezza. Gran parte di questo riguarda la comunicazione e l'avere una visione condivisa dal punto di vista aziendale, ma un'altra parte riguarda l'educazione del senior management su dove sono saggi di rischio. Trovo che visualizzare il debito-titolo della tua organizzazione aiuti le persone a prendere automaticamente decisioni più ponderate.

Ci sono alcune ragioni per cui collegare i sistemi interni direttamente a Internet è una cosa negativa?

Stai aumentando inutilmente la superficie di attacco. Ecco i problemi da considerare:

• Un utente malintenzionato che ottiene il controllo su questo singolo servizio esposto può eventualmente sfruttare tale accesso per infiltrarsi in altri servizi sulla intranet.

• Potresti avere difficoltà a monitorare i log per accessi non autorizzati. Gli aggressori da qualsiasi luogo tenteranno di accedere e sfruttare il servizio, attivando costantemente falsi allarmi.

• Gli aggressori potrebbero DoS il server e renderlo non disponibile, anche involontariamente, utilizzando strumenti di scansione automatizzata per testare l'applicazione per vulnerabilità o nel tentativo di eseguire accessi a forza bruta.
• Se uno sconosciuto acquisisce le credenziali di accesso di un dipendente che accede da un hotspot pulic (si spera che tu stia utilizzando HTTPS, ma potrebbero essere solo spalla- navigando), possono accedere direttamente dal proprio browser senza dover per prima cosa entrare nella rete aziendale.

• Anche se il servizio utilizza HTTPS, il proprietario dell'hotspot saprà che il dipendente ha avuto accesso a internal.yourcompany.com e potrebbe interessarsi.

• Se stai utilizzando un framework noto, CMS o altro software popolare, hai per essere veloci con gli aggiornamenti se un problema di sicurezza con quel software diventa pubblico. Devi aspettarti che gli aggressori siano server di scansione di massa per istanze prive di patch.

• Stai esponendo le tecnologie che usi internamente. Non è necessariamente una cosa negativa, ma potrebbe funzionare come argomento per il tuo capo.

• Dici che il servizio ha avuto un controllo di sicurezza: il tuo capo si fida della valutazione in una certa misura che qualsiasi sconosciuto su Internet possa sfidarlo?

La maggior parte di questi problemi potrebbe essere mitigata con una soluzione VPN per l'accesso remoto dei dipendenti invece di esporre direttamente parti della intranet. Una VPN offre al tuo capo la possibilità di abilitare, bloccare e monitorare rapidamente l'accesso remoto direttamente al gateway.

In un'applicazione / sistemi / distribuzione commerciale, non si esegue mai un sistema al di fuori delle specifiche ufficiali .

Il fatto che il sistema sia stato sviluppato e testato per la penetrazione partendo dal presupposto che verrà distribuito solo alla rete interna dovrebbe essere sufficiente per convincere il tuo capo. Gli sviluppatori e i custodi (tu sei l'ultimo) di un tale sistema non accetteranno e non possono accettare la colpa per eventuali conseguenze, che possono o meno essere gravi.

Se hai bisogno di analogie per convincere il tuo capo, ecco alcuni:

• Far funzionare i camion dell'azienda oltre il numero di giri al minuto della linea rossa per accelerare le consegne
• sovraccaricare la rete elettrica con un amperaggio più elevato rispetto ai fusibili consente di risparmiare sull'aggiornamento del sistema elettrico
• Far atterrare un aereo a una velocità superiore alla velocità massima di atterraggio

Sono sicuro che il capo non oserebbe suggerire nessuna delle azioni sopra. Questo è tutto ciò di cui hai bisogno per convincerlo. Molte persone hanno fornito preziose informazioni dettagliate a questo thread, ma il nucleo dell'argomento è nella mia prima frase, in grassetto.

Alcune buone risposte qui. Per aggiungere, ecco alcuni punti.

• Posizionando l'applicazione su Internet, non solo esponi quell'applicazione, ma aumenti anche l'esposizione delle tue applicazioni interne. se la tua applicazione di fatturazione è compromessa, un hacker potrebbe essere in grado di utilizzarla per accedere agli altri tuoi sistemi interni.

• I dati delle fatture presumibilmente contengono informazioni sui tuoi clienti. Sarai responsabile se qualcuno dei loro dati sensibili viene esposto.

• Mettere la tua applicazione su Internet può aggiungere un ulteriore onere normativo. Ad esempio, se gestisci le informazioni sull'assistenza sanitaria, dovrai soddisfare gli standard di sicurezza informatica HIPAA; se alcuni dei tuoi clienti sono enti governativi, potrebbe essere applicata la norma ISO-27000.

• Se intendi utilizzare lo stesso meccanismo di autenticazione, è possibile che le tue regole di complessità della password non siano valide abbastanza. Potrebbe essere necessario impostare il flag di reimpostazione della password su tutti gli utenti e chiedere loro di impostare nuove password in base a nuove regole di complessità.

• Quando si mette un sito su Internet, è possibile richiedono più hardware. Avrai bisogno almeno di un firewall perimetrale e possibilmente di un firewall aggiuntivo per stabilire una DMZ. Ciò potrebbe significare che i tuoi server web avranno bisogno di due NIC ciascuno.

• Potrebbe essere necessario acquistare un certificato SSL pubblico, che ha un costo.

Con le informazioni limitate che hai fornito, ecco i miei input.

Esporre un sistema attualmente interno a Internet può o non può essere una cattiva idea a seconda di vari altri fattori. Le domande che dovete porvi prima di renderlo accessibile al pubblico sono le seguenti.

1. Chi sono i potenziali utenti dei sistemi e del servizio?

Se l'applicazione viene utilizzata solo dai dipendenti, la mossa saggia è renderla accessibile tramite VPN. Tuttavia puoi anche renderlo pubblico, dopo aver eseguito una revisione dell'architettura.

2. Qual è l'attuale profilo di rischio dell'applicazione?

Comprendo che l'applicazione gestisce dati sensibili. Ma qual è il profilo di rischio dell'applicazione secondo l'organizzazione? Comprenderlo è importante perché uno dei fattori che influenzano il profilo di rischio cambierà notevolmente - l'impronta di Internet - dopo aver apportato questo cambiamento.

3. Con che frequenza esegui il test di penna dell'applicazione?

L'attuale profilo di rischio della tua domanda potrebbe non essere abbastanza alto per eseguire regolarmente pen test. È inoltre necessario considerare la probabilità di nuove vulnerabilità, zero giorni ecc. Durante l'esposizione a una rete esterna.

4. Meccanismo di autenticazione.

L'applicazione utilizza le credenziali di dominio? Utilizza traffico crittografato? Usa 2FA? Ha una politica di blocco? Molte di queste domande potrebbero essere state ignorate come a basso rischio durante l'esecuzione di un test penna considerando l'applicazione come interna. Potrebbe essere necessario un nuovo test prospettico sull'applicazione come applicazione esterna prima di distribuirla al pubblico.

1. Tutto ciò che è su Internet può essere compromesso e dovrebbe essere trattato come insicuro.
2. Tutto ciò che non è su Internet è più difficile da compromettere ma può comunque essere compromesso e dovrebbe essere trattato come se lo fosse su Internet.

In altre parole, tenere un sistema lontano da Internet lo rende più sicuro, ma non è una scusa per una cattiva sicurezza in altre parti del sistema. Sono preoccupato per la tua parte "tutto questo è stato fatto sulla base del fatto che il sistema era accessibile solo dal dominio interno": un sistema che non è su Internet dovrebbe essere reso sicuro come un sistema che è su Internet e come per quanto riguarda la progettazione / auditing / pentesting, dovrebbe essere trattato come se fosse su Internet. Tuttavia, un sistema sensibile dovrebbe essere sempre tenuto lontano da Internet a meno che non ci sia un motivo essenziale per cui deve essere su Internet (ad esempio, ci sono uffici in una posizione remota).

Una situazione simile si applica alle VPN, proxy, gateway e così via. Rendono un sistema più sicuro, ma non sono una scusa per una cattiva sicurezza altrove e possono comunque essere compromessi. È come mettere un altro lucchetto alla tua porta: potrebbe rallentare un aggressore ma non può fermarlo e il tuo sistema è ancora molto meno sicuro che se fosse tenuto fuori da Internet.

Esiste una formula razionale per il rischio. Rischio = Minaccia x Vulerabilità

Qual è il valore dell'asset? (Quanto costa il ripristino se i dati vengono persi, rubati o danneggiati? Sono i dati dei clienti a farti processare in caso di furto? Quanto sono preziosi questi dati per hacker o concorrenti?)

Identificare il valore dell'asset aiuta a stabilire la probabilità che una minaccia sfrutti una vulnerabilità per causare una perdita.

Quali sono le vulnerabilità? (Stai già tentando di stabilire le vulnerabilità con il test della penna).

Qual è il costo di un controllo di sicurezza per mitigare una vulnerabilità? Se il costo del controllo supera il costo dell'asset, non vale la pena installare la mitigazione della vulnerabilità.

Se esegui questi dati dal tuo capo, potrebbe pensare al costo della convenienza. Alcune persone pensano che il costo della convenienza valga il rischio, mentre altri non vogliono alcun rischio e non si preoccupano della comodità. Ricorda che la mitigazione del rischio è il fattore chiave.

Il principale rischio per la sicurezza non sono le VPN. Tutti sono molto ben protetti contro ogni possibile crack.

Il rischio per la sicurezza è il contenuto che muovi attraverso queste VPN e la falsa convinzione che le VPN difenderanno il tuo sistema. Sì, quasi sicuramente si difenderanno dagli attacchi alla VPN. Ma non contro gli attacchi del tuo sistema di prenotazione, che è sicuramente molto più complesso e con una sicurezza di gran lunga inferiore.

Il suo traffico tra i tuoi host esterni e la rete locale è perfettamente legale dal punto di vista della VPN.

Se utilizzi una soluzione diversa e non basata su VPN (ad esempio, utilizzando una sincronizzazione dei dati), puoi proteggere molto meglio la tua rete interna, ma non puoi risolvere l'essenza di questo problema.

Secondo me, se si tratta di un software di prenotazione, potrebbe trattarsi di dati finanziari, quindi altamente sensibili e privati ​​dei clienti . La maggior parte delle aziende che conosco difendono i dati dei propri clienti in modo più deciso rispetto ai propri, ed è un comportamento abbastanza razionale da parte loro. Senza sapere nulla dal tuo sistema, vedo del tutto possibile che questi dati siano effettivamente più importanti per il tuo datore di lavoro, poiché tutta la tua rete locale e altri. Il tuo capo lo sa sicuramente e penso che se vuoi convincerlo, discuti in questa direzione e non in quelle tecniche.

La tua domanda include il motivo principale ... è stato testato di penetrazione partendo dal presupposto che il sistema non fosse accessibile esternamente. Quindi inizia con il costo per eseguire il pentesting senza quell'ipotesi e quel test tornerà con tutti i rischi.

Rendere l'app accessibile esternamente senza un adeguato pentesting non dovrebbe nemmeno essere considerato il tuo tu e la tua azienda. Non sei un esperto in materia nel valutare il rischio di esporre un servizio progettato per essere interno alla rete Internet pubblica.

Tutti possiamo indovinare i numerosi modi in cui questa applicazione esporrebbe la tua azienda, ma questa è solo supposizione. Devi presumere il caso peggiore, ovvero che qualcuno violi il server di hosting e ottiene l'accesso root al server e quindi lo utilizza per ottenere l'accesso a tutti gli altri server. SE la tua attività dipende dai tuoi sistemi IT, la tua attività può essere interrotta al punto da non essere in grado di condurre gli affari, subire la perdita di credibilità all'interno del tuo settore e potenzialmente conseguenze legali.

In una lingua che il tuo capo capirà: lo svantaggio è che deve preoccuparsi della sicurezza, molto probabilmente sotto forma di assunzione di alcuni esperti esterni, e noi siamo costosi.

Una volta che hai messo il sistema su Internet, ogni hacker annoiato dalla Cina può entrare, solo per il lolz. Se pensi che non lo faranno (argomento standard "non abbiamo nulla che valga la pena rubare"), guarda indietro a quello che ho scritto: Il lolz. Non hai bisogno di un motivo per entrare in un sistema. La maggior parte degli attacchi in questi giorni sono non diretti, ovvero lanciano semplicemente una serie di exploit standard su un'intera rete e vedono chi cade. Solo dopo che hanno fatto irruzione, controlleranno anche cosa o chi è. E se non hai niente da rubare, c'è ancora potenza della CPU, larghezza di banda e far parte di una botnet.

Avere un sistema non su Internet è la misura di sicurezza numero 1 anche per i sistemi Internet. Ciò significa che se lo vuole su Internet, va bene. Ma dovrebbe esserci un firewall e / o un WAF e / o un gateway applicazione davanti e una DMZ attorno ad esso. Ovviamente puoi metterlo su Internet se lo desidera. Dalla tua domanda non è chiaro che il tuo capo capisca che significa qualcosa di più che inserire un cavo diverso nella porta di rete.

Se il tuo sistema è stato creato per essere accessibile pubblicamente, sarebbe molto intelligente farlo.

Esistono servizi che ti consentono di gestire le fatture direttamente su Internet, ad esempio.

Avere un servizio aperto a Internet non lo rende intrinsecamente più o meno sicuro. Tuttavia, sapere che è più esposto dovrebbe diventare un ottimo incentivo per renderlo il più a prova di proiettile possibile.

In altre parole, se sai che le tue app sono nascoste dietro la tua rete interna, il giorno in cui qualcuno entrerà, sarà molto fragile. La maggior parte dei sistemi a quei tempi non è isolata al 100% dal mondo esterno per sempre: accesso wifi, interruzioni del firewall, virus, VPN, ...

Quindi è buona norma avere una sicurezza approfondita.

Se è intrinsecamente sicuro, non vedo perché non possa essere aperto su Internet. Oggi, le operazioni bancarie, il gioco d'azzardo online e persino l'assistenza sanitaria sono accessibili da Internet.

Quindi è fattibile.