IT자격증

정보시스템감리사 자격증을 2016년에 취득했지만 당장 쓸려고 한건 아니었기 때문에 
계속 직장생활을 하고 있는 중에 .. 회사 업무도 짜증나고 회사 미래도 불투명하고
정말 회사 다니기 싫다는 생각이 올해는 무지 들었다.. 그러던 중에 나중에 감리시장에
뛰어들 때를 대비해서 미리 경험을 해보고자 감리사 동기분한테 소개 부탁을 해서
하 감리법인과 연결이 되었다.. 처음에는 종료감리에 투입되기로 했으나 나도 감리경험이
없는 상태이고 감리법인도 설계단계가 아닌 종료단계에 초짜를 투입하기에는 부담감이
있었기에 감리 대신 소스코드 보안약점진단 업무에 비상근 전문가 자격으로 투입되었다
나도 부담 백배였는데.. 소스코드 보안약점 진단은 훨 부담이 없다고 해서 다행..
단 대전으로 출장을 가야하는 일정이었다. (물론 회사에는 5일 연차 사용. 이판사판)
복장도 편한 정장이라고 하는데..어느정도 수준인지도 모르겠고 집에 양복도 없었기에
주말에 마트가서 세미정장 한벌과 와이셔츠 2벌을 장만했다.
(실제 가보니 그정도 까지는 필요없고 아래는 양복바지만 입고 위에는 꼭 와이셔츠나
양복상의가 필요 없어보였다.. 그냥 안에 셔츠에 바깥에 조끼나 니트 정도 입어도 될듯..)
그리고 캐리어를 가져가야할지 말지 고민하다가 그냥 스포츠가방에 넣어서 갔는데
다른 감리사분들은 캐리어을 가져오셨다.. 이것도 담에 참고..
월요일 아침에 일찍 서울역으로 가서 대전행 KTX를 타고 대전에 9시쯤 도착해서
감리사 분들과 같이 택시타고  감리장소로 갔다. 
다른 감리사분들은 이전에 설계단계 감리 때 와보셨기 때문에 다 능숙하게 자리잡으시고
노트북 꺼내서 바로 업무 시작.. 나는 회사에서 준 노트북을 키고 이전에 연습해본 
다른 소스진단결과를 보면서 긴장을 풀고 있었다.
회사에서 준 노트북은 주로 소스코드 보안약점 진단업무 전용 노트북으로서 안에
진단툴이 설치되어 있다.. (이 진단툴이 약 5천만원 한다고 함.)
오후에 점심먹고 사업자PM에게 소스 달라고 했고 PM은 정리해서 내일 오전에 드리겠다고
해서.. 오후는 그냥 놀았음.
퇴근은 5시 30분쯤에 일찍.. 아마도 대전 시내가 차가 막혀서 30분 미리 나가고 대신 담날
30분 일찍 8시 30분까지 출근했다 
모텔에 와서 방 배정받고 .. 낮설은 모텔방에서 혼자 자는데..첫날은 긴장해서 그런지 10시쯤
잠들었다. (이후 점점 적응하면서 취침시간이 11시, 12시, 1시로 늘어남. ㅋㅋ)
둘째날 오전에도 소스를 안줘서.. 좀 짜증이 나기 시작함.. 할일도 없어서.. 
오후에 드디어 소스를 받아서 진단툴에 넣고 냅다 돌렸다.. 
어떤 결과가 나올지 내심 기대가 되었다.. 보통 툴 돌리면 취약점이 2~4천개 정도 나오는 거같다.
진단 결과 2천여개가 나왔지만 다행이 위험도가 높은건 11건 밖에 안되고 중간껏도 120 개정도
나머지 95%가 낮은 위험도 였다.

진단툴은 생각보다 쓰기는 괜찮았다...
위와 같이 진단결과가 나오고 오른쪽에는 해당 소스 위치가 나오고 클릭하면 아래와 같이 해당 소스및 취약점 위치가
나온다. 

위에서 해당 취약점 라인을 클릭하면 우측에 아래와 같이 취약점 설명 및 조칩  방법에 대해서도 잘 나와있다.

각 위험도 별로 개별 소스를 확인해서 다음과 같이 3개로 분류를 했다.
  ① 오탐 - 취약점이 아닌데 진단툴이 그냥 syntax로 판단하다보니깐 취약점으로 잘못 탐지
  ② 예외처리 - 사업자가 개발한 소스가 아니거나 상용소프트웨어의 소스인 경우
  ③ 보안약점 - 위 두경우가 아닌 진짜 수정이 필요한 취약점

