이전     다음      처음   상세목차  

2 서론: Why Security? How?

• 2.0 보안이란?
• 2.1 왜 IT 보안이 필요한가?
• 2.2 왜 보안 정책이 필요한가?
• 2.3 당신의 시스템은 안전합니까?
• 2.4 보안을 개선하기 위한 방법
• 2.4.1 아래에서 위로의 접근(Bottom Up Approach)
• 2.4.2 위에서 아래로의 접근(Top Down Approach)
• 2.4.2.1 개요
• 2.4.2.1.1 공식 위험분석 방법(e.g. MARION)
• 2.4.2.2 위협+영향+가능성 =위험
• 2.4.2.3 위협의 원천
• 2.4.2.4 영향
• 2.4.2.5 제약조건 분석
• 2.4.2.6 위험 요약
• 2.4.2.7 대응 전략 & 대응 방법

2.0 보안이란?

업무의 연속성과 정보시스템의 올바른 작동은 대부분의 사업에서 중요한 문제이다. 전산화된 정보와 절차에 대한 위협은 업무의 품질과 효율성에 대한 위협이나 마찬가지다. IT 보안의 목적은 심각한 위협을 없애거나 수용가능한 수준으로 끌어내릴 수 있는 조치를 취하는 것이다.

보안과 위험관리는 품질관리와 밀접하게 연관되어 있다. 보안 방책은 위험분석에 근거하여 이행되어야 하고 품질구조, 절차 및 체크리스트와 조화를 이루어야 한다.

무엇으로부터, 어떻게, 무엇을 보호해야 하는가?

보안은 재난, 실수 및 부정한 조작으로부터 정보, 시스템 및 서비스를 보호하여 보안 사고의 가능성과 영향을 최소화 하는 것이다. IT 보안은 다음과 같이 구성된다:

기밀성: 민감한 업무대상 (정보 &절차)은 오직 인가된 사람들에게만 공개되어야 한다. ==> 대상에의 접근을 제한하기 위한 제어가 필요하다.
무결성: 대상(정보 및 절차)에 대한 변경을 제어해야 한다.==> 대상이 정확하고 완전하다는 것을 보장하기 위한 제어가 필요하다.
가용성: 권한 있는 사용자는 필요할 때 항상 업무대상 (정보 및 서비스)을 사용할 수 있어야 한다.==> 서비스의 신뢰도를 보장하기 위해 제어가 필요하다.

위협은 자산의 보안(기밀성, 무결성, 가용성)을 해쳐 잠재적인 손실이나 손상을 가져올 수 있는 모든 종류의 위험(danger)을 말한다.

2.1 왜 IT 보안이 필요한가?

대부분의 기업들은 일상적인 업무수행을 지원하는 데 전자적 정보를 광범위하게 사용하고 있다.데이터는 고객, 제품, 계약서, 재무결과, 회계 등에 저장된다. 이러한 전자적 정보가 경쟁자의 손에 들어가거나, 손상되어 틀려지거나 사라진다면 어떻게 될까? 그 결과가 무엇 이겠는가? 그래도 업무가 정상적으로 수행될 있을까?

• 고객정보나 회계정보가 공개되어 신용을 떨어뜨릴 수 있다.
• (새로운)경쟁자가 이 정보를 이용하여 더 효과적인 마케팅 캠페인을 벌일 수 있다.
• 경쟁자들은 보이지 않지만 효과적인, 증명하기 어려운 공격을 시작할 수 있다. 그러한 공격이 고객 서비스를 중단시키고, 과금데이터를 파괴했다면 고객의 신뢰를 잃을 것이고 경쟁자는 자신의 시장 점유율을 높이게 될 것이다.
• IT 시스템은 지금까지 수십년동안 공격을 받아왔다. 하지만 이렇게 많은 컴퓨터들이 네트웍으로 연결된 적은 일찌기 없었고, 저렴하고 자동화된 수많은공격 무기들을 이렇게 손쉽게 구할 수 있던 적도 없었다. 당신이 지금 공격을 받고 있는지, 또 누구로부터 받고 있는지 알기란 종종 불가능하거나 매우 어렵다. 공격자들은 지난 5-10년새 엄청나게 세련 되어졌다. 지난 2년간 많은 자동화 공격 도구들이 인터넷에 출현하면서 무지한 공격자들도 막대한 손해를 입히기기가 매우 쉬워졌다.
• 몇년 전만해도 지능적인 집단에서만 구할 수 있던 많은 무기들을 이제는 돈을 주고 살 수 있다.
• 바이러스는 지난 몇년 간 놀랄만한 속도로 개발되어 피해를 입지 않은 기업이 거의 없다.
• 시스템간 상호연결로 인해 보안 위험이 매우 높아졌다:

