Блог

Менеджмент бумажной безопасности

• Цветков Максим
• 18.01.2023

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

Почему мы должны работать со стандартами, которые были написаны кем-то другим? Во-первых, стандарты написаны большими группами экспертов со всего мира и представляют собой накопленную мудрость, полученную на основе обширного практического опыта. Во-вторых, в некоторых случаях можно получить сертификат соответствия стандарту (например, ISO/IEC 27001), что придает дополнительную уверенность ключевым заинтересованным сторонам, как внутренним, так и внешним, в отношении уровня безопасности организации. В-третьих, следование хорошо принятому процессу может сэкономить много времени и усилий, а также снизить вероятность того, что ключевые шаги будут пропущены. В-четвертых, некоторые клиенты могут настаивать на соблюдении одного или нескольких стандартов в качестве условия ведения бизнеса.

Также, стандарты это норма для любой зрелой индустрии. Где-то 1980 на западе появилось понимание, что существуют кибер-угрозы, так как начали утекать государственные документы через сеть. В 1990 сформулировалась критическая инфраструктура, и коммерция в интернете, что значимо увеличило кол-во инцидентов в интернете. 2000-е можно охарактеризовать как гонку кибер-вооружений, хотя до сих пор кибер оружие никак не регулируется Женевской конвенцией. Индустрия растет, поэтому стандарты будут появляться, а необходимость им следовать — ужесточаться.

ISO 27001 и NIST

Две ключевые серии стандартов для ИБ это ISO 27001 и NIST. Есть и другие, которые легко отнести к ключевым, такие как PCI DSS, GDPR, SWIFT, 152-ФЗ, ГОСТ 57580, положения ЦБ, ОУД4, но давайте сосредоточимся на самых международных в рамках ИБ для корпораций. ISO 27001 дает терминологию, и понимание взаимосвязи, в дополнение к нему всегда идет ISO 27002 как каталог прикладных советов. NIST же принято использовать, когда достаточно пройти само-сертификацию, например, для достижения внутренних OKR. ISO 27001 подойдет, если требуется международная сертификация. Зачем она может потребоваться? Предположим, вы производите мясо для бургеров McDonald’s. И McDonald’s хочет быть уверен, что его поставщики смогут поставлять котлетки каждый день, без перебоев. Наличие сертификации у вас как у поставщика дает McDonald’s больше уверенности, что цепочка поставок не будет нарушена из-за инцидентов ИБ. При этом, стандарты не дают прямых указаний, какие именно ИБ-продукты должны быть использованы. ISO/IEC 27001 позволяет организации выбрать любой подход к управлению рисками, если он дает последовательные результаты и включает другие общие характеристики, указанные в ISO/IEC 27001.

Итак, нам нужен сертификат. Любая организация, желающая получить сертификат соответствия ISO/IEC 27001, должна пройти аудит в аккредитованном органе по сертификации. Если очень грубо суммировать, то ISO/IEC 27001 требует, чтобы организация внедрила и поддерживала программу аудита. UKAS публикует лист организаций в UK, которые прошли аккридитацию по 27001.

Шаги: первый шаг это ревью документации, точнее анализ правил, стандартов, гайдлайнов внутри компании. Вторым шагом идет аудит сертификации: проверка, что все описанное в первом шаге существует не для галочки, а на самом деле применяется. Третий шаг это анализ, т.е. проверка, что все документы соответствуют требованиям ISO 27001. И четвертый шаг это отчет по аудиту от аккредитованной организации, который кладется на стол топ-менеджменту. На этом не все, после получения сертификации формируется график проверочных аудитов.

Ниже перечислены основные шаги чуть более детально.

1. Первым шагом является обзор документации, а именно обзор политик, процедур, стандартов и руководящей документации организации, чтобы убедиться, что она соответствует целям, отвечает требованиям ISO/IEC 27001, пересматривается и поддерживается.
2. Сертификационный аудит — разновидность доказательного аудита (или полевой проверки) — предполагает активное изучение доказательств для проверки соблюдения политик, а также установленных процедур и стандартов.
3. На следующем этапе, анализе, аудитор оценивает результаты проверки документации и сертификационного аудита, чтобы подтвердить, что требования ISO/IEC 27001 выполняются.
4. Результаты анализа включаются в отчет об аудите, который предоставляется руководству.

