侵入検知(Adaptive Platform R23-11)

# はじめに
Adaptive Platformの侵入検知の仕様について確認した結果を残す。
APIの詳細などは記載しない。
だいたいの機能の概要が掴めることが目的。

参照文書：

https://www.autosar.org/fileadmin/standards/R23-11/AP/AUTOSAR_AP_SWS_IntrusionDetectionSystemManager.pdf

# 5 Dependencies to other Functional Clusters
他機能との関係：
![スクリーンショット 2024-01-21 11.52.07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1878269/7e42792e-90e3-e031-04b4-7a76bf8b4407.png)

侵入検知のIFを使う関係にあるのは、「Firewall」「Communication Management」「Daignostic Management」
すべてセキュリティイベントを通知するために「EventReporter」というIFを使う。

Adaptive Applicationも使用するのではないかと思うが記載はない。

# 5.2 Required Interfaces
逆に侵入検知が必要とするIF：
![スクリーンショット 2024-01-21 11.55.30.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1878269/819ca81a-915f-66b8-b44d-d26eebb4af24.png)

侵入検知が使うサービスと目的を示す。

| サービス | 目的 |
| ---- | ---- |
| Cryptography | セキュリティイベントに署名付与 |
| Log and Trace | 標準化されたメッセージでログ記録 |
| Time Synchronization |  セキュリティイベントのタイムスタンプ決定 |

# 7 Functional specification

ara::core::Intitializeとara::core::Deinitializeを使用して、アプリケーションはara::idsmライブラリを初期化および非初期化することができる。

[SWS_AIDSM_00001]{DRAFT} ⌈ ara::core::Intitialize が呼び出されると、IdsM はマニフェスト情報を読み込み、アプリケーションからイベントを生成するために必要なアクセス構造を準備する。

[SWS_AIDSM_00002]{DRAFT} ⌈ ara::core::Deinitialize が呼び出されたとき、IdsM は獲得したすべてのハンドルを閉じ、すべてのアクセス構造体を解放する。
アプリケーションはara::core::Intitializeの前やara::core::Deinitializeの後にIdsMのAPIを呼び出さないことが期待される。

## 7.2 Event Generation
SWCL（Software Cluster） と FC(Functional Clusters) は、IdsM API を使用して新しいセキュリティ・イベントを生成できます。
SWCL によって生成できるイベント・タイプは、マニフェストで構成され、SWCL のポート・プロトタイプにリンクされます。

新しいイベントの生成には 3 つのステップがある：

1. PortPrototype の shortName パスを使用して、イベント・タイプをパラメータとして参照する InstanceSpecifier オブジェクトを構築します。
2. InstanceSpecifierを渡して、ara::idsm::EventReporterオブジェクトを構築する。
3. ara::idsm::EventReporter オブジェクトで ara::idsm::EventReporter::ReportEvent 関数を呼び出します。


ara::idsm::EventReporter::ReportEvent関数を使用して、アプリケーションはオプションでタイムスタンプ、カウンタ、コンテキストデータを提供することができます。

## 7.3 Reporting Mode
IdsM は報告された SEv 毎のモードを決定しないといけない。
（どんなセキュリティイベントはどこまで残すのか、フィルターかけるのかなど）

| モード | モード選択時の振る舞い |
| ---- | ---- |
| OFF | SEvをそれ以上処理することなく破棄する。 |
| BRIEF | SEvがコンテキストデータを含んで報告された場合、IdsMはそのコンテキストデータを以降の処理、伝送、保存から破棄しなければならない。 |
| DETAILED |  SEvがコンテキストデータを含んで報告された場合、IdsMはQSEvの送信または永続化のためにコンテキストデータを保持する。 |
| BRIEF_BYPASSING_FILTERS |  IdsMは、フィルターチェーンを適用することなく、コンテキストデータを含まないSEvを報告または保存する。 |
| DETAILED_BYPASSING_FILTERS |  IdsMは、フィルターチェーンを適用することなく、SEvをコンテキストデータ（センサーから提供された場合）付きで報告または保存する。 |

## 7.4 Context Data Modification
コンテキストデータは、API「ara::idsm::ContextDataProvider」を使って修正できる。
コンテキストデータのサイズが定義したサイズより大きい場合は違反として処理する。

# 7.5 Filter Chain

SEv が報告されると、IdsM は報告された SEv にマッピングされたフィルタチェーンを適用する。

フィルタチェーンは以下から構成される：
1. MachineState フィルタ
1. Forward-Every-nth フィルタ
1. Aggregationフィルタ
1. Thresholdフィルタ

IdsM は、1.〜4.の順番で、全てのフィルタを評価する。

