今、危険な脆弱性とその対策
―2021年上半期の診断データや攻撃事例より―

Share
キーボードと虫眼鏡

私たちの生活を支えるWebサイトは、攻撃者からみると、個人情報や機密情報などデータの宝庫であり、魅力的なターゲットになってしまっています。その理由は、Webサイトの多くに脆弱性が存在していることがあるためです。

本記事では、診断会社として多くの企業・組織への診断実績がある弊社の視点で、2021年上半期の診断結果、また攻撃事例などを振り返り、脆弱性対策に有効な手段を考えます。

Webサイトはなぜ狙われる?
―そこに脆弱性があるから

ハッカーがターゲットにしている対象のグラフデータ(The 2021 Hacker Reportより)

サイバー攻撃の対象は、Webサイトが最も高く、ハッカーのほとんどがWebサイトを攻撃しているといっても過言ではありません。

私たちの生活は公私共に、Webシステムに支えられており、Webサイトは個人情報や機密情報の宝庫です。そして、残念ながらWebサイトの多くには脆弱性が存在していることがあります。宝の山に脆弱性があるとなれば、悪意ある者に狙われてしまうのは当然といえます。

2021年上半期Webアプリケーション脆弱性診断結果

弊社では、様々な脆弱性診断メニューをご提供しております。その中で最もニーズの高いWebアプリケーション脆弱性診断について、2021年上半期(2021年1~6月)の結果をご紹介いたします。この半年間で14業種のべ610社、3,688システムに対して診断を行いました。

業種やシステムの大小にかかわらず、多くのWebアプリケーションになんらかの脆弱性が存在しています。検出された脆弱性をカテゴリ分けした内訳は円グラフのとおりです。

上半期診断結果脆弱カテゴリ別の円グラフ

このうち、例として、4割近くを占める「システム情報・ポリシーに関する問題」と、1割強程度ではあるものの、危険度の高い脆弱性が目立つ「入出力制御に関する問題」に分類される脆弱性の検出数をご覧ください(下記、棒グラフ参照)。

既知の脆弱性が検出されている、あるいはすでにベンダサポートが終了しているバージョンのOSやアプリケーションソフトの使用が数多く見られます。また、Webアプリケーションにおける脆弱性の代表格ともいえる「クロスサイトスクリプティング」や「SQLインジェクション」は、いまだ検出され続けているのが現状です。こうした脆弱性を放置しておくとどうなるか、実際に発生したインシデントの例を見てみましょう。

脆弱性を悪用した攻撃事例1:
既知の脆弱性が存在するWordPress

脆弱性のあるWordPressの悪用例

Webサイトの構築を便利にするCMS(Contents Management System)のうち、WordPressは世界でダントツのシェア40%以上を誇っています(CMS不使用は約35%、その他のCMSはすべて一桁パーセント以下のシェアです)*1。CMSの代名詞といえるWordPressですが、その分サイバー攻撃者の注目度も高く、脆弱性の発見とこれに対応したアップグレードを常に繰り返しています。

2021年に入ってからも10件以上の脆弱性が報告*2されているほか、国内でもWordPressを最新バージョンにアップデートしていなかったことで不正アクセスを受けたとの報告*3が上がっています。

脆弱性を悪用した攻撃事例2:SQLインジェクション

その対策が広く知れ渡っている今でも、「SQLインジェクション」は診断結果の中に比較的検出される項目です。

SQLインジェクション攻撃による国内情報流出事例

2021年も、実際にSQLインジェクション攻撃を受けたという報告*4が複数上がっています。

「SQLインジェクション」や「クロスサイトスクリプティング」のような、比較的知られている脆弱性に起因するインシデント事例は、企業のセキュリティ対策姿勢が疑われる結果につながり、インシデントによる直接的な被害だけでは済まない、信用の失墜やブランドイメージの低下といった大きな痛手を受ける恐れがあります。

最も危険な脆弱性ランキング

最も悪用された脆弱性ワースト30

脆弱性対策は世界的な問題です。2021年7月、アメリカ、イギリス、オーストラリア各国のセキュリティ機関が、共同で「Top Routinely Exploited Vulnerabilities(最も悪用されている脆弱性)」の30件を発表しました。

出典:https://us-cert.cisa.gov/ncas/alerts/aa21-209aより弊社作成

2021年にかけてサイバー攻撃グループが悪用していることが示唆されているものが多く含まれており、いまだ世界中の多くの企業や組織では、前述の脆弱性に対して未対応であることがうかがえます。

上記一覧からおわかりのとおり、ほとんどが、業務利用されているおなじみの製品群です。リモートワークの促進やクラウドシフトといったIT環境の変化が、既知の脆弱性に悪用する価値を与えているのです。各セキュリティ機関は、特にVPN製品に関する脆弱性に警鐘を鳴らしています。

思い当たる製品がある場合は、まずは侵害の痕跡(IoC:Indicator of Compromise)があるか確認し、必要に応じて対処する必要があります。そして可能な限り早急にパッチを適用する必要があります。いずれの製品にもセキュリティパッチがリリースされています。

最も危険なソフトウェアエラー 「CWE TOP25」2021年版

危険な脆弱性に関する情報として、米MITRE社より、「2021 CWE Top 25 Most Dangerous Software Weaknesses(最も危険なソフトウェアエラーTop25 2021年版)」も発表されています。CWE(Common Weakness Enumeration)は、ソフトウェアにおける共通脆弱性分類です。脆弱性項目ごとに一意のIDが決められ、そのタイプごとに体系化されています。

出典:https://cwe.mitre.org/top25/archive/2021/2021_cwe_top25.html より弊社翻訳

前年度と比較して順位を上げている項目については、特に脅威が高まっていると言えます。自組織のセキュリティの弱点と関係しているかといった分析や優先的に対策すべき項目の検討などに役立つ情報です。

脆弱性の対策に有効な手段とは?

多くのWebサイトに脆弱性が存在していることについて述べてまいりました。脆弱性の放置は、サイバー攻撃を誘発し、事業活動に甚大な影響を及ぼしかねません。たとえサイバー攻撃をすべて防ぎきることはできないにしても、セキュリティ対策をどのように講じてきたかという姿勢が問われる時代です。基本的なセキュリティ対策を怠っていたばかりに、大きく信頼を損ねる結果とならないようにしたいものです。

Webサイトにおける脆弱性の有無を確認するには、脆弱性診断が最も有効な手段です。自組織のセキュリティ状態を把握して、リスクを可視化することが、セキュリティ対策の第一歩となります。脆弱性診断を効果的に行うコツは、「システムライフサイクルに応じて」「定期的に」です。脆弱性の状況は、新規リリース時や改修時ばかりでなく、時宜に応じて変化することに注意が必要です。

変化という意味では、脆弱性情報のトレンドを把握するのも重要です。この点、様々なセキュリティ機関やセキュリティベンダなどが情報配信を行っていますので、最新状況のキャッチアップにご活用ください。

弊社では昨年8月に「テレワーク時代のセキュリティ情報の集め方」と題したウェビナーで、情報収集の仕方やソースリストのご紹介をしておりますので、ぜひご参考にしていただければと思います。

リスク評価、セキュリティ対策検討の初動である、脆弱性診断および脆弱性情報の収集が、健全な事業活動継続の実現に寄与します。

セキュリティレポート資料ダウンロードページボタン

年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

サービスに関するお問い合わせボタン

サービスに関する疑問や質問はこちらから
お気軽にお問合せください。


 

SQAT® Security Serviceページへのバナー

 

BBSecコーポレートサイトへのバナー

Share

企業が絶対にやってはいけないソーシャルエンジニアリング対策の「ある方法」とは

Share

今回は、サイバー攻撃の変わり種、システムではなく人間の弱点に付け入る攻撃、ソーシャルエンジニアリングを紹介します。

まずソーシャルエンジニアリングの具体的な手法を挙げ、どのように人間の弱点が利用されるのかを説明し、日本で起こったソーシャルエンジニアリングによる被害実例を紹介します。

途中ちょっと寄り道をして、オレオレ詐欺はソーシャルエンジニアリングなのかどうかについて考えつつ、最後に具体的かつ実践的な対策方法と、逆効果となる、とある対策・管理方針について言及します。

ソーシャルエンジニアリングとは

ソーシャルエンジニアリングとは、人を心理的に操作して、攻撃者にとって都合のいい行動を起こさせたり、機密情報を漏えいさせたりするサイバー攻撃です。情報収集やシステムへの不正アクセスなどを目的としています。

認知能力、心理など「人間の脆弱性」を攻撃するソーシャルエンジニアリング

アメリカの非営利のセキュリティ研究団体MITRE社の説明によると、ソーシャルエンジニアリングとは、人心を巧みに操り、その弱みにつけこんで、悪意ある相手に利するような行動や情報を引き出すというものです。具体的な例を挙げると、技術的な手段によらずに、口頭による会話といった「社会的(ソーシャル)」な手段で、ID・パスワードなどの重要情報を、巧みなやり方で関係者から直接聞き出す行為などがソーシャルエンジニアリングです。大きくは、人間の認知能力のさまざまな弱点やスキにつけ込むサイバー攻撃全般のことだといえるでしょう。

脆弱性診断サービスを提供するBBSecとして「脆弱性」という観点で申し上げるなら、ソーシャルエンジニアリングとは、「システムやソフトウェアではなく人間の脆弱性を突く攻撃」と言うことができます。

ソーシャルエンジニアリングの具体的手法

以下に典型的なソーシャルエンジニアリングの手法を挙げます。

・ショルダーハッキング
  例)パスワード等をユーザの肩越しに覗き見る
・トラッシング(スカベンジング)
  例)清掃員などに変装して標的組織に侵入し、書類やHDDなどのゴミや廃棄物をあさる
・なりすまし電話
 例)システム担当者などになりすましてパスワードなどを聞き出す
・ベイティング
 例)マルウェアを仕込んだUSBメモリを廊下に落とす
・フィッシング(ヴィッシング、スミッシング等 含む)
  例)信頼できる存在になりすまし、ID・パスワード、クレジットカードなどの情報を入手する
・ビジネスメール詐欺
 例)取引先などになりすまし、犯人の口座へ振込を行わせる
・標的型攻撃メール
 例)ターゲットに対する入念な調査に基づいて作成した、完成度の高いなりすましメールを送る

たとえば「なりすまし電話」ですが、上記に挙げた例とは逆に、入社したばかりの何も知らない社員を装ってシステム担当者に架電し、やり方がわからないふりをするなどして徹底的にイライラさせて、思わずパスワードを口に出させるなどの方法も存在します。人間の認知能力のスキをつくソーシャルエンジニアリングには、実にさまざまな方法があるのです。

