sec_devops_chat | Unsorted

Telegram-канал sec_devops_chat - Security Wine Chat (бывший DevSecOps Chat)

1807

Чат для обсуждения DevSecOps и постов канала @sec_devops Вакансии: @appsec_job Услуги: https://radcop.online/

Subscribe to a channel

Security Wine Chat (бывший DevSecOps Chat)

и ссср попросту считал госплан на куркуляторах. Сейчас это возможно

Читать полностью…

Security Wine Chat (бывший DevSecOps Chat)

Дык вы сами ответили - что в большой корпорации лучше стремиться к единству, в том числе на ДЗО. Другое дело - что сделать это большая проблема))) Вон даже СССР не справился (там решалась похожая задача на уровни Госплана и ЦЭМИ, и из-за масштаба объекта управления они запутались; другое дело, что например в ритейле международно, а-ля Wallmart, похожие задачи решаются достаточно успешно). Там правда речь идет о доступности товаров, логистике, их оборачиваемости и т.д., но там такие же интегральные показатели по существу, просто учитываются другие факторы, и работают другие сенсоры. А принципы сбора, обработки, синтеза данных в интегрированную информацию, имхо, идентичны.

Читать полностью…

Security Wine Chat (бывший DevSecOps Chat)

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

Читать полностью…

Security Wine Chat (бывший DevSecOps Chat)

Не, там в статье вообще про другое. Идея тут в том, что в рамках конкретного бизнеса, конкретные ЛПР, могут договориться о своей вариации интегрального показателя...

Читать полностью…

Security Wine Chat (бывший DevSecOps Chat)

Там можно ещё интереснее играть: уязвимость есть в конечном итоге в каком-то сервисе, в каком-то продукте. У продукта помимо прочего есть, например, показатели доступности и проблематика мониторинга доступности. Есть ещё какие-то факторы, включая статистику инцидентов и событий безопасности; или экспертное мнение руководства компания о критичности соответствующего актива; или.... Все это может учитываться при динамическом расчете. Мы что-то похожее делаем с коллегами из SECURITM тут: https://bosfera.ru/bo/ib-manevry

Читать полностью…

Security Wine Chat (бывший DevSecOps Chat)

Но почему, но почему (с) шуфик

Читать полностью…

Security Wine Chat (бывший DevSecOps Chat)

Contextual Vulnerability Management With Security Risk As Debt

Я думаю, каждый, кто занимался построением программы управления уязвимостями или хотя бы раз пытался добиться от ИТ-команд их устранения, знает, насколько сложно обеспечить соблюдение установленных SLA. Зачастую SLA берутся «с потолка» и, как правило, далеки от реальных возможностей организации по быстрому устранению выявленных уязвимостей. В результате в организации возникает общая фрустрация, где все сталкиваются с удручающими отчетами. А CISO за "кружкой пива" мрачно заявляет, что "у него в бэклоге 3 миллиона уязвимостей" и "он/она не знает, что с ними делать!". И хотя из общих соображений понятно, что здесь придется обращаться к приоритезации и мудрости в духе общества анонимных алкоголиков:

Господи, дай мне спокойствие принять то, чего я не могу изменить, дай мне мужество изменить то, что я могу изменить. И дай мне мудрость отличить одно от другого.


Всегда интересно понять, а как конкретно можно реализовать эффективный vulnerabilty management? Сегодня мы предлагаем вам ознакомиться с опытом DigitalOcean по внедрению методики «технического долга». Суть такова:

1) При выявлении новой уязвимости ей присваивается определенный уровень критичности.

2) В зависимости от уровня критичности уязвимости определяется рекомендуемое время для ее устранения. Это время известно как «Accepted Insecure Time» — период, в течение которого уязвимость должна быть устранена, чтобы не накапливать долг.

3) Если уязвимость не устранена в течение рекомендованного времени, начинает накапливаться долг по безопасности. Долг рассчитывается ежедневно: за каждый день, в течение которого уязвимость остается нерешенной после истечения срока, к общему долгу добавляется определенная величина, зависящая от критичности уязвимости. Чем выше критичность, тем быстрее накапливается долг.

4) Команды могут видеть свои показатели долга по безопасности через панель управления. Они могут анализировать, какие уязвимости вносят наибольший вклад в долг, и решать, на каких из них сосредоточить свои усилия в первую очередь.

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

6) Для всех бизнес-подразделений рассчитывается показатель соответствия порогу долга по безопасности (Security Debt Adherence), то есть процент команд, у которых долг по безопасности соответствует ожидаемому уровню (или, иначе говоря, установленному уровню обслуживания (SLO)). Вначале DigitalOcean достигали 75% и постепенно продвигались к цели в 95%. Этот порог является согласованным компромиссом между бизнес-подразделением и командой безопасности относительно того, насколько гибким может быть график выполнения работ по безопасности. Если ускорение разработки продукта, критическая инициатива, инцидент безопасности или другой фактор изменяет верхнеуровневую оценку этой гибкости, DigitalOcean может повысить или снизить порог долга для соответствующей части организации.

