Метрики из 800-55

Для того чтобы «закрутить» процесс, то есть направить процесс на постоянное повышение его эффективности в соответствии с циклом Деминга, для стадии «Check» можно использовать ключевые показатели эффективности процесса (KPI, они же метрики).

Я решил перевести фрагмент NIST 800-55 Revision1 о пользе использования метрик ИБ и собственно сами метрики ИБ.

Польза от использования метрик

Программа измерения показателей ИБ предоставляет ряд организационных и финансовых преимуществ. Главные преимущества заключаются в следующем: усилении подотчетности для повышения производительности процессов ИБ; увеличении эффективности процессов ИБ; демонстрации соответствия требованиям законодательства, правилам и нормативным документам; предоставлении количественных входных данных для принятия решений.

Усиление подотчетности. Измерение показателей ИБ может усилить подотчетность процессов ИБ, путем нахождения того, что внедрено некорректно, не внедрено или работает неэффективно. Сбор данных или анализ процессов может способствовать выявлению персонала, ответственного за внедрение контролей ИБ в специфические компоненты или в специфические информационные системы организации.

Увеличение эффективности ИБ. Программа измерения показателей ИБ позволит организации количественно улучшить показатели ИБ и продемонстрировать количественную динамику приближения к стратегическим целям. Это также позволяет определять эффективность  внедренных ИБ процессов и процедур, основываясь на результатах действий и событий ИБ (данных об инцидентах, потерянном доходе от кибер-атак и т.д.) до контролирования ИБ, и определять необходимые инвестиции в ИБ.

Демонстрация соответствия. Путем внедрения и поддержания программы измерения показателей ИБ, организация может демонстрировать соответствие требованиям законодательства, правилам и нормативным документам. Измерение показателей ИБ помогает ежегодно подтверждать соответствие требованиям FISMA (Federal Information Security Management Act of 2002 - Закон США), путем измерения метрик производительности для прошлого и текущего финансового года. Дополнительно эта информация может использоваться в качестве входных данных для GAO (Government Accountability Office – агентство в Конгрессе США) и IG (Inspector General – офис расследований в США). Это помогает демонстрировать проверяющим компаниям проактивный подход к ИБ и уменьшает время, затрачиваемое на сбор данных, необходимых для направления в GAO и IG, как во время проведения аудита, так и во время подтверждения статуса.

Предоставление количественных данных для принятия решений. Финансовые ограничения и рыночные условия вынуждают правительство и отрасль обходиться уменьшенными бюджетами. В таком положении трудно оправдать большие инвестиции в ИБ-инфраструктуру. Инвестиции в ИБ должны выделяться по результатам всесторонней программы оценки рисков. Использование мер ИБ поддерживает основанные на рисках решения и способствует сбору количественной информации для процесса управления рисками. Это позволяет организациям измерять успехи и неудачи в зависимости от прошлых и настоящих инвестиций в ИБ и предоставляет количественные данные для принятия решений по будущим инвестициям. Используя результаты анализа измерений, менеджеры и владельцы систем могут локализовать проблемы, использовать собранные данные для обоснования требуемых инвестиций и затем целенаправленно направлять инвестиции в нуждающиеся области. Такие целевые инвестиции помогают организациям получить большую отдачу от своих доступных ресурсов.   

Предлагаемые метрики

1. Процент бюджета на ИБ от общего бюджета ИТ;
2. Процент уменьшенных до приемлемого уровня уязвимостей высокого уровня критичности от общего числа уязвимостей за определенное время;
3. Процент удаленных точек доступа, используемых для неавторизованного доступа от их общего числа;
4. Процент сотрудников ИБ, которые прошли обучение по ИБ от их общего числа;
5. Средняя частота неразрешенных действий, обнаруженных в результате анализа логов;
6. Процент новых систем, которые прошли сертификацию в центрах аккредитации до начала их эксплуатации по отношению к общему количеству.
7. Процент одобренных и примененных изменений по отношению к их количеству до того как оно (железо, софт, документация) стало считаться базовой конфигурацией (версией).
8. Процент информационных систем, которые были протестированы в соответствии с ежегодным планом непрерывности бизнеса от их общего количества.
9. Процент пользователей, имеющих общие учетные записи от их общего количества.
10. Процент зарегистрированных инцидентов по категориям за определенный промежуток времени от их общего количества.
11. Процент компонентов системы, которые проходили обслуживание в соответствии с графиком от их общего количества.
12. Процент носителей информации, которые были очищены гарантированным способом от их общего количества.
13. Процент инцидентов с использованием неразрешенного физического доступа в помещения, где расположены информационные системы, от общего числа инцидентов физического типа.
14. Процент сотрудников, вначале подписавших правила ИБ и только потом получивших доступ к информационной системе, по отношению к общему числу сотрудников, получивших доступ.
15. Процент проверенных лиц до предоставления им прав доступа к информации организации к общему числу лиц.
16. Процент устраненных уязвимостей за определенный интервал времени по отношению к выявленному в результате сканирования общему количеству уязвимостей.
17. Процент систем или сервисов, контракты на покупку которых, содержат требования ИБ, по отношению к общему количеству таковых.
18. Процент мобильных компьютеров и устройств, на которых проводятся криптографические операции с использованием модулей шифрования, соответствующие требованиям стандарта FIPS 140-2, от их общего числа.
19. Процент уязвимостей ОС, на которых сканеры безопасности продолжали сообщать о наличии уязвимостей после применения патчей или же после уменьшения уровня риска иным путем до приемлемого уровня, по отношению к общему количеству уязвимостей, выявленных сканером безопасности.

