システム運用やセキュリティを主業務としている方々の中には大型連休前になると憂鬱になるという方もいらっしゃるのではないでしょうか?そのようなタイミングを計ったように大き目な脆弱性発見のニュースが飛び込んでくるように思えます。記憶に新しい2021年12月に発生したLog4jの脆弱性は皆さまどのように対応されたでしょうか?
今回はこれに関連してオープンソースソフトウェア(OSS)を効率良く管理するためのソリューションをご紹介していきます。

オープンソースソフトウェア(OSS)とは

昔々、OSSと聞いて真っ先に思い浮かぶのはLinuxやBSDなどのオペレーティングシステム(OS)だったように思います。しかし昨今ではOSは勿論ですが、どちらかと言うとアプリケーション開発に必要な様々なライブラリや開発フレームワークなど(以降、便宜上パーツと言います)を指すことが多いように思います。

OS Linuxなど
ミドルウェア Apache Tomcatなど
開発フレームワーク Struts、Springなど
ライブラリ Jackson、Hibernateなど

現在のアプリケーション開発は、可能な限りのスピード感で、いち早くアプリケーションを市場に投入することで、組織の競争力を上げ、収益へと繋げていくことが求められています。そのスピード感を実現するためには、一からアプリケーションのコーディングを行うのではなく、有志が開発した無償で利用可能な「出来合い」のパーツを組合せ、それらの連携部分や必要最低限な部分を独自のコーティングでまかない、仕様、設計に合ったアプリケーションに仕立てる手法がメインストリームになっています。この有志が開発した様々なパーツがオープンソースソフトウェア(OSS)です。
膨大な数の便利なパーツは「それなり」に動くものとして提供されていますが、安全性については誰かが保証するものでなく、利用は自己の責任において行うのがルールです。
更に、OSSの複製や改変といった利用範囲はOSSライセンスによって制限されていることを忘れてはいけません。例えば「GNU General Public License」は、コピーレフト型と呼ばれるライセンス形態で、他のコードと組み合わせた場合、他のコードのソース公開も求めるものです。つまりOSSの利用を行った自社ソフトウェアについてもOSSとすることが義務付けられます。OSS利用の際はライセンスにも注意することが必要です。

何を管理するのか?

OSSの利用は自己の責任において。重い言葉ですね。では責任を果たすためには何をする必要があるのでしょうか?
それは、OSSの管理です。もう少し具体的に書くと、下記の2点だと言われています。

セキュリティリスク 利用しているパーツに右記のリスクが発生していないかを確認します。 使用しているパーツが棚卸しできているか
セキュリティ脆弱性などの不具合はないか
アプリケーションの動作に影響はないか
ライブラリ同士の依存関係が壊れないか
コンプライアンスリスク 利用する様々なOSSが提示している使用許諾条件に反していないかを確認します。 利用規約に反していないか
損害賠償請求を受けるリスクはないか

ここでは、「セキュリティリスク」に注目します。
それぞれのパーツでセキュリティ脆弱性が発見され、確定情報になった段階で米国MITRE社が運営するCVE(Common Vulnerabilities and Exposures)に掲載されます。これは世界中の脆弱性情報が集約されたデータベースです。下記の図①に示す通り、毎年膨大な数の脆弱性が登録され、近年その数は爆発的に増加している状況です。掲載情報は脆弱性を含んだソフトウェア名とそのバージョン、事象と影響、対策方法などを含みます。しかしOSSである以上、対策されるかどうかは世界中の有志次第であり、対策は義務付けられていないということを予め理解しておく必要があります。
とは言え、世界的に影響を及ぼすような脆弱性については比較的迅速に対応されるのがこれまでの流れです。私たちは利用するOSSの不具合、脆弱性の有無、対策がなされているかを把握する必要があります。

図① 報告されたCVE数の推移

image1

参考資料:Annual total CVEs published 2002 to 2020 Vulnerability Forecasting: In theory and practice. ÉIREANN LEVERETT, MATILDA RHODE, ADAM WEDGBURY, Airbus, U.K.

対策がなされたバージョンが公開された場合、当該パーツを自社のアプリケーションが使用している古いパーツと差し替えることになりますが、その際に問題になるのが、他のパーツとの依存関係性です。パーツの中のAというライブラリをA’に差し替えた場合、Aを使っていたBというライブラリは正常に動作するのか?この依存関係性が幾多にも絡み合っている場合があり、これを紐解き、検証環境での動作確認を行うという流れになります。これが非常に骨の折れる作業で、人的リソースを要求されるアクションです。そして複数の脆弱性が発見された場合にはその数だけ対応しなければなりません。これを怠って本番アプリケーションに差し替えを適用すると、脆弱性を突いた悪意ある攻撃を受け、顧客情報の流出といった重大インシデントに繋がる恐れがあるため、動作検証は避けて通るわけにはいきません。

また、CVE番号の付いた脆弱性が報告されているが、よくよく確認してみると影響がある特定のパーツはインストールこそされているが、自社のアプリケーションでは使用しておらず、アンインストールを行うのみで済むケースもあります。このような場合、影響がなかったことを確認できて良かったとポジティブに考えられればよいですが、骨折り損と考えてしまうと、予め管理していればこの手間は省けたのではないか?と疑問を抱いてしまうのではないでしょうか。

OSS放置によるリスクとは

