Куда я попал?
AppSec Table Top: методология безопасной разработки от Positive Technologies
Framework
Эксплуатация
Для проведения оценки соответствия по документу войдите в систему.
Список требований
-
Инициатива: Сетевая безопасность
Описание:
Сетевая безопасность — это комплекс мер, направленных на защиту подключенных сетей и инфраструктуры от несанкционированного доступа, утечки информации, вредоносных действий и других угроз, которые могут привести к нежелательным последствиям (финансовые потери, нарушение конфиденциальности, простой в работе и т. д.).
Основные методы обеспечения сетевой безопасности:- Контроль доступа [AC2].
- Аутентификация и авторизация.
- Сегментация сети и виртуальные частные сети (VPN) [AC1].
- Применение инструментов защиты от утечек (DLP).
- Применение инструментов обнаружения и предотвращения вторжений (IPS/IDS).
- Использование брандмауэров [MI2].
- Использование шифропротоколов.
- Мониторинг безопасности [MI3].
Сетевая безопасность на этапе эксплуатации необходима для защиты сетей и данных от угроз, которые могут возникнуть в процессе работы приложения в промышленной среде. Она обеспечивает защиту от несанкционированного доступа, вредоносных программ, DDoS-атак, фишинга и других угроз. Сетевая безопасность также помогает обеспечить соответствие нормативным требованиям [TMR3], предотвратить простои в работе и сохранить репутацию организации.
Шаги реализации:- Проанализировать существующие угрозы и уязвимости сети, определить наиболее уязвимые точки и оценить потенциальный ущерб от возможных атак.
- Создать четкую политику безопасности, которая устанавливает правила доступа к сети и использования ресурсов.
- В соответствии с требованиями реализовать необходимые меры сетевой безопасности: контроль доступа, VPN, IPS/IDS, брандмауэры и т. д.
- Обеспечить сеть постоянным мониторингом на поиск подозрительных действий и уязвимостей.
- Регулярно обновлять настройки инструментов сетевой безопасности и политику безопасности.
- Дополнить политику безопасности всеми используемыми методами, инструментами и системами сетевой безопасности.
- Довести политику до сотрудников и разместить на внутреннем портале.
Зона ответственности: ИБ
Инструмент: FW, DLP, IPS/IDS, SIEM и т.д.
Артефакт: Политика безопасности -
Инициатива: SOC
Описание:
Security Operations Center (SOC) — это специализированный центр, где группа сотрудников поддержки круглосуточно мониторит безопасность приложений и сети, отслеживает потенциальные угрозы, предотвращает инциденты и реагирует на них [MI5] в реальном времени.
SOC использует разнообразные инструменты для мониторинга и анализа данных, включая:- Системы мониторинга сетевой безопасности (SIEM): собирают, анализируют и коррелируют данные из различных источников (брандмауэры, IPS/IDS, антивирусное ПО, журналы событий, данные о приложении).
- Антивирусное ПО: сканирует систему на наличие вредоносных программ и предотвращает их запуск.
- Журналы событий: собирают информацию о действиях пользователей, событиях в системе и сетевом трафике.
Для более полного понимания специалистами приложений у них должен быть доступ ко всей эксплуатационной документации [IA1].
Шаги реализации:- Определить конкретные методы и задачи, которые будет решать SOC.
- Выбрать систему управления информацией и событиями безопасности (SIEM), которая будет собирать и анализировать данные из различных источников.
- Внедрить необходимые инструменты мониторинга и интегрировать их с SIEM-системой (IPS/IDS, антивирусное ПО, инструменты мониторинга сети).
- Настроить сбор данных из различных источников (журналы событий, сетевой трафик, данные приложений).
- Создать правила для SIEM для фильтрации подозрительных событий.
- Регулярно мониторить работу SOC и отслеживать эффективность его действий.
- Анализировать данные об инцидентах и совершенствовать процедуры работы SOC.
- Составить документацию (или дополнить политику безопасности) по работе SOC, включая работу всех инструментов, процесс работы по мониторингу за приложениями, правила SIEM и т. д.
- Довести документацию до сотрудников и разместить на внутреннем портале.
Зона ответственности: ИБ
Инструмент: SIEM
Артефакт: Политика безопасности -
Инициатива: Анализ инцидентов
Описание:
Периодический анализ инцидентов безопасности необходим для эффективного управления рисками и повышения защищенности приложений. Анализ помогает понять причины инцидентов, идентифицировать угрозы и оценить их последствия. Например, если инцидент произошел из-за уязвимости в программном обеспечении, анализ поможет определить, какие именно уязвимости были использованы и как их можно исправить.
Понимание причин и последствий инцидентов позволяет обновить профиль рисков [RM2], скорректировать стратегию [SSDL5] и улучшить процессы за счет выявления слабых мест и проблем в системе безопасности. Анализ инцидентов также помогает повысить осведомленность сотрудников о киберугрозах и уровень культуры безопасности в организации.
Шаги реализации:- Наладить сбор информации о происходящих инцидентах безопасности (время, тип, влияние, причины инцидента, принятых меры).
- Классифицировать инциденты по типу, критичности и причине для выявления наиболее распространенных угроз.
- Проанализировать причины инцидентов, чтобы определить слабые места в системе безопасности или стратегии.
- Оценить ущерб, который был нанесен в результате инцидентов.
- На основе анализа инцидентов разработать и внедрить рекомендации по улучшению безопасности (изменения в политике безопасности или стратегии SSDL, обновление программного обеспечения, настройка инструментов, повышение осведомленности о киберугрозах).
- Сделать такую ретроспективу регулярной, определить периодичность и ответственных лиц.
- По результатам каждой ретроспективы также разрабатывать и внедрять рекомендации по повышению уровня безопасности.
Зона ответственности: ИБ
Инструмент: SIEM
Артефакт: Политика безопасности -
Инициатива: Плейбук реагирования
Описание:
Процесс постоянного мониторинга безопасности [MI3] можно дополнить плейбуком реагирования, в котором будут описаны возможные недопустимые события и представлен план поведения в случае их реализации. Это позволит ускорить время устранения инцидента и обеспечить слаженность действий сотрудников.
При создании плейбука следует опираться на анализ предыдущих инцидентов и реакцию на них [MI4], а также учитывать потенциальные недопустимые события, определенные в профиле рисков [RM2].
Шаги реализации:- Провести анализ возникших инцидентов и предпринятых мер, оценить их эффективность.
- Определить наиболее вероятные и критичные потенциальные недопустимые события и распространенные инциденты.
- Составить план реагирования на каждый из таких инцидентов.
- Создать плейбук реагирования — документ, в котором содержатся четкая инструкция действий по каждому инциденту, порядок отработки и эскалации, участвующие роли и т. д.
- Ознакомить сотрудников с плейбуком и разместить его на внутреннем портале.
Зона ответственности: ИБ
Инструмент: -
Артефакт: Плейбук реагирования -
Инициатива: Порядок работы с дефектами
Описание:
Формализовать работу с обнаруженными дефектами необходимо как на этапе разработки, так и в процессе эксплуатации ПО. Для этого требуется:- Выделить зоны ответственности по отработке и триажу дефектов.
- Выстроить процесс передачи дефектов разработчикам.
- Разработать подходы для оценки [VM3] и приоритизации дефектов, которые будут регламентировать очередность, критичность и допустимость эксплойта.
Очень важно использовать централизованное место разбора дефектов (например, дефект-трекер или инструмента класса ASOC).
Шаги реализации:- Определить общий порядок работы с дефектами.
- Выделить роли, ответственные за обнаружение, прием, классификацию, триаж, отработку и эскалацию дефектов.
- Назначить конкретные обязанности каждой роли.
- Встроить в процесс централизованную систему для управления дефектами (таск-трекер или оркестратор) и обеспечить ее доступность для всех ролей.
- Определить порядок передачи дефектов от тестировщиков к разработчикам.
- Разработать правила эскалации в различных ситуациях (например, при отсутствии ответа от разработчика в течение определенного времени или при выявлении критического дефекта).
- Разработать систему приоритизации дефектов и критерии оценки дефектов по критичности.
- Определить критерии допустимости дефектов и определить риск-акцепторов.
- Определить порядок исправления дефектов и установить SLA.
- Использовать дефекты в качестве метрик для улучшения стратегии SSDL (особо распространенные дефекты можно использовать для формирования программы обучения разработчиков).
- Дополнить регламент безопасной разработки процессом работы с дефектами (с описанием ролей, дефектов, используемых инструментов и т. д.).
- Довести регламент до сотрудников и разместить на внутреннем портале.
Зона ответственности: ИБ/ИТ
Инструмент: ASOC, Дефект-трекер
Артефакт: Регламент безопасной разработки -
Инициатива: Кастомизация инструментов анализа
Описание:
Кастомизация правил сканирования и обработки результатов в инструментах анализа [SPA3], [SCA1], [DPA2] и самом конвейере разработки [SPA4], [SCA2], [DPA4] позволяет учесть специфику проекта и минимизировать количество ложных срабатываний. Практика ускоряет работу инструментов и упрощает работу с дефектами для разработчиков. Кастомизация позволяет указать исключения для определенных участков кода, создать собственные правила сканирования и ввести системы корреляции и дедупликации дефектов.
Шаги реализации:- Проанализировать результаты работы инструментальных практик БР (SAST, DAST, SCA).
- На основе анализа создать новые правила сканирования, учитывающие специфику приложений, ложноположительные срабатывания и т. д.
- Внедрить настроенные правила в процесс сканирования инструментов.
- Создать документацию (или дополнить регламент безопасной разработки), описывающую новые правила сканирования.
- Довести документацию до сотрудников и разместить на внутреннем портале.
Зона ответственности: ИБ/Appsec
Инструмент: SAST, DAST, SCA
Артефакт: Регламент безопасной разработки -
Инициатива: Оценка критичности дефектов
Описание:
Методика оценки критичности и приоритизации дефектов основывается на модели критичности приложений [OAD2]. Оценка помогает определить приоритет отработки дефектов, их критичность, применимость и условия, когда дефект может стать блокером и его необходимо пропустить, либо наоборот, когда пропускать дефект нельзя.
Важно ввести роль риск-акцептора, ответственного за принятие рисков, решения о пропускании или немедленном исправления дефекта. Риск-акцептор принимает эскалации и при необходимости согласовывает риски с заказчиками. Такой подход позволит создать прозрачный и контролируемый процесс управления дефектами и обеспечить баланс между качеством и сроками разработки.
Шаги реализации:- Изучить порядок работы с дефектами и методику оценки критичности приложений.
- Определить уровни критичности дефектов (блокирующий, серьезный, малый, косметический) и факторы, влияющие на критичность.
- Установить правила определения приоритета дефектов в зависимости от критичности и влияния.
- Определить ответственного за принятие рисков, решение о пропускании или немедленном исправления дефекта.
- Разработать процедуры эскалации дефектов к риск-акцептору и бизнес-заказчику.
- Дополнить мероприятиями по оценке критичности и приоритизации методику критичности приложений.
- Ознакомить сотрудников с методикой и разместить ее на внутреннем портале.
- Внедрить методику в процесс работы с дефектами.
Зона ответственности: ИБ
Инструмент: -
Артефакт: Методика критичности/ приоритизации приложений -
Инициатива: Техподдержка
Описание:
После релиза приложения необходимо обеспечить его бесперебойную работу и реагировать на проблемы пользователей. Для этого формируется группа сотрудников, ответственных за сопровождение и техническую поддержку. Эта группа должна иметь четкие процессы и инструкции для эффективного реагирования на разнообразные ситуации.
Необходимо разработать систему приема, регистрации и обработки заявок от пользователей [TS2] (например, тикет-систему), определить процедуры реагирования на внештатные ситуации (сбои в работе приложения, ошибки в функциональности). Для каждой ситуации важно установить уровень критичности и определить ответственных за ее решение.
В случае возникновения серьезных проблем необходимо разработать процесс эскалации инцидентов [MI3].
Четко определенные процессы и инструкции позволят обеспечить эффективное реагирование на проблемы пользователей, минимизировать время простоя приложения и поддержать высокий уровень удовлетворенности клиентов.
Шаги реализации:- Определить сотрудников, которые войдут в группу техподдержки.
- Определить график и общий процесс работы техподдержки.
- Создать систему приема и обработки заявок от пользователей, определить шаблоны заявок, процедуры регистрации и отработки.
- Распределить инциденты по уровню критичности (сбои, ошибки, уязвимости), назначить ответственных за решение проблем.
- Разработать базу знаний и инструкции для пользователей по часто встречающимся проблемам, решениям.
- Составить подобный артефакт, разместить его на внутреннем портале, ознакомить с ним сотрудников и пользователей.
- Дополнить перечень эксплуатационной документации.
Зона ответственности: Организация
Инструмент: -
Артефакт: F.A.Q., Эксплуатационная документация -
Инициатива: Обратная связь
Описание:
Пользователи, взаимодействуя с приложением, могут обнаружить различные проблемы: от ошибок в дизайне до некорректной работы функционала. Обратная связь — не требующий больших ресурсов источник информации о потенциальных уязвимостях, которые могли остаться незамеченными во время тестирования.
Обратная связь от пользователей также является ценным инструментом для своевременного реагирования на аварийные ситуации. Если процессы технической поддержки [TS1] налажены и отработаны, пользователи могут стать первыми, кто обнаружит проблему и сообщит о ней.
Шаги реализации:- Внедрить механизмы сбора обратной связи от пользователей (контактные данные, кнопка в приложении, опросы по качеству).
- Определить ответственных за сбор и анализ обратной связи.
- Наладить процесс обработки фидбека от пользователей.
- Наладить процесс отработки обратной связи специалистами техподдержки.
- Анализировать фидбек и выявлять потенциальные дефекты.
Зона ответственности: Организация
Инструмент: -
Артефакт: -
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.