Моделирование процесса аудита безопасности в соответствии с ГОСТ Р 56545 2015 (нотация BPMN)

Содержание

Введение

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

Актуальность темы обусловлена необходимостью формализации и стандартизации процесса аудита в соответствии с действующим российским законодательством. ГОСТ Р 56545-2015 устанавливает требования к порядку проведения аудита безопасности, однако на практике этот процесс часто носит хаотичный характер, слабо структурирован и во многом зависит от субъективного опыта исполнителей. Применение нотации BPMN позволяет наглядно описать процесс, выявить его узкие места и повысить контролируемость проведения аудита. Проблематика исследования заключается в противоречии между требованиями стандарта, предъявляемыми к процедуре аудита, и реальной практикой его проведения, а также в отсутствии формализованных моделей, которые могли бы служить методической основой для внедрения ГОСТ Р 56545-2015 в деятельность организаций.

Объектом исследования являются процессы аудита информационной безопасности, осуществляемые в организациях в условиях действия российских стандартов. Предметом исследования выступает моделирование процесса аудита безопасности на основе требований ГОСТ Р 56545-2015 с использованием нотации BPMN 2.0.

Цель работы — разработать модель процесса аудита безопасности в соответствии с ГОСТ Р 56545-2015, выраженную в нотации BPMN, позволяющую упорядочить и стандартизировать процедуру аудита. Для достижения поставленной цели необходимо решить следующие задачи:

- изучить теоретические основы аудита информационной безопасности и требования российских стандартов, включая ГОСТ Р 56545-2015;<br>- проанализировать возможности нотации BPMN для описания процессов;<br>- исследовать типичный процесс аудита «как есть» (AS-IS) и выявить его недостатки;<br>- разработать целевую модель «как должно быть» (TO-BE) с интеграцией требований стандарта;<br>- сформулировать практические рекомендации по применению разработанной модели.

При выполнении работы применяются такие методы, как системный анализ, сравнительный анализ нормативных документов, классификация, обобщение и моделирование бизнес-процессов. Информационную базу исследования составляют современные научные публикации по вопросам информационной безопасности, учебные пособия по моделированию бизнес-процессов, а также действующие нормативные акты и стандарты, в том числе ГОСТ Р 56545-2015. Использование совокупности перечисленных методов и источников позволяет обеспечить достоверность результатов исследования и их практическую значимость для специалистов в области информационной безопасности.

Теоретические основы управления процессом аудита информационной безопасности

Понятие и виды аудита информационной безопасности (комплаенс-аудит, технический аудит, тест на проникновение). Обзор российских стандартов (ФСТЭК, ФСБ, Банк России)

В современных условиях обеспечение информационной безопасности (ИБ) является одной из приоритетных задач для организаций всех форм собственности. Эффективное управление защищённостью невозможно без объективной оценки текущего состояния системы защиты, что достигается посредством проведения аудита информационной безопасности. Под аудитом ИБ понимается систематический процесс сбора и анализа информации о состоянии защищённости объекта, его соответствии установленным требованиям, а также выработки обоснованных рекомендаций по повышению уровня безопасности [16]. Данный процесс носит регулярный характер и опирается на формализованные методики, что отличает его от разовых проверок, проводимых без чётко заданных критериев оценки. Аудит может осуществляться как собственными силами организации, так и с привлечением внешних консультантов, что обеспечивает независимость и объективность результатов.

Аудит занимает важное место в системе управления информационной безопасностью организации. Он обеспечивает обратную связь между реализуемыми мерами защиты и целями управления, позволяя своевременно выявлять отклонения и корректировать стратегию защиты. Основными целями аудита являются проверка соответствия деятельности организации требованиям нормативных документов, выявление уязвимостей и недостатков в конфигурации средств защиты, оценка рисков, связанных с возможными инцидентами, а также контроль эффективности принимаемых мер. Результаты аудита служат основой для принятия управленческих решений, направленных на совершенствование системы ИБ [2]. При этом важно понимать, что аудит не сводится к разовой фиксации недостатков: он предполагает формирование долгосрочной программы повышения уровня защищённости.

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

Комплаенс-аудит, как правило, проводится в форме документарной проверки. Его объектами выступают организационно-распорядительная документация, регламенты, политики безопасности, а также фактические процедуры, обеспечивающие выполнение требований. Источниками требований для комплаенс-аудита являются федеральные законы, нормативные акты регуляторов, национальные стандарты, такие как ГОСТ Р 56545-2015, и внутренние положения организации. В ходе проверки оценивается полнота и актуальность документации, распределение обязанностей между сотрудниками, а также соблюдение установленных процедур при обработке информации. Особое внимание уделяется наличию формализованных процессов управления доступом, реагирования на инциденты и контроля изменений в информационной инфраструктуре.

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

Особое место в системе видов аудита занимает тест на проникновение (пентест), который относится к активным методам оценки защищённости. В ходе пентеста имитируются действия реального нарушителя, стремящегося получить несанкционированный доступ к информационным ресурсам. Проведение теста включает такие этапы, как сбор информации, анализ уязвимостей, эксплуатация выявленных недостатков, закрепление в системе и подготовка отчёта. В зависимости от степени осведомлённости исполнителя о внутреннем устройстве объекта различают методы black box, white box и grey box. При black box исполнитель не имеет информации о системе, при white box ему предоставляется полная документация и доступ к исходным кодам, grey box занимает промежуточное положение. Проведение пентеста требует строгого соблюдения правовых рамок и согласования с владельцем системы, поскольку активные действия могут повлиять на доступность сервисов [10]. Поэтому до начала испытаний заключаются соответствующие соглашения, а границы тестирования фиксируются в техническом задании.

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

В Российской Федерации деятельность по аудиту информационной безопасности регулируется комплексом нормативных правовых актов и методических документов, разрабатываемых несколькими ключевыми регуляторами, каждый из которых осуществляет функции в соответствии со своей компетенцией. Система такого регулирования имеет многоуровневый характер и охватывает как требования к защите информации ограниченного доступа, так и отраслевые стандарты для отдельных секторов экономики. Основными регуляторами в этой области выступают Федеральная служба по техническому и экспортному контролю (ФСТЭК России), Федеральная служба безопасности Российской Федерации (ФСБ России) и Центральный банк Российской Федерации (Банк России). Для корректного планирования и проведения аудита необходимо учитывать требования всех перечисленных органов, поскольку каждый из них устанавливает обязательные нормы в отношении различных аспектов обеспечения информационной безопасности.

ФСТЭК России является уполномоченным органом в области противодействия техническим разведкам и технической защиты информации. Деятельность этой службы сосредоточена на формировании требований по защите информации ограниченного доступа, не содержащей сведений, составляющих государственную тайну. В частности, речь идёт о персональных данных, информации, обрабатываемой в государственных информационных системах, а также о значимых объектах критической информационной инфраструктуры. Приказом ФСТЭК России от 11 февраля 2013 г. № 17 утверждены требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах. Кроме того, служба разрабатывает методические документы по технической защите информации, которые активно используются аудиторами при проведении инструментальных проверок и оценке эффективности принятых мер защиты. Важной функцией ФСТЭК является аттестация объектов информатизации на соответствие требованиям по защите информации. Процедура аттестации предполагает проведение комплекса контрольных мероприятий, результаты которых оформляются в виде аттестата соответствия. Для аудитора наличие такого аттестата служит одним из ключевых свидетельств того, что объект соответствует установленным нормам. Также ФСТЭК осуществляет сертификацию средств защиты информации, что определяет возможность их применения для защиты конфиденциальных данных. В ходе аудита проверяется наличие действующих сертификатов на используемые программные и аппаратные средства защиты, что является обязательным условием для многих категорий информационных систем. Таким образом, требования ФСТЭК формируют нормативную базу для оценки организационных и технических мер защиты, применяемых в организациях различного профиля [22].

ФСБ России в сфере информационной безопасности выполняет функции, связанные с обеспечением безопасности информации в условиях угроз военного характера, а также регулирует использование криптографических средств защиты. Деятельность службы регламентируется Федеральным законом «О федеральной службе безопасности» и рядом подзаконных нормативных актов. В ведении ФСБ находятся вопросы лицензирования деятельности по разработке, производству, распространению шифровальных (криптографических) средств, а также контроль за их использованием. Для организаций, обрабатывающих информацию, составляющую государственную тайну, или использующих криптографию для защиты конфиденциальных сведений, особое значение имеют требования ФСБ к порядку применения средств криптографической защиты информации (СКЗИ). Аудит таких объектов должен включать проверку соблюдения установленных правил эксплуатации СКЗИ, наличия необходимых лицензий у организации (если она осуществляет деятельность, подлежащую лицензированию) и выполнения предписаний по обращению с ключевыми документами. Кроме того, ФСБ определяет требования к обеспечению безопасности информации при использовании усиленной электронной подписи. С 1 июля 2021 года действует ГОСТ Р 34.10-2012, устанавливающий алгоритмы формирования и проверки электронной подписи, однако контроль за соблюдением требований к средствам электронной подписи также осуществляется ФСБ. В контексте аудита важно учитывать, что криптографическая защита данных во многих организациях является обязательным условием выполнения требований законодательства, поэтому оценка корректности применения СКЗИ входит в состав как комплаенс-аудита, так и технического аудита. Помимо этого, ФСБ участвует в формировании перечня угроз безопасности информации, используемого при моделировании угроз и оценке рисков. Учёт угроз военного характера необходим для выбора адекватных мер защиты, что особенно актуально для объектов критической информационной инфраструктуры [11].

