С нами этого никогда не случится!
Пару лет назад приобщился к увлечению ходить в горы. Сейчас осваиваю пятитысячники Кавказа, в планах семитысячники Памира. Каждый раз перед поездкой возникают споры среди участников похода: "Надо ли брать с собой каски или ну ее, только лишний вес. Брать ли ледобуры для страховочных станций на случай срыва участника в трещину на леднике? Правда, это еще по 300 грамм – ну нет, связкой обойдемся!" Попытки аргументации в пользу безопасности, ссылки на статистику страховых случаев не всегда звучат убедительно. Мы уверены: "С нами этого никогда не случится!"
Это происходит оттого, что отношение к рискам, опыт наблюдения которых сам не пережил, не рационально. Побеждает стремление оставаться в зоне комфорта.
Перенасыщение рынка средств защиты для конечных точек сети вынуждает производителей разрабатывать новые ниши. Интерес вендоров пал на платежные pos-терминалы в крупных ритеил сетях. В качестве рекламной аргументации традиционно используются отсылки к требованиям регуляторов. Пока, на PCI DSS. Публикуются исследования как новые вирусы со звучными названиями покушаются на содержимое буфера платежных приложений с целью получить доступ к данным банковских карт.
"Это у них в Штатах карты без чипов, у нас все данные шифрованные. Кому они нужны?"
В 2015 году специалист по безопасности Karsten Nohl компании Security Research Labs продемонстрировал эксплуатацию уязвимости в протоколе передачи данных, по которому pos-терминалы передают данные банковских карт. В репортаже RT наглядно было показано как исследователи получили доступ к данным карты, в т.ч. пинкоду, и даже клонировали карту. Карта была с EMV.
Как заявил исследователь, эксплуатация уязвимости позволяет также изменить тип транзакции, размер платежа, а также подделать транзакцию, подменив ответ об успешной авторизации транзакции.
"Раньше мошенники использовали уязвимости в программном обеспечении. Для устранения проблем требовалось просто загрузить обновление. Мы взламываем сам протокол, то есть устройство работает в нормальном режиме, но при этом остается уязвимым. В результате данную проблему нельзя решить с помощью патча - придется перенастраивать всю систему", - пояснил Нол в интервью изданию Motherboard.
"Те, кто несет ответственность за пробелы в безопасности, в том числе банки, признают существование проблемы, однако принимать меры для ее решения не спешат. Они говорят, что подобных случаев мошенничества пока не зафиксировано, но ведь это лишь вопрос времени! Своим бездействием они только усугубляют ситуацию", - подчеркнул специалист. Подробнее.
Специалистам по безопасности inhouse приходится преодолевать скепсис менеджеров от бизнеса в вопросах обоснования необходимости защиты от угроз, которые наблюдать приходилось, пока, только в статьях в популярных отраслевых изданиях. Настойчивость, скорее, не приветствуется.
Аргументы бизнеса и более статусных в техническом блоке ИТ-подразделений звучат весомее:
- итак все на соплях держится, только антивирусов на кассах не хватало!
- у кого ты такое видел? У нас разве такая система?
- мы тут за консалтинг как кассовое пространство организовать и выиграть секунды на чек ТАКИЕ бабки вливаем, а ты антивирусами все поломать хочешь!
Аргументы весьма обоснованы. Современные антивирусы в режиме постоянной защиты ощутимо влияют на производительность компьютера. Задача антивируса: старт каждого процесса перехватить, проверить стартующий процесс по сигнатурам, сверить активность процесса с правилами политик контроля. А если еще и трафик сканируется, то задержек не миновать.
Процессы на кассовых компьютерах, подключенных к специализированной периферии, зачастую, весьма чувствительны к таймингам выполнения сценариев обработки команд от подключенных устройств. Большое количество функциональных драйверов «сидящих» на com службах также делают устройство весьма капризным в части задержек.
Стоит ли в таком случае устанавливать на столь чувствительную систему средства программной защиты?
Правильно настроенная система уже защищена от попыток деструктивного воздействия. Важно лишь сохранить такую конфигурацию в процессе эксплуатации. Почему же мы не можем обрести счастье?
Потому что новый бизнес-функционал платежных приложений и, соответственно, новое ПО и обновления ставить надо. И если на тестовых стендах в лабораторных условиях инженер все сделает "как надо" по инструкции, которую он же и написал, то "в поле" практика внесения ПО может отличаться:
- не тот образ развернули на некоторой части сети устройств;
- при исправлении возникшей коллизии переустановили драйвера и не поменяли запись upperfilter на com службах – что-то из периферии стало работать иначе;
- сделали конфигурацию как привыкли, а не как написано в инструкции;
- стали исправлять как велит "здравый смысл" и совет на форуме bankomatchik'ов – получилось "даже лучше", чем хотели.
Работает! Остальное не в зоне ответственности инженера по эксплуатации.
Отследить последствия такой, замечу, весьма распространенной практики при дальнейших эксплуатационных воздействиях невозможно.
Что будет если поставить средство программной защиты с "эталонными" настройками с тестового стенда на такую систему предсказать сложно.
Производители средств защиты, не дочитав статью до конца, тут же напишут комментарии: «зачем вы про антивирусы на кассах пишите! Зловреды для таргетированных атак пишут на заказ, они не попадут к аналитикам, в сигнатурах про них ничего не будет! Защита по "черным спискам" здесь не сработает! Нужны "белые списки" и контроль целостности процессов!"
Технологии "белых списков" действительно хорошо себя показали, например, на банкоматах. Технология уже не пионерская, годы эксплуатации позволили набить шишки и адаптироваться к особенностям эксплуатации на разнородной инфраструктуре весьма сложных устройств.
Есть примеры и неудачных проектов с «белыми списками» у разных производителей. Причина, по моему мнению, в ошибочном представлении, что можно реализовать защищенное состояние сети устройств, каждый раз перезаливая новым "эталонным" образом.
Однако оптимизация практик эксплуатации неизбежно приведет к смене методологии на внесение изменений в ПО и настройки защиты централизованно и удаленно. И здесь кроется острый подводный камень. Большинство существующих средств программной защиты основанных на "белых списках" работают по контрольным суммам и сертификатам исполняемых файлов, которые занесены в правила контроля приложений. Совпадает параметр процесса с правилами – процесс стартует. Нет – блокируется.
Что будет если при включенной защите попытаться заменить исполняемые файлы инсталлятором или самообновлением? Средство защиты заблокирует попытки изменений контролируемых процессов. Обновление, новое ПО установлено не будет.
А если отключить средство защиты на время установки нового ПО? При включении защиты драйвер не даст стартовать новым процессам, их новых параметров нет в правилах. Устройство зависнет и перезагрузки не помогут.
Как показала практика, уже спустя 1-2 квартала сеть устройств остается с выключенной защитой, так как доступность сети для бизнеса приоритетнее, чем ее защищенность.
В таких условиях обслуживания сети устройств хорошо показала себя практика внедрения режима безопасной эксплуатации ПО. Изменения в процессы вносятся в систему только доверенными инсталляторами, например, с цифровой подписью от доверенного издателя. Все изменения, вносимые в процессы доверенными инсталляторами, автоматически вносятся в правила контроля процессов: изменяются записи о соответствующих процессам контрольных суммах и сертификатах. Возможность централизованного мониторинга результатов отработки таких инсталляторов, изменения правил позволяют сделать процесс эксплуатации ПО на сети устройств легкоуправляемым, предсказуемым по результатам и безопасным.
Слабым местом в такой методике является дисциплина исполнения регламента выполнения инженерами работ «в поле» на выездах. Например, для замены периферийного устройства требуется установить новый драйвер. В случае, если инженер приехал на выезд с набором дистрибутивов, отличающимся от одобренных службой контроля, с флешкой, не внесенный в "белый список" одобренных подключаемых устройств, то либо инженер развернется и поедет в офис за «правильными лекарствами», либо таки уговорит по телефону знакомого администратора временно отключить удаленно защиту на устройстве. И как только он покинет объект, и администратор включит защиту, - касса повиснет. Признание «заговорщиков» получить своевременно будет не просто, а причину зависания кассы расценят как ложное срабатывание защиты. SLA по регламенту восстановления кассы жестче, чем необходимое время для разбора инцидента по логам действий администратора и инженера.
Красиво написанные дорогими специалистами по PR статьи про новые угрозы, нависшие над pos-терминалами, красочные публикации в деловых СМИ о последствиях атаки шифровальщиков на сеть кассовых терминалов у соседей, со временем, неизбежно повлияют на мнение о необходимости защиты сети кассовых комплексов в крупных ритеил сетях.
Когда-то и на банкоматах средства защиты также были экзотикой. "Сеть изолирована, каналы шифруются. С нами этого никогда не случится!" Сейчас защита на банкоматах продиктована регуляторами, что способствует развитию новой ниши рынка у производителей средств программной защиты. Лишь около 50% проектов постинцидентные.
