CICSトランザクションセキュリティの脆弱性を検出するための静的分析

CICSシステムは、世界で最も機密性が高く、大量のトランザクション処理環境をサポートしています。銀行や保険から物流や防衛に至るまで、これらのプラットフォームは、セキュリティ監視を許容できないワークロードを処理します。運用の稼働時間が最も注目されることが多いですが、CICSアプリケーションの構造は、 隠れたリスク 定期的なレビューでは見落としがちなもの。

これらのリスクの多くは、レガシーコードに起因します。ネストされたCOBOLモジュール、トランザクションプログラムバインディング、動的プログラム呼び出し、再利用されたcommareaは、 脆弱性 表面からは見えない脆弱性。一般的な例としては、検証されていない端末アクセス、XCTL命令やLINK命令の不正使用、不適切なトランザクションルーティングによる権限昇格などが挙げられます。これらの欠陥は、アラートがトリガーされることなく、何年も本番環境に存在する可能性があります。

静的解析 これらの問題が悪用される前に特定するための構造化された方法を提供します。しかし、WebアプリケーションやAPIアプリケーションとは異なり、CICSワークロードのスキャンにはより詳細な検査が必要です。アナリストは、複数のプログラムレベルにわたる制御フローをトレースし、共有メモリ内でのデータの移動を理解し、メインフレームのトランザクション動作に特有のパターンを検出する必要があります。

この記事では、CICS環境における静的解析を適用してセキュリティ上の欠陥を発見し、軽減する方法に焦点を当てます。注目すべき高リスク構造の概要、COBOLコードにおけるトランザクションロジックの解釈方法、そして大規模なレガシーシステムを正確かつ詳細にレビューする必要があるエンジニア向けのガイダンスを提供します。この記事の目的は、チームが推測や中断なしにトランザクション層を安全に保護できるように支援することです。

CICSトランザクション攻撃対象領域の理解

CICSトランザクションは、単なるプログラム的な作業単位ではありません。アクセス制御、ユーザーID、リソース認証、セッション整合性といった機能に深く組み込まれています。多くのメインフレームシステムは、セキュリティの適用が明示的ではなく暗黙的に行われる、数十年前の設計パターンに依存しています。これにより、テストやコンプライアンス監査において見落とされがちなリスクが生じます。

このレベルの静的分析は、制御がどこに渡されるか、入力がどのように処理されるか、そして特定の実行コンテキストにおいてどのパスが到達可能かをマッピングすることから始まります。侵入テストに合格したシステムであっても、誤ったルーティングや過剰な権限が付与されたトランザクションフローに関連する脆弱性が残っている可能性があります。

EXEC CICS 呼び出しにおける隠れた脆弱性

よくある弱点は、 EXEC CICS LINK, XCTLまたは RETURN 呼び出し元やコンテキストを検証せずに実行します。プログラムが緩く連鎖され、プログラム名が外部から提供されたり動的に構築されたりする場合、悪意のある入力によって、昇格された権限を持つモジュールへの実行が誘導される可能性があります。

実際には、次のようになります。

EXEC CICS LINK PROGRAM(PROG-NAME) COMMAREA(COMM-AREA) LENGTH(COMM-LEN) END-EXEC

If PROG-NAME ユーザーが指定した値から構築されたり、厳密な検証なしにテーブルからマップされたりすると、権限のないユーザーが公開されることを意図していない機密プログラムを呼び出す可能性があります。

静的解析では、特に次のようなパスを検出する必要があります。

• プログラム名は連結された値またはマスクされた値から構築されます
• 許可されたターゲットまたは期待されるターゲットに対してフォールバックチェックは実装されていません
• 受信プログラムは権限のさらなる検証なしに運営される

SVCとストレージ制御のエスカレーションパターン

マクロレベルの命令を介してアクセスされる特定のSVCベースの呼び出しまたは内部サービスルーチンは、メモリ操作によるエスカレーションを許可する場合があります。 ADDRESS, ASSIGN、またはターミナル データ ブロックへの直接アクセスにより、タスク レベルのセキュリティ コンテキストが適切に適用されていない場合に安全策をバイパスできます。

典型的な危険信号のパターンには次のものが含まれます。

