ぱと隊長日誌

ブログ運用もエンジニアとしての生き方も模索中

デブサミ2020「【13-F-2】アプリケーションやシステムが悪い奴らに攻撃されたらどうなる？」聴講メモ

アーキテクチャ 勉強会/セミナー

はじめに

Developers Summit 2020 (Developers Summit 2020)
アプリケーションやシステムが悪い奴らに攻撃されたらどうなる？
スピーカー：松岡 正人 [日本シノプシス]
の聴講メモです。

Twitterのつぶやきがtogetterでまとめられています。併せてご参照ください。
デブサミ2020【13-F-2】アプリケーションやシステムが悪い奴らに攻撃されたらどうなる？ #devsumiF - Togetter

【参考】としている箇所は私が挿入しています（補足や参考資料など）。登壇者の講演内容ではありませんので、その旨ご了承ください。

聴講メモ

シノプシスは半導体のIPを売ることがメインだった。

【参考】

IPコア（Intellectual Property Core）とは、FPGA、IC、LSIなどの半導体を構成する再利用可能な回路コンポーネントの設計情報です。ソフトウェア開発においてはその設計情報を「ライブラリ」と呼ぶのに対して、半導体設計では「IPコア」や省略して「IP」と呼びます。IPコアには回路の種類、有償無償、ファイルフォーマットなどにおいて様々な種類が存在します。

IPコア - MATLAB & Simulink

シノプシスはコベリティを買収し、その後も買収を繰り返してプロダクトのラインナップを広げている。ソフトウェアの品質を高めることが目標となっている。

日本でもクオリティの問題が発生している。7payがその一例だ。

【参考】
セブン・ペイ - Wikipedia
7payの不正利用事件についてまとめられています。

これまでのクオリティとは正しく動くかどうかだった。だが、悪い奴らにとってそれは関係なく、悪いことに利用できるかどうか、それで金儲けできるかどうかが重要だ。

ここ数年はサイバーインシデントが脅威であると言われている。

サイバーインシデントは悪いやつが何かやらかすか（事件）、うっかりをやらかすか（事故）で発生する。

脆弱性は必ずしもバグから発生する訳ではないが、コード量が増えれば穴はどうしても増える。これをどう減らすか。

車はソフトウェアの塊になっている。リコールもソフトウェアの不具合で起きている。

【参考】
https://www.synopsys.com/apps/japan/today-tomorrow/articles/tt107-tu-automotive-software.html
ソフトウェアのコード行数で比較すると、車載ソフトウェアのほうがFacebookやボーイング787よりも多いことを示すグラフが掲載されています。

2018年度のリコール件数は過去2番目の多さ、制御プログラムの不具合が影響大：エコカー技術 - MONOist
2018年にハイブリッドシステムの制御プログラムの不具合により、124万台以上を対象とするリコールが発生しました。

ボーイング737MAXの問題はソフトウェアの問題と言われている。悪い人がこうした問題を悪用するかもしれない。

【参考】
ボーイング737 MAXにおける飛行トラブル - Wikipedia

システムを止めると言うことはビジネスも止まるということ。自治体システムの障害や、OpenSSLのHeartbleedもそうだった。OpenSSLの問題は今も発生している。
開発者はその影響を会社のトップが正しく理解できるように説明しなければいけない。

【参考】
「自治体システムの障害」はこちらです。

2019年12月4日に日本電子計算の自治体向けIaaS（インフラストラクチャー・アズ・ア・サービス）「Jip-Base」でシステム障害が発生し、50自治体に影響が出た

自治体システム障害に進展、単独復旧不可は残り4%: 日本経済新聞

OpenSSLのHeartbleed問題をわかりやすく解説した記事です。
「OpenSSL」とは何ですか？「Heartbleed」はどのような問題でしょうか？ | サイバーセキュリティ情報局

シノプシスは半導体の会社だが、半導体にとってもソフトウェアは切っても切り離せない。コードの品質を上げなければいけない。

コード量は増えているし、組み合わせも増えている。複雑度のリスクが上がっている。組み合わせの一部で止まることが他に影響を及ぼすかもしれない。

今はいかに短い時間で開発しつつ、品質を担保するかが求められている。

日本は言葉の壁があるからセキュリティリスクは低いと言われていたが、今は翻訳で攻撃対象のシステムのドキュメントを読む時代となっている。技術の進歩がセキュリティリスクを高めた。

ソフトウェアの脆弱性は増えている。だが、それに対応できる要員がいない。

自分たちが何を扱っているのか、どんな課題があるのか、どうすれば対応できるか、を考えないといけない。

ソフトウェアは様々な要素の組み合わせになっている。
API、フレームワーク、OSS、OSなど。
これらを組み合わせたときに要素がどう連携しているかを可視化しないといけない。

シノプシスのSASTは静的解析ツールだ。コード量が増えると全てを目検では見切れないので、ツールで支援する。
Coverity 静的解析（SAST）ソフトウェア | Synopsys

インターフェースから脅威を考えるためにはNISTのセキュリティガイドを参照するのが良い。

【参考】
NIST (National Institute of Standards and Technology | NIST) のサイトから該当するドキュメントを探そうとしましたが、多すぎて上手く見つけることができませんでした。

IPA/ISEC が NIST の文章を翻訳して公開しているページも見ましたが、見つけられませんでした。
セキュリティ関連NIST文書：IPA 独立行政法人 情報処理推進機構

今はセキュリティに関する本・資料がある。そこからどんなアプローチで臨むかを考える必要がある。

脆弱性はリサーチャーと呼ばれる方が見つけるケース、ユーザーが見つけるケースと様々だ。そうした情報が集まるポータル（例：CWE）などを参照する。
https://cwe.mitre.org/

どんな怖いことが起こるのかということを脅威モデルといい、シノプシスの英語資料がある。
https://www.synopsys.com/content/dam/synopsys/sig-assets/datasheets/threat-modeling-datasheet.pdf

サーバーの内側と外側の脅威は両方考えないといけない。インシデントには内部の協力者がしばしば存在している。

脅威モデルではシステムの主要なアセットとその相互関係を可視化する。
脅威となる人（脅威エージェント）を想定する。脅威エージェントをシステムの領域に割り当て、何かしら悪いことをすると想定する。

セキュリティ管理策では悪いことをされると想定して何をするかを考える。例えば、レガシーシステムと接続しているのであれば、レガシーシステムは更新されずに脆弱性を突かれて脅威になりうると考えて、IP制限を実施するなど。

MITRE ATT&CK フレームワークにはどんな脆弱性を利用して攻撃のためのコードを作っているかのパターンがまとめられている。取るべき対策もまとめられている。取るべき対策は裏を返せば攻撃されるポイントでもある。認証情報窃取であれば "Credential Dumping" を参照のこと。

【参考】
今知るべきATT＆CK｜攻撃者の行動に注目したフレームワーク徹底解説
ATT&CK に直接リンクするより、このページで理解を深めることが有用と考え、紹介させていただきました。

脅威モデルを考えるうえで参考になるリソースを挙げる。
※注記：リンクは私が最も適当であろうと判断したサイトとなります。

(1) Microsoft STRIDE
脅威モデルを作るためのツールだ。
脅威 - Microsoft Threat Modeling Tool - Azure | Microsoft Docs

(2) OWASP CHEAT SHEET
Introduction - OWASP Cheat Sheet Series

(3) OAuth 2.0 Threat Model
RFCにもなっている。
OAuth 2.0 Threat Model and Security Considerations

シフトレフトし、品質を早い段階で対処することが必要だ。