2. Managing Security

2.1 공격과 공격자

인터넷에서 신용 카드 결제가 먼저 고려 될 때, 그것은 고객과 판매자(merchant) 간의 트래픽을 보호되어야 하는 것을 필수적 생각했다.결국(after all), 기본 인터넷 프로토콜은 기밀성을 제공하지 않는다, 그래서 파티들은 카드 번호를 캡처 할 수 있도록 후에 사기(fraudulent) 구매를 위해 고객과 판매자 사이에 위치한다. SSL은 1990년대 중반 큰 매우를 해결하기(deal with) 위해 넷스케이프에 의해 개발되었다.

그러나 실제 위험은 다른 곳에 숨어(lurk) 있다. 신용카드 번호를 포함하는 패킷에 대한 스캐닝 인터넷 트래픽은 낮은 률의 공격이다. 고객 신용 카드 번호의 데이터베이스가 심하게 보호된 서버가 훨씬 더 가치있는(rewarding) 타겟이다. 이러한 공격은 신용 카드 번호를 얻거나 판매자를 협박(blackmail)하는 것이 증거에 기록되어 있다.

신분 도용(Identity theft), 즉 자원 또는 서비스에 접근하기 위해 어떤 다른 사람의 ‘신원’(이름, 사회 보장 번호, 은행 계좌 등)을 사용한다,비밀이 아닌 정보의 요청을 인증(authenticate)하기 위해 사용하는 서비스의 고유(inherent)의 약점을 악용한다.

인터넷 브라우저나 메일 소프트웨어 같은 소프트웨어 처리 외부 사용자 입력의 취약점은 외부 파트들이 장치들을 제어 할 수도 있다. 공격자는 장치 자체에 대한 데이터 손상 또는 써드파티에 대한 공격을 위한 디딤돌로 사용할 수 있다. 웜과 바이러스는 지나치게 많은(overgenerous) 기능을 사용하거나 취약점 널리 퍼지고 네트워크가 과부하(overload)되고 종단 시스템은 트래픽을 생성한다. 1988년11월의 인터넷 웜은 초창기에 잘 문서화된 종의 예이다(세션1.3.1). 특정 대상에 대한 서비스 거부 공격은 1990년대 후반에 발생하기 시작했다. 서비스 거부 공격에 대한 회복력(resilience)은 보안 프로토콜의 설계의 새로운 기준(criterion)이 되고 있다.

공격 위의 시나리오는 외부로부터 왔다. 성벽 외부에 적을 유지하는 것은 컴퓨터 보안의 전통적인 패러다임이다. 그러나 공격 소스에 대한 통계는 종종 공격이 내부자(insider)로부터 다수(a majority of)의 사건을 설명하고(account for) 손상의 큰 비율을 보여준다.

거기에 인터넷을 통해 공격이 그림을 변경할 수 있다는 제안이 있지만, 내부 사기 조직의 전자 상거래에 상당한(considerable) 우려가 남아있다.

그것은 보안 엔지니어링 비용이 공격자의 이익을 상회하는 수준으로 공격의 노력을 높이기 위한 목표로 가지고 있다고 알려져 있다. 이러한 조언은 근시안적(short sighted)일 수 있다. 모든 공격자는 돈을 위한 욕망에 동기부여 되지는 않는다. 정리해고(redundant)된 직원은 이전 고용주에 대한 복수를 할 수 있다. 해커는 그들의 기술 전문성을 입증하고(demonstrate) 자신의 방식으로 보안 메커니즘을 뚫는 것(defeating)으로 부터 특히 만족을 그릴 수 있다. ‘사이버 파괴자’는 그들의 결과(consequence)에 많은 관심이 없는 공격을 개시 할 수 있다. 정치 활동가(Political activists)들은 그들이 싫어하는 조직의 웹 사이트를 훼손할 수 있다.

시스템에 침입(break into)하는 데 필요한 전문 지식에서 유사한 차이(variance)가 있습니다. 어떤 경우에는 내부자 지식은 공격의 성공 계획을 함께 넣어야 한다. 이러한 측면에서 사회 공학이 기술적 측면보다 더 중요할 수 있다. hassling computer operators on the phone to give the caller the password to a user account is a favourite ploy. 사용자 계정에 발신자에게 암호를 주는 것은 좋은 계획(ploy)이다. 일부 공격은 깊은 기술적 이해가 필요하다. 다른 공격은 자동화되어 있으며 웹사이트로부터 다운로드 할 수 있고 그들은 약간의 통찰력(insight)과 악용되는 취약점이 스크립트 키드가 실행될 수 있다.

공격 및 공격자의 간략한 조사는 관리 보안과 관련 되었을 때 다양한 측면을 보여준다(illustrate).

 