• 生の入力から端末IDまたはタスク番号を割り当てる
• 使い方 EXEC CICS ADDRESS TCTUA または同等の呼び出しの後に続く直接書き込み
• ロール検証なしでセッション状態に基づいて制御を切り替える

端末構造と CICS 内部に精通している攻撃者は、これらのアクセス ポイントを悪用して権限を昇格したり、意図しないコマンドを挿入したりすることができます。

これらの脆弱性を特定するには、CICS コマンドをスキャンするだけでなく、メモリ割り当て全体のデータ系統を解決し、制御パラメータの出所を確認し、安全でないまたは認証されていないコンテキスト値の使用にフラグを立てる必要があります。

CICS環境における静的分析の範囲

CICS環境における静的解析は、基本的な構文やキーワード検出にとどまらず、より高度な解析が必要です。アナリストは、コードの構造だけでなく、トランザクションモデル、プログラムの連携、データフロー、権限の境界も理解する必要があります。包括的な評価では、ユーザー、端末、アプリケーションが共有メモリや連鎖実行ロジックを通じてどのように相互作用するかを反映させる必要があります。

このレベルの検査は複雑であり、特に数十年前に開発され、複数のチームによって長期間メンテナンスされてきたアプリケーションを扱う場合にはなおさらです。プログラムは、構造化されていない制御フロー、動的なコマンドの使用、再利用されたプログラムIDに依存していることが多く、これらはすべて権限の始まりと終わりを曖昧にします。

信頼境界の COBOL-CICS ソースフローの分析

現代のアプリケーション環境では、信頼境界は通常、フロントエンドUIとAPI間などのレイヤーによって定義されます。CICSでは、信頼境界は暗黙的であり、プログラム間の連携の中に埋め込まれていることがよくあります。静的解析では、どのプログラムが他のプログラムに制御を渡しているか、入力がどこからシステムに入力されているか、そしてその入力の送信元が信頼できるかどうかを追跡する必要があります。

例えば、ログイントランザクションから始まるチェーンは、5つ以上のプログラムに制御を渡す場合があります。これらのプログラムのいずれかが、（例えば、更新されたcommareaセグメントを介して）新しいユーザー入力を再検証せずに受け入れた場合、信頼境界は破られます。静的解析では、これらの遷移ポイントを検証対象としてフラグ付けする必要があります。

検討すべき重要な側面は次のとおりです。

• 外部データが実行パスに入るエントリポイント
• 呼び出し元を検証せずに発生する LINK または XCTL の呼び出し
• 実行が認証フローから非認証フローに切り替わる領域

ハードコードされた認証情報と権限昇格ロジックの検出

急速な開発や緊急パッチ適用の際には、ハードコードされたセキュリティトークン、ユーザーID、またはAPPLIDが導入されることがあります。これらの値は、標準的なアクセス制御をオーバーライドしたり、実際の認証が失敗した場合にフォールバックアクセスを許可したりすることができます。

たとえば、次のような COBOL セグメントがあります。

IF USER-ID = 'SECADMIN' THEN
   MOVE 'Y' TO AUTH-FLAG
END-IF

表面上は危険に見えないかもしれないが、 USER-ID 外部から影響を受けたり、他のプログラムで再利用されたりする可能性があるため、永続的なリスクが生じます。

静的解析エンジンは以下を検索する必要があります。

• IF ステートメントまたは代入におけるセキュリティに敏感な値
• 検証なしに直接設定される権限フラグ
• 制御ロジックをバイパスする汎用APPLIDまたはユーザー名の使用

これらのパターンは目に見えないものですが、その存在は、セキュリティロジックとビジネスルールが重なり合う、より大きな設計上の問題を示唆することがよくあります。静的解析によってこれらのパターンを分離することで、チームは安全に、そして隠れた権限パスを回避してコードをリファクタリングできるようになります。

CICS環境における静的分析の範囲

CICSシステムは従来のアプリケーションスタックとは大きく異なります。最新のサービスはAPIやイベントドリブンフローを公開していますが、CICSアプリケーションは多くの場合、コマンドエリア、端末入力、共有メモリを介して渡されるデータに依存する、密結合されたプログラムチェーンとして実行されます。このアーキテクチャは、静的分析を特に困難にします。アナリストは、既知の脆弱な呼び出しを探すだけでなく、複数のプログラム（中には数十年にわたるレガシー開発にまたがるものもあります）にわたる実行フローを再構築する必要があります。

