Leta IT выпустила рекомендации по реагированию на инциденты ИБ. Точнее Leta IT - один из авторов документа "Инциденты информационной безопасности. Рекомендации по реагированию"; среди других заявлены СоДИТ, АРСИБ и Group-IB. Как написано в преамбуле "Данный документ представляет собой перечень практических рекомендаций по реагированию на возникшие инциденты, выработанных на семинаре, организованном Союзом ИТ-директоров России, Комитетом по безопасности предпринимательской деятельности ТПП РФ, Межрегиональной общественной организацией «Ассоциация защиты информации» (МОО «АЗИ»), Межрегиональной общественной организации «Ассоциация руководителей служб информационной безопасности» (АРСИБ), компанией LETA и Group-IB при содействии Школы ИТ-менеджмента АНХ при Правительстве РФ". Вообще я не сторонник писать ТАКИЕ документы по результатам семинаров, ну да ладно. Важен сам факт появления таких рекомендаций. Если не считать моего выложенного в Интернет курса по управлению инцидентами ИБ, то больше ничего на русском языке в этой области у нас и не было. Разумеется было немало статей; особенно в последнее время. Но вот систематизированного материала маловато. Так что данный материал Leta IT и Group IB можно только приветствовать.
Leta IT призывала комментировать свои публикации, чтобы они стали лучше. Не упущу и сейчас такой возможности ;-) Начну с того, что название документа не полностью соответствует его содержанию. Оно сосредоточено на инцидентах с ДБО, т.е. у документа узкая направленность на банки (это стоило бы отметить на титульной странице). Во-вторых, в документе, называемом "рекомендации", воды многовато - к самим рекомендациям пришли только на 9-й (из 20-ти страниц). Чуть меньше половины брошюрки - общие слова о важности и нужности. А вот определения инцидента ИБ так и не дано. Учитывая, что в авторах значатся СоДИТ и АРСИБ, а у безопасников и ИТшников немного разные толкования термина "инцидент", можно было бы и определиться с терминологической основой.
Полностью упущен момент о том, КТО должен реагировать на инциденты, КАК выстраивать службу реагирования и т.д. Возможно это была и не задача данного материала, но тогда стоило четко это зафиксировать и назвать документ более адекватно. Кстати, отсутствие ответа на поставленные вопросы заставило авторов включить 6-й пункт в алгоритм действия при наступлении инцидента. Только вот создавать группу реагирования надо ДО начала инцидента, а не как не в момент его развития в организации. Будут упущены драгоценные минуты, если не часы. Также как и гендиректора (п.4) беспокоить по каждому инциденту не надо и заваливать его служебными записками тоже. А для этого между 1-м и 2-м пунктами плана должен был быть как минимум еще один - классификация и приоритезация инцидента (ведь действия по реагированию очень сильно зависят от этого).
Вообще каждый из 13-ти пунктов плана требует детального рассмотрения. Ведь если специалист службы ИБ никогда не ставил перед собой задачи системного подхода к управлению инцидентами и он вдруг начнет следовать представленным рекомендациям, то вопросов возникнет еще больше. Как снять энергозависимую информацию с работающей системы? Как (а еще важнее где) собрать информацию об инциденте? Как снять образ с сетевого оборудования? Как опечатать iPad или BlackBerry? Как снять образ с виртуальной машины? Как оформить протоколом все операции с носителями? Как снять копию с сетевого оборудования или мобильного телефона? И таких вопросов по каждому пункту много.
Поэтому я бы рассматривал этот документ не как рекомендации, а как вводный материал к набору документов, описывающих все 14 шагов плана реагирования (я сюда добавил нулевой этап - создание группы реагирования). Тогда будет не только лишний повод для PR своих организаций, но и реальная польза для специалистов по безопасности. Причем опасаться, что после детальных рекомендаций никто не будет обращаться к специализированным компаниям (например, к Group IB) не стоит - будут. Хотя бы для того, чтобы снизить собственные издержки и доверить такой важный процесс квалифицированным специалистам.
Leta IT призывала комментировать свои публикации, чтобы они стали лучше. Не упущу и сейчас такой возможности ;-) Начну с того, что название документа не полностью соответствует его содержанию. Оно сосредоточено на инцидентах с ДБО, т.е. у документа узкая направленность на банки (это стоило бы отметить на титульной странице). Во-вторых, в документе, называемом "рекомендации", воды многовато - к самим рекомендациям пришли только на 9-й (из 20-ти страниц). Чуть меньше половины брошюрки - общие слова о важности и нужности. А вот определения инцидента ИБ так и не дано. Учитывая, что в авторах значатся СоДИТ и АРСИБ, а у безопасников и ИТшников немного разные толкования термина "инцидент", можно было бы и определиться с терминологической основой.
Полностью упущен момент о том, КТО должен реагировать на инциденты, КАК выстраивать службу реагирования и т.д. Возможно это была и не задача данного материала, но тогда стоило четко это зафиксировать и назвать документ более адекватно. Кстати, отсутствие ответа на поставленные вопросы заставило авторов включить 6-й пункт в алгоритм действия при наступлении инцидента. Только вот создавать группу реагирования надо ДО начала инцидента, а не как не в момент его развития в организации. Будут упущены драгоценные минуты, если не часы. Также как и гендиректора (п.4) беспокоить по каждому инциденту не надо и заваливать его служебными записками тоже. А для этого между 1-м и 2-м пунктами плана должен был быть как минимум еще один - классификация и приоритезация инцидента (ведь действия по реагированию очень сильно зависят от этого).
Вообще каждый из 13-ти пунктов плана требует детального рассмотрения. Ведь если специалист службы ИБ никогда не ставил перед собой задачи системного подхода к управлению инцидентами и он вдруг начнет следовать представленным рекомендациям, то вопросов возникнет еще больше. Как снять энергозависимую информацию с работающей системы? Как (а еще важнее где) собрать информацию об инциденте? Как снять образ с сетевого оборудования? Как опечатать iPad или BlackBerry? Как снять образ с виртуальной машины? Как оформить протоколом все операции с носителями? Как снять копию с сетевого оборудования или мобильного телефона? И таких вопросов по каждому пункту много.
Поэтому я бы рассматривал этот документ не как рекомендации, а как вводный материал к набору документов, описывающих все 14 шагов плана реагирования (я сюда добавил нулевой этап - создание группы реагирования). Тогда будет не только лишний повод для PR своих организаций, но и реальная польза для специалистов по безопасности. Причем опасаться, что после детальных рекомендаций никто не будет обращаться к специализированным компаниям (например, к Group IB) не стоит - будут. Хотя бы для того, чтобы снизить собственные издержки и доверить такой важный процесс квалифицированным специалистам.
3 коммент.:
документ ни о чем... по сути - 1-2 страницы... рекламный проспект больше напоминает
Учитывая, что в группу входят представители различных подразделений, которые, как правило, не сильно желают заниматься "факультативами", группу имеет смысл собирать после первичного анализа инцидента (а то мож у пользователя КАПС нажат и пароль не принимается, вот он и паникует). Хотя сформировать группу нужно заранее, это да...
Уведомление руководства может потребоваться, если требуется согласование каких-то действий (зависит от порядков в организации и степени самостоятельности должностных лиц).
А вот что непонятно - вообще можно ли как-то трогать задействованные в инциденте СВТ? Вроде же собранные самостоятельно доказательства не могут использоваться в суде. То есть, более логичный порядок - "зафиксировать" больного и ждать правоохранителей.
Об этом речь - много "если"
Отправить комментарий