드라이버에 대한 위협 모델링

드라이버 작성자와 설계자는 위협 모델링을 모든 드라이버에 대한 디자인 프로세스의 필수적인 부분으로 만들어야 합니다. 이 항목에서는 Windows 드라이버에 대한 위협 모델을 만들기 위한 지침을 제공합니다.

보안은 모든 드라이버의 기본 디자인 포인트여야 합니다. 모든 성공적인 제품이 대상입니다. Windows용 드라이버를 작성하는 경우 언젠가 누군가가 드라이버를 사용하여 시스템 보안을 손상시키려고 한다고 가정해야 합니다.

보안 드라이버 설계에는 다음이 포함됩니다.

• 드라이버가 공격에 취약할 수 있는 지점을 식별합니다.
• 이러한 각 지점에서 탑재할 수 있는 공격 유형을 분석합니다.
• 드라이버가 이러한 공격을 저지하는 방식으로 설계되도록 합니다.

위협 모델링은 이러한 중요한 디자인 작업에 대한 구조화된 접근 방식입니다. 위협 모델은 자산에 대한 위협을 분류하고 분석하는 방법입니다. 드라이버 작성기의 관점에서 자산은 컴퓨터 또는 네트워크의 하드웨어, 소프트웨어 및 데이터입니다.

위협 모델은 다음 질문에 답변합니다.

• 보호가 필요한 자산은 무엇입니까?
• 자산이 취약한 위협은 무엇인가요?
• 각 위협은 얼마나 중요하거나 가능성이 있나요?
• 위협을 완화하려면 어떻게 할까요?

위협 모델링은 사후 고려 사항이 아닌 보안이 제품에 기본 제공되도록 하기 때문에 소프트웨어 디자인의 중요한 부분입니다. 좋은 위협 모델은 디자인 프로세스 중에 버그를 찾고 방지하는 데 도움이 될 수 있으므로 나중에 비용이 많이 드는 패치와 organization 대한 잠재적인 평판 손상을 제거할 수 있습니다.

이 섹션에서는 드라이버 디자인에 위협 모델링 원칙을 적용하고 드라이버가 취약할 수 있는 위협의 예를 제공합니다. 소프트웨어 디자인에 대한 위협 모델링에 대한 자세한 설명은 이러한 리소스를 참조하세요.

• Microsoft SDL 웹 사이트:

  https://www.microsoft.com/sdl

• Microsoft SDL의 간소화된 구현:

  백서 다운로드

• 이 블로그 항목에서는 마이클 하워드와 스티브 리너가 제공하는 보안 개발 수명 주기: SDL의 무료 복사본을 다운로드하는 방법을 설명합니다.

  https://blogs.msdn.microsoft.com/microsoft_press/2016/04/19/free-ebook-the-security-development-lifecycle/

드라이버에 대한 위협 모델 만들기

위협 모델을 만들려면 드라이버의 디자인, 드라이버가 노출될 수 있는 위협 유형 및 특정 위협을 악용하는 보안 공격의 결과를 철저히 이해해야 합니다. 드라이버에 대한 위협 모델을 만든 후 잠재적 위협을 완화하는 방법을 결정할 수 있습니다.

위협 모델링은 코딩하는 동안 우연히 수행되는 것이 아니라 드라이버 디자인 중에 구성되고 구조화된 방식으로 수행될 때 가장 효과적입니다. 구조화된 접근 방식을 사용하면 디자인에서 취약성을 발견할 가능성이 높아집니다. 따라서 모델이 포괄적인지 확인하는 데 도움이 됩니다.

위협 모델링 작업을 구성하는 한 가지 방법은 다음 단계를 수행하는 것입니다.

1. 드라이버를 통한 데이터 흐름을 보여 주는 구조화된 다이어그램을 만듭니다. 드라이버가 수행하는 모든 가능한 작업과 드라이버의 모든 입력 및 출력의 원본 및 대상을 포함합니다. 공식 데이터 흐름 다이어그램 또는 이와 유사한 구조화된 다이어그램을 사용하면 드라이버를 통해 데이터 경로를 분석하고 드라이버의 외부 인터페이스, 경계 및 상호 작용을 식별하는 데 도움이 될 수 있습니다.
2. 데이터 흐름 다이어그램을 기반으로 잠재적인 보안 위협을 분석합니다.
3. 이전 단계에서 식별한 위협을 평가하고 이를 완화하는 방법을 결정합니다.

