カテゴリー: 情報セキュリティ

★ 本記事のテーマ

監査員教育と監査実施経験から

で十分です。

「意外だ」と思うでしょう。

実際に、ISMS監査員やISO27001審査官は
ソフトウェア開発を長年やってきたプロが転身する
ケースがほとんどです。

なので、

情報セキュリティの専門性が高い方がよいと思われがちですが、
監査員に必要な力量はそうでもないです。

大事なのは

QCプラネッツの経験では、下図のように、

で十分です。

ここで注意なのは、

ISOだけやっていればいいわけではありません。
情報セキュリティの勉強が必要です。

言いたいのは、

と言うことです。

QCプラネッツの経験上、

では、ISMS,ISO27001監査に求められる
情報セキュリティの専門性の高さをチェックします。

どれくらいわかるか？確認しましょう！
数問程度ですが、サンプルチェックとします。

★情報セキュリティの専門性チェック

いかがでしょうか？
難しいでしょうか？

正直

そうです！その通りです！

後で紹介しますが、

で構いません。

情報セキュリティの専門性は低くてよいようなイメージを与えるかもしれませんが、次の点はしっかりと作りこむ必要があります。

一言でいえば、

が大事です。

でも、

リスクアセスメントを総合的にみてもよいですが、下図のようにシンプルに集約できます。シンプルになるように統体して考え抜きました。

そして、

例えば、

監査員としてどう答えるべきか？

★ ×な回答

ＶＰＮとはVirtual Private Networkの事です。　
（相手は混乱するし、だから何なの？です。）

★○な解答

インターネットに入ると外の不審者が侵入してくるリスクがあります。なので、自分たちだけの空間の中だけネットできるようにして、外部侵入を防ぐものです。
（わかりやすいし、相手がどう防御すべきかも理解できる。）

これができれば、専門用語はそれほど怖くありません。

あなたの情報セキュリティの専門性より、

ですよね！

となると、

をしっかり見る力量の方が大事です。

QCプラネッツは

と願っています。

マネジメントシステムの基礎であり、理解しやすいISO9001を軸に、
情報セキュリティ寄りなISO27001へ広げていく視野が
組織とって良い監査質疑・評価ができるようになると分かっています。

①でも述べた通りですが、具体的に抽象化する方法を解説します。

という問いを自問しましょう。これが一番大事！

QCプラネッツは

●防犯体制が万全な豪邸で、外部侵入が難しいことが容易に想像つきます。だから内部を狙う（内部不正・情報漏洩）

●強い相手を倒すことより、弱くてトロイ者が狙われる。（正面突破より脆さ・騙しで侵入）

シンプルにこれくらいしかありません。

カタカナ用語で、難しいサイバー攻撃と言われると何か怖いイメージがありますが、よく考えるとやること、守ることはそれほどありません。

監査で一番神経を使うのが、

です。

専門性を確認しても意味がないし、
組織の情報セキュリティ強化につながる問いでなければ意味がない。

なので、専門知識を自分の言葉で説明ができ、相手にどう動いてもらうかを伝えるところまで、考え抜く必要があります。

情報セキュリティに対する組織という相手を知りましょう。

情報セキュリティに限らず、「２，６，２の法則」は一般に成り立ちます。

監査質疑対応する側は、

です。

大事なのは、

です。

組織の情報セキュリティは
どこか１か所でも突かれるとインシデントになってしまいます。

やる気がない人や、トロイ部分をどうやって
良くしていけばいいのでしょうか？

組織全員へ浸透させ、行動に移せているかを監査でみましょう。

●どんな汗をかいているのか？
●組織が動機づけするための苦労があるかどうか？　
●組織メンバーが自分事としているのか？
●要求事項の番号にあてはめより、組織が本当に機能しているかをチェックしたい。

そのためには、

情報セキュリティの専門用語や要求事項はその後でもよい。

となるはずです。

ここまで読んでいただければ、わかると思います。

でOKです。

余力があれば、

IPA(情報処理推進機構)の情報セキュリティ10大脅威20XX年
の事例をチェックし、なぜ発生したかを考える演習をしてください。

最初は、知識や情報を暗記で安心しますが、
監査はその情報から課題抽出・解決を導く思考力が
求められます。

専門用語の正確さも大事ですが、
目的達成に必要な提案力・思考へシフトしていけば、
立派な監査質疑ができるようになります。

頑張りましょう

