취약점 점검 자동화: 수집·판정·증적·오류 처리

01점검 자동화의 목표와 모듈 구조

• 자동화의 목적원본 과제는 주정통 항목의 현재 값을 조회하고 기준에 따라 평가하여 결과를 DB나 보고서로 저장하는 프로그램이었다.

  • 팀별로 서버·네트워크·보안 장비 등을 나누고 공통 실행부가 연결 정보를 넘겨 항목별 class 또는 function을 실행하는 구조를 논의했다.
• 모듈 경계공통 connector가 SSH 연결·명령 실행·타임아웃·종료를 맡고 collector가 관찰값을 수집하며 evaluator가 기준을 적용하고 reporter가 결과를 저장하도록 역할을 나눌 수 있다.

  • 모듈 이름과 JSON 키는 구현 예시다.
  • 점검 기준의 요구사항과 프로그램 내부 설계 규칙을 구분한다.
• 연결 재사용과 부분 실패연결을 항목마다 새로 맺지 않고 재사용하면 로그인 비용을 줄일 수 있지만 연결이 끊겼을 때 재시도·세션 상태·권한 전환을 처리해야 한다.

  • 한 자산의 실패가 전체 점검을 중단하지 않게 하고, 성공한 항목과 수집하지 못한 항목을 함께 기록한다.

02자동 점검의 수집·판정·보고 단계

1. 대상과 항목 로드자산 ID, 접속 방법, 점검 항목과 기준 판본을 읽는다.
2. 연결과 권한 확인공통 Connector가 연결을 준비한다. 실패한 자산과 오류를 남기고 다른 대상 처리를 계속할 정책을 적용한다.
3. Collector 실행허용된 조회를 실행하고 stdout·stderr·종료 코드·시간 초과를 구분해 수집한다.
4. Evaluator 판정수집값에 적용 조건·예외·양호/취약 기준을 적용한다. 빈 출력과 수집 실패를 정상 상태로 바꾸지 않는다.
5. Reporter 기록자산·항목·판정 이유·관찰값·시각·수집기와 규칙 버전을 저장한다.
6. 검토와 별도 조치불명확한 항목은 수동 검토하고 승인된 조치는 별도 변경 과정으로 수행한다. 조치 후 재점검 결과를 연결한다.

03읽기 전용 점검과 자원 사용 한도

• 조회와 변경의 분리진단은 현재 상태를 읽는 작업이다.

  • 취약점이 발견되었다고 설정 파일 수정·패키지 설치·서비스 재시작을 자동으로 섞지 않는다.
  • 보안 정책을 바꾸는 remediation은 승인된 변경 계획과 복구 절차 아래 별도 실행한다.
• 자원 사용 한도조회 명령도 큰 디렉터리 순회나 대량 로그 읽기로 I/O를 소모한다.

  • 대상 경로, 출력 크기, 동시 접속 수, 실행 시간을 제한하고 취소·오류 처리 경로를 만든다.
  • 결과를 저장하기 위한 파일 쓰기는 필요할 수 있지만 시스템의 보안 설정 변경과 구분하고 결과 경로의 접근 권한을 제한한다.
• 표준 출력·오류·종료 상태모든 오류를 2>/dev/null로 없애면 오판을 만들 수 있다.

  • stdout과 stderr, 종료 코드, timeout을 분리 수집하되 공개 보고서에는 필요한 부분만 담는다.
  • “출력이 비어 있음”이 값이 없다는 뜻인지 읽기 실패인지 판단할 근거를 남긴다.

04Windows secedit 내보내기와 실제 정책 범위

• secedit exportsecedit /export는 보안 템플릿과 연결된 보안 데이터베이스의 설정을 내보낸다.

  • 원본은 /db test.sdb 지정 시 오류가 나고 해당 옵션을 뺐을 때 동작한 기록을 남겼다.
  • 임의로 적은 DB 파일명과 시스템의 실제 보안 데이터베이스를 혼동한 사례로 읽으며 export 실패를 점검 양호로 처리하지 않는다.
• 병합 정책과 적용 범위도메인·로컬 정책의 병합을 고려할 때 /mergedpolicy 옵션과 적용 대상 영역을 확인한다.

  • 하나의 INF가 모든 레지스트리·모든 GPO·서비스별 보안 설정을 완전히 대표하는 것은 아니므로 대상 항목에 맞는 추가 조회가 필요하다.
  • /import는 DB로 들여오는 동작이고 /configure는 적용 작업이므로 진단 단계에 넣지 않는다.
• 공유 경로로 결과 전송UNC 공유 경로로 내보내기는 결과 전송 방식의 예다.

  • 공유 접근권한·네트워크 보호·수신 폴더 권한·자격 증명 취급을 검토해야 하며 남의 서버에 무단으로 저장하거나 누구나 읽는 공유에 결과를 두는 방식으로 일반화하지 않는다.

secedit /export /mergedpolicy /cfg C:\Audit\security.inf /log C:\Audit\export.log

기존 C:\Audit 폴더에 결과 파일을 생성하는 구조 예제다. 필요한 권한과 보관 위치를 먼저 준비하고, 실행 성공·오류를 확인한 뒤 파싱한다.

수업 원본 자료

원본 로컬 보안 정책 화면을 점검 근거로 읽기

원본 크기로 보기 ↗

이 자료에서 읽어낼 것

