Статический анализ для обнаружения уязвимостей безопасности транзакций CICS

ИН-КОМ 19 июня 2025 Анализ кода, Проверка кода, Анализ воздействия, Tech Talk

Системы CICS поддерживают одни из самых конфиденциальных и высокообъемных сред обработки транзакций в мире. От банковского дела и страхования до логистики и обороны, эти платформы справляются с рабочими нагрузками, которые не могут позволить себе упущения в плане безопасности. Хотя бесперебойность работы часто привлекает наибольшее внимание, структура приложений CICS вносит скрытые риски которые легко пропустить во время обычных проверок.

Многие из этих рисков возникают в устаревшем коде. Вложенные модули COBOL, привязки транзакционных программ, динамические вызовы программ и повторно используемые запятые могут создавать уязвимости которые не видны на первый взгляд. К распространённым примерам относятся непроверенный доступ к терминалу, неправильное использование инструкций XCTL или LINK, а также предоставление повышенных прав доступа из-за неправильной маршрутизации транзакций. Эти уязвимости могут существовать в рабочей среде годами, не вызывая оповещений.

Статический анализ Предлагает структурированный способ выявления этих проблем до того, как они будут использованы злоумышленниками. Однако, в отличие от веб-приложений или API-приложений, сканирование рабочих нагрузок CICS требует гораздо более глубокого анализа. Аналитикам необходимо отслеживать поток управления на нескольких уровнях программы, понимать, как данные перемещаются через общую память, и выявлять закономерности, характерные для поведения транзакций мэйнфрейма.

В этой статье рассматривается применение статического анализа в средах CICS для выявления и устранения уязвимостей безопасности. В ней описываются структуры с высоким уровнем риска, на которые следует обращать внимание, демонстрируется интерпретация логики транзакций в коде COBOL, а также даются рекомендации для инженеров, которым необходимо точно и глубоко анализировать крупные унаследованные системы. Цель статьи — помочь командам защитить транзакционные уровни без догадок и сбоев.

Содержание

Понимание поверхностей атак на транзакции CICS

Транзакции CICS — это не просто программные единицы работы. Они глубоко интегрированы в управление доступом, идентификацию пользователей, авторизацию ресурсов и целостность сеансов. Многие мэйнфреймовые системы основаны на устаревших шаблонах проектирования, где обеспечение безопасности подразумевается, а не является явным. Это создаёт риски, которые часто упускаются из виду при тестировании или даже аудите соответствия.

Статический анализ на этом уровне начинается с определения того, где передаётся управление, как обрабатываются входные данные и какие пути доступны в определённых контекстах выполнения. Даже системы, прошедшие тестирование на проникновение, могут содержать уязвимости, связанные с неправильной маршрутизацией или чрезмерно привилегированными потоками транзакций.

Скрытые уязвимости в вызовах 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или прямой доступ к терминальным блокам данных может обойти меры безопасности, если контекст безопасности на уровне задач не обеспечивается должным образом.

Типичная картина красного флага включает в себя:

Назначение идентификатора терминала или номера задачи из необработанных входных данных
. EXEC CICS ADDRESS TCTUA или эквивалентные вызовы, за которыми следуют прямые записи
Переключение управления на основе состояния сеанса без проверки ролей

Злоумышленники, знакомые со структурами терминалов и внутренним устройством CICS, могут использовать эти точки доступа для повышения привилегий или внедрения непреднамеренных команд.

Для выявления этих уязвимостей требуется не только сканирование команд CICS, но и разрешение происхождения данных по назначениям памяти, проверка происхождения параметров управления и отметка использования небезопасных или неаутентифицированных значений контекста.

Область статического анализа в среде CICS

Статический анализ в средах CICS должен выходить за рамки базового синтаксиса или обнаружения ключевых слов. Аналитикам необходимо понимать не только структуру кода, но и модель транзакций, связи программ, потоки данных и границы привилегий. Полная оценка должна отражать взаимодействие пользователей, терминалов и приложений через общую память и цепочку логики выполнения.

Такой уровень проверки сложен, особенно при работе с приложениями, написанными десятилетия назад и поддерживаемыми несколькими командами на протяжении длительного времени. Программы часто используют неструктурированный поток управления, динамическое использование запятых и повторно используемые идентификаторы программ, что затрудняет понимание того, где начинается и заканчивается авторизация.

