심사원의 자질(?)이 논란이 되자 2015년 신설된 ISMS인증심사원 선발시험에 응시해 취득한 ISMS인증심사원 자격과 기존의 PIMS인증심사원 자격의 통합되었다. 그로인해 작년 부터 숙원 사업(?)이었던 ISMS-P 인증심사원 자격을 취득했다. ISMS 인증심사원 자격만 갖고 있었기에 자격전환 시험을 치러야 했고.. 자격전환교육(2일)을 이수하고 만만하게 보고 치렀던 시험에서 1차 낙방을 겪었다.

시험의 난이도는 상상이상으로 어려웠고 대부분의 지인들이 증언하는 불합격 인증은 70점 커트라인에 합격율이 2~3%에 지나지 않는다는 소문이 사실임을 입증해주었다. 말도 많고 탈도 많았던 1차 시험이었다.

남은 기회는 두 번... 세번째 시험까지 치르기 싫어 도서관을 들락거렸고 난이도 조절을 했는지 조금 수월하게 2차 시험을 치렀고 무난히 합격할 수 있었다. 도서관을 드나들면서 지난 1회 ISMS인증심사원 시험준비할 때가 자꾸만 생각났다. 비슷한 방법으로 시험준비를 한 뒤 응시했고...

그리고 오늘.... 드디어 ISMS-P 인증심사원 자격증을 이메일로 받았다.

ISMS-P 인증심사원 자격전환 시험 합격 문자 및 자격증

전환시험 합격 후 1개월 하고도 20일만에 받은 ISMS-P 인증심사원 자격증이다. 2015년 ISMS인증심사원 필기시험 1회에 합격하여 ISMS인증심사원 자격 취득 3년만에 개인정보보호 관리체계 인증심사(ISMS-P)에도 참여할 수 있는 자격을 보유하게 되었다.

이젠 또 무엇에 도전해야 할까...

20년 넘는 시간의 직장생활을 그만두고 자유롭게(?) 일한지 만으로 2년이 되어간다.

20년...

지난 20년간 모두 4개의 회사를 경험했다. 두 회사는 합해서 2년을 채우지 못했고 두 회사는 각각 8년과 10년이 넘는 시간동안 재직했다. 그리고 그 안에서 대여섯 개의 본부와 팀을 경험했다. 그리고 운이 좋았는지 초반 4~5년이 지난 뒤 부터 때로는 작고 때로는 큰 조직을 맡아 리더의 역할을 수행할 수 있었다. 그리고 그 긴 시간동안의 경험을 바탕으로 팀과 본부급의 조직에서 리더가 갖추어야할 조건들에 대해 참 많은 것을 깨닫는 시간이기도 했다.

어떤 조직이든 조직의 리더에게는 리더쉽이 필요하다. 하지만 중요한 것은 조직의 리더가 갖추어야할 역량이나 능력은 조직이 처한 상황이나 구성원의 특징 혹은 조직의 분위기에 따라 모두 다르다는 점이다. 전에도 쓴 적이 있지만 (보러가기) 언론이나 자기계발서와 같은 책에서 떠드는 현실과 동떨어진 리더쉽을 마음에 담아두고 따라하려 해서는 안된다는 것이다.

흔히 리더쉽을 이야기하면 많은 사람들이 카리스마, 친화력 등 단순히 인간관계에서 한 사람을 돋보이게 하는 능력들을 이야기하지만 사실 그런 능력은 조직을 이끄는데 있어 양념의 역할은 할 수 있으나 그런 리더쉽은 대다수의 조직에서 조직을 제대로 이끌어 성과를 내는데는 큰 도움이 되지 못한다는 사실을 간과한다.

팀장이 카리스마가 있다고 팀원들이 더 열심히 일한다는 것은 아무런 근거도 없고 사실도 아니다. 다만 조직력이 잘 갖추어진 조직에서 팀장이 카리스마가 있다면 팀의 규율을 다지는데 도움이 될 수는 있다. 또한 팀장이 친화력이 좋다고 팀원들이 열심히 일하는가? 팀장의 친화력은 그저 팀의 수직적 커뮤니케이션을 원할하게 하는데 도움을 줄 뿐이다.

하지만 어떤 조직이든 리더가 갖추어야 하는 공통의 덕목 혹은 능력은 분명히 있다. 20년의 조직생활에서 깨달은 몇가지 리더의 조건에 대해 써보고자 한다.

솔선수범(率先垂範)

너무 식상한가? 이 네 글자를 보고 "겨우 이 이야기를 하려고.."라는 느낌이 찰라의 순간이라도 들었다면 당신은 지금까지 리더의 자격이 없었다고 단언하여 말해주고 싶다. "맞아..!!"라고 무릎을 쳤어야 한다. 율곡선생이 왕에게 "솔선수범"할 것을 직언했을 만큼 솔선수범은 리더가 갖추어야할 첫 번째 덕목이다.

직원들에게는 회사가 어렵다며 비용절감을 외치고 업무 수행에 필요한 최소한의 업무추진비 마저도 쓰지 못하도록 이런 저런 제약을 가하면서 사장이나 본부장, 팀장이 차량을 지급받고 직원들이 상상하기 힘들만큼 법인카드를 쓰고 다닌다면 직원들은 결코 회사에 애사심을 갖지 않는다. 당연히 조직의 성과도 기대할 수 없다.

또한 업무에 있어서도 솔선수범해야 한다. 예를 들어 직원들에게 출근시간을 지키도록 강요하면서 임원들이나 팀장들이 출근시간을 제대로 지키지 않는다면 누가 과연 업무에 충실하겠는가? 

또한 특정업무를 직원에게 시키기 전에 리더가 그 업무를 훌륭하게 해내는 것을 직원들에게 직접 보여줘야 한다.직원들은 자신들의 리더가 자신에게 할당한 업무를 훌륭하게 해낼 수 있다는 것을 믿을 때 그 업무에 보다 적극적으로 나선다. 리더가 그 업무를 완수하는 것을 본적이 없다면 직원들은 그 업무를 리더가 훌륭하게 완수할 수 있다고 생각하지 않는다. 즉, 업무를 대충해도 리더가 그 업무의 결과에 대해 제대로 판단할 수 없을 수도 있기에 적극적으로 업무를 수행하지 않는 것이다. 반면 리더가 그 업무를 완벽하게 수행해내는 것을 본 직원들은 최소한 리더가 수행한 만큼의 완성도를 추구하며 업무를 수행하게 된다. 리더가 수행하여 완수한 완성도가 직원들이 업무를 수행했을 때의 최소한의 기준이라고 각인하기 때문이다.

때문에 리더는 리더에게 속한 직원들이 보고 따라야하는 업무 수행의 목표가 되어야 한다.

나 또한 15년 동안 조직을 이끌면서 가장 신경을 썼던 대목이기도 하다.

적재적소(適材適所)

리더는 직원의 능력과 경험치에 따라 업무를 수행하기에 가장 적합한 직원에게 업무를 할당해야 한다. 많은 리더들이 제대로 갖추지 못한 능력 중 하나다. 리더가 갖추어야 하는 적재적소의 덕목은 직원의 업무수행 능력과 업무 난이도의 균형을 맞춰 능력을 낭비하는 일이 없도록 하는 것이며 또한 업무에 문제를 야기하지 않도록 하는 능력이다.

너무 어려운 업무를 능력이 되지 않는 직원에게 할당하거나 쉬운 업무를 탁월한 능력을 가진 직원에게 할당하는 실수를 범하면 안된다. 

또한 직원들은 모두 각자의 장점과 단점을 갖고 있다. 조직에서 수행해야 하는 모든 업무에서 탁월한 능력을 발휘하는 직원은 없다고 생각해야 한다.(멀티플레이어는 없다.) 따라서 조직에서 수행하는 다양한 업무를 잘 수행할 수 있도록 직원들을 적재적소에 배치하는 능력은 리더가 갖추어야할 매우 중요한 덕목이다. 

영업적 능력이 떨어지는 직원에게 영업을 맞긴다든가 화술이 부족한 직원에게 프리세일즈 업무를 맞기고 직원들을 통솔하는 능력이 떨어지는 직원에게 특정 조직이나 프로젝트의 리더를 맏기는 등의 과오는 적재적소의 능력을 갖추지 못해 발생하는 문제다. 

자기에게 맞지 않는 옷을 입은것 같은 직원들은 당연히 저성과의 늪에 빠지게 되고 다른 직원들과의 업무적 관계에서 서로에게 불만을 갖게 되며 불평을 입에 달고 살게 된다. 이런 조직은 당연히 업무성과가 떨어질 수 밖에 없고 조직이 사분오열될 수 밖에 없다.

존중(尊重)과 공정(公正)

리더는 직원들을 인격적으로나 업무적으로 존중해야 한다. 그리고 공정해야 한다. 주변에서 흔히 직원들이 수행한 업무의 결과에 대해 너무 쉽게 소리지르고 꾸짓고 인격적으로 상처를 받을만큼 혼을내는 경우를 흔히 볼 수 있다. 그렇다고 제대로 코멘트를 해주는 것도 아니면서 말이다. 또한 사적인 친분이 쌓인 직원과 그렇지 못한 직원의 업무 결과에 대해 공정하지 못한 평가를 하기도 한다.

여러 직원이 함께하는 회의 시간에 친하다는 이유로 특정 직원에게 반말로 업무를 지시한다거나 직원들을 하인 부리듯 하며 무시하는 경우도 흔히 볼 수 있다. 둘 만의 공간에서 사적인 대화나 가벼운 업무상의 이야기를 할 때는 반말을 할 수도 있겠지만 여러 직원이 함께하는 공식적인 회의 석상에서 반말은 상황과 분위기를 봐가며 해야한다. 본인은 직원들을 존중하는 언행을 하고 있다고 생각하지만 막상 직원들은 존중받지 못하고 있으며 공정하지 못한 대우를 받고 있다고 느끼는 경우가 의외로 많다.

또한 직원에게 지시하여 작성된 보고서나 결과에 대한 검토 시 언성을 높이거나 (제대로 업무를 가르쳐주지도 않았으면서) 타박을 하는 행위는 결코 있어서는 안된다. 또한 그 결과물을 타박하고 처음부터 직접 다시 작성하거나 대대적으로 수정하는 행위 또한 피해야 한다. 이는 직원이 "그럴 거면 왜 시켰냐?" 라는 불만을 갖게되는 직접적인 원인이 되며 이후 다른 업무를 수행할 때도 "어차피 혼나고 다 고쳐질텐데..."라는 패배의식을 심어주게 된다. 번거롭더라도 함께 검토하며 수정 방향을 꼼꼼히 체크해주고 업무 담당자가 직접 수정하도록 하여야 하며 모두 완료되면 "칭찬"을 빼놓지 말아야 한다.

또한 주의해야 할 것은 "사적인" 일을 시키지 말아야 한다는 것이다.

쓰레기통을 비우게 한다든가 심부름을 시킨다던가 하는 행위는 삼가야 한다. 때로는 부탁을 통해 작은 일들을 시킬 수도 있겠지만 당위성은 항상 염두에 두어야 한다. 업무 외적인...사적인 일을 지시받고 수행하는 직원은 당연히 불만을 갖게 된다. "내가 심부름이나 하려고 이 회사에 입사했나?"라는 생각을 한번 쯤 안해본 사람은 없을 것이다. 그만큼 불만의 원인이 된다. 게다가 사적인 친분이 있다고 사적인 일을 시키거나 친하지 않은 직원에게 차별하는 듯한 업무를 맏기는 불공정은 최악의 리어가 되는 가장 빠른 지름길이다.