意味のある静的レビューでは、データがシステムにどのように入力されるか、制御がモジュール間でどのように渡されるか、そして検証が期待されているにもかかわらず検証が行われていない箇所を考慮する必要があります。CICSにおけるセキュリティ違反は、必ずしも明らかに危険な呼び出しから発生するわけではありません。多くの場合、信頼に関する想定の見落とし、コンテキストチェックの欠落、またはネストされた実行フローや遅延実行フローにおける権限の不一致から生じます。

信頼境界の COBOL-CICS ソースフローの分析

典型的なCOBOL-CICSトランザクションは、単一のモノリシックブロックで構成されるのではなく、複数のプログラムにまたがり、 EXEC CICS LINK, XCTLまたは RETURNcommareaブロックを使用して、プログラム間でデータを共有します。多くのプログラムは、受信したcommareaの内容を独自に検証せず、信頼できる呼び出し元が既に検証済みであるという前提に依存しています。この前提は、権限ドリフトや不正アクセスの最も頻繁な原因の一つです。

静的解析では、データの侵入の開始点を特定し、それらの呼び出し全体にわたる伝播を追跡する必要があります。例えば、

MOVE WS-USERID TO COMM-USERID  
EXEC CICS LINK PROGRAM('ACCTUPD') COMMAREA(COMMAREA-BLOCK) LENGTH(COMM-LEN)  

次に、 ACCTUPD次のような表示が出る場合があります。

IF COMM-USERID = 'ADMIN01'  
   PERFORM ADMIN-ROUTINE  

これにより暗黙の信頼境界が作成されます。 WS-USERID フローの早い段階で上書きまたは偽造されたことがない場合、 ACCTUPD 管理ルーチンを盲目的に実行する。静的解析では相関関係を調べる必要がある。 COMM-USERIDの起源を特定し、再検証なしで機密の意思決定にそれを使用するすべての下流コードにフラグを設定します。

静的スキャンで検出できる一般的な信頼境界違反には次のようなものがあります。

• ローカル認証なしでcommareaフィールドに基づく決定分岐
• 端末またはAPPLID値に基づいてロジックを実行する
• 活用 EIBTRMID, EIBTASKNまたは EIBRESP 原点チェックなしの制御ロジック
• 疑似会話チェーンに再入する際のユーザーセッションの再検証がない

ハードコードされた認証情報と権限昇格ロジックの検出

静的レビューでは、COBOL文に直接埋め込まれたハードコードされたユーザーID、特殊コード、またはAPPLIDが頻繁に発見されます。これらは内部テストや運用上の回避策のために追加されたものである可能性がありますが、本番環境にそのまま残され、深刻なリスクをもたらすことがよくあります。

よくフラグが立てられる実際のサンプルパターンは次のとおりです。

IF USER-ID = 'SYSROOT'  
   MOVE 'FULL' TO ACCESS-LEVEL  

or

IF EIBTRMID = 'TSTTERM1'  
   MOVE 'Y' TO BYPASS-SECURITY-FLAG  

これらは、制御されていないアクセス権限の昇格パスを作成します。攻撃者が端末へのアクセスを取得したり、ハードコードされたユーザーIDを発見したりすると、アプリケーションの残りの部分は完全な認証が行われたかのように動作する可能性があります。

より微妙な例:

IF SUBSTR(COMMAREA-DATA, 1, 5) = 'DEBUG'  
   PERFORM DIAGNOSTIC-ROUTINES  

このロジックが削除または保護されていない場合、細工された入力によって、一般ユーザー向けではないログ、ファイル ポインター、またはメモリ診断を公開する機能がアクティブ化される可能性があります。

このような欠陥を検出するための静的ルールを構築するときは、次の点に重点を置きます。

• IF or EVALUATE ユーザーまたは端末に結び付けられたハードコードされたリテラル値を使用するステートメント
• ハードコードされた資格情報をアクセスフラグに直接マッピングする
• 旗など BYPASS, OVERRIDEまたは DEBUG 条件付きロジックをトリガーする
• ユーザー名や端末IDの表面的なチェックのみで保護されたコードセクション

