22년 9월 SW 보안약점 진단원 시험 후기

22년 9월 17일(토), 서울역 공간모아 6층에서 SW 보안약점 진단원 시험을 치렀다.

 

SW 보안약점 진단원 시험은 KISA 주관 교육인 SW 보안약점 진단원 양성과정 교육을 수료한 사람을 대상으로

수료 후 1년 내 횟수는 3회까지 진단원 시험 응시 기회가 주어진다.

    (수료 후 1년이면 다음 해 말까지는 응시가능기간으로 쳐준다.)

 

* 진단원 기본요건 :  6년 이상 소프트웨어 개발분야 업무를 수행한 자                                 또는 3년 이상 소프트웨어 보안약점 또는 보안 취약점 진단, 분석 업무를 수행한자 * 진단원 시험 자격기준 : 기본요건을 만족하고 기본교육을 이수한 자    (기본교육은 SW보안약점 진단원 양성과정(40시간) * 자격유지기준 : 자격 취득 후 다음해(1~12월)까지 유지되며 이후에는 매년 보수교육 수료해야 유지됨    (보수교육은 연 1회 8시간 진행되며, 보수교육 미수료 시 다음해부터 자격 정지, 수료 시 자격유지로 변경됨)

 

↓↓↓  교육 접수 및 시험 접수는 아래 홈페이지에서 가능하다.

http://academy.kisa.or.kr 

https://academy.kisa.or.kr/main.kisa

 

공부가 제대로 되어 있지 않은 상태에서 시험을 본거라 가벼운 마음으로 시험 응시...!

12시부터 입실이 가능하며, 12시 50분에는 시험지가 시험장으로 들어오기 때문에 공식적으로는 입실이 불가능하다.

(근데 감독관 재량인지 12시 59분에 입실하신 분도 있었다...ㅎㅎ;;;;)

 

물은 시험장 안에 정수기가 있어서 따로 들고가지 않아도 되었다.

준비물은 신분증과 검정색 펜(연필사용금지) 이다. (신분증 꼭꼭 가지고 가야한다.)

 

시험시간은

13:00~14:00 이론시험(60분) : 진위형(OX 문제), 객관식, 주관식(단답형) 및 간단한 서술형

14:00~14:10 휴식시간

14:10~14:20 시험지 배부 및 준비

14:20~16:00 실습시험(100분)

 

점수는 "이론시험(40%) + 실습시험(60%)" 100점 만점에 합격기준은 종합점수 70점 이상이어야 합격이다.

이론시험은 30문항에

      - 진위형(OX) 6문항 X 2점씩 = 12점

      - 객관식(4~5개 지문, 모두고르시오도 있음) 6문항 X 2점씩 = 12점

      - 단답형(SW개발보안제도 및 보안약점 관련 답안) 12문항 X 3점씩 = 36점

      - 서술형(보안약점 항목 및 보안대책 서술) 6문항(6점 4문항, 8점 2문항) = 40점

 

실습시험은 총 10문항에

      - 보안약점 정,오탐 분석 보고서 및 작성(구현단계 6문항, 설계단계 4문항)

         5문항 x 8점 = 40점

         3문항 x 10점 = 30점

         2문항 x 15점 = 30점

 

실습시험의 비중이 크기 때문에 실습시험 답안을 잘 작성해야 한다.

 

소프트웨어 보안약점 명은 굳이 암기하지 않아도 된다.

설계단계 보안약점명, 개발단계 보안약점명이 표로 앞뒤 한장짜리 종이로 배부가 되기 때문이다.

 

예) 설계단계 보안약점명   (순서대로가 아닌 섞어서 준다)

XML 조회 및 결과 검증	세션통제
비밀번호 관리	웹 서비스 요청 및 결과 검증
...	...

예) 구현단계 보안약점명 (순서대로가 아닌 섞어서 준다)

오류 상황 대응 부재	정수형 오버플로
신뢰할 수 없는 데이터의 역직렬화	부적절한 인가
...	...

 

