От автора:
Данная статья рассказывает о том, как зарождалась информационная безопасность (далее - ИБ) Wooppay и о некоторых сложностях в жизни специалистов по ИБ, в процессе совершенствования систем безопасности.
Платёжная система Wooppay(далее — ПС Wooppay), как наверное и любой хайтек-стартап, обязана была позаботиться об ИБ компании до стадии запуска проекта в эксплуатацию, что, собственно, и было сделано. В последствии был сформирован отдел ИБ (далее - ОИБ), который, как поначалу показалось, получил право на «Здесь должно быть так, а тут так не пойдёт...», но нет, реалии таковы, что когда речь идёт о ПС, отдел ИБ обязан очень плотно взаимодействовать с отделом технической инфраструктуры (далее - ОТИ), отделом тестирования и отделом разработки, ну и в принципе со всеми подразделениями, где хоть как-то могут появиться свежие идеи, требующие внимания специалистов ИБ, для оценки рисков. Что касается взаимодействия ОИБ и ОТИ, то тут очень много точек соприкосновения (Управление доступом, Криптография, Телекоммуникационная и сетевая безопасность, Резервирование и т.п.), в общем-то с этого всё и начиналось. Однажды, в студёную зимнюю стужу... шучу, конечно-же). На дворе стояла жара, проект уже находился на стадии закрытого альфа-тестирования и, наконец-то, наступает момент, когда проект, согласно «best practices» (лучших практик - стандартов ИБ), следовало отдать на аутсорс пентест (тестирование на проникновение — моделирование действий (не)реального злоумышленника, как правило это инструментальное сканирование с ручной верификацией уязвимостей, направленное на оценку текущего состояния процессов обеспечения ИБ). Бытует мнение, что можно делать как Google, Firefox и другие компании, платя деньги за найденные уязвимости хакерам, но тут появляется слишком много «НО», а именно проблемы с тем, что нет гарантий, что нашедший уязвимость хакер будет вам сообщать о ней за положенные ему деньги, быть может, уязвимость в дальнейшем можно будет продать конкурентам за очень большие деньги или организовать атаку с дальнейшим вымогательством у компании крупных денежных средств, для её прекращения. Было решено - это слишком большой риск и обратились к признанным и экспертам по ИБ, компании «Positive Technologies», имеющим статус QSA Associate, позволяющий проводить работы в данной сфере.
Ну теперь, собственно, почему я упомянул про ОТИ? Как уже упоминалось в статье «Техническая структура Wooppay. Показать всё что скрыто», нами была построена гибридная инфраструктура (IaaS + ЦОД) и на момент тестирования компанией «Positive Technologies» в ТИ входило всего несколько Web серверов, что открывало нам возможность использовать для каждого сервера собственный ip адрес, а также свободу выбора решений, для защиты от атак типа DDOS и таргетинговых атак, средствами WAF (Web Application Firewall), собственно благодаря чему, мы успешно прошли внешний пентест.
Может быть у некоторых из вас возникнет вопрос, почему не отдать на аутсорс защиту от DDOS таким экспертам как «QRATOR» и «Cloud frame»?, ответ прост — для того, чтобы они могли фильтровать передаваемые данные, им необходимо передать ssl сертификаты, для дешифрирования https трафика, а следовательно, третья сторона увидит проходящие через них финансовые данные, что не запрещено мировыми банковскими системами, если осуществляющая фильтрацию данных компания имеет сертификат соответствия стандарту PCI DSS (Payment Card Industry Data Security Standard - стандарт безопасности данных индустрии платёжных карт), но это в двое увеличивает шанс утечки конфиденциальной информации — стандарты стандартами, а человеческий фактор ещё никто не отменял.
Время шло, проект постепенно подходил к стадии производственной эксплуатации, разрабатываемых решений становилось всё больше и мы начинали понимать, что никаких денег не хватит, каждый раз отдавать разработанные решения на внешний пентест, было решено — необходима собственная команда тестеров и пентестер, который попал в нашу компанию волей случая и благополучно обосновался в ОИБ. Также с течением времени начали появляться и другие, на первый взгляд, небольшие проблемы. От отдела ТИ, поступает информация о том, что производительности Web сервером уже не хватает и необходимо в срочном порядке увеличить количество серверов, так стоп..., но тогда у нас не хватит выделенных ip адресов и нам придётся пользоваться балансировщиками нагрузки предоставляемыми IaaS, что повлечёт за собой скрытие реального ip адреса клиента для всех сервисов системы, за исключением веб приложения, получающего его через заголовок XFF (X-Forwarded-For) и, соответственно, проблемы для систем безопасности, которые будут видеть только ip адрес балансера.
Проанализировав последствия, начали смотреть в сторону HAproxy(High Availability Proxy), но протестировав его в нашей ТИ, обнаружили, что он нам не подходит из-за многих нюансов, делающих HAproxy единой точкой отказа для нашей ПС, выбора больше не было, да и времени собственно тоже, решили остановиться на балансировщике от IaaS, надёжном и по быстродействию не уступающим HАproxy. Отдел ИБ идёт на уступки отделу ТИ — безопасность в угоду масштабирования. Отныне, ни iptables нами любимый, ни WAF с возможностью предотвращения атак нам больше никак помочь не могли. Было решено срочно разработать новые методы организации ИБ и решение не заставило себя долго ждать, инженером безопасности системы было предложено использовать язык Lua для создания высокопроизводительных сценариев обработки веб трафика, как в последствии показало тестирование, решение оказалось весьма удачным.
Думаю из выше написанного понятно, что все эти меры безопасности для пользователя мало заметны, да и большая часть взлома аккаунтов происходит, либо из-за социальной инженерии, либо из-за инсайдеров, которые за определённое вознаграждение или из-за некой обиды к работодателю, сливают информацию третьим лицам или стараются нарушить её целостность. В общем, понимая все последствия заранее, совместным решением с высшим руководством, было решено жёстко ограничить доступ лиц к информации и внедрить DLP (Data Lose Prevention - технологии предотвращения утечек конфиденциальной информации из информационной системы вовне) систему, но те, кто хоть раз работал с подобного рода системами, прекрасно понимают, что люди, которые имеют доступ к столь конфиденциальной информации наверняка с лёгкостью обойдут DLP систему, поэтому встала задача шифровать таблицы в базе данных и естественно в таких полях как пароли, хранить хэши от паролей. Ну и как можно уже было догадаться, в первую очередь это логирование и аудит всего, что только можно мониторить.
В общем то, писать можно долго про то что внедряли, что и как защищено, но хочется отметить следующие моменты: Организовать безопасность периметра, организовать безопасность передачи данных между серверами и ЦОД задача, конечно, не из самых простых, но и не из самых сложных, так как это задача разовая и требует лишь время от времени доработок и мониторинга, а вот безопасность приложения ПС — это один из ключевых вопросов, который включает в себя непрерывный процесс разработки — тестирования — пентеста — багфикса — тестирования — пентеста - ....
Хочется подытожить словами: Абсолютной защиты не существует, в любой ситуации всегда присутствует человеческий фактор, благодаря чему наши системы безопасности постоянно совершенствуются и совершенству их нет предела.
Данная статья является страшно секретной.
Пожалуйста, не рассказывайте о ней никому.
После прочтения статья самоуничтожится.
Руководитель отдела информационной безопасности Wooppay.