설계부터 개발까지 직접 만들면서 배우는 보안 개발 시리즈 - Security School 1. 시리즈 소개 • 리눅스 환경에서 동작하는 보안 솔루션을 개발하며 기본 구조를 이해할 수 있습니다. • 백신 개발을 시작으로 시스템 보안과 네트워크 보안까지 개발합니다. • 다 만들어진 코드를 설명하는 게 아니라 기획/설계/구현하는 방법을 이야기합니다. • 보안 개발을 처음 시작하는 학생과 직장인을 대상으로 합니다. • 최대한 쉽게 구현합니다. • 누구나 보안 개발자가 될 수 있다는 꿈과 희망을 선사합니다. 2. 주요 특징 • UML 실용 설계 - UML을 효과적으로 사용하는 방법으로 간결한 코드만으로도 모든 요구사항을 만족시킬 수 있습니다. • 현실주의 - 현업에서 실제로 일어나는 일들과 그에 맞는 개발 프로세스를 이야기합니다. • 모듈식 구성 - 원하는 목적에 맞춰 골라 읽을 수 있습니다. • 손 안에 기술서 - 한 권의 내용을 1주에서 2주 정도면 정독할 수 있는 분량으로 짧게 구성합니다. 3. 사전 지식(권장) • C 언어 • 간단한 소켓 프로그래밍 • 리눅스 커널의 역할 이해(단, 커널 개발 경험은 없어도 됩니다.) • UML과 VMWare 사용의 이해 저자: 이창우 보안 기업 AhnLab에서 10년 동안 PC용 V3 방화벽과 침입차단 시스템 엔진, 웹 보안 솔루션을 개발했다. 이후 삼성전자에서 스마트TV 보안 강화 설계, SDL(Security Development Lifecycle) 적용, 임베디드 보안 프레임워크를 설계했고, 현재는 삼성 스마트TV 통합 보안 솔루션인 ‘스마트 시큐리티’를 담당하며 임베디드 백신, 코드 서명, 방화벽을 개발하고 있다. 하나의 보안 기술만으로 컴퓨터 시스템을 안전하게 만들 수 없다. 따라서 개발 기술뿐만 아니라 프로세스와 조직 문화까지 보안과 관련된 것이라면 무엇이든 공부하고 있다.

1. 이창우 지음
& Security School
IoT백신
직접설계하고개발하는
초급

2. 이창우 지음
IoT백신
직접설계하고개발하는

3. 직접설계하고개발하는IoT 백신초급
초판발행 2017년 4월 7일
지은이 이창우 / 펴낸이 김태헌
펴낸곳 한빛미디어(주) / 주소 서울시 마포구 양화로7길 83 한빛미디어(주) IT출판부
전화 02-325-5544 / 팩스 02-336-7124
등록 1999년 6월 24일 제10-1779호 / ISBN 978-89-6848-736-1 93000
총괄 전태호 / 기획·편집 정지연
디자인 표지 김연정 내지 여동일 삽화 윤병철 조판 최송실 / 제작 박성우, 김정우
마케팅 박상용, 송경석, 변지영 / 영업 김형진, 김진불, 조유미
이 책에 대한 의견이나 오탈자 및 잘못된 내용에 대한 수정 정보는 한빛미디어(주)의 홈페이지나 아래 이메일로 알려주십시오.
잘못된 책은 구입하신 서점에서 교환해 드립니다. 책값은 뒤표지에 표시되어 있습니다.
한빛미디어 홈페이지 www.hanbit.co.kr / 이메일 ask@hanbit.co.kr
Published by HANBIT Media, Inc. Printed in Korea
Copyright ⓒ 2017 이창우 & HANBIT Media, Inc.
이 책의 저작권은 이창우와 한빛미디어(주)에 있습니다.
저작권법에 의해 보호를 받는 저작물이므로 무단 복제 및 무단 전재를 금합니다.
지금 하지 않으면 할 수 없는 일이 있습니다.
책으로 펴내고 싶은 아이디어나 원고를 메일(writer@hanbit.co.kr)로 보내주세요.
한빛미디어(주)는 여러분의 소중한 경험과 지식을 기다리고 있습니다.

4. 지은이_이창우
보안 기업 AhnLab에서 10년 동안 PC용 V3 방화벽과 침입차단 시스템 엔진, 웹 보안 솔루션을 개발했
다. 이후 삼성전자에서 스마트TV 보안 강화 설계, SDLSecurity Development Lifecycle
적용, 임베디드 보안 프레임
워크를 설계했고, 현재는 삼성 스마트TV 통합 보안 솔루션인 ‘스마트 시큐리티’를 담당하며 임베디드 백
신, 코드 서명, 방화벽을 개발하고 있다.
하나의 보안 기술만으로 컴퓨터 시스템을 안전하게 만들 수 없다. 따라서 개발 기술뿐만 아니라 프로세스
와 조직 문화까지 보안과 관련된 것이라면 무엇이든 공부하고 있다.
목표
높은 점수나 좋은 직장을 위해 배우는 것이 아닌
단지 재미있어서 배우며
꿈을 키워 나가는 집을 짓는 것
昌宇
재미있게 꿈을 개발하는 공간 schoolime.com
지은이 소개

5. IoT 시대가 이제 열렸다고 하지만, 우리는 이미 IoT 시대에 살고 있습니다. 아침을 알리는 스마트워치, 등
교길 버스 요금 단말기, 강의 노트용 태블릿, 점심시간 편의점 계산 단말기, 인기 드라마를 보여주는 스마
트TV, 친구와 즐기는 게임기, 자기 전 보는 전자책, 시도 때도 없이 보는 스마트폰 등 생김새는 다르지만
우리는 모두 연결된 컴퓨터 시스템을 아침부터 밤까지 이용하고 있습니다. 그런데 이것 중 보안 기술이 적
용된 것은 몇 개나 될까요?
모두가 보안이 중요하다고 말합니다. 하지만 관련 인력이 부족한 게 현실입니다. 이는 프로그래밍을 시작
한 사람들에게 보안이 어려워 보이는 주제이기 때문입니다.
그래서 이 책을 썼습니다. C 프로그래밍은 가능한데 임베디드 개발 경험도 없고 리눅스 커널도 잘 모른다
고요? 그래도 괜찮습니다. 이 책의 내용을 그대로 따라 해보세요. 차근차근 따라 하다 보면 UML을 이용한
설계 방법도 알게 되고, 리눅스 커널도 약간 수정하다 보면 어느덧 간단한 백신의 실시간 감시 기능까지 구
현하게 됩니다.
이 책은 취업을 앞둔 대학생이 소프트웨어 공모전을 위해 간단한 IoT용 백신을 VMware 환경에서 개발
하는 이야기입니다. 현업에서 사용하는 기초적인 개발 프로세스를 기반으로 백신을 설계하고 구현하는 과
정을 그리고 있습니다. 따라서 주제는 백신 개발이지만, 현장의 개발 과정을 체험하면서 실용적인 소프트
웨어 설계 방법(UML 실용 설계)을 배울 수 있습니다.
이 책은 고등학생, 대학생, 사회 초년생을 대상으로 집필했습니다. 어려운 지식이 전달이 아니라, 호기심을
충족시키며 보안 개발자가 되는 길에 희망을 드리고자 쓴 책입니다. 그러니 부담 없이 읽어보세요. 누구에
게나 처음은 있습니다.
지은이의 말

