Questa domanda a Owasp Scotland questa sera non ha avuto risposte utili.
C'è troppa specializzazione nella sicurezza ora che significa che gli architetti delle imprese non possono conoscere abbastanza la sicurezza della consegna come parte del loro lavoro giornaliero?
La mia prima osservazione è che la sicurezza è responsabilità di tutti. Nessuna persona sarà in grado di controllare la base di codice di un'intera organizzazione. Il design della sicurezza e la progettazione aziendale sono intrinsecamente diversi per scopo e obiettivo, ma i due devono interagire strettamente per ottenere i migliori risultati. L'obiettivo di un architetto aziendale è quello di progettare un sistema che soddisfi le esigenze aziendali e rappresenti i processi aziendali in modo accurato e di creare uno schema coerente per l'implementazione di tale funzionalità. Uno degli obiettivi degli architetti della sicurezza è progettare un modello di sicurezza e fornire un modello coerente per la sua implementazione e applicazione.
In un ambiente vasto, la semplice scala di questi due compiti potrebbe meritare diverse persone che lavorano su di loro e potrebbe esserci un leggero guadagno in relazione alla separazione delle responsabilità tra il processo aziendale e il processo di sicurezza, ma in generale non lo faccio Non vedo alcun motivo valido per cui qualcuno con una serie di abilità incrociate non possa fare entrambe le cose. (Dico questo come un architetto software aziendale con uno sfondo in sicurezza design.)
Per pubblicare una vista contraria all'eccellente risposta di AJ:
In una grande azienda, l'architettura può diventare responsabile di più team in diversi dipartimenti, paesi, regioni ecc. per essere performante per ogni regione, mentre la sicurezza aziendale è probabilmente gestita da una prospettiva globale per ridurre rischio per l'organizzazione nel suo complesso.
Quindi tendo a favorire l'idea che l'architettura della sicurezza sia una sottocategoria dell'architettura o della sicurezza, con professionisti che lavorano con architetti aziendali al fine di raggiungere il meglio dalla soluzione dei due mondi (o del compromesso).
Innanzitutto, se parli di discipline all'interno dell'architettura Enterprise, presumo che tu parli di questi quattro:
Ovviamente esistono molte sotto-discipline, ma penso che quello sopra indicato sia quello che viene usato più spesso (anche quello usato da TOGAF).
Considerando che la sicurezza è un aspetto molto importante, penso che fornisca una visione troppo dettagliata per essere compresa come disciplina extra, accanto ai quattro sopra citati. L'architettura aziendale fornisce una vista sulla struttura dell'organizzazione, compresa nei suoi processi aziendali, oggetti (informazioni) dati, applicazioni e infrastruttura. Tutti questi devono essere sicuri, ma devono essere molto di più, a seconda degli obiettivi che l'organizzazione ha stabilito.
Se l'organizzazione non ha impostato la sicurezza come obiettivo (il che significa che non appare mai nella colonna delle motivazioni nella Zachman ), quindi NON deve essere tradotto in un processo, un oggetto dati, un'applicazione o un'infrastruttura. Questo è uno dei motivi principali per cui l'architettura di sicurezza non deve essere considerata una disciplina separata all'interno di EA: La sicurezza non fa parte della struttura di base di un'organizzazione, piuttosto la sicurezza è una scelta che può essere fatta su la struttura .
Questo non vuol dire che l'architettura di sicurezza non sia importante. Come confronto: un processo aziendale deve essere efficiente. Perché ha bisogno di essere efficiente? Perché è ovvio, anche se teoricamente dovrebbe essere efficace solo se c'è una motivazione (Zachman, ancora una volta) per rendere efficiente quel processo. Lo stesso vale per la sicurezza. Un'applicazione dovrebbe essere sicura, perché è ovvia (per noi). In teoria, tuttavia, dovrebbe esistere una motivazione a rendere sicura l'applicazione (o il processo aziendale, i dati o l'infrastruttura).
Per terminare con una citazione dagli autori di TOGAF :
Security concerns are pervasive throughout the architecture domains and in all phases of the architecture development. Security is called out separately because it is infrastructure that is rarely visible to the business function. Its fundamental purpose is to protect the value of the systems and information assets of the enterprise.
Una citazione, che ci ricorda che la sicurezza IS è importante per gli architetti aziendali e i corrispondenti framework. Non fa parte della classificazione generale (business, dati, applicazioni, tecnologia). Certo, se la tua domanda fosse "Perché l'architettura di un'azienda non si preoccupa della sicurezza?" o "Perché le metodologie di EA non parlano mai di sicurezza?", non sarei affatto d'accordo con te, perché loro (I) si preoccupano, e le metodologie parlano di sicurezza.
Ora, nel concludere questa risposta, ho notato che in realtà non ho risposto direttamente alla tua domanda. Quindi un'ultima frase: ci sono benefici per includere la sicurezza come preoccupazione principale durante lo sviluppo di EA, e gli architetti di impresa dovrebbero già conoscere questi benefici. È solo un ponte troppo lontano per includerlo come disciplina separata accanto alle quattro sotto-discipline ben conosciute di EA.
Leggi altre domande sui tag business-risk