NIST бесплатен, вы можете найти его по ссылке. NIST менее предписывающий, чем в ISO 27001. И не исключено, что более популярный, т.к. бесплатные стандарты обычно становятся более влиятельными, даже если они менее проработаны. NIST является обязательным требованием на федеральном уровне в некоторых штатах Америки. Всего у NIST 5 основных функций: идентифицровать, защитить, задетектировать, ответить и восстановить систему. Также, прописаны Tiers (уровни зрелости) от 1 до 4, где 1 это хаос, и 4 это сильная ИБ культура, т.е. градация от реактивных реакций на проблемы до настроенной безопасности на основе рисков.

Tier 1: Partial — менеджмент уязвимостей не формализирован, работа ведется на уровне ad hoc и реактивного подхода. Организация не понимает ценности ИБ.

Tier 2: Risk Informed — практики работы с рисками установлены, но не внедрены на уровне всей организации. Компания понимает важность работы с рисками ИБ, но работа ведется неупорядоченно и несистемно.

Tier 3: Repeatable — регламенты по ИБ согласованы и внедрены в работу. Уязвимости отслеживаются, обрабатываются по регламентированному процессу.

Tier 4: Adaptive — используются лучшие практики рынка, все изменения происходят быстро и эффективно.

И ISO 27001, и NIST CSF помогают создать ISMS. Более того, ISO 27001 содержит конкретные шаги, которые обязаны быть сделаны перед началом работы ISMS. Оба стандарта не указывают конкретные технологии, но дают общие рекомендации. ISO 27001 лучше для коммерческих компаний, потому что есть разделение на обязательную и необязательную документацию. И хорошо проработано распределение ответственности и обязательств. Но NIST более структурированный, и легок в понимании. Очень легко презентовать концепцию ИБ, которая по факту состоит из 5-и пунктов: Identify, Protect, Detect, Respond, и Recover. 

Другие стандарты

Существует огромное кол-во стандартов для различных индустрий. Незнание некоторых ключевых стандартов может даже вылиться в тюремное заключение или огромные штрафы для компании. Самый популярный и всем понятный пример это GDPR, но он не самый страшный. Если посмотреть на U.S. Sarbanes-Oxley — закон Сарбейнса-Оксли от 2002 года, то он требует, чтобы публичные компании применяли эффективные процессы внутреннего контроля финансовой информации, чтобы в случае возникновения нарушений можно было своевременно раскрыть информацию. Это необходимо для того, чтобы предотвратить обман общественности или финансовые ошибки. Такое требование применяется Комиссией по ценным бумагам и биржам США и распространяются на предприятия, расположенные на территории США, а также на любые предприятия, ведущие активную деятельность в США. Наказание за нарушение этого закона до 20 лет тюрьмы.

Если забыть про такие страшилки, все равно полезно знать о сущестовании стандартов в вашей индустрии. Не знаете, нужна ли вам сертификация? Существует ISO 27006, который дает рекомендации, кому и когда нужна сертификация. ISO 31000 подскажет про риск-менеджмент. 27007 и 27008 про ISMS.

Важный стандарт ISO 27031 про непрерывность бизнеса. Формально он называется «Руководство по готовности информационных и коммуникационных технологий к обеспечению непрерывности бизнеса». Однако стоит отметить, что ISO/IEC 22301 является более широким стандартом по управлению непрерывностью бизнеса для обеспечения безопасности и устойчивости. По стандарту ISO/IEC 27031, есть 6 шагов:

1. Определить сбой в системе
2. Выявить причины сбоя в системе
3. Оценить, какие усилия можно предпринять для предотвращения повторного сбоя
4. Применить изменения в системах
5. Записать результат выполненых действий
6. Ревью

