セキュリティ研修〜マネジメントパート〜（サイバーエージェント新卒研修2024）

Slide 1

Slide 1 text

24新卒エンジニア向け  セキュリティ研修  ～マネジメントパート～  2024/4 

Slide 2

Slide 2 text

はじめに  新入社員のみなさん  入社おめでとうございます🎉  

Slide 3

Slide 3 text

自己紹介  アシスタントの皆さんパーくん楽天家でドーナツ好きな男の子宇宙人に狙われているパーにゃん明るくノリの良いバリキャリ女子パーくん憧れの先輩らしい

Slide 4

Slide 4 text

自己紹介  アシスタントの皆さんパーマン通称「情報セキュリティ博士」イギリス出身のジェントルメンワームくんサイバー攻撃で地球侵略を目論む見た目に違わず The 地球外生命体

Slide 5

Slide 5 text

はじめに          本パートの目的 

Slide 6

Slide 6 text

はじめに  情報セキュリティの全体像を知る 

Slide 7

Slide 7 text

はじめに  エンジニアと情報セキュリティ  セキュリティのルール作ったよ！  開発のセキュリティ基準作ったよ！  リーダー開発者

Slide 8

Slide 8 text

はじめに  エンジニアと情報セキュリティ  セキュリティのルール作ったよ！  開発のセキュリティ基準作ったよ！  リーダー開発者セキュリティのルール守るよ！  開発のセキュリティ基準に従うよ！ 

Slide 9

Slide 9 text

9 リーダー開発者正直、理由はよくわかんないけど  とりあえず言われたとおりにやろう 

Slide 10

Slide 10 text

10 これでは、もったいないリーダー開発者正直、理由はよくわかんないけど  とりあえず言われたとおりにやろう 

Slide 11

Slide 11 text

はじめに  とは言え、いきなり  あれもこれも覚えるのは無理なので… 

Slide 12

Slide 12 text

はじめに  情報セキュリティを理解するための  ハコ（全体像）を押さえましょう 

Slide 13

Slide 13 text

はじめに          そもそもサイバーエージェントにおける  「エンジニア」の仕事とは？ 

Slide 14

Slide 14 text

はじめに  社会で広く利用されているサイバーエージェントの  サービスを開発する仕事です 

Slide 15

Slide 15 text

15 安心安全なサービスを維持しないと。。。            　　　　数多くの人間に被害を与えてしまいます 

Slide 16

Slide 16 text

16 サービス利用者の「個人情報」が漏れると、、、 ● アカウントの乗っ取り・なりすまし ● 悪徳商法・ストーカー・脅しのネタに悪用される ● ダークウェブ（闇のEC）で取引される想像以上の被害に発展する可能性がありますなんで私の今いる場所が  バレてるの！？怖いよ... 

Slide 17

Slide 17 text

17 会社との契約で「漏らしてはいけない」情報が漏れると、、、 ● 取引先、ユーザー、株主の信用を失ってしまう ● 漏らした情報を悪用されて損害を発生させてしまう巨額の損害に発展する可能性があります大丈夫って言うから情報を預けたのに…  もう一緒に仕事しないぞ！！ 

Slide 18

Slide 18 text

18 社会に大きな影響を与える＝ネガティブな影響も与えうる  ● 炎上する  ● ユーザーが激減する  ● 法的責任を問われる  ● 今後の新サービスにネガティブな影響を及ぼす　など    事業を続けることが困難になりかねない。 

Slide 19

Slide 19 text

はじめに  どんなに良いサービスでも    ひとつのセキュリティ事故で消し飛ぶ可能性があります 

Slide 20

Slide 20 text

はじめに  サイバーエージェントでは、ビジネスに  直結するリスクを「一発アウト」と呼んでいます 

Slide 21

Slide 21 text

はじめに  「不安」「心配」で思考停止せずに  情報セキュリティの枠組みを知り  「一発アウト」のリスクに  アンテナを張れるようになりましょう 

Slide 22

Slide 22 text

情報セキュリティ概要

Slide 23

Slide 23 text

情報セキュリティとは  全体像が分からないと考えようがないそもそも、どこから何を考えたらいんだろう...？

Slide 24

Slide 24 text

情報セキュリティとは  まずは手堅く  「情報セキュリティ」の  定義から確認しましょう 

Slide 25

Slide 25 text

情報セキュリティとは  各産業の標準化などを進めている組織  「JISC(日本産業標準調査会)」を当たってみます   

Slide 26

Slide 26 text

情報セキュリティとは JIS Q 27000:2019の定義  3.28   情報セキュリティ（information security）   情報の機密性（3.10）、完全性（3.36）及び可用性（3.7）を  維持すること。     さらに，真正性（3.6），責任追跡性，否認防止（3.48），信頼性（3.55）などの特性を維持することを含めることもある。 

Slide 27

Slide 27 text

情報セキュリティとは  ざっくり言ってしまえば、  ● 機密性  ● 完全性  ● 可用性  の３要素を維持できていないと  　　　情報セキュリティではないようです   

Slide 28

Slide 28 text

情報セキュリティとは  とは言え、これでは  まだちょっとよく分かりません 

Slide 29

Slide 29 text

情報セキュリティとは  そこで次に  ３要素の定義を確認してみましょう 

Slide 30

Slide 30 text

情報セキュリティとは  先にざっくり言ってしまうと、下記のようになります。    ● 機密性　＝　漏らさない  ● 完全性　＝　改ざんされていない  ● 可用性　＝　いつでも使えるようにする    これを念頭に置いて定義を確認します。 

Slide 31

Slide 31 text

機密性(Confidentiality)  認可されていない個人、エンティティ又はプロセスに対して、  情報を使用させず、また、開示しない特性。      「認可」については、後ほど掘り下げましょう。  情報セキュリティとは 

Slide 32

Slide 32 text

エンティティ？プロセス？情報セキュリティとは 

Slide 33

Slide 33 text

情報資産にアクセスするのは  人間だけとは限りません  管理者 SIEMサービス人力でもログを見ることもできるログ情報にアクセスアラート発報このため「エンティティ」と  表現する必要があります  情報セキュリティとは  システム内のログ情報