1つのフィルタの評価で SEv がドロップされた場合、IdsM は追加のフィルタを評価してはならない。
設定されたフィルタチェーンが正常に評価された後、セキュリティイベントを適格（QSEv）と定義する。
設定に応じて、QSEvはIdsRに送信されるか、ローカルに保持される。

※7.5.1 Machine State Filter 〜 7.5.4 Threshold Filterは飛ばす。

# 7.6 Timestamp
タイムスタンプはオプションであり、様々な方法でIdsMに提供できる。
設定されていない場合、IdsMはQSEvにタイムスタンプを追加せず、イベント報告インタフェースのtimestampパラメータ経由で提供されたタイムスタンプを無視する。


# 7.7 Propagation of QSEvs

IdsM APIを通じて生成されたセキュリティ・イベントは、以下で規定されたプロトコルでIdsRに送信する。

https://www.autosar.org/fileadmin/standards/R23-11/FO/AUTOSAR_FO_PRS_IntrusionDetectionSystem.pdf

プロトコルの概要：
![スクリーンショット 2024-01-21 12.03.59.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1878269/46d4cabf-d405-f6e4-ae5b-93505fa656e4.png)

# 7.8 Authenticity of Transmitted QSevs
IdsMはオプションで、署名を使用して送信されたQSEvsの真正性を保護できる。
どのデータに対して署名を計算し、IdsRに送信するメッセージにどのように署名を含めるかは、 [Specification of Intrusion Detection System Protocol](https://www.autosar.org/fileadmin/standards/R23-11/FO/AUTOSAR_FO_PRS_IntrusionDetectionSystem.pdf)に規定されている。
また、どの署名プリミティブを使用し、どの鍵を使用するかは、IdsmSignatureSupportApによって、設定することができる。

![スクリーンショット 2024-01-21 22.42.34.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1878269/6f9c7a7f-b5df-fa34-dc2e-a663e25f21a6.png)

# 7.9 Rate & Traffic Limitation

・レート制限
IdsM は、QSEv の送信により、IdsmRateLimitation.timeInterval で指定される現在のインターバルで送信される QSEv の数が、IdsmRateLimitation.maxEventsInterval で設定される最大送信数を超える場合、QSEv をトランスミッションからドロップするものとする。

・トラフィック制限
IdsM は、QSEv の送信によって、IdsmTrafficLimitation.timeInterval で指定された現在のインターバルで送信されるバイト数が、IdsmTrafficLimitation.maxBytesIntervalで設定された最大バイト数を超える場合、QSEv を送信からドロップする。

# 7.10 Access Control
IdsM は、以下を設定した範囲に制限する。
・プロセスが生成できるイベントタイプ
・TimestampProviderインターフェースを介してタイムスタンプを提供できるプロセス
・ContextDataProviderインターフェースを介してコンテキストデータを変更できるプロセス

# 7.11 Diagnostic Access
IdsMでは、2つのユースケースがある。
1. 永続化されたイベントの読み出し(7.11.1)
1. レポートモード（7.3で説明）の再設定(7.11.2)
※セキュリティイベント破棄の条件を動的に変更可能

## 7.11.1 Access to Persisted Events
各セキュリティイベントはDiagnosticEvent(DTC)と紐づいている。
以下の条件が整って、セキュリティイベントがQSEv成立の条件を満たしたら、IdsM はDiagnosticEvent のステータスを kFailed にし、提供されたコンテキストデータとタイムスタンプを DiagnosticEvent のスナップショットレコードに追加保存する。

・QSEv が永続化されるように設定されている
・DiagnosticEvent にマッピングされている
・ReportingMode が DETAILED または、DETAILED_BYPASSING_FILTERS の場合

つまり、ダイアグ機能でセキュリティイベントが読み出せる。

## 7.11.2 Reconfiguration of Reporting Mode
IdsMは、現在のモードを取得するサービス GetReportingMode(SecurityEventDefinition.id)と、
指定されたSecurityEventDefinition のモードを設定する診断サービス SetReportingMode(SecurityEventDefinition.id, ReportingMode) を提供しなければならない。

# 7.12 IdsM Provided SEvs
IdsM自身で内部SEvs（セキュリティイベント）を報告できる。
考え方はCPと同じで、以下のようなバッファ溢れや、通信エラーなどがある。
[CPの仕様](https://www.autosar.org/fileadmin/standards/R23-11/CP/AUTOSAR_CP_SWS_IntrusionDetectionSystemManager.pdf)参照：
![スクリーンショット 2024-01-21 23.36.24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1878269/ea0d9374-e2b4-99f7-fe9e-fcfb2557f6d3.png)

ただし、内部 SEvs は「7.9 Rate & Traffic Limitation」のレート制限、およびトラフィック制限によってフィルタリングされてはならない。