Другой стандарт, ISO/IEC 27035, дает нам стандартизированное определение «инциденту информационной безопасности»: это одно или несколько связанных и идентифицированных событий информационной безопасности, которые могут нанести ущерб активам организации или поставить под угрозу ее деятельность. Но самое интересное в этом определении, что инциденты информационной безопасности могут относиться к одному или нескольким событиям, которые потенциально могут причинить различный вред — сейчас или в будущем. Это определение предполагает, что вред уже нанесен, а не потенциальный.

Второе полезное знание из ISO/IEC 27035 говорит нам, что есть три типа Incident Response Team: одиночный, иерархический, удаленный. Одиночные IRT обычно отвечают только за одну организацию; иерархические IRT обычно соединяют несколько IRT, которые сосредоточены на различных аспектах безопасности в больших организациях; и удаленные IRT обычно работают по принципу аутстафа/аутсорса.

Упомянутый выше сборник советов 27002:2022 содержит замечательный блок organizational control, в котором прописаны инструкции для политик. Также, описаны превентивные и реактивные инструменты (они также делится на детектирующие и корректирующие). И глубже, корректирующие инструменты делятся на response и recovery.

А если нам нужно выстроить линию обороны, то модель COSO нам предложит аж три уровня защиты:

1. первая линия обороны — те, кто работают непосредственно с клиентами, способны уменьшать риск, оценить риск.
2. вторая линия обороны — независимая оценка рисков, и контроль первой линии.
3. третья линия — внутренний аудит, отчитывается напрямую совету директоров, контролирует первую и вторую линии обороны.

Риски

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

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

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

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

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

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

Далее, необходимы инструменты для полного избавления от риска, или хотя бы его смягчения. Условно, если мы боимся, что база данных может улететь в интернет, то базу надо шифровать. Или, риск что обиженный сотрудник удалит важный файл. Тут нужно внедрить персональную ответственность за действия, вплоть до уголовной. Можно официально принять риск и ничего не делать; просто официально подтвердить, что риск небольшой и шанс его возникновения низок. Либо, полное уничтожение риска: если использовать SFTP неудобно и эту функцию можно безболезненно убрать из системы, при том что риски, связанные с SFTP высоки — мы просто выпиливаем SFTP из продукта.

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

• корректирующий контроль должен снизить риск, если детективный контроль не сработает;
• превентивный контроль должен снизить вероятность того, что корректирующий контроль когда-либо придется использовать;
• детективный контроль должен снизить риск, если превентивный контроль не сработал;

И уменьшение риска через нормальное исполнение рабочих обязанностей, банально, брандмауэр обязан быть настроен следующим образом:

• изменить административные пароли по умолчанию на надежные и уникальные пароли (см. аутентификация на основе пароля) — или полностью отключить удаленный административный доступ
• предотвратить доступ к административному интерфейсу (используемому для управления конфигурацией брандмауэра) из
  из Интернета, если только нет четкой и документированной деловой необходимости, и интерфейс не защищен
  защищен одним из следующих элементов управления:
  o многофакторная аутентификация
  o список разрешенных IP-адресов, который ограничивает доступ к небольшому диапазону доверенных адресов в сочетании с
  с правильно управляемым подходом к аутентификации с помощью пароля
• блокировать неаутентифицированные входящие соединения по умолчанию
• обеспечить утверждение и документирование правил брандмауэра для входящих соединений уполномоченным лицом, и
  включать в документацию бизнес-потребности
• быстро удалять или отключать ненужные правила брандмауэра, когда в них больше нет необходимости

Все знают про SaaS-сервисы, но на самом деле есть и другие типы предоставления услуги как сервиса: IaaS, PaaS, SaaS. Например, фаервол или антивирус должен быть установлен и на стороне сервис-провайдера, и на ваших клиентских машинах, если речь про IaaS (Infrastructure as a Service). Это тоже уменьшение риска.