리더로 부터 존중받지 못하고 공정한 평가를 받지 못하는 직원들은 겉으로는 리더를 따르는 듯 보일 수 있지만 마음 속으로는 매우 강렬한 반감을 갖게 되며 조직의 다른 구성원과의 관계도 나빠질 수 밖에 없다.

공부(工夫)

내가 기술분야의 직업을 갖고 있기 때문인지는 모르겠지만 공부는 이 업종을 떠나는 순간까지 게을리해서는 안된다는 생각을 하게 되었다. 더군다나 작던 크던 기술조직의 리더라면 적어도 직원들보다는 많은 것을 알고 있어야 한다.

기술인력은 두가지 종류로 구분된다. 하나는 기술자이고 하나는 기능공이다. 넓은 의미에서 기술자는 기능공을 포함한다고 할 수 있다. 하지만 엄격히 따졌을 때 기술과 기능은 분명 구분이 가능하다.

특정업무에 숙련된..즉 반복되는 기술업무에 숙련된 사람은 기능공이라 불린다. 하지만 기술자라면 경험하지 못한 새로운 이슈에 대응할 수 있는 기반기술을 가진 사람을 뜻한다. 하지만 IT업종에서 많은 "엔지니어"라 불리는 사람들은 그저 "기능공" 수준을 벗어나지 못한다. 

나는 DBA나 DB엔지니어가 아니니까...

나는 개발자가 아니니까...

나는 네트워크 엔지니어가 아니니까...

적어도 기술조직의 리더가 되고자 한다면 DB, Network, OS, Programing은 물론 시스템SW에 대한 기반 기술들은 갖고 있어야 한다. 하지만 그 많은 분야의 지식을 쌓기위해서는 끊임없는 공부가 필요하다. 기술조직에서 그저 관리를 위한 리더는 존재가치가 없다. (적어도 난 그렇게 생각한다.)

하지만 기술조직의 팀장이나 부서장들 중에서 그렇게 열심히 공부하는 리더는 찾아보기 힘든게 현실이다. 오히려 사적인 이익을 취하기 위해 회사의 내부 정치나 인맥관리를 위해 술마시기를 즐기거나 자신은 잘 모르면서 직원들에게 떠넘기고 제대로 결과를 챙기지도 못하는 리더가 오히려 많은게 엄연한 현실이다.

그래서 조직원들이 따라 줄까? 과연 성과는 제대로 나올까? 그런 엔지니어들이 사업을 수행하는데 고객은 사업 수행 결과에 만족할까? 더군다나 변화 무쌍하고 새로운 기술이 넘쳐나는 IT 바닥에서 말이다.

지금까지 생각나는 대로 두서없이 리더의 조건에 대해 써봤다. 내 성격 상 한번 쓴 글은 오랫동안 다시 보지 않기에 읽기에 좀 거북한 표현이 있을지도 모르겠다. 20년간 일하면서 존경하고 따를 만한 리더를 만난적이 별로 없기에 세상의 많은 리더들에 대해 부정적인 생각을 갖고 있는게 사실이다. (하다못해 대통령 마저도 이모양이니...)

2016년 새해들어 복잡한 심경을 정리하며 문득 나는 어떤 리더였는지..그리고 내가 모셨던 리더들은 어떤 분들이었는지를 생각하다 문득 내가 추구하는 리더의 모습은 이런게 아닐까하는 생각이 떠올라 기록으로 남겨본다.

ISMS인증제도와 ISMS인증심사원

ISMS인증제도는 기업 스스로 체계적인 정보보호 활동을 위한 관리체계가 수립되어 있는지, 그리고 관리체계가 수립되어 있다면 법적 요구사항 및 ISMS인증제도 자체의 기준을 충족하는지를 평가하고 수립되어 있는 정책, 지침에 따라 지속적인 정보보호활동을 하고 있는지를 평가하고 인증해주는 제도다.

그리고 ISMS인증심사원은 인증기준에 맞춰 정보보호관리체계를 운용하고 있는지 실사 및 평가를 수행하는 인력이다. ISMS인증심사원은 2013년 개정된 정보통신망 이용촉진 및 정보보호 등에 관한 법률과 이하 시행령 및 고시에서 그 자격에 대해 명시하고 있다.

"보"를 떼다.

인증심사원 자격을 취득하고 나면 심사 참여 경력이 없기 때문에 심사원(보)의 자격을 부여한다. "보"를 떼기 위해서는 심사 참여 4회 이상과 심사일수의 합 20일을 넘겨야 하는 두 가지 기준을 모두 충족해야 한다.

2015년 신설된 필기시험을 통과하여 인증심사원 자격을 취득하고 2016년 1월 말... 드디어 첫 인증심사에 참여하게 되었다. 모 시청의 사후심사로서 3일간 진행된 심사였다. 그리고 2016년 여름과 늦가을에 두번의 인증심사(각 4일과 5일)에 참여하였고 2017년 5월, 5일로 진행되는 심사(최초심사) 2회에 참여하여 심사참여 4회, 심사일수 20일의 조건을 모두 충족시킬 수 있었다.  

그 과정에서 아쉬운 점이 있었는데... 순수하게 실제 심사를 보고 배울 기회가 없이 바로 실무에 투입된다는 점이다. 심사에 참여하면 심사팀장은 인증기관(KISA, TTA, KAIT, 금융보안원)에서 담당하며 심사원은 KISA의 ISMS 홈페이지에 공고하여 모집한다. 그리고 심사팀이 구성되어 심사를 수행하게 되면 관리과정은 심사팀장이 담당하고 보호대책의 13개 분야를 나머지 팀원이 분할하여 심사를 수행하는 것이 일반적이다. 이 때 심사 경험이 있든 없든... 몇개 분야를 맡아서 심사를 진행해야 한다. 즉, 처음 심사를 나가는 심사원은 맨땅에 헤딩을 하는 상황이 발생한다.(물론 5일 간의 심사원 교육을 받기는 했지만....)  게다가 심사일정이 매우 빡빡하기 때문에 다른 심사원의 도움을 기대하는 것도 불가능하다. 때문에... 심사원(보) 때는 심사원 1명을 함께 보내 OJT 형태의 심사를 수행하도록 하는 것이 바람직하지 않을까 싶다.

어쨌든 "보"를 떼고 본격적인 인증심사 경험을 쌓기 위해 열심히 심사 참여 신청을 하고 있다.

로그 수집 이슈

서버 HW, 운영체제 그리고 서버에서 실행되는 웹 서버 등의 애플리케이션의 상태와 해킹 시도 등을 탐지하기 위해 각종 로그를 수집하는 것은 서비스 상태의 모니터링과 보안관제 등의 업무에서 필수적인 요소다.

그래서 ESM(Enterprise Security Management) 솔루션은 물론이고 SIEM과 보안관제 등의 솔루션에서 서버에 쌓이는 로그파일을 수집하는 기능을 제공하며 로그를 수집하기 위해 Syslog 를 이용하는 등 다양한 방법을 사용할 수 있다. 하지만 syslog나 snmp 등을 지원하지 않는 웹서버 로그나 DB로그 그리고 인하우스 애플리케이션의 로그는 별도로 프로그램을 개발하거나 유료SW를 설치하지 않으면 수집하지 못하는 경우가 많다.

특히나 로그를 수집하는 로그 수집 및 분석 솔루션들은 돈을 더~ 벌기위해 로그를 수집하는 간단한 프로그램을 유료로 판매하는 경우가 많다. 하지만 대부분 FTP나 SFTP를 통해 지정된 로그파일을 다운로드 받을 수 있는 기능을 제공하는 경우가 많은데 이 때 사용할 수 있는 간단한 로그 수집 스크립트를 Perl로 작성해보았다.

로그 수집 스크립트를 작성할 때 고려해야할 점은 몇가지가 있는데....

이정도는 기본적으로 대비하여야 한다

로그의 증분 수집

아마도 많은 분들이 "증분 백업" 이라는 말을 들어보았을 것이다. 특정 시점에 데이터를 백업한 뒤 해당 시점 이후에 쌓인 데이터만 백업하는 것을 "증분 백업"이라고 한다. 로그를 수집할 때도 마찬가지 요건이 지켜져야 한다. 로그파일은 특정 시점 혹은 특정 용량에 도달할 때 까지 하나의 파일에 계속 추가 기록된다. 만약 한번 로그파일을 읽어간 뒤 일정 시간 뒤 다시 전체를 읽어가면 로그 수집 및 분석 솔루션 입장에서는 동일한 로그를 두번 읽어가는 현상이 발생하게 된다.

따라서 로그를 한번 읽어가면 어디까지 읽었는지를 기억했다가 다음번에 로그를 읽을 때 그 이후의 로그만 읽어가야 한다. 이러한 요건이 로그의 증분 수집 요건이다.

로그 로테이션의 대응

로그를 기록하는 거의 모든 SW나 장비들은 로그를 기록하며 일정 기간 혹은 일정 용량에 도달하면 로그파일을 다른 이름으로 변경하고 새로운 로그파일을 생성하여 기록한다. 이때는 이전에 읽었던 로그파일의 위치는 의미가 없어지게 되며 새로운 로그파일의 첫번째 로그부터 모두 읽어가야 한다.

로그 수집 스크립트는 이러한 상황에 대응이 되어야 한다.

로그파일 접근 에러에 대비

읽어야할 로그파일이 없거나 로그파일에 접근 권한이 없을 경우 에러가 발생할 수 있으며 이러한 상황에 대비할 수 있도록 코드가 짜여져야 한다.

로그파일의 용량이 클 경우 성능 문제 해결

읽어야할 로그파일이 클 경우 로그파일을 오픈한 뒤 이전에 마지막으로 읽어간 로그의 행을 찾아가는 과정에서 CPU 사용율이 증가하고 시스템이 느려지는 문제가 발생할 수 있다. 로그파일의 크기가 작을 경우는 전혀 문제가 되지 않지만 로그파일이 커질 수록 CPU 사용율은 점점 높아져 시스템에 문제를 야기할 수 있다.

로그파일 수집 스크립트의 작성

위의 로그파일 수집 이슈에 대응할 수 있는 스크립트를 만드는 방법은 매우 다양하다. 순수하게 Shell Script로 작성할 수도 있고 폼나게 C언어로 작성할 수도 있다. 하지만 현실적으로 가장 효과적인 방법은 Perl이나 Python 등을 이용해 스크립트를 작성하는 방법이다. 

여기서는 Perl을 이용해 작성하였다.

작성된 스크립트는 다음과 같다. 설명도 함께 달아두었다.

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

#!/usr/bin/perl

use strict;

use warnings;

my $CFGFILE = "CFG파일의 경로";

my $RFILE = "";

my $DFILE = "";

my $DSTDIR = "";

my $FILESFILE = "";

my ($rFile, $dFile, $cfgFile);

my $line;

my $ct = 0;

my $lct = 0;

my @tmpArr;

my @tmpStr;

my $strFile;

my (@srcFileName, @srcFileLine, @srcSvcName);

# CFG 파일을 연다.

open(cfgFile, "<$CFGFILE") or die("ERROR : Could not open logmon.cfg.");