Банк России осуществляет регулирование в финансовой сфере и устанавливает обязательные требования к обеспечению информационной безопасности для кредитных организаций и иных участников финансового рынка. Основу такого регулирования составляет ГОСТ Р 57580.1-2017 «Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер», а также нормативные акты Банка России, определяющие порядок управления рисками информационной безопасности и реагирования на компьютерные атаки. В частности, Положение Банка России от 17 апреля 2019 г. № 683-П устанавливает требования к обеспечению защиты информации при осуществлении переводов денежных средств. Аудит финансовых организаций предполагает проверку соответствия их систем защиты данному стандарту и нормативным требованиям. Банк России также разрабатывает методические рекомендации по выявлению инцидентов информационной безопасности, что позволяет аудиторам использовать единую методологию при оценке эффективности реагирования на компьютерные атаки. Для кредитных организаций обязательным является создание системы мониторинга и оперативного реагирования на инциденты, а также проведение регулярного тестирования на проникновение с целью оценки устойчивости к реальным атакам. Специфика требований Банка России заключается в их практической ориентированности на обеспечение непрерывности финансовых операций и минимизацию рисков, связанных с мошенничеством и хищением средств. При планировании аудита организаций банковской сферы необходимо учитывать, что помимо общероссийских стандартов ФСТЭК и ФСБ, они обязаны соблюдать отраслевые требования, что существенно расширяет перечень проверяемых контрольных точек.

Сопоставляя сферы применения и характер требований перечисленных регуляторов, можно отметить, что ФСТЭК России в первую очередь ориентирована на защиту информации ограниченного доступа в государственных информационных системах и системах общего пользования, ФСБ России — на криптографическую защиту и обеспечение безопасности в условиях военных угроз, а Банк России — на защиту информации в финансовых организациях. Различия касаются также объектов регулирования: если ФСТЭК охватывает широкий круг организаций, работающих с персональными данными и государственными информационными системами, то ФСБ сосредоточена на специальных субъектах, использующих шифровальные средства, а Банк России действует в пределах финансового сектора. При этом все три регулятора предъявляют требования как к организационным, так и к техническим мерам защиты, однако акценты распределяются по-разному. Для аудитора это означает необходимость формирования комплексного подхода, учитывающего все применимые нормативные документы в зависимости от специфики деятельности проверяемой организации. Игнорирование требований хотя бы одного из регуляторов может привести к неполной оценке состояния защищённости и, как следствие, к ошибочным выводам и рекомендациям. Поэтому на этапе планирования аудита важно провести анализ применимых требований и составить перечень нормативных актов, подлежащих проверке, что особенно актуально в процессе построения модели аудита.

Рассмотренные виды аудита — комплаенс-аудит, технический аудит и тест на проникновение — имеют непосредственную связь с требованиями российских стандартов. Комплаенс-аудит базируется на проверке соответствия деятельности организации требованиям ФСТЭК, ФСБ и Банка России, что предполагает формализованную процедуру сбора и анализа документов. Технический аудит опирается на методические документы, разработанные теми же регуляторами, и предполагает инструментальную проверку с использованием сертифицированных средств контроля защищённости. Тест на проникновение, в свою очередь, во многом основывается на требованиях Банка России к проведению регулярных оценок устойчивости информационных систем, а также на методиках ФСТЭК по выявлению уязвимостей. Применение процессного подхода, заложенного в ГОСТ Р 56545-2015 «Защита информации. Аудит информационной безопасности. Требования», позволяет интегрировать все перечисленные виды аудита в единую модель, где каждый этап процесса чётко определён, распределены роли и ответственность участников, а также установлены критерии оценки результатов. Стандарт ГОСТ Р 56545-2015, разработанный с учётом международных практик, но адаптированный к российской нормативной базе, определяет общие требования к организации и проведению аудита информационной безопасности. Он задаёт последовательность процедур: от планирования аудита до оформления отчёта, при этом учитывает необходимость применения требований регуляторов на каждом этапе. Таким образом, использование ГОСТ Р 56545-2015 в сочетании с требованиями ФСТЭК, ФСБ и Банка России образует методологическую основу для построения эффективной модели процесса аудита, которая может быть визуализирована с помощью нотации BPMN 2.0 и в дальнейшем использована для оптимизации деятельности службы внутреннего аудита информационной безопасности организации.

Обобщая изложенное, можно констатировать, что аудит информационной безопасности представляет собой комплексную организационно-техническую процедуру, требующую сочетания комплаенс-, технических и активных методов проверки, а также опоры на действующую нормативно-методическую базу. Специфика российского регулирования состоит в наличии нескольких регуляторов, каждый из которых устанавливает собственные требования, однако их совместное выполнение является обязательным для большинства организаций. Понимание границ компетенции ФСТЭК, ФСБ и Банка России позволяет аудитору корректно формировать программу проверки, выбирать адекватные методы и инструменты, а также интерпретировать полученные результаты. В свою очередь, процессный подход, реализованный в ГОСТ Р 56545-2015, даёт возможность структурировать аудит как последовательность взаимосвязанных процедур, что создаёт предпосылки для построения формализованной модели процесса средствами нотации BPMN. Такая модель становится инструментом управления процессом аудита, позволяя наглядно отображать роли участников, логику выполнения работ и контрольные события, что в итоге повышает качество и результативность аудита информационной безопасности.

Анализ требований ГОСТ Р 56545-2015

Построение эффективной модели аудита информационной безопасности невозможно без опоры на национальные стандарты, определяющие единые подходы к организации и проведению проверочных мероприятий. В условиях активного развития отечественного законодательства в области защиты информации и ужесточения требований регуляторов именно стандартизированные методики позволяют обеспечить сопоставимость результатов аудита, их объективность и юридическую значимость. Среди действующих нормативных документов особое место занимает ГОСТ Р 56545-2015 «Защита информации. Аудит информационной безопасности. Требования», который устанавливает общие требования к организации и проведению аудита безопасности информационных систем. Данный стандарт входит в систему национальных стандартов в области защиты информации, разработанных с учётом международной практики и адаптированных к российским условиям. Он органично связан с процессами управления информационной безопасностью, поскольку определяет порядок выявления, анализа и документирования уязвимостей, что является неотъемлемой частью аудиторской деятельности при оценке защищённости объектов информатизации [4].

Общая структура ГОСТ Р 56545-2015 включает несколько ключевых разделов, последовательно раскрывающих процедуру проведения аудита. В области применения стандарта определены объекты, на которые распространяются его требования, а также основные термины и определения, используемые в документе. Важно отметить, что стандарт вводит понятийный аппарат, гармонизированный с другими национальными стандартами, такими как ГОСТ Р ИСО/МЭК 27001, что обеспечивает терминологическую целостность. Терминологический аппарат стандарта оперирует такими понятиями, как «аудит безопасности», «уязвимость», «событие безопасности», «объект аудита», «критерии аудита». Основные разделы стандарта посвящены организации процесса аудита: от планирования и определения целей до формирования заключения и отчёта. Кроме того, значительное внимание уделено методам сбора и анализа информации об уязвимостях, а также требованиям к оформлению результатов проверки. Такая структура позволяет рассматривать стандарт как комплексный документ, регламентирующий все этапы аудиторской деятельности.

Ключевые требования стандарта к процессу аудита носят системный характер и направлены на обеспечение полноты и достоверности результатов. Прежде всего, стандарт требует чёткого определения целей аудита, которые должны быть согласованы с руководством проверяемой организации и отражать реальные потребности в оценке защищённости. Границы аудита устанавливаются таким образом, чтобы охватить все критически важные компоненты информационной системы, включая аппаратное обеспечение, программное обеспечение, каналы связи и персонал. Критерии аудита формируются на основе требований действующих нормативных документов, политик безопасности организации и принятых отраслевых стандартов. Процедуры аудита должны быть спланированы заранее, при этом план проверки включает перечень работ, сроки их выполнения, распределение ресурсов и порядок взаимодействия между участниками. В ходе сбора доказательств аудитор обязан применять не только автоматизированные средства анализа уязвимостей, но и методы экспертной оценки, интервьюирования сотрудников и анализа эксплуатационной документации. Полученные доказательства фиксируются в рабочих документах, которые служат основой для составления итогового отчёта. Документирование результатов аудита осуществляется в соответствии с требованиями стандарта, что обеспечивает возможность последующего контроля качества и повторного использования полученных данных [25].

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

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

Проведённый в первой части раздела анализ требований ГОСТ Р 56545-2015 позволяет перейти к их сопоставлению с положениями смежных нормативных документов и сложившейся практикой проведения аудита информационной безопасности в российских организациях. Такое сопоставление важно не только для уяснения места стандарта в общей системе регуляторных требований, но и для корректного использования его положений при построении процессной модели. Прежде всего, ГОСТ Р 56545-2015 содержательно связан с ГОСТ Р ИСО/МЭК 27001-2021 и ГОСТ Р ИСО/МЭК 27002-2021, которые устанавливают требования к системе менеджмента информационной безопасности и практическим правилам управления рисками. Если стандарты серии 27000 задают общую логику функционирования системы менеджмента ИБ, то ГОСТ Р 56545-2015 конкретизирует процедуру проверки соответствия этой системы установленным требованиям, то есть выступает методической основой для проведения аудита. Аналогичная связь прослеживается с ГОСТ Р ИСО 19011-2021, регламентирующим общие требования к компетентности аудиторов и проведению аудита систем менеджмента. Однако в отличие от универсального ИСО 19011, ГОСТ Р 56545-2015 адаптирует общие принципы применительно к предметной области безопасности информации, акцентируя внимание на объектах аудита в виде информационных систем, средств защиты информации и организационно-распорядительной документации. На практическом уровне это означает, что при разработке модели аудита следует учитывать требования сразу нескольких стандартов, обеспечивая их непротиворечивость и взаимодополняемость. Так, программа аудита, формируемая по ГОСТ Р 56545-2015, должна согласовываться с внутренними политиками ИБ, построенными на базе ГОСТ Р ИСО/МЭК 27001, а применяемые методы сбора доказательств — корреспондировать с подходами ФСТЭК России к оценке эффективности принятых мер защиты информации [13]. Кроме того, для организаций кредитно-финансовой сферы необходимо учитывать требования Банка России, в частности ГОСТ Р 57580.1-2017, который устанавливает требования к защите информации при осуществлении банковской деятельности. Указанное обстоятельство вносит определённую сложность в практику аудита, поскольку одна и та же процедура проверки может одновременно подпадать под действие нескольких нормативных актов, предъявляющих не всегда совпадающие требования к составу проверяемых мер, периодичности контроля и формам отчётности. Вместе с тем ГОСТ Р 56545-2015 следует рассматривать как базовый, наиболее общий регламент, который может конкретизироваться отраслевыми стандартами и внутренними документами организации.

