SQAT® Security 瓦版

2022年6月9日2022年6月14日

OWASP Top 10
―世界が注目するWebアプリケーションの重大リスクを知る―

2021年9月、4年ぶりに「OWASP Top 10 2021」が公開されました。国際的なセキュリティ啓発コミュニティであるOWASP（オワスプ：Open Web Application Security Project）が、悪用のしやすさ、検出のしやすさ、技術面への影響度などを考慮して重大なリスクを選び出したものになります。「OWASP Top 10」はWebサイトのセキュリティ対策のポイントに、参考にされることが多いガイドラインの一つですが、どのようなセキュリティリスクが挙げられているのかご存知でしょうか？本記事では、OWASP Top 10の各リスクのカテゴリ毎に脆弱性例と対策案をまとめ、最後に弊社視点での脆弱性対策の推奨対策案をご紹介いたします。

「OWASP Top 10」とは

OWASPは、Webアプリケーションセキュリティに関する研究、診断ツールの開発、ガイドラインの発行、イベント開催といった活動を行う国際的なオープンソース・コミュニティです。「OWASP Top 10」は、Webアプリケーションにおいて、重大と見なされるセキュリティリスクを選定し、解説したものです。2003年以降定期的に発行されており、2021年9月、前回の「OWASP Top 10 2017」より4年ぶりとなる「OWASP Top 10 2021」が公開されました。

「OWASP Top 10 2021」を紐解く

では、どういったリスクが最新のTop 10に挙げられているのか、見ていきましょう（以下、「前回」とは、「OWASP Top 10 2017」を指す）。

プロトコルバージョンの対応策や暗号技術の活用方法について、SQAT.jpでは以下の記事でご紹介しています。
こちらもあわせてご覧ください。
「Webサイトのセキュリティ強化を！TLSバージョンアップの対応にむけて」
「暗号技術を安全に活用するために―今、やっておくべきセキュリティ対策―」

セキュアな開発ライフサイクル・CI/CDのセキュリティ対策について、SQAT.jpでは以下の記事でご紹介しています。こちらもあわせてご覧ください。
「Webアプリケーション開発プロセスをセキュアに―DevSecOps実現のポイント―」

脆弱性を悪用した攻撃の脅威

攻撃者にとって、機密を含む様々な情報を取り扱っているWebアプリケーションは宝の山であり、魅力的なターゲットです。Webアプリケーションにおいて、脆弱性が放置されていると、サイバー攻撃の足掛かりとして利用されてしまいます。

脆弱性を悪用された例は、被害者企業の業種、規模を問わず、発生し続けています。被害を受けると、直接的な金銭被害のほか、顧客や取引先の信用失墜等、事業活動に深刻な影響を及ぼす恐れがあります。

SQLインジェクションの脆弱性について、SQAT.jpでは以下の記事でご紹介しています。こちらもあわせてご覧ください。
「SQLインジェクションの脆弱性、企業が問われる2つの責任とは」

設計・開発段階で作りこまれる脆弱性

Webアプリケーションにおけるセキュリティリスクは、もちろんOWASP Top 10ばかりではありません。OWASPほか、NIST、IPAなどが公開している各種セキュリティガイドラインを活用して、Webアプリケーションに脆弱性を作りこまないようにすることが重要です。開発にあたっては、仕様どおり動作しないという欠陥・不具合であるバグの解消はもちろんですが、セキュリティ上の欠陥・不具合である脆弱性にも対処する必要があります。

しかしながら、現実には脆弱性を完全にゼロにしてシステムをリリースするのは、非常に困難であるのもまた事実です。設計・開発の段階で、気の遠くなるような数のセキュリティ脅威、攻撃パターンをすべて検討・想定・対応し切ることは不可能だからです。

つまり、セキュリティを考慮した設計・開発の実施は大前提としつつ、脆弱性は意図せず作りこまれてしまうものであることも認識しておく必要があるでしょう。

脆弱性診断の活用

では、意図せず作りこまれてしまう脆弱性に、どう対処すればいいでしょうか。それには脆弱性診断を実施することが、最も有効な手段の一つと言えます。

脆弱性診断によって、システムにどのような脆弱性があり、どの程度のリスクがあるのか可視化され、その優先度に応じてセキュリティ対策を検討・実施することができます。

なお、弊社では「企業の対策すべき脆弱性入門」と題したウェビナーで、弊社脆弱性診断の検出結果を基に対応緊急度の高い脆弱性について取り上げております。参考にしていただけましたら幸いです。

脆弱性診断を効果的に活用するには、システムの機能や取り扱う情報の重要度に応じて、実施時期や頻度を考慮することも大切です。セキュリティ事情は常に変化しています。日々新たな脆弱性が発見され、サイバー攻撃も巧妙化する一方です。また、何年も前に報告されたのに放置されがちな脆弱性が、改めて悪用されることもあります。健康診断と同様、脆弱性診断も定期的に実施することが重要なのです。

脆弱性対策有効な手段について、SQAT.jpでは以下の記事でご紹介しています。こちらもあわせてご覧ください。
「今、危険な脆弱性とその対策―2021年上半期の診断データや攻撃事例より―」

また、「SQAT^® Security Report」では、セキュリティ事情に関するトピックをお伝えしております。情報収集の一助としてご活用ください。

参考情報：

BBSecの脆弱性診断サービス

弊社では、お客様のニーズに合わせて、様々な脆弱性診断サービスを提供しております。システムの特徴やご事情に応じてどのような診断を行うのが適切かお悩みの場合も、ぜひお気軽にご相談ください。

「毎日/週など短いスパンで定期診断して即時に結果を知りたい」

デイリー自動脆弱性診断「Cracker Probing-Eyes^®」は、脆弱性の検出結果を、お客様側での簡単な操作で、日々確認できます。導入のための設備投資が不要で、コストを抑えつつ手軽に診断できます。世界的なセキュリティ基準をベースにした弊社独自基準を設け、シグネチャの見直しも弊社エンジニアが定期的に行うことで、信頼性の高い診断を実現しております。

「システム特性に応じた高精度な診断をしたい」

対象システムの機能が複雑である、特にミッションクリティカルであるなどの理由により、広範囲かつより網羅性の高い診断をご希望の場合は、弊社エンジニアが手動で実施する「SQAT^®脆弱性診断サービス」をおすすめします。 Webアプリケーション、ネットワークはもちろんのこと、ソースコード診断やクラウドの設定に関する診断など、診断対象やご事情に応じて様々なメニューをご用意しております。

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

2022年4月19日2022年4月19日

Webサイトのセキュリティ強化を！
TLSバージョンアップの対応にむけて

2022年2月より、主要Webブラウザにおいて、TLS 1.0/1.1が完全に無効化されました。これにより、TLS 1.2以上が有効化されていないWebサーバは主要ブラウザからの接続ができなくなるといった影響があります。また、TLS 1.0/1.1を継続利用し続けることで、攻撃者に脆弱性を突かれ、重要情報を窃取されてしまうといったリスクも考えられます。本記事では、影響とリスクをご紹介し、セキュリティ強化にむけ、どのように対応すればよいのかについて、ポイントをご紹介いたします。

WebブラウザでTLS 1.0/1.1が完全に無効化

2022年2月1日、米 Googleがリリースした「Google Chrome 98」より、TLS 1.0/1.1が完全に無効化されました*1。「Microsoft Edge 98」や「Mozilla Firefox 97」といった、ほかのWebブラウザにおいても同様です*2。

2020年上半期には主要なWebブラウザでTLS 1.0/1.1はデフォルトで無効化されており、TLS 1.2以上に対応していないWebサイトへアクセスする際には「安全な接続ではない」旨の警告を示すエラーページが表示されていました*3 。今回のTLS 1.0/1.1の完全無効化はここからさらに進んだ対応で、TLS 1.0/1.1を有効化する機能も削除されました。

WebサイトにおけるTLSの利用状況

2022年1月時点で、世界の人気トップ15万件のWebサイトにおけるTLSのサポート状況は、TLS 1.0が39.3%、TLS 1.1が43.0%、TLS1.2が99.6%、TLS 1.3が51.4％です。

最も普及しているのはTLS 1.2ですが、複数のプロトコルバージョンをサポートしている場合、サーバとブラウザの両者が使用可能なバージョンのうち、新しいものから優先的に使用するのが標準的なTLSの設定です。

最新のブラウザでWebサイトを閲覧する場合、世界の人気トップ15万件のWebサイトへのアクセスの約50％が最新のTLS 1.3を使用することになるでしょう。調査データの範囲では、TLS 1.3への移行が進んでいることがみてとれるため、今後も調査範囲の対象外でも一般的に、暗号化通信はTLS 1.3への移行が進んでいくと考えられます。

また、主要WebブラウザにおいてTLS 1.0/1.1が完全無効化されたことで、TLS 1.1以下のバージョンは、互換性維持目的での使用すらされなくなりつつあります。

【各プロトコルバージョンのサポート状況】

過去の経緯

TLS 1.0/1.1についてはこれまでも、インターネット技術特別調査委員会（IETF）から2018年10月より非推奨と勧告されていました*4https://www.ietf.org/blog/tls13/ 。また、2020年7月に情報処理推進機構（IPA）と情報通信研究機構（NICT）より「TLS暗号設定ガイドライン第3版」が公開されています。さらに、2021年1月には、米国家安全保障局（NSA）より旧TLSプロトコル構成の削除に関するセキュリティガイダンス（Eliminating Obsolete Transport Layer Security (TLS) Protocol Configurations）も発行されています。

【概要】

TLS 1.2に対してはPFS（Perfect Forward Secrecy）を有する鍵交換方式（ECDHE、DHE）を含む暗号スイートのみの使用が強く推奨されています。PFSは、2013年のスノーデン事件をきっかけにその重要性が認識され普及が進んだ暗号化技術です。TLS 1.3では、既定でPFSを有する鍵交換方式のみが採用されており、今後、鍵交換方式が満たすべき標準になると考えられます。

TLS 1.0/1.1を継続使用することによる影響

主要Webブラウザが、TLS 1.0/1.1を完全無効化したことにより、 TLS 1.2以上が有効化されていない場合は主要ブラウザからの接続ができなくなるため、セキュリティが強化されたWebサーバ上でサイトを運用することが必要となります。