Озон и персональные данные

GLОчень был удивлен увидев на сайте Интернет-магазина «Озон» что-то относящееся к теме персональных данных.

Так вот, не поставив нижнюю галочку, не удастся зарегистрироваться и соответственно оформить заказ. Тыкаем на ссылку «Подробнее…» и читаем: 

«При регистрации на Сайте Клиент предоставляет следующую информацию: Фамилия, Имя, адрес электронной почты, пароль для доступа к Сайту.»

Пока нормально, читаем дальше:

«Продавец использует информацию:

для регистрации Клиента на Сайте;

для выполнения своих обязательств перед Клиентом;

для оценки и анализа работы Сайта;

для определения победителя в акциях, проводимых Продавцом.

Продавец вправе направлять Клиенту сообщения рекламно-информационного характера. Если Клиент не желает получать рассылки от Продавца, он должен изменить соответствующие настройки подписки в разделе "Мой OZON" - "Рассылки и Оповещения". Для входа необходимо ввести логин и пароль.

Автоматически соглашаемся на спам и читаем дальше шикарную фразу (я даже выделил ее жирным):

Продавец обязуется не разглашать полученную от Клиента информацию. Не считается нарушением предоставление Продавцом информации агентам и третьим лицам, действующим на основании договора с Продавцом, для исполнения обязательств перед Клиентом.»

Я бы сделал следующий вывод. В интернет-магазинах безопаснее всего регистрироваться на имя Васи Пупкина с адресом vpupkin@домен.ru

Непрерывность с примером

Мало кто из ИТ-сотрудников компаний знают, что такое непрерывность бизнеса, и тем более занимаются конкретными процессами восстановления отдельных сервисов. Для того чтобы понять с какой стороны подойти к внедрению этих процессов, я всегда руководствовался следующими простыми правилами – нужно ответить на следующие вопросы:

·         что случится, если ПК сотрудника отдела «X» выйдет из строя и сколько времени допустимо на восстановление его работоспособности? (и так по всем сотрудникам);

·         что случится, если сервер «X» выйдет из строя и сколько времени допустимо на восстановление его работоспособности? (по всем серверам);

·         что случится, если сетевое оборудование «X» выйдет из строя и сколько времени допустимо на восстановление его работоспособности? (по всему оборудованию).

Конечно, нужно рассматривать только критичные ПК, например те, на которых работают сотрудники бизнес подразделений, с которых ведутся платежи и др. в зависимости от направления компании. Точно такой же подход должен быть с серверами – важными могут быть серверы электронной почты, серверы с данными клиентов, серверы бизнес-приложений. Из сетевого оборудования важными всегда являются  маршрутизаторы и коммутаторы уровня ядра, а также оборудование, через которое происходят подключения с сетями клиентов.

Для этого нужно разработать план восстановления (оборудования, ПО, системы и т.д.) в зависимости от типа неработоспособности, внедрить в организации этот процесс и, что самое важное, регулярно проводить тестирование данного плана, по результатам которого вносить в него корректировки.

Само собой, что процессы резервного копирования на уровне данных и восстановление данных из резервных копий никто не отменял. Более того из этого следует, что в компаниях должен быть резерв типовых компонентов на случай выхода из строя существующего оборудования. Имеет смысл в резерве держать только то, без чего нельзя обойтись: процессоры, память, диски. Все остальное должно быть доступно для оперативной покупки в случае возникновения нештатной ситуации.

Если же компания имеет территориально распределенную структуру, нужно мыслить более масштабно. В этом случае помимо вышеуказанных категорий добавляются следующие:

·         что случится, если не работает отдел «X» и сколько времени допустимо на восстановление работоспособности (и так по всем  отделам);

·         что случится, если не работает филиал «X» и сколько времени допустимо на восстановление работоспособности (и так по всем  филиалам);

·         что случится, если не работает технологический или бизнес процесс «X» и сколько времени допустимо на восстановление работоспособности (и так по всем  процессам).

Тут важно понимать, что эффективнее делать в подобных ситуациях: восстанавливать работоспособность в текущем месте, в другом месте, на существующих или на других ресурсах. В каких-то случаях можно заключить договор о взаимопомощи с дружественной организацией. Такая организация должна