ソーシャルエンジニアリングの最大の特徴とは

人の脆弱性を突くソーシャルエンジニアリングの最大の特徴は、ターゲットを信頼させ、攻撃者に有益な情報の提供などを自発的に行わせてしまう点にあります。MITRE社の説明に「人を操る」とあった通り、権力や暴力を振りかざして重要情報を聞き出した場合、それは単なる脅迫であってソーシャルエンジニアリングではありません。

ターゲットの心を意のままに操作して、自発的に、ときに笑顔で協力させてしまう点にこそ、ソーシャルエンジニアリングを行う犯罪者の真骨頂があります。

ソーシャルエンジニアリングはどのように人間の弱点につけ込むのか

ソーシャルエンジニアリングは攻撃対象が信頼してしまう存在などになりすましてターゲットを信頼させ、心を開かせたり油断させることで行われます。

そのために攻撃者がしばしば目を付けるのが、「権威」に対する人間の弱さです。会社の取締役を装って電話をかける、得意客になりすましたビジネスメールを送る、大手金融機関や有名ブランドをかたったフィッシングメールを送る、などの手口に騙されるのが典型的なケースです。

なお、メールアカウントを乗っ取って旧知の取引先などになりすましたメールを送信することで拡散を図るEmotetは、フィッシングを行うマルウェアであり、ソーシャルエンジニアリングの一類型と言うことができます。

オレオレ詐欺はソーシャルエンジニアリングか

権威以外にも「義務感」「正義感」あるいは「好意」につけ込む方法もよく用いられます。多くの人は、困っている人に出会ったら「助けなければ」と感じます。助ける相手が親しい人物や好感を持てる人物であればなおさらです。

そこで思い浮かぶのがオレオレ詐欺ですが、ちなみに、この手の犯罪は、「ソーシャルエンジニアリング」なのでしょうか?

答えはNoです。ソーシャルエンジニアリングは、コンピュータセキュリティの文脈で使われる言葉であり、コンピュータやシステムへの不正アクセスを行うことを目的のひとつに含むという前提があります。そのため、オレオレ詐欺がソーシャルエンジニアリングと呼ばれることは一般にはほとんどありません。

ニューノーマル、テレワーク時代に気をつけたいソーシャルエンジニアリング

大きな環境変化の最中や直後などは、ソーシャルエンジニアリングの絶好の機会です。平時にはない緊張を強いられることで人々の不安やストレスが増し、感情的に動揺しやすくなるためといわれています。2020年、新型コロナウイルスの感染が一気に拡大した当初も、品薄状態だったマスクの配布をうたうメールやWebサイト、保健所からの連絡を装った攻撃などが複数確認されました。ニューノーマル時代、こうした攻撃に引き続き警戒が必要であることはいうまでもありません。

また、テレワークによって従業員どうしが切り離された就業環境においては、フィッシングメール標的型攻撃メールの感染確率が上がると言われています。これは、オフィスにいたなら同僚や情報システム部門に「変なメールが届いた」と気軽に相談できていたことが、テレワークによって難しくなるからです。

日本で起こったソーシャルエンジニアリングの被害実例

2015年に発生した日本年金機構の情報漏えい事件は、「【医療費通知】」という件名の標的型攻撃メールが公開メールアドレスに届き、その添付ファイルを開いたことが発端であったとされています。

また、2017年に大手航空会社がビジネスメール詐欺で数億円をだましとられた事件も、2018年に仮想通貨取引所から暗号資産が流出した事件も、いずれもソーシャルエンジニアリングが攻撃のステップのひとつとして用いられています。

ソーシャルエンジニアリング対策・防止策

では、こうしたソーシャルエンジニアリングを防止する対策方法には、どのようなものがあるのでしょうか。

「ソーシャルエンジニアリングの具体的手法」で挙げた攻撃に対しては、たとえばショルダーハッキングならプライバシーフィルターを利用する、ビジネスメール詐欺ならメールの指示をうのみにせず本人に電話をして確認するなど、さまざまな対策方法が存在します。また、近年攻撃者はSNSを活用してターゲットに関する情報を集めることが知られていますので、SNSの利用に組織としてルールを設けるなどの方法も有効です。研修や教育なども効果があります。

しかしその一方で、人間の脆弱性を突く攻撃を完全に防ぐことはできない、という観点に基づいた対策も、併せて必要になります。攻撃を防ぐ対策と同時に、攻撃が防げなかった場合(成功してしまった後)の対策も考える必要があるのです。BBSecはこの考えのもと、標的型攻撃リスク診断やペネトレーションテストなどのサービスを提供し、攻撃を受けることを前提としたセキュリティ対策に取り組む企業・組織の皆様をご支援しています。

企業が絶対にやってはいけないソーシャルエンジニアリング対策

ソーシャルエンジニアリングは人間の脆弱性を突く攻撃です。だからこそ、対策として絶対にやってはいけないことがあります。それは、騙された人を叱責する、何らかのペナルティを与える等の懲罰主義の管理です。

罰を受けるのを恐れることによって、事故が発生しても報告がなされず、それが、インシデントの発見の遅れを招き、組織にとっての致命傷を生むことがあります。あなたも私も、人間は皆、あやまちを犯す生き物なのです。あやまちを犯すことが覆い隠されてしまうような管理は、何の成果も上げられないでしょう。

まとめ

  • ソーシャルエンジニアリングとは、人の心を操って重要情報等を聞き出したりすることです。
  • ショルダーハッキング、フィッシング、ビジネスメール詐欺、標的型攻撃メールなど、さまざまな手法があります。
  • ソーシャルエンジニアリングは、「権威」「義務」「好感」などに惑わされる人間の弱さをあらゆる手口で突いてきます。
  • 環境が急激に変化する時は、ソーシャルエンジニアリングの付け入るスキが生まれます。ニューノーマルや急速なテレワーク化への対応を迫られる現在も、その例外ではありません。
  • 懲罰主義による管理は、ソーシャルエンジニアリング対策として何の効果もなく、インシデント発生の対応が遅れる要因になります。

まずは無料で資料をダウンロード

SQAT®APTの詳しいサービス内容が記載されている資料がダウンロードできるURLをお送りいたします。
見積もりについてのご相談は、お問い合わせよりご連絡ください。


 

 

 

年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

 

 

サービスに関する疑問や質問はこちらからお気軽にお問合せください。


 

 

 

 

Share

もしあなたの会社が不正アクセスされたら

Share

不正アクセスとは、アクセス制御機能を持つWebサービスやサーバ等に、正当なアクセス権限を持たない者が侵入する行為、およびそうした侵入を助長する行為を指します。あなたの会社で不正アクセスが生じた場合、その対応を誤ったり、対処が遅れたりすることで、事業への損害、評判の低下といった重大な事態につながる恐れがあります。本稿では、不正アクセスの主な手口を紹介し、被害を防ぐための対策、実際に被害にあってしまった場合の対処方法を解説します。

「不正アクセス」とは

「不正アクセス」と聞くと、本来その権限を持たない者が、サーバや情報システムの内部へ侵入を行う行為をイメージしますが、厳密にどのような行為を指すのかは、1999年に公布(最新改正は2013年)された「不正アクセス行為の禁止等に関する法律(不正アクセス禁止法)」で規定されています。特に注意しておきたいのが、同法では、他人のID・パスワード(「識別符号」)を不正使用した場合だけでなく、それ以外の情報を入力してWebサービスやサーバ等のシステム(「特定電子計算機」)を作動させる行為なども、「不正」とみなされる点です。また、不正アクセスを助長する行為としてID・パスワードの不正取得が禁じられているほか、ID・パスワードの不正な保管行為も同法に抵触します。違反した場合は、3年以下の懲役又は100万円以下の罰金が処せられます。

調査やテストで不正アクセスの加害者となる危険性も

なお、不正アクセス禁止法の定義に関しては、当該アクセスが「承諾」を得ていなければ不正とみなされる、という点にも注意が必要です。システムのセキュリティ診断を例に考えてみましょう。SQAT.jpを運営する株式会社ブロードバンドセキュリティでは、Webアプリケーションや社内ネットワークにセキュリティ上の弱点が存在しないかどうかを評価する脆弱性診断ペネトレーションテストを、システムを管理する企業からアクセスに対する承諾をいただいたうえで実施しています。もしこうした行為を、承諾もないのに実施していたとしたらどうでしょう。たとえそれが善意に基づくものであっても、不正アクセス禁止法に抵触することとなり、刑事罰が科されるかもしれません。

脆弱性診断やペネトレーションテストを行うツールは多数存在しており、無料で手に入れることも可能ですが、安易に使用することは禁物です。万一あなたの会社の技術者が、運用管理や保守、攻撃耐性の確認等の目的でこうしたツールを使用しており、その対象となるシステムが他社の管理下にある場合、不正アクセス禁止法に抵触するリスクがあることは覚えておくべきでしょう。

不正アクセス、その方法と手口

では、そもそも悪意を持った、攻撃者による不正アクセスの手口にはどのようなものがあるのでしょう。典型的なのは、「盗んだIDとパスワード、あるいは推測したパスワードを使って、システムに不正にログインする」というものです。ID・パスワードの組み合わせを総当り的に試してログインを図る「ブルートフォース攻撃」、辞書にある語句を利用する「辞書攻撃」、不正に入手したログイン情報を利用する「パスワードリスト攻撃」などが知られています。

中でも近年特に話題を集めているのは「パスワードリスト攻撃」です。背景には、数十万~数億件規模のID・パスワードがセットで売買されていたり、インターネット上に公開されていたりする事態があちこちで確認されており、攻撃者が不正アクセスのための情報を容易に手に入れやすくなっている状況があります。また、もし複数のシステムに対して同じID・パスワードが使いまわされている場合、1件の情報を入手することで複数のシステムへのログインが可能になるという点も、攻撃者を引き付けています。

この2020年8月には、日本企業約40社において、VPN(Virtual Private Network)のID・パスワードが盗まれ、インターネットに公開されるという事件が発生しました。VPNは、本来、セキュリティを確保したうえで企業ネットワークへアクセスするために使われる「安全性の高い入口」です。そこにログインするためのID・パスワードが盗まれることが極めて大きな被害につながり得ること、裏を返せば、攻撃者にとって極めて大きな利得につながり得ることは、論をまたないでしょう。

もちろん、不正アクセスのための攻撃は、ID・パスワードを狙ったものだけではありません。ID・パスワードの入手につながる脆弱性も格好の標的になります。例えば、Webアプリケーションや公開Webサーバの脆弱性はその最たるものです。攻撃者はしばしばSQLインジェクションの脆弱性クロスサイトスクリプティングの脆弱性などを悪用して個人情報を不正に入手し、ID・パスワードを特定してシステムへの侵入を試みます。

