Я бы предложил взглянуть на проблему немного шире, рассматривая ее не в концепции предприятия, а еще и отдельного человека и общества в целом. Тогда мы постепенно придем к таким терминам, как цифровая гигиена, информационный шум и прочее. Получится, что знание основ информационной безопасности - это такой же нужный навык как финансовая грамотность, и закладываться должна не только на предприятии.
Тогда специалист по awareness будет работать не сам по себе, а в системе, как например педагог в системе образования.
Если серьезно, то там где все это делается, то будет делаться и так, где не делают - ничего не изменится, возможно - до первого штрафа. Когда он будет, и будет ли?
Также соотносить 27001 и ужесточение по ИСПДн - странно.
Смешались в кучу кони, люди.. есть "пользовательские правила", есть "пользовательские сигнатуры", в чем разница? Есть вендорские или пользовательские правила, а в них.. снова сигнатуры. Есть политика, которая на самом деле тоже правило. При этом в правилах из БРП нет указания что делать с подходящим по условию трафиком - это указывается в настройке МЭ.. может, это тогда не правило, а условия? Или, как указано в настройках правила - сигнатуры? Путаница с терминологией.
Это больше претензия к разработчику, у которого такая каша в том числе и в документации.
По моему мнению, пентест это процесс более высокого уровня зрелости, результаты которого не будут использованы со 100% кпд, если до этого не выстроены процессы мониторинга и реагирования на инциденты безопасности и не применен комплексный подход. Например, пентестер может полгода колупать сеть заказчика без обнаружения, потому что нет мониторинга, или он может обнаружить 0-day уязвимость, но так как нет процесса управления уязвимостями и, соответственно, процесса тестирования и установки обновлений, то такие уязвимости будут возникать регулярно несмотря на то что по этому случаю дыру закроют.
Просто для вау-эффекта или чтобы проверить ошибки конфигурации - да, на таком уровне подойдет.
Просто это неэтичное поведение. Знание как нападать не означает что можно нападать. Одно дело обнаружить уязвимость, другое дело - ее использовать. Надеюсь, с тех времен вы поменяли свои взгляды.
Извините, возможно я не так понял, но вы под аккаунтом в котором написано кто вы и чем занимаетесь пишете комментарий о том как вы получили доступ к чужой почте и чужому серверу и два года использовали эти сведения в личных целях? Следует ли понимать это так, что вы во всей вашей деятельности придерживаетесь таких принципов?
Допустим, утечка персональных данных на предприятии не является недопустимым событием, значит ли это что сервер на котором они находятся не будет целью атакующего? Нет.
Если подходить комплексно, то нужно рассматривать весь спектр событий информационной безопасности.
Тем не менее, на суть статьи этот момент не влияет.
Как мне кажется, цели атакующего и недопустимые события - не обязательно совпадающие списки. Первый список шире. С одной стороны подход "от недопустимых событий" упрощает понимание целей работы отдела ИБ для руководства, с другой стороны важно не забывать и про другие цели атакующего - это важно уже для сотрудников отдела ИБ.
Смущает то, что в статье по архитектуре решений ИБ вы отталкиваетесь от целей, определяемых только недопустимыми событиями.
Странно, почему аварийное восстановление - это только про восстановление ИТ-систем? И почему-то в примере все спутано вместе, в обеспечении непрерывности при затоплении офиса устраняют инцидент, а в аварийном восстановлении обеспечивают доступность сервиса.
Как удалять рассылки: добавить в спам-лист слова "отписаться", "unsubscribe" и все их вариации. Почему? Потому что рассылки приходят даже если ты на них не подписывался, а любая активность от тебя будет расцениваться как то что почтовый адрес рабочий. Значит, это спам.
Подскажите, правильно ли я понимаю, что через accumulate можно объединять multiline логи в одно событие, к примеру - от postfix'а?
Я бы предложил взглянуть на проблему немного шире, рассматривая ее не в концепции предприятия, а еще и отдельного человека и общества в целом. Тогда мы постепенно придем к таким терминам, как цифровая гигиена, информационный шум и прочее. Получится, что знание основ информационной безопасности - это такой же нужный навык как финансовая грамотность, и закладываться должна не только на предприятии.
Тогда специалист по awareness будет работать не сам по себе, а в системе, как например педагог в системе образования.
Просто мысли вслух.
Поскорее бы попасть в этот дивный новый мир..
Если серьезно, то там где все это делается, то будет делаться и так, где не делают - ничего не изменится, возможно - до первого штрафа. Когда он будет, и будет ли?
Также соотносить 27001 и ужесточение по ИСПДн - странно.
Смешались в кучу кони, люди.. есть "пользовательские правила", есть "пользовательские сигнатуры", в чем разница? Есть вендорские или пользовательские правила, а в них.. снова сигнатуры. Есть политика, которая на самом деле тоже правило. При этом в правилах из БРП нет указания что делать с подходящим по условию трафиком - это указывается в настройке МЭ.. может, это тогда не правило, а условия? Или, как указано в настройках правила - сигнатуры? Путаница с терминологией.
Это больше претензия к разработчику, у которого такая каша в том числе и в документации.
По моему мнению, пентест это процесс более высокого уровня зрелости, результаты которого не будут использованы со 100% кпд, если до этого не выстроены процессы мониторинга и реагирования на инциденты безопасности и не применен комплексный подход. Например, пентестер может полгода колупать сеть заказчика без обнаружения, потому что нет мониторинга, или он может обнаружить 0-day уязвимость, но так как нет процесса управления уязвимостями и, соответственно, процесса тестирования и установки обновлений, то такие уязвимости будут возникать регулярно несмотря на то что по этому случаю дыру закроют.
Просто для вау-эффекта или чтобы проверить ошибки конфигурации - да, на таком уровне подойдет.
Наверное зависит от того, упадет ли у них после исправления прод) согласен с вами, некоторые понятия можно растянуть.
Просто это неэтичное поведение. Знание как нападать не означает что можно нападать. Одно дело обнаружить уязвимость, другое дело - ее использовать. Надеюсь, с тех времен вы поменяли свои взгляды.
Извините, возможно я не так понял, но вы под аккаунтом в котором написано кто вы и чем занимаетесь пишете комментарий о том как вы получили доступ к чужой почте и чужому серверу и два года использовали эти сведения в личных целях? Следует ли понимать это так, что вы во всей вашей деятельности придерживаетесь таких принципов?
Допустим, утечка персональных данных на предприятии не является недопустимым событием, значит ли это что сервер на котором они находятся не будет целью атакующего? Нет.
Если подходить комплексно, то нужно рассматривать весь спектр событий информационной безопасности.
Тем не менее, на суть статьи этот момент не влияет.
Как мне кажется, цели атакующего и недопустимые события - не обязательно совпадающие списки. Первый список шире. С одной стороны подход "от недопустимых событий" упрощает понимание целей работы отдела ИБ для руководства, с другой стороны важно не забывать и про другие цели атакующего - это важно уже для сотрудников отдела ИБ.
Смущает то, что в статье по архитектуре решений ИБ вы отталкиваетесь от целей, определяемых только недопустимыми событиями.
Странно, почему аварийное восстановление - это только про восстановление ИТ-систем? И почему-то в примере все спутано вместе, в обеспечении непрерывности при затоплении офиса устраняют инцидент, а в аварийном восстановлении обеспечивают доступность сервиса.
Как удалять рассылки: добавить в спам-лист слова "отписаться", "unsubscribe" и все их вариации. Почему? Потому что рассылки приходят даже если ты на них не подписывался, а любая активность от тебя будет расцениваться как то что почтовый адрес рабочий. Значит, это спам.
Пара вопросов, которые возникли после прочтения:
1) В вашем случае, кто был инициатором работы по оценке рисков ИБ? Проводится ли более общая оценка рисков бизнеса?
2) Какие методики по оценке рисков ИБ вы используете, придерживаетесь?