Все это звучит, как необходимость установить множество программных решений от разных вендоров. Что, безусловно, дорого, и мы не хотим переплачивать. Избежать имплементации одинаковых решений в рамках одной компании и контролировать финансовые затраты помогает ISMS. ISMS это источник правды про всю информацию в организации. Формируется специальный документ, SoA (statement of applicability), который должен содержать причины включения или исключения каждого контрола из ISMS. SoA позволяет аудитору понять, что ISMS работает эффективно. Если кому то нужно найти регламент, инструкцию, информацию о сотруднике — все должно быть в ISMS. Например, в ISMS может/должен быть прописан Recovery Time Objective (RTO) — период времени, в течение которого минимальный уровень обслуживания клиентов должен быть восстановлен после неблагоприятного события. Также, ISMS должен содержать информацию об всех ассетах организации, и кто за них отвечает.

Под ассетами я подразумеваю инвентеризацию: информация, каталог сотрудников, устройства, назначенные на сотрудников, физические и виртуальные серверы, прочие сетевые устройства, устройства, которые необходимо для функционирования инфраструктуры (ICT, насосы и разветвители для кондиционирования воздуха, генераторы, бесперебойники), + CMDB.

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

И один из вариантов таблички для описания кибер-риска:

Функции	Категории	Субкатегория	Референс
Identity	Identity Management and Access Control	External information systems are catalogued	Informative references
Protect	Categories	Subcategory	Informative references
Detect	Categories	Subcategory	Informative references
Respond	Categories	Subcategory	Informative references
Recover	Categories	Subcategory	Informative references

Витальное

Национальная безопасность это очень сложный вопрос. Но то, что вода должна поступать в квартиры, а больницы должны быть обеспечены электричеством — неоспоримый факт. А ведь сложность систем для таких задач это systems-of-systems, с красноречивой аббревиатурой SoS.

Мы поговорили про компании, но ведь еще есть государства, зачастую именно они спускают нам требования с помощью стандартов и сертификаций. На любой сервис, который обеспечивает услуги государства, найдется свой стандарт, зачастую за авторством ISO или CENELEC. За электричество отвечает IEC, ETSI пишет стандарты для Европы про телекоммуникации. Идентификационные карты — B10 , кибер-безопасность — CS1, биометрия — M1, технологии радиочастотной идентификации — T6.

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

• Установите и поддерживайте конфигурацию брандмауэра для защиты данных о держателях карт.
• Не используйте для системных паролей и других параметров безопасности значения по умолчанию, установленные поставщиком.
• Защищайте хранящиеся данные о держателях карт.
• Шифруйте передачу данных о держателях карт через открытые, публичные сети.
• Используйте и регулярно обновляйте антивирусное программное обеспечение или программы.
• Разрабатывайте и поддерживайте безопасные системы и приложения.
• Ограничьте доступ к данным о держателях карт в зависимости от служебной необходимости.
• Присваивайте уникальный идентификатор каждому лицу, имеющему доступ к компьютеру.
• Ограничьте физический доступ к данным держателей карт.
• регистрировать и контролировать весь доступ к сетевым ресурсам и данным держателей карт.
• Регулярно тестируйте системы и процессы безопасности.
• Поддерживайте политику, касающуюся информационной безопасности, для всего персонала.

А вдруг стандарта все еще нету? И тут возникает дилемма для производств. В мире ИБ, специалисты могут определить MBCO — минимальный уровень сервиса, который приемлим для организации, чтобы продолжать функционировать. Но достаточно ли это для завода? Восстановить из бекапа сервер можно, а как восстановить природу после утечки отходов? Это куда сложнее и дороже. Здесь мы можем чуть подумать, чем отличается киберустойчивость от кибербезопасности. Кибербезопасность фокусируется на информационных технологиях, в то время как киберустойчивость описывает способность организации прогнозировать, предотвращать и предупреждать возникновение кибер-рисков. Киберустойчивость использует более широкую перспективу в сравнении с кибербезопасностью, рассматривая, как киберриски могут угрожать выживанию всей организации, и как они влияют на бизнес-процессы. Причем, не нужно ждать требований от государства, обеспечение надежности на опасных производствах начинается с de facto, и лишь спустя время переходит в de jure на национальном, или даже интернациональном уровне.