ID・パスワードの保護に加え、結果としてID・パスワードの特定につながる脆弱性を放置しないことが、不正アクセスを防ぐためには最重要といえるでしょう。

「あなたの会社が不正アクセスされています」
突然やってくる電話やメール

もし実際に不正アクセスが行われた場合、それはどのようにしてわかるのでしょう。残念なことに、自分では気づけず、外部から指摘されて知ることが少なくありません。例えば、クレジットカード情報が不正アクセスによって盗まれた場合、カード会社から直接、漏えいや不正利用の兆候がある等の連絡が来ることがあります。また、サイバー犯罪の捜査過程で、あなたの会社に不正アクセスが行われていることが発覚した場合、さらには、それが他の会社での被害につながっていることが発覚した場合には、警察やセキュリティ事故発生時の調整を行う機関など(一般社団法人 JPCERT コーディネーションセンター等)から連絡が来ることもあります。

なお、サイバー攻撃が起こることを想定した組織体制がない場合、やってきた連絡が正当なものであるかの判断自体がつかない場合もあるかもしれません。実在する機関を装い、虚偽の不正アクセス事案を連絡する犯罪が発生する可能性も想定し、連絡の真偽は必ず確認するようにしましょう。

不正アクセスを防ぐための日頃の対策

日頃からWebサービスやサーバのセキュリティ強化に取り組むことで、不正アクセスの発生を抑え、万が一不正アクセスが発生した場合にも早期あるいは即時に把握することが可能になります。

例えば、サーバに対するアクセスログを収集・保存し、同一IPからの複数回ログインに対するアラートをルール化する等の設定をしておくことで、誰かが不正ログインを行っていることを早期に知り、ブロックするなどの対処を行えるようになります。

不正アクセスされてしまったら、すぐに行うべきこと

以前の記事「情報漏えいとは? 代表的な原因や求められる対応策」では、「情報漏えい事故の報告書と収束までの流れ」として、事故発生時の報告書作成の注意点について解説しました。今回は、不正アクセスされた直後の対応や、真相究明を行う社内の組織体制構築でのポイントをご紹介します。

不正アクセス事故対応のチーム作り

セキュリティ事故対応を行う専門部署であるCSIRTが社内にない場合は、事故対応チームを速やかに組織しなければなりません。どのような編成を想定すべきか、参考として、モデル的な図解を下記に示します。

https://www.nca.gr.jp/activity/imgs/recruit-hr20170313.pdf より当社作成

もちろん、セキュリティ専門企業でない限り、ほとんどの組織にとってはここまでの編成をとることは合理的とはいえません。既存の組織・人員の状況に応じて、下記のような事項をポイントにチームを編成し、自組織の業種業態、慣習、人材、文化等を踏まえながら継続的にチームの発展・強化に取り組むことをお勧めします。

  • CSIRTがインシデント発生時における最終判断(システム停止も含む)までを担う場合は、責任を担う経営陣を参画させる。
  • 現体制におけるキーマンを特定し、そのキーマンを必ずメンバーに加える。
  • 現体制で実施できている役割がないか確認する(「実施できている役割は踏襲する」という判断も重要)。
  • 技術的な知識、経験、人材を持たない場合は、最低限CSIRTに必要な機能(=有事の報告、伝達を的確に行い、意思決定者へ早期伝達すること)を有する、「コーディネーション機能に重点を置いたCSIRT」を目指す。

取引先、関係者、個人情報保護委員会への連絡

あなたの会社のステークホルダーに対して、現時点で判明している事故の事実関係を連絡します。規制業種の場合は所轄官庁への報告義務があります。なお、個人情報保護法では、個人情報漏えい等の場合、本人通知や監督官庁への報告を努力義務としていますが、2022年に施行予定の改正個人情報保護法では一定範囲においてこれが義務化されるため注意が必要です。

不正アクセスの原因究明

続いて取り組むべきは、原因究明です。不正アクセスを受けた場合、侵入経路の特定や証拠保全などは自社でどこまで可能なのでしょう。監視やSOC(セキュリティオペレーションセンター)サービスの契約などによって保存してあるログを解析可能な場合、「不正アクセスの発端と展開過程がわかるから、自経路の解析や被害範囲の特定もできる」と考えてしまうかもしれません。しかし、火事場のように混乱する事故発生直後は、日頃から備えをしていた企業ですら、一刻を争う状況下で解析すべき情報の膨大さに圧倒されるものです。また、刑事事件として告発を行う場合や損害賠償請求を行う場合には証拠保全が必要となりますが、混乱し、慣れない状況下で証拠保全を念頭に調査や対応を行うのは大きな負荷となります。

さらに、「サイバー攻撃を行う5つの主体と5つの目的」で解説した「APT攻撃」が行われるケースも想定しておく必要があります。APTでは、侵入の痕跡を消されることが少なくなく、そのような場合、侵入経路の特定や証拠保存は難しくなります。しかし、日々ログの収集を行っていたとしたら、その痕跡からデジタルフォレンジックを実施することが可能です。

不正アクセス事故を前提に、「かかりつけ」セキュリティ企業を持つ

日頃からのアクセスログ収集や分析、SOCサービスの契約、CSIRT組織の設置など、平時の備えが不正アクセスを防止し、いざ不正アクセス事故が起きたときの対応力を高めてくれます。さらにもう1つ有効な取り組みとしてお伝えしたいのが、頼りになるセキュリティ企業との関係構築です。あなたの会社の業務やシステムのことを知っている、かかりつけ医のようなセキュリティ企業は、何かあったときのための備えのひとつになります。

それまで取引が一度もなかったセキュリティ企業に、事故が発生した際に初めて調査や対応を依頼したとしたらどうでしょう。社内のネットワーク構成、稼働するサービス、重要情報がどこにどれだけあるのか、関係会社や取引先の情報などについて、わずかな時間も惜しまれるインシデント対応の現場で、いちから説明しなければならなくなります。

脆弱性診断などの実施でセキュリティ企業に依頼を行う際は、信頼できる企業かどうか、いざというときにサポートしてくれるかどうか等、診断以外のサービス体制も幅広く調べたうえで、長期的な観点から利用を検討することをお勧めします。

まとめ

  • 不正アクセスとは、アクセス制御機能を持つWebサービスやサーバ等に、正当なアクセス権限を持たない者が侵入する行為、およびそうした侵入を助長する行為を指します。不正アクセス禁止法の違反者は、3年以下の懲役又は100万円以下の罰金に処せられます。
  • たとえ悪意がなくても、セキュリティ診断ツールなどを使用することで不正アクセス禁止法に抵触することがあります。
  • ID・パスワードの管理だけでなくWebアプリケーションやサーバの脆弱性管理も重要です。
  • 不正アクセスが実際に起こってしまったら、早急に対応チームを組織し、ステークホルダーへの連絡や原因究明を行います。
  • いざ不正アクセス事故が起きたときの対応力を高めるには、日頃からのアクセスログ収集や分析、SOCサービスの契約、CSIRT組織の設置、「かかりつけ」セキュリティ企業との関係構築などが有効です。

年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Share

サイバー攻撃の原因となる「脆弱性」を理解する

Share

情報漏えいなどの被害をもたらすサイバー攻撃の多くは、「脆弱性」を悪用して行われます。メディアを賑わすセキュリティ事故の相当数が、脆弱性への対応を放置することで引き起こされたものです。脆弱性が生まれる原因、脆弱性情報を収集する方法、脆弱性を見つけるために利用できるチェックツールや診断サービスについての理解を深め、適切な対応を行えるようにしましょう。

「脆弱性」とは?―設定ミスなどによるバグが攻撃に悪用

脆弱性の多くは、「プログラムの設計ミスやコーディングミスなどによるバグ」になります。バグが存在せず正しく動作するプログラムやWebアプリケーションであっても、設計者が想定しないやり方で機能が悪用され、結果としてサイバー攻撃が成立する場合には、その「悪用されうる機能設計」が脆弱性とみなされます。また、システムやサービス全体という視点からは、設定に関して何らかの誤りがあり、そのことによって情報漏えいが起こったりサイバー攻撃が行われたりする可能性がある場合、そうした設定ミスが脆弱性とみなされます。たとえば、ポートの開放に関する設定、権限管理、AWSをはじめとするクラウドサービスの設定ミスがセキュリティ事故を招いた例は枚挙に暇がありません。

「脆弱性」はサイバー攻撃の端緒となる

脆弱性は「きじゃくせい」ではなく「ぜいじゃくせい」と読みます。対応する英語は、「Vulnerability」(「攻撃を受けやすいこと」の意)です。ハードウェア、サーバのOS、ソフトウェア、Webページ、Webアプリケーションなどに脆弱性が存在した場合、それが悪用されることで個人情報や知的財産を盗むようなサイバー攻撃を招くことになります。

脆弱性への対応を怠り社長が辞任に追い込まれたケースも

脆弱性への対応を誤ることは、しばしば事業の運営に甚大な影響をもたらします。典型的な事例をご紹介しましょう。2017年、クレジットカード等の与信に関わるアメリカの大手消費者情報調査会社がサイバー攻撃を受け、自社で保有していた4億件の個人の信用情報の約3分の1にあたる、1億4,000万件もの情報が盗まれました。この攻撃は、Webアプリケーションの開発フレームワークであるApache Strutsの脆弱性を、脆弱性情報とパッチの公開後速やかに修正できなかったことに起因するものです。

攻撃の端緒となった脆弱性に対しては、2017年3月にパッチや対策方法が公開されました。会社側では公開を受けて修正を図ったものの、組織体制の不備等もあいまって修正は不完全な形となり、結果、システムへの不正アクセスを許すことになりました。さらに、攻撃は同年5月から確認されていたにもかかわらず同社が事件を公表したのは9月。4か月もの間事態が公表されなかったことが大きな批判を浴び、CEOなど一部の幹部は辞任に追い込まれ、格付けも引き下げられたのです。脆弱性が引き金となり、このように甚大な影響がもたらされることは少なくないのです。

脆弱性情報はWebサイトでチェックできる

脆弱性は、さまざまなソフトウェアやプラットフォームで日々発見されています。そうした情報は、多くの場合、ソフトウェアやプラットフォーム提供元のWebサイトに掲載されます。少なくとも、自組織で利用している主要なプラットフォームに関しては、緊急性が高い脆弱性が出現していないかどうかを、提供元のWebサイトで定期的にチェックするとよいでしょう。

