3 важных урока из анализа сетевой безопасности

Хаки и хакеры повсюду. Все вы должны знать, что произошло с Equifax в 2017 году. Если вы не знаете об этом взломе, то где вы жили? Когда я начал писать эту статью, я столкнулся с брешью в British Airways и даже в Cisco.

Кажется, ни одна компания не застрахована. Соучредитель Crowdstrike Дмитрий Альперович известен тем, что сказал следующее:

Есть только два типа организаций: те, которые знают, что их взломали, и те, которые еще не знают.

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

Итак, несколько лет назад я работал над проектом по анализу сетевой безопасности. В сети, насчитывающей более 10 000 устройств, сложно убедиться, что все эти устройства настроены правильно и соответствуют корпоративным стандартам безопасности.

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

Не отставай на два шага

Хакеры всегда кажутся на шаг впереди. Безопасность — это та область, в которой вы не можете позволить себе отставать слишком далеко. Чтобы иметь шанс предотвратить нарушение, компания должна действовать упреждающе. К сожалению, слишком часто в IT мы не бываем. Нам часто кажется, что мы не ожидаем, что все мы люди, и ошибки могут быть и будут сделаны. По этой причине эта компания разработала собственный внутренний инструмент для сканирования сетевых устройств на наличие проблем с конфигурацией, которые потенциально могут привести к нарушениям безопасности.

Сколько раз вы набирали «9» вместо «0»? Или как насчет «а» вместо «9»? Должен любить эту кнопку переключения передач!

Человеческая ошибка — бывает. Иногда мы делаем ошибки. Но в других случаях эти «ошибки» могут быть преднамеренными. Кто-то может намеренно добавить к вашему сетевому устройству конфигурацию, которая идет вразрез с вашими стандартами, по своим темным причинам. Какой бы ни была причина, вам нужна возможность автоматически идентифицировать эти ошибки конфигурации, когда они происходят. Что и сделала эта компания. Они разработали инструмент для обнаружения таких ошибок. В зависимости от того, кто вы и где вы работали, вы, вероятно, можете увидеть несколько проблем с этим методом. Я подумал о техническом долге.

Теперь, создав что-то внутри, эта компания должна поддерживать этот внутренний инструмент отныне и до вечности. Ну, может быть, не вечность, но теперь они должны обновлять его по мере изменения технологий. Новые команды интерфейса устройства? Изменить управление! Возможности новых технологий устройств? Изменить управление! Несоблюдение этих изменений может оставить вашу сеть открытой для неблагоприятных обстоятельств. См. Эквифакс. И, кстати, ваш ведущий сетевой инженер? Человек, который возглавит команду по созданию этого инструмента? Да, они только что устроились на новую работу. Итак, они уходят.

Если ваша организация похожа на многие другие ИТ-организации, в которых я работал, документация — это не то, что вам нужно. Так что вполне возможно, что этот инженер только что получил большую часть знаний о вашем собственном инструменте. Я видел, что это происходит и с программным обеспечением поставщика. Продукт часто становится полочным товаром. Ну так что ты делаешь?

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

Не спланировать или спланировать неудачу

Так как же нам это сделать? Как заменить существующий инструмент безопасности продуктом поставщика?

Ну, вы разрабатываете план реализации, а затем любите его, когда план сводится воедино. Вам нужен план, чтобы действовать на опережение. Итак, у нас был план получить от клиента как можно больше подробностей об их сети и об этом внутреннем инструменте, который они использовали. Это включало количество устройств в сети, которые в настоящее время сканировались на наличие проблем с конфигурацией. У клиента было несколько тысяч устройств, а также несколько сотен правил во внутреннем инструменте для выполнения сканирования. Моя работа заключалась в том, чтобы сопоставить каждое из их правил с правилом в продукте поставщика. Если бы правила не существовало, мы бы создали новое правило. В конце концов, клиенты сопоставили несколько сотен пользовательских правил с менее чем 50 существующими правилами продукта поставщика. С точки зрения производительности, это победа!

Я считаю, что один из лучших способов анализа вашей сети, будь то с точки зрения безопасности или производительности, — это собирать данные из вашей сетевой инфраструктуры и анализировать их «в автономном режиме». Вы хотите свести к минимуму любое влияние на вашу производственную сеть. Будь то данные конфигурации с ваших маршрутизаторов и коммутаторов, журналы с ваших серверов или захваты пакетов с ваших сетевых устройств, вы хотите свести к минимуму прямое подключение к ним для извлечения данных анализа. Имея это в виду, мы собирали производственные данные из нашей сети по расписанию, в идеале во время более низкого использования сети, чтобы уменьшить любое потенциальное воздействие. Таким образом, мы смогли выполнить то, что намеревался сделать клиент — заменить его существующий инструмент настройки продуктом поставщика, который выполняет анализ безопасности.

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

1. Ты здесь?

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

Это можно сделать несколькими способами. Одним из способов является использование старого доброго SNMP, который исторически имел свои проблемы с безопасностью, но часто достаточно хорошо справляется со своей задачей. Другой способ — войти на каждое устройство и получить конфигурации с этих устройств. Третий — использовать существующие инструменты, которые уже есть у клиента, и извлекать оттуда информацию об устройстве. Самым точным методом в то время была возможность войти в устройства и выполнить sh run. Но много раз я либо не мог войти в устройство, либо устройство даже не отвечало.

Итак, я обнаружил, что только около 60 процентов сетевых устройств, которые, по мнению клиента, находились вне сети, были на самом деле доступны. Остальные 40 процентов были недоступны по тем или иным причинам. Это означало, что либо изменились учетные данные для входа на эти устройства, либо изменилась роль устройства, либо устройство было просто удалено из сети.

Отсутствие дескриптора сетевых устройств, которые есть в вашей сети, — это верный способ столкнуться с проблемой безопасности. Устройство, которое, по вашему мнению, находится в вашей сети, но не может быть пропинговано, может предположить, что оно есть, но использует другой IP-адрес, которого нет в вашей базе данных, или оно блокирует ваш вход в систему и/или запросы ICMP. Это оставляет вас в неведении о том, что находится в вашей сети, и потенциально открывает вам уязвимости, о которых вы не узнаете, пока в вашей сети не произойдет неблагоприятное событие безопасности.

2. Важность списка контроля доступа

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

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

3. Точная маршрутизация

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

В большой сети, такой как клиент, с которым я работал, у вас могут быть большие сегменты вашей сети, использующие BGP для маршрутизации трафика между собой. Но также вы можете использовать EIGRP или OSPF в этих сегментах сети для маршрутизации трафика.

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

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

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

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

Не будь уязвимым

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

Помочь этому клиенту определить некоторые вещи, которые он мог бы сделать лучше в то время и в будущем, — это то, к чему мы все должны стремиться. Независимо от того, используем мы инструменты или нет, мы не можем позволить нашим сетям оставаться открытыми для изменений, не зная, когда эти изменения могут сделать наши сети и, следовательно, наши компании уязвимыми для атак.

Извлеките уроки из этих трех уроков, чтобы убедиться, что вы проверяете свою сеть на наличие потенциальных проблем безопасности. Вы проводили такой анализ безопасности? Что вы открыли или унесли?