変貌するランサムウェア、いま何が脅威か
―2020年最新動向―

Share

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

データ等を不正に暗号化し、「身代金(Ransom)」を支払うよう個人や企業を脅迫・恐喝するランサムウェア。近年世界各地で猛威を振るい、日本国内での被害も複数報じられています。本記事では、そのランサムウェアをめぐる最新情報をご紹介します。なお、ランサムウェアに関する基本的情報については、「ランサムウェア その被害と対応策、もし感染したら企業経営者はどう向き合うべきか」をご参考ください。

ランサムウェア特集2021年版を公開しました!
2021年の最新動向については、「ランサムウェア最新動向2021
―2020年振り返りとともに―」をご覧ください。

ランサムウェアの現状

現在のランサムウェアは、「Ransomware-as-a-Service」(通称「RaaS」)と呼ばれる形態、すなわち、ランサムウェアそのものを提供するのではなく、サービスとして犯罪行為を提供する形態が主流となっています。また、従来のメールのばらまきやワームによる拡散のように機械的にランサムウェアをばらまく方式に加えて、攻撃者が手動で侵入し、ネットワーク内で慎重に被害範囲を拡大させて攻撃の影響を最大化する「人手によるランサムウェア攻撃(human operated ransomware attacks/campaigns)」が増えています。人手によるランサムウェア攻撃の手法には、APT(Advanced Persistent Threat:持続的標的型攻撃)との類似点が多く、APTへの対策がそのままランサムウェア攻撃への対策となりつつあるという現状があります。

また、単に身代金の支払いを要求するだけではなく、身代金を支払わなかったらデータの暴露を行うと脅すタイプのランサムウェア(とその犯行グループ)もあり、身代金を支払ったにもかかわらずデータが暴露されてしまったケースも出ています(なお、こうした犯行では、データを暴露するサイトがダークウェブに開設されています)。さらに、一部のランサムウェアはデータ破壊の機能も備えているため、以前にもましてオフラインバックアップの重要性が増しているともいえます。

身代金の額も年々上昇しており、ENISA(欧州ネットワーク情報セキュリティ庁)の2020年版年次レポートによると、2019年に支払われたと推計される身代金は100億ユーロ(約1.2兆円)を超えました。その他、各種調査機関の四半期レポートでも、2020年はさらに身代金の支払い額が増えていることが報告されています。

このような状況下においては、サイバー保険が一層重要性を増し、多くの企業ではランサムウェア等の被害からの復旧を前提として契約を行っていると考えられます。しかし、スイスの保険会社の米法人がランサムウェア攻撃をサイバー保険の免責事項にあたる戦争に該当するとして支払いを拒否したことから、現在係争中となっているケースがあり、「サイバー保険を掛けていれば大丈夫」と言い切れない点に注意が必要です。

各種ランサムウェアの概要

現在、活況を呈しているともいえるランサムウェア。2020年の時点でどのようなランサムウェアが確認されているのでしょう。主なものを以下に紹介していきます(類似の特徴を持つランサムウェアは、ランサムウェアファミリーとして、まとめて解説しています)。

REVil/Sodinokibi

<概要>
REVil、またの名をSodinokibi(またはSodin)。当初はアジア圏を中心に、現在は地域を問わず多くの被害が確認されているRaaSです。アフィリエイトプログラムも盛んで、支払われた身代金の30%~40%をアフィリエイトに支払っているとも言われ、組織的な犯行であることが知られています。2019年に活動停止を宣言したランサムウェアGandCrabのコードとの類似性が高いこと、身代金の支払いを行わなかった場合にデータの暴露を行う脅迫を行うことでも知られています。このランサムウェアファミリーの初期アクセス活動は、標的型フィッシングメールによるもののほか、リモートデスクトップサービス(RDP)やVPNゲートウェイなどの脆弱性を悪用したケースもあります。

<被害事例>
2020年1月に英・外貨両替商が被害を受け、230万米ドル(約2億5千万円)の身代金が支払われました。この事例では、脆弱性が修正されていないVPNサーバ「Pulse Connect Secure」が攻撃の足掛かりにされたことが知られています。

Nephilim/Nefilim

<概要>
このランサムウェアは、身代金の支払いと、身代金の支払いを行わなかった場合のデータ暴露という二重の脅迫を行うことで知られています。2020年6月にニュージーランドのCERTが公開した注意喚起によると、Cirtix ADCなどの脆弱性(CVE-2019-19781、2020年1月に修正プログラム公開済み)を悪用したり脆弱な認証機構を突破したりすることにより不正アクセスを行った後、Mimikatz、psexec、Cobalt Strikeなどのツールを利用して権限昇格や横展開を行って永続性を確保し、その後、このランサムウェアによるファイルの暗号化と身代金の要求が行われます。

<被害事例>
日本企業の豪子会社で2020年1月と5月の二度にわたってランサムウェアの被害が発生しましたが、そのうち5月に発生した被害がNefilimによるものであるとされています。なお1月のランサムウェア被害は、次に紹介するNetWalkerによるものでした。

NetWalker/Mailto

<概要>
主に欧米諸国とオーストラリアの企業をターゲットとしたランサムウェアで、他のランサムウェア同様に、身代金の支払いと、身代金の支払いを行わなかった場合のデータ暴露という二重の脅迫を行います。初期アクセスはRDP、標的型フィッシングメール、古いバージョンのApache TomcatやOracle WebLogic Serverへの攻撃により行われます。一方、侵入後の権限昇格にはSMBv3の脆弱性(CVE-2020-0796)などの脆弱性が用いられます。

<被害事例>
直近の事例では2020年10月にイタリアのエネルギー会社が被害を受け、1400万米ドル(約1億5千万円)の身代金を要求されたという報道*1があります。5TBほどのデータが暗号化されたうえ、持ち出された可能性があり、身代金を支払わない場合にはデータを暴露するという脅迫も受けています。

Ryuk/Conti

<概要>
Ryukは2019年に猛威を振るったランサムウェア、Contiは2020年に登場したランサムウェアで、類似性が指摘されています。いずれも北米での被害、それも公的機関や医療機関での被害が多い点に特徴があり、他のマルウェア(Trickbotなど)を介して侵入したのちデータの暗号化と持ち出し、身代金の要求を行います。Contiについては、身代金の支払いを拒否した組織のデータの暴露を行っており、EDRのフッキングをバイパスすることも報告されています。

<被害事例>
Contiについては2020年10月に米マサチューセッツ州とジョージア州の医療機関で被害があり、データの暴露が行われたことが確認されています。Ryukに関しては、米CISAが、医療機関での被害を受け、Trickbotおよびバックドア マルウェアであるBazarLoader/BazarBackdoorと合わせての注意喚起を行っています。

ChaCha/Maze/Sekhmet/Egregor

<概要>
ChaChaにルーツを持つランサムウェアがMazeで、SekhmetやEgregorはその亜種として位置づけられています。REVil/Sodinokibi同様にアフィリエイトモデルを採用している点に特徴があり、複数のグループが連動して動いているとされています。2020年11月、国内大手企業の被害により日本でも名を知られるようになったRagnar Lockerも、過去にアフィリエイトとして協力関係にあったといわれています。身代金の要求に加えて、支払いを拒否した場合のデータ暴露の脅迫を行う点もREVil/Sodinokibiと共通する点です。被害が発生しているのは特定の地域に限らず、世界規模と言っていいでしょう。Mazeでは、多様なエクスプロイトツールやマルウェアとの組み合わせで初期アクセスや横展開などが行われています。

<被害事例>
スイスのサイバー保険大手が2020年3月に被害を受けた事例や、2020年4月の米国の航空機メンテナンス会社の事例などが挙げられます。後者については、Mazeによるデータの窃取と公開を行ったうえで、攻撃後もターゲットのネットワーク内に潜伏し、データを摂取し続けていたことが判明しています。

その他のランサムウェア

  • Avaddon:botnetによりフィッシングメールが送信される点に特徴があるランサムウェア。RaaS。身代金要求に加えてデータ暴露の脅迫も行う。
  • CL0P:オランダの大学などが被害に遭ったランサムウェア。データ暴露のためのサイトを持っている。なおオランダの大学では身代金を支払ったことで復号鍵を入手し、データを復号化できた。
  • Dharma:侵入経路がRDPというオーソドックスなRaaS。MimikatzやLaZagneなどの追加のツールを使い、横展開する。
  • DopplePaymer:ランサムウェア「BitPaymer」をルーツに持つ。新型コロナウイルス(COVID-19)に関連したフィッシングメールを用いること、botnetやマルウェア感染させたインストーラなど多様な初期アクセスが確認されている点などが特徴。
  • Ragnar Locker:2020年11月に国内大手企業が被害を受けたランサムウェア。他のランサムウェアオペレータと協力して攻撃が行われる点に特徴がある。
  • WastedLocker:2020年7月、ウェアラブルデバイスやGPSの測位システムを提供する米企業への攻撃に用いられたランサムウェア。ロシアのサイバー犯罪組織・Evil Corpとの関連が指摘されている。