В моей практике было несколько примеров восстановления функционирования критичных сервисов, об одном из которых я хочу рассказать.

Случай произошел, когда я работал системным администратором в средней по размерам консалтинговой компании. Стояла задача миграции инфраструктурных решений на базе Microsoft Active Directory (AD) и Lotus Notes/Domino (Lotus)со старых версий на новые. Руководством было принято решение, что миграцией AD будем заниматься мы сами, а миграцией Lotus Notes займется ИТ-интегратор, у которого есть опыт подобной работы. Риски второй задаче заключались в том, что Lotus использовался в качестве корпоративной информационной системы и в нем присутствует важная информация.

По поводу первой задачи ИТ отдел подготовился следующим образом:

·         купили специальную литературу;

·         меня отправили на курсы Microsoft;

·         создали тестовую среду, повторяющую существующую;

·         сделали необходимые резервные копии;

·         провели пробную миграцию в тестовой среде;

·         провели миграцию в продуктивной среде.

Сама миграция происходила с выходные дни. За исключением каких-то мелочей все прошло гладко. Все пришедшие в понедельник на работу сотрудники также как обычно вошли в сеть и продолжили работу.

По поводу второй задачи руководством ИТ было выбрана следующая тактика:

·         поставили задачу интегратору;

·         интегратор провел мини обследование;

·         интегратор составил мини-план миграции;

·         интегратор провел неудачную миграцию.

Стоит рассказать, что же произошло, и как мы выбирались из этой ситуации. Lotus состоял из сервера приложений и сервера баз данных. С целью минимизации затрат было решено не трогать базу данных, а ограничиться только заменой сервера приложений. Интегратором был установлен и настроен новый сервер приложений, однако когда пришло время подключаться к серверу баз данных, выяснилось, что он функционирует как-то не правильно. При ближайшем рассмотрении выяснилось, что его массив вышел из строя, и с ним нужно было что-то делать. Интегратор заверил нас, что это частое явление, и они это сейчас исправят. После того как они поменяли диски местами, установили новый диск и запустили восстановление массива - все поняли, что данные уже не вернуть. Хорошо, что мы сделали на всякий случай резервную копию данных, но, к сожалению, не по фактическому завершению всеми сотрудниками работы, а в 19:00. Далее сотрудники интегратора заявили, что, во-первых, восстановление сервера в их функции не входит, а во-вторых, работа во внеурочное время им не будет оплачена и удалились.

Нам пришлось с нуля восстанавливать сервер баз данных, устанавливать на него все необходимые приложения и восстанавливать данные из резервной копии. Это все было проделано в субботу.  Замечу, что сотрудники интегратора успешно отдыхали все выходные дни.  Полностью работы были доделаны лишь к концу понедельника. Таким образом, частичный простой для компании или, как еще можно выразиться, ее неэффективная работа, продолжалась в целом 1 рабочий день. Также мы потеряли небольшую часть данных, которые восстанавливались до конца понедельника.

Какие ошибки были допущены, и как их можно было избежать?

·         не сохранились данные за последний час работы пятницы – нужно было сделать резервную копию после окончания работы всех сотрудников;

·         вышел из строя массив сервера базы данных – нужно было проверить и подготовить сервер к работам заранее, возможно следовало бы купить новый сервер.

·         часть дня понедельника было потрачено на завершение работ – нужно было предусмотреть в договоре работу интегратора во внеурочное время.

Моя борьба с акадо

Уже несколько лет я воюю с практически неизвестным Интернет-провайдером "акадо". Моя борьба с ними началась через несколько месяцев после подключения. Единственное замечание на них это методичные звонки с навязчивым предложением подключить ту или иную "выгодную" услугу. Все годы я регулярно точно и в срок вношу свои деньги на счет и пользуюсь услугой.      

Анализ сети Интернет показал, что это хамское их поведение абсолютно нормально. Они недавно обзавелись Call-центром в Туле, собственно оттуда и производят их менеджеры методичные звонки. Весь Интернет пестрит советами, как избавиться от столь ненавязчивого сервиса.

Пассивная стадия. Для начала я купил себе АОН, чтобы понять, кто мне ежемесячно звонит. Вот их номер телефона: 657-85-50. Далее мне пришлось сменить номер мобильного телефона, чтобы уменьшить их зону влияния. Этим летом я начал вести журнал входящих звонков с данного номера.

Активная стадия. Я подготовил и уже отправил несколько заявлений в ряд государственных органов с просьбой разобраться с данной компанией. Список инстанций пока следующий: Антимонопольная служба, Роскомнадзор, Прокуратура. То есть работу их юристам я гарантированно обеспечу.

Привожу текст письма и их первую реакцию на него. Вот текст письма:

Акадо (шаблон)

Удивительно, но очень быстро пришел от них ответ:

Вывод: всем абонентам данного оператора, желающим пользоваться сервисом, а не подходить бесконечно к телефону, я рекомендую последовать моему примеру и сделать рассылку во все инстанции по списку.