IT資産管理

【連載企画第二回】自社のセキュリティ対策に“シカク”はないか?(課題の発見)

Written by 香山 哲司

ジーブレイン株式会社 コンサルティング事業部 シニアコンサルタント(2019年6月~)
2001年、マイクロソフト株式会社(現、日本マイクロソフト株式会社)に入社、エンタープライズサービス部門に所属。
電力・ガス会社、また政令指定都市向けの大規模環境における認証基盤やスマートカード導入の支援を中心的な役割で担当。
2007年CISSPを取得後、
2010年7月(ISC)2より第4回アジア・パシフィック Information Security Leadership Achievements アワードを受賞。

【連載企画第二回】自社のセキュリティ対策に“シカク”はないか?(課題の発見)

AIサービス利用ガイドライン

“ChatGPT”の社内利用ルール、どう決める?
【AIサービス利用ガイドライン】を公開!

MOTEXが社内向けに作成したAIサービス利用ガイドラインをダウンロードできます。利用方針の決め方、作成ポイントの解説付き!

資料をダウンロードする

ホワイトペーパー

セキュリティ 7つの習慣・20の事例「セキュリティブック」

関連記事

【連載企画第一回】 セキュリティ事故の“ミカタ”

関連記事

【連載企画第三回】脆弱性を?ディス”る(課題の解決)

連載企画第1回の記事では「セキュリティ事故の“ミカタ”(現状分析)」と題して、過去のコンサルティング経験やお客様との会話で常々気になっている次の2点を取り上げ解説しました。

  • ・脅威と脆弱性とリスクをきちんと区別して整理できているか。
  • ・ITILのPeople Process Products、3単語の頭文字をとった「3つのP」をセキュリティ運用においても日頃から意識されているか。

読者の方から「やっと腹落ちできた」と、ありがたいコメントをいただき、基本的なことを繰り返し情報発信し続けることの大切さを感じるものでした。

情報セキュリティにおける潜在的な課題発見

さて、前回の内容をもう少し掘り下げるなら「外部」で起こったセキュリティ事故をどのように捉えるか、その際に役立つ基本的な枠組みとも言えます。
今回は「自組織」にどのような課題があるのか第1回の内容を念頭におきながら「第2回 その課題発見にシカクは?(課題の発見)」を解説していきます。

情報セキュリティ事故に限らず、“痛い目にあって”初めて潜在的な課題があったこと、ついうっかりミスをしやすい環境にあったことに気付くことは多いのではないでしょうか。痛い目にあった後「そもそも何が問題だったのか」根本原因を探り、再発防止を本格的に検討することはありがちなことです。

飲酒運転して重大な事故を起こすなど、運転手がルールを逸脱して事故になる場合と、運転席から見える景色に死角(シカク)があり周辺の状況確認ができないまま発進し、痛ましい事故が起こる場合もあります。

同様に、IT機器を扱うリテラシーやモラルの欠如など基本的な使い方に問題があるためにインシデントにつながることもあれば、IT機器が正しく実装・運用されていないためにインシデントにつながることがあります。どちらも大切なテーマですが、今回の記事では企業のIT実装・運用におけるセキュリティを対象とするため、リテラシーやモラルに関する課題は割愛いたします。

情報セキュリティの課題発見における3つの死角

できれば“痛い目に合う前”に「自組織」にどのような課題があるのか把握する上で、気を付けるべき3つの死角について解説をします。

  • ・IT業界におけるインシデントの意味
  • ・ダメージコントロール
  • ・パスワードポリシー

情報セキュリティの課題発見における死角その①
IT業界におけるインシデントの意味

医療業界でのインシデントとは、「もう少しで事故になったかもしれないこと」を“インシデント”、鉄道業界では“重大インシデント”と言われます。本当に事故になったらそれは“アクシデント”と表現される業界もあります。たとえば「京都府立医科大学附属病院における インシデント・アクシデント報告の分析」では“インシデント”と“アクシデント”の分類は以下のような表に整理されています。レベルがあがるごとに命に危険が及ぶ症状になり、途中のレベル3bから“インシデント”から“アクシデント”に表現が変わっていることがわかります。

