알고 있다. 1월 11일 포스팅의 분량이나 수준이 별로 높지 않았다는 것을. 하지만 이해해주기 바란다. 사실 최근 들어서 본격적으로 보안관제 취업을 준비하게 되었는데, 이제부터는 면접 준비를 해야 할 것 같아 오늘과 내일 양일 간은 문제 풀이보다는 면접 관련한 주제를 다룰 것이다. 면접 질문에는 다양한 질문들이 있겠지만, 이곳에는 기술과 관련한 예상질문들을 쓰고 모범답변(?)도 같이 달아보도록 하겠다. 이하의 예상 질문들은 구글링하여 가져온 보안관제 면접 기출질문들과 약간의 내가 만든 질문들이 들어있다.
보안관제 면접 준비 목차
- 기술 관련 질문
- 직무 및 회사 관련 질문
- 기타
1-1. OWASP Top 10
OWASP(Open Web Application Security Project) 재단에서 3~4년 주기로 발표하는 10대 웹 보안 취약점을 뜻한다.
오늘(2021.01.12) 기준 최신판인 2017년 버전에 따르면, OWASP Top 10은 아래와 같다.
- Injection (인젝션)
- SQL, OS, XXE, LDAP 인젝션 취약점은 신뢰할 수 없는 데이터가 명령어나 쿼리문의 일부분으로서 인터프리터로 보내질 때 발생한다.
- 공격자의 악의적인 데이터는 예기치 않은 명령을 실행하거나 올바른 권한 없이 데이터에 접근하도록 인터프리터를 속일 수 있다.
- 취약한 인증
- 인증 및 세션 관리와 관련된 어플리케이션 기능이 종종 잘못 구현되어 공격자들이 암호, 키, 세션 토큰을 위험에 노출시킬 수 있거나 일시적 또는 영구적으로 다른 사용자의 권한 획득을 위해 구현 상 결함을 악용하도록 허용한다.
- 민감한 데이터 노출
- 다수의 웹 어플리케이션과 API는 금융, 건강, 개인 정보 등과 같은 중요 정보를 제대로 보호하지 않는다.
- 공격자는 신용카드 사기, 신분 도용 등의 범죄행위를 하고자 보호가 취약한 데이터를 훔치거나 변조할 수 있다.
- 중요 데이터는 저장 또는 전송 시 암호화 등의 추가 보호 조치가 없으면 탈취될 수 있으므로 각별한 주의가 필요하다.
- XXE (XML eXternal Entity, XML 외부 개체)
- XXE는 악성 자바스크립트를 막기 위한 필터장치를 우회하는 취약점으로 XML 문서에서 동적으로 외부 URI의 리소스를 포함시킬 수 있는 외부 개체(Entity)를 사용할 때 발생한다.
- 오래되었거나 설정이 잘못된 XML 프로세서들은 XML 문서 내에서 외부 개체 참조를 평가한다.
- 외부 개체는 파일 URI 처리기, 내부 파일 공유, 내부 포트 스캔, 원격 코드 실행과 서비스 거부 공격을 사용하여 내부 파일을 공개하는데 사용할 수 있다.
- 취약한 접근 통제
- 인증된 사용자가 수행할 수 있는 작업에 대한 제한이 제대로 적용되어 있지 않을 경우를 말한다.
- 공격자는 이러한 결함을 악용하여 다른 사용자의 계정에 접근, 중요 파일 열람, 데이터 변조, 접근 권한 변경 등의 기능과 데이터에 접근할 수 있다.
- 잘못된 보안 구성
- 잘못된 보안 구성은 가장 흔하게 보이는 이슈이다.
- 취약한 기본 설정, 미완성 (또는 임시 설정), 개방된 클라우드 스토리지, 잘못 구성된 HTTP 헤더 및 민감한 정보가 포함된 장황한 에러 메시지로 인한 결과이다.
- 모든 OS, Framework, Library와 Application을 안전하게 설정해야 할 뿐만 아니라 시기 적절하게 패치 또는 업그레이드를 진행해야 한다.
- XSS (Cross-Site Scripting, 크로스 사이트 스크립팅)
- Application이 올바른 유효성 검사 또는 필터링 처리 없이 새 웹 페이지에 신뢰할 수 없는 데이터를 포함하거나, 자바스크립트와 HTML을 생성하는 브라우저 API를 활용한 사용자 제공 데이터로 기존 웹 페이지를 업데이트할 때 발생한다.
- 피해자의 브라우저에서 공격자에 의해 스크립트를 실행시켜 사용자 세션 탈취, 웹 사이트 변조, 악성 사이트로 리다이렉션 등의 악성행위를 수행한다.
- 안전하지 않은 역직렬화
- 안전하지 않은 역직렬화는 원격 코드 실행, 권한 상승, 인젝션, 재생 공격 등의 다양한 공격 수행에 사용될 수 있다.
- 알려진 취약점이 있는 구성요소 사용
- 라이브러리, 프레임워크 및 다른 소프트웨어 모듈 같은 구성요소는 어플리케이션과 같은 권한으로 실행된다.
- 해당 구성요소에 있는 취약점이 악용될 경우, 심각한 데이터 손실을 일으키거나 서버가 장악될 수 있다.
- 패치되지 않은 취약점이 있는 구성요소를 사용한 어플리케이션과 API는 방어를 약하게 하거나 다양한 공격과 영향을 주게 된다.
- 불충분한 로깅 및 모니터링
- 사고 대응의 비효율적인 통합 또는 누락과 함께 공격자들이 시스템을 더 공격하고, 지속성을 유지하며, 더 많은 시스템을 중심으로 공격할 수 있도록 만든다.
- 데이터를 변조, 추출 또는 파괴할 수 있다.
- 대부분의 침해 사례에서 침해 탐지까지 200일 이상이 소요되는 것을 보여주며, 이는 일반적으로 내부 프로세스와 모니터링보다 외부 기관이 탐지한다.
1-2. OSI 7 Layer
- 1계층 - 물리 계층
- 물리매체를 통한 bit 흐름을 전송
- 물리적 장치와 인터페이스가 전송을 위해 필요한 기능과 처리절차 규정
- 2계층 - 데이터 링크 계층
- 노드와 노드 사이의 데이터 전달
- 단순히 bit를 전송하는 물리층에 신뢰성을 더하기 위한 재전송, 흐름 제어 및 오류 제어 기능
- 3계층 - 네트워크 계층
- 송신 측에서 최종목적지까지 패킷을 전달
- 송수신 측의 논리주소 지정 및 패킷이 최종목적지에 도달하도록 경로를 배정하는 라우팅 기능
- 데이터 링크의 물리주소는 패킷이 시스템으로 이동할 때마다 변경되지만, 네트워크 주소는 목적지까지 변하지 않음
- 4계층 - 전송 계층
- 네트워크 계층에서 패킷을 종단까지 전달한다면, 전송 계층은 종단 내에서 최종 수신 프로세스로의 전달을 담당
- 분할, 재조립, 흐름 제어, 오류 제어
- 5계층 - 세션 계층
- 통신하는 프로세스 사이의 대화제어 및 동기화를 담당
- 6계층 - 표현 계층
- 데이터의 변환, 압축, 암호화를 담당
- 7계층 - 응용 계층
- 사용자에게 서비스 제공 역할. SMTP, FTP, HTTP 등 사용자가 원하는 최종목표에 해당
1-3. TCP와 UDP의 차이점
TCP는 신뢰성 있는 연결 지향. 통신 전 3-Way Handshaking을 통해 상대와 통신을 준비하는 과정이 있다. 흐름 제어, 오류 제어를 지원한다.
UDP는 TCP와는 달리 신속한 통신을 지향하므로 별도의 연결 과정 없이 바로 데이터 전송이 시작되며, 흐름 제어, 오류 제어를 지원하지 않는다. (단, 패킷의 변조를 확인할 수 있는 Checksum은 존재)
1-4. IDS와 IPS의 차이점
IDS와 IPS는 모두 설정된 정책에 따라 이상패킷을 탐지하는 기능이 탑재되어 있다. 그러나 IDS와 달리, IPS는 탐지 뿐만 아니라 해당 패킷을 차단하는 기능 또한 존재한다. 탐지만을 위한 IDS는 포트 미러링을 통해 복사된 패킷들을 분석하여 탐지하는 것이 일반적인데, 이럴 경우 IDS가 네트워크 흐름에 영향을 미치지 않으면서 분석이 가능하다. 즉, IDS로 인해 네트워크 속도가 느려지거나 네트워크가 다운되는 일 없이 분석을 할 수 있다.
IPS는 차단을 목적으로 설치하므로 실제 패킷들이 지나가는 관문의 역할을 한다. 즉 실제 패킷이 아닌 복사된 패킷들을 다루는 IDS와 달리 실제 패킷들을 실시간으로 분석하고 경우에 따라 차단도 할 수 있다. 이러한 점은 IDS보다 낫지만, IPS로 인해 네트워크가 느려지거나 다운되는 등의 상황이 발생할 수 있다. 최근 출시되는 제품들은 상당히 높은 대역폭(최대 40Gbps ~ 100Gbps)까지 다룰 수 있으며, IPS가 정상작동하지 못할 경우에는 자동으로 모든 패킷들을 허용하여 네트워크가 다운되는 일이 없도록 하는 기능이 추가되어 있다.
1-5. DoS (Denial of Service, 서비스 거부 공격)
공격 대상의 서비스 자원을 악의적으로 점거하여 정상적인 서비스 제공을 방해하는 행위를 말한다. 다수로부터 DoS 공격을 받을 경우에는 DDoS(Distributed Denial of Service, 분산 서비스 거부 공격)라고 하며, DDoS 공격 방식 중 반사체를 이용해 트래픽을 증폭시켜 공격하는 것을 DRDoS(Distribued Reflection Denial of Service, 분산 반사 서비스 거부 공격)라고 한다. 여기서 반사체는 정상적으로 운영되고 있는 서버들이 일반적이다. 반사체에게 공격대상(Target)의 IP 주소를 발신지로 하여 요청(Request)을 보내면 그 응답(Response)은 발신자의 IP 주소를 따라 공격대상에게 간다. 이 때 응답의 데이터 크기는 요청의 그것보다 훨씬 커서 이러한 응답들이 한꺼번에 한 대상으로 몰리면 상당한 트래픽을 발생시킬 수 있다.
DRDoS 공격에 사용되는 반사체들은 NTP, DNS, Memcached, SNMP, SSDP, Chargen 등의 프로토콜을 사용하는 서버들이며 해당 프로토콜의 취약점 또는 미흡한 서버 보안설정을 악용하여 외부에서 해당 서버들을 반사체로 사용할 수 있었다.
- DDoS 공격을 방어하는 방법
기본적으로 허용 가능한 최대 대역폭을 설정하고, 그 설정값을 초과한 대역폭은 차단하는 방식을 사용한다. 특정 IP 대역, 특정 프로토콜, 특정 url, 특정 국가로부터 오는 패킷 또는 패킷 내 특정 데이터(시그니처)를 포함하고 있는 패킷을 차단하는 것도 가능하다.
- HTTP와 관련된 DoS
- Slow HTTP Header DoS (Slowloris)
- HTTP 헤더의 마지막에는 CR-LF(Carriage Return - Line Feed)이 두번 들어가는데, 해당 값을 제외하여 비정상적인 HTTP 패킷을 보내는 공격방식이다.
- 이러할 경우 서버는 HTTP Header의 전송을 계속해서 대기하게 되는데, 그만큼 다른 클라이언트에게 사용해야 할 서버의 자원이 악의적으로 점유된다.
- Slow HTTP POST DoS
- POST Method를 사용할 때, Content-Length에 표시된 크기만큼 패킷이 도착하지 않으면 서버는 계속해서 패킷을 기다린다.
- 이러한 특성을 악용하여 Content-Length의 크기를 변조하여 보낸 후 데이터를 조금씩 전송함으로써 전송이 완료될 때까지 서버의 자원을 악의적으로 점유하는 공격방식이다.
- Slow HTTP Read DoS
- 패킷의 Window Size 값을 0으로 설정하여 보낼 경우, 서버는 데이터를 전송하지 않지만 응답은 계속해서 유지한다.
- 이러한 특성을 이용하여 서버의 자원을 악의적으로 점유하는 공격 방식이다.
- HTTP GET Flooding
- 공격대상에게 지속적으로 GET 요청을 보내 공격대상의 서비스 자원을 악의적으로 점유하는 공격 방식이다.
- HTTP CC Attack (HTTP Get Flooding with Cache-Control)
- 대부분의 웹 서버들은 클라이언트가 보낸 요청에 대한 응답(웹 페이지)이 이미 클라이언트에게 캐시되어 있을 경우, 서버에서 데이터를 보내지 않고 캐시 데이터를 불러오는 식으로 서버 자원을 절약하는 기능이 있다.
- 이때, HTTP 헤더에서 Cache-Control 필드의 값을 ‘no-store, must-revalidate’로 지정 후 요청을 보내면 서버는 강제적&지속적으로 데이터를 보내게 되어 서버 자원을 소모하게 된다.
- 보통 HTTP Get Flooding과 함께 사용하여 공격효과를 증폭시키는 목적으로 사용되는 공격방식이다.
- 대응방안
- 비정상적으로 연결이 오래 지속될 경우 해당 연결을 강제 종료 (Timeout)
- Window Size가 0이거나, Content-Length의 크기가 비정상적으로 큰 경우 차단
- 일정 시간동안 특정 발신지로부터 과도한 요청이 올 경우 해당 요청들을 차단
1-6. Snort
- alert (로그 기록 & 경고 알림)
- log (로그 기록)
- pass (패킷 통과)
- drop (패킷 차단 & 로그 기록 O & 송신자에게 오류 메세지 전송 X)
- reject (패킷 차단 & 로그 기록 O & 송신자에게 오류 메시지 전송 O)
- sdrop (패킷 차단 & 로그 기록 X & 송신자에게 오류 메시지 전송 X)
- tcp (tcp 패킷을 대상으로 지정)
- udp (udp 패킷을 대상으로 지정)
- ip (ip 패킷을 대상으로 지정)
- icmp (icmp 패킷을 대상으로 지정)
- any (모든 프로토콜, 모든 네트워크 주소 또는 모든 포트 주소를 대상으로 지정)
- msg (이벤트 발생 메시지)
- offset (패킷 분석 시 확인하는 특정 바이트의 위치(주소))
- depth (offset을 기준으로 분석해야 하는 바이트의 길이)
- nocase (대소문자 구별 없음)
- rev (룰 수정 횟수)
- sid (해당 룰의 식별자)
2-1. 지원 직무(보안관제)에 대한 설명
관제 대상의 자산을 내/외부의 보안위협으로부터 보호하기 위해 지속적인 모니터링과 위험 발생 시 그에 따른 적절한 대응조치 및 분석을 하는 업무이다.
2-2. 지원 기업 설명 (비전, 핵심가치, 제품, 서비스 등)
이 부분은 기업에 따라 조금씩 다르므로 구체적으로 적지는 않겠다. 웬만한 정보는 해당 기업의 홈페이지를 통해 확인할 수 있으며, 관련 기사들을 살펴보는 것도 도움이 된다. 최소한, 지원한 기업이 현재 어떤 사업을 하고 있으며 향후 어떤 식으로 발전을 계획하고 있는지 살펴보는 것이 좋다.
2-3. 다른 기업의 보안장비 사용 경험
이 부분 또한 지원하는 기업에 따라 다를 수 있다. 되도록 지원하는 직무와 관련된 보안장비에 대한 답변을 하는 것이 바람직하다. 보안관제 직무라면 IDS, IPS, UTM, NAC, EDR, PMS, WAF, ESM, SIEM 등.. 다양한 장비가 있으니 있는대로 얘기를 하자.
3-1. 1분 자기소개
당연하지만, 미리 스크립트를 준비하고 연습을 하고 가는 것이 좋다. 기업에 따라서는 자기소개서에 없는 내용들로 1분 자기소개를 준비하라고 할 수도 있다. 지원하는 기업의 요구사항에 따라 적절한 내용을 준비해서 가도록 하자. 아래는 인싸담당자 님의 유튜브 영상을 참고한 1분 자기소개 스크립트 구성 방식이다.
- [저는 ~~한 사람입니다.] - 특징, 성격, 가치관, 주변의 평가, 장단점, 특이 경험, 성공 경험 등
- [나의 경험] - 경험 또는 공부한 지식. 1번의 근거.
- [진정성 강조하는 요약]
- [나의 포부]
3-2. 자기소개서 관련 질문 (프로젝트, 학점, 대외활동 등)
당연히 자신이 작성한 자기소개서의 내용은 다 기억하고 있어야 한다. 자기소개서의 내용을 기반으로 추가 질문이 들어올 수 있으므로, 예상 질문과 답변을 만들어 연습을 해두는 것도 좋다.
3-3. 하고 싶은 말 또는 질문
면접을 마무리하며 마지막으로 남길 말이다. 첫인상 못지 않게 끝인상 또한 중요하다는 걸 생각하면 이 부분 역시 소홀히 해서는 안된다. 특히 질문을 할 때는 직무와 관련된 질문을 하는 것이 적절하며, 면접관 입장에서 쉽게 답하기 어려운 질문은 삼가는 것이 좋다.