攻撃者は、サーバを攻撃するにあたって必ずブラウザを経由するわけではないため、TLS 1.1以下の接続を許容すること自体が危険であり、攻撃者にとって狙いやすいターゲットとなる可能性があります。脆弱性を悪用された場合、通信を盗聴し復号することで重要情報の窃取が可能になるというリスクも考えられます。

TLS 1.1以下の暗号化通信に存在する脆弱性を悪用した攻撃例

BEAST攻撃	SSL 2.0、SSL 3.0およびTLS 1.0 プロトコルに影響を及ぼし、攻撃者はWebブラウザとWebサイトとの間のSSL暗号化、またはTLS暗号化されたセッションのコンテンツを復号することができる*5
ダウングレード攻撃	TLS 1.1以下のプロトコルでは、認証付き秘匿モード等の安全性の高いアルゴリズムがサポートされていないため、強度の低い暗号アルゴリズムを強制的に使用させることができる*6

現在のセキュリティ対策の指標として一般的に用いられる各種国際的標準でも、TLS 1.1以下の継続使用は下記のとおり推奨されていないため、利用している場合には、早急に対策を検討することが求められます。

NIST（National Institute of Standards and Technology、
米国立標準技術研究所）

2018年10月、ガイドライン案公開。2024年1月1日までにTLSを使用するすべての米国政府のサーバでTLS 1.3をサポートすることを提案

PCI DSS（Payment Card Industry Data Security Standard）

2018年6月30日以降、初期TLSを利用しているシステムはクレジットカード業界における監査基準に適合しない
※POS POI環境のように既知の脆弱性の悪用が困難であったり、SSL/TLSをセキュリティコントロールとしては使用していなかったりする等、例外的にTLS 1.1以下が許容される場合がありますが、情報セキュリティのベストプラクティスではTLS 1.1以下のプロトコルバージョンはすべて非推奨とされています。*7

セキュリティ強化にむけた対策のポイント

早急にTLS 1.1以下での接続可否を確認し、接続が可能な場合は対処を実施することが推奨されます。具体的には、TLS 1.1以下は無効（利用不可）とし、TLS 1.3およびTLS 1.2を有効にし、バージョンが新しいものから順に接続の優先度を高く設定してください。

2018年8月には、TLS 1.3が正式リリースされました。以降、TLS 1.3に対応するプラットフォーム等が次々に利用可能になっています。例としては、OpenSSL 1.1.1系（2018年9月）、OpenSSL 3.0系*8（2021年9月）、Java SE/JDK 11（2018年9月）、Java SE/JDK 8バージョン8u261以上*9（2020年7月）や、そのほかにもRed Hat Enterprise Linux 8（2019年5月）が挙げられます。

TLS 1.3のサポートにより、パフォーマンスとセキュリティが向上します。TLS 1.3を利用するメリットと導入時の課題については、下表のとおりです。構成上または仕組み上、現時点ではTLS 1.3を実装することが困難な場合、上記よりさらに古いシステムが稼働している可能性が考えられます。それらのシステムは、経年に伴う脆弱性の蓄積による影響や、サポート終了により新たに発見された脆弱性への対応策がなくなること等も危惧されます。

TLS 1.3を利用するメリットと導入時の課題

各種ガイドラインの紹介

PCI DSSについては、 2022年3月31日、Payment Card Industry Security Standards Council (PCI SSC)により、v4.0が公開されました。 *10https://www.jcdsc.org/pci_dss.php

また、上段でも触れた「TLS暗号設定ガイドライン第3版」における第2版からの改訂のポイントについては、こちらの記事でまとめてご紹介していますのであわせてご覧ください。
「TLS暗号設定ガイドラインがアップデート～TLS 1.0/TLS 1.1は完全に非推奨へ～」

本ガイドラインは、各種国際的標準（NIST SP800/PCI DSSv4.0/OWASP ASVS等）の準拠に向けた取り組みや、暗号設定における今後のセキュリティ対策を検討する上でも役に立ちます。ぜひ参照されることをおすすめします。

弊社のネットワーク診断サービスでは悪意ある第三者の視点で、ネットワークをインターネット経由またはオンサイトにて診断し、攻撃の入口となる可能性のある箇所を検出します。検出された問題点に対しては、各種国際標準や最新の脅威動向を踏まえて深刻度を評価し、推奨対策と合わせてご報告いたします。システムの導入・変更・アップグレード時、運用中のシステムの定期チェックにご活用いただけます。

また、デイリー自動脆弱性診断サービスでは、内部ネットワークおよびWEBサイトの脆弱性を毎日自動診断し、その結果を専用のWEBページで報告します。新規設備投資が不要で、即時に結果を確認できるので、脅威が現実となる前に対策を施すことが可能になります。

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

2022年3月15日2022年3月16日

Emotet再来！マルウェア感染被害をどう防ぐか

マルウェア「Emotet」の感染が、今年3月より急速に拡大しています。主な手口はメール攻撃ですが、過去の流行時に中心となっていた不特定多数に対するばらまき型でなく、特定の企業・組織を狙った標的型攻撃ツールとしての手法に進化しています。本記事では、これまでのEmotetの攻撃活動を整理したうえで、企業・組織がマルウェアの被害を防御・最小限にとどめるためにどのような対策をとればよいのかについて、解説していきます。

悪名高きEmotetが帰ってきた！

2021年11月、”世界で最も危険なマルウェア（world’s most dangerous malware）”と称された「Emotet」の活動再開が、明らかになりました。*11

Emotet興亡の様相は、おおむね右年表のとおりです。2019年から2020年にかけて、国内でも多くの企業・組織が被害を受けました。2021年1月に一度終焉を迎えた様子については、「ランサムウェア最新動向2021―2020年振り返りとともに―」でも取り上げました。

一網打尽にされたはずだったEmotetの復活には、マルウェアボットネット「TrickBot」が関係していると見られています*2 。以前TrickBotに感染したシステムに対してEmotetをインストールすることで、再び感染開始が可能になったと報告されています。こうしたTrickBotとEmotetの補完関係を利用した復活は、一部の専門家は予想済みの展開だったようです。

復活したEmotetの脅威は…

再開が観測されて以後、2018～2020年に発生したような大規模なスパム送信攻撃は、2021年12月では報告されていません。しかしながら、巧みに不正の痕跡を隠ぺいするといった、Emotetのマルウェアとしての有能さを考慮すると、深刻な脅威であることに変わりはありません。TrickBotに類する攻撃に有効な新しいボットネットの登場も予想されるため、引き続き警戒が必要です。

実際、IPA（独立行政法人情報処理推進機構）によると、活動再開が確認されてから、Emotet攻撃メールと見られる着信が複数観測されています*3 。また、警察庁の解析によると、攻撃対象のメールソフトとして、これまで知られていたOutlookのほか、Thunderbirdのようなオープンソースのメールソフトにも対象が拡大している*4とのことです。

主な感染経路：メール添付ファイルにご注意！

Emotetの主要な手口は、メール攻撃です。2020年にNICT（国立研究開発法人情報通信研究機構）は同機構宛に届いたEmotet攻撃メールには、「doc ファイル添付型」「URL記載型」「zipファイル添付型」が見られた*5という分析結果を公表しました。2021年には、IPAに寄せられた相談事例から、新たな手口として「Excelファイルの悪用」と「PDF閲覧ソフトの偽装」が紹介*6されています。

メールを感染経路としたEmotetの動作概要は下図のとおりです。

メールによるEmotetの感染後の影響 — 出典：「Emotetの解析結果について」（警察庁 @police）https://www.npa.go.jp/cyberpolice/important/2020/202012111.html

感染防止のためにユーザが実践すべき注意事項の基本は変わりません。確実に信用できるメール以外は、メールに添付されたファイルを開かない、編集しない、そして「コンテンツの有効化」ボタンをクリックしないこと。また、メール本文に記載されたURLリンクを不用意にクリックしないこと、たとえクリックしてしまった場合でも遷移先のサイトでデータの閲覧やダウンロードを行わないこと、といった内容になります。

Emotetの感染、関連するネットワークへの感染拡大、ランサムウェアをはじめとした別のマルウェアへの感染……といった深刻な被害の連鎖を生んでしまうか否か、受信者の行動が明暗を分けます。

注意するだけでは防げない巧妙なメール攻撃も…

被害相談例の図（IPA） — 出典：IPA（独立行政法人情報処理推進機構）
「Emotet（エモテット）」と呼ばれるウイルスへの感染を狙うメールについて」（2021年12月9日）
https://www.ipa.go.jp/security/announce/20191202.html

今時そんな見え透いたメール攻撃にはひっかからない、と思われる方もいらっしゃるかもしれません。確かに、ばらまき型メール攻撃なら、うっかり開けることはないという方も多いでしょう。しかし、標的型攻撃の場合はどうでしょうか。どう見ても取引先からとしか思えないような、絶妙なタイミングと巧妙な内容で偽装されたメール攻撃を受けることがあります。

右図は実際にIPAに2021年12月に寄せられた相談例だそうです。このようなケースでは、いくら注意しても完全に防ぎきることが難しいのが現実です。

マルウェア対策は組織一丸で

以上のような状況を踏まえ、企業・組織がEmotetをはじめとしたマルウェアの被害を防御、あるいは最小限にとどめるためにはどのような対策を講じるべきでしょうか。以下のような例が挙げられます。

マルウェア対策のモデルケース

限りある予算と時間の中で、すべての対策を講じることは困難なので、それぞれの企業・組織の現状に応じて取り組む必要があります。

自企業・組織の位置づけに応じて、今取り組むべき具体的な対策を見つけるには、例えば、右図のようなマルウェア対策のフェーズの視点で検討してみるとよいかもしれません。

スパムメールに対する従業員の知識が全くない組織であれば、標的型メール訓練を行ってリテラシーの向上を図ることから始めるといいかもしれません。従業員教育は行っているけれども、技術的な対策はウイルス対策ソフトを導入しているのみという組織であれば、感染してしまった場合にどのくらいの被害を受けるか調査してみると、優先的に実施すべき対策を検討する糸口となることでしょう。あるいは、メールセキュリティサービスをすでに利用しており、不正アクセス対策にもある程度自信があるという組織であれば、そういったセキュリティ対策が本当に有効に機能しているか、ペネトレーションテストのようなサービスを利用して実際に確認してみることをおすすめします。