また、一般社団法人JPCERTコーディネーションセンターとIPA(独立行政法人情報処理推進機構)では、公表された脆弱性情報を収集して公開するサービス「JVN(Japan Vulnerability Notes)」を共同運営しています。日本で利用されている大半のソフトウェアの脆弱性の情報は、このサイトでチェックできます。

さらに、特定の脆弱性によってどのような実害が発生するかは、脆弱性を発見したセキュリティ企業がブログなどで情報を公開している場合もあります。追加で調べてみてもいいでしょう。

日頃からできる脆弱性対策

衣服等の破れを補修する「継ぎ当て」や傷口に貼る「絆創膏」のことを英語で「パッチ(patch)」と言いますが、脆弱性を修正するプログラムも「パッチ」と呼ばれます。修正プログラムを適用することは「パッチをあてる」と言われたりします。脆弱性が発見されたら速やかにパッチをあてるのが原則ですが、下記のようにいくつか留意すべき事項がありますので、念頭に置いておきましょう。

・パッチをあてることにより、システムに影響が及ぶ場合があります。適用にあたっては事前に調査を行い、必要に応じて十分な検証を実施してください。なお、自組織で開発したシステムに関しては、必ずテスト環境を用意し、パッチ適用による整合性チェックを行ってください。

・自組織のネットワークやサーバでどんなソフトウェアが動いているのか、定期的に棚卸しを行って把握しておくことも重要です。棚卸しの過程で不要なサーバや機器などが発見されたら、将来のリスクの種を取り除く上で削除可能かどうかを確認してください。なお、棚卸しの際、ソフトウェアのバージョン台帳のようなリストを作成しておけば、新しい脆弱性が報告されたときに、自組織のシステムが該当するのかをすぐにチェックできます。

・ソフトウェアは定期的にアップデートが行われます。アップデートされた最新バージョンでは既知の脆弱性や不具合が修正されていますので、後回しにせずに更新を行うようにしてください。

・自組織で開発したソフトウェアやWebアプリケーション等の場合は、サービスが稼働する前の上流工程(開発段階)から、セキュアプログラミングやDevSecOpsなど、そもそも脆弱性を作り込まない体制を構築することが有効です。

・テレワーク化が急速に進む今日では、以上の留意事項に加え、クライアントサイドでのパッチ適用が適切に行われているかをチェックする体制を構築することも重要です。また、シャドーITの状況把握も厳格に実施する必要があります。「IT部門が知らないサービスを勝手に利用され、結果として脆弱性の有無について未検証のクライアントソフトやブラウザプラグインが使われていた」という事態は防がねばなりません。

「脆弱性が多い」と言われるソフトウェアの傾向

脆弱性が数多く報告されているのは、一体どんなソフトウェアでしょう。ひとつ共通することは「ユーザが多い」ということです。たとえば、皆さんがこのサイトをご覧になっているWebブラウザ、そのWebブラウザが動作するMicrosoft WindowsなどのOS、ビジネスでよく使われるPDFファイルを扱うAdobe Acrobat、WebサーバソフトのApache、データベースアプリケーションのMySQLなどです。いずれも、全世界に膨大な数のユーザを持つソフトウェアであり、規模のインパクトという点から、攻撃者にとって極めて魅力的、いわば人気があるのです。かつ、このようなソフトウェアでは、開発元において、脆弱性を早期に発見し、修正プログラムの公開、所定機関への報告を迅速に行う必要性が高いことから、報告件数が当然ながら多くなる傾向がみられます。

わかりやすい例としては、オンライン会議ソフトのZoomがあります。Zoomでは、2020年になって脆弱性が次々と発見されていますが、そこには、新型コロナウイルス対策の一環でテレワーク化が進み、Zoom利用者が爆発的に増えたという背景があります。攻撃者の格好のターゲットになったことと、Zoomの脆弱性の増加は、連動した現象なのです。

ここまでの説明でお気づきかもしれませんが、「脆弱性が多く報告されている」ことは必ずしも「品質が悪い」ことを意味するのではありません。脆弱性が存在してもそのことが報告・公表されていなければ、「脆弱性がある」とは認知されないわけです。

ツールを使って脆弱性を見つける

脆弱性を発見するためのソフトウェアは「チェックツール」「スキャンツール」「スキャナ」などと呼ばれます。以下に、代表的なものをご紹介しましょう。有償、無償のさまざまなツールが提供されていますので、機能や特徴を知り、ニーズに合致するものを試してみてはいかがでしょうか。

  有償ツール 無償ツール
Webアプリケーション向けAppScan、Burp Suite、WebInspect など OWASP ZAP など
サーバ、ネットワーク向け Nessus(一部無償)、nmap など Nirvana改弐、Vuls など

「脆弱性診断」サービスで自組織のソフトウェアの脆弱性を見つける

上記でご紹介したツールを使えば、脆弱性のチェックを自組織で行うことが可能です。しかし、前述の通り、「脆弱性が存在するのに報告されていない」ために情報がツールに実装されていないソフトウェアも数多くあります。また、一般に広く利用されているソフトウェアであれば次々に脆弱性が発見、公開されますが、自組織で開発したWebアプリケーションの場合は、外部に頼れる脆弱性ソースはありません。さらに、実施にあたっては相応の技術的知識が求められます。そこで検討したいのが脆弱性診断サービスの利用です。

脆弱性診断サービスでは、システムを構成する多様なソフトウェアやWebアプリケーション、API、スマホアプリケーション、ネットワークなどに関し、広範な知識を持つ担当者が、セキュリティ上のベストプラクティス、システム独自の要件などを総合的に分析し、対象システムの脆弱性を評価します。組織からの依頼に応じて、「自組織で気付けていない脆弱性がないかどうか」を調べる目的のほか、「脆弱性に対して施した対策が充分に機能しているか」を検証する目的で実施することもできます。

脆弱性との共存(?)を図るケースもある

最後に、診断で発見された脆弱性にパッチをあてることができないときの対処法をご紹介しましょう。

まず、「パッチを適用することで、現在稼働している重要なアプリケーションに不具合が起こることが事前検証の結果判明した」場合です。このようなケースでは、システムの安定稼働を優先し、あえてパッチをあてずに、その脆弱性への攻撃をブロックするセキュリティ機器を導入することで攻撃を防ぎます。セキュリティ機器によって「仮想的なパッチをあてる」という対策になるため、「バーチャルパッチ」とも呼ばれます。

また、脆弱性が発見されたのがミッションクリティカルなシステムではなく、ほとんど使われていない業務アプリであった場合は、脆弱性を修正するのではなく、そのアプリ自体の使用を停止することを検討できるでしょう。これは、運用によってリスクを回避する方法といえます。

なお、前項でご紹介した脆弱性診断サービスの利用は、脆弱性に対して以上のような回避策をとる場合にも、メリットがあるといえます。発見された脆弱性について、深刻度、悪用される危険性、システム全体への影響度といった、専門サービスならではのより詳細な分析結果にもとづいて、対処の意思決定を行えるためです。

まとめ

・サイバー攻撃の端緒となる脆弱性はプログラムの設計ミスなどによって生まれます。
・海外では脆弱性への対応を怠ったことで発生した情報漏えい事故で社長が辞任に追い込まれた事例もあります。
・脆弱性情報はベンダのWebサイトやJVNなどで公開されています。
・自組織のネットワークやソフトウェアなどの棚卸しを行い、それぞれのバージョンを把握しましょう。
・利用者が多いソフトウェアほど脆弱性が発見されます。必ずしも「脆弱性の報告数が多い=品質が低い」というわけではありません。
・脆弱性診断サービスは、自組織で開発したWebアプリケーションなどの脆弱性を発見するのに有効です。

関連情報

● 脆弱性診断の必要性とは?ツールなど調査手法と進め方

● 2019年下半期 カテゴリ別脆弱性検出状況


年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Share

見えない部分のセキュリティは忘れられがち
―メモリ領域の安全を考える―

Share

いまメモリの安全に関して、その重要性がますます注視されています。OSやアプリケーションを動作させるために必要なデータやプログラムは、そのほとんどが一度メモリ領域に展開されているため、メモリ領域が侵害された場合、実行中のソフトウェアから生きた情報が抜き出されてしまいます。にもかかわらず、メモリ領域のセキュリティは忘れられがちです。本記事では、メモリ領域に存在する脆弱性の脅威と、それを保護するためにどのようなセキュリティ対策を講じればよいのかについてご紹介します。


「メモリ」はコンピュータ用語では「記憶装置」や「記憶媒体」のことを指し、「メモリ領域」とは、その記憶媒体に保存されたプログラムを実行するときに、当該プログラムをロードするメモリの記憶領域を指します。つまり、OSやアプリケーションを動作させるために必要なデータやプログラム、プログラムの実行ロジックそのものまで、すべてがメモリ領域に存在しているといえるため、セキュリティ対策を行う上ではメモリ領域の安全を考えることが非常に重要となります。メモリ領域が侵害されると、実行中のソフトウェアから生きたデータを抜き出すことが可能となり、機微情報が悪意ある第三者に漏洩したり、プログラムの処理が改竄されることで不正に実行されたりする危険性があります。

2020年5月、Googleは2015年以降にChromeのコードベースで存在が確認された重要度の高い脆弱性のうち、約70%がメモリの安全性に関する問題であることを明らかにしました。メモリの安全に関する問題については、過去にMicrosoft社も同様に警鐘を鳴らしており、世界全体で毎年登録・公開される脆弱性において、常に20%程度をメモリ関連の脆弱性が占めています。

図1:Chromiumプロジェクトにおけるhigh以上の脆弱性

解放済みメモリに関連する脆弱性
他のメモリ関連の脆弱性
その他
セキュリティ関連のアサート

出典:
https://www.chromium.org/Home/chromium-security/memory-safety
より当社翻訳

普段OSやアプリケーションを使用する際、動作過程においてメモリ領域でどのような処理が実行されているかを深く意識する人は少ないでしょう。プログラムは、メモリ領域にすべてを展開して処理します。プログラムそのものもメモリ領域に存在しており、接続する各種デバイスも連携時にメモリ領域にて処理や制御が行われています。そんなシステムの根幹だからこそ、メモリ領域のセキュリティは万全であるべきですが、残念ながら脆弱性は存在し、攻撃者にとって格好のターゲットとなりえます。

図2:「メモリ領域への展開」の概要

メモリ関連の脆弱性、特にメモリ領域に関連する脆弱性の原因は、主にC/C++のポインタ周りのコーディングミスによるもので、代表的な脆弱性として、バッファオーバーフロー、領域外読み取り、Use-after-free(解放済メモリの再利用)といったものがあげられます。C/C++のメリットの一つにメモリ領域管理での柔軟性があり、それが処理の高速性をもたらす一方で、脆弱性を生み出すという皮肉な結果に結びついているのです。

