人という脆弱性
~ソーシャル・エンジニアリング攻撃~

Share

Security NEWS TOPに戻る
バックナンバー TOPに戻る

SQAT® Security Report 2020-2021年 秋冬号掲載

特殊詐欺のイメージ画像(電話・お金・メモ)

※本記事は、2020年10月公開SQAT®Security Report 2020-2021年 秋冬号の記事、「人という脆弱性~ソーシャル・エンジニアリング攻撃~」の一部抜粋になります。

ここ数年、ソーシャル・エンジニアリングを用いた攻撃による大規模な事件が多数発生している。

・2015年に発生した日本年金機構の大規模な情報漏洩事件*1
・2017年の大手航空会社が3億8000万円をだましとられた事件*2
・2018年の暗号通貨の不正送金事件*3
・2020年7月に起きた大手SNSの大規模アカウントハック事件*4

これらはすべてソーシャル・エンジニアリングを用いた攻撃に端を発しているといわれている。ソーシャル・エンジニアリングを用いた攻撃の高まりを受けて、IPA(独立行政法人 情報処理推進機構)が「ソーシャル・エンジニアリングを巧みに利用した攻撃の分析と対策」*5 を発表したのが2009年であるが、10年以上が経過した今も、ソーシャル・エンジニアリングを用いた攻撃は、収まる気配がない。それは、ソーシャル・エンジニアリングが持つ、人間という脆弱性を狙う性質に原因がある。
ここでは、今一度、ソーシャル・エンジニアリングと人間とのかかわりを考えていきたいと思う。

攻撃者の目線

サイバー攻撃を行う場合、攻撃者はいくつかの手段を選択することができる。その選択肢の中で、システムの脆弱性を攻撃して目的の情報を盗みだすことよりも、人間を狙って攻撃する方が、少ないコストで多くの利益を得ることができると、彼らはときに考える。それが、人間という脆弱性を狙った攻撃、つまりソーシャル・エンジニアリングを用いた攻撃である。ここでは人間をシステム全体に対する脆弱性ととらえて、解説と対策を語っていきたい。

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

そもそも、ソーシャル・エンジニアリングとは何なのだろうか? ソーシャル・エンジニアリングフレームワークの第一人者と知られるクリストファー・ハドナジー(Christopher Hadnagy)氏は、著作『ソーシャル・エンジニアリング』(日経BP社)の中で、ソーシャル・エンジニアリングを「人を操って行動を起こさせる行為。ただし、その行動が当人の最大の利益に適合しているか否かを問わないこともある」と定義づけている。これには警察官、弁護士、医師といった人々が、標的当人の利益となるように誘導するといったケースも含まれているが、一般的にサイバー攻撃におけるソーシャル・エンジニアリングとは、不正アクセスするのに必要なシステム情報、アカウント、パスワード、ネットワーク・アドレス等を正規のユーザあるいはその家族、友人などから人間の心理的な隙や、行動のミスにつけ込んで手に入れる手法と位置付けられることが多くなっている。ソーシャル・エンジニアリング攻撃の定義は様々なものがあるが、その共通するところは、人を介して攻撃を行うという点である。

人が持つ心理的脆弱性

では、なぜ人が脆弱性となってしまうのか、この点について、原因の一つとなっていると考えられる、人に存在する心理的脆弱性を見ていきたい。ハドナジー氏は人には以下のような8つの心理的脆弱性が備わっていると主張している。

返礼
人からの親切に対し、お返しをせずにはいられない特性

プレゼントのお返しに、何かしてほしいことはないかと聞く。

義務感
社会的、法的、道徳的に、人がなすべきだと感じている行動をとってしまう特性

身体が不自由な人に、積極的に手を差し伸べなくてはならないと考えて寄付を行う。

譲歩
何かを譲ってもらったら、同じように譲らなくてはならないと考える特性

相手の大きな要求を最初に断ったのだから、次の小さな要求には応じてあげたいと考える。


本記事はここまでになります。

この記事の続きでは、こちらでご紹介した以外にも、人に対する過度なストレスを与える攻撃、など心理的弱みを突く攻撃「ソーシャル・エンジニアリング」のメカニズムを徹底解説しています。 ぜひご一読ください。

※参考(続き)
contents
4.人へのバッファオーバーフロー攻撃
5.人間の隙をつくソーシャル・エンジニアリング攻撃
6.テクノロジーが人間を追い詰める
7.ソーシャル・エンジニアリングに対する防御
8.おわりに

下記より無料でダウンロードいただけます。

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

年二回発行されるセキュリティトレンドの詳細レポートをダウンロードできるURLをお送りいたします。
見積もりについてのご相談は、お問い合わせよりご連絡ください。

Security NEWS TOPに戻る
バックナンバー TOPに戻る


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

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像

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

Share