Slide 34

Slide 34 text

完全性(Integrity)  正確さ及び完全さの特性。      完全性のみ損なうケースとして、例えば、  ・認可された人間による内部犯行、  ・認可されたエンティティによる誤操作  などが考えられます。  情報セキュリティとは 

Slide 35

Slide 35 text

可用性(Availability) 認可されたエンティティが要求したときに、アクセス及び使用が可能である特性。可用性を度外視して機密性・完全性に振り切ると、業務の利便性を損なう恐れがあります。    そうなると、正規の手順を飛ばすなどの脱法行為やシャドーIT等の問題を招く可能性があり、  結果的に機密性や完全性を損なう事態に至ることがあります。  情報セキュリティとは 

Slide 36

Slide 36 text

● 機密性（Confidentiality）  ● 完全性（Integrity）  ● 可用性（Availability）  完全性  Integrity  機密性  Confidentiality  可用性  Availability  情報セキュリティ3要素  CIA  これらを脅かすものから情報資産を  守ることが情報セキュリティの  基本的な考え方です    情報セキュリティを保つことは、  ビジネス（事業）を継続するうえで、  とても大切なポイントになります。  情報セキュリティとは 

Slide 37

Slide 37 text

【機密性】識別・認証・認可とは

Slide 38

Slide 38 text

【機密性】識別・認証・認可とは「機密性」について少し掘り下げましょう。    ■ 機密性のおさらい  認可されていない個人、エンティティ又はプロセスに対して、  情報を使用させず、また、開示しない特性。 

Slide 39

Slide 39 text

認可に至るまでのステップは下記のとおりです。    1. 識別  2. 認証  3. 認可    【機密性】識別・認証・認可とは

Slide 40

Slide 40 text

まずはそれぞれの定義を確認しましょう    1. 識別  ○ ユーザーがシステムに対して自分が誰か宣言すること  2. 認証  ○ システムがそのユーザーが宣言した人物か確認すること  3. 認可  ○ 認証されたユーザーがシステムの特定のリソースにアクセスすることを許可すること    【参考】 ● NIST SP 800-63 ● RFC4949

Slide 41

Slide 41 text

マンションの部屋を借りる場面で例えてみます。  地球侵略の足掛かりに部屋を借りるぜ！  【機密性】識別・認証・認可とは

Slide 42

Slide 42 text

機密性に関する情報セキュリティ対策の例「認可」に至るまでのステップ 

Slide 43

Slide 43 text

機密性に関する情報セキュリティ対策の例「認可」に至るまでのステップ  ①識別契約で部屋を借りる宣言をする 103号室はワームくんが使う

Slide 44

Slide 44 text

機密性に関する情報セキュリティ対策の例「認可」に至るまでのステップ  ①識別 ➁認証鍵を持ってマンションに入る鍵があるから本人だろう契約で部屋を借りる宣言をする 103号室はワームくんが使う

Slide 45

Slide 45 text

機密性に関する情報セキュリティ対策の例「認可」に至るまでのステップ  ①識別 ➁認証 ③認可借主が借りている部屋に入るワームくんは 103号室なら入れる契約で部屋を借りる宣言をする 103号室はワームくんが使う鍵を持ってマンションに入る鍵があるから本人だろう

Slide 46

Slide 46 text

機密性に関する情報セキュリティ対策の例 ①識別が無いと、➁認証で弾かれる  ①識別 ➁認証賃貸借契約で部屋を借りる宣言をする契約しないと入れないよ！面倒だから勝手に部屋使うぜ！ 

Slide 47

Slide 47 text

機密性に関する情報セキュリティ対策の例 ①識別しても、➁認証でユーザーの証明ができないと弾かれる  ①識別 ➁認証しまった！これ宇宙船の鍵だ…  鍵が無い？借主じゃないな！？契約で部屋を借りる宣言をする 103号室はワームくんが使う鍵を持ってマンションに入る

Slide 48

Slide 48 text

機密性に関する情報セキュリティ対策の例 ①識別と➁認証を経ても、権限がなければ ③認可で弾かれる  ①識別 ➁認証 ③認可パーくんの部屋にはいっちゃえ！  103号室以外ダメだよ！え、ちょ、怖いよ！  契約で部屋を借りる宣言をする 103号室はワームくんが使う鍵を持ってマンションに入る鍵があるから本人だろう借主が借りている部屋に入る

Slide 49

Slide 49 text

情報へアクセスする「正当さ」    これをコントロールするのが「アクセス制御」です  【機密性】識別・認証・認可とは

Slide 50

Slide 50 text

アクセス制御    ビジネス要件およびセキュリティ要件に基づいて、  情報資産へのアクセスが許可および制限されることを保証する手段のこと。      ビジネス要件とは、ザックリ言ってしまえば   「事業や業務を遂行するために必要な要件」です。     どんな事業を行うのか、  その事業ではどんな業務を定義するのか、   その業務ではどんな情報を扱うのか   これらを整理することで、必要なセキュリティ要件を占えます   【機密性】識別・認証・認可とは

Slide 51

Slide 51 text

機密性に関する情報セキュリティ対策の例 ①～③の各ステップで、様々なアクセス制御方法があります。  ①識別 ➁認証 ③認可ユーザーを登録する開発者が登録されたユーザー本人か確認する ID/PASS OKだから本人だろう許された範囲でアクセスできる開発環境はOK 本番環境はNG 開発者  システム

Slide 52

Slide 52 text

機密性に関する情報セキュリティ対策の例 ①識別 ➁認証 ③認可 MFA （Multi-Factor Authentication） ①～③の各ステップで、様々なアクセス制御方法があります。  ユーザーを登録する開発者が登録されたユーザー本人か確認する ID/PASS OKだから本人だろう許された範囲でアクセスできる開発環境はOK 本番環境はNG 開発者  システム ※ ➁はあくまでも「看做している」だけなので、単純な認証方法（例えばID/PASSの組み合わせのみの単要素認証など）では、成りすましによる不正アクセスを招く可能性が跳ね上がります。   例えば、MFAの導入などにより、ユーザー本人であることの裏付けを採ることが認証では重要になります。  

