#Агент250: простой гайд по непростому указу

В прошлом году вышел указ президента РФ № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации». Если кратко, он заставляет топ-менеджеров компаний начать думать на языке кибербезопасности. Например, через механизм персональной ответственности за обеспечение ИБ, прописанный в пункте 2. При этом далеко не все детали указа № 250-ФЗ действительно понятны бизнесу.

Чтобы заполнить пробелы, Positive Technologies организовала в 2023 г. обучающий проект #Агент250. Цель — помочь заместителям генеральных директоров по ИБ, назначенным в рамках исполнения указа, разобраться в том, как построить результативную кибербезопасность. Мы объяснили, какие шаги необходимо предпринять, чтобы ИБ приносила компании понятный бизнес-результат. А сегодня, специально для тех, кто больше любит читать, чем смотреть и слушать, мы сделали гайд, в котором подсветим самые полезные моменты вебинаров #Агент250.

Вебинар «В поисках смысла: как правильно разговаривать с подразделениями ИТ и ИБ»

Как подружить CISO и топ-менеджеров

«Это было начало двухтысячных, я был инженером и приехал "внедрять тему" информационной безопасности в частную компанию, добывающую полезные ископаемые, — рассказывает Борис Симис, заместитель генерального директора по развитию бизнеса Positive Technologies. — Пришел к владельцу, говорю: "Перед началом работы хотел бы понять, какие риски вам релевантны, что вас тревожит в плане информационной безопасности". Он вздохнул и ответил: "Вот смотри: если сейчас налетит ураган и унесет все нефтегазодобывающее оборудование вместе с ангарами, с компьютерами, даже с людьми, я в течение месяца все восстановлю и добуду то, что не добыл. Так что меня вообще ничего не волнует". Я часто рассказываю эту историю, потому что за последние годы кибербезопасность перешла в совершенно другой статус. По мере роста зрелости и уровня цифровизации компаний их руководители уделяют все больше внимания ИБ».

Зачастую, когда руководители бизнеса приходят с запросом к ИБ-специалистам, начинаются проблемы. Как правило, они говорят на разных языках. В лучшем случае безопасники используют классическую рискориентированную модель, но для перестраховки закладывают в нее максимально возможное количество рисков. Бизнесу предлагается «заплатить 200—300 миллионов рублей, чтобы уменьшить вероятность чего-либо на 20%». Само собой, так просто на это никто не согласится. В худшем случае ИБ-эксперты приносят готовую спецификацию со словами «Нам нужно 350 миллионов рублей. На сто миллионов купим железо (хотим взять побольше решений вот этого вендора), потом VPN, а еще антивирусов. Кажется, на год хватит». Для бизнеса это звучит как «давайте мы что-то купим и внедрим». Ни о каком осязаемом результате речи не идет. Из-за этого ИБ-подразделение не получает необходимые средства, а диалог с бизнесом превращается в сломанный телефон.

Указ № 250 говорит, что бизнес должен заниматься практической безопасностью. При этом защититься от всего и сразу невозможно — хакеры всегда найдут лазейку. Важно сделать так, чтобы инциденты не приводили к недопустимым событиям, имеющим катастрофические последствия именно для бизнеса. Соответственно, строить систему обеспечения ИБ в компании нужно именно вокруг таких событий.

Сформировать перечень недопустимых событий могут только топ-менеджеры, прекрасно понимающие их критичность для своего бизнеса. В качестве примера Борис Симис привел риски Positive Technologies: «Мы переживем, если у нас украдут код, потому что в нем вряд ли кто-то разберется (а если и смогут, то серьезных рисков это не принесет). Но если злоумышленники смогут проникнуть в периметр компании, встроят в наш код бэкдоры и таким образом получат доступ к инфраструктуре заказчиков, это будет критично для бизнеса». 

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

Вопросы, которые топ-менеджер должен задать CISO

1. За что конкретно (за какой результат) ты несешь ответственность? CISO должен знать, какие события являются недопустимыми для бизнеса в данный момент, как их можно реализовать и какой ущерб при этом понесет компания. 

2. Каков реальный уровень защиты нашей компании? Зачастую топ-менеджерам показывают массу дашбордов с SLA, метриками по устранению уязвимостей, скоростью обнаружения инцидентов и прочими подобными показателями. Но что они значат? Как понять, насколько действительно защищена компания? Хорошим ответом со стороны CISO будет: «Мы приглашаем лучших хакеров, они пытаются реализовать недопустимые события, и у них не получается». Оценить уровень защищенности компании можно с помощью киберучений и выхода на платформы bug bounty.

3. Могут ли нас взломать прямо сейчас? Многие CISO боятся говорить, что компанию могут взломать, потому что в этом случае бизнес начнет искать виноватых. Это неправильно: ИБ-руководителям, которые не боятся прямо заявлять о проблемах, нужно давать индульгенцию и возможность исправить свои «грехи». 

4. Насколько мое понимание ИБ близко к реальности? Приведем пример. Представители одной энергетической компании были уверены, что даже если на электростанцию проникнет хакер, он не сможет нанести ей серьезный ущерб. Для этого нужно раскрутить турбину, но в нее встроен механический шпиндель, который препятствует чрезмерному разгону, вылетая при достижении определенной скорости. Однако при проверке объекта выяснилось, что механическое решение еще десять лет назад заменили на автоматизированную систему Siemens, которую хакеры запросто могут взломать.

Борис Симис перечислил главные ошибки топ-менеджеров в общении с CISO: 

1.    Мечтать, что все решится само собой. Иногда руководитель думает, что достаточно выделить денег, и все проблемы испарятся. Это не так — в современном мире эффективная кибербезопасность не строится без личного участия топ-менеджеров.

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

