TUTOR 리덕토의 배움세상

SOC(Service Organization Controls) Report에 대해서 들어본 사람이 있을까? 이게 무엇이며 왜 필요한지 또한 모르는 사람들도 많을 것이다. 결론 부터 말하면 이것은 잠재적인 고객이 조직의 보안 통제 평가를 확인 할 수 있는 보고서이다.

서론 

보안통제 항목의 평가나 감사활동의 결과, 침투테스트의 결과는 모두 비밀로 여겨지고는 한다. 조직의 취약성이 들어나는 곳이기도 할뿐더러, 어떠한 통제항목이 적용되어 평가되는지에 대한 내용은 조직입장에서는 지켜야할 자산이지만, 잠재적인 고객의 입장에서는 이를 모르는 상태로 나의 정보를 맡기거나 서비스를 위탁하는부담이 있을 것이다. 이에따라 정보누출 수준별로, 통제의 민감성에 따른 정보통제결과를 보고서화 할 수 있는 표준이 필요하였으니, 바로 SOC Report(Service Organization Controls) Report이다. SOC는 수준에 따라 SOC 1/2/3으로 분류되는데 자세한 점은 아래를 참고하자

SOC Report 1

고객의 재정상태에 서비스가 직접적인 영향을 미친다고 판단이 되면, SSAE 16 보고 표준에 따라 SOC 1이 생성이 되어야한다. SOC1은 아래와 같이 두가지로 구분된다.

• Type 1 : 검사/감사는 일회적으로 수행되었고, 운영상에 효과성을 검증하지는 않는다.
• Type 2 : 검사/감사는 사용자의 재정적인 불일치를 효과적으로 통제하기 위해서 수행되며, 시간이 지나감에 따라 지속적으로 수행된다. 표본방식또한 방법론적으로 정확한 것을 사용한다.

SOC Report 2

SOC Report 2는 다음과 같은 항목의 보고서 이다. AT 101의 보고 표준을 준수한다.

• 보안 통제(필수)
• 가용성 통제
• 무결성 처리 통제
• 기밀성 통제
• 개인정보 통제

SOC Report 2또한 2가지의 Type으로 분류된다.

• Type 1 : 검사/감사는 일회적으로 수행되었고, 상단의 통제들만을 평가한다.
• Type 2 : 검사/감사는 사용자의 재정적인 불일치를 효과적으로 통제하기 위해서 수행되며, 시간이 지나감에 따라 지속적으로 수행된다. 표본방식또한 방법론적으로 정확한 것을 사용한다.

SOC Report 3

SOC Report 3는 SOC Report 2의 Type 2방식을 민간에 Open할 수 있도록 기밀의 정보등을 제거한 보고서이다. 따라서 자세한 통제의 결과나 취약성은 공개되어있지 않다.

듣자하니 요즘 ISC2문제에 SOC를 물어보는 문제들이 많아서 종류만 정리를 해보았다. 한국어로 어떻게 번역이 되고 있는지는 모르겠지만... 정리에 다음의 글들을 공부하며 올려놓은 것이니, 궁금한 사람들은 참고하자 우리나라의 표준이 아닌만큼 자격증 공부제외 알아둘 일은 없을거 같다.

정보보안에는 여러가지 문서가 있다. 기업 정보보안에서 정책이 존재하는 이유는 무엇일까? 당연히 신뢰할 수 있는 반복적인 결과를 만들기 위함일 것이다. 표준화된 정책을 통해서 조직은 반복가능한 output을 생성할 것이고, 이는 품질의 항상성 상승과 신뢰도(Level of Confidence) 향상이라는 선기능의 체인을 만들게 된다. 이 정책은 one-size-fit이 될 수 없다. 그니까 만능정책은 존재하지 않는다. 쓰임에 따라, 분류에 따라, 적용대상에 따라 수많은 정책의 종류가 존재하며, 같은 정책임에도 불구하고 강제성의 유무, 세분화된 수준에 따라서 명칭이 달라진다.

이번시간에는 이에 대해서 갈피를 잡을 수 있도록 흔히 사용하는 정보보안 문서의 분류에 대해서 이야기를 해보도록 하겠다.

분류할 대상은 이름만 들어도 헷갈리는 것들인데, 정책 / 표준 / 기준 / 가이드라인 / 절차가 바로 그것이다. 저 문서들은 성격에 따라, 조직에 어떤 Tier 대상으로 적용되는지에 따라 쓰임세와 분류가 달라진다. 우선 정책부터 만나보도록 하자

순서는 조직의 상위문서부터 하위문서까지 정책 -> 표준 -> 기준 -> 가이드라인 -> 절차 순으로 소개한다.

① 정책(Policy)