while ($line = <cfgFile>) {

        if ( substr($line,0,1) ne "#") {

@tmpArr = split (':', $line);

# 읽은 파일을 저장할 경로

if ($tmpArr[0] eq "DSTDIR") {

  $DSTDIR = $tmpArr[1];

# 읽을 파일의 목록이 담긴 파일명 및 경로

} elsif ($tmpArr[0] eq "FILESFILE") {

  $FILESFILE = $tmpArr[1];

}

}

}

@tmpArr = ();

close(cfgFile);

# 읽을 파일의 목록이 담긴 파일을 연다.

open(cfgFile, "<$FILESFILE") or die("ERROR : Could not open files.cfg.");

while ($line = <cfgFile>) {

        if ( substr($line,0,1) ne "#") {

@tmpArr = split(':', $line);

# 읽을파일명:서비스명|현재까지읽은라인번호

                $srcFileName[$ct] = $tmpArr[0];

$srcSvcName[$ct] = $tmpArr[1];

$srcFileLine[$ct] = $tmpArr[2];

                $ct = $ct + 1;

        }

@tmpArr = ();

}

close(cfgFile);

# 현재날자와 시간을 구함. DSTDIR에 쓸 때 파일명에 날짜시간을 붙임.

my ($sec, $min, $hour, $mday, $mon, $year, $wday, $yday, $isdst) = localtime;

my $now = sprintf("%04d%02d%02d_%02d%02d%02d", $year + 1900, $mon + 1, $mday, $hour, $min, $sec);

$ct = 0;

$lct = 0;

chomp $DSTDIR;

chomp $FILESFILE;

# 읽을 파일명을 차례대로 루핑

