2019 年アプリケーションセキュリティリスクレポート - …...レポート 2019...

2019年アプリケーションセキュリティリスクレポート

レポートセキュリティ

ページ目次エグゼクティブサマリーと要点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22018年の傾向のレビュー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3National Vulnerability Databaseの分析 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11ソフトウェア分析 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21プライバシー、ポリシー、規格 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30オープンソースの依存関係にある脆弱性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

1www.microfocus.com

エグゼクティブサマリーと要点侵害を受けたシステムに関するたくさんのメディア報道から受ける一般的な印象にも関わらず、データによると、2018年の侵害発生率はそれ以前の年より高いわけではありません。しかし、アプリケーションセキュリティの世界では、攻撃側と防御側の間に示唆されるこの均衡状態を良いニュースと捉えるのは、自分の組織が過去に不利な形勢になっていたと感じる場合だけです。それはさておき、発生する侵害に関連して一定程度のランダム性があるように見えるのは興味深い点です。この知識は組織のアプリケーションセキュリティプログラムに適した事前予防的な防御戦略の開発に役立つ可能性があり、本レポートの結論ではそのような戦略のいくつかに簡単に触れています。一方で、本レポートには以下に示すいくつかの重要な調査結果が含まれています。

■ 国家機関への攻撃がより一般的な脅威となり、パッチ未適用の脆弱性を利用してデータを盗み取られることが多くあります。

■ PCIデータセキュリティスタンダード (PCI DSS)の影響を受ける企業は、一般に、1つ以上の DSS要件に準拠していません。

■ 人はミスをしやすいため、自動化できるにもかかわらず手動で行われているセキュリティ作業は、正しく実行されないリスクがあります。

■ 1年内に公表されたセキュリティ問題は過去最高のレベルに達しています。データによると、研究者が弱点領域を拡大したために多くの脆弱性が発見されています。

■ 2018年に一般データ保護規則 (GDPR)が施行され、即時適用されました。GDPR違反で科せられた 4件の制裁金のうち2件はアプリケーションセキュリティの不備に起因しています。

■ オープンソースコンポーネントの使用が増加していることにより、8件に 1件のオープンソースダウンロードに既知の脆弱性が含まれています。サプライチェーンの完全性が依然として大きな懸念事項となっています。オープンソースソフトウェアは、報告されている脆弱性の大部分を占めます。

■ 2018年にNational Vulnerability Database (NVD)に報告された脆弱性の数は 13%増加しました。セキュリティ研究者による自動化の利用の増加が、NVDへの報告の増加に寄与している可能性があります。

■ このような発見にも関わらず、脆弱性の発見はより困難になっています。これは、バグバウンティプログラム (脆弱性報奨金制度 )を実施している企業が、脆弱性の発見にハンターが時間をかけるよう報奨金を引き上げなければならなかったことにも反映されています。

■ 報告された脆弱性 (重大度の高い脆弱性を含む )は増加しましたが、重大度の高い脆弱性の割合は、 4年間で最低の水準、10年間で 2番目に低い水準に低下しました。重大度が中程度の脆弱性の割合が大幅に増加しました。

■ Fortify on Demand (FoD)の脆弱性データを分析した結果、11,000を超えるWebアプリケーションの94%にセキュリティ機能のバグが含まれており、またコード品質およびアプリケーションプログラムインターフェイス (API)悪用の問題は過去 4年間で約 2倍に増加していることが分かりました。また、入力の検証には依然として問題があります。

https://www.microfocus.com

レポート2019年アプリケーションセキュリティリスクレポート

2

■ 驚くことでないかもしれませんが、700を超えるモバイルアプリケーションから得た FoD脆弱性データを分析したところ、同一カテゴリの調査結果の数がパーセントポイントで大幅に増加しているケースがありました。たとえば、2018年のデータでは分析対象となったWebアプリケーションの 35%に API悪用の問題があったのに対し、モバイルアプリケーションでは発生率が 52%にまで上昇しています。

概要過去 20年間におけるソフトウェアセキュリティ業界の進化について言えることは数多くあります。その歴史を振り返ることは本書の意図ではありませんが、本レポートまたは類似のレポートで提示される情報を一貫して信頼できる形で理解するために重要な、時に誤解されることがある用語について読者に注意を喚起します。

攻撃を成功させるには、内在的な弱点に起因する、到達可能な脆弱性の悪用が必要であることは、かなり前から理解されてきました 1。

本レポートのコンテキストで、攻撃とは、ソフトウェアやソフトウェアシステムに対する悪意のある行為を意味します。悪用とは、ソフトウェアに設計意図から逸脱した動作をさせる特定の行為、または一連の行為を行うことです。弱点は、設計を通じて、またはシステム誤動作の結果として、許可のない行為の実行を条件が許してしまうときに存在します (ソフトウェアシステムのコードベースに内在しないソフトウェアコードの導入や呼び出し (つまり、コードインジェクション )を防止する防御手段の欠如は弱点の一例です )。脆弱性は、弱点の具体的で明示的なインスタンスです (たとえば、アプリケーションの特定バージョンにおけるクロスサイトスクリプティング (XSS)のインスタンスは脆弱性の一例で、XSSはコードインジェクションの弱点の特定のタイプです )。

上述の用語のコンテキスト内で、本レポートは 2018年に該当する調査結果を、過去の年の関連データとともに提示することを目的としています。まず、データ侵害の傾向について述べます。発生を減らす方法について知識があるにもかかわらず、データ侵害の発生をニュースで目にし続ける理由について、それらの傾向から何か知ることができないかを探ります。次に、攻撃者に発見される前に脆弱性を発見するための取り組みに関するソフトウェア業界の動向と、規制やその結果として制裁金を科すことで関連リスクを管理しようとする試みについて見ていきます。GDPRはそういった取り組みの一例です。National Vulnerability Databaseからのデータ分析に基づく結果を提示し、前年のデータセットと比較して 2018年のデータが示唆している可能性があることについての見解を示します。続いて、11,000を超えるアプリケーションのセキュリティテスト結果に対する考察に基づいて、ソフトウェアにおける弱点の傾向を説明します。この分析の後、プライバシー、ポリシーおよび規格をめぐる目に見える動き、およびデータ処理の最低基準確立、および (または )ソフトウェアシステムの所有者や運用者が (当局の目から見て )「適切に」ソフトウェアのセキュリティリスクに対処しなかった場合の懲罰的手段適用のために、管理機関が何をしているかを議論することで、リスク管理を再検討します。最後に、ソフトウェア業界がオープンソースおよびその他サードパーティコンポーネントへの依存度を高めていることを踏まえ、オープンソースの依存関係およびコンポーネントの分析を行い、リスクの潜在的な原因を明らかにするとともに、緩和のための指針を提供します。

__________

1 Richard Bisbey II and Dennis Hollingworth, Protection Analysis: Final Report, ISI/SR-78-13, University of Southern California/Information Sciences Institute, Marina Del Rey, CA 96291 (May 1978).

3www.microfocus.com

2018年の傾向のレビューデータ侵害には傾向がある2018年は、サイバーセキュリティと脆弱性管理の重要性が高まり、Facebook、Marriott、Quoraでの重大な侵害がビジネスプロセスやシステムのセキュリティ確保に失敗した場合の結果を明らかにしました 2。さらに、国家機関への攻撃がより一般的な脅威となり、パッチ未適用の脆弱性を利用してデータを盗み取られることが多く、また犯罪者は脆弱性を利用してシステム経由でランサムウェアを拡散させました。3

一般的なマスコミの報道やセキュリティベンダーによる報告を見ると、データ侵害がますます大きな問題になっていると考えるかもしれません。数千万人、さらには数億人の個人情報が流出するデータ侵害の報告は後を絶たないようです。その結果、人々の判断力が「可用性ヒューリスティック」4の影響を受けてしまいます。つまり、より頻繁に情報を耳にするようになったことで、常に新たな侵害に触れ、それらがより一般的であると信じてしまうのです。

しかし調査によると、実際は過去数年間に侵害の件数や規模に大きな変化はないことが示されています。この傾向が持続していることは、攻撃側と防御側が能力においてほぼ均衡に到達し、一方が能力を高めても、他方の能力向上によってすぐに相殺されることを示唆しているようです。

データ侵害のパターンに関する最新の研究を以下にまとめました。

モデルの分析結果によれば、過去 10年間でデータ侵害の規模と頻度のいずれも増加していないことが分かります。注目された増加は、データセットに潜在する裾の重い統計分布によって説明できることが分かりました。具体的には、データ侵害の規模は対数正規分布であり、1日の侵害の頻度は負の二項分布で表されることが分かりました 5。

研究者がデータ侵害の数も規模も変わっていないと言うときは、何を意味しているのでしょうか？研究によると、毎年発生するデータ侵害の件数と規模は、同じ統計分布からのランダムなサンプルのようであることが示されています。特に、侵害の規模は対数正規分布からのサンプルのように見えます。これは、馴染みのある正規分布のような形 (「ベルカーブ」)をしていないもので、観察値の分布の対数が正規分布であるものです。そして侵害の頻度は負の二項分布に従っています。これも、見た目ほど怖いものではありません。

正規分布はランダム効果が加算される状況で自然に現れますが、対数正規分布はランダム効果が乗算される (そのため対数が加算される )ときに自然に現れます。直感的に、悪意のあるハッカーがさまざまなレベルのセキュリティ侵入を成功させることは、加算的というよりも乗算的であり、ハッカーの全体的な成功は対数正規分布に従うことが合理的に予想される可能性があることを示唆しています。

__________

2 Newman, Lily Hay. “The Worst Hacks of 2018.” Wired.com. www.wired.com/story/worst-hacks-2018-facebook-marriott-quora/

3 “In addition to attacks by financially motivated criminals, a significant volume of public reporting increasingly attributes global cyber-attacks to the actions of nation states.” INTERNET ORGANISED CRIME THREAT ASSESSMENT (IOCTA) 2018, pg. 8, www.europol.europa.eu/activities-services/main-reports/internet-organised-crime-threat-assessment-iocta-2018

4 Tversky, Amos, and Daniel Kahneman. “Judgment under uncertainty: Heuristics and biases.” Science 185, no. 4157 (1974): 1124-1131.

5 Edwards, Benjamin, Steven Hofmeyr, and Stephanie Forrest. “Hype and heavy tails: A closer look at data breaches.” Journal of Cybersecurity 2, no. 1 (2016): 3-14.


https://www.wired.com/story/worst-hacks-2018-facebook-marriott-quora/




https://www.europol.europa.eu/activities-services/main-reports/internet-organised-crime-threat-assessment-iocta-2018






4

また、1日の侵害頻度の負の二項分布も、データ侵害がどのように起こるかについてはランダムな要素が強いことを示唆しています。負の二項分布とは、「表」が出るまでコインを何回投げるかをモデル化するときに使用するものです。データ侵害の発生は同じモデルに従っているため、データ侵害の件数はコインを投げたりサイコロを振ったりするのと同じくらいランダムであると考えるのが合理的です。

ここで引用している研究は 2016年に発表されたもので、現在も通用するとは限りません。しかし、10年間にわたり真実であったものであるため、現在も真実であると仮定することに特に論理を大きく逸脱する必要はありません。現在も通用すると仮定した場合、それは何を示しているのでしょうか？

表面的には、今後も侵害は発生し続け、そして将来の侵害の発生率と規模は過去に見てきたものとほぼ同程度であることを事実として受け入れざるを得ないように見えます。そうであれば、現在の情報セキュリティに対する取り組みのレベル以上を維持することを見込んでおく必要があります。これを怠ると、攻撃側が優位に立つことになり、それがデータ侵害の規模と頻度の増加に反映される可能性があります。ベンダーは革新を続ける必要があり、セキュリティテクノロジーの使用者はベンダーの最新の革新を導入し続ける必要があります。

しかし、データ侵害のフォレンジック分析を詳しく見てみると、たとえば Verizon 2018 Payment Security Report6やその前身のレポートなどでは、PCI DSSの 1つ以上の要件を遵守していない企業が多いことが示唆されています。たとえば、2017年には、12の DSS要件すべてを完全に遵守している企業はわずか52.5%でした。さらに、表 1に示すように、12の要件の全分野でコンプライアンスが著しく不足していました。

要件の説明要件番号コンプライアンス違反率(%)

カード会員データを保護するために、ファイアウォール設定を導入して、維持する

システムパスワードやセキュリティパラメータに、ベンダーが提供したデフォルト値を使用しない

保存されるカード会員データを保護する

オープンな公共ネットワーク経由でカード会員データを伝送する場合、暗号化する

ウィルス対策ソフトウェア/プログラムを使用し、定期的に更新する

安全性の高いシステムとアプリケーションを開発し、保守する

カード会員データへのアクセスを、業務上必要な範囲内に制限する

コンピュータにアクセスするすべてのユーザーに一意のIDを割り当てる

カード会員データへの物理アクセスを制限する

ネットワークリソースおよびカード会員データへのすべてのアクセスをトラッキングおよび監視する

セキュリティシステムおよびプロセスを定期的にテストする

全従業員向けの情報セキュリティポリシーを整備する

1.

2.

3.

4.

5.

6.

7.

8.

9.

11.

12.

10.

18.9

23.8

22.1

13.1

12.3

23.0

11.5

23.8

17.2

32.0

30.3

27.0

表 1.PCI DSSの重要要件のコンプライアンス違反率 (出典：Verizon 2018 Payment Security Report)

__________

6 https://enterprise.verizon.com/resources/reports/payment-security/2018/

https://enterprise.verizon.com/resources/reports/payment-security/2018/



5www.microfocus.com

PCI DSSの要件が複雑かつ難解であるために、企業がコンプライアンスを維持することが困難であるという見方もあるでしょう。そうであれば、定期的に発生する決済システムのデータ侵害は、決済処理に関わる企業が PCI DSSの要求する基本的なセキュリティ対策を正しく実施していないことが理由の 1つであるという考え方を裏付けることになります。また、企業は大規模なデータ侵害の発生時に科せられる可能性のある罰則を無視しているわけではなく、むしろ、単に現今の ITシステムが複雑すぎて、現在のテクノロジーでは管理できないためであるという説明の方が正しいかもしれないと考えるのが妥当なようです。ヒューマンエラーもここでは重要な要因となる可能性があります。また、決済業界以外のコンプライアンスレベルに関する詳細な情報は入手できませんが、多くの企業が自身の ITシステムのセキュアな構成を確立・維持することができていないという点で、同じ一般的なパターンに陥っていると考えられます。

人は驚くほどミスを犯しやすいものであり、どれほど単純な作業であっても人が作業を行う必要があるプロセスでは、リスクにつながるミスが発生する可能性があります。David Smithの著書『Reliability, Maintainability and Risk』7の付録 6「ヒューマンエラー率」では、タスクを「最も単純なタスク」、「単純なルーチンタスク」、「注意が必要なルーチンタスク」、「ルーチンではない複雑なタスク」の 4つの一般的なタイプに分類しています。たとえば、運転中に交通量の多い交差点の存在に気付くのは最も単純なタスクであり、部屋を出るときに電気を消すのは単純なルーチンタスクで、自動販売機で正しい選択をするのは注意が必要なルーチンタスクです。より複雑なタスクはルーチンではない複雑なタスクのカテゴリに分類されます。

