[정보보안기사] SECTION 33 웹 보안

늘 먹는 회덮밥. 사진 왜 이럼

1. 웹 보안 개요
   1. 웹 보안 위협
   2. 웹 트래픽 보안 방법
      • IPsec
        • 종단 사용자의 응용에 투명성을 제공하고, 범용 해결책 제시
        • 선별된 트래픽에 대해 IP 보안 처리
      • TCP 위에 보안 구현 — SSL, TLS — 선택적 암호화 적용 지원
2. SSL/TLS
   1. 개요
      1. 기본 개념
         • 클라이언트 서버 환경에서 TCP 기반의 애플리케이션에 대한 종단간 보안 서비스를 제공하기 위해 만들어진 전송 계층 보안 프로토콜
         • 가장 많이 이용되는 암호 통신 방법
         • 대칭키 암호, 공개키 암호, 일방향 해시함수, 메시지 인증 코드, 의사난수 생성기, 전자서명 조합
         • 암호 스위트를 변경하여 강력한 알고리즘 사용 가능
      2. 클라이언트와 서버
      3. SSL/TLS상의 HTTP
      4. SSL/TLS 보안 서비스
         • 기밀성 서비스 — DES, RC4 등의 대칭키 암호화 알고리즘을 사용하고, 비밀키는 Handshake Protocol을 통해 생성됨
         • 클라이언트와 서버 상호 인증 — RSA 등의 비대칭키 암호 알고리즘, DSS 등의 전사서명, X.509 공개키 인증서 사용
         • 메시지 무결성 서비스 — 메시지 인증 코드
      5. 암호 스위트(cipher suite)
         • 사용되고 있던 암호 기술에 결함 발견 시 교환 가능
         • 상호운영성으로 인해 자유롭게 선택 불가능
         • 추천 세트로 SSL/TLS가 규정되어 있음 → 암호 스위트
      6. SSL과 TLS의 차이
         • SSL
           • 1994년 Netscape
           • 2014년 3.0 사양에 푸들 공격이 가능한 취약점 발견
         • TLS
           • SSL 3.0을 기초로 IETF가 만든 프로토콜
           • 1.1 — AES 추가
           • 1.2 — CGM, CCM 사용 가능. HMAC-256 추가. IDEA와 DES 삭제. 의사 난수 함수에 SHA-256 이용
           • 1.3 — MD5, SHA-1, SHA-224, RC4, 3DES 등 제거. 0-RTT 모드 추가. ECDSA 추가
   2. TLS 프로토콜
      1. 개요 — TCP에 의존한느 프로토콜로 구현되는 일반 용도 서비스
      2. 구조
         • TCP 활용
         • 2계층에 걸친 프로토콜
         • Record 프로토콜 — 응용 계층으로부터 오는 데이터뿐만 아니라 TLS의 상위 프로토콜로부터 오는 메시지 전송
         • Handshake 프로토콜
           • Record 프로토콜에 대한 보안 매개변수 제공
           • 암호 집합을 설정하고 키와 보안 매개변수 제공
           • 필요하다면 클라이언트가 서버에 대해, 그리고 서버가 클라이언트에 대해 인증됨
         • ChangeCipherSpec 프로토콜 — 암호학적 비밀을 신속하게 보내는 데 사용
         • Alert 프로토콜 — 비정상 조건을 알리는 데 사용
         • Heartbeat 프로토콜 — 프로토콜 개체의 가용성을 모니터링할 때 사용
      3. Handshake 프로토콜
         • 개요
           • 서버와 클라이언트가 서로를 인증하고 암호화 MAC 알고리즘 그리고 TLS 레코드 안에 보낸 데이터를 보호하는 데 사용할 암호키 협상
           • 필드
             • Type — 1바이트
               • hello_request
               • client_hello — vsersion, random, session id, ciphersuite, compression method
               • server_hello — vsersion, random, session id, ciphersuite, compression method
               • certificate — 연속된 X.509v3 인증서
               • server_key_exchange — parameters, signature
               • certificate_request — type, authorities
               • server_hello_done
               • certificate_verify — signature
               • client_key_exchange — parameters, signature
               • finished — hash value
             • Length — 3바이트
             • Content — 메시지와 연관된 매개변수
           • 4단계
             1. 보안 기능 수집: 프로토콜 버전, 세션 ID, 암호 조합, 압축 방법, 초기 랜덤 넘버를 포함한다. + 키 교환, 메시지 인증을 위한 알고리즘
             2. 서버가 필요하다고 생각되면 인증서, 키 교환을 보내고, 인증서를 요청한다.
                • 서버는 클라이언트에 대해 인증됨
                • 클라이언트는 필요하다면 서버의 공개키를 알 수 있음
             3. 클라이언트는 요청된 인증서를 보내고, 키 교환을 한다. 클라이언트는 인증서에 대한 확인을 보낼 수도 있다.
                • 클라이언트는 서버에 대해 인증됨
                • 양측은 사전 마스터 비밀을(pre_master_secret) 알게 됨
             4. 암호 조합을 교환하고 핸드셰이크 프로토콜을 종료한다.
         • 단계별 세부 내용
           • HelloRequest
             • 서버가 언제든 보낼 수 있는 메시지
             • 협상 시작을 요구하는 메시지
             • 현재 협상이 진행 중이라면 클라이언트는 이 메시지 무시
             • 서버는 Handshake가 끝나지 않은 상태에서 다시 보내선 안 됨
           • ClientHello
             • 클라이언트는 서버에 처음으로 연결을 시작하거나 HelloRequest 메시지에 대한 응답으로 전송
             • 세션 식별자, Cipher Suite 리스트, 클라이언트가 지원하는 압축 알고리즘 리스트, 클라이언트 SSL 버전, 클라이언트가 생성한 난수를 서버에 전달
               • random
                 • replay 공격을 막기 위한 것
                 • master_secret으로부터 key_block을 생성할 때 입력값에 포함되어 각각의 연결마다 비밀키를 새롭게 생성할 수 있음
                 • session id — 클라이언트가 처음 세션을 생성할 때(full handshake)는 empty를 전송하고, 이미 생성된 세션이 상태를 재사용할 때(abbreviate handshake)는 재사용하고자 하는 세션 ID를 전송함
                 • cipher_suites
                   • 키 교환 알고리즘, 암호 알고리즘, MAC 알고리즘 포함
                   • 키 교환 및 인증 알고리즘, 암호 명세로 구성되어 있음
                   • SSL/TLS_{키 교환 및 인증 알고리즘}WITH{cipher_spec}
                   • 암호 명세(cipher_spec) — 대칭 암호 알고리즘, 암호키 길이, 블럭 암호 모드, HMAC용 해시 알고리즘 등으로 구성
           • ServerHello
             • 서버는 ClientHello 메시지에 대한 응답으로 전송
             • 실패 시 Handshake Failure Alert 메시지 전송
             • 세션 식별자, 선택한 CipherSuite, 선택한 압축 방법, 서버 SSL 버전, 서버가 생성한 난수 전달
           • ServerCertificate
             • 서버는 인증이 필요한 경우 ServerHello 뒤에 서버의 인증서가 포함된 Certificate를 전송해야 함
             • 인증서는 선택된 cipher suite의 키 교환 알고리즘에 맞는 유형
           • ServerKeyExchange — 서버의 인증서를 보내지 않았거나, 보낸 인증서에 키 교환에 필요한 정보가 부족할 때 전송되는 메시지
           • CertificateRequest — 서버는 자신을 인증함과 동시에 클라이언트의 인증서를 요구할 수 있음
           • ServerHelloDone
             • 서버가 보낼 메시지를 다 보냈음을 알리는 메시지
             • 클라이언트는 이 메시지가 도착할 때까지 대기
           • ClientCertificate — 서버가 클라이언트의 인증서를 요구할 경우 클라이언트가 보내는 메시지
           • ClientKeyExchange
             • 클라이언트는 세션키를 생성하기 위해 임의의 비밀 정보 48바이트 pre_master_secret을 생성함
             • 선택된 공개키 알고리즘을 통해 이를 서버와 공유
           • CertificateVerify — 클라이언트 인증서의 명백한 확인을 위해 클라이언트는 핸드셰이크 메시지를 전자서명하여 전송
           • ChangeCipherSpec, Finished
             • ChangeCipherSpecs 메시지는 핸드셰이크 프로토콜에 포함되는 것은 아니고, 이 메시지 이후에 전송되는 메시지는 새롭게 협상된 알고리즘과 키를 이용할 것임을 나타냄
             • Finished 메시지는 ChangeCipherSpec 메시지 이후에 전송되며, 협상된 알고리즘과 키가 처음으로 적용됨. 상대편에서 이 메시지를 통해 협상한 결과를 확인하게 됨
             • 서버는 두 메시지를 클라이언트에게 보내고, TLS 핸드셰이크 프로토콜 수행을 마침. 애플리케이션 데이터 전송 시작
      4. Record 프로토콜
         • 개요
           • 적용/변경된 보안 파라미터를 이용하여 실제 암호화/복호화, 무결성 보호, 압축/압축 해제 등의 기능을 제공하는 프로토콜
           • TCP 프로토콜 사용
           • TLS 연결을 위해 2가지 서비스 제공
             • 기밀성 — 핸드셰이크 프로토콜은 TLS 페이로드 관용 암호화하는 데 사용할 공유 비밀키를 정의함
             • 메시지 무결성 — 핸드셰이크 프로토콜은 MAC을 생성하는 데 사용할 공유 비밀키를 정의함
           • 전송할 응용 메시지를 블록으로 단편화
           • 옵션으로 데이터 압축, MAC 적용, 암호화, 헤더 추가 후 TCP 단편으로 전송
           • 수신된 데이터는 재조립하여 상위 계층 사용자에게 전달
      5. ChangeCipherSpec 프로토콜
         • 직전에 협상된 CipherSpec과 키에 의해 보호될 후속 레코드를 상대에게 알리기 위해 클라이언트 또는 서버에 의해 전송됨
         • 종단 간 협상된 보안 파라미터를 이후부터 적용/변경함을 알리기 위해 사용하는 프로토콜
         • 한 바이트로 구성. 값 1을 갖는 한 개의 메시지로 구성
      6. Alert 프로토콜
         • SSL/TLS 통신 과정에서 발생하는 오류를 통보하기 위해 경고할 때 사용
         • 2바이트
         • 첫 번쨰 바이트 — 경고 또는 심각
         • 두 번째 바이트 — 특정 경고를 나타내는 코드
      7. 하이트비트 프로토콜
         • 하트비트 — 정상 동작을 나타내기 위해 또는 시스템의 다른 부분과 동기화하기 위해 하드웨어나 소프트웨어가 생성하는 주기적 신호
         • 프로토콜 개체의 가용성을 모니터링할 때 사용하는 프로토콜
      8. SSL/TLS 공격
         • OpenSSL의 HeartBleed 취약점(2014년 4월)
           • 하트비트에서 클라이언트 요청 메시지를 처리할 때 데이터 길이 검증을 수행하지 않아 시스템 메모리에 저장된 64KB 크기의 데이터를 외부에서 아무런 제한 없이 탈취할 수 있는 취약점
           • 공격자가 메시지 길이 정보가 변조된 하트비트 요청 패킷을 취약한 OpenSSL 버전을 사용하는 서버에 전송할 경우, 정해진 버퍼 밖의 데이터를 공격자에게 전송하게 되어 시스템 메모리에 저장된 개인정보 및 인증 정보 등 탈취 가능
           • 노출 가능 정보 — SSL 서버 비밀키, 세션키, 쿠키 및 개인정보 등
           • 노출 정보는 서비스 환경에 따라 다름
           • 대응책
             • OpenSSL 갱신
             • 하트비트 확장을 사용하지 않는 옵션을 부착하여 재컴파일
             • 인증서 재발급 검토
             • 취약점 조치 후 비밀번호 재설정 유도
         • SSL 3.0 취약점과 POODLE 공격(2014년 10월)
           • 특정 조건에서 공격자가 TLS를 SSL 3.0으로 다운그레이드한 통신 강요 가능
           • SSL 3.0을 강제한 후 MITM 공격을 통해 암호화되어 송수신되는 쿠키 정보나 데이터를 추출하는 공격 가능
           • CBC 모드를 사용하는 경우 발생하는 패딩된 암호 블록이 MAC에 의해 보호되지 않는 취약점 이용
           • SSL 3.0 쓰지 말자
         • FREAK 공격과 암호 수출 규제(2015년 2월)
           • INRIA 및 MS 사에서 SSL을 통해 강제로 취약한 RSA로 다운그레이드시킬 수 있는 취약점 발견
           • SSL/TLS 서버에 대한 RSA Export Suites라고 불리는 약한 암호 스위트를 사용하게 하는 공격
           • MITM 공격을 통해 512비트 RSA로 다운그레이드시켜 정보 유출
           • 대응책
             • OpenSSL 업그레이드
             • OS 및 브라우저 업그레이드
         • 완전 순방향 비밀성(PFS)
           • SSL/TLS 통신의 서버 개인키 노출 시 문제점
             • 서버 공개키와 개인키를 이용하여 키 교환을 수행할 경우(RSA 방식) 공격자는 중간자 공격(MITM)을 통해 트래픽을 가로채고 서버 개인키를 이용하여 세션키/비밀키 및 송수신 데이터를 복호화할 수 있음
             • 서버 인증서를 폐기하더라도 유출된 서버 개인키로 보호되는 이전 트래픽 정보를 공격자가 보관한다면 이들 모두 복호화됨
             • 이를 해결하기 위해 PFS
           • PFS — 서버 개인키가 노출돼도 이전 트래픽 정보의 기밀성은 유지되는 암호학적 성질
   3. HTTPS와 S-HTTP
      1. HTTPS
         • 웹 서버 간 안전 통신 구현
         • 기밀성 및 클라이언트와 서버의 인증, 데이터 무결성 제공
         • 암호화되는 통신 요소
           • 요청 문서 URL
           • 문서 내용
           • 브라우저 양식 내용
           • 브라우저가 서버에게 보낸 쿠키와 서버가 브라우저로 보낸 쿠키
           • HTTP 헤더 내용
         • 사용자 입력값 검증 불가능
      2. S-HTTP
         • 개요 — 1994년 EIT에 의해 정의된 프로토콜
         • 원리
           • 일반 HTTP 메시지는 요구되는 보안 기능 정도에 따라 암호화되거나 서명되어 S-HTTP 메시지 내로 캡슐화됨
           • 메시지의 형식과 부호화 방식 등을 표시하는 S-HTTP 헤더와 함께 전달
           • 메시지가 암호화 및 서명되어 기존 TCP/IP 망을 통해 전송
           • 두 컴퓨터 사이의 통신 채널과 메시지 모두 보호
         • 동작
           • 다양한 암호 기능 지원
           • 협상 과정을 통해 다양한 암호 알고리즘, 모드, 매개 변수 등 설정 가능
           • 새 프로토콜 지시자로 shttp 사용. shttp://