多くの場合、これらのチェックは非公式に追加され、一度もレビューされていません。静的スキャンでは、手動検査のためにフラグを設定するか、繰り返し発生する不正使用に対してパターンベースのアラートを強制する必要があります。

静的分析レンズを拡張してこれらの境界条件とハードコードされたフォールバックを捕捉することで、監査人やセキュリティ エンジニアは、システムの残りの部分が安全に機能しているように見えても、CICS アプリケーションが信頼チェーンを壊す可能性がある場所をより正確に把握できるようになります。

セキュリティリスクを示すコード構造パターン

個々のCICSコマンドは単独では安全に見えても、トランザクションが実際に保護されているかどうかは、プログラムロジックの周囲の構造によって決まることがよくあります。静的分析では、プログラムがどのように相互作用し、権限がどのように推論され、制御フローのどこに暗黙的な信頼が組み込まれているかを理解するために、行単位のスキャンにとどまらない詳細な分析が必要です。

レガシーシステムは特にこれらのパターンに陥りやすい傾向があります。開発チームは時間の経過とともに、一時的なロジック、権限のショートカット、そして多目的トランザクションを導入し、関心の分離を曖昧にします。これらの構造的なアンチパターンを特定することは、トランザクションのセキュリティを強化するために不可欠です。

昇格された権限によるトランザクションとプログラムのマッピング

各CICSトランザクションIDは通常、特定のプログラムまたはディスパッチルーチンにマッピングされます。しかし、多くのシステムでは、異なるモジュール間でトランザクションコードを再利用したり、ユーザー入力に基づいて複数の機密機能を実行できる広範なプログラムハンドラーを割り当てたりします。

適切なフィルタリングなしに汎用ハンドラーが高権限トランザクションに結び付けられると、これは危険です。静的解析では、どのトランザクションIDがどのプログラムにマッピングされているかを追跡し、各プログラムがそのトランザクションコンテキストでどのようなロジックを実行するかを特定する必要があります。

例：

EXEC CICS RETRIEVE INTO(COMM-AREA)  
EVALUATE COMM-AREA-FUNCTION  
   WHEN 'UPDATE'  
      PERFORM UPDATE-ROUTINE  
   WHEN 'DELETE'  
      PERFORM DELETE-ROUTINE  
   WHEN OTHER  
      PERFORM INQUIRY-ROUTINE  
END-EVALUATE

上記を次のようなトランザクションにマッピングすると FINTRN01、そのトランザクションにシステム権限が割り当てられている場合、 COMM-AREA-FUNCTION ユーザーがロールの制限を回避し、削除または更新ロジックを呼び出すことを許可できます。

リスク指標には以下が含まれます。

• ユーザーが指定したフラグに基づいて複数の特権アクションを実行する単一のプログラム
• トランザクションから機能へのハードコードされた制限がない
• 環境またはビジネスユニット間で共有されるトランザクションコード
• ディスパッチモジュール内の特定のブランチに関連付けられたアクセスチェックがない

静的スキャンでは、commarea フラグがフローを制御する場所と、それらのフローが認証、ロール検証、またはリソース レベルの制約によって保護されているかどうかを特定する必要があります。

コマンドレベルとマクロレベルのコールパスの弱点

もう一つのリスク源は、コマンドレベルとマクロレベルのプログラム間の不整合です。時間の経過とともに進化したシステムでは、両方のスタイルが混在していることがよくあります。コマンドレベルのコードは構造化された構文と優れた可読性の利点がありますが、マクロレベルのコードは低レベルのアクセスしか提供せず、安全策も少ない傾向があります。

両方のタイプを一緒に使用すると、特にマクロレベルのプログラムが中間のセキュリティ強化なしで動的にリンクされている場合に、微妙な呼び出しパスの脆弱性が生じる可能性があります。

例：

• コマンド レベルのプログラムは、共有メモリを直接読み取ったり変更したりするマクロ レベルのモジュールにリンクします。
• マクロレベル モジュールは、呼び出し元のプログラムがすでにデータを検証していると想定します。
• エントリと実行の間に中間チェックは実行されません。

フローの簡略化されたビュー:

* In command-level handler  
EXEC CICS LINK PROGRAM('LEGACYIO') COMMAREA(DATA-BLOCK)