このような人為的ミスの傾向により、これらの各カテゴリに分類されるタスクはかなりの確率で不正確に行われる可能性があります。Smithによると、経験則として、人は約 10万回に 1回最も単純なタスクを失敗し、この失敗確率は 0.00001になります。単純なルーチンタスクでは、約 1,000回に 3回失敗し、失敗確率は 0.003となります。注意が必要なルーチンタスクでは、約 100回に 1回失敗し、失敗確率は 0.01となります。そして、より複雑なタスクの場合、少なくとも 10回に 1回失敗し、失敗確率は少なくとも 0.1となります。

経験豊富でよく訓練された管理者がいれば、ファイアウォールの構成を変更することは、注意が必要なルーチンタスクであるかもしれません。ほとんどの場合、構成は正確に更新されますが、約 100回に 1回の割合で障害が発生します。これら障害のすべてがファイアウォールの提供する保護を損なう結果になるわけではありませんが、一部はそうなります。そして、企業の ITシステムに日々どれだけの変更が加えられているかを見ると、多くのミスが発生する可能性は高いと推測されます。当然のことながら、それらのうち少なくとも一部はネットワークのセキュリティに影響を与えます。このように、ヒューマンエラーは ITシステムに相当数の脆弱性を引き起こす可能性があります。したがって、攻撃者がサイコロを振り、自分のハッキングツールが特定のシステムを侵害できるか試してみるというモデルすら機能するかもしれません。

__________

7 Smith, David J. Reliability, maintainability and risk: practical methods for engineers. Butterworth-Heinemann, 2017.



6

最高の訓練を実施しても、人間である管理者の限界を克服できる可能性は低いため、この問題に対処するもう一つの方法は、可能な限り多くのプロセスを自動化することです。ドットコム時代には、アプリケーションレベルの脆弱性についてソフトウェアをチェックできるツールはほとんどありませんでした。しかし今日では、影響を与えるソフトウェアがデプロイされる前に、多くの潜在的な脆弱性を特定できる非常に洗練されたツールを利用することができます。そのようなツールを使用することで、正しく構成されたシステムを攻撃者が攻撃する可能性を減らし、これまでデータ侵害の統計モデルが維持してきたレベルをより許容できるレベルにすることが可能になるかもしれません。たとえば、PCI DSS要件 6が適用されているソフトウェアでハッカーが脆弱性を見つけようとした場合、脆弱性が発見される確率を 23%からはるかに低いレベルに減少できる可能性があります。他の 11の PCI DSS要件を遵守するために必要なその他タスクの自動化に類似のテクノロジーを使用した場合、データ侵害の規模と頻度が減少することが見込まれます。

脆弱性の公開における傾向全体的に、公表されているセキュリティ問題は件数が増え続けており、1年内に記録された過去最高レベルに達しています。2018年に National Vulnerability Database (NVD)に報告された脆弱性の数は 16,517件に達し、前年比 12.8%増となっています (図 1：CVEの開示傾向を参照 )。

2009 20100

17,500

15,000

12,500

10,000

7,500

5,000

2,500

2011 2012 2013 2014 2015 2016 2017 2018

4,14

5

年

NVDに報告があった脆弱性(2009～2018年)16

,517

5,70

7

4,59

9

5,28

7

5,18

6 6,48

97,92

4

6,44

6

14,6

47

脆弱性の数

図 1.CVEの開示傾向

7www.microfocus.com

最高の訓練を実施しても、人間の限界を克服できる可能性は低いため、バグバウンティプログラムが脆弱性発見への関心を高めている一方で、脆弱性追跡会社である Risk Based Securityのデータによると 8、このような取り組みを通じて公開された脆弱性は約 4.3%にとどまっています。同社によると、脆弱性レポートのうち、組織的な公開プロセスを経たものは半数以下でした。

報告される脆弱性の数の増加は、業界における傾向が進化していることが背景にあります。過去 12か月間の主な傾向について以下で説明します。

ソフトウェア業界の傾向と脆弱性2018年、セキュリティテクノロジーと規制の状況は引き続き変化しました。バグバウンティプログラムによって、研究者たちは最も一般的なソフトウェアに深刻な欠陥がないか調べることに集中し、プライバシー規制により侵害は企業にとって以前にも増して対処コストのかかるものとなり、開発の早い段階で脆弱性を発見することに注力するようになった (いわゆる「シフトレフト」)結果、最も成熟したセキュリティプログラムを有する企業がよりセキュアなソフトウェアを生み出すようになりました。

一般的なソフトウェアにおける悪用可能な欠陥が見つかりにくくなり、それが報奨金引き上げの原因となっている欠陥の発見者に供与される報奨金は引き上げが継続しており、企業は報奨金引き上げの主な理由として、最も重大なタイプの欠陥、つまり一般的なソフトウェアや重要度の高いソフトウェアに存在する、リモート操作で悪用可能な問題の発見が困難になっていることを挙げています。たとえば、2017年に Googleは報奨金を引き上げ、「この数年で、重大度の高い脆弱性の特定がより困難になってきており、それらを発見するために研究者はより多くの時間を要しているため」と説明しています。9

2018年もこの傾向は継続しました。攻撃インテリジェンスおよび仲介会社である Zerodiumは、1月初旬に報奨金を少なくとも 3分の 1引き上げ、同社が最高額の報奨金を提示している、Appleの iOSでリモート操作により悪用可能な「ゼロタッチ」の攻撃に対する報奨金を 150万 USドルから 200万 USドルに引き上げました。10

また、ソフトウェア企業は、過去 2年間でソフトウェアの欠陥に対する報奨金を若干引き上げています。たとえば、Microsoftは現在、同社の最も重要なサービスのアカウント乗っ取りを可能にする脆弱性に対して最高 10万 USドル、同社の Hyper-V仮想コンピューティングおよびクラウドホスティングインフラストラクチャソフトウェアのリモート実行の問題に対して最高 25万 USドルを支払うとしています 11。Microsoftは2017年に報奨金を増額しており、緩和策と防御の報奨金を 15万 USドルから 20万 USドルに増額しました 12。Googleのソフトウェアとサービスに含まれる最も重大な脆弱性については、同社から 31,337USドルが支払われます。13

Microsoftでは、そのMicrosoft Security Response Center (MSRC)に報告される脆弱性の数が着実に増加している一方で、同時に、パッチ適用後 30日以内に悪用された脆弱性は減少しています。最新の利用可能なデータである 2017年には、398件の脆弱性のうち 30日以内に悪用されたのは 15件 (4%未満 )であったと、同社は 2018年 6月のブログ記事で述べています 14。

しかし、Kenna Securityのデータ 15によると、企業環境で発見された脆弱性の 4分の 3以上は 1年以上前のものです。

__________

8 ”On Pace To Break 20k Mark For Disclosed Vulnerabilities.” Risk Based Security. 2018-11-19. Web. www.riskbasedsecurity.com/2018/11/on-pace-to-break-20k-mark-for-disclosed-vulnerabilities/.

ﾠ9 Armour, Josh. “VRP news from Nullcon.” Google Security Blog. 2017-3-2. Web. https://security.googleblog.com/2017/03/vrp-news-from-nullcon.html.

10 https://zerodium.com/program.html

11 www.microsoft.com/en-us/msrc/bounty?SilentAuth=1

12 https://blogs.technet.microsoft.com/msrc/2017/07/26/announcing-the-windows-bounty-program/

13 www.google.com/about/appsecurity/reward-program/index.html

14 https://blogs.technet.microsoft.com/srd/2018/06/21/announcing-changes-to-microsofts-mitigation-bypass-bounty/

15 Cyentia Institute. “Prioritization to Prediction—Volume 2: Getting Real About Remediation.” Kenna Security. 2019-1-22. PDF. https://resources.kennasecurity.com/research-reports/prioritization-to-prediction-getting-real-about-remediation.


https://www.riskbasedsecurity.com/2018/11/on-pace-to-break-20k-mark-for-disclosed-vulnerabilities/





https://security.googleblog.com/2017/03/vrp-news-from-nullcon.html




https://zerodium.com/program.html

https://zerodium.com/program.html

https://www.microsoft.com/en-us/msrc/bounty?SilentAuth=1



https://blogs.technet.microsoft.com/msrc/2017/07/26/announcing-the-windows-bounty-program/






https://www.google.com/about/appsecurity/reward-program/index.html



https://blogs.technet.microsoft.com/srd/2018/06/21/announcing-changes-to-microsofts-mitigation-bypass-bounty/






https://resources.kennasecurity.com/research-reports/prioritization-to-prediction-getting-real-about-remediation







8

欧州の一般データ保護規則に基づき初の制裁金が科せられる他の国でも個人のプライバシーを保護するための法改正が行われ始めたため、EU内外の企業に対して制裁金が科せられるようになり、GDPRの効果が現れてきました。

昨年のレポートで、データセキュリティとGDPRの領域におけるアプリケーションセキュリティの重要性について説明しました 16。アプリケーション脆弱性のカテゴリをデータセキュリティに関連する 4つの論理的なグループ、(1)プライバシー侵害、(2)不十分なデータ保護、(3)アクセス違反、(4)機密データへの間接アクセス、に分類しました。これら 4つのグループはそれぞれ、直接または間接的に、個別にまたは他の脆弱性との組み合わせで、データセキュリティを損なう可能性のあるアプリケーション脆弱性の特定と対処に役立ちます。レポートでは、企業がアプリケーションセキュリティの全体的な検討をせずにデータセキュリティ対策を導入することは間違いであると説明しました。

GDPRに基づきこれまでに科せられた 4件の制裁金のうち、2件 (50%)はアプリケーションセキュリティの不備によるものです。GDPR違反の可能性があるとして British Airways17とFacebook18に対して行われている調査を考慮に入れると、アプリケーションセキュリティに関連する割合は 66%に跳ね上がります。以下でGDPRの各制裁金について説明しますが、この最初のGDPR違反で発見されたソフトウェアの脆弱性には、4つのアプリケーション脆弱性カテゴリのうち、(1)プライバシー侵害、(2)アクセス違反、(3)機密データへの間接アクセス、の 3つが含まれていることが分かります。

最初の GDPRの制裁金 19は、2018年 7月にポルトガルの National Data Protection Commissionが国内の病院、Centro Hospitalar Barreiro Montijoに対して科したものでした。同病院は、職員が患者データに不正にアクセスしたため、40万ユーロの罰金を科せられました 20。この病院ではアクセス違反の脆弱性があり、かつデータの機密性と完全性を保護するための「適切な技術的および組織的な対策」を実行するというGDPR前文 78を遵守していないことが判明しました。使われていないユーザーアカウントを無効化する適切な組織的対策と手順を欠いていたため、不正ユーザーがアクセス可能な状態となり、システムと患者データの完全性が損なわれていたのです。また患者データに対する技術的対策またはアクセスポリシーの管理もなく、システムのすべてのユーザーが患者のカルテに無差別にアクセスできるようになっていました。

2件目の GDPR制裁金 21は、2018年 10月にオーストリアの Data Protection Authority (DPA)により、場外馬券売り場の所有者に対して科せられました。この制裁金は、公共の空間 (店舗前の歩道 )の大部分を録画していた事業者による違法なビデオ監視行為に対するものでした。22この制裁金の金額は 4,800ユーロとも、5,280ユーロ 23とも報告されています。店外への監視カメラ設置は、「公衆が利用可能なエリアで大規模に体系的な監視を行う」ことを禁止するGDPR第 35条に違反していました。また、そのカメラでビデオ監視を行っていることが明示されておらず、GDPRの透明性義務に違反していました。

__________

16 www.microfocus.com/media/report/application_security_research_update_report.pdf

17 https://ico.org.uk/about-the-ico/news-and-events/news-and-blogs/2018/10/ico-statement-in-response-to-british-airways-breach-announcement/

18 www.dataprotection.ie/en/news-media/press-releases/data-protection-commission-opens-statutory-inquiry-facebook

19 www.hipaajournal.com/first-hospital-gdpr-violation-penalty-issued-portuguese-hospital-to-pay-e400000-gdpr-fine/

20 https://iapp.org/news/a/first-gdpr-fine-in-portugal-issued-against-hospital-for-three-violations/

21 https://edpb.europa.eu/news/national-news/2018/first-austrian-fine-cctv-coverage-summary_en

22 https://digital.freshfields.com/post/102f39w/first-gdpr-fine-issued-by-austrian-data-protection-regulator

23 https://edpb.europa.eu/news/national-news/2018/first-austrian-fine-cctv-coverage-summary_en

https://www.microfocus.com/media/report/application_security_research_update_report.pdf





https://ico.org.uk/about-the-ico/news-and-events/news-and-blogs/2018/10/ico-statement-in-response-to-british-airways-breach-announcement/







https://www.dataprotection.ie/en/news-media/press-releases/data-protection-commission-opens-statutory-inquiry-facebook






https://www.hipaajournal.com/first-hospital-gdpr-violation-penalty-issued-portuguese-hospital-to-pay-e400000-gdpr-fine/





https://iapp.org/news/a/first-gdpr-fine-in-portugal-issued-against-hospital-for-three-violations/





https://edpb.europa.eu/news/national-news/2018/first-austrian-fine-cctv-coverage-summary_en





https://digital.freshfields.com/post/102f39w/first-gdpr-fine-issued-by-austrian-data-protection-regulator










9www.microfocus.com

この年の 3件目の GDPR制裁金は、ドイツのバーデン＝ビュルテンベルク州 LfDI24により、国内チャットアプリ会社 Knuddelsに対してプライバシー侵害で科せられました。このドイツのソーシャルメディア会社は、侵害によって 808,000件のメールアドレスとパスワードが流出したと報告しました。25パスワードは暗号化されていない状態 (つまり、プレーンテキスト )で保存されており、GDPR第 32条「処理の安全性」に違反していました。26盗まれたデータは、GDPR第 32条に記載されているようにデータの暗号化や仮名化を使用するだけで、悪用を防止することができます。2018年 11月 21日、ドイツDPAは同社に 20,000ユーロの制裁金を科しました。同社はすぐにDPAに通知したため、最高 1,000万ユーロの制裁金を免れました。GDPRは、企業にデータ侵害の発見から 72時間以内に監督機関に通知することを義務付けています。

2019年初め、フランス当局は Googleがユーザー情報を収集する方法の透明性に関して、GDPR前文 58に規定されている透明性の原則要件を満たしていなかったとして、同社に対し、過去最高の GDPR制裁金を科しました。27「透明性の欠如、不十分な情報、広告のパーソナライズに関する有効な同意の欠如」について 5,000万ユーロ (約 5,700万 USドル )の制裁金が科せられました。28当局は Googleが同社のデータ収集を通じてユーザーの私生活がどの程度暴露されるかを適切に開示していなかったと認定しました。

この制裁金は、許容される最大の制裁である収益の 4%と比較すれば控えめなものですが、この決定は、データ収集がより慎重に行われなければならず、データ収集のビジネスモデルを欧州法の適用下で機能させるには大きな変更が必要になる可能性があることをテクノロジー業界に示すものとなっています。29

以下に示すのは、現在進行中の 2件の GDPRの調査で、データセキュリティに関連しており、機密データへの間接アクセスの例であるため、アプリケーションセキュリティの領域に該当します。