Анализ исходного потока COBOL-CICS для определения границ доверия

В современных прикладных средах границы доверия обычно определяются уровнями, например, между интерфейсом пользователя и API. В CICS границы доверия часто неявные и скрыты внутри связей программ. Статический анализ должен отслеживать, какие программы передают управление другим, где в систему поступают входные данные и является ли источник этих данных доверенным.

Например, цепочка, начинающаяся с транзакции входа в систему, может передавать управление через пять или более программ. Если одна из этих программ принимает новый пользовательский ввод (например, через обновлённый сегмент с коммарт-областью) без его повторной проверки, граница доверия нарушается. Статический анализ должен отмечать такие точки перехода для проверки.

Важнейшие аспекты, которые следует изучить, включают:

Точки входа, через которые внешние данные попадают на путь выполнения
Вызовы LINK или XCTL, которые происходят без проверки вызывающего абонента
Области, в которых выполнение переключается с аутентифицированного на неаутентифицированный поток

Обнаружение жестко запрограммированных учетных данных и логики эскалации полномочий

В процессе быстрой разработки или экстренного обновления иногда вводятся жёстко запрограммированные токены безопасности, идентификаторы пользователей или APPLID. Эти значения могут переопределять стандартные средства контроля доступа или обеспечивать резервный доступ в случае сбоя реальной аутентификации.

Например, сегмент COBOL вроде:

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

На первый взгляд может показаться, что это не опасно, но если USER-ID может быть подвергнут внешнему влиянию или повторно использован в других программах, это создает постоянный риск.

Системы статического анализа должны искать:

Значения, чувствительные к безопасности, в операторах IF или назначениях
Флаги полномочий, которые устанавливаются напрямую, без проверки
Использование универсальных идентификаторов приложений или имен пользователей, обходящих логику управления

Эти закономерности малозаметны, но их наличие часто сигнализирует о более серьёзных проблемах проектирования, где логика безопасности переплетается с бизнес-правилами. Выделение их с помощью статического анализа помогает командам безопасно рефакторить код, не используя скрытые пути доступа.

Область статического анализа в среде CICS

Системы CICS существенно отличаются от традиционных стеков приложений. В то время как современные сервисы предоставляют API и потоки, управляемые событиями, приложения CICS часто выполняются как тесно связанные цепочки программ, которые используют данные, передаваемые через области с коммами, терминальный ввод и общую память. Такая архитектура делает статический анализ особенно сложным. Аналитики не просто ищут известные уязвимые вызовы, но и должны реконструировать поток выполнения в нескольких программах, некоторые из которых могут охватывать десятилетия устаревшей разработки.

Полноценный статический анализ должен учитывать, как данные попадают в систему, как управление передаётся от одного модуля к другому и где ожидается, но отсутствует валидация. Нарушения безопасности в CICS не всегда возникают из-за явно опасных вызовов. Чаще всего они возникают из-за неучтённых предположений о доверии, отсутствия контекстных проверок или несоответствий разрешений, возникающих во вложенных или отложенных потоках выполнения.

Анализ исходного потока COBOL-CICS для определения границ доверия

Типичная транзакция COBOL-CICS не состоит из одного монолитного блока. Она часто охватывает несколько программ, связанных EXEC CICS LINK, XCTL или RETURN, используя блоки commarea для обмена данными между собой. Многие программы не выполняют самостоятельную проверку содержимого полученных ими 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источник и пометить весь нижестоящий код, который использует его для принятия конфиденциальных решений без повторной проверки.

К типичным нарушениям границ доверия, обнаруживаемым при статическом сканировании, относятся:

Ветви решений на основе полей коммэри без локальной аутентификации
Выполнение логики, обусловленной значениями терминала или APPLID
Использование EIBTRMID, EIBTASKN или EIBRESP в логике управления без проверки происхождения
Отсутствие повторной проверки сеанса пользователя при повторном входе в псевдодиалоговую цепочку

Обнаружение жестко запрограммированных учетных данных и логики эскалации полномочий

Статические проверки часто выявляют жёстко закодированные идентификаторы пользователей, специальные коды или идентификаторы APPLID, встроенные непосредственно в операторы COBOL. Хотя они могли быть добавлены для внутреннего тестирования или в качестве обходных решений, они часто остаются в производственной среде и представляют серьёзные риски.

