ISMSを取得するためには、審査機関により審査を通過しなければなりません。
最初に取得する時には、第1段階審査と第2段階審査があります。

この「審査」なのですが、いったいいつまで受ける事が出来るのでしょうか？
回答は「審査機関との調整によっては、12月31日でも可能」です。

もちろん、審査機関によっては拒否される事もあると思います。
（私も審査員として活動している身として、12月31日の審査を打診されたら
正直、二の足を踏んでしまいます＾＾；）

ただ、年末の時期に審査を受けると、審査で不適合が出た場合の
対応が年明けになる場合が多くなると思います。
お正月休みに、「あの不適合に対しては、どうしたら良いんだろう？」とか
「コンサルタントにどのタイミングで聞くのが良いのかな？」とか色々と
思い悩む（？）ことが出てくるでしょう。

やっぱりお正月はスッキリとした気分で迎えたいものです。

気分良く、年内に認証取得が出来るように、初回審査は遅くとも
12月の上旬ぐらいまでに受けるのがお奨めです。

でも、認証書の日付が1月1日というのも何か良いですね＾＾

ISMSの取得は初回審査を受審して、審査を無事通過してから1月ぐらいで認証取得というのが多いパターンです。

審査を通過してから1月間は何をしているのかと言うと、審査機関での色々な手続きにかかる期間です。
審査機関によって期間の長さは若干差がありますが、概ね1月間を見ておけば問題ないでしょう。

認証を取得する時期ですが、多い時期、少ない時期があるのか？

答えは「あります」 です。

11月、12月、1月、2月の4ヶ月が多いですね。

これは代表的なパターンに当てはまっているからです。

4月から期がスタートする会社が多く、「次の期のスタートである4月からISMS取得活動に取り組もう！」とするのが多いです。

そして、トップからの指示として多いのが「年内に取得しなさい」か「今年度中(3月まで)に取得しなさい」です。

LRMの標準取得コースでも、取り組み開始からISMS認証取得までの期間は10ヶ月を想定していますので、4月スタートなら1月なります。取得までの流れはこちら。

LRM以外のコンサルティング会社も多くは10ヶ月程度の期間を目処にしています。
そういった事もあり、ISMSを取得する時期は10月から2月にかけてが一番多いのです。

クラウド・コンピューティング自体は数年前から注目浴びていたものであり、多くの企業で様々クラウドサービスを導入されていることかと思います。

しかし、クラウドの環境において、様々な脅威や問題点(下記参照)が指摘されており、データの消失などの事件・事敀が発生したものもある。クラウドを利用する際は、組織の情報処理とデータ管理をどこまでクラウドで実施するか、事前に検討する必要があります。

＜脅威・問題点＞

• 外部からクラウドへの攻撃
• パスワードや暗号解析等による不正アクセス
• 停電やシステムの不具合によるデータの消失　等

また、従来、ホスティングやASPなどはそのサービス業者の業務環境に密接な関係にあったので、ISMS上リスクも推測し易しく、分析・対策も実施し易くありましたが、クラウドでは実動作環境はサービス業者にお任せとなるのが一般的です。

となると利用者側の対策としては情報セキュリティに関する契約事項やSLAなどを具体的かつ詳細の内容とするのがまず第一歩になり、A.6.2.3などの契約関連の管理策が重要となって参ります。

参考サイト：クラウドサービス利用のための情報セキュリティマネジメントガイドラインの公表～クラウドサービスの安全・安心な利用に向けて～

資料の中ではガンブラーとSQLインジェクションが取り上げられていますが、
共に超有名な脅威なのですが、それでも対策が不十分なケースが多かったのが改めて分かります。

ガンブラーは、2009年頃から出てきたウィルスで、企業のWebサイトに不正な
コードを挿入してWebサイトを改ざんしていくウィルスです。
ガンブラーに関して当初は日本の大手企業も被害にあった事例が報告されていましたが
カスペルスキーを始めとするウィルス対策ソフトベンダーが対応をしていき
次第に被害にあったというニュースは減ってきたのですが
今回のレポートでも被害がなくなっている訳でないことが分かりますね。