데이터 흐름 다이어그램 만들기

데이터 흐름 다이어그램은 드라이버와 드라이버가 상호 작용하는 외부 엔터티(일반적으로 운영 체제, 사용자 프로세스 및 디바이스) 간의 데이터 흐름을 개념적으로 보여줍니다. 공식 데이터 흐름 다이어그램은 다음 기호를 사용합니다.

다음 그림에서는 가상 커널 모드 WDM(Windows 드라이버 모델) 드라이버에 대한 샘플 데이터 흐름 다이어그램을 보여 줍니다. 특정 유형의 드라이버에 대한 아키텍처에 관계없이 개념적 모델은 동일합니다. 모든 데이터 경로를 표시하고 드라이버를 입력하거나 종료하는 데이터의 각 원본을 식별합니다.

참고 이전 그림에서는 사용자 프로세스와 드라이버 간에 직접 흐르는 데이터를 보여 줍니다. 중간 드라이버는 생략합니다. 그러나 실제로 모든 요청은 I/O 관리자를 통과하고 특정 드라이버에 도달하기 전에 하나 이상의 상위 수준 드라이버를 트래버스할 수 있습니다. 이 그림은 데이터의 원래 원본의 중요성과 데이터를 제공한 스레드의 컨텍스트를 강조하기 위해 이러한 중간 단계를 생략합니다. 커널 모드 드라이버는 사용자 모드에서 시작되는 데이터의 유효성을 검사해야 합니다.

운영 체제의 요청, 사용자 프로세스의 요청 또는 디바이스의 요청(일반적으로 중단)으로 인해 정보가 드라이버에 입력됩니다.

이전 그림의 드라이버는 여러 유형의 요청으로 운영 체제에서 데이터를 받습니다.

• DriverEntry, DriverUnload 및 AddDevice 루틴에 대한 호출을 통해 드라이버 및 해당 디바이스에 대한 관리 작업을 수행하는 요청
• 플러그 앤 플레이 요청(IRP_MJ_PNP)
• 전원 관리 요청(IRP_MJ_POWER)
• 내부 디바이스 I/O 제어 요청(IRP_MJ_INTERNAL_DEVICE_CONTROL)

이러한 요청에 대한 응답으로 데이터는 상태 정보로 드라이버에서 운영 체제로 다시 흐릅니다. 그림의 드라이버는 다음과 같은 유형의 요청으로 사용자 프로세스에서 데이터를 받습니다.

• 요청 만들기, 읽기 및 쓰기(IRP_MJ_CREATE, IRP_MJ_READ 또는 IRP_MJ_WRITE)
• 공용 디바이스 I/O 제어 요청(IRP_MJ_DEVICE_ CONTROL)

이러한 요청에 대한 응답으로 출력 데이터 및 상태 정보는 드라이버에서 사용자 프로세스로 다시 흐릅니다.

마지막으로, 디바이스 I/O 작업 또는 디바이스 상태 변경하는 사용자 작업(예: CD 드라이브에서 트레이 열기)으로 인해 드라이버가 디바이스에서 데이터를 받습니다. 마찬가지로 I/O 작업 중 드라이버의 데이터가 디바이스로 흐르고 디바이스 상태 변경됩니다.

이전 그림은 광범위한 개념 수준에서 드라이버 데이터 흐름을 보여줍니다. 각 원은 비교적 큰 작업을 나타내며 세부 정보가 부족합니다. 경우에 따라 샘플과 같은 한 수준 다이어그램은 데이터 원본 및 경로를 이해하는 데 적합합니다. 드라이버가 다양한 원본에서 다양한 유형의 I/O 요청을 처리하는 경우 더 자세한 내용을 표시하는 하나 이상의 추가 다이어그램을 만들어야 할 수 있습니다. 예를 들어 "I/O 요청 처리"라는 레이블이 지정된 원은 다음 그림과 유사한 별도의 다이어그램으로 확장될 수 있습니다.

