構築中。

名古屋のインフラエンジニアです。ITイベントへの参加記録などを残していきます。

2017年6月度 ISACA名古屋支部特別講演会/ ITリスク学再考 IoT時代のリスク評価(6/17)

3ヶ月ぶりの参加です。

6月は月例会ではなくて年次総会だったため、講演会前の発表等が延びて予定時刻より少し遅れての開始となりました。

2017年06月度 ISACA名古屋支部年次総会及び特別講演会 | ISACA NAGOYA (JP)

 

内容はそれなりのボリュームがあったので、要点(と思しきところ)のみ箇条書きで列挙します。

ITリスク学について、詳細は講演者(佐々木良一東京電機大学教授)の著書などを参照してください。

www.kyoritsu-pub.co.jp

ITリスク学研究会 | 日本セキュリティ・マネジメント学会

 

・リスクの定義

 ⇒「将来の帰結に対する現在における予測」という見方が下敷きになっている

  常に不確実性を伴う

  ISO/IEC 27005:2008によるITリスクの定義

   リスク=資産価値×脅威×脆弱性

・ITリスク問題が重要になった背景

 ⇒社会全体のITシステムへの依存増大による

・ITリスク学の確立

 ⇒2008/5に研究会立ち上げ、ITリスク学の定義、全体像と構成要素、研究課題の明確化、研究課題の解決に向けての活動を経て、2013/2に本を出版

・ITリスク学の定義

 ⇒不正によるものだけでなく、天災や故障ならびにヒューマンエラーによって生ずるITシステムのリスクならびにITシステムが扱う情報やサービスに関連して発生するリスクを、リスク対策の不確実性や、リスク対リスクの対立、関与者間の対立などを考慮しつつ学際的に対処していくための手段に関する学問

・ITリスク学再考

 ⇒必要性の高いテーマを先行的に扱っていたのは良かったが、範囲が広すぎ、掘り下げが不十分だった

  リスク評価・リスクコミュニケーションの部分に重点化すべき

  IoTによりリスク評価も新しいアプローチが必要

・多重リスクコミュニケータ(MRC)

 ⇒背景:①多くのリスクが存在→リスク間の対立を回避する手段が必要

     ②1つの対策だけでは目的達成が困難→最適な組み合わせを求めるシステムが必要

     ③多くの関与者が存在→関与者間の合意が得られるコミュニケーション手段が必要

  対応:①リスク・コストを制約条件とし、残存リスク等を最小化する対策組み合わせ問題として定式化

     ②関与者の合意が得られるまで制約条件値などの値を変えつつ最適化エンジンを用い解を求める

・MRCに関する最近の研究

 ⇒1. 合意形成対象者が1,000人を超す問題への適用

  2. 機能の拡張→被害発生防止対策と復元対策の両方を考慮した対策案最適組み合わせ法、動的リスクを考慮した多重リスクコミュニケータ、経営者とのリスクコミュニケーションも考慮した多重リスクコミュニケータ、多段にわたる攻撃のリスク評価のためのリスク解析法(EDC法)の開発

・EDC法

 ⇒イベントツリー分析法+ディフェンスツリー分析法

イベントツリー分析法

 ⇒事象の発生から時系列順にどのような事象に発展するかを分析

ディフェンスツリー分析

 ⇒攻撃に対しトップダウンにその要因を分析する

  アタックツリー分析に対策を加えたもの

・EDC法の実適用

 ⇒東京電機大学の次期セキュリティ対策

  コストをかけてもリスク値があまり下がらない対策がある

  結果、入口対策4:内部対策2:出口対策2を組み合わせることに

  ※詳細は機密情報なのであくまでイメージとして提示

・IoT時代に予想される攻撃

 ⇒被害大型化、被害形態多様化(完全性・可用性喪失が主)、攻撃対象多様化、犯罪組織高度化

  ネットワーク側から入力中心のIoT機器→制御系の危険性が高い

  人命が失われる場合も

  無防備な機器が多い(防犯カメラ等)

  DDoS攻撃の踏み台

  Censysを使った機器検索

  セキュリティ意識等とフィッシング被害等との相関

  IoTのサプライチェーンにおける脅威(メーカの本国政府へのデータ送信疑惑)

IoTセキュリティガイドライン

 ⇒5つの指針・21の要点

  実現・実行可能性は「?」

・IoTの階層別セキュリティ対策

 ⇒システム層(Data Center)、サブシステム層(Gateway)、IoT機器層

  セキュアゲートウェイ(サブシステム層→IoT機器層)

  認証チップ(IoT機器層→システム層)

  種々の対策の組み合わせ(全体)