Security NEWS TOPに戻る
バックナンバー TOPに戻る

キーボードと虫眼鏡

私たちの生活を支える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はすべて一桁パーセント以下のシェアです)*6。CMSの代名詞といえるWordPressですが、その分サイバー攻撃者の注目度も高く、脆弱性の発見とこれに対応したアップグレードを常に繰り返しています。

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

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

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

出典:IPA「安全なウェブサイトの作り方 – 1.1 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月に「テレワーク時代のセキュリティ情報の集め方」と題したウェビナーで、情報収集の仕方やソースリストのご紹介をしておりますので、ぜひご参考にしていただければと思います。

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

Security NEWS TOPに戻る
バックナンバー TOPに戻る


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

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像

クロスサイトリクエストフォージェリ(CSRF/XSRF)とは?狙われやすいWebアプリケーションの脆弱性対策

Share

Security NEWS TOPに戻る
バックナンバー TOPに戻る

今回は、クロスサイトスクリプティング(XSS)のような「大物の脆弱性」と比較すると、一見地味に見えてしまう「CSRF」の意外な危険性について取り上げます。CSRFの脆弱性リスクやXSSとの違い、さらに実際の診断の現場での検出頻度や、見つかった際に行うべき対応、予防策についてもご紹介します。安全なWebサイト運用のために必読です。

クロスサイトリクエストフォージェリとは

クロスサイトリクエストフォージェリ(Cross Site Request Forgery)は、Webアプリケーションの脆弱性の一つで、略称「CSRF」とも呼ばれます。読み方は「シーサーフ」です。英語で「Cross」は「X」と表記することがあるため、CSRFを「XSRF」と表記することもあります。

「クロスサイト」は「Webサイトをまたぐ」という意味で、「リクエスト」はユーザがWebアプリケーションなどに処理を要求すること、「フォージェリ」には「偽造品」などの意味があります。CSRFの脆弱性を悪用することで、ユーザが意図していないリクエストを強制的に行わせることが可能になります。攻撃者は罠として用意した偽造サイトを用いてユーザーに意図しないリクエストを強制的に送信させます。結果として、ユーザーの認証情報を利用した不正な操作や、個人情報の流出が引き起こされる可能性があります。

クロスサイトリクエストフォージェリとクロスサイトスクリプティングの違い

クロスサイトリクエストフォージェリと似た名前の脆弱性に「クロスサイトスクリプティング(XSS:Cross Site Scripting)」があります。クロスサイトリクエストフォージェリとクロスサイトスクリプティングは、どちらもサイトを横断(Cross Site)してサイバー攻撃が行われる点が共通していますが、発見される頻度や攻撃による影響、対策方法は異なります。

  • XSS:Webサイトに悪意のあるスクリプトを埋め込む
  • CSRF:ユーザの意図しないリクエストを強制的に実行させる

脆弱性診断の現場にみるCSRFの実態

あなたがいまご覧になっているサイト「SQAT.jp」を運営する株式会社ブロードバンドセキュリティでは、日々、さまざまなお客様のシステムに対して脆弱性診断を行っています。

ブロードバンドセキュリティが2024年上半期に総数3,536のシステムに対して行った脆弱性診断の結果、CSRFを含む「セッション管理関連の脆弱性」は15%のシステムで検出され、その中にCSRFは44%含まれていました。つまりCSRFの脆弱性が存在したシステムは全体の6%になります。ここの数字をどうとらえたらよいのか、このあと、CSRFの攻撃例やリスクを紹介しながら考えていきます。

CSRFによる攻撃と被害例

CSRFの脆弱性を悪用した攻撃事例としては、掲示板等に本人が全く意図していない書き込みをさせた例(「遠隔操作ウイルス事件」や「はまちちゃん事件」が有名)があります。

もしCSRFが脆弱性診断で見つかったら、すぐに対応が必要な場合もあります。特に、個人情報の登録や変更などに関わるログイン後のページで発見された場合は、すぐに修正を行わなければなりません。

意図しない掲示板の書き込み以外にも、CSRFの脆弱性を悪用すれば、たとえば「サイトAにログインして会員登録を行っているつもりが、実際には攻撃者が罠として用意したサイトBにログインしており、そこで個人情報を抜き取られる」ような攻撃が行われる危険性もあります。もしそうなれば、サイト運営者としての責任が厳しく問われることは間違いありません。

対策を怠ると他サイトへの遷移ができなくなる可能性も

また、主要なWebブラウザは、XSSやCSRFなどからの保護のために、脆弱性のあるWebサイトをブラウザに表示させない仕様を整えつつあります。たとえばGoogle Chromeは、Chrome 80以降、サイトを越えてCookie情報をやり取りするためのSameSite属性に対して制限を加え、CSRFを防御可能な設定値のみを許容する方向へと段階的に進んでいます*5 。CSRFを防御可能な設定値については他の主要ブラウザも同様の方向に進んでおり、Webアプリケーション開発においてCSRF対策は(他の対策とともに)取らないわけにはいかないものの一つとなりつつあります。