물론 2천여개 소스파일을 다 볼수는 없다.. 보다보면 같은 패턴이 왕창 나오기 때문에 나머지는
같은 분류로 판정하면 된다.
예외처리 건은 사업자 PM을 불러서 설명을 들어야 알수 있는 부분이 많다. 요 때 사업자랑
서로 인정 즉 합의가 되어야 한다.
이 과정을 통해서 3가지 분류를 확정한 다음 사업자PM에게 보안약점을 감리기간내에 최대한
조치해줄것을 요청한다. 그러면 사업자측은 수정을 할수 있는 건 최대한 수정을 해서 다시
소스파일을 준다. 그러면 이 소스파일을 가지고 2차 진단을 수행해서 감소된 취약점을
정리해서 최종 보고서에 1차 진단때 몇개가 검출되었고 감리기간내에 몇개가 수정되었고
나머지 잔여취약점이 몇개가 남았는지 작성해서 제출하면 된다.
다행이 이 사업자는 이전에 몇번 소스코드 보안취약점 진단을 했던 소스라서 아주 크리티컬한
취약점.. 예를 들어 SQL Injection, XSS 같은 취약점은 안나왔다. 

나에게는 어쩌면 정말 소중한 경험이었다..
비록 감리는 아니었지만 그래도 옆에서 분위기는 조끔 파악했고..어떤식으로 감리가 진행되고
종료보고는 어떤식으로 하는 건지도 배울수 있는 좋은 기회였다.
같이 감리수행하시는 분들은 나보다 연배가 한참 많으셨다.. 나는 거의 영계 수준.. ㅋㅋ
(참고로 나는 49세)
이놈의 회사는 맘에 안들어서 당장 감리법인에 가고싶지만.. 급여수준이 넘 차이가 나서
아직까지는 이 망할놈의 회사에 붙어있어야 한다..
옆에서 본 검리업무의 강도는 센편은 아니었다.. 어떻게 보면 여유가 있어 보이기도 하고..
편해 보이기도 했다.. 
내년에는 상반기에 설계감리부터 참여하고 하반기에 종료감리까지 한번 해보는게
목표다.

SW개발보안가이드중 구현단계에서의 점검항목은 크게 7가지 이다.  (입보시에코캡아)
  1. 입력데이터 검증 및 표현
  2. 보안기능
  3. 시간 및 상태
  4. 에러처리
  5. 코드오류
  6. 캡슐화
  7. API 오용
       7-1.DNS Lookup 에 의존한 보안결정
       7-2. 취약한 API사용

이 장에서는 "7.API 오용" 에 대한 점검항목을 설명한다.


7-1.DNS Lookup 에 의존한 보안결정

7-2. 취약한 API사용

SW개발보안가이드중 구현단계에서의 점검항목은 크게 7가지 이다.  (입보시에코캡아)
  1. 입력데이터 검증 및 표현
  2. 보안기능
  3. 시간 및 상태
  4. 에러처리
  5. 코드오류
  6. 캡슐화
      6-1.잘못된 세션에 의한 데이터 정보 노출 (싱글톤 멤버변수)
      6-2. 제거되지 않고 남은 디버그 코드
      6-3. 시스템 데이터 정보 노출
      6-4. Public 메소드로부터 반환된 Private 배열  (Get함수)
      6-5. Private 배열에 Public 데이터 할당 (Set함수)
  7. API 오용

이 장에서는 "6.캡슐화" 에 대한 점검항목을 설명한다.
(두음 : 잘제시PP)



6-1.잘못된 세션에 의한 데이터 정보 노출 (싱글톤 멤버변수)

6-2. 제거되지 않고 남은 디버그 코드

6-3. 시스템 데이터 정보 노출

6-4. Public 메소드로부터 반환된 Private 배열  (Get함수)

6-5. Private 배열에 Public 데이터 할당 (Set함수)

SW개발보안가이드중 구현단계에서의 점검항목은 크게 7가지 이다.  (입보시에코캡아)
  1. 입력데이터 검증 및 표현
  2. 보안기능
  3. 시간 및 상태
  4. 에러처리
  5. 코드오류
      5-1. Null Pointer 역참조
      5-2. 부적절한 자원 해제
      5-3. 해제된 자원 사용
      5-4. 초기화되지 않은 변수 사용
  6. 캡슐화
  7. API 오용

이 장에서는 "5.코드오류" 에 대한 점검항목을 설명한다.
(두음 : 널부해초)


5-1. Null Pointer 역참조

5-2. 부적절한 자원 해제

5-3. 해제된 자원 사용

5-4. 초기화되지 않은 변수 사용

SW개발보안가이드중 구현단계에서의 점검항목은 크게 7가지 이다.  (입보시에코캡아)
  1. 입력데이터 검증 및 표현
  2. 보안기능
  3. 시간 및 상태
  4. 에러처리
      4-1. 오류메시지를 통한 정보노출
      4-2. 오류 상황 대응 부재
      4-3. 부적절한 예외 처리
  5. 코드오류
  6. 캡슐화
  7. API 오용

