🧪 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 – 위험 평가와 보안 목표 도출

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

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

🔍 5강. Audit도 ‘과정’이 중요하다!

프로세스 흐름과 단계별 목표 완전 정복 🚦

안녕하세요~ 자동차 사이버보안 심사 준비생 여러분!
한 주도 보안과 함께 즐겁게 보내셨나요? 😊
오늘은 Audit의 진짜 핵심인 "흐름과 단계별 목적"을
밝고, 명랑하게, 실무감 있게~ 정리해보겠습니다!

🎯 오늘의 학습 목표

• ISO/PAS 5112 기준의 Audit 전체 흐름 이해하기
• 각 단계에서 심사관이 중점적으로 보는 포인트 파악하기
• 조직에서 무엇을 어떻게 준비해야 하는지 감 잡기!

🛤️ Audit 흐름, 이렇게 흘러갑니다!

Audit은 단발 이벤트가 아니라,
계획 → 실행 → 보고 → 후속조치의 네 박자 루틴입니다! 🥁
이 흐름을 이해하면 심사 대응력이 쑥쑥! 올라가요!

1️⃣ 계획 (Planning)

심사는 준비된 조직에게 유리하다!

이 단계에서 하는 일은?

• 감사 목적과 범위 정의
• 관련 규격(UN R155, ISO/SAE 21434 등) 기준 명시
• 감사 팀 구성 및 역할 분배
• 감사 일정 및 활동 계획 수립

📌 실무 꿀팁!

• 범위를 모호하게 잡으면 심사 대상이 늘어나요 😱
• OEM 요구사항, CSMS 문서 수준을 미리 확인해두세요!

2️⃣ 실행 (Conducting)

이제 진짜 감사가 시작된다! 🎤

실제로 하는 일은?

• 인터뷰(개발자, 책임자, 보안 담당 등)
• 문서 검토 (프로세스 문서, 로그, 결과 보고서 등)
• 현장 관찰 (예: 양산 시 Key Injection 과정 관찰)
• 샘플 점검 (모든 걸 보는 게 아니라 일부 샘플로 검토)

👀 심사관이 주로 묻는 질문 예시

• "이 절차가 실제로 이렇게 수행되고 있나요?"
• "이 교육은 정기적으로 이루어지나요?"
• "이 공급사에서 받은 자료는 어떻게 검토하셨나요?"

📌 주의!

• 실무와 문서가 다른 경우 ‘프로세스 불일치’로 지적됩니다!

3️⃣ 보고 (Reporting)

“우리는 이런 걸 봤고, 이런 걸 발견했어요.”

이 단계에서 나오는 것?

• 비정상 항목(Non-conformity, NC) 목록
• 개선 권고 사항 (Observation)
• 모범 사례(Best Practice, 칭찬도 합니다!)

📋 보고서 핵심 구성 예시:

• 감사 목적/범위/팀 구성
• 감사 결과 요약 (NC/Observation/Strength)
• 부적합 사례별 근거 및 재발 방지 권고

🎯 심사 대상 조직의 할 일

• 결과 공유 및 내부 커뮤니케이션
• 대응 일정 계획 수립!

4️⃣ 후속조치 (Follow-up)

“이 문제, 진짜 고쳤나요?”

실무에서는 이렇게 진행됩니다:

• 개선계획 수립 및 실행 (CAPA, Corrective Action Plan)
• 결과 공유 및 이행 증빙 제출
• 필요시 재심사 (Follow-up Audit)

🔧 실제 후속조치 예시

• “보안 교육 이력이 미흡하다” → 교육 이력 시스템 구축
• “공급망 위험 평가 문서 미흡” → 평가 절차 재정립

📌 심사관이 재방문하는 경우도 있어요!

• 특히 NC Level이 높거나 법규 위반 위험이 있는 경우

📊 Audit vs Daily Work

📝 오늘의 한 줄 요약

Audit은 '보안이 실질적으로 실행되는지'를 확인하는 흐름이다!
프로세스의 흐름을 알면, 대응도 부드러워진다~ 🎶

🔜 다음 강 예고:

6강 – Assessment 프로세스 흐름과 Audit과의 핵심 차이점

• Audit과 Assessment, 뭐가 다를까?
• 심사 vs 분석, 절차와 목적의 결정적 차이!
• 실무자에게 더 부담되는 건 사실 OO?

🚀 다음 강에서는 Audit과 Assessment의 핵심 차이점을 한 방에 비교해드립니다!

💬 *"Audit을 안다고 해서 Assessment를 아는 건 아니다!"*
다음 시간엔 그것의 진실을 파헤쳐봅시다! 😎