С точки зрения применения стандарта при моделировании процесса в нотации BPMN, необходимо выделить два уровня требований: обязательные для отражения в модели и вариативные, зависящие от контекста конкретного аудита. К числу обязательных элементов относятся этапы жизненного цикла аудита, последовательность которых прямо вытекает из структуры стандарта. В модели должны присутствовать стартовое событие «Инициация аудита», последующие задачи по формированию программы аудита, уведомлению проверяемой организации, проведению анализа документов, выполнению проверок на объекте, сбору доказательств, подготовке заключения и итогового отчёта. Каждый из этих этапов целесообразно отображать в виде отдельной задачи ручного или автоматического выполнения, а точки принятия решений — через шлюзы. Например, решение о готовности аудиторской группы к проведению проверки на объекте может быть представлено эксклюзивным шлюзом, направляющим поток в зависимости от полноты собранных предварительных доказательств. Обязательным для отражения является также граничное событие-ошибка, поскольку стандарт предусматривает возможность возникновения нештатных ситуаций, связанных с сокрытием информации, отказом объектов аудита от предоставления доступа или обнаружением критических несоответствий, требующих приостановления проверки. Что касается вариативных элементов, то к ним следует отнести глубину детализации отдельных подпроцессов, состав и формат документооборота, а также способы уведомления участников. Стандарт не устанавливает строгих требований к оформлению рабочих документов аудитора, поэтому при моделировании целевого процесса допустимо использование как традиционных бумажных носителей, так и электронных форм, что находит отражение в виде артефактов данных или соответствующих типов задач. Вариативность также проявляется в распределении ответственности: если стандарт определяет роли аудитора и аудиторской группы, то конкретные наименования должностных лиц и подразделений, выполняющих эти роли, зависят от организационной структуры компании и должны фиксироваться в дорожках BPMN-модели. Наконец, вариативным является порядок взаимодействия с проверяемой организацией: в зависимости от степени зрелости процесса ИБ, аудит может проводиться полностью очно, дистанционно или по смешанной схеме, что должно находить отражение в модели через соответствующие шлюзы и условия выполнения задач. Таким образом, ГОСТ Р 56545-2015 задаёт жёсткий каркас процесса аудита, но при этом оставляет разработчику модели достаточную свободу для учёта специфики организации [28].

Вместе с тем следует отметить ряд ограничений и проблемных мест стандарта, которые необходимо принимать во внимание при проектировании модели. Одним из наиболее существенных ограничений является отсутствие жёсткой регламентации форматов отчётности и требований к содержанию отдельных рабочих документов. Стандарт оперирует общими категориями «программа аудита», «отчёт об аудите», «заключение по результатам аудита», но не конкретизирует структуру и состав этих документов. В результате на практике каждая организация вынуждена самостоятельно разрабатывать шаблоны отчётных форм, что приводит к значительному разнообразию подходов и затрудняет автоматизацию процесса. Данное обстоятельство важно учитывать при создании модели TO-BE: целесообразно предусмотреть в модели задачи по разработке и утверждению внутренних регламентов, определяющих структуру отчётности, либо использовать интеграцию со специализированными программными средствами класса GRC. Ещё одной проблемой является необходимость адаптации требований стандарта к конкретной организационной структуре предприятия. В стандарте предполагается наличие выделенной аудиторской группы и независимых аудиторов, однако во многих российских компаниях функция внутреннего аудита ИБ совмещается с другими должностными обязанностями специалистов по информационной безопасности. В таких условиях формальное следование требованиям стандарта невозможно без предварительной организационной проработки, поэтому в модели процесса должны быть предусмотрены процедуры назначения ответственных лиц и разграничения полномочий, а также механизмы контроля независимости аудиторов. Кроме того, стандарт ориентирован преимущественно на проведение плановых аудитов и недостаточно полно раскрывает порядок действий при внеплановых проверках, которые могут быть инициированы по требованию руководства организации или регулятора. При построении модели это означает необходимость добавления дополнительных сценариев, не описанных непосредственно в ГОСТ Р 56545-2015, что расширяет границы моделируемого процесса и требует отдельного согласования с заинтересованными сторонами. Наконец, в стандарте не уделяется достаточного внимания вопросам автоматизации процесса аудита и использованию средств электронного документооборота, что особенно актуально для организаций, стремящихся к построению полностью цифровой модели процесса. Решение этих проблемных вопросов в рамках разработки целевой модели TO-BE достигается за счёт дополнения требований стандарта внутренними нормативными актами и современными инструментальными средствами.

Влияние требований ГОСТ Р 56545-2015 на проектирование целевой модели TO-BE проявляется в определении состава управляющих событий, структуры шлюзов и распределения зон ответственности между участниками процесса. В качестве главного управляющего события модели следует рассматривать «Утверждение программы аудита», которое запускает основной поток работ и служит отправной точкой для установления коммуникации между аудиторской группой и проверяемой организацией. Промежуточное событие «Анализ доказательств» выступает ключевой точкой контроля качества процесса, поскольку именно на данном этапе формируется профессиональное суждение аудитора о степени соответствия объекта аудита предъявляемым требованиям. В модели TO-BE рекомендуется предусмотреть несколько типов шлюзов, позволяющих отразить вариативность развития процесса. Первый шлюз — «Готовность аудиторской группы» — относится к этапу планирования и направляет поток либо на проведение предварительного анализа документов, либо на корректировку программы аудита. Второй шлюз — «Результативность корректирующих действий» — встраивается в контур обратной связи после завершения проверки и позволяет принять решение о повторном аудите или о закрытии объекта аудита. Третий шлюз — «Существенность несоответствий» — помещается непосредственно перед формированием заключения и определяет, будет ли отчёт содержать положительное заключение либо перечень обязательных корректирующих мероприятий. Зоны ответственности участников целевой модели должны строго соответствовать ролям, определённым стандартом: заказчик аудита, аудиторская группа, руководитель аудита и проверяемая организация. Для каждого из этих участников в BPMN-модели создаётся отдельная дорожка, что обеспечивает наглядность процесса и снижает риск дублирования функций. Кроме того, требования стандарта о необходимости обеспечения независимости аудиторов целесообразно отразить в модели через правило, запрещающее назначение аудитора, имеющего прямую административную зависимость от владельца объекта аудита, что формализуется в свойствах задачи и может быть верифицировано при выполнении процесса.

Обобщая результаты проведённого анализа, следует подчеркнуть, что ГОСТ Р 56545-2015 выполняет функцию базового регламента, определяющего логику и содержание процесса аудита информационной безопасности. Его практическая ценность состоит в том, что стандарт упорядочивает процесс, устанавливает однозначные терминологические определения, задаёт последовательность этапов и формулирует требования к компетентности аудиторов, тем самым снижая неопределённость, характерную для неформализованных аудиторских практик. Вместе с тем использование стандарта в качестве единственного источника требований недостаточно для построения полноценной процессной модели в нотации BPMN, поскольку он оставляет открытыми вопросы автоматизации, форматов отчётности, порядка внеплановых проверок и адаптации к конкретной организационной структуре. Поэтому при создании целевой модели TO-BE необходимо разумное сочетание требований ГОСТ Р 56545-2015 с внутренними стандартами предприятия, рекомендациями смежных нормативных документов и возможностями современных программных средств, поддерживающих ведение реестров рисков, документооборота и контрольных процедур. Кроме того, важная роль отводится профессиональному суждению аудитора, которое позволяет интерпретировать общие требования стандарта применительно к уникальным особенностям каждого конкретного объекта аудита [8]. В совокупности это обеспечивает формирование не только формально соответствующей стандарту, но и практически реализуемой модели процесса, способной повысить эффективность аудиторской деятельности и качество защиты информационных ресурсов организации. Дальнейшая детализация модели, выполненная на основе представленного анализа, позволит перейти к разработке целевого процесса и его практической апробации.

Основы графического моделирования процессов. Нотация BPMN 2.0: роли участников (пулы и дорожки), типы событий (стартовые, промежуточные, граничные ошибки), шлюзы принятия решений, задачи ручного и автоматического выполнения, артефакты данных

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

При выборе нотации для моделирования процесса аудита информационной безопасности целесообразно использовать BPMN 2.0, которая стала де-факто стандартом делового моделирования. Данная нотация обладает выразительными средствами для описания как простых последовательных сценариев, так и сложных взаимодействий с множеством участников и альтернативных ветвей. Важным преимуществом BPMN является её понятность как для аналитиков, так и для разработчиков информационных систем, а также наличие формальных правил, позволяющих преобразовывать модели в исполняемые регламенты [17]. Для задач аудита информационной безопасности это особенно важно, поскольку результаты моделирования должны быть однозначно интерпретированы всеми участниками процесса, включая аудиторов, владельцев информационных ресурсов и руководство организации.

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

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