두 번째 다이어그램은 첫 번째 다이어그램의 각 I/O 요청 유형에 대한 별도의 작업을 보여 줍니다. (간단히 하기 위해 디바이스에 대한 데이터 경로는 생략되었습니다.)

외부 엔터티와 다이어그램에 표시된 입력 및 출력 유형은 디바이스 유형에 따라 달라질 수 있습니다. 예를 들어 Windows는 많은 일반적인 디바이스 유형에 대한 클래스 드라이버를 제공합니다. 시스템 제공 클래스 드라이버는 일반적으로 콜백 루틴 집합을 포함하는 DLL(동적 링크 라이브러리)인 공급업체에서 제공하는 미니드라이버에서 작동합니다. 사용자 I/O 요청은 클래스 드라이버로 이동한 다음 미니드라이버의 루틴을 호출하여 특정 작업을 수행합니다. 미니 드라이버는 일반적으로 전체 I/O 요청 패킷을 입력으로 수신하지 않습니다. 대신 각 콜백 루틴은 특정 작업에 필요한 데이터만 받습니다.

데이터 흐름 다이어그램을 만들 때 드라이버 요청에 대한 다양한 원본을 기억합니다. 사용자의 컴퓨터에서 실행되는 모든 코드는 Microsoft Office와 같은 잘 알려진 응용 프로그램에서부터 잠재적으로 모호한 원본의 프리웨어, 공유웨어 및 웹 다운로드에 이르기까지 드라이버에 대한 I/O 요청을 생성할 수 있습니다. 특정 디바이스에 따라 회사에서 디바이스를 지원하기 위해 제공하는 미디어 코덱 또는 타사 필터를 고려해야 할 수도 있습니다. 가능한 데이터 원본은 다음과 같습니다.

• 드라이버가 처리하는 IRP_MJ_XXX 요청
• 드라이버가 정의하거나 처리하는 IOCTL
• 드라이버가 호출하는 API
• 콜백 루틴
• 드라이버가 노출하는 다른 모든 인터페이스
• 설치 중에 사용되는 파일을 포함하여 드라이버가 읽거나 쓰는 파일
• 드라이버가 읽거나 쓰는 레지스트리 키
• 구성 속성 페이지 및 드라이버에서 사용하는 사용자가 제공한 기타 정보

모델은 드라이버 설치 및 업데이트 절차도 다루어야 합니다. 드라이버 설치 중에 읽거나 쓰는 모든 파일, 디렉터리 및 레지스트리 항목을 포함합니다. 디바이스 설치 관리자, 공동 설치 관리자 및 속성 페이지에 노출되는 인터페이스도 고려합니다.

드라이버가 외부 엔터티와 데이터를 교환하는 지점은 공격에 취약할 수 있습니다.

잠재적 위협 분석

드라이버가 취약할 수 있는 지점을 식별한 후 각 지점에서 발생할 수 있는 위협 유형을 확인할 수 있습니다. 다음 유형의 질문을 고려합니다.

• 각 리소스를 보호하기 위한 보안 메커니즘은 무엇인가요?
• 모든 전환 및 인터페이스가 제대로 보호되나요?
• 기능을 부적절하게 사용하면 의도치 않게 보안을 손상시킬 수 있나요?
• 기능의 악의적인 사용이 보안을 손상시킬 수 있나요?
• 기본 설정이 적절한 보안을 제공합니까?

위협 분류에 대한 STRIDE 접근 방식

약어 STRIDE는 소프트웨어에 대한 6가지 위협 범주를 설명합니다. 이 머리글자어는 다음에서 파생됩니다.

• S푸핑
• 앰퍼링
• R사용법
• Information disclosure
• 서비스의 Denial
• E권한 부여

STRIDE를 가이드로 사용하여 드라이버를 대상으로 할 수 있는 공격 종류에 대한 자세한 질문을 제기할 수 있습니다. 목표는 드라이버의 각 취약한 지점에서 가능한 공격 유형을 확인한 다음, 가능한 각 공격에 대한 시나리오를 만드는 것입니다.

