Безопасность средств безопасности: СКУД

при защите сколь-нибудь значимых объектов только на СКУД не полагаются

При защите значимых объектов ЛВС СКУДа физически отделена от прочих сетей предприятия.

При защите значимых объектов ЛВС СКУДа физически отделена от прочих сетей предприятия.

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

Это не так.

Так оно и должно быть в идеале, но на практике не всегда.

Конечно, но защищать нужно все.

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

А расскажите, если не сложно, вот о чем: что является результатом Вашей работы при анализе ИБ? Как выглядит этот результат? Какой-то акт? протокол? рекомендации по дальнейшим действиям в части настройки сети?

На примере тестирования на проникновение сети. Это один общий документ или два разных (для руководства и тех. специалистов) в зависимости от пожелания заказчика:

• формальная часть
• список целей, которые поставлены заказчиком. Иными словами, что пытаться украсть в первую очередь
• Список проверок которые проводились и уязвимости на которые проверялась сеть и сервера
• Краткое заключение результатов аудита для руководства. Дословно уровень защищенности с минимумом технических деталей, что бы руководство без технических знаний смогло понять существующие угрозы
• далее техническая часть для инженеров заказчика
• Список обнаруженных уязвимостей
• список конкретных примеров, как по шагам можно украсть те или иные данные. Как правило, это совокупность последовательно или параллельно эксплуатируемых уязвимостей. С скриншотами, а иногда и видеороликами: как на практике делается взлом, что бы его мог повторить сам инженер заказчика. Сухое описание уязвимостей и теоритические угрозы воспринимаются несерьёзно, другое дело, когда в ролике показывается как наглядно получается доступ к конфиденциальным данным. Тут уже сложно с этим спорить.
• Рекомендации по исправлению выявленных уязвимостей
• Рекомендации мер по предотвращению появления подобных уязвимостей в будущем

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

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

Типы пентестов бывают разные.

По направлению:

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

По типу информированности:

• WhiteBox ("Белый ящик"). Когда аудитору предоставляют максимальные права и доступ везде, что бы он мог сразу оценить все конфиги и настройки. Чтобы вместо поиска уязвимостей web-приложения, можно было сразу проверять наличие уязвимостей по исходникам. Это наиболее эффективный вариант для выявления сложных уязвимостей и злонамеренных "закладок" aka бэкдоров. Хотя меньше всего это похоже на атаку хакера.
• GrayBox ("Серый ящик"). Когда аудитору предоставляется часть данных, что бы сэкономить время на рутинных задачах. Обычно это общая информация о топологии и инфраструктуре сети. Никаких доступов аудитору не предоставляется. Это самый популярный вариант.
• BlackBox ("Черный ящик"). Аудитору не предоставляется ничего. Например, входными данными может быть только наименование заказчика и его сайт, в случае внешнего пентеста. В случае внутреннего -- просто конец витой пары или типовое рабочее место непривилегированного сотрудника компании. Аудитор должен сам выявить все периметры, и заняться их изучением.

По информированности службы ИБ:

• Служба ИБ информирована об аудите. Т.е. служба ИБ в курсе работ.
• Служба ИБ не информирована об аудите. Т.е. служба ИБ не в курсе работ, для них это будет реальная атака на которую они должны будут среагировать. Это используется, когда нужно проверить эффективность всех внедренных средств и качество работы ИБ по факту. Это самая настоящая имитация хакерской атаки. Много раз бывало, когда служба ИБ вообще не замечала, что их взломали, и злоумышленник уже месяц хозяйничает в их сети. А бывает, когда служба ИБ прибегает через 5 минут после начала аудита.

О терминологии.

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

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

А можете пример реального отчета показать?

А можете пример реального отчета показать?

Да, завтра пришлю.

Не внимательно читали.

Уволили конечно кого нашли за прогулы. Вместе с этим нескольких контролеров, табельщиков, начальство цеха...

Про отпуска и больничные я писал. Это проверялось. Это были люди по которым через 2 недели принесли табеля с 8-ками. Был обычный сговор. На проходной не замечали оставшихся пропусков, табельщики забили на свою работу, ну а начальство видимо получало долю. Я на такое наткнулся в одном цехе :)) А народу там в 12 раз больше было.

Зарплата повременщикам начисляется не на основании трудового договора а на основании табелей учета рабочего времени. Откуда туда данные попадают дело тридцатое. В трудовом договре прописан только тариф и график работы.

Это проверялось

А была вся история уже в 90-е?

начальство видимо получало долю.

Вот отсюда и плясать надо. Тех уволили, новых мертвых душ оформили. Круговорот бабла в природе.

Да, в конце 90-х.

Но на сколько я знаю и раньше такое практиковалось.

Тут просто не знали что так резко начнут действовать и наблюдать за картиной.

Понятно что мертвые души :)

Ну не серьезно говорить о том, что было почти 20 лет назад...

А что, сейчас что-то поменялось?

Не думаю.

Мне лично известны такие случаи. Да и самому чего греха таить доводилось проводить такие фокусы. И наличие у меня на тот момент прав enterprice admin никак на это не влияло.