Size: a a a

DevSecOps - русскоговорящее сообщество

2020 June 01

GG

George Gaál in DevSecOps - русскоговорящее сообщество
Alexander Akulov
И как бы то, что все считают безопасников мудаками, а безопасники думают, что всем плевать на безопасность. В этом тоже есть стена непонимания которая была между Dev и Ops.
++++
источник

GG

George Gaál in DevSecOps - русскоговорящее сообщество
на самом деле нет, не плевать, хочется делать хорошо, но как обычно не хватает рук
источник

AK

Alexey Kudryavtsev in DevSecOps - русскоговорящее сообщество
Alexander Akulov
У QA есть куча тулов для отлова обычных багов, есть какие-то комьюнити, даже в самом маленьком стартапе есть отдельный человек. А для багов безопасности всё как-то сложно, по прежнему.
Смотря где, Саша ( привет ))) ). У нас в Банке с безопасностью так круто, шо капец....
источник

A

Asgoret in DevSecOps - русскоговорящее сообщество
George Gaál
на самом деле нет, не плевать, хочется делать хорошо, но как обычно не хватает рук
Не не хватает рук, а не хватает времени. Банально из-за того, что есть разрыв между бизнес отделами и ит (все ситуации "нужно было вчера" или "мы уже продали эту альфа фичу, как прод реди")
источник

GG

George Gaál in DevSecOps - русскоговорящее сообщество
Alexey Kudryavtsev
Смотря где, Саша ( привет ))) ). У нас в Банке с безопасностью так круто, шо капец....
даже пернуть не дают, простите?
источник

A

Asgoret in DevSecOps - русскоговорящее сообщество
Ну если мы берем за истину, что все хотят сделать хорошо
источник

AK

Alexey Kudryavtsev in DevSecOps - русскоговорящее сообщество
George Gaál
даже пернуть не дают, простите?
Именно, так. И вздохнуть тоже))) Ну что поделать - безопасность.
источник

SP

Sergey Pechenkó in DevSecOps - русскоговорящее сообщество
Alexander Akulov
И как бы то, что все считают безопасников мудаками, а безопасники думают, что всем плевать на безопасность. В этом тоже есть стена непонимания которая была между Dev и Ops.
Потому что между подходом "алерты в телегу запрещены" и "давайте сделаем понятный и прозрачный шлюз для алертов в телегу, такие-то вещи разрешены, такие-то будут баниться прямо на шлюзе" две большие разницы. Угадайте, какой подход проще для безопасников?
источник

S

St in DevSecOps - русскоговорящее сообщество
Sergey Pechenkó
Потому что между подходом "алерты в телегу запрещены" и "давайте сделаем понятный и прозрачный шлюз для алертов в телегу, такие-то вещи разрешены, такие-то будут баниться прямо на шлюзе" две большие разницы. Угадайте, какой подход проще для безопасников?
А как сделать такой шлюз? Кто его развернёт,  кто будет поддерживать? Кто писать политики?
источник

SP

Sergey Pechenkó in DevSecOps - русскоговорящее сообщество
St
А как сделать такой шлюз? Кто его развернёт,  кто будет поддерживать? Кто писать политики?
Как-как..... Написать самостоятельно, или использовать готовое ПО - squid тот же или nginx.
А кто - разработчики, как заинтересованные в алертах +
безопасники, как заинтересованные в предотвращении утечек.
источник

NK

Nick Kritsky in DevSecOps - русскоговорящее сообщество
Sergey Pechenkó
Потому что между подходом "алерты в телегу запрещены" и "давайте сделаем понятный и прозрачный шлюз для алертов в телегу, такие-то вещи разрешены, такие-то будут баниться прямо на шлюзе" две большие разницы. Угадайте, какой подход проще для безопасников?
А вот ещё два подхода. Первый - «давайте напишем, задокументируем, задеплоим такой шлюз, и передадим его безопасникам».
Второй - «давайте ждать пока безопасники сделают нам такой шлюз - это ведь им нужно алерты в телегу слать».
Как думаешь - какой путь выберут программисты? :)
источник

K

Konstantin in DevSecOps - русскоговорящее сообщество
Nick Kritsky
А вот ещё два подхода. Первый - «давайте напишем, задокументируем, задеплоим такой шлюз, и передадим его безопасникам».
Второй - «давайте ждать пока безопасники сделают нам такой шлюз - это ведь им нужно алерты в телегу слать».
Как думаешь - какой путь выберут программисты? :)
путь "шлюз? какой шлюз?".
источник

S

St in DevSecOps - русскоговорящее сообщество
Sergey Pechenkó
Как-как..... Написать самостоятельно, или использовать готовое ПО - squid тот же или nginx.
А кто - разработчики, как заинтересованные в алертах +
безопасники, как заинтересованные в предотвращении утечек.
И как squid или nginx будет анализировать текст? А если картинка пойдёт? Солар продаёт такие решения за нормальную такую кучку миллионов рублей, а мы вот так, херак херак и в продакшен
источник

GG

George Gaál in DevSecOps - русскоговорящее сообщество
St
И как squid или nginx будет анализировать текст? А если картинка пойдёт? Солар продаёт такие решения за нормальную такую кучку миллионов рублей, а мы вот так, херак херак и в продакшен
Легко можно картинку вырезать
источник

GG

George Gaál in DevSecOps - русскоговорящее сообщество
Тупо условно регекс на фильтр
источник

S

St in DevSecOps - русскоговорящее сообщество
Ну и ещё, чтоб что то подобное сделать, хотя бы анализ текста, то надо кучу ресурсов убить, выделить команду разрабов и безопасников, а нужно это бизнесу? Представляю пойдут руководители одних или других и скажут, давайте убьём месяц на написание и команду выделим, человека два-три. А потом этот фильтр, должен быть отказоустойчивым, его кто то поддерживать должен,  то есть еще пару серверов и человек и все ради логов в телегу...
источник

S

St in DevSecOps - русскоговорящее сообщество
George Gaál
Тупо условно регекс на фильтр
А дальше что? Просто вырезать и слать дальше? Или блокировать? Или надо разбираться с каждой сработкой?
источник

GG

George Gaál in DevSecOps - русскоговорящее сообщество
St
А дальше что? Просто вырезать и слать дальше? Или блокировать? Или надо разбираться с каждой сработкой?
Слушай. В первоначальном варианте достаточно просто логировать
источник

GG

George Gaál in DevSecOps - русскоговорящее сообщество
Если произошла утечка - мы знаем, кому по башке настучать
источник

GG

George Gaál in DevSecOps - русскоговорящее сообщество
Особо рьяных сливщиков это остановит
источник