Этичный хакинг

Аналитика и комментарии

клиентов провоцируют на совершение

Д. ЧЕРНОВ: «Самые слабые звенья в системе защиты – это люди и софт»


Несмотря на то что банки вкладывают огромные средства в совершенствование своих систем информационной безопасности, проблемы остаются: атаки злоумышленников продолжаются, при этом направлены они как на слабое звено (клиентов и сотрудников банка), так и на банковские системы, казалось бы, хорошо защищенные. О том, какова роль практической оценки защищенности, постоянного мониторинга событий ИБ и оценки защищенности ПО в минимизации рисков банков в сфере ИБ, рассказал в интервью NBJ руководитель отдела анализа защищенности ИТ-систем Центра информационной безопасности компании Инфосистемы Джет Даниил ЧЕРНОВ.
NBJ: Даниил, как сейчас обстоят дела с защищенностью банков в нашей стране?
Д. ЧЕРНОВ: С одной стороны, кредитно-финансовые организации исторически являются наиболее защищенными, поскольку ЦБ предъявляет к ним достаточно жесткие требования в части обеспечения ИБ. С другой стороны, даже самые большие вложения не могут обеспечить банкам стопроцентный уровень защищенности, так как всегда найдутся слабые звенья. облачные технологии и защита информации По статистике именно кредитно-финансовые организации, работающие с реальными деньгами, чаще всего подвергаются атакам.
NBJ: Что можно считать слабыми звеньями в системе защиты?
Д. ЧЕРНОВ: Первое слабое звено в системе защиты люди (клиенты и сотрудники). Второе − софт, через дыры в котором проходит большое число атак.

Сегодня это самый уязвимый технический элемент в системе защиты: по статистике основное количество успешных атак проходят через дыры в ПО.
NBJ: Что касается пользователей и клиентов: достаточно ли часто они становятся объектами атак?
Д. ЧЕРНОВ: Достаточно часто, и все чаще с использованием методов социальной инженерии. С помощью всяких уловок, иногда очень хорошо психологически просчитанных, клиентов провоцируют на совершение определенных действий, и злоумышленники в результате получают ценную информацию.

При этом пользователи (сотрудники банков) хотя бы проходят инструктаж: им объясняют, что можно делать, а что нельзя. А вот с клиентами в данном вопросе дело обстоит совсем плохо
NBJ: Но в последнее время банки делают большую работу, инструктируя и клиентов.
Д. ЧЕРНОВ: Да, но пока она не приносит должного результата. Люди, как правило, не воспринимают рекомендации банка по соблюдению ИБ всерьез.

Поэтому существенная часть клиентов попадается даже на самые простые удочки.

Например, в ответ на письма, якобы направленные банками, сообщают свои конфиденциальные данные, заходят по присланным ссылкам на фейковые сайты, имитирующие оригинальные сайты банков. В итоге клиент теряет деньги, банк неизбежно несет репутационные и финансовые (с учетом вступившего в силу ФЗ № 161) издержки.
NBJ: Возможно ли усилить названные слабые звенья так, чтобы атаки злоумышленников стали экономически невыгодными?
Д. ЧЕРНОВ: Если с пользователями и клиентами в целом все понятно (важно постоянно повышать уровень их понимания ИБ), то с программным обеспечением ситуация иная. проверить безопасность сервера В данном случае риски не очевидны, но вместе с этим весьма существенны. Итак, как повысить защищенность ПО?
Если взглянуть на данный вопрос локально, то самый верный путь проактивный подход. Приведу следующую аналогию: при постройке нового дома, вы рисуете план.

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

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

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

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

Они в первой группе риска, так как доступны для скачивания широкому кругу лиц. Больше всего уязвимостей мы находим в мобильных приложениях, работающих на платформе Android. Причем уязвимости не теоретические, а реально эксплуатируемые: используя их можно украсть у клиента деньги.
NBJ: Если говорить о превентивных мерах, с какой периодичностью, с Вашей точки зрения, надо проводить оценку защищенности ПО, мониторинг событий ИБ, а также оценку надежности средств защиты?
Д. ЧЕРНОВ: Оценку надежности средств защиты следует проводить планово (несколько раз в год) и внепланово (в случае возникновения изменений в инфраструктуре или в самих средствах защиты). При проведении оценки правильнее использовать не показатель работает не работает, а проверять, насколько надежным является средство защиты.

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

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

Учет места и временного промежутка показывает, что налицо инцидент. Но чтобы понять это и предотвратить нежелательный исход дела и для банка, и для клиента, сис мониторинга должна быть правильно настроенной это непременное условие.
NBJ: А эти сценарии должны быть настроены в системе изначально?
Д. ЧЕРНОВ: Наиболее распространенные дефолтные сценарии действительно заложены изначально, но этого недостаточно систему по ходу ее использования все равно надо донастраивать под конкретную среду.
NBJ: А как можно проверить надежность средства защиты?
Д. ЧЕРНОВ: Например, на компьютерах пользователей установлен антивирус. Как лучше всего определить его надежность как средства защиты?

Ответ очевиден: проверить, как антивирус справляется со своей основной задачей. Например, можно сформировать подборку из различных троянов и вирусов, по отдельности упаковать каждый из них и посмотреть, как антивирус справится с их обнаружением. проверить безопасность У нас есть отработанные методики для проверки различных средств защиты.
NBJ: То есть речь идет о так называемых penetration tests тестах на проникновение?
Д. ЧЕРНОВ: Не совсем. В данном случае речь идет о том, что реальную защищенность необходимо оценивать комплексно и практическими методами.

Тесты на проникновение лишь один из инструментов. В ходе тестирования на проникновение мы можем имитировать поведение различных видов злоумышленников.

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

Третья группа злоумышленников так называемые нелояльные сотрудники, их действия способны нанести банку наибольший вред. Именно от них организации менее всего защищены. В 95% случаев мы, имитируя действия таких злоумышленников, успешно ломаем систему защиты.
NBJ: По опыту компании Инфосистемы Джет, наибольшую сознательность в вопросе информационной безопасности проявляют крупные банки? Или размер здесь не имеет значения?
Д. ЧЕРНОВ: Вывод из строя системы или хищение важной для банка информации опасны для любой кредитно-финансовой организации, и совершенно не имеет значения, каково ее место в рейтингах. В любом случае она может понести репутационный ущерб.

Кстати, к нам обращаются с просьбой о проведении тестов на проникновение в том числе потому, что сотрудники ИБ желают продемонстрировать топ-менеджменту или собственникам актуальность проблемы. Как говорится, лучше один раз увидеть, чем сто раз услышать. Когда мы демонстрируем конкретные результаты теста на проникновение, руководители понимают, какими могли бы быть последствия, если бы атака была настоящей.
NBJ: Какие еще рекомендации Вы бы дали банкирам с учетом имеющегося у компании опыта?
Д. ЧЕРНОВ: В контексте нашей беседы я бы рекомендовал в дополнение к аудитам на соответствие требованиям регуляторов постоянно оценивать с практической точки зрения защищенность своих информационных систем. Это позволит понимать уровень безопасности и свое-
временно принимать меры по устранению выявленных недостатков. безопасность веб сервера Я рекомендую оценивать надежность имеющихся средств защиты помимо классических пентестов набором дополнительных тестов.

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

Похожие статьи Pentest

тестирование, тест, тестирования, безопасность, проникновение, система