"네트웍은 컴퓨터다" 라는 문구는 선 마이크로시스템이 80년대 중반에 만들어낸 말인데, 지금은 그때보다도 더욱 맞는 말이 되었다. 단일시스템 (e.g., 메인프레임)에서 돌아가던 어플리케이션은 서로 다른 시스템에서 돌아가는 여러개의 co-operating 모듈로 옮겨갔다. 전형적인 예가 바로, UNIX 게이트웨이를 거쳐 메인프레임에 있는 데이터에 접근하는 PC클라이언트로 구성된 클라이언트 서버 어플리케이션이다. 그러한 어플리케이션이 안전하려면 PC, UNIX, 메인프레임, 네트웍이 안전해야 한다. 클라이언트 서버 환경에서의 보안은 각각의 컴퓨터에서 전혀 다른 인증기법을 쓰고 있기 때문에 복잡하다. 클라이언트-서버 어플리케이션은 구성요소들간의 연결고리중 가장 약한 부분의 보안에 따라 보안 수준이 매겨진다,.예를들어 패스워드가 PC에서 읽을 수 있는 형태로 되어 있거나 종이에 씌어서 PC 화면에 붙여져 있다면, 아무리 안전한 메인프레임이라 해도 무슨 의미가 있겠는가?

다음 숫자들은 현실적으로 어떤 일들이 벌어지고 있는 지 알려주기 위해 예시하는 것이다. (source: Datapro Research)

• 손해(damage)의 일반적인 원인 : 인간의 실수 52%, 부정직한 사람들 10%, 기술적인 파괴 행위10%, 화재 15%, 수해 10% 그리고 테러리즘 3%.
• 누가 손해를 입히나?: 현재 직원 81%, 외부인 13%, 예전직원 6%.
• 컴퓨터 범죄의 유형: 금전적 절도 44%, 소프트웨어 손상 16%, 정보의 절도 16%, 데이터 변조 12%, 서비스 절도 10%, 불법침입 2%.

IT 보안 요구사항[ITSEC]은 종종 다음 항목으로 규정된다:

보증: 시스템이 기대되는 대로 (즉 자기 사양에 따라) 동작한다는 확신
확인/인증: 사용자나 프로그램이 서로 통신할 때 양쪽은 서로 상대방을 확인해야 한다.
책임추적성(Accountability)/추적감사: 누가 무엇을 언제 어디서 했는지 알 수 있는 능력. 사용자들은 자기의 행동에 대해 책임이 있다. 보안 침해를 탐지하기 위한 자동 추적감사. 감시(monitoring)와 분석
접근통제: 특정 자원에 대한 접근은 정해진 개체들에게만 허용된다.
객체 재사용: 한 프로세스에 사용된 객체가 보안이 위반될 수 있는 다른 프로세스에 의해 재사용되거나 조작될 수 없다.
정확성: 객체(정보 및 프로세스)는 정확하고 완전해야 한다.
안전한 데이터 교환:

• 기밀성: 데이터가 전송되는 동안에 비밀성을 유지해야 (공개되지 않아야) 한다.
• 무결성: 데이터가 전송되는 동안에 정확성과 완전성을 유지해야 한다.
• 이메일을 보낼 때나 프로그램간에 서로 통신할 때, 인증 (위 참조)이 필요하다.
• 어떤 경우에는, 정보가 어디에서 왔는지를 증명하는 것이 필요할 수도 있다. 이것을 송신(발원)지 부인방지라고 한다. 송신자도 마찬가지로 정해진 수신자가 메시지를 받았는지에 대한 증빙을 필요로 할 수 있다 - 수신 부인방지.

안전한 통신을 위해 사용되는 방법 중에는 축약, 공개키 암호화, 전자서명 및 챌린지-응답 (challenge-response) 등이 있다.

서비스 신뢰성: 데이터 및 중요한 서비스는 필요할 때 사용가능해야 한다.

어떤 시스템은 기밀 데이터를 가지고 있진 않지만 24시간 사용가능해야 할 수도 있다 - 즉 낮은 데이터 민감성과 높은 가용성이 요구된다. 고가용성 시스템들은 "서비스거부" 공격을 방지하기 위해 항상 높은 기밀성이 요구된다. 어떤 시스템들에게는 기밀성(즉 비밀성 또는 정보의 비공개)이 무결성(정보의 불법 변조)보다 더 중요하고, 또 다른 시스템들에게는 그 반대가 성립된다. 서로 다른 요구사항을 가지는 시스템들은 서로 다른 방법으로 보호되어야 한다.

