STRIDE 사례: 산업용 게이트웨이
Sytance · 업데이트
STRIDE는 여섯 가지 위협 범주를 사용해 시스템이 어떤 방식으로 공격받을 수 있는지 살펴봅니다. 아래의 가상 산업용 게이트웨이는 각 범주에 대한 시나리오 하나씩과 제안된 통제 및 테스트 기준을 보여줍니다. 이 예시들은 발생 가능한 공격과 계획된 테스트를 설명합니다.
게이트웨이 및 신뢰 경계
운영자는 브라우저를 사용해 게이트웨이 관리 API를 호출합니다. API는 로컬 구성 저장소를 읽고 씁니다. 로컬 컨트롤러는 운영 데이터를 게이트웨이에 보내고, 게이트웨이는 원격 측정 정보를 원격 서비스로 전달합니다. 별도의 업데이트 서비스가 펌웨어 패키지를 제공합니다.
이 예시에서 관리 및 원격 측정 연결은 TLS를 사용합니다. 컨트롤러 인터페이스의 인증과 업데이트 신뢰 메커니즘은 아직 설계상 미해결 사항입니다. 로컬 네트워크에 있다는 사실만으로 발신자의 신원이나 권한이 확인되지는 않습니다.
- 브라우저 → 관리 API: 세션, 상태 요청, 구성 변경.
- 관리 API → 구성 저장소: 저장된 설정 및 비밀 정보 접근.
- 로컬 컨트롤러 → 게이트웨이: 현장 네트워크의 운영 입력.
- 게이트웨이 → 원격 측정 서비스: 장치 식별 정보 및 원격 측정 데이터.
- 업데이트 서비스 → 게이트웨이: 패키지 메타데이터 및 펌웨어 콘텐츠.
컨트롤러 인터페이스에서의 신원 스푸핑
공격자가 현장 네트워크에서 로컬 컨트롤러가 보낸 것처럼 가장한 메시지를 보냅니다. 게이트웨이가 출발지 주소만 신뢰한다면 위조된 운영 데이터가 원격 측정 데이터 흐름에 들어갈 수 있습니다.
제안된 통제: 장치 신원을 설정하고 메시지를 수락하기 전에 이를 검증합니다. 컨트롤러가 인증을 지원할 수 없다면 인터페이스를 보호할 다른 방법과 여전히 가능한 공격을 평가하세요. 네트워크 세그먼트만으로 메시지의 출처를 증명할 수는 없습니다.
검증 기준: 인식되지 않은 테스트 신원의 메시지는 거부되고 승인된 컨트롤러의 메시지는 계속 정상 처리됩니다. 거부 결과를 캡처하고 위조된 값이 원격 측정 서비스에 도달하지 않았는지 확인하세요.
설치 전 펌웨어 변조
공격자가 침해된 배포 지점을 통해 얻은 패키지를 바꿉니다. 해당 지점까지 전송을 암호화해도 제조업체가 패키지를 승인했다는 사실을 증명할 수는 없습니다.
제안된 통제: 설치 전에 승인된 신뢰 앵커를 사용해 패키지 서명을 검증합니다. 검증 대상을 실제 설치할 바이트와 허용된 제품에 연결하세요. 오래된 서명 버전과 폐기된 서명 키를 처리하는 방법은 별도로 결정하세요.
검증 기준: 변조된 패키지와 신뢰할 수 없는 키로 서명된 패키지는 설치 전에 거부됩니다. 거부 후 게이트웨이는 명시된 운영 상태 또는 복구 상태를 유지해야 합니다.
추적할 수 없는 구성 변경
승인된 운영자가 원격 측정 대상을 변경했지만 기록에 개인 식별 정보나 결과가 없습니다. 팀은 변경 주체를 신뢰성 있게 파악하거나 쓰기 성공과 거부된 요청을 구분할 수 없습니다.
제안된 통제: 인증된 신원, 작업, 대상, 시각, 결과를 기록합니다. 로그 접근을 보호하고 저장 공간이 가득 찼을 때의 동작을 정의하세요. 로그에 암호 또는 접근 토큰을 기록하지 마세요.
검증 기준: 통제된 변경에 대해 해당 기록이 생성되고, 권한 없는 사용자가 이를 수정할 수 없으며, 저장 공간이 가득 찼을 때 감사 로그 동작이 문서화된 정책과 일치합니다.
구성 조회를 통한 비밀 정보 노출
상태 엔드포인트가 원격 측정 자격 증명을 포함한 전체 구성 객체를 반환합니다. 상태를 볼 권한만 있는 사용자에게 해당 역할에 필요하지 않은 정보가 전달됩니다.
제안된 통제: 비밀 필드를 제외한 목적별 응답을 반환하고 구성 조회 권한을 확인합니다. 전송 중 암호화해도 과도한 데이터 응답 문제는 해결되지 않습니다.
검증 기준: 지원되는 각 역할의 응답을 확인해 비밀 값이 응답, 오류 또는 로그에 나타나지 않는지 확인합니다.
입력 처리로 인한 게이트웨이 자원 고갈
발신자가 지나치게 크거나 반복되는 컨트롤러 메시지를 보냅니다. 파싱과 버퍼링이 게이트웨이의 관리 및 원격 측정에도 필요한 자원을 소비합니다.
제안된 통제: 메시지 크기와 큐 길이에 상한을 두고, 비용이 큰 작업 전에 입력을 검증하며, 중요한 처리를 격리합니다. 측정된 용량과 과부하 중 제품에 필요한 동작을 기준으로 한도를 설정하세요.
검증 기준: 승인된 테스트 환경에서 합의된 과부하 상황을 시험하고 메모리, 큐 깊이, 서비스 가용성, 복구 상태를 관찰합니다. 합격 한도는 이 제품의 요구사항에 따라 정하며, 보편적으로 적용되는 속도 기준은 가정하지 않습니다.
읽기 전용 사용자가 쓰기 작업에 접근
사용자가 로그인해 상태를 볼 수 있습니다. 이 사용자가 인터페이스를 우회해 구성 쓰기 API를 직접 호출합니다. API가 인증만 확인하면 관리자에게만 허용된 기능을 사용자가 획득하게 됩니다.
제안된 통제: 모든 쓰기 경로에서 서버가 작업 권한과 리소스 권한을 확인하도록 합니다. 일반 요청, 대량 작업, 유지관리 엔드포인트에 같은 규칙을 적용하세요.
검증 기준: 읽기 전용 계정의 직접 쓰기 요청은 실패하고 저장된 구성은 변경되지 않습니다. 승인된 계정으로 반복해 의도된 작업이 계속 성공하는지도 확인하세요.
범위 및 잔여 위험
여섯 범주는 Microsoft의 STRIDE 정의를 따릅니다. 공격 시나리오와 통제는 앞에서 설명한 게이트웨이 아키텍처를 전제로 합니다.
실제 제품에서는 하나의 범주에 여러 공격 시나리오가 있을 수 있고, 한 공격이 여러 범주에 해당할 수도 있습니다. 제품에 제조, 유지관리, 복구 인터페이스가 있다면 해당 인터페이스도 분석에 포함해야 합니다.
통제를 구현하고 테스트한 후에도 가능한 공격을 합의한 위험 기준에 따라 평가하세요. 그 결과로 내린 결정은 분석한 제품 릴리스에 적용됩니다.