Slide 53

Slide 53 text

機密性に関する情報セキュリティ対策の例 ①～③の各ステップで、様々なアクセス制御方法があります。  ①識別 ➁認証 ③認可 RBAC （Role-Based Access Control）ユーザーを登録する開発者が登録されたユーザー本人か確認する ID/PASS OKだから本人だろう許された範囲でアクセスできる開発環境はOK 本番環境はNG 開発者  MFA （Multi-Factor Authentication）システム ※ ③は、不正アクセスをされた場合、被害の範囲を抑える観点でも重要です。   　例えば、システム内の全てのコンポーネント/データにアクセスできるアカウントが侵害を受けた場合、   　システムの乗っ取りすら可能になってしまいます。  

Slide 54

Slide 54 text

SSGでは、PERMANという認証基盤も提供しています  ・離退職/異動者の管理  ・SSO  ・MFA  開発者の皆さん PERMAN 【機密性】識別・認証・認可とはクラウドサービスＡクラウドサービスＢクラウドサービスＣ

Slide 55

Slide 55 text

リスクとは

Slide 56

Slide 56 text

リスクとは  さて、それでは、    どうすればCIAを満遍なく    維持できるのでしょうか？ 

Slide 57

Slide 57 text

リスクとは  いきなり具体的な対策から考えると迷走します  いったい何からやればいいんだろう

Slide 58

Slide 58 text

リスクとは  具体的な情報セキュリティ対策を  考えるためのプロセスを学びましょう 

Slide 59

Slide 59 text

リスクとは  ここでのキーワードは    「リスク」    です 

Slide 60

Slide 60 text

リスクとは  情報セキュリティ事故に至る    「リスク」の枠組みを知ることで    「何をすべきか」の糸口を見つけられます 

Slide 61

Slide 61 text

リスクとはまたまた手堅く    「リスク」の定義から確認しましょう 

Slide 62

Slide 62 text

特定の「脅威」が「情報資産」の「脆弱性」を悪用し、  それによって組織に害を及ぼす可能性のこと。  これは、イベントの発生確率と  その結果の組み合わせの観点から測定される。  リスク=脅威*脆弱性*情報資産    脅威情報資産脆弱性リスク【参考】 ISO/IEC 27005:2022 Information technology — Security techniques — Information security risk management リスクとは

Slide 63

Slide 63 text

リスクとはざっくり言ってしまえば、リスクは  ● 情報資産  ● 脅威  ● 脆弱性  の３要素で   　測定できるとしているようです 

Slide 64

Slide 64 text

リスクとは ● 「脅威」＝情報資産のCIAを脅かすイベント    ● 「脆弱性」＝脅威が悪用する弱点 

Slide 65

Slide 65 text

リスクとは「脅威」と「脆弱性」について、  定義を確認してみましょう 

Slide 66

Slide 66 text

脅威  　情報システムを通じた不正なアクセス、破壊、露出、情報の改ざん、  またはサービス停止による、組織の業務や資産、個人、その他の組織または国家に悪影響を与える可能性のあらゆる状況またはイベント    脆弱性  　脅威リソースによって悪用される可能性のある情報システム、  セキュリティ手順、内部統制、または実装における固有の弱点  【参考】 NIST SP 800-30 Guide for Conducting Risk Assessments リスクとは

Slide 67

Slide 67 text

リスクとはちょっとややこしいので、  例え話で考えましょう   

Slide 68

Slide 68 text

リスクとはここからは、下記のワードが頻出します。    ● 情報資産  ● 脅威  ● 脆弱性    以降、上のように色を分けて表記します。 

Slide 69

Slide 69 text

例え話）  泥棒によって  鍵が壊れたドアから  壺が盗まれるリスク  について考える   

Slide 70

Slide 70 text

例え話）  泥棒によって  鍵が壊れたドアから  壺が盗まれるリスク  について考える    脅威  脆弱性  情報資産  「壺」は「情報」資産ではないじゃない…   というツッコミはしないでね！ 

Slide 71

Slide 71 text

脅威：泥棒によって盗まれる  脆弱性：鍵が壊れたドア  情報資産：壺  壺GETだぜ！  泥棒は鍵が壊れたドアを悪用して壺を盗む

Slide 72

Slide 72 text

盗む人が居ない  脅威：泥棒によって盗まれる  脆弱性：鍵が壊れたドア  情報資産：壺  泥棒が存在しなければ、壊れた鍵は悪用されない

Slide 73

Slide 73 text

盗めない  脅威：泥棒によって盗まれる  脆弱性：鍵が壊れたドア  情報資産：壺  鍵が正常なら、泥棒は悪用できない

Slide 74

Slide 74 text

盗むものが無い   脅威：泥棒によって盗まれる  脆弱性：鍵が壊れたドア  情報資産：壺  壺が無ければ、泥棒は盗めない

Slide 75

Slide 75 text

脅威：泥棒によって盗まれる  脆弱性：鍵が壊れたドア  情報資産：壺  壺GETだぜ！  結論：情報資産・脅威・脆弱性が揃うとリスクを観測できる

Slide 76

Slide 76 text

リスクとは情報セキュリティ対策を行ううえで  我々は、情報資産・脅威・脆弱性  どれをコントロールできそうでしょうか？   

Slide 77

Slide 77 text

脅威は基本的にコントロールできない    世界中から泥棒を抹消はできないですね...    自然災害だって人の手でコントロール不可能です  リスクとは

Slide 78

Slide 78 text

情報資産のコントロールはビジネスに影響する      我々は情報資産を利用してビジネスをしています    情報資産が狙われているからと言って、  その取扱いを直ちに止めるわけにはいきません  リスクとは

Slide 79

Slide 79 text

情報資産のコントロールはビジネスに影響する      リスクとはただし、保険に加入して損害を補填したり、  壺を警備のしっかりした組織に預けるなど、  他の組織とリスクを共有することは可能です。 

Slide 80

Slide 80 text

リスクとは脆弱性は、ある程度コントロールできる    壊れた鍵を直すことはできます！ 

Slide 81

Slide 81 text

