Category Archives: Security

(Paper Comment) Integrated Safety and Security Development in the Automotive Domain


이 논문을 한마디로 요약하자면, FuSa+Cyber Security계의 광맥이라고 볼 수 있겠다.

이 논문의 focus는 시스템 안전성과 사이버 보안을 독립적이 아닌 결합하여 해결함으로써 상호 영향에 대한 인식을 높이는 데 있다고는 되어 있기는 하지만, 사실 굉장히 방대하게 cover를 하고 있고, 관련 연구를 reference를 달고 있다.

읽고나서는 우와~ 하게 되지만 한마디로 요약하라고 한다면.. 딱히 어떻게 설명하기가 애매.

어쨌거나 유용하다고 생각되는 reference들을 정리하기로 한다.

여기 reference되어 있는 것들 중에 뭘 처음부터봐야 할 지가 심히 고민된다….(왜 이렇게 많아..)

 

Gashi [12]의 연구는 중복성, 다양성 및 임베디드 시스템의 안전 및 보안에 미치는 영향에 중점을 둡니다. 이 작업은 SeSaMo (임베디드 시스템의 보안 및 안전 모델링) 프로젝트의 일부이며, 구체적인 사용 사례를 통한 보안과 안전의 시너지 효과와 상충 관계에 중점을 둡니다.

12. Gashi I., Povyakalo A., Strigini L., Matschnig M., Hinterstoisser T., and Fischer B.. „Diversity for Safety and Security in Embedded Systems”. In International Conference on Dependable Systems and Networks, volume 26, 2014

http://sesamo-project.eu/documents

 

최신 ESCL 시스템은 명백한 안전 및 보안 관련 특성과 시스템 요소, 기본 기능 및 관련 외부 시스템과 관련하여 관리 가능한 복잡성으로 인해 대표적인 안전 및 보안 관련 사용 사례입니다.

따라서 이 사용 사례는 교육 목적으로도 사용되며 철저하거나 상업적으로 민감한 프로젝트를 나타내지 않습니다. 제시된 유스 케이스는 SoQrates 이니셔티브와 긴밀히 협력하여 정교하게 작업되었으며, 주요 작업 그룹의 여러 주요 자동차 공급 업체의 전문가를 통합합니다 [24].

  1. http://soqrates.eurospi.net/

 

 

Initial Cybersecurity and Safety Assessment

사이버 보안 위협 및 안전 위험에 대한 초기 평가를 위해 HARA와 TARA를 결합한 SAHARA 방법 [19]을 적용했습니다. SAHARA 방법의 개념 세부 사항과 ESCL에 대한 자세한 응용 프로그램은 [25]에서 찾을 수 있습니다.

[25] Integrating HARA and TARA – How does this fit with Assumptions of the SAE J3061

 

Security-by-Design
[27]에 따르면 설계별 보안에는 다음과 같은 모범 사례가 포함됩니다.
· 초기 개발 단계 및 주요 개발 단계 (주로 설계 결정이있는 단계)에서 보안 위험 고려
· 잠재적 위협 및 공격 대상 식별 및 해결
· 적절한 공격면(attack surface reduction) 축소 방법
· 계층화 된 사이버 보안 방어 (심층 방어)
· 신뢰 경계 식별
(생략)

27. Automotive Information Sharing and Analysis Center AUTO-ISAC, “Automotive Cybersecurity Best Practices Executive Summary”, 2016

 

 

Layered Cybersecurity Defense (Defense-in-Depth)
심층 방어 접근 방식의 기본 개념은 몇 가지 독립적인 방법을 사용하여 특정 공격으로부터 시스템을 방어하는 것입니다. 계층 중 하나라도 보호에 실패하면 다음 계층이 보호를 제공합니다. 이러한 아키텍처 심층 방어 접근법은 일반적으로 [28, 29]에 의해 자동차 시스템 및 특히 [30]에 의해 차내 인포테인먼트 시스템에 대해 제안된다.

  1. Brown D., Cooper G., Gilvarry I., Rajan A., Tatourian A., Venugopalan R., Wheeler D., and Zhao M., “Automotive Security Best Practices,” White Paper, 2015

  2. Hahn, T.; Matthews, S.; Wood, L.; Cohn, J.; Regev, S.; Fletcher, J.; Libow, E.; Poulin, C. & Ohnishi, K. “IBM Point of View: Internet of Things Security”, 2015.

 

 

 