Вот примеры реальных шаблонов, которые часто отмечаются:

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

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

Это создает неконтролируемые пути к повышению уровня доступа. Если злоумышленник получит доступ к терминалу или обнаружит жестко запрограммированный идентификатор пользователя, остальная часть приложения может вести себя так, как будто была выполнена полная аутентификация.

Более тонкий пример:

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

Если эта логика не удалена или не защищена, то специально созданный входной сигнал может активировать функции, раскрывающие журналы, указатели файлов или диагностику памяти, не предназначенные для обычных пользователей.

При создании статических правил для обнаружения таких недостатков обратите внимание на:

IF or EVALUATE операторы, использующие жестко закодированные литеральные значения, привязанные к пользователям или терминалам
Прямое сопоставление жестко запрограммированных учетных данных с флагами доступа
Флаги, такие как BYPASS, OVERRIDE или DEBUG которые запускают условную логику
Разделы кода защищены только поверхностными проверками имени пользователя или идентификатора терминала

Во многих случаях эти проверки были добавлены неформально и никогда не проверялись. Статическое сканирование должно помечать их для ручной проверки или активировать оповещения на основе шаблонов при повторяющихся злоупотреблениях.

Расширяя возможности статического анализа для охвата этих граничных условий и жестко запрограммированных откатов, аудиторы и инженеры по безопасности могут лучше понять, где приложения CICS могут нарушить цепочку доверия — даже если остальная часть системы, кажется, функционирует безопасно.

Шаблоны структуры кода, указывающие на риск безопасности

Хотя отдельные команды CICS могут казаться безопасными по отдельности, окружающая их структура программной логики часто определяет, действительно ли транзакция защищена. Статический анализ должен выходить за рамки построчного сканирования, чтобы понять, как взаимодействуют программы, как определяются разрешения и где в поток управления встроено неявное доверие.

Устаревшие системы особенно подвержены этим паттернам. Со временем команды разработчиков внедряют временную логику, сокращения привилегий и многоцелевые транзакции, которые размывают разделение задач. Выявление этих структурных антипаттернов крайне важно для повышения безопасности транзакций.

Сопоставление транзакций с программами с повышенными разрешениями

Каждый идентификатор транзакции CICS обычно сопоставлен с конкретной программой или процедурой диспетчеризации. Однако многие системы повторно используют коды транзакций в разных модулях или назначают обработчики общих программ, которые могут выполнять несколько конфиденциальных функций в зависимости от ввода пользователя.

Это становится опасным, когда универсальный обработчик привязан к высокопривилегированной транзакции без адекватной фильтрации. Статический анализ должен отслеживать, какие идентификаторы транзакций соответствуют тем или иным программам, и определять логику, которую каждая программа выполняет в контексте этой транзакции.

Пример:

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 и расставить приоритеты по устранению проблем на основе потенциального воздействия.

Статическое обнаружение злоупотреблений API, специфичных для CICS

CICS предоставляет широкий спектр команд и макросов EXEC, взаимодействующих с ресурсами системного уровня. К ним относятся идентификаторы терминалов, номера задач, память сеансов и логика маршрутизации транзакций. Хотя эти функции обеспечивают гибкость, они также могут создавать уязвимости при использовании без достаточных мер безопасности. Неправильное использование этих интерфейсов может привести к непреднамеренному повышению привилегий, обходу средств управления или доступу к несанкционированным областям системы.

Статический анализ позволяет разработчикам и аудиторам выявлять такие риски, анализируя, как вызываются эти API, какие параметры они используют и обеспечивает ли контекст вызова адекватную проверку. Для правильной реализации требуется тщательный анализ контекста выполнения, шаблонов доступа и границ потоков данных между транзакциями.

Отслеживание небезопасного использования EXEC CICS ASSIGN и ADDRESS

ASSIGN и ADDRESS Команды предоставляют прямой доступ к внутренним структурам CICS. Это включает критически важные метаданные, такие как идентификаторы терминалов, идентификаторы приложений и области памяти, специфичные для задач. Хотя эти значения часто используются для журналирования или отслеживания сеансов, они становятся опасными, когда логика управления зависит от них при принятии решений по безопасности.

Возьмите этот пример:

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

