年末年始などに代表される長期休暇は、多くのビジネスパーソンが休みを取る。長期休暇が可能なカレンダーのめぐり合わせの年や、製造業など計画的に休暇を組み入れる企業に勤めている場合には、9連休、10連休といった大型連休を楽しむ人も少なくない。こうしたビジネスパーソンにとっての至福の時間は、サーバー攻撃を仕掛ける悪意あるハッカーなどにとっても絶好の攻撃のチャンスになることをご存じだろうか。
年末年始など、一般的に長期休暇明けはサイバー攻撃が増加傾向に
情報処理推進機構(IPA)は、ゴールデンウィークやお盆休み、年末年始休暇などの長期休暇のセキュリティ対策について警鐘を鳴らす。なぜなら、「長期休暇の時期は、システム管理者が長期間不在になるなど、いつもとは違う状況になりがち」になるからだ。
システム管理者がいなかったり人手不足だったりする長期休暇期間中にセキュリティインシデントが発生すると、対応の遅れや、想定外の事象に発展したりする。思わぬ被害が発生したたり、休暇後の業務継続に影響が及ぶ可能性があるというわけだ。
攻撃者側も闇雲に攻撃を仕掛けているわけではなく、効率的に仕事をしようとしている。長期休暇で守りが手薄になっている企業や組織ならば、平時よりも仕掛けたわなに気づかれるまでの時間が稼げることもある。対策チームが稼働するまでに余裕があれば、多くの情報を窃取したりランサムウエアの種を仕掛けたりしやすくなる。
セキュリティ対策が手薄になることや、“心のスキ”を攻撃者は見逃さない…
長期休暇中のインシデントにはもちろん気をつけなければならないが、休暇明けにもまた落とし穴があることを忘れてはならない。
金融庁では、金融機関に対して以下のような注意喚起を行っている。それが連休明けの業務の集中で、例えば一斉に業務を開始した休み明けにはチェックするメールの数が増えて、疑わしいメールへの注意がおろそかになることで、感染リスクが高まるというもの。標的型攻撃を仕掛けてくる犯罪者は、企業の内部情報にも精通していることが多く、休暇明けの気持ちのスキに乗じた攻撃を仕掛けてくる可能性が高いことを忘れてはならない。
2015年に大きな話題になった日本年金機構の情報流出事件も、振り返るとゴールデンウィーク明けに標的型メールを受信したことから被害が拡大していったものだった。標的型メールは100通以上の受信が確認されているが、そのうちわずか5通を開封してしまったことから、125万件もの顧客の個人情報を流出させる事態に陥ってしまった。
昨今の犯罪者は企業の規模に関わらず攻撃を仕掛けるようになっている。関連企業などの小さなセキュリティの穴から、大企業を含むサプライチェーン全体への攻撃を図るサプライチェーン攻撃を成功させるためだ。中小企業であっても、連休明けの忙しさや気持ちの緩みからわずか1通の標的型メールを開封したことで、社会的信用を失ったり事業継続が困難になったりするリスクがあることも想定しておきたい。
セキュリティレベル保持のためアウトソーシングや24時間365日サポートの活用も
それでは、具体的にはどのような対応が求められるのだろうか。IPAでは、システム管理者向けに対しては、「緊急連絡体制の確認」「社内ネットワークへの機器接続ルールの確認と遵守」「使用しない機器の電源OFF」などの対策を求めている。
またユーザーに向けては、長期休暇明けの対策として、「修正プログラムの適用」「定義ファイルの更新」「持ち出した機器などのウイルスチェック」「不審なメールに注意」の4点を指摘する。こうした長期休暇時に気を付けるべきセキュリティについては、過去にBiz Clip内で紹介した記事も参考にしてほしい(長期休暇前後のセキュリティ対策)。
こうした対策はそれぞれ、システム管理者やエンドユーザーの注意や努力のもとに成り立つ。一方で口を酸っぱくして注意喚起をしたとしても、休み明けに山積みになった業務に追われていたら意識からセキュリティ対策が抜け落ちることは防げない。長期休暇中から休み明けにかけてのセキュリティ対策をより確実なものにするためには、自社のリソースによる対応に加えて、アウトソーシングサービスなどを活用することも考えたい。
内外に存在する脅威からのリスクを低減する事前対策をサービスで導入しておけば、長期休暇の間や休み明けの守りを手薄にしない態勢が作れる。また万が一のセキュリティ事故発生時にも事後対策のサービスにより、インシデントの発生を検知したらシステム管理者に通知し、さらに復旧支援や訪問サポートなども受けられる。
また、24時間365日対応のサポートを活用することで、休暇中のシステム担当者を総動員して対応するのではなく、最低限のリソースで迅速な対応が可能になるのだ。安心して長期休暇を迎えるためにも、セキュリティ対策のサービス利用やアウトソーシングを検討したい。
※掲載している情報は、記事執筆時点のものです