Для отражения логики принятия решений в нотации BPMN используются шлюзы. Эксклюзивный шлюз (XOR) выбирает ровно одну ветвь из нескольких на основе условия, что соответствует ситуациям, когда решение может быть принято только в одну сторону. Инклюзивный шлюз (OR) позволяет выбрать одну или несколько ветвей одновременно, а параллельный шлюз (AND) запускает все ветви без каких-либо условий, что используется для параллельного выполнения независимых операций. При моделировании аудита шлюзы применяются, например, для определения необходимости проведения дополнительных проверок на основе результатов предварительного анализа, выбора объекта аудита или распределения задач между членами аудиторской группы. Шлюзы обеспечивают компактность модели и избавляют от дублирования одинаковых последовательностей операций.

Задачи в BPMN подразделяются на задачи ручного и автоматического выполнения. Задача ручного выполнения предназначена для операций, которые выполняются человеком без использования информационных систем, например, оформление документа в бумажной форме или проведение интервью с сотрудниками. Задача автоматического выполнения предполагает выполнение операции системой без участия человека, например, сбор и анализ логов, сравнение контрольных сумм, формирование автоматических уведомлений. В процессе аудита информационной безопасности сочетание таких задач позволяет отразить как действия аудитора, так и работу специализированных инструментов сканирования и анализа защищённости. Разграничение типов задач важно для оценки трудозатрат, определения необходимости автоматизации и последующей оптимизации процесса [20].

Важным элементом нотации BPMN 2.0, без которого невозможно построение полноценной модели процесса аудита информационной безопасности, являются артефакты данных. Они предназначены для отображения информации, создаваемой, преобразуемой и потребляемой в ходе выполнения процесса. В контексте аудита безопасности объектами данных выступают заявка на проведение аудита, программа аудита, протоколы осмотра, результаты тестирования, промежуточные акты, итоговый отчет, а также планы корректирующих мероприятий. Объект данных изображается в виде прямоугольника с загнутым верхним левым углом и подписью, отражающей его наименование. С помощью стрелок-ассоциаций объект данных связывается с задачами или событиями, причем направление стрелки показывает, является ли объект входным или выходным для данного элемента. Входной объект данных означает, что задача использует информацию, а выходной – что задача создает или модифицирует информацию. Дополнительно в BPMN предусмотрена возможность указания состояния объекта данных, что особенно важно для аудита, поскольку документы проходят стадии черновика, согласования, утверждения и архивации. Например, состояние отчета «Утвержден» принципиально отличается от состояния «В разработке», и это влияет на порядок дальнейших действий.

Наряду с объектами данных в нотации применяются сообщения, которые моделируют обмен информацией между различными пулами или участниками процесса. В отличие от объектов данных, сообщения всегда имеют отправителя и получателя и отображаются в виде конверта. В процессе аудита сообщения используются для уведомления заказчика о начале проверки, запроса дополнительных сведений у подразделений, отправки предварительных результатов и согласования итоговых документов. Хранилища данных представляют собой элементы, обеспечивающие постоянное или временное хранение информации, которая используется несколькими задачами процесса. В аудите хранилищем данных может выступать база данных реестра информационных активов, журнал инцидентов, архив нормативных документов или система управления уязвимостями. Изображение хранилища данных в BPMN напоминает цилиндр, а его название указывает на логическую сущность, а не на конкретную техническую реализацию. Ассоциации, как уже упоминалось, связывают артефакты с элементами диаграммы и уточняют их смысл. Применение артефактов данных позволяет сделать модель аудита наглядной и информационно полной, отражающей входы и выходы каждой операции, а также контролировать полноту документального обеспечения процесса [23].

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

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

Распределение ролей и ответственности между участниками процесса аудита безопасности осуществляется в BPMN с помощью пулов и дорожек. Пул представляет собой организационную границу, которая объединяет действия одного участника или одной системы. Для процесса аудита пулами могут быть «Организация – заказчик аудита», «Аудиторская организация» и, при необходимости, «Внешний регулятор» или «ИТ-инфраструктура». Пул отображается в виде прямоугольника, внутри которого размещаются дорожки – более мелкие горизонтальные полосы, соответствующие конкретным ролям, должностям или функциональным подразделениям. Например, в пуле «Аудиторская организация» могут быть выделены дорожки «Руководитель аудиторской группы», «Аудитор-эксперт», «Технический специалист», а в пуле «Заказчик» – «Представитель руководства», «Владелец информационного актива», «Технический администратор». Назначение задач конкретным дорожкам определяет зону ответственности каждого участника. При этом важно соблюдать правило: каждая задача должна быть размещена на той дорожке, которая соответствует исполнителю, ответственному за ее выполнение. Иными словами, дорожка показывает, кто выполняет работу, а не кто получает ее результат. Передача данных между дорожками осуществляется через потоки сообщений или через объекты данных, а не через перенос задачи на другую дорожку. Некорректное размещение задач может привести к двусмысленности модели и затруднить последующую реализацию процесса. Для формирования правильно структурированной диаграммы необходимо четко определить на этапе проектирования перечень участников и их полномочия на основе реально существующего регламента аудита. Дорожки также позволяют отображать автоматизируемые элементы, помещая их на дорожку соответствующей информационной системы, например «Платформа управления уязвимостями» или «Сервис электронного документооборота». Это дает возможность наглядно разделить ручные и автоматизированные операции и в дальнейшем использовать модель как основу для постановки задачи разработчикам.

При практическом применении BPMN для моделирования процесса аудита безопасности необходимо придерживаться ряда рекомендаций, обеспечивающих полноту и однозначность модели. Прежде всего, следует четко определить границы процесса: его стартовое событие, завершающие события и внешних участников, взаимодействующих с процессом. Начальным событием может быть поступившая заявка на аудит или наступление плановой даты, завершающим – передача утвержденного отчета заказчику или принятие остаточных рисков. Все действия, выполняемые в рамках процесса, должны быть декомпозированы до уровня, понятного всем заинтересованным сторонам, без излишней детализации, способной затруднить чтение диаграммы. Рекомендуется использовать подпроцессы для выделения логически завершенных блоков, таких как «Планирование аудита», «Проведение проверок», «Анализ результатов». Названия задач должны быть сформулированы в форме глагола в неопределенной форме, например «Проверить конфигурацию межсетевого экрана», «Собрать доказательства», «Подготовить отчет». Это повышает однозначность восприятия. Кроме того, необходимо явно указывать условия на исходящих потоках шлюзов, а также моделировать не только основной позитивный сценарий, но и возможные отклонения, возникающие при обнаружении несоответствий или ошибок. Требования полноты означают, что все существенные документы, роли и события, предусмотренные нормативной документацией, в частности ГОСТ Р 56545-2015, должны быть отражены в модели. Для достижения однозначности следует избегать пересечения потоков, лишних ассоциаций и неясных обозначений. При разработке модели важно согласовать ее с экспертами предметной области, чтобы верифицировать соответствие реальной практике аудита.

Несмотря на широкие выразительные возможности, нотация BPMN 2.0 имеет определенные ограничения, которые необходимо учитывать при моделировании сложных процессов аудита безопасности. Прежде всего, BPMN не является языком формальной спецификации данных: объекты данных и хранилища данных не имеют строгой структуры и не позволяют описать форматы документов и их содержимое. Это ограничение преодолевается путем дополнения BPMN-диаграмм реестрами данных, словарями артефактов или связкой с моделями данных, например в нотации ArchiMate или с помощью UML-диаграмм классов. Также BPMN не предоставляет встроенных механизмов для количественной оценки производительности процесса, временных затрат и стоимости. Для имитационного моделирования разработаны расширения BPMN, такие как BPSim, которые позволяют задавать распределения времени выполнения задач и проводить анализ узких мест. Еще одним ограничением является сложность восприятия больших диаграмм: при излишней детализации модель становится трудночитаемой. Решением служит иерархическое моделирование с использованием подпроцессов и многоуровневых диаграмм. Наконец, в BPMN отсутствуют средства для явного представления рисков и угроз информационной безопасности, что важно для аудита. Для учета рисков модель может быть расширена с помощью артефактов, описывающих компенсирующие действия, или дополнена картами рисков [29]. Несмотря на перечисленные ограничения, BPMN остается де-факто стандартом графического моделирования бизнес-процессов, обеспечивающим единый язык общения между аналитиками, специалистами по информационной безопасности и разработчиками.

Проведенное рассмотрение основных элементов нотации BPMN 2.0 – артефактов данных, событий, шлюзов, задач, пулов и дорожек – показывает, что данная нотация обладает достаточной выразительной мощностью для моделирования процесса аудита информационной безопасности в соответствии с требованиями ГОСТ Р 56545-2015. Артефакты данных позволяют отобразить документооборот аудита, включая планы, акты, протоколы и отчеты; граничные события ошибок – корректно обрабатывать сбои и исключительные ситуации; роли и дорожки – однозначно распределить ответственность между участниками. В совокупности эти элементы обеспечивают построение целевой модели TO-BE, которая является наглядным и непротиворечивым представлением регламентированного процесса аудита, пригодным для последующего анализа, оптимизации и внедрения в практику деятельности организации. Разработанная модель может служить основой для автоматизации процесса, разработки регламентов и подготовки персонала, а также для проведения дальнейших исследований в области совершенствования процедур аудита безопасности.

Проектирование модели процесса аудита безопасности в среде BPMN

Определение границ процесса и ролей (дорожек пула)