Здесь контроль доступа напрямую привязан к идентификатору терминала. Пользователь, знающий его значение или имеющий возможность подделать настройки терминала, может воспользоваться этой логикой для обхода механизмов безопасности.

Или рассмотрите вариант, включающий ADDRESS:

EXEC CICS ADDRESS EIBTASKN
MOVE EIBTASKN TO TRACE-BUFFER

В отрыве от всего этого это кажется безвредным. Однако если EIBTASKN используется позднее для аутентификации или авторизации транзакций, это создает риск предсказуемости и несанкционированной импровизации сеанса.

К распространенным показателям небезопасного использования ASSIGN и ADDRESS относятся:

Управление ветвями исключительно на основе идентификатора терминала, APPLID или номера задачи
Прямое использование назначенных значений для проверки доступа или обхода флагов
Ссылки указателей без структурной проверки после команд ADDRESS
Жестко закодированные значения в сравнении с системно назначенными идентификаторами в условиях IF

Статические инструменты сканирования должны быть настроены на отметку таких условий, особенно когда назначенные данные влияют на маршрутизацию программ или логику привилегий.

Вмешательство в поток транзакций с помощью альтернативных путей выполнения

Во многих приложениях CICS для повышения отказоустойчивости используется резервная или альтернативная маршрутизация транзакций. К сожалению, эти альтернативные пути могут не иметь надлежащей проверки доступа или быть доступны в непредусмотренных условиях. Это создаёт возможности для злоумышленников активировать конфиденциальную логику вне обычного потока транзакций.

Рассмотрим этот случай:

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

Этот код перенаправляет выполнение, если не была передана запятая. Но RETRYTX Возможно, он предназначен для использования только в доверенных последовательностях. Если он не обеспечивает собственную проверку, пользователь может получить доступ к конфиденциальным функциям, просто запустив транзакцию нулевой длины.

Другой пример — молчаливая эскалация:

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

If ALTID сопоставляется с транзакцией с большими привилегиями или более широкой функциональностью и не содержит проверки ролей, этот откат приводит к непреднамеренному доступу.

Риски здесь обычно возникают из-за:

Использование START, XCTL или LINK для переключения программ в зависимости от состояний ошибок
Идентификаторы программ, которые повторно используются в нескольких кодах транзакций
Логика RETURN, которая откладывает проверку нижестоящим модулям
Значения Commarea, определяющие поток без проверки целостности

Статический анализ должен построить полный граф транзакций для выявления программ с несколькими путями входа и выделения тех, которые получают управление после неполной проверки. Даже если функции кажутся изолированными, скрытые потоки могут позволить злоумышленникам запускать привилегированные операции вне ожидаемого использования.

Обработка сложной обфускации логики безопасности

Одним из самых сложных аспектов защиты устаревших 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 Возможно, он не инициализирован или подделан. Вторая программа доверяет сеансу, основываясь только на переменной, без повторной проверки учётных данных.

Статический анализ должен отслеживать назначения переменных при переходах программы, особенно:

Когда одна программа устанавливает флаг, который другая программа считывает для принятия решений о доступе
Когда логика авторизации существует вне логики аутентификации
Когда программы можно запускать напрямую и обходить обычную проверку ввода

Эти шаблоны чрезвычайно распространены в устаревших проектах и часто упускаются при ручном анализе.

Перенаправление потока управления через внутренние отладочные или тестовые режимы

Разработчики иногда включают скрытые флаги или режимы отладки для упрощения тестирования. Если эти функции не удаляются перед развертыванием или доступны с рабочих терминалов, они могут стать лазейкой для доступа к конфиденциальным частям приложения.

Пример:

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

Или более тонко:

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

Во втором случае процедура, выполняемая после окончания рабочего дня, может обходить некоторые стандартные проверки безопасности, возможно, предназначенные для пакетных заданий или экстренного реагирования. Однако, если её можно запустить из интерактивного сеанса, она открывает вектор атаки, основанный на времени.

При сканировании на наличие запутанной или рискованной логики статический анализ должен уделять первоочередное внимание:

Необычные условия, управляющие логикой безопасности (время суток, идентификатор терминала, код региона)
Такие флаги, как 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 Проследив граф вызовов программы, обнаружил, что управляющий флаг передаётся через непроверенное поле с запятой, и выявил пять других транзакций с доступом к той же записи программы. Ручная трассировка не выявила этого.

