Перегибы безопасности

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

Почему-то иногда считается, что безопасность можно обеспечить, если внедрить все контроли, которые можно придумать, а если их еще внедрить в наиболее жестком варианте, то будет еще круче, хотя это напрямую противоречит принципу компромиссности, отмеченному выше (следует также добавить, что в условиях крупной корпорации, критерий управляемости выходит на первый план, по сравнению с качеством продукта безопасности. Простой пример: прекрасный антивирус, с максимальным % корректного определения\лечения зловреда, но не управляемый удобно и надежно в сети из 6000+ рабочих станций не будет иметь шансов в крупной корпорации – обслуживать вручную столько инсталляций невозможно). Но, самое ужасное, что такие контроли приводят к «перегибам», что снижает безопасность, что я и попытаюсь передать в этом посте.

1. «Высокий уровень сетевой безопасности в локальной сети». Ситуация заключается в том, что локальная сеть сегментирована (что очень хорошо) и трафик между сегментами фильтруется (что тоже прекрасно)… но плохо то, что изменение политик фильтрации происходит по неочевидным и долгим процедурам. Неочевидные и долгие процедуры приводят к тому, что процедура конфигурирования информационных потоков между сетевыми сегментами не может обеспечить быстро изменяющиеся потребности бизнеса. Но бизнесу надо работать и он … переносит свои информационные потоки в Интернет. Сама ситуация абсурдна в том смысле, что прямое назначение ЛВС – транспортировка внутренних информационных потоков, однако формальная зарегулированность ЛВС не позволяет ее использовать в интересах бизнеса по прямому назначению. Очевидно, вынос трафика приложений в Интернет, даже с использованием VPN, снижает уровень безопасности.

2. «Высокий уровень безопасности при обеспечении проектной деятельности». Здесь дело в том, что процесс управления проектной деятельностью построен так, что реализация инициативы в виде проекта становится рентабельной только начиная с определенного порогового значения (скажем, выполнять проект по всем правилам нерентабельно если он дешевле чем 10 у.е. – ввиду превышения накладных расходов над стоимостью производства), а другого, «облегченного» процесса не существует. Но бизнесу и в этой ситуации надо работать, строить информационные системы обработки своих данных, поскольку данных становится все больше, требования к точности их и скорости их обработки все выше. И здесь возможно два развития ситуации:

А) Перенос данных в облачные сервисы – использование различных колоборативных сред внешних сервисов, типа группы Facebook или Google, внешние тематические форумы и т.п. Здесь также противоречие смыслу ЛВС, которая должна стать средой для хранения, обработки и передачи корпоративных данных, а проблемы безопасности – очевидны – выложенные данные в Интернет перестали быть корпоративными

Б) Системы растут «подпольно», как «сорняки» в режиме ad-hoc. Здесь проблемы безопасности в том, что «проектирование» и «внедрение» таких систем производится без какой-либо оглядки на безопасность или выполнения элементарных рекомендацией производителей по ИБ, но уже являются продуктивными (важно понимать, что де-факто система начинает быть продуктивной когда в ней появились продуктивные данные). Здесь важное фундаментальное следствие: когда внедрение чего-то в заданных рамках бюджета и сроков неизбежно, всяко лучше ввязаться в процесс и попытаться сделать в части безопасности все возможное, а не «закрывать глаза» на сорняки, прикрываясь тем, что их не должно быть.

3. Стремление буквального исполнения требований регуляторов. В РФ великое множество compliance-а. Следует признать, что технологическое отставание нас от них равно бесконечности (мне, очень больно это осознавать). Как следствие, используемые нами продукты не соответствуют требованиями наших регуляторов, так как соответствуют требованиям их регуляторов. Поэтому существует много заплаток\докруток\доработок или, что еще хуже, разработанные с нуля продукты, подходящие под наши требования. Качество этих продуктов оставляет желать лучшего. На причинах не буду останавливаться особо, они очевидны: отсутствие конкуренции, мизерный рынок сбыта и т.п. Поскольку «безопасность» - один из элементов качества, - с ней тоже беда, но еще большая беда с управляемость, удобством использования, совместимостью и пр. , что хоронит возможность их использования. Но хочется отметить позитивные сдвиги в области отечественного compliance в последние годы: он стал более современный, стал учитывать возможность его практического применения - так держать! буду надеяться, что когда-нибудь наш compliance превратиться из "риск несоответствия" в "удобный инструмент использования".

4. Использование сертифицированных средств. Сертифицированное средство небезопасно банально потому что на него нельзя ставить заплатки безопасности. Я не раз писал о том, что я не вижу разницы между программной закладкой и программной ошибкой, позволяющей выполнить переполнение буфера, приводящее к запуску произвольного кода. Поэтому сертификация\аттестация будет иметь смысл только когда ответ на вопрос: «Гарантирует ли сертификация\аттестация отсутствие программных ошибок могущих привести к переполнению буфера?», - будет положительным. Приятно, что регуляторы и эту тему также понимают, поэтому, есть надежда, что в будущем сертифицированность будет не только "добавлять стоимость", но и действительно, "защищать потребителя от некачественного продукта" (можно заменить "некачественного" на "небезопасного").

5. Защита от админа. Я люблю повторять, что «риск нелояльности админа не снижается исключительно техническими контролями». Это также очевидно, как очевидна необходимость доверия пассажиров пилоту самолета или водителю автобуса. Более того, безопасность только тогда эффективна, когда реализуется в том числе и руками администраторов, когда она пронизывает все процессы поддержки и сопровождения. Да, безусловно, необходимо мониторить работу админов, но не надо им мешать делать их работу. Не надо путать понятие «Segregation of duties» с банальным размыванием ответственности за доступность. Доступность – это характеристика безопасности, и если в час Х у пользователя пропадет сервис, а админ не сможет оперативно выполнить свою работу – пострадает и безопасность, будучи исключительно прикладной: нет сервиса пользователя => нет объекта применения безопасности => нет и безопасности.

В заключение (обобщая пп 1,2) хочется сказать, что контроли безопасности должны быть не напряжны для их исполнения, по возможности. Если контроли построены по принципу «чтобы всем замучились», обеспечить их исполнение будет невозможно. Даже в случае невысоких накладных расходов на реализацию контролей безопасности, обязательна работа с бизнесом (бизнес-пользователями и их руководителями), чтобы люди понимали «зачем все это», «почему оно так, а не иначе» - только в этом случае можно надеяться, что люди будут исполнять контроли безопасности обдуманно, что, безусловно, будет способствовать повышению уровня безопасности, который зависит не только от работы подразделения ИБ, но и от каждого пользователя в отдельности!