«Нельзя: кликать, ходить, совать, открывать, качать…», или Итоги PHDays 2017

Продолжая тему, Тимур Юнусов (Positive Technologies) указал на то, что хакеры из числа «белых шляп» регулярно сообщают о найденных уязвимостях и средствах взлома, но обнаруженные проблемы не закрываются «пока гром не грянет».

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

По мнению Муслима Меджлумова (Ростелеком), проблема большинства организаций в том, что они вкладываются в технические средства, а не в компетенции – обосновать закупку вендорского «железа» оказывается проще, чем наем нескольких специалистов. Но технические решения не работают сами по себе, к тому же при наличии грамотных экспертов хорошую защиту можно построить на любых средствах, в том числе Open Source. Поэтому идти нужно по пути повышения уровня экспертизы собственной команды, а также повышения зрелости процессов обеспечения ИБ.

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

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

Защита приложений

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

Александр Баранов (НИУ ВШЭ) считает, что поскольку технологий безопасного программирования нет, а прикладная среда быстро меняется, защитить приложения раз и навсегда невозможно. Это процесс постоянный. Минимум, что необходимо — это инвентаризация ПО, удаление лишних программ, а также проверка того, чтобы приложения не связывались с Интернетом, если в этом нет необходимости.

Сергей Лебедь (Сбербанк) напомнил о концепции управления рисками: каждая организация может выделить ключевые объекты защиты и сосредоточить усилия на них.

О том, как решает проблему Ростелеком, рассказал Муслим Меджлумов. Оператор провел оценку рисков, разбил всю инфраструктуру на домены и субдомены и нарисовал карту угроз (уязвимостей для каждого домена). Максимум усилий по обеспечению ИБ отдается критичным системам. При проведении изменений в каждом домене обязательно, проводится анализ защищенности и пентесты. Затем происходит «работа над ошибками» и новые проверки — на регулярной основе. С разработчиками оператор договориться сумел. В рамках внедрения методологии Secure Software Development Lifecycle строится «цифровая песочница», которая сканирует приложение и его компоненты и дает возможность оценить его соответствие требованиям безопасности.

Интересным опытом поделился Андрей Ревяшко (Wildberries): за несколько лет количество заказов интернет-магазина возросло с сотен до сотен тысяч в день, большой ИТ-отдел не мог достаточно быстро и адекватно реагировать на запросы бизнеса. В результате проб и ошибок компания пришла к формату, который назвала «естественным Agile». До его внедрения в ИТ-отделе действовала служба единого окна, куда главы бизнес-департаментов подавали свои заявки на разработку того или иного функционала. Накапливалась очередь задач, сроки поджимали, у разработчиков не хватало сил и времени на повышение своей осведомленности в сфере ИБ, поэтому информационная безопасность «шла под откос».

Перейдя к практике Agile, компания вместо единого большого ИТ-отдела стала создавать небольшие (до семи человек), но полноценные (состоящие из специалистов разного профиля) ИТ-команды под задачи каждого бизнес-подразделения. Сегодня в компании действуют 20 таких команд, которые в месяц выполняют около 1,5 тыс. заявок со сроком реализации до 3 дней и 850 — более трех дней. Бизнес-руководители непосредственно принимают участие в разработке силами своей ИТ-команды и несут ответственность за результат. Они же «выбивают» бюджет. Поэтому исчезли попытки заказать лишний (ненужный, но модный) функционал, в то же время возросла заинтересованность бизнес заказчиков в повышении безопасности разработок: спрос за незакрытую уязвимость будет, опять же, с главы бизнес-департамента.

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

Вопросы информационного обмена

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

В любом случае, знать, что происходит «у соседей» будет полезно для любой организации. Сергей Лебедь поделился опытом посещения центра сбора и анализа информации об угрозах (Fusion center) крупного банка в США. Центр наблюдает, в частности, за сайтами всех основных поставщиков ИТ-решений банка, мониторит их доступность и сервисы и обновлений. Зачем? Затем, что если у поставщиков возникнут проблемы, они возникнут и у банка; а в случае атаки на банк, надо понимать, как быстро можно будет получить нужные обновления.