マルウェア対策の回答は1つではなく、多層防御がカギとなります。マルウェア課題の解消をお手伝いする、BBSecご提供サービスの一部をこちらにご紹介します。

Emotetご相談窓口開設中！

BBSecでは急増するお問い合わせに対し、Emotet専用ご相談フォームをご用意しています。何かおかしい、気になる、そんな時はすぐご相談ください。

標的型攻撃メール訓練サービス

https://www.bbsec.co.jp/service/training_information/mail-practice.html
※外部サイトへリンクします。

ランサムウェア対策総点検

https://cr.bbsec.co.jp/ransomware
※外部サイトへリンクします。

SQAT^® ペネトレーションテスト

「ペネトレーションテスト」では実際に攻撃者が侵入できるかどうかの確認を行うことが可能です。「ランサムウェア総点検」で発見したリスクをもとに、実際に悪用可能かどうかを確認いたします。

【シナリオ例】疑似マルウェア連携

https://www.sqat.jp/sqat-penetration-test/

IPA情報セキュリティ10大脅威にみるセキュリティリスク―内在する脆弱性を悪用したゼロデイ攻撃とは―

修正パッチが公開される前に、パッチ未適用な状態のソフトウェアやアプリの脆弱性を悪用するゼロデイ攻撃。その脆弱性の数は2021年の年間で前年比約2倍というデータもあることから、警戒が必要になってきています。ゼロデイ攻撃は完全に防ぎきることはできませんが、いまできうる対策としてはどのようなものがあるのでしょうか。本記事では、ゼロデイ攻撃の概要と直近のApache Log4jの脆弱性について紹介しつつ、最善策としてとりうる備えと対策についてご案内いたします。

「情報セキュリティ10大脅威 2022」に
新たに「修正プログラムの公開前を狙う攻撃（ゼロデイ攻撃）」がランクイン

2022年1月27日、独立行政法人情報処理推進機構（IPA）は毎年発表している「情報セキュリティ10大脅威」の2022年版を発表しました。そのうち、「組織」における脅威の注目すべき点として、昨年8位だった「インターネット上のサービスへの不正ログイン」に替わるかたちで、新たに「修正プログラムの公開前を狙う攻撃（ゼロデイ攻撃）」が7位にランクインしていることがあげられます。

IPA情報セキュリティ10大脅威（組織編） — 出典：独立行政法人情報処理推進機構（IPA）「情報セキュリティ10大脅威 2022」（2022年1月27日）組織向け脅威
https://www.ipa.go.jp/security/vuln/10threats2022.html

ゼロデイ攻撃の増加（グラフ） — 出典：ZER0-DAY.cz tracking project「Zero-day vulnerability 2006-2022(comparison)」

ゼロデイ攻撃
修正プログラムが提供される前の、修正パッチ未適用なソフトウェアやアプリの脆弱性（ゼロデイ脆弱性）を悪用した攻撃。2021年は前年と比較して、ゼロデイ脆弱性が約2倍に増加したとするデータもあり、警戒が必要である。ゼロデイ攻撃の場合、修正プログラムが提供された時点ですでに攻撃が行われているため、脆弱性対策に加え、外部からの侵入を検知／防御する機器を導入するなどの備えが重要となる*7

Apache Log4jの脆弱性

特にインパクトが大きかった修正パッチ未適用の脆弱性として、2021年末に話題となったApache Log4jの脆弱性（Log4Shell）があります。常に新しい攻撃手法を探求し続けている攻撃者たちは、すぐにこの重大な脆弱性を悪用し始めました。そして、12月から1月にかけて、Log4Shellを悪用した攻撃として、仮想通貨採掘マルウェアや「Mirai」などのボットネットやバックドアでの悪用、さらには「Conti」などのランサムウェアグループによる攻撃転用が確認されています。

Log4Shell
Javaのログ出力ライブラリであるApache Log4jの深刻な脆弱性。悪用された場合、任意のコードをリモートから実行される恐れがある。すでに世界中で大規模な脅威を及ぼしており、IPA等からもアラートが発表されている。Apache Log4jは広く使われているJavaのログ出力ライブラリであるため、本脆弱性は影響範囲が非常に大きいことが特徴となる。Javaの普及度合いについて情報セキュリティ会社の米Cybereasonは「Apacheソフトウェア財団製プログラムは世界のWebサーバの3分の1が使っている」*2としている。

Log4Shellへの備え
Log4Shellの影響範囲は非常に広いため、2013年以降にリリースされているシステムやソフトウェアなどでJavaを利用している場合は、影響を受けている可能性を前提に対応することが望まれる。影響を受ける製品情報についてはNCSC-NL（オランダ国家サイバーセキュリティセンター）が、GitHubに影響有無を公開しているので、それを参考にするのも有効である。またLog4Shell関連の情報は変化が早いことも特徴である。今日対応できていたものが、明日には対応できていない可能性もあるため、しばらくのあいだ情報収集を欠かさず、影響を受ける製品を使用している場合は、ベンダ情報にしたがってアップデートやワークアラウンドを実施するなどの対策が必要である。情報収集の際には、最新情報をベンダやJPCERT/CC等の信頼できる機関のソースを参照してもらいたい。

Log4Shellを悪用したマルウェアによる攻撃事例

①　仮想通貨マイナーをインストールするマルウェア「Kinsing」による攻撃
　　PCにインストールされてしまうと、個人情報を盗み取られるだけでなく、
　　CPUやメモリの計算リソースを勝手に使い込まれ、端末の処理速度を低下させ、
　　最終的に故障させてしまう恐れがある *3
②　新たなランサムウェアファミリー「Khonsari」による攻撃
　　WindowsのCドライブを除くすべてのファイルが暗号化され、開封しようとすると、
　　身代金支払い要求の記載されたメモ帳が開かれてしまう*4
③　ランサムウェアファミリー「Conti」による攻撃
　　VMware vCenter Server標的にした攻撃において、初期アクセスで侵入されたのち、
　　Log4shellによって、ネットワーク上でランサムウェアを横展開されてしまう*5

ゼロデイ攻撃への対策と備え

サイバー攻撃は近年ますます洗練化・巧妙化しています。また、それに応じて日々新たな脆弱性が発見されており、いつ・だれが攻撃のターゲットになってもおかしくありません。そんな中、増加の兆しを見せているゼロデイ脆弱性を悪用した攻撃は、内在する脆弱性を狙った攻撃のため、実際に攻撃され、インシデントが起こってからでないと自組織のシステムが攻撃されていること自体に気づきにくいという特性があります。

では、この攻撃による被害を未然に防ぐために、どのような対策をとればいいのでしょうか。重要なポイントは、「自システムの状態を知り、必要な対策をとる」ということです。ゼロデイ攻撃は完全に防ぎきることは難しい攻撃です。しかし、事前に対策することで、被害をあってしまった場合の被害を小さくすることは可能です。これにはまず、基本的なセキュリティ対策の実施をすることが前提となります。脆弱性の最新情報を収集し、セキュリティ更新プログラムのアップデートを行うことをはじめ、マルウェア対策にはEDR（Endpoint Detection and Response）による監視も推奨されます。組織の端末を24時間365日体制で監視し、インシデント発生時の初動対応まで実施できるようにしましょう。そのうえで、原因や侵入経路、被害状況などを把握することで、実際に被害にあってしまった場合でも、被害を最小限にすることが可能となります。

Webサイトの脆弱性対策について、SQAT.jpでは以下の記事でご紹介しています。こちらもあわせてご覧ください。
「中小企業がサイバー攻撃の標的に！Webサイトのセキュリティ対策の重要性 ―個人情報保護法改正のポイント―」

Log4Shellなどの深刻な脆弱性を検知するためには、企業等が提供する脆弱性スキャンツールを使用し、リスクを可視化することも重要です。また、安全性を維持するために定期的に診断を実施することも考え方の一つです。これにより、日々変化する脅威に対するシステムのセキュリティ状態を確認できるため、適時、適切な対策を実施することが可能となります。信頼できるセキュリティベンダ・専門家のサポートを検討するとよいでしょう。

BBSecでは

当社では以下のようなご支援が可能です。

脆弱性を悪用した攻撃への備え～自システムの状態を知る

本記事で紹介した「Log4Shell」のような脆弱性は日々新しい脆弱性や関連するアップデートが確認されています。こうした状況の備えとして、BBSecが提供する、デイリー自動脆弱性診断「Cracker Probing-Eyes^®」では、シグネチャの見直しを弊社エンジニアが定期的に行っており、ツール診断による脆弱性の検出結果を、お客様側での簡単な操作で、日々確認、即時に適切な対応をすることが可能になります。新規設備投資不要で、コスト削減にもつながります。

弊社診断エンジニアによる、より広範囲で網羅的な診断を検討している方は、手動で診断する、「SQAT^®脆弱性診断サービス」がおすすめです。

攻撃を受けてしまった場合の対策の有効性の確認

完全に防ぎきることは難しくても、「攻撃・侵入される前提の取り組み」を行うことで、攻撃を受けてしまった場合にも被害を最小化する対策をする、「多層防御」が重要です。詳しくは「APT攻撃・ランサムウェア―2021年のサイバー脅威に備えを―」をご確認ください。

「SQAT^® ペネトレーションテスト」では実際に攻撃者が侵入できるかどうかの確認を行うことが可能です。「ランサムウェア対策総点検」で発見したリスクをもとに、実際に悪用可能かどうかを確認いたします。

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

2022年2月4日2022年2月21日

既知の脆弱性こそ十分なセキュリティ対策を！

SQAT® 情報セキュリティ瓦版 2019年10月号
※外部サイトにリンクします。

サイバー攻撃が経年とともに進化を遂げていることにもはや疑う余地はありません。しかし、我々ユーザ側はどうでしょうか。「複雑さはセキュリティの敵」といわれる中、ますます複雑化するIT環境において求められている対策も多様化しています。日々様々な脆弱性が報告されていますが、三大脆弱性は「無知」「怠慢」「過信」であると考えます。「知る」「動く」そして「疑う」ことで、見えざる敵から情報資産を守りましょう。

