Безопасность кода - это про функциональность. Если код "дырявый", то спустя время, когда уязвимость в коде проэксплуатируют, функциональность будет стремиться к нулю, к сожалению. Нефункциональный код вряд ли кому-то нужен.
Привет! Почему в статье нет поинта, что хороший код - это безопасный код? Безопасная разработка становится уже признаком "хорошего тона". Код ревьюится на предмет безопасности - это тоже улучшает "насмотренность".
Действительно не на всю ЦА может быть применим конкретный подход. Нужно подбирать в рецепте соотношение "кнута и пряника". 100% никогда не получится покрыть, к сожалению... но из-за этого не стоит сдаваться)
Конечно, киберучения - часть процесса. Это одновременно и проверка знаний, и отработка действий, проверка полноты плейбуков и отработка коммуникаций внутри команд, а также между смежными командами.
Понимание всех сотрудников куда и обращаться в случае инцидентов - это также одна из метрик, которую можно и нужно снимать в ходу учений (для простоты возьмите учебный фишинг). Если брать службу поддержку, то тут всё просто: как писал выше, надо понимать целевую аудиторию. Поддержка - ЦА с особой спецификой работы. Для коллег нужно отдельно проработать материалы и выбрать удобный/эффективный способ донесения информации.
Конечно, к сожалению, встречаются "перегибы" на местах. Но есть и вторая сторона медали. ИБ рассматривает риски (Модель угроз), вектора возможных атак и, как упоминал в статье, потенциальный ущерб.
Например, если выбирают из двух вариантов: 1) пользователи нажимают 3 кнопки (без стороннего ПО)
2) пользователи нажимают 1 кнопку (со сторонним ПО и риском потенциального ущерба 100 000 000 из-за "небезопасности" этого ПО), то руководитель скорее выберет 2й "неудобный" вариант (не захочет нести убытки).
ИБ не всегда получается про "удобство". Возможно, коллеги в вашем кейсе видели большие финансовые риски для компании (ИБ старается предотвращать потерю компанией денег), а экспертиза ИБ-рисков на их стороне и были веские доводы, которые не были озвучены. ИБ не для "запретить", а для "не потерять", но глобально в интересах компании.
Но как выше написал, не исключен вариант перегиба в вашем примере.
Супер) Спасибо большое! Нашел много знакомого и... ответы на свои текущие вопросы: в части подготовки внутреннего CTF (уже 2й год проводим). Ну и сериал - это, конечно, просто ТОП!!! По KIPS: надо всё-таки попробовать формат онлайн - у нас ребятам зашло)
Добрый день! Пересмотреть ГП - это всегда чудесно! "Удаленщики" и "офисные" различают в основном различаются в двух моментах: физическая безопасность (политика чистого стола) и способ подключения к корпоративной сети - отсюда для них будут немного отличаться риски. В идеале, если сотрудник работает на своем оборудовании, то сотрудник соглашается, что на его устройство распространяются корпоративные политики безопасности (да это может быть неприятно). Но будет более неприятно, если из-за твоего личного "незащищенного" устройства возник инцидент и компания понесет убытки. большие по размеру, чем твой вклад в работу компании. Как один из вариантов BYOD.
Добрый день! Всё верно, такие сотрудники без ноутбуков/смартфонов/планшетов имели доступ к внутренней сети через специализированные устройства другого типа. Нужно отталкиваться от возможностей самого устройства и от "рутины" такого сотрудника. В данном случае были риски, как минимум: потеря устройства или его взлом (как с ПК и смартофонами).
Эти кейсы как раз подчеркивают важность одного момента: организатор такой активности должен понимать что делает и для чего. Если для "галочки", то получится именно так, как у вас описано. Важно понимать свою целевую аудиторию и её интересы, ну и организовывать "с душой", а не потому что "попросил директор". Конечно никогда не получится так чтобы понравилось абсолютно каждому участники.
Владелец предприятия (или лицо принимающее решение) - тот человек на предприятии, который принимает решение и риски (в статье писал). Возможно, с таким "пиратским" подходом для обеспечения ИБ достаточно просто вести бумажный журнал использования ПК - но это всё шутки) На мой скромный взгляд, использование пиратского системного и программного обеспечения просто кратно увеличивает риски возникновения инцидента ИБ и возможные убытки.
"в самих YAML-объектах указываем тех, кому предоставляем доступ"
автоматизация в этом моменте есть же? или руками?
Привет! А есть ли критерии выбора "падавана" для передачи ему функции. Зависят ли эти критерии от самой функции?
Про Bug Bounty (и свой опыт) неплохо написали ребята из Ozon.
https://habr.com/ru/companies/ozontech/articles/731700/
Большое спасибо!
Что нужно изучать тем, кто выбрал путь "BISO cбоку"?
Здравствуйте, спасибо за статью! А были ли метрики, от которых вы со временем отказались? Если да, то от каких метрик и по каким причинам?
А как происходил выбор ВУЗа? Всё чаще замечаю, что они дают студентам разную "базу". И разница этих уровней довольна заметна.
Роман, очень необычная статья - спасибо! Поэтому и вопрос фантасмагорический: реально ли написать функциональный код в стихотворной форме?)
Безопасность кода - это про функциональность.
Если код "дырявый", то спустя время, когда уязвимость в коде проэксплуатируют, функциональность будет стремиться к нулю, к сожалению. Нефункциональный код вряд ли кому-то нужен.
Привет! Почему в статье нет поинта, что хороший код - это безопасный код?
Безопасная разработка становится уже признаком "хорошего тона". Код ревьюится на предмет безопасности - это тоже улучшает "насмотренность".
А есть особенности приёма и адаптации стажеров, которые уже имеют немалый опыт работы в других сферах, но сменивших направление деятельности на ваше?
Спасибо за материал! На ваш взгляд сильно ли различается ПМ в ИБ от ПМ в ИТ?
Действительно не на всю ЦА может быть применим конкретный подход. Нужно подбирать в рецепте соотношение "кнута и пряника". 100% никогда не получится покрыть, к сожалению... но из-за этого не стоит сдаваться)
Конечно, киберучения - часть процесса. Это одновременно и проверка знаний, и отработка действий, проверка полноты плейбуков и отработка коммуникаций внутри команд, а также между смежными командами.
Понимание всех сотрудников куда и обращаться в случае инцидентов - это также одна из метрик, которую можно и нужно снимать в ходу учений (для простоты возьмите учебный фишинг). Если брать службу поддержку, то тут всё просто: как писал выше, надо понимать целевую аудиторию. Поддержка - ЦА с особой спецификой работы. Для коллег нужно отдельно проработать материалы и выбрать удобный/эффективный способ донесения информации.
Конечно, к сожалению, встречаются "перегибы" на местах.
Но есть и вторая сторона медали. ИБ рассматривает риски (Модель угроз), вектора возможных атак и, как упоминал в статье, потенциальный ущерб.
Например, если выбирают из двух вариантов:
1) пользователи нажимают 3 кнопки (без стороннего ПО)
2) пользователи нажимают 1 кнопку (со сторонним ПО и риском потенциального ущерба 100 000 000 из-за "небезопасности" этого ПО),
то руководитель скорее выберет 2й "неудобный" вариант (не захочет нести убытки).
ИБ не всегда получается про "удобство". Возможно, коллеги в вашем кейсе видели большие финансовые риски для компании (ИБ старается предотвращать потерю компанией денег), а экспертиза ИБ-рисков на их стороне и были веские доводы, которые не были озвучены. ИБ не для "запретить", а для "не потерять", но глобально в интересах компании.
Но как выше написал, не исключен вариант перегиба в вашем примере.
Супер) Спасибо большое! Нашел много знакомого и... ответы на свои текущие вопросы: в части подготовки внутреннего CTF (уже 2й год проводим). Ну и сериал - это, конечно, просто ТОП!!! По KIPS: надо всё-таки попробовать формат онлайн - у нас ребятам зашло)
Добрый день! Пересмотреть ГП - это всегда чудесно!
"Удаленщики" и "офисные" различают в основном различаются в двух моментах: физическая безопасность (политика чистого стола) и способ подключения к корпоративной сети - отсюда для них будут немного отличаться риски. В идеале, если сотрудник работает на своем оборудовании, то сотрудник соглашается, что на его устройство распространяются корпоративные политики безопасности (да это может быть неприятно). Но будет более неприятно, если из-за твоего личного "незащищенного" устройства возник инцидент и компания понесет убытки. большие по размеру, чем твой вклад в работу компании. Как один из вариантов BYOD.
Добрый день! Всё верно, такие сотрудники без ноутбуков/смартфонов/планшетов имели доступ к внутренней сети через специализированные устройства другого типа. Нужно отталкиваться от возможностей самого устройства и от "рутины" такого сотрудника. В данном случае были риски, как минимум: потеря устройства или его взлом (как с ПК и смартофонами).
Эти кейсы как раз подчеркивают важность одного момента: организатор такой активности должен понимать что делает и для чего. Если для "галочки", то получится именно так, как у вас описано. Важно понимать свою целевую аудиторию и её интересы, ну и организовывать "с душой", а не потому что "попросил директор". Конечно никогда не получится так чтобы понравилось абсолютно каждому участники.
Владелец предприятия (или лицо принимающее решение) - тот человек на предприятии, который принимает решение и риски (в статье писал). Возможно, с таким "пиратским" подходом для обеспечения ИБ достаточно просто вести бумажный журнал использования ПК - но это всё шутки)
На мой скромный взгляд, использование пиратского системного и программного обеспечения просто кратно увеличивает риски возникновения инцидента ИБ и возможные убытки.