社内の情報共有にchatterなどのツール活用、今更感がありますが提案していこう。
facebookなど外向けは考えず、とりあえず内向きから。
ガイドライン、詳細ルール、準備はあるのでうまく進めたいですね。
2012年04月26日
2012年04月05日
SIEM
既存のSIEMをコンピュータインシデント、変更管理、内部統制の要件を満たす事を目的に置き換えました。
改めて、ステークホルダーの管理、プロセス改善を考える良い機会でした。詳細はまた追って
改めて、ステークホルダーの管理、プロセス改善を考える良い機会でした。詳細はまた追って
2010年01月11日
クラウドのセキュリティ
しばらく更新が空いてしまいましたが、
その間にすっかりクラウドがはやり、
ステークホルダー間での認識の差が顕著になり、その調整をたびたび行ってきました。
ISMSを運用する立場的には変わりはないのですが、その経験談も更新したいと思います。
その間にすっかりクラウドがはやり、
ステークホルダー間での認識の差が顕著になり、その調整をたびたび行ってきました。
ISMSを運用する立場的には変わりはないのですが、その経験談も更新したいと思います。
2009年01月20日
incident management & IT Security evaluation
インシデントマネジメントのレスポンス時間と質を向上するために、
対応チームやプロセスのセットアップをする必要のある方。
また、インシデントの受付を外注化する準備をされる方、で海外とやり取りをする可能性のある方、
ISO/IEC 18044:2004が参考になると思います。
先日、同じような問い合わせを受けた際にこれを薦めました。
いろいろな書籍や情報があるのですが、海外とのやり取りを考えると言葉をはじめから統一しておかないと微妙なずれが発生すると思います。
ついでに、ISO/IEC18045
IT Security evaluation
あらゆるevaluationについて議論されています。ご参考までに
対応チームやプロセスのセットアップをする必要のある方。
また、インシデントの受付を外注化する準備をされる方、で海外とやり取りをする可能性のある方、
ISO/IEC 18044:2004が参考になると思います。
先日、同じような問い合わせを受けた際にこれを薦めました。
いろいろな書籍や情報があるのですが、海外とのやり取りを考えると言葉をはじめから統一しておかないと微妙なずれが発生すると思います。
ついでに、ISO/IEC18045
IT Security evaluation
あらゆるevaluationについて議論されています。ご参考までに
2009年01月16日
2009年01月15日
2008年12月25日
共通脆弱性評価システムCVSS
共通脆弱性評価システムCVSS(Common Vulnerability Scoring System)
最近、組織内のセキュリティパッチの配信の緊急度を評価するときにひとつの情報として利用しています。
セキュリティパッチの配信を考える上で、いくつか考慮すべき点があると思います。
1. ビジネスへのインパクト
2. 脆弱性に対する攻撃の有無
3. セキュリティパッチのインストールに関係するシステム停止などのインパクト
システムを運用する上で、ビジネスイベントにあわせて、システムに変更を加えず、可用性を確保する事が必要な期間があると思います。
特に、会計処理を行っている期間、重要なイベントを行う期間など。
これらを元に私の担当している組織では年間のメンテナンスのスケジュールをあらかじめ決めています。
大きなビジネスイベントの変更や、緊急度の高いセキュリティパッチのリリース、インシデントなどが無い限りは決められたメンテナンスデーにパッチを配信しています。
セキュリティパッチのリスク評価として、
毎月、マイクロソフトやそのほかのメジャーなセキュリティパッチの評価を行っています。
この中で、緊急度やシステムへのインパクトを評価するときのひとつの指針としてCVSSを利用しています。
(その他のリスク評価のポイントとしては、アンチウイルスやFirewall, IPSなどが該当する脆弱性へのプロテクションを提供できるかどうか、脆弱性への攻撃はリモートで可能なのかユーザの動作が必要なのかどうかなどあらかじめ決めてあるリストにのっとって評価)
CVSSの情報を利用することでインパクトを定量化できるため、意思決定が早まっています。
詳細はこちらを
http://www.ipa.go.jp/security/vuln/SeverityCVSS2.html
http://www.first.org/cvss/
リモートからの攻撃性の有無やexploitabilityの度合いに応じて、緊急リリースをするかどうかの判断や、
現状評価の内容を見て、クライアントには先行してパッチを配信する可などの判断などいろいろな角度から利用できると思います。
最近、組織内のセキュリティパッチの配信の緊急度を評価するときにひとつの情報として利用しています。
セキュリティパッチの配信を考える上で、いくつか考慮すべき点があると思います。
1. ビジネスへのインパクト
2. 脆弱性に対する攻撃の有無
3. セキュリティパッチのインストールに関係するシステム停止などのインパクト
システムを運用する上で、ビジネスイベントにあわせて、システムに変更を加えず、可用性を確保する事が必要な期間があると思います。
特に、会計処理を行っている期間、重要なイベントを行う期間など。
これらを元に私の担当している組織では年間のメンテナンスのスケジュールをあらかじめ決めています。
大きなビジネスイベントの変更や、緊急度の高いセキュリティパッチのリリース、インシデントなどが無い限りは決められたメンテナンスデーにパッチを配信しています。
セキュリティパッチのリスク評価として、
毎月、マイクロソフトやそのほかのメジャーなセキュリティパッチの評価を行っています。
この中で、緊急度やシステムへのインパクトを評価するときのひとつの指針としてCVSSを利用しています。
(その他のリスク評価のポイントとしては、アンチウイルスやFirewall, IPSなどが該当する脆弱性へのプロテクションを提供できるかどうか、脆弱性への攻撃はリモートで可能なのかユーザの動作が必要なのかどうかなどあらかじめ決めてあるリストにのっとって評価)
CVSSの情報を利用することでインパクトを定量化できるため、意思決定が早まっています。
詳細はこちらを
http://www.ipa.go.jp/security/vuln/SeverityCVSS2.html
http://www.first.org/cvss/
リモートからの攻撃性の有無やexploitabilityの度合いに応じて、緊急リリースをするかどうかの判断や、
現状評価の内容を見て、クライアントには先行してパッチを配信する可などの判断などいろいろな角度から利用できると思います。
2008年12月10日
フリーウイルススキャンツール
なかなか良いと思います。
http://www.avpusers.org/antivir.html
http://www.avpusers.org/antivir.html
2008年11月18日
JNSAによる2007年の個人情報漏えいインシデントの分析結果について
少し前の資料ですが、JNSAによる2007年の個人情報漏えいインシデントの分析結果について
http://www.jnsa.org/result/2007/pol/incident/2007incidentsurvey_v1.32.pdf
この資料は情報セキュリティ担当者は目を通しておくべきだと思います。
-----------------
インパクト
漏えい人数(レコード数)は3,053万人、想定損害賠償総額 2兆円超
ともに増加傾向です
インシデント発生の原因
紛失・置忘れ、管理ミス、盗難の合計が57.5%
誤操作、不正な情報持ち出し、設定ミス、内部犯罪・内部不正行為、不正アクセスの合計が27.8%
前者の原因に対しては啓蒙とデータの暗号化による保護である程度の保護可能
後者に対してはシステムログを一元管理して、不正の予兆をモニタする事とインシデント発生後に追跡が可能な体制を
構築しておくことで、けん制とすばやいインシデント対応が可能になる
前者の管理ミスのイベントもシステムログを一元管理することで未然の事故防止とすばやい対等が可能だと期待できる
全体のインシデントの傾向をつかむことと、傾向によって新たな要求や規制が現れるかもしれません。
企業の中でもあらなた対応が必要になることもあると思います。
イベントログや暗号化に対する対費用効果の資料作成の場合などにも参考になる資料だと思います。
http://www.jnsa.org/result/2007/pol/incident/2007incidentsurvey_v1.32.pdf
この資料は情報セキュリティ担当者は目を通しておくべきだと思います。
-----------------
インパクト
漏えい人数(レコード数)は3,053万人、想定損害賠償総額 2兆円超
ともに増加傾向です
インシデント発生の原因
紛失・置忘れ、管理ミス、盗難の合計が57.5%
誤操作、不正な情報持ち出し、設定ミス、内部犯罪・内部不正行為、不正アクセスの合計が27.8%
前者の原因に対しては啓蒙とデータの暗号化による保護である程度の保護可能
後者に対してはシステムログを一元管理して、不正の予兆をモニタする事とインシデント発生後に追跡が可能な体制を
構築しておくことで、けん制とすばやいインシデント対応が可能になる
前者の管理ミスのイベントもシステムログを一元管理することで未然の事故防止とすばやい対等が可能だと期待できる
全体のインシデントの傾向をつかむことと、傾向によって新たな要求や規制が現れるかもしれません。
企業の中でもあらなた対応が必要になることもあると思います。
イベントログや暗号化に対する対費用効果の資料作成の場合などにも参考になる資料だと思います。
2008年11月16日
ISO/IEC 38500と他のマネジメントシステムとの関連
掲題に付き分かり易いプレゼンテーションがありました。
特にスライド14の図は理解するうえでも説明する場合でもわかりやすいと思います。
http://www.mlem.com.au/uploads/files/GOV212%20Jason%20Masters%20Presentation.pdf
特にスライド14の図は理解するうえでも説明する場合でもわかりやすいと思います。
http://www.mlem.com.au/uploads/files/GOV212%20Jason%20Masters%20Presentation.pdf