그러나, 큰 구분(예 : 보안기능-암호화되지 않은 중요정보 에서 "보안기능") 은 명시되어 있지 않고

약점만 나열되어 있기 때문에 보안약점이 어떤 큰 구분에 포함되는지는 암기가 필요하다.

왜냐하면 시험에는 예를 들어,

소스코드를 주고 여기서의 보안약점은 "보안기능"에서 어떤 취약점에 해당하는가? 라고 문제를 주기 때문에

보안기능에 해당하는 보안약점들은 알고 있어야 한다. (매칭)

 

[이론시험]

이론시험은 시간이 크게 부족하진 않다. 다만 문제지 종이에 서술형 답을 다 쓰고 답안지에 옮기려고 하면 시간이 좀 부족하지 않을까 싶다. 나는 답안지 종이에 처음부터 답을 다 적어서 냈다.

 

이론 시험 문제를 기억해서 다음 시험을 치를 때 참고하고 싶었지만, 서술형 시험을 치르고 나서 

거의 머릿속이 초기화 되서 기억나는 문제가 거의 없...다...ㅎㅎ 

이론시험이 끝나고 중간 쉬는시간에 아예 책을 보지 못하게 하기 때문에 기억나는 문제를 따로 메모하지도 않았다.

그냥... 다음 시험을 공부하기 위하여 공부 중점을 잡고자 머릿속에 기억나는 것만 끄적끄적해본다.

 

가. OX 문항 

     -  한 문제 외에는 기억이 잘 안 난다 ㅠㅠ

     * 생각나는 키워드 : 운영체제 명령어 삽입

 

   1) OX 문제 6문항은 주로 취약점에 대한 설명에 맞는지 OX

예) (22년) 운영체제 명령어 삽입은 프로세스에 검증되지 않은 외부 입력 값을 허용한 경우 악의적인 코드가 실행 가능한 보안약점이다. (X)    ---> 문제는 운영체제 명령어 삽입인데, 설명은 코드 삽입에 대한 설명이므로 틀린 구문임

 

  (공부대책) 취약점과 설명 매칭!   취약점 명에 다른 취약점 설명이 들어가 있는 경우 X임  

              따라서 취약점 명-설명 매칭을 시키고, 다른 취약점 설명인지 구분할 줄 알아야 함(헷갈리는 설명은 구분해두자)

 

   2) 취약점에 대한 보안대책으로 맞는지 OX 

  ~ 취약점에 대하여 ~대책을 적용하면 안전하다.(OX)    ---> 문제가 잘 기억나지 않지만 요런 느낌인가 싶다.

 

예) 상태정보나 인증, 인가, 권한에 관련된 중요정보는 서버에서 관리하면 안전하다.(?)

      

     중요 상태정보나 인증, 권한결정에 사용되는 정보는 쿠키로 전송되지 않아야 하며, 불가피하게 전송하는 경우에는 암호화하여 전송한다. 

 

   (공부대책) 취약점에 따른 보안대책을 꼼꼼하게 공부해서, OX 함정에 빠지지 않도록 유의

       취약점과 다른 취약점에 대한 보안대책을 매칭시킬 수도 있음. 그러면 틀린 것임

 

   3) 그 외, 개발보안제도 등도 OX로 나올 수 있다.

 

   

 

나. 객관식  

  * 생각나는 키워드 : SSRF(서버사이드요청위조) 대응방안, 부적절한 XML 외부 개체 참조 대응방안

 