図3:主要プログラミング言語と現在利用されている代表的分野

メモリ領域を狙った攻撃にはステルス性が高く、一般的な攻撃検知策では検知が困難なケースもあり、また、被害も甚大となる可能性があります。近年ではニュース等で「Spectre」、「Meltdown」といった単語をよく耳にしたことでしょう。これらはCPUの脆弱性を突くものですが、メモリ領域へのアクセスにおいて、CPUを介さずに各種デバイスとメモリ間でデータ転送を直接行うDMA(Direct Memory Access)にもセキュリティ脅威は存在します。DMA攻撃については、Thunderbolt経由でデータへの完全なアクセスを得ることが可能となる「Thunderspy攻撃」が記憶に新しいかもしれません。DMAはメモリへの直接アクセスによりデータ転送の高速化を実現する一方で、その有効性が攻撃者に逆手に取られ、悪用される事態が後を絶ちません。

プログラムの実行順序や構造が、まるでスパゲティが絡まったように複雑に入り組んでおり整然としないプログラムを「スパゲティプログラム」などといいますが、昨今はメモリ領域内でも複数のアプリケーションや制御処理が複雑に連鎖・連携・連動し、似たような状態に陥っていることも珍しくありません。こうしたすべてを把握することは困難であり、将来においてはさらに複雑化していくでしょう。

メモリ領域は「美味み」と「鮮度」を兼ね備えており、攻撃者にとっては非常に魅力的なターゲットといえます。また以前に比べて、現在は標準的なシステムでもメモリ領域は潤沢で、迅速な処理が実行可能となったことや、リソースの利便性が向上したことにより、今後もメモリ領域への依存性が高まることは容易に想定されます。

潤沢となったメモリ利用例
・クラウド環境などの仮想化
・外部媒体とのデータ通信
・AI化およびビックデータの統計処理

以上の点から、メモリ領域を保護するためにセキュリティ対策として、システム自体、あるいは周辺機器に対する物理的な対策を除いた場合、一例として次の3つの観点と対策が考えられます。


実行プログラムに対する脆弱性対策
メモリ関連処理のロジックを正しく制御させ、ソースコード内に脆弱性を作りこまないようにする。

アプリケーションを実行させる環境に対する脆弱性対策
パッチの適用やアップデートなどを徹底し、プラットフォーム環境や関連するデバイス制御などに既知の脆弱性がないことを確認する。

メモリ領域を防御するセキュリティソリューションの導入
アプリケーションメモリファイアウォール等、メモリ領域の保護に特化したソリューションを導入、運用する。


メモリ領域には多種多様なプログラムが存在し、連携・連動しています。そのため、小さなセキュリティホールでも悪用されれば大きな被害を生む恐れがあります。プログラムも所詮、最終的には人間が作るものであり、「人間はもともとミスを起こしやすい動物である」とは人間工学でもいわれていることです。どんなに完璧なコーディングをしたと思っても、複雑化された構造の中にミスやエラーが埋もれてしまっているかもしれません。開発において当然テストはするでしょう。しかし、セキュリティを考慮しないテストでは正常動作の確認が主であり、『アクセス違反』(Access Violation)を見つけることに集中しがちです。

そのため、メモリ領域の脆弱性に関連するセキュリティ向上策の一つとして、セキュリティの観点からテストを行う「ソースコード診断」の実施も有効と言えるでしょう。


年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Share

ソースコード診断の必要性とは?目的とメリットを紹介

Share

ソースコードとはシステムやWebアプリを動かすコンピュータプログラムのことです。ソースコード診断を行うことで防げるサイバー攻撃や、ソースコード診断ならではの強み、ソースコード診断とDevSecOpsとの関連、上手な利用手順などを解説しています

企業が提供するWebサービスや、社内で活用するさまざまな業務用アプリケーションを検査、評価する方法はいくつも存在しています。この記事では、その中の「ソースコード診断」を取り上げて、その定義、特徴、メリット、目的などを紹介します。

ソースコード診断とは?

ソースコード診断とは、アプリケーションのソースコード(開発者が書いたプログラム)を解析して、セキュリティを含めて品質上の問題となるバグを検出する診断です。無料の診断ツールや、セキュリティベンダーが提供する診断サービスがあります。診断対象はWebアプリケーションを始めとして、スマートフォンやIoT機器上で動くアプリケーションにまで広がっています。

ソースコードを開示するため、ソースコード診断はホワイトボックステストと呼ばれます。これに対して、ソースコードや設計書を見ずに、システムの外部からアクセスして脆弱性や動作を検証する方法をブラックボックステストと呼びます。

ソースコード診断の特徴とメリット

ブラックボックステストでは検出が難しい脆弱性がソースコード診断なら検知できる場合があります。具体的には 「ソースコード診断で検出できる脆弱性」で後述します。

ブラックボックステストは、すでにソフトウェアあるいはシステムが機能していることを前提とした、リリース前あるいはリリース後に実施します。これに対して、ソースコード診断はその前段である開発プロセスから実施できるため、テスト結果を受けてプログラムを修正することが可能です。

開発の手戻りを減らすことでコストや工数削減につながります。詳細は「ソースコード診断の有効性」を参照してください。

ソースコード診断を実施する目的

ソースコード診断の目的は、プログラムに作りこんでしまった脆弱性を網羅的に検出することです。開発時に繰り返し実施し、開発者が修正していく運用が想定されています。

システムのセキュリティを確保する方法

開発(Dev)、運用(Ops)、セキュリティ(Sec)を一体にしてシステムライフサイクルを回すDevSecOpsという考え方が注目を集めています。DevSecOpsではシステムライフサイクルの初期から各段階でセキュリティについて考察、対処していきます。ここでは、開発プロセスのどこで、セキュリティを確保するための施策を実施するか説明します。

セキュアプログラミング

ソースコード診断の前に、そもそもシステムの設計・開発段階で、開発者が脆弱性を作りこまないようにする手法があります。これをセキュアプログラミングと呼びます。セキュアプログラミングで開発し、本当に脆弱性を作りこんでいないかどうかソースコード診断でチェックします。

ソースコード診断

ソースコード診断には、ツールを用いて自動的に処理するツール診断(自動診断)と、セキュリティエンジニアが目視で確認する手動診断があります。

効率的に網羅性を確保できる自動診断ツールの支援は欠かせません。

一方手動診断は、機械的に検出できず、人間による判断が必要な脆弱性を発見します。手動のみで行う場合もありますが、多くはツール診断と組み合わせて網羅性と精度を上げていきます。

脆弱性診断(セキュリティ診断)

システムのセキュリティを確保する方法には、ソースコード診断のほかに脆弱性診断(セキュリティ診断)もあります。脆弱性診断とは、システムの外部からアクセスして既知の脆弱性の有無を検証する方法です。システム構築後のさまざまなフェーズで実施します。

診断対象は、Webアプリケーションスマホアプリケーション、サーバ(OS等)ネットワークインフラなどさまざまです。

なお「セキュリティ診断」という名称で、脆弱性診断サービスが提供されている場合もあります。

ソースコード診断の有効性

ソースコード診断は開発フェーズ初期から実施可能です。リリース直前やリリース後に脆弱性が発見される可能性を抑えることで、より効率的で信頼性の高いシステム開発が可能になります。

CPE-Coreとはソースコード内の脆弱性と品質面の問題を検査する当社の自動自動静的解析ツールです。

ソースコード診断で検出できる脆弱性

一般的な脆弱性診断では検出しにくい脆弱性も、ソースコード診断では発見できる場合があります。たとえば未使用のコード、ログの改ざん、ログファイルやエラーメッセージへの機密情報の出力などは、ソースコードを直接確認することで検知可能になります。

以下、代表的な脆弱性(セキュリティバグ)について説明します。これらのバグを突く攻撃の名称としても用いられています。

バッファオバーフロー

プログラムを実行する際に確保するメモリ上のバッファ領域に対して、このサイズを超過するデータを書き込めるようになっているバグです。攻撃者は超過する部分に不正なプログラムを書いて実行します。

フォーマットストリング

プログラム中の、書式設定用の関数(フォーマットストリング)の引数の処理に関するセキュリティバグです。正しくは、引数として不正な値が入力された場合には、処理を止めてエラーメッセージを返さなければなりません。

SQLインジェクション/コマンドインジェクション

SQL(データベースを定義、操作する言語)文や、その他のコマンドが入力された場合でも、エラーにせずに処理してしまうバグです。攻撃者の観点からは、コマンドを注入(インジェクション)する形になるため、この名が付いています。攻撃の入り口はアプリケーション上の通常の入力欄で、ここに不正な値を入力することで攻撃を開始します。

クロスサイト・スクリプティング

悪意のあるスクリプト(プログラム)をユーザのコンピュータに注入して、複数のWebサイトをまたいで(クロスサイト)行う攻撃や、その攻撃で利用される脆弱性を指します。

まとめ

・ソースコード診断はソースコード(開発者が書いたプログラム)を解析し、セキュリティ上の問題点を発見する
・開発フェーズの初期から実施することで、リリース直前に脆弱性が発見されるようなスケジュールに影響するトラブルを防止する
・ソースコード診断のためのツールを効果的に活用しながら、熟練の技術者が手動でソースコード診断を行う


年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Share

業界別診断結果レーダーチャート

Share

2019年下半期 Webアプリケーション診断

診断対象を業界別に分類し、当社報告書内で使用している、入出力制御、認証、セッション管理、重要情報の取り扱い、システム情報・ポリシーといったカテゴリごとに、検出された脆弱性をリスクの重大性で評価してレー ダーチャート化した。レーダーチャートの算出方法は、集計期間に検出された脆弱性の平均値から、システムごとに判定した結果の平均値である。今回は、オリンピック・パラリンピックを目前に控え、新しい試みを続ける観光・宿泊・運輸(航空・旅客)業などの「ホスピタリティ」業界をピックアップし、分析した。

「高」リスク以上の脆弱性が検出されたシステムであっても、正しい対処を施せば影響は最小化できる。また、事故を未然に防ぐための方法を、官公庁などがガイドラインや対策提言などとして発表しているので、これらも参考にしていただきたい。

ホスピタリティ業界

図1 検出された脆弱性の平均値

ホスピタリティ業界(観光・宿泊・運輸)分野のシステム脆弱性診断の平均値は図1のとおり。システム情報・ポリシーにおいてやや数値が低いものの、平均して大きな問題が検出されたシステムは少ない。