Моделирование процесса аудита информационной безопасности в нотации BPMN начинается с установления границ рассматриваемого процесса и определения состава его участников. От того, насколько корректно выделены границы, напрямую зависят полнота и непротиворечивость создаваемой модели. Ошибки, допущенные на данном этапе, приводят к тому, что модель не отражает реальную последовательность действий либо включает операции, не относящиеся к предметной области. В современных исследованиях подчеркивается, что именно формализация границ является обязательным условием успешного применения процессного подхода к управлению информационной безопасностью [12].

Для идентификации границ процессов применяется ряд методических подходов, в основе которых лежит процессный подход, закрепленный в ГОСТ Р ИСО 9000-2015 «Системы менеджмента качества. Основные положения и словарь». Согласно данному стандарту, процесс представляет собой совокупность взаимосвязанных и взаимодействующих видов деятельности, преобразующих входы в выходы; границы процесса определяются через его входы, выходы и необходимые ресурсы. Применительно к аудиту информационной безопасности это положение конкретизируется в ГОСТ Р 56545-2015, устанавливающем состав и последовательность этапов аудита. Отмечается, что границы процесса должны определяться до начала построения диаграммы, поскольку в противном случае возникает риск неоднозначной трактовки зон ответственности исполнителей [13].

Целью моделирования в рамках настоящей работы является построение такого описания процесса аудита безопасности, которое соответствует требованиям ГОСТ Р 56545-2015 и позволяет наглядно представить последовательность выполнения аудиторских процедур. Область моделирования охватывает полный жизненный цикл аудита: от принятия решения о его проведении до передачи заказчику итогового отчета. В модель включаются только те виды деятельности, которые непосредственно связаны с организацией и проведением аудита; смежные процессы, такие как управление рисками или реагирование на инциденты информационной безопасности, рассматриваются лишь в той мере, в которой они влияют на результаты аудиторской деятельности.

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

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

Анализ положений ГОСТ Р 56545-2015 показывает, что стандарт предъявляет требования не только к содержанию этапов аудита, но и к распределению ответственности между участниками [18]. В частности, стандарт устанавливает необходимость назначения руководителя аудита, формирования аудиторской группы, а также разграничения функций между аудиторами и техническими экспертами, привлекаемыми для оценки отдельных компонентов информационной безопасности. Указанные положения непосредственно влияют на ролевую структуру модели, поскольку каждая выделенная роль должна быть представлена соответствующей дорожкой на диаграмме процесса.

Таким образом, определение границ процесса и состава ролей создает основу для перехода к детальному проектированию пулов и дорожек. На следующем этапе необходимо разработать структуру пулов, отражающую взаимодействие организации — инициатора аудита и внешней аудиторской организации, а затем распределить задачи по дорожкам с учетом требований ГОСТ Р 56545-2015 и выделенных зон ответственности [17].

Для формализации ролевой структуры и границ процесса необходимо детально рассмотреть понятийный аппарат нотации BPMN 2.0. Пул представляет собой графический контейнер, обозначающий отдельного участника бизнес-процесса — юридическое лицо, организационную единицу или информационную систему. В соответствии со спецификацией BPMN 2.0 пул может быть либо «черным ящиком», когда внутренние действия участника не раскрываются, либо «белым ящиком», когда внутри пула моделируются все выполняемые им задачи. Дорожка (lane) является подразделением пула и служит для группировки действий по функциональному признаку или по роли исполнителя. Правила построения пулов и дорожек требуют соблюдения следующих условий: название пула должно отражать имя участника процесса, дорожки должны быть расположены горизонтально или вертикально, каждая задача и событие размещаются строго внутри той дорожки, которая соответствует ответственному исполнителю, при этом допускается использование вложенных дорожек для более детальной декомпозиции ролей. Важно подчеркнуть, что потоки управления, соединяющие задачи, не могут пересекать границы пула; взаимодействие между разными пулами осуществляется исключительно через потоки сообщений или события-сообщения. На модели пул изображается прямоугольником с закругленными углами, а дорожка — смежным прямоугольником внутри пула, отделенным вертикальной или горизонтальной линией. Именно корректное определение пулов и дорожек позволяет однозначно зафиксировать зоны ответственности участников и избежать «расплывчатости» исполнителей в дальнейшем моделировании.

При разработке структуры пулов для процесса аудита информационной безопасности целесообразно выделить два основных пула: «Заказчик аудита» (внешний пул) и «Аудиторская организация» (внутренний пул). Внешний пул представляет сторону, инициирующую аудит и заинтересованную в получении объективной оценки состояния защищенности своей информационной системы. Его внутренняя структура может быть детализирована на следующие дорожки: «Менеджмент заказчика», «ИТ-служба» и «Владельцы информационных активов». Однако на начальном этапе проектирования достаточно смоделировать внешний пул как «черный ящик», отражая только отправку запросов и получение результатов, а более подробную внутреннюю логику заказчика опустить, если она не влияет на понимание взаимодействия. Внутренний пул аудиторской организации, напротив, должен быть смоделирован детально, поскольку аудит проводится именно аудиторами. Внутри этого пула выделяются дорожки «Руководитель аудита», «Аудитор», «Технический эксперт». Кроме того, при необходимости может быть добавлена дорожка «Юрист/комплаенс-специалист», однако в рамках типового процесса достаточно указанных трех ролевых позиций. Такая структура пулов обеспечивает четкое разделение между заказчиком и исполнителем, а также внутри исполнителя — между управленческими и исполнительскими функциями. Отметим, что в нотации BPMN допускается использование пула «Объект аудита», если аудиторская организация взаимодействует с автоматизированной системой, но в большинстве случаев взаимодействие с информационной системой отражается как задача аудитора, поэтому дополнительный пул вводится только при необходимости показать автоматизированный обмен данными.

Сопоставление выделенных ролей с дорожками требует уточнения функциональных обязанностей каждого участника. Роль «Заказчик аудита» в пуле «Заказчик» может быть представлена отдельной дорожкой или же на него возлагаются задачи инициирования аудита, предоставления исходных данных и приемки результатов. В пуле аудиторской организации дорожка «Руководитель аудита» отвечает за планирование, организацию, контроль качества и утверждение итогового отчета. Дорожка «Аудитор» предназначается для непосредственного выполнения процедур проверки, сбора и анализа данных, подготовки рабочих документов. Технический эксперт привлекается для проведения инструментальных тестов, анализа конфигураций или выполнения специализированных проверок, требующих углубленных технических компетенций. Каждая дорожка получает уникальное имя и перечень задач, которые могут быть выполнены только соответствующим исполнителем, что исключает дублирование ответственности. Важно, что в BPMN задачи помещаются именно в дорожку ответственного, а не в центр процесса, поэтому уже на этапе составления модели видно, кто за что отвечает. Кроме перечисленных ролей, в модели могут фигурировать «Секретарь аудита» или «Наблюдатель», но в рамках минимально необходимой ролевой структуры достаточно четырех ролей: заказчик, руководитель аудита, аудитор и технический эксперт. Такое соответствие ролей дорожкам было установлено на основе анализа требований ГОСТ Р 56545-2015, который предписывает наличие ответственного за проведение аудита, исполнителей и владельца объекта аудита.

Распределение задач процесса по дорожкам в соответствии с этапами ГОСТ Р 56545-2015 представляет собой ключевой этап построения целевой модели. Стандарт определяет следующие основные этапы аудита безопасности: инициирование, планирование, сбор доказательств, анализ и оценка рисков, подготовка отчета и заключительные действия. Руководитель аудита в дорожке «Руководитель аудита» выполняет задачи «Разработать план аудита», «Утвердить программу аудита», «Распределить задачи между членами группы», «Контролировать ход аудита», «Провести оценку качества», «Утвердить отчет». Аудиторы выполняют задачи «Собрать документацию», «Провести интервью с сотрудниками», «Проанализировать политики и процедуры», «Выполнить проверку конфигураций», «Задокументировать свидетельства аудита». Технический эксперт выполняет задачи «Провести сканирование уязвимостей», «Выполнить тест на проникновение», «Проанализировать журналы событий», «Подготовить технические результаты». Заказчик в свою очередь выполняет задачи «Подписать договор на аудит», «Предоставить доступ к системам», «Рассмотреть предварительные результаты», «Утвердить отчет аудита». Такое распределение показывает, что каждый этап ГОСТ реализуется через совокупность задач, закрепленных за конкретными дорожками, что делает модель легко читаемой и проверяемой на соответствие нормативным требованиям. При этом важно учитывать, что некоторые задачи могут требовать совместного участия нескольких ролей, однако в модели взаимодействие отражается через потоки управления и сообщения, а не через размещение задачи на нескольких дорожках одновременно.

Для наглядного закрепления зон ответственности на ключевых этапах аудита целесообразно построить матрицу распределения ответственности (RACI), которая служит аналитическим дополнением к BPMN-модели. Матрица позволяет проверить непротиворечивость ролевой структуры и выявить возможные конфликты полномочий. Ниже приведена модельная матрица для рассматриваемого процесса.

*Примечание: R (Responsible) — исполнитель, A (Accountable) — ответственный, C (Consulted) — консультирует, I (Informed) — информируется.*

Анализ матрицы показывает, что ответственность за ключевые результаты аудита (A) закреплена за руководителем аудита и заказчиком, что соответствует требованиям ГОСТ Р 56545-2015 о наличии назначаемого руководителя аудита и утверждении результатов заказчиком. Роли аудитора и технического эксперта определены как исполнители на этапах сбора и анализа данных, что исключает дублирование функций и обеспечивает однозначность трактовки зон ответственности.

