🛠️ 11강. 보안 요구사항 도출과 분류

"보안 목표는 나침반, 보안 요구사항은 지도다!"

안녕하세요, 사이버보안 항해 중이신 개발자 여러분!
이제 보안 목표(Cybersecurity Goal)까지 세웠다면…
다음 스텝은? 바로 요구사항으로 구체화하는 겁니다!

🎯 목표만으로는 제품이 만들어지지 않아요!
요구사항이 있어야 구현, 검토, 검증까지 쭉 이어질 수 있죠.

이번 강의에서는 보안 요구사항을 어떻게 도출하고,
어떻게 분류하고,
어떻게 시스템과 연계할 수 있을지 알아보겠습니다.

🧱 1. 보안 요구사항이란?

보안 요구사항(Security Requirement)은
"시스템이 보안 목표를 만족하기 위해 구현되어야 할 조건"입니다.

• 요구사항은 구체적이어야 하고
• 검증 가능해야 하며
• 개발 프로세스에 통합될 수 있어야 합니다!

🎯 한 마디로, 보안 목표를 '개발언어'로 번역한 것!

📂 2. 요구사항의 유형 – 기능적 vs 비기능적

✅ 기능적 요구사항 (Functional Requirement)

"무엇을 해야 하는가?"

• 시스템이 어떤 기능을 제공해야 하는지 정의
• 주로 보안 서비스나 메커니즘 중심

예시:

• 차량 도어는 인증된 명령에 의해서만 잠금 해제되어야 한다.
• OTA 업데이트는 무결성 검증이 성공한 경우에만 적용된다.

🔒 비기능적 요구사항 (Non-Functional Requirement)

"어떻게 해야 하는가?"

• 시스템의 품질 속성 또는 운영 조건 정의
• 성능, 유지보수성, 가용성, 정책 등 포함

예시:

• 모든 인증 로그는 삭제 불가능하고 1년 이상 보관되어야 한다.
• 데이터 전송은 TLS 1.2 이상 암호화 프로토콜을 사용해야 한다.

💡 둘 다 중요! 기능적 요구사항은 “행동”을,
비기능적 요구사항은 “조건”을 잡아줍니다.

🧭 3. 요구사항 분류 프레임워크

ISO/SAE 21434에서는 다음과 같은 관점으로 요구사항을 분류할 수 있어요:

🧩 요구사항은 ‘어떻게 구현할 것인가’에 따라 역할이 나뉘고 책임자가 달라집니다.

🏗️ 4. 시스템 레벨과의 연계 – 어디에 붙일까?

보안 요구사항은 시스템 개발의 다양한 레벨에 맞춰야 합니다:

🎯 보안 요구사항은 단순 문장이 아니라,
시스템 설계와 직접 연결되어야 진짜 힘을 발휘합니다!

🚗 실전 예제: 차량 진단 시스템 보안

🧭 보안 목표:

• 진단 명령은 인증된 장치로부터만 수신되어야 한다.

📋 보안 요구사항:

🧾 실무 팁!

• 요구사항은 “개발자가 구현할 수 있는 언어”로 표현하자
• 너무 광범위하거나 막연한 표현은 피하자 (❌ "보안에 유의한다")
• 요구사항마다 검증 기준(Test Case)도 함께 고려하자
• 가능한 한 요구사항 추적성(Traceability) 확보하자 (Goal ↔ Req ↔ Test)

✅ 오늘의 요약

⏭️ 다음 강의 예고

12강. 아키텍처 설계와 보안 통합

보안 요구사항이 정리되었다면,
이제 그것을 아키텍처 설계에 어떻게 녹여낼지 고민할 차례입니다.

• 도메인 분리
• 보안 경계 설정
• ECU 간 신뢰 관계
  이 모든 걸 다뤄볼 예정이에요!

🧠 시스템 설계자와 보안 담당자가 함께 보는 필수 강의! 기대해주세요 🔒🏗️

🧪 6강. Assessment는 Audit과 뭐가 달라요?

프로세스 흐름과 평가 포인트, 핵심 차이 완전 분석! 🔍

안녕하세요, 사이버보안 심사 마스터의 길로 한 걸음씩 나아가는 여러분!
오늘은 ‘Audit’과 함께 자주 등장하는 그 단짝!
Assessment에 대해 집중 탐구해볼 시간입니다! 🧠

지난 5강에서 Audit의 흐름과 목적을 배웠다면,
이번 6강에서는 그와 다르면서도 밀접한 관계를 가진 Cybersecurity Assessment의 프로세스를
설명해드립니다. 🎯 

🎯 오늘의 목표

• Assessment가 무엇인지, Audit과 어떻게 다른지 파악하기
• 개발 프로젝트 중심의 평가 특징 이해하기
• CS Maturity 평가와 어떻게 연결되는지 알아보기

🤔 Audit vs Assessment: 뭐가 다르죠?