• 스푸핑 은 다른 사람의 자격 증명을 사용하여 액세스할 수 없는 자산에 액세스하는 것입니다. 프로세스는 위조되거나 도난당한 자격 증명을 전달하여 스푸핑 공격을 탑재합니다.

• 변조 는 공격을 탑재하기 위해 데이터를 변경하고 있습니다. 예를 들어 필요한 드라이버 파일이 드라이버 서명 및 ACL(액세스 제어 목록)에 의해 적절하게 보호되지 않는 경우 드라이버가 변조에 취약할 수 있습니다. 이 경우 악의적인 사용자가 파일을 변경하여 시스템 보안을 위반할 수 있습니다.

• 거부 는 사용자가 작업 수행을 거부하지만 작업의 대상이 달리 증명할 방법이 없는 경우에 발생합니다. 보안이 손상될 수 있는 작업을 기록하지 않는 경우 드라이버는 거부 위협에 취약할 수 있습니다. 예를 들어 비디오 디바이스의 드라이버는 포커스, 스캔 영역, 이미지 캡처 빈도, 캡처된 이미지의 대상 위치 등과 같은 디바이스의 특성을 변경하라는 요청을 기록하지 않는 경우 거부에 취약할 수 있습니다. 결과 이미지가 손상될 수 있지만 시스템 관리자는 문제를 일으킨 사용자를 확인할 방법이 없습니다.

• 정보 공개 위협은 이름에서 알 수 있는 것과 정확히 같습니다. 볼 수 있는 권한이 없는 사용자에게 정보를 공개하는 것입니다. 사용자 버퍼에서 정보를 전달하는 모든 드라이버는 정보 공개 위협에 취약합니다. 정보 공개 위협을 방지하려면 드라이버는 데이터를 쓰기 전에 각 사용자 버퍼의 길이를 확인하고 버퍼를 0으로 초기화해야 합니다.

• 서비스 거부 공격은 유효한 사용자가 리소스에 액세스하는 기능을 위협합니다. 리소스는 디스크 공간, 네트워크 연결 또는 물리적 디바이스일 수 있습니다. 성능을 허용할 수 없는 수준으로 저하시키는 공격도 서비스 거부 공격으로 간주됩니다. 사용자 프로세스가 시스템 리소스를 독점할 수 있도록 허용하는 드라이버는 리소스 사용으로 인해 다른 유효한 사용자가 작업을 수행하는 데 방해가 되는 경우 서비스 거부 공격에 취약할 수 있습니다.

  예를 들어 드라이버는 세마포를 사용하여 IRQL = PASSIVE_LEVEL 실행하는 동안 데이터 구조를 보호할 수 있습니다. 그러나 드라이버는 KeEnterCriticalRegion/KeLeaveCriticalRegion 쌍 내에서 세마포를 획득하고 해제해야 합니다. 이 쌍은 APC(비동기 프로시저 호출)를 사용하지 않도록 설정하고 다시 활성화합니다. 드라이버가 이러한 루틴을 사용하지 못하는 경우 APC로 인해 운영 체제가 세마포를 보유하는 스레드를 일시 중단할 수 있습니다. 따라서 다른 프로세스(관리자가 만든 프로세스 포함)는 구조에 대한 액세스 권한을 얻을 수 없습니다.

• 권한 상승 공격은 권한이 없는 사용자가 권한 있는 상태 얻을 경우 발생할 수 있습니다. ZwXxx 루틴은 보안 검사를 무시하므로 사용자 모드 핸들을 ZwXxx 루틴에 전달하는 커널 모드 드라이버는 권한 상승 공격에 취약합니다. 커널 모드 드라이버는 사용자 모드 호출자로부터 수신하는 모든 핸들의 유효성을 검사해야 합니다.

  커널 모드 드라이버가 IRP 헤더의 RequestorMode 값을 사용하여 I/O 요청이 커널 모드 또는 사용자 모드 호출자에서 오는지 여부를 확인하는 경우에도 권한 상승 공격이 발생할 수 있습니다. 네트워크 또는 서버 서비스(SRVSVC)에서 도착하는 IRP에서 RequestorMode 값은 요청의 원본에 관계없이 KernelMode입니다. 이러한 공격을 방지하려면 드라이버는 단순히 RequestorMode 값을 사용하는 대신 이러한 요청에 대한 액세스 제어 검사를 수행해야 합니다.