端的に言えば、サイバー攻撃を受ける可能性があります。攻撃によるサービスダウン、情報漏洩、攻撃の踏み台にされるリスクが自社のアプリケーションに発現します。
昨今のサイバー攻撃は一般に報告された脆弱性の悪用方法をいち早く取り入れ、Bot(攻撃を自動化したツール)による無差別攻撃が行われることが多いです。放置された脆弱性は必ず悪用されます。
よく耳にする「うちには取られて困る情報はないから」という問題の先送りにより、自社の利害だけには留まらず、攻撃の踏み台として悪用され、他システム攻撃への一端を担がされることになる可能性があります。

直近では、Apacheに含まれるLog4jという利用(者)数が非常に多いライブラリに極めて重大な脆弱性(CVE-2021-44228)が発見されました。この件は世界的に見ても影響度合いが非常に大きくなることが予想されたため比較的迅速に修正版がリリースされました。また事態を重く見た米国政府は同国の一般企業に対してLog4j対策を徹底するよう強く要請を行い、従わなかった場合には罰則もあり得るとしました。その甲斐あってか現状目立った影響は見られていません。
少し遡ると、2017年には米国消費者信用情報会社のEquifax社が、世界中で広く利用されているJavaアプリケーションフレームワークStrutsで発見された脆弱性(CVE-2017-5638)の対策を実施しなかった結果、約1億4千万人の消費者信用情報を流出させ、米国政府から約750億円の制裁金支払いを命じられました。
この事例が示すことは、常に自社アプリケーション、システムが利用しているパーツのバージョン管理がなされていないと、必要な対策さえスピード感を持って取り組めなくなってしまうということです。

ここ数年来、「サプライチェーン」におけるOSS利用のリスクも考慮する必要性が問われています。ここでの「サプライチェーン」とは、ある特定のアプリケーションAを構成するアプリケーションサブセットの開発を幾つかの協力会社が行い、納入することを指します。このような場合において、アプリケーションAの持ち主は納入されたサブセットで使用しているパーツ(ライブラリなど)を、自社が開発したアプリケーションと同様に管理する必要があります。なぜならいくら自社がOSS管理を徹底していたとしても、サブセットに含まれるライブラリが脆弱であれば、その弱い部分を突かれて攻撃を受ける可能性があるためです。
まるで路上におけるもらい事故のようです。国家レベルで事故に合ってしまうことは許されるものではなく、これを抑止するために、米、バイデン大統領は「国家のサイバーセキュリティ改善に関する大統領令(Executive Order on Improving the Nation’s Cybersecurity)」を2021年5月に発布しました。その中に含まれるのが、「ソフトウェアのサプライチェーンセキュリティの強化策」=連邦政府に納入されるソフトウェアを構成する成分表を公開することが盛り込まれている点に注目すべきです。この成分表は「Software Bill of Materials(SBOM)」と称されます。読んで字のごとく、提供するソフトウェアを構成する様々なパーツはどこでどのように製造され、どのようなバージョンなのかなどの情報を含め、継続的に利用者に対して公開する必要があるのです。現在のところ米国政府および米軍関係に納入するソフトウェアに関してこの法令が適用されています。この流れが一般企業や組織、果ては世界中のIT業界に広がる可能性は十分に考えられます。

効率良くOSS管理を行う

「セキュリティ対策は手間がかかる」とよく言われますが、確かにその通りです。人力で様々な対策を行うのは気の遠くなるような時間と人手が必要になります。更にセキュリティ対策は一度ではなく継続して行う必要があると聞いたら誰もが匙を投げてしまうのも無理はないでしょう。
しかし、ITの世界には「テクノロジー」という強い味方がいます。多くの人々が課題と感じる手間作業とその継続性を可能な限り自動化したのがContrast Security社が提供するツール(サービス)です。とりわけここまでで説明したOSS管理はContrast SCAを利用することで劇的に効率化することが可能になります。
管理する対象システムにエージェントと呼ばれる小さなプログラムを導入することで、当該サーバやアプリケーションが利用するすべてのOSSコンポーネントの一覧をバージョン情報も含めて作成し、どのアプリケーションがどのOSSを利用し(利用していないか)、どこで実行されるか、既知の脆弱性はないか、管理者が何をすべきかを継続して監視することが可能になります。また、ライブラリの更新時、常に管理者や開発者の頭を悩ませる依存関係性についても自動で検証する仕組みを備えています。(図②③参照)

図② ContrastサーバにてCVE報告済の利用中ライブラリが存在することを指摘

image2

 

図③ Contrastサーバにて利用ライブラリの依存関係を赤字で警告

image3

SCAをご導入いただき、効果的なOSS管理を実現されているお客様事例はこちらです。

またContrast Protect(RASP製品)を組み合わせることで、万が一の攻撃に対して自動的に通信をブロックして安全性を確保する拡張性もあります。この仕組みを導入している企業は先般のLog4Shellによる攻撃を特別な施策を取らずとも防御したエピソードは是非ご覧いただきたいと思います。
「CONTRAST SECURITYは、LOG4J (LOG4SHELL)の 脆弱性攻撃から、グローバル企業およびFORTUNE 500の顧客企業を保護」

まとめ

市場において勝ち抜くためは高速化の一途を辿るアプリケーション開発においてその安全性をないがしろにするわけにはいきません。貴重な人的リソースを確保するため、機械で処理可能なタスクは積極的に切り出し、効率化をはかることが重要です。ツール導入時の設計、運用時の設計など、ユービーセキュアはお客様に寄り添いながら一丸となって課題を解決していくことモットーとしています。もしセキュリティの課題を抱えていらっしゃったら、是非お気軽に弊社までご相談いただければと思います。

詳細・お問い合わせはこちら