과다한 보안 (사용이 극히 제한적이고 비용이 많이 드는)과 과소한 보안(사용에 제한이 없고, 위험하고, "겉으로 보기에는" 비용이 적게 드는)사이에서 균형을 찾아야 한다.

적절한 대응책을 구현하기 위해서는 정보와 프로세스의 가치를 알아야 하고, 현재 환경에서의 위험을 분석해야 한다. 대응책의 초석은 위험분석과 보안정책 이다.

2.2 왜 보안정책이 필요한가?

A 보안정책은 중요한 회사 정보와 프로세스를 보호하기 위한 예방장치이다. 보안정책은 일관성있는 보안 표준을 사용자, 경영층 및 기술진들에게 전달한다.

• 정책은 현 시스템의 상대적 보안을 측정하는 데 사용될 수 있다.
• 정책은 외부 협력사들과의 인터페이스를 정의하는 데 중요하다.
• 고객 및 직원 데이터 보호와 관련하여 필수적인 법적 요구사항들이 있다.
• 정책은 품질 관리의 선수요건이다.(ISO 900x). 

2.3 당신의 시스템은 안전합니까?

영국표준협회[bsi1]에서는 기본적인 보안이 구현되어 있는지를 체크하는 10개의 핵심 관리사항에 대한 목록을 발표하였다:

1. 정보보호정책 문서
2. 정보보호 책임에 대한 할당
3. 정보보호 교육 및 훈련
4. 보안사고의 보고
5. 바이러스 통제
6. 사업연속성을 위한 프로세스
7. 소프트웨어 불법복제에 대한 통제
8. 조직의 기록에 대한 보호수단
9. 데이터 보호 법규의 준수
10. 정보보호정책의 준수

위 사항중 현재 환경에 적용되어 있는 것은 몇가지나 되는가? 

2.4 보안을 개선하기 위한 방법

보안을 개선하려면:

=> 어떤 데이터와 프로세스를 보호해야 하는지 식별한다.
=> 위협을 인식하고 위협이 미칠 수 있는 영향을 판단한다.
=> 위험을 산정하고 어떤 위험은 받아들일 수 있는 지 결정한다.
=> 대응책: 위험을 수용가능한 수준으로 끌어내리기 위한 전략을 세우고, 구현하고, 테스트 한 후 조정한다.

• 단순하게 한다. 보안이 너무 복잡하면 효과적이지도 않고 비용만 많이 든다.
• 일관성을 유지한다. 어떤 시스템은 아주 많이 보호되고 나머지는 모두 열려있는 것보다는 최소한의 일관된 보안수준을 유지하는 것이 더 낫다.
• 가능한한 표준을 지킨다(e.g. BSI, ITSEC, TCSEC), 그것이 시스템을 쉽게 선택하고 평가할 수 있게 해주며 기업간 표준을 제정하는 일도 더 쉬워진다.

보안 개선을 위한 두 가지 기본 접근방식이 있는데, 아래에서 위로 (Bottom Up) 올라가는 방식과 위에서 아래로(Top Down) 내려오는 방식이 있다.

2.4.1 아래에서 위로의 접근

이 접근법이 더 빠르긴 하지만 아주 정확하지는 않다.

무엇을, 누구로부터, 어느정도까지 보호하고 싶은지 알고있다면:

• 현재 어떤 정책, 네트웍 토폴로지, 운영절차 및 사용자 업무가 사용되고 있는지 파악한다.
• 공격 프로파일을 생성해 본다. 즉, 당신이 공격자라면 어떤 방법으로 회사를 공격할 것인가? 외부에 연결된 네트웍이나 모뎀, 기타등등에서 볼 수 있는 네트웍/시스템은 어떤 것들인가? 중요한 시스템은 어디에 보관되고 있으며 물리적으로 어떻게 접근할 수 있는가? 직원들을 어떻게 설득하면 패스워드를 알아낼 수 있을까? 공격자처럼 생각하다보면 생각지도 못했던 가능성(즉 취약점)들이 발견될 것이다!
• 위의 두 단계에서 나온 약점들을 요약하고, 어떤 약점과 미래의 위협에 대해 방어할 것인지 짧은 목록을 만든다.
• 정보정책을 정의한다 (아직 없다면). 정보를 분류한다. 어떤 정보가 가장 중요한지를 판단한다. 정책을 배포하고 사용자들을 교육한다.
• 사용자 정책을 만들고 배포하며 교육한다.
• 서버 및 네트웍(또는 그밖에 감지된 취약지점)의 안전한 설치, 유지보수 및 를 위한 기술적 지침을 만든다. 민감한 시스템들에대해 정기적으로 감사를 실시한다.