1件目は、英国個人情報保護監督機関 (Information Commissioner’s Office、ICO)が、2018年 9月のBritish Airwaysによる違反行為 30について、GDPR非準拠を理由に進めている調査です。この違反は、同航空会社の決済ページにあるクロスサイトスクリプティング (XSS)の脆弱性が原因でした。この脆弱性がハッカーによって悪用され、約 38万件のトランザクションからクライアントの財務情報が盗まれました。これは、ソフトウェアアプリケーションの設計、実装、デプロイメントにおける欠点や欠陥が機密データへの間接アクセスを可能にし、システムとデータのプライバシーを損なう可能性があることを示す、もう一つの例です。

2件目は、Facebookの「View As」の機能 31に関するデータ侵害のインシデントについて、同社が受けている調査です。このデータ侵害には、サイトのアクセストークンの不適切な実行と実装に関連する 3つの個別の脆弱性が関わっていました。つまり、それぞれの脆弱性は個別には機密データの流出に至らなかったかもしれませんが、3つの脆弱性が重なったことで機密データへの間接アクセスにつながっており、改めて、アプリケーションセキュリティと脆弱性評価を含め、プライバシーとセキュリティのコンプライアンスを満たすことの重要性が示唆されています。

__________

24 https://edpb.europa.eu/news/national-news/2018/baden-wuerttemberg-supervisory-authority-issues-first-german-gdpr-fine_en

25 https://iapp.org/news/a/germanys-first-fine-under-the-gdpr-offers-enforcement-insights/

26 https://gdpr-info.eu/27 Satariano, Adam. “Google Is

Fined $57 Million Under Europe’s Data Privacy Law.” The New York Times. 2019-1-21. Web. www.nytimes.com/2019/01/21/technology/google-europe-gdpr-fine.html.

28 https://edpb.europa.eu/news/national-news/2019/cnils-restricted-committee-imposes-financial-penalty-50-million-euros_en

29 Cuthbertson, Anthony. “Google GDPR Fine Shows �Embarrassing� Extent of How Firms Misuse People’s Data.” The Independent. 2019-1-22. Web. www.independent.co.uk/life-style/gadgets-and-tech/news/google-gdpr-fine-eu-data-privacy-cnil-amazon-apple-a8740191.html.

30 “Statement Update in Response to British Airways Breach.” ICO. https://ico.org.uk/about-the-ico/news-and-events/news-and-blogs/2018/10/ico-statement-in-response-to-british-airways-breach-announcement/

31 https://gdpr.eu/the-gdpr-meets-its-first-challenge-facebook/


https://edpb.europa.eu/news/national-news/2018/baden-wuerttemberg-supervisory-authority-issues-first-german-gdpr-fine_en







https://iapp.org/news/a/germanys-first-fine-under-the-gdpr-offers-enforcement-insights/




https://gdpr-info.eu/

https://www.nytimes.com/2019/01/21/technology/google-europe-gdpr-fine.html




https://edpb.europa.eu/news/national-news/2019/cnils-restricted-committee-imposes-financial-penalty-50-million-euros_en







https://www.independent.co.uk/life-style/gadgets-and-tech/news/google-gdpr-fine-eu-data-privacy-cnil-amazon-apple-a8740191.html















https://gdpr.eu/the-gdpr-meets-its-first-challenge-facebook/




10

DEVOPSの自動化がオープンソースコンポーネントの脆弱性を低減Micro Focusの最近のレポート「State of Application Security in the Enterprise report」32によると、企業はアプリケーションセキュリティを継続して重視しており、企業の 30%が脆弱性のないビジネスクリティカルなアプリケーションの提供を最大の課題として挙げています。また 21%の企業が、セキュリティプログラムの適用範囲を最大の課題と考えています。全体では 72%の企業が、アプリケーションセキュリティに対し、12か月前と比較して少なくともやや高い関心を寄せています 33。

アプリケーションセキュリティが重視されているのは、攻撃者がセキュリティ問題を迅速に修正しない企業に対する圧力を強めているためです。たとえば、オープンソースコンポーネントの脆弱性が公開されてから、その脆弱性が悪用されるまでの日数は、2006年の 45日から 2017年には 3日に短縮されています。34

さらに、オープンソースのダウンロードの 8件に 1件には既知の脆弱性が含まれています 35。

これらの問題とその他のセキュリティ問題を解決するために、企業は DevOpsに移行しています。企業の約4分の 3が開発をDevOpsモデルに移行済みか、または移行を検討しています 36。企業の 58%、つまり半数以上が少なくとも開発サイクルの全段階でソフトウェアの脆弱性をテストしており、30%の企業はコード変更のたびにテストを実施しています 37。

ソフトウェアサプライチェーンへの攻撃ソフトウェアサプライチェーンは企業にとって引き続き大きな懸念となっています 38。たとえば、2012年に米国議会は、米国のネットワークへの侵入に利用されることを懸念して、通信業者が中国の HuaweiとZTEから機器を購入することを阻止しました。そして 2017年、セキュリティ企業の Avastは、最近買収した CCleanerユーティリティが、開発中にネットワーク機器ハードウェアと企業向けソフトウェアの少なくとも20のメーカーを標的としたマルウェアに感染したと警告しました 39。

最近のサプライチェーン攻撃のもう一つの標的は、オープンソースのエコシステムです。攻撃者は、たとえば、オープンソースソフトウェアのサプライチェーンを汚染することを目的とした活動を増やしていると推測されます。ソフトウェアセキュリティ企業の Sonatypeによると、2018年には少なくとも6件のインシデントがバックドアコードでオープンソースライブラリーを標的にしていました 40。

政府と業界が協力してサプライチェーンの完全性の問題に対処し、予め感染した製品が企業ネットワークや政府機関に侵入するリスクを緩和する必要があると、調査会社のMITREはその 2018年のレポートで結論付けています 41。このレポートでは、政府や民間産業がサプライチェーン攻撃からシステムを防御するために必要な 15の行動が推奨されています。

__________

32 “State of Application Security in the Enterprise.” Micro Focus.2019-1-30. PDF. p. 6. www.microfocus.com/en-us/assets/security/the-state-of-application-security-in-the-enterprise.

33 “State of Application Security in the Enterprise.” Micro Focus. p. 11.

34 “2018 State of the Software Supply Chain Report.” Sonatype. 2018-9-25. PDF. p. 5. www.sonatype.com/2018-state-of-the-software-supply-chain-report-wp.

35 “2018 State of the Software Supply Chain Report.” Sonatype. p. 3.



38 https://theintercept.com/2019/01/24/computer-supply-chain-attacks/

39 Lemos, Robert. “CCleaner Attack Targeted Telecoms, Network Hardware Providers.” eWEEK. 2017-9-22. Web. www.eweek.com/security/ccleaner-attack-targeted-telecoms-network-hardware-providers.

40 Sonatype, “2018 State of the Software Supply Chain Report.” pp. 8-10.

41 Nissen Chris, et al. “Deliver Uncompromised: A Strategy for Supply Chain Security and Resilience in Response to the Changing Character of War.” MITRE. 2018-8-8. PDF. www.mitre.org/sites/default/files/publications/pr-18-2417-deliver-uncompromised-MITRE-study-8AUG2018.pdf.

https://www.microfocus.com/en-us/assets/security/the-state-of-application-security-in-the-enterprise





https://www.sonatype.com/2018-state-of-the-software-supply-chain-report-wp




https://theintercept.com/2019/01/24/computer-supply-chain-attacks/




https://www.eweek.com/security/ccleaner-attack-targeted-telecoms-network-hardware-providers






https://www.mitre.org/sites/default/files/publications/pr-18-2417-deliver-uncompromised-MITRE-study-8AUG2018.pdf





11www.microfocus.com

National Vulnerability Databaseの分析2018年に National Vulnerability Database (NVD)に報告された脆弱性の数は前年比 13%増となり、127%増となった 2017年の大幅な増加を維持しています。

脆弱性の報告件数が最も多かったのは、Google、Oracle、Microsoft、IBMの製品です (図 2を参照 )。全体では、NVDに報告された脆弱性の 39%を上位 10ベンダーが占めており、これは 2017年とほぼ同じでしたが、2016年および 2015年と比較して大幅に減少しています。

脆弱性が急増した理由重要な未解決の問題は、なぜ 2017年に報告された脆弱性の数が前年の 2倍以上に増加し、その数が2018年もさらに増加しているのかということです。

hp f5

goog

le

orac

le

mic

roso

ft

ibm

cisc

o

qual

com

m

adob

e

moz

illa

foxit

softw

are

huaw

ei

appl

e

redh

at

aqac

he

jenk

ins

sap

linux

debi

an

wire

shar

k

0

800

700

600

500

400

300

200

100

2018年にNVDへ報告された脆弱性で測定されたベンダー上位20社

798891110

11515

0

151

16018

0

18822

6247

353

374

37542

4

607

704

71377

0

報告された

CVE

図 2.ベンダー別 CVE属性



12

脆弱性が最も多く報告されているベンダーの上位は Google、Oracle、Microsoftでしたが、この増加は研究者が大手ソフトウェア企業に重点を置いたことによるものではないと見られます。下の 2つのチャートを見ると、上位 100製品または上位 10ベンダーの製品で発見された脆弱性の割合には若干の増加傾向が見られますが (図 3、図 4を参照 )、この傾向は過去 2年間維持されていませんでした。上位 10社のリストに含まれるベンダーは年によって変わっています。たとえば、Appleは 2017年には最も多くの脆弱性報告があったベンダーの上位 10社に入っていましたが、2018年には入っていません 42。さらに、ベンダーの数は、少ないときは 2011年の 910社から、多いときは 2018年の 2,976社まで、ばらつきがあります。

__________

42 「上位」の製品またはベンダーは、報告のあった脆弱性の数で測定されています。

2009 2010

上位100

その他

2011 2012 2013 2014 2015 2016 2017 2018

上位100製品に起因する脆弱性の割合

年

シェア

0

100%

80%

60%

40%

20%

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018

年

0

100%

80%

60%

40%

20%

上位100

その他

上位10社のベンダーに起因する脆弱性の割合

シェア

図 3.上位 100製品によるCVE発生範囲の割合 (1年ごとの製品数は図 5を参照 )

図 4.上位 10社のベンダーによるCVE発生範囲の割合


ある年の脆弱性が発見された製品の数と、その年に報告された脆弱性の総数の間には、強い相関があります (図 6を参照 )。このため、なぜ業界で脆弱性が急増したのかと尋ねるよりも、なぜより多くの製品が研究者たちの研究対象になったのか、という質問の方が適切かもしれません。

1,97

2

7,15

9

3,64

0

2,28

4 2,76

8 3,54

0

2,53

7

4,94

0

2,34

3

6,02

8

2009 20100

7,000

8,000

6,000

5,000

4,000

3,000

2,000

1,000

2011 2012 2013 2014 2015 2016 2017 2018

脆弱性の影響を受けた製品の数(2009～2018年)

年

製品数

図 5.長年にわたりCVEの影響を受けた製品

14

0913

12

16 15

1011

17

18

製品数

実施年

脆弱性数と製品数の比較(2009～2018年)

1,0000 2,0000

3,000 4,000 5,000 6,000 7,000 8,000

14,000

18,000

16,000

12,000

10,000

8,000

6,000

4,000

2,000

脆弱性の数

図 6.CVEと製品の比較



14

1つの答えとしては、研究者が自動化の利用を増やして関心を広げ、より多くの製品でより多くの種類のセキュリティ上の弱点を探すようになったことが、より多くの脆弱性の発見につながった可能性があります (図7を参照 )。2017年以前は、すべての脆弱性の 80%以上が、共通脆弱性タイプ一覧 (CWE：Common Weakness Enumeration)のフレームワークにより分類されたコーディング欠陥の 10のカテゴリに含まれていました。しかし、過去 2年間は 80%のしきい値を超えるためにより多くの CWEが必要となりました。2017年には脆弱性の 80%を占めるために 15の CWEカテゴリが必要でしたが、2018年には 19のCWEに拡大しました (詳細は次のセクションを参照 )。

これは、報告された脆弱性の爆発的増加が、脆弱性分類のより広範囲を対象とする、より幅広い研究の取り組みに起因するものであることを示唆しています。

脆弱性のタイプにおける傾向 2017年と2018年は報告された脆弱性の数が大幅に増加したため、過去 2年間は最も一般的な CWEで発見された脆弱性の数でも記録を更新しています。脆弱性の数で測定された上位 19の CWEカテゴリのうち15のカテゴリがこの期間に発生したことは驚くべきことではありません (次ページの図 8を参照 )。

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018

年

上位100

その他

上位10個のCWEに起因する脆弱性の割合

シェア

0

100%

80%

60%

40%

20%

図 7.上位 10個の CWEに起因する脆弱性の割合


図 8.この 10年間で特に頻繁に発生した CWE

この10年間で特に多く見られたソフトウェアの脆弱性

2018 2017 20092010201120122013201420152016

CWE-20

CWE-22

CWE-79

CWE-89

CWE-94

CWE-125

CWE-190

CWE-254

CWE-310

CWE-399

CWE-284

CWE-119

CWE-189

CWE-200

CWE-264

CWE-287

CWE-352

CWE-416

1,384

1,954

150

554

688

237

1,063

275

318

492

497

1,712

9

1,240

807

235

426

401

318

309

819

322

0

0

0

1

90

233

319

947

563

158

155

433

207

113

0

0

303

585

260

0

0

0

0

70

236

272

515

533

156

155

347

75

75

0

1

952

1,463

87

431

191

237

1,365

80

379

264

498

2,510

46

1,377

1,186

183

310

272

328

546

472

23

85

48

150

407

52

179

78

89

1,162

42

604

621

47

81

110

70

391

726

50

3

1

104

147

88

346

141

213

987

123

587

566

33

240

10

1

555

1,026

191

1

2

7

20

1,583

258

197

294

766

114

346

725

143

243

8

2

500

616

139

0

2

0

2

129

288

103

145

759

145

249

576

107

120

15

0

369

721

135

4

1

0

3

99

310

118

236

723

150

218

604

98

153

8

0

386

454

101

0

0

1

0

62

375

105

289

661

131

293

281

55

55

0

0CWE-476

特定のCWEの脆弱性が最も多かった年

特定の年に脆弱性が最も多かったCWE

注：青枠のボックスが各年に1つあり(列)、緑のボックスがCWEごとに1つあります(行)。ただし、2年分を合わせて最大脆弱性数を出しているCWE-254は除きます。

CWE-20

CWE-22

CWE-79

CWE-89

CWE-94

CWE-125

CWE-190

CWE-254

CWE-310

CWE-399

CWE-284

CWE-119

CWE-189

CWE-200

CWE-264

CWE-287

CWE-352

CWE-416

不適切な入力検証

Webページ生成時の入力の不適切な無効化(「クロスサイトスクリプティング(XSS)」)

コード生成時の不適切な制御(「コードインジェクション」)

境界外読み取り

整数オーバーフローまたはラップアラウンド

(カテゴリ) 7PK - セキュリティ機能

不適切なアクセス制御

(カテゴリ)暗号化の問題

(カテゴリ)リソース管理エラー

制限付きディレクトリーへのパス名の不適切な制限(「パストラバーサル」)

SQLコマンドで使用される特殊要素の不適切な無効化(「SQLインジェクション」)