以上、「ISMS,ISO27001 内部監査員に必要な力量がわかる」を解説しました。

★ 本記事のテーマ

多くの要求内容を求められる
ISMS,ISO27001ですが、
組織に必要なルールとは
具体的にどんなものかは
あまり知られていません。

組織で必要最低限のルールを解説し
ISMSの構築の仕方をお伝えします。

大事なのは

当然、組織の初期の状態は、
情報セキュリティは気持ちはあっても、ルール等は未整備です。

その組織にいろいろな苦労を経て
ISMSが構築されていったはずです。

その経緯、流れを理解することが大事です。

関連ブログ記事にて、確認ください。

【リンク】【重要】組織がゼロからISMS(ISO27001)水準に引き上げる手順がわかる どんな背景・理由を経て、ISMSを構築していったのか？をわかりやすく解説します。

リンクの解説記事のとおり、
必要な規程類がいくつかあります。

その規程類の種類、目的、必要な要求事項を下表にまとめます。

ここまで具体的に紹介する記事が
意外とないので、
QCプラネッツから紹介します。

個別に見ていきます。

★目的

★必要な要求事項

★目的

★必要な要求事項

★目的

★必要な要求事項

★目的

★必要な要求事項

★目的

★必要な要求事項

★目的

★必要な要求事項

★目的

★必要な要求事項

★目的

★必要な要求事項

★目的

★必要な要求事項

★目的

★必要な要求事項

★目的

★必要な要求事項

★目的

★必要な要求事項

★目的

★必要な要求事項

★目的

★必要な要求事項

いかがでしょうか。
１つずつ見ていけば、
項目だけでも、
あなたの組織でやるべきことが
具体的に見えるはずです。

以上、「ISMS,ISO27001 組織に必要な規程類がわかる」を解説しました。

★ 本記事のテーマ

多くの要求内容を求められる
ISMS,ISO27001ですが、
どの組織も最初から細かくルールを
構築・運用しているわけではありません。

組織で必要最低限のルール運用から
ISMS,ISO27001要求レベルまでの上げ方を
解説します。

まず、ゴールである、
ISMS,ISO27001　運用する組織に
必要な規程一覧を
紹介します。

関連ブログ記事にて、確認ください。

【ISMS,ISO27001　運用する組織に必要な規程が何かがわかる】リンク 情報セキュリティは煩雑な運用になりがちなため、必要最低限にするコツが大事！

リンクのとおり、
情報セキュリティは品質管理より要求事項が多いため、
必要最低限の規程類でまとめることが大事です。

その一覧は

No	ISMS	目的
1	情報セキュリティーポリシー	経営陣からの情報セキュリティに対する宣言
2	情報セキュリティ運営管理規程	ISMS体制・責任を定めたもの
3	文書化した情報の管理	文書管理方法
4	ISMSマニュアルの発行・管理	規程類以外で、必要な定義をまとめたもの
5	セキュリティ事件・事故管理規程	インシデント発生時の対応方法
6	人的セキュリティ管理規程	力量向上に必要な要求事項
7	是正処置管理規程	不適合、インシデント発生後の処置方法
8	内部監査管理規程	内部監査運用
9	外部審査管理規程	外部審査運用
10	事業継続管理規程	不慮の災害・事故に対する被害を最小化するルール
11	アクセス管理規程	アクセス管理方法
12	物理的・環境的管理規程	業務フロアー内のルール
13	リスクマネジメント管理規程	リスクへの対応方法
14	法規制管理	情報セキュリティ法規制関連

上の表にて、
・それぞれの規程類の目的
・規程類以外にISMSマニュアルを追加
を加えます。

それを下表でまとめます。