문제는  "부적절한 XML 외부 개체 참조"에 대한 대응방안을 모두 고르시오인데

     XML 삽입 대응방안을 골라서 틀린 것 같다...

 막상 시험장에서 보면 왜이리 헷갈리는지... 거의 공부 안 한 티가 팍팍 났다.(낚는 대로 다 낚이는 응시생...)

     

     - 보기 예 : 로컬 정적 DTD를 사용하도록 설정하고, 외부에서 전송된 XML 문서에 포함된 DTD를 완전하게 비활성화한다. (부적절한 XML 외부 개체 참조)

        XQuery 또는 XPath 쿼리에 사용되는 외부 입력데이터에 대하여 특수문자 및 쿼리 예약어를 필터링한다. (XML 삽입)

      

  (공부대책) 취약점에 대한 보안대책을 다 알아야 하며, 다른 취약점과 헷갈리면 안 된다.

     보안대책을 모두 고르시오 에서 모두 고를 수 있게! (아닌 것도 걸러낼 수 있게)

     헷갈릴 수 있는 취약점들을 취약점 설명 및 보안대책에 대하여 비교해가며 공부해야 된다.

 

다. 주관식(단답형)

   - 문장으로 주어지며 괄호가 2개 정도 비워져 있고 괄호 안에 해당하는 단어를 채워넣기. 생각보다 당황스럽다. 

     (갑자기 그 괄호 안에 내용만 기억이 안 난다!!)

   * 생각나는 키워드 : 역직렬화 함수, 시스템 종료 함수

 

예) (22년) 신뢰할 수 없는 데이터의 역직렬화 취약점에서 (     )와 같이 각 언어에서 제공하는 역직렬화 함수를 확인하고(와 같은 뉘앙스...), (뒤에도 괄호가 있었는데 잊어버림... HMAC이려나, 데이터 무결성이려나, 서명? 서명값 검증이었으려나.)

    → 첫번째 괄호 답은 답은 readObject() 인데, serialize()라고 오답을 작성했다.... 또륵... 정확하게 암기/이해하지 못한 탓이다. 진단방법에서 핵심적인 진단 함수와 관련 보안대책 키워드는 암기해두는 게 좋겠다. 괄호문제를 대비해서...

 

예) (22년) 안전한 난수 생성을 위한 seed 길이는 (   ) 비트이다.

     → 256 비트 이상 이 답인데, 128 비트로 답해서 틀린듯...     

           * 설계 부분에서 명시되어 있고 개발보안부분에는 명시가 되어 있지 않음

 

  (참고) 세션ID는 최소 128비트, 서버에서 생성, 안전한 난수 알고리즘

 

예) (22년) 응용프로그램에서 (    ) 함수는 웹 애플리케이션을 실행하고 있는 컨테이너까지 종료할 수 있으므로 사용하지 않는다. (와 같은 뉘앙스의 문제...)

    → 괄호 답은 System.Exit() 인 것 같다. 나는 exit() 이라고만 썼는데...ㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎ 모르겠다..ㅠㅠ

         System.Exit() 혹은 Application.Exit() 이 답인 것 같고, 이 함수 대신 Form.Closed, Form.Closing, Application.Close() 를 사용하는 것이 안전하다고 한다...   부분점수는 아마 안 주겠지?

     

 (공부대책) 괄호넣기 대비 취약점에 대한 핵심함수 혹은 키워드를 알아야 함.  특정 함수나 키워드들은 암기해두자.

                   개발보안이랑 설계보안을 같이 봐야 함

 

- 설계단계 보안약점 "요구사항"을 기술하고 보안약점명을 골라 작성하는 유형도 있다. 

 

예) (22년) LDAP 인증서버를 통해 인증을 구현하는 경우 인증요청을 위해 사용되는 외부입력값은 LDAP 삽입 취약점을 가지지 않도록 필터링해서 사용해야 한다. 

  → 해당 설명에 맞는 보안약점명(답)은 "디렉터리 서비스 조회 및 결과 검증" 이다. 

       LDAP이라는 키워드가 설계약점에는 디렉터리 서비스 조회 및 결과 검증이라는 것을 알아야 한다.

 

예) 사용자 권한확인 등 필요한 중요기능에 대한 웹 서비스 요청에 대한 유효성 검증방법과 유효하지 않은 요청에 대한 처리방법을 설계해야 한다.

  → 해당 설명에 맞는 보안약점명(답)은 "웹 기반 중요기능 수행 요청 유효성 검증" 이다. 

       웹서비스 요청 및 결과 검증 과 헷갈릴 수 있음

 

