За годы работы на рынке безопасности автору довелось увидеть десятки предприятий и сотни различных процессных регламентов. Нефтеперерабатывающие заводы, страховые компании, ритейл, банки и много других… Единственное, что их объединяло – процессы кибербезопасности, как правило,  нигде не работали. В лучшем случае – процентов на 10, то есть 1-2 регламента из десятков. Среди топовых по бесполезности регламентов – контроль и согласование изменений в ИТ-инфраструктуре, аудиты ИБ, управление рисками ИБ.

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

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

ВРАГИ РЕЗУЛЬТАТИВНЫХ ПРОЦЕССОВ

Количество – враг качества в случае процессов безопасности. Чем больше параметров мы контролируем, чем больше подписей собираем, чем больше подозрительных событий расследуем, тем формальнее мы к ним относимся. Классическая байка «Волки-волки» применима в данном случае как никогда.

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

Внутренние аудиторы – чума корпоративных служб ИБ. Единицы из них имеют представление о безопасности больше, чем general computer controls, и их советы не только отдают нафталином, но и отвлекают ограниченные временные, человеческие и бюджетные ресурсы от актуальных угроз.

Регуляторы – вечный тормоз кибербезопасности. Появляются, когда угрозы поднимаются в полный рост, но после того, как передовые службы ИБ уже завершили десятки проектов по теме… Съедают весь бюджет, требуя применения решений, от которых «цифровые» процессы просто встают.

СОЮЗНИКИ РЕЗУЛЬТАТИВНЫХ ПРОЦЕССОВ

Спонсор процесса  – альфа и омега процесса безопасности. Если процесс никому не нужен, то не нужно его проектировать, внедрять и интегрировать с другими процессами. Сильным спонсором процесса может быть только зарабатывающее или управляющее подразделение. С различных «костов» (ИТ, АХО) выходят плохие спонсоры, они избавляются от ИБ при малейшем кризисе или проблеме.

Проектный подход. Обязателен для успешного создания и закрепления в корпоративной жизни процесса ИБ. Среди важных для внедрения процессов ИБ доменов проектного управления (по модели PMBook) – управление ожиданиями заинтересованных лиц (stakeholder management), управление объемом проекта (scope management), управление интеграцией проектных активностей (integration management) и управление коммуникациями.

Владелец процесса. Дает процессу возможность жить и развиваться. Бесхозный («сиротский») процесс проживет недолго – падет жертвой первого же сокращения костов, оптимизации корпоративных процессов или политических игр.

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

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

ОБЯЗАТЕЛЬНЫЕ ПРОЦЕССЫ БЕЗОПАСНОСТИ

Внедрение процесса ИБ должно дать компании максимум пользы и внедрить процесс максимально «бесшовно». Однако есть и процессы, без которых служба ИБ не сможет эффективно и стабильно выполнять свою задачу – защищать интересы организации в информационной сфере.

Управление политикой ИБ. Обязательно для определения «что можно, а что нельзя» делать с информационными активами организации. В практике автора бывало, что структуры с миллиардами долларов активов страдали от примитивных инцидентов типа «сотрудник унес жесткий диск домой», и этому сотруднику ничего не могли вменить – служба HR  думала, что инструктаж делает служба ИБ, а ИБ, – что HR.

Управление доступом. Обязательно, как с точки зрения любых стандартов ИБ (в том числе определенных законодательством как обязательные), так и с точки зрения здравого смысла: зачем сотрудникам знать больше, чем им требуется для выполнения должностных обязанностей? Правильно организованное управление доступом стимулирует бизнес брать на себя ответственность за свои информационные активы. Банально, не хочешь быть владельцем актива, значит, не имеешь права определять, кто получит к нему доступ.

Мониторинг и управление инцидентами ИБ. Просто дает реальную картину: что происходит в информационной инфраструктуре и системах организации. Дает факты: кто, что, где и как делал – пользователи, ИТ, автоматизированные сервисы, внешние нарушители и подрядчики… Без этого организация лишь догадывается о реальном состоянии защищенности своего информационного пространства.

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