이 형태는 Rockwell 특정이 아님

테스트 1의 발견 — 프로토콜 기본 상태에 인증 없음 — 은 EtherNet/IP에만 고유한 것이 아닙니다. Modbus TCP는 여전히 물/폐수 제어 시스템에서 가장 널리 배포된 프로토콜 중 하나이며, 프로토콜 사양에 인증 개념이 전혀 없습니다; 1979년 직렬 통신으로 거슬러 올라가며 보안을 염두에 두고 설계된 적이 없습니다. CISA는 ICS 권고 전반에 걸쳐 정확히 이 실패를 반복적으로 지목했습니다(예: Mitsubishi Electric의 MELSEC iQ-F 시리즈: "MODBUS/TCP는 적절한 인증이 부족하여" 무단 읽기/쓰기/정지를 허용). Modbus Organization의 자체 답변인 Modbus/TCP Security는 X.509 인증서를 사용한 TLS 캡슐화입니다 — 구조적으로 테스트 3이 여기서 보여주는 것과 동일한 수정 범주이며, 한 공급업체가 아닌 프로토콜 조직 수준에서 표준화되었습니다. DNP3에는 선택적 Secure Authentication 확장(SAv5, 2012년 표준화)이 있습니다; 독립 분석과 구현자 설명 모두 실제로는 거의 구성되지 않는다고 설명하며, OT 제조업체 간 상호운용성 격차와 진정한 프로토콜 복잡성을 인용합니다 — 테스트 1이 EtherNet/IP에 대해 보여주는 것과 동일한 노출을 남깁니다.

아키텍처적 요점, 과장되지 않도록 정확히 진술: 테스트 3의 수정 — 상호 TLS, 인증서에 바인딩된 장치별 ID(CA 유효성만이 아님), CRL을 통한 폐기 — 는 ICS 애플리케이션 프로토콜이 아닌 전송 계층에서 작동합니다. 이 원리는 Modbus, DNP3 또는 독점 프로토콜 아래에서 동일하게 적용 가능합니다; 변경되는 것은 래퍼이지 수정의 형태가 아닙니다. 이 저장소는 Modbus 또는 DNP3 특정 PoC를 구축하거나 실행하지 않았습니다 — 이는 공개 문서에서 얻은 아키텍처적 일반화로, 여기의 다른 모든 것과 동일한 "입증 vs. 출처" 계층에 유지되며 새로운 테스트된 주장이 아닙니다.

출처: Modbus/TCP 인증 격차에 대한 CISA ICS 권고 — Industrial Cyber · Modbus/TCP Security 개요 — Veridify · DNP3 SAv5/SAv6 채택 과제 — Step Function I/O

세 가지 다른 실패 — 구별 유지

공개 패킷은 이들을 섞지 않음으로써 성공하거나 실패합니다, 각각 다른 수정이 있기 때문입니다:

• 인증 없음 / 부재 (테스트 1) — 자격 증명 계층이 전혀 없는 노출된 장치. CyberAv3ngers 캠페인이 의존한 광범위한 기준선(많은 피해자가 없거나 기본 자격 증명으로 도달 가능).
• 플릿 전체에 걸친 하나의 하드코딩/공유 키 (CVE-2021-22681의 특정 형태, 테스트 2로 모델링) — 하나의 키를 한 번 추출하여 플릿 전체를 위조. 이것이 실제 CVE입니다.
• 기본 자격 증명 — 공장 자격 증명이 변경되지 않음. 여기서 모델링되지 않음; 위의 두 가지와 혼동되지 않도록 명명됨.

여기서 입증된 수정 — 장치별 ID 바인딩 (테스트 3) — 플릿 키 실패를 해결합니다.

엄격한 경계 (먼저 읽으십시오)

두 행을 혼동하지 마십시오. 원리는 입증되었습니다. 공급업체의 특정 구현은 신뢰할 수 있지만(그들 자신의 명시된 설계 의도) 실제 장비에 대해 우리가 테스트하지 않았습니다.

도구

test1_baseline_vulnerable.py — 무인증 기준선, 실시간

