FSEG is not Flexible-Segmentation

【IIJ 2018 TECHアドベントカレンダー 12/21（金）の記事です】

はじめに

先日、FSEGに関するプレスリリースを行いました^(※1)。プレスリリース内ではFSEGのターゲット市場や特徴について簡単に記載させていただきました。今回は、我々がFSEGを開発するに至った背景を中心に説明したいと思います。

急増するIoT機器

あらゆる分野でIoT化、ICT化が進んでいます。それを示すデータはあちこちにありますが、例えば総務省の「平成30年情報通信白書^(※2)」によりますと、2020年にはIoTデバイスとして、つまりネットワークに繋がるデバイス数として403億個が予測されています。これらIoTデバイスについては、セキュリティ上の懸念がやはりあちこちで語られており、同じく総務省の「ICT によるイノベーションと新たなエコノミー形成に関する調査研究^(※3)」によれば、「IoTの特徴とセキュリティ上の課題」として以下（抜粋）があげられています。

つまり、一言でいってしまえば「IoT機器側にセキュリティソフトをインストールし、適切にメンテナンスしていくことが必ずしも行えない」のです。

産業用IoT

加えて、「平成30年情報通信白書^(※2)」には、分野別年平均成長率予測としては産業用途（工場、インフラ、物流）が30.8%でトップだとの記載もあります。スマート工場やConnected Factory といった言葉もよく聞き、関連する展示会も大変に盛況ですが、数字としてもそれが表われていますね。では、工場のIoT化にあたっての課題はなんでしょうか。それは、「制御システムと情報システムが共存する」「生産活動を止めないことを目的としている」、このような特徴そのものが課題だといえるでしょう。IPAによる「重大な経営課題となる制御システムのセキュリティリスク^(※4)」に、「制御システムと情報システムにおける情報セキュリティの考え方の違い」として以下のようにまとまっています。

これらの違いを認めつつセキュリティを確保していかなくてはならないわけです。また、工場などの製造ラインを持つ企業は、ランサムウェアなどの攻撃対象になりやすいということもあります。これは、攻撃による業務停止は利益損失に直結するため、攻撃者にとっては効果が大きい（つまり、身代金を得やすい）ためです。IPAによる同資料には、国内工場での数億円の損害例の記載もあります。

2020年の東京オリンピック・パラリンピックだけでなく、その前年の2019年にはラグビーのワールドカップ、2025年の大阪万博など、日本では世界的イベントの開催が続きます。過去の事例をみると、こういった大規模なイベントの際には、その国がサイバー攻撃のターゲットになっています。少し古いデータですが、経済産業省によりますと^(※5)、日本には約42万の工場があり、従業員300人以上のいわゆる大工場だけでも約3,000存在します。イベント時、これら大工場が攻撃者にとって効果的なターゲットとして選ばれる可能性を考えてしまうのは、杞憂でしょうか。

既存技術の限界

では、どのように対応すれば良いのでしょうか。IoT機器側にセキュリティ対策を期待するのは難しいことは上述したとおりです。そして、「侵入防止」を目指した今までのセキュリティ対策では、「組織の内部にいったん入り込まれてしまうと、その後の感染拡大を防ぐものがない」のです。例えばUSBメモリ経由で侵入したウィルスがネットワークの内部で感染を拡大していった事例^(※4)があります。

FSEG

「ゼロ・トラスト環境に対応した、拡散防止のためのネットワークセキュリティ」、それが我々の解決策「FSEG」です。ゼロ・トラストとは、2010年にForrester ResearchのJohn Kindervag氏によって提唱されたセキュリティモデルで、ユーザもデバイスもアプリケーションも、全てが無条件で信頼されることはなく、信頼しない代わりに常に検証することによって安全を確保する、という考え方です。拡散防止とは、感染してしまうのは仕方がないとして、しかし極力感染範囲を小さくしようとする（拡散を抑える）ものです。また、セキュリティ対策を期待できない多数のIoTデバイスがつながる環境対策として、ネットワーク側でセキュリティを提供します。FSEGが提供する機能は、大きくは以下の2つです。

