Day12. セキュリティエンジニアに聞く「セキュリティの勘所」

※ひとりでIoTまるっとチュートリアル Advent Calendar 2018 12日目

ひとりでIoTまるっとチュートリアル Advent Calendar 2018 - Qiita

なにかと後回しにされがちなセキュリティ。2017年のガートナー社が提供するハイプ・サイクルを見ても、「IoTセキュリティ」はまだまだ認知されていないということが伺えます(そして、なぜか2018年では消えていました。)

しかし、あらゆるモノがインターネットにつながっていて、セキュリティの問題が起こらないわけがありません。国やIPAもガイドラインを制定し、一層注力していく分野に思われます

※参考1：IoTセキュリティガイドライン
※参考2：IoT開発におけるセキュリティ設計の手引き)

そこで今回は、セキュリティエンジニアに、セキュリティの勘所、IoTセキュリティで考えるべき点を伺ってきました！
それを元に、今日から2日掛けて、セキュリティについてガッツリ書いていきます！！ぜひご覧ください。

一日目はセキュリティ全般のお話。

【目次】
・セキュリティに対する心構え
・どこから守るか考える「リスク分析」
・セキュリティを考える上で有用な「STRIDE」
・対応範囲をを切り分ける「トラストと設計」

セキュリティ意識

imaimai : まずはじめに、社内のセキュリティを強化する上での意識というか、心構えを聞きたいです。

A : これは経験談ですが、セキュリティ施策に対して文句を言う組織に限ってインシデントを起こしたりします。セキュリティに関しては、まず何よりも当事者意識をもつことです。攻撃は特定の組織しかくらわないとか思わず、自分の周りに起こる可能性が十分にあるということを。認知しないといけません。

また、社内教育も必要です。なぜ今の状況が危険なのか、そして、その施策をすることでどういった脅威から見を守れるのかをきちんと説明し、理解してもらってこそ、社全体のセキュリティが高まるのです。

どのように守るのか

imaimai : なるほど、しかし、インシデントが「なんとなく危険」とはわかっているとはいえ、セキュリティの危険性を把握するのは難しい気がします。どのように考えていけばいいのでしょうか？

A : セキュリティを考える場合、まず行うのがリスク分析です。このメソッドでは、リスク(攻撃を受けたときのダメージ)を次の3つの掛け算で計算します。

☑ 資産(守るべきもの)
☑ 脅威(ハッカーからの攻撃/自然災害など)
☑ 脆弱性(外部の攻撃から守れるか)

クラウドに情報を置いていて、外部からハッカーが来て、どういう攻撃が来るかを想定してリストアップしそれを並べた後、この掛け算に従って大事そうなところから進めていくことで、方針がはっきりと定まるでしょう。

また、「そこそこセキュリティ」という考え方も大事です。漏れたとして、個人の事業に関係ない日記だとしたり(資産性が低い)、もはや誰も攻撃してこなさそうなニッチな分野(脅威が低い)ところまで、ガチガチに固めてしまっては、コストが馬鹿にかかったり、システムが使いにくくなってしまいます。ユーザビリティやコストとのトレードオフも考え、自社に本当に大事なところから始めていくという意識を持っておきましょう。。

imaimai: なるほど。この3つの掛け算だと思うと、少し考えがクリアになりますね。でも、ここで難しいのが洗い出しの粒度かなと思うのです。セキュリティエンジニアが少ない会社などは、どうするのがいいのでしょう？

A : もちろん、自社でセキュリティエンジニアや、CSIOがいるのが最も好ましいです。しかし、いなくても、定性的なリスク分析を行うのは大事です。それこそ冒頭の当事者意識を持つことが大事ですから。

また、まずは外部のセキュリティコンサルなどに委託するのも一手ではないかと思います。ウェブアプリやプラットフォームの診断もきちんと行ってくれますので、サービスを本番運用する方々は一度申し込むのがいいかと思います。私のおすすめは下記の4企業です。