6. 4차 산업혁명이 진행되는 시대를 사는 우리는 생활의 편리함을 가져다주는 다양한 형태의 사물인터넷IoT,
Internet of Thing
기기를 만나고 있습니다. 하지만 보안이 담보되지 않은 경우 우리의 소중한 자산뿐 아니라 사
랑하는 사람의 생명까지도 위협하는 뉴스 역시 종종 보게 됩니다. 따라서 IoT 기기의 제조사는 물론이고
이를 사용하는 사용자도 보안에 대한 인식을 제고하고, 더불어 SW 보안에 대한 전문가를 더욱 양성해야
하는 시대가 도래된 것입니다.
저자는 AhnLab에서 백신 개발, 삼성전자에서 스마트TV 보안 솔루션 개발을 15년 이상 해온 본인의 경
험을 바탕으로 독자 스스로 IoT 백신을 만들어 볼 수 있게 합니다. 즉, IoT 백신 개발이라는 작지만 의미
있는 프로젝트를 따라 하며 15년 보안 솔루션 개발 경험을 공유할 수 있게 하고 있습니다. 예를 들어, 기획
자나 PM을 통해서는 제약사항을 상세히 전달받지 못할 수 있다는 점과 같이 개발 단계에서 흔히 발생하
는 커뮤니케이션 문제 등 실무 단계에서 쉽게 발생하는 시행착오를 줄일 수 있는 팁들을 알려줍니다. 또한,
요구사항 분석에서 설계, 구현 등 개발 프로세스의 전 과정을 모두 경험할 수 있게 함으로써 초보 SW 개발
자에서 SW 보안 아키텍트Security Architect
로 발전해 나갈 수 있는 단초를 제공하고자 했습니다.
IoT 세상에서는 동일한 형태의 한두 가지 보안기술이 여러 곳에 쓰이기보다는 기기 특성과 상황에 맞는
다양한 보안 기술을 필요로 합니다. 이 책에서는 IoT 전등을 보호하는 솔루션을 개발하면서 ‘제로 UI’와
‘저사양 HW’ 등의 요구사항을 만족하며 보안 솔루션을 개발하는 미션을 독자와 같이 수행하고 있다. 어렵
게만 보이는 리눅스 커널 수정과 보안 솔루션 개발을 위한 시스템 프로그래밍, 원격 업데이트가 필요한 백
신 개발 등 하나하나를 따라 하다 보면 어느새 독자들은 보안 전문가의 길로 걸어가고 있다는 것을 스스로
느끼게 될 것입니다.
해킹 기술을 다룬 많은 책은 취약점을 공격하는 것에 대한 위험성을 알게 하지만, 이 책은 더 나가 해킹 공격
에 대응할 수 있는 방어 솔루션을 스스로 설계하고 개발할 수 있게 합니다. 이렇게 진정한 보안 전문가의 길
을 제시하는 책이기에 매우 의미 있는 발걸음이라 생각합니다. 더불어, 15년 전 함께 땀 흘리던 동료가 세상
에 내놓는 책을 통해 그의 세상을 향한 긍정적인 에너지를 느낄 수 있어 행복한 마음에 이 책을 추천합니다.
2017년 3월 26일 이희조
고려대학교 컴퓨터학과 교수
IoT 소프트웨어보안 국제공동연구센터 센터장
2016년 아시아태평양 정보보안 최고상 수상
추천사

7. 감사의 말

8. “It’s not your fault”
- 영화 ‘굿 윌 헌팅’ 중에서 -

9. 차례
지은이 소개 ...................................................................................................003
지은이의 말 ...................................................................................................004
추천사 ...................................................................................................005
들어가며
“저도 백신을 만들 수 있을까요?”.......................................................................013
“Security School에 오신 것을 환영합니다.”.......................................................018
“여러분이 준비할 것과 얻을 것입니다.”..............................................................028
1장 백신 개발 프로젝트 Airplane 시작
1.1 보안 개발 입문기...................................................................................037
1.2 프로젝트 준비.......................................................................................039
1.1.1 EA 준비......................................................................................040
1.1.2 UML 전체 흐름도 준비..................................................................045
1.1.3 UML 실용 설계............................................................................049
2장 요구사항
2.1 요구사항 수집.......................................................................................055
2.1.1 사용자 인터뷰...............................................................................055
2.1.2 요구사항 작성...............................................................................057
2.1.3 제약사항 작성...............................................................................061
2.2 요구사항 분석.......................................................................................064
2.2.1 정적 분석.....................................................................................064
2.2.2 동적 분석.....................................................................................072

10. 3장 프로토타입
3.1 개발 환경 만들기...................................................................................083
3.1.1 필요한 테스트 베드........................................................................083
3.1.2 개발과 테스트를 위한 우분투 설치....................................................085
3.1.3 Update Server Guest OS 설치.....................................................094
3.1.4 최종 확인.....................................................................................094
3.2 리눅스 커널 수정과 모듈 만들기...............................................................096
3.2.1 커널 재빌드..................................................................................096
3.2.2 커널 모듈 만들기...........................................................................102
3.3 백신의 실행 파일 실시간 감시..................................................................107
3.3.1 Linux Security Model이란............................................................107
3.3.2 실행되는 프로세스 로그 남기기........................................................111
3.3.3 간단한 필터링 구조 만들기..............................................................113
3.4 리눅스 커널 소켓 프로그래밍...................................................................126
3.4.1 간단한 소켓 서버 만들기.................................................................127
3.4.2 간단한 소켓 클라이언트 만들기 .......................................................132
3.4.3 서버와 클라이언트 통신 테스트........................................................135
3.4.4 커널에서 소켓 클라이언트 만들기.....................................................136
3.4.5 백신의 업데이트 기능 ....................................................................148
3.4.6 악성 파일 목록 변화 감지................................................................149
3.4.7 파일 정보 추출하기........................................................................166
3.5 프로토타입 정리....................................................................................181
3.5.1 알게 된 것....................................................................................181
3.5.2 다음 설계에 반영할 내용.................................................................182

11. 4장 설계
4.1 설계 범위 정하기......................................................................................186
4.1.1 설계서 작성을 싫어하는 개발자........................................................186
4.1.2 소프트웨어 설계는 소프트하게.........................................................187
4.1.3 모듈 성격에 따라 설계서는 다르게....................................................188
4.1.4 UML 실용 설계서.........................................................................189
4.2 정적 설계 시작.........................................................................................190
4.2.1 클래스 도출하기............................................................................190
4.2.2 클래스 관계 만들기 .......................................................................194
4.3 동적 설계로 완성하는 정적 설계..................................................................196
4.3.1 효과적인 Sequence와 Class 다이어그램 작성 방법...........................196
4.3.2 Airplane 프로젝트의 Sequence 다이어그램 작성하기.........................204
4.3.3 Sequence 다이어그램을 UML 전체 흐름도에 삽입하기......................211
4.3.4 완성된 Airplane의 클래스 다이어그램..............................................213
4.4 모듈 설계................................................................................................215
4.4.1 Component 다이어그램 작성 방법...................................................215
4.4.2 Airplane 모듈 설계서.....................................................................217
4.5 배치도 작성하기.......................................................................................219
4.5.1 노드 도출하기...............................................................................220
4.5.2 Deployment 다이어그램 완성.........................................................221
4.6 정리 ...................................................................................................222
5장 구현
5.1 구현 준비................................................................................................226
5.1.1 UML에서 소스 코드 자동 생성하기..................................................226
5.1.2 Airplane 소스 트리 .......................................................................231

