Практика ИБ \ Бюджет ИБ и Эффект Якоря

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

Именно по этой причине, для получения нужного бюджета и экономии нервов, в первоначальном проекте бюджета имеет смысл предусмотреть дополнительные статьи расходов, от которых можно отказаться, пессимистично учитывать темпы роста цен, курс доллара и т.п., чтобы итоговый бюджет оказался на 30% - 100% выше оптимального (в зависимости от количества этапов согласования и "экономичности" согласующих).

Уверен, что большинство это и так прекрасно знает! Но все ли знают, почему это так? ;-)

Практика ИБ \ CERT - Руководство по обработке инцидентов, связанных с утечкой внутренней информации

Переведен еще один документ CERT Societe Generale - Руководство по обработке инцидентов, связанных с утечкой внутренней информации. Авторы документа - Cédric Pernet и David Bizeul. В документе приведены рекомендации по выявлению фактов утечек информации, проведению расследования, а также по действиям, которые нужно предпринять для минимизации воздействия произошедшей утечки информации на компанию.

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

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

Далее приведены краткие инструкции для каждого из этапов.

Практика ИБ \ CERT - Руководство по обработке инцидентов, связанных с заражением вредоносной программой Windows-компьютера

Перевел еще один документ CERT Societe Generale - Руководство по обработке инцидентов, связанных с заражением вредоносной программой Windows-компьютера. Автор документа - Cédric Pernet. В документе кратко приведены основные моменты, которыми следует руководствоваться при поиске и удалении вредоносных программ на компьютерах с операционной системой MS Windows.

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

• Подготовка: обеспечение готовности к обработке инцидента
• Обнаружение вредоносного ПО: выявление инцидента
• Локализация и снижение воздействия: минимизация воздействия инцидента
• Исправление: очистка компьютера от вредоносной программы
• Восстановление: восстановление нормального состояния
• Заключительный этап: составление отчета и совершенствование процесса

Далее приведены краткие инструкции для каждого из этапов.

Практика ИБ \ CERT - Руководство по обработке инцидентов, связанных с DDoS-атаками

Перевел еще один весьма полезный и актуальный документ - Руководство по обработке инцидентов, связанных с DDoS-атаками. Автор документа Vincent Ferran-Lacome (CERT Societe Generale). В документе кратко приведены основные моменты, которые нужно учесть при обеспечении защиты от DDoS-атак, а также при реагировании на соответствующие инциденты.

В документе определены 6 этапов обработки инцидентов, связанных с DDoS-атаками:

• Подготовка: обеспечение готовности к обработке инцидента
• Идентификация: выявление инцидента
• Локализация и снижение воздействия: минимизация воздействия инцидента
• Исправление: возобновление работы
• Восстановление: восстановление нормального состояния
• Заключительный этап: анализ и совершенствование процесса

Далее приведены краткие инструкции для каждого из этапов.

Практика ИБ \ SANS - Топ 20 наиболее критичных защитных мер и средств

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

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

Практика ИБ \ Пишите документы по безопасности, которые люди смогут читать!

Недавно увидел очень интересную презентацию Брэда Бимиса (Brad Bemis) "Пишите политики безопасности, которые люди смогут читать!". Брэд в одной презентации объединил лучшие рекомендации, которые позволят сделать нормативные документы по информационной безопасности гораздо более эффективными. Я решил не просто перевести презентацию, а сделать из нее небольшую статью.

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

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

Практика ИБ \ Классификация данных и выбор стратегии защиты их доступности

Перевел еще один полезный документ. Это руководство компании BakBone по оценке требований бизнеса и классификации данных для организации их защиты (в документе рассматриваются вопросы обеспечения доступности).

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

Переводы \ Руководство с Марса, Специалисты по ИБ - с Венеры

В последнем номере журнала (IN)SECURE понравилась статья Брайана Хонана (Brian Honan) о взаимодействии специалистов по информационной безопасности с руководством и бизнес-подразделениями компании. Поскольку проблема не теряет своей актуальности, решил перевести статью на русский.

Практика ИБ \ Скрытые затраты на проекты по информационной безопасности

Еще одна полезная заметка из блога Lenny Zeltser'а. 

Все мы периодически реализуем различные проекты в области информационной безопасности, планируем бюджеты, защищаем их перед руководством... Но даже в случае утверждения бюджета в достаточном объеме не редко возникают ситуации, когда денег все равно на что-то не хватает, когда неожиданно возникает необходимость в существенных дополнительных трудозатратах, которые изначально не планировались и на которые нет ресурсов. Иногда это приводит к невозможности завершения проекта или к сдвигу сроков его реализации. Почему так происходит? Дело в том, что часто при планировании проекта учитываются только явные денежные и трудовые затраты, а неявные, косвенные затраты, либо вообще не учитываются, либо недооцениваются. К тому же люди склонны выдавать желаемое за действительное и обманывать себя при оценке рисков проекта, считая, что проект непременно пройдет гладко. К сожалению, большинство проектов сталкивается с теми или иными проблемами, а неявные затраты порой существенно превышают явные.

