Журнал "Information Security/ Информационная безопасность" #3, 2018

Для того чтобы уровень зрелости процесса вырос, необходимо: l cоздать документацию с четким описанием самого процесса; l cформировать техниче- ские требования для систем, которые необходимы для реализации процесса; l сформировать команду участников процесса и опи- сать их зоны ответственно- сти (идеальным инструмен- том тут является RACI- матрица); l запустить процесс соглас- но описанию и всем требо- ваниям к ресурсам. Как известно, обес- печение информацион- ной безопасности, а в частности управление информационной без- опасностью, – это мак- ропроцесс (процесс обеспече- ния конфиденциальности, целостности и доступности информации), который, в свою очередь, состоит из множества отдельных процессов. Уровень зрелости процессов уже есть величина измеримая. Как пра- вило, такой измеритель при- меняется в аудиторской прак- тике, например на соответ- ствие стандарту ISO 27001. Помимо описания и оценки зрелости самих процессов хорошими критериями для оценки уровня защищенности является оценка соответствия требованиям в более глобаль- ном смысле. Каким требованиям – вопрос сугубо специфичный для кон- кретной организации. В част- ности, у нас имеется законода- тельство, которое необходимо выполнять, имеется множество рекомендаций как от техниче- ских вендоров, так и от регули- рующих организаций. На базе всего этого можно разработать отдельные списки требований и в целом получить комплексную оценку уровня зрелости составных процессов ИБ и оценку соответствия тре- бованиям. Такая оценка позво- лит нам контролировать теку- щий уровень зрелости функции ИБ и на базе этого планировать дальнейшее ее развитие. Про- блема в том, что такой подход не позволит нам видеть теку- щую динамическую картину угроз. Для ее формирования необходим другой подход. Начнем с процессов Широко используемой мето- дологией оценки зрелости про- цесса является методология, базирующаяся на модели Capa- bility Maturity Model Integration (CMMI). Для наглядности сведем значение, уровни и описание в таблицу. Рассмотрим простой пример на базе процесса управления инцидентами ИБ. Допустим, в инфраструктуре "упал" сервер базы данных (БД), в течение суток его восстановили и рабо- тающие на нем системы про- должили функционирование, руководству доложили: "Да, был сбой, но мы все починили". Кого-то после этого накажут. А сама БД, возможно, потом "всплывет" где-то в теневом Интернете. Это неконтролируе- мый процесс управления инци- дентами, он же начальный (1). Для того чтобы уровень зре- лости процесса вырос, необхо- димо: l cоздать документацию с чет- ким описанием самого про- цесса; l cформировать технические требования для систем, которые необходимы для реализации процесса; l сформировать команду участ- ников процесса и описать их зоны ответственности (идеаль- ным инструментом тут является RACI-матрица); l запустить процесс согласно описанию и всем требованиям к ресурсам. Допустим, у нас имеется опи- сание процесса, его постоянное выполнение и все необходимые для него средства и ресурсы. Тот же самый инцидент с "падением" сервера базы дан- ных, но в тот самый момент, когда в БД произошел сбой: сотрудник ИБ моментально получил сообщение от системы, уведомил всех участников про- цесса, получил всю цепочку событий, предшествующих инциденту, а по результатам был написан подробный отчет. Базу данных при этом удалось восстановить за пять минут, благодаря полученной цепочке событий. Все угрозы утечки БД удалось заранее заблокировать. А менеджмент получил полное понимание причинно-следствен- ной связи. Такой процесс можно назвать управляемым (4) или даже оптимизируемым (5). Итак, что мы имеем. Если взять стандарт по ИБ (готовый, или разработанный внутри ком- пании), расписать все процессы по нему и понять, на каком же уровне зрелости они находятся, мы можем получить некую оцен- ку каждого процесса от 1 до 5, что позволит нам получить еди- норазовый срез уровня защи- щенности. Надеюсь, с процес- сами все более-менее понятно. А что же с "требованиями"? Для начала надо определить- ся, какие требования нам необходимо обязательно выпол- нять, в первую очередь это относится к законодательству и сфере деятельности компа- нии. Например, вы медицинское учреждение, наверное, тут будет особо важным соблюде- ние ФЗ-152 о персональных данных. Вы работаете с пла- тежными картами? Будьте добры соответствовать PCI DSS. Во вторую очередь, нужно определиться, каким сторонним стандартам мы хотим соответ- ствовать (например, в перспек- 38 • УПРАВЛЕНИЕ Формирование показателей уровня защищенности, методы и практики ля того чтобы контролировать ту или иную деятельность в нашей жизни, необходимо измерять ее эффективность. А для измерения эффективности и контроля необходимо сформиро- вать показатели (метрики).Таким образом, для контроля информационной безопасности необходимо сформировать показатели уровня защищенности. Но что же такое уровень защищенности и что может являться его показателем? Д Андрей Пряников, заместитель директора по безопасности по защите информации, ООО ТД “УНКОМТЕХ”