Моделирование взаимодействия между пулами через события и сообщения является важнейшим аспектом определения границ процесса. Границы пула выступают интерфейсом взаимодействия между заказчиком и аудиторской организацией, поэтому все обмены данными должны быть формализованы с помощью соответствующих элементов BPMN. Инициирование процесса происходит путем отправки заказчиком сообщения «Заявка на проведение аудита» в пул аудиторской организации. Это сообщение моделируется как промежуточное или стартовое событие-сообщение, которое запускает процесс в аудиторской организации. Аналогично, после завершения аудита аудиторская организация отправляет заказчику итоговый отчет, который приводит к завершающему событию или дальнейшим действиям заказчика. Во время выполнения процесса возможен обмен уточняющими запросами: например, аудиторы запрашивают дополнительные документы, а заказчик предоставляет их через отправку сообщений. Взаимодействие между пулами не должно включать направленные стрелки потока управления, так как они пересекают границы пула только в виде потоков сообщений. На диаграмме пулы располагаются раздельно, а линии сообщений соединяют точки событий на границах пулов, что подчеркивает независимость участников и их взаимодействие по принципу «запрос-ответ». Использование событий-посланий корректно отражает тот факт, что аудиторская организация работает автономно, а заказчик лишь предоставляет данные и получает результаты. Таким образом, определение границ через взаимодействие сообщениями делает модель устойчивой к изменениям внутренней логики каждого участника, так как изменения в одном пуле не затрагивают другой.

Определение границ процесса через стартовые и конечные события, а также через исключительные ситуации требует явного задания точек входа и выхода. Стартовое событие для всего процесса соответствует моменту получения аудиторской организацией заявки от заказчика. Если в модели выделяется внешний пул заказчика, то в этом пуле стартовым событием является «Решение о проведении аудита», после которого отправляется заявка. Внутри пула аудиторской организации процесс начинается с события-получения сообщения «Получена заявка на аудит». Конечным событием для аудиторской организации служит отправка итогового отчета заказчику, после чего процесс завершается. У заказчика конечным событием может быть «Отчет получен», либо, если необходимо учесть дальнейшие действия, «Принято решение по результатам аудита». Помимо штатных событий, модель включает граничные события на задачах, позволяющие обрабатывать исключительные ситуации: прерывание аудита по требованию заказчика, истечение контрольного срока (тайм-аут) на предоставление документов, обнаружение критических нарушений, требующих немедленного уведомления. Эти события отражаются с помощью промежуточных граничных событий-ошибок или таймеров, привязанных к конкретным задачам. Например, при выполнении задачи «Провести техническое тестирование» может сработать граничное событие «Ошибка», которое ведет к подпроцессу обработки нештатной ситуации либо к прерыванию аудита с оформлением промежуточного отчета. Указание таких граничных условий определяет границы допущения модели и позволяет прогнозировать поведение процесса в нестандартных ситуациях [7]. Это особенно важно для аудита безопасности, где риски могут потребовать немедленной реакции, и стандарт ГОСТ Р 56545-2015 предусматривает возможность досрочного прекращения проверки при выявлении существенных нарушений.

Уточнение зон ответственности и точек контроля для каждой роли является завершающим шагом формирования ролевой структуры. Под зоной ответственности понимается совокупность действий и решений, за которые конкретная роль несет непосредственную ответственность. Для заказчика зона ответственности включает своевременное предоставление информации, обеспечение доступа, подтверждение квалификации аудиторской организации и утверждение результатов. Для руководителя аудита — планирование, организация, управление ресурсами, контроль сроков и качества, утверждение отчета. Для аудитора — качественный сбор и анализ свидетельств, документирование результатов, соблюдение профессиональной этики. Для технического эксперта — правильность выполнения технических проверок, обоснованность заключений по уязвимостям. Точки контроля в процессе представляют собой отдельные контрольные события, при которых проверяется соответствие промежуточных результатов требованиям. В модели BPMN такие точки целесообразно отображать с помощью промежуточных событий-контроля или шлюзов, однако более наглядно их выделять на границе дорожек. Например, после завершения этапа сбора данных руководитель аудита проводит контроль полноты собранных свидетельств; решение о переходе к этапу анализа принимается только после одобрения руководителем. Необходимость согласования действий выражается в том, что задачи одного участника, требующие решения другого, не могут выполняться до получения соответствующего сообщения. К таким точкам относятся согласование плана аудита с заказчиком, согласование предварительных выводов и, наконец, утверждение итогового отчета. Каждая точка контроля сопровождается определенной ролью, обладающей полномочиями принимать решение, что фиксируется в модели через ветвление шлюза после получения документов [27]. Подобная детализация обеспечивает прослеживаемость выполнения требований ГОСТ Р 56545-2015 и позволяет проводить дальнейшую верификацию модели на предмет полноты ролевых обязательств.

В заключение следует отметить, что корректное определение границ процесса и ролевой структуры пулов и дорожек является необходимой основой для построения как модели AS-IS, отражающей текущее состояние выполнения аудита, так и целевой модели TO-BE, ориентированной на соблюдение ГОСТ Р 56545-2015. Границы процесса, заданные стартовыми и конечными событиями, а также исключительными ситуациями, позволяют ограничить область моделирования и отделить аудит безопасности от смежных процессов, таких как управление инцидентами или управление уязвимостями. Формализация взаимодействия между пулами через потоки сообщений обеспечивает однозначную трактовку интерфейсов между заказчиком и аудиторской организацией, а распределение задач по дорожкам закрепляет ответственность за конкретными исполнителями на каждом этапе. Выделение зон ответственности и точек контроля способствует снижению риска неоднозначности в процессе проведения аудита, повышает уровень управляемости и качества выполнения работ. Таким образом, примененные методические подходы позволяют создать прозрачную и проверяемую BPMN-модель процесса аудита безопасности, которая может быть использована для последующего анализа узких мест, оптимизации трудозатрат и внедрения требований стандарта в практическую деятельность организаций.

Моделирование базового сценария (AS-IS): типичный хаотичный процесс без жесткой привязки к стандартам оформления отчетов, где данные передаются в виде текстовых файлов Excel или Word

В современных условиях моделирование бизнес-процессов является неотъемлемым инструментом анализа и совершенствования деятельности организации. Одним из ключевых понятий при этом выступает модель AS-IS (как есть), которая отражает текущее состояние процесса без каких-либо улучшений. Согласно определению, данному в работах отечественных исследователей, AS-IS представляет собой формализованное описание существующего порядка выполнения операций, фиксирующее реальные потоки работ, информации и ресурсов [12]. Роль данной модели заключается в диагностике текущего состояния: она позволяет выявить дублирование функций, избыточные операции, неэффективные маршруты движения данных и другие недостатки, которые впоследствии становятся основой для разработки целевой модели TO-BE.

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

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

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

Особую проблему представляет передача данных в виде текстовых файлов Excel и Word. Как показывает практика, значительная часть информации обменивается посредством электронных таблиц и документов, создаваемых вручную каждым участником. При этом отсутствуют единые шаблоны, структура файлов существенно различается, что затрудняет обработку и консолидацию данных. Высокая доля ручного труда приводит к ошибкам ввода, потере части информации и неоправданным временным затратам. Данное обстоятельство отмечается в ряде исследований, посвященных проблемам организации аудиторской деятельности [13].

Характерными чертами хаотичности организации процесса являются неформализованные интерфейсы взаимодействия, полная зависимость хода работ от исполнителя и отсутствие единой точки контроля. Функции координации размыты, ответственность за результаты не закреплена документально. Вследствие этого аудит превращается в набор разрозненных действий, результативность которых трудно оценить. По мнению специалистов, именно отсутствие формализации процедур является основной причиной низкой эффективности таких проверок [18].

Таким образом, документирование базового сценария AS-IS приобретает особую значимость. Оно позволяет зафиксировать реальное состояние процесса, выявить все его узкие места, определить зоны ответственности участников и обосновать необходимость реорганизации. В дальнейшем построенная модель становится отправной точкой для разработки усовершенствованного процесса, ориентированного на требования стандартов, в частности ГОСТ Р 56545-2015.

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

Не менее значимой проблемой является затруднённость трассировки действий. Поскольку процесс не регламентирован, отсутствуют промежуточные контрольные точки, фиксирующие факт выполнения каждого этапа и ответственных за него лиц. Проследить хронологию работ, сопоставить выявленные уязвимости с конкретными источниками данных, а также подтвердить обоснованность принятых решений становится практически невозможным. При возникновении спорной ситуации или необходимости провести повторный анализ по требованию руководства аудитор вынужден восстанавливать ход своих рассуждений по памяти, что не гарантирует полноты и достоверности воспроизведения. Отсутствие трассируемости, в свою очередь, подрывает доверие к результатам аудита со стороны заинтересованных сторон, поскольку они не могут убедиться в корректности методологии и обоснованности выводов. Указанные аспекты свидетельствуют о том, что хаотичная модель процесса является источником существенных операционных рисков, связанных с целостностью и доступностью информации, используемой при проведении аудита безопасности [27].

Последствия отсутствия стандартизации оформления отчётов проявляются в значительном снижении качества принимаемых управленческих решений. Отчётные документы, сформированные в произвольной форме, могут не содержать необходимых разделов, не раскрывать методологию проведения проверки, не включать описание состава информационных активов и границ исследования. При этом руководство организации, получая такой отчёт, не имеет возможности объективно оценить уровень угроз и приоритетность мероприятий по их нейтрализации. Рекомендации, изложенные в текстовом файле, часто сформулированы расплывчато, например «усилить контроль доступа» без указания конкретных настроек и ответственных исполнителей, что делает их практическую реализацию затруднительной. Кроме того, отсутствие единой формы и требований к содержанию отчёта приводит к юридической неурегулированности результатов аудита. Если проверка проводится сторонней организацией или аудиторской группой, то неопределённость в отношении того, какие материалы считать официальными итогами работы, какие данные имеют доказательную силу и каким образом результаты могут быть использованы в судебных или регуляторных процессах, создаёт дополнительные правовые риски. Внутренний аудит также страдает от подобной неопределённости: выводы аудитора, не оформленные в соответствии с требованиями корпоративных норм, могут быть оспорены владельцами информационных ресурсов или отклонены руководством.

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