メモリーバッファー境界内の操作の不適切な制限

(カテゴリ)数値エラー

情報漏洩

(カテゴリ)認可、権限、アクセス制御

不適切な認証

クロスサイトリクエストフォージェリ(CSRF)

解放済みメモリの使用

NULLポインターデリファレンスCWE-476



16

上のチャートに示す CWEは、CVE Detailsが実施したテキスト分析と一致しています。43たとえば、CWE-79カテゴリ、Webページ生成時の入力の不適切な無効化 (「クロスサイトスクリプティング (XSS)」)は、2018年に 1,954件と脆弱性の数が最多となり (図 9を参照 )、CVE Detailsがその年について指摘した 2,004件の脆弱性とほぼ一致しています。

CVE Detailsのデータによると、2018年はコード実行、XSS、バイパス、CSRFでトップ、2017年はDDoS、オーバーフロー、ディレクトリートラバーサルでトップとなっています。2015年、2014年、2008年、2006年は、それぞれテキストベースのカテゴリ1つずつでトップとなりました。

■ DoS (2017年 )

■ コード実行 (2018年 )

■ オーバーフロー (2017年 )

■ メモリー破損 (2015年 )

■ SQLインジェクション (2008年 )

■ XSS (2018年 )

■ ディレクトリートラバーサル (2017年 )

■ バイパス (2018年 )

■ 情報取得 (2014年 )

■ CSRF (2018年 )

■ ファイルインクルージョン (2006年 )

__________

43 “Vulnerabilities by Type.” CVE Details.閲覧日 : 2019-2-8. Web. www.cvedetails.com/vulnerabilities-by-types.php.

1954

1712

1384

1240

1063

807

688

554

497

492

426

414

401

318

318

300

278

275

245

237

cwe-

79

cwe-

119

cwe-

20

cwe-

200

cwe-

284

cwe-

264

cwe-

190

cwe-

125

cwe-

89

cwe-

22

cwe-

352

None

cwe-

416

cwe-

476

cwe-

399

cwe-

77

cwe-

787

cwe-

310

cwe-

255

cwe-

254

0

2000

1,500

1,000

500

2018年にNVDへ報告された脆弱性で測定されたベンダー上位20社

報告されたCVE

図 9.2018年に特に頻繁に発生した CWE

https://www.cvedetails.com/vulnerabilities-by-types.php




オープンソースソフトウェアは脆弱性の数で継続してトップを維持オープンソースソフトウェアは継続して脆弱性の報告件数が最多であり、Debian Linux、Android、Ubuntu Linux、そして 3種類の Red Hat Enterprise Linux製品が、報告されている脆弱性件数の上位 4製品となっています (図 10を参照 )。オープンソースのブラウザー Firefoxは、2018年に 333件の脆弱性が報告され、製品中第 5位 (チャートでは第 7位 )となりました。

各製品について報告された脆弱性の数を分析する上で重要な問題は、類似したコードベースの脆弱性の重複によって実際よりも多い数が報告されていないかどうかです。これはある程度、事実です。たとえば、2018年には CVEと製品の異なる組み合わせが 36,436件あり、これは報告された 16,517の CVEと、その年に National Vulnerability Databaseによって記録された 7,159の固有製品の両方を大幅に上回っています。

図 10.CVEの数で見た上位 20個のアプリケーション

上位20個のアプリケーションの脆弱性の数(2018年)

955debian linux

611

496

394

378

369

333

286

286

278

報告されたCVE

0 1000800600400200

278

255

253

253

252

240

240

235

240

224SD 820ファームウェア

android

ubuntu linux

エンタープライズLinuxサーバー

エンタープライズLinuxワークステーション

エンタープライズLinuxデスクトップ

firefox

acrobat dc

acrobat reader

SD 210ファームウェア

acrobat reader dc

acrobat

windows 10




windows server 2016





18

一部の製品は CVEが両方のコードベースに影響を与えていて、かなりの重複があります。たとえば、図11ではRed Hat LinuxとDebian Linuxに301件の脆弱性が共通していますが、Debian LinuxとLinuxカーネルベースの Android OSでは 5件のセキュリティ問題しか共通していないことが示されています。

逆に、Microsoft Windowsの異なるバージョンなど、一部のコードベースは、同じセキュリティ問題が多数共通しています。図 12は、Windows 10がWindows 7と137件、Windows Server 2012と153件の問題を共有していることを示しています。

Linux配布パッケージ間のCVEの重複

Red Hat Linux

Android

Debian Linux

610

5

649 301

96

図 11.Linux配布パッケージに共通するCVE

図 12.Windowsの各バージョンに共通するCVE

Windowsバージョン間のCVEの重複

95

7

23 3

6

130

18

Windows Server 2012

Windows 7

Windows 10


クローズドソースソフトウェアの中で広く利用されているアプリケーションに最多の脆弱性が存在クローズドソースソフトウェアに関して、脆弱性の研究は、最も広く利用されているアプリケーションとOSに重点を置いているようです。脆弱性の報告が最も多いソフトウェア製品の上位 5つはすべてオープンソースのエコシステムからの製品でしたが、続く5製品のうち4製品はクローズドソースのものでした。異なるバージョンの Adobe Acrobatが第 6位となり、異なるバージョンのMicrosoft Windowsが第 7位でした。

脆弱性の報告が最も多いソフトウェアの第 8位と第 9位は、Qualcommの Snapdragonファームウェアと、Foxit Softwareの Phantom PDFリーダーという、比較的知名度の低い 2製品でした。オープンソースの電子メールクライアント、Mozilla Thunderbirdが第 10位でした。

図 13.2018年の CVE開示数が多いOS上位 10個

図 14.2018年の CVE開示数が多いアプリケーション上位 10個

2018年にNVDへ報告された脆弱性で測定されたOS上位10個

報告されたCVE

0 1000800600400200

955debian linux

611android

496ubuntu linux

394エンタープライズLinuxサーバー

255windows 10

253SD 210ファームウェア

240windows server 2016

163windows 8.1

170Linuxカーネル

162windows server 2012

上位10個のアプリケーションの脆弱性の数(2018年)

報告されたCVE

0 350300200 25015010050

333firefox

286acrobat dc

223phantompdf

187foxit_reader

175thunderbird

161edge

160chrome

108mysql

108intelligent_management_centre

95chakracore



20

Appleは公表されている脆弱性の報告件数を減らすことに成功しており、iOSでは 125件、Mac OS Xでは 107件の問題が報告され、2017年の iOSで 386件、Mac OS Xで 297件の問題が報告された状況と比較して、大幅に改善されています。

重大な脆弱性の増加の有無共通脆弱性評価システム (Common Vulnerability Scoring System、CVSS)は、脆弱性の重大度を表すためによく使用される方法です。この指標は研究により多くの問題点が指摘されていますが、脆弱性の潜在的影響を評価するための最も一般的な方法であることに変わりはありません。2018年は、CVSSが 7.0以上と定義された、重大度の高い脆弱性の数が、絶対数および報告された脆弱性全体に占める割合の両方において、前年比で減少しました。しかし全般的には、2017年と2018年の両方で、すべての重大度レベルで脆弱性が増加していますが、重大度が中程度の脆弱性が急増しています。

2018年には、高重大度の脆弱性の割合が 26%にまで低下し、4年間で最低の水準、かつ 10年間で 2番目に低い水準となりました。逆に、重大度が中程度の脆弱性の割合は、2009年の 48%から 59%に増加し、重大度が低い脆弱性は、2009年の 5%から 2018年には 15%に増加しています。

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018

数

年

0

10,000

8,000

6,000

4,000

2,000

高(7～10)

中(4～7)

低(4未満)

CVSSスコア別の脆弱性(2009～2018年)

図 15.年別に見た CVSS重大度の分布


ソフトウェア分析このセクションでは、26以上のプログラミング言語の分析が可能な技術と、900以上の弱点タイプに関する知識に基づいて、100万以上の APIを網羅し、11,000を超えるアプリケーションで検出されたソフトウェアの脆弱性分析について説明します。基礎となるデータは、アプリケーションにおけるセキュリティの脆弱性を発見するための動的、静的、手動の分析機能を提供する、Micro Focus Fortify on Demand (FoD)プラットフォームから取得しています。

これらの異なるアプローチから得られた結果は、Seven Pernicious Kingdoms (7PK)044としても知られる、Fortify Software Security Taxonomyの共通用語の下で標準化されています。この分類法は、開発者による修正 (つまり、弱点を修正するためにどのような根本的変更が必要か )の観点から弱点を説明することを目的としています。

本レポートで分析した FoDデータのサブセットは、2017年 10月 31日から 2018年 10月 30日の間に収集されました。Webアプリケーションデータは11,000を超えるアプリケーションで構成され、モバイルデータセットは 700を超えるアプリケーションで構成されていました。

図 16.過去 10年間の CVSS重大度別の割合

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018

年

年別に見たCVSSスコアの分布(2009～2018年)高(7～10)

中(4～7)

低(4未満)

0

100%

80%

60%

40%

20%

シェア

__________

44 https://vulncat.fortify.com


https://vulncat.fortify.com


22

領域別Webアプリケーションの結果

88%

0

90%

100%

80%

70%

60%

50%

40%

30%

20%

10%

Webアプリモバイルアプリ

年

致命的/重大度「高」の問題が1つ以上あるテスト済みアプリケーションの割合(%)

79%

80%

89%

68%

2018

2017

2016

79%

アプリ�%�

領域別に見たWebアプリケーションの脆弱度

アプリ数�%�

0 100%90%50% 60%40% 70% 80%30%20%10%

18%エラー

27%時間と状態

35%APIの悪用

36%コード品質

60%入力検証と表現

70%カプセル化

78%

20%

28%

37%

35%

57%

70%

81%環境

セキュリティ機能93%

94%

2018

2017

図 17.領域別に見たWebアプリケーションの脆弱性の分布 (2017/2018年 )

テスト済みWebアプリケーション 5つのうち4つに、致命的または重大度「高」の問題が 1つ以上ありました。


前のページの図 17は、8つ (7+1)の領域 (kingdom)にわたる脆弱性の分布を示しています。この分布は、ソフトウェアの弱点の原因となるコーディングパターンが、前年比でかなり類似していることを反映しています。図 18は過去 4年間の傾向を示しています。「入力検証と表現」は継続して 4番目に多い領域となっており、影響を受けたアプリケーションの数は 50%から 60%の間で推移しています。過去 4年間で最大の変化は、「エラー」の領域に含まれる弱点を持つアプリケーションが大幅に減少 (47%から 18%に減少 )したことです。同期間、「コード品質」(17%から 36%)と「APIの悪用」(16%から 35%)の問題は約 2倍になっています。

「入力検証と表現」の脆弱性は、すべての問題の中でも重大な問題とみなされる傾向にあります。このカテゴリにおける 3%の増加は大きいと考えられ、より詳細な分析によると、「パスマニュピレーション」と「サーバーサイドリクエストフォージェリ」がこの増加の原因となったトップのカテゴリであることが示されています(報告された問題がそれぞれ前年比 8%と7%の増加 )。先に図 8で示したように、もう一つのパス関連カテゴリである「パストラバーサル」も、2018年に報告された CVEが大幅に増加しました。「セキュリティ機能」は弱点が 1%増加したのみで、全体的に比較的変化がなかった一方で、「セキュアでないトランスポート：チャネルミキシング」の問題は、2017年の 15%から 2018年は 30%に倍増しました。「クッキーセキュリティ」問題は、「クッキーセキュリティ：HTTPOnly属性未設定」と「クッキーセキュリティ：SSLでクッキーを送信しない」がそれぞれ 8%と7%減少しています。

図 18.領域別に見たWebアプリケーションの脆弱性の分布 (過去 4年間 )

アプリ数�%�

0 100%90%50% 60%40% 70% 80%30%20%10%

エラー

時間と状態

APIの悪用

コード品質

入力検証と表現

カプセル化

環境

セキュリティ機能

2018

2017

2016

2015

領域別に見たWebアプリケーションの脆弱性の分布(過去4年間)



24

領域別モバイルアプリケーションの結果

図 19に示すように、モバイルアプリケーションの脆弱性傾向も昨年と変わらず、「コード品質」関連の問題が同程度に増加し、「時間と状態」関連の問題が顕著に減少しています。特定の状況下で重大なセキュリティ脆弱性の原因となり得る「Nulllデリファレンス」などのコード品質の問題は、2017年から 9.56%増加しました。「アカウント管理：不適切なアカウントロックアウト」の問題は 7%減少し、これが時間と状態に関連する問題の全体的な減少の主な原因となっており、攻撃者が総当たり攻撃を使用してアプリケーションを侵害するために利用される可能性のあるミスを開発者が回避していることが示唆されています。

図 19.領域別に見たモバイルアプリケーションの脆弱度

領域別に見たモバイルアプリケーションの脆弱度

アプリ数�%�

0 100%60%40% 80%20%

11%エラー

23%時間と状態

52%APIの悪用

56%コード品質

57%

68%

79%

13%

33%

54%

48%

62%

68%

82%

環境

セキュリティ機能96%97%

2018

2017

入力検証と表現

カプセル化


Webアプリケーションにおける上位の脆弱性

図 20にWebアプリケーションにおける脆弱性の上位の傾向を示しています。「システム情報の漏洩：外部」は、このカテゴリに対して脆弱性のあるアプリケーションが 3%減少したにもかかわらず、今年もトップカテゴリのままとなっています。「クッキーセキュリティ：HTTPOnly属性未設定」は、2017年のアプリケーションと比較して脆弱性のあるアプリケーション数が8%と顕著に減少し、第10位に順位を落としました。「(セキュアでないトランスポート：HSTS未設定」も減少しましたが、順位を下げるには至りませんでした。「セキュアでないトランスポート：脆弱な SSLプロトコル」は今年、脆弱性のあるアプリケーションが大幅に減少した重要なカテゴリです（アプリケーション数が昨年より7%減少）。この急激な認識の高まりは、PCIデータセキュリティスタンダード (PCI DSS)が 2018年 6月までにトランスポートレイヤーセキュリティ (TLS)プロトコルの上位バージョンへの移行を義務付けたことに一部起因していると考えられます。この指令は、TLS1.0を脆弱であるとみなし、企業が TLS1.2に移行することを推奨しているNIST SP 800-52 Revision 1のコンプライアンスをサポートしています。さらに、2014年 1月からNIST SP 800-131Aはデジタル署名における SHA-1の使用を非推奨としており、これは実質的に TLS1.1がいかなる場合も強力と見なされなくなったことを意味しました。しかし、どの規格でも TLS1.1の使用を明示的に「脆弱」とはしていません。より脆弱な SSLプロトコル (SSLv2や SSLv3など )を、少なくとも 2018年のある時点で、サポートしているアプリケーションを調査し、その結果を 2017年に報告されたものと比較しました。

図 20.Webアプリケーションの脆弱性上位 10項目

Webアプリケーションの脆弱性上位10項目(2018年 vs 2017年)

34%クッキーセキュリティ：HTTPOnly属性未設定

34%キャッシュ管理：セキュアでないポリシー

36%Webサーバーの誤設定：保護されていないディレクトリー

36%hiddenフィールド

39%

40%

42%

42%

31%

37%

35%

36%

47%

45%

クロスフレームスクリプティング

クッキーセキュリティ：SSLでクッキーを送信しない 51%

44%

2018

2017

セキュアでないトランスポート：脆弱なSSLプロトコル

プライバシー侵害：オートコンプリート

アプリ数�%�

0 70%60%40%30% 50%20%10%

48%51%

システム情報の漏洩：外部 58%

55%

セキュアでないトランスポート：HSTS未設定



26

表 2は、2017年と比較して TLS1.0とTLS1.1の全体的な使用量が減少したことを示しており、これはこれらのシステムがより上位の TLS1.2と新たに標準化された TLS1.3に移行したことを示唆している可能性があります。しかし、PCIのガイドラインを十分に満たすアプリケーションはごくわずかです。

SSLv2 SSLv3 TLS1.0 TLS1.1 TLSV1.1のみ TLSV1.1とTLS1.0

2017

2018

37%

32%

6%

8%

43%

38%

47%

34%

4%

2%

1%

1%

トランスポート層プロトコルの使用状況（2017年 vs 2018年)

