2010-07-26 17 views
10

maggior parte della letteratura sui colloqui di sicurezza circa l'importanza di definire una politica di sicurezza prima di iniziare a allenamento sui meccanismi e implementazione. Sebbene ciò sembri logico, non è abbastanza chiaro quale sia il significato di una politica di sicurezza.Definizione di una politica di sicurezza per un sistema

nessuno qui ha avuto alcuna esperienza nella definizione di una politica di sicurezza, in caso affermativo:

1) Qual è il risultato di una tale definizione? La forma di tale politica, per esempio il sistema distribuito, è un documento contenente una serie di dichiarazioni sui requisiti di sicurezza (cosa è permesso e cosa non lo è) del sistema?

2) Può la politica assumere la forma leggibile macchina (se questo ha un senso), e se sì, come può essere utilizzato?

3) Come si mantiene una tale politica? La politica viene gestita come documentazione (come con tutto il resto della documentazione) sul sistema?

4) Se è necessario per rendere riferimenti al documento di politica in codice?

Brian

+0

Questo non sembra riguardare la programmazione. Dato che apparentemente si tratta di sicurezza a livello aziendale, vota la migrazione a Server Fault. –

+2

@David: non sono assolutamente d'accordo. Quando si progetta un sistema con implicazioni di sicurezza, i meccanismi che implementa devono supportare la gamma di potenziali politiche. – Novelocrat

+0

@Novelocrat: Certamente, e la programmazione di detti meccanismi è completamente in discussione qui. Tuttavia, si tratta di stabilire una sorta di regole che verranno implementate in vari modi, alcune probabilmente coinvolgono la programmazione, e che non è in argomento su SO. –

risposta

-1

Se si deve progettare una politica di sicurezza, perché non pensare a utenti e autorizzazioni?

Quindi, diciamo che si dispone di un'API per qualcosa. Prendi in considerazione alcuni accordi sugli utenti che li dividono in ciò che vogliono fare e quali sono i permessi minimi di cui hanno bisogno per farlo. Quindi, se qualcuno deve solo leggere documenti da un database, l'API stessa non permetterà all'utente di fare qualcos'altro.

Immaginate che questa sia un'API JSON web. L'utente fa clic su un pulsante e JS elabora una richiesta e la invia. Normalmente funziona bene, ma se qualcuno manomette la richiesta, il server restituisce semplicemente un codice di errore perché sta autorizzando solo poche azioni che l'utente può fare.

quindi penso che tutto si riduce a utenti e permessi.

+0

Questo è focalizzato molto strettamente su un tipo di ambiente di sicurezza. Altri ambienti avranno impostazioni molto diverse. Ad esempio, considera un requisito contro la divulgazione di informazioni statistiche. O un sistema le cui azioni consentite dipendono dai dati e dalle condizioni attuali. – Novelocrat

+0

È intenzionalmente semplificato a quello che penso sia la situazione più comune in cui devi sviluppare una politica.La maggior parte delle politiche di sicurezza IMHO riguardano gli utenti finali che dovrebbero o non dovrebbero accedere a determinati dati. Inoltre la domanda è molto difficile da affrontare completamente (mi piacerebbe che tu provassi perché probabilmente potresti avere una comprensione migliore di me). –

+0

'" O un sistema le cui azioni permesse dipendono dai dati e dalle condizioni attuali "' - sembra il tipo di cosa in cui un approccio "permessi utenti e whitelist" funzionerebbe. –

1

È necessario prendere una delle politiche di sicurezza standard e lavorare da lì. Quello più comune è la conformità PCI (Payment Card Industry). È molto ben pensato e ad eccezione di alcuni punti deboli, generalmente buoni. Non ho mai sentito parlare di una politica leggibile da una macchina tranne che per una definizione di Microsoft Active Directory o una serie di regole di iptables di Linux.

https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml

EDIT:

Scopri politiche SE Linux anche:

http://en.wikipedia.org/wiki/Security-Enhanced_Linux

1

L'Application Security Project OWASP Open Web è un progetto indipendente dal linguaggio per educare sulla sicurezza e di fornire strumenti per testare e supportare il software. Sebbene sia incentrato sul web, molte delle idee chiave sono ampiamente applicabili. Il sito web è orientato sia verso gli ingegneri del software che verso la gestione.

1

Quando le persone parlano di "politica di sicurezza", potrebbero riferirsi a due diversi tipi di politica di sicurezza.

Uno di loro sono quelli ad alto livello, generalmente definiti da direzioni. I principali lettori di questa politica di sicurezza sono umani. È un documento che definisce l'obiettivo, il contesto, le aspettative e i requisiti di sicurezza nella mente del management.Le lingue utilizzate all'interno di questa politica potrebbero essere vaghe, ma è la "legge" elementare della sicurezza nel contesto applicativo. Tutti i soggetti coinvolti dovrebbero seguire tale politica.

1) Il risultato di tale politica è i requisiti di sicurezza chiaramente definiti dalla direzione. Con queste politiche, tutte le persone coinvolte possono comprendere le aspettative della direzione e, se necessario, emettere un giudizio relativo alla sicurezza.

2) Poiché i principali lettori di tali politiche di sicurezza sono umane e le dichiarazioni sono in genere molto generali, potrebbe non essere in una forma leggibile dal computer. Tuttavia, potrebbero esserci un paio di documenti definiti in base alla politica, ovvero linee guida, procedure e manuali di sicurezza. Sono nell'ordine del livello crescente di dettagli su come la sicurezza dovrebbe essere effettivamente implementata. Ad esempio, i requisiti definiti nella politica di sicurezza possono essere realizzati in manuali di tempra per diversi sistemi operativi, in modo che Amministratori e Ingegneri possano eseguire efficientemente le attività di indurimento senza spendere troppo tempo a interpretare le riflessioni della direzione. I manuali di indurimento possono quindi essere trasformati in un insieme di configurazioni leggibili dalla macchina (ad esempio, lunghezza minima della password, numero massimo di accessi falliti prima del blocco dell'account, ecc.) Che automatizzano le attività di indurimento.

3) Il documento deve essere reso accessibile a tutti i soggetti coinvolti e regolarmente rivisto dalla direzione.

4) Praticamente potrebbe essere difficile fare tali riferimenti. Le politiche di sicurezza potrebbero essere aggiornate di volta in volta e probabilmente non si desidera ricompilare il programma se le modifiche apportate ai criteri influiscono solo su alcuni parametri. Tuttavia, è bello fare riferimento alla politica nei documenti di sviluppo come design sepc.

Un altro tipo di "politica di sicurezza" potrebbe semplicemente riferirsi a quei gruppi di parametri che sono i programmi di sicurezza. Ho scoperto che alcuni programmi di sicurezza amano davvero usare la parola "policy" per rendere le loro configurazioni più organizzate e strutturate. Ma in ogni caso, queste "politiche di sicurezza" sono in realtà solo valori e/o istruzioni per i programmi di sicurezza da seguire. Ad esempio, Windows ha il proprio set di "politiche di sicurezza" per l'utente per configurare le registrazioni di controllo, i diritti utente, ecc. Questo tipo di "politiche di sicurezza" (parametri per programmi) viene effettivamente definito in base al 1 ° tipo di "politiche di sicurezza" (requisiti della direzione) come menzionato sopra.

Potrei scrivere troppo su questo. Spero che sia d'aiuto.

Problemi correlati