3.    Верить в мифы. «У нас все сертифицировано, мы прошли проверку регуляторов, значит, с ИБ в компании все отлично». Увы, это не так — сертификаты не гарантируют безопасность. 

4.    Думать, что защищать нужно все. Все — это слишком много и избыточно с точки зрения и финансовых затрат, и людских ресурсов. Поэтому нужно фокусироваться на важном!

Вебинар «Как повысить защищенность компании? Дорожная карта»

Отличия между SMB и крупным бизнесом

Архитектор по информационной безопасности Positive Technologies Михаил Кадер выделяет следующие отличия малого и среднего бизнеса от крупного с точки зрения построения ИБ:

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

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

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

Базовые советы

Защититься от всех атак невозможно, поэтому главная задача ИБ-подразделения — отрабатывать инциденты быстрее, чем они приведут к реализации недопустимых событий. Для этого нужно максимально усложнить путь злоумышленника. К примеру, если хакеры получили учетные записи пользователей из двух схожих компаний, но в одной из них используется 2FA, а в другой нет, очевидно, что он выберет более доступную жертву.

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

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

Еще один важный момент: если в компании используется Wi-Fi (а для SMB это постоянная практика), не забудьте обезопасить доступ к корпоративным ресурсам. Нужно выстраивать сетевую инфраструктуру так, чтобы с помощью Wi-Fi сотрудники могли пользоваться только внешними сервисами. Для доступа к корпоративным приложениям необходимо обязательно использовать VPN.

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

Ошибки при построении результативной кибербезопасности

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

Ожидания, что все получится с первого раза. «При проработке реальных карт кибертрансформации для заказчиков мы всегда закладываем в них промежуточные киберучения, — объясняет Михаил Кадер. — Таким образом можно определить точки доработки внедренных решений и связанных с ними процессов».

Нежелание заботиться о выстроенной системе кибербезопасности. Как показывает практика, ИТ-системы, недопустимые события и сам бизнес постоянно меняются. Поэтому важно постоянно проводить анализ киберзащищенности с учетом новых вводных. 

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

Вебинар «Собственный отдел ИБ vs. аутсорсинг: кто должен отвечать за кибербезопасность?»

«Я часто замечаю, что люди находятся в плену парадигмы "информационной безопасностью должны заниматься специально выделенные люди", — комментирует Алексей Лукацкий, бизнес-консультант по информационной безопасности Positive Technologies. — На самом деле есть и другие варианты. Например, можно распределить эти задачи между разными подразделениями или отдать на аутсорсинг. Подход нужно выбирать, исходя из специфики конкретной компании».

Как понять, подходит ли вам вариант с аутсорсингом? Для начала нужно ответить на простой вопрос: «Какого рода данные придется отдавать подрядчику?» Если речь о чувствительной информации, которой вы не готовы делиться, аутсорсинг исключен. Значит, проблему нужно решать внутренними ресурсами — формировать ИБ-службу или передавать ее функции ИТ-отделу. ИТ-специалисты вполне могут выстраивать средства защиты, заниматься мониторингом, сегментировать сеть и выполнять другие задачи, связанные с информационной безопасностью.

Если же вы готовы делиться данными и не можете сформировать собственную ИБ-команду, передайте вопросы безопасности в руки партнера. «Для большинства компаний ИБ — не профильная задача, поэтому не стоит бояться отдавать ее партнеру. Главное — наладить контроль», — добавил Алексей Лукацкий. 

На одного ИБ-специалиста (если нанимать его в Москве) нужно закладывать порядка 3 млн руб. в год только в фонд оплаты труда. Плюс не забывайте про закупку техники, обеспечение рабочих мест, приобретение ПО для защиты и другие сопутствующие расходы. Если планируете собрать полноценную ИБ-службу, рассчитывайте, что в среднем один сотрудник обойдется компании примерно в 10 млн руб. в год.

Вебинар «"Подушки безопасности": как защитить бизнес, который создает или предоставляет ИТ-продукты и сервисы»

Три причины, почему ваше приложение небезопасно

«Любая компания сейчас — технологическая, — уверен ведущий архитектор Swordfish Security Юрий Шабалин. — Большинство организаций создают что-то свое, используют или дорабатывают проприетарное ПО. Соответственно, практически любая компания на рынке может считаться технологическим бизнесом».

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

Есть несколько причин, почему даже хорошо написанные приложения небезопасны. Например, в них часто используются компоненты open source, которые могут содержать уязвимости. К тому же разработчики в первую очередь ориентируются на соответствие ТЗ, скорость работы и общее качество сервиса. Программисты — не ИБ-специалисты, поэтому они отодвигают безопасность на второй план. 

Как писать безопасные приложения

Обезопасить процесс разработки могут подходы DevSecOps и SSDLC. Да, ошибки все равно будут, но если заложить механизмы ИБ в саму архитектуру приложения, исправить их будет гораздо проще и дешевле.

«Если в компании не выстроен процесс безопасной разработки, реализация недопустимых событий становится делом времени, — комментирует Денис Кораблев, управляющий директор и директор по продуктам компании Positive Technologies. — Вопрос не в том, должен ли в компании существовать такой процесс, а в том, из каких именно компонентов он должен состоять.

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

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

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

«Я часто сталкивался с тем, что при внедрении процесса безопасной разработки люди забывали про слово "процесс" и начинали просто скупать ИБ-инструменты, — добавил Юрий Шабалин. — Это одна из главных ошибок: компания, не зная ничего о своей инфраструктуре, подходе к разработке и системах, сразу покупает продукт, на который начинает натягивать процесс. Сначала нужно разобраться, какие языки используются при создании продуктов, какие интеграции потребуются и так  далее. Только после этого можно думать о покупке инструментов».