2005年11月04日

IPA・情報セキュリティセミナー(京都)にいってきた

11月2日(水)に京都であった、IPAの情報セキュリティセミナーに行ってきた。
http://www.ipa.go.jp/security/event/2005/sec-sem/index.html

聞いてきたのは、午後の「情報セキュリティ対策技術コース」
講師は園田さん。

人が多くて机にありつけない人たちがかなりいた。
私はなんとか後ろのほうで机をゲット。電源なしでぎりぎり4時間持ちこたえた。

園田さんがものすごくかみくだいて説明されていたけど、それでも中高年のスーツの人たちには難しかったらしい。

その後、迎撃エソカイにもいってきて楽しかった。



講演資料
http://www.ipa.go.jp/security/event/2005/sec-sem/programs.html


以下気になったところをメモ。
---------------------
情報漏洩の傾向と原因分析

○情報漏えいの原因
 JNSA 2004年度・情報セキュリティインシデントに関する調査報告書
 http://www.jnsa.org/active/2004/active2004_1a.html

○暗号化
 鍵はどこにあるの?同じディスクにおいてない?
 暗号化して気休めにしてませんか?

○バランス
 ●ルールに頼り切ってませんか?
 ●技術的対策に期待しすぎるパターン
  手に余って処理しきれないとなってませんか?
  監視するシステムが機能不全を起こしたときのエラー処理をどうするか
 →技術的対策は、増える手順を軽減する目的で導入するとバランスをとれるのでは

○最近の傾向
 個人情報などお金に繋がりやすいデータを狙う
 ツールで攻撃:ツールで見つかる脆弱性をもったサーバも多い


○不正アクセスとはなにか
 一般的な概念
  経産省「コンピュータ不正アクセス対策基準」
  http://www.meti.go.jp/press/past/c60806a2.html
 法的な定義
  不正アクセス行為の禁止等に関する法律
  http://www.ipa.go.jp/security/ciadr/law199908.html


○脆弱性対策への取り組み
 早期警戒パートナーシップ
 http://www.ipa.go.jp/security/ciadr/partnership_guide_200507.html

○ウェブアプリケーションの脆弱性届出状況
 クロスサイトスクリプティング。SQLインジェクションが1・2位。
 2005年第3四半期(7月〜9月)
 http://www.ipa.go.jp/security/vuln/report/vuln2005q3.html

○クロスサイトスクリプティング
 信用失墜につながる
 お金になるので、被害は増えていく傾向
 ●対策
  開発時:
   期待しない解釈をしていないか?ユーザが入力可能な文字を厳密に定義
   ページを動的に生成して出すときもチェック(メタキャラクタのエスケープ処理)
   →2重にチェックする

  参考:
  Webサイトにおけるクロスサイト スクリプティング脆弱性に関する情報
  http://www.ipa.go.jp/security/ciadr/20011023css.html

  セキュア・プログラミング講座
  http://www.ipa.go.jp/security/awareness/vendor/programming/

  運用時:
   アプリケーションファイアウォールを利用
    mod_security、Guardian@JUMPERZ.NET、CodeSeekerなど
   Webサーバ、Webアプリケーションの欠陥修正

○SQLインジェクション
 問い合わせの中にSQL文を混ぜ込んで
 データベースの中を改ざんしたりする
 ●対策
  開発時:
   XSSとそうかわらない
   入力された値を信用せずに、キチンと精査すること
   不正な値を警告・取り除くこと
   →プログラムの定義を厳格につくるのが望ましい
   準備済みSQL文を使用する(バインドメカニズム)
  運用時:
   エラーメッセージを出さない。不用意に出していることが結構ある
   Webアプリケーションの実行する権限を制限する
   Webアプリケーションのパスワードの秘匿
    利用者画面でない、メンテ用画面があることが多い。
    この画面でパスワードを隠しましょうということ
   実行可能なコマンドの制限
   アクセスログの取得および解析
   WebアプリケーションFWの導入
    後付でできるので、バリバリに運用していて作り変えるのが難しいときにいい

○DNS情報の設定不備をついた手口
 ●手口
  DNS情報の設定の不備
  期限切れドメイン名を第三者が取得
 ●脅威
  フィッシングに利用される
  利用者PCへの悪質なソフトウェアインストール
 ●対策
  ドメイン名が安全に運用されているか確認
   自分のサイトに似た名前のドメインも抑えておく
   どういうサイトがあるかを把握
  DNSサーバの登録情報を確認
  DNSサーバを管理委託している場合は、業者が正しくDNSサーバを運用しているかを確認
  
  DNSSecの導入がすすめば安全性もたかまるがいろんな事情があってなかなか進まない

  参考:
  ドメイン名の登録と DNS サーバの設定に関する注意喚起
  http://www.ipa.go.jp/security/vuln/20050627_dns.html

  JPRSがDNSサーバの不適切な管理による危険性解消のための取り組みを開始
  http://jprs.co.jp/press/050804.html

 -----------------
 ※DNSSECってなに?ということでググってみる
 ■e-Words: DNSSEC 【DNS Security Extension】