増加するデータ漏洩事故

データ漏洩、Webサイト改竄、マルウェア感染、サービス運用妨害（DoS／DDoS）等、サイバー攻撃はとどまることを知らず、被害件数は増加する一方です。脆弱性情報やデータ漏洩事故に関する市場調査およびリスク評価などを専門とするRisk Based Security社の統計によれば、2019年1月から10月現在までに発生したデータ漏洩事故は約5,000件にも及び、漏洩したデータ件数は約75.6億件で、現在もその数は増え続けています。*6

同社より発行された最新の統計レポート『Cyber Risk Analytics 2019 MidYear QuickView Data Breach Report』*2 をみると、2019年上半期に発生したデータ漏洩事故件数は、過去8年間で最も多いことが分かります。（下記、図2参照）

最近では、NoSQLや全文検索システムにおいて立て続けにデータ漏洩事故が発生しています。2019年8月上旬に報道された、国内の企業で起きた従業員に関するデータ漏洩事故が記憶に新しいところかもしれません。2019年7月から8月の2ヵ月間において、NoSQLサーバであるMongoDB、またはNoSQL/全文検索システムであるElasticsearchを使用している環境で発生した主なデータ漏洩事故・事件の一覧をまとめました。（表3参照）

設定不備が問題に

ここで誤解しないでいただきたいのは、これらデータ漏洩事故・事件はMongoDBやElasticsearch自体に問題があったのではないということです。問題は、NoSQLサーバや全文検索システムをデフォルト設定のまま利用していたことにあります。例えば、MongoDBやElasticSearch、またシェアの高いApache Cassandra、Apache Solrでは、いずれもデフォルトで認証設定が無効です。これはNoSQLがユーザデータベースのような構造化データを扱うものとは区別され、元来非構造化データを集積する目的で使用されてきたことが背景にあると推測されます。外部から参照される可能性が低いものとして捉えられてきた非構造化データを取り扱うため厳密な認証は不要、というのがNoSQLの開発者の認識だったのではないでしょうか。中でもElasticsearchは以前、認証機構を別モジュールとして有償販売をしていました。外部からアクセスされることは極めて稀なケースであるという認識だったからこそ、別モジュール扱いにしていたのでしょう。このような背景を考えると、ユーザが「なんとなく」「うっかり」認証設定をしていなかった可能性は十分考えられます。しかし、2019年5月からElasticsearchが認証を本体の機能として追加したことや様々なデータが格納されるようになったこと等を鑑みると、認証設定を「うっかり忘れた」や「必要だと思わなかった」では済まなくなります。

ではなぜ、最近になって頻繁にMongoDBやElasticsearchのデータ漏洩事故が取り上げられるようになったのでしょうか。一つの要因として、クラウド環境に導入しやすいという点があります。

実際、検索エンジンの「SHODAN」によると、AWS（Amazon Web Services）やDigitalOcean、Microsoft Azure、Google Cloudなどで多くのインスタンスが公開されていることを確認できます。クラウド環境に構築し、そこにオンプレミス環境からデータを移行した際、「うっかり」認証を設定し忘れたなどの理由で第三者にアクセスされる機会を増やしてしまったケースもあるでしょう。また、昨年秋ごろから多くのセキュリティ研究者が認証のないNoSQLや全文検索システムを発見する、一種の“ブーム”が到来していることも原因の一つとなっています。当社の脆弱性診断でも、認証設定のないElasticsearchやApache Solrを何度か検出しています。

定期的な対策と設定の見直しを

問題なのは認証設定だけではありません。出荷時／インストール時のデフォルト設定のまま確認もせずに運用することも、セキュリティのベストプラクティス（最善策）として推奨されません。利用可能なセキュリティ設定は適用する、不要なサービスポートは閉じる、悪用されうるサービスポートに対しては強固なアクセス制御を行う、といった基本のセキュリティ対策を講じるべきでしょう。ちなみに、同じ非構造化データを扱うSplunkにおいては、デフォルトでいくつかのセキュリティ設定が有効化されています。オープンソースと商用ソフトウェアで、コスト、運用保守、互換性など様々な面でメリット・デメリットがありますが、いずれにしても言えることは、自組織の資産に対して、オンプレミスかクラウド環境かに関わらず、定期的な棚卸しとアップデート、設定の確認、脆弱性診断などを通じて、不要なものや対処が必要なものがないかを常に把握しておくことが重要です。

NoSQLや全文検索システムに関するデータ漏洩事故について調査し、設定に問題のあるシステムを数多く発見、報告しているセキュリティアナリストのBob Diachenko氏は、とあるインタビューでこの問題について今後の展望を聞かれた際、利用者の意識改革が鍵であると答えています。*3

色々な顔を持つクリックインターセプション

サイバー攻撃は日々繰り広げられていますが、毎回脆弱性が新たに発見されているとは限りません。以前からある脆弱性を利用して、手口だけを進化させているケースも多々あります。先般、「クリックインターセプション」に関するホワイトペーパーが公開されました。これは、2019年8月中旬に米国カリフォルニア州で開催された、大学の研究者などが研究成果を発表するアカデミックカンファレンス「USENIX Security ‘19」において、香港中文大学、ソウル国立大学、Microsoft Research、ペンシルバニア州立大学の研究者らによって共同研究されたクリックインターセプションに関する研究・調査結果をまとめたものです。*4

もしかすると「クリックインターセプション」という言葉には耳慣れないかもしれません。これはサイバー攻撃の一種で、Webサイト内のリンクやボタンなどをクリックして遷移する先が第三者のページになるようURLを差し替える攻撃です。これまでユーザのクリック操作を利用した攻撃については、Webページの透過表示機能などを悪用した視覚的な騙しの技法が「クリックジャッキング」という名称で広く取り上げられてきました。しかし、ユーザのクリック操作を利用した攻撃はそれ以外にも様々なものがあり、悪質な第三者のJavaScriptによって引き起こされる、あらゆる種類のクリックインターセプションを取り上げたのが今回の研究です。この言葉自体は新しいものではなく、大きく分けて以下の3つのタイプがあります。

①ハイパーリンクを利用したクリックインターセプション
②イベントハンドラ2)を利用したクリックインターセプション
③視覚的な騙しを利用したクリックインターセプション

いずれの場合も、Webサイトの利用者が何らかのクリック操作を行うことで、第三者の用意した悪意のあるページに遷移させられ（視覚的に判断できるかできないかは別として）、機密情報を奪取されたり、マルウェアに感染させられたり、あるいはアドフラウド（広告詐欺）に加担させられたりといった様々な被害を受けます。

今回の研究で、研究者らは「Observer」と名付けたWebサイトにおけるクリックに関する挙動を確認するツールを作成し、Alexaアクセス数ランキングの上位250,000のWebサイトのTOPページを調査しました。その結果、613のWebサイトにおいてクリックインターセプションに該当する事象が確認されています。また、①を実行する新たな手口として、巨大なハイパーリンク3) を埋め込み、Webサイトを訪問した利用者がクリックを余儀なくされるように仕込んだものが発見されたとのことです。

前述のとおり、クリックインターセプションは金銭的利益を得る目的で利用されることもあります。特に最近では、クリックインターセプションがアドフラウドの新たな手口の一つになりつつあります。アドフラウドは広告業界にとって深刻な問題であり、広告主は多大な金銭的被害を受ける恐れがあります。2019年8月初旬、Facebookが、同社の広告プラットフォームを利用して不正な広告収入を得たとしてアプリの開発者を告訴した事件が報道されました。これもクリックインターセプション攻撃の一種で、Google Playストアからアプリがダウンロードされる際に端末をマルウェアに感染させ、ユーザに気づかせずにアプリ内の広告のクリックを発生させる仕組みになっていたとのことです。これにより、あたかもユーザが自身の意思で表示される広告をクリックしているように見せかけ、不正に広告収入を得ていたとFacebookは説明しています。*5

十分なセキュリティ対策を

本稿で取り上げた脆弱性は、どれも新しいものではありません。攻撃手法は進化していますが、その元となる問題は十数年前から存在するものです。しかし、未だ対策されていないシステムが多く存在しているのが実情です。当社の脆弱性診断では、こうした既知のセキュリティ上の問題を検出し、それに対するリスク分析と問題を解消するための対策案をご提示いたします。自組織の資産のセキュリティ状況の把握、定期保守などを目的に、各種法令や基準に則って、脆弱性診断を継続的に活用されることをおすすめいたします。

注：
1) 訳：tl;dr –マニュアルを読みなさい、そして面倒がらずに行動しなさい！（※「tl;dr」が何か分からない場合は検索してみてください。「知る」「動く」「疑う」を実践しましょう。）
2) JavaScriptで記述された、マウスの動きなどの操作に対して特定の処理を与える命令のこと
3) 例として、ページの広い範囲を埋めつくすようなバナーなど

2021年12月8日2021年12月16日

ランサムウェア攻撃に効果的な対策
‐セキュリティ対策の点検はできていますか？‐

これまでSQAT.jpの記事においても何度か取り上げている「ランサムウェア」ですが、攻撃パターンが変化し、なお進化を続け、その被害は国内外ともに2020年よりも増加傾向にあります。いまや完全に防ぐことが難しいランサムウェア攻撃に有効な対策としておすすめしたいのが、「攻撃・侵入される前提の取り組み」です。本記事では、ランサムウェア攻撃の拡大理由を探りながら、企業・組織が行うべき「ランサムウェア対策の有効性検証」について解説します。

現在のランサムウェア事情

海外レポートにおけるランサムウェア事情

2021年10月、米財務省金融犯罪取締ネットワーク（FinCEN）は2021年1月～6月におけるランサムウェア攻撃についてのレポートを発行しました。サイバー犯罪は政府全体で優先的に取り組むべき課題であるとしている中で、特にランサムウェアに関しては懸念される深刻なサイバー犯罪であると強調されています。

FinCENがランサムウェアをそのように注視している背景として、各金融機関から報告された2021年上半期のランサムウェアに関する不審な取引報告数が、2020年の１年間の合計件数よりもすでに多い状態であることや、ランサムウェア攻撃関連の取引総額も2020年の合計額よりもすでに多いことをレポートに挙げています。