💡 요약하자면:

Audit은 '회사 전체의 사이버보안 체계'를 보고,
Assessment는 '개별 프로젝트의 보안 활동'을 들여다본다!

🛠️ Assessment의 전체 흐름 (ISO/SAE 21434 기준 기반)

1️⃣ 평가 계획 수립

• 어떤 프로젝트를 어떤 관점에서 평가할지 정의
• 개발 단계(Lifecycle)에 따라 범위 결정
• 평가 수행자 선정 (기술적 역량 필요!)

📌 예시:
ADAS ECU 프로젝트, Concept 단계에서 평가 진행

2️⃣ 산출물 기반 분석

• 프로젝트에서 작성된 보안 활동 산출물을 수집
• 요구사항 정의서, 위험 평가 결과, 설계서, 검증 결과 등 검토

🎯 이때 평가자는 ISO/SAE 21434의 각 항목에 따라
해당 산출물이 "목적에 맞게 작성되었는가?"를 판단합니다.

3️⃣ 인터뷰 및 근거 검토

• 산출물만으로 부족한 부분은 인터뷰로 보완
• "이 결정은 어떤 위험 평가를 기반으로 했나요?"
• "이 위협은 어떻게 대응했죠?"

📌 문서 + 인터뷰로 타당성과 일관성 확보가 중요!

4️⃣ 평가 결과 정리

• 부적절하거나 누락된 활동은 개선 권고
• 문제는 없지만 더 잘할 수 있는 부분은 Observation
• 양호한 사례는 Best Practice로 기록

✋ 주의사항

• Assessment는 “리뷰”가 아닙니다!
  단순히 확인이 아니라, “적절했는지 평가”입니다.
• 출처 불명확하거나 임의로 정한 평가 기준은 금지!
  → 반드시 ISO/SAE 21434의 요구사항 기반으로 진행되어야 합니다.

📝 오늘의 한 줄 요약

Assessment는 프로젝트의 보안 건강검진!
프로세스도 중요하지만, 실제 활동의 ‘품질’이 관건이에요! 🧪

🔜 다음 시간 예고

7강 – 심사 기준 문서화: 증빙자료의 요건

• 증적(Evidence)은 어떤 형식이어야 할까?
• 심사관이 좋아하는 문서 vs 실격 문서
• “보안활동은 했지만 증거가 없다면, 안 한 거예요!”

다음 시간엔 ‘문서의 품질’과 ‘증적 관리 전략’을 깊이 있게 다뤄보겠습니다!
실무자들이 가장 자주 고민하는 포인트니까, 놓치지 마세요! 📁

💬 “Audit은 조직의 거울이고,
Assessment는 프로젝트의 엑스레이다.”
정확한 진단이, 진짜 보안을 만듭니다!

🔐 10강. TARA – 위험 평가와 보안 목표 도출

"모든 위협이 똑같이 무섭진 않다구요!"

안녕하세요, 사이버보안 개발자 여러분!
오늘은 TARA의 마지막 단계, 바로 "이 위협은 얼마나 위험할까?"에 대해 이야기해보는 시간입니다.

지금까지 우리는:

• 자산을 식별하고,
• 시스템 경계를 정하고,
• 공격 시나리오를 만들었습니다.

이제 "그래서 얼마나 위험한데?",
그리고 "뭘 지켜야 하지?" 라는 질문에 답할 차례입니다.

🎯 오늘의 핵심 목표

• 위험 평가란 무엇인가?
• Impact/Risk Matrix로 직관적으로 평가하기
• 보안 목표(Cybersecurity Goal)를 도출하는 법
• 실전 예시까지!

⚖️ 1. 위험 평가(Risk Assessment)란?

"해킹 시도가 100번 들어오더라도, 실제 피해가 0이면 괜찮은 거 아닌가요?"

맞습니다!
그래서 우리는 공격의 가능성과 영향(Impact) 을 함께 고려해야 해요.

📌 핵심 요소

• Likelihood (발생 가능성)
  얼마나 자주 또는 쉽게 공격이 일어날 수 있는가?
• Impact (영향도)
  공격이 성공했을 때 안전, 재산, 운영에 얼마나 큰 영향을 주는가?

🧮 2. Impact / Risk Matrix 사용법

Risk Matrix는 Likelihood와 Impact를 기준으로 위험도를 시각화하는 도구예요!

📊 예시: 3x3 Risk Matrix

🔍 각 시나리오에 대해 이 테이블을 적용해보면 위험 우선순위를 직관적으로 정할 수 있어요!

🚗 3. 실전 예제: 차량 위치 추적 공격

시나리오 요약

• 해커가 백도어 앱을 통해 차량의 실시간 GPS 데이터를 수집
• 운전자의 위치 및 이동 경로를 서버에 전송

평가 항목

보안 목표 도출 예시