【セキュリティ診断に定評のある企業】
☑ NRIセキュア : セキュリティのプロ集団。品質は相当高い。
☑ 三井物産セキュアディレクション : NRIセキュアに引けを取らない品質
☑ LAC : セキュリティの最王手企業
☑ セキュアスカイ : リーズナブルで、コストパフォーマンスが良い

また、自社でのセキュリティ運用が困難であるなたば、リスクの転移という考え方もあります。保守会社におまかせするなどして、責任を他社に委ねるというのも一手です。

セキュリティを考える上で有用な「STRIDEモデル」

imaimai : こういった形で、セキュリティ関連の会社は運営してらっしゃるのですね。。重要性がわかった気がします。ちなみに、セキュリティに関して自社でも考えていきたいなと思うのですが、脅威に対しての考え方のコツってありますか？

A : STRIDEモデルという考え方がそれに近いかもしれません。セキュリティを考える際には、次の6種類の脅威を考えることで、できるだけ網羅的にリスクを考えられるとされています。

STRIDEモデル
☑ Spoofing : 偽装 他人になりすますこと。
【例】ID/PWを盗んでログインし、あたかも本人のように振る舞うなど。
☑ Tampering : 改ざん 内容を不正に書き換えること
【例】機密文書の内容を書き換えてしまう
☑ Repudiation  :  否認 ある行為が発生した場合、「それは自分ではない」と言い張ること
【例】メールを送ったのに、「送っていない」ことにしてしまう
☑ Information Disclosure : 情報漏えい
【例】内部告発や外部からの攻撃など、意図しない流出経路からの漏洩
☑ Denial of Service : サービス拒否
【例】アクセスを大量にして、サーバーを落とす(DDoS)
☑ Elevation of Priviledge: 特権昇格
【例】 root権限で実行されるプログラムに脆弱性があり、一般ユーザで不当にroot権限を得る

参考 : 脅威分析モデル STRIDE

imaimai : なるほど、こういう考え方があるのですね。ある程度考えやすくなる気がします！

※IoTという文脈で、どこがどのように脅威になるかと言うのを一緒に考えてみました。その内容はDay13にて書きます。

対策範囲を切り分ける『トラストと設計』

imaimai : 最後に、最近「クラウドにデータを貯めている」というだけで、拒否するお客様もかなりいます。この辺り、どのように訴求していけばいいのでしょう？

A : 難しい問題ですね。しかし、ある程度道標になるかなと思うのがセキュリティの「トラストと設計」という考え方です。

☑ トラスト: クラウドベンダを信じる部分
☑ 設計 : 我々ができるところ
例 : 閉域網・データの暗号化・冗長化・トレーサビリティ

トラストというのは、何を根拠に、どこまでクラウドベンダを信じるかです。たとえば、クラウドはAWSを自社が使っているのだとすれば、AWSのセキュリティ体制(責任共有モデル)を完全に信じられるのかというところです。資料やSLAを調べ、顧客に対して信頼に足る説明ができるベンダ選びをしましょう。

(責任共有モデル。AWSより引用)

例えば責任共有モデルでの上半分・ユーザに範囲が及ぶ部分は、自分たちでしっかりと設計しなければなりません。自社の設計でどこまできちんとセキュリティを担保できるか。リスク分析、STRIDEモデルを使い、きちんと対策を打っていくことが大事です。

便利さと、トラスト/設計でカバーできるかを考慮して、許容できるならば使っていくべきだと思います。

まとめ

いかがでしたか？セキュリティといっても、かなりぼやっとした認識の方も多かったのではないでしょうか？

しかし、やはり方法論はあります。セキュリティエンジニアいわく、今回のは基礎的な内容だけれど、だからこそ本質的で大事な内容とのことです。

さて、明日は今日の内容を元に、実際にIoTにおいてどんな脅威が考えられるか、どうやって対策していけばいいかを考えていきましょう。ではではっ！

前の日 : Day11. IoTの中核部分「通信技術」の奥深さと可能性に迫る
次の日 : Day13. セキュリティエンジニアと考えるIoTにおけるセキュリティ