IT業界においてインシデントは、医療の世界でいうアクシデントをインシデントととらえることが多いですが、JIS Q 27000:2014には、情報セキュリティインシデントについて以下のように記載されています。
「望まない単独若しくは一連の情報セキュリティ事象,又は予期しない単独若しくは一連の情報セキュリティ事象であって,事業運営を危うくする確率及び情報セキュリティを脅かす確率が高いもの。
前半の“望まない単独若しくは一連の情報セキュリティ事象…“は事故のことを示していますが、後半の「危うくする確率」「脅かす確率」の高いものは、もう少しで事故になったかもしれないこともインシデントに含まれるわけです。医療の世界でいうインシデントがこの部分にあたるかと思います。
インシデント対応とは事故対応と同義で使われているのですが、まさにここが死角であり、本当は事故になる可能性のある事に対応することがより重要視されるべきではないでしょうか。インシデントは業界によってさまざまな定義があるようですが、IT業界においてその意味は事故だけを示しているわけではないことをあらためて認識しておくことが大切です。

情報セキュリティの課題発見における死角その②
セキュリティダメージコントロール

昨今のマルウェアは検知しにくくなっていることを代表するように、サイバー攻撃の手法は巧妙化し防ぐことが難しくなってきたため“事故前提”の対策が重要とされはじめました。
防御一辺倒ではなく、防御を破られても被害を最小限にとどめるための活動、セキュリティダメージコントロールです。大きな火事になる前にボヤ騒ぎで収めることとも言えるでしょう。
人間はミスをします。どんなに完全なものを目指してもどこかにほころびが出て、事故発生に結び付くことから事故前提を考慮しなければなりません。
しかし管理されていない、言わば「散らかったIT環境」で事故が起こった場合の対応と、「可能な限り管理レベルをあげたIT環境」で事故が起こった場合の対応では、被害の規模や影響レベル、解決までの時間もまったく異なるものになるのではないでしょうか。
事故前提の取り組みがあるからといって、決して今の環境を放置してよいわけではありません。情報セキュリティ課題発見の死角2つ目は、事故前提でセキュリティ対策を考える風潮から現状の改善活動がおろそかになっている傾向です。
セキュリティダメージコントロールの死角とは、前述の「インシデントの意味」とも重なりますが、インシデントといっても実際の事故そのものばかり関心が集まり、ヒヤリハットをはじめ事故寸前の状態が把握しきれていないのです。
たとえばログの活用もその傾向にあります。とにかくすべてのログをとって、何か事故があったときにその前後の日付のログを見るといような運用です。こうした運用では、そもそも“ヒヤリハットしようがない状態”になっており、事故後の対応が中心になっている具体例とも言えます。
セキュリティダメージコントロールをより効果的に実施するためにも、既存環境の整備が必要なのです。
例えるならお掃除ロボットが部屋を隅々まで動き回り掃除できるように、部屋が整理されていることが大事なのです。

情報セキュリティの課題発見における死角その③
パスワードポリシー

2018年3月、総務省は「国民のための情報セキュリティサイト」を改訂し、「パスワードの定期的な変更は不要」とする方針には様々な議論が沸き起こりました。「定期的に変更するもの」とするこれまでの常識と異なり、多くの人が驚いたと思います。
パスワードは言うまでもなくシステムを利用する際、ユーザーIDとともに入力する本人確認手続き、つまり認証を行うためのシンプルな手法です。認証手続きに不備があると不正アクセスが可能になり、さまざまなインシデントに発展します。
ところで、「パスワードの定期的変更は不要」を検討する前に、そもそもパスワードを入力する際、いったいどのような場面で入力するのかという議論が抜けていないでしょうか?インパクトの大きなニュースや記事をそのまま鵜呑みにすることが3番目の死角です。

パスワードを入力するのは代表的には以下の場面があります。

  1. ① e-コマースやSNSなどで、ユーザー会員としてパスワード入力
  2. ② 企業・組織の一員であることを確認するためにパスワード入力
  3. ③ システムの設定変更などのためのシステム管理者としてパスワード入力