セキュリティ企業が見るCSRFのリスクとは

なお、わたしたちセキュリティ診断サービス会社にとってCSRFとは、一定頻度で検出されるものの、CSRF単体ではそれほどリスクは大きくない脆弱性です。事実、CSRFだけを使った攻撃事例はあまり多くないのです。

CSRFで注意すべきは、他のサイバー攻撃手法と組み合わされることでリスクや被害が大きくなることです。

たとえば「セッションフィクセーション」と呼ばれるセッションIDを強制・固定化する攻撃と、CSRFの脆弱性を悪用した攻撃を組み合わせることで、「セッションハイジャック」と呼ばれるサイバー攻撃が成立すれば、セッションの乗っ取りが行われ、オンラインバンキングでの不正送金などにつながる可能性があります。

CSRFのリスクは低い? 高い?

CSRFだけを考えてしまうとリスクはそれほど高くないため、対応は後回しにされがちです。しかし実際のサイバー攻撃はそう単純ではなく、いくつもの方法が複合されて行われます。「見つかったらすぐに対応が必要な脆弱性のひとつ」とわたしたちが考える理由がそこにあります。

CSRFは、単体では攻撃者にとってそれほど使い勝手の良い脆弱性ではありません。しかし、CSRFはいわば、自身では主役は張れないものの、サイバー攻撃の主役を引き立てるために機能する、名脇役のような脆弱性と言えるかもしれません。

CSRF脆弱性への対策

最も効果的な対策は「トークン」呼ばれる推測困難な文字列の使用です。

  • ユニークな推測困難な文字列を生成
  • リクエスト時に追加検証
  • PHP、Java、ASP.NETの主要フレームワークで実装可能

CSRFの脆弱性を悪用した攻撃で最も警戒すべきはログインしたユーザをターゲットとした攻撃になります。この場合、ログインしたユーザからの正しいリクエストであることを証明するために、「トークン」を使って確認を行うことや再度の認証を行うこと*2などで攻撃を防ぐことができます。

事実、PHP、Java、ASP.NET等の開発言語で提供されている、Webアプリケーションフレームワーク(Laravel、Spring等)は、CSRFの脆弱性を悪用した攻撃を防ぐために、ユニークなトークンを発行する仕組みを持つようになっています。しかし、それでもなおCSRFの脆弱性が見つかることがあるのです。これはどうしてでしょう。

注意!トークン実装の落とし穴

フレームワークに機能があっても、実際のコーディング時に1行追加することを忘れがちです。「機能がある=安全」ではありません。

開発フレームワークがトークンを発行する機能を持っているのにWebアプリケーションでCSRFの脆弱性が発見される理由は、単純そのもので「そもそもトークンを発行するための1行がかかれていない」*3から、ということが多いのです。「機能があるから大丈夫だろう」という思い込みが思わぬリスクを招きます。

前半で、ブロードバンドセキュリティが行った脆弱性診断の結果、約6%でCSRFの脆弱性が検出されたとお伝えしましたが、リスクを知り、適切な対策を確実に実装することで、この数字をもっと少なくすることができるでしょう。

まとめ:CSRFは名脇役、されど油断大敵

  • CSRFとは、「シーサーフ」と呼ばれる、攻撃者が罠として用意したサイトを用いて、ユーザが意図しないリクエストを強制的に行わせることを可能にする脆弱性です。
  • CSRFは単独では大きな脅威ではありませんが、他の攻撃手法と組み合わさることで深刻なセキュリティリスクになり得ます。
  • CSRFとXSSは、どちらもサイトを横断してサイバー攻撃を行う点だけは共通していますが、発見頻度やリスク、対策方法は異なります。
  • 定期的な脆弱性診断と、最新のセキュリティ対策が何より重要です。

Security NEWS TOPに戻る
バックナンバー TOPに戻る


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

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像

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

Share

Security NEWS TOPに戻る
バックナンバー TOPに戻る

いまメモリの安全に関して、その重要性がますます注視されています。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)を見つけることに集中しがちです。

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

Security NEWS TOPに戻る
バックナンバー TOPに戻る


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

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像

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

Share

Security NEWS TOPに戻る
バックナンバー TOPに戻る

WEBアプリケーションは、プログラムの集合体であり、 ソースコードとはシステムやWebアプリを動かすコンピュータプログラムのことです。 このプログラムの集合体は現在では人間から読み書きしやすい言語で書かれていることが多くWebアプリケーションは人間にも読みやすいプログラムのテキスト、ソースコードの集合体と言い換えることができるようになっています。