行	番号	文書一覧
1	(1)	情報セキュリティーポリシー
2	(2)	ISMSマニュアル
3	1	適用範囲関連資料(1.組織図)
4	2	適用範囲関連資料(2.周辺地図・ビル全体図・フロア図)
5	3	適用範囲関連資料(3.ネットワーク図)
6	4	適用範囲関連資料(4.ISMS推進体制図&緊急連絡体制図)
7	(3)	情報セキュリティ運営管理規程
8	1	年間情報セキュリティ目標
9	2	情報セキュリティ委員会録
10	3	プロジェクト会議録
11	4	稟議書
12	5	外部委託における契約書,SLA
13	6	マネジメントレビュー報告書
14	7	マネジメントレビュー議事録
15	8	文書管理台帳
16	(4)	リスクマネジメント管理規程
17	1	情報資産台帳
18	2	重要資産持ち出し管理台帳
19	3	リスクアセスメント表
20	(5)	適合性管理規程
21	1	法規制管理台帳
22	2	ライセンス管理台帳
23	(6)	システムの開発および保守管理規程
24	1	ブロックリスト
25	(7)	事業継続管理規程
26	1	訓練記録
27	2	バックアップ確認表
28	3	復旧手順書
29	4	事業継続計画テスト結果記録
30	(8)	アクセス管理規程
31	1	アカウント管理台帳
32	2	アカウント申請書
33	3	誓約書
34	4	リモートワーク許可申請書
35	5	情報セキュリティー供給者レビューチェックリスト
36	(9)	物理的・環境的管理規程
37	1	入退室管理台帳
38	2	来訪者入退室管理台帳
39	3	作業報告書
40	4	情報資産台帳廃棄管理台帳
41	(10)	人的セキュリティ管理規程
42	1	力量管理表
43	2	力量認定要件表
44	3	教育・研修アンケート
45	4	教育・研修受講記録管理台帳
46	(11)	内部監査管理規程
47	1	内部監査員リスト
48	2	内部監査計画書
49	3	内部監査結果
50	4	内部監査報告書
51	(12)	外部審査管理規程
52	1	改善機会一覧表
53	(13)	是正処置管理規程
54	1	是正処置要求・報告書
55	(14)	セキュリティ事件・事故管理規程
56	1	セキュリティ事件・事故報告書

必要最低限なものまで絞りましたが、それでもかなりの文書が必要だとわかりますね。

どの組織でも、最初からISMS,ISO27001には対応していません。

自分たちなりに必要なルールや運用方法はどんなものかを列挙しましょう。

行	番号	文書一覧
3	1	適用範囲関連資料(1.組織図)
4	2	適用範囲関連資料(2.周辺地図・ビル全体図・フロア図)
5	3	適用範囲関連資料(3.ネットワーク図)
10	3	プロジェクト会議録
11	4	稟議書
31	1	アカウント管理台帳
32	2	アカウント申請書

ぐらいでしょう。

組織に関する基本情報、会議録、アカウント設定くらいがある程度でしょう。

大事なことは、

でも、

これから、１例として4つステップで
組織が情報セキュリティへの取り組み強化する
様子を解説します。

1つずつ見てきましょう。

気持ちとしては、本来はやりたくない業務です。

しかし、そんな組織にトラブルが発生することで
仕方がなく、対策を取り始めるのが現実
です。

意外と思うかもしれませんが

品質、環境などの管理系において、だいたい当てはまります。

具体的には、

このような攻撃を受けて、被害に遭って初めて
対策を投じることになります。

★対策

ちょっとしたルール化や
ルールを運用するための文書・帳票が
登場するようになります。

行	番号	文書一覧
3	1	適用範囲関連資料(1.組織図)
4	2	適用範囲関連資料(2.周辺地図・ビル全体図・フロア図)
5	3	適用範囲関連資料(3.ネットワーク図)
6	4	適用範囲関連資料(4.ISMS推進体制図&緊急連絡体制図)
10	3	プロジェクト会議録
11	4	稟議書
27	2	バックアップ確認表
28	3	復旧手順書
31	1	アカウント管理台帳
32	2	アカウント申請書
55	(14)	セキュリティ事件・事故管理規程
56	1	セキュリティ事件・事故報告書

上表の黄色マーカー部分が追加されるでしょう。
・緊急体制
・バックアップ・復旧
・事故報告書
などの必要最低限のものが追加されることが
イメージできますね。

【ステップ1】で済めばここでEndですが、

ルール運営化するために、
規程がいくつか増えます。

表で追加部分を見てみましょう。