3. 웹 서버 보안
   1. IIS 보안 설정
      1. 권한 설정
      2. 관리자 페이지 접근 통제
         • 관리자 페이지가 추측 가능한 형태로 구성되어있을 경우 쉽게 접근 가능
         • 무작위 대입 공격을 통해 권한 획득 가능
         • 웹 서버/페이지에 접근하는 사용자를 IP 주소 등을 통해 통제
      3. 메소드 제한
      4. 헤더 정보 숨김 — 서버명, 버전 등
   2. Apache 보안 설정
      1. 서버 실행 계정 확인
      2. httpd.conf 파일
         • ServerType(standalone)
           • 서버를 standalone 모드 혹은 inetd 모드로 운영할지 결정. 웹은 일반적으로 standalone
           • standalone — 사용자 요청을 직접 웹 데몬이 받아서 처리하는 방식
           • inetd — 사용자 요청을 inetd 데몬이 받아서 처리하는 방식
         • Timeout(300)
         • KeepAlive(On) — 요청 연결에 대해 한 번만 처리하는 것이 아니라 또 다른 요청 대기
         • MaxKeepAliveRequests(100) — KeepAlive 상태에서 처리할 최대 요청 처리 건수
         • KeepAliveTimeout(15)
         • MinSpareServers(5) — 아파치가 실행될 때 최소 예비 프로세스 수 설정. 보통 8
         • MaxSpareServers(10) — 보통 20
         • MaxClients(150) — 최대 256. 최대치를 수정하기 위해 HARD_SERVER_LIMIT 부분 수정하고 아파치 재컴파일
         • MaxRequestsPerChild(0) — 자식 프로세스가 처리할 수 있는 최대 요청 처리 건수. 0은 무제한
         • User(nobody) — 자식 프로세스가 생성될 때 그 프로세스의 소유자와 소유 그룹 결정
         • Port(80)
         • ServerAdmin(root@localhost)
         • ServerName(xxx.co.kr) — 작동 중인 서버 이름. 기본은 주석 처리
         • DocumentRoot(”/usr/local/apache/htdocs”) — 아파치 웹 문서들이 존재하는 위치 저장
         • Options
           • 지정한 디렉터리 이하에 모든 파일과 디렉터리에 적용할 접근 제어 설정
           • Indexes — 디렉터리 내의 파일 목록 리스트를 웹 브라우저로 제시. 서버 보안을 위해 사용하지 않는 것이 좋음(Options -Indexes)
           • FollowSymlinks — 심볼릭 링크 허용. 웹 브라우저에서 링크 파일의 경로까지 확인 가능
         • ErrorLog(/usr/local/apache/logs/error_log)
         • LogLevel(warn) — 에러 로그 내용의 레벌 설정
         • ServerSignature(On) — 서버 배너 정보를 나타냄
         • ServerTokens(ProductOnly)
           • 서버의 정보 표시 제한 설정
           • ProductOnly — 웹 서버 종류만 표시
           • Minimal — 웹 서버 종류와 버전 정보 표시
           • OS — 웹 서버 종류와 버전, 운영체제 정보 표시
           • Full — 웹 서버 종류와 버전, 운영체제, 설치된 모듈 정보 표시
      3. 검색엔진 정보 노출 취약점
         • 개요 — 검색엔진에 의해 웹사이트 해킹에 필요한 정보가 검색되는 취약점
         • robots.txt 설정 방법 — 웹사이트 취상위 주소에 저장