色々なガンブラーの亜種も出てきているようです。

対策としては、まずは基本中の基本であるウィルス対策ソフトの更新をしっかりすること！

SQLインジェクションもそうなのですが、Webサイトを改ざんされた場合は
自社が被害者になるだけでなく、そのサイトが踏み台にされることにより
同時に加害者にもなってしまう可能性があります。

自社のサイトを見に来てくれたお客様や見込み客に迷惑を掛けることもありますので
企業としてWebサイトの管理は、しっかりとしていく責任があります。

ちなみに、LRMはカスペルスキーの正規販売代理店です。
カスペルスキーの導入を検討されている場合は是非ご一報下さい。

[参考サイト]JPCERT：「Web サイト改ざん及びいわゆる Gumblar ウイルス感染拡大に関する注意喚起」

今回から何回に分けて10大脅威の中で気になった点をブログで取り上げていきたいと思います。
まず、最初は堂々の（？）第1位となった「人」が起こしてしまう情報漏洩です。

ちなみに「人」が起こしてしまう情報漏洩は2006年度からずっと10大脅威にランクインしている定番の脅威です。

2006年度からの順位の変遷は以下のようになっています。
7位(2006)→3位(2007)→5位(2008)→5位(2009)→1位(2010)

セキュリティ対策というとイメージ的には、何でもかんでもシステムで対応すると思われている方も多いですが、実際はそんなことはありません。
もちろん中にはお金がたっぷりあってシステムでガッチリしている会社もありますが、多くの中堅・中小企業ではシステム以外の部分での対応もしています。

俗に言う「運用でカバーしています」という状況です。
この場合はどうしても漏洩が起こる可能性が高くなります。

資料では故意による情報漏えいとして①データの持ち出しと②暴露・組織外部への情報流布、過失による情報漏えいとして①誤送信と②紛失・盗難が上げられています。

故意による情報漏えいの②に関しては、TwitterやFacebookを始めとして個人でも手軽に情報を外部に発信できる環境になったのも影響していると思います。
悪気がなくて、いつものようにつぶやいたら、つぶやいた内容に業務内容が含まれていて後で取り返しがつかなくなった事例もあります。

過失による情報漏えいの①に関しては、メール、FAXともに誤送信がなかなかなくなりませんね。
こちらに関してはメールの暗号化等で間違えて送っても内容が分からないようにする等のソリューションが出ていますので自社にあった対応をしていくのが良いと思います。

敢えてメールの利用を制限して、チャットや掲示板で情報のやり取りをするのも1つの手段だと思います。

情報漏えいの場合は、起こってしまった場合に企業イメージの低下や損害賠償等が発生するなど企業経営に直接影響を与える可能性があるので従業員が増えるほど、しっかりと対策をとっていかないとダメでしょう。

[参考サイト] IPA：「2011年版 10大脅威 進化する攻撃．．．その対策で十分ですか？」を公開

ISMSの観点から考えるときに、やはり事前のリスク分析と
災害対策を含めた事業継続管理が重要になってくると思います。

リスク分析に関しては、今回のような災害を事前に予測することは
非常に難しいです。
と言うか無理でしょう。
津波の高さや地震の規模は「想定外」レベルです。

ビジネスを行っていく上でも100%安全ということはありません。
想定外の出来事が起きた場合は、「受け入れて対応をしていく」しかありません。

対応の1つに災害時の連絡体制構築があります。
多くの会社で緊急連絡網を作っている会社があると思いますが、
だいたいは電話での連絡網だと思います。

もちろん電話連絡網も大事だと思いますが1つの手段だけですと、
その手段が普通の場合に全く連絡が取れなくなります。

電話(通話)が繋がらないという状況での対応方法を検討することも重要です。