• CG-01: 차량의 위치정보는 인증된 사용자만 접근 가능해야 한다.
• CG-02: 위치정보 전송 시 암호화되어야 한다.
• CG-03: 클라우드에서 위치정보 접근 로그가 기록되고, 조작되지 않아야 한다.

💡 보안 목표는 "시스템이 어떤 상태를 반드시 유지해야 하는가?"에 대한 선언이에요!

🎯 4. 보안 목표(Cybersecurity Goal) 도출 팁

• 하나의 위협 시나리오 → 여러 개의 보안 목표
• 보안 목표는 기능이 아니다! 시스템이 유지해야 하는 '보장 조건'이다
• 가능한 한 구체적으로, 측정 가능하게 작성할 것!

🧾 5. 현실 적용 팁

• 위험 수준이 낮다고 완전 무시하지 마세요!
  예: 로그인 실패 횟수 제한을 안 두면 저위험이 모여 고위험이 될 수 있음.
• Impact는 안전, 재산, 법적 문제까지 고려하세요!
  특히 기능안전(ISO 26262) 과 연계된 시스템에서는 Impact 점수가 상승하는 경우가 많아요.
• Risk 평가 주체가 중요합니다
  개발자, 보안 담당자, QA, 심지어 법무까지 함께 논의하는 것이 가장 이상적입니다!

✅ 오늘 요약

⏭️ 다음 강의 예고

11강. 보안 요구사항 도출과 분류

보안 목표까지 도출했다면,
이제 그걸 개발팀이 바로 이해하고 구현할 수 있는 형태로 바꿔야겠죠?

Functional Requirement, Technical Control, Organizational Policy
이 세 가지 관점으로 나누는 방법을 다음 시간에 알아봅시다!

🛠️ 보안, 이제 구체적으로 만들 시간입니다!

🛡️ 9강. TARA – 공격경로와 위협 시나리오 그리기

"공격자의 시선을 가져라, 방어가 보인다!"

안녕하세요, 사이버보안 개발자 여러분!
오늘은 TARA의 두 번째 단계, 바로 "어떻게 공격할 수 있을까?" 를 다뤄보는 시간입니다!

🚨 자산(Asset)을 다 파악했다면, 이제는 그걸 어떻게 노릴 수 있을지를 상상해봐야겠죠?

🎯 오늘의 목표:

• STRIDE 기반으로 사고하는 법
• DFD(데이터 흐름도)로 공격 경로를 시각화하는 방법
• 실전 위협 시나리오 예제!

🎩 1. 해커의 관점으로 생각하라! – STRIDE 사고법

STRIDE는 Microsoft가 만든 위협 분류 모델인데,
해커가 어떤 식으로 시스템을 공격할 수 있는지를 알려주는 훌륭한 사고 도구입니다.

🔍 STRIDE란?

🎯 STRIDE는 '공격자의 입장'에서 시나리오를 짤 수 있도록 도와줘요!

📈 2. DFD로 시스템을 도식화하자

🤔 DFD란?

Data Flow Diagram, 즉 데이터 흐름도는 시스템 내 컴포넌트 간 데이터의 흐름을 그려주는 도식입니다.

📌 DFD를 그려야 공격자가 어디로 들어올 수 있을지를 눈으로 확인할 수 있어요!

💡 DFD 작성 요령

1. 프로세스 (원) : 데이터 처리 주체 (예: ECU, 서버)
2. 데이터 저장소 (두 줄) : DB, 로그, 저장 공간
3. 외부 개체 (사각형) : 사용자, 앱, 외부 서버
4. 데이터 흐름 (화살표) : 통신, 데이터 전달

🔐 그리고 나면, 각 컴포넌트와 흐름에 STRIDE를 적용해서 위협을 찾습니다!

🚗 3. 실전 예시: 원격 도어 락 시스템

🧱 시스템 구성

• 사용자 앱 → 클라우드 서버 → 차량 게이트웨이 → 도어 컨트롤러

📌 STRIDE 분석 + DFD 위협 예시

🎯 이런 위협 시나리오가 TARA의 핵심 결과물입니다!

🧭 4. 위협 시나리오 구성 팁!

• 자산과 DFD를 연결하라
• 각 데이터 흐름에 STRIDE를 대입해 보라
• '공격자의 관점'에서 “어떻게 뚫을 수 있을까?”를 상상하라
• 가능한 한 구체적으로 “누가”, “어떻게”, “무엇을” 공격하는지를 시나리오화하라

✅ 오늘의 핵심 요약

⏭️ 다음 강의 예고

10강. TARA – 위험 평가와 보안 목표 도출

이제 우리가 만든 위협 시나리오가 얼마나 위험한지,
그리고 무엇을 지켜야 할지 정해볼 시간입니다!

🚦 "모든 위협이 다 중요한 건 아니다!"
위험의 크기에 따라 보안 목표가 정해집니다.
다음 강의도 꼭 챙겨보세요! 😊