行	番号	文書一覧
3	1	適用範囲関連資料(1.組織図)
4	2	適用範囲関連資料(2.周辺地図・ビル全体図・フロア図)
5	3	適用範囲関連資料(3.ネットワーク図)
6	4	適用範囲関連資料(4.ISMS推進体制図&緊急連絡体制図)
7	(3)	情報セキュリティ運営管理規程
9	2	情報セキュリティ委員会録
10	3	プロジェクト会議録
11	4	稟議書
12	5	外部委託における契約書,SLA
16	(4)	リスクマネジメント管理規程
17	1	情報資産台帳
18	2	重要資産持ち出し管理台帳
25	(7)	事業継続管理規程
27	2	バックアップ確認表
28	3	復旧手順書
30	(8)	アクセス管理規程
31	1	アカウント管理台帳
32	2	アカウント申請書
36	(9)	物理的・環境的管理規程
37	1	入退室管理台帳
38	2	来訪者入退室管理台帳
39	3	作業報告書
40	4	情報資産台帳廃棄管理台帳
41	(10)	人的セキュリティ管理規程
42	1	力量管理表
44	3	教育・研修アンケート
55	(14)	セキュリティ事件・事故管理規程
56	1	セキュリティ事件・事故報告書

いかがでしょうか。
上表からいくつか規程が登場しています。

情報セキュリティ対策を
組織で運用するために、
ルール整備が整ってきます。

【ステップ2】でも十分かと思いますが、
それなりにセキュリティレベルが上がったとはいえ、
内外の環境状況をみて、

ルールができたとはいえ、形骸化するのは時間の問題でもあり、
有効に機能させるための組織化が必要となります。

表で追加部分を見てみましょう。

行	番号	文書一覧
1	(1)	情報セキュリティーポリシー
3	1	適用範囲関連資料(1.組織図)
4	2	適用範囲関連資料(2.周辺地図・ビル全体図・フロア図)
5	3	適用範囲関連資料(3.ネットワーク図)
6	4	適用範囲関連資料(4.ISMS推進体制図&緊急連絡体制図)
7	(3)	情報セキュリティ運営管理規程
8	1	年間情報セキュリティ目標
9	2	情報セキュリティ委員会録
10	3	プロジェクト会議録
11	4	稟議書
12	5	外部委託における契約書,SLA
15	8	文書管理台帳
16	(4)	リスクマネジメント管理規程
17	1	情報資産台帳
18	2	重要資産持ち出し管理台帳
20	(5)	適合性管理規程
21	1	法規制管理台帳
22	2	ライセンス管理台帳
23	(6)	システムの開発および保守管理規程
24	1	ブロックリスト
25	(7)	事業継続管理規程
26	1	訓練記録
27	2	バックアップ確認表
28	3	復旧手順書
29	4	事業継続計画テスト結果記録
30	(8)	アクセス管理規程
31	1	アカウント管理台帳
32	2	アカウント申請書
33	3	誓約書
34	4	リモートワーク許可申請書
36	(9)	物理的・環境的管理規程
37	1	入退室管理台帳
38	2	来訪者入退室管理台帳
39	3	作業報告書
40	4	情報資産台帳廃棄管理台帳
41	(10)	人的セキュリティ管理規程
42	1	力量管理表
44	3	教育・研修アンケート
45	4	教育・研修受講記録管理台帳
53	(13)	是正処置管理規程
54	1	是正処置要求・報告書
55	(14)	セキュリティ事件・事故管理規程
56	1	セキュリティ事件・事故報告書

上表からわかるように、組織化によって、
下の項目が追加されました。

情報セキュリティ対策を
組織で運用するために、
ルール整備が整ってきます。

【ステップ3】レベルまで組織運用できていれば、

となるでしょう。

あとは、

具体的には、

が追加されます。
すでに、組織でISMS運用が機能されているので、
追加対応はそれほど大変でもないでしょう。

【ステップ0】から【ステップ4】までの変化を図でまとめます。

本記事のやり方が絶対ではなく、
組織によって、若干の味付けの違いはあるでしょう。

ただ、いきなり、
ISMS,ISO27001要求レベル
へ組織をもっていくのは、
無理なので、
１つずつステップを刻む必要があります。

以上、「【重要】組織がゼロからISMS(ISO27001)水準に引き上げる手順がわかる」を解説しました。

★ 本記事のテーマ

ISOでは必須ではなくなったマネジメントマニュアルですが、
割と提出が求められるものです。

手間をかけないためにも
シンプルであることが最も大事です。

品質にも、「品質マニュアル」があります。
品質マニュアルの書き方や運用について
ブログ記事を紹介します。

【品質マニュアルがわかる】リンク 書き方、運用のポイントをわかりやすく解説します！

マネジメントシステムのマニュアルは
元々は最上位文書でした。

ISO要求事項は、文書管理をベースとしていたのが背景です。

ISO9001 2015以降、マニュアルは
ISOの最上位文書から、
オプションの位置でよいと
暗に伝えています。(明確には書いていませんけど)