* In macro-level module LEGACYIO  
L R1,=V(DATA-BLOCK)  
ST R1,=V(SYSTEM-FILE-POINTER)  

ここで、マクロレベルのモジュールはストレージポインタを直接操作することが信頼されています。呼び出し側プログラムが検証に失敗した場合、 DATA-BLOCK攻撃者がメモリ領域を操作したり、許可されていないデータセットを参照したりする可能性があります。

静的分析では、次の点に特に注意する必要があります。

• 構造化プログラムからレガシーモジュールへのLINKまたはXCTL呼び出し
• コマンドレベルとマクロレベルのコード間のパラメータの受け渡し
• 境界チェックを行わずにストレージポインタやシステムファイル識別子を使用する
• 入力検証が他の場所で行われていると想定される再利用モジュール

これらの脆弱性は、エクスプロイトの条件として、端末のコンテキスト、タスクパラメータ、実行フローの正確な整合性が求められることが多いため、テストではほとんど検出されません。しかし、静的スキャンでは、これらの脆弱性を可能にする構造的な設定を検出できます。

欠陥のあるコード行だけでなく構造上のリスクを特定することで、アナリストは CICS システムの全体的なセキュリティ体制をより適切に評価し、影響の可能性に基づいて修復の優先順位を決定できます。

CICS 固有の API 不正使用の静的検出

CICSは、システムレベルのリソースとやり取りする幅広いEXECコマンドとマクロを公開しています。これには、端末識別子、タスク番号、セッションメモリ、トランザクションルーティングロジックなどが含まれます。これらの機能は柔軟性を提供しますが、十分な保護対策を講じずに使用すると脆弱性が生じる可能性があります。これらのインターフェースを誤用すると、意図しない権限昇格、制御のバイパス、または許可されていないシステム領域へのアクセスにつながる可能性があります。

静的分析により、開発者や監査担当者は、これらのAPIがどのように呼び出され、どのようなパラメータが使用されるか、そして呼び出しコンテキストが適切な検証を提供しているかどうかを検証することで、こうしたリスクを特定できます。適切な実装には、実行コンテキスト、アクセスパターン、そしてトランザクション間のデータフロー境界を注意深く検査する必要があります。

EXEC CICS ASSIGNおよびADDRESSの安全でない使用の追跡

その ASSIGN and ADDRESS コマンドはCICSの内部構造に直接アクセスします。これには、端末ID、アプリケーションID、タスク固有のメモリ位置といった重要なメタデータが含まれます。これらの値はログ記録やセッション追跡に頻繁に使用されますが、制御ロジックがセキュリティ上の判断にこれらの値を利用する場合、危険を伴います。

この例を見てみましょう：

EXEC CICS ASSIGN TERMINALID(TERM-ID)
IF TERM-ID = 'DEVBYPASS'
   PERFORM SKIP-AUTH-CHECKS

ここでは、アクセス制御は端末IDに直接結び付けられています。この値を知っているユーザー、または端末設定を偽装できるユーザーは、このロジックを悪用してセキュリティメカニズムを回避する可能性があります。

あるいは、次のようなバリエーションを考えてみましょう ADDRESS:

EXEC CICS ADDRESS EIBTASKN
MOVE EIBTASKN TO TRACE-BUFFER

単独で見ると、これは無害に思えます。しかし、もし EIBTASKN 後で認証やトランザクション承認に使用される場合、予測可能性や不正なセッションのなりすましのリスクが生じます。

安全でない ASSIGN および ADDRESS の使用を示す一般的な指標には、次のものがあります。

• 端末ID、アプリケーションID、またはタスク番号のみに基づいて分岐を制御する
• アクセス検証またはバイパスフラグに割り当てられた値を直接使用する
• ADDRESSコマンド後の構造検証なしのポインタ参照
• IF条件におけるシステム割り当て識別子とハードコードされた値の比較

特に割り当てられたデータがプログラム ルーティングや特権ロジックに影響を与える場合は、静的スキャン ツールをこれらの条件にフラグを立てるように構成する必要があります。

代替実行パスによるトランザクションフローの改ざん