1. 선택된 항목은 Administrator 계정 이름 바꾸기이며 오른쪽 표시 값도 Administrator이다. 변경이 완료된 결과 화면이라고 주장하지 않는다.
2. 계정 상태, 이름 변경, 원격 접속 권한, 암호 정책은 별도 조건이다. 표시 이름 하나만 바꾸어 모든 관리자 보안이 강화되었다고 평가하지 않는다.
3. 정의되지 않음과 해당 없음이 섞여 있다. 도메인 정책과 실제 적용 상태를 확인하지 않고 모든 항목을 일괄 양호로 판정하지 않는다.
4. 전체 화면은 로컬 정책 관측 시점의 증거다. 자산 식별·수집 시각·기준 판본 및 다른 수집 결과와 연결하여 보고서에 사용한다.

05SID·표시 이름·유효 권한을 구분하기

• SID와 계정·그룹Windows는 보안 주체를 SID로 식별한다.

  • 내장 Administrator 계정의 RID는 500이고, S-1-5-32-544는 Administrators 그룹, S-1-5-32-551은 Backup Operators 그룹이다.
  • Windows SID와 Linux UID는 다른 식별 체계이며 개인 계정과 그룹도 구분한다.
• 표시 이름과 권한 할당SeBackupPrivilege에 나열된 SID는 해당 사용자 권한의 할당 대상을 가리킨다.

  • 계정의 표시 이름이 바뀌어도 SID가 함께 새로 생기는 것은 아니다.
  • 이름 문자열만 비교하면 이름 변경·언어 차이·그룹 중첩 때문에 잘못된 결과를 낼 수 있다.
• 유효 접근 권한계정 잠금·활성 상태, 암호 정책, 원격 로그온 권한, 그룹 소속, 서비스 설정과 접근 경로를 기준에 맞춰 나눠 점검한다.

  • 관리자 이름 변경 화면 하나를 시스템 관리자 권한의 전체 검증으로 대신하지 않는다.

06Linux·네트워크 장비의 유효 설정 수집

• 실제로 적용된 설정Linux 서비스는 기본 파일, Include, 배포판 도구와 runtime 상태가 겹친다.

  • SSH는 Match 조건과 유효 설정, PAM은 실제 인증 스택, rsyslog는 로드한 규칙과 출력 대상까지 봐야 한다.
  • 파일이 있다는 사실과 기능이 실제 활성화된 것은 다르다.
• 표시·보존·전송의 차이원본 로그 실습은 *.alert의 콘솔 출력과 journald ForwardToWall 설정을 바꾸어 경보가 보이는지 비교했다.

  • 콘솔 표시, 사용자 터미널로 wall 전송, 파일 보존과 중앙 수집은 서로 다른 목적이다.
  • 콘솔에서 한 줄 보였다는 결과만으로 로그 보존·무결성·전송 기준을 모두 충족했다고 판정하지 않는다.
• 장비 출력과 파서 버전네트워크 장비의 show running-config를 수집할 때 pagination, 권한 수준, 출력 생략, 비밀 포함 여부와 소프트웨어 버전을 고려한다.

  • show 명령 이름에 해당한다고 무조건 모든 장비에서 같은 필드가 나온다고 기대하지 않는다.
  • 진단 대상과 파서 버전을 결과에 함께 기록한다.

07판정 결과 스키마와 오류의 표현

• 결과 스키마한 항목 결과에는 자산 ID, 기준 이름·판본, 항목 코드, 상태, 관찰값, 판정 이유, 수집 시각, collector·rule 버전과 오류 정보를 둔다.

  • 여러 팀이 같은 규칙으로 출력해야 DB 적재와 보고서 집계가 가능하다.
  • 다음 키는 학습용 설계 예이며 공식 필수 양식이라는 뜻이 아니다.
• N/A·ERROR·수동 검토N/A는 적용 대상이 아니라는 확인된 근거가 있을 때 사용한다.

  • 권한 부족과 명령 실패는 ERROR 또는 별도 수집 상태로 남기고 평가되지 않은 항목 수에 포함한다.
  • 수동 검토는 누구에게 어떤 정보가 더 필요한지 적어야 검토 대기 상태가 영구적인 면제가 되지 않는다.

{
  "asset_id": "LAB-WIN-01",
  "baseline": "course-lab-v1",
  "check_id": "LAB-ADMIN-01",
  "status": "REVIEW",
  "observed": "로컬 정책 화면과 내보내기 결과 확보",
  "reason": "도메인 적용 정책과 유효 원격 권한 추가 확인 필요",
  "evidence_id": "E-001",
  "collector_version": "1.0",
  "collection_error": null
}

교육용 결과 객체다. 공식 점검 코드를 임의로 붙이지 않았고 실장비에서 실행한 결과가 아니다.

09판정기를 시험하고 팀 결과를 통합하기

• 판정 표본과 회귀 비교정상·취약·해당 없음·누락·권한 실패·알 수 없는 버전의 입력 표본으로 판정기를 시험한다.

  • 수집기의 명령 성공만 시험하면 evaluator가 잘못된 기준을 적용해도 발견하기 어렵다.
  • 원문과 기대 판정을 한 세트로 보관하고 기준 개정 때 회귀 비교한다.
• 파싱 경계와 테스트 자료파일 인코딩, 줄바꿈, 로케일, 빈 값·중복 값, 네트워크 장비의 더 보기 프롬프트도 파싱 결과를 바꾼다.

  • 비밀과 개인정보를 제거한 fixture를 사용하고 테스트용 기대 값을 실제 고객 점검 결과처럼 보고하지 않는다.
  • 점검 코드 변경 이력과 기준 변경 이력을 함께 관리한다.
• 팀 결과의 집계 규칙팀 통합에서는 자산 ID와 항목 ID의 유일성, 중복 결과 처리, 재실행 시각, 일부 실패 때의 집계 정책을 합의한다.

  • 취업용 설명에서는 자신이 작성한 수집·판정·저장·검증 부분과 공동 실행부의 경계를 구체적으로 말하고, 실제 운영 환경 적용 여부를 구분한다.