security/audit/auditing (r1.18)

[victory <victory.deb@xxxxxxxxx>]

security/audit/auditing (r1.18)

#use wml::debian::template title="監査の実施"
#use wml::debian::recent_list
#use wml::debian::translation-check translation="1.18"

<p>このページではパッケージ監査の実施にあたって必要な手順の概観を提示します。</p>

<p>第一段階は調査するパッケージを実際に選択することで、
セキュリティがより重要であるものを取り上げるべきです。</p>

<p>決断方法についての提案ですが<a href="$(HOME)/security/audit/packages">\
監査にあたって私たちが最も重要だと考えるパッケージ一覧</a>を見てみてください。</p>

<p>一つはっきりさせておくべきことは、私たちは、
以前にパッケージの監査が確実に行われたことを示したいのでは<em>ない</em>ということです。
多くの人が同一パッケージの調査を選択するとしたらそれは良いことで、
そのパッケージはセキュリティに細心の注意を払うべきだ、
と多くの人が考えていることを実証することになります。</p>

<p>パッケージを本質的に無作為に選んでもらうことで、私たちは調整作業を簡略化できます。
さらに「X さんがよい仕事をすることをどうすれば確信できるのか ?」という問題も解決することができます
(遅かれ早かれ誰か他の人が同一プログラムを選んで検査することになるのでその必要はありません)。</p>

<h2>監査の開始</h2>

<p>パッケージを選択したら今度は実際に監査を始める必要があります。</p>

<p>どんな種類の問題を探せばよいのかよくわからなかったらまず、
安全なソフトウェアの開発方法に関する本を読むことから始めてください。</p>

<p><a href="http://www.dwheeler.com/secure-programs";>Secure Programming
for Linux and Unix HOWTO</a> によい情報が多くあり役立つでしょう。
Mark G. Graff と Kenneth R. van Wyk による
<a href="http://www.securecoding.org/";>Secure Coding: Principles &amp;
Practices</a> も素晴らしい本です。</p>

<p>ツールは不完全ではありますが、脆弱性らしきものを見つけるにあたっては非常に役に立ちます。
一部の利用可能な監査ツールやその使われ方についてのさらなる情報は、
<a href="tools">監査ツールのページ</a>を見てください。
</p>

<p>コード自体を見るのと同様に、そのパッケージの付属文書を読んでみる、
インストールを試してみる、使ってみるというのもよい案です。</p>

<p>こういったことにより、
標準的な操作でそのプログラムの機能を損なわせる方法を考え出せるかもしれません。</p>


<h2>問題の報告</h2>

<p>調査しているパッケージに問題を見つけた場合、それを報告するべきです。
セキュリティバグを報告する際、パッチの提供も考えてみてください。
それにより開発者は直ちに修正できます。
攻撃例を提供する必要はありません
(<em>exploit</em> や <em>概念実証</em> とよく呼ばれます)。
これはパッチがそれ自体でそういったことを提示してしまう類のものなので、
バグを悪用した攻撃の成功につながるため、
通常は正式なパッチを提供するための時間的猶予を与えることが最善となります。</p>


<p>これは Debian でセキュリティバグを見つけた時に推奨される手順一覧です:</p>

<ol>

<li>バグのパッチを作るか十分な情報を収集するようにしてください。
それによって他の人がバグの存在を確定できます。
理想的なのはそれぞれの報告に発見した問題の修正方法が含まれることで、
その修正方法は試験の上、問題を実際に終息させることが確認されているものとなります。

<p>修正方法がわからない場合は、問題の適用範囲や相対的な影響の大きさ、
それに次善策があるとなお良いでしょう。</p></li>

<li>まず、そのセキュリティバグが安定版 Debian リリースに存在するのか、
他のディストリビューションや上流のメンテナにより提供されたバージョンに\
存在するのかを調べ直します。</li>

<li>上で調べ直した結果を踏まえて、問題を報告してください:

<ul>

<li>上流のメンテナ宛にセキュリティ連絡用の当該 e-mail 経由で、分析とパッチを添えて。</li>

