ФБО - функциональные возможности безопасности ОО (реализация ФТБ)
ФТБ - функциональные требования безопасности (каталог содержится в ГОСТ Р ИСО/МЭК 15408-2-2013)
@Alexey_Antonov не могли бы вы взять скриншоты интерфейса какого-нибудь банка и на них подписать/порисовать в следующей статье что в интерфейсе есть ФБО, ФТБ, ТДБ, ПФБ
Очень подробно описаны алгоритмы, которые известны уже много лет, а вот про алгоритмы или конкретные решения именно zero-trust не сказано ничего. Последний раздел звучит красиво, но так ли легок к реализации на самом деле? Что если злоумышленник получил полное владение ПК сотрудника, поможет ли zero-trust?
Почему сотрудник изображен именно в недоверенной сети, а если я включаю ПК который находится в доверенной сети, для него никакого zero-trust не будет, он сразу будет иметь полный доступ Или как в данном случае предполагается?
Почему по тексту используется термин субъект, но если идет объяснение, то становится понятнее, что речь идет о ПК пользователя. Zero-trust для доступа серверов к серверам плохо применим? Или точнее он совсем не применим так как рассмотрены алгоритмы аутентификации людей, а не программ при доступе к программам?
Суть как понимаю не в активах, а в том что, если не успевать их реализовывать, то кто-то другой построит аналог Starlink либо все плюнут на Starlink и перестанут им пользоваться. Ну а инвесторы как раз обидятся.
Возможно мелко плаваю как тех. специалист, но в достаточно большом Холдинге с филиальной структурой по стране, почти нигде не сделано по данной картинке. Везде на самой границе что-то специфически ИБшное, а не просто роутер с грубой предфильтрацией АЦЛ.
Но это ладно, может они/мы лохи. Но вот новичку я бы точно советовал как у вас нарисовано - не
Судя по всему, вы сами не понимаете почему у вас так, а не как у меня и постулируете ваше решение как верное решение абзацами выше, причем не советуете делать так, хотя в начале пишите, что все указанное это спорный момент
ДОС на пограничный ФВ не самая большая беда. И если учесть, что ДМЗ делаются далеко не всегда на стыке публичных сетей с частными, а в т. ч. в пределах одной, допустим, корпоративной сети, заради разделения и безопасного инф. обмена частей сети с разным уровнем доверия/критичности, где ДОС маловероятен или вообще невозможен, все же два независимых ФВ делают и логика там ближе к чистой ИБ, чем к нагрузочным моментам.
Не понял поток мыслей, наверное, вы писали про то, что каждая ИСПДн/направление бизнеса/ЮЛ в группе компаний/либо огромные связные наборы сетей/ либо еще по какой методике защищаемые разными межсетевыми экранами сегменты, для удобства защищаются разными МЭ. Оно?
Каждый сам решает как ему лучше, что у него будет на границе хоть группы внутренних сетей: МЭ, коммутатор либо роутер; внешних: роутер, средство защиты от ddos, мэ. Не важно крупная или мелкая компания - в компаниях каждого размера компаний бывает обычное межсетевое экранирование и каждый сам решает.
По поводу всех вами указанными новомодными погремухами, для всех финансовых организаций действует ГОСТ 575801.1-2017, а конкретно его мера:
СМЭ.15
Реализация сетевого взаимодействия и сетевой изоляции на уровне не выше третьего (сетевой) по семиуровневой стандартной модели взаимодействия открытых систем, определенной в ГОСТ Р ИСО/МЭК 7498-1, внутренних вычислительных сетей финансовой организации и сети Интернет
Не считаю, что понимание сегментации сразу на уровне L7 является базой, так же понимание того, что один межсетевой экран может все роутеры, межсетевые экраны, умные коммутаторы, заменить, тоже всем новичкам ни к чему.
Если у вас есть желание рассказать об этом, вы можете написать свою статью, не забудьте расписать сегментацию сразу в контейнеризации, она же тоже сейчас у всех есть.
Но только не картинку, а аля консультант аля wiki
Сделайте в Github, будем всем сообществом вносить вам правки
Супер дизайн, чтобы побить Tesla придется его сохранить
@Alexey_Antonov не могли бы вы взять скриншоты интерфейса какого-нибудь банка и на них подписать/порисовать в следующей статье что в интерфейсе есть ФБО, ФТБ, ТДБ, ПФБ
Очень подробно описаны алгоритмы, которые известны уже много лет, а вот про алгоритмы или конкретные решения именно zero-trust не сказано ничего. Последний раздел звучит красиво, но так ли легок к реализации на самом деле? Что если злоумышленник получил полное владение ПК сотрудника, поможет ли zero-trust?
Почему сотрудник изображен именно в недоверенной сети, а если я включаю ПК который находится в доверенной сети, для него никакого zero-trust не будет, он сразу будет иметь полный доступ Или как в данном случае предполагается?
Почему по тексту используется термин субъект, но если идет объяснение, то становится понятнее, что речь идет о ПК пользователя. Zero-trust для доступа серверов к серверам плохо применим? Или точнее он совсем не применим так как рассмотрены алгоритмы аутентификации людей, а не программ при доступе к программам?
Стоп, правильно ли я понял, что это решение класса privilege access management, которое есть в Azure и судя по всему должно быть и в AWS?
Суть как понимаю не в активах, а в том что, если не успевать их реализовывать, то кто-то другой построит аналог Starlink либо все плюнут на Starlink и перестанут им пользоваться. Ну а инвесторы как раз обидятся.
Говорят в оригинальной статье как раз нет количества, это количество додумано
-2 вице-президента, прикиньте как так там двинется вертикаль управления, чтобы кого-то повысили, ему нужно чутка переработать на выходных
Это в тысячах измерение?
Чувствую очередной распил, хэш-функцию придумали, затем я чутка испорчу свой палец и биометрическая система перестанет уметь сравнивать.
Судя по всему, вы сами не понимаете почему у вас так, а не как у меня и постулируете ваше решение как верное решение абзацами выше, причем не советуете делать так, хотя в начале пишите, что все указанное это спорный момент
Не понял поток мыслей, наверное, вы писали про то, что каждая ИСПДн/направление бизнеса/ЮЛ в группе компаний/либо огромные связные наборы сетей/ либо еще по какой методике защищаемые разными межсетевыми экранами сегменты, для удобства защищаются разными МЭ. Оно?
Каждый сам решает как ему лучше, что у него будет на границе хоть группы внутренних сетей: МЭ, коммутатор либо роутер; внешних: роутер, средство защиты от ddos, мэ. Не важно крупная или мелкая компания - в компаниях каждого размера компаний бывает обычное межсетевое экранирование и каждый сам решает.
Для этого разрабатывается защита на уровне L2 и к межсетевому экранированию не имеет отношения, следовательно в статье этого нет.
Да нет же, это название сервиса такое
По поводу всех вами указанными новомодными погремухами, для всех финансовых организаций действует ГОСТ 575801.1-2017, а конкретно его мера:
Не считаю, что понимание сегментации сразу на уровне L7 является базой, так же понимание того, что один межсетевой экран может все роутеры, межсетевые экраны, умные коммутаторы, заменить, тоже всем новичкам ни к чему.
Если у вас есть желание рассказать об этом, вы можете написать свою статью, не забудьте расписать сегментацию сразу в контейнеризации, она же тоже сейчас у всех есть.
Спасибо
Статья про любого ИТшника как я понимаю? Ничего специфичного (технического) именно в DevOps не увидел
Правильно понимаю, что речь про отдельный инстанс mail.ru для бизнеса?
Так и не понял суть работы атаки