드라이버 분석 기술

분석을 구성하는 간단한 방법은 잠재적인 위협과 함께 취약한 영역을 나열하고 각 위협 유형에 대해 하나 이상의 시나리오를 나열하는 것입니다.

철저한 분석을 수행하려면 드라이버의 잠재적으로 취약한 모든 지점에서 위협 가능성을 탐색해야 합니다. 각 취약한 지점에서 가능할 수 있는 위협의 각 범주(스푸핑, 변조, 부인, 정보 공개, 서비스 거부 및 권한 상승)를 결정합니다. 그런 다음 각 그럴듯한 위협에 대해 하나 이상의 공격 시나리오를 만듭니다.

예를 들어 앞의 그림과 같이 IRP_MJ_DEVICE_CONTROL 요청에 대한 데이터 흐름을 고려합니다. 다음 표에서는 이러한 요청을 처리할 때 드라이버에서 발생할 수 있는 두 가지 유형의 위협을 보여 줍니다.

취약한 지점	잠재적 위협(STRIDE)	시나리오
IRP_MJ_DEVICE_CONTROL 요청	서비스 거부 권한 상승	사용자 프로세스는 디바이스가 실패하도록 하는 일련의 IOCTL을 실행합니다. 사용자 프로세스는 FILE_ANY_ACCESS 허용하는 IOCTL을 발급합니다.

한 위협은 종종 다른 위협과 관련이 있습니다. 예를 들어 권한 상승 위협을 악용하는 공격으로 인해 정보 공개 또는 서비스 거부가 발생할 수 있습니다. 또한 일부 유형의 공격은 일련의 이벤트에 따라 달라집니다. 악의적인 사용자는 권한 상승 위협을 악용하여 시작할 수 있습니다. 그런 다음, 상승된 권한과 함께 제공되는 추가 기능을 통해 사용자는 추가 취약성을 찾아서 악용할 수 있습니다.

위협 트리 및 개요는 이러한 복잡한 시나리오를 모델링하는 데 유용할 수 있습니다.

위협 트리는 위협 또는 취약성의 계층 구조를 보여 주는 다이어그램입니다. 기본적으로 위협 트리는 공격을 탑재하는 악의적인 사용자의 단계를 모방합니다. 공격의 궁극적인 목표는 트리의 맨 위에 있습니다. 각 하위 수준에는 공격을 수행하는 데 필요한 단계가 표시됩니다. 다음 그림은 이전 예제의 서비스 거부 시나리오에 대한 간단한 위협 트리입니다.

위협 트리에는 특정 공격을 탑재하는 데 필요한 단계와 단계 간의 관계가 표시됩니다. 개요는 위협 트리의 대안입니다.

개요는 단순히 특정 위협을 공격하는 단계를 계층적 순서로 나열합니다. 예를 들면 다음과 같습니다.

1.0 디바이스의 응답이 중지되도록 합니다.

1.1 오류 시퀀스에서 IOCTLS를 발급합니다.

1.1.1 디바이스가 실패하게 만드는 시퀀스를 결정합니다.

1.1.2 내부 IOCTL을 발급하는 상승된 권한을 가져옵니다.

어느 기술이든 가장 위험한 위협과 디자인에서 가장 중요한 취약성을 이해하는 데 도움이 될 수 있습니다.

빠른 경로 위협 모델링

리소스가 제한된 경우 전체 위협 모델 다이어그램을 만드는 대신 드라이버에 대한 보안 위험을 평가하는 데 도움이 되는 요약 개요를 만들 수 있습니다. 예를 들어 아래 텍스트는 이전 예제에서 설명한 예제 드라이버에 다이어그램된 일부 표면 영역을 설명합니다.

드라이버는 다음과 같은 여러 유형의 요청으로 운영 체제에서 데이터를 받습니다.