今後求められるランサムウェア対策とは

冒頭でも触れたとおり、今やランサムウェア攻撃はAPT(持続的標的型攻撃)と同様の戦術を用いるものとなっています。ランサムウェア攻撃とAPTの違いはもはや、攻撃者の最終的な目標が身代金をはじめとする金銭か、そうでないのか、という1点にしか過ぎないといえます。

「APTは国レベルのサイバー攻撃だから自分たちには関係ない」と思っていたとしたら、その認識を改める必要があります。今はランサムウェア攻撃でAPTと同じ手法が使われ、長期にわたる準備期間を経てデータを人質に取られ、身代金を要求される可能性がある―そんな時代になってしまったのです。

人手によるランサムウェア攻撃やAPTに対する対策は非常に複雑です。「今後いつ攻撃を受けることになるかわからない」という前提で、まずは自組織のシステムが攻撃者から見てどのような状態にあるか、現状を知ることが必要になります。セキュリティコンサルタントによるリスクアセスメントやペネトレーションテストによるリスクの洗い出しを行って、攻撃を受けた場合にどのような影響が起こりうるかを把握することを推奨します。

リスクアセスメントやペネトレーションテストなど今すぐには難しい、という場合は、初期アクセスに最も頻繁に用いられる標的型攻撃メールの訓練、公開Webアプリケーションの脆弱性診断、侵入された後の対策として重要なマルウェアによる横展開リスクの診断など、できることから少しずつでも手を付けていくアプローチをぜひ検討してください。

参考情報:
https://www.ipa.go.jp/archive/security/security-alert/2020/ransom.html
https://www.enisa.europa.eu/publications/ransomware
https://www.ipa.go.jp/archive/files/000084974.pdf


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


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

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

診断結果にみるクラウドセキュリティの今

Share

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

弊社では現在、Amazon Web Services(以下AWS)、Microsoft Azure(以下Azure)、Google Cloud Platform(以下GCP)の主要三クラウドを対象とした「クラウドセキュリティ設定診断サービス」をご提供しています。本記事では、弊社の視点で、診断を行う中でみえてきた、クラウドセキュリティの今をお伝えします。

クラウドをめぐるトレンド

昨今、クラウド関連では新しいキーワードが続々と登場しています。例えば、皆様も以下のような言葉を耳にしたことがあるのではないでしょうか。

  • ゼロトラストアーキテクチャ
  • SDP(Software Defined Perimeter)
  • IDaaS(Identity as a Service)
  • コンテナ・マイクロサービス

「ゼロトラストアーキテクチャ」「SDP」は、クラウドを含む企業インフラの在り方を変える仕組み、「IDaaS」は多くのIT関係者の頭痛の種である認証機構をクラウドで実現する新しいサービス、「コンテナ・マイクロサービス」は、開発や運用を効率化するクラウド技術であり、いずれも、しばしば「革新的」「画期的」といった形容詞と共に語られます。しかし、「革新的」「画期的」なものを取り入れさえすれば、クラウドのセキュリティは担保されるのでしょうか。

診断結果からみえてくるもの

弊社ではAWS、Azure、GCPというIaaSを対象としたクラウドセキュリティ設定診断サービスをご提供しています。診断で検出されることが多い問題は、表 1のとおりです。

表1 弊社のクラウドセキュリティ設定診断で多く検出される問題