Обнаружение скрытых флагов управления и запутанных путей доступа

Многие устаревшие программы содержат встроенные условия переопределения или аварийные процедуры. Их часто сложно найти вручную из-за глубокой вложенности, необычного наименования переменных или размещения внутри резервной логики. SMART TS XL использует сканирование на основе правил и сопоставления с шаблонами для извлечения:

Условные переходы, управляемые редко используемыми значениями флагов
Логика запускается на основе идентификатора терминала, времени суток или метаданных задачи
Обход ветвлений с помощью флагов-компиляров, жестко запрограммированных идентификаторов пользователей или процедур на уровне макросов

Он отображает все случаи потенциально привилегированных точек принятия решений и ранжирует их по достижимости, подверженности транзакциям и потенциалу эскалации привилегий.

Автоматизированные правила уязвимостей для конструкций CICS

В отличие от сканеров поверхностного уровня, SMART TS XL Включает встроенные правила, адаптированные для программ COBOL-CICS. Они выявляют уязвимости, связанные с:

Небезопасное использование EXEC CICS ASSIGN и ADDRESS
Непоследовательная логика доступа в выполняемых процедурах
Отсутствует проверка перед командами WRITE, DELETE или START
Устаревшие псевдоразговорные потоки со слабым управлением состоянием

Эти правила можно настраивать с учётом особенностей окружающей среды, бизнес-функции или критериев аудита. Они особенно полезны для выявления ложных предположений, оставленных старыми командами разработчиков.

Ускоренное восстановление с отслеживанием последствий

После того, как уязвимость обнаружена, ее устранение можно ускорить с помощью SMART TS XLВозможности трассировки. Для любой логической ветви или функции программы она может показать:

Все транзакции, которые к этому ведут
Все вызываемые им модули
Все переменные, от которых это зависит
Любая логика доступа, которую он обходит

Эта карта трассировки помогает разработчикам и аудиторам сразу определить, является ли уязвимость изолированной или системно выявленной. Она также сокращает время, затрачиваемое на ручное сопоставление зависимостей, и снижает риск появления новых ошибок при установке исправлений.

Заключение и дальнейшие шаги по проверке безопасности

Устаревшие CICS-приложения содержат критически важную бизнес-логику, но их возраст и сложность создают «слепые зоны» безопасности, которые стандартные методы часто пропускают. Статический анализ — надёжный способ обнаружить скрытые риски до того, как ими смогут воспользоваться злоумышленники, особенно когда он нацелен не только на синтаксис или фрагменты кода, но и на более широкий поток управления и предположения о доступе в транзакциях.

В этой статье мы рассмотрели типы недостатков, присущие системам CICS:

Логика авторизации разбросана по слабосвязанным программам
Уязвимые шаблоны команд, такие как ASSIGN и ADDRESS, без проверки
Резервные транзакции и пути отладки, обходящие обычные проверки
Повторно используемые процедуры, предполагающие доверенный ввод данных от вызывающих абонентов

Для организаций, управляющих крупными портфелями CICS, фрагментарный подход к обеспечению безопасности больше невозможен. Современные угрозы могут эксплуатировать один-единственный недостаток, скрытый в сотнях модулей. Статический анализ, применяемый с глубоким пониманием контекста, может выявить эти проблемы до того, как они будут реализованы или подвергнуты аудиту.

Вот основные действия, которые следует рассмотреть в качестве следующих шагов:

Создайте полную карту транзакций-программ, включая все пути XCTL и LINK
Определите и реорганизуйте любую общую бизнес-логику, которая выполняет привилегированные операции.
Аудит всех ветвей, на которые влияют флаги коммэри или решения на основе терминала
Установить проверку безопасности на входе каждой транзакции
Проверьте логику отступления и пути экстренного реагирования на непреднамеренное воздействие.

Для команд, стремящихся ускорить этот процесс и сократить ручную работу, такие инструменты, как SMART TS XL обеспечивают статический анализ, адаптированный для архитектуры CICS, что позволяет проводить безопасный рефакторинг с полной прослеживаемостью потока.

Защита мэйнфреймовых сред требует не только бдительности, но и контроля. И статический анализ — один из немногих методов, обеспечивающих и то, и другое.