これだけは絶対覚えたいセキュリティ基礎/The Basics of Information Security

Webエンジニアにとって必須スキルであるセキュリティについて、歴史/実例/雑学を交えながら初学者に向けてお話ししました。

【サポーターズ勉強会】これだけは絶対覚えたいセキュリティ基礎講座
https://supporterzcolab.com/event/640/

Transcript

1. Dec 12, 2018 #spzcolab The Basics of Information Security @ariaki4dev CC-BY-4.0
2. セッションの目的 セキュリティへの意識を高めよう 情報をキャッチアップできるようになろう セキュリティの基礎を知ろう 雑学を楽しもう 2
3. 資産と安全 3
4. 資産 ヒト モノ カネ 4
5. 生命 生活 生活資産（衣食住） その他の有形資産 現預金・有価証券 その他の無形資産 安全 5
6. あなたの豊かな暮らし 安全 6
7. 考えてみよう カード情報漏洩 想定される被害 7
8. 考えてみよう カード情報漏洩 - 不正利用 - 利用妨害 - 信用情報漏洩 - 利用履歴漏洩 - 利用履歴操作 - 信用失墜 ： 想定される被害 8
9. リスクを多方面から考える 9
11. Hello, I’m @ariaki4dev #engineers_lt #techdo
12. 12 アジェンダ セキュリティとは 1 ガイドラインと攻撃傾向 2 セキュアコーディング 3 事例からみる危殆化 4 OSセキュリティ 5 ページ ページ ページ ページ ページ 13 31 40 49 67 最後に 6 ページ 77
13. 13 セキュリティとは About Security
14. セキュリティリスク って聞いたことありますか？ 14
15. 15 インシデント リスク 潜在 顕在
16. 脆弱性の程度 16 脅威の程度 資産価値 リスクの大きさ
17. 17 セキュリティリスク 脅威の分類 分類 脅威の例 人為的脅威 意図的脅威 攻撃（不正侵入、ウイルス、改ざん、盗 聴、なりすまし、等） 偶発的脅威 人為的ミス、障害 環境的脅威 災害（地震、洪水、台風、火事、等）
18. 18 セキュリティリスク 脆弱性の分類 分類 脅威の例 物理的脆弱性 建物などの設備やハードウェアに存在する （建物構造、機器故障、盗難、紛失、等） 人的脆弱性 組織や人、運用管理に存在する （組織管理、人、問題対処法、等） 技術的脆弱性 プログラム上に存在する （アプリケーション、プロトコル、等）
19. 19 セキュリティリスク 資産の分類 分類 脅威の例 情報 データベース、データファイル、設計書、等 ソフトウェア 業務用ソフト、アプリケーションソフト、等 ハードウェア コンピュータ、通信装置、記憶媒体、等 サービス 電源、暖房、照明、通信網、等 人 人そのもの
20. 20 セキュリティリスク リスクコントロール • リスク回避 … 不要情報の破棄、等 • リスク軽減 ◦ リスク分散 … 分散処理、等 ◦ リスク集中 … マシンルームで集中管理、等 ◦ リスク移転 … アウトソーシング、等 ◦ 損失予防… 保守メンテナンス、等 ◦ 損失軽減… システム多重化、バックアップ、等
21. 21 セキュリティリスク リスクの図式 泥棒 脅威 資産 脆弱性 鍵が開いている窓 現金など クラッカー セキュリティホール 情報など インシデント
22. 22 セキュリティリスク リスクの図式 泥棒 鍵が開いている窓 現金など クラッカー セキュリティホール 情報など 想定 脅威 資産 脆弱性
23. 23 セキュリティリスク リスクの図式 泥棒 鍵が開いている窓 現金など クラッカー セキュリティホール 情報など 対策 脅威 資産 脆弱性
24. 24 セキュリティリスク リスクの図式 泥棒 鍵が開いている窓 現金など クラッカー セキュリティホール 情報など 管理 脅威 資産 脆弱性
25. 25 セキュリティ セキュリティの定義 • 機密性 ( Confidentiality ) アクセスを認められた者だけが、情報にアクセスできる • 完全性 ( Integrity ) 情報が破壊、改ざん又は消去されていない • 可用性 ( Availability ) アクセスを認められた者が、必要時にアクセスできる JIS Q 27002 : 2014
26. 26 セキュリティ セキュリティの定義（拡張） • 真正性 ( Authenticity ) ある主体又は資源が、主張どおりであることを確実にする • 責任追跡性 ( Accountability ) 動作及び動作主を一意に追跡できることを確実にする • 否認防止 ( Non-Repudiation ) 発生事象を後から否認されないように証明する • 信頼性 ( Reliability ) 意図した動作及び結果に一致する
27. 27 セキュリティ セキュリティ対策の基礎 予防 検知 回復 • 予防 … リスク分析しセキュリティ対策を実施する • 抑制 … 罰則を科したり、モラルに働きかける • 防衛 … アクセス制御やファイアウォールなどを行う
28. 28 セキュリティ セキュリティ対策の分類 分類 脅威の例 技術的対策 ファイアウォール、侵入検知、ウイルス対策、等 物理的対策 防犯対策、入退室管理、盗難防止、等 人的対策 規程、手順書、従業員教育、等
29. 29 セキュリティ セキュリティ対策の観点 個人情報保護 事業継続担保 保管されている個人情報が 漏洩しないための対策 攻撃等による事業の停止が 最小限に収まるための対策
30. 攻撃を受けない為の知識 攻撃を発見する為の知識 攻撃を緩和する為の知識 被害を最小限に抑える知識 被害から復帰する為の知識 セキュリティ ＝ 知識 30
31. 31 ガイドラインと攻撃傾向 Security Guidelines & Trend of Attacks
32. SQLインジェクション CSRF XSS ディレクトリトラバーサル コマンドインジェクション ヘッダインジェクション ディレクトリリスティング オープンリダイレクト 32 ブルートフォース攻撃 親切過ぎるエラーメッセージ クリックジャッキング サイズ制限の無いアップロード DDoS いくつ知っていますか？ 知っていますか？脆弱性
33. 33 （OWASP Top 10 2017 日本語版より抜粋）
34. 34 ガイドライン 攻撃技術の発達 • 1988年 スタックオバーフロー • 1998年 ヒープオーバーフロー • 1998年 SQLインジェクション • 2000年 JavaScriptインジェクション（XSS） • 2000年 フォーマット文字列 • 2002年 整数オーバーフロー • 2004年 HTTPヘッダインジェクション セキュアプログラミング（防御的プログラミング）の歴史をざっと振り返る
35. 35 ガイドライン 代表的な情報セキュリティガイドライン OWASP Top 10 - 2017 PCI DSS CWE/SANS Top 25 Most Dangerous Software Errors JIS Q 27002 : 2014 安全なウェブサイトの作り方 開発者向けセキュリティ関連コンテンツ
36. 36 ガイドライン 代表的なコーディングガイドライン CERT Top 10 Secure Coding Standard OWASP Secure Coding Practices OWASP Top 10 Proactive Controls JPCERT セキュアコーディングスタンダード IPA セキュア・プログラミング講座 Androidアプリのセキュア設計・セキュアコーディングガイド
37. 37 ガイドライン 攻撃手法のトレンド 情報セキュリティ10大脅威 2018 サイバー攻撃トレンド：2018年上半期レポート 2018 IT Security Outlook
38. 流行は日々変わります 38 継続的な情報収集と改善が必要
39. 39 まとめ 最新知識を身に着けよう • ガイドラインがたくさんあります ◦ セキュアなコードを書くためのガイドライン ◦ 脆弱性対策ガイドライン ◦ 攻撃トレンドガイドライン • その他にも巧妙な攻撃手法があります ◦ GitHub / yum / apt / gem / npm / composer 等を利用
40. 40 セキュアコーディング Defensive Programming
41. メソッド 外部出力 41 入力処理 ロジック処理 出力処理 入力処理 ロジック処理 出力処理 入力処理 ロジック処理 出力処理 外部入力 アプリケーション モジュール
42. 42 セキュアコーディング セキュアコーディングの手法 • ゼロトラスト ◦ 入力の正しさ/出力の正しさ/論理的な正しさ ▪ 論理的 … 郵便番号と都道府県 契約プログラミング ▪ 事前処理, 事後処理, 不変条件 ▪ 信頼境界線 • 正しいエラーハンドリング • イベントロギング
43. 43 どこで入力値 $val を検証しますか？ 1. 関数コール前に検証する 2. 関数内で検証する
44. 44 どこで入力値 $val を検証しますか？ 1. 関数コール前に検証する（※契約プログラミングの場合） 2. 関数内で検証する
45. 45 入力値 $val を検証してみた
46. 46 セキュアコーディング 信頼境界線 • 入力受付時にチェックする ◦ MVCで言えばControllerが担う ◦ 複雑なバリデーションをModelに押し付けない • 大規模アプリケーションでは内部でも境界線を引く ◦ 自分のコード/他人のコード ◦ モジュール単位
47. 47 セキュアコーディング なぜ今必要なの？ • 最近はマイクロサービスへの置換が進んでいる ◦ サービスやコンテナ間の信頼関係の確立が課題 • コードによるアーキテクチャの前提は有効ではない ◦ 全てがネットを介するため、信頼できる発信者はいない ◦ 従来、サーバ側にあった機能がクライアント側で実装される
48. 48 セキュアコーディング まとめ • セキュアコーディングを意識する ◦ 脆弱性がない事がセキュアではない ◦ 攻撃を受けにくいコードを書く ◦ ゼロトラスト/信頼境界線を考えよう ◦ セキュアコーディングガイドを読もう • セキュリティとパフォーマンスはトレードオフ ◦ 適宜取り入れるようにしよう
49. 49 事例からみる危殆化 Compromise to think from case
50. 50 最低限の対策してますか？ Webサーバをセキュアに保つ設定のまとめ https://qiita.com/ariaki/items/78ed2d3810ad17f72398 Apache SSL TLS セキュリティ
51. き た い か 51 危殆化
52. 52 危殆化の事例 1999 1996 1995 2008 2006 2018 TLS/1.0 SSL/3.0 SSL/2.0 TLS/1.2 TLS/1.1 TLS/1.3 https://www.ssllabs.com/ssl-pulse/ @ Dec 03, 2018
53. 53 危殆化の事例 SSL 3.0 • 1996年に登場 ( RFC6101 ) • 2014年10月に仕様上の脆弱性が発見された ◦ 2015年6月に使用禁止された ( RFC7568 ) ▪ Force Downgrade ( POODLE ) の対象となる為 ▪ SSL/2.0も、2011年3月に使用禁止された ( RFC6176 )
54. 54 危殆化の事例 TLS 1.0 • 1999年に登場 ( RFC2246 ) • 拡張仕様が追加された ( RFC3546 ) • 必須共通鍵暗号：TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA • 一部の鍵交換アルゴリズム廃止 ( FORTEZZA ) • ハッシュ計算方法の変更 • CBCモードにおけるパディング方法の変更 • 2018年6月30日をもって使用禁止された ( PCI-DSS v3.2 )
55. 55 危殆化の事例 TLS 1.1 • 2006年に登場 ( RFC4346 ) • 必須共通鍵暗号：TLS_RSA_WITH_3DES_EDE_CBC_SHA • 共通鍵暗号に AES 追加 • CBCモードにおけるパディング方法の再変更 ( POODLE ) • セッション再開の規制緩和 • 既に脆弱性が発見され、TLS/1.2 への移行 が望まれている
56. 56 危殆化の事例 • 2008年に登場 ( RFC5246 ) • 必須共通鍵暗号：TLS_RSA_WITH_AES_128_CBC_SHA • 脆弱なハッシュの利用箇所削減 ( MD5, SHA-1, 等 ) • CipherSuite によりハッシュ方式設定 • 署名方式の解釈方法変更 • CBC に加えて、GCM / CCM 追加 TLS 1.2
57. 57 危殆化の事例 TLS 1.3 • 2018年8月に登場 ( RFC8446 ) • ハンドシェイクの高速化 ( 再接続 0-RTT, 初回接続 1-RTT ) • 平文通信が必要な部分を極力少なくして情報を秘匿 • AEAD ( 認証付き暗号 ) 必須化 • データ圧縮の廃止 ( CRIME ) • CBCモードの廃止 • セッションハッシュ機能 ( ネゴシエーション履歴全体ハッシュ ) など
58. 58 暗号周りの豆知識 暗号利用モード • ブロック暗号で、ブロック長よりも長いメッセージを暗号化する ◦ 詳細は暗号利用モードを参照 • 複数のモードがあり、ECB、CBC、OFB、CFB、CTRが有名 • 多くのモードで初期化ベクトル（IV）が使われる
59. 59 暗号周りの豆知識 CBCモード 暗号化処理 暗号化処理 暗号データ 暗号データ 平文データ 平文データ 初期化ベクトル (IV) XOR XOR
60. 分類 種類 Triple DES ブロック暗号 (64bit) AES (Rjindael) ブロック暗号 (128bit) Camellia ブロック暗号 (128bit) KCipher-2 ストリーム暗号 60 暗号周りの豆知識 暗号アルゴリズム ※CRYPTRECによって採択されたアルゴリズムを表記
61. 61 暗号周りの豆知識 暗号アルゴリズム • 3-DESは今もICカード等で使われている • 3-DESに変わるアルゴリズムとしてNISTが2001年にAESを選定 ◦ AES: Advanced Encryption Standard ◦ Rijndael（ラインダール） AESが選ばれるまでの歴史
62. 62 暗号周りの豆知識 分類 初出 ダイジェストのビット長 MD5 1991 128 SHA-1 1995 160 SHA-2 2001 224, 256, 384, 512 SHA-3 2015 224, 256, 384, 512 ハッシュアルゴリズム ※代表的なアルゴリズムを表記
63. 63 暗号周りの豆知識 ハッシュアルゴリズム • 強衝突耐性は誕生日のパラドックスによって計算 ◦ Nビットの乱数が衝突するまでの回数の期待値 = 2 ▪ 128ビットの場合は約1844京回 • 現時点で MD5, SHA-1 はすでに脆弱 ◦ MD5はすでに数十分で衝突させられる ◦ SHA-2への置換が推奨されている N/2
64. 64 暗号周りの豆知識 ハッシュといえば… • パスワード等のデータベース格納どうしていますか？ ◦ 平文？ ◦ ハッシュ？ ◦ ハッシュ＋ソルト？ ← BETTER ◦ B-Crypt？ ← BEST
65. 65 暗号周りの豆知識 塩コショウ • ソルト … ランダム文字を平文の末尾に付加してハッシュ化 • ペッパー … 固定の文字を平文の末尾に付加してハッシュ化 • 詳細はこの辺を参照
66. 66 まとめ 最新情報を収集しよう • 世の中には危殆化だらけ • 可能な限り最新バージョンにする必要がある • 暗号周りも少し覚えておくと楽しい
67. 67 OSセキュリティ Security of Operating System
68. 68 OSセキュリティ is 何？
69. © 2000「リング０～バースディ～」製作委員会
70. リング 0 バースデイ • 2000年1月22日に公開 • 原作は鈴木光司『バースデイ』 • 映画版リングシリーズの完結編 • 同時上映は『ISOLA 多重人格少女 • ついに明かされる貞子出生の秘密 • リングは今世紀最悪の０で終わる © 2000「リング０～バースディ～」製作委員会
71. 特権命令 Ring 3 Ring 2 Ring 1 Ring 0 Device drivers Device drivers Applications Kernel 低 高 権限 71 リングプロテクション • CPUに実装されている • CPU-OSで異なる使用法の場合も ◦ カーネルがRing-3で動いたり ◦ 一部のリング使ってなかったり • 動作モードとして ◦ スーパーバイザモード ◦ ユーザモード 詳細はWikipediaで
72. 72 仮想8086モード リアルモード プロテクトモード ロングモード 16bit 32bit 64bit 電源ON 互換モード Legacy Mode CPU動作モード
73. 73 リアルモード プロテクトモード - 16bit - RAMに自由アクセス - RAM 640KBを利用可能 - 32bit - RAMにアクセス制限 - RAM 4GBを利用可能 ロングモード - 64bit - RAMにアクセス制限 - RAM 1TBを利用可能 ※理論上は1PBまで （※80286以外） CPU動作モード
74. 74 コールゲート方式 Ring-3 Ring-2 Ring-1 Ring-0 ※x64では通常使用されない システムコール
75. 75 メモリプロテクション メモリ OS アプリ-A アプリ-B ( Ring-0 ) ( Ring-3 ) ( Ring-3 ) アプリ-A
76. 76 まとめ OSの世界は面白いよ • 動作モードと仮想メモリによって守られている • CPU/OS実装は密接に関連している • 仕組みを理解すれば脆弱性情報もわかりやすくなる • OSは自作できる
77. 77 最後に Conclude
78. 78 まとめ 技術的な攻撃以外も考えよう 今期の決算って どうだった？ 多分超黒字 ボーナス多そう 人を介した機密情報漏洩 人間を介した機密情報漏洩は最もシンプルかつ簡単に行えるものです。 技術的な情報以外も該当するので普段から充分な注意をしましょう。
79. 79 まとめ 常にセキュリティを考えよう • あなたが利用しているサイトのパスワードは？ 複数サイトで使い回していない 十分に複雑な文字列にしている 公開されたサイト上に保管していない • あなたの情報端末は？ 離席時に画面ロックしている スマホのパスワードを 4 桁にしていない
80. 80 まとめ 常にセキュリティを考えよう • 最近のフィッシング詐欺は PC だけじゃない 佐川急便を装った迷惑メール LINEフレンドからのプリペイドカード要求 • エンジニアは格好の標的 ◦ 他職種より重要な情報を保持している ◦ 私物からも機密情報漏洩の可能性が十分にある
81. 81 まとめ 常にセキュリティを考えよう • 知識の段階 ◦ 知らない ◦ 知っている ◦ 知っていて利用できる ◦ 知っていて無視せず利用できる • セキュリティを学び、正しく実践しよう
82. This JavaScript code powers a 1,500 user intranet application 最悪なログインコード
83. Security NEXT by NEWSGAIA 相次ぐ個人情報漏洩事件
84. まとめのまとめ 被害を最小限に抑える為の予防と準備を行おう 技術以外にもセキュリティリスクは存在する インシデントは発生する前提で考える 危殆化しない為に継続的な情報収集を行う 84 一般的な脆弱性を理解してしっかり対策する
85. Build Something Amazing written by ariaki4dev
86. 86 Appendix 小さく始める情報セキュリティ管理 祝RFC！Transport Layer Security (TLS) 1.3 発行の軌跡 理解してるつもりの SSL/TLS でも、もっと理解したら面白かった話 yohgaki’s blog
87. 87 Appendix https://speakerdeck.com/ariaki/os-that-we-should-know 全てのエンジニアに知ってもらいたい OSの中身 https://speakerdeck.com/ariaki/learn-about-vulnerability Learn about vulnerability and how to secure your website
88. 88 Appendix https://speakerdeck.com/ariaki/2020-evolution-of-internet 2020: Evolution of Internet