실제 EtherNet/IP PLC 시뮬레이터(cpppo, Allen-Bradley ControlLogix 에뮬레이션)를 시작하고 자격 증명 없이 제어 태그를 읽고 씁니다. (범위: 이는 캠페인이 의존한 광범위한 무인증 기준선 — CVE-2021-22681의 특정 하드코딩 키 메커니즘이 아님. 의도적으로 구별 유지; 위의 "세 가지 다른 실패" 참조.)

test2_shared_secret_fails.py — 플릿 키 결함의 형태 (내러티브 브리지, 테스트 아님)

두 엔드포인트가 하나의 정적 키를 보유; Device A의 자격 증명이 변경 없이 Device B를 엽니다 — CVE-2021-22681의 하나의 키가 모두에게 맞는 결함에 가장 가까운 구조적 유사체. 그러나 동어반복입니다: 두 핸들러 모두 해당 키를 수락하도록 구성되어 있으므로 실패할 수 있는 실행 경로가 없습니다. 코드가 정의로 존재하게 만드는 것 외에는 아무것도 입증하지 않습니다. 테스트 1에서 테스트 3으로의 내러티브 브리지로 유지; 증거적 가중치가 없으며 의도적으로 증명 다리가 아닙니다.

test3_mutual_tls_fix.py — 수정, 음성 대조군 및 양방향 포함

실제 CA, 두 개의 개별 고유 장치 인증서 — 폐기된 CommonName이 아닌 SubjectAlternativeName에 바인딩된 ID. 5개 사례, 모두 실행:

• [1] Device A의 자체 인증서 → 허용 · [2] 인증서 없음 → TLS 핸드셰이크에서 거부 · [3] Device B의 CA 유효 인증서 → ID에서 거부(엄격한 엔드포인트).
• [4] 대조군 — CA 유효성-만 엔드포인트에 대한 동일한 Device B 인증서 → 허용. 이것이 [3]에 의미를 부여합니다: ID 검사 없이는 모든 플릿 인증서가 모든 장치를 엽니다(== TLS 옷을 입은 테스트 2).
• [5] 역방향 — Device B의 인증서를 제시하는 악성 서버가 device-a를 바인딩하는 클라이언트에 의해 거부됨(실제 SAN에 대한 check_hostname). 상호 — 양쪽 끝이 ID를 바인딩.

test4_revocation.py — 수명 주기 다리: 폐기

실제 CA 서명 CRL. 클라이언트 자격 증명(engineer-1)이 허용됨; 그런 다음 해당 일련번호가 CRL에 추가되고, 동일한 여전히 유효하고 만료되지 않은 CA 서명 자격 증명이 거부됩니다 — CR 1.8 / 1.9 폐기 조항의 경험적 내용. 고유성(테스트 3) ≠ 폐기 가능성; 이는 자격 증명을 되돌려 가져올 수 있음을 보여줍니다.

test5_rotation.py — 테스트 4가 닫지 않은 수명 주기 다리: 회전

이미 유효한 자격 증명(v1)을 보유한 동일한 ID(engineer-1)에 대한 교체 자격 증명(v2)을 발급합니다. 대조군(사례 3): v1이 v2가 존재한 후 그러나 v1이 명시적으로 폐기되기 전에 다시 제시됨 → 여전히 허용 — 재발급만으로는 이전 자격 증명이 폐기되지 않음을 입증. v1이 CRL에 명시적으로 추가된 후에만(사례 4) 거부됩니다; v2는 전체 기간 동안 영향을 받지 않습니다(사례 5) — 전환 중에 ID가 액세스를 잃지 않습니다. CR 1.8의 "교체 발급 및 이전 것 폐기"는 두 가지 작업이며, 이것은 둘 다 별도로 보여줍니다.

test6_tamper_injection.py — CR 3.1이 "구성상"으로만 명명한 다리: 전용 무결성 테스트

