САПУИБ — это система класса Security GRC (Governance, Risk, Compliance), которая позволяет автоматизировать деятельность подразделения ИБ, эффективно внедрить и поддерживать процессный подход к управлению информационной безопасностью компании.
Governance — осознание главенствующей роли руководства организации в постановке целей, контроля их достижения. Это важнейший элемент, отражающий зрелость организации и способность воплотить концепцию GRC.
Risk management — риск-ориентированный подход – достижение поставленных целей, через определение значимых рисков, препятствующих этому.
Compliance — определение совокупности внешних (от регуляторов области или рекомендаций производителей ПО/оборудования) и внутренних требований (например, политика ИБ), невыполнение которых, в том числе, влияет на увеличение рисков.
САПУИБ решает задачи:
Формализации деятельности подразделений ИБ компании и ее филиалов при реализации процессов управления ИБ.
Обеспечения информационного взаимодействия подразделения ИБ со смежными организационными единицами.
11.1 Бизнес процессы: демонстрация работы
Агрегации данных с учетом их взаимосвязей и мониторинга по различным направлениям ИБ.
Обеспечения объективности и оперативности оценки текущего уровня ИБ структурных подразделений и компании в целом.
Основными заказчиками системы автоматизации процессов управления ИБ (САПУИБ) являются крупные компании и холдинги, которые при создании системы менеджмента информационной безопасности (СМИБ) придерживаются принципов, отраженных в серии стандартов ISO 27000, ГОСТ Р ИСО МЭК 27000. Их деятельность обычно обеспечивается сложной ИТ-инфраструктурой и комплексной системой защиты информации.
Организации, которые внедрили процессы СМИБ или находятся в стадии их внедрения, скорее всего уже столкнулись со следующими проблемами:
- отсутствие единой точки агрегации данных (как технических, так и организационных) по различным взаимозависимым аспектам информационной безопасности компании;
- ограниченный штат сотрудников ИБ или нехватка квалифицированных специалистов по управлению ИБ;
- сложность своевременной актуализации значительного объема внутренних документов, касающихся вопросов ИБ;
- обширный перечень критичных ресурсов ИТ-инфраструктуры, подлежащих учету и защите;
- большое количество прикладных систем, где обрабатывается информация ограниченного доступа, требующих учета и анализа их защищенности;
- наличие значительных потоков данных, в том числе событий и уязвимостей безопасности, от технических средств системы защиты информации и невозможность трансформировать их содержимое в оценку влияния на автоматизируемую бизнес деятельность;
- сложность организации процессов обработки обнаруженных инцидентов ИБ, реагирования и проведения расследований;
- низкая оперативность актуализации рисков ИБ на операционном и стратегическом уровне, учета их взаимосвязи с общекорпоративными рисками;
- сложность учета и соблюдения множества требований ИБ из различных источников (например, государственные регуляторы, стандарты организации) как по организационным, так и по техническим мероприятиям;
- сложность оперативного контроля состояния ИБ в компании и ее филиалах.
Решить эти проблемы позволит автоматизация процессов менеджмента ИБ за счет внедрения САПУИБ.
Как строится модель бизнес-процессов. Взгляд изнутри #shorts
Выгоды от внедрения
Повышение зрелости организации с точки зрения понимания влияния состояния информационной безопасности на функционирование бизнес-процессов компании.
Интеграция рисков ИБ в существующую систему управления рисками.
Переход от качественных оценок влияния ИБ на бизнес к количественным оценкам, опирающимся на конкретные данные в системе.
Получение актуальных свидетельств функционирования системы менеджмента ИБ.
Полученные выгоды от внедрения, в том числе, значительно облегчают прохождение сертификации компанией системы менеджмента ИБ (ISO 27001, ГОСТ Р ИСО МЭК 27001).
Таким образом, САПУИБ – это своего рода «ERP-система безопасника», основной инструмент руководителя, менеджеров и специалистов ИБ. Именно внедрение подобного инструмента позволит кардинально привнести новую парадигму в работу специалистов ИБ, трансформировать и «оцифровать» деятельность в области управления ИБ в компании.
Преимущества компании
- обладаем компетенциями в области формализации и автоматизации процессов управления ИБ;
- наличие собственных уникальных разработок;
- успешный опыт внедрения и сопровождения САПУИБ в крупных компаниях;
- опыт интеграции с продуктами: SIEM, IdM, DLP, Vulnerability/Compliance management , ITSM и пр.
- высокий профессиональный уровень с опорой на лучшие мировые практики;
- статус авторизованного партнера компаний RSA Security (подразделение Dell Technologies) и ООО «Компания информационных технологий»;
- федеральная сеть представительств по всей России.
Есть вопросы? Обратитесь к нашим специалистам
В настоящий момент разработки ООО «Газинформсервис» позволяют автоматизировать девять процессов управления ИБ, встроив их в существующую систему обеспечения ИБ предприятия (интеграция с существующими средствами защиты информации).
Каждый из девяти автоматизируемых процессов реализуется отдельным функциональным модулем системы.
На базе платформы и перечисленных выше функциональных модулей также реализованы процессы, позволяющие автоматизировать деятельность по учету и категорированию объектов критической информационной инфраструктуры, а также по управлению и контролю за мероприятиями по обеспечению безопасности таких объектов, требования к которой определены Федеральным законом от 26 июля 2017 г. № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации», Приказами ФСТЭК №235 от 21 декабря 2017 г., №239 от 25 декабря 2017 г.
В качестве внешних источников данных для функциональных модулей, реализующих автоматизацию процессов управления ИБ, используются смежные системы, а именно: существующие на предприятии информационные системы и системы защиты информации. Способ импорта зависит от возможностей каждой из них. Специалистами компании «Газинформсервис» накоплен широкий практический опыт работы с различными продуктами.
Архитектурно САПУИБ представляет собой интеграционную платформу с реализованными на ней функциональными модулями и коннекторами к смежным системам.
- Возможна реализация на одной из двух интеграционных платформ: RSA Archer eGRC (США) или ePlat4m (Россия). Взаимодействие пользователей с САПУИБ осуществляется через веб-интерфейс.
- Обе платформы состоят из клиент-серверного веб-приложения, использующего Microsoft IIS в качестве сервера приложений и Microsoft SQL Server в качестве СУБД. В настоящий момент ведется разработка реализации платформы ePlat4m на базе ПО, отвечающего требованиям по импортозамещению (ОС Linux, СУБД Jatoba).
- Основой бизнес-логики являются функциональные модули. Система может внедряться помодульно, выбор состава модулей зависит от текущих потребностей заказчика. Функциональность модулей может адаптироваться.
- Данные из различных систем (СЗИ или корпоративные ИС) посредством коннекторов импортируются в САПУИБ, агрегируются и участвуют в межмодульном взаимодействии.
Введение в САПУИБ (Система Автоматизации Процессов Управления Информационной Безопасностью), разработанной компанией ООО «Газинформсервис» на платформе ЕМС RSA Archer eGRC и позволяющей жестко увязывать управление процессами информационной безопасности (ИБ) с бизнес-процессами компании, а также с требованиями региональных и отраслевых регуляторов.
В журнале BIS Journal опубликована статья, в которой рассматривается решение задачи обеспечения непрерывности и восстановления деятельности (ОНиВД) для кредитно-финансовых учреждений (КФУ).
Статья, приуроченная к конференции по теме информационной безопасности объектов ТЭК, прошедшей в 2014 году. В статье упоминаются этапы развития решения САПУИБ.
В настоящей статье рассматриваются две системы централизованного управления ИБ – Security Operation Center (SOC) и Information Security Management System (ISMS), раскрываются преимущества их интеграции и основные возможности в рамках автоматизируемых функций.
О важности и необходимости внедрения в организациях системы управления информационной безопасностью(СУИБ) на основе процессного подхода уже говорилось и писалось неоднократно, в Интернете можно найти многочисленные материалы, посвященные этой теме. В данной статье речь пойдет об одном из процессов менеджмента информационной безопасности – идентификация и классификация активов компании – и практических аспектах автоматизации этого процесса.
Выпуск BIS TV о технологиях и практическом опыте обеспечения информационной безопасности в российских компаниях: Погружение в информационную безопасность. Обсуждение с экспертами темы по автоматизации деятельности подразделений ИБ: для чего она нужна, где её внедрять и как не допустить распространённых ошибок.
Источник: www.gaz-is.ru
Автоматизация бизнес-процессов в системах безопасности
Теория процессного управления все чаще применяется в настоящее время, приходя на смену функциональному подходу. Сегодня можно найти довольно много трудов, посвященных выстраиванию бизнес-процессов на предприятии и их оптимизации. Однако, большинство статей посвящено описанию основных бизнес-процессов, то есть таких, от которых зависит результативность основной деятельности предприятия: производства бензина для нефтеперерабатывающего завода, работы с держателями кредитов в банке и т. п. В данной статье мы постараемся показать, что процессный подход уместен и в сфере эксплуатации инженерно-технических средств охраны, а его правильное применение позволит как сэкономить средства, так и повысить безопасность и управляемость предприятием.
ПРОЦЕССНЫЙ ПОДХОД
Сформулируем основные положения процессного подхода к управлению предприятием и отличия от функционального:
1. Компания рассматривается как сеть взаимосвязанных бизнес-процессов, а не в качестве отдельных лиц, ответственных за определенные функции.
2. Преимуществом такого подхода является ориентированность на конечный результат как каждого отдельного бизнес-процесса, так и их совокупности.
3. Процессный подход позволяет оценить вклад каждого бизнес-процесса в конечный результат и правильно подойти к мотивации сотрудников.
У бизнес-процесса обязательно должны быть владелец и менеджер. Разница между ними заключается в следующем: владелец процесса описывает процесс и имеет право изменять его в зависимости от потребностей компании, а менеджер осуществляет оперативное управление. Чтобы лучше объяснить различие, приведем пример: курьер привез документы на режимный объект.
Для того чтобы попасть внутрь, он должен зарегистрироваться в бюро пропусков, получить пропуск и инструкцию, в какой кабинет идти. Владельцем процесса в данном случае выступает начальник службы режима, регламентировавший алгоритм допуска на объект.
Менеджером процесса является сотрудник бюро пропусков, который непосредственно осуществляет регистрацию посетителя, выдачу пропуска и направляет его в нужный кабинет. Также важно знать, кто является потребителем процесса. Потребитель может быть внешним (не входит в состав организации, владеющей бизнес-процессом) и внутренним (входит в состав). Заметим, что внутренним потребителем процесса может быть как его владелец, так и другие сотрудники предприятия, так или иначе извлекающие выгоду от его наличия. В нашем примере потребителем процесса является собственник объекта: в результате внедрения пропускного режима повышается безопасность объекта и осуществляется контроль перемещения товарно-материальных ценностей на предприятии.
Составим простейшую схему приведенного выше процесса, используя нотацию BPMN (Business Process Management Notation) 2.0 (рис. 1). Изображение человека в теле задачи обозначает, что задачу выполняет сотрудник. Автоматизированные задачи обозначаются «шестеренкой» или «скриптом» в зависимости от характера автоматизации. Как правило, «шестеренкой» обозначаются задачи, исполняемые серверной службой (приложением), а «скриптом», исполняемые при помощи скрипта — например, JavaScript на веб-странице с соответствующим интерфейсом.
Принято выделять три основных вида бизнес-процессов:
1. Управляющие — они охватывают все функции управления на уровне отдельных бизнес-процессов и их системы в целом. К таким процессам относятся стратегический менеджмент, корпоративное управление и т. п. Некоторые эксперты выделяют процессы развития в отдельный класс, однако, в общем, это тоже управляющий бизнес-процесс.
2. Операционные — эти бизнес-процессы составляют основу бизнеса компании и создают основной поток доходов. Самыми распространенными примерами операционных бизнес-процессов являются снабжение, производство, маркетинг и продажи.
3. Поддерживающие бизнес-процессы, обслуживающие основной бизнес. К таким процессам можно отнести бухгалтерский учет, техническую поддержку, различные административные функции.
Рис. 1. Простейший бизнес-процесс
АЛГОРИТМ АВТОМАТИЗАЦИИ
С чего следует начать автоматизацию бизнес-процессов на предприятии? Однозначного ответа на данный вопрос дать нельзя, ведь на каждом уникальном предприятии есть свои уникальные процессы. Но можно обозначить общие шаги, выполнение которых так или иначе необходимо для успешного описания тех или иных действий, которые мы хотим упорядочить и в конечном итоге автоматизировать.
Первое: необходимо определить цели и задачи бизнес-процесса. Задача должна быть поставлена максимально четко, цель не менее четко определена. Вот пример правильно сформулированной цели: сократить время нахождения транспортного средства на КПП с пяти до двух минут с целью увеличения грузопотока в два раза. Для достижения этой цели необходимо решить следующие задачи:
■ устранить очереди на КПП путем планирования их равномерной загруженности;
■ автоматизировать допуск на объект зарегистрированных транспортных средств путем внедрения системы распознавания номеров;
■ в случае, если номер не распознается или его нет в базе, направить автомобиль на стоянку для ожидания, оформить допуск вручную.
В результате автоматизации данного процесса владелец предприятия оптимизирует грузопоток, что приведет не только к сокращению простоя автотранспорта на КПП, но и к равномерному распределению нагрузки между операторами. Это, в свою очередь, может снизить вероятность возникновения ошибки из-за усталости или другого «человеческого» фактора, а также позволит уделить больше времени решению возникающих нестандартных ситуаций (рис. 2).
Рис. 2. Упрощенный бизнес-процесс контроля проезда транспорта через КПП
Вторым важным шагом является ограничение времени исполнения процесса. Участники процесса должны укладываться в определенные временные рамки — иначе становится непонятно, зачем мы его автоматизируем. Несомненным аргументом в пользу использования информационных управляющих систем является возможность анализа на наличие «слабых звеньев». Определение проблемных мест позволяет минимизировать влияние человека, не связанное с форс-мажорными обстоятельствами.
Третьим шагом является определение этапов и ключевых точек (точек контроля) бизнес-процесса. Этот шаг позволяет распределить задачи и назначить ответственных за их исполнение. В нашем примере с автотранспортом такими точками являются регистрация посетителя и направление его на наименее загруженный КПП (ответственный — администратор портала); автоматическое распознавание номера и занесение информации в базу данных (ответственный — инженер, обслуживающий систему охранного телевидения); ручное оформление транспорта в случае несрабатывания автоматической системы (оператор КПП).
Четвертый шаг — описание алгоритмов, условий перехода, уведомлений внутри бизнес-процесса. Например, в форму регистрации можно добавить тип транспортного средства, проверку паспортных данных водителя на наличие в списке разыскиваемых лиц, настроить уведомление инженера по обслуживанию системы видеонаблюдения о снижении вероятности распознавания номера — это может быть следствием загрязнения кожуха телекамеры, а может свидетельствовать о более серьезных неисправностях.
Пятый шаг — учет ресурсов бизнес-процесса. Нельзя рассматривать бизнес-процесс в отрыве от предприятия и доступных ресурсов: временных, материальных, человеческих и пр. Еще раз подчеркнем, что желательно осуществлять контроль ключевых точек в «ручном» режиме. Именно для этого назначается менеджер процесса, а в случае особо сложных задач их может быть несколько.
Шестое, на что следует обратить внимание, — потоки информации, сопутствующие бизнес-процессу. Правильная настройка уведомлений позволяет оперативно разобраться с задачами, вовремя обратить внимание руководства на трудности, возникающие при реализации того или иного этапа бизнес-процесса. Современные средства позволяют использовать различные методы уведомлений: будь то электронная почта, корпоративный мессенджер (Lync, Skype, Telegram, Viber, WhatsApp и т. п.) или SMS-сообщение.
И седьмое — результат бизнес-процесса. Положительный или отрицательный — любой. В случае если цель достигнута, можно удовлетвориться этим, а можно проанализировать процесс еще раз и усовершенствовать его. В случае если цель не достигнута, может помочь изучение журналов событий и работа над ошибками, допущенными при проектировании бизнес-процесса. Один из основоположников менеджмента Петер Друкер писал: «. В XXI веке. выживают лидеры перемен — те, кто чутко улавливают тенденции изменений и мгновенно приспосабливаются кним, используя во благо открывающиеся возможности».
ЧАСТНЫЙ СЛУЧАЙ
Спускаясь от общего к частному, давайте рассмотрим процессы, связанные с работой комплексов инженерно-технических средств охраны. Большинство таких процессов можно отнести к классу поддерживающих (или вспомогательных), т. к. согласно приведенному в начале статьи определению они обслуживают основной бизнес предприятия.
Рис. 3. Пример вспомогательного бизнес-процесса оформления пропуска
На рисунке 3 представлен вариант процесса оформления пропуска на режимном объекте. Пользователь, работающий на объекте, авторизуется на начальной странице. На данном этапе простую аутентификацию по паролю или по доменной учетной записи можно дополнить запросом к СКУД: находится ли пользователь на объекте, если удаленного доступа к этому процессу не предусмотрено? В случае если введенные логин и пароль совпадают с записями в базе данных, а сотрудник прошел через турникет на КПП, пользователь попадает на страницу интерфейса работы с основными программными модулями, в противном случае информация передается в службу безопасности предприятия.
После того, как пользователь авторизован, приложение генерирует интерфейс на основании ролей и полномочий пользователя. Так, например, администратор системы получает доступ к ее настройкам, секретарь — к интерфейсу оформления заявок и выдачи пропусков (в т. ч. с картами СКУД), сотрудник отдела режима — к интерфейсу выдачи разрешения на посещение объекта.
После этого пользователь начинает работу. В процессе выполнения заданий сотрудник может направлять на сервер запросы для выполнения тех или иных задач, работать с отчетами, обращаться к записям в базе данных. После каждого действия интерфейс обновляется, предоставляя пользователю актуальную информацию. После того как все задачи выполнены, пользователь выходит из системы и экземпляр процесса завершается.
Выгоды от автоматизации, казалось бы, такой тривиальной задачи весьма существенны, особенно если оценивать их в течение длительного временного периода. Допустим, на режимном объекте работает около тысячи сотрудников сторонних организаций-подрядчиков.
Для каждого такого сотрудника нужно получить его согласие на обработку персональных данных в соответствии с требованиями 152-ФЗ «О персональных данных» и обеспечить их безопасность, составить заявку, доставить ее в режимный отдел, дождаться согласования, отнести в бюро пропусков и выдать пропуск. Зачастую эту работу выполняет квалифицированный специалист, например, инженер отдела IT, которому предприятие вынуждено платить деньги в том числе и за «походы по кабинетам». Автоматизация этого процесса не только экономит деньги (трудозатраты на оформление пропуска могут сократиться в 4-5 раз), но и структурирует информацию о том, кто согласовал проход того или иного человека на объект, когда он приходил и к кому (при интеграции со СКУД). Наконец, оперативность оформления пропуска положительно влияет на имидж предприятия.
Какой же подход выбрать к автоматизации таких процессов? Сегодня существует две стратегии, довольно сильно отличающихся на первый взгляд, но весьма похожих при детальном изучении. Как в «Евгении Онегине»: «Они сошлись: вода и камень, стихи и проза, лед и пламень — не столь различны меж собой».
Первая стратегия кажется более трудозатратной и сложной в исполнении: нужно разработать специализированное программное обеспечение, совместимое с, а еще лучше — интегрированное в IT-инфраструктуру предприятия. Такое решение больше всего похоже на пошив делового костюма у кутюрье: итоговый продукт будет практически идеально соответствовать вашему бизнесу, но гибкость использования такого продукта может быть ограничена рамками конкретной задачи. Вторая стратегия — взять одно из средств автоматизации бизнес-процессов, представленных на рынке, и использовать его. Поставщики таких решений убеждают потребителей, что работать в них не сложнее, чем в пакете офисных программ, а автоматизировать бизнес-процесс сможет и аналитик, а то и сам руководитель на досуге. Пример интерфейса программного обеспечения для автоматизации бизнес-процессов приведен на рисунке 4.
Рис. 4. Один из вариантов проектирования бизнес-процесса в специализированном ПО
В рамках данной статьи невозможно детально сравнить два этих подхода, но это и не требуется. Довольно качественное сравнение приведено на сайте https://habrahabr.ru/post/304628/. Приведу выводы, которые автор делает по результатам анализа вышеобозначенных стратегий:
1. Модель бизнес-процесса не отражает реальности для бизнес-аналитика (он не видит код исполнения задач серверными приложениями) и неудобна для разработчика.
2. Нет набора готовых компонент для гибких бизнес-процессов (agile, adaptive case management), а средства создания таких компонент неадекватны. 3. Поддержка версионности бизнес-процессов реализована частично. Короче говоря, нарисовать схему бизнес-процесса действительно просто, она будет понятна бизнес-аналитику и отлично подойдет для доклада руководству.
Но вот хотите ли вы писать весь код самостоятельно? По большому счету, чем это отличается от создания корпоративного приложения? И наконец, возвращаясь к костюму, давно ли вы доставали журнал с выкройками?
BS ISO/IEC 20000 — процессный подход к управлению информационной безопасностью современной организации
Существование большинства бизнес-процессов невозможно без информационного обеспечения. Не секрет, что большинство бизнес-процессов современной организации обеспечиваются исключительно одной или несколькими информационными системами. Внедрение системы управления информационной безопасностью (СУИБ) — важное мероприятие, целью которого является управление процессами информационного обеспечения организации и предотвращение несанкционированного использования информации.
Требования бизнеса к ИБ оказывают воздействие на ИТ-подразделения и должны быть отражены в соглашениях об уровне сервиса (SLA — Service Level Agreement). Задачей процесса управления ИБ в данном контексте является постоянное обеспечение безопасности услуг на согласованном с партнером уровне, а информационная безопасность — важнейший показатель качества управления.
C точки зрения поставщика услуг, процесс управления информационной безопасностью способствует интеграции аспектов безопасности в ИТ-структуру. В свою очередь, принципы построения СУИБ содержатся в сборнике практических рекомендаций BS ISO 17799:2005, который дает исчерпывающее руководство для разработки, внедрения и оценки мер информационной безопасности.
Процесс управления ИБ имеет важные связи с другими процессами. Некоторые виды деятельности по обеспечению безопасности осуществляются другими процессами библиотеки ITIL, под контролем процесса управления ИБ.
С позиций стандарта BS ISO/IEC 20000 процесс управления информационной безопасностью имеет два целеполагающих значения:
> выполнение требований безопасности, закрепленных в SLA, и других требований внешних и внутренних соглашений, законодательных актов и установленных правил;
> обеспечение базового уровня ИБ, независимого от внешних требований.
Входными данными для процесса служат SLA, содержащие требования безопасности, по возможности, дополненные документами, определяющими политику организации в этой области, а также другие внешние требования. Процесс также получает важную информацию, относящуюся к проблемам безопасности, из других процессов, например об инцидентах, связанных с ИБ.
Выходные данные включают информацию о достигнутой реализации SLA вместе с отчетами о нештатных ситуациях с точки зрения безопасности, а также информацию о регулярных мероприятиях по улучшению СУИБ.
Преимущества внедрения
Эффективное информационное обеспечение с адекватной защитой информации важно для организации по ряду причин. Во-первых, эффективное функционирование организации возможно только при наличии доступа к точной и полной информации. Уровень ИБ должен соответствовать этому принципу. Во-вторых, в результате деятельности организации создаются продукты и услуги, которые доступны рынку или обществу и нужны для выполнения определенных задач. Неадекватное информационное обеспечение влечет производство некачественных продуктов и услуг, которые не могут использоваться для выполнения соответствующих задач и ставят под угрозу существование организации или безопасность зависящих от нее процессов.
Процессный подход
Управление ИБ, в рамках управления организацией в целом, сводится к перманентно функционирующему циклу PDCA [Цикл PDCA (plan, do, check, act) — модель непрерывного улучшения процессов, описанная впервые У. Шухартом в 1939 году. Состоит из четырех этапов. На этапе планирования осуществляются идентификация и анализ проблемы, оценка возможностей и планирование необходимых изменений.
На этапе выполнения происходит поиск решения проблемы и осуществление запланированных мероприятий. На этапе проверки производится оценка результатов и делаются выводы в соответствии с поставленной задачей. На этапе «действий» принимается решение на основе полученных выводов. Если изменение не решает поставленную задачу, план корректируется и цикл повторяется].
Поставщик услуг доводит соглашения до заказчика в форме плана по обеспечению ИБ, определяющего критерии безопасности или операционные соглашения об уровне услуг. Этот план исполняется, результаты оцениваются. Затем план и способы его реализации корректируются, о чем сообщается заказчику.
Таким образом, заказчик и поставщик услуг совместно участвуют в формировании всего жизненного цикла процесса. Заказчик может изменить требования на основе получаемых отчетов, а поставщик услуг может корректировать план или его реализацию на основе результатов наблюдения или поставить задачу изменения договоренностей, определенных в SLA. Функция контроля представлена в центре рис. 1. Далее эта диаграмма будет использоваться при описании видов деятельности процесса управления информационной безопасностью.
Взаимодействие процессов управления
Процесс управления информационной безопасностью имеет связи с другими процессами управления (см. рис. 2), так как в других процессах выполняются действия, связанные с обеспечением ИБ. Эта деятельность проводится в обычном порядке в рамках ответственности определенного процесса и его владельца. При этом процесс управления информационной безопасностью обеспечивает другие процессы инструкциями о структуре деятельности, связанной с ИБ. Обычно соглашения об этом определяются после консультаций между владельцем процесса управления информационной безопасностью и владельцами других процессов.
Управление конфигурациями
В контексте информационной безопасности процесс управления конфигурациями позволяет классифицировать информационные активы (ИА). Эта классификация определяет связи между ИА и предпринимаемыми мерами или процедурами обеспечения ИБ.
Классификация ИА определяет их конфиденциальность, целостность и доступность. Эта классификация основана на требованиях безопасности SLA. Классификацию определяет заказчик, так как только владелец актива может решить, насколько важны информация или информационные системы для бизнес-процессов.
При создании классификации ИА заказчик учитывает степень зависимости бизнес-процессов от информационных систем и информации. Затем проводится привязка классификации к соответствующим ИА.
Следующий этап — реализация комплекса мероприятий ИБ для каждого уровня классификации. Эти комплексы мероприятий могут быть описаны как процедуры (например, «Процедура обращения с носителями данных, содержащими конфиденциальную информацию») и составлять единую систему в соответствии с требованиями к документации BS ISO/IEC 27001:2005.
В SLA определяются комплексы мер безопасности для каждого уровня классификации. Система классификации совместима со структурой организации-заказчика. Однако для упрощения управления рекомендуется использовать одну общую систему классификации, даже если организация имеет несколько разных заказчиков.
Из вышесказанного можно сделать вывод, что классификация является ключевым процессом. Каждый ИА в конфигурационной базе данных (CMDB) должен быть обязательно классифицирован. Эта классификация связывает ИА с соответствующим комплексом мер по защите информации.
Управление инцидентами информационной безопасности
Любой инцидент, который может помешать выполнению требований безопасности SLA, классифицируется как инцидент ИБ. Необходимо включать в SLA определение типов инцидентов ИБ.
Сообщения об инцидентах ИБ поступают не только от пользователей, но также от различных процессов управления. Крайне необходимо, чтобы процесс управления инцидентами отражал все типы инцидентов ИБ. Это требуется для инициирования соответствующих процедур для обработки инцидентов. Также желательно, чтобы все внешние сообщения, относящиеся к инцидентам ИБ, проходили через менеджера СУИБ.
Управление проблемами
Процесс управления проблемами отвечает за идентификацию и устранение структурных сбоев СУИБ. Проблема может привести к возникновению риска функционирования СУИБ. Управление проблемами — пролонгированный процесс, в основе которого лежит анализ событий ИБ. Для того чтобы не возникло новых проблем с ИБ, принятое окончательное или обходное решение должно быть тщательно проверено, подкреплено результатами наблюдений и выявления закономерностей. Проверка должна основываться на соответствии предлагаемых решений требованиям SLA и внутренним требованиям ИБ.
Управление изменениями
Работы, выполняемые в рамках процесса управления изменениями, тесно связаны с ИБ, так как управление изменениями и управление информационной безопасностью взаимозависимы. Если достигнут приемлемый уровень ИБ, который находится под контролем процесса управления изменениями, то можно гарантировать, что этот уровень ИБ будет обеспечиваться и после проведения изменений.
Для поддержки уровня ИБ существует ряд стандартных операций. Каждый запрос на изменения связан с рядом параметров, которые определяют процедуру внесения изменений. Параметры срочности и степени воздействия могут быть дополнены параметром, связанным с безопасностью. Если запрос может оказать значительное воздействие на информационную безопасность, потребуются расширенные приемочные испытания и процедуры.
Мероприятия ИБ, связанные с внесением изменений, должны реализовываться одновременно с проведением самих изменений и тестироваться совместно.
Управление релизами
Процесс управления релизами осуществляет контроль и развертывание всех новых версий программного обеспечения и технических средств. Этот процесс гарантирует, что:
> используется соответствующее аппаратное и программное обеспечение;
> аппаратное и программное обеспечение тестируется перед использованием;
> внедрение надлежащим образом санкционировано с помощью процедуры изменения;
> программное обеспечение является легальным;
> программное обеспечение не содержит вирусов, и вирусы не появятся при его распространении;
> номера версий известны и зарегистрированы в CMDB процессом управления конфигурациями;
> управление развертыванием будет эффективным.
Управление уровнем сервиса
Процесс управления уровнем сервиса гарантирует, что договоренности об услугах, предоставляемых организации, определены и выполняются. В соглашениях об уровне сервиса должны учитываться меры ИБ. Целью этого является оптимизация уровня предоставляемых услуг.
Управление уровнем сервиса включает ряд видов деятельности, связанных с ИБ, в которых важную роль играет СУИБ:
1 определение потребностей заказчика в области ИБ;
2 проверка осуществимости требований заказчика;
3 предложение, обсуждение и определение уровня обеспечения ИБ ИТ-услуг в SLA;
4 определение, разработка и формулирование внутренних требований ИБ для ИТ-услуг (операционные соглашения об уровне услуг — OLA);
5 мониторинг стандартов ИБ;
6 составление отчетов о предоставляемых услугах.
Управление ИБ предоставляет управлению уровнем сервиса входную информацию и поддержку для осуществления видов деятельности с 1 по 3. Виды деятельности 4 и 5 функционируют в рамках СУИБ. Для вида деятельности 6 управление ИБ и другие процессы предоставляют необходимую входную информацию.
Управление доступностью
Процесс управления доступностью рассматривает техническую доступность ИТ-компонентов, связанную с доступностью услуги. Качество доступности определяется непрерывностью, ремонтопригодностью и устойчивостью. Так как многие меры ИБ оказывают положительное воздействие и на доступность, и на аспекты ИБ — конфиденциальность и целостность, существенно важной является координация мер между процессами управления доступностью, управления непрерывностью функционирования ИТ и управления ИБ.
Управление мощностями
Процесс управления мощностями отвечает за наилучшее использование ИТ-ресурсов организации. Требования к производительности основаны на количественных и качественных стандартах, определенных процессом управления уровнем услуг. Почти все виды деятельности процесса управления мощностями воздействуют на доступность и, следовательно, также на процесс управления информационной безопасностью.
Управление непрерывностью
Процесс управления непрерывностью ИТ-услуг гарантирует, что воздействие любых непредвиденных обстоятельств будет ограничиваться уровнем, согласованным с заказчиком. Основными видами деятельности являются определение, поддержка, внедрение и тестирование плана обеспечения непрерывной работы и восстановления функционирования, а также принятие превентивных мер. Из-за присутствия в этих видах работ аспектов безопасности возникает связь с процессом управления информационной безопасностью. С другой стороны, невозможность выполнения базовых требований безопасности может сама рассматриваться как чрезвычайное обстоятельство.
Нравится статья? Поделитесь с друзьями, нажав на кнопки соцсетей! Спасибо!
Источник: www.itsmonline.ru
