Sikkerhetsarkitektur for Forsvarets informasjonsinfrastruktur - en innledende studie av rammeverk og begreper

Publisert
2017-07-14
Emneord
Virksomhetsarkitektur
Informasjonssikkerhet
Risikovurdering
Sikkerhetsarkitektur
Rapportnummer
17/01169
Permalenke
http://hdl.handle.net/20.500.12242/1246
Samling
Rapporter
17-01169.pdf
Size: 1M
Sammendrag
Mange nye kapabiliteter som ønskes realisert i Forsvaret, forutsetter ny funksjonalitet i informasjonsinfrastrukturen. Men for å oppnå ønsket operativ evne, må tilstrekkelig sikkerhet være på plass for å beskytte mot aktuelle trusler. Dette har en økonomisk kostnad og kan sette begrensinger på hva som kan realiseres i praksis av ønsket funksjonalitet. Det er også vanskelig å vurdere hva som er tilstrekkelig sikkerhet for en gitt funksjonalitet og for informasjonsinfrastrukturen som helhet. En helhetlig sikkerhetsarkitektur har lenge blitt nevnt som en mulig tilnærming for å håndtere kompleksiteten rundt informasjonssikkerhet i Forsvaret. Med arkitektur menes en strukturert tilnærming til planlegging og utvikling av komplekse systemer over tid, samt en formell beskrivelse eller detaljert plan på komponentnivå. Man kan da tenke på en sikkerhetsarkitektur som en beskrivelse av tekniske sikkerhetsløsninger og de prinsippene og retningslinjene som styrer deres utvikling. Disse løsningene skal både være konsistente på tvers av Forsvaret og samtidig sørge for at informasjonsinfrastrukturen som helhet kan operere innenfor et akseptabelt risikonivå. For å sikre dette er det nødvendig å se sikkerhet i et bredere perspektiv. En helhetlig sikkerhetsarkitektur skal sørge for at sikkerhetsarbeidet forankres i virksomhetens strategiske mål og behov og at også ikke-tekniske aspekter blir identifisert og integrert i planlegging og utvikling av sikkerhetsløsninger. Slike aspekter kan for eksempel være forretningsprosesser, kontekster som virksomheten opererer i, lover og regelverk, økonomiske rammer, eller nye teknologiske muligheter. Til tross for at det finnes flere rammeverk som definerer verktøy, metoder og modeller for å bygge en slik arkitektur, er det likevel utfordrende å realisere den i praksis. Generelt er det vanskelig å vurdere og måle risiko, noe som er sentralt i alt sikkerhetsarbeid. I tillegg er det uklart hvordan sikkerhetsarkitektur og virksomhetsarkitektur skal integreres. Vi diskuterer derfor relevante utfordringer knyttet til risikovurdering, og på bakgrunn av dette diskuterer vi eksisterende rammeverk for virksomhetsarkitektur og sikkerhetsarkitektur. Rapporten gir også en kort beskrivelse av de viktigste dokumentene som gir føringer for informasjonssikkerhet i Forsvaret, siden de er med på å definere rammene for en sikkerhetsarkitektur. Vi konkluderer med at et arkitekturrammeverk kan gi oss metoder og verktøy, men Forsvaret må selv avgjøre riktig omfang og utforming av arkitekturarbeidet for å dra nytte av det. Erfaringsmessig er rammeverkene for omfattende og generiske til å brukes slik de er, og tilpasningsbehovet er derfor stort. Det er viktig at det er målene en virksomhet vil oppnå med sikkerhetsarbeidet, og ikke selve rammeverkene, som danner grunnlaget for en arkitektur. Faren er ellers at man fokuserer for mye på arkitekturmetoden og glemmer de underliggende problemene den skal hjelpe med å løse.
Many new capabilities that the Armed Forces intend to implement require new functionality in the information infrastructure, but in order to achieve the desired operative effect, adequate security must be in place to protect against relevant threats. This has an economical cost and can limit the functionality that can be implemented in practice. It is especially challenging to determine the adequate level of security both for capabilities and for the infrastructure as a whole. A comprehensive security architecture is an approach that has long been mentioned as a possible way to address the complexity of information security in the Armed Forces. Architecture is a structured approach to planning and developing complex systems over time, as well as a formal description or detailed plan at the component level. One can then think of a security architecture as a description of technical security solutions, as well as the principles and guidelines that govern their development. However, in order to ensure that these solutions are consistent across the Armed Forces, and that the information infrastructure as a whole operates within an acceptable risk level, one needs to see security in a broader perspective. A comprehensive security architecture should ensure that security supports the enterprise’s strategic goals and needs. It should also ensure that relevant aspects apart from the technical ones are identified and integrated in the planning and developing of security solutions. Such aspects can for example be business processes, laws and external regulations, the contexts the enterprise operates in, or new technological possibilities. Despite the fact that there are various frameworks that define tools, methods and models to build such a security architecture, it is still challenging to implement one in practice. One reason is that it is difficult to assess and measure risk in general, something that is central to all security work. Another is that it is unclear how security architecture and enterprise architecture should be integrated. Therefore, we discuss relevant challenges associated with risk assessment, and based on this we present existing frameworks for enterprise and security architecture. The report also briefly describes the most important documents concerning information security in the Armed Forces, as they may help define the scope of a security architecture. We conclude that while the frameworks can provide the methods and tools to build an architecture, the Armed Forces must themselves decide the correct scope and form of the architecture work in order to benefit from it. From experience, these frameworks are too comprehensive and generic to be used as they are, and require significant adaptations. It is therefore important that an enterprise’s information security goals form the basis for an architecture – not the frameworks. Otherwise, the danger is to focus too much on the architecture method instead of the problems it should help solving
View Meta Data