조직 정보보안에서 가장 상위티어에 존재하는 모호한 문서이다. 예를 들면 "조직의 자산은 안전하게 보호되어야한다"라는것은 조직의 정보보안 정책안에 들어가 있어야하는 내용이다. 하단은 SANS에서 제공하고 있는 policy Template의 Email-Policy의 목차를 가져와 보았다.

1. 개요

2. 목적

3. 범위

4. 정책

5. 정책의 규정사항

6. 관련근거, 정책, 절차

7. 용어 정리

8. 개정기록

email_policy.pdf (contentstack.io)

보면 알겠지만 정책은 그다지 긴 문서가 아니다. 최고수준의 맥략적인 내용을 다루고 있는 정보보안 규정이니, 애매모호한 부분이 있다. 이런 애매모호함을 규정하기 위해서 우리는 세부적인 규정을 차용/생성 해야한다.

② 표준(Standards)

표준은 조직에서 맞추어야하는 규약이다. 네트워크에 익숙하신 독자라면 프로토콜(Protocol)의 의미를 알고 있을 것이다. 상호규약을 정의하는 이 프로토콜처럼, 조직내에서 지켜야하는 정보보안의 일치된 수준을 표현하는 것이 바로 표준이다. 이 표준은 국제표준기관(ISO)등에서 차용해서 사용하는 경우가 많다. 아래는 "정보보안의 인증 국제 표준"인 ISO 27001의 소개 홈페이지 이다.

ISO - ISO/IEC 27001 — Information security management

③ 기준(Baseline)

"Base"라는 단어에 집중하자.(물론 baseline이 한 단어이긴 하지만) 기준은 조직이 "최소한"으로 지켜야하는 수준을 논의한다. 가령 Anti Virus에 관련된 기준이 존재한다면 "모든 전산장비의 Anti Virus 패치는 최소 30일 이내의 패치가 적용되어야한다."가 기준에 들어갈 수 있는 내용이겠다.

하단은 Baseline Security가 무엇인지를 NIST와 다른 기관을 비교하며 설명하는 사이트이다. 인용해보았다.

What is baseline security? - Sherweb

④ 가이드라인(Guideline)

다른 규정과 가이드라인은 강제성에서 규정성격의 차이가 난다. 이는 비강제적인 문서이다. 모든 보안 문서는 상기하였듯이 one-size-fit할 수 없다. 예를들어 기준에 "사내의 모든 업무용 PC의 OS는 window 8이상을 사용함으로 규정한다"라는 조항이 있는데 특정한 PC에 설치되어있는 프로그램이 window 7에서 밖에 동작하지 않는 프로그램이라면? 그 기준을 위반하지 않도록 [예외사항]이라는 것을 만들어 두어야한다. 물론 Baseline문서에 예외조항을 만들어 두는 것이 일반적이지만, 규정의 숨통(여유공간)이 생성되어야된다는 점에서는 동일하다. 이런 숨쉴수 있는 기포를 만들어주는것이 Guidline이다.(사실 NIST쪽 문서를 보면 Guide는 기업별로 Customize할 수 있게 만들어 두었다. 그래서 Guide for ~ 라는 문서로 이루어져있다.) 아래는 NIST의 대표적인 Guide문서인 NIST 800-30, 위험평가수행에 대한 가이드 이다.

Guide for Conducting Risk Assessments | NIST

⑤ 절차(Procedure)

멀리까지 왔다. 가장 구체적이면서 세부적인 문서이다. 예를들어 "Anti-Virus 업데이트절차"라는 절차문서가 있다면, 다음의 절차가 될것이다.

1. 회사 IT Security Team에서 최신의 패치를 수령한다.

2. 패치.exe를 우클릭해서 [관리자 권한으로 실행]한다.

3. [다음을 누른다.]

4. [차한잔 마신다.]

5. [끝.]

세부적이다. 엄청 세부적이다. 이렇게 세부적인 절차가 필요한 것이다. 바로 서문에서 설명하였던 반복, 예측가능한 output을 위함이다. 개인에 의존하는 정보보안 시스템은 위험하다. 가뜩이나 기술적이고 내제적인 위험이 많은 정보보안 업무에 turn-over와 같은 인적위험또한 impact를 높이는 꼴이된다. 이를 최소화하기위해서는 잘-구성된 시스템이 필요하고, 잘-구성된 시스템을 위해서는 길가의 아저씨를 대려다 두어도 정비사로 일할 수 있는 잘-서술된 절차가 필요하다. 

정보보안의 문서는 이 이상으로 필요에 따라 많은 분류가 생성된다. 당장 우리나라만 봐도 정보통신망법과 개인정보보호법등에 근거를 둔 정보보안 문서들이 많이 존재한다. 규정과 절차가 중요한 기업정보보안의 특성상 정보보안담당자(SISO나 ISSM/O)라면 해당 문서정도는 당연히 구분할 줄 알아야한다는 생각에 글을 작성해 보았다.

