Принципы организации медицинской помощи: триаж, логистика, маршрутизация
Сортировка пациентов происходит непосредственно на въезде в отделение неотложной помощи, специалисты оценивают, куда пациента направить дальше: в экстренную реанимацию, оперблок либо на диагностическую койку. Проведение медицинской сортировки требуется даже для двух пациентов, если они одновременно поступили во флагманский центр.
ПРОВЕДЕНИЕ МЕДИЦИНСКОЙ СОРТИРОВКИ ТРЕБУЕТСЯ ДАЖЕ ДЛЯ ДВУХ ПАЦИЕНТОВ, ЕСЛИ ОНИ ОДНОВРЕМЕННО ПОСТУПИЛИ ВО ФЛАГМАНСКИЙ ЦЕНТР
Алгоритм проведения медицинской сортировки на госпитальном этапе в медицинских организациях был утвержден приказом* Департамента здравоохранения города Москвы в декабре 2021 года. Регламент приказа заключается в регулировании и упорядочивании последовательности и перечня мероприятий по осуществлению медицинской сортировки в приемных отделениях скоропомощных медицинских организаций. Основными задачами медицинской сортировки, согласно данному приказу, являются оптимизация логистики пациентов и сокращение времени ожидания начала оказания медицинской помощи тяжелобольным пациентам. Приказ стал одним из основополагающих нормативных документов нового стандарта экстренной медицинской помощи.
* Приказ ДЗМ от 13.12.2021 № 1243 «Об утверждении Алгоритма проведения медицинской сортировки на госпитальном этапе оказания медицинской помощи в медицинских организациях государственной системы здравоохранения города Москвы, оказывающих специализированную, в том числе высокотехнологичную, медицинскую помощь взрослому населению»
Категории пациентов в соответствии с принципами медицинской сортировки (триажа):
Срочные пациенты, нуждающиеся в экстренной реанимационной помощи или экстренной хирургии. Это пациенты с кровотечениями, обширными ранами, проникающими ранениями, угнетением сознания, дыхания и гемодинамики, тяжелой сочетанной травмой и т. д.
Относительно стабильные пациенты. К этой категории можно отнести случаи, клинически стабильные, но имеющие риск ухудшения состояния.
Стабильные пациенты с низкой вероятностью ухудшения состояния.
Хирургическое лечение — самый востребованный вид помощи во флагманских центрах. Фото: НИИОЗММ ДЗМ
Помимо этого, поступившие пациенты в приемном отделении распределяются по характеру заболевания (острое или хроническое), тяжести (состояние пациента легкой степени тяжести, средней или тяжелое), а также профилю заболевания.
В результате проведенной работы экспертами было выделено 14 профилей медицинской помощи, с последующим отбором наиболее массовых/значимых диагнозов, для которых были разработаны типичные сценарии оказания медицинской помощи. Подготовлены дорожные карты по профилям и отдельным нозологиям — оперограммы.
ЭКСПЕРТАМИ БЫЛО ВЫДЕЛЕНО 14 ПРОФИЛЕЙ МЕДИЦИНСКОЙ ПОМОЩИ, ДЛЯ КОТОРЫХ БЫЛИ РАЗРАБОТАНЫ ТИПИЧНЫЕ СЦЕНАРИИ ОКАЗАНИЯ МЕДИЦИНСКОЙ ПОМОЩИ
Наиболее массовые/ значимые диагнозы, явившиеся причиной обращения в медицинскую организацию, условно можно разделить по методам лечения:
рентгенэндоваскулярная диагностика и лечение,
реанимация и интенсивная терапия,
сочетание методов лечения (работа мультидисциплинарной команды).
Хирургический блок. Хирургическое лечение является наиболее часто применяемым в скоропомощных больницах и используется для оказания медицинской помощи практически по всем профилям. Как наиболее объемный, хирургический блок включает такие профили, как хирургия, травматология, нейрохирургия, сердечно-сосудистая хирургия, гинекология, урология, офтальмология, челюстно-лицевая хирургия, оториноларингология; возможно сочетание двух и более профилей.
Терапевтический блок включает в себя медицинскую помощь по профилям «неврология», «кардиология», «терапия», требующим, как правило, консервативного лечения.
Блок рентгенэндоваскулярной диагностики и лечения объединяет состояния по профилям «сердечно-сосудистая хирургия», «нейрохирургия», «кардиология» и «неврология», сопровождающиеся поражением сосудов головного мозга, сердца, аорты и других крупных сосудов и требующие применения рентген-визуализации в ходе лечения.
Блок анестезиологии и реаниматологии включает медицинскую помощь при отравлениях, острой дыхательной недостаточности, а также помощь пациентам, которым уже начато проведение сердечно-легочной реанимации в процессе транспортировки во флагманский центр.
Типовые случаи (диагнозы в соответствии с Международной классификацией болезней 10-го пересмотра) для каждого профиля выбраны исходя из частоты встречаемости среди населения, частоты обращения в службу скорой медицинской помощи, поступления в стационар пациентов с сочетанной травмой, а также массовым поступлением пострадавших в чрезвычайных ситуациях.
Логистика госпитализации
Логистические процессы, реализованные во флагманских центрах, организованы с учетом принципов медицинской сортировки и последующего движения пациента в зависимости от тяжести состояния и диагноза. Такой подход позволяет выделить основные логистические процессы, определяющие порядок, место проведения диагностических и лечебных манипуляций, материальное, техническое, информационное и медикаментозное обеспечение, а также маршрутизацию пациента от момента поступления в медицинскую организацию до момента выписки. Кроме того, при разработке логистических процессов были учтены ситуации массового поступления пострадавших или больных, имеющих признаки заболевания особо опасными инфекциями.
Сортировка пациентов происходит на въезде в отделение неотложной помощи. Фото: НИИОЗММ ДЗМ
Внутри помещений для маршрутизации потоков пациентов используется цветовая индикация, соответствующая тяжести состояния больного и очередности оказания медицинской помощи. Реализована концепция работы «врач — к пациенту», при которой диагностика проводится у постели больного, для чего предусмотрены специализированные зоны — палаты интенсивного наблюдения, смотровые.
ЧТОБЫ УПРОСТИТЬ ПРОЦЕСС МАРШРУТИЗАЦИИ, ВНУТРИ ПОМЕЩЕНИЙ ИСПОЛЬЗУЕТСЯ ЦВЕТОВАЯ ИНДИКАЦИЯ, СООТВЕТСТВУЮЩАЯ ТЯЖЕСТИ СОСТОЯНИЯ БОЛЬНОГО И ОЧЕРЕДНОСТИ ОКАЗАНИЯ МЕДИЦИНСКОЙ ПОМОЩИ
Все уникальные разработки направлены на сокращение до минимума времени от момента поступления экстренного пациента до оказания ему медицинской помощи.
Протокол оказания медицинской помощи предусматривает определенный процесс, начинающийся с сопровождения пациента в зону триажа, где проводится первичное обследование пациента для определения его категории. В зависимости от категории выбирается дальнейший алгоритм взаимодействия с пациентом, включающий осмотры специалистами, определенные инструментальные и лабораторные исследования, процедуры и манипуляции, оперативные вмешательства, назначение лекарственных препаратов и др. Все эти действия, в зависимости от категории пациента, максимально детально описаны в оперограммах, в которых также отражены все специалисты, работающие с пациентом (врачи, медицинские сестры, немедицинский персонал), и логика такого контакта.
Маршрутизация пациентов. Оперограмма
Маршрутизация пациентов осуществляется по принципу «триаж» и основывается на практичной и интуитивной системе навигации для пациента и медицинского персонала. В зависимости от установленного диагноза (в соответствии с Международной классификацией болезней 10-го пересмотра) процесс оказания помощи пациентам основан на четком следовании стандартам и типовым алгоритмам — оперограммам.
ВСЕ УНИКАЛЬНЫЕ РАЗРАБОТКИ НАПРАВЛЕНЫ НА СОКРАЩЕНИЕ ДО МИНИМУМА ВРЕМЕНИ ОТ МОМЕНТА ПОСТУПЛЕНИЯ ЭКСТРЕННОГО ПАЦИЕНТА ДО ОКАЗАНИЯ ЕМУ МЕДИЦИНСКОЙ ПОМОЩИ
Оперограмма позволяет наглядно показать движение пациента от момента его поступления в стационар до момента выписки. Кроме того, с помощью оперограммы становится возможным оценить степень загруженности всех участников лечебно-диагностического процесса, выявить текущую и потенциальную нехватку персонала, определить потребности в лекарственных препаратах, материалах и оборудовании.
В оперограммах указываются нормативные трудозатраты на каждое действие лечебно-диагностического процесса, частота и кратность последовательных шагов. Кроме того, в оперограммах отражаются все ресурсы, необходимые для реализации лечебно-диагностического процесса, в том числе медикаменты, расходные материалы, изделия медицинского назначения, оборудование, помещения с учетом требований действующей нормативно-правовой базы. В рамках работы по подготовке оперограмм участники проектной команды провели сопоставление кодов манипуляций из «Номенклатуры медицинских услуг» с кодами по реестру Московского городского фонда обязательного медицинского страхования.
Профили медицинской помощи, для которых разработаны оперограммы
Таким образом, в итоговом виде оперограмма представляет собой таблично-графическую модель комплексной медицинской услуги, полностью отвечающей требованиям нового стандарта экстренной медицинской помощи в Москве. Модель содержит наиболее важную информацию о перечнях и последовательности выполняемых действий медицинским и немедицинским персоналом, в том числе консультациях врачей-специалистов, лабораторных и инструментальных исследованиях, а также ресурсном обеспечении лечебно-диагностического процесса: медикаментах, расходных материалах, применяемом оборудовании и специализированных помещениях. Для каждого исследования, манипуляции регламентированы кратность использования и трудозатраты персонала на их выполнение.
В кабинете диагностики. Фото: НИИОЗММ ДЗМ
На основе оперограммы разрабатывается краткая технологическая карта, отражающая сводные ресурсные характеристики лечебно-диагностического процесса.
Технологическая карта комплексной медицинской услуги включает в себя дополнительно описание трудовых функций и профессиональных компетенций привлекаемых врачей и специалистов со средним медицинским образованием.
Например, технологическая карта комплексной медицинской услуги «Острый аппендицит» вкратце описывает технологию выполнения медицинской услуги следующим образом: «Пациент поступает самотеком/ по каналу скорой медицинской помощи с направительным диагнозом «острый аппендицит». Проводится триаж, размещение пациента на койке, первичный осмотр хирурга, объяснение плана дообследования и лечения, сбор информированных согласий на обследование, дообследование в объеме УЗИ, рентгена, КТ брюшной полости, ЭКГ, анализов крови, при необходимости — консультаций смежных специалистов. По результатам дообследования пациент амбулаторизируется/госпитализируется».
ДЛЯ КАЖДОГО ИССЛЕДОВАНИЯ, МАНИПУЛЯЦИИ РЕГЛАМЕНТИРОВАНЫ КРАТНОСТЬ ИСПОЛЬЗОВАНИЯ И ТРУДОЗАТРАТЫ ПЕРСОНАЛА НА ИХ ВЫПОЛНЕНИЕ
В зависимости от результатов, полученных в ходе диагностики, предусмотрено несколько вариантов дальнейшей маршрутизации пациента (госпитализация в стационарное реанимационное отделение, в профильное отделение, направление в операционную или выписка под амбулаторное наблюдение).
Все алгоритмы медицинских услуг будут интегрированы в общую информационную систему флагманских центров, что позволит вести медицинскую документацию в электронном виде и использовать возможности искусственного интеллекта для уточнения диагноза.
Медицинская сортировка
Медицинская сортировка или триаж (фр. triage, сортировка) — распределение пострадавших и больных на группы, исходя из нуждаемости в первоочередных и однородных мероприятиях (лечебных, профилактических, эвакуационных) в конкретной обстановке. Даже для двух одновременно поступивших пострадавших требуется проведение медицинской сортировки. При проведении медицинской сортировки допускается гипердиагностика. Основа сортировки: единые представления о диагностике, лечебных мероприятиях и прогнозах результатов лечения. Цель сортировки: обеспечить своевременное оказание медицинской помощи максимальному числу пострадавших в оптимальном объёме. Состояние пострадавших детей и беременных женщин без видимых повреждений всегда оценивается как тяжёлое, эвакуация и оказание помощи производится в первую очередь.
Содержание
В России
Основные Пироговские сортировочные признаки:
- опасность пострадавшего для окружающих;
- нуждаемость пострадавшего в лечебных мероприятиях;
- нуждаемость пострадавшего в эвакуации.
В зависимости от решаемых задач выделяют два вида сортировки.
- Эвакуационно-транспортная — распределение пострадавших на 3 группы:
- подлежащие дальнейшей эвакуации, при этом решаются следующие вопросы :
- куда?
- каким транспортом?
- в каком положении?
- в какую очередь?
должен быть отправлен пострадавший;
- нуждающиеся в помощи на месте;
- не нуждающиеся в дальнейших медицинских мероприятиях, то есть те, кто могут быть отпущены (отправлены).
- Внутрипунктовая — распределение пострадавших на группы для принятия решения об оказании медицинской помощи на данном этапе (при этом решаются следующие вопросы: где, в какую очередь, в каком объёме необходимо оказать помощь). Выделяют следующие основные группы пострадавших:
- нуждающиеся в оказании неотложной помощи,
- те, которым помощь может быть отсрочена.
Сложность вызывают лица, представляющие опасность для окружающих. Они могут подлежать специальной обработке (дегазации, дезактивации, демеркуризации и т. д.), санитарной обработке, нуждаться во временной изоляции. Это не исключает нуждаемость данных лиц в лечебных и эвакуационных мероприятиях.
Сортировка должна проводиться непрерывно, преемственно и конкретно. К организации и проведению медицинской сортировки должен быть привлечен наиболее подготовленный из имеющихся в данный момент медицинских специалистов.
За границей
Современная система медицинской сортировки (триаж) в большинстве западных стран основывается на разделении всех пострадавших на четыре группы, каждой из которых присвоен свой цветовой код:
| Категория | Пояснение | Действие | |
|---|---|---|---|
| I | Immediate/ Неотложная помощь |
Тяжёлые пострадавшие, которые могут умереть в течение часа. | Немедленное оказание помощи и транспортировка в больницу. |
| II | Delayed/ Срочная помощь |
Тяжёлые пострадавшие, чья жизнь пока не находится под угрозой. | Стабилизация состояния и транспортировка во вторую очередь. |
| III | Minor/ Несрочная помощь |
Пострадавшие, способные передвигаться самостоятельно. | Помощь оказывается в последнюю очередь. В больницу могут добраться самостоятельно. |
| IV | Morgue/ Морг |
Пострадавшие, у которых отсутствует дыхание и пульс, и агонизирующие. | Помощь не оказывается. |
Данная система предназначена для определения очерёдности оказания медицинской помощи и транспортировки в больницу при наличии большого количества пострадавших, но ограниченного количества медицинского персонала и средств транспортировки. Весь процесс оценки состояния одного пострадавшего занимает, как правило, менее 60 секунд. По завершению оценки, пострадавшие помечаются цветом одной из четырёх категорий сортировки, в виде специальной цветной бирки (triage tag) и цветного фонарика (в тёмное время суток), либо просто цветной ленты.
Существуют различные методы медицинской сортировки: SALT (Sort, Assess, Lifesaving Interventions, Treatment/Transport), SAVE (Secondary Assessment of Victim Endpoint), JumpSTART, Care Flight Triage, Triage Sieve, Sacco Triage Method, Pediatric Triage Tape и другие. Разные методы приспособлены для использования в различных обстоятельствах. Например, метод SAVE предназначен для вторичного триажа при землетрясениях, когда из-за разрушенной инфраструктуры немедленная госпитализация пострадавших невозможна. Метод JumpSTART используется для медицинской сортировки пострадавших детского возраста; и т.д. Большинство из методов предназначены для триажа при несчастных случаях и стихийных бедствиях. Однако существуют также методы сортировки для пострадавших в результате химического, биологического или радиационного загрязнения.
Состояние пострадавшего, после первичного триажа, может ухудшиться или улучшиться, поэтому сортировка продолжает осуществляться всё время осуществления спасательной операции и пострадавшие в любой момент могут быть переквалифицированы из одной категории в другую. Внутри одной категории предпочтение отдаётся детям и беременным женщинам.
Метод START
Один из наиболее распространённых методов первичной медицинской сортировки получил название START (Simple Triage and Rapid Treatment). Данный метод был разработан в 1983 году специалистами Пожарного департамента г. Ньюпорт-Бич в Калифорнии (Newport Beach Fire Department), совместно с врачами местной больницы Хоаг (Hoag Hospital). Он предназначался для использования пожарными и экстренными службами в случае землетрясения или других глобальных природных бедствий. Однако впоследствии он также стал стандартным методом медицинской сортировки при оказании помощи пострадавшим в результате терактов, а также крушении поездов, автобусов и других несчастных случаев с большим числом пострадавших.
Согласно методу START, спасатели, первыми прибывшими на место происшествия, сначала отделяют легкораненых от остальных пострадавших. Для этого они просят всех, кто в состоянии передвигаться самостоятельно, отойти от остальных пострадавших и собирают их в определённом месте, где их помечают зелёным цветом. Эти пострадавшие либо получили лёгкие ранения, либо вообще не получили ранений и помощь им оказывается уже после оказания помощи более тяжёлым пострадавшим.
Далее спасатели обследуют пострадавших, которые не могут передвигаться и определяют у них наличие дыхания, кровообращения и неврологических функций, на основании чего разделяют оставшихся пострадавших на три категории: нуждающиеся в неотложной помощи, в срочной помощи и мёртвые.
В первую очередь спасатели определяют, дышит ли пострадавший. Если он не дышит, они проверяют его дыхательные пути и устраняют препятствия для дыхания. Если дыхание пострадавшего после этого не восстановилось, считается, что жертва мертва и тело помечают чёрным цветом.
Если пострадавший дышит, то спасатели измеряют его частоту дыхательных движений. В случае, если она составляет более 30 в минуту, то пострадавший помечается красным цветом, требующим неотложной помощи, так как увеличение частоты дыхательных движений является одним из признаков шока.
После этого спасатели определяют у пострадавшего наличие пульса на запястье. Если пульс не прощупывается, то пострадавшего помечают красным цветом, а если пульс есть, то проводят тест капиллярных сосудов, нажимая на ноготь пальца руки, пока он не побелеет, а затем считая, за сколько секунд кровь вернётся обратно к пальцу. Если ноготь не порозовеет в течение двух секунд, то пострадавшего помечают красным цветом, а если он приобретёт нормальную окраску ранее, то приступают к последнему тесту — неврологических функций.
Спасатели просят пострадавшего выполнить какое-либо простое действие. Если он адекватно реагирует на их указания, его помечают жёлтым цветом. Если же пострадавший не реагирует на окружающих, его помечают красным цветом, так как его состояние, возможно, является опасным для жизни.
Метод START хорошо зарекомендовал себя среди спасателей благодаря простоте использования, доступной даже лицам, не имеющим профессиональной медицинской подготовки.
Профессиональные врачи, осуществляющие медицинскую сортировку, как правило, пользуются более сложными методами, которые, в частности, позволяют им помечать чёрным цветом не только уже умерших пострадавших, но и тех, чьи ранения, по их заключению, не совместимы с жизнью.
В 1995 году на основе метода START доктор Лу Ромиг (Lou Romig) из Детской больницы Флориды (Florida Children’s Hospital) в Майами разработал метод медицинской сортировки JumpSTART для педиатрических пациентов, который впоследствии стал стандартным при триаже детей в США.
Триаж
Триаж – это медицинский термин, который обозначает оценку и классификацию срочно поступивших больных по степени неотложности врачебной помощи. Сначала эта система применялась в военно-полевых условиях, где пациентов делили на три категории: умирающие, кому оказать помощь уже нельзя; те, кто может выжить только при неотложной помощи; и те, кто, скорее всего, останется в живых и без срочной помощи. И сейчас в приемных покоях больниц существует подобная система классификации пациентов.
Триаж был усвоен разработчиками ПО для систематизации дефектов во время стабилизационной фазы традиционного программного проекта. Триаж использовался для отделения ошибок, которые должны быть устранены (и очередности их устранения), от тех, что останутся и могут пойти в производство при выходе продукта. Обычно триаж ошибок проводили ведущий тестировщик и ведущий разработчик, руководители группы тестирования и разработки, а также владелец продукта.
В Канбане тоже имеет смысл проводить триаж ошибок. Однако еще полезнее применять его к элементам бэклога, ожидающим поступления в систему.
Триаж бэклога нужно проводить сравнительно нечасто. (Заметим, что в некоторых методах гибкой разработки ПО он называется «грумингом».) Разные команды предпочитают различную периодичность – ежемесячно, ежеквартально, дважды в год. При триаже бэклога обычно присутствуют те же владельцы продукта и представители бизнеса, которые ходят на собрания по пополнению очереди, а также менеджер проекта. Технических сотрудников немного – нередко они представлены одним менеджером среднего звена.
Цель триажа бэклога – проанализировать все эти элементы и решить, оставить их или удалить. При этом не назначаются никакие ранги и не расставляются приоритеты: выбор стоит единственный – оставить или удалить.
Некоторые команды смогли отказаться от триажа благодаря автоматизации и внутренним правилам. Так, команда Microsoft XIT из кейса в главе 4 ежемесячно удаляла из бэклога все элементы старше шести месяцев. Считалось, что если элемент за полгода так и не перевели во входящую очередь, то он вряд ли обладает существенной ценностью и, возможно, его вообще никогда не выберут. Но при изменении ситуации его всегда можно затребовать обратно, так что удаление из бэклога ничего не испортит.
Цель проведения триажа бэклога – сокращение его размеров. Преимущество меньшего размера бэклога – в облегчении процедуры обсуждения приоритетов. Выбирать из 200 элементов гораздо проще, чем из 2000.
Неплох также метод, при котором бэклог подвергается значительному сокращению, если работа по нему превышает три месяца пропускной способности и все элементы за это время не могут попасть в систему. У разных рынков и отраслей свои оптимальные размеры бэклога. Отраслям с высокой изменчивостью подойдет бэклог на месяц работы. Если же изменчивость низкая, то бэклог может содержать элементы даже на год вперед.
Таким образом, существует взаимосвязь между бэклогом, изменчивостью в отрасли, в условиях которой работает конкретная канбан-система, и скоростью выполнения, или пропускной способностью команды. Если команда выполняет 20 пользовательских историй в месяц, а отрасль обладает определенной, но не слишком большой изменчивостью, то предпочтителен бэклог на три месяца работы, то есть он должен содержать примерно 60 элементов.
Как ловко и оперативно обрабатывать уязвимости
Меня зовут Антон Башарин, я работаю в компании Swordfish Security и занимаюсь построением и автоматизацией процессов разработки защищенного ПО, в том числе интеграцией практик информационной безопасности в DevOps. Вместе с моей коллегой Анастасией Арсеньевой мы собрали в один материал основные проблемы, чаще всего встречающиеся при обработке уязвимостей ИБ, и постарались разобраться, как можно оптимизировать этот процесс с помощью инструмента класса ASOC. Ниже описаны решения и «показана» эффективность их применения с помощью дашбордов, которые мы разработали для модуля визуализации метрик DevSecOps в рамках развития нашего продукта AppSec.Hub, реализующего практику ASOC. Мы взяли эту платформу лишь с той целью, чтобы с практической точки зрения раскрыть спектр возможностей решения класса ASOC. Итак, поехали!
DevOps и DevSecOps
В настоящее время стандартом IT-индустрии является методология DevOps (автоматизация технологических процессов сборки, настройки и развертывания ПО). Показатели производительности DevOps, согласно парадигме DORA, – три метрики, отвечающие за скорость поставки, и одна – за качество ПО (процент изменений кода, приводящих к сбоям, должен стремиться к нулю).
Если говорить о том, что команде или всей компании необходимо соответствовать требованиям регуляторов и корпоративным политикам ИБ, то без встраивания проверок ИБ в налаженные процессы DevOps не обойтись. Таким образом, реализация DevSecOps-подхода будет влиять на метрики DevOps, о которых говорили выше. Например, скорость сканирования с помощью инструментов ИБ может уменьшать скорость поставки, а неправильно организованный процесс обработки результатов, полученных из этих же инструментов, будет ухудшать качество ПО. Далее поговорим именно про обработку результатов и о том, как можно оптимизировать этот процесс, опираясь на цифры и графики.
Узкие места в обработке результатов проверок ИБ
При попытке интеграции инструментов анализа защищенности приложений в конвейер CI/CD многие компании сталкиваются с потерями в скорости разработки на нескольких этапах обработки уязвимостей. Ниже мы опишем основные ситуации и связанные с ними сложности:
Во-первых, сканеров ИБ, позволяющих обнаружить уязвимости различного вида на разных этапах разработки, довольно много, и у каждого – свой интерфейс, особенности работы и формат вывода результатов сканирования.
Одна и та же проблема безопасности может дублироваться, будучи обнаруженной различными сканерами или при повторной проверке. К тому же некоторые инструменты и практики ИБ могут выдавать большое количество ложных срабатываний. Разбор и сопоставление всех результатов проверок ИБ (триаж) для отсева повторных и ложных срабатываний отнимают немало времени у инженеров безопасности.
Во-вторых, мало обнаружить уязвимость, нужно еще ее устранить. Однако временнЫе, человеческие и финансовые ресурсы небезграничны, все выявленные дефекты убрать невозможно, да и не нужно. Рациональным решением будет сосредоточиться на ликвидации тех проблем, которые несут в себе больше всего риска.
А это значит, что перед передачей уязвимостей команде разработки необходимо приоритизировать результаты сканирований, определив, какие из ошибок наиболее серьезны и обязательны к устранению, какие – желательны, а какие из них (вместе с рисками) компания готова принять. Частично осуществлять такое ранжирование могут инструменты ИБ. Однако классификация уязвимостей может быть разной, а это значит, что бОльшая часть работы по приоритизации опять выполняется командой инженеров ИБ вручную.
Наконец, приоритизированные уязвимости нужно передать в разработку для исправления, и не всегда это происходит в удобном для разработчика виде. Некоторые инструменты управления позволяют выгрузить результаты сканирования напрямую в дефект-трекинговую систему. Однако тогда разбор и анализ однотипных проблем становятся ответственностью команды разработки, а значит, ее специалисты тратят время на ранжирование уязвимостей вместо того, чтобы их исправлять.
ASOC как часть DevSecOps
Практика показывает, что использование инструментов класса ASOC (Application Security Orchestration and Correlation) позволяет упростить тестирование и устранение уязвимостей за счет автоматизации рабочего процесса. Решения ASOC собирают и объединяют результаты сканирования из всех используемых инструментов ИБ, сопоставляют их, отдавая приоритет критически важным уязвимостям. Пройдя через все стадии автоматической и ручной обработки, анализа, приоритизации и корреляции, уязвимости преобразуются в дефекты, экспортируемые в дефект-трекинговую систему команды разработки для исправления.
Основные стадии обработки результатов сканирования:
Применение автоматических правил обработки
Более подробно рассмотрим эти стадии и их эффективность на примере соответствующего дашборда:
Структурно дашборд делится на 3 части: центральная иллюстрирует поток обработки и корреляции в числовых и процентных показателях, верхняя панель отображает метрики производительности каждого этапа обработки, нижняя позволяет оценить эти показатели в различных разрезах.
Этапы обработки уязвимостей
На центральной части дашборда показаны этапы обработки, которые проходят результаты проверок ИБ, трансформируясь в нижней части воронки в дефекты, автоматически выгружаемые в дефект-трекинговую систему. Слева – показатели в количественном выражении (первые 5 этапов – уязвимости, шестой – дефекты), справа те же стадии – в процентах от первоначального числа результатов сканирования.
С каждым уровнем число уязвимостей уменьшается, и на финальной стадии обработки они трансформируются в дефекты, направляемые в команду разработки для устранения. Обработка производится как автоматически, так и посредством привлечения инженеров ИБ.
Переход от стадии к стадии в процентном соотношении показан на верхней панели.
Чтобы оценить вклад каждого этапа и сделать выводы о его эффективности, расскажем подробнее о процессе обработки результатов сканирования.
Дедубликация
Дедубликация – процесс автоматического анализа уязвимостей с выделением первично и повторно обнаруженных проблем.
Не каждой уязвимости, найденной при сканировании, присваивается уникальный номер –вначале система проводит анализ результатов проверки на предмет дубликатов/повторов. Если выясняется, что данные о проблеме уже есть, система обновляет существующую запись, не плодя новые сущности.
На графике воронки данный этап обозначен как число уязвимостей, оставшихся после исключения повторных срабатываний.
В панели метрик «Дубликаты, %» – отношение повторных срабатываний к общему количеству выявленных уязвимостей.
Низкий % дубликатов характерен для активно меняющегося кода (кардинально разные результаты от сканирования к сканированию). Чаще наблюдается при рефакторинге или изменении архитектуры системы.
Высокий % дубликатов говорит нам о небольшом количестве изменений в коде, его стабильности. Такая ситуация часто наблюдается в системах, которые еще эксплуатируются, но не развиваются (например, ведется разработка системы, которая должна заменить текущую).
Применение автоматических правил обработки
Применение правил обработки уязвимостей – процесс автоматического отсеивания ложных срабатываний/принятия риска в соответствии с правилами, заранее настроенными инженером ИБ.
Здесь результаты сканирования проходят через «фильтр» автоматических правил обработки. Инженер ИБ может настроить их таким образом, чтобы часто встречающиеся ложные срабатывания, которые ранее приходилось обрабатывать вручную, еще до начала триажа автоматически получали статус False Positive. Аналогично можно настроить автоматические правила принятия риска.
На графике воронки данный этап обозначен как число уязвимостей, оставшихся после применения автоматических правил и требующих ручного разбора.
В панели метрик «Применение rules, %» – отношение уязвимостей, автоматически помеченных False Positive или Accepted risk к уязвимостям (без учета дубликатов) по заранее настроенным инженером ИБ правилам.
Низкий % применения правил свидетельствует о том, что инженер редко использует функционал правил автоматической обработки и вынужден больше времени и сил тратить на ручной разбор уязвимостей.
Триаж
Триаж – ручная обработка и анализа выявленных уязвимостей, который проводит инженер безопасности.
Уязвимости, к которым не были применены автоматические правила обработки, должны быть вручную разобраны инженером ИБ. Основываясь на данном показателе, можно видеть, насколько сотрудники подразделения безопасности, ответственные за обработку результатов сканирования, справляются с объемом работы. Фактически все выявленные на предыдущих этапах и не обработанные уязвимости являются техническим долгом для инженеров ИБ.
«Триаж, %» рассчитывается как отношение рассмотренных инженером ИБ уязвимостей к количеству проблем, требующих обработки (результат после применения автоматических правил).
Данный показатель должен быть близок к 100% (особенно для уязвимостей высокой и критической серьезности). Низкий % может свидетельствовать о кадровом голоде или низком приоритете задач триажа инженеров ИБ. Если низкий % триажа сочетается с низким % применения автоматических правил, рекомендуется обратить внимание на настройку правил обработки, чтобы сэкономить время на ручном разборе, уменьшая таким образом размер технического долга.
Приоритизация
Приоритизация – процесс анализа и оценки рисков инженером ИБ при обработке уязвимостей для выбора проблем, приоритетных для исправления.
На данном этапе инженер ИБ анализирует уязвимости, чтобы определить те, которые необходимо устранить в первую очередь.
Результат этапа – уязвимости, назначенные инженером ИБ для исправления, однако до отправки в дефект-трекинговую систему команды разработки они проходят еще одну трансформацию (корреляцию и группировку уязвимостей в дефекты).
«Приоритизация, %» – отношение приоритизированных уязвимостей, обработанных инженером ИБ, которые в дальнейшем объединяются в дефекты и направляются на устранение в команду разработки, к количеству всех проблем, рассмотренных специалистом по безопасности.
По данному показателю можно судить о том, какую часть выявленных проблем безопасности инженер ИБ выделяет для исправления и передачи в разработку. Низкий % говорит о большом числе ложных срабатываний (регулируется настройками сканеров ИБ и автоматических правил обработки) или большом % принятия рисков (может сигнализировать о формальном подходе или игнорировании требований безопасности, т. е. принятии риска вместо устранения уязвимостей).
Корреляция
Корреляция – процесс создания дефекта для отправки его в дефект-трекинговую систему команды разработки на базе приоритизированных уязвимостей. Критериями группировки могут являться: тип, CWE ID, имя файла, номер строки кода в файле, статус, категория, критичность уязвимости.
Этот процесс позволяет объединять однотипные/похожие/найденные рядом в коде уязвимости в значительно меньшее число дефектов, а значит, экономить время и ресурс команды разработки на их устранение.
Корреляция, % – отношение количества дефектов к числу приоритизированных уязвимостей.
Анализ эффективности этапов
Разобрав этапы более подробно теперь можно сказать, что этот дашборда позволяет нам на одном экране увидеть поток обработки уязвимостей от результатов сканирования до передачи их в разработку в виде дефектов. Мы можем оценить эффективность процесса в целом и отдельно каждого его этапа: как применяется функционал инструмента класса ASOC по обработке уязвимостей (автоматическое исключение дубликатов, применения правил обработки, корреляция), как происходит ручная обработка сотрудниками команды ИБ (триаж, приоритизация). Это позволяет в том числе оценить технический долг по триажу (анализу) уязвимостей.
А понимая контекст, мы сможем принять решения, помогающие увеличить эффективность обработки уязвимостей командой инженеров ИБ – например, за счет уменьшения доли ручного труда инженеров ИБ по разбору и анализу через настройку автоматических правил.
Оценка процесса в разных контекстах
Нижняя часть дашборда позволяет нам оценить поток обработки уязвимостей и показатели эффективности каждого этапа в различных разрезах: в разбивке по серьезности уязвимостей, практикам и инструментам обнаружения, приложениям.
Структурно каждая вкладка состоит из двух частей: слева находится график «радар», который позволяет сравнивать между собой сущности сразу по нескольким показателям (в левой части – последовательные шаги количественной «воронки», справа на тех же уровнях – соответствующие показатели эффективности этапов). На графике «радар» хорошо видны максимальные значения, а выявить аутсайдеров по разным показателям помогут две таблицы, расположенные справа: отдельно количественные показатели, отдельно параметры эффективности прохождения этапов обработки.
Серьезность уязвимости
К примеру, мы видим, что чаще всего выявляются уязвимости низкого уровня серьезности (что вполне естественно), а автоматические правила обработки настроены в основном для проблем критической и высокой степени серьезности. % триажа тоже выше для критических уязвимостей.
Приложение
На графиках мы видим, что одно приложение (User Management System) – явный лидер по количественным показателям, однако у него сильно отстает от других показатель эффективности приоритизации: направляются в работу только 5% проанализированных уязвимостей.
Давайте попробуем понять причину этого, отфильтровав данные, оставив только приложение User Management System, и оценив поток обработки в разрезе сканеров/практик ИБ.
Практика ИБ / сканеры ИБ
Что касается показателей по практике и сканерам ИБ, есть небольшое отличие от других измерений. Поскольку система, отсеивая повторно выявленные уязвимости, не создает для каждой проблемы отдельную запись, мы можем с уверенностью говорить только об уязвимостях без учета дубликатов, обнаруженных с помощью каждой практики/сканера.
Возвращаясь к обнаруженному «бутылочному горлышку» приоритизации уязвимостей: отфильтровав данные по приложению User Management System, мы видим, что наименьший показатель эффективности приоритизации у уязвимостей, выявленных практикой SAST. Только 3% от проанализированных уязвимостей направляется в работу, что лишний раз иллюстрирует большое количество ложных срабатываний у анализаторов кода, используемых «из коробки» (без дополнительной настройки под анализируемые системы). Ещё можно обратить внимание на то, что автоматические правила обработки почти не настроены. Менее 1% из выявленных уязвимостей обрабатываются автоматически – инженер ИБ тратит много времени на ручной анализ каждого срабатывания, тем временем накапливая технический долг по разбору остальных уязвимостей.
Фильтры
Разумеется, дашборд – это интерактивный инструмент, который можно гибко настроить для получения ответов на конкретные вопросы, применив фильтры. По умолчанию отображаются данные за все время использования инструментов ИБ в процессе безопасной разработки компании, однако можно выбрать период покороче (фильтр по дате сканирования) для анализа ситуации за текущий/прошлый месяц/год и т. д. Также вполне реально отфильтровать данные по каждому приложению, практике, сканеру ИБ и серьезности.
Заключение
Мы рассмотрели один из аспектов DevSecOps – процесс обработки выявленных уязвимостей ИБ – на примере инструмента класса ASOC. Подведем итоги. Использование таких решений помогает упростить обработку результатов сканирования и увеличить скорость поставки ПО за счет автоматизации сразу нескольких важных процессов.
Во-первых, решения ASOC (в части, отвечающей за оркестрацию) позволяют подключать разные сканеры и практики ИБ и управлять запуском тестирований «из одного окна», собирая и автоматически анализируя результаты проверок: при повторном срабатывании система не будет создавать новую запись об обнаруженной уязвимости, а обновит запись найденной ранее проблемы. Настройка автоматических правил обработки позволяет значительно сократить время, которое затрачивается на ручной отсев ложных срабатываний, часто выдаваемых некоторыми сканерами ИБ. Автоматические правила можно настроить и для принятия риска.
Во-вторых, в сканерах ИБ может быть разное число степеней критичности уязвимостей, и обозначаться они могут тоже по-разному. – Инструмент класса ASOC позволяет ввести прозрачную систему классификации проблем по уровню серьезности (критический, высокий, средний, низкий). Это приводит к сокращению времени на анализ и приоритизацию уязвимостей для передачи наиболее важных на исправление в разработку.
И в-третьих, такие решения реализуют корреляцию. Приоритизированные уязвимости передаются для исправления в команду разработки не списком в виде отчета, а автоматически экспортируются в дефект-трекинговую систему в качестве сформированных дефектов. При этом инженер ИБ может объединить однотипные/похожие/найденные рядом в коде уязвимости в значительно меньшее число дефектов, добавив комментарии и рекомендации. Это улучшает взаимодействие команд безопасности и разработки и сокращает время на исправление проблем ИБ.
В целом внедрение практик ИБ в DevOps и реализация DevSecOps – задача с большой звездочкой. Единого подхода к ее решению пока нет, поэтому компании по-разному строят процесс безопасной разработки и зачастую сталкиваются с серьезными проблемами в части реализации и управления DevSecOps. В ответ на этот вызов продукты класса ASOC предоставляют универсальные возможности, позволяющие построить процесс безопасной разработки, применяя комплексный и централизованный подход.