<li>そのバグが Debian のリリース済みのバージョンに存在する場合 Debian
セキュリティチーム宛に。Debian セキュリティチームは通常、<a
href="$(HOME)/security/cve-compatibility">CVE 名</a>を脆弱性に割り当てます。
セキュリティチームは、必要に応じて他の Linux
ディストリビューションとの調整やパッケージメンテナへの連絡を行います。
そのメールの複製をパッケージメンテナにも送ることはできますが、
それは危険性の低い脆弱性 (以下参照) を扱う場合だけにしてください。</li>

<li>そのバグが Debian のリリース済みのバージョンに存在せず、そのアプリケーションが
他のディストリビューションやオペレーティングシステムに存在する可能性がある場合は、<a
href="http://oss-security.openwall.org/wiki/mailing-lists/oss-security";>oss-security</a>
(開示されたセキュリティバグの報告および議論に使われる公開メーリングリスト)
にメールを送ってください。バグを Debian セキュリティチーム宛に既に送っていれば、
チームの方でこのリストにも転送するのでこれは必要ありません。</li>

<li>そのバグが Debian のリリース済みのどのバージョンにも存在<strong>せず</strong>、
そのアプリケーションが他のどのディストリビューションや\
オペレーティングシステムにも含まれ<strong>ない</strong>
ことが絶対に確実であればバグ追跡システム経由で報告してください。</li>

</ul></li>

<li>脆弱性が公開 (つまり Debian セキュリティチームや他のベンダーが勧告を発表)
されたら、バグとその関連情報を全て Debian バグ追跡システムに提出し、
Debian のまだリリースされていないバージョン (つまり <em>sid</em> や
<em>testing</em>) のセキュリティ問題を追跡出来るようにすべきです。
これは通常セキュリティチーム自身が行いますが、
見逃していることに気付いた場合やセキュリティチームに報告していない場合は
自分で報告することも可能です。
バグに適切なタグ (<em>security</em> タグを使ってください) を付けたか、
適切な優先度 (通常 <em>grave</em> かそれ以上) がセットされているか確認してください。
当該 <a href="$(HOME)/security/cve-compatibility">CVE
名</a>が既に割り当てられている場合はそれをバグの題名に確実に含めるようにしてください。
これでセキュリティバグを追跡する道筋が出来、Debian
のリリース済み、未リリース双方のバージョンで修正されることになります。</li>

<li>望むなら、問題が公開されればこの情報を
<a href="https://lists.grok.org.uk/mailman/listinfo/full-disclosure";>full-disclosure</a>
や <a href="http://www.securityfocus.com/archive/1";>Bugtraq</a>
等の完全公開されている公開メーリングリストに転送することもできます。</li>

</ol>

<p>ここに挙げた手順は見つかった脆弱性に関わる危険性によることに注意してください。
危険性を評価する際の基準となるのは:</p>

<ul>
<li>脆弱性がリモートかローカルか。</li>
<li>脆弱性が悪用された場合の被害。</li>
<li>脆弱性により影響を受けるソフトウェアの普及度合い。</li>
</ul>

<p>取るべき手順は、
例えば認証済みユーザによってのみ使用可能なローカルのシンボリックリンク攻撃で、
システムに損害を与える手段を提供するだけのものを報告するのと、
普及しているソフトウェアに管理者特権を提供するリモートのバッファオーバフローが\
存在するのを報告するのとでは異なります。</p>

<p>ほとんどの場合セキュリティバグ修正されるまで公開されるべきではないので、
標準となっている <a href="http://bugs.debian.org/";>Debian バグ追跡システム</a>
経由での報告は<em>せず</em>、まずは<a href="$(HOME)/security/">セキュリティチーム</a>
宛に直接問題を報告してください。セキュリティチームが更新パッケージのリリースを担当し、
問題を修正したら BTS に報告します。</p>


-- 
victory
no need to CC me :-)
http://userscripts.org/scripts/show/102724