Правильно оценить объем финансовых и трудовых затрат проекта поможет методика определения Совокупной стоимости владения (TCO - Total Cost of Ownership). К тому же эта методика поможет сделать правильный выбор решения или поставщика, учитывая при этом не только единовременные затраты, но и затраты на последующее содержание и управление купленным продуктом или сервисом.

Практика ИБ \ Процедуры анализа журналов регистрации событий в соответствии с PCI DSS. Часть 3

Продолжение Руководства по организации процедур анализа журналов регистрации событий в соответствии с требованиями PCI DSS. (Первые две части - здесь и здесь). Третья часть посвящена доказательствам выполнения процедур анализа журналов регистрации событий.

Во третьей части рассмотрены следующие вопросы:

• Подтверждение проведения анализа журналов регистрации событий
• Доказательство журналирования событий
• Доказательство выполнения анализа журналов регистрации событий
• Доказательство выполнения обработки необычных событий
• Журнал регистрации расследованных необычных событий
• Рекомендуемый формат журнала регистрации расследованных необычных событий
• Пакет доказательств соответствия требованиям PCI DSS
• Отчеты для руководства
• Периодические оперативные задачи
• Ежедневные задачи
• Еженедельные задачи
• Ежемесячные задачи
• Ежеквартальные задачи
• Ежегодные задачи

Практика ИБ \ Процедуры анализа журналов регистрации событий в соответствии с PCI DSS. Часть 2

Продолжение Руководства по организации процедур анализа журналов регистрации событий в соответствии с требованиями PCI DSS. (Первая часть - здесь). Вторая часть посвящена собственно процедурам анализа журналов регистрации событий и расследования необычных событий.

Во второй части рассмотрены следующие вопросы:

• Политика ведения журналов регистрации событий
• Рабочий процесс анализа журналов регистрации событий
• Процедура анализа журналов регистрации событий
• Подготовка к анализу журналов регистрации событий
• Выделение типов событий из журналов регистрации событий
• Создание первоначального профиля «нормальной» деятельности с использованием автоматизированных средств
• Создание первоначального профиля «нормальной» деятельности вручную
• Руководство по выявлению «заведомо плохих событий»
• Ежедневный анализ журналов регистрации событий
• Частота периодического анализа журналов регистрации событий
• Процедура анализа журналов регистрации событий
• Процедура расследования и анализа необычных событий
• Первичное расследование
• Внешние источники информации для расследования
• Эскалация расследования и проведение совместного анализа

Практика ИБ \ Процедуры анализа журналов регистрации событий в соответствии с PCI DSS. Часть 1

Антон Чувакин опубликовал в своем блоге практическое Руководство по организации процедур анализа журналов регистрации событий в соответствии с требованиями PCI DSS. Руководство достаточно универсально и может использоваться в качестве основы при организации анализа событий в рамках любых других требований, в том числе СТО БР ИББС-1.0, РС БР ИББС-2.3, ISO 27002, CobiT, либо просто в рамках реализации программы обеспечения безопасности компании без каких-либо внешних требований.

При переводе руководство было мной немного актуализировано и приведено в соответствие с требованиями новой версии PCI DSS 2.0. Руководство состоит из трех основных частей:

1. Описание требований PCI DSS в части журналирования событий, 
2. Описание процедур анализа журналов регистрации событий,
3. Описание доказательств, которые потребуются для подтверждения соответствия требованиям PCI DSS в части журналирования событий.

В первой части рассмотрены следующие вопросы:

• Цели создания Руководства
• Начальные требования и предположения
• Вопросы, которые не вошли в Руководство
• Роли и обязанности
• Требования PCI DSS в части журналирования событий
• Требования раздела 10 PCI DSS
• Другие требования, связанные с журналами регистрации событий

Практика ИБ \ Метрики для оценки эффективности антивирусной системы

Что-то я давненько не выкладывал в блоге ничего кроме CISSP'а. Судя по логам, некоторые заскучали (хотя может это Новый год сказывается ;-)). На самом деле интересного материала накопилось много, но хочется сначала закончить с CISSP'ом.

Вобщем исправляюсь :-)

Lenny Zeltser очень кстати опубликовал в своем блоге рекомендации по выбору метрик для оценки эффективности работы системы антивирусной защиты компании. Ниже представлен перевод статьи.

К вопросу о полезности пентестов

Полезны ли пентесты? Безусловно! Но... только в определенных ситуациях. Очень хорошая заметка на тему пентестов и аудитов - на каких этапах развития компании они нужны: http://toxa.livejournal.com/487821.html. Автору респект :-)

