Про стандартизацию ФСТЭК и сертификацию процессов безопасной разработки
Помните один из первых постов этого канала? https://yangx.top/sec_devops/20 Отечественная стандартизация безопасной разработки продолжает набирать обороты. В пятницу ФСТЭК России опубликовал на regulation.gov Порядок сертификации процессов безопасной разработки программного обеспечения средств защиты информации :
https://regulation.gov.ru/Regulation/Npa/PublicView?npaID=143132
Главная идея, стоящая за проектом проста. Примирить требования регуляторики и Agile. Позволить разработчикам не отправлять каждый релиз на согласование в испытательную лабораторию, а доказав надежность своей CI/CD и пройдя её сертификацию, утверждать - что все продукты этой сертифицированной CI/CD заслуживают доверия.
Цитата из пояснительной записки к проекту:
"Сертификация процессов безопасной разработки программного обеспечения средств защиты информации является добровольной и позволит разработчикам и производителям сертифицированных средств защиты информации в случае проведения данной сертификации проводить испытания средств защиты информации, обусловленные внесением изменений в программное обеспечение средства защиты информации, самостоятельно без привлечения испытательной лаборатории. Что позволит сократить сроки проведения испытаний и затраты разработчиков и производителей сертифицированных средств защиты информации на проведение указанных испытаний средств защиты информации и, как следствие, снизить себестоимость средств защиты информации, применяемых в государственных информационных системах и на объектах критической информационной инфраструктуры."
Какое это имеет отношение к широкому рынку? Очень простое. Несмотря на определенные в документе границы (сертификация средств защиты), аналогичные подходы могут быть спроецированы и на обычные приложения. На компании не являющиеся разработчиками антивирусов, межсетевых экранов и иных специализированных средств.
В частности с февраля 2022 года Банк России в последней редакции своего Профиля защиты*, в разделе 7.4 рассказывает о требованиях к безопасности жизненного цикла. По мнению регулятора (оставим за скобками ряд правовых и технических нюансов) это позволяет избежать оценок соответствия или сертификации каждого релиза ДБО, т.е. по целям является аналогичным проекту ФСТЭК:
https://www.cbr.ru/content/document/file/132666/inf_note_feb_0422.pdf
*Профиль защиты является де-факто стандартом требований регулятора к банковским ДБО, личным кабинетам финансовых организаций, другим приложениям, связанным с финансовыми операциями (не являющимися средствами защиты по ФСТЭК России).
#dev #ops #law
Помните один из первых постов этого канала? https://yangx.top/sec_devops/20 Отечественная стандартизация безопасной разработки продолжает набирать обороты. В пятницу ФСТЭК России опубликовал на regulation.gov Порядок сертификации процессов безопасной разработки программного обеспечения средств защиты информации :
https://regulation.gov.ru/Regulation/Npa/PublicView?npaID=143132
Главная идея, стоящая за проектом проста. Примирить требования регуляторики и Agile. Позволить разработчикам не отправлять каждый релиз на согласование в испытательную лабораторию, а доказав надежность своей CI/CD и пройдя её сертификацию, утверждать - что все продукты этой сертифицированной CI/CD заслуживают доверия.
Цитата из пояснительной записки к проекту:
"Сертификация процессов безопасной разработки программного обеспечения средств защиты информации является добровольной и позволит разработчикам и производителям сертифицированных средств защиты информации в случае проведения данной сертификации проводить испытания средств защиты информации, обусловленные внесением изменений в программное обеспечение средства защиты информации, самостоятельно без привлечения испытательной лаборатории. Что позволит сократить сроки проведения испытаний и затраты разработчиков и производителей сертифицированных средств защиты информации на проведение указанных испытаний средств защиты информации и, как следствие, снизить себестоимость средств защиты информации, применяемых в государственных информационных системах и на объектах критической информационной инфраструктуры."
Какое это имеет отношение к широкому рынку? Очень простое. Несмотря на определенные в документе границы (сертификация средств защиты), аналогичные подходы могут быть спроецированы и на обычные приложения. На компании не являющиеся разработчиками антивирусов, межсетевых экранов и иных специализированных средств.
В частности с февраля 2022 года Банк России в последней редакции своего Профиля защиты*, в разделе 7.4 рассказывает о требованиях к безопасности жизненного цикла. По мнению регулятора (оставим за скобками ряд правовых и технических нюансов) это позволяет избежать оценок соответствия или сертификации каждого релиза ДБО, т.е. по целям является аналогичным проекту ФСТЭК:
https://www.cbr.ru/content/document/file/132666/inf_note_feb_0422.pdf
*Профиль защиты является де-факто стандартом требований регулятора к банковским ДБО, личным кабинетам финансовых организаций, другим приложениям, связанным с финансовыми операциями (не являющимися средствами защиты по ФСТЭК России).
#dev #ops #law
Telegram
DevSecOps Wine
Про стандарты безопасной разработки ФСТЭК
01.11.19 прошло совещание во ФСТЭК касательно обсуждения безопасной разработки
Выделен отдельный программный комитет ПК4 по безопасной разработке в составе ТК362.
Обсуждался проект стандарта "Руководство по безопасной…
01.11.19 прошло совещание во ФСТЭК касательно обсуждения безопасной разработки
Выделен отдельный программный комитет ПК4 по безопасной разработке в составе ТК362.
Обсуждался проект стандарта "Руководство по безопасной…
Здесь очень характерно поведение Microsoft, который после покупки GitHub, начал интегрировать с ним все больше интересных инструментов, связанных с безопасностью разработки. Например, уже в декабре на базе GitHub должен открыться (если еще не открылся) чат с Copilot, который позволит в числе прочих фич следить за безопасностью создаваемого кода в режиме онлайн. А тут можно посмотреть демо от CEO Microsoft с возможностями Copilot в части интеграции с различными приложениями и внешними источниками данных, в рамках Office 365 и как это позволит автоматизировать самые разные задачи. И это один продукт, одной корпорации, не специализированной на кибербезопасности. Понятное дело, что Microsoft известен своими багами и что в любом случае адаптация к новым возможностям займет какое-то время. Но кажется для всех, кто хочет "держать хвост по ветру" наступает время готовиться к адаптации прямо сейчас. И для тех, кто любит неопределенность и риски открываются возможности по развитию собственных стартапов в новых нишах. Например, почти наверняка потребуются консультанты по обучению команд AppSec и DevSecOps использованию и внедрению нового инструментария, возникнет потребность в защите API агентов GPT, встанут вопросы дообучения и тюнинга моделей, появятся истории про доверие и конфиденциальность вводимых данных, станет накапливаться ещё больше чисто юридических кейсов относительно прав собственности на "выделяемый AI продукт", потребуются стандарты и фреймворки безопасности AI и т.д. и т.п.
И хотя футурология и прогнозы дело не благодарное** (во многом потому, что технологии не существуют в вакууме и многое зависит от сил, занимающихся их внедрением, и заинтересованности субъектов, которые используют эти технологии), кажется, что AI не будет пустым хайпом и в ближайшую декаду мы увидим существенную трансформацию профессии, к которой можно и нужно готовиться прямо сейчас. А что думаете вы?
*Подробнее о состоянии безопасности в развивающихся странах можно посмотреть в замечательном выступлении Евгения Соболева: https://youtu.be/XWSrDseKMaI?si=QStWhX4u3BfSNlUp
**Здесь "на каникулы" рекомендую годную книгу "ИИ-2041. Десять образов нашего будущего" Кай-Фу Ли и Чэнь Цюфань - достаточно взвешенная и многомерная аналитика от профильного специалиста на тему влияния AI на разные области жизни. Сама книга смесь сборника художественных рассказов и научно-популярных заметок к каждому из них, где рассматриваются в том числе аспекты кибербезопасности AI.
#dev #ops #ai #прогнозы
И хотя футурология и прогнозы дело не благодарное** (во многом потому, что технологии не существуют в вакууме и многое зависит от сил, занимающихся их внедрением, и заинтересованности субъектов, которые используют эти технологии), кажется, что AI не будет пустым хайпом и в ближайшую декаду мы увидим существенную трансформацию профессии, к которой можно и нужно готовиться прямо сейчас. А что думаете вы?
*Подробнее о состоянии безопасности в развивающихся странах можно посмотреть в замечательном выступлении Евгения Соболева: https://youtu.be/XWSrDseKMaI?si=QStWhX4u3BfSNlUp
**Здесь "на каникулы" рекомендую годную книгу "ИИ-2041. Десять образов нашего будущего" Кай-Фу Ли и Чэнь Цюфань - достаточно взвешенная и многомерная аналитика от профильного специалиста на тему влияния AI на разные области жизни. Сама книга смесь сборника художественных рассказов и научно-популярных заметок к каждому из них, где рассматриваются в том числе аспекты кибербезопасности AI.
#dev #ops #ai #прогнозы
👍2❤1
State-of-SSPM-Report-2023.pdf
5.2 MB
SSPM и защита SaaS сервисов
В развитии вчерашнего лонгрида пример нового класса решений, ещё не сильно распространенного на рынке. SSPM призваны решать проблему контроля и безопасности интеграций компаний со все большим количеством облачных сервисов. Когда тот же самый GPT помощник, или онлайн-репозиторий не просто детектируется, но ставится на непрерывный контроль автоматически. Это подразумевает:
- правильную конфигурацию;
- выявление уязвимостей;
- мониторинг и реагирование на инциденты;
- контроль утечек защищаемой информации;
- управление привилегиями;
и многое другое
Подробнее про риски, подходы и модель работы с SaaS здорового человека можно почитать в прилагаемом отчете AppOmni - одного из вендоров SSPM. По данным авторов отчета в части безопасности SaaS на рынке доминирует ложная уверенность в надежности собственной системы защиты. Так 71% из 644 опрошенных оценивают уровень безопасности своих SaaS между средним и высоким, при том, что 79% из них сталкивались с соответствующими инцидентами за последние 12 месяцев. При этом, большинство опрошенных занимаются ручным контролем интеграции SaaS в организацию, и не осуществляют непрерывный контроль текущего состояния сервисов. Число же используемых сервисов и интеграций непрерывно растет.
Здесь очень хорошо видна коренная проблема ИБ: непрерывное развитие технологий и гонка за новыми интеграциями порождает небезопасный фронтир, который требует автоматизации. Автоматизация требует инвестиций времени и квалификации, либо деньги и сторонние решения с поддержкой. И вот уже на смену универсальным сканерам, IaC утилитам и system hardening решениям приходят "точечные продукты" под узкопрофильные задачи. Так и живем.
#ops #sspm #решение
В развитии вчерашнего лонгрида пример нового класса решений, ещё не сильно распространенного на рынке. SSPM призваны решать проблему контроля и безопасности интеграций компаний со все большим количеством облачных сервисов. Когда тот же самый GPT помощник, или онлайн-репозиторий не просто детектируется, но ставится на непрерывный контроль автоматически. Это подразумевает:
- правильную конфигурацию;
- выявление уязвимостей;
- мониторинг и реагирование на инциденты;
- контроль утечек защищаемой информации;
- управление привилегиями;
и многое другое
Подробнее про риски, подходы и модель работы с SaaS здорового человека можно почитать в прилагаемом отчете AppOmni - одного из вендоров SSPM. По данным авторов отчета в части безопасности SaaS на рынке доминирует ложная уверенность в надежности собственной системы защиты. Так 71% из 644 опрошенных оценивают уровень безопасности своих SaaS между средним и высоким, при том, что 79% из них сталкивались с соответствующими инцидентами за последние 12 месяцев. При этом, большинство опрошенных занимаются ручным контролем интеграции SaaS в организацию, и не осуществляют непрерывный контроль текущего состояния сервисов. Число же используемых сервисов и интеграций непрерывно растет.
Здесь очень хорошо видна коренная проблема ИБ: непрерывное развитие технологий и гонка за новыми интеграциями порождает небезопасный фронтир, который требует автоматизации. Автоматизация требует инвестиций времени и квалификации, либо деньги и сторонние решения с поддержкой. И вот уже на смену универсальным сканерам, IaC утилитам и system hardening решениям приходят "точечные продукты" под узкопрофильные задачи. Так и живем.
#ops #sspm #решение
👍8❤1🔥1