12. 5.2 공통 소스 구현.........................................................................................233
5.2.1 설계 도면.....................................................................................234
5.2.2 pss_hash 소스............................................................................235
5.2.3 pss_ksock 소스...........................................................................239
5.3 백신 업데이트 서버 구현............................................................................244
5.3.1 설계 도면.....................................................................................244
5.3.2 pssas_update 소스......................................................................245
5.3.3 pssa_serv 빌드...........................................................................252
5.4 백신 필터 구현.........................................................................................255
5.4.1 설계 도면.....................................................................................255
5.4.2 pssa_filter 소스...........................................................................257
5.4.3 pssa_lkm.ko 빌드........................................................................264
5.5 정리 ...................................................................................................267
6장 테스트
6.1 테스트 케이스 준비...................................................................................269
6.1.1 테스트 케이스란............................................................................269
6.1.2 EA를 이용한 테스트 케이스 작성.....................................................270
6.1.3 테스트 케이스 정리........................................................................275
6.2 테스트 케이스 수행...................................................................................277
6.2.1 TC#01 Eicar 테스트 ....................................................................277
6.2.2 TC#02 업데이트 서버 시작.............................................................279
6.2.3 TC#03 백신 필터 시작...................................................................280
6.2.4 TC#04 Eicar 차단........................................................................282
6.2.5 TC#05 업데이트 .........................................................................282
6.3 QA 리포트..............................................................................................287

13. 7장 뫼비우스의 띠
7.1 개선할 부분.............................................................................................292
7.1.1 업데이트 서버...............................................................................292
7.1.2 클라이언트 ..................................................................................293
7.2 응용할 수 있는 부분..................................................................................295
7.2.1 시스템 모니터링............................................................................295
7.2.2 산업 소프트웨어 보안 ....................................................................296
7.3 끝이 없는 해킹과 보안의 싸움.....................................................................297
7.3.1 백신의 태생적 한계 .......................................................................298
7.3.2 새로운 도전의 시작........................................................................299

14. 들어가며 - 013
시리즈 소개
들어가며
“저도 백신을 만들 수 있을까요?”
“네. 여러분도 만들 수 있습니다.”

15. 014 -
백신 개발자를 바라보는 타인의 시각
저는 2002년부터 현재까지 소프트웨어 개발직에 종사하고 있으며, 그중에서도 백신이나 방화벽 같
은 보안 관련 제품을 개발하고 있습니다. 다른 사람에게 자신을 처음 소개하는 자리에서 백신을 개발
하고 있다고 하면 분명히 조금 전에 인사를 나눴는데도 불구하고 찬찬히 다시 보는 걸 느낄 수 있습
니다. 입으로는 아무 말 없지만, 눈빛으로 ‘너 같이 생긴 사람이 백신을 만들 줄 안다고?’ 하는 것 같
습니다.
일반인들, 심지어 같은 소프트웨어 개발직에 종사하는 사람들이 생각하는 보안 분야 종사자에 대한
인식은 다음과 같을 겁니다.
-- 일반인의 시각
●
모니터가 안 나오는 내 컴퓨터도 고칠 수 있는 사람
●
계속 알고 지내면 내 통장의 잔액도 알아낼 것 같은 사람
●
소지섭(드라마 ‘유령’의 보안전문가)처럼 생긴 사람
-- 타 분야 개발자의 시각
●
1년 내내 컴퓨터만 붙들고 있는 사람
●
나보다 더 개발을 잘해서 관련 대화는 하지 말아야 할 사람
●
나보다 더 많은 연봉을 받는 사람
●
그래서인지 그냥 밉상인 사람
죄송합니다. 모두 오해입니다(특히 배우 소지섭의 외모는 지나친 오해입니다;;;). 저도 여러분과 똑같이 태어
나서 옹알이했고 똑같이 주입식 교육만 받았으며 똑같은 연봉을 받고 있습니다. 차이가 있다면, 다른
사람이 잘 안 하는 분야에 호기심이 있었고 새로운 분야에 대한 도전에 조금 더 용기를 내었을 뿐입
니다. 백신 개발이 어려울 거로 생각하고 오해하는 겁니다. 저는 지극히 평범한 사람임에도 불구하고
보안 제품을 개발하고 있습니다.
백신 개발이 어렵다고 생각하는 이유
그럼 사람들은 왜 백신 개발이 어렵다고 생각하는 걸까요? 보통 컴퓨터 보안을 생각하면 떠오르는 핵
심 키워드는 ‘컴퓨터 바이러스’일 겁니다. 보안 관련 개발을 하려면 컴퓨터 바이러스도 잘 만들 줄 알

16. 들어가며 - 015
아야 하고(소지섭의 얼굴을 하고) 방화벽을 넘나들며 다른 사람의 컴퓨터 정도는 우습게 엿볼 줄 알아야
한다고 생각할 겁니다. 하지만 모두 오해입니다.
컴퓨터 소프트웨어 개발 분야가 UX, OS, 임베디드, 인공지능 등 여러 분야로 나뉘듯이 컴퓨터 보안
도 악성코드 분석, 보안 솔루션 개발, 침해 대응, 보안 컨설팅 등 여러 분야로 나뉩니다. 오해를 불러
일으키는 핵심 키워드인 ‘컴퓨터 바이러스’를 굳이 양지의 보안 분야로 분류한다면 ‘악성코드 분석’
범주에 넣을 수 있겠네요.
백신 개발도 말 그대로 개발입니다. 다시 말해 다른 소프트웨어 개발과 같습니다. 프로젝트를 의뢰한
사람에게서 요구사항을 받으면 이를 분석해 설계하고 구현한 후 문제가 없는지 테스트해서 납품하면
끝나는 일입니다. 그리고 당연히 프로젝트마다 요구사항이 다른데, 이 요구사항이 ‘백신’일 뿐입니
다. 그러므로 여러분이 백신을 개발하지 못할 이유가 없습니다. 누군가 ‘어떤 플랫폼에서 어떤 파일
들을 어떻게 차단해야 하는지’를 요구사항으로 정리해서 준다면 여러분도 충분히 백신을 개발할 수
있습니다.
요구사항만으로 개발하는 데 필요한 것
요구사항만 주어지면 모든 걸 개발할 수 있다는 게 다소 억측처럼 느껴집니다. 소프트웨어 개발 프로
세스를 일반화하면 [요구사항 → 설계 → 구현 → 테스트]입니다. 원론적으로 보면 불가능한 일이 아
닙니다. 그런데도 어렵다고 느끼는 것은 왜일까요? 원인은 우리가 받은 교육 방식에 있습니다.
우리는 학창시절 내내 주입식 교육을 받아왔습니다. ‘이 상황에서는 이렇게 해’, ‘이럴 땐 이렇게 표현
해야 해’하는 식입니다. 생각하게 하는 교육이 아닌 생각의 틀에 맞추는 교육방식입니다. 소프트웨어
개발도 마찬가지입니다. ‘이 상황에서는 스레드를 만들어’, ‘이럴 땐 무슨 API를 사용해’라고 배웠습
니다. 처음 개발을 시작했을 때를 떠올려 보십시오. 문서화된 요구사항보다 누군가가 이미 만들어 놓
은 비슷한 코드를 보는 게 더 편하지 않았나요? 이게 바로 주입식 교육에서 비롯된 문제입니다. 여러
분만의 문제가 아닙니다.