多くのCICSアプリケーションでは、フォールトトレランスを向上させるためにフォールバックまたは代替トランザクションルーティングが使用されています。しかしながら、これらの代替パスは適切なアクセス検証が行われていなかったり、意図しない状況でアクセスされてしまう可能性があります。これにより、攻撃者が通常のトランザクションフローの外部から機密ロジックをトリガーする機会が生じます。

次のケースを考えてみましょう。

IF EIBCALEN = 0
   EXEC CICS XCTL PROGRAM('RETRYTX')

このコードは、commareaが渡されなかった場合に実行をリダイレクトします。しかし RETRYTX 信頼できるシーケンス内でのみ使用するように設計されている可能性があります。独自の検証を実施しない場合、ユーザーは長さゼロのトランザクションを実行するだけで機密性の高い機能にアクセスできてしまいます。

もう 1 つの例は、サイレント エスカレーションです。

IF AUTH-FAILS
   EXEC CICS START TRANSID('ALTID')
   EXEC CICS RETURN

If ALTID より高い権限またはより広範な機能を持つトランザクションにマップされ、ロール チェックが欠如している場合、このフォールバックによって意図しないアクセスが発生します。

ここでのリスクは通常、次のようなものから生じます。

• エラー状態に基づいてプログラムを切り替えるための START、XCTL、または LINK の使用
• 複数のトランザクションコード間で再利用されるプログラムID
• 下流モジュールへの検証を延期するRETURNロジック
• 整合性チェックなしでフローを指示するコンマエリア値

静的解析では、完全なトランザクショングラフを構築し、複数のエントリパスを持つプログラムを特定し、不完全な検証後に制御を受け取るプログラムを強調表示する必要があります。関数が分離されているように見えても、隠れたフローによって攻撃者が想定外の特権操作を実行できる可能性があります。

複雑なセキュリティロジックの難読化の処理

レガシーCICSアプリケーションのセキュリティ確保において最も困難な側面の一つは、難読化された、あるいは深くネストされたセキュリティロジックを解明することです。多くのCICSプログラムは数十年にわたって進化し、様々なチームを経て、多層的なアクセス処理を組み込んできました。その結果、重要なセキュリティ上の決定事項は、アクセスできないパスに埋もれたり、モジュール間で複製されたり、断片化されたルーチンに分割されたりすることがよくあります。静的分析では、これらのパターンを再構築し、想定や見落としによってリスクがもたらされた箇所を明らかにする必要があります。

複数のプログラムにわたる分割認証パスの識別

CICS開発者は、複数のユーザーインタラクションに渡って状態を維持するために、疑似会話型プログラミングを実装することがよくあります。その際、意図せず認証と認可が分離してしまう可能性があります。あるプログラムが資格情報を検証し、別のプログラムがセッションフラグを設定し、さらに別のプログラムがアクセスチェックを実行します。このチェーンの一部が切断されたり、別のコンテキストで再利用されたりすると、セキュリティホールが発生します。

例：

プログラム1：

IF USERID = 'SUPPORT1'
   MOVE 'OK' TO SESSION-AUTH
EXEC CICS RETURN TRANSID('TX02')

プログラム2：

IF SESSION-AUTH = 'OK'
   PERFORM PROCESS-ADMIN-DATA

これは意図通りに使用すれば安全であるように思われます。しかし、別のトランザクションがプログラム2を経由せずにプログラム1を直接開始した場合、変数 SESSION-AUTH 初期化されていないか偽造されている可能性があります。2番目のプログラムは、資格情報を再確認することなく、変数のみに基づいてセッションが有効であると信頼します。

静的解析では、特に次のようなプログラム遷移全体にわたって変数の割り当てを追跡する必要があります。

• あるプログラムがフラグを設定し、別のプログラムがそれを読み取ってアクセスを決定する場合
• 認証ロジックの外部に認可ロジックが存在する場合
• プログラムを直接起動して通常の入力検証を回避できる場合

これらのパターンは従来の設計では非常に一般的であり、手動レビューでは見落とされることがよくあります。

内部デバッグまたはテストモードによる制御フローの迂回

開発者は、テストを支援するために、隠しフラグやデバッグモードを組み込むことがあります。これらの機能がデプロイ前に削除されていない場合、または本番環境の端末からアクセス可能な場合、アプリケーションの機密部分へのバックドアとなる可能性があります。

例：

IF COMM-FLAG = 'DEBUG'
   PERFORM BYPASS-AUTH-CHECK

