Security First: 3月 2008

メディアの識別

内部監査であれ何であれ、各現場を回ると目に付くのが無造作に置かれたメディア。フロッピーは減ったとは言えパソコンとかサーバーの側の机の引き出しを開けると出てくる。CDRも生なのか何か入っているのか分からないものが出てくる。始末が悪いのがUSBで、形もばらばらで、サイズも小さい。

ある部署では、識別（ラベリング）も何もしない理由が、重要と書いたり印をつけると重要と分かって持ち出されるから敢えて識別しないと強弁していた。都度、パソコンに掛けて内容を確認すると。結局、何が持ち出されても分からない状態でリスク受容らしいが、呆れるばかり。もちろんNGだけど、これでその部署の責任者なんだから先は長いというしかありません。

本題：メディアの識別の問題は内容が可変であることが、本質的な問題です。空ならごみでも消しきれていなければ重要資産。その可変性が結局管理を放棄させています。

審査ノウハウ：現場審査

審査ノウハウというほどのものではない。監査とか審査とか、あるいは現場診断とかを実施した場合に、「普通じゃないな」と感じる場面に遭遇する。そこでのやり方が他の現場で見てきたのとは多少違う場合です。

他の現場が、他部門であることもあれば、他社の場合もあります。多少違うのは当然ですが、それでも尚、違和感が残る場合です。通常は合理性、妥当性、適切性などの価値観に触ってくるものです。

で、首をかしげながらも一応メモを取って、場合によっては後で質問できるようにして、次の現場に向かってしまうことがあります。

既に、失敗というか間違っていますね。後で聞いても、殆どの場合、確認にはなりません。既に現場ではありませんから、実際のところ指摘なんてものはできません。守るも攻めるも現場が命です。

現場では、

業務のあるいは管理の実態を聞く、見る。
それら現場の実態は何に基づいての作業によるものかを確認する。現場が使っている作業標準です。
決めたとおりにやっていれば、現場の（作業者の）問題は無い。
現場で使う作業標準（現場で作成した作業標準）に不自然なものがあれば、何に基づいて作成したかを聞く。現場作業標準が共通の標準書（普通は規定）に基づいているか確認する。
規定に沿っていれば現場の標準は問題ない。
次は規定そのものの成り立ちを見る。規格適合性ですね。
で、残念ながら？、規定は規格に適合している。と。

コンサルは不自然を解消するためにさらに深堀をしますが、審査はこれでお仕舞いです。本当？　実力が無いとこういう役立たずな審査になってしまいます。最初の直感は正しくても原因を推定できないのです。でも、現場審査のプロセス自体はこれが正しいのです。

現場審査に入る前に文書審査で、規定類が規格適合していることを先に確認します。ここはまだ机上論です。

電子メールのセキュリティ

電子メールのセキュリティ対策

パソコン上に余計なメールを持ち込まないためにWEBメールを使うのも一つの方法。Webメールはまたパソコンの容量を圧迫しないので、有用。

電子メール関連の管理策は、

10.4.1ウイルス対策
10.4.2モバイルコード対策
10.8.4メッセージの完全性

Webメールのセキュリティ機能

フィルタリング・振り分け→識別
メール拒否設定
フィッシング対策

対応関係が分からない。

主要なWebメールは殆どセキュリティに配慮しているがそれぞれ特徴がある。組み合わせて（＝各Webを直列スルーさせて）より高いセキュリティを目指したい。

Gmail
Windows Live Mail
Yahoo! Mail
Mail@nifty

4.3.2i)と4.3.2j)の違い

違いがよくわからない。どちらかひとつで足りるのではないかな？

4.3.2d)と4.3.2f)の違い

可用性の観点で違いがいまいち理解できない。

4.2.3g)

監視および見直しから検出されたことを踏まえて、セキュリティ計画を更新することが、この項目の要求事項になっているが、さてと困った。この「セキュリティ計画」って何を指すんでしょう。英文を見るとsecurity plansになっているからセキュリティ関連の諸計画としても良さそうです。

リスク対応計画
セキュリティに関する教育計画
運用を管理する中で生まれる年間計画
セキュリティ調整のための運営計画

など何でも必要なものに反映させることになりますね。

4.2.4a)

改善をやれといっているが、何処から引っ張り出す改善なんだろう？

4.2.3b)

4.2.3b)では、ISMSの有効性の定期的な見直しが出て来るがイメージが湧かない。これって、マネジメントレビューでは駄目なのかな。もしくは内部監査では駄目なのかな。

待てよ、これらは、まあ、年次だわね。普通、システムを監視していて、手直しの判断を年次でやる会社は無いでしょう。ミニマム月次で報告レビューでしょう。厳しい会社、変化の多い会社なら週次になります。勿論、大型投資･戦略的なシステム変更は年次に近いものでも止むを得ないでしょうが。

しかし、しかしです。測定基準・評価基準の見直しは年度の途中でやると変になる。見直しの材料は短いインターバルで集めて良いが、根っこの見直しは年次でも良いでしょう。

と言うことは、ここの管理策の肝は、見直しの材料として、十分であったかどうかですね。

「見直し材料」

セキュリティ監査の結果
インシデント
有効性測定の結果
提案
利害関係者からのフィードバック

規格解釈｜4.2.2b)と4.2.2c)の違い

4.2.2はISMSの導入と運用

これのb)項とc)項の違いが分からない。と言うことはリスク対応計画が良く分かっていないことになる。世の中のISMSを見たり聞いたりすると（極めて少ないサンプルには違いないが）、リスク対応計画と管理策の違いを本質的に理解しているところは少ない。リスク改善に繋がるのでどちらであっても結果には大きく影響しないから特に問題にする必要は無いということでしょう。でも正しく理解しておくことも大事ですから、少しトライしてみます。

4.2.2c) 管理策の実施：
既に策定されている管理策の整然たる遂行。
4.2.2a) リスク対応計画の立案：
システム（ISMS)の構築レベルが不十分で管理策の実施に入れる状態にない場合、不足分の工事をやる必要がありますがそのプラン（リスク対応計画）の立案を行うことです。
4.2.2b) リスク対応計画の実施：
プランの実施です。これによりシステム（ISMS)は変化し（改善され）目的の水準に達します。
リスク対応はシステムに変化を及ぼす。管理策はシステム自身は変化しない。管理策を黙々やっていくだけではシステムの改善は行われません。毎年チャレンジ項目を決めてリスク対応計画として消化していくことが大事です。

資産台帳と分類表

「よくある勘違い」

資産目録、資産台帳を作成していると、この手間が大変。同じようなものがずらっと並ぶ。現場部門が非協力的で、事務局が一手に引き受ける場合は、特に大変。で、共通項をまとめたマスターリストみたいなものを作って、例外だけを追記してもらう。部門はマスターと現物との突合せはやらない。
リスクアセスも事務局でまとめてやってしまうので、分類表と変わらない台帳が生き残る。
要因はトップの指示が現場でなく事務局に行ってしまうことにある。トップの意識･目論見･目的が認証取得だけに走ると陥るケース。苦し紛れの勘違いですね。

登録: 投稿 (Atom)

Security First

ページ