しかし注意を喚起したいのが、このレーダーチャートがあくまでも「平均」であることだ。殆どのシステムは平均値を上回る、あるいはほぼ平均値に近い値であったものの、大きく平均を下回るシステムも存在した。特に入出力制御とセッション管理においてその傾向が顕著であった。なお、システム情報・ポリシーは総じて平均に近い値であった。オリンピック・パラリンピックに向けて活況な業界の現状と課題について考えていく。

電子商取引(BtoC-EC)の活況と課題

2019年5月に経済産業省が公表した「平成30年度 我が国におけるデータ駆動型社会に係る基盤整備」によれば、日本のBtoC-ECのサービス系分野において、最も市場規模が大きいのが旅行サービスである。2018年のBtoC-ECの市場規模は3兆7,186億円にのぼり、全体の約56%を占める。ここでいう「旅行サービス」とは、旅行代理店への申し込み、航空機利用(国内便・国際便)、鉄道(新幹線・その他在来線)、バス利用、ホテル・旅館の宿泊費に関して、消費者の国内外を問わず日本の事業者に支払いが発生する市場を指す(ビジネスで利用する「出張」は除外)。牽引するのはインターネット専業の旅行代理店(通称:OTA :Online Travel Agency)で、国内のサイトをはじめ、エクスペディアやBooking.comといった外資系OTAも目立っている。特にインバウンドにおいては外資系OTA抜きでは成り立たないといっても過言ではない。

旅行サービス業においてBtoC-ECは、航空券やホテル予約における空席や空室といった「在庫」管理に直結している。例えば、客室数という確定サービス枠が存在し、空室を「在庫」として顧客に提示しインターネットを介して予約を受け付け、自動で在庫管理を行う形態は、「在庫数」が明確に定義できるサービスにとって非常に親和性の高い形態である。

しかし、市場が成長を続ける一方でセキュリティの甘さも課題として浮かんできた。

2018年にセキュリティ企業のTrustwaveが犯罪被害にあった世界19カ国の企業・団体など数千社を対象に行った調査結果では、宿泊業・旅行業を含む「ホスピタリティ産業」は、小売、金融に次いで3番目に被害が多く、全体の10%を占めた。特にクレジットカード払いができるシステムが狙われている。またセキュリティ企業のDashlaneが2018年に実施した調査では、旅行関連サイト55社の89%でパスワードポリシーや認証機構に問題があったとの結果が報告されている。さらにシマンテックの研究者による調査では、54カ国約1,500のホテルにおける67%もの予約サイトがサードパーティサイトに予約参照コードを意図せず漏らしているリスクを内包しているという報告がなされている。同調査では、ホテルサイトの4分の1以上(29%)が、顧客への予約受領のメールに記載している予約管理システムへのリンクを暗号化していないとも述べている。実店舗を狙ったサイバー攻撃は減少傾向にあるものの、電子商取引ではむしろ増加傾向にあるといえるだろう。

OTAに関しては観光庁が2015年に「オンライン旅行取引の表示等に関するガイドライン」を策定し、旅行業のオンライン取引で表示すべき内容やその表示方法について細かく規定した。しかしセキュリティ対策については触れられておらず、各企業・団体によって対策状況はまちまちであった。2016年、大手旅行会社・中堅運輸会社において情報流出事件が発生したのを受け、「観光庁・旅行業界情報共有会議」が発足された。「中間とりまとめ」において旅行業情報セキュリティ向上のため早急に講ずべき対策が提言され、2018年には「旅行業者における情報セキュリティ確保に係る安全ガイドライン」策定の予算が支出されたものの、2020年1月の段階では、公表されていなかった。ただし、社団法人日本旅行業協会/社団法人全国旅行業協会が2014年に「旅行のウェブ取引に関するガイドライン(改訂版)」を出しており、事実上これがスタンダードになっているともいえる。

一方、国土交通省ではサイバーセキュリティ戦略本部の「重要インフラ分野における情報セキュリティ確保に係る安全基準等策定指針」に依拠する形で、航空・物流・鉄道・空港の各分野に対し、個別に「情報セキュリティ確保に係る安全ガイドライン」を策定している。また、鉄道、バス・バスターミナル、タクシー、宿泊施設の各業種に対しては個別の「情報セキュリティ対策のチェックリスト」を公開して対策を促している。

インバウンドサービスの動向

ホスピタリティ業界において今年開催のオリンピック・パラリンピックを目前に脚光を浴びているのが、訪日外国人観光客を対象とするインバウンドサービスである。日本が「観光立国」を打ち出したのは今から17年ほど以前に遡る。小泉首相(当時)による「観光立国懇談会」が平成15年(2003年)に発足し、2006年には「観光立国推進基本法」が成立した。2015年以降、国際貿易収支上、観光業は「輸出産業」となっている。また、2019年の世界経済フォーラムの観光競争力レポートでは第4位と、2017年より2回連続で上位にランクインしている。日本の評価を押し上げた項目としては「安全・安心」、「保険・衛生」、「ICTの普及」がある。

世界観光機関(UNWTO)によれば、今後のインバウンドサービスのカギとなるのはデジタル技術、特にバーチャル・アシスタントとリアルタイムデスティネーションであるとしている。国土交通省では令和元年度の施策として、主要観光地の多言語対応、全国3万カ所の主要観光地・防災拠点で無料Wi-Fi整備を進めるとともに、「キャッシュレス・消費者還元事業」として中小・小規模事業者のキャッシュレス決済の普及に力を注いでいる。観光庁も、2018年には「外国人観光旅客利便増進措置に関する基準」、「公共交通機関における外国人観光旅客利便増進措置ガイドライン」を策定した。同ガイドラインでは「インターネットによる予約環境の整備」として「インターネット上でクレジットカード等による決済も可能であることが望ましい」としている一方で、セキュリティに関しては、「公衆無線LAN等を整備するにあたっては、以下を参照されたい」として、「Wi-Fi提供者向けセキュリティ対策の手引き」(平成28年総務省)、「公衆無線LANセキュリティ分科会報告書」(平成30年3月総務省)を挙げているのみである。

旅行者はパスポート、支払い情報、詳細な旅程など、データの宝庫を持ち歩く存在といえる。さらに旅行者は、旅行先では利便性を優先し、セキュリティ意識が通常より甘くなりがちであることから、攻撃者にとっては格好の「獲物」となりやすい。先のTrustwaveのレポートによれば、調査対象のアメリカ人の70%以上が公共のWi-Fiへの接続や公共のUSBステーションでのデバイス充電、Wi-Fiへの自動接続を有効化することで自分自身の情報をさらす行為をしていた。なお、個人旅行に比べビジネス旅行の方が、リスクの高い行動をとる人が多い。

新たな取り組み-VR/ARを活用した観光コンテンツ

こうした中、セキュリティ要件を組み込まないガイドラインを基に「VR/AR等を活用した観光コンテンツ」が独り歩きしている現実もある。VR(Virtual Reality:仮想現実)が現実世界から得られる感覚情報を遮断して人工的に再現した感覚情報に置き換えるのと対照的に、AR(Augmented Reality:拡張現実)は現実空間を起点としデジタル情報を付加し、CGや動画を合成表示する。RPGを現実の空間と重ねるスマホゲームなどがARの代表である。ARに固有のセキュリティやプライバシーを考慮する必要があると主張する研究者もいる。

2019年にはサイバーセキュリティカンファレンスRECONにおいて、VRのハッキングが紹介された。観光に関するVRコンテンツは観光庁・文化庁がそれぞれ個別にガイドラインを公表しているが、どちらもセキュリティ要件を含んでいない。また経済産業省の補助事業として、特定非営利活動法人映像産業振興機構(VIPO)が「VR等のコンテンツ制作技術活用ガイドライン2018」を公表しているが、やはりセキュリティについては触れられていない状況だ。データセキュリティのみならず、個人情報(位置情報)保護、プライベート空間権利(公的空間の境界)等の課題もある。これらに関して今春以降、矢継ぎ早にガイドラインが発行されることが予想されるが、現在設計・開発中の案件については、ガイドラインが発行されてからセキュリティ要件を追加することになり、いびつな構造になってしまう。

まずは設計・開発の段階から「セキュリティ・バイ・デザイン」の思想を実践するとともに、ガイドラインに盛り込まれるであろう最低限のセキュリティ要件は予め組み込んでおくことが肝要だろう。どんな要件がガイドラインに組み込まれるか、あるいはガイドラインの最低基準以上の対策が必要なものは何かといった、専門家の知見が必要になる。これからインバウンド関連の事業を展開するのであれば、是非にも開発段階からのセキュリティ診断を実施することをお勧めする。

図 2 国際観光収支の推移(観光庁資料より当社作成)
出典:https://www.mlit.go.jp/common/001186621.pdf

ガイドライン一覧

その他の業種はこちら



Share

診断結果にみる情報セキュリティの現状

Share

SQAT® Security Report 2020年春夏号

2019年下半期 診断結果分析

BBSecの診断について

当社では、Webアプリケーション、ネットワーク(プラットフォーム)、スマホアプリ、IoT、パブリッククラウド、ソースコード、標的型攻撃に対するリスク可視化等、様々な局面における診断サービスを提供することで、お客様のニーズにお応えしている。

当社の脆弱性診断サービスは、専門技術者による高精度の手動診断と独自開発のツールによる効率的な自動診断とを組み合わせ、検出された脆弱性に対するリスク評価について、右表のとおりレベル付けしている。お客様のシステム特性に応じた脆弱性の検出、リスクレベルの評価、個別具体的な解決策の提供が適切に行えるよう、高い頻度で診断パターンを更新し、診断品質の維持と向上に努めている。

2019年下半期診断結果

当社では、2019年7月から12月までの6カ月間に、14業種延べ537企業・団体、4808システムに対してシステム脆弱性診断を行った。情報セキュリティ対策に重きを置く企業・組織側の姿勢もあり、診断案件数は年々増加している。脆弱性の検出率は次ページのとおりである。

診断の結果、Webアプリケーション診断では、脆弱性が検出されたシステムが全体の81.5%と、前年同期(2018年下半期)の84.9%に比べて微減しているものの、依然として高い割合である。ネットワーク診断においては、脆弱性検出率はシステム全体の47.8%であり、2017年下半期以降、減少傾向にあるが、およそ半数のシステムに何らかの脆弱性が検出されている。

検出された脆弱性のうち、早急な対処が必要な「高」レベル以上のリスクと評価された脆弱性は、Webアプリケーションでは26.9%、ネットワーク診断では30.4%検出されている。前年同期比(2018年下半期「高」レベル検出率:Webアプリケーション27.6%/ネットワーク診断 17.8%)でいうと、Webアプリケーションはほぼ横ばいだったが、ネットワークは12.6ポイント増えておりリスクレベルの高い脆弱性が増加傾向にある。当サイトでは、 「2019年下半期カテゴリ別脆弱性検出状況」とし、当社診断で検出された脆弱性を各性質に応じてカテゴライズし、評価・分析をした結果をまとめた。以降、診断カテゴリごとに検出数が多かったものの中から、特筆すべきことに焦点を当ててリスクや対策を述べる。