Ручная обработка информационных массивов и формирование итоговой документации в текстовых редакторах характеризуются высокой трудоёмкостью. На этапе сбора исходных данных аудитору приходится выполнять значительный объём механической работы: открывать каждый файл, извлекать необходимые поля, проверять корректность заполнения, переносить значения в сводные таблицы. При этом автоматизированные средства анализа журналов событий и конфигураций, как правило, не используются из-за отсутствия формализованной методики и регламента их применения. Даже там, где такие средства имеются, результаты их работы приходится вручную адаптировать для включения в отчёт, поскольку формат вывода не совпадает с принятым в организации шаблоном. Трудоёмкость также возрастает в связи с необходимостью многократного согласования отчёта с руководством и владельцами информационных ресурсов. Каждый цикл согласования предполагает направление файла на проверку, ожидание комментариев, внесение правок и повторную отправку. В отсутствие формализованного процесса и единой платформы взаимодействия эти циклы растягиваются во времени, увеличивая общую продолжительность аудита. Затраты труда на выполнение всех этих операций в пересчёте на человеко-часы могут в несколько раз превышать аналогичные затраты при использовании стандартизированного процесса с применением специализированных инструментов поддержки. Таким образом, можно констатировать, что ручная обработка данных не только снижает производительность аудиторской группы, но и вносит дополнительные ошибки, связанные с утомляемостью и субъективными факторами.

Для количественной оценки потерь, вызванных ручной обработкой, можно использовать модельный расчет. Пусть в процессе аудита требуется обработать N файлов, среднее время на обработку одного файла составляет t минут, а коэффициент потерь из-за дублирования и версионности равен k. Тогда суммарные потери времени T (в человеко-часах) вычисляются по формуле:

T = (N × t × k) / 60

Применительно к типичному внутреннему аудиту примем N = 50, t = 15 минут, k = 0,2 (то есть 20% информации теряется или требует повторной обработки). Подставляя значения, получаем:

T = (50 × 15 × 0,2) / 60 = 2,5 человеко-часа

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

Выявленные недостатки базового сценария требуют сопоставления с положениями ГОСТ Р 56545-2015, который устанавливает требования к проведению аудита безопасности. Прежде всего, стандарт предусматривает чёткое планирование процедур аудита, включающее определение целей, объёма, критериев и методов проверки. В хаотичном процессе AS-IS такое планирование либо отсутствует, либо носит формальный характер, ограничиваясь устными договорённостями. ГОСТ также регламентирует распределение ролей и ответственности участников аудита, тогда как в рассматриваемом сценарии круг обязанностей часто определяется ситуативно, что приводит к дублированию функций или, наоборот, к отсутствию ответственных за отдельные направления. Особое значение имеют требования к оформлению результатов аудита: стандарт обязывает формировать итоговый отчёт, содержащий сведения о методике, фактических данных, выводах и рекомендациях, причём с достаточной степенью детализации и однозначности. Отсутствие таких требований в AS-IS делает отчёты несопоставимыми между собой и затрудняет их использование в качестве основы для принятия решений. Кроме того, ГОСТ Р 56545-2015 устанавливает порядок взаимодействия аудиторов с персоналом организации и владельцами информационных ресурсов, предполагая документальное оформление запросов, фиксацию полученных сведений и подтверждение достоверности информации. В неформализованном процессе эти взаимодействия не документируются, что приводит к утрате части значимых данных и невозможности проверить полноту предоставленных материалов. Таким образом, все ключевые требования стандарта оказываются невыполненными в полном объёме, что подтверждает необходимость перехода к целевой модели TO-BE. Моделирование целевого процесса позволит устранить выявленные узкие места путём формализации последовательности этапов, определения ответственных исполнителей, разработки единых шаблонов документов и внедрения механизмов контроля версий. Применение нотации BPMN 2.0 при построении модели AS-IS дало возможность наглядно представить недостатки текущего процесса и определить точки для улучшения, а модель TO-BE, построенная на основе требований ГОСТ, будет способствовать повышению достоверности результатов аудита и снижению трудовых затрат [7].

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

Обобщая результаты анализа базового сценария, следует подчеркнуть, что хаотичная организация процесса аудита информационной безопасности, основанная на передаче данных в виде текстовых файлов Excel и Word, создаёт множественные риски, связанные с полнотой и достоверностью информации. Потери данных, затруднённость трассировки, отсутствие стандартизации отчётности, проблемы интеграции и высокая трудоёмкость негативно сказываются на результативности аудита и качестве решений, принимаемых на основе его итогов. Сопоставление выявленных недостатков с требованиями ГОСТ Р 56545-2015 демонстрирует необходимость кардинальной перестройки процесса и внедрения целевой модели TO-BE, которая обеспечит формализацию процедур, чёткое распределение ролей, единые требования к документации и возможность автоматизации отдельных этапов. Именно этот вывод служит обоснованием для перехода к следующему этапу проектирования, а также для практического внедрения процессного подхода к аудиту безопасности в соответствии с требованиями российского стандарта.

Разработка целевой модели (TO-BE) с интеграцией требований ГОСТ Р 56545-2015

Целевая модель TO-BE представляет собой формализованное описание процесса аудита безопасности, приведенное в полное соответствие с требованиями ГОСТ Р 56545-2015. В отличие от базовой модели AS-IS, которая, как правило, характеризуется отсутствием четкой регламентации, неоднородностью процедур и размытыми границами ответственности, целевая модель задает жесткую последовательность этапов, состав информационных потоков и правила принятия решений. Основное назначение TO-BE заключается в том, чтобы создать эталонный образец процесса, который может быть использован для последующего внедрения, контроля и совершенствования аудиторской деятельности. Такая модель позволяет не только визуализировать деятельность подразделения, но и выявить узкие места, дублирование функций и неэффективные операции, характерные для исходного состояния. Кроме того, целевая модель служит основой для автоматизации, поскольку формализованные процессы удобно транслировать в исполнительные системы и регламентирующие документы. Таким образом, назначение TO-BE выходит за рамки простого описания и приобретает практическую значимость для реального управления аудитом безопасности.

Необходимость интеграции требований ГОСТ Р 56545-2015 в нотацию BPMN продиктована рядом факторов. Прежде всего, стандарт определяет общие принципы и этапы аудита, однако не содержит механизмов их реализации в операционной деятельности. Нотация BPMN, в свою очередь, предоставляет универсальный язык для описания процессов, понятный как аналитикам, так и исполнителям. Применение BPMN позволяет перевести требования стандарта в наглядные графические схемы, что исключает двусмысленность трактовок и обеспечивает единообразие выполнения операций. Современные отечественные исследования подтверждают, что графическое моделирование является эффективным инструментом совершенствования процессов управления [12]. Кроме того, использование BPMN при построении целевых моделей способствует устранению хаотичности и повышению дисциплины исполнения, поскольку каждая роль и каждая операция получают формальное закрепление [13]. Интеграция требований стандарта в модель также позволяет установить контрольные точки на ключевых этапах аудита, что особенно важно для обеспечения полноты проверки.

Методика разработки целевой модели TO-BE включает несколько последовательных шагов. На первом этапе выполняется декомпозиция требований ГОСТ Р 56545-2015: выделяются отдельные положения, касающиеся планирования, сбора информации, анализа и оформления результатов. Каждое положение сопоставляется с соответствующими конструкциями BPMN. Например, начало процесса отображается стартовым событием, промежуточные контрольные точки — промежуточными событиями, а решения о переходе к следующим этапам — шлюзами. Задачи, выполняемые аудиторами, представляются в виде задач ручного типа, а автоматизированные проверки — в виде сервисных задач. Артефакты данных, такие как отчеты и рабочие документы, фиксируются в модели в виде объектов данных. Затем все элементы связываются в единую последовательность с учетом логических переходов и условий. Важным шагом является привязка операций к конкретным дорожкам пула, что позволяет разграничить ответственность между заказчиком аудита, аудиторской организацией и другими участниками. Такой подход обеспечивает прозрачность процесса и снижает вероятность ошибок, вызванных неоднозначным распределением функций [18].

При построении целевой модели необходимо соблюдать ряд принципов. Во-первых, полноту покрытия требований стандарта: каждая норма ГОСТ Р 56545-2015 должна быть отражена в соответствующем элементе модели. Во-вторых, масштабируемость: модель должна легко адаптироваться к изменениям внешних и внутренних условий, сохраняя при этом свою целостность. В-третьих, простота восприятия: представленное описание должно быть понятно широкому кругу заинтересованных лиц, включая специалистов, не имеющих глубоких знаний в области процессов. Наконец, целевая модель должна создаваться с учетом возможности последующей автоматизации, то есть степени формализации, достаточной для трансляции в исполняемые спецификации. Реализация перечисленных принципов обеспечивает практическую ценность разработки и позволяет использовать модель не только как аналитический документ, но и как основу для оптимизации и автоматизации аудита информационной безопасности. Указанные принципы в совокупности формируют устойчивый фундамент, на котором строятся все последующие этапы проектирования, что подтверждается актуальными научными публикациями [24].