레코드 수준 릴레이가 실제 상호 TLS 클라이언트와 서버 사이에 위치하여 5바이트 헤더만 파싱하여 TLS 레코드를 전달합니다 — 암호화된 페이로드의 평문을 결코 볼 수 없습니다. 대조군: 모든 바이트가 수정 없이 전달됨 → 메시지가 온전하게 전달됨. 변조: 활성 Application Data 레코드의 암호문 내부에서 한 비트가 뒤집힘 → 수신 TLS 스택의 AEAD 검사 실패(SSLV3_ALERT_BAD_RECORD_MAC) 및 연결 종료 — 손상된 데이터가 유효한 것처럼 전달되지 않습니다. 어느 바이트인지, 그리고 왜 지정되었는지: TLS 1.2 AEAD 레코드 본문은 explicit_nonce(8) ‖ ciphertext ‖ auth_tag(16)이므로 바이트 0은 논스이지 페이로드가 아닙니다. 논스를 뒤집어도 AEAD 검사가 실패합니다 — 그러나 변경된 페이로드를 태그가 잡는 것이 아니라 복호화를 손상시켜서입니다. CR 3.1은 전송된 정보의 무단 수정에 관한 것이므로, 뒤집기는 암호문 중간의 바이트를 대상으로 하며, 테스트는 그런 다음 주장하는 문장을 정확히 입증합니다.

범위 경계 (주장되지 않는 것)

• 폐기 및 회전 — 둘 다 이제 입증됨. 장치별 고유성(테스트 3)은 폐기 가능성과 동일하지 않습니다; 테스트 4가 그 격차를 닫습니다 — 여전히 유효하고 만료되지 않은 CA 서명 자격 증명이 폐기 전에 허용되고 폐기 후 거부됩니다. 테스트 5가 나머지 수명 주기 격차인 회전을 닫습니다 — 동일한 ID에 대한 교체 자격 증명 재발급 및 이전 것의 명시적 폐기, 두 가지가 별도의 작업임을 보여주는 자체 음성 대조군 포함.
• 이 스크립트의 TLS 1.2는 테스트 결정성 산출물이지 배포 권장 사항이 아닙니다. 모든 스크립트는 maximum_version = TLSv1_2를 고정하며, 그 이유는 관찰 가능성에 관한 것이지 보안이 아닙니다: TLS 1.2에서는 누락되거나 거부된 클라이언트 인증서가 핸드셰이크 중에 실패하므로 테스트는 TLS 1.3의 핸드셰이크 후 실패 대신 결정적이고 귀속 가능한 오류를 얻습니다; 그리고 레코드 콘텐츠 유형이 평문으로 계속 보여 테스트 6의 릴레이가 Application Data 레코드를 식별할 수 있습니다. 장치가 지원하는 가장 높은 TLS 버전을 배포하십시오 — 가능한 경우 TLS 1.3. 이 저장소의 어떤 것도 프로덕션 시스템을 1.2로 제한하라는 조언으로 읽혀서는 안 됩니다.
• 상수 시간(낮은 심각도, 위생을 위해 명명). ID 문자열 비교(presented == KEY, identity in SAN)는 상수 시간이 아닙니다. 여기서 악용 가능하지 않음 — 비교되는 값은 공개적인 ID 문자열이며 TLS가 비교 실행 전에 실제 암호화 인증을 이미 수행했습니다 — 그러나 패턴이 중요한 곳에 복사되기 때문에 플래그가 지정되었습니다.

설정

다음 단계 (2026-08-03 기준 모든 명명된 항목 완료 — 아래 모든 것은 라이브, 푸시됨, 보류 없음)