リスクとは脅威と情報資産を  認識することで、  具体的な脆弱性が見えてきます！ 

Slide 82

Slide 82 text

リスクとは具体的な脆弱性が見えてくれば、  対策も具体的に考えられます。 

Slide 83

Slide 83 text

リスクとは泥棒が壺を狙ってるわ…！    お家確認してみたら、ドアの鍵が壊れているようね。。。    なら、、、    ・監視カメラを設置して犯行を「検知」してみようかしら  ・監視中のステッカーを貼って犯行「予防」していいかも  ・それと、壊れた鍵を直して「是正」しておきましょう！ 

Slide 84

Slide 84 text

リスクとは安心・安全なサービスのために  脆弱性の潰し込みや、発見・解消に向けて  技術力を使うのがエンジニアの役割です     

Slide 85

Slide 85 text

リスクとは要するに、サービスが抱える  ● 情報資産  ● 脅威  ● 脆弱性  からリスクを洗い出すことで    具体的な情報セキュリティ対策を考えられます   

Slide 86

Slide 86 text

リスクとは実のところ、情報セキュリティの考え方は、  何も特別なものではありません。    皆さんも日常的に意識して実践しています。   

Slide 87

Slide 87 text

リスクとはカフェでお茶しているけれど、ちょっと席を外したいわ…    だけど、スマホと財布をテーブルに置いたままだと、  他の人がが盗むかもしれないわ…！  こんな感じで、おそらく皆さんも  日常的に無意識レベルで考えて実践しています 

Slide 88

Slide 88 text

リスクとはリスク分析が甘かったせいで発生した  情報セキュリティ事故事例を見てみましょう   

Slide 89

Slide 89 text

事例１    概要  　・車両利用者に対しナビゲーション等を提供するサービスにおいて、  　　個人情報を含むデータが、クラウド環境の誤設定により公開状態となっていた    被害（漏れた可能性のある情報）  　・情報：車載端末ID、車台番号、車両の位置情報、時刻  　・件数：約215万人分  　・期間：2013年11月6日～ 2023年4月17日（10年弱！）  リスクとは

Slide 90

Slide 90 text

事例１    原因  　・従業員において「何が個人情報に当たるのか」十分な認識が無かった  　・アクセス制御の観点からの監査・点検を実施していなかった    再発防止策  　・個人情報の取り扱いに関する社内教育の徹底  　・クラウド設定を監視するシステムの導入  　・個人情報の取り扱い状況に対する定期的な監査の実施  リスクとは

Slide 91

Slide 91 text

この事例の教訓...      リスクとは

Slide 92

Slide 92 text

リスクとはこの事例の教訓...    そもそもサービスで守るべき「情報資産」を  認識していない  　　　　↓  　リスクを見落としてしまう  　　　　↓  　情報セキュリティ対策が不足してしまう 

Slide 93

Slide 93 text

リスクとは「『情報資産』って大事だよね！」    と言われれば    おそらく皆さん『YES』と答えるでしょう 

Slide 94

Slide 94 text

リスクとはですが「『情報資産』って大事だよね☆！」で    思考停止してはいけません。 

Slide 95

Slide 95 text

リスクとは何が大事な情報資産か見極めないと、    必ず情報セキュリティ対策が甘くなります  社内ポータルサイト等で大事な情報資産に関する  アナウンスなどもしているので、ご参照ください。 

Slide 96

Slide 96 text

リスクとはここからは、特にエンジニアに  関係するリスクの話をします   

Slide 97

Slide 97 text

リスクとは「脆弱性」の見落としに起因した  セキュリティ事故の事例を見てみましょう   

Slide 98

Slide 98 text

事例２    概要  　・エンジニア向けの転職サービスにおいて、  　　本来マスキングされるはずの一部データが、  　　HTMLソース上にて第三者による閲覧が可能な状態になっていた    被害（漏れた可能性のある情報）  　・情報：氏名、企業からのオファー情報等  　・期間：2022年6月13日～ 2023年6月17日  リスクとは

Slide 99

Slide 99 text

事例２    原因  　・機能開発におけるシステム設計の考慮漏れ    再発防止策  　・システム設計時の社内レビュー体制を拡充する  　・社外・第三者によるレビュー体制を導入する（検討する）      サイバーエージェントでは、リリース前、および、  リリース後も定期的に脆弱性診断を実施しています。  脆弱性診断後の改修も踏まえて、  開発スケジュールを立てましょう。  リスクとは

Slide 100

Slide 100 text

事例3    概要  　ソフトウェアフレームワーク「Apache Struts 2」の脆弱性を  　悪用した不正アクセスの事例      この脆弱性の悪用は、  多くの企業に被害を及ぼしました。    ここでは、脆弱性がどのようなスピード感で  悪用されるのか一例を紹介します。  リスクとは

Slide 101

Slide 101 text

事例3    概要  　ソフトウェアフレームワーク「Apache Struts 2」の脆弱性を  　悪用した不正アクセスの事例    被害  　例えばある企業においては、下記のような被害が発生した。  　・クレジットカード番号・有効期限・セキュリティコード  　・メールアドレス等の個人情報の漏えい    ※ この企業では、再発防止委員会の設置、コールセンター設置、  　フォレンジック対応、経済産業省への報告対応、  　 PCI DSS再審査対応など膨大な事後対応も発生した  リスクとは

Slide 102

Slide 102 text

事例3    原因  　Apache Struts 2の脆弱性（S2-045/CVE-2017-5638）対応が遅れたため  「遅れた」とありますが、、、    当時、US Apache Siteで脆弱性情報が公開された翌日には、  Githubで攻撃コードが公開されています。    そして、攻撃コード公開の翌日には、攻撃が開始されています。    このように、脆弱性が公開されてから攻撃に転用されるまでの  スピードは、皆さんの想像を超えるレベルで早いものです。  リスクとは

Slide 103

Slide 103 text

サイバーエージェントでは、SSGからもツールやソフトウェアなどの脆弱性に関する情報を配信しています。  脆弱性に関する情報を収集する手段は様々あります。    しかし、自分たちがどのようなツールや  ソフトウェアを利用しているのか把握していなければ、  必要な情報を収集できません  リスクとは