• DriverEntry, DriverUnload 및 AddDevice 루틴에 대한 호출을 통해 드라이버 및 해당 디바이스에 대한 관리 작업을 수행하는 요청
• 플러그 앤 플레이 요청(IRP_MJ_PNP)
• 전원 관리 요청(IRP_MJ_POWER)
• 내부 디바이스 I/O 제어 요청(IRP_MJ_INTERNAL_DEVICE_CONTROL)

이러한 요청에 대한 응답으로 데이터는 상태 정보로 드라이버에서 운영 체제로 다시 흐릅니다. 드라이버는 다음 유형의 요청으로 사용자 프로세스에서 데이터를 받습니다.

• 요청 만들기, 읽기 및 쓰기(IRP_MJ_CREATE, IRP_MJ_READ 또는 IRP_MJ_WRITE)
• 공용 디바이스 I/O 제어 요청(IRP_MJ_DEVICE_ CONTROL)

이러한 요청에 대한 응답으로 출력 데이터 및 상태 정보는 드라이버에서 사용자 프로세스로 다시 흐릅니다.

드라이버에 대한 데이터 흐름에 대한 기본적인 이해를 사용하여 각 입력 및 출력 영역에서 가능한 위협을 검사할 수 있습니다.

위협 평가에 대한 DREAD 접근 방식

드라이버의 공격 방법과 위치를 결정하는 것만으로는 충분하지 않습니다. 그런 다음, 이러한 잠재적 위협을 평가하고, 상대적 우선 순위를 결정하고, 완화 전략을 고안해야 합니다.

DREAD는 소프트웨어에 대한 위협을 평가하기 위한 다섯 가지 기준을 설명하는 약어입니다. DREAD는 다음을 의미합니다.

• Damage
• Reproducibility
• Exploitability
• ffected 사용자
• Discoverability

드라이버에 대한 위협의 우선 순위를 지정하려면 두려운 평가 조건 5개 모두에 대해 각 위협의 순위를 1에서 10으로 지정한 다음 점수를 추가하고 5(조건 수)로 나눕니다. 결과는 각 위협에 대해 1에서 10 사이의 숫자 점수입니다. 높은 점수는 심각한 위협을 나타냅니다.

• 손상. 보안 공격으로 인해 발생할 수 있는 피해를 평가하는 것은 분명히 위협 모델링의 중요한 부분입니다. 손상에는 데이터 손실, 하드웨어 또는 미디어 오류, 표준 이하 성능 또는 디바이스 및 해당 운영 환경에 적용되는 유사한 측정값이 포함될 수 있습니다.

• 재현성은 지정된 유형의 공격이 성공하는 빈도를 측정한 것입니다. 쉽게 재현 가능한 위협은 거의 또는 예측할 수 없는 취약성보다 악용될 가능성이 높습니다. 예를 들어 기본적으로 설치되거나 모든 잠재적 코드 경로에 사용되는 기능에 대한 위협은 재현 가능성이 높습니다.

• 악용 가능성은 공격을 탑재하는 데 필요한 노력과 전문 지식을 평가합니다. 상대적으로 경험이 부족한 대학생이 공격할 수 있는 위협은 매우 악용될 수 있습니다. 고도로 숙련된 인력이 필요하고 수행하는 데 비용이 많이 드는 공격은 악용성이 떨어집니다.

  악용 가능성을 평가할 때 잠재적인 공격자 수도 고려합니다. 원격 익명 사용자가 악용할 수 있는 위협은 권한이 높은 온사이트 사용자가 필요한 위협보다 더 악용할 수 있습니다.

• 영향을 받는 사용자. 공격의 영향을 받을 수 있는 사용자 수는 위협을 평가하는 또 다른 중요한 요소입니다. 최대 한두 명의 사용자에게 영향을 줄 수 있는 공격은 이 측정값에서 상대적으로 낮은 비율을 기록합니다. 반대로, 네트워크 서버와 충돌하는 서비스 거부 공격은 수천 명의 사용자에게 영향을 미칠 수 있으므로 훨씬 더 높은 비율을 기록할 수 있습니다.

