#безопасная_архитектура — Public Fediverse posts

4 мифа про DevSecOps, которые мешают безопасной разработке

Привет, Хабр! На связи Николай Лузгин, DevSecOps Lead и Илья Шаров (@issharov), Head of DevSecOps из МТС Web Services. Те самые безопасники, которые приходят в каске, запускают сканеры и доводят разработчиков до слез (нет). На самом деле DevSecOps — это не про страдания и бесконечные отчеты сканеров в PDF, а про здравый смысл и взаимодействие. У нас в MWS это полноценный процесс, состоящий не только из инструментов, пайплайнов, требований и Security Gate. В своей работе мы учитываем особенности продуктовой разработки большого количества команд — от крупных до малых инженерных групп, создающих MVP. Вместе с ними боремся за Time-to-Market и оптимизацию расходов, но при этом делаем ставку на повышение безопасности выпускаемого продукта. И главное — помогаем находить уязвимости на ранних этапах. Объясняем их суть на понятном языке, проверяем эксплуатируемость, придумываем меры митигации и составляем план по устранению — причем не где-то там в своих кабинетах, а вместе с командой при планировании работы на спринт или квартал. Звучит неправдоподобно? Из-за образа безопасников-церберов, который складывался в ИТ-тусовке десятилетиями, работа DevSecOps и правда представляется по-другому. Мы решили разобрать четыре главных мифа, которые встречаются при выстраивании отношений между ИБ и ИТ. Погнали рушить стереотипы!

https://habr.com/ru/companies/ru_mts/articles/1004448/

#devsecops #devsecops_и_devops #безопасная_разработка #ssdlc #мифы_о_devsecops #безопасная_архитектура #безопасный_процесс #shift_left #shift_left_security

4 мифа про DevSecOps, которые мешают безопасной разработке

Привет, Хабр! На связи Николай Лузгин, DevSecOps Lead и Илья Шаров (@issharov), Head of DevSecOps из МТС Web Services. Те самые безопасники, которые приходят в каске, запускают сканеры и доводят разработчиков до слез (нет). На самом деле DevSecOps — это не про страдания и бесконечные отчеты сканеров в PDF, а про здравый смысл и взаимодействие. У нас в MWS это полноценный процесс, состоящий не только из инструментов, пайплайнов, требований и Security Gate. В своей работе мы учитываем особенности продуктовой разработки большого количества команд — от крупных до малых инженерных групп, создающих MVP. Вместе с ними боремся за Time-to-Market и оптимизацию расходов, но при этом делаем ставку на повышение безопасности выпускаемого продукта. И главное — помогаем находить уязвимости на ранних этапах. Объясняем их суть на понятном языке, проверяем эксплуатируемость, придумываем меры митигации и составляем план по устранению — причем не где-то там в своих кабинетах, а вместе с командой при планировании работы на спринт или квартал. Звучит неправдоподобно? Из-за образа безопасников-церберов, который складывался в ИТ-тусовке десятилетиями, работа DevSecOps и правда представляется по-другому. Мы решили разобрать четыре главных мифа, которые встречаются при выстраивании отношений между ИБ и ИТ. Погнали рушить стереотипы!

https://habr.com/ru/companies/ru_mts/articles/1004448/

#devsecops #devsecops_и_devops #безопасная_разработка #ssdlc #мифы_о_devsecops #безопасная_архитектура #безопасный_процесс #shift_left #shift_left_security

4 мифа про DevSecOps, которые мешают безопасной разработке

Привет, Хабр! На связи Николай Лузгин, DevSecOps Lead и Илья Шаров (@issharov), Head of DevSecOps из МТС Web Services. Те самые безопасники, которые приходят в каске, запускают сканеры и доводят разработчиков до слез (нет). На самом деле DevSecOps — это не про страдания и бесконечные отчеты сканеров в PDF, а про здравый смысл и взаимодействие. У нас в MWS это полноценный процесс, состоящий не только из инструментов, пайплайнов, требований и Security Gate. В своей работе мы учитываем особенности продуктовой разработки большого количества команд — от крупных до малых инженерных групп, создающих MVP. Вместе с ними боремся за Time-to-Market и оптимизацию расходов, но при этом делаем ставку на повышение безопасности выпускаемого продукта. И главное — помогаем находить уязвимости на ранних этапах. Объясняем их суть на понятном языке, проверяем эксплуатируемость, придумываем меры митигации и составляем план по устранению — причем не где-то там в своих кабинетах, а вместе с командой при планировании работы на спринт или квартал. Звучит неправдоподобно? Из-за образа безопасников-церберов, который складывался в ИТ-тусовке десятилетиями, работа DevSecOps и правда представляется по-другому. Мы решили разобрать четыре главных мифа, которые встречаются при выстраивании отношений между ИБ и ИТ. Погнали рушить стереотипы!