예) 비정상적인 HTTP헤더, 자동연결 URL 링크 등 사용자가 원하지 않는 결과를 생성할 수 있는 HTTP 헤더 및 응답결과에 대한 유효성 검증방법과 유효하지 않은 값에 대한 처리방법을 설계한다.

 

외부입력값이 페이지이동(리다이렉트 또는 포워드를 위한 URL로 사용되어야 하는 경우, 해당 값은 시스템에서 허용된 URL 목록의 선택자로 사용되도록 해야 한다.

 → 해당 설명에 맞는 보안약점(답)은 "HTTP 프로토콜 유효성 검증" 이다.

 

예) 파일 업로드 취약점 보안대책 작성

 → 코드를 주고 보안대책을 쓰라고 했던 것 같은데 잘 기억이 나지 않는다...

 

예) XML 삽입에서 XQuery XPath 중 파라미터화된 쿼리문을 지원하는 것은 (    ) 이다,.

 → 개략 요런 느낌이었던 듯. 답은 XQuery이다.

  쿼리구조를 변경시키지 않는bindString() 함수 사용이라는 보안대책을 쓰는 게 있었는지 모르겠다.

 

(공부대책) 설계단계 '요구사항'이 주어지면 헷갈리지 않게 보안약점명을 매칭하자. 보안대책도 공부하자.

 

라. 서술형

   - 취약한 소스코드를 제시

     1) 취약한 소스코드 라인이 밑줄로 표시된 문제를 주고,

          이 라인은 어떤 보안약점이 발생할 수 있는지 보안약점명과 설명/보안대책서술   

 

  * 생각나는 키워드 : 버퍼오버플로 or 정수형 오버플로, 부적절한 예외처리 or 오류상황 대응부재, 오류메시지 정보노출

                                 HTTP응답분할

 

    ① 버퍼오버플로 vs 정수형 오버플로

         - int형 배열 길이가 5로 정해져 있는데

           배열 길이를 고려하지 않고 배열 인덱스를 argv[1] 입력값으로 받아오는 경우

 

           → 정수형 오버플로우다.

               이건 가이드 p.291, 292 를 보면서 구분해야할 것 같다.

 

    ② 부적절한 예외처리 vs 오류상황 대응부재

         - 소스코드로는 2가지가 나왔다 (하나는 실습시험에 나온건지 좀 헷갈림)

            첫번째(교재 p.212, 213 참고)  : try{} 문 이후에 catch(exception e){} 로 단순 처리 

            두번째(교재 p.210, 211 참고) : try{} catch(){} 구문이 없는 경우  --- 보안약점을 제대로 잡았는지는 모르겠다...

 

    ③ 오류메시지 정보노출

예) (22년) 다음 밑줄친 부분에서 "개발단계" 보안약점명과 설명, 보안대책을 작성하시오

     * 표에 빈칸을 주고 채우라고 함 