あるいはもっと微妙に言えば:

IF CURRENT-TIME > '210000'  
   PERFORM EMERGENCY-ROUTINE  

後者の場合、業務時間外のルーチンは、バッチジョブや緊急対応のための通常のセキュリティチェックを回避してしまう可能性があります。しかし、対話型セッションから起動できる場合、タイミングベースの攻撃ベクトルが開かれることになります。

難読化されたロジックや危険なロジックをスキャンする場合、静的分析では次の点を優先する必要があります。

• セキュリティロジックを制御する異常な状況（時刻、端末ID、地域コード）
• DEBUG、DEV、OVERRIDE、TEST、BACKDOORなどのフラグ
• 特定の実行条件下ではスキップされるアクセスチェック
• 検証ブランチを飛び越える GOTO または PERFORM パス

目標は、直接的かつ目に見える承認チェックなしで特権コードに実行を渡すことができるものをすべて明らかにすることです。

一貫性のないアクセス制御による再利用ルーチン

多くの大規模CICSアプリケーションでは、開発者はデータアクセスやビジネスロジックのために共通ルーチンを再利用します。これらのルーチンは、公開トランザクションと内部管理ユーティリティの両方から呼び出される可能性があります。共有ロジックにおいて、呼び出し元が既にユーザーのロールを検証済みであると想定している場合、その想定が常に成立するとは限らないため、間接的な脆弱性が生じます。

典型的な構造は次のようになります。

PERFORM UPDATE-ACCT-INFO

...

UPDATE-ACCT-INFO.
   IF ROLE = 'ADMIN'
      EXEC CICS WRITE FILE('ACCTDB')

これは、すべての発信者が UPDATE-ACCT-INFO 正しく設定する ROLE 変数。アプリケーションの他の部分でこのルーチンを呼び出した場合、 ROLE 初期化されていない場合、または呼び出し元が弱いチェックに基づいて誤って設定した場合、不正アクセスが発生する可能性があります。

静的スキャンでは次の項目にフラグを立てます:

• セキュリティ上重要なアクションを実行する共有ルーチン
• 共有ルーチン内でのローカル検証の欠如
• 外部で定義されたアクセス決定に使用される変数
• 執行の現場から遠く離れた場所で行われる役割の割り当て

この形式の難読化は、意図的な隠蔽ではなく、長期的なアーキテクチャの変化によって生じます。コンポーネントがモジュール間で再利用されるにつれて、当初のアクセス想定は劣化します。これらのリスクを明らかにするには、コードの詳細なトレースとコンテキストの相関関係の調査が必要です。

使い方 SMART TS XL CICSトランザクションの脆弱性を検出して排除する

レガシーメインフレームシステムにおけるセキュリティ分析の取り扱いは、本質的に複雑です。CICS環境は、集中管理された構造が欠如していることが多く、最新のドキュメントがほとんど存在せず、手続きの進化が数十年にわたっているのが現状です。 SMART TS XL COBOL、PL/I、JCL、CICS固有のパターンに特化した静的解析エンジンを提供することで、これらの問題に対処します。汎用ツールとは異なり、メインフレーム・エコシステム特有のアーキテクチャと規約を理解します。

CICS のマルチレベルフロー再構築

SMART TS XL アプリケーションポートフォリオ全体をスキャンし、プログラム間フローマップを構築します。これには以下が含まれます。

• トランザクションとプログラムのマッピング
• LINK、XCTL、RETURNを使用したプログラム間の遷移
• 変数とコンマ領域の伝播
• ロールベースの制御ロジックとエントリ条件のトレース

完全な実行チェーンを再構築することで、信頼できるコンテキストを前提とするプログラムが、検証されていない可能性のあるポイントを含む複数のポイントから実際に到達可能であることを検出できます。

ユースケース例：

内部監査により、取引のセキュリティ上の欠陥が明らかになった。 TX94 元々は管理者専用だったプログラムを起動しました。 SMART TS XL プログラムのコールグラフをトレースし、制御フラグが未チェックのcommareaフィールドを介して渡されていることを発見し、同じプログラムエントリにアクセスする他の5つのトランザクションを特定しました。手動トレースではこれを見逃していました。

隠された制御フラグと難読化されたアクセスパスの検出