Люди, а не документы

ИБ в настоящий момент больше сосредоточена на людях, нежели на технических решениях. Не важно, насколько хороши ваши средства защиты, если сотрудники уверенно кликают на любые ссылки из электронной почты. И первое желание любого руководителя это ввод строгих правил, чтобы сотрудники боялись сделать лишнее действие. Но проблема в том, что это всегда уменьшает продуктивность. Низкоэффективные сотрудники редко получают повышение в карьере или зарплате, поэтому они начнут ломать правила для увеличения своей продуктивности. На этой ноте нужно обратиться к еще одному стандарту, ISO 9241–11:2018, который про юзабилити. Он содержит в себе три ключевых слова: effectiveness, efficiency, satisfaction. Эти критерии также коррелируют с принципами дизайна Kerckhoffs and Saltzer & Schroeder’s, то есть, ИБ не должно ущемлять качество жизни сотрудников и ломать goal-driven культуру.

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

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

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

В противоположность, существует позитивная безопасность, которая описывает чувство благополучия, основанное на доверительных отношениях между людьми. Вы все правильно поняли! Позитивная безопасность часто относится к тому, как люди могут быть поддержаны путем построения доверительных отношений между людьми, которые способствуют благополучию. Это может включать в себя финансовую безопасность или чувство доверия и поддержки со стороны местного сообщества или компании. Мы должны думать о позитивной безопасности как о предоставлении «свободы» делать что-то, обеспечивая необходимые условия для этого. Чтобы сотрудники не боялись, а хотели защитить компанию. В этом случае, безопасность начинается с отдела HR. Я понимаю, что доверие и ИБ на первый взгляд, выглядят как взаимоисключающие понятия. Но опытные ИБ-специалисты знают, что прочные и позитивные социальные отношения между людьми, основанные на предыдущем опыте — ключ к безопасности. Способность людей строить прочные и позитивные социальные отношения между собой и в рамках организации сложно переоценить. Это часто поддерживается чувством лояльности и поддержки между людьми и организациями, уверенностью в том, что меры контроля будут справедливо и надлежащим образом применяться во всех подразделениях организации, и что, по сути, организация заботится о людях. И если какие-то меры контроля были введены, значит, это необходимая мера не против людей, а ради их блага.

Как другая аналогия, в ИБ есть понятие целостности информации. Но целостность относится как к информации, так и к профессиональной честности людей на работе. Это важно, так как вселяет уверенность в том, что организация будет иметь последовательную информацию, что с людьми будут обращаться справедливо, и что это приведет к большей предсказуемости результатов по ряду вопросов (технических и нетехнических).

Раз уж мы говорим про людей, нельзя не упомянуть EDI assessments, которое расшифровывается как… equality, diversity и inclusion. Не спешите закрывать статью, потому что не от нас зависит кол-во людей разных этносов и полов в компании (я надеюсь). Для нас это данность. Но разные по культуре люди требуют различных подходов к обеспечению безопасности. Управление безопасностью может использовать оценки EDI, чтобы помочь разработать и реализовать управление безопасностью для различных людей. Это может означать внимание к различным аспектам использования софта, допустимости хранения персональных данных и тому, как обеспечить, чтобы управление безопасностью не ставило в привилегированное положение один способ работы или жизни.

Поэтому, перед тем как внедрять новые строгие правила в качестве реакции на инцидент ИБ, постарайтесь ответить на вопросы про людей:

• Какой инструмент они используют (и какие потенциальные проблемы поведения пользователей вам необходимо учесть)?
• Что они делают (и что они могут делать)?
• Где они это делают (как контекст повлияет на их способность выполнить задачу)?
• Когда они это делают?
• Почему они это делают (факультативно или обязательно)?
• Как они это делают (какие устройства они используют)? Сквозной темой здесь является то, что необходимо соблюдать соображения безопасности, поэтому следует добавить:
• каковы требования безопасности действий пользователя?

И тогда сотрудники не будут воспринимать в штыки новые меры по обеспечению безопасности.