DNSのセキュリティを向上させるための拡張仕様。サーバとクライアントの間で交わされるメッセージが改ざんされていないことを保証するため、メッセージのハッシュ値を公開鍵暗号方式で暗号化し、メッセージと共に送る。届いたメッセージからハッシュ値を求め、復号したハッシュ値と一致すれば、改ざんが行なわれていない証拠となる。

 ■DNSSEC要不要に関する議論

 ■@IT 第13回 次世代のセキュリティ拡張DNSSECをBIND 9で実現
 
 -----------------

○その他のWebサイトの問題
 ●パス・トラバーサル問題: 公開すべきでないファイルを公開
 ●ショッピングサイトの表記を改ざん問題:
  商品名、値段の書き換えられる
  hiddenタグを使っていると、書き換えられるなど。
 ●フィッシング詐欺
  オレオレ証明書:独自の証明書
  認証局にお金払えばいいのに、私の証明書を信用しなさいと押し付け

 参考:消費者向け電子商取引サイトの運用における注意点
 http://www.ipa.go.jp/security/vuln/20050304_ec_security.html

 ウェブサイトのセキュリティ対策の再確認を 〜脆弱性対策のチェックポイント〜
 http://www.ipa.go.jp/security/vuln/20050623_websecurity.html

○フリーなWebアプリケーションファイアウォール
 mod_security
 http://www.modsecurity.org/

 Guardian@JUMPERZ.NET
 http://www.jumperz.net/index.php

 CodeSeeker
 http://sourceforge.net/project/showfiles.php?group_id=64424&package_id=76046
 --------------------
 ※アプリケーションFWについてのページ
 ○mod_security
  @IT Webアプリケーションに潜むセキュリティホール・第11回 Webアプリケーションファイアウォールによる防御
  Softec mod_securityでWebサーバを守る(第1回)

 ○Guardian@JUMPERZ.NET
  ユーザーズマニュアル日本語版

 ○CodeSeeker
  開発が進んでいないのか情報がほとんどないなあ。
  非営利団体のOWASP、オープンソースのファイアウォール/IDSを公開予定
  
 --------------------

情報セキュリティ技術マップ
○リモートアクセス対策
 VPN
  メリットとして、使い方次第では相手を認証できる
  証明書を持っている人しか通信できない
 SSH
  最近はSSHを狙う人が多い。パスワード解析をする
  証明書なしでパスワードだけで運用すると危険

○定期的な監査
 完全性保護対策
  Tripwireなど
  ひきつぎの時にも役立つ → どの部分をどれだけ変えたかわかる

○情報漏えい対策
 ●スパイウェア・ウイルス対策
  不要な権限を与えない方法も。インストール権限を与えない。
  最近は産業スパイ系も。特定の会社を狙い撃ち
  オープンソースで誰でも開発できるものも。有償サポートもあるらしい。

○脆弱性監査ツール
  Nessus:最近はライセンスが微妙だがまだフリー
  http://www.nessus.org/

  SARA(Security Auditor's Research Assistant)
  http://www-arc.com/sara/


インシデント対応
 JPCERT/CC 技術メモ - コンピュータセキュリティインシデントへの対応
 http://www.jpcert.or.jp/ed/2002/ed020002.txt

○平時におけるインシデント対応の準備
 非常事態ほど手順書がありがたい

 ●バックアップ
  どうやって復旧するか
  原因を特定しないまま、バックアップから戻していいのか?
  どういう状態に戻すか迷う。

○インシデント検知
 本当にインシデントなのか判断がけっこうむずかしい
 インシデントかの確認をすると証拠保全上はよろしくない

○関連組織とのコミュニケーション
 JPCERT/CC 技術メモ - 関係サイトとの情報交換
 http://www.jpcert.or.jp/ed/2002/ed020001.txt

○止め方
 ネットワークを引っこ抜くのは愚の骨頂
 ルータ、FWで止める
 電源を抜くのが証拠保全的にいいらしい
 →システムの状態がそのまま残るので。ネットワーク抜くと状態が変わる

○まとめ インシデント対応の作業手順
 重要なのは作業記録!
 お客さんへどのようにお知らせするかの重要なポイント

○個人情報漏洩時の対応手順
 経産省 個人情報保護に関する法律についての経済産業分野を対象とするガイドライン
 http://www.meti.go.jp/feedback/downloadfiles/i41013fj.pdf


セキュリティ情報収集の方法
こちらに分離
posted by 端っこなひと at 01:28| Comment(0) | TrackBack(1) | セミナー・勉強会 | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前: [必須入力]

メールアドレス:

ホームページアドレス:

コメント: [必須入力]


この記事へのトラックバック

スパイウェア??ボット???
Excerpt: 久しぶりに個人的興味もかねて、情報セキュリティセミナー2005を受けにいってきま...
Weblog: かえるのバタあし
Tracked: 2005-11-08 19:01