В информационной безопасности мы выработали ряд аксиом, с которыми не принято спорить:
- Никогда не внедряйте собственную криптографию.
- Всегда используйте TLS.
- Безопасность через неясность (security by obscurity) — это плохо.
И тому подобное. Большинство из них в целом верны. Однако мне начинает казаться, что люди слепо следуют этим аксиомам как культу карго. И многие на самом деле не думают об исключениях из правил. В этой статье я выскажу свои возражения против идеи «безопасность через неясность — это плохо».
Риск, эшелонированная оборона и швейцарский сыр
Одной из главных задач ИБ является снижение рисков. Согласно методологии OWASP, риск возникновения проблемы рассчитывается по формуле:
Риск = Вероятность * Воздействие
По этой формуле, проблема удалённого выполнения кода (RCE) представляет больший риск, чем проблема межсайтового скриптинга, поскольку RCE несёт большее воздействие. Здесь всё просто. Но что насчёт метрики вероятности? Согласно OWASP, вероятность определяется так:
На самом высоком уровне это приблизительная оценка шансов, что конкретная уязвимость будет раскрыта и использована злоумышленником
Таким образом, если мы уменьшаем вероятность, то уменьшаем общий риск. Это хорошо. На самом деле это очень похоже на известную концепцию «эшелонированной обороны». Её также называют «моделью швейцарского сыра».
Согласно этой модели, вам нужно выстроить защитные механизмы в многоуровневой модели таким образом, чтобы даже если злоумышленник пройдёт первый уровень, он будет остановлен на других.
Безопасность через неясность
Итак, поговорим о безопасности через неясность. Плохая идея использовать её в качестве единственного уровня защиты. Если злоумышленник пройдёт его, то вас больше ничто не защитит. Но на самом деле он неплох в качестве «дополнительного» уровня. Потому что у него низкая стоимость внедрения и обычно он хорошо работает.
Рассмотрим несколько сценариев:
- На моём сервере SSH запускается на дефолтном порту 22, а учётные данные
root:123456. Какова вероятность компрометации?
Вероятность почти 100%, так как хакеры по всему интернету брутят сервисы со стандартными учётными данными.
- SSH работает на порту 22, а учётные данные
utku:123456. Какова вероятность компрометации?
Ну, мы устранили опасность брутфорса со стандартными учётными данными. Вероятность и риск снижаются. Однако мы по-прежнему сталкиваемся с массой целевых атак. Кто-то может угадать имя пользователя utku, так как это моё настоящее имя.
- SSH работает в порту 64323, а учетные данные
utku:123456. Какова вероятность компрометации?
Мы изменили номер порта по умолчанию. Поможет ли это? Во-первых, мы снова устранили опасность стандартного брутфорса, поскольку он сканирует только общие порты. А как насчёт остальных? Я провёл небольшой опрос в своём твиттере, чтобы выяснить поведение людей при сканировании портов.
Как видите, многие склонны сканировать только стандартные и самые популярные порты. Таким образом, если вы измените порт с 22 на 64323, то устраните некоторые из потенциальных атак. Вы уменьшите вероятность и риск.
То же самое относится и к уязвимостям программного обеспечения. Если уязвимость обнаружена в протоколе Microsoft Remote Desktop Protocol, весь интернет начнёт сканировать порт 3389. Вы можете уменьшить риски, просто изменив порт по умолчанию.
Другие области применения
Конечно, кроме изменения значений по умолчанию можно использовать ту же методологию и в других областях. В некоторых случаях (не всегда) можно применить следующие идеи.
- Обфускация кода: конечно, это общеизвестно. Хакеры тоже люди. Если вы хорошенько обфусцируете код, им придётся уделить больше времени на поиск проблем. В конце концов они могут сдаться.
- Случайные имена переменных для веб-приложения: Вместо понятных имён переменных можно использовать случайные символы. Это может помочь точно так же, как обфускация кода.
- Симметричное шифрование в базе данных: при записи данных в БД используйте функцию вроде
encryption_algorithm(data, key). Аналогично, при считывании данных —decryption_algorithm(data, key). Если злоумышленник получил доступ к внутреннему коду, то, очевидно, сможет расшифровать БД. Но если из-за какой-то уязвимости злоумышленник считывает данные из БД, но не видит внутренний код (например, через SQL-инъекцию), то полученные данные ничего ему не дадут.
Применение в реальной жизни
Безопасность через неясность широко используется в физической/реальной безопасности. Например, президент едет из пункта А в пункт Б с кортежем из 30-ти автомобилей. Но он не сидит в своей президентской машине, чтобы не стать лёгкой мишенью. Он может находиться в любой машине из кортежа, и это снижает риск нападения.
Животные также используют безопасность через неясность — это камуфляж. Скрытность снижает вероятность быть убитым. Поэтому в процессе эволюции они приобрели такую способность.
Вывод
Безопасности через неясность самой по себе недостаточно. Всегда следует применять лучшие практики. Но если вы можете снизить риск с нулевыми затратами, то должны это сделать. Неясность — это хороший слой в общей системе безопасности.
Автор: GlobalSign_admin
