今回は青山にあるOracle青山センターさんよりお送りしております。
随時まとめを投稿していきたいと思います。
(2010/3/6 13:07追記)
スタートしました。まずは恒例のご挨拶＆自己紹介から。
(2010/3/6 13:50追記)
自己紹介終了、只今1回目の休憩中。休憩終了後はいよいよ本編の開始です。
(2010/3/6 15:05追記)
Session1:「Security Development Lifecycle(MS ジョン・ルー氏)」
MSにおけるSDLの考え方については、ココを参照。
英語Onlyですが、ココも参照されると良いでしょう。
・各種S/W、特にWebAppについてはオンラインという特性上、常に悪意ある攻撃に対する危機に晒されていると言える。
・しかも攻撃のルート・方法は多岐に渡る。
・例え内部でしかアクセスできないモノであっても、様々なルートから攻撃が来る以上、対策する必要がある。
・セキュリティ対応は「パッシブ」と「プロアクティブ」の2種類がある。
・パッシブは従来型の対応、基本何かあったら都度対応(パッチとかパッチとかパッチとか(笑))。
・対してプロアクティブは、先に対応してしまおうという方法、ベストプラクティスを普及し、それに従い開発等を行い、脆弱性の芽を潰すという考えである。
・SDLとは言え、基本はソフトウェア開発ライフサイクルの延長線上でしかない……各段階でセキュリティの事を考慮するというエッセンスを加えているに過ぎない。
・例えはトレーニング段階では、通常のトレーニングに加え、セキュリティのトレーニングを加えると言った感じ。
・従来のソフトウェア開発ライフサイクルでは機能を重視していたが、SDLの場合、更にセキュリティの三要素(CIA)を考慮する必要がある。
・MSでは実現するために、体制を組んでいる。セキュリティアドバイザはセキュリティに関する技術・知識を伝達する事が役目で、1～数名存在する。各チームにセキュリティチャンピオンと呼ばれている人が存在し、チーム内のプロダクトに関するチェックを行っている。
・プロジェクト開始時……全員セキュリティトレーニングを実施する。
・勿論その際、上層部に対してこれらの対策を施すには十分なリソースが必要である事を申し送る事も重要である。
・設計段階では、採用するモジュールのメリット・デメリットを十分に検討する。
・今回はトレーニング、脅威モデル、Verificationについて説明を進める。
・セキュリティチャンピオンはプロジェクトの各段階において、チェックシートに対して必要事項を入力し、可否を確認しながら作業を進めている。MSでは全チェックがクリアになるまでリリースできない規定になっているとの事。
・トレーニング段階では、全員が受けるモノ、開発者が追加で受けるモノ、テスターが追加で受けるものがある。全員で受けるモノはセキュリティに関する基礎を、開発者追加版はコーディング時における危険性と対策を学ぶ事になる(例えば各種脆弱性を作りこまないようにするにはどうすればよいかというベストプラクティスを学ぶ事になる)。テスター追加版は、如何に脆弱性を見つけ、開発者に報告するかについて学ぶ。
・脅威モデルについては、この辺が参考になるかも。
[Web アプリケーションの脅威モデル - MSDNライブラリ]
http://msdn.microsoft.com/ja-jp/library/ms978516.aspx
・評価にはSTRIDE脅威モデルを用いる(ココ参照)。
・これらを設計段階で十分に検討する事になる。その際、単純に技術的に検討するのではなく、そのアプリの目的・特性も考慮する事になる。それによって、特に注意するポイントも見えてくる。
・注意するポイントを特定したら、次に対策を検討する。検討では作用・副作用両方と、アプリの目的・特性を考慮した上でどの対策を採用するか検討する事になる。
・結局リスクアセスメント・マネジメントを人力で地道に行う事で実現できている。
・実施はデータフローを用いてブレインストーミング形式で行う。勿論技術的な話だけでなく、コストも考慮する必要がある。
・マネジメントを説得する場合、攻撃を受けた場合の予測被害額と、それに対する対策にかかる金額を示す事で行っている。
・イニシャルコストは確かにかかるが、繰り返しが効くので、結果としてペイ可能との事。
・また既に外部事業者からのチェックを活用している場合でも、SDLを導入した方が良い。
(2010/3/6 15:47追記)
お菓子タイム終了～。後で写真上げます。
(2010/3/6 16:20追記)
Session2:「アクセス制御の共通化を考える（XACMLの話）(Oracle 澤井氏)」
・アクセス制御部分の一元管理→意外と難しい(できる処とできない処がある)
・アクセス制御→認証と認可の2要素で成り立っている
・なぜ共通化が難しい?→「1.それぞれに実装している」「2.共通化するための条件を満たしていない(共通項が存在し、標準化・正規化できないと辛い)」
・XACML(ザクムルと読む)、現在はVer2.0、XMLベースのアクセス制御ポリシーの標準化とプロトコルを規程している。
古い情報だが、この辺りが参考になるかも。
[PKIとPMIを融合させる次世代言語XACML - @IT]
http://www.atmarkit.co.jp/fsecurity/rensai/webserv05/webserv01.html
・SAMLとXACML……排他するものでなく、両方一緒に使うケースもある。
・実装の考慮点
・実現性……適用範囲が狭すぎると対費用効果が低い←JavaAPI/RMI、.NET API、SOAP API、特定のアプリ
・性能面……セキュリティ強化(認可の徹底)のために性能を犠牲にしてはいけない←PEPの実装(キャッシュ、プロトコル)、PDPの配置を工夫する
・ポリシー管理……どのようにポリシーを管理するか?(運用できないシステムに意味はない)←使いやすさ(視覚化)、運用効率、展開計画
・XACML実装例(ココで図が表示された)
・ポリシー設定例(が示されたが割愛)
・動向:NIST RBACに対する認識→スタンダードはあるが、現実に即していない?
・動向:Access Control Model
・ソフトウェア開発とセキュリティ要件の話
・構築フェーズ(既知の問題を潰す)と運用フェーズ(新たな問題を潰す)の違いとか
・機能(コントロールの精度)とポリシーの違い(コントロールの鮮度)とか
(2010/3/6 16:35追記)
お菓子はこんな感じでした～。
随時まとめを投稿していきたいと思います。
(2010/3/6 13:07追記)
スタートしました。まずは恒例のご挨拶＆自己紹介から。
(2010/3/6 13:50追記)
自己紹介終了、只今1回目の休憩中。休憩終了後はいよいよ本編の開始です。
(2010/3/6 15:05追記)
Session1:「Security Development Lifecycle(MS ジョン・ルー氏)」
MSにおけるSDLの考え方については、ココを参照。
英語Onlyですが、ココも参照されると良いでしょう。
・各種S/W、特にWebAppについてはオンラインという特性上、常に悪意ある攻撃に対する危機に晒されていると言える。
・しかも攻撃のルート・方法は多岐に渡る。
・例え内部でしかアクセスできないモノであっても、様々なルートから攻撃が来る以上、対策する必要がある。
・セキュリティ対応は「パッシブ」と「プロアクティブ」の2種類がある。
・パッシブは従来型の対応、基本何かあったら都度対応(パッチとかパッチとかパッチとか(笑))。
・対してプロアクティブは、先に対応してしまおうという方法、ベストプラクティスを普及し、それに従い開発等を行い、脆弱性の芽を潰すという考えである。
・SDLとは言え、基本はソフトウェア開発ライフサイクルの延長線上でしかない……各段階でセキュリティの事を考慮するというエッセンスを加えているに過ぎない。
・例えはトレーニング段階では、通常のトレーニングに加え、セキュリティのトレーニングを加えると言った感じ。
・従来のソフトウェア開発ライフサイクルでは機能を重視していたが、SDLの場合、更にセキュリティの三要素(CIA)を考慮する必要がある。
・MSでは実現するために、体制を組んでいる。セキュリティアドバイザはセキュリティに関する技術・知識を伝達する事が役目で、1～数名存在する。各チームにセキュリティチャンピオンと呼ばれている人が存在し、チーム内のプロダクトに関するチェックを行っている。
・プロジェクト開始時……全員セキュリティトレーニングを実施する。
・勿論その際、上層部に対してこれらの対策を施すには十分なリソースが必要である事を申し送る事も重要である。
・設計段階では、採用するモジュールのメリット・デメリットを十分に検討する。
・今回はトレーニング、脅威モデル、Verificationについて説明を進める。
・セキュリティチャンピオンはプロジェクトの各段階において、チェックシートに対して必要事項を入力し、可否を確認しながら作業を進めている。MSでは全チェックがクリアになるまでリリースできない規定になっているとの事。
・トレーニング段階では、全員が受けるモノ、開発者が追加で受けるモノ、テスターが追加で受けるものがある。全員で受けるモノはセキュリティに関する基礎を、開発者追加版はコーディング時における危険性と対策を学ぶ事になる(例えば各種脆弱性を作りこまないようにするにはどうすればよいかというベストプラクティスを学ぶ事になる)。テスター追加版は、如何に脆弱性を見つけ、開発者に報告するかについて学ぶ。
・脅威モデルについては、この辺が参考になるかも。
[Web アプリケーションの脅威モデル - MSDNライブラリ]
http://msdn.microsoft.com/ja-jp/library/ms978516.aspx
・評価にはSTRIDE脅威モデルを用いる(ココ参照)。
・これらを設計段階で十分に検討する事になる。その際、単純に技術的に検討するのではなく、そのアプリの目的・特性も考慮する事になる。それによって、特に注意するポイントも見えてくる。
・注意するポイントを特定したら、次に対策を検討する。検討では作用・副作用両方と、アプリの目的・特性を考慮した上でどの対策を採用するか検討する事になる。
・結局リスクアセスメント・マネジメントを人力で地道に行う事で実現できている。
・実施はデータフローを用いてブレインストーミング形式で行う。勿論技術的な話だけでなく、コストも考慮する必要がある。
・マネジメントを説得する場合、攻撃を受けた場合の予測被害額と、それに対する対策にかかる金額を示す事で行っている。
・イニシャルコストは確かにかかるが、繰り返しが効くので、結果としてペイ可能との事。
・また既に外部事業者からのチェックを活用している場合でも、SDLを導入した方が良い。
(2010/3/6 15:47追記)
お菓子タイム終了～。後で写真上げます。
(2010/3/6 16:20追記)
Session2:「アクセス制御の共通化を考える（XACMLの話）(Oracle 澤井氏)」
・アクセス制御部分の一元管理→意外と難しい(できる処とできない処がある)
・アクセス制御→認証と認可の2要素で成り立っている
・なぜ共通化が難しい?→「1.それぞれに実装している」「2.共通化するための条件を満たしていない(共通項が存在し、標準化・正規化できないと辛い)」
・XACML(ザクムルと読む)、現在はVer2.0、XMLベースのアクセス制御ポリシーの標準化とプロトコルを規程している。
古い情報だが、この辺りが参考になるかも。
[PKIとPMIを融合させる次世代言語XACML - @IT]
http://www.atmarkit.co.jp/fsecurity/rensai/webserv05/webserv01.html
・SAMLとXACML……排他するものでなく、両方一緒に使うケースもある。
・実装の考慮点
・実現性……適用範囲が狭すぎると対費用効果が低い←JavaAPI/RMI、.NET API、SOAP API、特定のアプリ
・性能面……セキュリティ強化(認可の徹底)のために性能を犠牲にしてはいけない←PEPの実装(キャッシュ、プロトコル)、PDPの配置を工夫する
・ポリシー管理……どのようにポリシーを管理するか?(運用できないシステムに意味はない)←使いやすさ(視覚化)、運用効率、展開計画
・XACML実装例(ココで図が表示された)
・ポリシー設定例(が示されたが割愛)
・動向:NIST RBACに対する認識→スタンダードはあるが、現実に即していない?
・動向:Access Control Model
・ソフトウェア開発とセキュリティ要件の話
・構築フェーズ(既知の問題を潰す)と運用フェーズ(新たな問題を潰す)の違いとか
・機能(コントロールの精度)とポリシーの違い(コントロールの鮮度)とか
(2010/3/6 16:35追記)
お菓子はこんな感じでした～。