出典：Financial Crimes Enforcement Network
「Financial Trend Analysis – Ransomware Trends in Bank Secrecy Act Data Between January 2021 and June 2021」（2021/10/15）

これまでのバックナンバーでも触れてきましたように、ランサムウェアは変遷が激しく、日々新種や亜種が生まれ、大きな勢力を持っていたものですら、すぐに入れ替わってしまいます。

2020年以降のランサムウェアの変貌について、SQAT.jpでは以下の記事でご紹介しています。
こちらもあわせてご覧ください。
「変貌するランサムウェア、いま何が脅威か―2020年最新動向―」
「ランサムウェア最新動向2021―2020年振り返りとともに―」
「APT攻撃・ランサムウェア―2021年のサイバー脅威に備えを―」

このようにランサムウェアがRaaSとしてビジネス化している中で、依然として攻撃件数や被害総額は増えており、ランサムウェアの種類の移り変わりの激しさを見ても、活発な市場であることがわかります。

国内レポートにおけるランサムウェア事情

次は日本国内における最近のランサムウェア攻撃事情もみていきましょう。2021年9月に警察庁が公開した「令和３年上半期におけるサイバー空間をめぐる脅威の情勢等について」によると、ランサムウェア攻撃による被害が多発している中で、昨今のランサムウェアは下記のような特徴があるとしています。

二重恐喝（ダブルエクストーション）	データの暗号化だけでなく、窃取したデータを使って「対価を支払わなければデータを公開する」などと二重に金銭を要求する手口
標的型ランサムウェア攻撃	特定の個人や企業・団体を狙って、事前にターゲットの情報を収集し、より確度の高い攻撃手法で実行する攻撃
暗号資産による金銭の要求	身代金の支払いを暗号資産で要求する
VPN機器からの侵入	従来は不特定多数を狙って電子メールを送る手口が一般的だったが、現在はVPN機器からの侵入が増えている

出典：https://www.npa.go.jp/publications/statistics/cybersecurity/data/R03_kami_cyber_jousei.pdfより弊社作成

同報告書によると、2021年上半期に都道府県警察から報告があった企業・団体等のランサムウェアの被害件数は61件であり、前年下半期の21件と比べると大幅に増加しました。被害を受けた企業・団体等は、大企業・中小企業といった規模や業界業種は問わずに被害が報告されている状況です。表でご紹介した昨今のランサムウェアの特徴である二重恐喝は、手口を確認できた被害企業のうち77%で実施され、また暗号資産による支払い請求は90%にもおよびました。

さらにランサムウェアの感染経路に関してもVPN機器からの侵入が55%で最も多く、次いでリモートデスクトップからの侵入が23%となっており、リモートワークが浸透してきた昨今の時勢からみると、まだセキュリティ対応の追いついていない穴をつく攻撃が多いことがわかります。

警察庁が被害を受けた企業・団体等に向けて実施したアンケートによると、被害後、復旧に要した期間は「即時～1週間」が最も多く全体の43%にあたります。次いで多いのは「1週間～1ヶ月」であることから、多くの企業は早々に復旧できているようです。

しかしながら、被害後の調査および復旧時の費用総額を見てみると、最も多いのは「1,000万円以上5,000万円未満」で全体の36%となっています。復旧の期間だけで見ればそれほど被害を大きく感じないところではありますが、調査および復旧時の費用総額を考えると、かなりのコストがかかってしまっているのが実情です。

注：図中の割合は小数点第1位以下を四捨五入しているため、総計が必ずしも100にならない

出典：https://www.npa.go.jp/publications/statistics/cybersecurity/data/R03_kami_cyber_jousei.pdf

またそういったコスト以外にも、ランサムウェアによる被害が業務に与えた影響について、「一部の業務に影響あり」と90%が回答しているものの、被害を受けた企業のうち2件は「すべての業務が停止」したため、もしランサムウェアの被害にあった場合はインシデント対応以外にも業務に支障が出てしまうことも忘れてはいけません。

なぜランサムウェア攻撃が増加していくの

ここまでみてきたとおり、国内外問わず依然として活発となっているランサムウェア攻撃ですが、なぜ拡大していく一方なのでしょうか。その理由として大きくは、下記のことが考えられます。

●　RaaSビジネスとして儲かる市場ができている*6
●　ランサムウェア攻撃をしても捕まりにくく、ローリスクハイリターンの状態である

既述の国外のランサムウェア事情でも触れましたように、ランサムウェアの市場は“稼げるビジネス”として活発であり、ビジネスとして儲けやすい状態にあります。

さらに攻撃者を捕まえるためにはこのように国際協力が必要不可欠であり、最近ようやく法整備などが整いつつある状況ではありますが、未だランサムウェア攻撃者が逮捕されにくいのが現状です。そういった状況からランサムウェア市場は今後も衰えることなく拡大していくことが想定されます。被害にあわないためにも、ランサムウェアを一時的な流行りの攻撃としてとらえるのではなく、今後も存在し続ける脅威だということを念頭において対策を行うことを推奨します。

進化し続けるランサムウェア

先に述べましたようにRaaSビジネス市場の活発さやランサムウェアの特徴の変化など、ランサムウェアは日々目まぐるしいスピードで進化し続けています。それに伴い、実際に被害件数や身代金の被害総額などが増加しているのも見てきたとおりです。また、テレワークやクラウドサービスの利用を緊急で対応した企業が多い中で、昨今のランサムウェアの特徴の一つである「VPN機器からの侵入」がメインの手法となっている今、そこが弱点となり得る企業が多く存在しています。

ランサムウェアの脅威は一時的なものではなく、来年、ないしはその先でも攻撃の手が伸びてくる可能性があることを忘れてはなりません。引き続きテレワーク・クラウド環境のセキュリティの見直しを行うことはもちろん、そういった働き方の変化に伴って増加している標的型攻撃メールやフィッシング攻撃についても警戒が必要です。

企業が行うべきランサムウェア対策の実効性評価

しかしながら、いくら警戒を強めて対策を行っていても、ランサムウェア攻撃を完全に防ぐことは難しいのが現実です。そこでBBsecが提案しているのは、完全に防ぐのではなく、攻撃への抵抗力を高めるという考え方です。そのために重要となってくるのは「攻撃・侵入される前提の取り組み」です。第一段階に侵入を防ぐ対策を行い、第二段階にもし侵入されてしまった場合に被害を最小化する対策を行うことで、多層防御を行うというものです。詳しくは「APT攻撃・ランサムウェア―2021年のサイバー脅威に備えを―」をご確認ください。

また、なかには思い浮かぶ限りの基本的な対策はすでに実施済みという方もいらっしゃるでしょう。そういった方々へ次のステップとしておすすめしているのは、「対策の有効性を検証する」という工程です。

BBsecでは多層防御実現のために「ランサムウェア対策総点検＋ペネトレーションテスト」の組み合わせを推奨しています。

ランサムウェア対策総点検

「ランサムウェア対策総点検」では現状のリスクの棚卸を行うことが可能です。システム環境の確認や、環境内で検知された危険度（リスクレベル）を判定いたします。

また弊社では、11月に「リスクを可視化するランサムウェア対策総点検」と題したウェビナーで、サービスのデモンストレーションとご紹介をしております。こちらも併せてご覧ください。

ペネトレーションテスト

【例】

このように実際に対策の有効性を検証したうえで、企業・組織ごとに、環境にあった対策を行い、万が一サイバー攻撃を受けてしまった場合でも、被害を最小限にとどめられるような環境づくりを目指して、社員一人一人がセキュリティ意識を高めていくことが重要です。

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

2021年11月5日2021年12月9日

Webアプリケーション開発プロセスをセキュアに ―DevSecOps実現のポイント―

DevSecOpsは、「DevOps」―開発（Development）チームと運用（Operations）チームが相互協力しながら品質を向上させ続けるサイクル―の一環に、セキュリティ（Security）を組み込むことで、トータルコストを低減しつつ、さらなるクオリティ向上を実現する手法です。セキュアなWebアプリケーション開発プロセスの実現のためには、この考え方が重要です。しかし、多くの企業・組織にとって、DevSecOpsの実現には様々な課題があるのが実情です。本記事では、開発の現場担当者が感じている課題を整理したうえで、セキュアなWebアプリケーション開発にむけて、どのように取り組むべきかについてご紹介します。

OWASP Top10に新たな項目

2021年9月、「OWASP Top 10 2021」が発表されました。Webアプリケーションセキュリティに関する最も重大な10項目のリスクを取り上げたものです。前回発表された2017年版（OWASP Top 10 2017）から4年ぶりの更新となります。

※OWASP（Open Web Application Security Project）…Webアプリケーションセキュリティに関する国際的コミュニティ

2017年版Top 10の各項目は、2021年版ではそれぞれ順位を上げ下げしつつ、一部統合されて7項目となり、完全に消えたものはありませんでした。そして、新たなカテゴリが3項目追加される形で計10項目となりました。

OWASP Top 10 – 2021

A01:2021 –	アクセス制御の不備
A02:2021 –	暗号化の不備
A03:2021 –	インジェクション
A04:2021 –	^NEWセキュアでない設計
A05:2021 –	セキュリティ設定のミス
A06:2021 –	脆弱かつ古いコンポーネントの使用
A07:2021 –	識別と認証の不備
A08:2021 –	^NEWソフトウェアとデータの整合性の不備
A09:2021 –	セキュリティログとモニタリングの不備
A10:2021 –	^NEWサーバサイドリクエストフォージェリ（SSRF）

「NEW」は2021年度版で追加された項目
https://owasp.org/Top10/ より弊社和訳

新設された3項目のうち2つが、システム開発のプロセスにかかわる内容に焦点を当てています。

●　セキュアでない設計（Insecure Design）
　　ポイント：設計における管理策の欠如、ロジックの検証が不十分である等
　　推奨対策：シフトレフトによる開発ライフサイクルの実践等
●　ソフトウェアとデータの整合性の不備（Software and Data Integrity Failures）
　　ポイント：安全でないデシリアライゼーション、
　　信頼できないコンポーネントの利用、CI/CDパイプラインにおける検証不備等
　　推奨対策：データの整合性チェック、コンポーネントのセキュリティチェック、
　　CI/CDのセキュリティ対策 等

※シフトレフト…開発工程のより早い段階でセキュリティに関する問題に対処する、ソフトウェアの開発や運用の考え方