Webアプリケーション診断結果

Webカテゴリ結果の31.4%を占める「システム情報・ポリシーに関する問題」のうち、最も検出数が多かったのは、「脆弱なバージョンのOS・アプリケーションの使用」である。脆弱なバージョンのOS、アプリケーションを使用している場合、既知の脆弱性の影響を受ける可能性がある。最新バージョンへのアップデートが望ましいが、システム環境における制約等の理由でバージョンアップができないのであれば、必要なセキュリティパッチがすべて適用されていることを確認すべきである。

次にWebカテゴリ結果の検出割合が多かったのは、19.7%を占める「セッション管理に関する問題」。最も検出されたのは、「不適切なセッションタイムアウト」であった。ログインセッションのタイムアウト値が適切に設定されていないと、長時間操作を行わずアイドル状態のままでもセッションが維持されることから、セッションハイジャック等の攻撃が成功する確率が高まるほか、サービス運用妨害(DoS)攻撃につながる可能性もある。セッションタイムアウトは、Webアプリケーションのデフォルト設定として一般的に採用されている30分が望ましいが、ユーザビリティを考慮してタイムアウト値を長くする場合は、追加のリスク緩和策を講じることが推奨される。

ネットワーク診断結果

NWカテゴリ結果の52.3%が「通信の安全性に関する問題」であった。なかでも、「推奨されない暗号化方式の受け入れ」(検出割合は右表を参照)の検出数がトップであり、第2位の「推奨されないSSL/TLS通信方式の使用」と比べて2倍以上の差がある。

サーバがブロック長64ビットのブロック暗号をサポートしている場合、誕生日攻撃(birthday attack)を介して長い期間暗号化されたセッションを復号・解読される「SWEET32」と呼ばれる攻撃の影響を受ける可能性がある。「NVD(National Vulnerability Database)」などに本脆弱性の影響を受ける製品は公表されており、ベンダからも正式な対策が公開されていて、ベンダ情報を参照のうえ対策することが望ましい。

SSL/TLS通信において、強度の低い暗号化方式(RC4、3DESなど)が許容されていると、既知の脆弱性を悪用した攻撃(平文回復攻撃など)により、攻撃者に暗号化されたデータが解読される危険性がある。また、強度が低いハッシュアルゴリズム(SHA-1など)が許容されていると、衝突攻撃に弱くなり証明書の偽造等が可能となる恐れがある。鍵長が128ビット未満の暗号方式については、総当り(Brute-Force)攻撃への耐性が低く、中間者(Man-in-the-Middle)攻撃などの標的になりうる。強度の低い暗号化方式やハッシュアルゴリズムは使用を停止し、SSL/TLSによる通信の保護には鍵長が128ビット以上の暗号化方式を実装するべきである。SSHプロトコルにおいても、攻撃者に暗号文を解読される恐れがあるため、脆弱な暗号化方式およびハッシュアルゴリズムを許容しないことが望まれる。

カテゴリ別の検出結果詳細についてはこちら


年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Share

自動車ハッキングの今

Share

SQAT® Security Report 2019年10月号掲載

自動車業界のトレンドは「Connected(コネクティッド化)」「Autonomous(自動運転化)」「Shared/Service(シェア/サービス化)」「Electric(電動化)」の頭文字をとった「CASE」という言葉に集約されつつある。自動車は外部ネットワークと繋がり、新しい価値が創出されようとしているが、販売されている自動車の多くはセキュリティ対策が不十分なため、ハッキングの脅威に晒されている。


車載ネットワーク「CAN」

自動車内には主に四種類のサブネットワークが存在している。エンジンやブレーキの制御をつかさどる「制御系」、ドアやエアコン、シートやミラーを制御する「ボディ系」、カーナビやカーオーディオを制御する「マルチメディア系」、エアバッグなどの安全機能にかかわる部品を制御する「安全系」である。そしてそれらは、多くの車では制御の要となるCAN(Controller Area Network)を中心に、様々な機能を付加する形で車載ネットワークを構成している。

自動車ハッキングにおいて主に狙われるのがこのCANである。CANは1980年代にドイツのボッシュ社で開発された非常にシンプルなプロトコルで、その簡潔性、柔軟性、低コスト性から、今なお多くの自動車で採用されているほか、鉄道、航空機、船舶にも利用されている。

自動車に最も求められるのは、「走る」「止まる」「曲がる」に関する高い安全性であるが、CANは高い電磁ノイズ耐性と早く確実なレスポンス性能を持ち、安全性に対する多くの要求に応えるものだった。

一方で車が外部ネットワークに繋がったことによって、CANはセキュリティに関する多くの問題を抱え、安全性すらも脅かされている。Flex Ray のようなCANに代わるよりセキュアなプロトコルも登場してきているが、その採用は現状ではまだまだ限定的である。

自動車の未来

コネクティッドカーの登場により外部ネットワークに繋がれた自動車は、インターネットを経由した攻撃や、車車間通信を経由した攻撃に晒されている。今後自動運転車が本格的に市場に投入されるようになれば、外部ネットワークへの接続からのリモート操作が人命にかかわる大事故につながる恐れがある。また、EV充電や課金を伴う新サービスの登場により車がクレジット情報を直接的に扱うようになれば、それを狙った犯行の発生も予想される。

Electronic Control Unitの略称。自動車に搭載された様々な機能や装置を電子制御するためのコンピュータ。現在では車載ネットワーク上に100以上のECUが接続されることも珍しくない。

自動車にもセキュリティを考えなければならない時代が来ている。
自動車向けのサイバーセキュリティガイダンスであるSAE J3061*5 を取り入れたり、設計段階からのセキュアコーディング、さらに実車に対する脆弱性診断を実施したりするなど、今後ますます対策が必要になるであろう。

(左)燃料噴射量を調整してエンジンの回転数を増やす操作 (中)(右)燃料計の表示を操作。走行中に操作されればパニックになる可能性があるほか、攻撃のための細工を施した特定の燃料スタンドに立ちよらせるために利用することもできるだろう。

 

年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Share

<対談>杉浦 隆幸 氏(合同会社エルプラス 代表社員) ✕ 齊藤 義人(BBSec SS本部 本部長 )

Share

SQAT® Security Report 2019年3月号

     杉浦 隆幸 氏 × 齊藤 義人  

日進月歩のサイバーセキュリティ。昨年「一般社団法人 日本ハッカー協会」を設立し、サイバーセキュリティ、システム開発、IoTなどさまざまな分野でハッカーに活躍の場を提供し、ハッカーの地位向上と活躍によるネット社会の安全や健全な発展を通じて日本のセキュリティの進歩に寄与する杉浦隆幸氏に、当社セキュリティサービス本部本部長 齊藤義人が忌憚のない意見をぶつけた。

※当社は一般社団法人 日本ハッカー協会の賛助会員です。


BBSec:まずはお二人に、昨年の総括と申しましょうか、2018年に起こったサイバー事案についてお伺いします。

杉浦:総括といいますか、2018年は仮想通貨まわりの事案が大きく動きまして、2018年1月にはCoincheck(コインチェック)2、9月にはZaif(ザイフ)2 、Monappy(モナッピー)3の話題が世間をにぎわしましたね。被害額が通常では考えられないくらいの桁数が出ておりまして、500億とか、お金が絡んでハッカーが本気になると被害が大きくなるということが証明された感じです。

齊藤:金銭的な動機があった、ということが明確に現れてますね。2017年はランサムウェアとか小金を狙っていたのが、2018年では変化があった。インターネットで巨大な金額が動くとなれば、当然そちらがターゲットになっていくわけですね。

杉浦:そうですね。ランサムウェアの場合も、小金と大金がありましたが、世界的な傾向として、データベースを狙うなど、金額が大きくなった感じですね。

齊藤:攻撃者の成功体験が、またその先の誰かの攻撃手法になっていくという。

杉浦:目立つ成功は真似されやすいですよね。

齊藤:仮想通貨のお話はまさに杉浦さんのご専門ですが、先に話の出たZaifの事件は新聞にも掲載されて一般の方にも話題になるほどでしたね。元々OSINTコミュニティでMonacoinを追っている途中で、突然Zaifの話が出てきたという経緯があったため、有志の動きがものすごく早かったと聞いています。いわゆるハッカーと呼ばれている人々が一気にビットコインのシステムのハッシュを集めて…という動きを、警察で実施するとなるとおそらく膨大なコスト(人件費)がかかるので、同じようなスピードで対応するのは難しいのではないかと思います。こうしたハッカー有志が動けるというのは、言い方が正しいかどうかはともかく、経済効果がすごく見えてきたのではないかなと思っているんですよ。社会的な貢献要素というか。

杉浦:ただ実際に彼らが集まるのも、私が企画(「Zaif犯人追跡ハッカソン」4)した以上は将来的にお金が見えている可能性があるので(笑)。そうでないとあんな優秀な人たちを使えないですから、実際は。そういう仕組みをしっかり整えて、それを実証することによって、将来的に同様の事件があった場合に、速やかに対応をとれるような体制5を構築することが大事ですね。結構な費用がかかるんですが、(官は)前例がないことに費用はかけにくい。ですから前例を作ってしまおうというのが狙いではありますよね。

齊藤:それが実際に功を奏した、と。

杉浦:まぁ、そうですね。ただ、犯人はほぼ特定できたものの、実際の逮捕は警察次第。氏名が特定できても捕まるかどうかというのはまた別の問題なので。そこが難しいですね。

齊藤:それはどうしても民間では届かないところというか。役割の問題ですよね。FBIなんかですと、サイバーアタックの犯人リストがあったりしますが、日本ではそういった動きはまだないですね。
企業の対応もどうしたらいいですかね。例えば、これからも仮想通貨サービスはどんどん増えていって、いつかは法律で縛りがより強くなってくると思いますが。

杉浦:それがまさに問題ですね。実はLINEさんは仮想通貨の取引所をしていらっしゃるんですけど、知らないと思うんですよ、皆さん。というのも、サービスの提供で日本と米国は除外されているという、非常によくない状況になっていまして。コインチェック事件があったことで、認可側のマンパワーが足りないために認可がとれない状況ですね。

齊藤:なるほど。そんなことで日本の経済スピードを落としてしまうという可能性も出てくる、と。

