분석 대상 시스템/제품/서비스를 정의합니다.
Automotive SPICE
Automotive SPICE 개요
Automotive SPICE 소개
ASPICE(Automotive Software Process Improvement Capability Determination)는 자동차 소프트웨어 개발 프로세스를 평가하기 위한 업계 표준 지침입니다. 2005년에 도입된 ASPICE는 자동차 공급업체가 모범 사례를 통합하여 개발 초기에 결함을 식별하고 OEM 요구 사항을 충족할 수 있도록 평가모델을 정의하였습니다.
ASPICE는 프로세스를 두 부분으로 나누는 시스템과 소프트웨어 개발 과정에서 V 모델을 활용합니다. 문자 V의 왼쪽은 설계 및 개발 단계를 나타내고 오른쪽은 테스트 단계를 나타냅니다. 이러한 방식으로 모든 개발 단계는 테스트 단계에 의해 반영됩니다. 문자 V는 확인 및 검증을 의미하기도 합니다.
Automotive SPICE 역사
ASPICE(Automotive SPICE)는 1990년대 후반 BMW, Bosch, Continental, DaimlerChrysler 및 Volkswagen을 포함한 독일 자동차 회사 그룹에 의해 처음 개발되었습니다. 자동차 산업에서 사용되는 소프트웨어 개발 프로세스를 평가하고 개선하기 위해 공통 프레임워크를 구축하고자 개발되었습니다.
ASPICE의 첫 번째 버전은 소프트웨어 개발을 위한 V-모델(VDA 6.3)로 2003년에 출시되었습니다. 이 버전은 소프트웨어 개발 전반에 걸쳐 테스트 및 검증의 중요성을 강조하는 소프트웨어 개발 모델인 V-모델을 기반으로 했습니다.
2005년에는 프로세스 평가 모델(PAM)을 도입한 ASPICE의 두 번째 버전이 출시되었습니다. PAM은 자동차 산업에서 소프트웨어 개발 프로세스의 효과성과 효율성을 평가하는데 사용되는 일련의 지침 및 기준입니다. 그 이후로 ASPICE는 여러 번 수정되고 업데이트되었습니다.
2017년 ASPICE 3.1버전이 출시된 이 후 국내외 자동차산업 전반에서 자동차부품 개발 프로세스 평가모델로 적용하고 있으며, 2024년 2Q에 ASPICE 4.0 버전 출시를 앞두고 있습니다.
오늘날 ASPICE는 자동차 산업에서 소프트웨어 개발 프로세스를 평가하고 개선하기 위한 프레임워크로 널리 사용되고 있습니다. 이 모델은 수많은 자동차 조직에서 지원되며 업계에서 소프트웨어 개발을 위한 중요한 표준으로 인식되고 있습니다.
Automotive SPICE 구성
Automotive SPICE는소프트웨어 개발에서 이행해야 할 프로세스를 나타내는 프로세스 참조 모델(PRM: Process Reference Model)과 공급업체(Supplier) 능력 판정을 위한 평가 프레임워크를 나타내는 프로세스 평가 모델(PAM: Process Assessment Model)로 구성됩니다.
프로세스 참조 모델(PRM)은 3개의 라이프사이클 카테고리(3 LifeCycle Category), 7개의 프로세스 군(7 Process Group), 31개의 프로세스(31 Process)로 구성됩니다.
프로세스 능력 지표의 능력 수준은 레벨 5를 최상위로 6단계로 구성됩니다.
Automotive SPICE 활용
Automotive SPICE를 프로젝트에 적용하려면, 완성차 업체가 공급업체(Supplier)에게 요구하는 능력 수준과 함께 Automotive SPICE에 대한 준수를 요청할 수 있습니다.
요청을 받은 공급업체(Supplier)는 요구된 능력 수준에 따라 자사의 프로세스를 정비하고 실제 개발 프로젝트에 적용합니다. 예를 들면, 완성차 업체가 레벨 3을 요청했다면, 전사 공통의 조직 표준 프로세스를 정의하고 각 프로젝트에 맞게 테일러링(Tailoring)하여 적용해야 합니다. 완성차 업체는 공급업체(Supplier)에 대해 평가를 실시하고, 요구하는 능력 수준을 달성하고 있는지 확인합니다.
Automotive SPICE 4.0 릴리즈
프랙티스 영역 추가 및 삭제
- V3.1 모델에서 기존 10개의 프랙티스 영역이 사라집니다. ACQ.3, ACQ.11, ACQ.12, ACQ.13, ACQ.14, ACQ.15, SPL.1, SUP.2, SUP.4, SUP.7가 대상입니다.
- V4.0 모델에 10개 신규 프랙티스 영역이 추가됩니다. HWE.1, HWE.2, HWE.3, HWE.4, MLE.1, MLE.2. MLE.3, MLE.4, VAL.1, SUP.11가 대상입니다.
BP1의 Strategy와 GP2.1.1 통합, GP2.1.3, GP2.1.4 통합
- 테스트 영역, 지원영역 BP1 Strategy가 삭제됩니다.
- GP2.1.1 프로세스 속성에 Strategy가 추가되어 통합됩니다.
- GP2.1.3프로세스 속성과 GP2.1.4 프로세스 속성이 통합됩니다.
- GP3.1.2가 삭제되고 GP3.1.x과 GP3.2.x 간의 Consistency를 갖도록 변경됩니다.
Cyber Security영역과 Mechanic System Engineering 영역 Plug-in 모듈화
- Cyber Security 영역은 별도의 PAM v1.0으로 릴리즈되어 운영됩니다.
- Mechanic System Engineering 영역은 PAM v1.8로 릴리즈되어 운영됩니다.
“intacs® 교육” 워킹 그룹 현황
"intacs® 교육" 워킹 그룹은 현재 새로운 교육 자료와 일부 확장 모델의 검토하여 새로운 교육 아키텍처를 개발하여 배포를 준비하고 있습니다.
- Cyber Security, Hardware, Mechanical, Agile, Data management, Organizational, Improvement 영역 Model을 추가할 계획입니다.
- 각 모델은 1~2일 정도로 제공되며, 선임심사원 교육과정에 포함되지 않습니다.
Cybersecurity
ISO/SAE 21434 개요
ISO/SAE 21434는 도로 차량 전기·전자 시스템의 사이버보안 위험을 개념 단계부터 개발·생산·운영/유지보수·지원 종료까지 관리하는 국제표준이며, SPID는 CSMS 구축, TARA, Cybersecurity Concept·요구사항, 검증·Validation, 공급망 인터페이스 및 심사 대응을 통합 지원합니다.
표준의 목적
차량 연결성과 SW 기능 확대로 커지는 사이버보안 위험을 체계적으로 식별·처리하며, 조직 관리체계와 프로젝트 엔지니어링 활동을 함께 요구합니다.
규제와의 관계
UNECE R155는 형식승인을 위해 제조사 CSMS와 차량형식 위험관리 증적을 요구하며, ISO/SAE 21434는 이를 지원하는 대표 엔지니어링 프레임워크입니다.
적용 범위
- 개념 → 개발·생산 → 운영/유지보수 → 폐기까지 전 수명주기 적용
- OEM·Tier 1·하위 공급업체 간 분산개발·책임 인터페이스 관리
- SW·HW·통신·백엔드 연계를 포함한 차량 E/E 시스템 전체
- 조직 Governance 및 프로젝트별 Cybersecurity Plan 요구
- TARA 결과 기반 목표·요구사항·설계·검증 증적 연결
TARA 적용 시점
위협 분석 및 위험 평가 방법(Threat Analysis and Risk Assessment methods)은 사이버보안 위협이 이해 관계자에게 주는 영향을 결정하기 위해 사용되는 방법론입니다. TARA는 Concept 단계에서 시작하고, 제품 수명주기 전반에서 반복 업데이트됩니다.
-
재평가 Trigger
설계 변경 · 신규 Interface · 공급업체 변경 · 신규 Vulnerability · 현장 Incident · Software Update
-
Concept 단계
Item과 Asset을 정의하고 피해·위협 시나리오를 식별하여 초기 TARA를 수행합니다. 결과는 Cybersecurity Goal 도출의 근거가 됩니다.
-
개발 단계
Architecture, Interface, 보안 요구사항과 구현 변경을 반영하고 공격 경로, 영향도 및 공격 실현 가능성을 재평가합니다.
-
개발 후 단계
Field Monitoring에서 확인한 Event와 Vulnerability를 평가하고 Incident Response 및 Software Update 판단과 연결합니다.
TARA 수행 절차
위협 분석 및 위험 평가(TARA, Threat Analysis and Risk Assessment)는 아이템을 정의한 뒤, 보호해야 할 자산(소프트웨어, 통신 링크, 데이터 등)을 식별하는 것에서 시작합니다. 이어서 자산이 훼손되었을 때의 피해 시나리오와 사이버보안 속성을 침해하는 위협 시나리오를 정의하고, 공격 경로·공격 실현 가능성·영향도(안전·재무·운영·개인정보)를 평가하여 위험값을 산정합니다.
산정된 위험값에 따라 위험 완화·회피·전가·수용 중 처리 방식을 결정하며, 그 결과를 사이버보안 목표(Goal) 또는 클레임(Claim)에 매핑해 설계·검증까지의 추적성을 유지합니다.
보호해야 할 주요 기능, 데이터, 시스템 및 구성요소를 식별합니다.
자산의 사이버보안 속성을 침해할 수 있는 위협과 공격 목적을 구체적인 시나리오로 정의합니다.
Threat Scenario가 실현될 수 있는 취약점과 공격 단계를 분석하여 가능한 공격 경로를 도출합니다.
공격 소요시간, 전문성, 대상 정보 및 필요 장비를 기준으로 공격 경로의 실현 가능성을 평가합니다.
자산 훼손으로 발생할 수 있는 피해 시나리오를 정의합니다.
안전 · 재무 · 운영 · 개인정보(SFOP) 영향을 평가합니다.
공격 실현 가능성과 영향도를 조합하여 위험값을 산정합니다.
위험값을 기반으로 하나 이상의 위험 처리 방안을 결정합니다.
위험원 제거
(Definition Modification)
기능 삭제, 설계 변경, 운영환경 변경 등
위험을 허용 가능한 수준으로 감소
(Cybersecurity Goal)
자산을 보호하기 위한 목표를 명시(CS개념, 요구사항으로 전개)
계약, 보험 등으로 위험을 제3자에게 이전
(Cybersecurity Claim)
위험 전가 결정의 근거를 명시
잔여 위험을 수용하고 지속적으로 모니터링
(Cybersecurity Claim)
TARA에 사용된 가정에 근거하여 위험을 수용한 경우
ASPICE for Cybersecurity 개요
ISO/SAE 21434가 자동차 사이버보안 활동과 산출물에 대한 기술적·관리적 요구사항을 정의한다면, ASPICE for CS는 이러한 활동이 개발 프로세스 안에서 일관되게 수행되고 관리되는지를 평가합니다.
필요성
ISO/SAE 21434 요구사항을 문서로만 정의하면 프로젝트별 실행 수준이 달라질 수 있습니다. ASPICE 관점은 활동의 수행, Work Product 품질, 책임과 추적성을 평가 가능한 형태로 관리하도록 돕습니다.
적용 효과
- Cybersecurity 활동과 기존 SYS·SWE 프로세스의 연결
- 프로젝트 간 일관된 Work Product와 품질기준 확보
- 요구사항·위험·설계·검증 결과의 양방향 추적
- 프로세스 성과와 개선사항을 조직 자산으로 축적
Cybersecurity Engineering Process Group(SEC)
| 프로세스 | 설명 |
|---|---|
| SEC.1 Cybersecurity 요구사항 도출 |
Cybersecurity 관련 요구와 제약을 수집·분석하고 합의하며 요구사항 간 일관성과 추적성을 확보합니다. |
| SEC.2 Cybersecurity 구현 |
Cybersecurity 요구사항을 설계·구현에 반영하고 구현 결과와 관련 산출물의 일관성을 유지합니다. |
| SEC.3 Risk Treatment 검증 |
위험처리 방안이 요구사항과 설계대로 구현됐는지 검증하고 결과와 미해결 사항을 기록합니다. |
| SEC.4 Risk Treatment 유효성 확인 |
의도된 사용환경에서 위험처리가 Cybersecurity Goal과 사용 목적을 충족하는지 확인합니다. |
ISO/SAE 21434와 ASPICE for Cybersecurity 관계
ISO/SAE 21434 수명주기 요구를 ASPICE 프로세스와 수행능력 관점으로 연결합니다.
IEC 62443 개요
IEC 62443은 국제전기기술위원회(IEC)가 제정한 산업 사이버보안 표준 체계로, 산업 자동화 및 제어시스템(IACS)을 사이버 위협으로부터 보호하기 위한 요구사항과 프로세스를 제시합니다.
자산 소유자(운영조직), 서비스 제공자(통합·유지보수), 제품 공급자(개발조직) 등 역할별로 적용 범위가 나뉘어, 제조·에너지·수처리·항공 등 OT 환경에서 보안 조치를 체계적으로 적용할 수 있도록 지원합니다.
관련 인증은 문서 검토나 일회성 진단을 넘어, 실제 산업 환경에 보안이 내재화되어 있는지를 검증하는 기준입니다. OT 시스템이 고도화될수록 침해 시 생산 중단은 물론 안전·생명까지 영향을 줄 수 있어, IEC 62443 대응의 중요성이 커지고 있습니다.
IACS 보안관리체계
위험·자산·계정·패치·사고관리
솔루션 설계·통합·운영지원 과정의
보안 프로세스 요구
Secure Development Lifecycle와
구성요소 기술 보안요구
IEC 62443 인증 범위와 성숙도
IEC 62443 인증·평가는 적용 대상과 표준 파트에 따라 범위가 달라집니다. 제품 공급자의 개발 프로세스는 IEC 62443-4-1의 Maturity Level(ML), 시스템·구성요소의 기술적 보안 역량은 IEC 62443-3-3·4-2의 Security Level(SL)을 기준으로 평가합니다. 대상 표준과 인증 범위를 정한 뒤 갭 분석, 위험평가, 설계·구현 및 심사를 준비합니다.
팀 구성 · 목표 설정
내부 교육, 일정 수립
현재 상태 평가
기존 정책 · 인프라 점검
보안수준(SL) 정의
위험 분석, 공격 시나리오 설정
기술적·관리적 조치 적용
네트워크 분리, 접근 제어
공식 심사기관 인증 요청
외부 심사 및 피드백 반영
| 국제 기준 | IEC-62443 연관 영역 | 특징 |
|---|---|---|
| ISO/IEC 27001 | 조직 보안정책 · 위험관리 | ISMS 기반, 전사(全社) 적용 |
| NIST SP 800-82 | 산업제어시스템(ICS) 보안 | 미국 표준, 기술 중심 |
| NIS2 Directive | 유럽 산업 사이버보안 규정 | 법적 의무화, 벌칙 규정 포함 |
TISAX 개요
TISAX(Trusted Information Security Assessment Exchange)는 VDA ISA 카탈로그를 기준으로 자동차 공급망의 정보보안 수준을 평가하고, 결과를 ENX 포털에서 신뢰관계가 설정된 파트너와 공유하는 체계입니다. ISO/IEC 27001 기반 관리체계와 연계되며, 시제품 보호와 개인정보보호 등 자동차 산업 특화 평가목표를 추가로 다룹니다.
자동차 공급망의 요구
OEM과 협력사는 설계도, 시제품 정보, 시험 데이터 및 개인정보를 지속적으로 교환합니다. TISAX는 공급망 참여자의 보안수준을 같은 기준으로 평가하고 결과를 선택적으로 공유하여 중복 심사를 줄입니다. 고객이 요구하는 TISAX Label이 없으면 신규 거래나 프로젝트 참여가 제한될 수 있으며, 자동차 공급망의 OEM·협력사·서비스 파트너에 적용될 수 있습니다.
평가 범위
- Information Security
- Prototype Protection
- Data Protection
TISAX의 특징
- VDA가 개발한 ISA Catalog를 평가기준으로 사용
- ENX 협회 운영을 통해 참가자 등록과 평가 결과를 다른 기업과 공유할 수 있어, 글로벌 공급망에서 효율적 정보보안 관리가 가능
- Assessment Level과 Protection Need에 따라 평가 깊이를 결정
- 평가 결과를 지정된 파트너와 공유하여 중복 고객심사 부담 완화
- 국제 정보보안 표준 ISO 27001 기반의 관리체계와 연계 가능하나 자동차 특화 요구를 별도로 반영
SPID 컨설팅 서비스
SPID는 평가범위와 목표 Label 설정부터 VDA ISA Gap분석, 증적 구축과 평가대응까지 지원합니다.
- 대상 Location·Service·정보자산 확인
- Protection Need와 심사목표 설정
- ENX Portal 등록
- VDA ISA 항목별 현 수준 진단
- 목표 성숙도 대비 Gap과 위험 분석
- 개선과제·책임·일정 수립
- 정책·절차와 기술적 통제 구축
- 자산·접근·공급업체·사고·연속성 관리
- 교육과 운영 증적 확보
- Mock Assessment와 Evidence Review
- 담당자 인터뷰 준비
- Finding 분석과 Corrective Action 지원
CRA (Cyber Resilience Act)
EU CRA 개요
EU 사이버복원력법(Cyber Resilience Act, CRA, Regulation (EU) 2024/2847)은 EU 시장에 출시되는 ‘디지털 요소가 있는 제품(products with digital elements)’, 즉 네트워크나 다른 기기와 직접 또는 간접적으로 연결되는 하드웨어·소프트웨어 제품과 그 제품에 필요한 원격 데이터 처리에 대해 공통의 사이버보안 요구사항을 정한 규정입니다.
2024년 12월 10일 발효되었고, 2026년 9월 11일부터 취약점·사고 보고 의무(Article 14)가, 2027년 12월 11일부터 모든 의무가 적용됩니다. 규정(Regulation)이므로 별도의 국내법 전환 없이 모든 회원국에 직접 적용됩니다.
- 하드웨어 · 소프트웨어 · 원격 데이터 처리
- 네트워크·기기와 논리적, 물리적, 직/간접 연결
- 필수 요구사항 충족 (ANNEX I) · 위험평가 · SBOM
- 적합성 평가 · 기술문서 · EU 적합성 선언서
- 지원 기간 동안 취약점 처리 · 보고 (24h/72h)
- CRA 적합성 평가 완료 후 CE 표시
- 미충족 제품 출시 제한·시장감시·과징금
- 최대 €1,500만 또는 전 세계 연매출 2.5%
-
2024.10.23
규정 채택 유럽의회·이사회
-
2024.12.10
발효 관보 게재 20일 후
-
2025.12.11
제품 분류 기술 설명 적용 이행규정 (EU) 2025/2392
-
2026.06.11
통보기관 규정 적용 Chapter IV
-
2026.09.11
취약점·사고 보고 의무 Article 14 · 24h/72h
-
2027.12.11
전면 적용 모든 필수 요구사항 · CE 표시
제조자는 설계·개발 단계부터 지원 기간이 끝날 때까지 제품 사이버보안을 관리해야 하며(security by design), 필수 요구사항(ANNEX I)을 충족하고 적합성 평가를 마친 제품에만 CE 표시를 할 수 있습니다. 형식승인 대상 차량과 그 전용 부품(Regulation (EU) 2019/2144), 의료기기, 항공, 선박 장비 등 동등한 사이버보안 규제를 받는 분야는 제외됩니다.
위반 시 최대 1,500만 유로 또는 전 세계 연매출의 2.5% 중 큰 금액까지 과징금이 부과될 수 있습니다.
EU CRA 요구사항 및 대응
CRA는 제품의 핵심 기능이 갖는 사이버보안 위험에 따라 제품을 일반 제품, 중요 제품(ANNEX III, Class I·II), 핵심 제품(ANNEX IV)으로 나누고 적합성 평가 방식을 달리 정합니다.
제조자는 위험평가를 바탕으로 ANNEX I의 제품 보안 요구사항(Part I)과 취약점 처리 요구사항(Part II)을 이행하고 기술문서·SBOM·EU 적합성 선언서를 작성하며, 출시 후에는 지원 기간 동안 보안 업데이트를 제공하고 적극적으로 악용된 취약점과 중대한 사고를 24시간 이내 조기 경보, 72시간 이내 통보, 이후 최종 보고서로 ENISA 단일 보고 플랫폼에 보고해야 합니다(Article 14).
제품 분류와 적합성 평가 (Article 7 · 8 · 32)
- 일반 제품 Default · 자체평가(Module A)
- 중요 제품 Class I ANNEX III · 19개 유형 · Harmonised 표준 적용 시 자체평가, 그 외 제3자 평가
- 중요 제품 Class II ANNEX III · 4개 유형 · 통보기관 제3자 평가 필수
- 핵심 제품 ANNEX IV · 3개 유형 · 위임법령 지정 시 EU 인증
제조자 의무 생애주기 (Article 13 · 14 · 31 · ANNEX I · II · VII)
- 위험평가 수행 · 설계 반영
- ANNEX I Part I 적용
- 제3자 구성요소 실사
- 지원 기간 결정 · 이용자 정보
- 기술문서 · SBOM 작성
- 적합성 평가 · DoC · CE 표시
- 취약점 처리 · 보안 업데이트
- 취약점·사고 보고
- 기술문서 보관 (10년 이상)
취약점·사고 보고 (Article 14 · 2026.09.11부터)
신고 대상은 모든 취약점이 아니라, 실제 악용된 취약점과 제품 보안에 영향을 미치는 중대한 사고입니다. 제조사는 이를 인지한 뒤 아래 시한에 따라 ENISA가 구축한 CRA 단일 신고 플랫폼(SRP)으로 보고해야 합니다.
-
24시간 이내
조기 경보 활성 악용 취약점 또는 중대한 사고를 인지한 뒤 조기 경보를 제출합니다.
-
72시간 이내
상세 신고 조기 경보에 이어 취약점·사고에 대한 상세 신고를 제출합니다.
-
14일 이내
최종 보고서 · 활성 악용 취약점 시정 조치가 가능해진 뒤 14일 이내에 최종 보고서를 제출합니다.
-
1개월 이내
최종 보고서 · 중대 사고 72시간 상세 신고 이후 1개월 이내에 최종 보고서를 제출합니다.
Harmonised 표준 (표준화 요청 M/606)
기술 표준은 CRA 이행을 돕는 핵심 수단입니다. CRA 필수 요구사항에 적합함을 입증할 때, Harmonised 표준을 준수한 디지털 요소 제품은 해당 표준이 다루는 범위에서 적합성 추정(presumption of conformity)을 받습니다. Harmonised 표준은 CRA의 필수 사이버보안 요구사항을 상세 기술 사양으로 옮기며, Standardisation Regulation(Regulation (EU) No 1025/2012)에 따라 채택됩니다.
유럽위원회는 CRA를 지원하는 표준화 요청 M/606을 채택했으며, 여기에는 수평 표준과 수직(제품별) 표준을 포함한 41개 표준이 담겨 있습니다. 유럽표준화기구(ESO)가 산업계와 협력해 개발을 주도하며, 첫 요청에서는 CRA ANNEX III·IV의 중요·핵심 제품군 표준 개발이 우선됩니다. 용어, 섹터별 위험평가 방법, 공통 위협 카탈로그 등 지원 산출물도 함께 마련되고 있습니다.
EU 관보(OJ)에 등재된 Harmonised 표준을 준수하면 해당 범위에 한해 적합성이 추정됩니다. 표준 개발·등재 현황은 지속적으로 확인해야 합니다.
출처: European Commission — CRA Standardisation
ISO/SAE 21434 기반 체계를 갖춘 기업은 TARA·취약점 관리·지원 종료 관리 활동이 CRA의 위험평가·취약점 처리·지원 기간 요구사항과 상당 부분 대응되므로, 이를 기반으로 CRA 대상 제품의 요구사항 차이를 식별하는 방식으로 대응할 수 있습니다.
CRA 대응 자동화 플랫폼 Assurance Studio
Assurance Studio는 제품 전 수명주기를 포괄하는 AI-driven End-to-End Product Security 분석 및 관리 Platform입니다. CRA Compliance를 위해서 SBOM, Vulnerability Management, Risk Analysis, Remediation, Technical Documentation 및 Compliance Evidence를 제품 전 수명주기에 걸쳐 관리해야 합니다. 제품 구조 분석부터 위험 판단, 규제 증적과 출시 후 모니터링까지 하나의 흐름으로 관리합니다.
- 제품 구성 가시화: Firmware·Software·SBOM 분석과 구성요소·종속성 매핑
- 위험 기반 분석: 자산·위협·공격 경로 분석과 취약점 도달 가능성 평가
- 취약점 처리: 위험 우선순위, 조치 결정, VEX 및 Remediation 이력 관리
- Compliance Evidence: 기술문서·보고서·검토 기록을 연결한 감사 대응 증적
- 지속적 업데이트: Release 변경 비교와 신규 취약점 모니터링·재평가
일회성 Scan이 아니라 제품 전 수명주기의 보안 상태와 Compliance Evidence를 지속적으로 관리합니다.
SPID × Finite State: CRA 대응 체계
- CRA 적용 대상·제품 분류 검토
- Gap 분석 · 제품 사이버보안 위험평가
- 조직·제품별 프로세스·책임체계 구축
- 기술문서 · EU 적합성 선언 · CE 대응
- 교육 · 내부점검 · 적합성 평가 지원
- Firmware·Software·SBOM 통합 분석
- Threat Modeling · Attack Path 분석
- 취약점 Reachability · 위험 우선순위
- VEX · Remediation · 증적 이력 관리
- Release 비교 · 지속 모니터링·재평가
- CRA 대상·Gap 확인
- 제품 위험 및 취약점 분석
- 조치·증적·기술문서 관리
- 적합성 평가·CE 대응
- 출시 후 지속 관리
SPID는 Finite State의 공식 한국 파트너로서 플랫폼 도입과 CRA Compliance 체계 구축을 함께 지원합니다.
CMMI
CMMI(Capability Maturity Model Integration) 개요
CMMI(Capability Maturity Model Integration) 역사
- 미국 국방부가 소프트웨어 개발 업체의 품질과 기능을 평가하기 위해 카네기멜론대학의 소프트웨어공학연구소(SEI)를 통해 SW-CMM을 개발하였습니다.
- 30년 이상 모델이 발전하여 소프트웨어 개발 중심에서 모든 산업 분야에 적용이 가능한 통합된 CMMI 모델로 발전하였습니다.
- SEI가 CMMI Institute로 이름이 바뀌었고, 현재는 ISACA의 일원이 되었습니다.
Maturity Level 정의
- CMMI의 Maturity Level은 5단계까지 있습니다.
- Level 4와 Level 5를 High Maturity라고 부릅니다.
High Maturity 개념
- CMMI High Maturity 조직은 조직의 성과목표를 관리하기 위해 해당 프로세스의 성과기준을 설정하고, 미래의 성과를 예측하기 위한 프로세스 성과 모델을 개발해야 합니다.
- 성과기준 설정 및 성과모델 개발에는 통계 및 정량적 기법이 적용되어야 합니다.
- 실질적인 CMMI High Maturity 달성을 위해서는 CMMI Level 2, 3 수준의 개선 활동을 수행할 때부터 High Maturity에 대한 이해를 갖추어야 합니다.
CMMI 이행
CMMI V3.0 모델
- CMMI V3.0은 적용 Domain이 8개로 확대되었습니다.
- Development또는 Service Domain을 필수로 하고 다른 영역을 추가하여 심사를 할 수 있는 구조입니다.
- Practice Area는 17개의 Core Practice에 심사 대상 Domain에 해당하는 세부 Practice Area를 적용해야 합니다.
- 개발 조직에서 CMMI V3.0 심사를 진행하려면 17개의 Core Practice 영역과 2개의 Development Practice 영역을 적용하여 총 19개의 Practice Area를 준비해야 합니다.
- 협력업체 관리영역까지 확대하여 선택하면 Suppliers Domain의 Practice 1개를 추가하여 총 20개의 Practice Area를 준비해야 합니다.
컨설팅 수행 방법론
- CMMI 모델을 기반으로 현재 상태를 진단하여 개선 활동을 수행하고 조직 내에 프로세스가 내재화되도록 지속적인 점검 및 보완을 통해 성공적인 CMMI 인증 목표 달성이 되도록 컨설팅을 수행 합니다.
- 또한, 단계별로 필요한 교육, 사례 및 경험 정보를 제공하여 효과적으로 목표 달성을 할 수 있도록 도와 드립니다.
- CMMI High Maturity 조직은 조직의 성과목표를 관리하기 위해 해당 프로세스의 성과기준을 설정하고, 미래의 성과를 예측하기 위한 프로세스 성과 모델을 개발해야 합니다.
- 성과기준 설정 및 성과모델 개발에는 통계 및 정량적 기법이 적용되어야 합니다.
- 실질적인 CMMI High Maturity 달성을 위해서는 CMMI Level 2, 3 수준의 개선 활동을 수행할 때부터 High Maturity에 대한 이해를 갖추어야 합니다.
CMMI 이행
CMMI V3.0 모델
- CMMI V3.0은 적용 Domain이 8개로 확대되었습니다.
- Development또는 Service Domain을 필수로 하고 다른 영역을 추가하여 심사를 할 수 있는 구조입니다.
- Practice Area는 17개의 Core Practice에 심사 대상 Domain에 해당하는 세부 Practice Area를 적용해야 합니다.
- 개발 조직에서 CMMI V3.0 심사를 진행하려면 17개의 Core Practice 영역과 2개의 Development Practice 영역을 적용하여 총 19개의 Practice Area를 준비해야 합니다.
- 협력업체 관리영역까지 확대하여 선택하면 Suppliers Domain의 Practice 1개를 추가하여 총 20개의 Practice Area를 준비해야 합니다.
컨설팅 수행 방법론
- CMMI 모델을 기반으로 현재 상태를 진단하여 개선 활동을 수행하고 조직 내에 프로세스가 내재화되도록 지속적인 점검 및 보완을 통해 성공적인 CMMI 인증 목표 달성이 되도록 컨설팅을 수행 합니다.
- 또한, 단계별로 필요한 교육, 사례 및 경험 정보를 제공하여 효과적으로 목표 달성을 할 수 있도록 도와 드립니다.
기능안전 (ISO26262/IEC61508)
자동차에 적용되는 전기/전자 시스템의 오작동 행위로 인하여 발생하는 위험원이 원인이 되는 비합리적인 리스크가 존재하지 않도록 하기 위한 기능안전 국제규격
ISO 26262 기능안전 국제규격
자동차 전자제어 시스템이 복잡해지고 친환경 이슈로 인하여 전자제어장치(ECU) 수가 증가함에 따라 자동차 기능 안전성에 대한 중요성과 기술 표준에 대한 필요성이 커지고 있습니다.
자동차 전자제어 시스템이 복잡해지고 친환경 이슈로 인하여 전자제어장치(ECU) 수가 증가함에 따라 자동차 기능 안전성에 대한 중요성과 기술 표준에 대한 필요성이 커지고 있습니다.
정의 및 표준 개요
ISO 26262란 무엇인가?
ISO 26262란 자동차 전자제어장치 오작동으로 인한 사고 및 인명손실을 최소화하기 위해 제정한 기능 안전성 규격으로 2011년 11월 15일 국제 표준으로 발표되었습니다. 자동차에 탑재되는 소프트웨어 오류로 인한 사고를 미연에 방지하기 위해, 차량용 부품을 설계하거나 제조할 때 기능안전성을 반영해야 한다는 개념이 도입된 새로운 기능안전(functional safety)규격입니다.
세계 10개국 27개 자동차 제조사 및 부품 공급사가 개발에 참여했으며, 지난달 15일(2011년 11월 15일) 공식 발표됐습니다.(BMW와 다임러, GM, 보쉬 등 글로벌 자동차 제조기업과 부품제조사는 표준 확정 이전부터 개발 프로세스에 적용을 준비해 왔다.)
IEC 61508이 일반 전기전자 장치 안전에 관한 포괄적 기능안전 규격인데 반해, 이를 대체하는 ISO 26262는 자동차업계에 특화된 기능안전 표준입니다. IEC 61508 표준이 화학공장과 같이 주로 공정 산업에 적용되던 표준이라 자동차에 적용하는데 한계가 있었기 때문입니다.
ISO 26262는 어떤 내용을 담고 있나요?
'ISO 26262'는 기능 안전성 관리, 구상 단계(개념설계), 제품 개발(시스템 레벨, 하드웨어 레벨, 소프트 웨어 레벨), 생산 및 운영, 지원 프로세스 등 총 10개 파트로 구성됐으며 총 43개의 요구사항 및 권고 사항으로 이루어져 있습니다. 자동차 전체 시스템이 적용대상이며 개발 초기부터 생산, 폐기에 이르는 전체 생명주기에서 안전 관련 요구사항을 포함하고 있습니다.
제조사는 전체 개발 단계에서 ISO 26262 표준을 준수하였음을 문서로 증명해야 하고 안전과 관련된 사항들이 설계, 개발, 생산에의 모든 단계에서 고려되어 적절하게 반영되었음을 증명해야 합니다. ISO 26262에서는 프로세스, 위험 평가, 방법론 등 세 가지를 규정해 기능안전을 표준화하고 있습니다. 위험 노출 가능성, 위험의 잠재적 심각도, 통제 가능성에 따라 차량 안전성 보전등급을 결정합니다. ISO 26262의 차량 안전성 보전 등급인 ASIL은 자동차 제품 특성을 반영한 것으로 위험도에 따라 A~D단계로 분류합니다.
최저 등급인 ASIL A부터 최고 등급인 ASIL D까지 총 4개 등급으로 구분되며 ASIL이 높다는 것은 개발 대상의 오류로 사고가 날 경우 상대적으로 피해가 클 수 있다는 의미입니다. 위험을 줄이려면 높은 수준의 안전 메커니즘이 필요하기 때문에 안전에 대한 요구사항은 더욱 높아집니다.
영향 분석
ISO 26262 국제 표준 제청에 따른 국내 자동차 업계에 미치는 영향은?
안정성 무결함 증거 제조사가 제시해야
- 자동차 제조사(OEM) 측면
자동차 제조사의 기술적 결함에 대한 부담은 더욱 커질 것입니다. 이제까지는 자동차 기능안전 관련 사고 발생 시 자동차 기술적 결함을 소비자가 직접 증명했지만, 앞으로는 자동차 제조사가 국제 표준에 따라 안전한 차량을 개발하기 위해 충분한 노력을 기울였다는 증거를 제시해야 합니다. 그렇지 않으면 징벌적 손해 배상 책임을 져야 할 수도 있기 때문입니다. 따라서 제조사는 전체 개발 단계에서 ISO 26262 표준을 준수했음을 문서로 증명해야 합니다.
- 자동차 부품 제조사 측면
OEM요구에 선제적 대응 필요. 또 자동차 제조사에 시스템을 공급하는 자동차 부품 업체들은 각 단계별로 개발 체제 및 방식 등을 확립할 필요가 있습니다. 선진국 자동차 업계에서는 ISO 26262 준수를 위해 시스템 성숙도 모델인 CMMI 혹은 Automotive SPICE 등 소프트웨어 엔지니어링 프로세스를 지키고 있습니다. ISO 26262 기능안전규격 도입은 향후 자동차 소프트웨어의 개발 패러다임에도 큰 영향을 끼칠 것으로 예상됩니다. 기능은 점점 다양해지고 복잡해지면서도 짧은 개발 주기를 가진 자동차 산업 특성상 전 제품의 라이프사이클에 안전성과 신뢰성을 높일 수 있는 개발 프로세스를 구축해야만 이 표준을 충족시킬 수 있기 때문입니다.
SPID는
SPID는 CMMI 기반 프로세스 개선컨설팅을 통해 자동차 업계에서 인정 받은 경험을 바탕으로 고객 여러분이 ISO 26262 규격을 보다 효과적이고 체계적으로 도입할 수 있도록 지원해 드리고 있으며, 또한 개발 제품에 대한 Functional Safety 인증 서비스를 제공해 드리고 있습니다.
- ISO 26262 규격에 대한 교육(기본교육, 실무교육)
- Hazard Analysis And Risk Assessment
- FTA (Fault Tree Analysis) / FMEA (Failure Mode and Effects Analysis)
- 객관적인 ISO 26262 Compliance Level 평가 서비스 (Gap Analysis)
- ISO 26262 Functional Safety 충족 지원을 위한 국내외 전문가를 통한 컨설팅 서비스
- Functional Safety 충족을 확인하기 위한 Testing Service
- ISO 26262 프로세스 인증 서비스
반도체 기능안전 (ISO 26262-11)
반도체 기능안전이란, 반도체의 오작동 행위로 인하여 발생하는 위험원(hazard)의 원인이 되는 비합리적인 리스크(unreasonable risk)를 제거하여 반도체의 안전성을 높이는 것입니다.
반도체 기능안전 개요
반도체 기능안전 활동은 아래와 같은 활동으로 요약할 수 있습니다.
- 반도체 레벨의 안전 요구사항 도출
- 반도체 오동작을 방지하기 위한 안전 메커니즘 설계
- 반도체 안전 분석(FMEA, FTA, DFA)
- 반도체 고장률 분석을 통한 안전목표 위배 평가 (FMEDA)
- 반도체 통합 및 시험
이를 위하여 ISO 26262-11에서는 아래 그림과 같이 반도체 내부 IP(Intellectual Property)를 중심으로 반도체 회로 종류 별로 Digital, Analog, PLD(Programmable Logic Device), Multi Core, Sensor & Transducer로 분류하여 고장을 분석합니다. 고장을 회피하여 안전 상태가 되도록 안전 메커니즘을 설계하고, 설계 및 공정 단계별 검증(Verification)을 실시하고 정량적 안전분석인 FMEDA, 정성적 안전 분석인 DFA를 수행합니다. 이러한 안전활동은 안전 매뉴얼(Safety Manual)로 정리합니다.
Dividing a semiconductor component in parts
반도체는 하나의 컴포넌트(component)이며, 반도체 내부적으로 여러 파트들 (parts)로 나눌 수 있으며, 파트(part)는 여러 서브 파트들(sub-parts)로, 서브 파트(sub-part)는 여러 기본 서브 파트들(Elementary sub-parts)로 구성되어 있습니다.
Intellectual property
반도체 내부 재사용되는 모듈로서 ‘반도체 지적 자산’이라고 하며, IP 공급 업체와 IP 통합 업체 간의 인터페이스와 책임 할당에 의해 위험한 고장을 줄여야 합니다.
Semiconductor FMEDA
반도체 내부 고장률 기반 안전분석인 FMEDA는 아래와 같이 수행됩니다.
Semiconductor DFA
반도체 내부 의존고장분석(DFA)는 아래와 같이 수행됩니다.
반도체 기능안전 산출물 List
반도체 기능안전 컨설팅 서비스
SPID는 반도체 기능안전 관련하여 아래와 같은 서비스를 제공해 드리고 있습니다.
- ISO 26262-11 규격에 대한 교육
-
반도체 기능안전 엔지니어링 컨설팅
- 반도체 안전요구사항 도출
- 반도체 안전메카니즘 설계 코칭
- 반도체 안전분석(FMEA, FTA, DFA)
- 반도체 고장률 기반 안전목표 위배 평가(FMEDA : SPFM, LFM, PMHF)
- 반도체 통합 및 시험
- 반도체 기능안전 프로세스 컨설팅
- 기능안전 관리 프로세스
- 기능안전 지원 프로세스
- 반도체 기능안전 인증 서비스 (해외 인증 가능(Exida, TÜV…))
- 반도체 제품 인증
- 반도체 프로세스 인증
로봇, 제어시스템, 기계류 기능안전
로봇 시스템, 로봇 설치 라인, 일반제어시스템, 일반 기계시스템(기계시스템, 공압시스템, 유압시스템, 전기시스템), 일반 전기전자시스템(system, hardware, software, semiconductor)의 기능안전 컨설팅, 현장 안전 진단 및 가이드, 관련 교육을 제공하는 서비스입니다.
적용 대상 및 적용 Standard
적용대상
- 로봇, 로봇 제어시스템, 로봇 설치 라인, Smart factory
- 일반 제어시스템 (sensor, processor, actuator)
- 일반 기계시스템 (기계시스템, 공압시스템, 유압시스템, 전기시스템)
- 일반 전기 전자시스템 (system, hardware, software, semiconductor)
적용 Standard
- ISO 10218-1 : 산업용 로봇 기능 안전
- ISO 10218-2 : 산업용 로봇 시스템 및 통합, 로봇 설치 라인 안전
- ISO 20218-1 : 산업용 로봇 시스템 말단장치(End effectors) 안전스템)
- ISO 20218-2 : 산업용 로봇 시스템 수동 이적재대(Manual load/unlosd stations) 안전
- ISO 13849-1 : 기계안전-제어시스템 안전관련 부품 설계 원칙
- ISO 13849-2 : 기계안전-제어시스템 안전관련 부품 검증
- ISO 12100 : 기계안전-위험성평가와 위험성 감소
- IEC 61508 : 전기/전자/프로그램 전자 안전관련 시스템
로봇 시스템 안전
ref. https://www.worksafe.govt.nz/topic-and-industry/manufacturing/safe-use-of-machinery/, Figure 34
- 성능요구사항(PL:Performance Level)
- 비상정지 / 보호정지
- 감속제어 (TCP : 250 mm/s 이하)
- 협동운전 요구사항
- 위험원 인지와 위험도 평가
- 본질적인 안전설계 요구사항
- 보호수단 요구사항
- 안전 요구사항 및 보호 대책에 대한 확인 검증
- 사용정보에 대한 요구사항
주요 위험원
ref. https://www.worksafe.govt.nz/topic-and-industry/manufacturing/safe-use-of-machinery/, Figure 7
- 기계적 위험원
- 전기적 위험원
- 열에 의한 위험원
- 소음에 의한 위험원
- 진동에 의한 위험원
- 방사선에 의한 위험원
- 재료/물질에 의한 위험원
- 인체공학적인 위험원
- 기계가 사용되는 환경에 관한 위험원
- 여러 위험원의 결합
안전요구사항 및 대책의 확인 수단
- A : 육안검사
- B : 실제 시험
- C : 측정
- D : 운전 중 관찰
- E : 응용별 구성도 및(또는) 회로도 및 설계 재료에 대한 검토
- F : 작업기반 위험도 평가 검토
- G : 사양 및 사용 정보에 대한 검토
위험성 감소 과정
반복적 3 단계 방법을 포함하는 위험성감소 과정의 도해
제어시스템의 안전관련 부품(SRP/CS)의 반복적인 설계절차
안전기능에 요구되는 PLr 결정을 위한 위험성 그래프
범주에 따른 지정된 architecture
범주B, 1
범주2
범주3, 4
Performance Level 결정
각 채널의 위험한 평균 고장시간 (MTTFd)
진단범위(DC)
SRP/CS에 의해 달성되는 PL을 결정/결과평가하기 위한 단순화된 절차
검증과정의 개요
- 분석에 의한 검증
- 시험에 의한 검증
- 안전기능의 안전요구사항 규격 검증
- 안전기능의 검증
- 성능수준 및 범주의 검증
- 환경 요구사항의 검증
- 유지관리 요구사항의 검증
- 기술문서 및 사용자 정보의 검증
- 기본 안전원칙
- 충분한 시험을 거친 안전원칙
- 결함과 결함 제외
로봇, 제어시스템, 기계류 기능안전 컨설팅 서비스
산업용 로봇 관련 컨설팅
- 산업용 로봇 시스템 현장 안전 진단 및 가이드
- 산업용 로봇 시스템 위험성 평가 컨설팅
- 산업용 로봇 시스템 안전 설계 컨설팅
- 산업용 로봇 시스템 검증 컨설팅
- 산업용 로봇 시스템 국제 인증 서비스
- 산업용 로봇 시스템 안전 교육
일반 기계 및 전기전자 시스템 관련 컨설팅
- 일반 기계 및 전기전자 시스템 현장 안전 진단 및 가이드
- 일반 기계 및 전기전자 시스템 위험성 평가 컨설팅
- 일반 기계 및 전기전자 시스템 안전 설계 컨설팅
- 일반 기계 및 전기전자 시스템 검증 컨설팅
- 일반 기계 및 전기전자 시스템 국제 인증 서비스
- 일반 기계 및 전기전자 시스템 안전 교육
선박 자율운항 기능안전
선박 자율 운항의 핵심 시스템인 선박 자율 운항 시스템의 기능안전 적용을 위한 컨설팅을 제공합니다.
IMO의 선박자율운항 단계 구분
ref. IMO MASS Autonomous Resulting from MSC100 3.1.6
선박 자율 운항 시스템의 일반적인 구성
ref. 그림 2.1, 자율운항선박 지침, 한국선급
선박 자율 운항 시스템의 주요 기능
ref. https://www.worksafe.govt.nz/topic-and-industry/manufacturing/safe-use-of-machinery/, Figure 7
선박 자율운항 적용 Standard
철도 산업 분야 시스템 및 SW엔지니어링
SPID는 국내외 철도 산업분야 시스템의 설계 강건성 및 안전성 확보를 위해 시스템엔지니어링 서비스와 IEC-62278/IEC 62279에 부합하는 SW 엔지니어링 서비스를 제공합니다.
철도 차량 및 시설 관련 전기/전자 시스템의 안전 설계 가이드 개발 경험과 기술을 기반으로 SIL 인증 대응을 위한 최고 수준의 엔지니어링 서비스를 제공합니다.
시스템/SW엔지니어링 서비스
- 시스템/SW 요구사항 개발
- 시스템/SW 기능 분석 및 개발
- 시스템/SW 설계 사양서 개발
- 시스템/SW 모델링 및 설계
- 요구사항 및 형상관리 방안 서비스 제공
- 시스템/SW 안전요구사항 분석 및 개발
- 시스템/SW 설계 적합성 검토 컨설팅 제공
SW SIL 인증 대응 서비스
- SIL 대응 SW 안전요구사항 명세 가이드 및 코칭
- SIL 대응 SW 아키텍처 설계 가이드 및 코칭
- SIL 대응 SW 정적 및 동적 검증 가이드 및 코칭
- SIL 대응 품질보증 계획 가이드 및 코칭
- SIL 대응 형상관리 계획 가이드 및 코칭
철도분야 사업실적
| 고객사 | 사업명 | 수행 기간 |
|---|---|---|
| 우진산전 | 서울4호선 및 부산양산선 신조차량 시스템 및 하부장치 SW 활동 대응 컨설팅 | 2023-08 ~ 2024.12 |
| 우진산전 | 부산1호선 및 별내선(서울 8호선) 차량 시스템 및 하부장치 SW 활동 대응 컨설팅 | 2022-05 ~ 2023.12 |
| 우진산전 | PSD 시스템 SIL3 인증 대응 산출물 용역 | 2019-08 ~ 2020.12 |
| 정보통신산업진흥원 | 철도 분야 SW신뢰·안전성 확보를 위한 가이드 개발과 시범적용 (철도 SW분야 형식인증 대응을 위한 가이드 – 철도기술연구원 자문) |
2017-05 ~ 2017-11 |
| KT(공항철도공사) | 공항철도 열차무선설비 RAMS 컨설팅 용역 | 2017-04 ~ 2018-01 |
| 정보통신산업진흥원 | 철도 분야 SW신뢰·안전성 확보를 위한 가이드 개발과 시범적용 (철도 SW분야 형식인증 대응을 위한 가이드 – 철도기술연구원 자문) |
2016-07 ~ 2016-12 |
| 한국철도기술연구원(KRRI) | 시스템 엔지니어링 기반의 신규 BCT 신호시스템 설계 안전성 활동 용역 | 2016-04 ~ 2016-10 |
