セキュリティ対策したときに本当に有効なのかと自分で確認したことはありますか？ドアを施錠したらガチャガチャ確認するのに、セキュリティ対策した後ガチャガチャ確認しないのは不思議ではありませんか？
本稿は、「制御システムのドアノブ、ガチャガチャしてますか？[OTセキュリティ:インターネットへの疎通可否]」のおまけです。
- おまけ１ なぜ"制御システムのドアノブ、ガチャガチャしてますか？”というブログを書くに至ったか。
- おまけ２ [OTセキュリティ:インターネットへの疎通可否]に関する想定Q&A。読む前に、OTセキュリティ:インターネットへの疎通可否をさらっと見ていただいた方がよいかもしれません。
おまけ１：なぜ、このブログを書こうと思ったのか？
なぜ、制御システムのドアノブ、ガチャガチャしてますか？というブログを書こうと思ったのかがつらつらと記載してあるので、興味ある方は眺めてみてください。 長年開発者目線で制御システムのセキュリティに関わってきた後、現在、セキュリティ業界側から制御システムのセキュリティに関わっていて思うことです。
なぜ、こんなに基礎的な確認が漏れてしまったのだろうか？
制御システムのぺネトレーションテスト（攻撃者目線で侵入を繰り返し模擬的な被害発生までを試みるテスト）では、システムへの初期アクセスから被害発生までの一連のシナリオによる攻撃実現性を確認する場合があります。「誰かがもう少し気にかけていればそこまでは侵入されずに済んだだろうなぁ。」という場面に何度も出あってきました。
一流のペネトレーションテスターでなければ発見できないようなゼロデイ脆弱性や、それなりのツールを使いこなして発見する既知脆弱性を発見することは、多くのセキュリティテストの予算がとれない組織では難しいと思います。ただ、中には、制御システムの開発・保守に関わる技術者の誰かが、ほんの少し確認方法の知識があり確認さえしていれば、避けれたであろうという項目にも出会うものです。 このような場面は、もう少し確認手順の知識が広まれば世の中から減らせるのではないかと思います。
人に聞けば安心ですか？
サイバーセキュリティは難しくてわからないから、わかっていそうな人に、しっかり対策できているか聞くだけですましている人も多いのではないでしょうか？聞かれた人も対策が有効だと信じて作業しているでしょうが、その対策で侵入リスクをどれだけ低減できているか実はわかっていないかもしれません。また、思いもよらぬ設定ミスをして、意図せず侵入の抜道をつくってしまっているかもしれません。設定作業にミスはなくても設定内容を設計した人が設計ミスをしているかもしれません。
サイバーセキュリティに関わる技術者であれば、セキュリティテストをしていて、こういう場面に出会ったことはあると思います。
一度確認すれば未来も安心ですか？
セキュリティテストを実施する予算のある組織であっても、開発当初のみテストを実施して、以降はテストしていない組織も多いのではないでしょうか？予算的に何度も大きなコストをかけないことは妥当な判断なのだろうとも思います。 ただ、長年保守・改造する中で意図せぬミスで抜道をつくってしまうことはあり得るのではないかと思います。初期開発時のセキュリティ設計思想を知らずに便利さを実現するために穴を開けてしまう事も考えられますし、開発当初の体制が整っている時よりも改造時は関わる人員が少ない分ミスしたときに見逃される可能性は上がると思います。 テスト観点・能力の違い、新たに公開された既知脆弱性などで、開発時のテストでは発見されなかった抜道が、次回のテストでは発見される場合もあるでしょう。
全てを防ぐことはできなくとも、せめて、簡単な確認方法だけでも知っていれば、ほとんど追加コストをかけずに確認することで防げる項目もあるのではと思います。
世の中の対策製品が高度すぎてあきらめてしまっていませんか？
世間には、様々な対策製品があります。高度な製品ほど機能が多く技術的な説明や理解が困難なためか、世間一般向けには、シェア、受賞歴、数字比較など、技術的観点からはふわっとした感じを受ける話題が多い感じがしています。セキュリティ業界の中でも特にOTに関しては、まだまだ他の業界と比べれば決して成熟しているとはいえず止むを得ない部分も多いとも思いますが、一技術者からみると少し残念な気もします。 一方で、専門家でなければ読み取れない技術特化した内容を広く一般の人に理解してもらうのも無理があると思います。ちょうど、間をとったような程よく平易な解説があればいいのになぁと思っていました。対策を選ぶ上でも基本的な仕組みを理解していると、コストと効果を考えた時に適切な選択ができるようになると思います。
結局、何がいいたいのか
安全・簡単であればガチャガチャしたいと思っていただけたのでしたら、自分でガチャガチャできないか知ろうとしてみてほしいです。思ったより簡単にできることもあるはずですので侵入できるかガチャガチャしてみてください。頻度はリスクと予算の兼ね合いで。
おまけ２：本稿が平易すぎて説明不足と感じる方への補足情報
「制御システムのドアノブ、ガチャガチャしてますか？[OTセキュリティ:インターネットへの疎通可否]」のブログは、「ありがちなケアレスミスだがサイバー攻撃の目的達成において大きな役割を果たす弱点となりえるポイントを、簡単な方法で見つける。」ということを主眼にしています。多くの方が平易にイメージを理解しやすいように極力サイバーセキュリティの専門用語は排除し記載したため、詳しい方にとっては、つっこみどころが多い文章となっているかと思います。おまけ２として、いくつか想定疑問を挙げて補足します。
挙げ出すとキリがなく、厳密に考え出すと「気にする項目が多すぎて自分で確認しようという気がなくなる。」という様子を感じていただく程度でもよいと思います。考えられる全てを確認することが重要なのではなく、基本的な仕組みを理解し要点を絞って確認いただくことが、コスト対リスク低減効果を考えても現実的かと思います。
制御システムのネットワークからインターネットと疎通できたら危険なのか？
制御システムのネットワークからインターネットと疎通できても、それがすぐにインターネット上の犯罪者からサイバー攻撃を受ける差し迫ったリスクがあるとは思いません。物理侵入対策や教育により制御システム内に攻撃起点がつくられない前提であれば、インターネット起点で制御システムへアクセス可能なグローバルIPとポートがあり、そこに侵入可能な脆弱性があるのでなければ、インターネット起点で直接アクセスして侵入することはできないわけですから。また、適切にセキュリティ対策を施した上でインターネットと繋げている制御システムも近年は多いと思います。 今回のテーマは、セキュリティ対策の有効性を確認していますか？ という事を考えるきっかけをつくるために、まず１つ目のテーマとして、通信の基本となるゲートウェイを理解するために本テーマをとりあげたものです。
インターネットへの疎通確認の前に、よりリスクが高そうなインターネットから制御システムの装置にアクセスできるか？を調べる方が先なのではないか？
たしかに、インターネットからアクセスできるということは世界中から攻撃を行えるという意味なので、インターネットからアクセスできるか確認することはセキュリティ対策上重要なポイントです。このため機会があれば別テーマとして紹介したいと思います。 ただ、インターネットから制御システムの機器にアクセスできるということは、制御システムの機器からインターネットへ応答を送信できるということであり、制御システムの装置のルーティングテーブルにゲートウェイが設定されているということになります。つまり、インターネットからのアクセスを考える上でもルーティングテーブルとゲートウェイについての基礎知識が必要になることを考慮し、まずは、通信の基礎であるルーティングテーブルとゲートウェイの仕組みを理解してもらうために、今回のテーマを先に選びました。
なぜ疎通確認専用の端末を用意しないのか？
疎通確認を行うための専用の端末を用意せずに「保守作業を行うときに使用してよい端末」を使う記載としたのは、制御システムのネットワークに接続してよい端末が保守運用ルールにより管理されており、新たな端末を用意することは管理上ハードルが高いと想定したためです。 今後もセキュリティ診断しようという目線で考えれば、必要な診断ツールをインストールした端末を用意し、使用して良い空きIPアドレスを割り当てて確認する方法が、既存の端末の設定変更もどし忘れの心配もないとは思います。
なぜ疎通確認する先を8.8.8.8としているのか？
まず、今回の前提がインターネットと疎通できないはずの環境における確認であったため作業途中でインターネット上のどの宛先との通信が切れても運用上問題がないという前提であること、および、ネット上の情報を検索するとインターネットへの疎通確認する相手の例として8.8.8.8がよく引用されているからです。 ただし、「他人が用意した相手にアクセスするのは迷惑がかかりそう、もしくは他人が用意した相手と通信はしたくない。」という場合は、自分でインターネット上のクラウド環境にグローバルIPを割り当てたLinuxのサーバを立てることをお勧めします。本題内でも軽く触れた任意のポートの疎通確認する際にも便利ですし、今後、インターネットから制御システムへアクセス可能かなどの確認をする際にも何かとインターネット上にLinuxサーバがあると便利です。ただし、クラウド上にサーバを立てる場合はセキュリティ対策にご注意ください。簡単には説明しきれないため今回は8.8.8.8としました。
pingで疎通確認するよりtracertの方が通過するゲートウェイも確認できてよいのでは？
経路上のゲートウェイ（ルータ）が、Time Exceeded Messageを返せる状態なのであれば、tracertの方が経路途中のルータのIPアドレスを表示してくれるので、通過するゲートウェイのアドレスも表示してくれて便利なのですが、Time Exceeded Messageを返さない機器もあるためpingとしました。WindowsのtracertはICMPを使いますが、Linuxのtracerouteは標準でUDPを使うこともあり混乱しないようにpingとしたという意味もあります。もう少し仕組みを知りたい方は、この方の解説がわかりやすいと思います。
なお、実際に疎通確認するまではなく、単に8.8.8.8と通信する際に利用するゲートウェイがどれなのかを確認したい場合は、powershellの find-netroute コマンドを使って確認していただくとわかりやすいと思います。コマンドだけ記載しておきます。
PS > find-netroute -remoteipaddress "8.8.8.8"
このコマンドで確認すると、NextHopの項に、使われるゲートウェイのIPアドレスが表示します。
サイバー攻撃でインターネットと接続される という例が書いていないのはなぜ？
内部犯がLTE回線など無線で遠隔操作可能なRasberry piなどの小型端末を、制御システムのネットワークに接続したなど悪意のあるサイバー攻撃を起点としたインターネットへの接続は話しが長くなるため除外しています。今回は、サイバー攻撃を受ける以前に、攻撃者に弱点として利用されかねないミスをしていないかという観点に着目しています。 たとえば、制御システムセキュリティのインシデント事例でよく述べられるUSB機器を挿してC2サーバと繋げて、という文脈は、今回のテーマの仕組みを理解できていれば、インターネットとの疎通が取れない環境にしておけばUSB挿されても防げるでしょうし、逆に、インターネットとの疎通ができる端末にUSB挿されたら危ないということが理解いただけると思います。
ゲートウェイとなる可能性がある候補探すのにpingとarp使うのは面倒では？
ping 192.168.10.255 のように、ブロードキャストアドレス宛に1回送信してarp応答を受けてarpテーブルを確認する方法が紹介されているサイトもありますが、手元のWindows10とWindows11の環境で確認した際、Windows11ではarp応答は受けてもarpテーブルに反映されない現象が確認できたため、本稿ではブロードキャスト宛のpingは紹介しませんでした。なお、1アドレスずつ手動でping確認するのは手間なのでfor文を使い254回のpingを実施するコマンドで説明しました。
IPv4だけで、IPv6に言及していないのはなぜ？
現時点で、本稿を読んでいる方が扱う制御システムはIPv4のみを利用していることが大半だと考えるためです。話しを簡単にするためIPv4のみ言及しIPv6については触れませんでした。もしIPv6使う必要なくセキュリティ面だけを考えるならば、様々な装置でIPv6を無効とした方がよいですし、FWにしてもIPv6を通さない設定とした方がよいです。もちろん設定したら、ガチャガチャする観点でIPv6通信は通さないか確認した方がよいです。
なぜDNSにはあまり言及しないのか？
DNSによる名前解決は、話しが複雑になるので本稿では軽く触れる程度としました。 インターネットへアクセスする必要がない制御システムのネットワークでは、DNS設定は不要なためDNSが設定されていない場合も多々あると思います。IPアドレスをDHCPで自動設定する設定としており無意識にデフォルトゲートウェイがDNSサーバとして設定されている場合もあるかもしれませんが、制御システムのネットワーク設計においては、DHCPを使わずに固定IPで設定しておりDNSも設定されていないということが多いのではないでしょうか。 いちおう、上記のとおり無意識にDNSが設定されている事も考えられるため、ブラウザでURL指定してhttpsで外部ネットワークと疎通確認する手順を本文中では記載しました。
なお、名前解決はDNSを使わずとも装置内のhostsファイルに設定することでも名前解決はおこなえますが、制御システム内の装置のhostsファイルにgoogle.comなどのインターネット上のURLを明示的に記載する人はほぼいないと思われるため言及しないでおきました。
ICMP,httpsなど今回例示したプロトコル・ポート以外で疎通できることもあるのでは？
はい。そのとおりです。全てあげると話しが複雑になるので本稿では、あまりセキュリティを気にせずにFWを設定した場合に通過する状態になっていることが多いICMPとDNS,httpsを例にあげました。他にも同様に一般的によく使われるプロトコル・ポートとして、http(TCP/80)、ssh(TCP/22などがあります。次の項目で説明するとおりFWでブロックされていないプロトコル・ポートであれば、ルーティングさえ通っていれば疎通できます。
また、HTTPプロキシの設定がされていて、制御ネットワークの外部のプロキシサーバと通信できるようにしている場合もあると思います。この場合、制御ネットワークからインターネットへは直接IP通信できなくてもプロキシサーバ経由で、インターネットと通信ができてしまいます。HTTPプロキシでよく使われがちなポートにTCP/8080やTCP/3128があります。開発・保守作業員がインターネットと一時的に通信したいためにプロキシサーバを制御ネットワークの外に構築し、制御ネットワークからプロキシ設定したまま、撤去し忘れているなどということもあるかもしれません。
FWの設定で、特定のIPアドレスのみしか通信できないようにされている場合もあるのでは？
はい。そのとおりです。厳密に送信元IPアドレス、送信先IPアドレス、送信先ポートで、FW設定している制御システムもあると思います。 当然、セキュリティ面を考えればこのように設定することが理想的です。 ただし、機器が多いシステムで個別IPアドレスをFWフィルタルールに設定するのは煩雑になりますし保守性も悪いため、ネットワークセグメント単位で設定していたり、制御ネットワーク側（内側）からインターネット側（外側）への通信はフィルタ設定がしていなかったりという場合も多いのではないかと思うのです。本稿は、ありがちなケアレスミスで作ってしまった弱点を、簡単な手順で見つけれることもありますよ。という趣旨であり、網羅的に厳密にチェックすることを目的とした内容ではありません。
昨今インターネットと繋がるシステムが増えてきており、インターネットと疎通できることを確認してもあまり意味がないのでは？
昔はインターネットと繋がる制御システムはほとんどなかったのですから昨今繋がるシステムが増えてきたのは当然だと思います。一方で、昔同様、繋がるルートが無いように設計しているシステムも多数あるので意味がないとは思いません。 今回のテーマは繋がらない前提のテーマでしたが、本稿では、つなげた方が良いかつなげない方がよいかという類の基本思想的あるべき論には言及はしません。個々のテーマにおいて前提を明確にした上で、技術的な観点から情報をお伝えできればと思います。
おまけ最後に制御システムの可用性
最後は制御システムの可用性の話しで締めたいと思います。このブログを書こうと思った当初は、「インターネットとの疎通確認方法を伝えることは簡単なこと」と思って書き始めましたが、「制御システムの運用に影響がないように伝える。多くの人が誤解せずに仕組みと手順を理解できるように簡潔・平易に伝える。」ということを考え出すと大変であることを改めて感じました。仮に、これを読んだ本人が理解いただけても、関係者にこの内容だから安全・平易にできるということを説明し許可を得られなければ現実の制御システムでは確認の実施はできません。制御システム業界の方から相談を受けるサイバーセキュリティの専門家の方は、制御システムに関わる人たちは、可用性を担保するためにこういうことも気にするのか？という事を感じていただけたらよいかもしれません。