• 62443-4-2 SL 2 매핑 — 초안 작성됨 → 62443-4-2_SL2_MAPPING.md (CR 1.2 / 1.8 / 1.9 / 1.14 / 3.1, 정직하게 계층화, 모든 격차 명명; CR 1.2, CR 1.9 및 CR 1.8의 발급/검증/폐기 다리는 이제 입증됨). PSIRT([email protected] / [email protected])에 보내기 전: 구매한 IEC 62443-4-2:2019 사본에 대해 각 CR의 규범적 텍스트를 검증.
• 단계적 롤아웃 — 초안 작성됨 → PHASED_ROLLOUT.md (0단계 출혈 중지 · 1 세그먼트 · 2 보상 제어 · 3 CIP Security/PKI, 하드웨어 허용 시 · 4 운영). 소규모 유틸리티에 적합한 크기; CIP Security가 하드웨어에 의해 제한된다는 점을 정직하게 인정, 따라서 0~2단계가 위험 감소를 담당합니다.
• 책임 있는 공개 순서 — 완료. PSIRT에 2026-07-31 연락, 저장소/문서가 같은 날 약 30분 후 공개, Rockwell의 답변 2026-08-03. 전체 세부 사항은 위의 "공급업체 상태"에 있음; 이 항목에 열린 것은 없음.
• 2026-08-03 추가 — 조언을 소규모 유틸리티가 실제로 사용할 수 있는 산출물로 전환: PHASE0_INVENTORY_WORKSHEET.md(작성 가능한 장치 인벤토리, 만들라는 지시만이 아님), RESOURCES.md(무료 CISA / EPA / WaterISAC / AWWA 지원, 회상이 아닌 라이브로 검증됨), 및 INCIDENT_RESPONSE_QUICK_REFERENCE.md(첫 60분 카드, 전체 IR 계획이 아님을 명시 — 운영 안전이 항상 최우선).
• 이전에 명명된 두 기술 항목 — 완료(2026-08-03). test5_rotation.py는 CR 1.8을 "활성화"에서 완전히 입증된 것으로 이동(회전, 자체 대조군 포함); test6_tamper_injection.py는 CR 3.1을 "구성상"에서 입증된 것으로 이동(실제 비트 뒤집기, TLS의 AEAD 검사로 거부됨). 둘 다 여기에 추가되기 전에 반복 실행되어 불안정성이 없음을 확인. 또한 추가됨: PHASE3_CA_QUICKSTART.md("몇 줄의 코드" CA, 실제 테스트된 openssl 명령으로) 및 PHASED_ROLLOUT.md 1단계의 구체적인 허용 목록 예.
• 단계적 롤아웃 자체 — 완료, 전체 5단계(0~4). 모든 단계가 한 번만 초안 작성된 것이 아니라 내부 일관성을 위해 검토 및 수정됨: 3단계 CA 설정에서 발견되어 닫힌 실제 취약점, 누락되었던 CRL 실패-개방/실패-폐쇄 결정이 이제 이루어지고 명시됨, 인증서 만료가 그것이 새로운 중단 모드임을 명명됨, 2단계 모니터링에 대한 3단계의 조용한 영향이 대체와 함께 명명됨, NTP가 전제 조건으로 나열됨, 모든 지원 문서(GLOSSARY.md, INTEGRATOR_CHECKLIST.md, PHASE3_CA_QUICKSTART.md)가 이제 참조되지 않은 채 방치되는 대신 계획에서 실제로 링크됨. 이 목록의 어떤 것도 여전히 초안이 아님 — 위와 아래의 모든 것이 푸시되어 공개 저장소에 라이브 상태입니다.

인용 — 회상이 아닌 검색됨(및 제출 전 재풀)

여기의 모든 외부 식별자는 훈련에서 회상된 것이 아니라 2026-07-31에 라이브 소스에서 가져왔습니다: AA26-097A(다중 소스, WaterISAC / Tenable / SecurityWeek 포함), 공개된 4개 피해자 중 하나로서의 Braham, CyberAv3ngers/IRGC, PN1550이 실제 Rockwell 권고임을 확인하고 2행 인용이 그대로 확인됨("적절히 배포되면 CIP Security는 이 취약점을 해결합니다" + "하드코딩된 키를 사용하지 않습니다"), "패치로 완화할 수 없음" 그대로, CVSS 10.0 / CRITICAL (v3.1), CISA 추적 ICSA-21-056-03, 및 62443-4-2 CR 1.8(PKI) + CR 3.1(통신 무결성)이 정확히 확인됨. 패킷에 대한 규율: 제출 시점에 모든 식별자를 기본 소스에서 다시 풀어야 합니다. 권고는 번호가 다시 매겨지고, 확장되고, 대체됩니다 — AA26-097A는 이미 한 번의 확장을 보여줌 — 따라서 "2026-07-31에 검증됨"은 "제출 시 검증됨"이 아닙니다. 전체 공식 CR별 62443-4-2 매핑이 이제 작성되었습니다(62443-4-2_SL2_MAPPING.md) — 남은 것은 제출 전에 구매한 표준 사본에 대해 인용된 규범적 텍스트를 다시 풀는 것이지 매핑 자체를 작성하는 것이 아닙니다.