ID/アクセス管理(IAM)に関する問題
  • 利用されていない認証情報が存在する
  • 長期間ローテーションされていないキーが存在する
  • MFA(多要素認証)が有効化されていない
  • パスワードポリシーが基準を満たしていない
  • セキュリティキーの適用が有効になっていない管理者アカウントが存在する
  • ロギングに関する問題
  • 必要なログが記録される設定になっていない
  • ログが適切に暗号化されていない
  • モニタリングに関する問題
  • ログメトリックフィルタとアラート/アラームが存在しない
  • ネットワーク通信に関する問題
  • SSHやリモートデスクトップサービス(RDS)へのアクセスが制限されていない
  • その他
  • 推奨される暗号化が施されていない
  • OS Loginがプロジェクトで有効になっていない
  • 均一なバケットレベルでのアクセスが有効になっていない
  • 特に目立つのは、ID/アクセス管理(以下IAM)の設定周りの不備です。IAMはクラウドのセキュリティにおける最重要事項であり、この領域でさまざまな問題が検出されているという結果は、危機感を抱くべき状況といえます。

    例えば、「パスワードポリシーが基準を満たしていない」、「長期間ローテーションされていないキーが存在する」、「MFAが有効化されていない」(仮想MFAのみ有効である場合も含む)といった問題は、従来のオンプレミス環境での運用水準を前提とした設定・運用を、クラウド環境に対してもそのまま適用していることが原因ではないかと推測されます。また、「利用されていない認証情報が存在する」のは、異動した社員や退職者の認証情報が削除されずに放置されているためと推測されますが、もし、「ひょっとしたら」「うちの会社も」と感じられるようでしたら、早急に確認することをおすすめします。

    ロギングやモニタリングに関する問題も目を引きます。まず、本番環境において適切なロギングやモニタリングが行われていない場合、対象の環境に何らかの問題が起きた時になすすべもない状況に陥る可能性があります。また、開発環境やステージング環境については、ロギングやモニタリングが無効になっている場合、そのことが問題発生時の原因究明を阻害する要因になりえます。開発環境やステージング環境で意図的にロギングやモニタリングを無効にしている場合は、そのようなリスクがあることを認識し、適宜対応の見直しを検討する必要があります。もちろん、その前提として、本番環境とステージング・開発環境が厳密に分けられていて、アクセスや認可がしっかり設定されていることが必要です。

    さらに、ネットワーク通信に関しては、「SSHやリモートデスクトップサービス(RDS)へのアクセスが制限されていない」という問題が検出されています。これについては、Shodanなどで各ポートを開放しているサーバを検索するとクラウドサービスのFQDNを表示するサーバ多数がクエリを返してくる、という状況があり、そのことをご存知の方であれば、「ああやはり」という感想をお持ちになるのではないでしょうか。クラウドでもオンプレミス環境同様、SSHやRDSへのアクセスを制限しないことは攻撃者に初動の足掛かりを与えることにつながります。制限を掛けることが必須であるはずなのに、案外そうなっていないケースがみられる、というのが、診断結果における現状です。

    いずれの問題についても、「うっかり」も含め、クラウド環境での基本的なセキュリティ設定への対応が十分に行われていないことを示す結果になっているといえます。

    実際のインシデント・事件ではどうだったか

    では、実際のインシデントではどのような対応不備が確認されているのか、クラウドコンピューティングのセキュリティに取り組む国際的非営利団体「クラウドセキュリティアライアンス」(以下CSA)が本年9月に公開したケーススタディ分析「Top Threats to Cloud Computing: Egregious Eleven Deep Dive」から見てみましょう。

    同資料では、近年発生したクラウド上での大規模セキュリティインシデントの中から9件を取り上げ、CCM(Cloud Control Matrix)というフレームワークを用いて分析しています。なお、CCMは、クラウドサービスに必要な管理策・統制とその実装方法の提示を行うフレームワークとして、情報セキュリティとITガバナンスの観点から対処すべき点に関する指針をまとめたものです。同フレームワークに基づく指摘項目数をインシデントごとに集計したものが表 2となります。

    表 2 ケーススタディ事例に対するCCMコントロールドメイン別の指摘項目数

    9件中8件で指摘されたのが、まず、弊社のクラウドセキュリティ設定診断結果でも顕著であった「IAM」、そして「SEF」(セキュリティインシデント管理、Eディスカバリ、クラウドフォレンジックス)関連の不備でした。また、インシデントの過半数において、「TVM」(脅威と脆弱性の管理)、「HRS」(人事)、「IVS」(インフラと仮想化のセキュリティ)、「CCC」(変更管理と構成管理)の問題が指摘されています。

    先ほど述べたとおり、CCMは情報セキュリティに加えてITガバナンスの観点を含むフレームワークであり、弊社がセキュリティ診断で用いている指標との間に直接の互換性はありません。しかしながら、例えば、「利用されていない認証情報が存在する」問題は前述の「IAM」に加えて「HRS」に、ロギングやモニタリングの問題は「IVS」に関連付けられます。また、「TVM」は弊社の脆弱性診断と共通の目的を持つものです。その意味で、セキュリティ面での課題を解消・改善する取り組みは、確実にインシデントの発生抑制に寄与するといえるでしょう。

    新しいキーワードに目を向ける前に

    クラウドサービスの急速な普及が進む中、セキュリティ対策が不十分な状態で導入に踏み切り、セキュリティ事故を引き起こす組織が後を絶ちません。背景には、従来のオンプレミス環境で「外からアクセスされるわけではないから今まで通りでもまあいいか」と設定や運用をなおざりにしてきた「うっかり」を許し、設定ミスを防げなかった、等さまざまな状況があると考えられます。ID/アクセス管理といった基本的な対応の不備が目立つのもその表れでしょう。

    クラウドは今まさに旬のテクノロジーであり、冒頭に紹介したような新しいキーワードは、今後も次々に登場するものと思われます。キーワードを考慮して新たな戦略を練る前に、利用するクラウドサービスの基本的なセキュリティ設定はできているかを確認することが大切です。例えば、「ゼロトラストアーキテクチャ」を本気で適用しようとした場合、もしIAMの設定に不備があったとしたらどうでしょう。ゼロトラストアーキテクチャに求められる厳格な認証・認可の運用に致命的な問題を引き起こしかねません。新しいものに目を向ける前に、足元を見直す。弊社は診断サービスを通じてこれを支援していきたいと考えています。

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

    クラウドセキュリティ設定診断サービスの詳しい内容が記載されている資料がダウンロードできるURLをお送りいたします。
    見積もりについてのご相談は、お問い合わせよりご連絡ください。


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


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

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

    ブルートフォース攻撃 ~ IDとパスワードだけのセキュリティはもうオワコン?

    Share

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

    ブルートフォース攻撃とは、不正アクセスを行うために、パスワードを総当たりで試すことです。今回は、辞書攻撃やパスワードスプレー攻撃など、さまざまなパスワードへの攻撃を紹介しながら、ユーザと管理者が行うべき対策、そして最新のWebアプリケーションの検証基準であるOWASP ASVS 4.0にも記載のある多要素認証やリスクベース認証を説明し、これからのアカウント保護について考えます。

    ブルートフォース攻撃とは

    ブルートフォース(Brute Force)とは「力任せ」という意味です。サイバーセキュリティの用語「ブルートフォース攻撃(Brute Force Attack)」とは、パスワードに対する攻撃のことを表し、たとえば数字四桁のパスワードなら「0000」からはじまり「0001」「0002」「0003」…と順に「9999」まで試すことで、いつかは正しいパスワードを確実に探し当てることができる、まさに力づくの攻撃手法です。

    知識が不要で、誰でもできる難易度が低い攻撃です。ブルートフォース攻撃を行うためのツールが出回っている点も難易度を引き下げる要因となっています。

    辞書、パスワードリスト、リバースブルートフォース、パスワードスプレー…、パスワードを破るサイバー攻撃の手法は多種多様

    IDとパスワードだけでログインできるシステムの場合、そのふたつさえ明らかになれば不正アクセスが成立します。そのため、不正アクセスのためにパスワードを破る攻撃は多種多様な工夫が行われ、進化を遂げています。いくつか代表的なパスワード破りの攻撃を紹介しましょう。

    ・辞書攻撃
    全く意味のない文字列を暗記するのは難しいため、多くの場合人間は意味のある言葉をパスワードに用います。辞書攻撃は、一般的な単語やあるいはよくパスワードに使われる言葉(「123456」「qweryty」「password」etc.)を試していく攻撃方法です。ブルートフォース攻撃よりも時間がかかりません。

    ・パスワードリスト攻撃
    たとえば同一のメールアドレスで、A、B、C三つのWebサービスに登録しており、WebサービスAの情報漏えいによってIDとパスワードのリストが流出した場合、パスワードを使い回していた場合、サービスBとCにも不正アクセスされてしまう可能性があります。すべてのサービスでパスワードを別々に管理することが難しい点を突いた攻撃です。

    ・リバースブルートフォース攻撃
    ブルートフォースと「逆(リバース)」の攻撃、つまり「123456」や「password」など、非常にしばしば用いられる文字列にパスワードの方を固定して、IDをさまざまなメールアドレス等に変えてログインを試みます。

    ・パスワードスプレー攻撃
    パスワードスプレー攻撃はよく使われるパスワードを大量のアカウントへのログインに試す攻撃で、一種の辞書攻撃ともいえます。一般的にほとんどのWebサービスや各種の認証機構は現在、パスワード入力を何度か間違えるとロックされて一定時間操作ができなくなる、同一IPアドレスからの接続を遮断するというブルートフォース攻撃への対策が取られています。しかし、パスワードスプレー攻撃は、大量のアカウントに対してロックされない最大の回数のパスワード試行を、時間をおいて、ときには数ヶ月もの期間、「low-and-slow」ともいわれる方法でくりかえし行うことで、一般的なブルートフォース攻撃対策を潜り抜ける点に特徴があります。

    診断会社がブルートフォース攻撃を業務として行うとき

    SQAT.jpを運営する株式会社ブロードバンドセキュリティは、セキュリティ診断サービスを提供しており、お客様からのご希望に基づき、オプションとしてパスワードへの模擬攻撃を行うことがあります。たとえば、認証系の攻撃テストの項目のひとつに疑似ブルートフォース攻撃が含まれていたりします。

    ブルートフォースや辞書攻撃はパスワード解析ツールなどを稼働させて診断を行いますが、PCの負荷が高くなるため、診断を行う技術者はその作業中、PCで別の作業がほとんどできなくなったりすることがあります。

    なお、こうしたセキュリティ診断業務としてのブルートフォース攻撃等は、すべてお客様からの依頼に基づいて、事前にヒアリングを行い、書面で契約を締結して実施されます。一般の方が、ネットで見つけたパスワード解析ツールを企業のWebサイトなどに対して勝手に使用したりすると、即「不正アクセス行為の禁止等に関する法律」に抵触する犯罪となることをここに記載しておきます。

    パスワードの黄昏、IDとパスワードのみの認証はもうオワコン?

    これまでのセキュリティに関する記事や読み物ならば、このあたりで、ユーザ向けなら「強いパスワードを作る方法」「サービス毎の別々のパスワード管理」等を紹介し、システム管理者向けなら「パスワードを流出させない対策」「万が一事故が起こったときのためのパスワードのハッシュ化とソルトによる不可逆暗号化」などを提案して終わりにしたことだと思います。

    しかし本稿執筆の2020年の今、それだけで十分ではないのでは?とわたしたちは考えます。

    どんなに強いパスワードを設定していても、ハッシュ値で保護していても、「レインボーテーブル」と呼ばれるハッシュ化されたパスワードの解析ツールを用いてしまえばパスワードが解析されてしまいます。もちろんパスワードのハッシュ化に加えてソルトやストレッチといった方法でさらに保護することも必要ですが、ソルト、ストレッチが複雑化・多重化されていなければハッシュ同様に解析されてしまう可能性も否定できません。

    さらに、パスワードリスト攻撃に使われるIDとパスワードのセットは、大手サービスの情報漏えいなどで流出したデータ等が用いられますが、これらはアンダーグラウンド市場などで、数億件のIDとパスワードのセットを低価格で購入することができますし、一定の方法で検索するとネットに落ちていることすらあります。

    パスワードだけで認証する時代はもう終わったと捉えるべき時期に来ています。パスワードの適切な管理の重要性は今後もまったく変わりませんが、それだけでなんとかなった時代にはもう戻れないのです。

    認証のセキュリティ対策に求められる要件は?Webセキュリティの国際検証基準「OWASP ASVS 4.0」

    Webアプリケーションセキュリティに関する国際的コミュニティOWASP(Open Web Application Security Project)は、アプリケーションの設計や開発、脆弱性診断などにおいて必要となるセキュリティ要件の検証基準としてASVS(Application Security Verification Standard)を公開しています。最新版のOWASP ASVS v4.0 では、従来に比べて認証に関する記載がいっそう細かくなっています。

    いわく「パスワードの長さを12文字以上にしなさい」「将来パスフレーズに利用できるようUnicodeを受け入れなさい」「ブルートフォースのような認証系攻撃のためにレート制限などの対策をしなさい」等々。そのなかでも目を引くのは、多要素認証とリスクベース認証の推奨です。

    多要素認証とリスクベース認証~ひとつの方法でアカウントを守る時代の終わり

    多要素認証とは、ワンタイムパスワードなどに代表されるトークンや、指紋や虹彩等の生体認証など、IDとパスワードに代表される「あなたが知っているもの」以外の複数の要素(「あなたが持っているもの」「あなた自身の何か」)を用いて行う認証方法のことで、オンラインバンキングや、LINEやGmail等のサービスで使ったことがある読者もいるかもしれません。

    リスクベース認証は、ログインを試みようとしている時刻やIPアドレス、ブラウザなどの情報を元に、そのユーザの通常の行動と照らし合わせて、いつもと異なっていたら、追加の要素による認証を求め確実な本人確認を行う方法です。新しいパソコンを購入した直後に、いつもはIDとパスワードだけでログインできていたサービスが、ショートメッセージでスマホに送られたパスコードの入力を求めるといった事象に遭遇したことがあると思いますが、それがリスクベースの認証の一例になります。

    くり返しますが、これからは、ひとつの手段でアカウントを守るのではなく、複数の手段でアカウントを守ることが普通になります。

    まとめ

    • ブルートフォース攻撃とは総当たりでパスワードを破ろうとするサイバー攻撃で、難易度が低く攻撃ツールも出回っています。
    • 不正アクセスのためにパスワードリスト攻撃やリバースブルートフォース攻撃など、パスワードを破る攻撃は多様な進化を遂げてきました。
    • 強いパスワードの設定、パスワードのハッシュ化とソルトによる不可逆暗号化などはとても大事ですが、それだけでアカウントを守ることは難しい時代になっています。
    • OWASP ASVSの最新版であるv4.0は、多要素認証とリスクベース認証を推奨しています。
    • 多要素認証やリスクベース認証など、これからは複数の手段でアカウントを守ることが普通になります。

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


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

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

    プログラミング言語の脆弱性対策を考える

    Share

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

    プログラミング言語のセキュリティは、組織のシステム全体のセキュリティに大きな影響を与えます。「アプリケーションの脆弱性の半数はC/C++に起因する」という報告もあり、プログラミング言語における脆弱性の特徴を理解し、適切な対策を講じることは、いまや組織のセキュリティに不可欠な取り組みといえます。本記事では、プログラミング言語の最新動向、脆弱性が生まれる背景を解説します。

    プログラミング言語のトレンド

    言語 使用している
    開発者の比率
    JavaScript69.7%
    HTML/CSS 62.4%
    SQL 56.9%
    Python 41.6%
    Java 38.4%
    Bash/Shell/PowerShell 34.8%
    C# 32.3%
    TypeScript 28.3%
    PHP 25.8%
    C++20.5%
    C 18.2%
    Go 9.4%
    Kotlin8.0%
    言語 使用している
    開発者の比率
    Ruby7.5%
    VBA6.2%
    Swift6.1%
    R5.5%
    Assembly4.9%
    Rust4.8%
    Objective-C4.4%
    Scala3.9%
    Dart3.7%
    Perl3.3%
    Haskell1.8%
    Julia0.9%

    Stack Overflow Developer Survey 2020 より弊社作成
    https://insights.stackoverflow.com/survey/2020#technology-programming-scripting-and-markup-languages-professional-developers

    JavaScript、HTML/CSS、SQLなどが上位に並んでいますが、皆さんの予想どおりでしょうか?ちなみに冒頭で述べた、「脆弱性の半数」を生み出すとされるC/C++に関しては、昨今IoTデバイスなどの組込機器やデスクトップアプリケーション等に利用目的が収れんしてきているといわれ、その使用率は減少傾向にあります。また、リストには記載がありませんが、日本に限ってみると、COBOLなどのレガシーシステム向けの言語がいまだ根強いシェアを保っているのはご存じの方も多いことでしょう。

    なお、弊社での診断傾向としては、JavaScriptのほか、Pythonが目立っています。今後については、「オーバーヘッドが少なく、静的型付け言語である」という特徴をもつTypeScriptなどが、軽量さの望まれるサーバレス環境での需要につながるものとみられます。また、Android端末向けにKotlinの需要も高まると予測しています。以下、ご参考に、プログラミング言語と主な利用分野のマッピングを示します。

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

    プログラミング言語の脆弱性 ― 言語ごとに異なる特徴を知る

    プログラミング言語の脆弱性を考える場合、特定の言語に固有のものと、言語間で共通のものを押さえておく必要があります。

    例えば、C/C++では、その脆弱性の7割がメモリハンドリングのミスに起因するといわれており、メモリ関連処理のロジックを正しく制御させ、ソースコード内に脆弱性を作りこまないようにすることが、重要なセキュリティ対策となります。そのほか、言語固有の脆弱性として代表的なものは、Javaでの「安全でない入力に対するデシリアライゼーション」の問題、JavaScriptでの「パストラバーサル」や「暗号」の問題、PHPでの「クロスサイトスクリプティング(XSS)」や「SQLインジェクション」などになります。

    なお、2000年代後半以降にリリース開始された比較的新しいプログラミング言語(Kotlin、Golang、Rustなど)については、上記とは若干が異なる観点からの注意が必要です。まず、こうした言語では、セキュアコーディングのための様々な関数やライブラリなどが用意され、セキュリティに関する手厚い対策が組み込まれているのですが、その一方で、セキュリティの機能が増えれば増えるほど関連ドキュメントが膨大になり、把握が追いつかないという課題が生じています。例えば、Kotlinの場合、Kotlin自体のドキュメンテーションではセキュリティ関連の記述はNULLの安全性に触れる程度なのですが、セキュアコーディングに取り組もうとすると、膨大なAndroid Developer Guideを参照する必要があります。また、相互運用性への配慮も必要です。例えばKotlinやGolangはJavaと一緒に利用するケースが多いため、こうした言語で開発を行う場合には、Java側の環境を考慮したうえでのセキュアコーディングが不可欠になり、それが開発の難易度を押し上げているという状況があります。

    プログラミング言語の脆弱性 ― 全言語に共通の特徴を知る

    続いては、すべての言語に共通する脆弱性です。これは大きく以下の3つに分類できます。

    情報漏洩
    ・表示する必要のない機微な情報(ユーザ名やIDなど)の露呈
    ・不要なシステム情報の公開
    入力検証の不備
    ・不正なパラメータの許容、XSS、SQLインジェクション
    ・HTTPヘッダ分割
    認可・認証関連の脆弱性
    ・オブジェクトやファイルなどへのアクセス認可の不備
    ・認証情報の保護機構や暗号化の不備

    脆弱性が発生する背景

    以上述べてきたような脆弱性は、なぜ発生するのでしょう。その背景には、開発現場における以下のような課題があると考えられます。

    ・プロジェクトベースで人員が変わることが多く、知識や経験の共有が行われることがまれ
    ・脆弱性やセキュアコーディングに対する意識、知識レベルがプログラマによって異なる
    ・ギリギリのスケジュールでプロジェクトが進むことが多く、知識や経験の共有まで手が回らない
    ・セキュリティへの対応が明示的な業務として遂行されるのではなく、プログラマやプロジェクトメンバー1人1人の善意に依存する面が強い

    具体例で説明しましょう。先ほど、PHPではXSSやSQLインジェクション等の脆弱性がよく見られると述べました。しかし、PHPでも、バージョン4以降であれば「htmlspecialcharacters」という関数を利用することでXSSの回避に必要な特殊文字のエスケープ処理ができます。SQLインジェクションについても、プレースホルダの利用による回避が可能です。このように、すでに対策が存在する場合であっても、プログラマ間で知識や経験の共有が行われていない場合、ソースコード診断やステージング環境でのWebアプリケーション脆弱性診断が実施されない限り、脆弱性は放置されることになります。また、「機微な情報の露呈」という問題については、個人情報保護などの法制度に対する知識が共有されておらず、そもそも課題として認識されていないという可能性があります。なお、知識共有のハードルは、セキュリティ機能が充実しているゆえに把握すべき情報量が膨大で、他の言語との互換性等まで含めた配慮が求められる最近のプログラミング言語では、さらに高いといえるでしょう。

    こうした課題を解決するには、プログラマ個人の知識・技術レベルを高めることはもちろんですが、それ以上に重要なのは、組織を挙げての体系的な取り組みであるといえます。

    先手を打った対処がカギ

    そこでぜひ取り入れたいのが、プログラミング言語に関わる脆弱性が生じていないかを、開発の初期段階から継続的に点検する取り組みです。これは「DevSecOps」とも呼ばれる考え方で、「開発(Dev)」・「運用(Ops)」に「セキュリティ(Sec)」の観点を組み込むことで、システムのセキュリティ強化を図るものです。開発プロジェクトは常に時間との闘いですが、だからといって脆弱性への対応を先送りしてはなりません。対処が事後になればなるほど、影響範囲が広がり、コストも肥大する恐れがあります。

    以前の記事でも解説しましたが、何よりも、初期段階からの取り組みが重要です。例えば、人員の流動が激しいプロジェクトベースの現場では、開発の早期からソースコード診断を含むテスト活動を実施し、脆弱性をコード単位で効率的に解消していくことによって、各段階で積み上げられた知識や経験を、後続の工程で活用することが可能になります。また、近年主流になっているアジャイル型の開発手法でもこれは有効で、短い開発サイクルが繰り返される中で早期に・こまめにテストや修正を行うようにすることで、セキュリティを強化できるのみならず、プロジェクト全体の工数も抑制できます。なお、短いサイクルでテストを回すには、SaaSタイプのソースコード診断サービスの利用を検討してもよいでしょう。

    先手を打って脆弱性に対処できれば、脆弱性の要因となっていた様々な課題に取り組む余裕も生まれます。結果として、セキュリティと開発効率をともに高められる好循環を実現できるのではないでしょうか。

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


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

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

    APIのセキュリティ脅威とは

    Share

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

    APIとは、ソフトウェアが相互に機能やデータを利用しあうための仕組みで、機能や開発効率を向上させるなどのメリットがあります。しかしAPIにもセキュリティ上のリスクがあり、セキュリティ対策を怠ったことによる被害も報告されています。今回は、APIの安全な利活用について解説します。

    「API」とは

    「API」とは「Application Programming Interface」の略で、複数のソフトウェアが相互に機能を利用しあうために設けられたインターフェースを意味します。コンピュータプログラムやWebサービスなどをつないで連携させ、さまざまな機能やデータを共有可能にすることで、従来にない価値を生み出せるという点が大きなメリットといわれています。例えば、あるアプリが、特定の機能を持つAPIを利用することで、それまでなかったサービスをユーザに提供できるようになります。

    APIのなかでも広く利用されているのがWebに公開されている「Web API」で、多数のWebサービスやプラットフォーマーが各社のWeb APIを公開しています。身近な例としては、位置情報ゲームで地図情報サービスが提供するAPIを利用するケースなどがあります。

    APIの積極的な活用は、IoTや企業のDX(デジタルトランスフォーメーション)の実践に不可欠と言っても大げさではありません。さまざまなアプリやWebサービスがAPIを通じて相互接続することで、利用者の利便性の向上、経済の活性化など、単独では実現できなかった価値を生み出せるようになります。こうした仕組みのことを「APIエコノミー」と呼ぶこともあります。

    あなたの身近にあるAPIの活用例

    Webサービスなどを利用しているときに「Facebookでログイン」「Googleでログイン」などのボタンを見たことはありませんか? Facebook、Google、Twitterなどで設定したアカウントを使って、別のECサイトなどにログインする「ソーシャルログイン」は、各サービスが公開するAPIを使って実現されています。また、企業などのWebサイトで地図情報がGoogle Mapから呼び出されて掲載されている、あの仕組みもAPIによるものです。

    API活用のメリット

    APIを活用すれば、個別の機能を各サービスで一から開発する必要がなくなるため、開発効率が上がり、コストを抑えることができます。機能を提供する側も、機能を使ってもらうことで自社のブランド力の向上、広告収入といった経済的利益を得られます。また、前出の「ソーシャルログイン」などでは、独自のログイン用プログラムを各企業がそれぞれ開発する場合に比べ、一定のセキュリティ水準を確保できるという効果も期待できます。

    Web APIはWebアプリケーションでどう使われるか

    ここで、「Web API」はいわゆる「Webアプリケーション」でどう使われるのか、少し補足しておきましょう。

    WebアプリケーションがAPIを用いて地図情報だけを外部の地図サーバから取得しているケースについて考えてみます。Webサーバはブラウザからのリクエストを受け、WebアプリケーションからAPIを経由して地図情報を地図サーバにリクエストします。地図サーバはAPIを介して地図情報をWebアプリケーションへ送り返します。それを受けたWebサーバが、地図情報を含めたページ全体をユーザに返します。ユーザから見たときにはAPIを使っているかどうかはわかりませんが、このように、APIは、特定の機能のため、特定の情報のやり取りのために利用されているのです。

    APIのセキュリティの重要性

    Webサービスを利用するユーザ側から見れば、そこでAPIが使われているかどうかは何ら重要なことではありません。しかしサービス提供側から考えた場合、APIにもWebアプリケーション同様、脆弱性をはじめとするさまざまなセキュリティリスクが存在することを忘れてはなりません。また、近年のスマートフォンの普及により、スマートフォンのアプリケーションがAPIを直接利用するケースも増えており、今までサーバ側での利用が主流だったAPIがユーザの手元から直接利用される時代になっている点にも注意が必要です。

    適切なセキュリティ対策を怠った場合のリスクは、むしろWebアプリケーションよりも深刻かもしれません。さまざまなソフトウェアと連携するというAPIの特質から、被害が自社のコントロールの及ぶ範囲を超えて広がる可能性が想定されるためです。

    APIが原因で起こったサイバー攻撃被害

    2018年、米大手SNSが開発者向けに公開していたAPIのバグが悪用され、ログインを行う際のカギとなるデータが盗まれる事件が発生しました。2019年には、大手配車マッチングアプリで、APIが降車時の支払い方法の検証をしないことで、無賃乗車ができてしまうバグが報告されています。

    米大手SNSの事件は、多数のAPIが組み合わされることによって、バグの検出やセキュリティ上の問題の発見が遅れたり困難になったりするという問題をあらわにしたものでした。また、配車マッチングアプリのバグは、APIの入力値を検証することの重要性を改めて気づかせるものでした。

    その利便性から急速に普及が進んでいるAPIですが、「事故やサイバー攻撃被害の発生によって初めて、リスクの存在を認識する」という昨今の状況を踏まえると、セキュリティに関してはまだまだ未成熟な領域であるといえるでしょう。

    「OWASP API Security Top 10」などのリソースを活用して対策を立てる

    こうしたサイバー攻撃被害や事故を受け、今、APIのセキュリティは最重要事項の1つとして取り組まれるようになっています。その大きな成果の1つとして、「API Security Top 10」をご紹介しましょう。これは、Webアプリケーションセキュリティに関する国際的コミュニティOWASP(Open Web Application Security Project )がAPIセキュリティに関する10大リスクを選定・解説したもので、2019年末に公開されました。API固有のセキュリティリスクを把握し、対策を講じるために役立ちます。


    OWASPによるAPIセキュリティ10大リスク

    1.オブジェクトレベルでの許可の不備(Broken Object Level Authorization)
    2.認証の不備(Broken User Authentication)
    3.データの過度な露出(Excessive Data Exposure)
    4.リソースの制限、頻度の制限の不足(Lack of Resources & Rate Limiting)
    5.機能レベルの認可の不備(Broken Function Level Authorization)
    6.一括での割り当て(Mass Assignment)
    7.不適切なセキュリティ設定(Security Misconfiguration)
    8.インジェクション(Injection)
    9.不適切なアセット管理(Improper Assets Management)
    10.不充分なロギングとモニタリング(Insufficient Logging & Monitoring)

    (翻訳:SQAT.jp 編集部)


    上記のような資料は、自組織のAPIセキュリティを点検する際のガイドラインとしてぜひ活用したいものです。さらに、APIを含むWebアプリケーションに対する脆弱性診断サービスを利用して、第三者視点から、自組織のシステムで使用されているAPIのセキュリティを定期的に評価することもお勧めします。

    まとめ

    ・APIとはアプリやWebサービスなどが相互に機能やデータを利用しあうための仕組みです。
    ・API活用には、開発のスピードアップやコスト削減などのメリットがあります。
    ・近年はスマートフォンからAPIを直接利用できるケースも増えており、利用の機会が増えています。
    ・APIにもセキュリティ上のリスクがありますが、様々なサービスとつながるために利用するという性質から、ひとたび事故や攻撃が起こった場合、より広い範囲に影響が及ぶ可能性があります。
    ・APIのセキュリティ対策を怠ったことによるサイバー攻撃被害や事故が報告されています。
    ・OWASP「API Security Top 10 2019」などを参考にAPIのセキュリティ強化に取り組みましょう。

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


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

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

    Webアプリ脆弱性の代表格「クロスサイトスクリプティング」の攻撃事例と対策

    Share

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

    クロスサイトスクリプティング(XSS:Cross Site Scripting)とは、サイバー攻撃に悪用される脆弱性のひとつです。

    この脆弱性を悪用した攻撃の多くが、Webサイトを横断(Cross Site)して行われたためこの名称がつけられました。現在では攻撃類型が増えたことから、必ずしもサイト横断的な攻撃でなくても、クロスサイトスクリプティングと呼ばれることがあります。

    今回は、クロスサイトスクリプティングを悪用したサイバー攻撃の事例やその対策について説明します。

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

    クロスサイトスクリプティングとは、動的にHTMLを生成するWebアプリケーションで、ユーザの操作を介して不正なスクリプトを実行させる(できる)事象を指します。

    クロスサイトスクリプティングの脆弱性には、大きく分けて下記の3種類があります。

    1.反射型
    攻撃者がリクエストに混入させたスクリプトなどが、Webサーバからのレスポンスに含まれる形で実行されるもの

    2.蓄積型
    攻撃者がWebサーバ上に何らかの方法でスクリプトを格納したうえで、被害者がアクセスすることでスクリプトが実行されるもの

    3.DOMベース
    Webサーバ側がスクリプトで動的にHTMLを生成する場合にスクリプトタグを生成してしまうことに起因し、ブラウザ側での処理の際に不正なスクリプトが実行されるもの

    クロスサイトスクリプティング脆弱性が悪用された事件による騒動

    クロスサイトスクリプティングの脆弱性が悪用された被害が多数報告されています。なかでも有名なのは、過去に二つの大手ITサービスで発生した事件です。

    2010年、YouTubeとTwitterで、クロスサイトスクリプティングの脆弱性を悪用した攻撃が相次いで発生、虚偽情報を知らせるポップアップが表示されたり、ユーザが意図しない投稿が繰り返されたりするなど、世界中で騒動となりました。

    Twitterへの攻撃は、ユーザが意図しない投稿を行うもので、見つけた脆弱性がどう動くのか実験したいというちょっとした出来心が攻撃意図に含まれていたと言われています。YouTubeについてはフェイクニュースをポップアップで表示するなどのいたずらに近い内容でした。いずれも被害は軽微で、すぐに気づくことができた点は幸運だったといえるでしょう。

    クロスサイトスクリプティングを悪用した攻撃の本当の危険性と恐ろしさ

    クロスサイトスクリプティング攻撃の危険性

    一方、上記のようないたずら目的ではない攻撃では、正規サイトと全く見分けがつかないフィッシングサイト等へ誘導されたり、ログイン状態の維持のために利用しているCookieなどのセッション情報を盗まれたり、入力した情報(例えばパスワードやクレジットカードの番号やセキュリティコード)が盗まれるといったことが行われます。この結果、アカウントへの不正アクセス、クレジットカード情報・個人情報の漏えい、あるいはクレジットカードの不正利用などが行われることがあります。またスクリプトの実行による任意コードの実行やマルウェア感染といった問題も存在します。このようにクロスサイトスクリプティング脆弱性は悪用された場合に甚大な被害が発生する可能性が高いという点に危険性があるといえます。

    ユーザに被害が出てから発覚することのリスク

    Webアプリケーションを利用するユーザの側では、身に覚えのないクレジットカードへの課金など、具体的な被害が発生するまで攻撃を受けたことにすら気づかないこともあるでしょう。一方のWebアプリケーション開発側・運用側でも、実際にユーザやクレジットカード会社から被害発生を知らされるまで気づかないというケースもあります。

    ユーザ側の視点でみると、「自分が被害に遭ったのに、サイトの運営者が気付いていないなんて」と憤る可能性もありますし、「こんな不完全なサイトを運営するなんて」と不信感を抱く可能性もあるでしょう。クロスサイトスクリプティング脆弱性のあるサイトを運用することはともすればユーザの信頼を損なう結果に結びつく可能性があるのです。

    クロスサイトスクリプティングの発見報告状況

    SQAT.jp を運営する株式会社ブロードバンドセキュリティが行ったWebアプリケーション脆弱性診断の2020年上半期の統計によれば、クロスサイトスクリプティングは、検出される全脆弱性の約5%を占めています。

    冒頭で「Webアプリ脆弱性の代表格」と述べている割にあまり比率が多くない、と感じるかもしれませんが、むしろ古くから警鐘が鳴らされ、対策も公表されているにもかかわらず、新たに作られたWebサービスにも(ステージング環境の診断を含むとはいえ)一定割合存在する点に注目すべきでしょう。

    クロスサイトスクリプティングは入出力制御に関する問題です。したがって金融・保険業界、情報通信産業やECサイト関連等の、「オンラインでの商取引を厳格に行う必要がある業界」「個人情報や決済情報を厳密に扱う必要がある業界」では、クロスサイトスクリプティングを含む入出力制御に関する問題への対策が厳格に行われています。これらの業界では開発段階でのソースコード診断やステージング環境での脆弱性診断などを行って必要な修正を施したうえで本番環境へ移行しているケースが多いのです。

    このように、シフトレフトの考えに基づいて開発中にソースコード診断を行う、開発の最終段階やWebサイトの改修などの都度こまめに脆弱性診断を行うことで、クロスサイトスクリプティングの脆弱性をより早い段階で解消する効果は見逃せないものではないでしょうか。

    クロスサイトスクリプティングの脆弱性を発見し対処する必要性

    以前の記事で紹介した裁判事例では、WebアプリケーションにSQLインジェクション脆弱性を発生させた開発会社に対して、実際に損害を被った企業向けに約2,200万円の損害賠償支払いを命じる判決が2014年に下されています。

    また、2020年6月に公布された改正個人情報保護法においては、サイバー攻撃によって個人情報漏えいが発生した場合でも、被害者個人(本人)と個人情報保護委員会への通知が義務付けられました。違反には最高で1億円の罰金が科され、悪質な場合は社名も公表されます。2022年の施行に先立ち、具体的な運用方法について年内に政令や規則がまとめられる見通しですが、今後、Webサイトを運営する企業の義務と万が一の場合の責任は重くなることが予想されます。

    先にみたように、クロスサイトスクリプティングの脆弱性に気づかず放置することで、フィッシングに悪用されるケースや、不正アクセス、情報漏えいなどさまざまな被害が生じる可能性があります。

    本稿執筆時点の2020年、クレジットカード情報をWebサイト上で盗むためにクロスサイトスクリプティングの脆弱性を悪用する攻撃が問題となっており、現在もクロスサイトスクリプティングが脆弱性の代表格であることに変わりはありません。

    クロスサイトスクリプティングの対策方法

    クロスサイトスクリプティングの脆弱性を生み出さないための対策としては、以下の方法が挙げられます。

    1.JavaScript実行のために埋め込まれる特殊文字を変換して処理(エスケープ処理)することや入力文字種を制限して特殊文字を許容しないといった対策を行う

    2.正規のスクリプトが悪用されないようにするため、処理中に文字列が意図しないスクリプトとして解釈されないようにホワイトリストなどによる検証を行う

    3.DOMベースXSS対策として、DOM操作用のメソッドやプロパティを使用する

    4.Webアプリケーション開発にあたって信頼性の高いライブラリを利用する

    また、Webアプリケーションへの入力値のチェックなどを行うWAF(Webアプリケーションファイアウォール)を用いた防御なども考えられるでしょう。ただしWAFを使った防御では、そもそもの脆弱性を解消するという本質的問題解決をはかることができない点に注意が必要です。

    クロスサイトスクリプティングを脆弱性診断で発見し、適切に対応して利用者の安全を守り、組織の顔であるWebサイトやWebアプリケーションの健全性を維持することは、WebサイトやWebアプリケーションを運営する企業や組織にとって必ず行わなければならない義務といえるかもしれません。

    まとめ

    ・クロスサイトスクリプティングはサイバー攻撃に悪用されるWebアプリケーション等の脆弱性のひとつです。
    ・蓄積型や反射型、DOMベースなどの種類があります。
    ・Webサイト等に悪意のあるスクリプトを混入させることで攻撃を行い、ユーザの情報を盗み出すなどの被害が発生します。
    ・「特殊文字の変換処理」「入力文字種の制限」などの対策実施によって防ぐことができます。
    ・クロスサイトスクリプティングに限らずWebアプリケーションの脆弱性を積極的に発見し対処することは運営者の社会的義務です。

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


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

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

    拡大・高度化する標的型攻撃に有効な対策とは
    ―2020年夏版

    Share

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

    「組織のセキュリティにとって最大の脅威」は何だと思いますか?IPAが毎年公表している「情報セキュリティ10大脅威」で例年第1位にランクインしている「標的型攻撃による機密情報の窃取」ではないでしょうか。「標的型攻撃」は、特定の組織をターゲットに定めた攻撃が行われます。「攻撃者に狙われるものはないからウチには関係ない」とは言えません。ターゲット組織を直接狙う代わりに、ターゲットとなる組織の取引先(サプライチェーン)の中で最もセキュリティの弱い組織を入口にし、侵入を図るケースもあるためです。本記事では、標的型攻撃の特徴、対策のポイントについて解説します。

    手口がさらに巧妙化

    今年に入り、防衛省と取引関係にある超大手企業の情報漏えいが立て続けに明らかになり、世間をにぎわせました。攻撃者は、攻撃の痕跡を消すなどの巧妙な手口を使い、過去数年にわたって標的の組織に潜入を続け、国家防衛に関する機微情報の窃取を行っていたとみられています。こうした、秘匿性の高い情報を狙った高度かつ持続的な攻撃は「APT(Advanced Persistent Threat)」と呼ばれますが、近年のIoTの普及等を背景に、攻撃者は、情報を保有する組織のみならず、その組織とつながりを持つあらゆる関連組織をも標的に含めるようになっています。

    各国で注意喚起

    度重なる情報漏えい事件の発覚で警戒感が強まる中、2020年6月、経済産業省からサイバーセキュリティの強化推進を目的とした報告書が公開されました。内容は、中小企業を含めたサプライチェーン全体のサイバーセキュリティ強化を呼びかけるものであり、昨今のセキュリティ被害の特徴として「標的型攻撃の更なる高度化」「サプライチェーンの弱点への攻撃」「不正ログイン被害の継続的な発生」という傾向が指摘されています。一方、同じく2020年6月、日本と並び、従来サイバー攻撃遭遇率が比較的低いとされていたオーストラリア、ニュージーランドにおいて、組織的と見られる大規模サイバー攻撃が確認され、当局から注意喚起が出されています(下表参照)。オーストラリアでは、同時期に日本企業の子会社におけるランサムウェア被害も確認されており、親会社を最終ターゲットにしたサプライチェーン攻撃につながる可能性も懸念されるところです。グローバル化が進む今日、海外のことだから日本国内とは関係ないと言い切れないという点で、意識の変革も求められます。

    日本 6月12日、経済産業省が昨今の攻撃動向にもとづき、サプライチェーン全体のサイバーセキュリティ対策が急務である旨を注意喚起*2
    ニュージーランド 6月16日、CERT NZ(ニュージーランドCERT)が、リモートデスクトッププロトコル(RDP)、仮想プライベートネットワーク(VPN)などのリモートアクセスシステムを介して組織のネットワークにアクセスするサイバー攻撃キャンペーンに関して注意喚起*2
    オーストラリア 6月19日、ACSC(オーストラリアサイバーセキュリティセンター)が、既知のリモートコード実行を引き起こす脆弱性やスピアフィッシング攻撃を用いた攻撃キャンペーンに関して注意喚起*3

    各国での大規模サイバー攻撃への注意喚起

    攻撃の特徴を知る―ポイントは「侵入」

    2020年現在、標的型攻撃やAPT攻撃は最大限の脅威をもたらす攻撃のひとつであるといえ、あらゆる規模の組織に標的型攻撃、APT攻撃への備えが求められています。対策を立てるには、攻撃の特徴に応じたアプローチをとらなくてはなりません。それを考える上でのキーワードとなるのが「侵入」です。ここでは、攻撃者の視点で「侵入」と「侵入後」の2つのフェーズに分けて対策を考えてみましょう。

    「侵入」前後の攻撃の流れ

    まず、攻撃者が「侵入」前後でどんな手口を用いて攻撃を行うのかを押さえましょう。

    <「侵入」の手法>
    攻撃者は、標的とする組織に、極めて多様な方法で内部への侵入や侵害行為をします。代表的な手法は以下のとおりですが、単一の手口を使うとは限らない点や、巧妙化が進んでいる点に注意が必要です。

    標的型フィッシングメールによるもの
    ・添付ファイルによるマルウェアの投下
    ・偽サイトへ誘導し、認証情報の窃取

    Webアプリケーションなどの公開アプリケーションの脆弱性を悪用するもの
    ・不正アクセス
    ・マルウェアのインストール

    有効なアカウント情報を悪用するもの
    ・VPN、RDP、SSHなどの社内インフラへアクセスできるアカウント情報を悪用した不正アクセス
    ・メール、コラボレーションプラットフォーム等のSaaSのアカウント情報を悪用して不正アクセスを行い、なりすましメールなどへの悪用を行うケース

    リモート環境で使用されるVPN、リモートデスクトップなどの脆弱性を悪用するもの
    ・脆弱性および設定の不備を突いた不正アクセス


    図:侵入の手法(例)


    防御側は、侵入を防ぐための対策をそれぞれの手法に対して講じる必要があります。

    <「侵入後」の手法>
    侵入に成功した攻撃者は、最終目的の達成(例えば、ランサムウェアによる身代金要求、破壊活動、情報窃取やコインマイナーのインストールなど)に向け、継続的に探索・侵害行為を進めます。これは「水平展開(Lateral Movement)」と呼ばれる活動で、マルウェア、リモートアクセスツール、Webシェルなどの不正なツールの使用に加えて、正規のツールや機能をも悪用し、社内インフラ内の他のサーバや機器類への侵入を深めていきます。

    防御側としては、「いかに早期の段階で侵入に気づいて対策を打てるか」が、被害を最小化する上での鍵になります。「侵入後」を想定した対策が何もとられていなかった場合、被害が目に見える形で明らかになった時点で初めてそれに気づき、取り返しのつかない事態を招く可能性があります。

    侵入されることを前提に対策を立てる

    具体的にとり得る対策に関しても、「侵入」「侵入後」の観点から検討していくことができます。「侵入」への対策(「侵入を起こさない」ための対策)を立てるのはもちろんですが、「侵入後」の対策(「侵入は起こりうる」ことを想定した対策)も必須です。

    <「侵入」への対策>
    侵入を防ぐには、防御のための機構を実装すること、外部からアクセスできる箇所に不備がないことを確認することが求められます。防御機構の代表例は、従来であればファイアウォール、Webアプリケーションに関してはWebアプリケーションファイアウォール(WAF)による対策などが挙げられるでしょう。これに加えて、最近では多要素認証の実装が強く推奨されており、実際に導入を検討されている組織も多いのではないでしょうか。また、基本的ではありますが見逃されやすいこととして、公開する必要のないアプリケーション(例:Windowsのファイル共有など)が外部に公開されていないかどうかの確認、不要なアカウント情報の削除などを含むアカウント管理の徹底といった点が挙げられます。

    <「侵入後」の対策>
    防御に関しては、古典的ではありますが、社内環境におけるネットワークセグメンテーションの徹底、不要なアプリケーションの削除・無効化、ユーザ管理の厳格化や特権ユーザの管理の徹底などが有効でしょう。破壊活動のターゲットとなった場合に備えたデータバックアップも重要です。一方、検知については、IDS/IPSによる侵入検知やSIEMによるログ・イベント情報の収集・解析、エンドポイントセキュリティ製品による検知といったものが挙げられます。

    攻撃で実際に用いられた手法を詳細に分類し、緩和策や検知方法を記載した「MITRE ATT&CK®」というナレッジベース/フレームワークを参照すると、攻撃手法に対して緩和策がないケースが散見されます。また、厳格に適用すると運用上大きな負荷となる緩和策も一部にはあります。このため、具体的対策を立てるにあたっては、「防御できる領域はしっかり防御し、防御が難しい領域については検知に力を入れる」といった判断が求められます。

    「侵入」「侵入後」の対策の確認方法

    では、侵入、侵入後に向けた一連の対策によって、適正に攻撃を防ぎ、見つけ出すことができているかどうかを確認するにはどうすればよいでしょう。そこで威力を発揮するのが「ペネトレーションテスト」です。ペネトレーションテストでは、自組織において防御や検知ができていない領域を把握するため、多様なシナリオによる疑似攻撃を実行してシステムへの不正侵入の可否を検証します。ペネトレーションテストの結果は、今後対策を打つべき領域の特定や優先順位付け、対策を実施する前の回避策などの検討に役立てることが出来ます。

    侵入への対策
    目的:システムへの侵入を防ぐ
      侵入後の対策
    目的:侵入された場合の被害を最小化する
    ・多要素認証の実装 ・不要なアカウント情報の削除(退職者のアカウント情報など)
    ・公開サーバ、公開アプリケーションの脆弱性を迅速に発見・解消する体制の構築
    ・VPNやリモートデスクトップサービスを用いる端末
    ・サーバのバージョン管理(常に最新バージョンを利用) ・ファイアウォールやWAFによる防御 など 
      ・社内環境におけるネットワークセグメンテーション
    ・ユーザ管理の厳格化、特権ユーザの限定・管理(特にWindowsの場合)
    ・侵入検知(IDS/IPSなど)、データバックアップといった対策の強化
    ・SIEMなどでのログ分析、イベント管理の実施
    ・不要なアプリケーションや機能の削除・無効化
    ・エンドポイントセキュリティ製品によるふるまい検知の導入
    対策の有効性の確認方法
    ・脆弱性診断
    ・ペネトレーションテスト
      ・ペネトレーションテスト

    「侵入まで」と「侵入後」の対策

    一方、外部からアクセスできる箇所に攻撃の起点に悪用され得る脆弱性や設定の不備が存在しないかどうかを確認することも重要です。その際に有効なのが「脆弱性診断」です。攻撃者はシステムの脆弱性を突いて侵入を試みるため、診断によって脆弱な領域を洗い出し、優先度に応じた対策を講じます。なお、診断は、定期的に実施するだけでなく、システム更改時にも必ず実施することが推奨されます。

    なお、脆弱性診断やペネトレーションテストでセキュリティ事業者のサービスを利用する場合は、診断やテスト後のサポート体制についても事前に確認しておくことが必要です。攻撃者は、日々研究を重ねながら脆弱性を探し出し、手を替え品を替え、攻撃を仕掛けてきます。継続的なフォローアップを行ってくれる事業者を選び、ますます高度化する標的型攻撃に常時体制で備えていくことが求められるでしょう。

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


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

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

    テレワーク環境下における営業秘密の保護

    Share

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

    緊急事態宣言が解除されて1か月余り。通常勤務に戻る企業もあれば、テレワークを存続させる企業もあり、対応はさまざまです。不動産業界の調べによれば、東京都心のオフィスビルの空き室率は2020年3月以来微増しており、テレワークを今後も継続する企業は少なくないようです。

    もともと欧州ではワークライフバランスの立場から在宅勤務(テレワーク)を推進してきました。オランダでは2016年に労働者が自宅を含む好きな場所で働く権利を認める法律が施行されています。フィンランドでも今年1月に同様の法律が施行されました。コロナ禍によってこうした動きは一層加速されており、米国は民間企業主体ではあるものの、やはり大手IT企業を中心に在宅勤務を義務化・恒久化する動きがあります。

    しかしながら、日本においてはテレワークが欧米ほど浸透していません。国土交通省が今年3月に実施した「令和元年度テレワーク人口実態調査」では「会社でないと閲覧・参照できない資料やデータがあった」のは26.8%、また、セキュリティ対策に不安があったのは3.4%とありました。情報へのアクセス整備やセキュリティ対策不備に伴う漏えいへの不安がテレワーク推進の妨げになっていると考えられます。

    テレワークにおける情報漏えいの不安

    テレワークの場合、自宅での「在宅勤務」、出先や移動中に行う「モバイルワーク」、シェアオフィスなどを利用する「サテライトオフィス」のいずれにしても、インターネットを通じて業務データを社外で利用することに変わりありません。また、作業者が使用しているPCに重要なデータをダウンロードして作業する場合、セキュアゾーンで実施されないことも多いでしょう。そこにセキュリティ上の不安があるものと思われます。

    総務省「テレワークセキュリティガイドライン第4版」においても、起こりうる事故として「情報漏えい」「重要情報の消失」を挙げています。確かに、企業が保有する設計図・製造ノウハウ・調査研究データなどの技術的な情報、取引内容・顧客リスト・財務データなどの営業上の情報は、事業存続および競争力強化にとって重要な情報資産であり、漏えいすることによるリスクははかりしれません。こうした懸念から、テレワークへの切り替えを躊躇する向きもあるでしょう。

    そこで、適切にセキュリティを確保して情報流出の不安を解消しながらテレワークを実施できるよう、経済産業省は5月7日、「テレワーク時における秘密情報管理のポイント (Q&A解説)」を公表しています。以下に、そのポイントをみていきましょう。

    「不正競争防止法」により保護される営業秘密(機密情報)

    セキュリティ対策によって保護すべき、企業が保持する「営業秘密」は、一定の要件を満たすことで不正競争防止法の下で保護されます。法的保護を受けることにより、例えば電子データで取り扱われている機密情報がセキュリティの脆弱性を突かれて漏洩した場合でも、差止請求や損害賠償請求などが可能です。このため、事業における金銭的被害や信用失墜といったリスクを軽減できます。

    ただし、営業秘密として法的に認められるためには、対象となるデータに対して以下の条件が整っていることが必要です。

    1.秘密管理性:その情報が秘密であるとわかるように管理されていること
    2.有用性:事業活動に役立つ情報であること
    3.非公知性:世間一般に知られていないこと

    「秘密管理性」の趣旨は、「企業が秘密として管理しようとする対象(情報の範囲)が、従業員等に対して明確化されることによって、従業員等の予見可能性、ひいては経済活動の安定性を確保する」ことにあるとされています。つまり、情報が営業秘密として保護されるためには、「秘密である」こと自体をはっきり示す必要があります。

    「非公知性」は、営業秘密保有者の管理下以外では一般的に入手することができない状態とされています。このため、営業秘密としての条件を満たすには、容易に人に見られたり、聞かれたりしないようにしなければなりません。

    テレワーク環境で営業秘密を保護する対策

    テレワーク環境下で、秘密管理性と非公知性の要件を満たして情報を保護しつつ、情報漏えいを防止するには、状況に応じて以下のような対策が挙げられます。

    状況別 対策の例
    テレワーク対応導入の第一歩 ●営業秘密管理規程、情報取扱規定等をテレワークに即した内容に改訂
    ●諸規程の従業員に対する周知徹底
    ●情報に応じたアクセス権者の設定 等
    業務における情報持ち出しおよび
    社外からのアクセス
    ●データのファイル名や当該データ上に「㊙」(マル秘)・「社内限り」等の秘密であることの表示を付す*4
    ●情報のコピー・持ち出しにおける上長等の事前許可/返却・破棄ルールの周知・徹底と持ち出し記録の整備
    ●紙の資料・PC等を机上等に放置しないといった取扱いルールの徹底
    ●ID・パスワードによるアクセス制限の実施
    ●チャットツールで営業秘密についてやりとりするスレッドと参加者を限定 等
    社外作業 ●PCにのぞき見防止フィルム等貼付の徹底
    ●音声が漏れない場所でのオンライン会議実施徹底
    ●公共無線LANの使用禁止、従業員のポケットWi-Fi・テザリングの禁止、業務使用Wi-Fiの貸与 等
    情報漏えい、不正持ち出しの防止 ●メールの転送・添付制限、送信前の上長承認、上長のCC追加設定
    ●遠隔操作でPC内データを削除できるツールの利用
    ●PCに対するUSB、スマホ接続不可設定
    コピーガード付き記録媒体の利用 等

    営業秘密として秘密管理性要件を満たすと認められる技術的要素

    テレワークにおける情報流出対策として規程を整備し、徹底した従業員教育を行ったとしても、所詮は人間が実施することであるため、悪意の有無にかかわらず、すべてが絶対確実に守られるとは言い切れません。そのため、前述の対策の例にも、技術的に強制するような仕組みがいくつか含まれています。

    アクセス制御と権限管理の徹底

    データ管理における秘密管理性要件については、通常、アクセス制御が実施されていることをもって、「秘密である」ことを示すと見なされています。これは、アクセス制御の基本的な考え方が、当該情報を知るべき者だけが情報にアクセス可能であるべきという「Need to Know」の原則に基づいていることと関係があります。アクセス制御とは、正規に承認されたユーザにのみコンテンツへのアクセスを許可するセキュリティ対策だからです。

    このため、秘密管理性の要件を満たすためには、アクセス制御自体が適正に実施されている必要があります。例えば、同じアカウントを複数の従業員が使い回しているような状態や、パスワードに社員番号をそのまま当てはめていて他人が容易に推測可能な状況の場合、秘密管理措置を講じていないと判断される恐れがあります。

    アクセス制御が「対象へのアクセスそのものを制御する」のに対し、「行為の実行権限を管理する」のが権限管理です。権限管理とは、ログインによってWebシステムやファイルサーバへアクセスするためのユーザを認証するシステムにおいて、各ユーザアカウントの役割を定義し、データに対する閲覧・編集等、実行できる処理についての権限を付与・管理することを言い、当該ユーザに対して必要最低限の権限を付与する「最小権限の原則(Least Privilege)」を適用します。データの重要性や種類に応じて、特定のグループだけが編集権限を持ち、他の従業員には閲覧のみを許可するといった設定です。

    適正なアクセス制御・権限管理のどちらが欠けても「脆弱なシステム」であると言わざるを得ません。

    認証機構の堅牢化

    アクセス制御に欠かせない認証機構ですが、IDとパスワードによる単要素認証は、リスト型ハッキング攻撃等の標的となりやすいため、テレワーク導入・継続に備え、パスワード強度に対するポリシーの見直しをお勧めします。現在、セキュリティの各種基準・仕様においては8文字未満のパスワードは脆弱であるとみなされており、14文字以上のパスワードが推奨されています。流出したパスワードや汎用的で推測容易なパスワードを排除する実装の導入も有効です。

    しかしながら、ユーザにとっては長いパスワードを複数覚えておくのは至難の業であるため、パスワードの使いまわしもなくならないでしょう。これを防ぐには、ID/パスワード以外に、認証要素(指紋や顔等の生体認証、またはワンタイムパスワードトークンやSMS等の所有物認証)を1つ以上追加した、多要素認証の導入をお勧めします。

    この他、データの管理についても注意が必要です。データをUSBやDVDに記録できないようにする、プロジェクト終了後のデータ消去について確認する手段を講じるなどです。

    テレワーク導入・継続における技術的要素について、詳しくはこちらもご参照ください

    法的要件の確認にも有効なセキュリティ診断

    営業秘密として保護されるべき法的要件を技術的な側面で満たしているかどうか確認する有効な手段に、セキュリティ診断があります。営業秘密に当たる情報を扱っているWebアプリケーション、ネットワーク(プラットフォーム)、スマホアプリ、IoT機器等に対し、第三者であるセキュリティ専門企業による診断を受けることをお勧めします。

    先に述べた、アクセス制御や権限管理が適切に導入・運用されているかも、セキュリティ診断によって確認できます。

    自らは気づいていない脆弱性を洗い出して悪用された場合のインパクトを事前に調査し、技術的に対応できること、対応が難しければ法的保護を受けるために講じるべき回避策や代替手段として何を整備しておくべきかを検討するなど、リスク対応策を検討しておくことが事業継続の肝となります。


    参考情報

    ・テレワーク時における秘密情報管理のポイント (Q&A解説)
    https://www.meti.go.jp/policy/economy/chizai/chiteki/pdf/teleworkqa_20200507.pdf

    ・逐条解説 不正競争防止法
    https://www.meti.go.jp/policy/economy/chizai/chiteki/pdf/20190701Chikujyou.pdf


    まとめ

    ・テレワークは緊急事態宣言後も一定の割合で継続される見込み
    ・テレワーク導入・継続における情報流出の不安には、経済産業省による「テレワーク時における 秘密情報管理のポイント (Q&A解説)」が対策のヒントになる
    ・テレワーク環境下でも、会社の重要情報を「不正競争防止法」による法的保護の対象である「営業秘密」として管理することが肝要
    ・適正なアクセス制御と権限管理は営業秘密の秘密管理性要件を満たす技術的なセキュリティ対策である
    ・機密情報を扱うシステムに対するセキュリティ診断の実施は、リスク対策における技術的な対応策と法的保護策の切り分けにも活用できる

    関連情報

    ●<インタビュー>上野 宣 氏 / ScanNetSecurity 編集長

    ●<コラム>「ゼロトラストアーキテクチャ」とは?

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


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

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