17. 016 -
주입식 교육을 받고 개발회사에 입사한 저의 신입 시절을 예로 들어보겠습니다.
‘어제 프로젝트 매니저(이하 PM)님이 모듈을 만들라고 하셨으니, 일단은 비주얼 스튜디오를
실행하고 개발을 시작해볼까?’
#include <stdio.h>
int main(void) {
return 0;
}
요구사항과는 상관이 없는 클래스들이 만들어지고 쓸모없는 코드들은 버그를 양산했습니다. 시간이
흘러 저는 주임연구원이 됐고, 이제 제법 후임들도 생겼습니다. 3년 동안 코딩했으니 이제는 슬슬 아
키텍트Architect
라는 나를 더 차별화해줄 수식어에 관심이 생깁니다. 요즘에는 UMLUnified Modeling Language,
이하 UML
이 인기라네요. UML 책을 샀습니다.

18. 들어가며 - 017
한 번쯤 겪어 봤을 이야기입니다. 유스케이스Use Case
를 그리는 방법은 배웠지만, 그걸 이용해 클래스
다이어그램을 도출하는 방법, 그 생각의 방법을 배우지는 못했습니다. 한마디로 개발 프로세스는 알
고 있지만, 요구사항을 분석하고 설계해서 구현하는 방법을 생각해 본 적이 없습니다. 이런 상황에서
백신 요구사항을 받으면 개발할 수 있을까요? 아마 안 될 겁니다. 저는 10년이 지나서야 잘못 배웠다
는 걸 깨달았습니다. 그리고 다른 무엇이 필요함을 느꼈습니다.
우리에게 필요한 기술서 형태
배움을 시작하는 아이들을 예로 들어보겠습니다. 조카에게 1부터 100까지의 수를 합하는 프로그
래밍 방법을 알려줘야 하는 상황입니다. 일단은 C 문법을 알려줘야 하니 stdio를 타이핑하게 하고
int가 무엇인지 for는 무엇인지 설명하는 방법이 있습니다. 우리에게는 익숙한 방법이고 재미없는
방법입니다. 조카는 자꾸 printf로 별만 반복해서 찍으라는 삼촌에 대한 미움은 키워가고 프로그래
밍에 대한 흥미는 잃어갑니다.
이렇게 해보는 건 어떨까요? 먼저 1부터 100까지 더하기를 해보라고 합니다. 1과 2를 더하고 계속
해서 더하게 합니다. 그런데 자세히 보니 99번 반복했네요. 생각해보니 프로그래밍이라는 게 저장,

19. 018 -
반복, 조건의 연속입니다. 그럼 조카가 머릿속으로 생각한 걸 이 3가지로 표현하는 연습을 하게 하면
어떨까요? 조카는 자기 생각이 순서도로 옮겨지는 과정을 깨우쳤고, 다른 문제도 표현해보려 합니다.
그 순서도를 C로 표현하든 Java로 표현하든 그건 나중의 문제 아닐까요? 이게 Security School
시리즈를 기획하게 된 이유입니다.
“Security School에 오신 것을 환영합니다.”
“새로운 지식을 드리지는 못합니다. 하지만 새로운 느낌을 드릴 순 있습니다. 그건 바로 ‘할 수
있다’라는 느낌입니다.“
이 책을 시작으로 보안 개발 시리즈를 시작합니다. 시리즈의 이름은 ‘Security School’입니다. 본
시리즈의 기획 의도를 요약하면 다음과 같습니다.
1. 보안 솔루션들을 직접 개발합니다.
2. 백신 개발을 시작으로 시스템 보안과 네트워크 보안까지 개발합니다.
3. 다 만들어진 코드를 설명하는 게 아니라, 기획/설계/구현하는 방법을 이야기합니다.
4. 보안 개발을 처음 시작하는 학생과 직장인을 대상으로 합니다.
●
제품 상용화가 아닌 학습이 목적입니다.
●
최소한의 필수 기본 구조만 개발합니다.
●
최대한 쉽게 구현합니다.
Security School은 실용주의를 표방합니다. 다수의 사람이 이미 알고 있거나 쉽게 배울 수 있는 기
술을 토대로 직접 보안 솔루션을 개발하고 응용하는 것을 목표로 합니다. 따라서 이 시리즈에서는 수
준이 높거나 소수에게만 이로운 보안 기반 기술은 다루지 않습니다. 그런 정보는 국내외 논문에서 찾
을 수 있습니다. 예를 들어, 여러분이 다음 키워드를 떠올리며 이 글을 읽고 있다면 기대에 부응하지
못합니다.
●
휴리스틱 분석Heuristic Analysys
●
행위 탐지 백신Behavior Detection Antivirus
●
비정상 행위 자체 학습 애플리케이션 방화벽Self-learning Anomaly-Base Web Application Firewall
●
기타 생소한 영어 단어로 구성된 기술들

20. 들어가며 - 019
높은 수준의 기술서는 아니지만 다른 서적에서는 볼 수 없는 Security School만의 특징들을 준비
했습니다. 다소 진부한 이야기일 수도 있으나, 시리즈 전반에 적용되는 중요한 내용이니 SKIP 하지
말고 꼭 읽어주십시오. 길지 않습니다(SKIP에 대해서는 ‘캐주얼 기술서’에서 다루겠습니다).
실용주의 - 현실에 맞춘 개발 프로세스를 만들어 사용합니다
우리는 소프트웨어 공학을 통해 다양한 개발 프로세스를 배웠습니다. 하지만 현장을 둘러보면 배웠
던 프로세스들이 실제로 적용되고 있지 않습니다. 왜 일까요? 저는 정서의 차이라고 생각합니다. 소
프트웨어 공학의 프로세스들은 서양의 건축 프로세스에 기반을 두고 있다고 합니다. 이를 군수 산업
에 적용하며 많은 시행착오로 만들어진 모델들입니다. 그런데 문제는 ‘서양’이라는 겁니다. 우리나라
와 서양의 정서는 다릅니다. 소프트웨어는 사람이 기반이어서 사람의 정서를 무시할 수 없습니다. 외
국 개발자들 사이에서도 한국의 ‘빨리빨리’ 문화는 잘 알려져 있습니다.
Security School은 실용주의 기술서를 표방합니다. 따라서 개발 프로세스도 우리나라 현장에 적합
한 모델을 만들어 사용합니다. 기본적인 개발 프로세스도 많은 시행착오와 여러 사람의 노력으로 만
들어진 것이니 먼저 그것들을 살펴보고 우리나라 실정에 맞춰 바꿔보겠습니다. 첫 번째는 폭포수 모
델입니다.
그림 개발 프로세스 – 폭포수 모델
계획
요구분석
설계
구현
테스트
유지보수
Feedback
Feedback
Feedback
Feedback
Feedback

21. 020 -
폭포수 모델은 우리 모두에게 익숙한 모델입니다. 간단히 설명하면 다음과 같습니다.
●
계획하고 요구사항을 만든다.
●
요구사항을 분석한다.
- 분석하며 계획에 문제가 있으면 피드백한다.
●
요구사항을 토대로 설계한다.
- 설계하며 요구사항에 부족한 점이 있으면 피드백한다.
●
앞의 과정을 반복한다.
이 폭포수 모델의 장단점은 다음과 같습니다.
-- 장점
●
가장 오래된 모델이고 성공 사례도 많다.
●
매우 단순해 이해하기 쉽다.
●
진행 과정을 관리하기가 쉽다.
-- 단점
●
초기 요구사항 분석이 어렵다.
●
중요한 결함이 나중에 발견된다.
●
이전 단계가 끝나야 다음으로 넘어갈 수 있다.
단점 중 앞의 두 가지 문제는 치명적입니다. 요구사항만 보면 충분히 구현할 수 있다고 생각하지
만, 구현 후 테스트 중에 실제 동작하는 디바이스의 한계 때문에 설계를 다시 해야 하는 일들이 있습
니다. 또는 요구사항 분석 과정에서 제약사항을 충분히 산출하지 못하면 개발자는 필요 이상의 많
은 코드를 구현하게 됩니다. 예를 들어, 처리해야 할 파일이 100개가 넘어갈 일이 없는데 개발자는
65,535개의 파일을 처리하려고 불필요한 설계와 구현을 하게 됩니다. 앞의 두 가지 상황은 현업에
서 5년 정도 프로젝트를 진행한 개발자라면 이미 경험한 일일 겁니다. 이런 문제를 보완하기 위해서
‘프로토타입’ 모델이 나왔습니다.

