Мы собрали открытые книги и статьи ведущих экспертов по кибербезопасности, а также руководства для желающих погрузиться в DevSecOps. Материалы из подборки расскажут, какие ИБ-практики можно называть самыми неэффективными и с чего начать защиту облачных решений. И напомним, что у нас есть открытый курс по основам DevOps-подхода, Kubernetes и современных облачных решений.
DevSecOps 101 — знакомство для начинающих
Хорошей отправной точкой в изучении DevSecOps может стать руководство «Безопасность приложений 101». Его автор — фронтенд-разработчик Алекс Макра, опубликовавший материал на платформе TechSplicer. Там у инженера набрались уже сотни постов — большинство о решениях в сфере ИБ. Еще автор ведет блог про кибербез и МО на персональном сайте. Например, в одной статье он анализирует, как системы ИИ трансформируют циклы разработки.
Но конкретно этот материал ориентирован на новичков, поэтому автор начинает с азов: что такое DevSecOps, какие проблемы помогает решить такой подход, какие преимущества для компании он предлагает. Отдельный подраздел посвящен сложностям и нюансам, связанным с интеграцией практик безопасности на всех этапах жизненного цикла разработки программного обеспечения: в частности, автор затрагивает тему возрастающей нагрузки на разработчиков и специалистов по ИБ (в контексте большого количества оповещений от систем безопасности).
Залогом успешного внедрения DevSecOps Макра считает переход от традиционного CI/CD к конвейеру с многоуровневой проверкой безопасности. Начать можно с поиска уязвимостей в зависимостях, затем проверить контейнерные образы и завершить динамическим тестированием готового программного обеспечения.
Как построить дорожную карту облачной безопасности
Чандрапал Бадшах — эксперт в области защиты AWS-инфраструктуры. Он разрабатывает решения для автоматического выявления и нейтрализации угроз, а также основал образовательную платформу Cloud Security Club, где специалисты изучают методы защиты облачных сред. Он подготовил материал для руководителей стартапов и DevOps-инженеров, в котором объясняет, как составить дорожную карту безопасности для облачного проекта. По его словам, многие DevSecOps-специалисты ограничиваются выбором CSPM- или CNAPP-решений и мониторингом уведомлений, но такой подход не соответствует современным стандартам кибербезопасности.
Бадшах опирается на собственный опыт и разбирает примеры на базе инфраструктуры крупного западного облачного провайдера. Однако предлагаемые им принципы универсальны — их можно адаптировать под любые облачные платформы, включая мультиоблачные среды. Прежде чем строить дорожную карту безопасности, он советует четко ответить на четыре ключевых вопроса:
Какие облачные платформы использует компания?
Каковы приоритеты в сфере безопасности на ближайшие полгода?
Как имеющиеся cloud-сервисы соотносятся с этими приоритетами?
Насколько масштабной должна быть программа облачной безопасности?
Автор также приводит примеры того, как могут выглядеть ответы на эти вопросы для небольшого стартапа и крупной организации с сотнями специалистов. При этом автор не ограничивается теорией — он разбирает примеры дорожных карт от экспертов (опубликованных в открытом доступе), анализирует их и выделяет ключевые преимущества.
Шаблон Скотта Пайпера — идеален для молодых стартапов, так как предлагает простую и понятную структуру.
Модель от облачного провайдера — охватывает политики и лучшие практики от IAM до повышения отказоустойчивости. В целом подходит как для малого бизнеса, так и для крупных компаний с сотнями сотрудников.
Бадшах и сам дает несколько рекомендаций. Во-первых, при построении дорожной карты необходимо учитывать требования регуляторов: их игнорирование может создать серьезные риски для стартапа. Во-вторых, следует начинать с внедрения превентивных механизмов защиты и только потом переходить к реактивным. Наконец, важно регулярно (например, каждые два квартала) пересматривать план безопасности, чтобы оценить его эффективность и скорректировать стратегию.
Zero-trust в работе c генеративными моделями
Традиционные методы обеспечения безопасности не подходят для разработки систем GenAI — так считает разработчик Адитья Рохилл. Он работает в стартапе, который развивает системы ИИ для борьбы с киберпреступлениями, а до этого был сотрудником Amazon, Walmart Labs и Samsung Research.
Эксперт подготовил руководство, в котором объясняет, почему при разработке генеративных систем ИИ необходимо придерживаться принципов zero-trust. Рохилл приводит рекомендации по построению безопасной архитектуры в соответствии с этой моделью в формате: «Зачем это нужно --> Как внедрить».
Например, в разделе об управлении идентификацией он подчёркивает: доступ для каждого сервиса, пользователя или ИИ-агента должен строго проверяться. Этого можно добиться за счет применения стандартов вроде SPIFFE/SPIRE, внедрения облачных систем управления пользователями, группами, политиками и ролями (IAM) и мониторинга утечек учётных данных с помощью инструментов типа truffleHog.
В завершение Рохилл предлагает список материалов для углублённого изучения темы. Среди них — книга Computer Security, выложенная в свободный доступ по лицензии CC BY-SA 4.0. Её авторы рассматривают процессы DevSecOps через призму экономической модели киберзащиты.
Ещё Рохилла советует пройти вводный курс по киберзащите от Калифорнийского университета в Беркли (его материалы выложены в открытый доступ под лицензией Creative Commons). В нем рассматриваются основы ИБ: термины и определения, известные практики по борьбе с уязвимостями.
Шесть глупых идей в кибербезопасности
Ещё в 2005 году вышла статья, в которой автор разбирает неудачные решения в сфере цифровой безопасности. Этот материал — наглядный пример того, когда можно извлечь полезную информацию не только из самой публикации, но и из её обсуждений на других ресурсах. В своё время она вызвала резонанс — даже криптограф, писатель и специалист по компьютерной безопасности Брюс Шнайер обсуждал предложенные тезисы. И сегодня материал «всплывает» на профильных площадках — фактически он стал классикой, обязательной к прочтению для начинающих разработчиков, сисадминов и DevOps-специалистов [да и опытным профессионалам может дать повод для размышлений].
Автор этого «антирейтинга» — Маркус Ранум, эксперт в области информационной безопасности, один из разработчиков первого коммерческого брандмауэра DEC SEAL, который также стоял у истоков сканера уязвимостей Nessus.
В частности, Ранум пишет, что полагаться на черные списки при настройке файрволов бессмысленно — список киберугроз ежедневно расширяется. Он также отмечает, что конечный пользователь не должен отвечать за кибербезопасность — и это ключевой принцип для DevSecOps.
Еще автор предупреждает: недоделанные системы защиты опаснее их отсутствия. Если решение не прошло полноценную проверку — лучше отложить внедрение, чем создавать ложное чувство безопасности.