l0gic — Patrick Crosby · 2026-07-31.

강화 로그, 2026-08-03: test5_rotation.py 및 test6_tamper_injection.py 추가, 2026-07-31부터 열려 있던 두 기술 항목을 닫음 — 각각 여기에 기록되기 전에 세 번 재실행되어 불안정성 없음 확인. PHASE3_CA_QUICKSTART.md(실제 테스트된 openssl 명령), 구체적인 1단계 방화벽 허용 목록 예, PHASE0_INVENTORY_WORKSHEET.md, RESOURCES.md, INCIDENT_RESPONSE_QUICK_REFERENCE.md 및 Modbus/DNP3 일반화도 같은 날 추가됨.

강화 로그, 2026-08-03(계속) — 두 번의 독립 검토 패스, 모두 적용됨: 보안 레드팀이 CA 퀵스타트에서 실제 PKI 취약점을 발견하고 수정함(-copy_extensions copyall이 악성 인증서 요청이 CA:TRUE를 자체 선언하도록 허용; 명시적 -extfile로 수정, 의도적으로 악성 요청에 대해 양방향으로 검증됨) 및 test6이 바이트 0(논스)이 아닌 암호문을 구체적으로 뒤집도록 수정, 실제 스레드 안전성 수정 및 의존성 고정 추가. 별도의 구조적 감사 — 체크리스트가 아닌 시간에 걸친 시스템으로서 단계를 읽음 — 다음을 발견하고 수정함: 3단계의 "몇 줄" 헤드라인이 폐기/회전이 단순하지 않음을 숨김; CRL 실패-개방/실패-폐쇄가 결정되지 않음(이제 결정됨, 기본값 및 근거 포함); 인증서 만료가 새롭고 명명되지 않은 중단 모드였음(4단계가 이제 테스트 5의 안전한 중첩 교훈을 담당); 3단계가 2단계의 쓰기 경보기를 조용히 차단함(이제 명명되고 대체 제안됨); NTP가 명시되지 않은 전제 조건이었음; CR 1.14가 "충족되지 않음"으로 프레임되었는데 "수정된 설계에 적용되지 않음"이 정확한 진술임; 및 INTEGRATOR_CHECKLIST.md/GLOSSARY.md가 아무것도 링크하지 않은 고아 문서였음(이제 3단계와 이 계획의 상단에서 링크됨). 모든 수정은 diff를 다시 읽는 것이 아니라 영향을 받는 테스트를 재실행하여 검증됨. 푸시 및 라이브 — 롤아웃 계획의 전체 5단계가 완료되었고 두 번 검토되었으며 오늘의 어떤 것도 더 이상 로컬에 남아 있지 않습니다.

강화 로그: 테스트 3이 음성 대조군(사례 4, 발화만이 아닌 필요성 입증), 역방향 사례(사례 5, 상호 바인딩) 및 SAN 기반 ID(CN 아님)를 포함하도록 강화된 후 5개 사례를 모두 재실행하여 재검증됨; 테스트 4(CRL 폐기)가 추가됨. 테스트 1/2 캡션이 세 가지 실패 클래스를 구별하도록 적절한 크기로 조정됨; 테스트 2가 "테스트"에서 내러티브 브리지로 강등됨; 폐기 및 상수 시간 범위 경계가 추가됨. 인용 체인이 기본 소스에서 검색되어 제출 시 재풀용으로 스탬프됨.