多くのレガシープログラムには、オーバーライド条件や緊急ルーチンが組み込まれています。これらは、深いネスト、一般的でない変数名、フォールバックロジック内の配置などにより、手動で特定するのが困難な場合が多くあります。 SMART TS XL ルールベースおよびパターンマッチングスキャンを使用して以下を抽出します。

• めったに使用されないフラグ値によって制御される条件分岐
• 端末ID、時刻、またはタスクのメタデータに基づいてトリガーされるロジック
• commarea フラグ、ハードコードされたユーザー ID、またはマクロレベルのルーチンを使用して分岐をバイパスします。

潜在的に特権のある決定ポイントのすべてのインスタンスを明らかにし、到達可能性、トランザクションの露出、および特権昇格の可能性に基づいてランク付けします。

CICS 構造の自動化された脆弱性ルール

表面レベルのスキャナーとは異なり、 SMART TS XL COBOL-CICSプログラム向けにカスタマイズされた組み込みルールが含まれています。これらのルールは、以下の脆弱性を特定します。

• 安全でないEXEC CICS ASSIGNおよびADDRESSの使用
• PERFORMされたルーチンのアクセスロジックが一貫していない
• WRITE、DELETE、またはSTARTコマンドの前の検証が欠落しています
• 状態管理が弱い、時代遅れの疑似会話フロー

これらのルールは、環境、業務機能、監査基準に基づいてカスタマイズできます。特に、古い開発チームが残した誤った仮定を特定するのに便利です。

インパクトトレースバックによる修復の加速

脆弱性がフラグ付けされると、修復は次のように加速されます。 SMART TS XLのトレース機能。ロジック分岐やプログラム関数ごとに、以下の情報を表示できます。

• それにつながるすべての取引
• 呼び出すすべてのモジュール
• 依存するすべての変数
• バイパスされるアクセスロジック

このトレースマップは、開発者や監査人が、欠陥が孤立したものなのか、それともシステム全体に露出したものなのかを即座に把握するのに役立ちます。また、依存関係を手動でマッピングする時間を短縮し、パッチ適用時に新たなバグが混入するリスクを軽減します。

結論と次のセキュリティレビュー手順

レガシーCICSアプリケーションは重要なビジネスロジックを保持していますが、その古さと複雑さゆえに、標準的な方法では見落とされがちなセキュリティ上の盲点が存在します。静的解析は、特に構文やコードスニペットだけでなく、トランザクション全体にわたるより広範な制御フローやアクセスの想定を対象とすることで、隠れたリスクを悪用される前に確実に発見する手段となります。

この記事では、CICS システム特有の欠陥の種類について検証しました。

• 疎結合プログラムに分散された認証ロジック
• 検証なしのASSIGNやADDRESSなどの脆弱なコマンドパターン
• 通常のチェックをバイパスするフォールバックトランザクションとデバッグパス
• 呼び出し元からの信頼できる入力を前提とした再利用ルーチン

大規模なCICSポートフォリオを運用する組織にとって、セキュリティに対する断片的なアプローチはもはや通用しません。現代の脅威は、数百ものモジュールに埋もれた単一の見落としを悪用する可能性があります。詳細なコンテキスト認識を備えた静的分析を適用することで、これらの問題が実際に発生する前、あるいは監査に直面する前に、これらの問題を明らかにすることができます。

次のステップとして検討すべき重要なアクションは次のとおりです。

• すべてのXCTLおよびLINKパスを含む完全なトランザクション・プログラムマップを作成する
• 特権操作を実行する共有ビジネス ロジックを特定してリファクタリングする
• commarea フラグまたはターミナルベースの決定によって影響を受けるすべてのブランチを監査します。
• 各トランザクションのエントリポイントでセキュリティ検証を確立する
• 意図しない露出に対するフォールバックロジックと緊急パスを確認する

このプロセスを加速し、手作業の労力を削減したいチームにとって、次のようなツールは SMART TS XL CICS アーキテクチャに合わせてカスタマイズされた静的分析を提供し、完全なフロー追跡可能性を備えた安全なリファクタリングを可能にします。

メインフレーム環境を保護するには、警戒だけでなく可視性も必要です。そして、静的解析は、その両方を実現できる数少ない手法の一つです。