Как сделать так, чтобы Ваш 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. Иметь свою "закладку" в базе - потенциально интересного для злоумышленника клиента, но не с настоящим номером телефоном, а с подконтрольным Вам - это позволит вовремя увидеть утечку и остановить её.

Итог

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

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

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

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