Как сделать так, чтобы Ваш IT-отдел не стал местом утечки информации, за которую Вы отвечаете?

Этим вопросом задается всё больше и больше руководителей разного уровня. На фоне происходящих "громких утечек" в оценке рисков IT-проектов появляется графа с суммой рисков по утечкам информации. Я не знаю доподлинно, отказывались ли на момент сегодня от инвестирования в проекты с сомнительным статусом таких рисков, но от нас, как от подрядчика, требуют эти риски снижать.

В чем именно риск? Утечка может привести к разным последствиям:

  • К проверкам и прямым штрафам от контролируюших органов. Это очень явно, суммы штрафов можно вносить в графу рисков.
  • К негативному влиянию на бренд и снизить результаты маркетинга через "утрату доверия". Это не так явно и зависит от "щепетильности темы". Например, утечка списка посетителей гей-клуба в России с участием публичного лица в этом списке - это большая сумма, которую можно отсудить, а так же при перегибе процесса в сторону публичного лица еще и возможное привлечение за клевету. Это бизнес-специфичный риск и не всегда явный.
  • К использованию средств клиентов (для онлайн-сервисов с наличием предоплат/депозитов). Здесь сумма рисков фактически равна объемам продаж и массовая реализация рисков очень опасна.


Как защититься и как вообще работает защита?

Любая безопасность - это в первую очередь система. Система, разделяющая угрозы и борящаяся с помощью средств, предназначенных для своего класса угроз.

В случае современного Web имеется глобальное разделение:

  1. Угрозы случайные (боты и сканеры)
  2. Угрозы вредоностного ПО и закладок (80% от реальных случаев утечек)
  3. Угрозы преднамеренные и целенаправленные (например, DDoS в жестких конкурентных условиях)
  4. Угрозы человеческого фактора (например, неудачное добавление роли в RBAC после релиза).


Как же отделить угрозы одну от другой на техническом уровне?

Для начала, Вам требуется понимать способы работы и признаки этих угроз:

1. Боты выполняют сканирование с целью поиска уязвимостей и часто используемых паролей. Поведенческие признаки ботов, выполняющих такое сканирование, известны и имеются продукты, защищающие от них. Я говорю и о догостоящих средствах, таких как WAF (хотя это и очень эффективное средство) и об открыто-доступных конфигурациях (например, для nginx). Принять меры по отсечению ботов нужно для того, чтобы отсечь огромный поток мусора, закрыться от "случайных типовых дыр" и облегчить работу над остальными угрозами.

2. Угрозы вредоносного ПО - это не просто поиск вирусов путем сканера. Вот такой код на PHP является однозначно вредрносным и так же однозначно им не является:

@eval($_REQUEST['c']);

Но на момент 2018-12-15 не находится ни одним сканером.


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

Совет любому хакеру звучит примерно так: "в любой непонятной ситуации пиши библиотеку и выкладывай на github".

Защита от таких уязвимостей выполняется двухкаскадная:

На уровне доступа - любое приложение принимается потенциально взломанным и должно иметь доступ только к необходимым для его работы данным и только по сети.

На уровне хранилища данных (СУБД) - любое новое (не замеченное ранее) поведение считается началом утечки и пресекается.

Антивирусные сканеры полезны. Для зачистки результатов старых взломов, для минимизации "шума алертов", для снижения нагрузки на аналитику поведения в хранилище данных. Так же они закрывают свой спектр задач - заложенные вирусы и бекдоры, еще не начавшие активную работу.

Обычно закладки и вредоносное ПО пишут не с целью взломать именно вас. Это как рыбалка - забрасывается тысяча крючков и на каком-то из них оказывается хорошая рыба.

3. Угрозы преднамеренные и целенаправленные - это совершенно другая задача. Для того, чтобы понять как она решается, нужно понять, что будет делать злоумышленник и зачем. Преднамеренные атаки бывают совершенно разные - от DoS/DDoS в высококонкурентной среде,  публикации "грязного белья" или "черной документации", до "публикации логинов и паролей ваших клиентов" в ситации выхода на избыточный предложением рынок нового игрока. В этой статье я разберу лишь один пример - получение доступа к логинам и паролям пользователей.

В первую очередь, развею миф - шифрование Вас не спасет. Вы можете как угодно и какими угодно алгоритмами шифровать пароли пользователей, хешировать их и т.п.. Современная статистика такова, что раз в 1-2 года находятся математические методы взлома алгоритмов шифрования. Это обозначает лишь одно - выкраденная зашифрованная база выстрелит не прямо сейчас, а через 1-2-3-4 года. Такая перспектива не радует и поэтому системы авторизации требуется изолировать не на уровне шифрования, а на уровне доступа к ним. Микросервисная архитектура позволяет отделить код и базу подсистемы авторизации от других систем. На уровне балансировщика http (например, nginx очень удобен) описать допустимые и недопустимые запросы.

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

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

Главное помнить, что шифрование - это "последний край" и "крайние меры" в защите информации. Полагаться только на шифрование никак нельзя.

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

4. Угрозы человеческого фактора - в первую очередь, это внутренние угорозы, исходящие изнутри компании, от её сотрудников, администрирующих и пользующихся Вашим online-сервисом, а так же от разработчиков этого online-продукта.

Здесь также важно разделение, но не с целью что-то усложнить, а наоборот - с целью упростить жизнь Ваших сотрудников. Программист или системный администратор не дожны думать о безопастности, решая свою задачу - они просто "забьют болт" на безопасность с целью выполнения своих непосредственных задач. Специалист по безопасности - отдельный человек. Его задача - выстроить систему (из железа, сети, систем и Людей) такой, чтобы люди не должны были задумываться в процессе своей работы о безопасности, уязвимостях и дырах.

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

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

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

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

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

Как защититься от таких проблем и при этом не заниматься личным контролем всего (не быть самому тем единственным человеком, который сам себя не предаст)? Вообще, способов много:

  1. Не держать яйца в одной корзине, распределять корзины географически.
  2. Если ценность одной из имеющихся "корзин с яйцами" велика (а это почти всегда так), то она должна быть неподъемной.
    CRM с фукнцией экспорта всех контактов (или экспорта произвольной информации) - очень удобная для злоумышленника CRM. Такая функция должна ограничиваться правами и ролями.
    CRM, в которой находится мало клиентов, не составляет сложностей даже в отсутствие экспорта (всех можно просто обзвонить с личного телефона) - живых клиентов должно быть много, тогда увод нескольких не испортит ситуацию, но будет вовремя замечен.
    CRM, в которой все имеют доступ ко всем данным, так же удобна для того, чтобы её унести.
    К любой CRM полный доступ есть у системного администратора, а значит, это должен быть человек, финансово не заинтересованный в уводе клиентов от Вас. Здесь есть варианты: либо это крупный подрядчик, либо сотрудник, мотивированный внутри компании.
  3. Иметь свою "закладку" в базе - потенциально интересного для злоумышленника клиента, но не с настоящим номером телефона, а с подконтрольным Вам - это позволит вовремя увидеть утечку и остановить её.

Итог

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

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

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

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