[レポート] re:Invent 2019 毎日がゼロデイ オープンソースとセキュリティ #reinvent #OPN219

本記事はAWS re:Invent 2019のセッション「OPN219 - It’s always day zero Working on open source and security」 のレポートです。
2019.12.05

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは。
ご機嫌いかがでしょうか。
re:Invent2019 に参加するためラスベガスへ来ています吉井 亮です。

はじめに

本記事はAWS re:Invent 2019のセッション「OPN219 - It’s always day zero Working on open source and security」 のレポートです。

セッション概要

AWSでは、セキュリティが私たちの最優先事項であり、オープンソースの仕事にも当てはまります。 オープンソースソフトウェアのセキュリティリスクを監査するために開発した手法、ツール、およびプロトコル、これらのリスクを軽減する方法、オープン性とコラボレーションの間の扱いにくいバランスを管理し、禁輸されたセキュリティ問題と重大な修正を処理する方法についてお聞きください。

スピーカーはこの方。

Colm MacCarthaigh - Senior Principal Engineer, Amazon Web Services

セキュリティは最優先事項

セキュリティのために考えたこと

  • 開発文化のなかでどのようにセキュリティを推進し報いるか?
  • どのようにして自分達のソフトウェアにセキュリティを組み込むか?
  • 新しい出現する脅威にどのように対応するか?
  • セキュリティイシューをどのように処理するか?

オープンソースソフトウェアを扱うものとして
セキュリティは本当に本当に大切なものです。

読みやすいコードを書く

セキュリティを重視するプロジェクトのコードは読みやすいものです。
読みやすさとセキュリティは密接に関連する傾向にあります。

多層防御

セキュリティを重視するプロジェクトは多層防御を行っています。
セキュリティ防御における単一の致命的な欠陥を無害にします。

セキュリティを処理する

イシューに応じてセキュリティ重要度を設定しています。

LOW

実害が少ないイシュー
リソース使用率のイシュー
安全ではないパフォーマンスイシュー

MEDIUM

ローカルメモリ漏洩
ローカル権限昇格
リモートへの破壊的行動
通常ではない状態への遷移

HIGH

リモートメモリ漏洩
リモートから何か実行される
データ破壊
認証のバイパス

開発者チームとセキュリティ研究者チームの関係

プロダクト開発者とセキュリティ研究者チームが敵対関係になってはいけません。
同じサイドに立って (つまり協力して) 悪意あるアタッカーに対抗していきます。

セキュリティ脅威に対応

イシューに関する通知を受け取る

セキュリティ研究者チームからセキュリティイシューに関する情報や通知を受け取ります。

通知を確認する

通知の内容を確認します。
適切な情報だったら情報提供者への感謝を忘れずに。

イシューを理解する

関係者でイシューについて詳細まで調べます。
全ての関係者がイシューを理解したことを確認します。

既存の対応策を考える

関係者で話し合い、既存の対応策が存在するかを調べます。

対応策を議論する

イシューに対する対応策を議論します。
パッチを適用するのか、代替案で対策するのかを関係者で議論します。
研究者にテストに関する有益な情報がないかを確認します。

タイムラインに合意する

対策の期限を決めます。
期限を決めたら研究者にイシューの情報公開はいつかを訪ねます。
必要に応じて CVE を割り当てます。

情報開示を調整する

必要に応じて同じイシューの影響を受ける他のチームに情報を開示します。

対応策の実施

対応策を実施します。
本番環境に実施する前に別の環境でテストをしておきます。

備えに対する問い

CVE を検索

プロジェクトがどのくらいの頻度でセキュリティイシューによる影響を受けていますか?
影響を受けた場合、対策までにどのくらいの時間を要していますか?

プロジェクトのセキュリティポリシーは?

プロジェクトにセキュリティポリシーは存在しますか?
チームはセキュリティイシューに対応する準備はできていますか?

情報開示?

セキュリティイシューの情報開示を行えますか?

コードのテスト?

豊富なテストパターンがありますか?
テストが容易にできるフローはありますか?
新しいテストパターンを作るのは容易ですか?
コードは読みやすいですか? それとも読みにくいですか?

コード解析は?

コード解析方法は?
著名な解析方法を用いるとコード解析が素早く実施できます。

まとめ

セキュリティリスクの評価をすることが、技術的かつカルチャーとして根付いている必要があります。
セキュリティ観点でコードを見る、セキュリティポリシーを文書化する、イシュー処理の適切な前例を用意しておきましょう。

所感

いくらセキュリティ対策の準備をしたとしても
カルチャーとして根付いていないと効果がある対策ができないのだろうと
改めて感じました。
関係者全員が当たり前のように自然にセキュリティ対策に取り組むカルチャー作りを!

以上、吉井 亮 がお届けしました。