• ゼロ・トラスト環境への対応
  • セキュリティ製品を機能ごとに分けて、トラフィックが流れる経路上のあちこちにそれらを分散配置することで適切な監視と迅速な検知を可能にする仕組み
  • 少し詳しく言えば、「セキュリティVNF」などをネットワーク上に動的に分散配置し、SDN技術によってそれらを繋げることで実現しています。IPS機能、URLフィルタ機能、振る舞い検知機能などです。

• 拡散防止機能
  • 人や機器をグループ（FSEGでは「JIN」と呼んでいます）としてまとめ、グループ内の通信のみを許可する仕組み
  • 少し詳しく言えば、SDN技術によって「個々のトラフィックの到達可能場所」を細かく制御することによって実現しています。従来のL2/L3のネットワークセグメントとは全く異なるものです。

止めないセキュリティ

これら2つの機能によりさらに、次のようなFSEGの特徴的な動作を作り出しています。

「脅威検知後に感染端末をすぐに隔離する」だけでは、隔離する端末によっては製造ラインが止まってしまうこともあり、産業用IoTのセキュリティには不向きです。FSEGでは、脅威検知後の処置として「多段階処置」が可能です。例えば、1段目のIPS機能により不正アクセスとして検知されたトラフィックの送信元端末からの通信全てを振る舞い検知機能に渡すような経路制御を行います。IPSには誤検知の懸念もあるため、この段階で急激な対応を行ってしまうのは、産業用途としてはためらわれます。そこで、例えば2段階目として振る舞い検知機能を配置し、トラフィックを監視して本当に不正な動作をしているのであれば、その時点で隔離や遮断といった対応を行う、などです。負荷が軽い機能を用いて常時チェックし、必要に応じて負荷がかかる機能を用いてチェックするといったことも実現できます。

もうひとつは、「予防措置」と我々が呼んでいるものです。あるJIN内で脅威感染した端末が検出されると、その情報はただちにFSEG配下全てで共有されます。その脅威感染した端末が属する全てのJIN内の他の端末に対しても、あらかじめ振る舞い検知機能を通すように変更する、などの処置を行うことができます。つまり、同じJIN内にいる端末は同じ資源にアクセスしているので、現時点では不正な挙動はしていないが既に感染しているかもしれない、だから予防的に監視を強化しよう、ということです。

「多段階処置」「予防措置」により、FSEGは業務継続性を損なわないセキュリティソリューションとして、産業用IoTなどに適したものとなっています。

今後

現状では OpenFlow機器を一部に使用しますが、より多くの方にFSEGをご利用いただきたけるよう、2019年の早いうちにOpenFlow機器ではなく通常のL2/L3スイッチにも対応する予定です。その後、デバイス特定機能も実装予定です。また、FSEGはAPI提供を行なっておりますので、お客様の既存システムとの連携なども進めていきたいと思っています。

おまけ：名前の由来

FSEGは「エフ・セグ」です。ある日、名前を考えよとの命を受けた私。新しさやセキュリティをイメージする幾つかの単語を並べて、それぞれの単語から1文字ずつとってみるといったありがちな方法で名前候補を何個作ったことでしょうか。「これは良いぞ」と私が思った名前も却下されつづけ、気がつけば足掛け半年以上。もう名前のことなんか忘れているだろうと思い、放っておくと催促が。そんなある日、英単語を選んで並べ文字をひろっていると、日本語の単語のように読めたのです（疲れていたのですね、きっと）。これだ、と同じパターンで一応幾つか作成しプレゼン。するとあっさり「これでいこう」と。それが、最初に私に降りてきた4文字「FSEG」です。

もうおわかりですね。FSEGは「防ぐ (FuSEGu)」なのです。Flexible とか Segmentationとか、そんなものでは断じてないのです。あ、JINは「陣」。

注釈