・STAMP法=概念

 ⇒MITのLeveson教授が提唱

  安全解析のパラダイムシフト

  従来手法:アクシデントは構成機器の故障やオペミスで起きると仮定

  新手法(STAMPなど):アクシデントは構成要素間の相互作用(信号有無、タイミングのずれ等)から創発的に発生すると仮定

  「STAMP手法に関する調査報告書」を公開:IPA 独立行政法人 情報処理推進機構

・STPA=安全解析手法(ハザード分析)

 ⇒STAMPモデルの3要素(相互作用を表すコントロールストラクチャー、アルゴリズムと対象プロセスを表すプロセスモデル、守るべき安全制約)を用い、コントロールを行う側とその対象プロセスとの間の相互作用において、安全制約が不適切であったり守られない状態になったりするシナリオを中心に分析

  安全分析/解析手法であるため、セキュリティを導入する新手法(新技法)の開発とデザインへの取り込みが重要に

  ※そこを今世界に先駆けてできるように頑張っている

  EDCもIoT向けのアプローチとして使えそう

・まとめ

 ⇒IoTシステムのセキュリティ対策→今後ますます重要に

  IoTシステムのリスク評価・リスクコミュニケーションも大切

  セーフティとセキュリティを同時に考えていく必要→対応は簡単ではない

  研究者が限られる→学会・研究会を通じた情報交換が大切

 

本の紹介/Real World HTTP ――歴史とコードに学ぶインターネットとウェブ技術

オライリー本ですが、翻訳本ではなくて日本人が書いた日本語がオリジナルの本です。

たまたま著者さんのブログの記事を見かけたことでこの本のことを知り、「いくら探しても見つからないな…」と思っていたら発売日を勘違いしていただけ(まだ発売日前だった)…というオチで、今週、無事に入手することができました。

www.oreilly.co.jp

私が社会に出た頃に、ようやくHTTPのバージョンは1.0になり…ということで、当時を思い出すと「インターネット=メール&ニュースグループ(USENET)」だったなぁ…という感じなのですが、この本でも最初のほうでHTTPと電子メール、ニュースグループの関係が取り上げられています。

HTTP/0.9からHTTP/2、HTML5までの流れと、各バージョンでできるようになったことやユースケースが歴史とともに触れられており、私のようなおじさんにとっては、

「ああ、懐かしい」

「ここは雑にしか理解せずに流してたな」

「これは知らなかった」

というように「復習」と「不足知識の穴埋め」ができますし、若い人にもHTTP/2やHTML5に至るまでの技術の積み重ねがこの1冊である程度理解できるので、結構オススメできます。

全般的に「そこそこ詳しいけど細かすぎない・長すぎない、絶妙な記述量」という印象なので、読み切るのに挫折せずにすみそうです。

余談ですが…たまに700ページ超の技術書がありますが、その手の本で私が読み切ることができたのはこれ↓ぐらいです。初版は薄かったのに、第3版では850ページ超え…。

www.oreilly.co.jp

 

また、HTTP/0.9からHTTP/2までの歴史とは別に、独立した章(10章)でセキュリティについて触れています。最近CORSを扱う案件があったので、もう少し早く発売されていれば…。

あと、RESTful APIについても11章で軽く触れられています。

それから、「実践的になにかを試す」ためのツールとして、前半部分でCurl、全体を通じてGo言語が用いられています。

HTTPを扱う上では、このあたりは必須またはそれに近い存在になってきたな(というか、Curlは昔からそうだけど)、という感じです。

続・今年は名古屋で色々開催されるようで

先日、↓これを書きましたが…

hmatsu47.hatenablog.com

今日、偶然名古屋情報セキュリティ勉強会のサイトを覗いたら、第13回名古屋情報セキュリティ勉強会の案内が出ていました。

nagoya-sec.techtalk.jp

ちょっと先ですが9/9(土)です。

個人的には仕事で大きなイベントがある(であろう)時期なので、もしかするとキャンセルするかもしれませんが、とりあえず勉強会本体のみ申し込んでおきました(休日出勤による重要な作業が1週間前か1か月後にずれてくれることを期待して)。

テーマは「ダークウェブのマーケット(仮)」だそうで、「(仮)」がそのまま外れるのかどうかわかりませんが、そのままの内容で開催されれば、普段(名古屋にいると)あまり聞けない話なので面白そうです。

 

今年は最低あと2回東京のイベント・勉強会に参加する予定ですが(多分もう1~2回ぐらいは増えそう)、体調の問題もあるので(耳鳴りはおさまったものの相変わらず騒がしい場所での聞こえはあまり良くない)、名古屋に来てもらえるのはありがたいです。