정보보안기사 11회 실기 출제 예상
10회 실기 패인 요소를 반면교사 삼아 예상해본 문제 리스트
이번 세션을 통해 보안기사 11회 실기로 출제될만한 개념을 예상해보았다. 총 세 개 중에 하나는 예상 문제가 아니라 이런 식의 개념으로 출제될 거라는 정도로 받아들이고 세부적인 사항은 이미 바탕이 깔린 지식으로 추론해낼 수 있어야 한다(시험 4일 남기고 기본 개념은 이미 여러 번 정리되어 있어야 이 시험의 합격 가능성이 그나마 있다). 이 시험은 어느 한 분야에 정통한 보안 전문가이든 경력이 십 수년이 넘어도 어려운 거 매한가지이다. 왜냐하면 제너럴한 이론과 디테일과 깊이 있는 스페셜의 실무지식을 동시에 요구하는 보기 드문 형태의 시험 유형이기 때문이다.
5월 22일 토요일에 11회 차 시험이 있다. 보안 기사는 또한 특이하게 보통 국가자격증과 달리 토요일에 치른다. 주최기관도 한국인터넷진흥원(KISA)이라서 기출문제에 대한 공개도 안 한다. 문제 수준은 사이트에 공개하는 매회 합격률을 보면 짐작할 수 있다.
문제 수는 단답형 10문제, 서술형 3문제, 실무 작업형 3문제(3문제 중 택 2문제)로 16문제밖에 안되어서 동일한 범위의 개념이 일 년에 두 번 치르는 시험에서 연속으로 출제되지 않을 거라고 예단했었다. 그러나 10회 실기 시험 경험으로 바로 전 회차 때 출제된 개념이 연속으로도 출제될 수도 있다는 것을 알았다. 9회 때 법률 파트가 다수 출제되어서 10회 때 정보보안 법규 문제가 드물게 출제되지도 않았을뿐더러, 같은 공격이라도 다른 질문으로 연속해서 출제되었다. 그러니까 출제 경향이라는 것을 예상하면 족집게 공략의 폐단으로 오히려 시험을 망칠 수도 있으니, 전범위의 주요 개념은 기본으로 먼저 확실히 그리고 완전히 깔고 들어가야 한다.
그러면 보안 전문가로 살다가 생을 마감하고 싶은 해커 지망도가 몇 가지 문제의 개념을 예상해보겠다.
첫 번째, 침해사고 분석 및 대응 파트 실무형 예상 문제의 개념으로 'Snort rule'과 애플리케이션 공격 중 'SQL Injection', 'XSS' 등을 탐지하기 위한 룰 바디 셋을 알고 있는가? 두 가지의 웹 서버단에서의 공격을 IDS 도구 중인 하나인 스노트 룰로 탐지하는 Set은 아래와 같다.
1) SQL injection 공격 방지를 위한 Set은 PCRE(정규표현식을 이용하면 유용하다.) -> 여태껏 미출제된 정규표현식과 여러 번 출제된 애플리케이션 공격들을 조합한 개념
alert tcp $EXTERNAL_NET any -> $HOME_NET any(msg: "pcre_sql_injection"; content: "+ or+ "; content "%27%3D%27"; nocase; distance: 0; within: 20; pcre: "/^(GET|POST)/"; sid: 1000040;)
스노트 룰은 "Sniffer and More"라는 이름의 유래처럼 패킷 스니퍼와 패킷 로거, 그리고 네트워크 IDS/IPS 기능이 주요한 기능이다. local.rules.txt 파일에 내부 정책을 세팅하면 된다. 위의 명령어 별거 없다. 무슨 뜻인지만 알면 포함되어 있는 정규표현식까지 한 번에 익혀서 SQL injection 애플리케이션 공격도 탐지할 수 있다는 것을 알면 된다.
뜻? 찾아봐라~.
2) XSS 공격 방지를 위한 Set은 간단하다.
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg: "Reflective_XSS_attack_detect"; content: "<script>"; http_uri; nocase; sid: 1000062;)
경고 메시지 발생해라(alert 액션으로 탐지하고 패킷을 로그에 남김)! 만약 tcp 프로토콜(udp, icmp, ip 네 가지 중에 하나다.)에 대해서 출발지가 외부 네트워크 단의 모든 포트이고 목적지가 내부 네트워크단의 모든 포토인 HTTP(http_uri 옵션으로 인해) 패킷 URI 쿼리 스트링 부분에 '<script>' 포함한 경우에 한해서만.
Snort는 HTTP 패킷에 대해 패킷 전체가 아닌 특정 필드에서 패턴을 검사하는 기능을 지원함. 이는 오탐(false positive)을 줄이고 성능을 향상해주는 효과가 있다고 한다(알기사 실기 '이론편', 정일영).
http_method -> HTTP 패킷의 메써드 부분만 검사 (eg. GET /index.php HTTP/1.1)
http_uri -> HTTP 패킷의 uri 부분만 검사 (eg. GET /index.php HTTP/1.1)
http_header -> HTTP Header 부분을 검사, 요청(request)/응답(response) 헤더에 모두 사용
http_cookie -> HTTP cookie* 부분을 검사
http_client_body -> HTTP 클라이언트 요청의 body 부분을 검사(즉 POST 요청에 대한 검사)
http_stat_code -> HTTP 응답의 status_code 부분을 검사 (eg. HTTP/1.1 200 OK)
http_stat_msg -> HTTP 응답의 status_message 부분을 검사 (eg. HTTP/1.1 200 OK)
위는 local.rules.txt 파일의 default 설정이고 아래의 예와 같이 하나씩 주석으로 무슨 탐지 세팅인지 설명하고 rule을 설정함.
SQL injection과 XSS 공격 탐지 rule 세팅SQL 인젝션 공격 탐지 룰의 바디(Body: 괄호 안 msg부터 시작되는) 부분 설정은 XSS 탐지와는 다르게 길다. 페이로드(데이터)와 범위 관련 옵션을 추가하였는데, content 옵션의 text는 "%27%3D%27"이라는 패턴을 탐지하라는 뜻이다. 보통 사이트 로그인 창의 사용자 ID 입력란의 폼에서 입력되는 값은 GET method로 전달된다. 이때 전달되는 URL(Uniform Resource Locator; HTTP 프로토콜 개념 중에 하나임.) 값은 평문 그대로 전달하지 않고 한번 인코딩(16진수 HEX값)해서 보내기 때문에 '='(양쪽 어포스트로피가 %27)이 %27%3D%27이라는 HEX 문자열로 변경되어 전달된다.
즉 입력 폼에 '='이라는 문자를 쳐서 서버에 보내진 GET 메써드의 URL 값은 '%27%3D%27'이 포함되어 있다. 그리고 pcre 옵션에 /^(GET|POST)라는 정규표현식으로 인해 GET 또는('|'버티컬 바는 논리 연산자 ‘or’와 동일하다) POST로 시작('^'정규표현식)하는 문자열을 탐지하라고 설정하였다. Content 패턴에 매칭 되는 HTTP 요청 메시지 중에 GET(입력 시) 또는 POST 방식(수정 시)의 요청을 탐지하라는 설정이다. 여기서 역슬래쉬(/)는 뒤따라나오는 문자열 그 자체를 지칭한다고 하여 ‘이스케이프’ 문자열이라고 한다.
생략할 뻔한 처음의 content 매칭 패턴에 +or+ 가 있다. 유의해서 봐야 할 점이 타이핑할 때 "+(space) or+(space)"로 구성된다는 것을 알아야 SQL 인젝션 공격 시 쿼리문의 변조가 가능하다는 것도 알 것이다. content 패턴을 합쳐서 +(space)or+(space) 문자열과 %27%3d%27('=') 문자열을 탐지하므로 폼(form) 기반의 SQL 인젝션 형태인 ' or '1'='1' # 패턴 같은 예를 탐지할 수 있다. 이 부분은 조건절 내부의 전체 논리식으로 구성하면 어떤 레코드의 "빈칸과 1과 1은 같다(true)”라는 항상 참인 값을 OR 논리 연산자로 결과를 내면 모든 레코드를 만족한다는 값(ture)이 된다. 결국에는 빈칸 앞에 어떤 쿼리가 오느냐에 따라서 결과문에 DB 테이블의 정보가 출력된다. 변조된 입력값의 논리로 인해 웹서버에서 다음과 같은 SQL SELECT문이 수행될 가능성이 크다.
SELECT password FROM user WHERE usename='' or '1'='1'#'
조건절 WHERE이 항상 참이므로 사용자(user) 테이블의 모든 레코드가 쿼리 된다. 즉, 모든 사용자의 패스워드 정보를 확인할 수 있다. 참고로 논리식 뒤의 # 이후는 주석 처리된다. MySQL에서 주석처리이며, Oracle과 MS-SQL은 -- 로 주석 처리된다.
두 번째, 10회 실기에서는 정보보안 법규 문제 출제 예상을 짚지 않고 법률 테두리 안에서 반드시 알고 있어야 할 부분만 외우고 시험에 임했는데, 다른 법률 조항(정보보안에는 현재의 행정안전부에서 주관하는 '개인정보보호법'과 방송통신위원회에서 주관하는 '정보통신망법'과 '정보통신 기반보호법'이 대체적으로 출제된다)의 내용이 혼용되어 예상 점수보다 아주 밑도는 점수를 받는 패인의 요소가 되었다. 그런데 실기 10회에서 출제된 법률문제 중 하나로 필기 8회부터 10회까지 연달아 출제된 '정보통신 기반보호법'에서의 문제가 그대로 있었다.
그래서 9회부터 10회 필기에서 출제한 법률 파트를 조사해봤는데(11회는 본인의 능력 범위에서 구할 수 있는 경로가 없어서 참조를 못했다), '개인정보보호법' 제33조에 해당하는 "개인정보 영향평가 시 고려사항"이 9회, 10회 필기에서 연달아 출제되었다. 11회 실기에 출제된다는 보장은 없다. 하지만 확률적으로 있다는 것이니 외워둬야 할 법률조항이다.
개인정보 영향 평가 시 고려사항 다섯 가지 항목 (NODIS).
1) 처리하는 개인정보의 수 -> N(umber of info.)
2) 개인정보의 제삼자 제공 여부 -> O(ffer to 3rd partition)
3) 정보 주체의 권리를 해할 가능성 및 그 위험 정도 -> D(anger possibilities)
4) 민감정보 또는 고유 식별정보의 처리 여부 -> I(dentification info.)
5) 개인 정보 보유 기간 -> S(tored period)
세 번째, 하나 더 예상하는 법규로 망법 27조 3 (개인정보 유출 등의 통지, 신고) 항목이다.
정보통신 제공자(전기통신사업자/정보 제공 또는 정보 제공 매개자)는 다음의 각 호를 해당 이용자에게 알리고 방송통신위원회 또는 인터넷진흥원에 신고하여야 한다.
개인정보 유출 등의 통지, 신고 (EP A1 A2 H/P)
1) 유출 등이 된 개인정보 항목 -> E(ntries)
2) 유출 등이 발생한 시점 -> P(oint)
3) 이용자가 취할 수 있는 조치 -> A(ction 1)
4) 정보통신 서비스 제공자 등의 대응 조치 -> A(ction 2)
5) 이용자가 상담 등을 할 수 있는 부서 및 연락처 -> H/P