22. 들어가며 - 021
그림 개발 프로세스 - 프로토타입 모델
계획요구분석
프로토타입
개발/개선
프로토타입
평가
구현
인수/설치
Feedback
Feedback
앞에서 보는 바와 같이 프로토타입 모델은 요구분석과 프로토타입을 반복하면서 요구사항을 정교하
게 만들고 평가받습니다. 이 모델의 장단점은 다음과 같습니다.
-- 장점
●
요구사항과 제약사항 도출이 비교적 쉽다.
●
사용자가 만들어질 시스템을 이해하기 쉽다.
●
사용자와의 소통이 쉽다.
-- 단점
●
사용자가 프로토타입 결과물을 최종 결과물로 오해한다.
●
최종 결과물 개발까지 비용이 많이 든다.
●
요구사항이 자주 변경돼 문서화가 어렵다.
프로토타입 모델은 대규모 프로젝트 진행 시 사업 타당성을 결정하는 데 자주 사용합니다. 대규모 비
용이 드는 게임 프로젝트가 그 예입니다.
이 외에도 V 모델, 애자일 등 여러 가지 모델이 있습니다. 하지만 대부분 우리나라 정서에는 맞지 않
습니다. 애자일의 경우에는 개발자 의견을 존중해야 하는데, 관리 중심의 현장에서는 적용하기 힘든

23. 022 -
게 현실입니다. 실무 경험이 있다면 알고 있을 겁니다. 우리는 매일 밤, 이 주제를 안주 삼아 밤새 술
을 마시며 서로 위안하거나 누군가를 헐뜯고 있습니다.
인정합시다. 현실을 인정하고 현실에 맞는 변종 모델을 찾아봅시다. 밤새 술을 마셔봐야 나오는 건
우리 하복부이고, 누군가를 헐뜯어봐야 다음 날 얼굴을 보면 서먹해질 뿐입니다. 어차피 정서는 당장
바뀔 수 없습니다. 언제까지 한탄만 하며 살 수는 없습니다. 우리가 스스로 이 상황을 해결할 만한 적
당한 프로세스를 만들어봅시다. 그러려면 우리나라 다수의 개발자가 접하는 프로젝트 특성을 살펴봐
야 합니다.
●
1년 이내의 단기 프로젝트들입니다(1년도 장기 프로젝트에 속합니다).
●
프로젝트마다 필요한 기반 기술이나 플랫폼이 다릅니다(지난번은 iOS로, 이번에는 안드로이드로, 다음에는 타이젠으로).
●
이런 상황이니 일정 지연은 항상 있는 일입니다(관리자용 일정 = 개발자 공지용 일정 + 1달 버퍼).
정리하면, 우리는 아주 짧은 주기로 프로젝트에 투입됩니다. 그리고 항상 새로운 걸 배워야 합니다.
항상 새로운 걸 하다 보니 한 기술에 숙련되질 않습니다. 그런 상황에서 요구사항 명세서를 작성하라
고 합니다. 마지막에는 제약사항이라는 항목이 있네요. 해당 기술을 사용한 경험도 많지 않은데, 제
약사항을 사전에 어떻게 알겠습니까? 해봐야 알겠지요. 예의상 몇 글자 작성하고 넘어갑니다. 시간은
흘러 QA 단계에 이르렀습니다. 테스터에서 이슈를 할당받았습니다. 원인을 찾아보니 이건 플랫폼에
서 지원하지 않기 때문에 만들 수조차 없던 기능이었네요. PM에게 이야기했습니다. 그걸 이제 이야
기하면 어떻게 하냐고 하네요. PM과의 불신은 쌓이게 되고 설계, 구현이 반복되며 일정은 지연됩니
다. 매번 지연되는 일이니 서로 얼굴을 붉히지만, 속으로는 그러려니 합니다.
만약 프로젝트 초기에 다뤄보지 않은 기술을 학습할 수 있는 시간이 주어졌더라면, 초기에 요구사항
을 충족시키지 못하는 제약사항을 발견할 수 있었다면 어땠을까요? 개발 프로세스를 조금 바꿔보겠
습니다.

24. 들어가며 - 023
그림 개발 프로세스 - Security School의 실용 개발 프로세스
대단한 건 없습니다. 폭포수 모델의 단점을 보완하기 위해 프로토타입 모델을 적용하되 한 번만(‘빨리
빨리’ 정서와 타협한 횟수) 수행하고, 프로토타입을 통해 새로운 것을 학습하며 제약사항을 반드시 명시
합니다. 이를 자세히 설명하면 다음과 같습니다.
1. 기획자는 상품 계획을 세운다.
2. PM은 1차 요구사항을 정리한다.
3. 개발자는 1차 요구사항으로 프로토타입을 진행한다.
A. 요구사항을 해본 것과 안 해본 것으로 나눈다.
B. 해본 것들은 바로 제약사항을 추가한다.
C. 안 해본 것들만 추려 프로토타입 하며 숙련도를 올린다.
D. 새로 알게 된 제약사항을 추가한다.
4. 전체 제약사항 목록을 PM과 논의한다.
5. 계획을 수정하고 요구사항에 반영한다.
6. 설계를 시작한다.

25. 024 -
예를 들어, 회사 홍보 앱 개발 프로젝트에 이 프로세스를 적용해봅시다. 지난번에는 홍보 앱을 iOS로
만들었습니다. 이번에는 안드로이드로 만들라고 하네요. 만들어야 하는 UI가 무언지는 잘 알고 있지
만, 똑같은 UI가 안드로이드에서도 가능한지 잘 모르겠습니다. 그래서 프로토타입에 한 달의 시간이
주어졌습니다. 안드로이드에서 안 해본 UI 10개만 프로토타입으로 만들어봅니다. 10개의 화면 중 1
개는 안 되는 거네요. 기획자와 PM에게 이야기해서 가능한 화면으로 화면 설계서를 변경합니다. 테
스트 단계에서 발견될 문제가 사라졌고, 재설계/구현 반복이 줄어 일정 준수가 가능해집니다.
정리하면, 개발 프로세스 초기에 약간의 프로토타입 시간을 추가해서 개발자가 안 해본 걸 해봤을 뿐
인데 다음과 같은 이점이 생겼습니다.
개발자 PM
안 해본 분야의 기술 노하우가 생깁니다. 요구사항이 구체화됩니다.
제약사항을 도출할 수 있습니다. 정교한 일정 산출이 가능합니다.
프로젝트 리스크가 감소합니다.
잘 와 닿지 않는다고요? 알고 있습니다. 저도 그렇고 개발자들은 직접 해봐야 이해됩니다. 1장부터
이 책의 소재인 백신 개발을 통해 앞의 프로세스를 체험해보겠습니다.
쉬어가기 이 글을 읽고 읽는 PM이나 관리자께
저도 잠시나마 PM 업무를 담당한 적이 있습니다. 윗선에서는 일정이나 품질로 압박해 오고, 고집 센 개발자들은 자신
만의 용어로 다른 노선을 구축하고… 매우 외로우시죠? 그런데 이 외로움을 윗선에서 달래줄까요? 윗선에 기대하는
것보다는 팀원이나 개발자들에게 기대하는 것이 더 현실적이지 않을까요? 가지고 계신 일정 버퍼를 공개하고 프로토
타입 시간으로 할당해주면 안 될까요? PM과 개발자가 서로를 진심으로 존중하고 같은 목표로 일하는 게 어려워 보이
지만, 불가능한 일도 아닙니다.
모듈식 구성 - 필요에 따라 골라 보면 됩니다
이제 Security School 시리즈의 두 번째 특징에 관해 이야기하겠습니다. 비싼 돈을 내고 책을 구
매했는데, 중반 정도 읽었을 때 원하던 책이 아니란 걸 깨달은 적이 있지 않던가요? 원하던 내용이긴
한데, 읽다가 지쳐서 포기한 적이 있지 않던가요? 그래서 모듈식 구성을 생각하게 됐습니다. 다음은
Security School 시리즈의 출판 계획입니다.