Identification of Trust Boundaries
신뢰 경계 식별을 지원하기 위한 적절한 체계적인 접근 방식이 필수적입니다. [32]에서는 ISO 26262 기능 안전 개발 프로세스의 중심 개발 아티팩트 인 하드웨어 소프트웨어 인터페이스 (HSI)를 기반으로하는 신호 인터페이스를 통해 복잡한 시스템에서 신뢰 경계 및 공격 벡터를 식별하는 방법을 제안합니다. 이것은 앞에서 언급 한 계층화 된 사이버 보안 방어 접근 방식의 개념을 따릅니다.

  1. Macher, G.; Sporer, H.; Brenner, E. & Kreiner, C. “Supporting Cyber-security based on Hardware-Software Interface Definition Systems”, Software and Services Process Improvement – 23nd European Conference, EuroSPI 2016 Proceedings, Springer, 2016.

현재 보안 설계 조정에 대한 표준화가 확립되지 않았으며 보안 컨텍스트를 제공하는 방법을 결정하는 것은 제조업체의 책임입니다. ECSL의 경우 표 5에 설명 된 서로 다른 보안 수준 ([34] 기준)에 대한 신호 보안에 대한 설계 지침이 작성되었습니다.

  1. Otsuka, S., Ishigooka, T., Oishi, Y., and Sasazawa, K., “CAN Security: Cost-Effective Intrusion Detection for Real-Time Control Systems,” SAE Technical Paper 2014-01-0340, 2014,

(paper comment) Safe and Secure Development; Challenges and Opportunities


Functional Safety와 Cyber Security간 발생할 수 있는 충돌상황이 어떤 것들이 있을 수 있는지, 이에 대해 어떤 점들이 아직 해결되지 않은지에 대한 내용을 다루고 있으며, 이를 통해 미래의 자동차가 어떻게 개발되어야 하는지에 대한 hint를 조금은 얻을 수 있다.

FuSa와 Security의 차별점.

1) HARA는 고정된 target인데 반해서 TARA는 moving target이다.

FuSa의 경우, vehicle function은 자동차 concept개발시에 결정된다. 그리고 operation environment도 역시 어느정도 결정이 되어 있다. 그렇다면 거의 모든 것이 결정된 상황에서 주행시나리오에 대해 risk를 평가하게 되므로 어느정도 그 결과는 안정적이고 시간이 바뀌어도 달라질 가능성이 거의 없다.

반면 Security의 경우, vehicle이 다른 네트워크 노드와 연결되게 되면서 누구와 붙느냐는 현재 시점에서 결정적이지 않다. 다른 어떤 취약점을 가진 녀석 때문에 그 녀석과 연결되어 공격을 받을 수도 있다. vehicle의 외부는 시대에 따라 바뀔 수 있고 그렇기 때문에 TARA의 결과는 moving target을 잡으려고 하는 것과 비슷하다.

이것만 놓고 보면, 보안 취약성이 나올때마다 windows update하듯이 vehicle software도 update를 해야 할 필요가 생긴다고 볼 수 있다. manual reprogramming을 하게 된다면 어떻게 될지…현실적이지는 않을 것 같다.

2) 안전 목표와 보안 목표가 서로 충돌할 수 있다.

논문에서는 중앙도어 잠금기능을 사례로 들었다. 보안 관점에서는 잠금되어 있는 상태가 secure하다고 볼 수 있을 것이지만, safety관점에서는 어떤 안전상의 문제로 인해 잠금해제 되어 있는 상태가 safe state라고 볼 수 있다. 이런 두 가지 목표가 충돌할 수 있는 상황이 발생할 수 있기 때문에,  이것은 전적으로 자동차 concept을 개발하는 OEM의 개발전략에 의존적이라고 볼 수 있다. FuSa만 놓고 개발하는 것이 향후에는 적절하지 않을 수 있다는 말이 된다. Security 요구사항을 같이 검토하고 consistency checking을 해 봐야 한다는 의미가 된다.

사이버 보안 위협과 관련된 위험이 기능 안전 위험보다 훨씬 높으면 일부 충돌 상황에서 보안 우선 순위를 결정할 수도 있다. 이는 안전 및 보안과 관련된 전반적인 위험을 수용 가능한 수준으로 줄이기 위해 각 분야는 공동 전략을 개발할 수 있도록 각각 다른 분야의 목표와 전략을 알고 있어야 한다는 것을 의미한다. 

 

3) mechanism이 서로 충돌할 수 있다.

위에서 언급한 최종 도달해야 하는 safe state가 다르기 때문에 이에 대한 해결책도 달라질 수 있다는 얘기..

 

향후에는 safety의 약점을 악용하여 공격자가 security공격을 할 수도 있기 때문에, 이 부분에 대한 두 가지 측면을 모두 고려하고 충분히 숙지한 후에 개발이 되어야 할 것으로 보인다.