Slide 104

Slide 104 text

リスクとは  よく知られている「脅威」に対抗するため、  「脆弱性」を作り込まない、見過ごさないのが、  エンジニアの重要なミッションです。      　　　　　　　　　　とは言え、、、 

Slide 105

Slide 105 text

リスクとは  エンジニアとしては、  「具体的にどこまで何をすれば良いのか」  イメージが湧かないかもしれません    このヒントになるのが、法律やガイドラインです    詳しくは後ほど一緒に学びましょう 

Slide 106

Slide 106 text

おさらい：「リスク」は  情報資産・脅威・脆弱性により特定できる。  ● 守るべき情報資産がある  ● CIAを損なう脅威がある  ● 脅威に対する脆弱性がある  リスクとは

Slide 107

Slide 107 text

このようにリスクを識別する行為を    「リスク特定」と言います  リスクとは

Slide 108

Slide 108 text

リスクアセスメント

Slide 109

Slide 109 text

おさらい  ● リスク=脅威*脆弱性*情報資産  　　　  しかし、、、  リスクアセスメント脅威情報資産脆弱性リスク【参考】 ISO/IEC 27005:2022 Information technology — Security techniques — Information security risk management

Slide 110

Slide 110 text

「リスク特定」だけでは、  情報セキュリティ対策を進めるのに  まだ十分ではありません。    なぜなら、、、  リスクアセスメント

Slide 111

Slide 111 text

その「リスク」が  どの程度「ヤバい」のか決めないと  優先順位を決められないからです。  リスクアセスメント

Slide 112

Slide 112 text

優先順位を決めないと  他人に説明できる根拠（指標）が  示せず時間やお金を使えません、、、  リスクアセスメント

Slide 113

Slide 113 text

なので、特定した「リスク」の  ヤバさの程度を表現してあげる必要があります  →　これが「リスク分析」です  リスクアセスメント

Slide 114

Slide 114 text

脅威情報資産脆弱性リスク ● 情報資産  ● 脅威  ● 脆弱性  これらを何らかの手段で数値化して、  リスク値を測定する方法があります    　☛ それぞれの円が大きくなると  　それだけ「リスク」も大きくなる  リスクアセスメント

Slide 115

Slide 115 text

例）  ○ 情報資産を損なう影響  ■ （１:影響なし～４:経営に大きな影響）  ○ 脅威の発生頻度  ■ （１:数年に1回～４:月に1回以上）  ○ 対策の脆弱性  ■ （１:強固に対策済み～４:何もしていない）  リスクアセスメント

Slide 116

Slide 116 text

当てはめ）  　医療情報を扱うシステム  　　＝経営に大きな影響「４」  　犯罪者による不正アクセスの可能性  　　＝年に1回以上「３」  　パスワード認証のみ実装している  　　＝少し対策済み「３」  　　　　　　⇒ ４×３×３＝リスク値「３６」  リスクアセスメント

Slide 117

Slide 117 text

【参考】リスク評価のメソッド例  ● DREAD  ○ 5要素を評価し平均値スコアとする  ■ Damage Potential（損害の可能性）  ■ Reproducibility（再現性）  ■ Exploitability（悪用のしやすさ）  ■ Affected Users（影響を受けるユーザ）  ■ Discoverability（発見のしやすさ）  リスクアセスメント【原文】 Microsoft Build　Chapter 3 – Threat Modeling

Slide 118

Slide 118 text

【参考】リスク評価のメソッド例  ● CVSS（Common Vulnerability Scoring System）  ○ 脆弱性を定量的に評価するためのフレームワーク  ■ 影響範囲、攻撃の複雑さ、影響等を基にスコアを算出する  リスクアセスメント

Slide 119

Slide 119 text

【参考】リスク評価のメソッド例  ● CVSS（Common Vulnerability Scoring System）  ○ 脆弱性を定量的に評価するためのフレームワーク  ■ 影響範囲、攻撃の複雑さ、影響等を基にスコアを算出する  リスクアセスメント先ほど紹介した事例3の  「Apache Struts 2」のCVSSスコアは  v2で最高値の10.0（危険）とされていました 

Slide 120

Slide 120 text

リスクアセスメントさて、リスク値で優先順位を定めたら、  今度はどのようにアプローチするべきでしょうか？ 

Slide 121

Slide 121 text

リスクアセスメントいきなり具体的な対策を考える前に、  大枠として「4つのアプローチ」を抑えましょう。 

Slide 122

Slide 122 text

リスクアセスメントリスクに対する「4つのアプローチ」 

Slide 123

Slide 123 text

リスクアセスメント ● リスク低減  ○   ● リスク回避  ○   ● リスク移転  ○   ● リスク保有  ○   【参考】ISO 31000:2018 — Risk management

Slide 124

Slide 124 text

リスクアセスメント ● リスク低減  ○ 具体的に脆弱性を潰し込むことでリスク値を下げる考え方です  ● リスク回避  ○ 情報資産の取り扱いをやめる考え方です  ● リスク移転  ○ リスク発生を別の組織体と共有する考え方です  ● リスク保有  ○ リスクがあると自覚して受け入れる考え方です  【参考】ISO 31000:2018 — Risk management

Slide 125

Slide 125 text

リスクアセスメントエンジニアの皆さんに関わる  「リスク回避」の例をご紹介します 

Slide 126

Slide 126 text

リスクアセスメントアプリケーション  ランタイム  ミドルウェア  コンテナ管理機能  OS  仮想マシン  ハードウェア  アプリケーション  ランタイム  ミドルウェア  コンテナ管理機能  OS  仮想マシン  ハードウェア  アプリケーション  ランタイム  ミドルウェア  コンテナ管理機能  OS  仮想マシン  ハードウェア  アプリケーション  ランタイム  ミドルウェア  コンテナ管理機能  OS  仮想マシン  ハードウェア  オンプレミス  IaaS  PaaS  SaaS  データ  アカウント  データ  アカウント  データ  アカウント  データ  アカウント  クラウドサービスプロバイダの責任   クラウドサービスカスタマの責任   ■ クラウド責任共有の例   皆さんがクラウドサービスを利用する場合「クラウドサービスカスタマ」となります。     皆さんがクラウドサービスを提供する場合「クラウドサービスプロバイダ」となります。     例えば、AWSやGCPなどを利用して開発をする場合、クラウドサービスプロバイダ側にセキュリティに関する対応を委ねることとなります。     その結果、皆さんは自分の責任を負う範囲に注力することが可能となります。  