Есть рынок сервисов информирования об угрозах (Threat Intelligence Feeds). Их интеграция с корпоративной системой ИБ позволит использовать знания, накопленные экспертами во всем мире, для повышения эффективности собственной защиты. Но, подчеркнул Сергей Лебедь, прежде чем обращаться к средствам Threat Intelligence, нужно создать в компании необходимую базу: обеспечить мониторинг, управление рисками и инцидентами.

У Threat Intelligence Feeds есть оборотная сторона: к ним могут обращаться как защитники, так и нападающие. Поэтому часть информации из базы угроз должна распространяться ограниченно. Сергей Гордейчик выдвинул предложение создать единый ресурс в интересах участников российского рынка ИБ, куда поставщики ИБ-решений и сервисов могли бы поставлять информацию об обнаруженных угрозах. Чтобы это не противоречило коммерческим интересам поставщиков, в открытом доступе может размещаться часть информации (тем более, что у ряда компаний подобные открытые источники уже есть), а более детальная предоставляться на платной основе. Участники дискуссии идею поддержали.

Эволюция безопасности

Высказывая свое мнение на пленарной сессии «Безопасность и технологии: личный взгляд», Дмитрий Мананников (SPSR Express) акцентировал внимание на том, что безопасность эволюционирует вместе с окружающим миром. Ключевое изменение в мире — автоматизация, которая одновременно является и драйвером прогресса, и «слабым звеном». Любые процессы становятся все более технологичными. Меняется и формат преступлений — они уходят в цифру, и для борьбы с ними нужны технические знания. Поэтому все направления безопасности (физическая, экономическая) становятся, по сути, частью безопасности информационной. Казалось бы, ИБ должна стать во главу угла. Но этого не происходит: бизнес видит в ИБ ограничитель, а не помощника, и относится к ней только как вынужденной страховке. ИБ-службы постоянно сталкивается с нехваткой бюджетов. Ключевая мысль выступления заключалась в том, что индустрия ИБ должна научиться говорить на одном языке с бизнесом, а безопасность — стать не дополнением к любому продукту или процессу, а его неотъемлемой частью.

О том, как эволюционируют системы антифрода, рассказали на специальной экспертной секции Алексей Сизов и Евгений Колесников («Инфосистемы Джет»). Фрод — это яркий пример атаки на бизнес-процесс, в котором задействовано большое количество людей и технических средств. Антифрод-система должна уметь анализировать большие объемы текущих и исторических данных и помогать принимать решения в режиме реального времени. Соответственно, при создании таких систем не обойтись без технологий Big Data и анализа данных с применением экспертных правил и машинно-обученных моделей.

Но есть ли резон доверять выявление фактов мошенничества машине? Как отметил Алексей Сизов, большинство компаний считают, что аналитики способны разработать правила, позволяющие контролировать любое мошенничество. Зачастую это действительно так. Однако найдется немного компаний, способных нанять штат квалифицированных аналитиков, которые будут работать в режиме 24х7. Кроме того, многие заказчики заинтересованы не столько в замещении человеческого ресурса машинным, сколько в его подстраховке. Аналитики могут ошибиться или что-то упустить. К тому же создавать и модифицировать правила с учетом больших массивов данных машина способна быстрее и качественнее, чем человек.

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

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

Ответственность и вовлеченность

Культура информационной безопасности, ответственность людей, будь то разработчики, бизнес-руководители или рядовые пользователи, их осведомленность и мотивация к соблюдению правил ИБ — фактор, который нельзя недооценивать. Как можно мотивировать разработчиков и руководителей, показывает, например, упомянутый кейс Wildberries. Что же касается пользователей, то интересным личным опытом в этом вопросе поделился во второй день форума Алексей Волков (Сбербанк). Несколько жизненных экспериментов доказали, что можно прожить и без покупки ИБ-решений, достаточно выполнять несколько несложных правил. Сформулированы они были так: «Нельзя: кликать, ходить, совать, открывать, качать. Нужно: проверять, бэкапить, обновлять, осознать, вовлечься». Последние два пункта можно, пожалуй, назвать ключевыми. Пользователи должны осознавать последствия своих действий. Главное оружие против киберпреступлений — в головах людей.