表 2.トランスポート層プロトコルの使用状況（2017年 vs 2018年 )

表 3.セキュアなトランスポートと通信の完全性を実現するためのカテゴリ

アプリケーション数(2018年)カテゴリ：サブカテゴリアプリケーション数(2017年)

クッキーセキュリティ：SSLでクッキーを送信しない

クッキーセキュリティ：SSLでセッションクッキーを送信しない

セキュアでないデプロイメント：OpenSSL

セキュアでないSSL：サーバーID検証が無効

セキュアでないトランスポート：HSTS未設定

セキュアでないトランスポート：脆弱なSSLサイファ

セキュアでないトランスポート：公開鍵ピンニングの欠如

セキュアでないトランスポート：不十分なHSTS有効期限

セキュアでないトランスポート：SSLv3/TLS再交渉ストリームインジェクション

セキュアでないトランスポート：公開鍵ピンニングの誤設定

セキュアでないトランスポート：App Transport Securityが無効

セキュアでないトランスポート：OAuth通信チャネル

クッキーセキュリティ：SSLでCSRFクッキーを送信しない

セキュアでないSSL：範囲が広すぎる証明書の信頼

セキュアでないSSL：Androidホスト名検証が無効


セキュアでないトランスポート：チャネルミキシング

セキュアでないトランスポート：Perfect Forward Secrecyの欠如

セキュアでないトランスポート：不十分なDiffie Hellmanの強度

セキュアでないトランスポート：TLS_RSA

セキュアでないトランスポート：セキュアなセクションアクセスがSSL非対応

セキュアでないトランスポート：HSTSがサブドメインを含んでいない

頻繁に悪用される：脆弱なSSL証明書

不十分なエラー処理：SSL Exceptionの未処理

Webサーバーの誤設定：SSL証明書のホスト名の食い違い

Webサーバーの誤設定：SSL証明書の期限切れ

51%

2%

0%

2%

1%

0%

47%

15%

5%

該当なし

0%

2%

1%

51%

22%

48%

2%

1%

0%

0%

0%

4%

0%

12%

2%

0%

44%

2%

0%

4%

4%

3%

48%

31%

15%

2%

0%

4%

0%

40%

30%

4%

2%

1%

0%

0%

0%

4%

0%

6%

3%

0%


32%のアプリケーションが依然として TLS1.0とTLS1.1をサポートしており、これは 2017年と比較してわずか 5%の減少となっています。FoDのデータは現在、脆弱と見なされていないプロトコルを追跡していないため、ここでは TLS1.2に関するデータを収集することはできません。さらに、スキャンされたアプリケーションの多くは、PCI規格に準拠する要件がない可能性があります。

SSL関連の問題が継続して注目されており、2018年に PCIの指令が発効することを踏まえ、HTTPでの暗号化通信提供に関連するすべてのセキュリティカテゴリの状況も調査しました。2017年と比較して、これらの問題は累積でわずか 3%の減少に留まりました。前のページの表 3は、2018年と2017年のカテゴリ一覧と、それぞれの脆弱性のあるアプリケーション数を割合で示しています。これらの問題のうち少なくとも 1つに対して脆弱なアプリケーションの累積数は、2018年が 70%、2017年が 73%となっています。開発者によるクッキーセキュリティの確保とセキュリティヘッダーの使用におけるミスは明らかに少なくなりましたが、強力な暗号スイートを設定せず、HTTPSとHTTPチャネルが同一ドメイン上で混在することを許可することで、セキュアなクッキーフラグとセキュリティヘッダーの使用で得た利益の一部が帳消しになる可能性があります。

次に、脆弱性カテゴリの上位 10項目を、致命的または重大度の高いもののみで比較しました。

図 21.Webアプリケーションの致命的 /重大度「高」の問題 (2018年 vs 2017年 )

Webアプリケーションの致命的/重大度「高」の脆弱性上位10項目(2018年 vs 2017年)

15%ログ偽造

16%パスマニュピレーション

17%セキュアでないトランスポート：脆弱なSSLプロトコル

17%プライバシー侵害

19%

19%

20%

11%

8%

19%

13%

18%

15%

21%

クロスフレームスクリプティング

クロスサイトスクリプティング(XSS)：

反射型21%21%

2018

2017

パスワード管理：ハードコーディングされたパ

スワード

パスワード管理：設定ファイルにパスワードがある

アプリ数�%�

0 30%20%15% 25%10%5%

21%14%

NULLデリファレンス20%

24%

リリースされないリソース：ストリーム



28

前ページの図 21を見ると、2017年と比較して最も致命的および重大度の高い問題が大幅に増加していることが分かります。「セキュアでないトランスポート：脆弱な SSLプロトコル」の問題のうち、致命的な問題の件数は 2%減少しました。すべての脆弱なプロトコルの構成が同じように深刻であるとは限りません。たとえば、SSLv2はエクスプロイトが容易であるため、いかなる場合も回避すべきですが、TLS1.1はエクスプロイトを成功させるために多大な労力と計算リソースを要します。「パスマニュピレーション」の問題は今年 2倍の 16%に増加しており、致命的な「プライバシー侵害」の問題も大幅に増加しています。「セキュアでないトランスポート：脆弱な SSLサイファ」は、2017年の第 9位から 2018年は第 23位に順位を下げました。

モバイルアプリケーションにおける上位の脆弱性

2018年、モバイルアプリケーションでは 4つの新しいカテゴリの脆弱性が上位 10項目にランクインしました (図 22を参照 )。これらには、「セキュアでないトランスポート」、「セキュアでないトランスポート：App Transport Securityが無効」、「特権管理：Androidデータストレージ」、「プライバシー侵害」が含まれています。Webアプリケーションの脆弱性における傾向に続いて、モバイルアプリケーションでも SSLプロトコルの構成が改善されていました。上位 10項目の懸念事項はインジェクションの問題ではなく、アプリケー

モバイルアプリケーションの脆弱性上位10項目

34%セキュアでないトランスポート

34%プライバシー侵害：ジオロケーション

35%パスワード管理：Androidデータストレージ

36%プライバシー侵害

36%

37%

41%

28%

37%

29%

25%

34%

30%

50%

プライバシー侵害：HTTP GET

脆弱な暗号学的ハッシュ52%

49%

2018

2017

セキュアでないトランスポート：App Transport Securityが無効


アプリ数�%�

0 70%40%30% 50% 60%20%10%

50%56%

システム情報の漏洩：内部 58%

54%

セキュアでないストレージ：データ保護の欠如

図 22.モバイルアプリケーションの脆弱性上位 10項目 (2018年 vs 2017年 )


ションがデータを使用する際のプライバシー維持と、クライアントとサーバー間でのデータ転送時における強力な構成の選択を代表するものであることが分かります。長年にわたり入力インジェクション関連の問題が注目されてきましたが、ここ数年の傾向は攻撃者がどこに注力しているかを示しています。

図 23にモバイルアプリケーションにおける致命的および重大度の高い問題における傾向を示します。ここでも、データ転送、データ保存、個人データの取り扱い時における強力でセキュアな構成の欠如に関連するテーマが、Webアプリケーションでもそうであったように、継続してモバイルアプリケーションでの最大の懸念事項となっていることが示されています。これは、これらの分野で教育を強化し、認識を高める必要があり、またこれらのパラメーターをより容易に構成する方法を提供する新しいメカニズムが必要である可能性を示唆しているのかもしれません。GDPR45および California Privacy Act (カリフォルニア州プライバシー法 )46では、個人情報流出に高額の制裁金を科しています。また、これらの法律により、消費者の個人情報保護に対する意識が高まっています。前述したように、消費者のプライバシーを保護しなかった企業に制裁金が科せられるケースがすでに発生しています。これは、企業がそういったセキュリティホールへの対応を優先させる動機付けとなり、今後それらの数字が減少していくことが見込まれます。

モバイルアプリケーションの致命的/重大度「高」の脆弱性上位10項目

21%入力の傍受：キーボード拡張機能を許可

22%パスワード管理：ハードコーディングされた

パスワード

23%プライバシー侵害：

HTTP GET

26%セキュアでないストレージ：データ保護の欠如

27%

27%

29%

20%

15%

19%

22%

19%

17%

13%

リリースされないリソース：ストリーム

セキュアでないトランスポート：脆弱なSSLプロトコル 34%

33%

2018

2017

NULLデリファレンス

セキュアでないSSL：範囲が広すぎる証明書の信頼

アプリ数�%�

0 40%20%15% 25% 30% 35%10%5%

34%23%

セキュアでないトランスポート：App Transport Securityが無効 30%

37%

プライバシー侵害

図 23.モバイルアプリケーションの致命的 /重大度「高」の問題上位 10項目 (2018年 vs 2017年 )

__________

45 https://eugdpr.org/46 www.caprivacy.org/


https://eugdpr.org/

https://www.caprivacy.org/


30

プライバシー、ポリシー、規格サイバー侵害のリスクは、企業や機関、政府の存続を脅かす深刻な脅威として急速に広まっており、国家安全保障、経済的繁栄、公衆安全、組織の評判にも影響を及ぼしています。毎年、平均すると130件もの大規模攻撃が起きていますが 47、世界中の企業でサイバー攻撃に対し十分な準備をしていると回答した企業は半数にも達していません 48。サイバー攻撃の脅威は高度化し、発生頻度も増しています。さらに、職場でのデジタルテクノロジーの使用率も急増しています。このようにサイバー空間の戦場の進化に対応し続けていくことは、組織にとって難しい課題です。特にアプリケーションセキュリティは大きな課題と言えるでしょう。Cybersecurity Venturesの調査によると、新たに作成されるソフトウェアコードは年間で 1,110億行 49にも及び、攻撃される可能性がある脆弱性が続々と生まれています。

サイバー攻撃の標的になる可能性があるものについては、サイバー防御体制を構築する際にさまざまな不確定要素を考慮に入れる必要があります。まずやらなければならないことは、規制の観点から諸要素を考えることです。法律や規制、規格が最新のサイバー攻撃に追いついているとは言えません。とはいえ、規制機関や標準化機構が新しい法律や規制を制定 /発表した場合には、企業や機関は導入後の結果を十分把握しておく必要があります。大半の組織は、変化のスピードが遅い法的環境がもたらす意味とインパクトを過小評価しており、広範囲にわたる課題を適切なタイミングで解決することに失敗しています。さらに、サイバーセキュリティに関する規制は一層複雑化しており、最低限のコンプライアンスを確保するだけではもはや不十分です。

__________

47 www.accenture.com/us-en/insight-cost-of-cybercrime-2017?src=SOMS

48 www.irishtimes.com/business/technology/majority-of-businesses-across-the-world-unprepared-for-cyberattacks-1.3756463

49 www.networkworld.com/article/3198474/lan-wan/cisco-to-network-engineers-get-comfortable-with-software-it-s-here-to-stay.html

0

90%

100%

80%

70%

60%

50%

40%

30%

20%

10%

GDPRカテゴリ別のWebアプリケーションの脆弱性

機密データへの間接アクセス

95%

62%

不十分なデータ保護

91%

57%

アクセス違反

51%

78%

プライバシー侵害

27%

72%

任意の重大度の問題が1つ以上(%)致命的/重大度「高」(%)

アプリ�%�

https://www.accenture.com/us-en/insight-cost-of-cybercrime-2017?src=SOMS




https://www.irishtimes.com/business/technology/majority-of-businesses-across-the-world-unprepared-for-cyberattacks-1.3756463






http://www.networkworld.com/article/3198474/lan-wan/cisco-to-network-engineers-get-comfortable-with-software-it-s-here-to-stay.html








サイバーセキュリティに関する法令とコンプライアンスは、地域、国、世界全体といったさまざまなレベルで常に変化しています。たとえば、米国ではサイバーセキュリティに関する厳格な連邦法を施行する代わりに、各州が公共セクターと民間セクターの両方に対し、セキュリティインフラストラクチャの改善やベストプラクティスの推奨、消費者のプライバシー保護対策の強化を提案しています。サイバーセキュリティに関する法令は、35の州とワシントンD.C.で施行されています。2018年、プエルトリコでは 22以上の州がサイバーセキュリティに関する 51の法案を同時期に可決しました。50また、州法や法的枠組み以外にも、PCI DSSなどの業界標準や OWASP Top 10などのベストプラクティスが大きな影響力を持つようになっています。コンプライアンスの課題を迅速に解決するためにも、今後の統制環境を予測することが非常に重要であり、複数の管轄区域で活動する組織には特に必要です。

昨年注目されたのは、2017年 10月に発表された Open Web Application Security Project (OWASP) Top 10 2017と、EUの GDPR対応期限 (2018年 5月 25日に施行 )でした。2019年、当社は、検出された弱点や脆弱性の変化について観察を開始し、それによる規格やベストプラクティスの変更の可能性を探るとともに、GDPR関連の罰則水準を見直す動きにも注意を払っています。さらに、この分野に関する法律を修正した国が増え、プライバシーポリシーは継続的に進化しています。

米国カリフォルニア州は、2018年 6月に同州住民の個人データを収集、処理する営利企業を対象にしたCalifornia Consumer Privacy Act (CCPA)を制定し、2020年 7月 1日の CCPA施行までに連邦レベルにエスカレーションする事項について先例を示しました。CCPAの特徴は「世帯」が対象に含まれていることです。個人の識別に限定される「個人情報」ではなく、世帯に集約される情報も対象としています。

国際的には、中国が、個人情報保護に焦点を合わせた個人情報 (PI)セキュリティ規範を発表し、2018年5月 1日に施行しました。同規範は必須要件ではないものの、国内のサイバーセキュリティ法と密接に連動しています。51,52

他の国でも個人のプライバシーを保護するための法改正が行われ始めたため、EU内外の企業に対して制裁金が科せられるようになり、GDPRの効果が現れてきました。

米国のアプリケーションセキュリティ規格セキュリティ規格は、対象システムのセキュリティに必要な制御に脆弱性が発覚し、それによって生じた変更を反映させるため、定期的に更新されています。しかし、ソフトウェアの開発 /デプロイ /使用方法は大きく進化しているため、従来の規格を見直し、改訂する必要に迫られています。現在、2019年夏に、NIST Special Publication 800-53、Revision 5が大幅に改訂されることになっています 53。NIST SP 800-53のアップデート後には、DISA STIG、FISMA、FIPS 200も更新されることが予測されます。