Slide 127

Slide 127 text

クラウドプロバイダのサービスを  利用する場合、どのレイヤーが  プロバイダの責任なのか確認が必要です。    また、クラウドサービスプロバイダの  セキュリティ体制を確認することも大切です。    参考：AWS 責任共有モデル  リスクアセスメント

Slide 128

Slide 128 text

リスクアセスメント ● リスク低減  ○ 具体的に脆弱性を潰し込むことでリスク値を下げる考え方です  ● リスク回避  ○ 情報資産の取り扱いをやめる考え方です  ● リスク移転  ○ リスク発生を別の組織体と共有する考え方です  ● リスク保有  ○ リスクがあると自覚して受け入れる考え方です  特定・分析したリスクをどのアプローチで  処理するか定めることを「リスク評価」と称します。 

Slide 129

Slide 129 text

リスクアセスメントリスクの特定・分析・評価、この一連の取り組みを  「リスクアセスメント」と言います。  SSGではリスクアセスメントをサポートしています。  ① リスク特定 ➁ リスク分析 ③ リスク評価 ④ 優先度順に対応を推進する

Slide 130

Slide 130 text

リスクアセスメント SSGでは、クラウド等のリスクを  可視化するサービスも提供しています  管理者 RISKEN 人力でリスク把握は大変自動的にリスク評価を実施評価結果を共有クラウド上に構築したシステム

Slide 131

Slide 131 text

リスクアセスメント 4つのリスク対応を踏まえた、リスク対応のおさらい  1. 「リスク特定」「リスク分析」により現状を把握する  a. 情報資産は何で、それはどの程度重要か？  b. 脅威（CIAを脅かすもの）はどのくらいの頻度で起こり得るか？  c. その脅威に対して今何をしており、それはどの程度脆弱か？    2. 「リスク評価」でアプローチの方針を定める  a. 「リスク低減」「リスク回避」「リスク移転」を検討する  b. 優先度がものは「リスク保有」でリスクを自覚する    3. 「リスク評価」で定めたアプローチの具体案を検討する   

Slide 132

Slide 132 text

リスクアセスメント全てのリスクを「ゼロ」にすることは極めて困難です。    しかし、リスクアセスメントによりリスクを可視化し、    優先順位を付けていけば、順繰りに対策が取れます。 

Slide 133

Slide 133 text

法律・ガイドライン

Slide 134

Slide 134 text

法律・ガイドラインエンジニアが  なぜ「法律・ガイドライン」を  知らねばならないのか？ 

Slide 135

Slide 135 text

法律・ガイドライン「法律は守らないとダメ」  もちろんそれは正論ですが、  エンジニアにとって情報セキュリティの観点で、  知るメリットが存在します。 

Slide 136

Slide 136 text

法律・ガイドラインそれは、法律やガイドラインが  「情報セキュリティ対策の最低ラインになる」です 

Slide 137

Slide 137 text

法律・ガイドラインそもそも法律やガイドラインは、国や業界団体が  リスクアセスメントして作っているものです。 

Slide 138

Slide 138 text

法律・ガイドラインもし法律やガイドラインが存在しなかったら、、、  我々はゼロベースでリスクアセスメントして、  情報セキュリティ対策を考えねばなりません。 

Slide 139

Slide 139 text

法律・ガイドラインゼロベースでリスクアセスメントをすると、、、  ● 業務と併せてリスクアセスメントするのは大変  ● 情報資産、脅威を見落として脆弱性が残るかも 

Slide 140

Slide 140 text

法律・ガイドライン独立行政法人情報処理推進機構（IPA）から  出されているガイドラインの例    ● Web Appliサイバーエージェントtion Firewall 読本  https://www.ipa.go.jp/archive/security/vuln/waf.html  ● 安全なウェブサイトの作り方  https://www.ipa.go.jp/security/vuln/websecurity/about.html   ● ECサイト構築・運用セキュリティガイドライン  https://www.ipa.go.jp/security/guide/vuln/guideforecsite.html  ○ IPAセキュアプログラミング講座  https://www.ipa.go.jp/archive/security/vuln/programming/index.html 

Slide 141

Slide 141 text

法律・ガイドライン PCI DSS  ○ ロールベースでのアクセス権付与  ○ アカウントの厳格な管理  ○ 定期的な脆弱性診断/侵入テストの実施　など 

Slide 142

Slide 142 text

法律・ガイドライン PCI DSS  ○ ロールベースでのアクセス権付与  ○ アカウントの厳格な管理  ○ 定期的な脆弱性診断/侵入テストの実施　など  PCI DSSは、クレジットカード会員データを  安全に取り扱う事を目的として策定された、  クレジットカード業界のセキュリティ基準です  その要件数は400を超えます。 

Slide 143

Slide 143 text

法律・ガイドライン ISMS  ○ リスクアセスメントの実施  ○ リスクアセスメントに基づく情報セキュリティ計画の策定  ○ 内部監査の実施　など 

Slide 144

Slide 144 text

法律・ガイドライン ISMS  ○ リスクアセスメントの実施  ○ リスクアセスメントに基づく情報セキュリティ計画の策定  ○ 内部監査の実施　など  ISMSの認証には、必ず第三者機関の審査が必要です。    サイバーエージェントグループでは、例えばMG-DX社がISMSの認証を受けており、ISMSのセキュリティ管理策を遵守しています。 

Slide 145

Slide 145 text

法律・ガイドラインとは言うものの 

Slide 146

Slide 146 text

法律・ガイドライン具体的にどの法律やガイドラインを  見るべきでしょうか？ 

Slide 147

Slide 147 text

法律・ガイドライン実際は、事業で取り扱っている情報資産や、  業界の特性から法律やガイドラインを  ピックアップすることになります 

Slide 148