Действительно, мы слишком часто рассматриваем пентест, как единственное решение проблемы с бюджетом на следующий год. Мы читаем, слушаем, рассказываем про "процессные подходы", "комплексную безопасность", "осознание ИБ бизнесом"... Но ведь это ж все на словах интересно, в теории. А на деле - скукота, рутина и еще не факт, что получится. Вот мы и ищем "волшебные таблетки" - денег заплатил и (о чудо!) все проблемы решены, в чек-листе поставил очередную галочку. Сейчас в моде пентесты, которые могут сразу же перевернуть отношение бизнеса к безопасности. Чуть раньше - это были системы DLP, раз и навсегда решавшие проблемы утечек информации. Ну и, конечно же, популярные во все времена торжественные порки несчастных рядовых пользователей, нарушивших требования ИБ - депремировал парочку и сразу же из курилок начинают доноситься обрывки обсуждений разделов политики информационной безопасности вместо традиционного шоппинга, футбола и погоды.

Вот только почему-то на практике "волшебная таблетка" оказывается не очень приятной на вкус и не такой уж волшебной (хотя, наверное, бывают и исключения). Бизнес все равно почему-то денег не дает и начинает как-то нехорошо коситься на безопасность, обнаруживается куча проблем безопасности, решение которых займет уйму времени, вместо старых "дыр" появляются новые, данные продолжают утекать, а пользователи, даже те, которых еще не пороли, науськивают на безопасность свое начальство... За что боролись... 

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

Пентест - отличная штука, на практике подтверждающая успешность огромного объема проделанной ранее работы :-)

ИТ, ИБ и реалии жизни

Успех - это способность не теряя энтузиазма, 

идти от одной неудачи к другой.

Интересное и очень точное наблюдение в отношении ИТ-аутсорсинга: http://juick.com/101O101/753410. Сам недавно занимался аудитом в довольно крупной компании (около 1500 сотрудников), в которой услуги ИТ-аутсорсинга предоставляла очень крупная именитая и уважаемая иностранная компания и еще кучка мелких - региональных (названий указывать не буду)... Был, мягко говоря, просто поражен реалиями аутсорсинга. При просто космических ценах никто не считал проблемой частые сбои в работе основных систем в рабочее время, ошибки при передаче финансовой информации, реакцию на "критические" проблемы в течении недель и т.п. Про безопасность предоставляемых сервисов вообще речи не было - ее не было в SLA... А уж какие показатели были в SLA!.. Причем, судя по всему, это был далеко не самый плохой вариант.

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

Руководству НЕ нужна полноценная и эффективная ИБ. Ему НЕ нужна гарантированная непрерывность работы, быстрое восстановление бизнес-процессов, безопасность и отказоустойчивость. Руководству нужно чтобы было дешево, прямо сейчас и был четко обозначен виноватый в случае инцидента ИБ или сбоя. При этом убытки компании от сбоев всем "до лампочки", ибо человеко-часы офисного планктона никто не считает.

Инциденты безопасности часто вообще остаются незамеченными, либо считаются неизбежными. А уж если они повлекли реальный ущерб, на который кто-то случайно обратил внимание, то самое главное в этой ситуации - найти "козла отпущения" (которым часто бывает начальник ИБ, если он не подсуетился и не возглавил эти поиски) и объявить ему торжественный выговор (в крайнем случае - депремировать на 10%, в совсем крайнем - уволить)... Все равно убытки компании на бонусах ее менеджеров обычно не сказываются...

Подчеркну, что это относится именно к руководителям, как отдельным личностям. Может бизнесу в целом-то оно и нужно - об этом говорят на совещаниях различных комитетов, правлений и советов директоров... Но почему-то это остается просто словами. Самих руководителей интересует выгода только сиюминутная, мало кто думает о будущем компании больше, чем на полгода вперед. Личные бонусы в конце квартала (года) куда интереснее потенциальной прибыли компании через пять лет...

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

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

А мы при этом пытаемся внедрять "лучшие практики" ИБ и ИТ. И удивляемся, что они почему-то не работают...

Практика ИБ \ Наиболее распространенные ошибки при построении системы ИБ

Ниже представлены наиболее распространенные ошибки при построении системы информационной безопасности, которые следует избегать. Это переведенная, расширенная и слегка адаптированная "шпаргалка" (How to Suck at Information Security) с сайта Ленни Зельцера.

Практика ИБ \ Аудит событий безопасности

Антон Чувакин выложил в своем блоге интересную "шпаргалку", в которой приведены все наиболее важные виды событий, которые нужно собирать и анализировать в рамках текущей деятельности и при разборе инцидентов безопасности. Может очень пригодиться на начальном этапе внедрения практического аудита событий, когда нужно из огромной массы возможных событий выбрать тот разумный минимум, который позволит накапливать всю нужную информацию и при этом не утонуть в море "шума". Особенно актуально при анализе событий полуручными методами.