foreach $RFILE ( 0..$#srcFileName ) {

  # 파일경로및파일명에서 파일명만 추출함.

@tmpArr = split('/', $srcFileName[$RFILE]);

  # 추출한 로그를 쓸 파일명을 기록

$DFILE=$DSTDIR . "/" . $tmpArr[$#tmpArr] . "_" . $srcSvcName[$RFILE] . "_$now";

  # 파일이 없으면 에러 처리

if ( -f $srcFileName[$RFILE] ) {

    # 읽을 파일의 현재 전체 라인수를 구함

$lct = `wc -l $srcFileName[$RFILE] | awk '{print \$1}'`;

    # 전체라인수에서 이전까지 읽은 라인수를 뺌. 즉 추출해야하는 라인수(끝에서 부터)

        $ct = $lct - $srcFileLine[$RFILE];

# tail 명령의 조합.

        $strFile = "tail -" . $ct . " " . $srcFileName[$RFILE];

     # 읽어야할 라인이 있으면...

        if ( $ct > 0 ) {

                $strFile = "tail -" . $ct . " " . $srcFileName[$RFILE];

                `$strFile >> $DFILE`;

# 파일 로테이션 되었으면 

} elsif ( $ct < 0 ) {

                $lct =~ s/\n//g;

                $strFile = "tail -" . $lct . " " . $srcFileName[$RFILE];

                `$strFile >> $DFILE`;

}

} else {

$lct = "0";

        }

chomp $lct;

  # 읽어야할 파일목록에 현재까지 읽은 라인 수 기록

open($cfgFile, ">>$FILESFILE.new") or die("ERROR : Could not open file - $FILESFILE.new -.");

        print $cfgFile "$srcFileName[$RFILE]:$srcSvcName[$RFILE]:$lct\n";

        close($cfgFile);

}

# 새로운 읽어야할 파일목록이 저장된 파일교체 (읽은 행수 반영) 

unlink $FILESFILE;

rename "$FILESFILE.new" , $FILESFILE;

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

이렇게 작성된 스크립트는 Crontab 에 등록하여 5분 간격 혹은 그 이상의 주기로 정기적으로 실행하도록 하면 된다.

데이터가 잔뜩~ 들어있는 엑셀 시트를 이용하다 보면 셀을 병합해야할 때가 있죠. 그럴 때마다 병합할 셀을 영역으로 선택하고 셀서식 페이지를 열고 맞춤 탭을 선택한 뒤 셀병합을 체크하는 작업은 한마디로 "노가다" 입니다. 병합해야하는 셀이 몇개 안되면 모르지만 수천라인에 있는 여기저기 흩어져 있는 수백개의 셀을 병합하는 것은 노가다 중에서도 고된 노가다죠. 

마침 방화벽 정책을 마이그레이션 하는 과정에서 기존의 정책을 이관시키고 관련 정책 문서를 만들어줘야 하는 상황이 생겼는데 기존 정책을 엑셀로 받아 Copy/Paste 방식으로 통합하다 보니 단위 정책들이 있는 셀을 병합해야 했습니다. 이 노가다를 팀원이 해야하는 상황이라 매크로를 만들기로 하고 인터넷을 뒤졌습니다.

그런데 인터넷을 뒤져보면 셀병합을 하는 매크로와 셀병합 시 사라지는 데이터를 유지하는 매크로는 있지만 아래 사진처럼 여러개의 열을 한꺼번에 처리하는 매크로는 찾을 수 없었습니다. 

병합 전

병합 후

이럴 경우 보통은 병합 작업을 세번 반복해야 하는 어려움이 있습니다. 이런 병합을 한번에 해내는 매크로 입니다.

셀의 다중 병합 매크로

다중 for 문과 if 문을 알고 배열처리에 대한 개념이 있는 분이라면 이 매크로를 이해하는 것은 그리 어렵지 않습니다. 다만 Range로 선택된 각 열의 첫번째 셀의 값이 사라지는 문제가 있어서 한시간 정도 싸움(?)을 했습니다. 그 원인은 rStr 변수를 초기화하는 과정에서 rStr = "" 과 같이 초기화할 경우 엑셀에서 병합되는 첫번째 셀의 데이터를 제대로 표시하지 못하는 문제가 있기 때문인 듯 했습니다.

그래서 rStr 변수를 초기화할 때 각 열의 첫번째 셀의 값으로 초기화해주니 잘 수행이 되었습니다. ( rStr = cRng.Cells(1,t) 부분) 

위의 매크로는 아래 화면처럼 C4 에서부터 E8 까지 선택하면 각 열 기준으로 행의 병합을 반복 수행해줍니다. 

셀병합의 노가다로 고생하는 많은 분들에게 도움이 되면 좋겠네요.

주의!  행 전체를 선택하여 영역을 지정하면 무한루프에 빠질 우려가 있으니 반드시 사각형 영역 선택을 하시기 바랍니다.

        그리고 매크로에 대한 자세한 설명은 생략합니다.

2016년 7월 21일 오전...

지난 6월의 후반부 2주...그리고 7월 첫주의 토요일까지 5일간 이수한 개인정보영향평가 전문교육과 마지막날 치러진 평가시험의 결과가 어제 아침... 이메일로 송부되어 왔다.

그리고 함께 수신된 인증서...

이 개인정보영향평가에 대한 자세한 정보는 행정자치부에서 운영하는 "개인정보보호 종합포털"에서 확인할 수 있는데 개인정보 영향평가를 받고자 하는 기관은 반드시 개인정보 영향평가 전문교육을 이수하고 인증시험을 통과한 전문인력으로 구성된 영향평가팀에게 영향평가를 받도록 법제화되어 있다.

때문에 요즘(2016년)은 이 PIA자격증만 있으면 개인정보 영향평가 기관으로 지정받은 전문업체나 보안컨설팅업체에 어렵지 않게 취업이 가능하다고 하는 핫한 직종이다.

자세한 개인정보 영향평가 전문교육과 시험 내용은 카페에 올렸다. (보러가기)

2년 전... 전자정부 정보보호 솔루션페어 참가 이후 행사 참여는 일절 없었는데 2년 만에 작지만 포럼에 참가하게 되었다. 내가 하는 "서버보안" 일이 보안업계에서도 그다지 겉으로 드러나지 않는 분야이기에 세미나나 포럼 등 참가할 일이 사실 거의 없다.

서버보안은 많은 사람들이 그저 "운영체제의 보안 설정 잘해주면 되는거 아냐?"라고 생각하기 일쑤다. 하지만 운영체제의 보안설정이라는 것이 운영체제가 갖고 있는 근본적인 취약성을 제거해주지는 못할 뿐더러 "내부통제" 측면에서 봤을 때는 사실상 "보안 설정을 하나 안하나" 별반 차이없는 수준이기에 서버보안SW는 꼭 필요한 존재라 할 수 있다.

그리고 최근 이슈가 되고 있는 ISMS(정보보호관리체계) 인증 의무 대상 기업 확대에 종합병원 급의 대형 병원들이 무더기로 포함될 것으로 보이면서 매년 2회씩 진행되는 병원협회의 의료정보화 발전 포럼에서 이번엔 ISMS와 관련된 내용들이 많이 포함되어 있었다. 그리고 실제로도 대형병원의 정보시스템 부서와 보안 담당자 분들이 대거 참여할 것으로 예상되었고 실제도로 많은 분들이 관심을 갖고 참여하였다.

이번 포럼에서 우리회사는 "서버보안시스템 소개" 세션의 발표와 전시부스 운영을 맡아 진행하였다.

전시부스 사진... 사실 전시부스는 세개업체에서만 참여하였다. 포럼이 열린 연세세브란스병원 은명대강당의 구조상 그 이상의 부스는 설치가 어려워보였다. SecureOS인 RedCastle과 이중인증 그리고 명령어 통제 워크플로를 지원하는 AuthCastle과 통합감사서버인 AuditCastle.. 이 세개의 솔루션이 서버보안 시스템을 구성한다. 그 어떤 솔루션보다 "서버의 보안 접근 통제 및 내부통제강화"에 막강한 능력을 발휘한다. 그래서 내가 10년 넘게 서버보안 분야에 몸담고 있을 수 있다.

2016 병원 의료정보화 발전 포럼의 프로그램.. 오후 2시40분.. 한참 식곤증이 밀려올 타이밍.. 서버보안시스템 소개 세션이 있었다. 오전엔 이번 포럼의 핵심 주제인 보안과 ISMS 인증관련 세션들로 가득차 있다.

서버보안시스템 소개를 비롯해 하루종일 발표가 이어진 은명대강당.. 서버보안시스템 소개 세션 장면.. 홍성훈 차장이 찍어준 사진.. 교육, 제안발표, 설명회 등을 통해 자주 발표를 하지만 할 때마다 떨린다는.. -.- 이놈의 무대 울렁증은 사라질 줄을 모른다.

아래는 발표자료의 핵심 내용 중 하나인 "서버보안시스템"과 ISMS 인증기준의 관계를 정리한 장표..

사실 아직도 많은 기관과 기업에서 ISMS 인증기준 대비 제대로 된 보호대책을 수립하지 못하고 있는 것이 현실이다. 수립하고 있더라도 관리자 수준에서 모두 무력화 시킬 수 있는.. 서버보안 분야에서 일하고 있는 내 기준에선 내부통제 관점에서 볼 때 제대로 된 보호대책이라 인정하기 힘든 수준에 머무르고 있는 경우가 대부분 이다. 서버의 보안을 강화하기 위해선 서버 내에 강력한 통제 기능을 가진 서버보안SW가 필수적인 이유다. 게이트웨이 형태의 보안장비를 도입해서 해결할 수는 없는 것이 바로 "서버의 보안 강화" 숙제다.

2014년 겨울...

10년 여의 보안업계 근무 경력을 증거할 무언가를 만들기 위해...그리고 혹시나 모를 이직에 대비하기 위해 필기와 실기를 합쳐 평균 10% 내외라는 합격율을 자랑(?)하는 정보보안기사 자격증을 취득했다.

그리고 강화된 ISMS 인증심사원 제도가 시행된 첫 해인 2015년, 서류전형 및 필기시험과 5일간의 교육 그리고 실기 시험을 거쳐 자격증을 취득하게 되었다. (ISMS 인증심사원 필기시험과 심사원 교육 후기)

ISMS 인증심사원 제도

ISMS 인증심사원은 2014년 까지는 "위촉"의 형태였다. 위촉의 사전적 의미는 다음과 같다.

즉 한국인터넷진흥원(KISA)에서 심사를 대행할 심사원을 모집하여 교육과 시험을 거쳐 통과된 사람에게 심사를 대신 위탁하는 것이다. 그래서 ISMS 인증심사원들에겐 "자격증"이 아닌 "위촉장"이 주어졌다고 한다. (자격증이라 명시되었지만 실제론 위촉장이었다고 함)

하지만 2013년 개정된 정보통신망 이용촉진 및 정보보호 등에 관한 법률과 이하 시행령 및 고시에서 다음과 같이 인증심사원의 자격 요건을 명시하고 있다.

그리고 2014년 하반기까지는 별도의 시험없이 서류심사만으로 인증심사원 교육 대상자를 선발하여 교육을 실시하고 실기시험을 거쳐 인증심사원으로 위촉하였다. 하지만 지속적으로 인증심사에 대한 여러가지 문제점이 대두되자 2015년 부터 서류심사-필기시험-교육-실기시험의 4단계 전형을 실시하는 것으로 제도가 변경되었다.

제도가 변경되면서 2015년에는 필기시험이 치러졌으며 심사원도 "위촉"이 아닌 "국가 공인 자격"으로 인정받게 되었다. 그리고 합격율이 역시나 10% 정도 였던 2015년 필기시험에 운이 좋았는지 합격하고 교육을 거쳐 실기 시험을 치른뒤 ISMS 인증심사원 자격을 취득한 첫 기수(?) 되었다.

직장에 적을 두고 일을한지 20여년... 이제 앞으로의 20년(?)을 위한 전환점이 되지 않았나 싶다.

개발..DBMS..시스템(서버위주) 성능/장애/이벤트 통합관리..그리고 보안... 다양한 기술업무를 주 업무로 수행한지 15년.. 그리고 최근 몇년간은 프리세일즈 업무를 수행했다. 

지난 2~3년간 현재하고 있는 일 보다 한단계 발전적인 일을하기 위한 여러 시도를 했었고 그 마지막 결실의 수확을 눈앞에 두고 있다.

바로 ISMS 인증심사원 이다.

내가 작년부터 시도한 보안관리체계의 인증심사원 자격취득.. 작년(2014년)까지만 해도 ISMS 인증심사원 선발은 서류심사와 5일간의 심사방법론 교육과 교육 마지막날 치러지는 심사실습시험으로 이루어졌었다. 당연히 학벌.. 수행하는 업무가 보안컨설팅인지..등이 더 중요하게 서류전형에 작용했을거라 예상된다. 하지만 올해(2015년) 부터는 서류 자격 심사는 많이 완화되는 대신 필기시험이 치러졌다.

인증심사원의 자질논란 촉발

ISMS 인증심사원 선발과정에 필기시험이 추가된 이유는 현재 ISMS 인증심사를 수행하는 심사원들의 자질 논란 때문이라고 한다. 당연히 그런 논란이 발생할 수 밖에 없을 것이다.

보안관리체계의 핵심 요소 중 하나인 다양한 보안 솔루션을 조직의 보안정책에 맞추어 제대로 활용하고 있는지..그리고 관련 감사자료를 증적하고 있는지를 보는 것이 심사의 중요한 포인트 중 하나다. 하지만 현재 대부분의 기업과 공공기관에서 도입하여 운용하고 있는 보안 솔루션들은 자체적인 문제점을 매우 많이 갖고 있어 완벽하지 못한 상태로 운영되고 있는 경우가 많다.

반면 다양한 운영체제와 보안 솔루션들에 대한 기술적 이해와 경험이 없는 심사원들이 심사를 수행하고 있는 경우가 있다. 따라서 기업과 보안조직이 당면하고 있는 어려움을 이해하지 못한 채 무리하게 "원칙"만을 내세우면 심사 대상 기업에서는 "불만"을 토로할 수 밖에  없다. (ISMS/PIPL 등 대부분의 인증심사원이 서류전형과 교육만으로 심사원자격을 부여받고 있다.)   그러한 어려움을 이해하고 대체 가능한 보안정책과 보완대책을 인정하고 보완대책이 현실적인 대안이 될 수있는지를 봐주어야 하는데 현실적으로 경험이 부족한 심사원들은 그러한 유연성을 발휘하지 못하는 것이 아닐까 생각된다. (개인의견임)

인증심사원 필기시험으로 본 심사원 선발 기준

2015년 인증심사원에 지원하면서 작년(2014년)에 취득한 정보보안기사 자격증이 얼마간 도움이 되었다고 생각되며 2015년 1회 ISMS 인증심사원 필기 시험을 치른 경험을 바탕으로 보면...

1. 빠른 판단력과 이해력

시험의 형식을 보면... A4 사이즈 50 page에 육박하는 방대한 내용의 시험지가 주어진다. 문제는 단 80문제. 시간은 겨우 2시간이다. 지문과 예문 등을 꼼곰히 읽으며 생각할 시간은 없다. 누군가 그랬듯이 "동물적인 감각"으로 정답을 찾아내야 한다. 문제는 5지선다형이 대부분이고 정답 하나만 찾는 문제와 옳은 것 모두, 틀린것 모두를 찾는 문제도 출제된다.

아마도 길어야 5일인 심사기간에서 빠른 판단력과 이해력은 필수라고 생각한 듯 하다.

2. 풍부한 경험

문제를 풀다 보면 피 심사기관에서 발생할 수 있는 보안관련 이슈들이 제시해준다. 보안과련 이슈가 발견되었을 때 보안 홀은 맞지만 실제 업무를 수행하다보면 어쩔 수 없는 상황이 있게 마련이다. 이 "어쩔 수 없는"상황을 이해가고 있는지가 중요하다. 이 "어쩔 수 없는 상황" 임에도 불구하고 결함으로 지적해야 하는지, 보완대책이 있다면 PASS할 것인지를 판단해야 한다. 실무 경험이 없다면 "왜 어쩔 수 없는지"를 이해하지 못할 수 밖에 없다. 게다가 위험관리 프로세스에 대한 지식과 실무경험도 꼭 필요하다.

3. 보안 기술 지식

시험엔 일부 기술적인 지식을 묻는 문제도 출제된다. 정보보안기사와 비슷한 수준이거나 혹은 더 난이도 있는 문제도 있었다. 

제1회 ISMS 인증심사원 시험은 2015년 9월에 치러졌고 내년 부터는 초여름인 6월경에 치러질 것으로 보인다. 이 시험의 합격율은 정보보안기사와 마찬가지로 매우 낮은 편이다. 

제1회 시험에는 약 700명이 응시했다. (수험번호와 한곳 뿐인 시험장을 기준으로 추측하건대..)  그리고 합격자는 60명 내외다. (교육이 약 30명씩 2회로 나누어 진행됨) 즉 10%가 채 안되는 사람들만 합격하였다. 합격의 기준은 최소 60점 이상 그리고 필요인원 기준으로 위에서부터 짜른다고 한다.

ISMS 인증심사원 교육

필기시험에 합격하면 심사원교육을 받게 된다. 나도 겨우겨우 합격선에 들어 합격통보를 받았고 교육을 몇일 남겨둔 어제 이메일로 교육안내장을 받았다. 이메일로 날아온 교육 안내문의 커리큘럼은 다음과 같다.

교육내용은 매우 심플하다. 그냥 인증심사 실습이다. 그리고 마지막날엔 평가가 있다. 아직은 모르겠지만 작년까지의실기 시험의 합격율은 70%~80% 사이인 듯 하다. 구글링을 통해 검색해 보면 실제로 불합격한 사람의 수기도 있다. (무섭다....)

어찌됐든...이제 마지막 고비만 남았다.

마지막까지 힘을 내야겠다.

ISACA와의 인연

2002~3년 KBS에서 6개월 상주 프로젝트를 진행하던 즈음에 시험에 합격했던 CISA로 ISACA와 인연이 되었습니다... 그리고 몇년 뒤 경력 증명 자료와 함께 자격 신청을 했고 라이센스를 부여받았습니다. 그 후 몇년간은 미국 ISACA 회원으로 가입하여 CPE 입력과 회비 납부를 성실하게 수행하여 CISA 자격을 유지했었죠. 하지만 이직 한 직장에서 이직하지 않고 쭈욱~재직하면서 몇년동안 회비납부와 CPE 입력을 등한시 했더니.. CISA 라이센스가 Expire 되었습니다. 즉, CISA 자격이 취소 된 것이지요.

CISA 자격의 회복 방법

취소된 CISA 자격의 회복은 공식적으로는 불가능한 것으로 보입니다. ISACA 홈페이지에도 CPE 미등록 등 기타 사유로 CISA 자격이 취소되면 CISA 자격을 회복하기 위해서는 다시 시험을 치르고 합격한 뒤 경력을 증명해야 한다고 되어 있습니다. 하지만 "특별한 사유"로 CPE 등록이나 회비 납부가 불가하였다면 라이센스 담당자에게 이메일을 보내라고만 되어 있습니다.

정보시스템감사통제협회 저널 원고 초록제출과 기고문 선정 그리고 원고 편집/수정 과정

2015년 6월 한국ISACA의 회원에게 보내지는 저널 기고문 신청을 받는다는 메일이 눈에 띄었고 무엇에 홀리듯 신청을 했습니다. 초록까지 제출해달라 했는데 진짜 무엇에 홀리듯 초록을 작성해 보냈죠. 그리고 몇일 뒤 초록 검토를 마치고 원고를 7월초까지 제출해달라는 회신이 왔고 7월 4일인가에 1차 원고를 제출했습니다. 분량은 MS-Word 기준으로 약 7 페이지 분량이었습니다. 업무가 바쁘기에 몇일간 몰아치기로 작성하여 검토하고 제출했습니다. 평소 수행하는 업무의 연장선상에 있는 그런 수준의 일이었기에 빠르게 작성이 가능했습니다. 그리고 수정 요청이 오면 그때 조금 더 보완하자는 생각이었죠.

그리고 약 2주 뒤인 7월 중순경에 "특별기고"에 실을 수 있다는 연락과 함께 두 분의 검토 위원이 검토한 내용이 함께 왔습니다. 한분은 대폭 수정이 필요하며 전체적인 수준이 낮다...-.- 라는 평가였고 한분은 약간의 수정 후 게재해도 되겠다는...조금은 상반된 평가였습니다. 

낮게 평가하신 분은.... 저널지에 실리는 기고문도 양은 적지만 논문이라 표현하였고 비교적 높은 수준의 격식과 엄격한 문장 서술 기준 그리고 출처까지도 요구하고 있었습니다. 순간 "아...내가 너무 가볍게 생각했구나" 싶은 부끄러운 마음이 들었습니다. 그리고 한 분의 검토 위원은 비교적 너그럽게 몇가지 지적사항만을 제시하였습니다.

두 검토위원의 의견을 모두 반영하여 답변과 함께 2차 원고 제출을 하였습니다. 당연히 기한은 지켰습니다.

이후 다시 오타 및 문구 수정 요청이 있었습니다. 편집하시는 분들이 최대한 원고에 직접 손을 대지 않는다는 원칙을 지켤하는 것을 느낄 수 있었습니다. 그리하여 3차, 4차 수정 제출 후 9월 초 저널지에 최종적으로 실린다는 통보를 받았습니다.

그리고 9월 초, 정보시스템감사통제협회 저널 2015년 판을 보내주신다는 연락과 함께 배송 주소를 요청하여 알려드렸습니다. 

정보시스템감사통제협회(ISACA) 저널 2015 (통권 27호)

어제(2015년 9월 15일) 저널지를 수령했습니다.

꼼꼼하게 포장되어 있습니다.

총 5권이나 보내주셨습니다.

특별 기고란의 "서버 운영체제 접속에 대한 이중 인증 시스템 구축 사례 분석"입니다. 제 블로그에도 종종 관련있는 포스트를 올렸었습니다. 

본문입니다. 

여러차례 제품소개자료나 기술자료, 세미나 자료..그리고 교육교재나 프로젝트 산출물 등을 작성하고 책으로 제본하여 직접 작성한 글이 인쇄된 것을 본적이 있지만 저널지에 글을 실어보긴 처음인지라 무척 재미있는 경험이었습니다.

-- 관련 포스트 --

1. [2 factor 인증] 공인인증서/OTP/ARS를 이용한 자연인 기반의 서버 접근제어(텔넷, SSH, FTP 등) 기법 2012/06/23
2. APT 공격의 방어와 추적을 위한 보안 시스템 구성 2013/08/30
3. 2 채널인증과 2 팩터 인증의 차이점과 네트워크 기반 서버접근제어 2 팩터 인증의 취약점 2014/03/15
4. 금융감독원 전자금융감독규정에 서버 운영체제 계정 접속 시 2차 인증 의무화 시행되다. (2) 2014/07/17
5. [서버보안] 서버 내에서의 명령어 통제 (실행) 기술 동향 (4) 2014/08/22
6. 2차 인증 및 워크플로 기반 명령어 통제 시스템 2015/05/15

평생교육이라는 말이 있 듯... 배움에는 나이가 없다고 한다. 하지만 이 명제는 누군가에게는 진실이고 누군가에게는 거짓이다. 술과 담배 그리고 유흥과 소위 여러 잡기에 찌들어 있는 많은 사람에게 평생공부라는 단어는 그리 어울리지 않는다. 많은 사람들이 공부보다는 인맥을 만들기에 몰두하고 있기에 무언가 새로운 학문과 기술을 배우는 것에는 소홀한 것이 현실이다. 그리고 우리나라에서는 새로운 학문과 기술보다는 "인맥"이 더 큰 투자 대비 효과를 보이는 것이 사실이고 대부분의 사람들이 그렇게 믿고 있다. 그래선지 기술분야에서 일하는 30중반 이후의 엔지니어나 개발자는 정체되어 있거나 퇴보하는 경우를 많이 볼 수 있다. 나이를 먹으면서 느는 것은 체중과 술 그리고 아집과 독선 뿐인 경우가 많은 이유다.

물론... 존경스러울 만큼 기술력과 컨설팅 능력을 키워나가는 엔지니어와 개발자도 있기는 하다.

나의 비전공 분야인 정보보안

기술적인 측면에서 정보보안은 컴퓨팅과 뗄레야  뗄 수 없다. 현대사회에서 90%이상의 정보는 컴퓨터 상에서 입력되고 저장되며 가공되고 보여진다. 따라서 디지털 전기/전자/통신공학과 컴퓨터사이언스 그리고 프로그래밍은 정보보안 전문가에겐 기반기술이다. 따라서 전자공학을 전공하면서 마이크로프로세서와 프로그래밍을 독학하다시피한 내게 정보보안의 최소한의 기초는 갖추고 있다고 본다.

흔히 보안이라고 하면 해킹, 리버싱 등과 같이 기술적으로 난이도가 높은 해킹기술만을 생각하는 사람들이 많지만 정보보안의 범주가 기술적, 관리적, 물리적 관점으로 구분되는 것에서 볼 수 있듯 조직(기업 및 공공부문)의 경영 및 관리와 법률적 관점에서 IT기술을 해석하고 적용할 수 있는 능력이 필요한 경우가 더 많다고 할 수 있다. 그러기 위해서는 기술적 지식에 정보보안에 필요한 관리적 보안 측면의 지식을 더 쌓아야 할 필요가 있다.

어떤 조직에서 정보보안이라는 과제를 수행하기 위해서는 기술적 관점에서의 해커와 엔지니어 그리고 관리적 측면에서의 컨설턴트 그리고 그 두분야를 모두 이해하며 코디네이션 해 줄 수 있는 정보보안전문가가 필요하다고 생각된다. 물론 그들 모두를 정보보안전문가라 부를 수도 있지만 내 생각에는 진정한 정보보안전문가는 특정 분야의 깊이 있는 지식보다는 IT분야의 폭넓은 지식을 갖고 있어야할 필요가 더 크다고 생각된다. (물론 다양한 기술에 대한 정확한 이해는 꼭 필요하다. 단순히 "들어봤다"거나 "대충 알고 있다"가 아닌 아키텍쳐, 네트워킹, 프로그래밍 관점에서 해당 기술에 대한 "이해"가 필요하다.)

그런 면에서 난 경영 및 법률을 포함하는 관리적 측면에서의 경험이 부족하기에 정보보안전문가라 부르기에는 미흡한 면이 많다고 생각된다.

그래서 선택한 고려사이버대학교 정보보안관리학과 편입 도전

2013년과 2014년엔 오랫만에 무언가 증거를 남길 수 있는 자기계발의 계획을 수립하고 하나의 목표를 이루었다. 5회까지 시행되었고 매 시험에서 최종 합격율이 10% 안팎인 정보보안기사 자격증을 취득한 것이다. 서버의 보안만을 다루던 내게 네트워크 보안, 애플리케이션 보안 그리고 정보보호법률과 컨설팅 영역인 위험관리에 대한 공부는 매우 새로운 지식들을 습득할 수 있는 기회가 되었고 공부를 하면서 많이 부족했었음을 느꼈다. 그리고 어쨌든 학원을 다니지 않고 독학으로 정보보안기사 시험을 준비해 자격증을 취득할 수 있었다. 하지만 내 스스로 돌이켜 봐도 역시나 정보보안 전문가라 칭하기에는 많은 부족함을 느낄 수 밖에 없는 과정이었다.

그래서 정보보안관리를 체계적으로 공부하기 위해 여러 사이버대학교의 정보보안 관련 학과를 살펴보았고 가장 인지도 있는 고려사이버대학교의 정보보안관리학과의 2015년 후기 편입에 응시했다.

고려사이버대학교의 후기 편입 응시 과정

내가 응시했던 고려사이버대학교의 2015년 후기 편입은 다음의 과정으로 진행되었다.

고려사이버대학교 후기 편입

가장 중요한 과정은 학업계획서 작성과 학업소양검사다. (그리고 원서 접수 후 최종졸업학교의 졸업증명서와 성적증명서를 등기우편으로 마감시한 내에 보내야 한다. 졸업증명서와 성적증명서는 이메일과 같은 온라인으로는 받지 않는다.)

고려사이버대학교 편입에서 응시자에 대한 평가는 학업계획서평가점수 70%와 학업소양검사 평가점수 30%로 이루어진다고 한다. 난 그걸 인지하지 못한 상태에서 학업소양검사에 회사 업무시간에 응시했다가 식겁했다. 중간에 끊고 다시 이어서 응시할 수 없기 때문이다. 일단 시작하면 끝까지 가야한다. 시간은 1시간을 주는데 최소 40분 이상 소비했었다. 업무중 응시하면 곤란한 상황이 발생할 수도 있으니 주의해야 한다.

반면 학업계획서는 마감일까지 수정이 가능하다. 학업계획서에는 자기소개와 학업계획 그리고 응시사유를 평가자를 설득할 수 있도록 체계적이고도 감동(?)을 줄 수 있는 내용으로 작성해야 한다. 물론 "거짓"을 쓰면 안되겠다. 흔히 자기소개서에 "거짓"을 쓴 것으로 보이는 입사지원자들을 너무도 쉽게 볼 수 있는데 그것은 본인의 "신용"을 깎아내리게 된다. 그리고 그러한 거짓은 한번 저지르게 되면 평생...반복해 저지르게 되는 중독성이 있다. 애초에 "거짓"을 쓰거나 말하지 않는 것이 중요하다.

고려사이버대학교 2015년 후기 모집의 경쟁률

응시하고 나서 결과를 기다리는데 경쟁률이 궁금해 찾아보고 깜짝 놀랄 수 밖에 없었다. 사이버대학교 후기 모집에 그렇게 많은 사람들이 응시하리라고는 생각하지 못했었다. 경쟁률이 10대1이 넘는다니...

내가 응시했던 3학년 일반전형 공학계열의 경쟁률이 12.3대1이었다. 아마도 정보보안관리학과는 학과의 특성상 더 높은 경쟁률을 보이지 않았을까 싶다.

응시 결과

높은 경쟁률에도 다행스럽게 합격할 수 있었다. 자기소개서와 소양검사결과가 뜻밖에도 꽤나 잘 나왔던 듯하다.

고려사이버대학교

이제 등록금 내고...

열심히 공부할 일만 남았다.

앞으로 2년간은 딴 생각하지 않고 학업에 전념해야할 듯 하다. 

그리고 그 다음엔 바로 "그 것"에 도전해 봐야겠지 ??

중소규모의 솔루션을 공급하는 IT 업체의 엔지니어들은 하루에도 두 개 이상의 프로젝트를 지원해야 하는 경우가 많다. 일 년 내내 그렇게 프로젝트를 지원하다 보면 프로젝트별로 작성된 산출물에 대한 관리가 무척 어렵다. 개인적으로는 노트북이나 외장하드에 고객사나 프로젝트 별로 폴더를 만들어 저장해 두는 경우가 대부분이다. 그리고 혼자 사용한다면 폴더에 의한 관리만 잘해도 크게 문제가 되지 않는다.

하지만 문제는 산출물의 공유에서 발생한다. 

산출물이나 기술자료의 공유를 위해 FTP서버나 게시판을 이용하는 경우가 많은데 이 또한 고객사나 프로젝트 혹은 문서내의 목차 등에 의한 검색에 한계를 갖는 경우가 대부분이다. 그래서 기술 지원 업무 관리 시스템을 재구축 하면서 그누보드5를 이용해 문서 관리를 위한 기능을 만들어 보기로 했다.

아래 화면이 그누보드의 스킨을 조금 수정하고 그누보드에서 지원하는 확장필드를 이용해 만든 문서 저장 게시판이다.

그누보드5의 리스트 스킨 수정

맨 위의 문서 종류는 그누보드에서 지원하는 식별자다. 아래 게시판의 글 목록에서 "제목" 대신 확장필드에 지정한 "고객사"와 "프로젝트"를 보여주도록 했다. 

그리고 아래의 검색창에도 "고객사명"과 "프로젝트명"을 이용해 검색할 수 있도록 했다. 그누보드에서 검색창에 확장필드의 값을 지정할 경우 자동으로 확장필드에서 검색하도록 편리하게 만들어져 있었다.

그누보드5 글쓰기 스킨에 확장 필드 값 입력하기

아래 화면은 프로젝트가 선택되어진 화면이다.

등록된 산출물...

아키텍쳐 설계서가 등록되었고 "제목" 부분에 "고객사"와 "프로젝트명"이 표시되는 것을 볼 수 있다. 고객사와 프로젝트 명으로도 검색이 가능하다. 그누보드5에서 지원하는 구분자와 함께 사용하면 특정 프로젝트의 특정 산출물을 검색할 수 있겠다.

등록된 산출물 게시글의 내용을 보는 화면에도 고객사와 프로젝트명, 그리고 문서 종류를 함께 표시하도록 하였다.

산출물 관리에서 이렇게 도구를 만들어 제공하는 것 보다 더욱 중요한 것은 이 도구를 얼마나 효율적으로 사용하느냐다. 

문서의 작성자, 작성일, 버전은 물론...

문서를 등록할 때 등록자가 문서 내용의 목차,문서의 주요 내용 등을 함께 기재하여 검색의 효율을 높일 수 있도록 하는 것이 더욱 중요하다. 아무리 좋은 도구를 제공해도 사용자들이 등록된 문서를 제대로 검색해 볼 수 없다면 그 활용도는 매우 떨어질 수 밖에 없다.

다음에는...

위키를 이용한 문서 관리를 한번 연구해볼 필요가 있겠다. 위키에서도 수십..수백개의 고객사와 프로젝트 같은 키에 의한 문서 식별이 가능할까 모르겠다.

예전에 만들어 사용하던 SW 기술지원팀의 프로젝트 및 일정관리 시스템은 단지 "고객사"-"프로젝트" 단위로만 일정 등록이 가능했다. 하지만 필자가 프리세일즈를 수행하는 컨설팅팀으로 자리를 옮기면서 업무의 종류가 다양해 졌다. 

고객사 관련 업무가 아닌 제품소개자료의 작성

기술채널사의 엔지니어들을 대상으로 하는 정기교육의 강의 

또는 외부 강의...

홈페이지에 업로드 될 기술자료의 작성...

일주일에 한두 번씩 나가는 제품설명회...

등등 고객사와 프로젝트의 분류 만으로는 감당이 안되는 다양한 업무들을 함께 수행하게 되었다.

그래서... 기존의 프로젝트 및 일정관리 시스템을 리뉴얼 하면서 업무의 분류를 조금 더 세분화하여

공통업무,

세일즈업무,

컨설팅업무,

고객사,

연구/개발업무

등으로 세분화하여 업무를 등록하고 일정을 관리할 수 있도록 리뉴얼 하였다. 이 시스템은 CentOS 6.4, Apache 2, Mysql 5, PHP 5 로 구축된 서버에 그누보드 5.0을 설치한 뒤 PHP 코드를 구현하여 구축하였다. 사실 전문 개발자와 코웍할 수 있다면 판매할 수 있는 개발/영업/구현을 아우르는 CMMI 시스템을 만들어 비지니스를 해보고 싶은 생각도 있다.

1. 팀관리 및 팀원관리

어떤 시스템을 관리하든 멤버와 그룹의 관리는 필요하다. 예전의 일정관리 및 프로젝트 관리 시스템은 제로보드4의 회원시스템을 그대로 사용하였다. 제로보드는 회원관리에 그룹의 개념이 들어가 있어 그룹을 그대로 팀으로 구분하면 되었다. 하지만 이번엔 그누보드를 사용하기로 했다. 왜냐하면 그누보드에는 모든 테이블에 확장필드라는 것이 10개씩이나 존재해서 훨씬 확장성이 높기 때문이다. 회원의 정보에 확장필드를 사용하여 팀과 팀ID를 기록하여 사용하기로 했다.

당연히 그누보드의 회원에 대해 팀을 할당하고 변경할 수 있도록 페이지를 만들었다.

2. 업무 분류 관리 (카테고리, 대분류(고객사), 단위업무(프로젝트) 관리)

이 부분의 개념이 제일 까다롭다. 모든 업무 수행은 업무분류(대업무)와 단위업무(소업무)로 구분하였다. 공통업무의 "휴가"를 예로 들면 휴가는 전 사원의 공통업무다. 그리고 휴가에는 "연차휴가", "월차휴가", "병가", "공가" 등 다양한 형태의 휴가가 있다. 따라서 "휴가"라는 대업무에 4개의 단위업무가 포함된다. 

기술지원업무의 경우에는 업무분류(대업무)를 "고객사"로 잡았다. 그리고 단위업무는 "프로젝트(사업)"으로 정했다.

모든 업무를 2단계로 구분하여 등록함으로써 DB에서 업무분류 테이블과 단위업무 테이블 2개로 모든 업무를 관리하도록 설계했다. 다만 DB에는 업지만 업무분류(대분류)를 4개의 카테고리로 구분하여 대분류에 카테고리가 지정되도록 했다. 결국 3단계의 업무 구성이 이루어지도록 설계하였다.

즉 "공통업무", "고객사지원업무", "컨설팅업무", "연구/개발업무"의 4개의 카테고리 하위에 업무분류(대분류)와 단위업무(소분류)가 등록된다.

이렇게 등록된 단위 업무/프로젝트는 이슈 관리는 물론 산출물 관리에서도 주요 키로 사용될 수 있다.(보러가기)

3. 일정 수행의 유형 관리

일정관리 및 프로젝트 관리를 수행하다 보면 단순히 업무의 종류 또는 프로젝트 단위로만 분석하게 되는 것은 아니다. 일반업무나, 프로젝트, 개발업무는 모두 각 업무 특성에 적합한 업무의 유형 혹은 업무의 수행 단계가 있다.

예를 들어 내가 몸담고 있는 서버보안 프로젝트의 경우 "현황분석","설치", "정책협의", "정책적용", "감사로그분석", "정책검토/수정" 등의 단계별 업무가 있다. 따라서 이러한 단계를 일정 등록 시 "일정 유형"으로 지정하게 되면 사후 프로젝트별로 어느 단계에서 얼마나 시간을 소비했는지를 산출할 수 있다.

다만 업무분류 즉, 일반업무인지, 고객사 지원업무인지, 컨설팅업무인지, 연구/개발업무인지에 따라 모두 업무수행의 단계(일정유형)가 다르기 때문에 각각 분리하여 업무분류가 일반업무인 업무의 일정을 등록할 때와 고객사지원업무의 일정을 등록할 때 "일정유형"을 각기 다르게 지정할 수 있어야 하는 것이 이번 리뉴얼의 핵심이라고 할 수 있었다.

4. 일정 등록

업무유형(카테고리) - 업무분류(대분류) - 단위업무(프로젝트) 의 업무 구성과 일정유형의 지정이 끝나면 업무 수행에 따른 일정을 등록할 수 있다.

일정은 아래와 같이 달력에서 등록하고 관리할 수 있다.

등록된 일정은 "예정"과 "완료" 두 상태로 보여지며 제목과 내용, 분류 같은 관리 불가능한 단순한 형태가 아닌 업무분류와 단위업무, 그리고 일정유형 등 분류체계가 모두 적용되어 보여진다. 마우스 커서를 일정위에 올리면 다양한 정보가 보여지게 되도록 만들었다. 또한 팀별로 일정을 분리하여 선택된 팀의 팀원에 대한 일정만 보여지게 함으로써 그누보드의 회원시스템의 레벨에 따라 타 팀의 일정에 접근하지 못하도록 추후 수정이 가능하다.

초록색 + 버튼을 클릭하면 일정이 등록되며 일정을 클릭하면 일정을 수정할 수 있다.

일정등록 화면은 아래와 같다.

<일정 입력 편집기를 그누보드에 포함된 CKEditor와 네이버 스마트에디터로 변경하는 방법 보러가기>

위 화면은 "연구/개발"업무로 지정된 제품과 제품에 대한 개발 단위업무를 선택했을 때의 일정 등록/수정 화면이다. 일정을 신규 등록할 때는 "업무분류"-"단위업무" 목록을 보고 선택하여 지정하도록 되어 있으며 일정유형에는 "연구/개발"업무의 일정유형으로 등록된 일정유형목록이 드롭다운리스트 형태로 보여진다.

위 화면은 "공통"업무 및 "컨설팅" 업무로 지정된 단위업무를 선택했을 때의 일정 등록/수정 화면이다.

위 화면은 "고객사"로 등록된 업무분류의 단위업무를 선택했을 때 보여지는 일정의 등록/수정 화면이다.

이 시스템을 이용하면 프로젝트 또는 단위업무별로 사업이나 업무가 종료되었을 때 어느정도의 공수가 투입되었는지 누가 얼만큼의 업무를 수행하였는지, 프로젝트의 단계별로 투입된 인력 등을 산출할 수 있다. 당연히 산출된 공수에 투입인원별 공임을 곱하면 프로젝트 수행에 소요된 인건비를 계산할 수도 있다.

이 시스템을 얼마나 사용하게 될지는 모르지만... 뭔가 개발을 하고 완성(?)된 물건을 동작시켜보면 느껴지는 짜릿한 쾌감은 예나 지금이나 똑같은 것 같다. 

내 성격(?)상의 성향으로 인해 개발자가 아닌 엔지니어/컨설턴트의 길을 가고 있지만 취미 삼아 머리 속에 쌓여있던 로직을 코드로 구현하다 보면 내 몸에 개발자의 DNA도 있는 것은 아닐까 느껴지기도 한다.

보안 쪽 일을 한지도 벌써 10년이 되어간다.

보안 쪽 일을 하며 취득한 자격증은 오늘 이전까지는 2개였다.

하나는 CISA (정보시스템공인감사사) 자격증이고 나머지 하나는 아는 사람이 거의 없는 CA의 CACES(CA공인 eTrust 엔지니어)자격증이다. CACES는 사설 자격증으로서 CA사의 보안 솔루션 엔지니어가 취득하는 자격증이다.

그리고 오늘 새로운 자격증 하나를 추가했다. 바로 국가공인자격증인 "정보보안기사" 자격증이다. (상세한 정보는 여기로)

이 자격증은 2012년 까지 KISA에서 운영하던 민간자격증인 SIS 자격증을 국가공인으로 전환하여 2013년 1회 시험을 시작으로 매년 2회 시험이 실시되는 자격증이다. 오늘(2014년 12월)까지 4회의 시험이 실시되었다.

이 정보보안기사 자격증은 정보처리기사 자격 시험과는 달리 합격율이 매우 낮은 것이 특징(?)이다.

정보보안기사의 출제 범위는 매우 넓다. 정보보안이라는 것이 IT 전분야를 다루어야 하기 때문에 범위는 넓을 수 밖에 없다. 운영체제 개론에서부터 시스템보안, 네트워크 보안, 응용보안, 암호학, 정보보호개론, 위험관리 방법론, 정보보호관련 법규 등 매우 광범위한 분야를 공부해야하는 시험이다.  (정보보안기사 출제범위는 여기로)

1차 필기 시험은 4지선다형 객관식으로 치러진다. 적당한 교재를 하나 사서 공부하면 무난히 합격이 가능하다. 나도 필기시험은 한번에 Pass했으니까.. 하지만 실기 시험은 조금 다르다. 일부 합격자들은 교재로만 공부했다는 원론적인 이야기를 하지만 내 경험에 의하면 교재만 공부해서는 2차 실기시험 커트라인 60점을 넘기기는 쉽지 않다.

2차 실기시험 출제 형태

실기시험은 먼저 시험지 앞 부분에 단답형 10문제가 출제된다. 

각 3점으로서 총 30점이 배점이 되어 있다. 문제에 따라 다르지만 하나의 답변으로 끝나는 문제도 있고 3개의 답변을 써야 하는 문제도 있다. 출제 분야는 종잡을 수 없다. 4회 시험엔 C 소스를 보여주고 버퍼오버플로를 예방하기 위한 코드를 써넣는 단답형 문제도 출제되었다. 모든 출제 범위에서 다양하게 10문제가 선택되어 출제된다.

그리고 단답형에서는 최신 보안트렌드에 대한 문제도 출제되곤 한다. 2014년을 뜨겁게 달궜던 하트블리드 취약점에 대한 문제가 3회 시험에서 출제되기도 했다.

10문제의 단답형 다음에는 3문제의 서술형 문제가 출제된다.

각 문제는 14점 배점이며 단답식 처럼 하나나 두개의 단어로 답변할 수 없는 문제가 출제된다. 적어도 3~5줄 이상 서술해야하는 문제가 출제된다. 또한 여러개의 답을 요구하기도 한다. 예를 들면 이번 4회의 시험에선 Layer 2와 Layer 3의 VPN 프로토콜을 서술하고 Layer 3의 VPN 프로콜에서 전송모드와 터널모드에 대해 서술해야 하는 문제가 출제되기도 했다. 

그리고 1회와 2회 때는 ARP 스푸핑과 같은 ARP 프로토콜의 취약성 공격에 대한 서술형 문제가 연속으로 출제되기도 했다. ARP 취약성에 무엇이 있는지와 ARP 취약점 공격 기법 그리고 방어기법 등을 모두 이해해야만 서술할 수 있는 문제들이었다.

이 서술형 3문제도 매우 광범위한 부분에서 출제되는 경향이 있다.

마지막으로는 실무형 문제 3문제(각각 14점)가 출제되며 그 중 2문제를 풀면 된다. 

두 문제의 실무형 문제 중 하나는 주로 해킹 공격에 대한 로그를 분석하는 문제 혹은 네트워크 장비의 커맨드 문제 또는 취약성 분석 도구의 사용법에 대한 문제가 출제되었다. 최근에는 2회 연속으로 SQL 인젝션에 대한 웹서버의 공격 로그를 보여주고 공격의 종류와 어떤 취약점을 공격하는 것인지, 공격에 성공했을 때 해커가 획득할 수 있는 것에 대해 서술해야 하는 문제가 출제되었으며 HTTP 프로토콜의 취약점 공격 관련 실무형 문제도 출제되었다. 실무형 문제 중 나머지 한 문제는 보안관련 법규 혹은 위험관리에 대한 문제가 출제되었다. 4회 시험에는 위험관리 기법 중 정량적 위험분석의 ALE를 구하는 문제가 출제되기도 했다. 자산가치와 노출계수를 계산하고 단일 예상손실과 연간예상손실을 실제로 계산하는 문제가 출제되었다.

이렇듯...

3점 배점의 단답형 10문제 = 30점.

14점 배점의 서술형 3문제 = 42점

14점 배점의 실무형 3문제 중 2문제 = 28점

으로 구성된 정보보안기사 실기시험에서는 사실 모두 70점이 배점된 서술형/실무형 문제 5문제가 당락을 좌우한다고 해도 과언이 아니다.

기본적으로 단답형에서 최대한 많은 점수를 확보한 뒤 (최소 20~25점)...

서술형과 실무형에서 40점 이상을 확보해야만 합격선에 다가설 수 있다

2차 실기시험의 채점 기준

사실 서술형과 실무형 6문제의 채점기준은 나도 잘 모르겠다. 정보보안기사 실기 시험의 채점기준은 일절 공개하지 않고 있다. 그렇기 때문에 채점 기준을 매시험 달리하여 합격선을 어느 정도 조정하고 있는 것으로 예상된다. 문제의 난이도가 매 시험 다르기 때문에 합격율을 조정하기 위해서는 채점 기준이 매시험 달라질 수 밖에 없을 것으로 보인다.

그리고 경험상...부분점수는 분명히 있는 것으로 보인다. 하지만 출제 기준에 의해 가장 요구되는 핵심적인 사항을 답변 했느냐 하지 못했느냐에 따라 부분점수의 부여 양상도 달라지는 것으로 보인다. 

합격 조회

1회 필기에 합격하고 오랜 시간이 지나 겨우 실기 시험에 합격하였다. 오랜 시간 머리속을 지배하던 시험..시험..시험..의 강박에서 벗어나는 것이 시험의 합격 기쁨보다 더 큰 듯 하다.

SeOS라는 시큐어OS를 접한지 10년이 넘은 지금까지 난 서버보안 관련 일을 하고 있다. 그 전에 C언어와 웹개발언어를 공부해두었고 Ingres라는 관계형데이터베이스 시스템 , 서버 및 네트워크 모니터링/관리 소프트웨어인 CA Unicenter, BMC PATROL, 백업SW인 ARCServe, 배치작업관리 솔루션인 AutoSys 그외에도 다양한 시스템소프트웨를 접한 덕분에 시큐어OS를 통한 보안강화 정책 수립에 큰 어려움이 없었다.  시큐어OS의 특성상 운영체제와 운영체제 위에서 구동되는 다양한 소프트웨어..그리고 서버에 로그인하는 관리자와 개발자들의 행동패턴을 알고 있는 것이 보안정책의 수립에 큰 도움이 된 것이다.

시큐어OS는 앞에서도 언급했 듯 운영체제와 시스템소프트웨어 그리고 웹서버 등 애플리케이션의 구조와 동작 방식을 이해하지 못하면 제대로 정책을 적용할 수 없고 누군가 대신 정책을 적용해 주었다 하더라도 위반 감사 로그 발생 시 전혀 추적을 할 수 없다.  때문에 시큐어OS 교육을 받기 위해서는 운영체제에 대한 기본적인(?) 이해가 필요하다.

우리나라의 군에서는 여러 서버보안SW(시큐어OS)가 운용 중이다. 서버의 보안을 위해서는 필수적인 소프트웨어이기 때문이다. 군의 특성 상 더욱 강력한 보안정책 적용이 필요하다. 그래서 군에 도입된 서버보안SW의 활용을 위해 교육이 개설되었고 내가 첫 "서버보안 강화를 위한 시큐어OS 활용"이라는 과목의 강의를 하게 되었다.

첫 교육인 만큼 교육의 내용은 평이한 수준으로 잡았다. 교육 대상자의 수준을 알지 못했기 때문에 유닉스/리눅스 운영체제가 갖고 있는 기본적인 취약성(취약점 아님)에 대한 악용 혹은 공격에 대해 방어할 수 있는 Baseline Security Policy에 대해 설명하고 실습을 하는 내용으로 8시간 동안 진행하였다.

서버보안SW는 일반적인 공격탐지 및 방어솔루션들 처럼 패킷을 분해하여 패킷헤더나 메시지의 내용을 시그니처라 부르는 공격패턴과 비교하여 통제하는 방식이 아닌 서버에 접속한 사용자 및 세션의 행위를 정책(Policy)을 적용하여 통제하는 방식으로 동작한다.

그렇기 때문에 정책(policy)는 특정 취약점에 종속되지 않고 현재까지 알려지지 않은 새로운 취약점으로 인한 공격도 방어할 수 있는 특징이 있다.

지금까지 수많은 기관과 기업이 서버보안SW를 도입하였지만 활용도 측면에서는 아직도 개선의 여지가 많다. 언젠가는 서버 내의 자원을 보호하기 위한 운영체제 수준에서의 강력한 보안 정책을 원하는 기관과 기업이 늘어날 것이라 예상된다. 그때는 서버보안의 강화를 위한 보안 컨설팅을 제대로 해보지 있을 수 있지 않을까 생각된다.

SecureOS (서버보안SW)는 서버에 대한 접근과 서버에 접속한 사용자들의 행위를 감시하고 명령어의 실행과 파일의 수정 및 삭제를 통제할 수 있는 매우 강력하고 다양한 기능을 제공하는 보안 솔루션이다. 하지만 2014년인 지금까지도 그 활용 수준은 미미한 것이 현실이다.

내가 처음 SecureOS를 접한 것은 아마도 IMF 구제금융사태가 끝나갈 무렵인 2000년 전후였던 것으로 기억된다. 당시 국내에서 쓸만한 유일한 서버보안SW(== SecureOS)였던 미국 CA사의 eTrust Access Control이 처음 접한 서버보안SW다. 

당시 내가 일하던 '포시에스"는 CA의 리셀러였고 Ingres RDBMS와 Unicenter, BMC의 Patrol 등 외산 SW를 국내에 공급하고 기술지원을 하는 회사였다. CA가 무척이나 다양한 서버용 SW를 개발하고 판매하는 글로벌 SW 기업인 덕분에 그 외에도 많은 서버용 SW를 접할 수 있었고 시스템 SW에 대한 폭넓은 시야와 경험을 쌓는데 매우 큰 도움이 되었다. 그와중에 접하게 된 것이 바로 지금도 내가 주 업무로 담당하고 있는 서버보안분야의 핵심적인 SW인 SecureOS 였다.

이 서버보안SW는 이스라엘의 MEMCO라는 벤처에서 만든 SeOS(많은 사람들이 당시 "쎄~오에스"라고 불렀음)를 플라티늄이라는 회사를 거쳐 CA가 인수하여 eTrust Acces Control 이라는 이름으로 개명하여 공급하고 있었다.

5일 짜리 기초교육을 받고 곧바로 구미에 내려가 프로젝트를 수행해야 했지만 제품의 컨셉 정도만 이해하고 있던 당시에는 서버의 계정관리 정책이나 파일에 대한 접근 통제 정책 수립에 대한 컨설팅은 꿈도 꾸지 못했었다.

당시 처음 접했던 서버보안SW가 인연이 되어 지금도 국산 서버보안SW인 RedCastle SecureOS와 관련된 일을 하고 있다. 

이미 개발된지 10년이 넘은 RedCastle은 단언컨대 최고의 서버보안SW다. RedCastle은 SecureOS의 핵심인 참조모니터가 구현된 보안커널의 아키텍쳐나 보안커널에서의 파일접근통제 메커니즘과 파일접근통제를 위한 정책의 수립을 위한 사용자 지원 유저인터페이스등 서버보안SW의 가장 중요한 부분에서 최고의 성능과 안정성을 보장한다.

2003년 당시 RedCastle이 개발된지 얼마 안되었을 즈음에는 서버에 설치하거나 설치한 뒤 종종 서버에 장애를 유발하는 문제도 있었지만 몇년 안되어 안정성이 충분히 확보되었고 성능도 외산보다 더 뛰어날 정도로 발전을 거듭하였다. 

일례로 외산을 사용하던 고객사에서 서버의 운영체제와 DB를 업그레이드 한 뒤 외산서버보안SW를 설치하면 서버가 서비스를 할 수 없을 만큼 성능이 저하되어 RedCastle을 이용해 문제를 해결하고 임시로 임대하여 사용한 사례가 있을 정도 였다. (지금은 해당 고객사가 전사적으로 RedCastle을 도입하여 사용 중임)

얼마 전 RedCastle에 대한 소개자료를 새로 만들었다. 매번 프로젝트 수행에 필요한 산출물 위주의 문서작업이나 교육교재 (Basic Course 및 Advanced Course) 등 기술자료만 만들다 영업에 사용될 기초적인 소개자료를 만들려하니 무척이나 까다로운 작업이었다.

그런데... 반응이 신통치 않았다. 우리나라 사람들은 이런 스타일의 문서를 "싫어"한다는 것을 알기 때문일 것이다. 나도안다. 왜 나라고 우리나라 스타일을 모르겠는가? 한눈에 직관적으로 알 수 있는 그림과 표가 가득한 겉만 화려한 그런 문서말이다. 하지만 그렇게 그림과 표로 많은 내용이 함축된 문서는 보는 이들이 곡해할 수 있는 요소가 너무 많은 것이 문제다. 전혀 다른 엉뚱한 의미로 이해하는 "사고"가 발생할 가능성이 너무 높다. 그래서 누군가가 "부연 설명"을 해줘야 한다.

그래서 난 부연설명의 필요성을 최소화할 수 있는 소개자료를 만들어 보고 싶었다. 차분히 문서하나를 다 보면 충분히 이해할 수 있는 그런 문서를 말이다. 그래서 만든 문서가 바로 이 RedCastle 소개자료다.

서버보안SW(SecureOS)가 무엇인지 궁금한 사람들에게 도움이 되었으면 한다.

RedCastle 소개자료 다운로드 받기

RedCastle_소개자료_20140414(GD).pdf

새로운 포스트 (업그레이드 되었습니다.): 프로젝트 및 일정관리 시스템 리뉴얼 (2015.01.11)

아찔한 추억

내 첫 직장은 외산 DBMS와 서버 및 네트워크 통합 관리 솔루션 그리고 서버보안SW를 판매하고 기술지원하는 일을 주업으로 하는 곳이었다. 처음 입사 후 2년은 멋도 모르고 개발일을 했었다. 당시엔 아무것도 모르는 초짜였기에 뭔가를 만든다는 재미에 빠져 개발을 했지만 지금 생각하면 혼자 공부한게 다인 초보개발자가 아무리 작은 프로젝트지만 혼자 진행했던게 얼마나 무모한 것이었는지 당시를 떠올리면 식은땀이 난다.. -.-

그 후엔 개발 프로젝트가 아닌 서버에 SW를 설치하고 구현(implementation)을 위주로 하는 일을 했다. 수없이 많은 고객사에 설치된 RDBMS에 대한 기술지원과 DB를 이용하는 애플리케이션에 대한 개발지원(EmbededSQL C, 혹은 DBMS의 자체 4GL)과 서버 및 네트워크 장비에 대한 성능/장애 모니터링, 이벤트 모니터링을 수행하는 시스템 SW를 설치하고 구현하는 프로젝트를 진행하고 관리했다.

어려움

담당하는 고객사가 늘어갈 수록 동시에 진행해야 하는 사업의 수는 늘어가고 과거 수행한 사업에 대한 유지보수 업무도 진행해야 하기에 문서나 엑셀...그리고 단순한 게시판 형태의 정보관리로는 한계가 느껴졌다. 다른 여러 프로젝트 관리를 위한 솔루션들이 있었지만 수행업무에 대한 적합성이나 편의성, 복잡성 등을 따져보면 썩~맘에 드는 솔루션을 찾긴 어려웠다.

대부분 개발프로젝트나 팀단위수행 프로젝트에 적합하고 여러 엔지니어가 공동 혹은 개별적으로 다수의 프로젝트와 유지보수 사업의 지원이력 관리 및 일정관리를 수행하기에는 적합하지 않은 경우가 많았다.

개발

그래서 직접 만들기로 했고 틈틈히 일을하는 와중에 코딩을 해봤다.

리눅스 서버에 아파치웹서버와 PHP 그리고 MySQL을 올려 간단한 DB설계를 하고 코딩을 시작했다. 실력도 딸리고~ 시간도 부족하고 해서 팀과 팀원 관리는 제로보드의 것을 그대로 연동했다. 게시판이 필요할 경우 그대로 쓸 수 있으니 일석이조였다.

고객사관리

고객사는 고객사의 업종(나중에 고객사의 분류를 위해)과 고객사명 그리고 고객사의 유니크한 ID로 구성된다.

이름으로 검색하기와 추가하기가 가능하다. 

고객사 이름을 클릭하면 해당 고객사에서 수주한 프로젝트(사업) 관리 페이지로 연결된다. 소프트웨어나 하드웨어의 경우 하나의 고객사에서 여러 차례에 걸쳐 구매를 하기 때문에 각각의 프로젝트를 분리하여 관리해야 한다.

프로젝트 관리

솔루션벤더의 프로젝트는 개발 프로젝트와는 성격이 많이 다르다. 한명의 엔지니어가 수십개의 프로젝트를 진행할 수 있기 때문이다. 당연히 상주지원은 하지 않는게 원칙이어야 한다. 

프로젝트는 고객사, 프로젝트명, 담당 엔지니어, 프로젝트의 진행상태로 검색이 가능하다.  또한 프리세일즈 단계의 프로젝트는 수주 가능성에 따라 여러 1순위, 2순위, 3순위 등으로 구분하여 관리하여야 한다.

또한 프로젝트가 종료되면 유지보수사업을 신규로 등록하여 수행중인 프로젝트와 유지보수사업을 분리하여 관리하고 일정도 각기 등록할 수 있다.

신규 프로젝트가 영업단계에 돌입하거나 수주하여 사업을 수행하게 되면 고객사에 프로젝트를 추가한다. 담당 영업 및 엔지니어, 수주 금액, 프로젝트 상태 등의 정보를 입력하고 킥오프 일자 및 사업 종료시 완료(검수)일자를 입력한다. 프로젝트에 대한 상세 내용은 하단에 입력하여 추후 조회할 수 있도록 한다.

프리세일즈 단계의 사업은 영업팀에게만 공개되며 [진행상태]를 "사업진행"으로 변경하고 엔지니어를 지정하면 담당엔지니어에게 프로젝트가 보이게 되고 지원일정을 등록할 수 있다.

이 프로젝트는 고객사 뿐만 아니라 사내에서 수행하는 여러 업무를 분류하여 등록하면 내부 업무에 대한 관리도 가능하다. 현재 이 시스템은 프로토타입 수준으로 개발되어 있기에 보다 보강하여 개발한다면 상업용으로도 써먹을 수 있지 않을까 싶다.

일정관리

프로젝트가 등록되면 영업담당자 및 엔지니어는 프로젝트를 기반으로 일정을 등록한다. 등록된 일정은 아래와 같이 캘린더에 표시되는데 현재는 [고객사/엔지니어] 형태로 캘린더에 표시되어 엔지니어나 담당영업사원이 일자별로 어느 고객사에 기술지원 혹은 세일즈를 진행하는지 한눈에 알 수 있도록 하고 있다.

화면 상단에 팀을 구분하여 볼 수 있도록 하고 있다. 내가 속한 팀의 일정이나 개인의 일정 혹은 타 팀의 일정을 볼 수 있다.

일자를 클릭하거나 일정을 클릭하면 아래와 같은 창을 띄워 신규 일정 등록 혹은 수정을 할 수 있다.

[고객사명]의 찾기 버튼을 눌러 일정을 등록할 프로젝트를 선택한 뒤 일정의 [제목]과 오전 [직출여부], 업무의 유형 등을 선택하여 저장하면 캘린더에 표시되도록 되어 있다. 업무를 수행한 뒤 일정을 수정하여 업무(작업)의 [시작시간]과 [종료시간]을 선택하면 [소요시간]이 자동으로 계산되어 저장되며 [일정유형]을 "완료"로 변경하면 캘린더에 파란색으로 표시되어 처리완료한 일정임을 알 수 있다.

위의 화면은 고객사명을 "병원"으로 검색하여 프로젝트를 조회한 화면이다.

입력된 데이터는 추후 통계에 사용될 수 있다.

캘린더에서는 아래와 같이 일정에 마우스를 올릴 경우 일정의 내용을 볼 수 있도록 처리했다. 일일히 일정을 클릭해 창을 열지 않아도 되도록....

추후 특정 프로젝트를 선택하여 지원 내역(프로젝트 수행내역)과 총 지원 시간을 합계내어 볼 수 있도록 했다. 적자를 보는 프로젝트가 아닌지...투입된 인건비가 얼마인지를 계산할 수 있다.

마이페이지

마이페이지에는 아래 처럼 "예정"으로 등록된 일정을 보여주고 담당자가 본인으로 되어 있는 프로젝트 및 유지보수사업의 목록이 보여진다. 

마무리

프로토타입 수준의 이 시스템은 30여명의 엔지니어들이 사용하고 있으며 꽤나 유용하게 쓰이고 있다. 보완하고 싶은 것은 많지만 귀차니즘으로 인해 엄두를 못내고 있는 실정이다. JSP 버전으로 바꾸고도 싶고 영업정보를 추가하여 영업관리 기능을 넣고 싶기도 하고 연구소의 제품개발일정 관리 기능도 추가하고 싶기도 하다.

때론 이걸 제품화해서 팀오피스 처럼 ASP 사업을 해보고 싶기도 하다. 틈새시장은 충분할테니까... 머리속에 축적된 세일즈, 프로젝트, 유지보수 및 기술지원 업무 관리 플로우를 실제로 구현하고 싶지만 나의 코딩 속도는 너무 느리고 코드 설계는 이젠 버겁다. T.T

하루가 48시간만 되면 24시간은 일상생활과 회사에... 나머지 24시간은 여기에 투자 해볼텐데... ^^

netsec-kr 2014에서 세션하나를 맡아 주제발표를 하게 되었다. SecureOS (RedCastle)을 활용한 서버보안 강화 분야의 일을 주로 하다보니 보다 폭 넓은 주제를 맡은 것이 꽤나 부담이 되기도 했다. 하지만 서버로의 접근통제와 접속한 이후의 서비스 및 사용자 세션의 행위 통제에서 벗어나 내부 및 외부 인력의 서버에 대한 접근 통제란 주제에 대해 보다 폭넓게 고민해 볼 수 있는 계기가 되기도 했다.

NETSEC-KR 2014는 4월24일(목)~25일(금) 양일간 코엑스 3층에서 진행되었고 "창조경제를 위한 정보보안"이라는 주제로 열렸다. (조금 뜬금없기는 하지만.... ^^)

첫날 오후 금융보안 트랙의 세번째 세션이다.

그리고 몇일 뒤...

메일링 신청해놓았던 보안뉴스에서 날아온 메일에 내가 발표했던 세션에 대해 기사가 스크랩돼서 날아왔다. 그래서 보안뉴스 사이트로 가보니....

음... 정말..핵심만 잘 요약한 기사였다..

기자분의 요약이 내가 횡설수설 발표한 것보다 낫다는 생각이... -.-

그리고 요약을 잘 해주어서 인지...많이 본 기사 부문에서 14위(?)엔가 랭크되어 있었는데.. 몇일 뒤 5위까지 올라가 있었다.

SecureOS 에 대한 주제라면 더 잘할 수 있었겠다는 아쉬움..?? 도 있었지만 그래도 재미있는 경험이었다.