はじめに
こんにちは！NTTドコモビジネスの2025年夏の現場受け入れ型インターンシップに参加させていただきました、インターン生の竹田です。私は現在高専の専攻科1年生で、普段は船舶におけるサイバーセキュリティに関する研究活動を行っています。
この記事では、私が今回のインターンシップで取り組んだ業務体験内容について紹介します。
参加のきっかけ
私がインターンシップに参加したのは、研究のテーマとして「船舶におけるIDS（侵入検知システム）」を扱っていることが理由です。制御システムのセキュリティと船舶のセキュリティは「可用性」を最重要視するという点で類似しているため、実際に制御システムで使用されているOT-IDS（制御システム向けIDS）がどのように運用されているのかを知りたいと思いました。また、船にIDSを導入することで船舶会社にどのような利点が見込めるのか、導入する場合の技術的な課題は何かについて理解したいという思いもありました。
インターンシップ概要
今回私は、NTTドコモビジネス イノベーションセンターで、OTシステム向けIDS・セキュリティ可視化サービスである、OsecT（オーセクト）の開発に関する業務を行いました。
インターンシップで行った業務体験内容を以下にまとめます。
OTセキュリティとOsecTの概要把握
まず、OTセキュリティの概要を把握するために、イノベーションセンターが社会人向けに提供している教育プログラムを受講させていただきました。
講義では、Stuxnet、Mirai、WannaCryといったマルウェアが制御システムに影響を及ぼした事例に加え、GPSスプーフィングやWebカメラの不正利用など、制御環境にも波及する脅威が紹介されました。また、ランサムウェア被害を受けた企業の約53％が50万ドル以上の身代金を支払ったという調査結果を知ることになりました。私はこの数字を聞いて、サイバーリスク保険の存在によって経済的負担が減っているために、莫大な金額を請求されても企業が支払いに踏み切ってしまう現状があるのではないかと思いました。
さらに、ICSサイバーキルチェーンやMITRE ATT&CK for ICSといった、OTセキュリティ特有の分析フレームワークも紹介されました。これまで一般的なITセキュリティのフレームワークしか知らなかったため、制御システム向けに整理された独自の手法が存在することを初めて知り、新鮮な学びとなりました。
OTセキュリティの概要を学ぶ上で特に面白いなと感じたのは、業界によってセキュリティ要件の枠組みが大きく異なる点です。
- 船舶分野
- UR E26/27という国際的に統一された技術要件が存在し、グローバルに共通の基準に基づいて安全性やサイバーセキュリティ対策を整備する流れがある。これは国際航行を前提とするため、世界的に統一されたルールが不可欠となっている。
- 製造分野
- 国や地域、さらには分野ごとに異なる規格が並立しており、北米ではCSA規格、EUではNIS2指令、半導体分野ではSEMI規格などが例として挙げられる。市場や技術領域の多様性が大きいため、各地域、各分野で独自の要件が策定されている。
この違いは、業界ごとの国際性や供給網の特性を反映していると考えられます。船舶は国際航行を前提とするためグローバルに統一されたルールが不可欠である一方、製造業は市場や技術領域の多様性が大きいため、各地域で独自の要件が策定されやすいのだと理解しました。単に「OTセキュリティ」と括るのではなく、こうした制度設計や標準化の背景を踏まえて学ぶことの重要性を改めて実感しました。
次に、チームが開発しているサービスであるOsecTについての説明を受けました。
(引用元: https://www.ntt.com/business/services/security/security-management/wideangle/osect.html)
OsecTは2つの基本機能を備えています。
- ネットワークの可視化
- ネットワークトラフィックを分析し、資産・通信・セキュリティリスク等をwebポータル画面で可視化できます。これにより、ネットワークマップやトラフィック量から重要な端末を視覚的に把握でき、対応の優先順位がつけやすくなります。
- 脅威・脆弱性の検知
- 通信状況を学習し、脅威や脆弱性を検知した際にアラートを通知します。検知した情報はwebポータルでも確認可能です。
また、資産台帳と連携する機能も持っているため、不審な状況を見つけたときに設置場所や担当者などの情報をもとに、素早く対応することが可能となっています。さらに、資産台帳に登録されていない、いわゆる未把握の機器も表示されるため、台帳の漏れを補完したり、不正に接続された端末の存在を調査したりすることも可能です。これにより、既存の資産管理の精度を高めると同時に、セキュリティリスクを早期に発見する仕組みとしても活用できます。
一方で、現行の仕組みには課題があることも示されました。例えば、IPアドレスを持たない機器については、対応しているOTプロトコル以外は可視化の対象外となるため、すべての資産を完全に把握できるわけではありません。
説明を聞いて、これまでIDSというと「脅威検知」をするものだという印象がありましたが、OT-IDSには「ネットワークの可視化」という重要な役割も担っているんだということを知り、とても勉強になりました。
テーマ選定
ここまでの講義・説明を受けて、私はある1つの仮説を立てました。
船舶のプロトコルを分析すれば船内の資産を把握でき、資産インベントリの作成・更新補助ができるのではないか。
※資産インベントリとは、IACS UR E26/27で提出が義務付けられている、船舶機器の詳細をまとめた台帳です。
船舶のライフサイクルを通じて船舶資産インベントリは更新・維持されなければならないことを考慮して作成する必要があります。なお、資産インベントリの管理を手動で行う場合、更新作業が煩雑になる可能性があります。そのため、資産インベントリの更新を効率化し、精度を高めるために、システム化が推奨されます。 （Class NK | IACS UR E26 p.31 4-1.2より）
この点を踏まえ、各船舶機器が発する固有のシグナルを活用できれば、船舶資産の自動識別が可能となり、資産インベントリの作成・更新作業を大幅に補助できるのではないかと考えました。
しかし、OsecTは船舶特有のプロトコルに対して十分な解析機能を持っていません。解析可能とするためには新たに専用のパーサーを開発・実装する必要があります。
そこで、以下のプロセスで調査・検証を進めることにしました。
検討1: 船舶での使用プロトコル調査
調査の結果、船舶では主に2つのプロトコルが使われていることが分かりました。調査内容を以下にまとめます。
NMEA 0183
- NMEAは「National Marine Electronics Association（米国海洋電子機器協会）」の略。
船舶機器間の通信のための仕様で、潮流計、音響測深機、ジャイロコンパス、GPSなどのデータを伝送するために使用される。シリアルポートを使用した片方向通信でASCII形式。
例（GPS）：
$GPGGA,052400.00,3539.3146239,N,13945.6411751,E,4,07,0.59,4.987,M,34.035,M,1.0,3403*76（データ引用元: https://ales-corp.co.jp/technical-information-nmea/）Talker IDとよばれる、どの機器がそのデータを送信しているかという識別子がある。上記の例では、
$GPGGAのGPの部分がTalker IDとなる。Talker ID対応表（一部） 引用元：pynmea2/NMEA0183.pdf at master · Knio/pynmea2 · GitHub
| **ID** | **解説** | | --- | --- | | AG | 一般的なオートパイロット | | AP | 磁気コンパス連動のオートパイロット | | CD | DSC（デジタル選択呼出）通信装置 | | CR | 無線ビーコン受信機 | | CS | 衛星通信機 | | CT | MF/HF帯ラジオ電話通信機 | | CV | VHF帯ラジオ電話通信機 | | CX | スキャン機能付き無線受信機 | | DF | 方位探知機 | | EC | ECDIS | | EP | EPIRB | | ER | 機関室モニタリングシステム | | GP | GPS受信機 | | HC | 磁気コンパス | | HE | ジャイロコンパス（真北追従） | | HN | ジャイロコンパス（非真北） | | II | 統合計測機器 | | IN | 統合ナビゲーションシステム | | LC | ロランC | | P | メーカー独自（非標準） | | RA | レーダー/ARPA（自動衝突予防装置） | | SD | 音響測深機 | | SN | その他の電子測位システム | | SS | スキャニング音響測深機 | | TI | ターンレートインジケータ | | VD | ドップラー式速度センサ | | DM | 水中・磁気式速度ログ（船速計） | | VW | 水中・機械式ログ（パドルホイール等） | | WI | 気象センサ | | YX | トランスデューザー | | ZA | 原子時計 | | ZC | クロノメーター | | ZQ | 水晶時計 | | ZV | 電波時計 |
IEC61162-450
- IECは「International Electrotechnical Commission（国際電気標準会議）」の略で、後ろに標準化された規格の番号を付与して文書や通信規格そのものの名として利用される。
UDPマルチキャストを使って、NMEAセンテンスをEthernetパケットで送信するための規格。
例：
UdPbC\0\s:GP0001\$GPGGA,052400.00,3539.3146239,N,13945.6411751,E,4,07,0.59,4.987,M,34.035,M,1.0,3403*76\r\nタグブロック部と呼ばれる、NMEAセンテンスの直前に配置される行の中にはsブロックとよばれる送信元識別子がある。
調査の結果、NMEA 0183にはTalker ID、IEC61162-450にはsブロックと、どちらのプロトコルにも資産特定に使えそうな識別子がありました。
検討2: 現状の船内ネットワーク調査
次に、現状の船内ネットワークがどのような構成なのか調査しました。
あくまで私の予想ですが、GPSや潮流計などのシリアル出力データ（NMEA 0183）を入出力IF装置がIEC61162-450に変換しているのだと思われます。
検討3: 船舶pcapに対する現状のIDS製品の出力検証
次に、OsecT以外でのOT-IDSについても船舶プロトコルの対応状況を調査するために、以下の環境を想定したpcapファイルを用意し、2つのOT-IDS製品を使ってトラフィック解析しました。
結果として、今回の検証で使用したOT-IDSでは船舶で使われているプロトコルを解析できませんでした。このため、OsecTに適用可能な船舶プロトコルパーサーを新たに作成することにしました。
今回は、IEC61162-450の仕様書が手元にない＋インターネットにもあまり情報がないため、NMEA 0183のTalker IDを足掛かりにしてパーサーの作成を進めました。
Talker IDから資産を出力するZeek・Spicyパーサー作成・検証
OsecTのパーサーはZeek・Spicyで構成されています。
Zeek・Spicyとは
- Zeek
- トラフィックを解析して、IPアドレス、MACアドレスやプロトコルなどの情報をログとして出力するOSS。
- Spicy
- Zeekで利用するC++のパーサーをC++で記述することなく簡易に生成するためのツール。
参照：【日本初紹介】Zeek・Spicyの使い方まとめ - NTT docomo Business Engineers' Blog
今回は、ZeekとSpicyを使って船内ネットワークトラフィックを解析するためのパーサーを作成しました。
パーサー検証
作成したパーサーを使って、実際に船内ネットワークトラフィック（pcapファイル）を解析しました。
今回の検証では、2種類のNMEA 0183メッセージからTalker IDとSentence Typeの2つのフィールドを抽出し、Talker IDからセンサの特定ができているかを確認しました。以下は、ZeekとSpicyを用いて取得したNMEAメッセージの解析結果（logファイル抜粋）です。
GPの場合：GPS
HEの場合：Heading （ジャイロコンパス）
上記の通り、Talker IDから発信元のセンサの特定（船舶資産の特定）が行えていることが分かります。
まとめ
今回は、既存のOT-IDSが船舶特有のプロトコルを解析できないという技術課題に対し、NMEA文を解析可能にする独自のパーサーを作成しました。
このパーサーではNMEA 0183内に含まれるTalker IDを足掛かりにして船舶機器を特定できるように設計しており、その情報をOsecTの可視化機能に組み込むことで、船舶特有の機器の可視化の強化や資産インベントリの補助につながる可能性があるというポジティブな成果を得ることができました。
イベントへの参加
IDSに関する業務以外にも複数の社内イベントや見学会に参加させていただきました。
SOC見学
NTTセキュリティのSOC（Security Operation Center）を見学しました。
当初はSOCに対して「脅威を検知したら即座にアラートを出す場所」というイメージを持っていました。しかし、実際にNTTセキュリティが提供するSOCサービスは一定期間トラフィックを収集・分析し、詳細なレポートとしてクライアントに提供するサービス形態であることを知りました。SOCには多様な形があるのだということを知ることができ、とても勉強になりました。
ドコモとのコラボ企画
イノベーションセンターで攻撃インフラの解明や撲滅に向けて活動しているPJがセキュリティ国際会議「Botconf」で発表した内容を、ドコモ本社のインターン生とともに聴講させていただきました。
発表内容は新ロシア派ハクティビストに関する詳細なレポートで、実際の脅威情報分析の手法を学ぶ貴重な機会となりました。また、ハクティビストの情報を安易に拡散することがかえって悪影響を生む可能性があると知り、情報との向き合い方を考え直すきっかけにもなりました。
イノベーションセンター内での業務共有
イノベーションセンター内で活動する5名のインターン生が、それぞれの担当業務や取り組み内容を共有しました。
普段は近くで作業していても、実際に何をしているのか詳しく知る機会は少なかったので、とても新鮮でした。みんな全然違うテーマやプロジェクトに取り組んでいて、「そんなことやってるんだ！」と驚くことも多く、チームの多様性やそれぞれの専門性の広さを実感できて面白かったです。
TechLunch
NTTドコモビジネスで不定期開催されているランチ勉強会「TechLunch」に参加しました。
「勉強会」という言葉から堅い雰囲気を想像していましたが、実際は社員の方がそれぞれの興味関心に基づいて自由に発表する形式で、活発かつフランクな学びの場でした。
当日は社員1名とインターン生2名の発表があり、発表中はSlack上でリアルタイムに反応が飛び交い、オープンな雰囲気を感じました。
インターンシップを通して学んだこと
インターンに参加する前は、GPSスプーフィングやAISスプーフィングといった船舶に多く見られる攻撃を検知するIDSを作成することを考えていました。しかし、OT-IDSの説明をしていただく中で「資産インベントリ補助」という新たな活用方向を見出すことができ、とても有意義な経験となりました。
また、製造業と船舶業界ではセキュリティ要件の枠組みが大きく異なることも学びました。将来的には製造業のセキュリティ分野に関わりたいと考えているため、今後は制度やプロトコルの違いを意識しながら、より幅広い視点で学びを深めていきたいと思います。
さらに、インターンを通じてセキュリティに関わる仕事の現実的な難しさと奥深さを実感しました。重大なインシデントが起こらないことは、セキュリティに携わる者として理想的な状態です。しかし一方で、何か大きな事件が起こらなければ業界全体の意識や整備が進みにくいという現状もあり、その間にある葛藤のようなものを感じました。
おわりに
今回のインターンはこれまで開発に携わった経験がなかった自分にとって、大きな一歩を踏み出す機会となりました。以前から「何かを作ってみたい」と思いながらも、具体的なアイデアが浮かばなかったり、時間を理由に後回ししてしまったりしていました。そんな中で、実際に手を動かして開発へ取り組めたことは、自分にとって非常に貴重な経験でした。
また、さまざまなイベントにも参加させていただき、自分の所属チームだけでなく他のチームやインターン生、さらにはドコモグループの社員の方々とも関わることができました。部署を越えて多くの方と交流する中で、職場の雰囲気や、人とのつながりの大切さを改めて実感しました。
最後になりましたが、このインターンに関わってくださった皆さまに心より感謝申し上げます。受け入れてくださったチームの皆さま、特にこのインターンで参加したIT/OT統合セキュリティPJおよびOsecT Tech PJの田中さん、前田さん、加島さんには2週間にわたり大変お世話になりました。温かくご指導くださり、本当にありがとうございました。