2.4.2 위에서 아래로의 접근

2.4.2.1 개요

이 접근법은 조직적이고 더 정확하지만, 느려질 수 있고 초기비용이 많이들 수 있다. 보안이 "시급히" 개선되어야 한다면 두가지 방법을 병행하는 것이 좋다. 즉 중요하고 "잘 알려진" 시스템에 대해서는 아래에서 위로(bottom up)의 접근방식을 선택하고, 경영층이 지원하고 이해하는 장기적이고 정확한 보안관련 정책, 전략 및 비전을 얻기 위해서는 위에서 아래로(top down)의 접근방식을 쓴다.
위에서 아래로의 접근방식에는 다음과 같은 것들이 포함된다:

1. 자산분석: 무엇이 보호되어야 하는가? 정보와 프로세스 (중요한 자산은 무엇인가? 컴퓨터에 저장되어 있는가? 이 자산을 잃을 경우 금전적인 손실은 얼마나 되는가?)를 나열한다. 자산을 보호하기 위한 수단은 자산의 가치에 상응해야 한다.
2. 현재의 보안 규칙/정책/관레를 분석한다(있다면).
3. 기본적인 보안 목표: e.g. 기본적인 가용성, 기밀성, 무결성의 목표를 결정한다.
4. 위협 분석: 시스템을 어떻게 보호할 지 결정하기 전에, 어떤 시스템을 보호할 지, 즉 어떤 위협으로부터 보호할 지를 알아야 한다. 위협을 식별한다(직원의 앙갚음,해커, 첩보활동,기술적 장애 등). 나중에 위협의 실례들이 열거된다. 위협은 본질적으로 일반화되는 경향이 있다.
5. 영향분석:
• 하나의 위협, 또는 여러 복합적인 위협들이 실현되었을 때 그 영향 또는 결과 (사업에 미치는 손해)는 무엇인가? 이것은 시스템에 따라 다르다. 예를들면 회사 비밀의 유실, 회계제이터의 변조, 송금 위조 등이다.
• 그 영향은 기술 전문가가 아닌 업무 전문가가 판단해야 한다.
• 영향은 두 가지 요소를 가진다, 단기적 영향(위협이 단기적이다)과 장기적 영향(위협이 지속되면서 사업에 장기적으로 영향을 미친다). 종합적인 영향은 장단기로 구분하여 숫자 (0-5)로 표현된다.
1. 영향이 무시할 만하다.
2. 영향이 적다, 주요 사업기능은 영향을 받지 않는다.
3. 사업기능이 일정시간동안 중단된다. 매출 손실이 있고 고객의 신뢰도에 약간의 영향이 있다 (고객을 잃을 정도는 아니다).
4. 사업기능이나 고객 신뢰도 또는 시장점유율에 중대한 손실이 발생한다. 고객을 잃게 될 것이다.
5. 재난에 가까운 영향으로, 비싼 대가를 치루지만 어쨌든 회사는 살아남게 될 것이다.
6. 파멸적인 영향으로, 회사는 살아남지 못하게 된다.

6) 위험을 산정한다:

• 위협이 발생할 가능성은 얼마나 되는가 (0-5)? 위협이 발생할 가능성에 대해서는 기술전문가들이 업무전문가보다 아마 더 잘 결정할 것이다.
1. 위협이 발생할 가능성이 거의 없다
2. 위협이 일년에 한 번 미만으로 발생할 수 있다.
3. 위협이 일년에 한 번 정도 발생할 수 있다.
4. 위협이 한달에 한 번 정도 발생할 수 있다.
5. 일주일에 한 번 정도 발생할 수 있다.
6. 매일 발생할 수 있다.

• 위험 = 영향 * 가능성
• 위험은 최소값 0(위험 없음)부터 최대값 25(극히 위험)까지의 값을 가질 수 있다. 위험수치가 높을수록 대응책을 구현하는 것이 중요해진다.
• 감수할 수 있는 위험수치를 정해야 한다. 이 숫자보다 높은 값을 가지는 위험들은 모두 수용 불가능한 것들이며 대응을 해야 한다. 여기서는 (잠정적으로) 감수할 수 있는 위험=15 로 정한다.

