11/28/2016

フリーソフトウェアのクイック・セキュリティ・チェックリスト

ISC SANSより

フリーソフトウェア(オープンソースもしくはそうでないもの)は様々な理由で面白い。あなた自身のニーズに適応でき、簡単に複雑なアーキテクチャの中に統合できる。しかし、最も重要なのはもちろん依然として価格である。たとえ、無料ソフトウェアに関連する多くの隠されたコストがあってもだ。もし、問題があれば、解決策を探したり、ソースコードの中に没頭するために多くの時間を費やすかも知れない(そして、誰もが時は金なりということを知っている!)。

今日、もはやインフラにフリーソフトウェアをデプロイすることをためらわない経営陣が増えたが、その解決策は本当に安全なのだろうか? 顧客が私にフリーソフトウェアのセキュリティ監査を実行することについての興味深い質問をしてくれた。その考えとは、彼の(とてもセンシティブな)インフラにデプロイする前にソフトウェアを検証することに関してだ。これは品質保証の類と見ることができる。

その考えは、深いソースコードレビューを実行すること、あるいはツールをペネトレーションテストすることではなく、急所のチェックリストを制定することである。私は既に質問への大まかなリストを集めたので、皆さんに共有したい:

  • 利用するプログラミング言語は何か?
    全ての言語が同じセキュリティの成熟度を持つわけではない。一部のアプリケーションは古くなり定期アップデートがなくなった関数に依存している(PHPが良い例である)。特定のバージョンの言語が必要か? (例: Python 2対Python 3) また、CやPerlで安全なコードを書くことは他の言語ほど簡単ではない。

  • アーキテクチャやセキュリティフレームワークは?
    アプリケーションは仮想環境下でデプロイできるか? Dockerコンテナは利用可能か? それらは他のソフトウェアコンポーネントが必要か? (データベースサーバ、Redisサーバ、...のように) どのくらい簡単にアプリケーションを高い可用性でデプロイできるか? リバースプロキシの背後で適切に動くか (ウェブアプリケーションの場合)? 統合されているか、他のソフトウェアレイヤが必要か?

  • 定期的なアップデートは?
    ソフトウェアにバグやセキュリティの問題があるか? パッチのリリース方法と頻度は? 開発者はどのように反応するか? もし、バグ追跡システムがあるなら、問題を修正するために必要な平均時間をチェックしてほしい。一部のプロジェクトは非常に素晴らしく、通知されて数時間以内に修正を公開するが、他のプロジェクトはこれほど素晴らしくない。他の全てのソフトウェアも同じパッチ要件を満たさなければならない。

  • 次のロードマップは?
    新しい機能を持ったロードマップが存在するか? ユーザは新しい機能の提案や提出(submit)ができるか?

  • プロジェクトの周りのコミュニティはどのくらい大きいか?
    フォーラム、メーリングリスト、github.comに報告された問題をよく調べてほしい。定期的なコミットはあるか? 開発者は簡単に連絡可能か? どのくらいのメッセージがパブリックリソースに投稿されているか?

  • 現在のユーザベースはどのくらい大きいか?
    既存のユーザベースが大きいなら、バグはすぐに見つけられ、新しい機能が提案される見込みはある。今のユーザはアプリケーションを使っている間、幸せそうに見えるか?

  • コードの中のドキュメントやドキュメントの品質は?
    優れたドキュメントはコードがちゃんと維持できていることを意味する。ドキュメントはアプリケーションを運用と問題解決の手助けに必須である。

  • 使われているライブラリのような外部のコードは?
    ほとんどのアプリケーションは外部のライブラリ(OpenSSLについて考えてほしい)に依存している。これらのコードは同じプロセスでフォローされなければならない。

  • データ管理は?
    アプリケーションによって利用/生成されるデータはどのくらい安全か? 「使用中」、「停止中」、「移動中」のデータを考えてほしい。バックアップやリストアの手順はあるか?

  • 設定に十分な細かさがあるか?
    アプリケーションは複雑な設定をどの程度サポートするか? どのくらい難しいカスタマイズができるか? AAA (認証、認可、課金)、RBAC (ロールベースアクセス制御)を実装しているか?

  • アプリケーションの拡張性は?
    アプリケーションはモジュール式で、モジュールやプラグインで拡張できるか? Wordpressのような人気のアプリケーションを考えてみると、コアはかなり上手く管理されているが、プラグインは多くの脆弱性を取り込んでおり、確実に管理されているかどうか分からない。そのため、フリーパッケージに追加されるサードパーティ製モジュールはソフトウェアと別に扱うことをお勧めする。

  • プロジェクトの年齢や成熟度は?
    リリースされたばかりの新しいソフトウェアをすぐにレビューすることはとても難しい。

  • ソフトウェアの配布に使われているライセンスは何か?
    ライセンスはその使用目的に制限がないことを確認するためにレビューしなければならない。フリーソフトウェアの多くは企業利用は無料ではない。もし、あなた自身のニーズにそのソフトウェアを適応する計画があるなら、どのようにしたら既存ライセンスに違反しないか?

  • 他のツールとの一体化は?
    認証メカニズム(LDAP、RADIUS)をアプリケーションに統合するのは簡単か? ログは簡単に書き出せるか? (Syslog、CEF)

  • ソフトウェアに関連するCVEはあるか?
    直近xヶ月でリリースされたCVEの数は? CVEの重大度は何か? CVEで問題が繰り返されているか(一つのインスタンスを修正しただけか、同じような問題に残りのコードベースを調べて、同じように上手く修正しているか)。最近リリースされたソフトウェアは、関連するCVEがなくても安全だとは言えない。CVE数が多い場合、コードの品質が良くないか、コードを分析して穴を見つける人が多いことを示している。反対に、CVE数が少ないと、必ずしも安全なコードを作っているとは言えない。私は、CVEの問題を追跡し続け、あなたの決定の基準にするためCVEを修正するためにどのくらい早くパッチがリリースされているかを確認することをお勧めする。

  • コマーシャルなソリューションに使われているか?
    営利会社は製品にプロジェクトを組み込む場合、これらの会社はセキュリティ問題を修正することを確実にするために大きな開発者チームを持っている。

  • コマーシャルなサポートは?
    問題の集積やデバッグを手助けるためにフリーランサーを雇うことができるか?

リソースがあれば、アクセス制御、認証、暗号化、SQLの処理のような重要な分野の迅速なソースコード分析が役立つ。もし、アプリケーションがバイナリに依存するなら、バックドアのような潜在的な問題を検出するのに、Cuckooのようなサンドボックスを通して実行してみてはどうだろう。

最後の意見として、商用製品でも同じことをやらない理由はない。ほとんどの商用製品でもオープンソースのライブラリ/ソフトウェアを利用している、あるいは依存している。また、商用製品だからといって安全であるという意味ではないことを肝に銘じておいてほしい。

リストに追加する他の規制はありますか? 気軽にあなたのコメントを共有して下さい!

Xavier Mertens (@xme)
ISC Handler - フリーランスのセキュリティ・コンサルタント