이 장에서는 "3.에러처리" 에 대한 점검항목을 설명한다.


4-1. 오류메시지를 통한 정보노출

 

4-2. 오류 상황 대응 부재

4-3. 부적절한 예외 처리

SW개발보안가이드중 구현단계에서의 점검항목은 크게 7가지 이다.  (입보시에코캡아)
  1. 입력데이터 검증 및 표현
  2. 보안기능
  3. 시간 및 상태
      3-1. 경쟁조건: 검사시점과 사용시점 (TOCTOU)
      3-2. 종료되지 않은 반복문 또는 재귀함수
  4. 에러처리
  5. 코드오류
  6. 캡슐화
  7. API 오용

이 장에서는 "3.시간 및 상태" 에 대한 점검항목을 설명한다.



3-1. 경쟁조건: 검사시점과 사용시점 (TOCTOU)

3-2. 종료되지 않은 반복문 또는 재귀함수

SW개발보안가이드중 구현단계에서의 점검항목은 크게 7가지 이다.  (입보시에코캡아)
  1. 입력데이터 검증 및 표현
  2. 보안기능
      2-1. 적절한 인증없는 중요기능 허용
      2-2. 부적절한 인가 
      2-3. 중요자원에 대한 잘못된 권한 설정
      2-4. 취약한 암호화 알고리즘 사용
      2-5. 중요정보 평문 저장
      2-6. 중요정보 평문 전송
      2-7. 하드코드된 비밀번호
      2-8. 충분하지 않은 키 길이 사용
      2-9. 적절하지 않은 난수값 사용

      2-10. 하드코드된 암호화 키
      2-11. 취약한 비밀번호 허용
      2-12. 사용자 하드디스크에 저장되는 쿠기를 통한 정보노출
      2-13. 주석문 안에 포함된 시스템 주요 정보
      2-14. 솔트없이 일방향 해쉬 함수 사용
      2-15. 무결성 검사 없는 코드 다운로드
      2-16. 반복된 인증시도 제한 기능 부재
  3. 시간 및 상태
  4. 에러처리
  5. 코드오류
  6. 캡슐화
  7. API 오용

이 장에서는 "2.보안기능" 에 대한 점검항목을 설명한다. (두번째)



2-10. 하드코드된 암호화 키

2-11. 취약한 비밀번호 허용

2-12. 사용자 하드디스크에 저장되는 쿠기를 통한 정보노출

2-13. 주석문 안에 포함된 시스템 주요 정보

2-14. 솔트없이 일방향 해쉬 함수 사용

2-15. 무결성 검사 없는 코드 다운로드

2-16. 반복된 인증시도 제한 기능 부재

SW개발보안가이드중 구현단계에서의 점검항목은 크게 7가지 이다.  (입보시에캡코아)
  1. 입력데이터 검증 및 표현
  2. 보안기능
      2-1. 적절한 인증없는 중요기능 허용
      2-2. 부적절한 인가 
      2-3. 중요자원에 대한 잘못된 권한 설정
      2-4. 취약한 암호화 알고리즘 사용
      2-5. 중요정보 평문 저장
      2-6. 중요정보 평문 전송
      2-7. 하드코드된 비밀번호
      2-8. 충분하지 않은 키 길이 사용
      2-9. 적절하지 않은 난수값 사용

      2-10. 하드코드된 암호화 키
      2-11. 취약한 비밀번호 허용
      2-12. 사용자 하드디스크에 저장되는 쿠기를 통한 정보노출
      2-13. 주석문 안에 포함된 시스템 주요 정보
      2-14. 솔트없이 일방향 해쉬 함수 사용
      2-15. 무결성 검사 없는 코드 다운로드
      2-16. 반복된 인증시도 제한 기능 부재
  3. 시간 및 상태
  4. 에러처리
  5. 코드오류
  6. 캡슐화
  7. API 오용

이 장에서는 "2.보안기능" 에 대한 점검항목을 설명한다. (첫번째)


2-1. 적절한 인증없는 중요기능 허용
      < Key Point > 
        개인정보수정, 계좌이체등 중요기능은 재인증을 다시 할것!!
        물론 재인증시에는 "보안기능 결정에 사용되는 부적절한 입력값 " 처럼 Session정보 이용)

2-2. 부적절한 인가 
  < Key Point > 
      : 삭제 권한

2-3. 중요자원에 대한 잘못된 권한 설정
    < Key Point >
       : 파일에 대한 접근권한

2-4. 취약한 암호화 알고리즘 사용

2-5. 중요정보 평문 저장

2-6. 중요정보 평문 전송

2-7. 하드코드된 비밀번호

2-8. 충분하지 않은 키 길이 사용

2-9. 적절하지 않은 난수값 사용