脆弱性診断とは、システムのセキュリティ上の問題点を洗い出す検査のことですが、その中でも診断対象によりさまざまなサービスがあります。この記事では、その中の「ソースコード診断」を取り上げて、その定義、特徴、メリット、目的などを紹介します。

ソースコード診断とは?

脆弱性診断とは、システムのセキュリティ上の問題点を洗い出す検査のことを指します。
診断対象により、さまざまな脆弱性診断サービスがあります。

まず、企業が開発したWebアプリケーションが挙げられます。
問合せや会員登録といった、入力フォームの入出力値の処理、ログイン機能の認証処理などに対して、幅広く網羅的に脆弱性診断が行われます。
次に、そのWebアプリケーションを実行するサーバやネットワーク機器、OSやミドルウェアに脆弱性がないか検査するネットワーク診断があります。
そのほか、近年増加の一途をたどる スマホアプリケーションや IoT機器を対象とした脆弱性診断もあります。

このうち、ソースコード診断とは、アプリケーションのソースコード(開発者が書いたプログラム)を解析して、セキュリティ上および品質上の問題をコーディングレベルで検査する診断のことをいいます。

ソースコード診断

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

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

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

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

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

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

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

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

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

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

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

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

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

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

開発(Dev)、運用(Ops)、セキュリティ(Sec)を一体にしてシステムライフサイクルを回すDevSecOpsという考え方が注目を集めています。DevSecOpsとは、開発の全工程において、開発チームと運用チームが相互協力し、その一環にセキュリティを組みこむことで、アプリケーション開発のセキュリティを確保していく考え方のことをいいます。ここでは、開発プロセスのどこで、セキュリティを確保するための施策を実施するか説明します。

DevSecOpsにおけるセキュリティ対策

DevSecOps実現のためには、「シフトレフト」の考え方が大切になります。
セキュリティを開発の最終段階で対応したのではすでに遅く、開発プロセスの全フェーズにおいて常にセキュリティ上の課題を先取りして解決しながら進めることが、テストやリリースといった最終段階での手戻りを防ぎ、結果的にトータルコストの削減と品質の向上に寄与します。

一般的なセキュリティ対策として多くイメージされている「Webアプリケーション脆弱性診断」は「テスト」「リリース」工程におけるセキュリティ対策の一つ。
その一つ手前工程の「製造」工程におけるセキュリティ対策の一つが「ソースコード診断」です。

セキュアプログラミング

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

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

一般的なWebアプリケーション脆弱性診断(ブラックボックステスト)では検出しにくい脆弱性も、ソースコード診断(ホワイトボックステスト)では発見できる場合があります。
たとえば未使用のコード、ログファイルによる情報の露出、エラーメッセージによる情報の露出などは、ソースコードを直接確認することで検知可能になります。

以下はWebアプリケーション診断とソースコード診断の両方の観点で検出可能な脆弱性です。
ここでは代表的な脆弱性(セキュリティバグ)について説明します。これらのバグを突く攻撃の名称としても用いられています。

バッファオーバーフロー

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

フォーマットストリング

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

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

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

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

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

まとめ

・ソースコード診断はソースコード(開発者が書いたプログラム)を解析し、セキュリティ上の問題点を発見する
・開発フェーズの初期から実施することで、リリース直前に脆弱性が発見されるようなスケジュールに影響するトラブルを防止する
・一般的なWebアプリケーション脆弱性診断では検出しにくい脆弱性も、ソースコード診断を実施することで開発段階から検出ができる

Security NEWS TOPに戻る
バックナンバー TOPに戻る


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

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像

診断結果にみる情報セキュリティの現状
~2019年下半期 診断結果分析~

Share

Security NEWS TOPに戻る
バックナンバー TOPに戻る

SQAT® Security Report 2020年春夏号

BBSecの診断について

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

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

2019年下半期診断結果

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

脆弱性診断脆弱性検出率2019年下半期

診断の結果、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プロトコルにおいても、攻撃者に暗号文を解読される恐れがあるため、脆弱な暗号化方式およびハッシュアルゴリズムを許容しないことが望まれる。

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

Security NEWS TOPに戻る
バックナンバー TOPに戻る


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

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像

自動車ハッキングの今

Share

Security NEWS TOPに戻る
バックナンバー TOPに戻る

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*4 を取り入れたり、設計段階からのセキュアコーディング、さらに実車に対する脆弱性診断を実施したりするなど、今後ますます対策が必要になるであろう。

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

Security NEWS TOPに戻る
バックナンバー TOPに戻る


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

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像

<対談>杉浦 隆幸 氏(合同会社エルプラス 代表社員) ✕ 齊藤 義人(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で行われた診断の統計データも掲載。
サービスに関する疑問や質問はこちらからお気軽にお問合せください。