特に③のシステム管理者のアカウントは、特権アカウントともいわれますが、このアカウントを不正に利用されるとシステム全体に被害が出るため、特に重要なアカウントとして位置づけられます。
さて、このいずれのパターンも本当にパスワードの定期的変更は不要なのでしょうか?
筆者の経験上、重要システムの特権アカウントはパスワード認証ではなくICカードなど多要素認証を活用することが推奨され、一部の企業ではすでにそのような運用がされています。
それをもってパスワードはもう使っていないから定期的変更は必要ないとする趣旨なら合理性はありますが、そうでない場合、パスワードを定期的に変更しないことは危険な場合があると考えるのが筆者の意見です。

今回の記事では詳細を割愛しますが、Windowsの認証方式の弱点を突いたPass the HASH攻撃はNTLM認証で利用されるHASH値を不正に取得し、条件が整うとActive Directoryの管理者アカウントが乗っ取られる事態になります。
説明は不要かと思いますが、通常パスワードはそのまま保存されるのではなく、ランダムな固定長の値に変換する「不可逆変換」されたものをHASH値と呼びます。HASH値から元のパスワードに戻すことは困難な状態になっています。
ただ、NTLM認証ではパスワードを変更しない限りずっと同じHASH値のままなのです。一度不正に入手したHASH値の再利用(悪用)を試みる攻撃者にとって、パスワードを定期的に変更しないことは攻撃者に有利な状況を作ってしまっていると言えるのではないでしょうか。
パスワードの定期的変更については様々な意見がありますが、少なくともNTLM認証の弱点をついた攻撃を考察すると、パスワードを定期的に変更しないことが安全になるとは考えにくいです。多要素認証など使わずパスワードのみで認証をしている場合の特権アカウントならなおさらです。
インパクトの大きなニュースを十分に吟味しないまま、パスワード設定を変更したりルールを変えてしまうことの危うさについて具体例をまじえてとりあげました。

まとめ

ここまでの3つの死角をまとめると次のようになります。

  • ・インシデントに結び付く可能性のある課題の発見が十分でないことが多い
  • ・既存環境の整理整頓が十分ではないのにセキュリティダメージコントロールに視点が移っている
  • ・新しいセキュリティに関する指針をどう自組織に反映するか

こうした死角を可能な限り排除し、課題の発見を効果的に補うにはどうすればいいでしょうか? 一言で言ってしまえば脆弱性を網羅的に見つけることですが、無手勝流・自分流の手法で網羅性をもって取り組むことは難しいのではないでしょうか?

課題を見つける手法のひとつとして情報セキュリティ監査を実施することが役立ちます。
一般的には情報セキュリティポリシーに基づいて活動しているかの「準拠性」、つまりポリシーどおり運用されているのかを確認していくことが監査の中心と思われがちです。
しかし監査の対象には、セキュリティポリシーの「妥当性」の確認も含まれています。
組織の情報セキュリティポリシーそのものが、情報セキュリティを取り巻く状況等に照らし妥当なものかどうかを点検・評価し、組織に正しい情報セキュリティポリシーが整っているか、妥当なものかをチェックするものになります。案外知られていない監査の分類ではないでしょうか。
妥当性監査の後、すぐにポリシー改訂と進むわけではありませんが、時代にそったセキュリティポリシーになっていない場合は、現在の脅威に則した内容に改訂することが重要です。
こうした課題の発見には、成熟度が高く、高いスキルが必要になります。広い知識を持っていることのみならず、他社での取組など自組織の中にいるだけでは見えない死角の把握にはセキュリティ資格取得も有効です。
筆者が取得したCISSP、また公認情報セキュリティ監査人、2016年から国家資格となった情報処理安全確保支援士(RISS、通称;登録セキスぺ)の集合講習講師を担当している経験から、コミュニティや様々な講習の場で現在の知識をUpdateし、実践力を上げる機会があります。こうした資格取得後の外部での活動も有効なものです。もちろん資格(シカク)があるだけで、死角(シカク)がなくなるわけではありませんが、多くの知見が必要な現在の情報セキュリティ対策を強化する上で効果的な取り組みのひとつです。

次回第3回は「課題の解決」について、代表的な解決策をとりあげ、なぜ有効なのかも補足しながら解説を進めてまいります。

AIサービス利用ガイドライン

“ChatGPT”の社内利用ルール、どう決める?
【AIサービス利用ガイドライン】を公開!

MOTEXが社内向けに作成したAIサービス利用ガイドラインをダウンロードできます。利用方針の決め方、作成ポイントの解説付き!

資料をダウンロードする