https://habr.com/ru/companies/ru_mts/articles/1004448/

#devsecops #devsecops_и_devops #безопасная_разработка #ssdlc #мифы_о_devsecops #безопасная_архитектура #безопасный_процесс #shift_left #shift_left_security

4 мифа про DevSecOps, которые мешают безопасной разработке

Привет, Хабр! На связи Николай Лузгин, DevSecOps Lead и Илья Шаров (@issharov), Head of DevSecOps из МТС Web Services. Те самые безопасники, которые приходят в каске, запускают сканеры и доводят разработчиков до слез (нет). На самом деле DevSecOps — это не про страдания и бесконечные отчеты сканеров в PDF, а про здравый смысл и взаимодействие. У нас в MWS это полноценный процесс, состоящий не только из инструментов, пайплайнов, требований и Security Gate. В своей работе мы учитываем особенности продуктовой разработки большого количества команд — от крупных до малых инженерных групп, создающих MVP. Вместе с ними боремся за Time-to-Market и оптимизацию расходов, но при этом делаем ставку на повышение безопасности выпускаемого продукта. И главное — помогаем находить уязвимости на ранних этапах. Объясняем их суть на понятном языке, проверяем эксплуатируемость, придумываем меры митигации и составляем план по устранению — причем не где-то там в своих кабинетах, а вместе с командой при планировании работы на спринт или квартал. Звучит неправдоподобно? Из-за образа безопасников-церберов, который складывался в ИТ-тусовке десятилетиями, работа DevSecOps и правда представляется по-другому. Мы решили разобрать четыре главных мифа, которые встречаются при выстраивании отношений между ИБ и ИТ. Погнали рушить стереотипы!

https://habr.com/ru/companies/ru_mts/articles/1004448/

#devsecops #devsecops_и_devops #безопасная_разработка #ssdlc #мифы_о_devsecops #безопасная_архитектура #безопасный_процесс #shift_left #shift_left_security

Безопасность «на берегу»: опыт внедрения подхода Secure by Design в ИТ-компании

Про Secure by Design в кибербезе не слышал только ленивый, но не только лишь все смогут объяснить, как на практике выглядит процесс внедрения этого подхода в крупной ИТ-компании. Чтобы разобраться в этом, мы поговорили с Романом Паниным — руководителем направления архитектуры ИБ в крупной телекоммуникационной компании и автором Telegram-канала « Пакет безопасности» . Роман поделился собственным опытом применения Secure by Design и рассказал о преимуществах и издержках методики. «На десерт» — несколько полезных лайфхаков для тех, кто планирует внедрить эту практику в своей компании. Передаем слово эксперту!

https://habr.com/ru/companies/bastion/articles/842874/

#безопасная_архитектура #secure_by_design #безопасная_разработка #безопасность_вебприложений #кибериммунинет #безопасный_код #ИБархитектура #киберимунный_подход #архитектура_безопасности

Безопасное проектирование программного обеспечения: Хеширование и salting

Автор статьи: Рустем Галиев (IBM Senior DevOps Engineer & Integration Architect) Привет, Хабр! Сегодня продолжим про безопасную архитектуру. В современном цифровом мире безопасность данных становится все более актуальной задачей. С ростом числа кибератак и утечек информации, защита конфиденциальных данных пользователей является приоритетом для разработчиков программного обеспечения. Одним из ключевых методов обеспечения безопасности является хеширование и добавление соли (salting) к паролям и другим критически важным данным. Хеширование представляет собой процесс преобразования исходных данных в уникальный зашифрованный код фиксированной длины. Этот метод широко используется для защиты паролей, так как даже при утечке хешированных данных восстановить оригинальный пароль крайне сложно. Однако, хеширование само по себе не всегда достаточно для полной безопасности. Злоумышленники могут применять атаки типа радужных таблиц (rainbow tables) для нахождения исходных значений по их хешам. Для усиления защиты применяется salting — добавление случайных данных к исходным паролям перед их хешированием. Этот подход значительно усложняет задачу для злоумышленников, так как каждый хеш становится уникальным, даже если несколько пользователей имеют одинаковый пароль. В результате, атаки с использованием радужных таблиц и другие методы подбора паролей становятся менее эффективными. В данной статье мы подробно рассмотрим концепции хеширования и salting, их роль в безопасном проектировании программного обеспечения.

https://habr.com/ru/companies/otus/articles/822953/

#безопасная_архитектура #безопасность_данных #хеширование #salting