ここで推奨対策例として出てきた「シフトレフト」と「CI/CDのセキュリティ対策」はアプリケーション開発プロセス手法である「DevSecOps」実現に欠かせません。

アプリケーション開発における「DevSecOps」

DevSecOpsは、「DevOps」―開発（Development）チームと運用（Operations）チームが相互協力しながら品質を向上させ続けるサイクル―の一環に、セキュリティ（Security）を組み込むことで、結果的にトータルコストも削減でき、サービスの価値をさらに向上させる手法です。

DevSecOpsとシフトレフト（Shift Left）について、詳しくは過去記事「前倒しで対処　ーセキュリティを考慮したソフトウェア開発アプローチ「シフトレフト」とはー」をご覧ください。

“セキュリティ”が組み込まれていないと…

DevSecOpsにおけるシフトレフト

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

DevSecOpsにおけるCI/CDのセキュリティ対策

“Sec”が入らないDevOpsにおいては、設計・実装を小さな単位で素早く繰り返し実行していく手法（アジャイル開発手法等）が一般的ですが、このスピード感をサポートするのが「CI/CD」です。

CI（Continuous Integration）は継続的インテグレーション、CD（Continuous Delivery）は継続的デリバリの略です。アプリケーション開発におけるコード、ビルド、テスト、デプロイといった各作業を自動化して継続的にサイクルを回せるようにする仕組みを指します。オンプレミスでもクラウド上でも展開可能で、CI/CDを提供する様々なツールやサービスが提供されています。

ただし、CI/CDはセキュリティ上のリスクにもなりえます。CI/CD環境に脆弱性が潜んでいて不正アクセスされるようなことがあれば、そこを発端に組織全体が危険にさらされる恐れもあるのです。このため、DevSecOps実現のためには、CI/CDのセキュリティ対策が不可欠です。

セキュアでない設計によるリスク

では、シフトレフトが意識されていない、セキュアでない設計にはどのようなものがあるでしょうか。ユーザの認証に用いられる情報がIDと生年月日である場合、生年月日は他者が容易に知りうる情報なので、本人確認の仕様としてはふさわしくないことがわかります。例えば、補助金の申請システムにおいて、申請者の本人確認や申請内容の検証が甘いために容易に複数の虚偽申請を許してしまうようでは、実用に耐えるとはいえないでしょう。

こうしたセキュリティについて考慮されていない設計は、弊社の脆弱性診断でも相当数検出されています。アカウントロックアウトが設定されていない、Webサーバからのレスポンスにクレジットカード番号のような重要情報が含まれている、個人情報が暗号化されないまま送信されている、といった例は多々見受けられます。放置しておくと、個人情報や機密情報の漏洩を引き起こしかねません。

プライバシーマーク推進センターによって報告された、2020年度「個人情報の取扱いにおける事故報告集計結果」によると、誤送付や紛失・盗難によらない情報漏洩のうち、プログラムやシステムにおける設計・作業ミスを原因とするものは102件あったとのことです。大した件数ではないようにも見えますが、インシデント1件あたりの漏洩件数が増加傾向にあるとの報告もあり、影響の大きさに注意が必要です。また、これらはあくまで報告があったものだけの数ですので、セキュアでない設計によるアプリケーションが人知れず稼働したままになっている危険性は大いにあるでしょう。

一般財団法人日本情報経済社会推進協会（JIPDEC）プライバシーマーク推進センター
2020年度「個人情報の取扱いにおける事故報告集計結果」（2021年10月15日更新）より

CI/CDパイプラインにおける検証不備によるリスク

CI/CDパイプラインに起因するリスクの方はどうでしょう。2021年にあるインシデントが発生しました。ソースコードのテスト網羅率を計測するコードカバレッジツールがサイバー攻撃を受けた結果、このツールを使用していた国内企業のCI環境に不正アクセスされ、重要情報を含む1万件以上の情報漏洩につながったというものです（右図参照）。

自動化、高効率化ツールによる利便性を享受するためには、そこに係るすべてのツールや工程におけるセキュリティチェックを行う必要があるのです。

DevSecOps実現を阻む壁

さて、安全なWebアプリケーション開発の重要性は認識できているとしても、実現できなければ意味がありません。とはいえ、DevSecOps実現には、多くの企業・組織において様々な障壁があるものと思われます。今回は主な障壁を「組織」と「技術」のカテゴリに分類し、それらの問題点および解決の糸口を考えていきます（下図参照）。

DevSecOps実現のためにできること

DevSecOpsに特化したガイドラインが存在しないというのも、対応を難しくしている要因の1つかもしれません。とはいえ、Webアプリケーション開発におけるセキュリティ対策の課題を考慮すると、鍵となるのはやはりシフトレフトです。シフトレフトを意識しながら、システム開発プロセスに組み込まれたセキュリティ対策を実践する例として、以下のようなイメージが考えられます。

Webアプリケーション開発におけるセキュリティ対策実施の背景には、Webアプリケーションの規模や利用特性ばかりでなく、開発組織の業務習慣や文化等、様々な事情があることでしょう。例えば、セキュアコーディングのルール整備やスキルの平準化が不十分という課題があれば、まずは現場レベルでそこから取り組んでいくといったように、信頼されるWebアプリケーション構築のために、少しずつでもDevSecOpsの実装に近づけていくことが肝要です。

【参考】システム開発プロセスのセキュリティに関するガイドライン・資料等

●NIST
　Security Assurance Requirements for Linux Application Container Deployments
　https://csrc.nist.gov/publications/detail/nistir/8176/final

●OWASP
　OWASP Application Security Verification Standard
　https://github.com/OWASP/ASVS

●内閣サイバーセキュリティセンター（NISC）
　情報システムに係る政府調達におけるセキュリティ要件策定マニュアル
　 https://www.nisc.go.jp/active/general/pdf/SBD_manual.pdf

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

2021年9月27日2021年12月9日

なにはともあれリスクの可視化を！
―テレワーク運用時代に伴う課題とは―

2021年に入ってからも新型コロナウィルス（COVID-19）の感染拡大は収まることを知らず、外出自粛などの影響により、いまや7割近くの企業・組織にテレワークが導入されています。しかしそこには、緊急事態宣言の発令後、やむを得ず急な対応を迫られた結果、セキュリティ対策が十分にされないままテレワークの導入が進み、様々なリスクにつながってしまっている、という落とし穴があります。

本記事では、テレワーク運用時代における課題を挙げ、対応すべき対策例を考えていきます。

ニューノーマルがニューでなくなった日常

東京都における企業のテレワーク実施率は、2021年8月時点で7割近くにのぼるという報告*2が出ています。

クラウド利用もさらに進み、オンラインによるコミュニケーションやデータ共有、迅速なシステム構築などに活用されています。いまや全国でクラウドサービスを利用している組織は68.7％にのぼるとの調査結果*2もあり、ITビジネス環境に欠かせない存在です。

こうした調査結果は、「ニューノーマル」がもはや私たちの日常となったことを示しているといえるでしょう。

出典：
左図（■東京都内企業のテレワーク実施率）：
東京都産業労働局「8月の都内企業のテレワーク実施状況」（2021年9月3日）https://www.metro.tokyo.lg.jp/tosei/hodohappyo/press/2021/09/03/09.html
右図（■クラウドサービスの利用状況）：
総務省「通信利用動向調査」（令和3年6月18日）
https://www.soumu.go.jp/johotsusintokei/statistics/statistics05.html

テレワーク運用時代の新たなリスク

テレワーク導入期を過ぎ、運用期に入った組織が多数となった現在、新たなリスクが指摘されています。独立行政法人情報処理推進機構（IPA）が2021年4月に公表した「ニューノーマルにおけるテレワークとITサプライチェーンのセキュリティ実態調査」では、次のような実態が明らかにされています。

出典：IPA「ニューノーマルにおけるテレワークとITサプライチェーンのセキュリティ実態調査」（2021年4月）より当社作成

※BYOD（Bring Your Own Device）…業務に私用の端末を利用すること

例外や特例を継続することによるリスク

多くの組織がテレワーク導入を迫られた2020年、以下のような例外や特例を認めた組織は少なくないようです。

●支給IT機器の調達が間に合わず、利用ルールが整備されないままBYODを容認
●自宅環境からの接続を早急に実現するため、管理外の自宅ルータの使用を許可
●即日使用可能なツールの必要性に迫られ、習熟しないままクラウドサービスを導入　など

テレワークやクラウド利用により機密情報を含む各種データへのアクセス環境が多様化するなか、事業継続優先を理由にやむを得ず許容されたはずの“当座の対応”が、そのままになっていることが問題視されています。置き去りにされたセキュリティ対策が十分に対応されないままだと、以下のような被害につながる危険があります。

◇業務に使用していた私用スマートフォンの紛失による情報漏洩
◇自宅から業務システムへのアクセスに使用していたルータの脆弱性を突いた不正侵入
◇業務利用のクラウドサービスに機密情報が公開状態で保存されていたことによる情報漏洩　など

ギャップが生むサプライチェーンのリスク

出典：内閣府「第3回新型コロナウイルス感染症の影響下における生活意識・行動の変化に関する調査」（令和３年６月４日）

ITサプライチェーン※において、委託先の情報セキュリティの知識不足、という課題も指摘されています。

※サプライチェーン問題については、過去記事「テレワーク導入による開発現場での課題―セキュアプログラミングの重要性―」も参考ください。

確かに、テレワーク導入率は情報通信業が目立って高く、8割近くにのぼるとする調査結果 *3 もあります。システム構築業務が委託および再委託で成り立っている日本の産業界においては、たとえ委託元のシステム開発会社がクラウド利用やテレワーク環境におけるセキュリティポリシーを整備していたとしても、オンラインでデータのやりとりなどをする委託先のセキュリティ意識が十分でないと、ITサプライチェーン全体のリスクにつながる恐れがあるのです。

また、地域における差異も気になるところです。東京23区以外の地域のテレワーク実施率は2割程度*4とのことで、東京とそれ以外の地域では明らかに差があります。もちろん、新型コロナウイルス感染者数の差によるところも大きいでしょう。しかしながら、多くの事業活動が組織単体または地域限定で行われているわけではないため、テレワーク環境が当たり前の組織とそうでない組織の差異は、商習慣、ひいてはセキュリティ対策ギャップにつながりかねず、注意が必要です。