杉浦:そうです。実際、規制があまりにも厳しすぎて経済スピードは落ちています。まぁ、事件起こしたところで、ちゃんと対策したところは、十分強くなっていますけど。

齊藤:確かに、反動力がありますね。

杉浦:ええ。相場モノですので、戻しは必ずあります。1回落ちたら必ず戻すっていうのが。

齊藤:「不正マイニング」の話なんかはどうですか。

杉浦:あれは微妙ですね。ちょうど裁判 も大詰め6、どこが不正でどこがそうでないのか、といったところで、セキュリティにかかわる人たちが怯えながら仕事しなきゃいけなくなるというのが現状ですね。

齊藤:たとえ、著名な方であっても、研究のための範囲だといっても関係ないですからね。

杉浦:(警察が)捕まえやすいかどうかいという、あまりよろしくない状況ですね。実はセキュリティは法的なラインが低いんです。そのため、捕まるときは大量に捕まる7、という。

齊藤:それは足枷ですね。

杉浦:セキュリティ業界全体の足枷となっております、これは。

齊藤:やはり日本企業全体で、セキュリティというものがリスクをとりながら行っているものなんだという理解が進んでいかないと難しいですね。いわゆる「ホワイトハッカー」、彼らが研究しないことには・・・。

杉浦:実際に守る側というのは、攻撃するすべての手段を想定しなければならないから難しい。攻撃する側は一つでも当たればOKなんですけれども。ひとつ突破口があれば皆それをまねてしまう。(攻撃側に)1人優秀な人が存在すればそれだけでリスクになる。

齊藤:日本国内ではセキュリティエンジニアが不足しているといいますが、例えばトップエンジニアとなるべき人をどう教育していくか、という課題がこれまでずっと何年も解決できていません。杉浦さんは昨年、日本ハッカー協会を設立されましたね。

杉浦:先にお話したような、攻撃者に対抗できるトップエンジニアになるには、相当高いスキルが必要です。ところが、セキュリティエンジニアの世界は特殊で、犯罪と紙一重ですから、一線越えたような人たちが業界には結構いる。そのおかげで進歩しているのに、「一線越えてしまったら帰ってこれない」では困ります。彼らの活躍の場が必要ですし、また罪に問われないように保護する仕組みが必要だと思ったわけです。日本では凶悪犯であればあるほど捕まりにくい、という面があります。小中学生とか、未熟なスキルの人ほどつかまってしまう。法的な知識もありませんし。そうすると、そこで将来が閉ざされてしまう。それを何とかしないと。

齊藤:脆弱性が発見されることに対する考え方も問題ですね。お客様の現場から、「何でこんなに脆弱性が見つかるんだ!」と聞こえてくることがある。いや、見つかってよかったじゃないですか、という話なんですけども(笑)。

杉浦:悪用される前にね(笑)。

齊藤:そうなんですよ、悪用される前に見つかってよかったじゃないですか(笑)。そのためにやっているのに、「何でこんなに脆弱性が見つかるんだ!」となってしまう。

杉浦:まぁ、そういうものは出てきて当たり前、逆に早めに全部出してくれというマインドを持っていただくことが必要ですね。むしろ何で出てこないんだ、というくらい。何も出てこないシステムはよほどしっかりした作りか、逆に脆弱性診断が実にやりにくいサイトか(笑)。

BBSec:診断しにくいシステムですか。結構あるものでしょうか。

齊藤:ありますね、診断がしにくい。何でこんなことになっているんだ、と。

杉浦:IPSが入っていて、一部しかコマンド飛ばないとか。アプリケーション診断なら、そういうものを排除してから実施したいというのはありますね。脆弱性が確定してからIPS入れて、防御しましょう、となるべきなんですが。

齊藤:本来はそういった「生」のものにアタックをかけて、さらに防衛されている防衛装置の上からでもいけますか、という二段階の診断をするのが望ましいですね。最近では、WAFとかIPSもある程度負荷をかけた状態の時には抜けてしまうというようなこともありますから、防御装置を入れてあるから大丈夫、ではなくて、その外側からもちゃんと見ていく、ということも必要ですね。

杉浦:特にエンタープライズ系のセキュリティというのは、全体的な統制がとれていないとか、実際動いてない機械が半数ということも多いですし。

齊藤:そうですね、IPSはどこかにアラートをあげるような設定を初期に行っていたとしても、だんだんチューニングがおろそかになって行って、実態と乖離してくることがある。

   合同会社エルプラス 代表社員
      杉浦 隆幸 氏

杉浦:やっぱり運用は難しいですからね。全部アウトソーシングしているところも多いですしね。社員1万人くらいの大きい会社さんでセキュリティをちゃんとマネジメントしようとすると、全部で20名以上のセキュリティ要員が必要になるでしょうからね。SOC(Security Operation Center)を作ったり、新しく導入したシステムのテストをするとか、インシデントレスポンス対策など考えると、やはりそれだけの人数は必要になりますが、なかなか自前でそれだけの技術者を用意するのは難しい。ですからセキュリティ専門企業をうまく使いこなすのが日本のセキュリティマネジメントのキーファクターですね。

齊藤:そのとおりですね。SIEM(Security Information and Event Management)なんかも多くの企業で導入していますが、本当に必要なログを有効な方法で取得しているか、あとで確認できるものになっているか、というとまだまだハテナをつけざるを得ない。特に企業側で運用を始めますと、工数のこと考え始めますから。余計なログはとりたくない、とか。そういう考えに陥ってしまう。そういう意味でいくと、セキュリティ専門でそこだけを見ているようなところに頼んでいただけると、運用工数ありきのセキュリティにはならないわけですね。

杉浦:またセキュリティのスペシャリストは専門性が高いですから、いろんな事例を知っていた方がお客様に対するフィードバックも厚くなる。そういうことを考えると、社外の、豊富な事例を知っている専門家に依頼する方が有効ですね。社内で脆弱性診断を抱える意味はまったくないです。よほどたくさんのサービスを持っているなら別でしょうけど。

BBSec:一人の優秀なエンジニアが突破口となって飛躍してしまう、とのことでしたが、そうした攻撃手法や脆弱性の検証に苦労したお話があればお伺いしたいのですが。

杉浦:検証自体、結構苦労しますよね。脆弱性を見つけるだけならバージョンチェックで済むこともありますよ。いま年間1万件以上の脆弱性が発見されるじゃないですか。専門家であっても、その数を全部追いかけるのは難しいわけですよ。

齊藤:CVSSの登録をするのがセキュリティエンジニアのマスト要件か、ぐらいの感じで(笑)。再現性の問題ですが、IoT機器なんかは、製品は大きなものなのでひとつしかお貸し出しできません、となったりすると、トライできる回数が非常に限られてしまう。そういったことが、検証が難しい要因となりますね。

杉浦:理想を言えば、「壊すのでひとつください」ですよね。いろんな検査をして結果的に壊していいものと、正常な振る舞いを見るためのもの。このふたつをください、です。

齊藤:本当に1回しかトライできないとなると、例えばBlack HatDEFCONで、爆弾処理のトレーニングがあるんですね。ちょうどその一人目がクリアする前の記録を見ると、342人とありましたので「ああ、342人死んだんだな」と。実際に防ぎなさいという場合はどう検証しようか(笑)。

杉浦:無理やり、液体窒素で冷やして、爆発しないようにして、爆発するときは爆発用に囲った中でとか、あるいは敢えて爆発させてみて検証するとか、色々あるんでしょうけども。訓練としては面白いですよね。作ってみましょうか。爆発したら花火が上がるとか・・・(笑)。
先ごろ*8 4年ぶりに改定されたOWASP IoT Top 10でもファームウェアのアップデートをちゃんとしなさい、と言っているんですが、当たり前のことがやっと書かれたくらいです。IoT機器は使われる期間が長いし、ある程度ユーザが考えていかなきゃならない部分もあるんですよね。

BBSec:企業でも忘れられた機器が残っていることがありますね。

齊藤:繰り返しになりますが、システムの運用を維持する、というのは本当に大変なことなんですよ。

杉浦:セキュリティコストが高い、といわれる一番の原因は運用の問題でして。運用もやっぱり費用がかかるわけですから、そもそもの設計段階で、安全性を担保しながら費用を軽減できる方法を考えておかなければならない。それをしないと、セキュリティをまともにやろうとした段階ですごく高コストになるんですよ。大体機器の2倍から5倍かかるというのが一般的です。コストばかりかかって実効性がないセキュリティになってしまったりするんです。それは経営層がちゃんと考えておかなければならない。予算は有限ですからね。

齊藤:例えば、建物の縁の下がどれだけゴミだらけでも住んでる人は気にしない、みたいな感じですね。放置していたらそこから腐っていって土台が緩んだりすることもあるし、誰か入り込んでくる可能性だってある。その辺をセキュリティに置き換えたときにどのくらい想像できるかでしょうね。

杉浦:誰も見てない、録画してない監視カメラがやたらあるけど・・・みたいな(笑)。ある程度の防犯効果はあるだろうけど、いざというときに役に立っていない。

齊藤:そういった防犯効果だけを求めるのであれば、高額な機器を導入するのではなく、代替機器でどうにかする、という発想も必要ですね。本当に必要な機能を適正に選んでいく、というのが大事です。先ほどの家の話でいきますと、お風呂場で覗かれるのを防ぐために防犯カメラを導入するのかというと、そこまでは必要ない。むしろ、お風呂場の窓の下に砂利を敷き詰める方がコストもかからず効果も高い。

杉浦:そうです、音が鳴るだけでも十分効果が得られますから。

齊藤:ですから、そうした全体像をどこまで描けるか、が重要ですね。

BBSec: 仮想通貨を巡る話題から、日本のセキュリティ業界のあり方やトップエンジニアの将来を守りたい、という強いお気持ちなど、「サイバーセキュリティ最前線」にふさわしいお話を伺うことができました。本日は長時間ありがとうございました。


杉浦 隆幸 氏
合同会社エルプラス 代表社員
Winnyの暗号の解読にはじめて成功、ゲームのコピープロテクトの企画開発をはじめ、 企業や官公庁の情報漏洩事件の調査コンサルティングを行う。 昨今では仮想通貨の安全性確保、Androidアプリの解析や、電話帳情報を抜くアプリの撲滅、 ドローンをハッキングで撃墜するデモや、自動車のハッキングなどを行う。テレビなどの出演多数 。

齊藤 義人
株式会社ブロードバンドセキュリティ (BBSec)
セキュリティサービス本部本部長
Webアプリケーションを中心とした開発エンジニアを経て、官公庁および 大手顧客向け脆弱性診断・ペネトレーションテストに従事。 数年にわたる長期かつ大規模システムのプロジェクトマネージャーとして活躍。


年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Share