Slide 148 text

法律・ガイドライン例えば、  ● 個人情報を扱っている　＝　個人情報保護法　等  ● 入札で公的な認証が必要　＝　ISMS、Pマーク　等  ● クレジットカード情報　＝　PCI DSS  　…などなど、情報資産やビジネスを見て、  　　必要なものをピックアップすることになります。 

Slide 149

Slide 149 text

法律・ガイドラインエンジニアに関わる部分で、もう少し  法律やガイドラインについて掘り下げましょう   

Slide 150

Slide 150 text

法律・ガイドライン自分の担当するシステムについて  「情報セキュリティ対策もキチンとすべきだ」  と言われるかもしれません。 

Slide 151

Slide 151 text

法律・ガイドラインこれは、一見するとド正論です。  しかし、、、 

Slide 152

Slide 152 text

15 2 何をもって「キチンと」取り組んだ  と言えるのでしょうか？ 

Slide 153

Slide 153 text

法律・ガイドラインこの「キチンと」の基準になり得るのが、  法律やガイドラインです 

Slide 154

Slide 154 text

法律・ガイドラインちょっと事例を見てみましょう 

Slide 155

Slide 155 text

法律・ガイドライン事例４  ECサイトに内在する脆弱性を悪用されて情報漏洩に至った事例    X  【発注者】  Y  【受注者】  敗訴  【参考】東京地判平26.1.23判時2221-71

Slide 156

Slide 156 text

法律・ガイドライン事例４      敗訴  ECサイト開発してください！わかりました！ X  【発注者】  Y  【受注者】  【参考】東京地判平26.1.23判時2221-71

Slide 157

Slide 157 text

法律・ガイドライン事例４  X社の  ECサイト  敗訴  さぁビジネスするぞ！できました！ X  【発注者】  Y  【受注者】  【参考】東京地判平26.1.23判時2221-71 DB

Slide 158

Slide 158 text

法律・ガイドライン事例４  X社の  ECサイト  敗訴  個人情報やクレジットカード情報を保存 X  【発注者】  Y  【受注者】  【参考】東京地判平26.1.23判時2221-71 DB

Slide 159

Slide 159 text

法律・ガイドライン事例４  X社の  ECサイト  SQLインジェクションの脆弱性を  悪用してDB内の情報を窃取  へへへへ… お宝の山だぜぇ！！ X  【発注者】  Y  【受注者】  【参考】東京地判平26.1.23判時2221-71 DB

Slide 160

Slide 160 text

法律・ガイドライン事例４  X社の  ECサイト  敗訴  欠陥品作りやがって！損害賠償だ！１億払え！ X  【発注者】  Y  【受注者】  【参考】東京地判平26.1.23判時2221-71 DB

Slide 161

Slide 161 text

法律・ガイドライン事例４  X社の  ECサイト  敗訴  欠陥品作りやがって！損害賠償だ！１億払え！ X  【発注者】  Y  【受注者】  セキュリティの仕様を指示してないじゃん！【参考】東京地判平26.1.23判時2221-71 DB

Slide 162

Slide 162 text

法律・ガイドライン事例４  敗訴  裁判官  Yはプロなんでしょ？  だったら、やるべきことをやる義務があるよね。    IPAとか経産省のガイドラインでも  「SQLインジェクションの対策は必須」って  書いているじゃん。    ま～さすがに１億円の責任は無いけど、  Yはやるべきことやったって言えないから、  2千万円を損害賠償としてXに支払ってね。  【参考】東京地判平26.1.23判時2221-71

Slide 163

Slide 163 text

法律・ガイドライン我々はプロとして仕事をする立場なので、  法律やガイドラインを意識しないと、  「キチンとやった」と評価されないかもしれません。 

Slide 164

Slide 164 text

プライバシー保護

Slide 165

Slide 165 text

プライバシー保護そもそも「プライバシー」とはなんでしょう？   

Slide 166

Slide 166 text

プライバシー保護いつものように  まずは定義から確認しましょう。   

Slide 167

Slide 167 text

プライバシー保護 “他人の干渉を許さない、各個人の私生活上の自由”  　自分が他人に知られたくない情報のこと  【引用】総務省　プライバシー情報の取り扱い

Slide 168

Slide 168 text

プライバシー保護たとえば…  1. 個人情報  2. 医療情報  3. フィナンシャル情報  4. インターネット使用情報  5. 通信情報  6. 生物学的特徴 

Slide 169

Slide 169 text

プライバシー保護法律でも、プライバシー保護を図るものがあります  1. 刑法  2. 民法  3. 個人情報保護法  4. プロバイダ責任制限法　等 

Slide 170

Slide 170 text

プライバシー保護プライバシーが大事かどうかの価値観は人によるかもしれません    しかし！    少なくとも「プライバシー」は法律で  保護されるに値するものである（取り扱い注意な情報資産）と評価されている  ことは意識しましょう。 

Slide 171

Slide 171 text

プライバシー侵害の当事者になった場合に想定される影響の例  ● 賠償金支払い  ○ 個人情報保護委員会からの命令違反の場合の参考  ■ 法人：1億円以下の刑事罰  （個人：1年以下の懲役または100万以下の刑事罰）  ■ 社会的信用の失墜  ■ システム変更に伴う改修コスト  ■ その他  プライバシー保護

Slide 172

Slide 172 text

プライバシーのうち、  サイバーエージェントで最も取り扱いが多いのが  「個人情報」です。  プライバシー保護

Slide 173

Slide 173 text

サイバーエージェントでは、  個人情報の取り扱いについて  ホームページでもポリシーを宣言しています。    サイバーエージェントプライバシーポリシー  https://www.cyberagent.co.jp/privacy/  プライバシー保護

Slide 174

Slide 174 text

個人情報の難しいところは、  「これって個人情報になるの？ならないの？」  の判断が即答できないケースがあることです。  プライバシー保護

Slide 175

Slide 175 text

プライバシー保護今日の「事例１」を思い出してください。   同事例では「車載端末ID、車台番号、車両の位置情報、時刻」について、   システム運用者はこれらが個人情報との認識がありませんでした。   個人情報の難しいところは、  「これって個人情報になるの？ならないの？」  の判断が即答できないケースがあることです。 

