本稿では「制御システム固有のプロトコルに対応」という用語の意味することについて考えてみました。 昨日の低予算で始めるArkimeによるOT IDS運用 - 実践ガイドに引き続き通信監視ネタです。なお、WiresharkのDissectorとは、通信データを解釈・解析してわかりやすく表示する仕組みです。
はじめに
2020年に公開した WiresharkのDissectorを使った独自プロトコル解析をやさしく解説してみました の記事は、今では、Dissectorに興味をもった人に最初に目にとまる定番記事となっているようであり、Dissectorの草の根普及に少しでも貢献できていたとすれば嬉しい限りです。読んでいただいた皆様、この場でお礼申し上げます。
もともと、制御システムの通信テストやトラブル解析でWiresharkの生データを見て四苦八苦していた当時、Dissectorを自作できることを知り覚醒の思いだったことを覚えています。同じように苦労している方に広く知っていただきたいという思いから上記含めた3本の記事を公開してから、はや3年、久々にDissector絡みで制御プロトコルに関して記事を書いてみました。
なぜ「制御プロトコル対応」をとりあげるの？
技術部の安井です。長年、制御システムを開発した経験から、現在は制御システムセキュリティ向上に取り組んでいます。
制御システムセキュリティに関わって来た中で、たびたび、「制御システムの固有プロトコルに対応」という用語に、人それぞれ持っているイメージが異なる場面に出逢ってきました。コミュニケーションする際に用語の認識が合えば余計な誤解が生まれずに済むと思い「制御プロトコル対応」をとりあげてみました。
サイバーディフェンス研究所には、文末のいろんな制御システムをつくってみたにも記載していますが、サイバーセキュリティの研究やトレーニングに使用するために構築した制御システム群があります。やはり、実物から学べることは多いものです。今回は、その中の１つを使い「制御プロトコル対応」という用語について少し考えてみたいと思います。
制御プロトコル対応の意味するところ
こちらが、ある制御システムの装置の写真です。
制御システム関係の記事で、独自プロトコルや制御プロトコルというキーワードを見かけた事がある人もいると思いますが、意味するところは様々であり、物理層にシリアル回線を使い通信フォーマットはそのシステム専用に設計されたゴリゴリの独自プロトコルから、今回の装置のModbus/TCPの様に仕様が公開された汎用的な制御プロトコルという場合もあります。 セキュリティツールの機能で「制御プロトコルに対応した」という記載を見る事がありますが、その意味するところは、今回とりあげるModbus/TCPのような仕様公開されたフォーマットを理解できるよという事が多いように思います。ちなみに、WiresharkのDissectorはModbus/TCPに対応しています。ただし、「対応している」という用語が、必ずしも「そのツールで通信パケットを見ると、通信パケットが何を意味しているか人間が理解できる」という訳ではなく、「何かのキーワードに対して何かの数値で表示している事が分かる程度」の事を指す場合が多い気がします1。具体的例で紹介したいと思います。
例えば、次の図2は、右側に表示したサーバの表示画面でSP(設定値)=50 と設定した内容がコントローラに送信された際のパケットを、Wiresharkでキャプチャして表示した結果です。
Wiresharkの表示を見ると、 Register1(UNIT16):2500 と表示されています。このように整形された形式で表示しているのは、WiresharkにModbus/TCPという制御プロトコルに対応したDissectorが標準搭載されているためです。このWiresharkの表示内容だけを見て、SP(設定値)を50.0にしろという情報が送られたと理解できる人はいないと思いますが、コントローラの画面と見比べれば、「2500x0.02=50.0だからRegister1(UINT16)がSP(設定値)に対応しているのだろう」と推測できると思います。
ちなみに同じパケットを、Wiresharkに標準搭載されているModbus/TCPのDissectorを消して単なるTCPのバイト列で表示としてみたものが以下の図3です。
「data:00000 --略-- 9c4」と表示されており何を意味しているか、わからないと思います。Wiresharkの標準のDissectorが対応していない制御プロトコルのパケットを表示すると、このような何を意味するのかがわからない表示となります。各メーカが自社で開発し業界標準化がすすめられていないプロトコルはWiresharkの標準のDissectorが対応しておらず、このような表示となることが多いです。余談ですが、Wiresharkはオープンソースソフトウェアであり、年を経るにつれ標準のDissectorで対応している汎用的な制御プロトコルも増えてきている感じがしています。各メーカの方が読んでおられたら、自社製品普及のためにも自社製の制御プロトコルのDissectorの作成公開を検討いただたらなぁ等とも思うところです。なお、第３者が特定メーカのプロトコルのDissectorを作成し公開するのは法的な面も含め注意してください。
最後に図4が 、WiresharkのDissectorを使った独自プロトコル解析をやさしく解説してみました で解説したノウハウを元に、誰もが直感的に理解できるDissectorを自作しWiresharkに適用して表示した例です。
このWiresharkの表示内容であれば、誰がみてもSP(設定値)を50に設定しろという情報が送られたことがわかります。これはSP(設定値)だけに特化したDissectorですが、Dissectorの過去記事を見ていただければ応用したDissectorも作れると思います。 参考のために、Dissectorのソースコードも載せておきます。
proto = Proto("ORIGINAL","独自制御プロトコル")
uint1_F = ProtoField.new("SP(設定値)","originalCS.uint",ftypes.FLOAT)
proto.fields = {uint1_F}
function proto.dissector(buffer, pinfo, tree)
pinfo.cols.protocol = "ORIGINAL"
local subtree = tree:add(proto,buffer())
subtree:add(uint1_F, buffer(13,2), buffer(13,2):uint()*0.02)
end
udp_table = DissectorTable.get("tcp.port")
udp_table:add(502, proto)
以上の事から分かることは、セキュリティツールが「制御プロトコル対応」と謳っていても、利用者のニーズに見合うのかは利用者の前提知識次第だということです。様々なセキュリティツールで、制御プロトコル対応を謳っているものがありますが、その価値を判断をされる際は、自分が必要とするプロトコルに対応しているかはもちろん、仮に対応していたとして、自分のニーズを満たすまでには何をしなければいけないかまでを確認した方がよいかもしれません。もしかすると、手を加えなければならない労力が大きく、せっかくの機能を使いこなせなかったということになるかもしれません。
なお、通信パケットからサイバー攻撃を検知・防護するということに興味がある方は、まずは、低予算で始めるArkimeによるOT IDS運用 - 実践ガイドで取り上げたような無償のツールで基礎知識を得た上で、必要に応じて制御プロトコルに対応するセキュリティツール2に取り組んでみると言う流れもよろしいのかなと思います。
まとめ
「制御プロトコル対応」という用語について考えてみました。「制御プロトコル対応」という用語を使う際は、その意味するところの認識を合わせた上でコミュニケーションとることが大事だと思います。
いろんな制御システムをつくってみた
当社はサイバーディフェンス研究所という名称に示す通り（？）、制御システムのサイバーセキュリティ分野に関し、各所からのご相談やペネトレーションテストのような業務以外にもこの手の実験にも取り組んでおり、今回とりあげた制御システム以外にも制御システムを学ぶための教材として、日本でシェアNo.1のメーカのPLCを用いた鉄道模型を制御するシステムや、仮想環境で動くSCADAと連携したPLCで工場設備を制御するシステムなどいくつかの制御システムを自製し社内・社外の教育に役立てています。それらの経験から、実際の制御システムを触ることで、今回のように異なる特徴のある制御プロトコルに触れるなどする中で、百聞は一見にしかずという思いを強くしています。
セキュリティ用途に限らず教育用途で模擬制御システムを保有したい組織は少なくないのではないでしょうか？興味がある方は、リアル感ある制御システムが無料で作れて勉強になった話もご覧ください。