В результате, по словам DigitalOcean, снизилась "ментальное давление" на команды и улучшились отношения с бизнес-подразделениями, что привело к тому, что многие другие команды начали адаптировать концепцию технического долга.

Очень красивая success story. И что характерно очень соответствующая ситуационным моделям управления ИБ, которые мы упоминали во вчерашнем посте. А как выстраиваете свой VM вы, и что используете в качестве "центральной шины"?

#vm #experience

Читать полностью…

Security Wine Chat (бывший DevSecOps Chat)

да, но и профит какой-то должен быть на выходе…если делать ради того, чтобы делать, то ок, если пытаться что-то менять…были уже такие сообщества, с выходом на регуляторов, но как-то и у них не получилось

Читать полностью…

Security Wine Chat (бывший DevSecOps Chat)

Так продавать не с точки зрения ибшника. А выгоды для бизнеса

Читать полностью…

Security Wine Chat (бывший DevSecOps Chat)

Но все равно можно получить вдохновение !

Читать полностью…

Security Wine Chat (бывший DevSecOps Chat)

Изолируйте все то, что вам не нравится и не подходит - в отдельный загончик и не давать этой проказе хаоса расползаться дальше

Читать полностью…

Security Wine Chat (бывший DevSecOps Chat)

Зависит от репутации и формата "чата" + от психотипа и культуры ЛПР в конкретной организации. Где-то вполне будет работать.

Читать полностью…

Security Wine Chat (бывший DevSecOps Chat)

Отсюда собственно сравнение с алхимией, и современной химией, и ставка на институты и ресурсы =)

Читать полностью…

Security Wine Chat (бывший DevSecOps Chat)

Ну а как "бизнесу продали" идею TCP/IP?) Ключ в том, что это не совсем про бизнес, и что именно поэтому существуют государственные и надгосударственные регулятора, от ФСТЭК и ФСБ, до консорциумов и советов типо IEEE.

Читать полностью…

Security Wine Chat (бывший DevSecOps Chat)

это теория и демагогия, на практике продайте бизнесу эту идею…что ради унифиации работы ИБшника и требований ИБ, им нужно потратить N-миллионов тугриков на перестройку ИТ-ландшафта и изменение подходов к разработке

Читать полностью…

Security Wine Chat (бывший DevSecOps Chat)

сейчас унификация проще за счет того, что есть средства массовой автоматизации

Читать полностью…

Security Wine Chat (бывший DevSecOps Chat)

А как масштабируется на большую и разветвленную инфраструктуру? Если каждый отдел или дочернее общество будет считать по разному получится путаница. Хотя кажется я неправ

Читать полностью…

Security Wine Chat (бывший DevSecOps Chat)

Это как раз к вчерашней дискуссии, под опросом, о стандартизации - здесь как раз могут быть разнообразные подходы к измерениям, т.к. это вопрос целей-ценностей-рисков, и здесь много субъективного для конкретной организации и её ЛПР/клиентов/пользователей.

Читать полностью…

Security Wine Chat (бывший DevSecOps Chat)

Получается утяжеляете формулу веса уязвимости и еще по своему калькулятору критичности дополнительный расчет? Факторы доступности и так далее, звучит как threat intelligence докинули в интегралку. Могу ошибаться

Читать полностью…

Security Wine Chat (бывший DevSecOps Chat)

Определенная величина, зависящая от критичности. Единственное в формулу добавили еще время

Читать полностью…

Security Wine Chat (бывший DevSecOps Chat)

Технический долг звучит как показатель интегральной уязвимости.

Читать полностью…

Security Wine Chat (бывший DevSecOps Chat)

ну возможно, я бы посмотрел на это с попкорном )

Читать полностью…

Security Wine Chat (бывший DevSecOps Chat)

Там кажется больше политики всегда, чем здравого смысла и «техники»

Читать полностью…

Security Wine Chat (бывший DevSecOps Chat)

если бы все так было просто, особенно в рамках больших компаний

Читать полностью…

Security Wine Chat (бывший DevSecOps Chat)

Инфраструктура на мой взгляд должна быть похожа на подлодку. Утопило одну секцию - остальные плывут дальше

Читать полностью…

Security Wine Chat (бывший DevSecOps Chat)

где небольшой штат ИТ и небольшой сервис\группа сервисов

Читать полностью…

Security Wine Chat (бывший DevSecOps Chat)

так и я про это же…что создав чат и накидав туда прикладных кейсов врядли что-то изменится, т.к. ваш кейс не будет применим у меня 🤷

Читать полностью…

Security Wine Chat (бывший DevSecOps Chat)

скорее навязали сверху

Читать полностью…

Security Wine Chat (бывший DevSecOps Chat)

тут да, нужно не на уровне прикладного архитектора или даже CISO что-то менять, а на уровне трендмейкеров отрасли и возможно даже ИТ-отрасли, а не ИБ

Читать полностью…

Security Wine Chat (бывший DevSecOps Chat)

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

Читать полностью…
Subscribe to a channel