Slide 176

Slide 176 text

まずは「個人情報」の定義から押さえましょう。  プライバシー保護

Slide 177

Slide 177 text

個人情報  「個人情報」とは、生存する個人に関する情報であって、当該情報に含まれる氏名、生年月日、その他の記述等により特定の個人を識別することができるもの（他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む。）、又は個人識別符号が含まれるもの  　　　　　　　　　　　【参照】個人情報の保護に関する法律 2条1項  プライバシー保護大まかに言うと、情報の取扱い状況から  「個人を特定できる」か否かがポイントになります。 

Slide 178

Slide 178 text

「個人を特定できるか」という観点で、  もう少しいろいろな情報を見ていきましょう。  プライバシー保護

Slide 179

Slide 179 text

下記のどれが個人情報に該当するでしょうか？  1. 遺伝子情報  2. 指紋データ  3. マイナンバー  プライバシー保護

Slide 180

Slide 180 text

プライバシー保護答えは「全て個人情報に該当する」です。    遺伝子情報も、指紋データも、マイナンバーも個々の人間が持つ固有の情報なので、個人を特定することが可能です。    よって、個人情報に該当するものです。 

Slide 181

Slide 181 text

では、下記は個人情報に該当するでしょうか？  1. メールアドレス  2. 人名のイニシャル「H・T」  3. 統計データ内にある目黒区在住の41歳男性  プライバシー保護

Slide 182

Slide 182 text

プライバシー保護答えは「全て個人情報に該当する可能性がある」です。    まず、メールアドレスもイニシャルも他の情報と合わせたり、復元することで個人を特定できる可能性がある場合、個人情報に該当することがあります。    特にメールアドレスはユーザー名＠ドメインの組み合わせで、個人の特定ができる場合、単独でも個人情報になる可能性があります。 

Slide 183

Slide 183 text

プライバシー保護統計データは、他の情報と合わせたり、復元しても個人を特定できない場合、個人情報に該当しません。    このような情報を「匿名加工情報」と呼びます。    逆に言えば、復元により個人を特定できる状況であれば、それは個人情報になります。 

Slide 184

Slide 184 text

最後に下記は個人情報に該当するでしょうか？  ● Cookie ID  プライバシー保護

Slide 185

Slide 185 text

プライバシー保護答えは「個人情報に該当する可能性がある」です。    Cookie IDは、ウェブサイトがユーザー再訪時に当該ユーザーを認識するもので、これ単独では個人を特定できるものではありません。    しかし、特定の情報と組み合わせて個人を特定できる場合は、その特定の情報と合わせて個人情報となります。 

Slide 186

Slide 186 text

プライバシー保護なお、日本の個人情報保護法では、Cookie単体で個人情報とはみなしません（個人に関連する「個人関連情報」としてルールを定めています）。    しかし、GDPRではCookie単体でも個人情報とするなど、国により扱いが違う点に注意が必要です。 

Slide 187

Slide 187 text

Cookie IDの取扱いについては、  サイバーエージェントもポリシーを出しています。    サイバーエージェントクッキーポリシー  https://www.cyberagent.co.jp/cookie/  プライバシー保護

Slide 188

Slide 188 text

インシデント対応概論

Slide 189

Slide 189 text

さて、ここまでは、  情報セキュリティ事故を如何に発生させないかに  フォーカスを当てて話してきました。  インシデント対応概論

Slide 190

Slide 190 text

しかし  インシデント対応概論

Slide 191

Slide 191 text

19 1 情報セキュリティ事故は、  大なり小なり必ず発生します 

Slide 192

Slide 192 text

なぜなら、リスクはゼロにできないからです  インシデント対応概論

Slide 193

Slide 193 text

● 情報セキュリティ事故の予兆をいち早く察知する  ● 情報セキュリティ事故が発生したら即座に対応する    この仕組み作りがポイントになります。  インシデント対応概論

Slide 194

Slide 194 text

まずは、何が「情報セキュリティ事故」に  当たるのかを理解しましょう。  インシデント対応概論

Slide 195

Slide 195 text

インシデント対応概論 ■ 情報セキュリティ事故（ISO/IEC 27000）  　一つ以上の情報セキュリティインシデントが  　組織の情報セキュリティを著しく影響させる  　可能性がある状態     

Slide 196

Slide 196 text

    続けて、  「情報セキュリティインシデント」の  定義も確認しましょう  インシデント対応概論

Slide 197

Slide 197 text

■ 情報セキュリティインシデント  （ISO/IEC 27035）  　情報セキュリティの  ● ポリシー違反または失敗  ● またはその防護措置の違反または失敗  インシデント対応概論

Slide 198

Slide 198 text

情報セキュリティ事故に至らせない、  または、至っても被害を拡大させないためには、  「情報セキュリティインシデント対応を早急かつ適切に行う」  ことが大切です  インシデント対応概論

Slide 199

Slide 199 text

エンジニアの皆さんは、  システム設計・構築・運用に携わるため、  情報セキュリティインシデントに  関わる機会が多くなります。  インシデント対応概論

Slide 200

Slide 200 text

まずは、配属先組織におけるインシデント対応のフローを確認し、  何かあったら、早急にフローを遂行できるようにしましょう。      インシデント対応概論

Slide 201

Slide 201 text

20 1 皆さんの早急な対応が、    サイバーエージェントの事業継続を左右することになります

Slide 202

Slide 202 text

エンジニアの皆さんにお願いしたいこと。  ● インシデントかも...と思ったら、  即座にインシデント対応フローに基づき報告・連絡・相談してください！  ● 少しでも早い対応が、被害拡大の阻止につながります  インシデント対応概論

Slide 203

Slide 203 text

まとめ

Slide 204

Slide 204 text

まとめ ■ 情報セキュリティとは？  　機密性、完全性、可用性を維持すること  ■ そのために何をするの？  　情報資産、脅威、脆弱性からリスクを把握する  ■ インシデント  　100％は防げない！必ず配属先の対応フローを押さえよう  　 

Slide 205

Slide 205 text

おわり