__________

50 https://riskandinsurance.com/top-5-cyber-security-regulations/

51 www.insideprivacy.com/international/china/china-issues-new-personal-information-protection-standard/

52 www.nortonrosefulbright.com/knowledge/publications/163195/personal-information-security-specification

53 https://csrc.nist.gov/projects/risk-management/schedule


https://riskandinsurance.com/top-5-cyber-security-regulations/



https://www.insideprivacy.com/international/china/china-issues-new-personal-information-protection-standard/





http://www.nortonrosefulbright.com/knowledge/publications/163195/personal-information-security-specification





https://csrc.nist.gov/projects/risk-management/schedule




32

2018年、国防情報システム局 (DISA)は、ベンダーや開発チームによる製品サポートの在り方を大幅に変更しました 54。具体的には、関連 CCIが CCI-003372からCCI-003376に変更され、サポート終了時には「情報システムのコンポーネントを置き換えること」を強調しています。コンポーネントのメンテナンスが終了し、新しいものに置き換えたとしても、セキュリティ上の問題は解決しません。ここで生じる疑問は、積極的な貢献者が存在しないにも関わらず、アクティブな状態にあるオープンソースコンポーネントをどう扱えばよいかです。

国際規格クレジットカード業界 (PCI)向けに開発された規格は、企業が支払いカードのオンライン処理をセキュアに行うための最低限のセキュリティをまとめた指針を示しています。Micro Focus Fortifyは、1つ以上の PCI DSS要件と脆弱性カテゴリとの相関を示します (「セキュアでないトランスポート：脆弱な SSLプロトコル」は、カード会員データのセキュアなトランスポートを脅かす脆弱性を規制する要件 4.1、セキュアでない通信に関する要件 6.5.4と連動していること、など )。

PCI DSSのさまざまなセクションと関連付けられた脆弱性の分布は、次のページの図 24に示しています。2018年の分析では、約11,000のアプリケーションから成る同じサブセットを使用しました。アプリケーションの 83%が正しいエラー処理 (要件 6.5.5)に失敗しており、その数は 2017年の 80%からわずかに増加しています。また 81%が 1つ以上の重大度の高いまたは致命的な問題 (要件 6.5.6)を抱えていますが、この値は前年比 9%増でした。要件 6.5.6「プライバシー侵害：カリフォルニア州の運転免許証番号」の違反の原因となるさまざまなカテゴリでは、19%という最大の増加幅になりました。75%のアプリケーションは、推奨される暗号化または仮名化を使用して保存データや転送データのセキュリティを保護していません。

__________

54 STIGID APSC-DV-003240

0

90%

100%

80%

70%

60%

50%

40%

30%

20%

10%

規制と関連付けられていない問題を持つテスト済みアプリケーションの割合(%)

OWASP TOP 10

94%

61%

NIST

61%

24%

PCI DSS

26%

78%

GDPR�LOGICAL

30%

66%

問題が1つ以上

致命的/重大度「高」の問題が

1つ以上

アプリ�%�


これらの要件と関連付けられたカテゴリは 25以上ありますが、そのすべてが同じ割合で違反しているわけではありません。当社のデータセットで特に違反が多いのは、「クッキーセキュリティ：SSLでクッキーを送信しない」(44%)、「セキュアでないトランスポート：HSTS未設定」(48%)、「セキュアでないトランスポート：脆弱な SSLプロトコル」(40%)、「セキュアでないトランスポート：脆弱な SSLサイファ」(31%)でした。ソフトウェアの脆弱性に関するセクションで触れた「セキュアでないトランスポート：脆弱な SSLプロトコル」は、今年 7%減少しました。これは、2018年 6月 30日までに、より新しいバージョンの TLSへ移行するというPCIの指令によって、意識が高まったことが原因と見られます。もう一つ注目すべきカテゴリは、「セキュアでないトランスポート：チャネルミキシング」です。昨年は 15%のアプリケーションでこのカテゴリが検出されましたが、今年は 30%と倍増しました。同一ドメインからのリソースが、セキュアな HTTPSからセキュアでない HTTP経由で参照される場合、チャネルミキシングとして警告されます。セキュアな SSLクッキーが実装されておらず、チャネルが混在している環境では、プライベートデータとシステムデータ（認証トークンなど）の漏洩という深刻な問題が発生する恐れがあります。

規格の見直しという大きなテーマに取り組むため、2019年、PCIセキュリティ基準委員会 (SSC)は、PCIの新たなソフトウェアセキュリティフレームワーク (SSF)の一環として、新しい PCIソフトウェアセキュリティ規格とPCIセキュアソフトウェアライフサイクル (SLC)を公開しました。この新しいフレームワークは、関連するソフトウェアセキュリティ規格と検証、リスティングプログラムを集約したものです。最終的には、PCI Payment Application (PA) -DSSと検証済みの支払いアプリケーションのリストは廃止され、アプリケーションは新しい PCIソフトウェアセキュリティフレームワークのもとで評価されます。55

__________

55 https://blog.pcisecuritystandards.org/just-published-new-pci-software-security-standards

PCIで見られる問題グループ上位10項目(2018年)

0 80%40% 60% 90%70%50%30%20%10%

45%要件4.1、要件6.5.4、要件6.5.10

48%要件6.5.10

49%要件6.5.1

56%要件3.2

61%要件3.2、要件3.4、要件4.2、要件8.2.1

66%要件6.5.8

75%要件4.1、要件6.5.4

81%要件6.5.6

78%なし

83%要件6.5.5

図 24.PCIにおける脆弱性の分布 (2018年 )


https://blog.pcisecuritystandards.org/just-published-new-pci-software-security-standards






34

ベストプラクティス Open Web Application Security Project (OWASP)は、長年にわたり、重要な脆弱性リスクを回避するための指針を提供してきました。2017年には、Top 10に「セキュアでないデシリアライゼーション」を加え、大幅な変更を行いました。

図 25は、約 7,500のアプリケーションの脆弱性に関する2017年のデータと、約 11,000のアプリケーションの脆弱性に関する 2018年のデータを、OWASP Top 10 2017の各カテゴリと関連付けて比較したものです。最も動きがあったカテゴリは、「A9 既知の脆弱性を含むコンポーネントの使用」と「A8 セキュアでないデシリアライゼーション」です。A9は大幅に増加し (16%)、A8でも影響を受けるアプリケーションが 7%増えています。過去のレポートでは、ソフトウェアの脆弱性上位 10個に「セキュアでないデシリアライゼーション」は入っていませんでしたが、全般的に顕著な増加を見せています。脆弱性全体で見ると、「動的なコード評価：セキュアでないデシリアライゼーション」は 48位から16位に上昇にし、検出数は 3%増でした。コンポーネント分析では、8位から 4位に上昇しています。

OWASP 2017の関連付け別に見たWebアプリケーションの脆弱性

a6 不適切なセキュリティ設定

2018

2017

a9 既知の脆弱性を含むコンポーネントの使用

アプリ数�%�

0 70%60%40%30% 50% 100%90%80%20%10%

a3 機密データの漏洩

なし

a4 XML外部エンティティ(xxe)

a8 セキュアでないデシリアライゼーション

a2 認証の不具合

a7 クロスサイトスクリプティング(XSS)

a5 アクセス制御の不具合

a1 インジェクション

図 25.OWASP TOP 10 2018の比較 (前年比 )


図 26は同様の比較を示していますが、致命的な問題や重大度の高い問題のみを取り上げています。「なし」が示しているように、OWASP Top 10から除外された致命的カテゴリの割合は、2017年のデータと比べ増加しています。今後は、OWASP Top 10を対象にしたセキュリティ評価を堅実な第一歩として実施する必要があります。ただし、本番リリースの前に、より包括的な評価の実施計画を検討しなくてはなりません。

「セキュアでないデシリアライゼーション」は、2017年のランキングで 8位から 7位に上昇しました。次のセクションでも説明しますが、開発者は、デシリアライゼーションの欠陥があるコンポーネントに特に注意する必要があります。コンポーネントを使用したり、コンポーネント内で直接 APIを使用したりしなくても、この脆弱なコードは、クラスパス内のコンポーネントに到達する可能性があります。

図 26.OWASP Top 10 2018の致命的 /重大度「高」の比較 (前年比 )

OWASP 2017の関連付け別に見たWebアプリケーションの致命的な脆弱性

a6 不適切なセキュリティ設定

2018

2017

a1 インジェクション

アプリ数�%�

0 60%40%30% 50% 70%20%10%

a3 機密データの漏洩

なし

a4 XML外部エンティティ(xxe)

a2 認証の不具合

a8 セキュアでないデシリアライゼーション

a7 クロスサイトスクリプティング(XSS)

a9 既知の脆弱性を含むコンポーネントの使用

a5 アクセス制御の不具合



36

オープンソースの依存関係にある脆弱性コンポーネントの管理は、セキュアなソフトウェア開発にとって重要な要素です。このセクションでは、Fortify on DemandテクノロジーとSonatypeとのパートナーシップを利用してアプリケーションを解析し、サードパーティコンポーネントがどのように使用されているかを分析した結果を報告します。今回の調査サンプルは、2017年 10月 31日から 2018年 10月 30日の期間に分析された 1,250のアプリケーションで参照されている 586のライブラリーについて報告のあった 874の CVEです 56。

オープンソースコンポーネントへの依存オープンソースコンポーネントは、データセットの全アプリケーションで参照されていました。60%のアプリケーションが、オープンソースコンポーネントの 75%以上を参照していました (図 27を参照 )。

CVEの重大度 Sonatypeが分析した 586のコンポーネントでは、合計 874の CVEが報告されました。次のページの図 28で示しているように、参照ライブラリーで見つかった CVEの 95%以上が、Sonatypeの脅威レベルで重大または致命的と評価されています (CVSS基準スコアが 4.0超 )。目を引く点は、致命的 CVE群が2017年の 27%から 55%へとほぼ倍増していることです。

__________

56 1,250のアプリケーションは、調査で使用した FoDデータセットから取り出した 11,000以上の固有アプリケーションのサブセットでした。

0 (1-24)%0

70%

60%

50%

40%

30%

20%

10%

(25-49)% (50-74)% (75-100)%

オープンソースコンポーネントの範囲

アプリケーション�%�

特定範囲内でオープンソースコンポーネントを使用しているアプリケーションの割合

60%

0%

5%

11%

24%

図 27.参照コンポーネントにおけるオープンソースの割合


図 29は、アプリケーションの 87%が、参照コンポーネントから致命的な脆弱性を継承していることを示しています。この数は 2017年から 22%増えています。

図 28.重大度別 CVE (2018年 )

図 29.重大度別に見た CVEを 1つ以上含むアプリケーション

重大度別CVE

CVE数�%�

0 80%50% 60%40% 70%30%20%10%

55%クリティカル

51%重大

27%

67%

中6%

4%

2018

2017

重大度別に見たCVEを含むアプリケーションの割合

CVE数�%�

0 100%60% 80%40%20%

87%クリティカル

39%重大

65%

82%

中

2018

2017

96%37%



38

次のページの図 30は、2018年のデータセットで 1つ以上のアプリケーションに影響を与えた CVEの数を年ごとに示したものです。図 31は、2018年のリスクレポートのデータセットを使用して同じ分析を行った結果です。この2つの図を比較した結果と、アプリケーションの数およびアプリケーションから参照されるコンポーネントの数が前年から倍増している事実を合わせて考えると、CVE開示の割合はこの 2年間で大きく変化していません。重要なのは、致命的な CVEの数が大幅に増加していることです。詳細を見てみると、興味深いことに致命的な CVEの大半は、Microsoft.TypeScript.MSBuildとMicrosoft.TypeScript.Compilerの 2つのコンポーネントに関するものです。この 2つのコンポーネントは、2017年のデータにも出てきていますが、2018年には、この 2つのライブラリーに関連する開示数が大幅に増加しています。Sonatypeが報告した FoDデータによると、Microsoft.TypeScript.MSBuildには既知の CVEが 5つ、Microsoft.TypeScript.Compilerには致命的な CVEが 19ありました。どちらのコンポーネントにも、ほかの脅威カテゴリの既知の CVEはありませんでした。これに対し、2018年のデータでは、Microsoft.TypeScript.MSBuildにおける脅威カテゴリが致命的な CVEは 118、重大な CVEは 2つでした。また、Microsoft.TypeScript.Compilerについては致命的な CVEが 175、重大な CVEは 5つでした。さらに掘り下げていくと、これらの CVEは TypeScript自体が原因ではなく、パッケージに含まれている再配布用ファイルChakraCore.dllに関連しています。ChakraCore.dllは、任意の信頼できない JavaScriptを意図的に処理するインターネット用の下位階層コンポーネントであるため、この CVE数は理にかなっています。ChakraCoreコンポーネントのセキュリティには、Microsoftと外部のセキュリティ研究者が特別な注意を払っています。ただし、TypeScriptを使用する場合、ChakraCore.dllは静的な JavaScriptファイルの解析と実行に使用されるため、悪意を持った人物が不正な入力 (非常によく使われる低セキュリティの攻撃経路 )を使ってメモリーを直接破損することはできません。

もっと端的に言えば、ChakraCore.dllの CVEは TypeScriptを使用しても発生しないため、TypeScriptのセキュリティプロファイルには直接関係しません。この状況からは、業界にとって興味深い疑問が数多く浮かび上がります。たとえば、コンポーネント利用者は、既知の脆弱性を含む直接的および遷移的な依存関係と関連する到達可能性、攻撃容易性、リスクベクトルをどうやって判断できるでしょうか。

分析データからは、今年の現時点までにアプリケーションに影響を及ぼしている大半の CVEが、2017年にすでに開示されていたことも観察できます。セキュリティの問題が発覚してから一般に情報が公開されるまでに空白の時間があることを考えると、2018年に開示された CVEの数は、年内にまだ増加する可能性があります。さらに、このデータセットは 2017年 10月 31日から 2018年 10月 30日までの概要です。情報公開までに十分な時間があった過去の年と比べると、2018年はわずか 9か月間のデータでしかありません。


2003 2009 20100

200

250

150

100

50

2011 2012 2013 2014 2015 2016 20172005 200820072006 2018

年別CVE開示数

年

CVE数

致命的

深刻

中

CVE数

図 30.2018年のデータセットの参照ライブラリーにおける年別 CVE登録数

図 31.2017年のデータセットの参照ライブラリーにおける年別 CVE登録数

2003 2009 20100

80

100

60

40

20

2011 2012 2013 2014 2015 20162005 200820072006 2017

年別CVE開示数

年

CVE数

致命的

深刻

中

CVE数



40

この 4年間で開示数が劇的に増えているように見えますが、当社のデータセットを見ると、Sonatypeによるコンポーネントスキャンを含むアプリケーションの数は 2017年から 2倍になっています。また、参照されるコンポーネントの数もほぼ倍増しているため、これもCVE増加の原因と考えられます。ところが、コンポーネントごとのCVEの平均数はほぼ変わらず、1つのコンポーネントに1つまたは2つのCVEしかありません。図 32は、アプリケーション、コンポーネント、CVEが比例して増加していることを示しています。