7) 제약조건 분석: 당신의 통제 밖에 있는 요구사항들을 조사한다(국가 및 국제법, 기업의 요구사항, 기업문화, 계약조건, 예산 등).

8) 대응전략을 결정한다:

• 보안의 목적을 정의한다.
• 대응 수단을 정의한다. (e.g. 정책, 역할, 프로세스, 책임, 공정(메커니즘))
• 이 전략으로 위험을 수용가능한 수준까지 끌어내릴 수 있는가? 비용이 너무 많이 드는가?
• 아니라면, 나머지 위험들에 대해서는 적은비용으로 지킬 수 있는가?
• 그렇지 않다면 전략을 다시 짠다.

9) 구현:

• 정보 분류 시스템과 함께 정책과 지침을 개발한다.
• 보안 조직을 정의한다(또는 현 조직을 수정한다). 사용자,시스템 관리자 및 관리자들의 역할과 책임이 명확하게 정의되고 당사자들에게 인지되어야 한다.
• 파일럿 테스트를 진행한다. 정책과 프로세스, 조직을 결과에 따라 조정한다.
• 그 후 광범위하게 시스템들에 대해 보안을 적용한다.

10) 보증: 위험과 보안전략을 정기적으로 재평가한다(e.g. 2년에 한 번씩).

2.4.2.1.1 공식 위험분석 방법 (e.g. MARION)

위에서 말한 방법은 공식적으로 승인된 방법론이 아닌 임시변통적이고 "뻔한" 방법이다. .  많은 공식 방법들이 있는데, 아래에서는 Marion에 대해 설명한다. 유럽 보안 포럼(THe European Security Forum)도 괜찮은 것을 하나 가지고 있긴 하지만 아직 자세히 살펴보질 않았다.

MARION[1]이라고 알려진 공식 IT 위험분석방법은 기업에서 top-down 위험분석 및 보안을 구현하기 위한 좋은 시작점이 된다. 이 방법은 1984년 프랑스에서 개발되었으며 기업을 집중분석하는 데 있어 최고경영층을 참여시키는 등 실용적으로 설계되었다. 1992년에, 특히 프랑스에서, 800개가 넘는 프로젝트에 사용되었다.

이 공용 방법론은 프랑스 컴퓨터 보안 클럽 CLUSIF와 보험조직인 APSAD에 의해 매년 통계치와 함께 갱신되고 있다.

MARION 위험분석을 수행하는 Coopers & Lybrand 같은 회사에 가면 참고가 될 것이다. 연락처는 부록 C를 보기 바란다.

2.4.2.2 위협 + 영향 + 가능성 = 위험

시스템을 어떻게 보호할 지 결정하기 전에, 어떤 시스템을 보호할 지, 즉 어떤 위협으로부터 보호할 지를 알아야 한다. 다음 절에 여러 유형의 위협이 설명되어 있다.

위협은 다음 범주들로 나뉘어진다: 일반, 확인/인증, 가용성, 비밀성, 무결성/정확성, 접근제어, 부인, 법률

이 절에서는 다음의 것들을 포함하는 표를 제시한다: 위협(설명을 포함한), 위협의 영향(영향 표에 대한 참조표시)과 수치(0-5) 및 위협 발생 가능성(0-5의 수치).

일반적 위협:
 

확인/권한부여(인가) 위협:
 

서비스 신뢰도 위협:
 

프라이버시 위협:
 

무결성/정확성 위협:
 

접근제어 위협:
 

부인 위협:
 

법적 위협:
 

2.4.2.3 위협원

2.4.2.4 영향

영향은 사업에 따라 달라지며, 자산, 사업유형, 현재 대응책(IT 하부구조)에 의존적이다. 영향응 위협으로 인한 결과를 나타낸다. 영향은 또 업무기능이 방해받은 시간과도 관계가 있다.
다음은 기업이 받기쉬운 몇몇 기본적인 영향들이다. 사업을 상세히 이해하고 있는 관리자들에 의해 자세한 내용이 완성돠어야 한다.
 

2.4.2.5 제약조건 분석

자신의 통제를 벗어나는 필요조건을 검사한다:

• 외설, 직원사생활 및 고객 데이터, 명예훼손 등 화제가되는 국가, 국제법들을 고려해야함
• 회사의 필요조건 (미션, 전략 등)
• 예산 (돈이 목표가 아닌 이상!). 