FuSa도 태산인데, security가 붙으면 이건 뭐가 될지…

제 3자 평가가 할 수 있는 것과 없는 것


다음의 논문을 읽다가 문득 든 생각이다.

Security Process Capability Model Based on ISO/IEC 15504 Conformant Enterprise SPICE

SPICE기반으로 보안 프로세스 역량 성숙모델을 개발한 논문이다.

다음과 같이 프로세스를 만들었다. 훌륭하다.

PRIM.RISK.1. Security Vulnerabilities

Purpose Outcomes
To identify, analyze and report information security vulnerabilities of an artifact to be protected 1) Information security vulnerability analysis strategy is developed and maintained;
2) Vulnerabilities are identified;
3) Vulnerabilities are analyzed;
4) Dependent vulnerabilities are derived;
5) Information security vulnerabilities are reported.
Base Practices
PRIM.RISK.1.BP.1: Develop and maintain information security vulnerability analysis strategy. [Outcome: 1]

PRIM.RISK.1.BP.2: Identify vulnerabilities. [Outcome: 2]

PRIM.RISK.1.BP.3: Analyze vulnerabilities. [Outcome: 3]

PRIM.RISK.1.BP.4: Derive vulnerabilities. [Outcome: 4]

PRIM.RISK.1.BP.5: Report information security vulnerabilities of an artifact. [Outcome: 5]

 

문제는 저렇게 한건 좋은데, 그래서 security를 달성했다는 것을 검증하는 입장에서는 어떻게 확인할 수 있을까? 저렇게 하라는 대로만 하면 되는건가?

 

사람은 누구나 옷을 입는다. 정상적이지 않은 일부의 사람들이 공원에서 홀랑 벗고 돌아다니다가 경찰에 붙잡히기도 하지만..

옷을 잘 입기 위한 프로세스를 만든다고 치자.. 목적은 멋쟁이가 되기 위한 것일 것이다. 그래도 그런 절차가 목적을 달성해주지는 못할 것이다. 그렇게 해도 패션 테러리스트들에게 있어서 달라지는 것은 없을 것이라 본다.

위의 논문에서도 만든건 좋고 훌륭하다. 그 자체에 대해 뭐라고 하고 싶은건 아니다. 다만 그 행위가 과연 충분히 달성되었는지를 어떻게 입증할 것인지에 대해서는 답을 줄 수가 없다.

제 3자 평가라고 하는 것이 그것이 safety가 되었건 security가 되었건 제 3자가 product에 대한 기본적인 지식이 별로 없는 사람들이 safety/security의 충분성을 평가하기가 쉬울까?

제 3자 평가자라고 하더라도 사람마다 평가 기준이 각기 다를 것이고, 그것을 specification하는 것은 굉장히 어려울 것이다. 그리고 그렇게 하는 순간, 그것을 비웃으면서 우회할 수 있는 수많은 방법들이 생겨나게 될 것이다.

여러모로 굉장히 어려운 일이다. 이런점에서 제3자가 security나 safety에 대해 평가한다는 것은 일정정도 한계를 가질 수 밖에 없고, 그들이 아무리 평가를 한다고 해도 완전하게 할 수는 없다.

하지만 관리적인 차원의 활동은 좀 얘기가 달라질 수 있다. management측면의 프로세스 활동에 대해서는 엄격한 기준과 잣대를 표준화시킬 수 있다.

 

패션 테러리스트들에게 패션 리더가 되기 위해서는 무엇이 필요할까? 프로세스가 필요하다고 생각하는가? 우스운 일일 것이다. 감각을 갖춘 best practice를 보면 될까? 조금은 나아질 것이다. 그렇다고 없던 감각이 생겨나진 않지 않을까? 여전히 어설프고 이상한 복장이 되지 않을까?

패션리더가 되었다는 것을 평가를 제 3자 평가자가 한다고 하면, 그런 sense에 대해 객관적이고 표준화시킬 수 있는 지표라는 것이 존재할 수 있을까? 제 3자 평가라는 것이 가능하기나 한건가? AI가 바둑도 정복하고 스타크래프트도 정복하려고 하는 마당에 언젠가는 정량화 시킬 수는 있을거라고 생각하는데, 현재로서의 ‘나’는 아직 답을 모르겠다.

safety나 security도 이와 유사하지 않을까 하는것이 개인적 생각이다. 최신 자료 계속 리서치하고, best practice를 계속 따라하는 수 밖에 없다. 그것이 패션 테러리스트들의 슬픈 숙명이다.