26. 들어가며 - 025
해킹 변화별 대응 전략
악성코드 대응 변종코드 대응 네트워크 공격 대응
난이도
초급 A(irplane) B C
심화 D E F
가로는 해킹 형태 변화에 따른 보안 대응 전략을 나타냅니다. 세로는 대응 전략의 난이도입니다. 이
책은 A 단계에 해당하고, 입문자를 대상으로 악성코드에 대응하는 방법을 이야기합니다. 그래서 이
책의 목표가 간단한 백신 개발입니다.
초기 백신은 패턴 인식 기술을 기반으로 만들어졌습니다. 2000년 초반에 휴리스틱과 행위 기반이라
는 이름으로 패턴 인식의 문제점을 극복하려 했으나 오탐이 높아서 여전히 패턴 인식을 주류로 사용
합니다. 이런 패턴 인식의 문제점은 변종 악성코드에 취약하다는 점인데, 최근 보안 업계는 클라우드
와 빅데이터 기법으로 이 위기를 극복하려 노력 중입니다. 변종 악성코드가 만들어지는 속도를 따라
잡기 위해 더 빠른 패턴 업데이트 전략을 만든 겁니다.
B 단계에서는 이런 변종 악성코드에 대한 대응 솔루션을 만들어봅니다. 앞에서처럼 빠른 대응방법보
다는 좀 더 근본적인 해결 방법을 고민하고 실험해보겠습니다.
해킹과 보안은 바둑판과 같습니다. 한사람이 수를 두면 다른 사람이 막고 그걸 막고 또 막고… 이 패
턴의 반복입니다. 차이가 있다면 끝이 있냐 없냐의 차이입니다. 바둑판은 크기가 정해져 있어서 끝이
있습니다. 하지만 해킹과 보안에서는 대상인 디바이스가 계속 다양해지므로 싸움의 끝이 없습니다.
예를 들면, 파일 형태의 바이러스를 만들어서 해킹하니까 백신이 나왔고, 해커들은 파일 형태를 피하
려고 네트워크 공격기법을 접목합니다. 우리는 이걸 방화벽이라는 수로 받아쳤습니다. C 단계에서는
아주 기본적인 방화벽을 만들어보겠습니다.
쉬어가기 코드레드 웜 바이러스
악성코드에 대응하기 위해 PC에서 만들어지는 파일만 잘 감시하면 된다고 생각하던 시절이 있었습니다. 2001년 출
현한 코드레드 웜 바이러스는 네트워크로 시스템의 취약점을 공격하고 메모리에 상주하는 형태였습니다. 모든 백신을
보기 좋게 무력화하면서 전 세계 컴퓨터를 마비시켰습니다(당시 병원 시스템도 마비돼 진료가 지연될 정도였습니다.) 보안
업체들은 부랴부랴 개인 PC용 백신에 침입 방지 시스템IPS, Intrusion Prevention System
을 추가하기 시작했습니다.

27. 026 -
이 사건은 해킹과 보안의 끝 없는 싸움을 잘 대변하는 사건입니다. 인터넷이라는 연결고리 하나가 추가되면서 이런 일
이 벌어졌는데, IoT의 시대에는 어떤 일들이 벌어질지 보안 업계의 한 사람인 동시에 소비자로서 매우 걱정됩니다. 연
결고리 추가로 인한 위험성은 뒤에서 다시 이야기하겠습니다.
해킹별 대응과 난이도라는 두 가지 축 때문에 Security School의 특징인 ‘모듈식 구성’이 가능해집
니다. 예를 들면 다음과 같습니다.
1. 패턴 기반의 백신 개발을 깊게 공부해보고 싶다면 [A+D] 조합으로 읽으면 됩니다.
해킹 변화별 대응 전략
악성코드 대응 변종코드 대응 네트워크 공격 대응
난이도
초급 A B C
심화 D E F
2. 방화벽은 필요 없고 변종 악성코드 대응을 깊게 공부하고 싶다면 [A+B+E] 조합입니다.
해킹 변화별 대응 전략
악성코드 대응 변종코드 대응 네트워크 공격 대응
난이도
초급 A B C
심화 D E F
3. 방화벽 개발에 관심이 많은 사람이라면 [A+C+F] 조합이면 됩니다.
해킹 변화별 대응 전략
악성코드 대응 변종코드 대응 네트워크 공격 대응
난이도
초급 A B C
심화 D E F
앞의 예에서 봤듯이, A에 해당하는 이 책은 시리즈의 시작이자 기본입니다. 따라서 어떤 조합이 되든
반드시 읽어야 하는 필독서입니다. 집필 순서는 알파벳 순이며 1~2년에 한 권씩 출간할 계획입니다.

28. 들어가며 - 027
캐주얼 기술서 - 빠르게, 재미있게, 소통하며
요즘 가족의 휴대전화 번호를 외우는 사람이 몇이나 될까요? 심지어 여자친구 휴대전화 번호도 주소
록에 의지하고 있습니다. 그런 여러분을 탓하는 게 아닙니다. 우리는 그런 시대를 살고 있습니다. 개
발도 마찬가지입니다. 코딩하다가 스레드를 만드는 함수 이름을 찾아야 합니다. 인터넷에서 검색하
면 바로 훌륭한 예제가 나옵니다. 과거처럼 외우거나 바이블같이 두꺼운 API 서적을 들고 다닐 필요
가 없습니다. 이처럼 지식은 검색하는 시대가 되면서 소비자는 더 빠른 미디어를 원하게 됐습니다.
그래서 짧은 글이 특징인 SNS가 인기를 끌고 1분짜리 드라마도 나오는 시대가 됐습니다.
이 시리즈도 한 권의 내용을 짧게 구성하려 합니다. 1주에서 2주 정도면 정독할 수 있는 분량으로 구
성하려고 합니다. 이를 위해 두 가지 장치를 마련했습니다. 첫 번째는 SKIP입니다.
SKIP 이미 알고 있다면 ‘이곳’으로 넘어가세요.
책을 읽다 보면 ‘난 이미 이 내용을 아는데, 다음으로 넘어가려면 어디로 가야 하지?’라고 생각한 적이 있을 겁니다. 그
런 경우를 위한 장치입니다. SKIP에는 다음 내용을 요약해 놓습니다. 이미 알고 있는 내용이라면 명시된 곳으로 넘어
가면 됩니다.
두 번째는 앞에서도 나온 쉬어가기입니다.
쉬어가기 내용과 직접 연관은 없지만 유익한 이야기들
이곳에는 본문에서 나왔던 단어와 연관해 추가적인 정보와 개발자로서 현장에서 겪었던 일들 또는 개발자로서의 사견
등이 수록됩니다. 시간이 없다면 넘어가도 됩니다.
오프라인 매체는 수정이나 내용 추가가 어렵다는 단점이 있습니다. 그래서 온라인으로 이동하고 있
지만, 여전히 손으로 종이를 넘기며 읽는 게 더 편하고 읽은 보람도 있습니다. Security School 시
리즈는 이런 오프라인의 단점을 극복하고자 AS라는 장치를 마련했습니다.
AS 본문과 연관된 사이트 주소
http://schoolime.com/securityschool에 접속하면 다음과 같은 내용이 준비돼 있습니다.