2.2 보안 관리

보안 실무자(practitioner)는 기술만으로는 해결할 수 없는 ‘보안은 사람 문제’ 라는 것을 알고 있다. 법률 시스템은 데이터 보호 및 컴퓨터 오용(misuse) 법을 통하여 수용적 행동(acceptable behaviour)의 경계를 정의한다. 조직의 보안 책임은 그 기업이나 대학에서는 경영진과 마지막(ultimately)으로 상주한다(reside). 사용자가 협력해야 하고 조직에 규정된(laid down) 보안 규칙을 준수해야 한다. 기술적 대책의 올바른 배포 및 작동도 물론 전체 솔루션의 일부이다.

조직의 자산을 보호하는 것은 관리자의 책임이다. 자산은 제품 기획, 손님 기록, 재무 데이터 및 같은 중요한 정보가 포함 된 조직의 IT 인프라이다. 동시에 보안은 종종 자신의 작업 패턴에서 조직의 구성원을 제한하고 보안 규칙을 경시하기(flout) 위하여 잠재적인 유혹이(temptation) 있을지도 모른다 측정한다. 이것은 특히 보안 지침은 뛰어난 권위(superior authority)가 아니라 조직의 일부 다른 지점에서 오지 않는 경우에 발생하는 것은 그렇다.

따라서 강하고, 명확 보안 조치는 고위 관리직의 전폭적인지지(full support)를 가​​지고 있다. 같이 조직의 보안책임을 조직하는 것을 권장한다. 그라운드 룰을 정하고 최고 경영 책임자에 의해 서명된 간결한 정책 문서는 출발점으로서의 역할을 할 수 있다. 이 문서는 모든 사람의 고용 핸드북의 일부가 된다. 모든 회원은 보안 전문가가 될 수 있지만, 모든 구성원이 알 필요는 없다.

●보안은 자신을 위해, 조직을 위해 중요한 이유

●어떤 각 멤버가 예상되고,

●그들이 따라야 할 좋은 사례

보안 인식(awareness) 프로그램은 이 정보를 전한다(convey). 사용자의 반대는 분명히 불합리한 보안 규칙을 무시하고, 보안 전문가는 적으로써 분명히(apparently) 불합리한(unreasonable) 사용자를 다루고 있다(treating).

그들의 조직의 보안 이해 관계자로 사용자를 강제하려고 하면 자발적으로(voluntarily) 규칙을 준수하는 것(comply with)이 아니라 해결 방법을 찾기 위해 그들을 설득하는 것은 좋은 방법입니다

IT 서비스 및 제품을 개발하는 조직에서는 개발자를 위한 보안을 제공해야 한다. 보안 관련 요소와 시스템의 다른 부분과의 사이에 명확한 경계선은 거의 없습니다(rarely). 일반적으로 개발자는 서비스가 배포되는 환경 및 예상되는 위험을 인식하는 경우에는 이와 같이, 그들은 보호 메커니즘 자체를 구현하지 않는 경우에도 보호의 필요성을 강조 할 수 있도록 도운다. 개발자는 실제로 경계해야 할 중요한 데이터의 특정(certain) 범주, 예를 들면 개인 데이터는 특정 규칙 및 규정에 따라 처리해야한다. 결국 개발자는 알려진 코딩 취약점과 데이터로 유지해야한다.

 

2.2.1 보안 정책

보안 정책은 컴퓨터 보안의 핵심 개념이다.

●보안 정책 - 조직의 보안 목적을 정의하고, 무엇을 보호해야 하는지 명시하며, 보호가 어떻게 수행되어야 하는 명시할 수 있다.

예를 들어, 정책은 기업의 구내(premises)에 액세스를 규제(regulate) 할 수 있다. 제한 구역에 들어갈 권한을 누가 가지고? 보안 경비 대한 액세스를 제어하기 위해 존재해야 하나?

모두가 눈에 띄게 식별(visibly) 배지(badge)를 착용해야하나? 방문자는 항상 동반해야 하나?

그들의 가방은 확인해야하나? 언제 건물이 잠겨있나? 키에 대한 액세스 권한을 누가 있나?

정책은 문서에 대한 액세스를 규제 할 수 있다. 예를 들어 군사 세계의 비밀 문서는 충분한 허가(adequate clearance)에 의해 직원에게 전달 될 수 있다. 정책은 회사를 대신하여(on behalf of) 상업 거래(commercial transactions)를 승인하는 권한이 있는 사용자를 규정(stipulate) 할 수 있다. 정책은 특정 트랜잭션이 하나 이상의 사람이 서명해야 한다는 규정이 있습니다. 그것은 어느 정도 직원이 사적인 목적으로 기업의 IT 시스템 (웹 서핑, emial)를 사용하게 되는 것으로 정의 할 수 있다. 정책은 공격 메일을 보낸 사람이 징계에(disciplinary) 직면하는 것을 선언(declare) 할 수 있다. 정책은 고용주가 사용자 행동을 말할 수 있게 감시하도록 허락 된다.