その理由は、

じゃー、マニュアルは要らない！のか？
というと、

例えば、

なので、

ただし、手間がかかるのでシンプルにしたいですよね。

いろいろな組織の監査や、
マネジメントシステムの講習演習などで、
マニュアルを見てきました。

ほとんどのマニュアル構成は以下となっています。

注意点は、

ISO27001では、
30超の要求事項+93管理策
があります。

この文面を写し、
さらに、自組織の場合を追加すると、

一回100ページ超のISMSマニュアルをみたことがありました。

なぜ大変かというと、

手間だらけです。

なので、

です。

では、どうすればシンプルに作成できるかを解説します！

どうでしょうか？

過去に作ったマニュアルを
急に全く異なる構成なマニュアルに
になる点は慎重にすべきですが、
マニュアルの設計図を提唱します。

★マニュアルの中に、必要なもの

マニュアルの中に、必要なものは、

★マニュアルの外にしたいもの

としたいです。

こうすれば、ISMSマニュアルが20ページ以内に収まり、
規程類の更新の時だけ、個々のISO27001要求事項＋管理策との関係
をチェックすれば効率的な運用ができるからです。

ISMSは大事ですが、煩雑になりやすく
煩雑になると情報セキュリティインシデントの際
身動きがとれなくなります。

そうならないように、シンプルな構成がベストです。

ISOでは必須ではなくなったマネジメントマニュアルですが、
割と提出が求められるものです。

手間をかけないためにも
シンプルであることが最も大事です。

以上、「ISMSマニュアルの作り方(シンプルがベスト)」を解説しました。

★ 本記事のテーマ

インシデント発生は「恐怖・不安」ですが、
本当ですか？

煩雑な運用である、情報セキュリティだけに、
冷静であることが最も大事です。

いくつか事例を挙げます。

どうでしょうか？

「情報セキュリティインシデント」と聞くと、どうでしょうか？

が伝わってきます！

恐怖にかられると、天邪鬼なＱＣプラネッツは
「ホンマにそうなの？」
「しっかり対策を取っていても攻撃でやれらるの？」
「ぶっちゃけインシデント発生した真相はどうなの？」
と疑ってしまいます。

公になっている情報を鵜呑みせず、一旦冷静になりませんか？

このテーマですが、あえて、考えましょう！

この意地悪な問いに対して、
理由がなければ、
情報セキュリティインシデントは本当に恐怖だと
思います。

天邪鬼なＱＣプラネッツはこの問をこう考えます。

いくつか考えてみました。

こういう情報ばかりだと、不安になるし、
専門家にすがりたくなります。

でも、それは相手の思う壺かもしれません。

本当に知りたいのは、

です。

我々がいつも想像するのは、下図のように、
(1)普段からあるべき防御力があるが、
(2)それを上回る攻撃を受けた。

だから、情報セキュリティインシデントは怖い！
であれば、仕方がないし、納得できます。

しかし、実体はどうでしょうか？

我々がいつも想像するのは、下図のように、
(3)普段からあるべき防御力があるが、
適正な運用がなく、本来の防御力が機能していない。
または、実は防御力そのものが低かった。

だから
他社なら回避できる程度の攻撃でもインシデントになってしまった。

可能性もあるでしょう。

しかし、
実体（本来の実力）を知らない（公表されない）から
名のある企業なら
「情報セキュリティ体制は万全なのにどうして？」
と過大評価することも考えられる。

実情を冷静かつ客観的に見る必要があります。
そのために、「報告書」が公表されています。

しかし、

「報告書」にインシデントの真因は書かれていない場合がほとんど

これは、なぜでしょうか？

⑤情報セキュリティインシデントの真因を隠す傾向が強い

会計、品質、環境、情報セキュリティなどの管理すべきものは、
不正や法令違反がある場合、組織・企業は真因究明と再発防止を
コミットするために報告書を公表しています。

品質不正は必ず真因を報告書に載せる

品質不正事例は、ＱＣプラネッツのブログ記事でまとめています。

【まとめ】品質不正がよくわかる

どの報告書も、真因は明快に書かれています。
だから、さらに深部へ分析ができる。

どの報告書も、真因は明快に書かれています。

情報セキュリティインシデント報告書は真因を明示しない

一方、情報セキュリティインシデントは
報告書に真因を明示しない、
公表しない場合が
多いです。