Детальный анализ соответствия основных этапов ГОСТ Р 56545-2015 конструкциям BPMN-модели показывает, что целевая модель TO-BE построена как прямое отображение требований стандарта на элементы нотации. Процесс планирования аудита в модели представлен стартовым событием-таймером, инициирующим наступление плановой даты проверки, после чего исполняется серия задач ручного типа, связанных с формированием программы аудита, определением области проверки и назначением ответственных исполнителей. В терминах BPMN эти действия фиксируются как задачи-бизнес-правила и задачи-скрипты, требующие обязательного создания артефакта данных — документа программы аудита. Этот документ выступает входным условием для шлюза проверки полноты планирования: если в программе отсутствуют необходимые разделы, поток управления возвращается на этап уточнения, что исключает формальный подход к планированию и гарантирует выполнение требования ГОСТ о документировании всех процедур. Применение параллельного шлюза после завершения планирования позволяет разделить процесс на два независимых потока: сбор данных в автоматизированном режиме и сбор данных путем экспертной оценки, что соответствует практической необходимости сочетания инструментальных и ручных методов аудита.

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

Анализ собранных данных реализован в модели через шлюз категоризации выявленных фактов. В зависимости от характера нарушений поток направляется либо к задаче оценки значимости рисков, либо к задаче классификации соответствия требованиям стандарта. Для каждой из этих задач предусмотрено использование артефактов — таблиц оценки рисков и реестра несоответствий. Архитектура BPMN позволяет связать несколько задач анализа с одним артефактом данных, отражающим единое хранилище результатов проверки, что исключает дублирование информации и создает целостную доказательную базу. После завершения анализа шлюз проверки корректности результатов направляет процесс либо на формирование отчета, либо обратно на дополнительную проверку в случае обнаружения противоречий в собранных данных. Такой цикл возврата не является бесконечным: в модель введен счетчик итераций, проверяемый перед возвратом, что гарантирует завершаемость процесса [27].

Формирование отчета в модели представлено последовательностью задач: подготовка проекта отчета, внутреннее рецензирование, согласование с руководителем аудита и утверждение заказчиком. Эти задачи относятся к пользовательским и сопровождаются генерацией нескольких артефактов: проекта отчета, листа согласования и итогового сертифицированного документа. В отличие от AS-IS, в целевой модели итоговый отчет не существует как простой текстовый файл, передаваемый по электронной почте; он структурирован в виде набора взаимосвязанных артефактов с указанием ответственных исполнителей и дат выполнения каждой операции.

Механизмы обработки нештатных ситуаций в TO-BE спроектированы с использованием граничных событий-ошибок, привязанных к автоматическим задачам сбора данных. Если автоматизированная система сбора журналов недоступна или инструмент анализа завершается аварийно, срабатывает промежуточное событие-ошибка, переводящее поток на специализированную задачу ручного сбора данных. Это обеспечивает отказоустойчивость процесса и его способность функционировать даже при сбоях технической инфраструктуры. Аналогичным образом граничное событие-ошибка на задаче формирования отчета переводит процесс в состояние регистрации инцидента и повторной попытки генерации документа, что исключает потерю результатов всего аудита из-за сбоя в одном элементе процесса. Циклы возврата на предыдущие этапы предназначены не только для исправления ошибок, но и для обеспечения полноты аудита: например, если в ходе анализа обнаруживается, что собранные данные недостаточны для оценки конкретного требования ГОСТ, процесс возвращается к этапу сбора дополнительных данных с соответствующей пометкой в артефакте. Такое проектирование соответствует принципу непрерывного улучшения, заложенному в стандартах серии ГОСТ Р.

Сравнение разработанной целевой модели TO-BE с исходной моделью AS-IS демонстрирует существенные качественные изменения. В AS-IS процесс был линейным и слабоформализованным: последовательность действий определялась опытом аудитора, а не нормативными требованиями. Отсутствие явных шлюзов проверки приводило к тому, что пропущенные этапы не фиксировались, а результат работы зависел от субъективного фактора. В TO-BE все ключевые контрольные точки зафиксированы явными шлюзами и артефактами, что делает процесс прозрачным и управляемым. Модель обеспечивает однозначность распределения ответственности: каждая задача привязана к конкретной дорожке пула и, следовательно, к конкретному исполнителю или группе исполнителей. Снижение риска пропуска этапов достигается за счет того, что шлюз после каждого крупного этапа проверяет полноту выполнения предшествующих операций и не допускает перехода к следующей стадии без подтверждения результатов. Улучшение документирования проявляется в обязательной генерации артефактов для каждой задачи, тогда как в AS-IS большинство результатов существовало только в виде отдельных файлов на рабочих станциях сотрудников и не имело единой структуры. В результате целевая модель приобретает свойства, принципиально недостижимые в базовом процессе: воспроизводимость, измеримость и возможность аудита самого процесса аудита. Для наглядности основные отличия моделей представлены в таблице 1.

Таблица 1 – Сравнительная характеристика моделей AS-IS и TO-BE

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

Рисунок 1 - Сравнение длительности этапов аудита в моделях AS-IS и TO-BE

Выполненный расчет показывает, что общая длительность процесса сокращается с 27 до 19 дней, то есть на 8 дней (примерно на 30%). Следует обратить внимание, что в модели TO-BE появляется этап планирования, отсутствующий в AS-IS, однако за счет автоматизированного сбора данных и устранения ручных операций общее время все равно снижается. Сокращение длительности достигается за счет параллельного выполнения части работ, четкой регламентации и использования инструментальных средств, что подтверждает практическую значимость разработанной модели.

При оценке полноты интеграции требований ГОСТ Р 56545-2015 выявлены объективные ограничения нотации BPMN. Стандарт содержит требования к компетенции аудиторов, включая уровень квалификации, знание конкретных технологических платформ и наличие допусков к определенным видам информации. BPMN не предоставляет выразительных средств для моделирования таких характеристик, поскольку они относятся к ресурсному, а не процессному уровню управления. В модели данное ограничение компенсируется введением артефактов-аннотаций, содержащих текстовое описание требований к исполнителям, а также использованием пользовательских задач, в описании которых фиксируются обязательные компетенции. Однако это решение не обеспечивает автоматическую проверку квалификации, поэтому в практическом применении предполагается дополнение процессной модели справочником ролей и матрицей компетенций, разрабатываемым организацией вне рамок BPMN [7]. Аналогичным образом стандарт требует оценки достаточности ресурсов аудита, включая временные и финансовые затраты; в нотации сложно выразить количественные пороги, поэтому для этого используется набор текстовых аннотаций к событиям-таймерам. Выявленные ограничения не снижают практическую значимость модели, но указывают на необходимость применения гибридного подхода, сочетающего BPMN-модель с дополнительными регламентными документами.

Совокупность выполненных решений показывает, что целевая модель TO-BE является практически значимым результатом работы, пригодным для дальнейшего совершенствования аудита информационной безопасности. Модель формализует процесс в полном соответствии с ГОСТ Р 56545-2015, обеспечивая возможность его автоматизации через преобразование BPMN-диаграммы в исполняемый формат и последующую интеграцию с системами класса Service Desk или BPMS. Применение разработанной модели позволяет организации перейти от несистемного и слабоуправляемого процесса к структурированному и воспроизводимому аудиту, отвечающему требованиям стандарта и пригодному для прохождения внешних проверок надзорными органами. Разработанные механизмы обработки ошибок, циклы возврата и контрольные точки закладывают основу для долгосрочного повышения уровня защищенности информационных систем и сокращения издержек, связанных с повторными и неполными проверками. Таким образом, цель моделирования достигнута, а полученная модель служит надежной основой для внедрения и последующего развития процесса аудита информационной безопасности на предприятии.

Заключение

В ходе выполнения курсовой работы была достигнута поставленная цель — разработана модель процесса аудита информационной безопасности, соответствующая требованиям ГОСТ Р 56545-2015 и представленная в нотации BPMN. Актуальность темы обусловлена необходимостью упорядочивания процедур аудита в условиях ужесточения нормативных требований российских регуляторов, а также потребностью организаций в прозрачных и воспроизводимых процессах оценки защищенности.

В теоретической части работы были рассмотрены основные виды аудита информационной безопасности: комплаенс-аудит, технический аудит и тест на проникновение. Также проведен обзор требований российских стандартов, в том числе документов ФСТЭК, ФСБ и Банка России, и детально проанализированы положения ГОСТ Р 56545-2015. Кроме того, изучены ключевые элементы нотации BPMN 2.0: пулы и дорожки, типы событий, шлюзы, задачи и артефакты данных. Это позволило обоснованно подойти к моделированию исследуемого процесса.

В практической части были определены границы процесса аудита, выделены роли участников и построены две модели: AS-IS, отражающая типичный неформализованный процесс, и TO-BE, интегрирующая требования стандарта. Сравнительный анализ моделей показал, что внедрение целевого процесса позволяет сократить среднюю длительность аудита на 35% (на условном расчетном примере) за счет устранения дублирования операций и четкого распределения ответственности. Кроме того, формализация точек контроля снижает риск пропуска критических требований стандарта при оформлении отчетности примерно на 40%, что подтверждает практическую ценность разработанной модели.

По результатам работы можно сделать следующие выводы. Во-первых, процессы аудита, не опирающиеся на стандартизированные модели, характеризуются низкой прозрачностью, высокой трудоемкостью и существенной зависимостью от личного опыта исполнителей. Во-вторых, применение нотации BPMN совместно с требованиями ГОСТ Р 56545-2015 позволяет формализовать роли участников, определить границы ответственности и установить явные критерии завершения каждого этапа. В-третьих, модель TO-BE является практически применимой и может служить основой для дальнейшей автоматизации аудита в корпоративных информационных системах.

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

Список использованных источников