• 검색 가능성은 위협이 악용될 가능성입니다. 검색 가능성을 정확하게 예측하기는 어렵습니다. 가장 안전한 방법은 취약성이 결국 활용되고 결과적으로 다른 조치에 의존하여 위협의 상대적 순위를 설정하는 것이라고 가정하는 것입니다.

샘플: DREAD를 사용하여 위협 평가

위에서 설명한 예제를 계속 진행하면서 다음 표에서는 디자이너가 가상의 서비스 거부 공격을 평가하는 방법을 보여 줍니다.

공포 기준	점수 매기기	의견
피해	8	작업을 일시적으로 중단하지만 영구적인 손상이나 데이터 손실은 발생하지 않습니다.
재현 가능성	10	매번 디바이스가 실패하도록 합니다.
악용 가능성	7	명령 시퀀스를 결정하려면 집중적인 노력이 필요합니다.
영향을 받는 사용자	10	시장에서 이 디바이스의 모든 모델에 영향을 줍니다.
검색 기능	10	모든 잠재적 위협이 검색될 것이라고 가정합니다.
총:	9.0	이 문제를 완화하는 것이 높은 우선 순위입니다.

위협 완화

드라이버 디자인은 모델이 노출하는 모든 위협을 완화해야 합니다. 그러나 경우에 따라 완화가 실용적이지 않을 수 있습니다. 예를 들어 매우 적은 수의 사용자에게 영향을 미칠 수 있으며 데이터 또는 시스템 유용성이 손실될 가능성이 없는 공격을 고려합니다. 이러한 위협을 완화하는 데 몇 달의 추가 노력이 필요한 경우 드라이버를 테스트하는 데 추가 시간을 할애하도록 합리적으로 선택할 수 있습니다. 그럼에도 불구하고 결국 악의적인 사용자가 취약성을 찾아 공격을 탑재할 가능성이 높으며, 그러면 드라이버에 문제에 대한 패치가 필요합니다.

광범위한 보안 개발 수명 주기 프로세스에 위협 모델링 포함

광범위한 보안 개발 수명 주기 - SDL에 위협 모델링 프로세스를 포함하는 것이 좋습니다.

Microsoft SDL 프로세스는 단일 개발자를 포함하여 organization 크기에 맞게 수정할 수 있는 여러 권장 소프트웨어 개발 프로세스를 제공합니다. 소프트웨어 개발 프로세스에 SDL 권장 사항의 구성 요소를 추가하는 것이 좋습니다.

자세한 내용은 Microsoft SDL(보안 개발 수명 주기) - 프로세스 지침을 참조하세요.

교육 및 조직 기능 - 소프트웨어 개발 보안 교육을 추구하여 소프트웨어 취약성을 인식하고 수정하는 기능을 확장합니다.

Microsoft는 4개의 핵심 SDL 학습 클래스를 다운로드할 수 있습니다. Microsoft 보안 개발 수명 주기 핵심 교육 클래스

SDL 학습에 대한 자세한 내용은 이 백서를 참조하세요. Microsoft SDL용 Essential Software Security Training

요구 사항 및 디자인 - 신뢰할 수 있는 소프트웨어를 빌드할 수 있는 가장 좋은 기회는 개발 팀이 주요 개체를 식별하고 보안 및 개인 정보를 통합하여 계획 및 일정 중단을 최소화할 수 있기 때문에 새 릴리스 또는 새 버전의 초기 계획 단계에서입니다.

이 단계의 주요 출력은 특정 보안 목표를 설정하는 것입니다. 예를 들어 모든 코드가 경고가 없는 Visual Studio 코드 분석 "모든 규칙"을 전달해야 한다고 결정합니다.

구현 - 모든 개발 팀은 승인된 도구 목록과 컴파일러/링커 옵션 및 경고와 같은 관련 보안 검사 목록을 정의하고 게시해야 합니다.

드라이버 개발자의 경우 대부분의 유용한 작업은 이 단계에서 수행됩니다. 코드가 작성되면 가능한 약점에 대해 검토됩니다. 코드 분석 및 드라이버 검증 도구와 같은 도구는 강화될 수 있는 코드의 영역을 찾는 데 사용됩니다.