サイバー攻撃者は狙いやすいところを目ざとく見つけて突いてきます。サプライチェーンの中の一組織におけるセキュリティ不備が、そこに連なる様々な地域、規模、業種の関連組織に影響を及ぼしかねません。

まずはリスクの可視化を！

自組織からの情報漏洩を防ぎ、自らの被害ばかりでなくサプライチェーンリスクの起点とならずに済むようにするために、まずはリスクを可視化することを推奨します。

「リスクがどこにあるのか」「そのリスクはどの程度か」を明確にするのです。存在していることに気づいていないリスクを把握するのはもちろんのこと、存在自体は認識していても意図せず放置されたままになっているリスクを確認することも大切です。

リスクが明らかになってはじめて、なにに対してどのように対策を講じるか、すなわち優先的に取り組むべきポイントやそれぞれどの程度手厚く取り組む必要があるかを、具体的に検討することができます。

“なに”を”どう”守るか

リスクの洗い出しにおいては、保護すべき資産は“なに”か、そしてそれらを“どう”守るべきか、という視点で考えます。情報セキュリティリスクにおける保護すべき資産とは、「情報（データ）」です。例えば以下のようなステップを踏んで絞り込んでいきます。

リスクの可視化の重要性

すでにある程度セキュリティ対策は実施済み、という場合にもリスクの可視化は必要でしょうか。

「国内企業のサイバーリスク意識・対策実態調査2020」（一般社団法人　日本損害保険協会、2020年12月）によると、8割以上の組織において「ソフトウェア等の脆弱性管理・ウイルス対策ソフトの導入」が行われているとのことです。確かに、現在、最も代表的なセキュリティ被害の1つがランサムウェア※であることを鑑みると、最低限のセキュリティ対策としてやっていて当たり前という意識が感じられる結果です。

※ランサムウェアについては過去記事「ランサムウェア最新動向2021―2020年振り返りとともに―」も参考ください。

しかし、残念ながらセキュリティ対策にはこれだけやっておけば万事解決、という最適解はありません。インシデントが発生する恐れがゼロではないという現実がある以上、ランサムウェアに感染した場合や、システムに潜む脆弱性を悪用されて攻撃された場合に、どのような影響を受ける可能性があるのか、リスクを可視化しておくべきでしょう。

セキュリティ対策には専門家の力を

組織が抱えるリスクは、業種や規模のほか、サプライチェーンの特性や取り扱う情報の種類、テレワークやクラウド利用といったシステム環境の状況、セキュリティ対策の度合い……といった様々な事情に応じて異なります。まずは、自組織が抱えるリスクは何かを正確に見極め、優先度に応じた対策を検討できるようにすることが重要です。

その際、第三者視点の正確なリスクの検知と評価、そして講じるべき具体的な対策について、的確なアドバイスがほしいものです。ぜひ心強いパートナーとなり得る、リスクアセスメントに精通したセキュリティベンダを探してみてください。

【参考】テレワークに関するガイドライン・参考資料等

●総務省
　「テレワークセキュリティガイドライン第５版」（令和３年５月）
　https://www.soumu.go.jp/main_content/000752925.pdf
　「中小企業等担当者向けテレワークセキュリティの手引き
　（チェックリスト）（初版）」（令和２年９月11日）
　https://www.soumu.go.jp/main_content/000706649.pdf

●経済産業省 / 独立行政法人情報処理推進機構（IPA）
　「テレワークを行う際のセキュリティ上の注意事項」
　（2021年7月20日更新）
　https://www.ipa.go.jp/security/announce/telework.html
　「テレワーク時における秘密情報管理のポイント(Ｑ＆Ａ解説)」
　（令和２年５月７日）
　https://www.meti.go.jp/policy/economy/chizai/chiteki/pdf/teleworkqa_20200507.pdf
　「クラウドサービス利用のための情報セキュリティマネジメントガイドライン 2013年度版」
　https://www.meti.go.jp/policy/netsecurity/downloadfiles/cloudsec2013fy.pdf
　「中小企業のためのクラウドサービス安全利用の手引き
　https://www.ipa.go.jp/files/000072150.pdf

●内閣サイバーセキュリティセンター（NISC）
　「テレワーク実施者の方へ」（令和2年6月11日更新）
　https://www.nisc.go.jp/security-site/telework/index.html
　「インターネットの安全・安心ハンドブックVer 4.10」
　（令和2年4月20日）
　https://www.nisc.go.jp/security-site/files/handbook-all.pdf

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

2021年8月26日2021年12月9日

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

私たちの生活を支える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

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