4. 웹 보안 위협 및 대응책
   1. 주요 웹 보안 위협 및 대응책
      1. SQL Injection
         • 개요
         • 취약잠 판단 방법 — 검색어 필드 및 로그인 필드에 큰따옴표, 작은따옴표, 세미콜론을 입력하여 DB 에러 발생 여부 확인
         • 공격 종류
           • Form SQL Injection
             • HTML Form 기반 인증을 담당하는 애플리케이션의 취약점이 있는 경우, 사용자 인증을 위한 쿼리문의 조건을 임의로 조작하여 인증을 우회하는 기법
             • where절이 항상 참이 되도록
           • Union SQL Injection
           • Error-Based SQL Injection
             • DB 쿼리에 대한 에러값을 기반으로 한 단계씩 점진적으로 정보 획득
             • 특수문자를 삽입하여 SQL 에러가 발생한다면 취약점이 있다고 판단
           • Blind SQL Injection
             • 쿼리 결과의 참과 거짓을 통해 SQL문을 실행함으로써 DB 공격
             • 오류 메시지를 자세히 반환하지 않게 설정했다면 Error-Based SQL Injection은 피할 수 있지만 Blind SQL Injection에 취약
         • 대응 방법
           • 모든 입력값에 대해 적절한 검증 절차 설계
           • SQL 서버의 에러 메시지 미표기
           • 애플리케이션이 사용하는 DB 연결 계정은 해당 애플리케이션이 사용하는 데이터에 대한 읽기, 쓰기, 삭제, 업데이트 권한만 설정
           • 동적 SQL 완성 방식을 지양하고 저장 프로시저 사용
           • 선처리 질의문
      2. XSS
         • 개요
         • 공격 종류
           • Stored XSS — 게시판 또는 자료실과 같이 사용자가 글을 저장할 수 있는 부분에 스크립트 코드 입력
           • Reflected XSS — 스크립트 코드가 삽입된 URL 클릭 시 코드가 HTML 문서에 포함된 채로 응답되어 스크립트 서버 사이트에서 실행
           • DOM based XSS
             • DOM — HTML 및 XML 문서에 접근 방법을 표준으로 정의하는 문서 객체 모델. HTML 문서를 계층적으로 보면서 콘텐츠를 동적으로 변경 가능
             • 피해자 브라우저가 HTML 페이지를 구문 분석할 때마다 공격 스크립트가 DOM 생성의 일부로 실행되면서 공격. 페이지에 포함되어 있는 브라우저측 코드가 DOM 환경에서 악성코드로 실행
         • 보안 대책
           • 문자 변환
           • 서버에서 사용자 입력값 검증
           • HTML 태그 허용 시 화이트 리스트 선정
         • 코드 예제
      3. 사이트 간 요청 위조(CSRF)
         • 개요
           • 공격자가 의도한 행위를 인증된 사용자의 권한을 통해 실행
           • 사용자가 악성 스크립트를 서버에 요청
           • On-site 요청 변조 — 한 사이트 내에서 요청 변조가 발생하는 취약점
         • 공격 과정
         • 보안 대책
           • 요청 검증
           • CSRF 토큰 사용 — 세션별로 CSRF 토큰을 생성하여 세션에 저장
           • 사용자와 상호 처리 기능 적용
             • CSRF 토큰 방식도 XSS를 통해 무력화 가능
             • CAPTCHA 등의 사용자와 상호 처리 가능한 기법 적용
           • 재인증 요구
         • 코드 예제 — POST 방식 사용
      4. 서버 사이드 요청 위조(SSRF)
         • 개요
           • 공격자가 조작된 요청을 웹 서버에 전송하여 웹 서버가 내부 네트워크에 있는 다른 서버에 악의적인 요청을 보내는 취약점
           • 보안 장비를 우회하여 내부 스캔, 정보 탈취 등 가능
         • 보안 대책
           • 사용자의 입력값을 다른 시스템의 서비스 호출에 사용하는 경우, 사용자의 입력값을 화이트리스트 방식으로 필터링
           • 무작위 입력값 사용 시 블랙리스트 필터링
           • 동일한 내부 네트워크에 있는 서버 간이라도 기기 인증, 서비스 접근 권한 등을 확인하여 요청
      5. 직접 객체 참조
         • 개요
           • 파일, 디렉터리, DB 키와 같이 내부적으로 구현된 객체에 대한 참조가 노출될 때 발생
           • 데이터에 접근하기 위해 노출된 참조 조작 가능
         • 디렉터리 탐색 공격(파일 다운로드 취약점)
           • 파일 다운로드 취약점 — 외부 입력값에 대해 경로 조작에 사용될 수 있는 문자를 필터링하지 않으면, 예상 밖의 접근 제한 영역에 대한 경로 문자열 구성이 가능해져 시스템 정보 누출, 서비스 장애 등을 유발할 수 있는 취약점
           • 디렉터리 탐색 — 웹 브라우저에서 확인 가능한 경로의 상위로 탐색하여 특정 시스템 파일을 다운로드하는 공격 방법
         • 파일 업로드 제한 부재
         • 리버스 텔넷(리버스 셸) — 아웃바운드 정책 허점
         • 보안 대책
           • 업로드되어 저장되는 파일 타입, 크기, 개수, 실행 권한 제한
           • 업로드되어 저장되는 파일은 외부에서 식별되지 않아야 함
           • 파일 다운로드 요청 시, 요청 파일에 대한 검증 작업 수행
           • 다운로드받은 소스코드나 실행 파일은 무결성 검사 실행
      6. 보안 설정 취약점
         • 디렉터리 리스팅 — 설정 옵션 Indexes
         • 백업 및 임시 파일 존재 — login.asp.bak 등
         • 주석 관리 미흡
   2. 웹의 취약점 보완
      1. 특수문자 필터링
      2. 서버측 통제 적용 — ASP, JSP 등의 SSS로 필터링 수행
      3. 지속적인 세션 관리
   3. 웹 방화벽(WAF)
      1. 개요
         • 웹 애플리케이션 대상으로 시도되는 해킹을 차단하는 보안 장비
         • 웹 공격을 탐지하고 차단. 정보 유출 방지, 부정 로그인 방지, 웹사이트 웨변조 방지 등
      2. 웹 방화벽 기능 및 비교
         • 기능
           • 사용자 요청 검사 — 접근제어, 과다 요청 제어, 업로드 파일 및 요청 형식 검사, SQL Injection 및 XSS 등 차단
           • 콘텐츠 보호 — 주요 고객 정보 유출 차단, 웹 변조 방지, 코드 노출 진단
           • 위장 — URL 정보 위장, 서버 정보 위장
         • 기존 방화벽과의 비교