次のページの図 33は、当社のデータセットの中で特に脆弱性の開示が多いコンポーネントをまとめたもので、上位には Jenkins、MSBuild、Compilerが入っています。Microsoft.TypeScriptコンポーネントの問題の多くは、2018年に開示されました。

2015 2016 2017 2018 2019

数

年

0

1,400

1,200

1,000

800

600

400

200

プロジェクト

コンポーネント

CVE

過去5年間のアプリケーション数、コンポーネント数、CVE開示数

図 32.過去 5年間のアプリケーション数、コンポーネント数、CVE開示数の増加


次のページの図 34は、FoDデータセットで特に多く参照されている 10個のコンポーネントを示しています。Springフレームワークは 1位との差がほとんどなく、Sonatypeによってライブラリーに合計 63の関連CVEがあることが報告されていますが、そのうち29の CVEが致命的と評価されました。

図 33.CVE開示数が特に多いライブラリー

CVE開示数が多いライブラリー上位10個

org.jenkins-ci.main:jenkins-war

CVE数(致命的)

CVE数(すべて)

org.jenkins-ci.main:jenkins-core

CVE数

0 6040 80 120 140 160 180 20020 100

Microsoft.TypeScript.Compiler

Microsoft.TypeScript.MSBuild

org.apache.tomcat.embed:tomcat-embed-core

com.googlecode.t7mp:tomcat

org.apache.struts:struts2-core

za.co.absa.spline:spline-web

org.apache.activemq.examples.modules:artemis-tomcat-

jndi-resources-sample

com.google.gwt:gwt-dev



42

いくつのコンポーネントに対していくつの CVEが開示されているのかという疑問に加え、どのようなタイプの脆弱性がアプリケーションに影響を与えているのかという疑問もあります。当社は、CVEの詳細、ベンダーが開示した情報、研究論文をもとに、参照されるライブラリーのすべての CVEと 7つの Pernicious Kingdoms分類を関連付けました。図 35は、入力検証の弱点が標的になる脆弱性が最も多いことを示しています。

アプリケーションで参照されたコンポーネント上位10個apache-httpclient:

commons-httpclient

xerces:xerceslmpl

commons-fileupload:commons-fileupload

com.google.guava:guava

org.springframework:spring-webmvc

org.springframework:spring-core

com.fasterxml.jackson.core:jackson-databind

org.springframework:spring-expression

org.springframework:spring-web

commons-beanutils:commons-beanutils

dom4j:dom4j

0 45%25% 35% 50%40%30%20%15%10%5%

アプリケーション数�%�

24%

27%

29%

29%

35%

32%

38%

39%

43%

45%

45%

図 34.人気コンポーネント上位 10個

図 35. Kingdoms別の CVE分布

CVEのKingdoms別分布

報告されたCVE

0 700600500400300200100

2エラー

6コード品質

12APIの悪用

18時間と状態

20環境

23カプセル化

180セキュリティ機能

613入力検証と表現


図 36では、今年、「バッファーオーバーフロー」が CVEを最も多く発生させた要因となり、「サービス拒否」と入れ替わったことが分かります。しかし、詳しく見ていくと、今年最も増加したのは、Microsoft.TypeScript.MSBuildとMicrosoft.TypeScript.Complierの2つのコンポーネントが原因のCVEでした。「脆弱性のタイプにおける傾向」セクションによれば、バッファーオーバーフローは、どの年でも、NVDデータベースで最も報告数の多いCWEタイプの CVEとして頻繁にトップに立っています。オンラインデータソースの CVE Details57は、CVEの詳細についてテキスト分析を実施しカテゴリを決定していますが、CVE Detailsによると、オーバーフローが「サービス拒否」の脆弱性を上回るという同様の傾向が確認されています。「クロスサイトスクリプティング (XSS)」は常に上位 10位に入り、「セキュアでないデシリアライゼーション」は、昨年の 8位から今年は 5位に急浮上しました。「アクセス制御：権限昇格」を除く、ほとんどのカテゴリは常に上位 10位に入っています。権限昇格は、「アクセス制御：セキュリティマネージャーのバイパス」と入れ替わり、今年初めてランクインしました。

感受性分析：現在の SCAを強化するこんな状況を想像してみてください。「電話が鳴っている。午前 3時だぞ。そういえば、ソフトウェアコンポーネント分析ツールが、ほとんどのWebアプリケーションにデプロイされているライブラリーに、リモートでコードを実行される脆弱性があると報告していたな。CVSSスコアは 10段階評価で 9.8だった。冷汗が出てきた。どうしよう、心臓がドキドキしてきた。」ソフトウェアコンポーネント分析 (SCA)レポートを読んだとき、このような状況が起こり得ることは想像できるでしょう。おそらく、パニックになる理由が明確に存在しているからではないでしょうか。

図 36.CVEタイプで見たカテゴリ上位 10個

__________

57 www.cvedetails.com/vulnerabilities-by-types.php

CVE開示数が多いカテゴリ上位10個

脆弱な暗号化

アクセス制御：権限昇格

動的なコード評価：コードインジェクション

アクセス制御：権限付与のバイパス

ディレクトリートラバーサル

動的なコード評価：セキュアでないデシリアライゼーション

XML外部エンティティインジェクション

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

バッファーオーバーフロー

サービス拒否

0 100 140 18016012080604020

CVE数

171

69

54

54

38

32

30

21

19

15






44

セキュアでないデシリアライゼーション（FoD Webデータにおける）は、検出数が 3%増加して 48位から 16位に上昇しました。FoD Sonatypeデータでは 8位から 4位に上昇しました。昨年は 293のコンポーネントで18のCVE、今年は586のコンポーネントで 38の CVEがありました。

コンポーネント分析レポートに目を通す際は、その情報は大きなパズルの 1つのピースに過ぎず、ソフトウェアソリューションの一部のみを近視眼的に捉えた結果であることを忘れないでください。ソフトウェアコンポーネント分析ツールは、アプリケーションで使用するライブラリーを詳細に分析しますが、その分析には、アプリケーションがコンポーネントライブラリーで実際に脆弱なコードを実行しているかという重要な視点が抜けています。また、アプリケーションが脆弱なコードに到達し実行するよう、攻撃者が操作できるかという点も重要です。

CISOが真夜中に叩き起こされるような事態につながるCVEの例 (図 37)なら、答えは簡単です。アプリケーションは、信頼できないデータを最初にデシリアライズしていますか。答えは簡単ではないかもしれません。でも、どうやってそれを知ることができるでしょうか。アプリケーションが、信頼できないデータを明示的にデシリアライズしていなくても、あるいは制御された安全な方法でデシリアライズしていても、アプリケーションで使用されるフレームワークが、その反対の処理を実行している可能性があります。Spring HTTP Invoker、RMI、JMXなどのフレームワークやライブラリーは、ユーザーが制御するデータをデシリアライズすることがあります。組織全体で静的コード分析 (SCA。この略語は以前 AppSecで使用されていました )プログラムを実行すると、その答えは即座に判明します。デシリアライゼーションの脆弱性を検出できる静的コード分析製品は、アプリケーションがこうしたフレームワークを使用している場合、問題を報告し、フラグを立てます。そして、CVEが報告された場合には、ソフトウェアセキュリティダッシュボードからアプリケーションポートフォリオをゆっくり確認できます。この方法により、現実的なリスクに晒されているアプリケーションを判別し、修正プログラムを作成してパッチリリースプロセスを最優先で進めることができます。

Apache Commons FileUploadライブラリーのシリアライゼーションの脆弱性を使用してリモートでコードを実行 (+2以上)

AV:N/ AC:L/ Au:N/ C:P/ I:P/ A:P

AV:N/ AC:L/ PR:N/ UI:N/ S:U/ C:H/ I:H/ A:H

CVE-2016-1000031情報開示

致命的(CVSS v3)

高(CVSS v2)

9.8

7.5

タグ：リモートプロシージャコール

Apache Commons FileUpload、tomcat-coyote、tomcat-embed-coreは、シリアライゼーションを介してリモートでコードを実行される脆弱性があります。

Apache Commons FileUploadは、シリアライゼーションを介してリモートでコードを実行される脆弱性があります。Apache Commons FileUploadでは、DiskFileItemを使用してファイルアップロードを処理します。DiskFileItemはシリアライズ可能で、カスタムのwriteObject()関数とreadObject()関数を実装します。攻撃者は、シリアライズされたデータをデシリアライゼーション前に変更し、ディスクの任意の場所にファイルを書き込んだりコピーしたりできます。さらに、攻撃者はこの脆弱性をysoserialツールと統合し、1回のデシリアライゼーション呼び出しでバイナリーをアップロードし実行することができます。

図 37.www.sourceclear.com/vulnerability-database/security/remote-code-execution-via-serialization/java/sid-2911

https://www.sourceclear.com/vulnerability-database/security/remote-code-execution-via-serialization/java/sid-2911

https://www.sourceclear.com/vulnerability-database/security/remote-code-execution-via-serialization/java/sid-2911


ソフトウェアコンポーネント分析レポートを受け取ったときにアプリケーションについて確認すべき項目は、必ずしも簡単に分かるわけではありません。例に挙げたレポートの場合、分析対象のライブラリー自体は脆弱ではなく、ガジェット (特定の状況のもとサーバー上で実行できる小さなコードの集まり )に問題があるため、アプリケーションの脆弱性 (セキュアでないデシリアライゼーションの問題 )がリスクになるか判断するのは容易ではありません。

SCA2(ソフトウェアコンポーネント分析と静的コード分析 )を連動させて活用するには、次のような 2ステップのプロセスが必要です。1. ソフトウェアコンポーネント分析レポートは、ベンダーが提供する情報を分析し、根本的な脆弱性とそれがアプリケーションに与える影響を明確にしながら結果を要約する必要があります。

2. 静的コード分析は、ステップ 1で提示された情報をカスタマイズ可能な方法でチェックできるようにします。

私たちはこれを感受性分析と呼び、報告のあった CVEが原因でアプリケーションがどの程度攻撃される可能性があるかを評価します。また、アプリケーションが、この依存関係を使用するだけで直ちに脆弱になるか（Struts2フレームワークでのOGNLインジェクションなど）、あるいは、アプリケーションが分析対象のコンポーネントで脆弱なコードを実行するかについても分析します。

再利用可能なコンポーネントの CVEは、コンポーネントにセキュリティホールとなる脆弱性が 1つ以上存在するものの、この脆弱性に到達しない限り実行されないことを示しています。アプリケーションが脆弱なコンポーネントを利用している状況では、利用されるコンポーネントの脆弱性の影響を受けるアプリケーションが攻撃を受ける可能性は、脆弱性に到達できるか、またはコンポーネント内の脆弱な機能を呼び出して実行できるかによって異なります (脆弱な機能に到達するためにユーザー制御による入力が必要な場合もあります )。また、アプリケーションによって直接呼び出されないコンポーネントコードがコンテキストに組み込まれる脆弱性もあります (セキュアでないデシリアライゼーションやセキュアでないリフレクションなど )。これは、脆弱なコンポーネントを利用するアプリケーションは、(a)脆弱性が実行される形でコンポーネントのロジックを呼び出す必要があること、あるいは (b)脆弱性に到達し、攻撃できる弱点 /不具合がアプリケーションに 1つ以上あることを意味します。

実際のところ、CVEレポートでは、何が根本的な脆弱性かが常に明らかされているわけではありません。これは当然です。そうしないと、特定の CVEを悪用する方法を攻撃者に教えてしまうことになるからです。しかし、分析がより困難になるのも事実です。根本原因を突き止め、脆弱性の仕組みを理解し、アプリケーションへの影響を確認するには、OSS CVS Commitを調べたり、コンポーネントをリバースエンジニアリングしたりする必要があります (許可がある場合 )。これは、Fortify Software Security Research (SSR)グループが取り組んでいる研究の 1つです。Struts2フレームワークについて報告された最新の GNLインジェクションなどが良い例です (CVE-2018-11776など )。これまでの OGNLインジェクションと異なり、新しいアイテムは、このフレームワークの特定のバージョンを使用するだけではアプリケーションは脆弱にならないという意味ではユニバーサルではありません。その代わり、特定の方法でStrutsアクションを公開したり、ユーザーが制御できるOGNL式と一緒に Strutsタグを使用したりして脆弱なコードを実行する必要があります。



46

前述のとおり、アプリケーションのセキュリティは大きなパズルのようなものであり、さまざまなピースを微調整しながら、組織全体に総合的に価値をもたらすものでなければなりません。

コンポーネント分析の視点と交差検証

このセクションでは、コーポレートソフトウェアのリスク計算において、脆弱な外部コンポーネントが果たす役割の分析について説明します。SonatypeとFortifyは、このセクションで取り上げるデータ分析を共同で行い、指標を比較し、外部コンポーネントに共通して見られる使用状況の傾向を導き出しました。図 38では、Fortify需要 (FP)で特定された上位 10個の脆弱なコンポーネント (VC)のうち、4つのコンポーネントが同時期の中央リポジトリダウンロード (CRD)統計の結果と同じだったことが確認できます。VC上位10個 (FP統計 )は、対象の FoDで検出された脆弱なオープンソースコンポーネントの中で最も頻繁に検出されるものを示しています。VC上位 10個 (CRD統計 )は、中央リポジトリからダウンロードされた絶対数を表し、同じエンティティから複数回ダウンロードされた重複分はフィルタリングしていません。Sonatypeは、2018年にダウンロードされた 233,963の独自コンポーネントを含む、約 290万件のリリースを追跡しました。指定期間中に中央リポジトリからダウンロードされた合計数は 1,460億でした。全体では、中央リポジトリ統計は 271,783の独自コンポーネント (GA)を対象に 350万件のリリース (GAV)を追跡します 58。ダウンロード数はコンポーネントの人気を表しますが、エンタープライズシステムに影響を与えるプロジェク

1

0

6

0

3

6 7

Fortity需要

Sonatype需要

中央リポジトリダウンロード

図 38.脆弱なコンポーネント (VC)上位 10個。Fortify需要 (FP)、中央リポジトリダウンロード (CRD)、Sonatype需要 (SP)によって論理的にグループ化

__________

58 https://search.maven.org/stats

https://search.maven.org/stats

https://search.maven.org/stats


トでそのコンポーネントが実際に使用されているかどうかは示しません。しかし、Sonatype需要 (SP)統計では、Sonatype Lifecycleを使用してスキャンしたアプリケーションからデータを収集しています。Sonatype Lifecycleは、デプロイしたアプリケーションで使用される可能性が高いコンポーネントを示します (ある期間では、約 110,000の独自アプリケーションがスキャンされ、それらのアプリケーションでは約27,000のコンポーネント (GA)と151,000件のリリース (GAV)が使われていました )。3つのコンポーネントが、3つすべての VC上位 10個で共通していました (30%)。残りの VC上位 10個 (FPコンポーネント )は、CRD統計とSP統計ではかなり下位にランクされています。図 39は、VC上位 10個を FortifyデータとSonatypeデータで比較して順位付けを行った結果です。これは、最もスキャンされたエンタープライズアプリケーションには、ダウンロードして実際に使用された上位 100個のコンポーネントが含まれていることを意味します。より具体的には、3つすべての指標は、VC上位 10個 (FP)の 70%が 2つの Sonatype指標セットの VC上位 25個に入っていることを示しています。