2.4.2.6 위험 요약

위협, 영향 및 해당위험이 나열되고 제약조건이 분석되면, 주요 사업위험(또는 취약점)이 좀더 명확해질 것이고, 이에 대한 대응 전략이 개발될 수 있다.

대응할 위험을 하나의 표로 요약하는 것이 좋다. 마찬가지로 주요 강점을 요약해 놓으면 현재까지 어떤것들이 달성되었는지 볼 수 있을 것이다.

주요 위험/취약점 목록의 한 예로:

• 경영진이 거의 보안조치를 장려하거나 지원하지 않는다.
• 부적절한 정보보호정책이 있고 정보가 분류되어 있지 않다.
• 사용자들이 보안의식이 없고 대개 나쁜 패스워드를 사용한다. 사용하지 않는 단말은 거의 보호되지 않는다.
• 동종, 표준 소프트웨어로 설치된 컴퓨터가 거의 없다. 대부분의 사용자들이 자기가 원하는 것을 설치한다.
• 회사의 인터넷접속이 취약한 방화벽, 소수의 접근제어 메카니즘으로 구성되어 있고 감사로그,공식정책 및 모니터링/침입탐지나 사고대응팀이 없다.
• 잠겨진 컴퓨터룸에 있지 않는 서버들이 몇몇 있고, 백업전원, 공기조절장치나 정전기/전자파 보호장치가 없다.
• 문서화된 컴퓨터 운영절차가 거의 없다.
• 오프사이트 백업이 없다.
• 직원들이 제대로 구분되지 않고 방문객들이 아무런 저지없이 돌아다닌다. (방문잭에 대한 절차가 없고 건물보안이 없다.)
• 건물이 지진지역-30년에 한번정도 약한 지진이 일어나는정도의-에 있다.
• 네트웍 통제실이 지하에 있어 큰 폭우시 홍수가 날 우려가 있다. 

2.4.2.7 대응전략 & 대응조치

위의 위험 요약을 기초로 전략을 개발한다:

• 위험을 제거하거나
• 위험을 수용가능한 수준으로 줄이거나
• 손실을 제한 (위협의 영향을 축소)하거나
• 손실을 메우기(보험) 위한 전략개발

대응전략에는 주로 다음과 같은 것들이 포함된다: 보안정책, 보안조직(책임,역할 & 프로세스) 및 특정한 메카니즘

1. 위험분석결과에 기반을 둔, 정보보호 정책("정책" 장 참조). 정책은 위험을 줄인다.
• 정책의 구현: 역할, 책임 및 조직이 필요하다(다음 장 참조) 보안조직은 위험을 줄이고 손실을 제한할 수 있다.
• IT 보안조직에는 명확한 미션과 전략이 명문화 되어 있어야 한다.
• 보안 역할 & 프로세스 등의 정의
• 사용자, 운영관리자(administrators) 및 관리자(managers) 들은 역할/책임이 명확히 정의되어 있고 이를 숙지하고 있어야 한다.
• 사용자 / 지원 인력이 부여된 책임을 맡을 수 있도록 교육훈련이 필요할 수 있다.
• 메카니즘 필요조건 정의: 보안적용을 위한 메카니즘과 프로세스의 효과적인 사용. 적절한 보안 메카니즘 선택과 안전한 운영절차는 위험을 감소시킬 수 있다. 필요조건은 다음의 제목(ITSEC 권고) 아래 나열되어야 한다. ITSEC은 또 메카니즘과 대응책의 강점을 기본, 중간 또는 높음으로 등급을 매기도록 권고하고 있다.
• 확인과 인증
• 책임
• 감사
• 접근제어
• 객체 재사용
• 정확성
• 데이터 교환
• 서비스의 신뢰성
• 특정 시스템들에 대해 견고한 보안운영 지침과 규제를 정의한다 (III부를 볼 것)
• 위의 방법들로 처리할 수 없는 위협들에 대해 보험을 고려한다.
• 보증 / 부단한 경계:
• 중요한 시스템들에 대해서는 정기적인 감사를 실시한다. 대응책들은 얼마나 효과적이며, 조율이 필요하지는 않은가?
• 위험을 정기적으로 재고한다. 새로운 위협들이 더 중요한가, 없어진 위협들은 있는가? 위험과 전략은 정기적으로 재고되어야 한다. (일년 또는 이년에 한번씩)

[1] M?hodologie d'Analyse des Risques Informatique et d'Optimation par Niveau

                 Previous     Next      Top   Detailed TOC