29. 028 -
●
책 업데이트
- 책에서 수정해야 할 내용
- 지면상 수록하지 못한 내용
●
자료실
- 설계서 및 소스 코드 파일
- 책 관련 이벤트
출판 후에도 여러분과 소통하며 살아 있는 매체를 만들고자 합니다.
“여러분이 준비할 것과 얻을 것입니다.”
책을 읽는 데 필요한 사전 지식
이 시리즈는 보안에서 최소한의 [요구사항 → 설계 → 개발] 과정에 대한 책입니다. 따라서 이 책에서
는 프로그래밍 기초를 가르쳐주지 않습니다. 어느 정도는 여러분이 준비해야 합니다. 이 책을 읽는
데 필요한 배경 지식은 다음과 같습니다.
●
C 언어
●
간단한 소켓 프로그래밍
●
리눅스 커널의 역할 이해(단, 커널 개발 경험은 없어도 됩니다.)
●
UML의 이해
이 내용을 종합해 만들 수 있는 프로그램을 예로 들면 네트워크 파일 복사 프로그램입니다. UML은
기초적인 부분만 사용하므로 순서도를 작성해보았다면 얇은 UML 책을 반나절 정도 정독하면 됩니
다. 시험 삼아 네트워크 파일 복사 프로그램을 UML로 표현해보겠습니다. 뒤에 나오는 그림들을 이
해하고 해당 프로그램을 코딩할 수 있다면 이 책을 읽을 수 있습니다.
한 가지 당부를 드리면 여기서 사용하는 UML 표현이 틀릴 수도 있습니다. 변명하자면 저는 UML
전문가가 아닙니다. 또한, 같은 개발 언어를 사용해도 개발자마다 코드가 다르듯이 UML도 사용하는
사람에 따라 표현 방법이 다를 수밖에 없습니다. 한마디로 UML에 정답은 없다고 생각합니다.

30. 들어가며 - 029
UML은 Unified Modeling Language의 약자입니다. 말 그대로 설계에 사용하는 언어를 다른
사람과 소통하기 위해서 단일화한 언어입니다. 하지만 다른 사람의 시선과 평가를 너무 의식한 나머
지 UML에 쏟는 시간과 노력이 지나쳐 설계 본연의 목적을 잃어버리는 일이 종종 생깁니다. 따라서
UML을 사용할 때는 적당한 수준으로 작성해야 하는데, 그러려면 자신만의 원칙을 세워야 합니다.
다음은 저의 원칙이자 이 책의 원칙입니다.
●
각 다이어그램 사이에는 연관성이 있어야 한다.
습관적으로 클래스를 먼저 만들지 말고, 왜 그런 클래스를 만들었는지 스토리가 있어야 한다.
●
모든 걸 명시하려 하지 말고 중요한 흐름만 명시하자.
보는 사람이 10분 이내에 모든 흐름이 파악되게 하자. 10분 이상의 내용 공유는 회의 소집 후 종이와 연필이
더 효과적이다.
●
중요한 제약사항이나 알려진 이슈(Known-Issue)들은 반드시 명시하자.
중요한 건 한눈에 보이도록 노트를 활용하자. 그래야 PM이나 기획자가 이해할 수 있다.
이 원칙들은 4장 설계에서 실습해보겠습니다.
다음은 앞에서 언급한 네트워크 파일 복사 프로그램을 UML로 표현한 다이어그램들입니다. 생소한
표현이 있다면 UML 관련 책을 보고 사전학습해 주세요. 이 다이어그램들을 이해할 수 있다면 이 책
에 사용된 모든 UML 다이어그램과 소스 코드를 이해할 수 있습니다.
그림 Requirement 다이어그램

31. 030 -
그림 UseCase 다이어그램
그림 Activity 다이어그램

32. 들어가며 - 031
그림 Sequance 다이어그램
그림 Class 다이어그램
보안 관련 개발자 관련 전망
먼저 기사 하나를 보겠습니다. 다음은 IoT 시대 보안 시장의 수요에 대한 기사01
입니다.
01 http://it.donga.com/21473/

33. 032 -
향후 5년간 연평균 7% 성장 전망… IoT 보안 시장 수요 크다
한국IDC(www.kr.idc.asia)가 최근 발간한 *보고서에 따르면, 2014년 국내 보안 소프트웨어 시장은 2013년과 비
교해 7.6% 성장하며 3,386억 원을 기록한 것으로 집계됐다.
(중략)
*Korea Security Software 2014-2019 Forecast 2014 Year End Review, Doc #KR320515174
그림 국내 보안 소프트웨어 시장 전망, 2014-2019(단위: 백만 원)
550,000
500,000
450,000
400,000
350,000
300,000
Korea Security S/W Market
2014 2015 2016 2017 2018 2019
CAGR
2014-2019
7.0%
출처 IDC, 국내 보안 소프트웨어 시장 전망
(중략)
보안 소프트웨어 적용 시장은 전통적인 데스크톱과 노트북뿐만 아니라 BYOD 및 스마트워크 문화 확산에 따라 태
블릿PC, 스마트폰 영역은 물론 IoT 환경으로까지 시장이 확대되는 모습을 보였다. PC는 물론, 모바일 환경에서도
악성코드 감염을 통해 개인정보, 피싱, 파밍 공격을 통해 금융정보를 탈취하는 사례가 늘어나고 있으며, 모바일의
경우도 스미싱을 통한 악성코드 감염으로
(중략)
현재 헬스케어 기기는 대부분 암호화 하지 않은 평문 형태의 정보를 전송하고 있기 때문에 가장 우려가 큰 보안 위
협중 하나로 꼽히고 있어, IoT 보안과 관련된 시장 지속적으로 확대될 것이라고 말했다
IDC는 올해 국내 보안 소프트웨어 시장이 7% 성장하며 3,620억 원 규모를 형성할 것으로 전망하며 향후 5년간 연
평균 성장률도 7%를 유지, 오는 2019년 4,940억 원 규모에 이를 것으로 내다봤다.