それには理由があるからです。

★理由

情報セキュリティインシデントは犯罪行為。
犯罪の手口を明示すると再犯されるリスクがある。

確かに、納得がいく理由です。

しかし、１つ注意が必要で、

対象となった組織・企業の情報セキュリティの防御力が低い弱点をさらさなくて済む。

本来、組織が改善すべきポイントが露わにならないため、
改善したと後日公表しても、本当かどうかは疑わしいかもしれません。

品質でもそうですが、
組織改革にはエネルギーと時間がすごくかかります。
その間に、再攻撃受けるリスクが残っています。

情報セキュリティインシデント真因をあるある

とはいえ、
数件ですが、
真因を明示している事例もあります。
(本当にありがたいです！)

その事例を紹介します。

★ 真因

1. 名のある大企業だが、情報セキュリティ専門者が0.5人(他業務と兼任)。
2. 大病院だが、管理者パスワードが初期設定のままだった。
3. 業務中に、ＮＧなサイトをクリック・ダウンロードしてしまった。
4. インシデント対策訓練

確かに、
・報告書では体制強化、モラル・意識向上など
難しく、それらしい言葉が並ぶが、
上の理由を見れば、
「そりゃ、ダメでしょう！」
と言いたくなるものが意外と多いです。

少ない情報の中、
名のある企業・組織だからと
過大評価せず、
何が真因なのかをよく考え、調べる必要があります。

⑥サイバー攻撃する方も実は大変苦労している

サイバー攻撃は確かに怖いけど。。。

1日、数百万件のサイバー攻撃を我々は受けています。
確かに、怖い！
でも、ここでも冷静に考えてみましょう。

攻撃力が上がれば、相手の防御力も上がる

20年前は、確かに世界的なサイバー事件がニュースになり、
知り合いがその対象になったことを思い出します。

しかし、

攻撃力や攻撃種類が上がると、
すぐに対策が講じられ、
それほど深刻ではないと
いう冷静な目線も必要です。

攻撃は犯罪行為であり、逮捕されるリスクがあります。
一方、防御は良い行為であり、評価されるメリットがあります。

あなたが優秀なハッカーなら
攻撃?
防御?
どちらで飯を食いますか?

明らかに、後者ですよね。

多数の攻撃のイメージ

など、考えると、

攻撃力や攻撃種類が上がると、
すぐに対策が講じられ、
それほど深刻ではないと
いう冷静な目線も必要です。

★ハッキングのイメージ

ハッキング攻撃のイメージは
下図のように、
組織のセキュリティの壁を叩きまくって
力で壁を壊し内部に侵入する

とよく思われているはずです。

しかし、実際は、防御力も高く、外部から力で侵入するのは難しいです。

実際は、下図のように、
道にとりあえず、ハッキングする種をばらまき
そこに引っかかる獲物を捕まえる

方が現実的ではないでしょうか。

汚い例ですが、
「道に放置された動物の糞を避けれるのに、
うっかり踏んでしまった」
のが情報セキュリティインシデント
というイメージがわかりやすいでしょう。

⑦情報セキュリティインシデント対策でやるべきこと

情報セキュリティインシデントはリスクであることは間違いありません。

しかし、見えない恐怖に疑心暗鬼にならずに、冷静に考えて対応しましょう！

では、どのような対策をすればよいでしょうか？

情報セキュリティインシデント対策

大事なのは、

●たくさん対策をとるな!（逆効果）
●レベルの高いことをやるな!（組織全員では無理）
●外部攻撃より、身近なミス・不正防止を徹底（その方が確実）

でしょう。

難しく、たくさん対策して万全と言えば、
かっこいいと思いがちですが、それは無理で、逆効果です。

●個人レベルでは簡単な対策でいい。
●簡単なアクションを組織全体で回すことに一番注力すべきです。

当たり前のことを、皆でやる！
がISMSであり、
ISO27001です。

まとめ

以上、「疑心暗鬼に陥りがちな「情報セキュリティインシデント」（冷静になれ！）」を解説しました。

• ①情報セキュリティインシデント事例
• ②ありがちな恐怖
• ③その恐怖は本当なの？
• ④恐怖・不安を仰ぐ理由
• ⑤情報セキュリティインシデントの真因を隠す傾向が強い
• ⑥サイバー攻撃する方も実は大変苦労している
• ⑦情報セキュリティインシデント対策でやるべきこと