5. 소프트웨어 개발 보안
   1. 개요
      1. SW 개발 생명 주기(SDLC)
         • 정의
           • 소프트웨어의 생성에서 소멸까지의 과정을 단계별로 나눈 것으로 각 단계별 주요 활동과 산출물을 통해 프로젝트의 진행 방향을 명확하게 파악하고 관리를 용이하게 함
           • 정의 단계, 개발 단계, 유지보수 단계
         • 단계별 활동
           • 정의 단계
             • 무엇을 처리하는 소프트웨어을 개발할 것인지 정의
             • 타당성 검토 단계, 개발 계획 단계, 요구사항 분석 단계
           • 개발 단계
             • 어떻게에 초점을 두고 실제로 소프트웨어를 개발하는 단계
             • 설계 단계, 구현 단계, 테스트 단계
           • 유지보수 단계 — 운영하며 변경에 초점을 두고 환경 변화에 따라 소프트웨어를 적응 및 유지시키는 단계
      2. 주요 소프트웨어 개발 생명 주기 모델
         • 폭포수 모델 — 순차적으로 소프트웨어를 개발하는 전형적인 개발 모델. 전 과정을 나누어 체계적이고 순차적으로 접근
         • 프로토타입 모델 — 점진적으로 시스템을 개발해나가는 접근 방식. 원형을 만들어 평가 후, 요구사항 정제
         • 나선형 모델 — 위 둘의 장점을 수용하고 위험 분석을 추가한 점증적 개발 모델. 위험 관리 및 최소화
      3. 소프트웨어 개발 보안 방법론
         • 신뢰성이 위협받는 상황에서도 시스템을 신뢰할 수 있는 상태로 유지할 수 있도록 만들어진 SW
         • 요구사항 분석
           • 요구사항 중 보안 항목 식별
           • 요구사항 명세서
         • 설계
           • 위협원 도출을 위한 위협 모델링
           • 보안 설계 검토 및 보안 설계서 작성
           • 보안 통제 수립
         • 구현
           • 표준 코딩 정의서 및 SW 개발 보안 가이드를 준수하여 개발
           • 소스코드 보안 약점 진단 및 개선
         • 테스트
           • 모의침투 테스트 또는 동적 분석을 통한 보안 취약점 진단 및 개선
         • 유지보수
           • 지속적인 개선
           • 보안 패치
      4. 소프트웨어 보안 약점 유형
         • 입력 데이터 검증 및 표현
         • 보안 기능
         • 시간 및 상태 — 하나 이상의 프로세스가 동작하는 환경에서 시간 및 상태를 부적절하게 관리하여 발생할 수 있는 보안 약점
         • 에러 처리
         • 코드 오류
         • 캡슐화
         • API 오용

• DLL 인젝션 — 다른 프로세스의 주소 공간 내에서 DLL을 강제로 로드시켜 코드 실행