Category Archives: Related areas

(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가 붙으면 이건 뭐가 될지…

View Points in the Architecture


Purpose of the design is to help stakeholders to understand author’s intent. To do this, having several view points are necessary. But what happens if an author tries to contain all knowledge in one view?

As I know, an engineers knows too much and it prohibit him to explain simply. She/He might think that the reason the other persons do not understand her/his documents is humble knowledge that readers have. It may be true, but too much information do not help readers to understand author’s point.

To achieve this, proper abstraction is necessary. Less important parts are recommended to be deleted to help reader’s understanding. Or proper hierarchical structure helps readers to understand.

When we think why this documents are existing, purpose of the document is to let others understand author’s point. By the reason, viewpoints are necessary.

When we consider a design in the system level, he/she wants to communicate to hardware and software team. As you know, One to One communication is better than multi to multi. System designer’s point of view, a viewpoint specific to software is easy to communicate than a viewpoint to all.

And many contents are contained in the design, readers don’t like to read because too much information is contained. They will lost their concentration and miss some contents. This situation will not be what the author want to.

Do not try just to contain all knowledge that you know in the design. Functional safety manager has to help engineers to write documents by guidelines, policies. In the functional safety standards, not only system design but also SW/HW design is required. To have balance between system, SW and HW design, structure and contents detail level needs to be considered. And proper viewpoints are required to guide engineers’ documentation.

As I emphasized in the previous post, scope of safety analysis depends on what engineers contain in the design document. If they omit some view points, safety analysis for the missed contents cannot be analyzed.

 

Related Article(in Kor)