С ростом автоматизации владельцы облачных инфраструктур всё чаще сталкиваются с угрозами, которые исходят от ботов, парсеров, агентов, сервисных и других подобных автоматизированных аккаунтов.
Начало статьи немного вводит в замешательство, потому что статья и сам проект, кажется, скорее о другом виде угроз -- а именно об угрозах компрометации различного рода NHIs для компаний, которые используют их, например в интеграциях со сторонними системами. То есть об угрозах несанкционированного доступа к этим системам и информации в них с использованием скомпрометированных NHIs.
NHI2:Secret Leakage
Понятно, что сейчас эпоха облаков, но всё же странно, что в качестве дополнительной меры защиты не упомянут (как в проекте от OWASP, так и статье) список разрешенных IP-адресов, с которых можно использовать конкретный NHI. Иными словами, даже обширный список адресов может сильно усложнить эксплуатацию полученного API-ключа для злоумышленника.
К сожалению, Хабр за это время эволюционировал также и в ещё одну площадку для размещения статей про успешные успехи с кликбейтными заголовками и рекламой телеграм-каналов, которая стала уже практически дефолтом.
Вставлять баннер в середину поста как-то не ок. Особенно с учётом того, что сверху есть уже настолько большой, что приходится скроллить до начала этого самого поста :(
За потоком ненависти, передёргивания фактов (?) и просто набросов в этом посте можно разглядеть и разумное зерно. Безопасность в большинстве случаев не должна вредить пользовательскому опыту, потому что она является "частью продукта". Как только пользователю становится неудобно использовать сервис по причинам так или иначе связанным с обеспечением безопасности, то это сразу начинает негативно влиять как на впечатление от самого сервиса (и компания теряет пользователя, а вместе с ним и деньги), так и на соответствующую функцию безопасности (пользователь начинает использовать эту функцию не так, как планировались при проектировании, потому что ему так удобно -- и это нормально). При этом важно помнить про анализ рисков и сервисы с многомиллионными аудиториями.
Поэтому в предложенном опросе, очевидно, не хватает третьего пункта "Безопасная свобода".
Всего 3 ссылки на Телеграм в конце поста -- надо больше! :) А вообще, выделить бы вот это всё "Развитие стартапа, Интервью, Лайфхаки для гиков, Бизнес-модели" в отдельную секцию Хабра...назвать как-нибудь необычно, например "ВЦ".
Есть вот такой небольшой проект генератора статического OPDS-каталога для домашней библиотеки: Lib2OPDS. На сервере есть директория, куда кладутся книги, а дальше по крону генерируется OPDS-каталог, который можно раздавать с помощью веб-сервера по вкусу.
Внезапно и странно с учётом позирования Хабра как сообщества IT-специалистов (https://company.habr.com/ru/) и возможности указать на несоответствие тематики при отметке минусом поста.
Наша цель — создать комфортную экосистему для сообщества разработчиков, инженеров, дизайнеров, менеджеров — всех, кто создаёт IT-продукты.
Надеюсь, что команда Хабра наконец-то обратит внимание и таких статей станет меньше (или хотя бы будет работающий способ убрать их отовсюду из интерфейса при игноре автора).
Допустим, что у вас 5 вертикалей и каждый SecBP уходит отпуск хотя бы раз в год, тогда почти полгода основная команда будет вынуждена переключаться на решение задач соответствующего бизнес-юнита (и следовательно будет необходимость поддерживать знание в соответствующем домене). Как вы планируете решать эту проблему? Планируете ли возможность организовать команду под каждого SecBP?
Нет, не рассматривали. С таким подходом вижу сложность в оценке, тк не все изменения можно предусмотреть заранее
По описании фичи часто можно спрогнозировать, что она в принципе будет рискованна. Следовательно можно и заложить под это полноценный анализ рисков (вместо фиксированного времени, которого просто может не хватить и будет пропущен действительно рискованный релиз).
В целом, любопытно было бы почитать такой же пост, но по прошествии 1-2 лет и, конкретно, про то, насколько много продуктовые команды вертикалей стали делать больше самостоятельно в плане ИБ (либо же SecBP стали для них ответом на все вопросы).
SecBP закреплен за бизнес-направлением, в котором может быть 25–40 команд. Он служит точкой входа в основную команду ИБ, но не берет на себя все задачи по безопасности.
А что происходит, когда SecBP уходит в отпуск?
Продуктовые команды действительно начали активнее работать с инструментами ИБ, улучшать их настройку и процессы. Однако пока рано говорить о полноценном эффекте, так как в ряде направлений (кроме двух пилотных) роль SecBP еще не внедрена, и эти задачи по-прежнему выполняются основной командой ИБ.
Этот результат немного отличается от декларируемого в статье: "В целом инициатива оказалась крайне полезной. Мы достигли повышения прозрачности ситуации с безопасностью, улучшили процессы и повысили зрелость команд в вопросах ИБ. Многие команды сильно поменяли свой mindset и стали относиться к ИБ не как к «необходимому злу», а как к надёжным помощникам, стали активнее давать обратную связь и делиться идеями по улучшению процессов ИБ. "
Приблизительно оценили, сколько времени уходит на выполнение задач.
Часто размер задач достаточно сложно оценить, тем более в часах. У вас же получилось упаковать то же тестирование безопасности и исправление найденных уязвимостей в достаточно жесткие временные рамки. Рассматривали ли вы возможность сначала делать быструю сортировку фич с дальнейшим анализом рисков и уже на основе этого тестирование безопасности и т.д.? То есть идти от того, насколько потенциально рискованная фича, а не просто строго выделять время в неделю.
Основной целью пилота было снижение рисков и повышение уровня безопасности продуктов Авито за счёт более тесного и эффективного взаимодействия между продуктовыми командами и командой безопасности, чтобы обе стороны выиграли от сотрудничества.
Не получилось ли так, что продуктовые команды по сути начали аутсорсить все вопросы безопасности в своих SecBP (и теперь надо как минимум иметь количество SecBP >= число команд) вместо того, чтобы осознать собственную ответственность за риски в разрабатываемых сервисах (и, как следствие, уделять больше внимание вопросам ИБ)? Стали ли продуктовые команды выполнять больше задач, относящихся к безопасности, после того как у них появлялся SecBP, но без его участия?
Чтобы пилот прошёл успешно, от команд разработки требовалось выделить время для онбординга Sec BP на регулярные встречи, предоставление документации и погружение в контекст проектов: 4 часа в неделю. Важно было выделить время на оценку рисков — 2 часа от команды, проведение пентестов ключевых фич — 1 час на одну фичу — и на устранение найденных уязвимостей.
А почему вы решили это измерять, причем формально (в часах)?
В команды могут влететь разные задачи: пройти аудит по защите персональных данных, запатчить баги, пройти обучение и т.д.;
Почему это рассматривается именно как "внешние" задачи, при том, что это по сути часть продукта?Например, если баги не будут исправлены, то может реализоваться риск соответствующей атаки (и инцидента). Этот риск может и быть принят в пользу расхода ресурсов на продуктовые фичи. И это решение продуктовой команды.
Заголовок мог быть ещё лучше -- "Сёрфер-энтузиаст из Санта-Круса закрыл прибыльный магазин на {маркетплейсе}, переехал жить в {например_хостел} и покорил 32-метровую волну. Как это у него получилось и в чём нюанс?". К сожалению, таких постов и новостей, теперь на Хабре становится всё больше.
Прочитал в оригинале. Книга произвела впечатление хорошего обзорного (угроз) труда. Идея с отсылками к конкретным моментам и вообще к ЗВ понравилась, хотя и частенько, как мне показалось, это было "притянуто за уши".
Кто сказал что здесь не может быть ничего альтерантивного?
С момента своего запуска Хабр эволюционировал из ресурса для обмена знаниями из мира информационных технологий (назовём это computer science) в гораздо менее специализированный сайт, который часто используется как генератор трафика или рекламная площадка. Ещё и добавили неотключаемые новостные блоки, чтобы ещё больше получить внимания. Проблема даже не в этой эволюции, а в том что альтернативы текущему Хабру, но с прежними принципами, так и не появилось (?) за это время. К тому же, всё-таки и сейчас бывают годные статьи тут.
И кучи картинок больше мегабайта каждая.
Спасибо за интересный обзор этого проекта!
Начало статьи немного вводит в замешательство, потому что статья и сам проект, кажется, скорее о другом виде угроз -- а именно об угрозах компрометации различного рода NHIs для компаний, которые используют их, например в интеграциях со сторонними системами. То есть об угрозах несанкционированного доступа к этим системам и информации в них с использованием скомпрометированных NHIs.
Понятно, что сейчас эпоха облаков, но всё же странно, что в качестве дополнительной меры защиты не упомянут (как в проекте от OWASP, так и статье) список разрешенных IP-адресов, с которых можно использовать конкретный NHI. Иными словами, даже обширный список адресов может сильно усложнить эксплуатацию полученного API-ключа для злоумышленника.
К сожалению, Хабр за это время эволюционировал также и в ещё одну площадку для размещения статей про успешные успехи с кликбейтными заголовками и рекламой телеграм-каналов, которая стала уже практически дефолтом.
Вставлять баннер в середину поста как-то не ок. Особенно с учётом того, что сверху есть уже настолько большой, что приходится скроллить до начала этого самого поста :(
За потоком ненависти, передёргивания фактов (?) и просто набросов в этом посте можно разглядеть и разумное зерно. Безопасность в большинстве случаев не должна вредить пользовательскому опыту, потому что она является "частью продукта". Как только пользователю становится неудобно использовать сервис по причинам так или иначе связанным с обеспечением безопасности, то это сразу начинает негативно влиять как на впечатление от самого сервиса (и компания теряет пользователя, а вместе с ним и деньги), так и на соответствующую функцию безопасности (пользователь начинает использовать эту функцию не так, как планировались при проектировании, потому что ему так удобно -- и это нормально). При этом важно помнить про анализ рисков и сервисы с многомиллионными аудиториями.
Поэтому в предложенном опросе, очевидно, не хватает третьего пункта "Безопасная свобода".
Всего 3 ссылки на Телеграм в конце поста -- надо больше! :) А вообще, выделить бы вот это всё "Развитие стартапа, Интервью, Лайфхаки для гиков, Бизнес-модели" в отдельную секцию Хабра...назвать как-нибудь необычно, например "ВЦ".
Есть вот такой небольшой проект генератора статического OPDS-каталога для домашней библиотеки: Lib2OPDS. На сервере есть директория, куда кладутся книги, а дальше по крону генерируется OPDS-каталог, который можно раздавать с помощью веб-сервера по вкусу.
Внезапно и странно с учётом позирования Хабра как сообщества IT-специалистов (https://company.habr.com/ru/) и возможности указать на несоответствие тематики при отметке минусом поста.
Спасибо за ссылку на комментарий!
Возможно, что сработал накопительный эффект, описанный в https://habr.com/ru/articles/883222/comments/#comment_27934622
Надеюсь, что команда Хабра наконец-то обратит внимание и таких статей станет меньше (или хотя бы будет работающий способ убрать их отовсюду из интерфейса при игноре автора).
Спасибо за ответы и в любом случае желаю удачи! :)
Кстати, на Хабре были также статьи про SecBP/БПИБ от ребят из Озона (https://habr.com/ru/companies/ozontech/articles/744524/).
Допустим, что у вас 5 вертикалей и каждый SecBP уходит отпуск хотя бы раз в год, тогда почти полгода основная команда будет вынуждена переключаться на решение задач соответствующего бизнес-юнита (и следовательно будет необходимость поддерживать знание в соответствующем домене). Как вы планируете решать эту проблему? Планируете ли возможность организовать команду под каждого SecBP?
По описании фичи часто можно спрогнозировать, что она в принципе будет рискованна. Следовательно можно и заложить под это полноценный анализ рисков (вместо фиксированного времени, которого просто может не хватить и будет пропущен действительно рискованный релиз).
В целом, любопытно было бы почитать такой же пост, но по прошествии 1-2 лет и, конкретно, про то, насколько много продуктовые команды вертикалей стали делать больше самостоятельно в плане ИБ (либо же SecBP стали для них ответом на все вопросы).
А что происходит, когда SecBP уходит в отпуск?
Этот результат немного отличается от декларируемого в статье:
"В целом инициатива оказалась крайне полезной. Мы достигли повышения прозрачности ситуации с безопасностью, улучшили процессы и повысили зрелость команд в вопросах ИБ.
Многие команды сильно поменяли свой mindset и стали относиться к ИБ не как к «необходимому злу», а как к надёжным помощникам, стали активнее давать обратную связь и делиться идеями по улучшению процессов ИБ. "
Часто размер задач достаточно сложно оценить, тем более в часах. У вас же получилось упаковать то же тестирование безопасности и исправление найденных уязвимостей в достаточно жесткие временные рамки. Рассматривали ли вы возможность сначала делать быструю сортировку фич с дальнейшим анализом рисков и уже на основе этого тестирование безопасности и т.д.? То есть идти от того, насколько потенциально рискованная фича, а не просто строго выделять время в неделю.
Спасибо за то, что поделились интересным опытом!
Не получилось ли так, что продуктовые команды по сути начали аутсорсить все вопросы безопасности в своих SecBP (и теперь надо как минимум иметь количество SecBP >= число команд) вместо того, чтобы осознать собственную ответственность за риски в разрабатываемых сервисах (и, как следствие, уделять больше внимание вопросам ИБ)? Стали ли продуктовые команды выполнять больше задач, относящихся к безопасности, после того как у них появлялся SecBP, но без его участия?
А почему вы решили это измерять, причем формально (в часах)?
Почему это рассматривается именно как "внешние" задачи, при том, что это по сути часть продукта?Например, если баги не будут исправлены, то может реализоваться риск соответствующей атаки (и инцидента). Этот риск может и быть принят в пользу расхода ресурсов на продуктовые фичи. И это решение продуктовой команды.
Зачем вы текст скриншотом вставляете?
Сделайте, пожалуйста, возможность добавлять авторов в чёрный список, чтобы скрывались их материалы со всех блоков Хабра, включая "Читают сейчас".
Тут мой парсер заголовка статьи сломался и я пошёл смотреть в спеку HTTP :)
Заголовок мог быть ещё лучше -- "Сёрфер-энтузиаст из Санта-Круса закрыл прибыльный магазин на
{маркетплейсе}, переехал жить в{например_хостел}и покорил 32-метровую волну. Как это у него получилось и в чём нюанс?". К сожалению, таких постов и новостей, теперь на Хабре становится всё больше.Прочитал в оригинале. Книга произвела впечатление хорошего обзорного (угроз) труда. Идея с отсылками к конкретным моментам и вообще к ЗВ понравилась, хотя и частенько, как мне показалось, это было "притянуто за уши".
С момента своего запуска Хабр эволюционировал из ресурса для обмена знаниями из мира информационных технологий (назовём это computer science) в гораздо менее специализированный сайт, который часто используется как генератор трафика или рекламная площадка. Ещё и добавили неотключаемые новостные блоки, чтобы ещё больше получить внимания. Проблема даже не в этой эволюции, а в том что альтернативы текущему Хабру, но с прежними принципами, так и не появилось (?) за это время. К тому же, всё-таки и сейчас бывают годные статьи тут.
Эта статья, к сожалению, вообще отвечает почти всем тенденциям последнего времени на Хабре:
кликбейтный заголовок
не относится к IT вообще
репост с другого ресурса, например VC
в посте куча картинок, часто и для кода
обязательно попытка в юмор и мемы, что само по себе и не так уж и плохо, но вопрос в уровне
в конце обязательно должне быть призыв подписываться на блог в Телеграме