今回の地震では発生当時からTwitterで情報のやりとりが頻繁に行われました。
またスカイプ等で連絡をとった人達もいたようです。

インターネットを利用して連絡体制を構築する
1アイデアとしてFacebookを利用する方法もあると思います。

Facebookを登録して、会社として1つのグループ(公開レベルは、非公開か秘密で)
を作成して、そこで情報をやりとりする方法があります。

会社の規模により一概に良いとは言えませんが、
中小企業にとっては1つの案としてはありだと思います。
料金も無料ですしね。

LRMでは、秘密のグループとして会社グループを作成して関係者全員を登録しています。
何かあった際には、そのグループ内でイベントを作成して
その中で安否確認を行うようにしています。(2011年3月15日現在)

もちろんインターネット自体が普通になるとダメですけどね。

その他、有料の安否確認サービスなど色々な方法があると思います。
自社にあった体制をしっかりと構築しておくことです。
有事の際に慌てないように、事前に体制を構築しておくことです。

文末となりますが、東北地方太平洋沖地震におきまして被害に遭われた皆様に心よりお見舞いを申し上げるとともに、犠牲になられた方、ご遺族の皆様に深くお悔やみ申し上げます。

JIPDECのページで確認してみると、2011年3月6日現在では25の審査機関があります。

ISO27001という規格は1つなのだから、どの審査機関でも受けても
同じでしょうと思っている人もいるかと思いますが、違います。

料金も審査内容も審査機関によって異なります。

ハッキリ言うと、ある機関では不適合とされるけど
別の機関では不適合にならないというケースもあります。

もちろん、PDCAの中のどれか1つが抜けている場合や
不正ソフトウェア使用などの法令違反の場合はどの審査機関で
受けても不適合になってしまいますが、審査機関によって
不適合の判断が異なる箇所があるのは確かなことなのです。

弊社もコンサルタントとして複数の審査機関の審査に立ち会い、
またはお客様が審査を受けて、その結果を確認させてもらいましたが、
審査機関によって異なるというのは真実です。

ただ、「どの審査機関が良い」とか「悪い」という訳ではありません。

取得企業にとって、向いている審査機関と向いていない審査機関があります。
本当に、合う合わないの世界です。

ただ、合わない審査機関と組んでしまうと本当に悲惨です。
会社が目指すマネジメントシステムが審査機関によって
構築出来ないことも可能性としてありえます。

そういった事が起きないように
ISO27001を取得する企業にあった審査機関を選ぶために
LRMでは、コンサルティングをさせて頂くお客様の審査機関の選定も
一緒に行わさせて頂いています。

コンサルティングの見積りの時に、審査の見積りも一緒に下さいと
お願いされる場合もありますが、コンサルティング前だと
その企業に合った審査機関が分からないので、LRMでは
見積り段階でそういった申し出を受けた場合はお断りさせて頂きます。

企業にとって、どの審査機関を選ぶかはISO27001を運用していく上では
非常に重要な要素となってきますので、
どの審査機関がベストフィットなのかも一緒になって検討させてもらいます。

それがLRMのスタンスです。

情報セキュリティ月間とは、内閣官房情報セキュリティセンターを中心に政府が進めている活動で、2009年から毎年2月を「情報セキュリティ月間」として、情報セキュリティに関する様々な取り組みを行っています。

2月に集中的に情報セキュリティに関する行事を実施して、国民一人一人の情報セキュリティに対する意識を上げていこうというものです。

今年のキャッチフレーズは「知る。守る。続ける。」です。
ISMSでも上記のキャッチフレーズは有効です。

特にISMS取得後に関してはISMS活動を続けていくことが非常に重要になってきます。

続けると言っても「維持する」ことと「改善する」ことは異なってくると思います。
何も全ての組織が毎年毎年改善をする必要はないと思います。
時期によっては、今年は現状維持でもOKという判断はありだと思います。

事業の中でのISMSの位置づけによって変わってくるものでしょう。