34. 들어가며 - 033
IoT가 성장하면 인터넷에 연결되는 디바이스가 증가할 테고, 디바이스가 증가하면 보안 시장도 성
장할 겁니다. 누구나 예상할 수 있는 이야기인데요. 저는 숨겨진 성장 요소가 더 있다고 생각합니다.
이를 알아보기 위해 잠시 보안 컨설턴트가 돼 보겠습니다.
SKIP 이후 다음과 같습니다.
1. IoT 성장에 따른 보안 성장과의 숨은 관계를 알아보려고 합니다.
2. 보안 컨설턴트가 돼 디바이스의 취약점 대응 전략을 세워보겠습니다.
3. 과거와 현재의 디바이스 보안 대응을 비교해봅니다.
4. 외부에서 한 디바이스에 접근할 수 있는 포인트가 증가했습니다.
5. IoT 성장에 따른 보안 시장의 증가를 예측할 때 인터넷에 연결된 디바이스 수에 연결 포인트를 곱해야 합니다.
6. 현재 예상보다 더 많은 보안 인력이 필요할 것입니다.
시간이 없고 앞의 내용을 이해했다면 다음 장으로 넘어가세요.
서두에 이야기했듯이 보안에도 여러 분야가 있습니다. 그중에 보안 컨설턴트는 기업이나 디바이스
내 데이터 흐름을 파악해 보안상 문제가 없도록 구조를 개선하거나 프로세스 강화 가이드를 제시합
니다. 어렵게 보이지만, 어찌 보면 우리가 이미 초등학생 때부터 해왔던 일입니다(실제로 보안 컨설턴트
는 많은 경험과 다방면의 역량이 필요합니다. 오해 없길 바랍니다).
이 시리즈에는 ‘임나훤’이라는 가상의 인물이 등장합니다. 내용에 필요한 상황을 묘사할 때 등장하는
인물입니다. Security School은 이 임나훤 군의 성장 스토리이기도 합니다.
1980년대, 초등학생인 임나훤 군은 명절날 세뱃돈으로 많은 돈을 받았습니다. 큰돈이 생긴 임나훤
군은 호시탐탐 기회를 엿보는 형제들로부터 세뱃돈을 보호해야 합니다. 이를 UML의 Deployment
다이어그램으로 표현해보겠습니다.
1. 일단 방안에서 가장 찾기 어려운 곳을 찾는다.
2. 방안으로 들어올 수 있는 곳이 어딘지 살핀다.
3. 창문은 꼭 필요한 게 아니니 막아버리자.
4. 남은 건 방문뿐이다.
5. 방문에 자물쇠를 추가하자.

35. 034 -
그림 세뱃돈을 보호해야 하는 나훤군
시간이 흘러 2000년대, PC로 은행 거래를 할 수 있는 시대가 됐습니다. 임나훤 군은 보안 컨설턴트
로 근무 중입니다. 첫 번째 임무는 PC 내 공인인증서 보안 가이드 작성입니다. 임나훤 군은 다음과
같이 생각했습니다.
1. 공인인증서를 숨겨야 하니 암호화를 하라고 한다.
2. 외부로부터 해당 PC에 접근할 수 있는 경로를 찾는다.
3. USB 메모리는 사용도가 낮으니 비활성화를 권고한다.
4. 관리자가 네트워크 연결은 꼭 필요하다고 한다.
5. 방화벽 설치를 권고한다.
그림 2000년대 신입 보안 컨설턴트의 업무

36. 들어가며 - 035
두 가지 상황을 비교해보니 목적어만 다르고 동사의 패턴은 같다는 것을 알 수 있습니다. 이를 표로
정리하면 다음과 같습니다. 생각의 패턴을 보면 불필요한 유입경로를 줄이고 꼭 필요한 경로에는 보
안 솔루션을 도입함을 알 수 있습니다.
순서 생각의 패턴 초등학생 보안 컨설턴트
1 중요한 걸 숨긴다. 세뱃돈 공인인증서
2 외부 유입 경로 탐색 창문, 방문 USB, 네트워크
3 경로 최소화 방문 네트워크
4 보안 솔루션 도입 자물쇠 방화벽
시간은 흘러 2017년, 임나훤 군은 부장급 보안 컨설턴트가 됐고 IoT 시대에 살고 있습니다. 앞에서
와 같은 논리로 스마트폰을 보안 컨설팅해볼까요?
그림 2017년 스마트폰 보안 컨설팅
눈치가 빠른 여러분 이미 알아챘을 겁니다. 디바이스는 하나지만, 외부로부터 들어오는 유입 경로,
그것도 꼭 필요한 유입 경로가 2배가 됐습니다. 따라서 필수 보안 솔루션도 2배가 돼야 합니다.
제가 보안 시장의 성장을 확신하는 이유가 이것입니다. 최악에는 IoT의 시대가 늦어진다고 해도 각
디바이스로의 유입 경로는 지금보다 더 많아질 겁니다. 경로가 많아지면 배치해야 하는 보안 솔루션

37. 036 -
의 숫자도 증가하고 종류도 다양해져야 합니다. 그만큼 보안 솔루션 개발자에 대한 수요도 늘어날 겁
니다. 지금도 현장에서는 보안 솔루션 개발 경험자를 찾기 힘든 실정입니다. 제가 PC 보안 회사에서
TV 개발 회사로 이직할 수 있었던 것도 같은 이유입니다.
다음은 가트너에서 예상한 인터넷에 연결된 디바이스의 개수를 전망하는 그래프입니다. 여기에 유입
경로로 2를 곱한다면 어떻게 될까요? 미래의 보안 시장은 현재 사람들의 예측치보다 더 성장할 것입
니다. 먼 미래의 이야기가 아닌 지금의 이야기입니다. 보안 개발자에 대한 수요가 증가해 모든 개발
자가 관심을 가질 때는 이미 늦었습니다. 여러분이 지금 준비한다면 5년, 10년 뒤 여러분의 가치도
높아질 것입니다.
그림 가트너의 IoT 단말기 매출 예상 그래프02
(단위: 백만 달러)
18,000
16,000
14,000
12,000
10,000
8,000
6,000
4,000
2,000
출처: 가트너(2014년 10월)
2013 2014 2015 2016 2017 2018 2019 2020
소비자
자동차
공업
기타
0
20,000
시리즈 전반을 설명하다 보니 서론이 길었습니다. 이제 백신 개발을 시작합니다.
02 http://www.ciokorea.com/news/22966

38. 설계부터 개발까지
직접 만들면서 배우는 보안 개발 시리즈 - Security School
ISBN 978-89-6848-736-1
9 788968 487361
9 3 0 0 0
보안과 해킹 / 분석 방어
정가 24,000원
예제 소스 http://www.schoolime.com/securityschool/antivirus/files
● 리눅스 환경에서 동작하는 보안 솔루션을 개발하며 기본 구조를 이해할 수 있습니다.
● 백신 개발을 시작으로 시스템 보안과 네트워크 보안까지 개발합니다.
● 다 만들어진 코드를 설명하는 게 아니라 기획/설계/구현하는 방법을 이야기합니다.
● 보안 개발을 처음 시작하는 학생과 직장인을 대상으로 합니다.
● 최대한 쉽게 구현합니다.
● 누구나 보안 개발자가 될 수 있다는 꿈과 희망을 선사합니다.
시리즈 소개
● UML 실용 설계 - UML을 효과적으로 사용하는 방법으로 간결한 코드만으로도 모든 요
구사항을 만족시킬 수 있습니다.
● 현실주의 - 현업에서 실제로 일어나는 일들과 그에 맞는 개발 프로세스를 이야기합니다.
● 모듈식 구성 - 원하는 목적에 맞춰 골라 읽을 수 있습니다.
● 손 안에 기술서 - 한 권의 내용을 1주에서 2주 정도면 정독할 수 있는 분량으로 짧게 구성
합니다.
주요 특징
● C 언어
● 간단한 소켓 프로그래밍
● 리눅스 커널의 역할 이해(단, 커널 개발 경험은 없어도 됩니다.)
● UML과 VMWare 사용의 이해
사전 지식
(권장)