3つのリストに共通する3つのコンポーネントのうち、特に関心を引くのは、2つのSpringフレームワークコンポーネント (org.springframework:spring-coreとorg.springframework:spring-expression)です。この 2つのコンポーネントは、「動的なコード評価：セキュアでないデシリアライゼーション」、「パスマニュピレーション」、「入力検証と表現」、「アクセス制御のバイパス」、「誤って実装されたセキュリティ機能」という 5つの脆弱性の原因になっていました。

図 39.VC上位 10個の Fortify需要を、中央リポジトリダウンロード統計とSonatype需要統計と比較して順位付け

3521

10

2788

9132

8

16157

3661055

103

2247103

11132

12141

xerces:xerceslm

pl

comm

onsfileupload:

comm

onsfileupload

com.google.guava:guav

org.springfarmwork:

spring-w

ebmvc

org.springfarmwork:

spring-core

com.fasterxml.jackson.core:

jackson-databind

dom4j:dom4j

org.springfarmwork:

spring-expression

org.springfarmwork:

spring-w

eb

0

120

80

100

60

40

20

VC上位10個のFortify需要と中央リポジトリダウンロードおよびSonatype需要との比較

RAN

K

SONATYPEのオープンソース分類

comm

onsbeanutils:

comm

onsbeanutils

Fortify需要


Sonatype需要



48

上位 10個のコンポーネントについて、これまで開示された脆弱性は合計 53に上ります。これらの脆弱性は、18の共通脆弱性タイプ一覧 (CWE：Common Weakness Enumeration)の識別子と関連付けることができます。CWE ID 20「無効な入力検証」は、最もよく報告されている脆弱性タイプの 1つでした。VC上位10個 (FP統計 )では、コンポーネントデータごとに Sonatypeが収集した CWEによると、「CWE ID 264：認可、権限、アクセス制御」は VC上位 10個の中で 2番目に多く報告されている問題です。CWE ID 502「動的なコード評価：セキュアでないデシリアライゼーション」は 3位にランクしており、この脆弱性に関する業界全体の傾向と一致しています。図 40は、VC上位 10個 (FPコンポーネント )の既知の脆弱性と関連付けられているすべての CWEを示しています (Sonatypeの CWEデータを参照 )。

5

4

3

2 2 2 2

1 1 1 1 1 1 1 1 11 1

cwe-20

cwe-918

cwe-91

cwe-833

cwe-79

cwe-400

cwe-358

cwe-352

cwe-284

cwe-16

cwe-119

cwe-113

cwe-611

cwe-399

cwe-254

cwe-22

cwe-502

cwe-2640

6

5

4

3

2

1

VC上位10個のFortify需要で見られたCWE

コンポーネント数

CWE識別子

CWE ID

CWE ID 16

CWE ID 113

CWE ID 119

CWE ID 20

CWE ID 254

CWE ID 284

CWE ID 358

CWE ID 79

CWE ID 91

CWE ID 400

CWE ID 22

CWE ID 264

CWE ID 352

CWE ID 399

CWE ID 611

CWE ID 833

CWE ID 918

CWEカテゴリ名

HTMLヘッダーのCRLFシーケンスの不適切な無効化(「HTTPレスポンス分割」)

不適切な入力検証

セキュリティ機能

不適切なアクセス制御

不適切に標準実装されたセキュリティチェック

リソースの無秩序な消費

Webページ生成時の入力の不適切な無効化(「クロスサイトスクリプティング(XSS)」)

XMLインジェクション(別名：ブラインドXPathインジェクション)

構成管理

メモリーバッファー境界内の操作の不適切な制限

制限付きディレクトリーへのパス名の不適切な制限(「パストラバーサル」)

認可、権限、アクセス制御

クロスサイトリクエストフォージェリ(CSRF)

リソース管理エラー

XML外部エンティティ参照(「XXE」)の不適切な制限

デッドロック

サーバーサイドリクエストフォージェリ(SSRF)

図 40.VC上位 10個 (FP)におけるCWE ID


VC上位 25個 (FP)の詳細なリストを見ると、CRDリストは 822位まであり、Fortifyリストには 25のコンポーネント、SPリストには 20,541あります。さらに、上位 25個の FPコンポーネントのうち22個は、CRDリストでVC上位 100個のダウンロード済みコンポーネントと関連付けられており、SPリストでは 21個のコンポーネントが VC上位 100個と関連付けられていました。この詳細なリストのマッシュアップにより、Fortifyデータセットに基づく分析は、外部コンポーネントのリスク分析で判明する大まかな傾向を公正に示していることが確認されました。3つすべてのリスト (VC上位 25個 (FP)、VC上位 25個 (CRD)、VC上位 25個 (SP))に入ったコンポーネントは 8つありました。そのうち4つは Springフレームワークコンポーネントでした。これらの Springフレームワークコンポーネントは、2018年の FoDデータセットにおいて 31以上の致命的および重大度の高いCVEに関連していました。

図 41は、VC上位 25個 (FP)リストをもとに、1つ以上のコンポーネントに該当する Sonatypeのオープンソース分類カテゴリ別に見たコンポーネント数を示しています。Sonatypeのオープンソース分類は、コンポーネントの機能をベースにオープンソースコンポーネントのカテゴリグループを階層別にまとめた一覧です。Sonatypeのオープンソース分類には 172の分類があり、そのうち158が上位 25個の分析に使用されました。「ビルドツール」、「テストフレームワーク」、「その他」の各カテゴリと関連するコンポーネントは、本番のエンタープライズアプリケーションに含まれないことが多いため (少なくとも含むべきではありません )、除外されました。興味深いことに、Fortifyデータセットの中でよく使用されている上位 25個のコンポーネントは、Sonatypeのオープンソース分類の 17カテゴリに分布していました。25のコンポーネントのうち8つは、さまざまな「データ処理」機能と「データプロトコル」機能のために参照されていました。

図 41.Sonatypeコンポーネント分類ごとのコンポーネントタイプとVC上位 25個 (FP)の CVE数

1 1

1

1

2 2

1 1 1 1

2

1 1

2

4

2

1

セキュリティ

アプリケーションおよびサーバー管理

データプロセッサ

/フォーマット

/JSON


/フォーマット

/XML

データプロトコル

/クライアント/HTTP


/クライアント/SOAP

依存関係インジェクションとアスペクト指向式言

語

ファイルユーティリティ

ファイルユーティリティ/ファイルIO

プログラミング言語ユーティリティ

/コレクション


/リフレクション

セキュリティ

/認証と権限付与

Webフレームワーク

ログ記録

セキュリティ/検証

security/validatio

n0

5

4

3

2

1

Sonatypeのオープンソース分類別のVC上位25個(FP)

コンポーネント数




50

図42は、Sonatypeのコンポーネントタイプ別に見たCWE ID数を示しています。脆弱性が最も多いのは、「アプリケーションおよびサーバー管理」タイプのコンポーネントorg.apache.tomcat.embed:tomcat-embed-coreでした。「アプリケーションおよびサーバー管理」に対して開示された脆弱性タイプには、「入力検証」、「暗号化」、「URLリダイレクト」、「データ認証の非効率的な確認」などがあります。データフォーマッタは、主に「入力検証」や「パスマニュピレーション」、「コード品質」(デッドコードや、final宣言していないパブリック静的フィールドなど )、「セキュアでないデシリアライゼーション」の問題を抱えています。8つのコンポーネントは、XMLや JSONフォーマッタ、あるいは HTMLや SOAPフォーマッタなど、さまざまなデータプロセッサとして分類されました。

VC上位 25個の中央リポジトリダウンロード統計とSonatype需要統計 Sonatypeは、このレポート用に設定した期間 (2017年 10月 31日から 2018年 10月 30日まで )における、上位 25個の脆弱なコンポーネントの中央リポジトリダウンロードリストとSonatype需要リストも提供しています。具体的には、commons-codec:commons-codecが、CRDから最もダウンロードされたコンポーネントであり、Sonatypeの需要が最も高かったコンポーネントでした。このコンポーネントには、「代替エンコーディングの不適切な処理 (CWE -172)」の脆弱性が報告されています。これは重大度が「中」の問題で、攻撃者がアクセス制御を回避できる場合があります 59。

19 16 18 8

112 1

4 6 3 3 3 4 19 17

73

セキュリティ

アプリケーションおよびサーバー管理


/フォーマット

/JSON


/フォーマット

/XML


/クライアント/HTTP


/クライアント/SOAP

依存関係インジェクションとアスペクト指向式言

語

ファイルユーティリティ

ファイルユーティリティ/ファイルIO


/コレクション


/リフレクション

セキュリティ

/認証と権限付与

Webフレームワーク

ログ記録

セキュリティ/検証

security/validatio

n

Sonatypeのオープンソース分類別のVC上位25個(FP)

脆弱性の数


80

70

60

50

40

30

20

10

0

図 42.VC上位 25個 (FP)の Sonatypeオープンソース分類別に見た脆弱性の数

__________

59 https://cwe.mitre.org/data/definitions/173.html

https://cwe.mitre.org/data/definitions/173.html

https://cwe.mitre.org/data/definitions/173.html


図 43から分かるように、CRDリストとSPリストでは 18のコンポーネントが共通しています。Sonatypeのデータが示すように、この 18のコンポーネントには 59の脆弱性が見つかっています。このうち9つのコンポーネントが Springフレームワークに関連しており、59の脆弱性のうち29がこの 9つの Springコンポーネントで発見されています。問題点としては、「式言語インジェクション」、「不適切な入力検証」、「不適切な権限付与」、「信頼できないデータのデシリアライゼーション」、「設定」、「クロスサイトスクリプティング(XSS)」などが挙げられています。開示された脆弱性が最も多い Springコンポーネントは org.springframework:spring-webでした (11の脆弱性 )。

共通するコンポーネントのうち残りの9つは com.google.guava:guava、commons-collections:commons- collections、ch.qos.logback:logback-classic、org.apache.httpcomponents:httpclient、commons-beanutils:commons-beanutils、com.fasterxml.jackson.core:jackson-databind、com.fasterxml.jackson.core:jackson-core、org.javassist:javassist、commons-codec:commons-codecでした。上位25個 (CRD)データには 25の脆弱性タイプ (CWE)の脆弱性があり、上位 25個 (SP)データには 23の脆弱性タイプがありました。上位 10個の CWEには、両方のデータセットで同じCWEが入っています。

図 43.中央リポジトリダウンロードリストとSonatype需要リストの VC上位 25個

187 7

Sonatype需要




52

図 44は、VC上位 25個における開示された脆弱性の数を、Sonatype需要データと中央リポジトリダウンロードデータごとに示しています。これは、全バージョンのコンポーネントを対象にした数です。3つすべての VC上位 25個リストに挙がったコンポーネントの平均使用年数は 10年です。

VC上位 25個 (CRDコンポーネント )全体で、重大度「高」とされる既知の脆弱性の最大数は 15、重大度「中」では 8でした。VC上位 25個 (CRDコンポーネント )のモードは 1となっており、これは上位 25個のコンポーネントの大半に脆弱性が 1つ存在することを意味します。VC上位 25個 (SPでも同じ傾向が見てとれました。25コンポーネントが、少なくとも 1つのバージョンで既知の脆弱性を抱えていましたが、そのうち 22は、脆弱性の報告がないバージョンが最低 1つありました (VC上位 25個の CRDリストおよび SPリストの両方で )。従って、エンタープライズアプリケーションで最も参照されているコンポーネントには「既知の脆弱性」が少なく、統合のためのコンポーネントに修正版 /パッチ適用版が高い確率で存在すると見なすことができます。コンポーネントを適切に管理し、既知の問題に対する修正が提供されるまで軽減策を適用することで、リスクプロファイルを改善できます。

まとめ攻撃者への対抗手段を取っている組織にとって、今日の大胆で執拗な攻撃を考えると、なんとか持ちこたえている自分たちを誇らしく感じるかもしれません。しかし、これまでの対応を振り返ってみてください。一般に提供されているセキュリティ対策の導入をたびたび怠り、均衡状態を維持できていないという事実に気付くかもしれません。ソフトウェアシステムのセキュリティ障害の原因としてよく引き合いに出される人的要因は、このレポートで扱ったテーマの 1つでもあります。「自動化できるタスク」を自動化し潜在的な人的ミスを

重大度別に見たVC上位25個の脆弱性

脆弱性の数

0 454025 3020 3515105

37高

41中

38

42

低

VC上位25個のSonatype需要統計での脆弱性数

VC上位25個の中央リポジトリダウンロード統計での脆弱性数

11

正規化されたSO

NATYPE

の重大度

図 44.正規化された Sonatypeの重大度別に見た VC上位 25個 (CRD/SP統計 )での脆弱性


失くすことは、少なくとも無作為攻撃に対する保護レベルを強化する戦略にはなるかもしれません。つまり、「攻撃されるか否かが問題ではなく、いつ攻撃されるかが問題である」という考えに従って準備しておくのです。

これは明らかに納得のいく話であり、考えられる明確な解決策が存在します。エラーが発生しやすいタスクを自動化し、ヒューマンエラーの影響を軽減すればいいのです。自動化は、DevOpsパラダイムに完全に適合するだけでなく、オープンソースコンポーネントとそれに必然的に付随する脆弱性を管理するという戦略に対する適切なソリューションでもあります。このレポートで取り上げたいくつかの調査によると、放置されているオープンソースソフトウェアやその他のサードパーティコンポーネントは、ソフトウェアシステムの完全性を守るうえで重大なリスクをもたらす恐れがあります。ただし、コンポーネントの依存関係によって人為的脆弱性が生まれる可能性があるので注意してください。脆弱性分析では、サードパーティコンポーネントの明らかな脆弱性が真に有効で対象範囲に入っているか十分な注意を払って確認する必要があります。

最後に、「シフトレフト」は月並みな対策になりつつありますが、このレポートで取り上げているような一部のリスクを軽減するうえで役立ちます。開発者がコードセキュリティの問題を迅速かつ頻繁に特定できる環境の構築は、タスクの自動化とサードパーティのコンポーネント管理にうまく適合する戦略です。これら 3つの戦略を組み合わせると、ハッカー予備軍やこのレポートで言及した「能力の均衡状態」からソフトウェア /データの完全性を守る防御側へと力関係を逆転させることができます。

著者 :Alexander M. HooleNidhi ShahSejal KamaniAlvaro MunozLuther MartinRob LemosBruce C JenkinsHarley AdamsStan WissemanBruce MayhewMichael Fanning

貢献者：Gazi MahmudDylan ThomasTim CappettoSonatype Inc.


191-JA0002-001ﾠ|ﾠMﾠ|ﾠ07/20ﾠ|ﾠ© 2020 Micro Focus or one of its affiliates.Micro FocusおよびMicro Focusロゴは、英国、米国、およびその他の国におけるMicro Focus、その子会社、関連会社の商標または登録商標です。その他すべての商標は、該当する所有者に帰属します。

お問い合わせ先：www.microfocus.com

マイクロフォーカスエンタープライズ株式会社[email protected]

https://www.microfocus.com/ja-jp/about/contact/

mailto:[email protected]

http://www.microfocus-enterprise.co.jp

2019 年アプリケーション セキュリティリスクレポート - …...レポート 2019...

Documents

2019 年アプリケーションセキュリティリスクレポート - …...レポート 2019...