정책은 암호의 형식 및 업데이트 간격(interval)을 정의 할 수 있다. 이것은 최신의 보안 패치가 설치되어있는 유일하게 승인 된 컴퓨터가 회사 네트워크에 연결할 수 있다는 것을 선언 할 수 있다. 정책은 중요한 전자 메일은 암호화되어야 한다는 것을 말할 수 있다. 이를 통해 사용자는 개인 정보를 수집 할 때 동의를 주고 있는지 말할 수 있다.

따라서 정책 목표의 상당한 다양성과 상세 수준이 표현 된다. 우리의 관점에서 명확성(clarity)을 유지하기 위해, 우리는 레이아웃 정의하고 조직과 자동 보안 정책을 구별한다. 정책은 목표를 주고 있다 :

●보안 정책 목표: 승인되지 않은 사용으로부터 확인된 자원을 보호하기 위한 문장

정책은 목표가 충족되어야한다는 방법을 설명해야 한다. 이것은 조직 수준에서 처음으로 할 수 있다.

●조직의 보안 정책: 조직이 자원을 관리, 보호 그리고 배포하여 보안 정책 목표를 달성하기 위한 법, 규칙들의 집합.

IT 시스템 내에서 조직의 정책은 기술적 수단에 의해 지지 될 수 있다.

●자동화된 보안 정책: 조직의 보안 정책을 위반한 경우 컴퓨터 시스템이 이를 어떻게 자원을 보호할 것인가를 명시해 놓은 것.

자동화 된 정책은 접근 제어 목록 및 방화벽 설정을 규정하고, 사용자 장치에서 실행할 수 있는 서비스를 규정하며, 네트워크 트래픽을 보호하기 위한 보안 프로토콜을 규정한다.

 

2.2 보안 관리

 

-----------------------------------------------------------------------------------------------------------------

 

2.3 위험 과 위협 분석

 

 위험은 불확실한 사건의 consequence(결과) associated(조합되었다).

 Hazard risk(위협적인 위험)은 피해를 주는 사건 또는 stock exchange(주식 거래소)에서의 재정 투자와 같은 긍정적 지출과 같은 opportunity(선택적) 위험과 관련이 있다.

 IT 위험 분석은 위협적인 위험을 look at(검사한다.) 이것은 시스템의 디자인 단계, 구현 단계, 운영 단계 동안 it can be conducted(실행될 수도 있다.) 이것은 또한 apply(적용될 수 있다.)

 

 - 소프트웨어 보안의 영역에서 새로운 컴포넌트의 개발 동안 

 - 특별히 enterprise(기업)의 IT infrastructure(기반)을 위해

 - comprehensively(광범위하게) 기업의 모든 정보 자산을 위해

 

위험 분석에 대한 literature(문헌)은 위협, 취약점, impact(영향), 자산 그리고 공격과 같은 terms(용어)를 사용한다.

이러한 용어들은 다음과 관련이 있다. 예를 들면 공격은 자산에 부정적인 영향을 끼치기 위하여 취약점을 exploit(공격하다.)

패스워드를 갈취하는 것과 같은 자산에 대한 피해는 다음 공격 단계를 facilitate(촉진할 수 있다.) 또한 추가적인 자산에 대한 피해를 야기시킬 수 있다.

리스크 분석을 위한 structured(구조화 되고) 시스템 적인 접근이 없다면, 너는 너의 위험의 광범위한 overview(개요)를 수립하는 데 실패하고, particular(특별한) 보안 문제의 상세한 손실이 증가할 위험에 처하게 된다.

 

structuring(구조적) 위험 분석에는 다양한 방법이 존재한다.

위험 분석, 위협 분석, 취약점 scoring(기록)이 necessarily(반드시) 다른 활동들인 것은 아니다.

그것들은 잠재적 피해를 assess(평가할) 때 서로 다른 초점을 express(표현하)는 것이 아니라, 같은 objective(목적)을 위해 단순히 이름만 다를 뿐이다.

informally(비공식적으로) 위험은 어떤 사고나 공격이 너의 기업에 피해를 야기시킬수 있는 가능성을 말한다.

IT 시스템에 대응되는 공격은 공격자의 목적이 성취될 때까지 시스템의 취약점을 공격하는 활동의 sequence(연속)으로 구성된다.

공격에 의해 posed(발생된) 위험을 평가하기 위하여, 너는 공격의 영향과 공격 발생의 likelihood(가능성)을 평가해야만 한다.