2021年に入ってからも10件以上の脆弱性が報告^{*2https://jvndb.jvn.jp/search/index.php?mode=_vulnerability_search_IA_VulnSearch&lang=ja&useSynonym=1&keyword=wordpress}されているほか、国内でもWordPressを最新バージョンにアップデートしていなかったことで不正アクセスを受けたとの報告^{*3https://ssl4.eir-parts.net/doc/7357/tdnet/1964869/00.pdf}が上がっています。

脆弱性を悪用した攻撃事例2：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月に「テレワーク時代のセキュリティ情報の集め方」と題したウェビナーで、情報収集の仕方やソースリストのご紹介をしておりますので、ぜひご参考にしていただければと思います。

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

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

2021年8月2日2021年12月9日

暗号技術を安全に活用するために
―今、やっておくべきセキュリティ対策―

暗号技術は、私たちの安全なシステム利用や事業継続のためにかかせないテクノロジーです。しかし、とりあえず導入しているからそれでよい、というわけではなく、ただしく実装されているかを確認したうえで、環境・リスクに応じて適切に実装することが求められます。本記事では、暗号技術を安全に活用するために、必要なポイントを解説し、やっておくべき現状確認についても紹介いたします。

contents

現代の暗号技術の２大課題

暗号技術は情報セキュリティを支える重要な技術の1つです。暗号技術があればこそ、私たちは安心して業務システムを利用し、インターネット経由での事業活動を行うことができています。

一方で、今、次世代暗号に関する話題が、少しずつ一般的なニュースでも取り上げられ始めています。なぜ、次世代暗号技術が求められているのでしょうか。その背景には、既存の暗号技術に対する次のような懸念があるためと考えられます。

量子コンピュータの脅威に対抗：耐量子暗号

将来、コンピュータの処理能力の進化によって、現在普及している暗号技術が無力化されてしまうと言われています。これは昨今よく取りざたされている、量子コンピュータの登場に起因しています。量子コンピュータは量子力学を計算過程で用いて並列計算を実現することで、現在のコンピュータと比較して圧倒的な処理能力を保持するとされています。

量子コンピュータの登場による既存の暗号技術への脅威、そしてその対策は以下のとおりです。

量子コンピュータは2030年には実用化されると想定されているため、その頃にはサイバー攻撃者が量子コンピュータを用いた攻撃を実行してくる恐れがあるということになります。これが、「暗号の2030年問題」と言われるものです。このため、2030年に先駆けて、防御策を実現する必要があります。そこで、耐量子暗号の選定や鍵長ポリシーの見直し、といった次世代暗号に向けた標準化が、日米において進められています。

暗号技術の標準化動向

●米国：NIST（米国立標準技術研究所）
　→2022年頃の標準化を目指す
●日本：CRYPTREC（暗号技術検討会（総務省・経産省））
　→各種タスクフォース等により調査検討中
　　NISTと同等の時期での標準化を目指す

NISTによる標準化検討で挙げられている耐量子暗号の最終候補には、以下のようなものがあります。そう遠くないうちに確定されることでしょう。

暗号化とデータ活用の両立：高機能暗号技術

従来の暗号技術は、
●データの秘匿：保管している内容が第三者にわからないようにする
●改竄の防止：メッセージ認証等、内容が書き換えられていないかチェック
●認証：なりすましが行われていないか電子証明書による確認
●通信の安全性確保：ネット上で流れるデータ内容が第三者にわからないようにする
といった機能に特化したものです。　　

そして、データの照合や分析といったデータ活用時の処理は平文（データが暗号化されておらず、誰が見ても内容がわかる状態）で実施しているのが現状です。このため、データ処理者に対する平文データへのアクセスを許容せざるを得ず、結果として、業務上の利便性等の都合により、暗号化されていてしかるべき重要情報が平文のまま保存されているといった実情があります。結果、内部犯行はもちろんのこと、外部からの不正アクセスを受けた場合に、平文の重要情報が盗取されてしまう恐れがあるわけです。

これに対し、従来に加えて付加的な機能がある暗号技術の総称が、「高機能暗号技術」です。

なかでも、暗号化したまま演算処理できる「準同型暗号」は、今まさに、実装ライブラリについての国際標準化推進活動が進行中です。準同型暗号のような高機能暗号技術が実用化されれば、クラウドサーバ上における暗号化したままでのデータ照合や分析、個人情報や機密データを秘匿したままでの様々な処理の実現といった、セキュリティが保持されたデータ活用に期待が持たれています。

現在主流の暗号方式の種類

さて、次世代暗号技術のことを述べてきましたが、ここで、従来の暗号技術、すなわち現在主流の暗号技術について確認してみましょう。現在使用されている暗号技術は以下のとおりです。

暗号方式	特徴	主な用途	主な暗号種別
共通鍵暗号	暗号化も復号も同じ鍵を使用 →処理が高速 →鍵の管理が煩雑	ファイルの暗号化	DES Triple DES RC5 AES
公開鍵暗号	公開鍵と秘密鍵を作成して暗号化と復号で異なる鍵を使用 →セキュリティ強度が高い →鍵の管理が容易 →処理は低速	共通鍵の鍵配送電子署名電子証明書	RSA DSA DH（Diffie-Hellman） ECC（Elliptic Curve cryptosyste：楕円曲線暗号）
ハイブリッド暗号	共通鍵暗号の受け渡しには公開鍵暗号を、データ自体の暗号化には共通鍵暗号を使用 →安全性が保たれたうえで高速な処理が可能	SSL/TLS（HTTPS通信）	鍵交換：DH 暗号化：AES、Camellia

共通鍵暗号と公開鍵暗号を組み合わせた「ハイブリッド暗号」には、身近な利用例として、SSL/TLSがあります。HTTP通信をSSL/TLSによって暗号化するHTTPS通信です。共通鍵暗号と公開鍵暗号のそれぞれの長所を組み合わせることで、セキュリティ強度の高い暗号化を実現し、通信の安全性を高めています。

暗号化されていないデータに伴うリスク

このように、暗号技術は情報セキュリティの基盤技術として、インターネット通信、電子署名、ファイルやデータベースの暗号化等に活用され、安全な事業活動に寄与しています。

ここで気をつけたいのが、通信上を流れるデータには注意を払っていても、自組織内で保存する重要なデータが平文のまま、というケースです。これは、ビジネス上の非常に大きなリスクとなり得ます。ここでは主に二つのリスクが考えられます。一つ目は、攻撃者の侵入を許してしまった場合、使用可能な状態の情報にアクセスを許してしまうことによる情報漏洩のリスク、二つ目が内部による犯行を誘発するリスクです。過去には実際に、保存データが平文であったことで深刻な情報漏洩となってしまった例が存在します。

暗号化されていなかったことにより個人情報が漏洩した事例

2020年通販サイト(日)*5	約6,300件漏洩パスワードを平文で保存
2020年カード決済事業者(米)*2	約250万件漏洩クレジットカード情報を平文で保存
2019年ファイル送信サービス(日)*3	約480万件漏洩パスワードを平文で保存	⇒サービス終了
2018年航空会社(中)*4	940万件漏洩バックアップファイルを平文で保存	⇒多額の制裁金等
2017年信用情報機関(米)*5	約1億4,500万件漏洩ユーザデータを平文で保存	⇒格付け引き下げ、多額の制裁金等
2014年通信教育会社(日)*6	約3,500万件漏洩内部関係者による犯行	⇒刑事裁判での過失責任認定等

仮に攻撃者の侵入を許してしまったとしても、暗号化でデータを保護することによって、情報漏洩の被害を防ぐことが可能です。また、ランサムウェアの二重脅迫*7https://www.sqat.jp/kawaraban/14279/や、内部犯行に対しても暗号化は有効です。

安全な暗号技術導入のために必要なポイント

では、取りあえず暗号技術を導入していれば安心かというと、決してそんなことはありません。

暗号化を実装したつもりで、実はこんな状態になっている、ということはないでしょうか。

●一部の個人情報や機密情報といった重要情報がHTTP通信で送信されている
●サーバ証明書が期限切れである
●信頼できない認証局SSL/TLS証明書を使用している
●危殆化した暗号アルゴリズムや鍵長を利用しているプラットフォームがある
●ソースコードに独自の暗号化関数（またはライブラリ）を実装している
●ソースコードにおいて暗号鍵がハードコード(※)されている

※ハードコード… 本来、ソースコード内には記述すべきではない処理や値を直接書き込むこと。（例：税率など）動作環境や利用条件に応じて処理や値を変更する場合、対応が困難になる。

例えば、前述した「ハイブリッド暗号」で触れたSSL/TLSの実情について見てみましょう。IPA（独立行政法人情報処理推進機構）が2020年7月に発行した「TLS暗号設定ガイドラインv3.0.1」では、暗号化通信のプロトコルバージョンについて、TLS 1.2とTLS 1.3のみ推奨としています。Chrome、Firefoxといった主要ブラウザもTLS 1.1までのバージョンをすでに無効化しています。しかしながら、TLS 1.1以下をサポートしているサイトがいまだ全体の4割程度存在することがわかります（グラフ参照）。たとえブラウザで無効化されていたとしても、攻撃者がブラウザを経由せずサーバを攻撃する恐れがあるため、TLS 1.1以下の接続を許容すること自体がリスクとなります。早急にTLS 1.1以下での接続可否を確認し、接続が可能な場合は対処を実施するべきです。

自組織の現状確認、最新の暗号技術動向の把握に努め、環境・リスクに応じた適切な暗号技術の実装を行う必要があるでしょう。

安全に暗号技術を活用するためにやっておくべきこと

せっかくコストをかけて暗号技術を導入していても、適切に実装できていなければ宝の持ち腐れになってしまいます。まずは自組織の暗号化実装がセキュリティ対策として実効性のあるものか、現状の確認を行うことを推奨します。

例えば以下のような観点でチェックすることが必要です。

環境・システムへの暗号化実装による実効性確認のポイント

●プラットフォーム
●Webアプリケーション
●API
●スマホアプリ
●クラウドサービス

確認方法の例

●システム脆弱性診断
●PCI DSS準拠チェック
●ソースコード診断
●クラウド設定チェック（CISベンチマーク、ベストプラクティス適合度）
●ペネトレーションテスト

現状、適切な暗号技術の実装がなされていれば、来る次世代暗号技術への移行準備を実施する段になっても、スムーズに対応することができるでしょう。

参考情報：暗号化実装に関するガイドラインの紹介

■電子政府における調達のために参照すべき暗号のリスト
（CRYPTREC暗号リスト）（最終更新：2021年4月1日）
　総務省・経済産業省
　https://www.cryptrec.go.jp/list/cryptrec-ls-0001-2012r6.pdf

■TLS 暗号設定ガイドライン（2020年7月）
　IPA（独立行政法人情報処理推進機構）・NICT（国立研究開発法人情報通信研究機構）
　https://www.ipa.go.jp/security/ipg/documents/ipa-cryptrec-gl-3001-3.0.1.pdf

■暗号鍵管理システム設計指針(基本編)（2020年7月）
　IPA（独立行政法人情報処理推進機構）・NICT（国立研究開発法人情報通信研究機構）
　https://www.cryptrec.go.jp/report/cryptrec-gl-3002-1.0.pdf

■SP 800-57 Part 1: Recommendation for Key Management: Part 1 – General」（2020年5月4日）
　NIST（米国立標準技術研究所）
　https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf

■SP 800-175B: Guideline for Using Cryptographic Standards in the Federal Government: Cryptographic Mechanisms（2020年3月31日）
　NIST（米国立標準技術研究所）
　https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-175Br1.pdf

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

2020年通販サイト(日)*5	約6,300件漏洩パスワードを平文で保存
2020年カード決済事業者(米)*2	約250万件漏洩クレジットカード情報を平文で保存
2019年ファイル送信サービス(日)*3	約480万件漏洩パスワードを平文で保存	⇒サービス終了
2018年航空会社(中)*4	940万件漏洩バックアップファイルを平文で保存	⇒多額の制裁金等
2017年信用情報機関(米)*5	約1億4,500万件漏洩ユーザデータを平文で保存	⇒格付け引き下げ、多額の制裁金等
2014年通信教育会社(日)*6	約3,500万件漏洩内部関係者による犯行	⇒刑事裁判での過失責任認定等

「OWASP Top 10」とは

「OWASP Top 10 2021」を紐解く

脆弱性を悪用した攻撃の脅威

設計・開発段階で作りこまれる脆弱性

脆弱性診断の活用

BBSecの脆弱性診断サービス

「毎日/週など短いスパンで定期診断して即時に結果を知りたい」

「システム特性に応じた高精度な診断をしたい」

WebブラウザでTLS 1.0/1.1が完全に無効化

WebサイトにおけるTLSの利用状況

【各プロトコルバージョンのサポート状況】

過去の経緯

TLS 1.0/1.1を継続使用することによる影響

TLS 1.1以下の暗号化通信に存在する脆弱性を悪用した攻撃例

セキュリティ強化にむけた対策のポイント

各種ガイドラインの紹介

悪名高きEmotetが帰ってきた！

復活したEmotetの脅威は…

主な感染経路：メール添付ファイルにご注意！

注意するだけでは防げない巧妙なメール攻撃も…

マルウェア対策は組織一丸で

マルウェア対策のモデルケース

Emotetご相談窓口開設中！

標的型攻撃メール訓練サービス

ランサムウェア対策総点検

SQAT® ペネトレーションテスト

【シナリオ例】 疑似マルウェア連携

関連リンク：

「情報セキュリティ10大脅威 2022」に新たに「修正プログラムの公開前を狙う攻撃（ゼロデイ攻撃）」がランクイン

Apache Log4jの脆弱性

Log4Shellを悪用したマルウェアによる攻撃事例

ゼロデイ攻撃への対策と備え

BBSecでは

脆弱性を悪用した攻撃への備え～自システムの状態を知る

攻撃を受けてしまった場合の対策の有効性の確認

増加するデータ漏洩事故

設定不備が問題に

定期的な対策と設定の見直しを

色々な顔を持つクリックインターセプション

十分なセキュリティ対策を

現在のランサムウェア事情

海外レポートにおけるランサムウェア事情

国内レポートにおけるランサムウェア事情

なぜランサムウェア攻撃が増加していくの

進化し続けるランサムウェア

企業が行うべきランサムウェア対策の実効性評価

ランサムウェア対策総点検

ペネトレーションテスト

OWASP Top10に新たな項目

OWASP Top 10 – 2021

アプリケーション開発における「DevSecOps」

DevSecOpsにおけるシフトレフト

DevSecOpsにおけるCI/CDのセキュリティ対策

セキュアでない設計によるリスク

CI/CDパイプラインにおける検証不備によるリスク

DevSecOps実現を阻む壁

DevSecOps実現のためにできること

【参考】システム開発プロセスのセキュリティに関するガイドライン・資料等

ニューノーマルがニューでなくなった日常

テレワーク運用時代の新たなリスク

例外や特例を継続することによるリスク

ギャップが生むサプライチェーンのリスク

まずはリスクの可視化を！

“なに”を”どう”守るか

リスクの可視化の重要性

セキュリティ対策には専門家の力を

【参考】テレワークに関するガイドライン・参考資料等

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

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

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

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

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

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

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

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

現代の暗号技術の２大課題

量子コンピュータの脅威に対抗：耐量子暗号

暗号技術の標準化動向

暗号化とデータ活用の両立：高機能暗号技術

現在主流の暗号方式の種類

SQAT^® ペネトレーションテスト

【シナリオ例】疑似マルウェア連携

「情報セキュリティ10大脅威 2022」に
新たに「修正プログラムの公開前を狙う攻撃（ゼロデイ攻撃）」がランクイン

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

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

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