2024-08-20

正確性、完全性、一貫性の出典はどこなのだろうか？

現時点での候補は、
IEEE Std 830, "IEEE Recommended Practice for Software Requirements Specifications"
いくつかバージョンがあって、1998年版があたらしい。

ソフトウェア要求仕様が持つべき指標として、以下の８項目が挙げられている。
a) Correct;
b) Unambiguous;
c) Complete;
d) Consistent;
e) Ranked for importance and/or stability;
f) Verifiable;
g) Modifiable;
h) Traceable.

ただし、Correctnessではなく、Correctになっていて、且つ３つ以外にもあるので、これが原典なのかがわからない。
意味は読み取ることができるが、要求仕様を定義する側の立場になっており、要求仕様書をもとにブレイクダウンする側の立場の定義になっていない。

例）
An SRS is correct if, and only if, every requirement stated therein is one that the software shall meet.
SRS は、そこに記載されているすべての要件がソフトウェアが満たすべき要件である場合に限り、正しいものとなります。

2024-08-16

S.T.R.I.D.E. model

[1]
Loren Kohnfelder and Praerit Garg (April 1, 1999). "The threats to our products". Microsoft Interface
https://shostack.org/files/microsoft/The-Threats-To-Our-Products.docx

[2]
Shawn Hernan, Scott Lambert, Tomasz Ostwald and Adam Shostack (November 2006). "Uncover Security Design Flaws Using The STRIDE Approach," MSDN Magazine
http://msdn.microsoft.com/en-us/magazine/cc163519.aspx

Element	Spoofing	Tampering	Repudiation	Information Disclosure	Denial of Service	Elevation of Privilege
Data Flows	-	X	-	X	X	-
Data Stores	-	X	-	X	X	-
Processes	X	X	X	X	X	X
Interactors	X	-	X	-	-	-

Elevation of Privilegeは、Processにのみ紐付けられているが、車両レベルのリスクアセスメントではProcessを考慮することは困難である。よって、使い所が難しい。また、そもそもこの表は、Microsoftにおけるソフトウェア開発のセキュリティのためのものであり、そのまま車両レベルのリスクアセスメントに適用すべきではない。

この資料では、セキュリティ属性とSTRIDEとが1対1で対応している。

Spoofing	Authentication
Tampering	Integrity
Repudiation	Non-repudiation
Information disclosure	Confidentiality
Denial of service	Availability
Elevation of privilege	Authorization

[3]
Microsoft Threat Modeling Tool 2014
https://www.microsoft.com/en-us/download/details.aspx?id=42518

2024-08-15

Draft of item definition

List

Process

Service tool
- DoCAN
- DoIP
Debug tool
Entry point
- Attack feasibility = High
- Attack feasibility = Middle
- Attack feasibility = Low
Sensor
- Attack feasibility = Middle
- Attack feasibility = Low
ECU
- ECU with entry point
- ECU without entry point
- Accessory
- OTA master *1
Other microcontroller in ECU
Other VM
Other container
OTA master *1
Hypervisor
Execution environment for App
CarPlay / Android auto

memo:

車両レベルのリスクアセスメントでは、一般的にソフトウェアそのものの脆弱性は考慮する必要がないが、Appの実行環境では無視できない。
他部品との非デジタル通信のじか線接続は、Sensor / Actuatorとみなす。

Data flow

Digital path
- LIN
- CAN / CAN FD
- FlexRay
- USB
- Ethernet
- MOST（Media Oriented System Transport）
Multimedia path
- HDMI
- LVDS
Non-digital path
- Analog
- PWM
- High / Low
Unused connector
Connection in ECU
Connection in PCB
Connection in microcontroller
Memory
- Memory in microcontroller
- Memory in ECU (Out of microcontroller)

memo:

通信規格に加え、ドアの施錠をしたままアクセスできるかでAttack feasibilityが変わる。
同じDigital pathであっても、例えばCANとEthernetとでは、物理攻撃をするためのAttack feasibilityが変わる。

Data store (Asset)

Data
- Program / Parameter
  - Factory-fitted
  - App
- Financial data
- Privacy data

memo:

Commandには、Actuatorへの指示も含まれる。

Combination

Attack feasibilityは、Iterator or ProcessとData flowとの組み合わせで決まる。

example:

Iterator or Process	Data flow	Attack feasibility	Aftermarket
ECU without entry point	CAN	Low	-
Accessory	CAN	Low	o

memo:

センサーとアクチュエータは別のものであるが、ひとまとまりにすることで入出力の一方向性がなくなり、ほかのProcessと統一に扱えるようになる。

2024-06-10

ニデックインスツルメンツランサムウェア被害

www.nidec.comhttps://www.nidec.com/-/media/www-nidec-com/nidec-instruments/corporate/news/2024/20240610.pdf

このたび、当社において２０２４年５月２６日に外部の悪質なる集団からサイバー攻撃を受け、複数
のサーバ内ファイルが暗号化されるランサムウェア被害が発生したことをお知らせ致します。本件に
ついて、現在全社対策本部を設置し、外部専門家の助言を受けながら、影響の範囲等の調査と復旧へ
の対応を進めております。また、当社にて本インシデント発生直後より、警察などの関係機関への相
談を開始しており、対応についてご指導をいただいております。
現時点では、データ漏洩の範囲を明確に特定することは出来ておりませんが、本件を徹底的に調査し、
早期の解明と、再発防止にむけての、今後のあらゆる予防措置を講じて対応してまいります。
このたびの事件は、弊社への犯罪的攻撃として、社内業務に著しい障害を生じさせたと共に、お取引
様、関係先の皆様に大変なるご不安とご迷惑をおかけすることとなり、深くお詫び申し上げます。当
社は、本件の迅速かつ適切な解決に、あらんかぎりの必要とするリソースを全力で投入し、情報のセ
キュリティを当社の最優先事項として、本件解決にむけ最善を尽くし対応にあたる所存であります。