확인 - 확인은 소프트웨어가 기능적으로 완료되고 요구 사항 및 디자인 단계에 설명된 보안 목표에 대해 테스트되는 지점입니다.

binscope 및 퍼지 테스터와 같은 추가 도구를 사용하여 보안 디자인 목표가 충족되고 코드가 제공될 준비가 되었는지 확인할 수 있습니다.

릴리스 및 대응 - 제품 출시를 준비하기 위해 새로운 위협에 대응하기 위해 수행할 작업과 배송 후 드라이버를 서비스하는 방법을 설명하는 인시던트 대응 계획을 만드는 것이 좋습니다. 이 작업을 미리 수행하면 제공된 코드에서 보안 문제가 식별되면 더 빠르게 대응할 수 있습니다.

SDL 프로세스에 대한 자세한 내용은 다음 추가 리소스를 참조하세요.

• 이 사이트는 기본 Microsoft SDL 사이트이며 SDL에 대한 개요를 제공합니다. https://www.microsoft.com/sdl

• 이 블로그에서는 마이클 하워드와 스티브 리너가 제공하는 보안 개발 수명 주기: SDL의 무료 복사본을 다운로드하는 방법을 설명합니다. https://blogs.msdn.microsoft.com/microsoft_press/2016/04/19/free-ebook-the-security-development-lifecycle/

• 이 페이지에서는 추가 SDL 게시에 대한 링크를 제공합니다. https://www.microsoft.com/SDL/Resources/publications.aspx

조치 사항

드라이버 개발자의 경우:

• 위협 모델링을 드라이버 디자인의 일부로 만듭니다.
• 드라이버 코드의 위협을 효율적으로 완화하는 단계를 수행합니다.
• 드라이버 및 디바이스 유형에 적용되는 보안 및 안정성 문제를 숙지합니다. 자세한 내용은 WDK(Windows 디바이스 드라이버 키트)의 디바이스별 섹션을 참조하세요.
• 사용자 요청이 드라이버에 도달하기 전에 운영 체제, I/O 관리자 및 상위 수준 드라이버가 수행하는 검사와 수행되지 않는 확인을 이해합니다.
• 드라이버 검증 도구와 같은 WDK의 도구를 사용하여 드라이버를 테스트하고 확인합니다.
• 알려진 위협 및 소프트웨어 취약성의 공용 데이터베이스를 검토합니다.

추가 드라이버 보안 리소스는 드라이버 보안 검사 목록을 참조하세요.

소프트웨어 보안 리소스

책

보안 코드 작성, 마이클 하워드와 데이비드 르블랑의 두 번째 버전

24 소프트웨어 보안의 치명적인 죄: 프로그래밍 결함과 그들을 해결하는 방법, 마이클 하워드, 데이비드 르블랑과 존 비에가에 의해 첫 번째 버전

소프트웨어 보안 평가의 예술 : 마크 다우드, 존 맥도날드와 저스틴 슈에 의해 소프트웨어 취약점을 식별하고 방지

Microsoft 하드웨어 및 드라이버 개발자 정보

Windows 드라이버 백서에서 논리 취소

Windows 보안 모델: 모든 드라이버 작성기에서 알아야 할 사항

Microsoft Windows DDK(드라이버 개발 키트)

커널 모드 드라이버 아키텍처의 드라이버프로그래밍 기술을 참조하세요.

테스트 도구

성능 및 호환성에 대한 테스트의 Windows 하드웨어 랩 키트를 참조하세요.

알려진 위협 및 소프트웨어 취약성의 공용 데이터베이스

소프트웨어 위협에 대한 지식을 확장하려면 알려진 위협 및 소프트웨어 취약성의 사용 가능한 공용 데이터베이스를 검토합니다.

• CVE(일반적인 취약성 및 노출): https://cve.mitre.org/
• 일반적인 약점 열거형: https://cwe.mitre.org/
• 일반적인 공격 패턴 열거형 및 분류: https://capec.mitre.org/index.html
• NIST는 취약성이 카탈로그되는 방법을 설명하는 사이트를 유지 관리합니다. https://samate.nist.gov/BF/

참고 항목

드라이버 보안 검사 목록