1:  try{   2:  } catch(IOException e{ 3:   e.printStackTrace(); 4: }

 

헷갈리는 취약점들의 대환장파티였다. 양성과정 교육교재에서 언급한 취약점 "원인"을 간단하면서도 명확하게 이해해서 구분만 했더라도 틀리지 않았을 문제들이다.

 

  ④ HTTP 응답분할에 대하여 대응방안을 작성하는 문제가 나왔다. 

       개행문자(\r, \n) 제거에 대해서 썼던 기억은 나는데, 디테일이 좀 약했던 것 같다.

 

    

 

[실습시험]

1. 소스코드를 주고 "정탐, 오탐" 여부 판별, 해당하는 보안약점명 및 해당하는 이유, 라인수, 대책을 작성

    ① XML 삽입 - 정탐, 오탐

   

...

String ex = "doc('users.xml')/userlist/user[uname='"+name"']";

...

혹은

...

XPathExpression expr = xpath.compile("//users/user[logintext()='"+nm+"' and password/text()='"+pw+"']/home_dir/text()");

...  

이 부분에서 취약한 부분에 대한 이유를 작성하고, 보안대책을 작성하라는 문제였는데

SQL Injection 취약점 및 보안대책과 헷갈렸던 것 같다 ㅠㅠㅠ

 

SQL Injection 은

Query query = session.createQuery("from Student where studentName = '" + name + "' ");

 

부분에서 name이 취약한데

${ }$ 를 #{ }# 로 바꿔야 되는 부분과 헷갈려서

+ + 를 #{}# 로 바꿔야 된다고 잘못 답한것 같다.

 

+{ }+ 에서 + 가 취약한 것이 아니라

인자가 검증없이 들어간 게 취약한 것이므로,

보안대책을 제대로 적어야 한다.

 

 

 

2. 설계 단계 

     요구사항, 보안대책, 개발가이드, 아키텍처 설계 를 제시하고,

     - 약점이 있는 부분 명시

     - 왜 보안약점이 있는 설계인지에 대한 설명

     - 보완대책 설명 (최소 ~가지 이상)

 

① 웹 서비스 요청 및 결과 검증 (설계 문서들)

 

   * 아키텍처 설계서 그림을 보면,

      Filter : 입력값에 대해 XSS 필터 적용

      Controller 내 핸들러 인터셉터: 입력값을 검증하여 안전하지 않은 입력값 요청 차단

      Controller 내 핸들러 Validation : 공통코드로 작성된 Validator를 이용하여 각 Controller에서 입력값 검증 후 사용

      Controller 내 비즈니스 로직 & View : 출력값에 대하여 HTML 인코딩을 적용하거나, XSS 필터를 적용 (안전한 값으로 변환하여 응답)

   

       (공부방법) 설계시 고려사항 공부, 딸린 아키텍처 그림에 대해서 맞는 아키텍처에 서술되어 있는지 구분  

 

② 취약한 암호화 알고리즘(전송 TLS 버전, MD4나 5가 있었던 것 같음, SEED-128, AES-128)

    - 잘못된 것 3가지 쓰기

     아마, 한개는 MD4나 5인 것 같고, 하나는 전송 TLS 버전이 1.1이어서 취약하다는 내용으로 써야 할듯

     DES는 취약하지만 AES-128이나 SEED-128은 안전한 것 같다.

    (가이드 p.330 참고)

 

       (공부방법) 보안대책을 자세하게 서술해야 한다.(예를 들어 어떤 취약한 알고리즘이 제시되었다면 취약한 암호화알고리즘 설계이므로 안전한 암호화알고리즘이 어떤 것이 있으므로 대체해서 써야한다. 등 구체적인 대책을 이해 및 암기해서 디테일하게 제시해야 한다)  

 

그 외, XML 조회 및 결과 검증에서 XPath가 아닌, 외부 입력값이 쿼리문의 구조를 바꿀 수 없는 XQuery 를 사용한다.

 

20년 대비 21년에 신설된 항목들이 자주 나오는 듯 하다.

 

 

필수 공부교재는 1개를 꼽으라면 양성과정 교육교재보다는

"소프트웨어 보안약점 진단가이드"가 더 나은 것 같다. (교육교재는 생략된 내용들이 좀 많고, 설명이 부족하다)

먼저 양성과정 교육교재에서 빠르게 키워드들을 잡아나간 뒤, 보안약점 진단가이드로 상세 내용을 공부해나가는 것이 좋은 것 같다.

 

 

퇴실은 15:20분부터 가능한데... 실습시험을 보다보면 시간이 그렇게 부족하지도, 넉넉하지도 않은 느낌이다.

 

추가적으로, 시험시간이 길기 때문에 시험 중간에 먹을 초코렛? 정도 가져오면 좋은 것 같다.