숱한 보안시험에서 국내외를 안가리고 출시되는 분야는 위험관리이다. 위험의 식별, BIA의 진행, 위험 관리 프레임워크, 정성적 / 정량적 분석방법, 위험 핸들링등 IT관련된 위험과, 비 IT적 위험(이건 국내시험에 안나오는거 같다. CGEIT시험에서 이거떄문에 혼났다.)을 구분하여 심도깊은 이야기를 나누는 생각보다 깊은 분야다. 이번시간에는 그 심도싶은 분야에서 공짜점수를 제공해주는 효자지표 SLE와 ALE의 대한 이야기를 나누겠다.

일반상식

SLE를 계산하는 이유는 위험분석이다. 위험분석에는 정량적 / 정성적 분석방법이 있고, 특정한 자산 A가 어떠한 위험R에 노출되어 있는 경우, 이 자산에대한 위험의 수치를 정량적(재정적)으로 계산하기위한 방법이다. 

용어정리

• AV(Asset Value) : 자산가치(단위 : 원) (EX : 100만원의 라우터)
• EF(Exposure Factor) : 노출계수(단위 : %) (EX : 자산이 위험R에 노출되었을 때 XX%의 손실이 발생한다.)
• SLE(Single Loss Expection) : 단일 예상 손실액(단위 : 원) (EX : 100만원의 자산이 위험R에 1회 노출될 때 나오는 손상액)
• ARO(Annual Rate Occurrence) : 연간 발생율(단위 : %) (EX : 위험 R은 4년에 1번 발생한다. >> 1/4 = 25%)
• ALE(Annual Loss Expection) : 연간 예상 손실액(단위 : 원) (EX : 100만원의 자산은 위험R에 1년 노출될 떄 나오는 손상액)

좋다. 자극적인 용어를 필자는 좋아한다. 즉 1번 위험에 노출되어 발생될 손상액과 1년간 위험에 노출되었을때 나오는 평균 손상액을 계산하는 방법이 SLE / ALE 계산이다. 자 공식들어간다.

• SLE = AV * EF
• ALE = SLE * ARO

예제

Q. 보안업체 ABC의 CEO REDUCTO는 큰맘먹고 새로운 방수라우터A를 1000원 주고 샀다. 이곳은 홍수가 자주일어나는 도시로 2년에 1회의 홍수가 발생을 하는데  기가막히게 이 방수라우터가 방파제에 설치되어있어 노출계수는 75%이다. 이때 ALE는 어떻게 되는가?(노출계수는 50%로 설정한다.)

A. 답 : 375원. 각 요소는 다음과 같이 계산된다.

• SLE = AV * EF = 1000 * 0.75= 750원
• ARO = 1/2 = 50%
• ALE = SLE * ARO = 750 * 0.5 = 375원

여담

SLE를 계산하는데에 사실 AV * EF만 있는것은 아니다. 한번 발생 했을 때 발생하는 impact또한 SLE로 계산이가능한 데 만약 자산가치가 100원, 고장탐구비용이 20원, 서비스 인터럽트 비용이 50원이면 AV * EF가 아니라 100+20+50으로 170원이 된다.  

소프트웨어 공학을 공부하며 Test-Driver나 Stub에 대해서 공부를 하고 있었다. 그러던 중 Test-Harness라는 용어를 보았는데, 실물로 보지는 못했지만, 여러군데 돌아다니면서 확인한 이론적인 정보를 아는만큼 정리해두려고한다.(대부분의 정보출처가 위키백과이다)

여담으로 하네스가 무엇일까 해서 검색하니 다음과 같은 결과가 나왔다.... 소프트웨어공학의 뒷모습인가?

더보기

 

테스트하네스란?

테스트하네스란 자동화된 테스트 지원도구 이며 프로그램을 유닛단위로 테스팅하고 여러가지 조건에 따른 프로그램의 행동과 결과를 모니터링하기위해 만들어진 소프트웨어의 구성이다. 

테스트하네스의 목적?

- 테스트 프로세스의 자동

- 테스트케이스의 실행

- 연관된 테스트보고서를 생성

테스트하네스의 장점?

- 테스트 프로세스 자동화를 통한 생산성 향상

- 회귀테스트 발생가능성 향상(어? 이건 좋은건가?)

- 소프트웨어 컴포너늩와 어플리케이션의 품질향상

- 테스트의 부절차(SubRoutine) 반복성 제공

- 오프라인 테스트(예를들면 사무실에 사람이 없는 밤시간 등에 테스트를 진행할 수 있음)

- 좀처럼 일어나지 않는 특이상황의 테스트가능(예를들면 평소보다 높은 부하량등)

정리를 하다보니, Test 자동화 프레임워크의 목적과 정의와 장점이 그대로 적혀있는것을 알 수 있었다. 그냥 동일하다고 생각해도 되는 것일까? 으흠.... 조금 더 찾아봐야겠다.