さて、今年の情報セキュリティ月間には、あのGoogleからも以下のような記事があります。

Google は日本政府の「情報セキュリティ月間」を支持します。
Google 製品のセキュリティ保護対策をわかりやすくご紹介します。

「Google は日本政府の「情報セキュリティ月間」を支持します。」の記事の中で

どんなに強力なセキュリティ対策のための技術やサービスを導入していたとしても、詐欺やフィッシングなどインターネットでの安全を脅かす行為に対しては、ユーザー自身が決して安全対策を怠らないことが重要です。

という一文がありますが、まさしくですね。
技術でカバーできる問題も多いですが、技術ではカバーできない問題も多いです。

ハード（技術）とソフト（人）の両方で対策をしていくのが情報セキュリティだと思います。

ITセキュリティに関する事項が述べられており、日本国内というよりかは世界規模のレポートですので日本では一般的にはあまり騒がれていないマルウェア名とかも出ています。

段々とマルウェアとかも進化しており今後はソーシャルネットワークやiPhone、Androidを標的とした脅威も間違いなく出現してくるでしょう。

今までは、一般的にはWindowsやOffice等のマイクロソフト製品の対策というのがソフトウェアの脆弱性対策と考えられていて、マイクロソフト製品以外は後回しにしていた企業もあります。
ただ、昨年にもありましたがAdobe製品やApple製品の脆弱性を狙うマルウェア等が増えてくるでしょう。

企業や個人で利用頻度が高い製品は、攻撃対象になり易いです。

そして、利用頻度が高い製品は大手企業だけでなく中堅・中小企業でも多く使われています。中堅・中小企業でもそういった製品の脆弱性が発見された時には速やかにアップデートを行うようにしていきましょう。

[参考サイト]
Kaspersky Lab：セキュリティの総括と予測を発表～脅威の巧妙化が新たなレベルに達した2010年とサイバー犯罪の新概念「スパイウェア 2.0」が生まれる2011年～

先日のITmediaの記事でパスワード関連の記事がありました。
その中で、依然として安易なパスワードを使っている人が多いことが実態として明らかになってきました。

Wall Street Journalの調査では安易なパスワードのワースト10として以下のパスワード（？）が挙がっています。

いやいや。これはパスワードでも何でもないでしょう。

5位のqwertyだって、キーボードのqから順に右側に打っていっただけですしね。
相変わらずpasswordや123456は多いですね。

確かにノーパスワードよりかは上記のようなパスワードでもマシかも分かりませんが、やっぱり宜しくはないでしょう。

もちろん何でもかんでも難しいパスワードを入れる必要はないと思います。

要は

そのパスワードが破られた際にどんな影響があるか？

によってパスワードの強度は選べば良いと思います。
そういった意味ではオンラインバンキングのパスワードなどは最低でも10文字以上の英数字混在が望ましいと思います。

もちろんパスワードの使い回しも避けるべきでしょう。
（特段、機密性が高い情報がないサイト等でしたら
共通のパスワードを使うのもありだとは思います。
全てのパスワードを個別にするのも必要ない場合もありますし）

会社でも色々なケースでパスワードの入力が求められると思います。
その際にも「なぜパスワードが必要なのか？」
「パスワードが破られた場合はどんな影響が出るのか？」を考えてパスワードの運用をすれば良いと思います。

「ISMSで決められているから」という理由で思考停止するのでなく、しっかりと考えてパスワードを設定して下さい。
もちろん「ここはパスワードはいらないな」という判断をしても良いと思います。
（会社で決まっている場合は事務局等に意見をして検討題材にすれば良いと思います。）

強度が強いパスワードを複数暗記しておくことは大変ですので
パスワード管理ツールや手帳にメモをしておくのも
パスワード管理としては良いと思います。

[参考サイト]
ITmedia：Gawkerからの流出情報から学ぶ「使ってはいけないパスワード」筆頭は？