商品の価値という目で見れば，多くの組込み機器に取ってサイバーセキュリティは潜在的価値（=ユーザーにとって当たり前に出来ていて欲しいこと）なので，できればコストをかけずに達成したい。
一方で，悪意を持ったハッカーは何をやってくるのか分からないと考えると，最悪のケースが次々を浮かんできて，どこまでサイバーセキュリティの対策をやればいいのか見当が付かない。
組込み機器のサイバーセキュリティはどこまでやればいいのかは，１つの視点だけで考えていたら答えがでないような気がする。
そこで，「1. 危害の大きさ」「2. 悪用の可能性」「3. 製品のライフサイクル」の3つの視点で，どこまでやればいいのか，最低限のハードルはどこかを考えてみる
1. 悪用による危害の視点
マルウェアや悪意を持ったハッカーの攻撃で，機器が受ける危害の大きさを考えてみる。サイバー攻撃による危害は情報セキュリティの3要素であるCIA（Confidentiality:機密性，Integrity：完全性，Availability：可用性）の侵害で考えるとよいのではないかと思う。
例えば，可用性の侵害とは，機器が使えなくなるとどんな困ったことになるかを考える。重要な機器ほど動かなくなると大変だ。例えば，ペースメーカーや人工呼吸器などの生命維持装置の可用性が侵害されたら，患者の死につながる。でも，個人のPCが感染して使えなくなっても人は死なない。その人の仕事ができなくなるだけだ。ただ，事務所中のPCが感染すると事務所の仕事が止まるので，危害は大きくなる。できるのかどうかは別にして使えなくされたらどんな影響があるのかを考えるのが可用性の侵害だ。
完全性の侵害とは，機器内部の情報が改ざんされるとどんな困ったことになるかを考える。重要な情報，例えば，検査装置の診断結果が「治療が必要」だったのが「正常」に改ざんされると，必要な治療が行われなくなる。事務に使っているPCで送ったメールの内容が変えられてしまったら，業務に支障がでるかもしれない。以前，PCを遠隔操作されて，本人の意思とは無関係に脅迫メールを送ったとして誤認逮捕された事件があった。改ざんや成りすましによる影響を考えるのが，完全性の侵害だ。
機密性の侵害とは，機器が扱う情報が外部に流失してしまうと，どんな困ったことになるのか考える。企業にとっては，情報の流失は信用の低下を招くので，機密性の侵害を重要視する製品もあるだろう。例えば，企業内で使用するネットワークプリンタなどだ。個人情報を扱わないなど機器が保持する情報がそれほど重要でなく，流失してもさほど大きな危害には至らない機器もあるかもしらない。機密性の侵害を，可能性や完全性の侵害よりも低いと考える考え方もあるが，情報が漏洩してしまったときの企業の社会的評価の低下を重要視する場合もある。
このように，悪用の可能性をひとまず考えずに，悪用されてしまったとして，機器のCIAの侵害を評価すると，起きてしまったときの影響の大きさを推察することができる。影響が大きければ大きいほど，確実な対策が求められる。もしも，CIAの侵害が起こらないことを証明できれば，サイバーセキュリティの対策は終わりにできる。
CIAの侵害が起こらないと言い切れないのであれば，「悪用の可能性」を考慮しなければいけない。
2. 悪用の可能性の視点
悪用の可能性では，まず，侵入の経路を分析する。IoTというとネットワークに接続されることが前提なので，侵入経路はあるのだが，ネットワーク接続やポータブルメディアのインタフェースを持たない組込み機器もあるので，そういった機器は悪用の可能性が極めて低い。（ROMを引っ剥がすといった可能性もあるのでゼロとは言えないが）
よって，侵入経路がない，または侵入経路を施設のゲートウェイが抑えているといった場合は，悪用の可能性が低くなるので，ハードルを下げられるかもしれない。しかし，サイバーセキュリティの場合，悪意を持ったハッカーが攻撃の意思を持っていると，可能性が低くてもチャレンジしてくる可能性があるため，悪用可能性が低いから対策しなくていいとはなかなか言い切れない。
例えば，汎用OSで既知の脆弱性がある場合，その脆弱性のパッチを当てていなければ，悪用される可能性は高いし，使っていない TCP/IP のポートが開いていればこれまた悪用の可能性は高まる。悪用の可能性を低くできるならば，コストが許す限り低くした方がよい。
なお，機器の外部環境に条件を付けることで，悪用の可能性を低くすることができる。例えば，施設内のネットワークとインターネットとの間にゲートウェイを設置してもらい，ゲートウェイで不審な通信をカットしてもらうようなケースだ。このような場合，機器のセイバーセキュリティのための環境条件が守られていないと，悪用の可能性が上がってしまうことをユーザーにアピールする必要がある。
また，ネットワーク接続があっても，RTOSを使い，プログラムがリードオンリーの領域でしか動かないならば，これまた悪用の可能性は下がる。ネットワーク経由でプログラムを書き換える機能を持たない，動的メモリ上でタスクが動かないなら，その機器が踏み台になる可能性はあっても，機器自体が発症する可能性はない。
ちなみに，ホワイトリスト式のアンチウイルスソフトウェアを搭載する行為もそれに似ていて，ホワイトリストに載っているアプリやサービス以外は動かないという設定にしておけば，マルウェアが機器上で発症することができなくなる。
脆弱性が多い機器は，悪用の可能性が高く，悪用の可能性が高い機器は，それだけ対策もたくさん取らなければならない。汎用性の高いOSを使っている機器は，結果として悪用可能性も高くなってしまう。
3. 製品のライフサイクルの視点
製品を市場に出す前と出した後の視点で考える。市販後に用意にソフトウェアをアップデートできるならば，市販前の対策はそれほどやらなくてもいいかもしれない。OTS（商用で即利用可能なソフトウェア製品）を使っている場合は，既知の脆弱性，未知の脆弱性があるので市販前も市販後もどっちも対応が必要になるかもしれない。
Windows や Linux には多くの脆弱性が見つかるので，市販前に分かっているぶんはパッチの適用が必要だし，市販後に発覚した場合は，パッチを当てる必要があるかどうか判断して実行する。
パッチが当てやすくなっていたとしても，全部やる必要があるかないかは，1の危害の重大度と2の悪用の可能性で評価するしかない。
脆弱性が見つかりにくいマイナーなOSを使っていれば，市販後の対応もほとんどなくなる可能性はある。
セキュリティインシデントが起こってしまった後に対応すれば済む場合は，市販前にはコストのかかる対策は行わずに，市販後に対応について準備をしておけばいいかもしれない。セキュリティインシデントが起こってしまうと取り返しが付かないような製品には，市販前の対策を十分にとって，悪用の可能性を低くしておかなければいけない。
「1. 危害の重大度の視点」「2. 悪用の可能性の視点」「3. 製品のライフサイクルの視点」の3つは，それぞれ関係性があってややこしいが，まずは，他の視点こ考慮せずに，それぞれの視点で組込み製品のサイバーセキュリティを評価してみて，その上で，どの対策をするとどこの影響を抑えることができるのかを考えてみたらどうだろうか。
0 件のコメント:
コメントを投稿