이러한 가능성은 잠재적 공격자에게 쉽게 공격이 실행될 수 있는 방법(취약점의 공격)과 너의 시스템이 노출시킬 것이다.

In turn(다음으로), 공격의 위험성 아래에서 이러한 가능성은 시스템의 보안 구성에 의존할 것이다.

 

시스템은 자원과 자원을 운영하는 agent(대리인)으로 구성되어 있다.

컴퓨터에서, 프로세스는 대리인을 말한다.

조직에서, 대리인은 업무를 수행할 의무를 가진 사람을 말한다.

이러한 사람은 업무를 수행하기 위한 필요한 자원을 사용할 수 있는 권한을 가지게 된다.

예를 들어 회사에서 시행하는 car pool(자동차 함께 타기) 를 위한 차를 고객에게 방문하기 위한 차량으로 assigned(할당)하여서, 그 사람이 

업무를 적절하게 실행하지 못한다면 그 사람은 그 책임을 져야 할 것이다.

자원의 corruption(부패)는 confidentiality(기밀성), 무결성, 가용성을 따르기 위한 것으로 분류될 수 있다.

대리인의 부패는 주어진 권한을 넘어서거나, 의무를 회피하려는 유혹에 빠지는 행동을 가져올 수 있다.

 

이미 분석은 설계 단계에서 수행될 수 있다.

이러한 관점에서 너는 너의 자산과 대리인, perhaps(아마도) 또한 너의 시스템이 deploy(배치)되어 있는 환경의 conceptual(개념적인) 모델을 가진다.

너는 아직 고려할만한 구현상의 취약점을 가지고 있지 않다.

너는 환경의 노출과 잠재적 피해를 야기시키는 각각의 위협을 rate(평가할)수 있다.

우리는 특별히 설계 단계에서 위험 분석을 위하여 위협 분석을 사용할 것이다.

위협 분석은 시스템 설계의 한 부분이 되야만 하는 보안의 특징을 증명할 것이다.

  

2.3.1 Asset (자산)

 

첫번째 단계로써, 자산은 가치화 해야 하고, 식별되어야 한다.

IT 시스템에서 자산은 아래와 같은 것들을 포함한다.

 

- 하드웨어 : 랩탑, 서버, 라우터, 모바일 폰, 넷북, 스마트 카드 등

- 소프트웨어 : 응용프로그램, 운영체제, 데이터베이스 관리 시스템, 소스 코드, 객체 코드 등

- 데이터와 정보 : 너의 사업을 계획하고 진행시키기 위한 본질적 데이터, 서류 디자인, 디지털 콘텐츠, 너의 고객을 위한 데이터 등

- reputation : 명성

 

자산의 identification(식별)은 relatively(상대적으로) 더욱 straightforward(직접적이고) 시스템적인 exercise(훈련)을 해야만 한다.

자산 가치의 측정은 더 큰 도전이 필요하다.

하드웨어와 같은 몇몇 자산은 그들의 monetary(화폐)를 대체하는 비용으로써 가치가 있다.

데이터와 정보와 같은 다른 자산은 더욱 가치 측정이 어렵다.

만약 너의 사업 계획이 경쟁자에게 leaked(누출)되거나, 너의 고객에 대한 사적인 정보가 공공연하게 누출된다면, 너는 비즈니스 기회의 손실 due to(때문에) 발생하는 간접적인 손실을 설명해야 한다.

경쟁자는 너보다 더 underbid(싸게 입찰)할 지 모른다. 그러면 너의 고객은 너를 desert(버릴) 지도 모른다.

장비를 잃어버리거나, stolen(도둑 맞았을) 때 조차도 너는 사업을 운영하기 위한 서비스의 가치 또는 저장된 데이터의 가치를 고려해야만 한다. 이러한 상황에서 자산은 그것들의 중요성에 따라 가치화될 수 있다.

그러한 중요성을 위한 훌륭한 metric(계량법)같은 것은 너에게 피해를 줄 수 있는 자산이 주어졌을 때, 너의 사업이 얼마나 길게 살아남을 수 있는 지 알려줄 수 있다. (하루, 일주일, 한달?)

 

2.3.2 Threats (위협)

 

 

2.3.3 Vulnerabilities (취약점)

 

 

2.3.4 Attacks (공격)

 

 

2.3.5 Common Vulnerability Scoring System (일반적인 취약점 기록 시스템)

 

 

2.3.6 Quantitative and Qualitative Risk Analysis (양적 또는 질적 위험 분석)

 

 

2.3.7 Countermeasures - Risk Mitigation (대책 - 위험 경감)

[출처] [09/24] 보안공학 스터디 - 2장 Managing Security By 영민 |작성자 착남