* 참고문헌

http://tryqa.com/what-is-test-harness-unit-test-framework-tools-in-software-testing/

https://en.wikipedia.org/wiki/Test_harness

크롤링이라.... 심란한 분야이다. 전 세계 트래픽의 절반 이상이 Bots으로 이루어져 있다는 사실은 이미 유명할 것이다.(어라 조금 더 있었던 거 같은데?)

 사실 이러한 크롤링이 순기능만을 가지고 있는 것은 아니라고 본다. 

"아니 정보의 바다에서 필요한 정보만을 가져오는게 뭐가 불만이에요!"

이렇게 생각하는게 당연하다. 물론 그렇고 말고

단, bots의 크롤링을 필터링 없이 무분별하게 허용하는 순간 많은 위험에 빠지는 것은 당연하다. 기본적인 취약점 스캐닝 도구인 Nikto나 Nessus 등 여러 가지 Explotable 한 요점을 뽑아낼 수 있는 툴은(심지어 스크립트 엔진을 쓴 nmap까지)에 대해서 bots의 접근 차단하지 않으면 자신의 서버의 취약점을 open 하겠다는 선언과 다를 바 없으니 말이다. 그러면 이러한 위협에서 우리를 도와줄 프로토콜은 없는 것인가? 그 아이디어에서 나온 게 바로 로봇 배제 표준이다.

정의

로봇 배제 표준(robots exclusion standard), 로봇 배제 프로토콜(robots exclusion protocol)은 웹 사이트에 로봇이 접근하는 것을 방지하기 위한 규약으로, 일반적으로 접근 제한에 대한 설명을 robots.txt에 기술한다.

< 로봇 배체 표준 정의 : 출처 위키백과 https://ko.wikipedia.org/wiki/%EB%A1%9C%EB%B4%87_%EB%B0%B0%EC%A0%9C_%ED%91%9C%EC%A4%80>

로봇 배제 표준을 robots.txt에 기술한다고 적혀있는데 robots.txt를 보면 다음과 같은 형식을 가진다.

User-Agent : [로봇명]
Allow : [크롤링 허용 경로]
Disallow : [크롤링 차단 경로]

User-Agent : [로봇명]
Allow : [크롤링 허용 경로]
Disallow : [크롤링 차단 경로]

User-Agent : [로봇명]
Allow : [크롤링 허용 경로]
Disallow : [크롤링 차단 경로]

...

참고로 robots.txt는 사이트의  루트디렉토리(/)에 있는 것이 원칙이다. 또한 public 하게 공개되어있다. User-Agent에 애스터레이크(*)가 있으면 모든 요청에 대한 것을 의미한다.

아래는 구글 robots.txt의 일부이다.

User-agent: *
Disallow: /search
Allow: /search/about
Allow: /search/static
Allow: /search/howsearchworks
Disallow: /sdch
Disallow: /groups
Disallow: /index.html?
Disallow: /?
Allow: /?hl=
Disallow: /?hl=*&
Allow: /?hl=*&gws_rd=ssl$
Disallow: /?hl=*&*&gws_rd=ssl
...

https://www.google.com/robots.txt

다음번 포스팅은 robots.txt의 단짝인 sitemap에 대해서 적어보려고 한다.

패스워드 크래킹은 여러 가지 방법이 있다. 가장 기본적인 방법은 BF(Brute Force) 방식이다. 모든 가능한 패스워드 조합을 다 때려 박아 보는 건데, 결국 100% 뚫린다는 장점이 있지만, Key의 길이가 늘어남에 따라 걸리는 시간이 천문학 적으로 늘어난다는 단점이 있다. 이 시간을 줄이기 위한 노력과 늘리기 위한 노력 패스워드 크래킹이라는 분야에서 크래커들과 정보보안담당자들이 싸우는 전장이 되는데, 대표적으로 공격시간을 줄이기 위한 방법으로 알려진 Dictionary Attack이 있다. 미리 정해진 단어를 사전에 저장해주고, 그걸 공격하는 방식이 그 방법이다.예를 들면 패스워드로 자주 쓰는 단어인 ps1234나 admin이나 password등 뭐 이런 거 있지 않은가.

BF라는 똑똑하지 않아 보이는 방법과 Dictionary Attack을 합친 방법을 Syllable Attack이라고 한다.

* Hybrid Attack과는 다른다. Hybrid Attack은 다른 PW 공격의 종류를 합쳐서 기동할때나, Dicationary Attack에 있는 사전 단어와 무엇인가를 합쳐서 쓸 때 Hybrid Attack이라고 한다.

그래 뭔들 중요하겠는가 뚫으면 땡이지 아래 출처 남긴다.

https://xtraweb.wordpress.com/types-of-password-attack-2/