Архив рубрики: Управление безопасностью

НСПК на крючке у АНБ?

Сижу я с утра, правлю резюме, и изучаю сайт потенциального работодателя Solar Security.

nsa-nspkЗацепился взгляд за последнюю новость (сохраненная копия):

Компания Solar Security, разработчик продуктов и сервисов для целевого мониторинга и оперативного управления информационной безопасностью, сообщает об успешном завершении основного этапа проекта, реализованного в АО «Национальная система платежных карт» (НСПК).

В ходе проекта сотрудники Solar Security и НСПК совместно подключили инфраструктуру компании к сервисам Solar JSOC, который обеспечил выявление и анализ событий ИБ, а также позволил предотвращать кибератаки в режиме реального времени 24/7. Параллельно в НСПК была развернута вся необходимая инфраструктура для построения внутреннего SOC, на которую постепенно были перенесены правила корреляции и выявления инцидентов, профили источников данных и другие наработки Solar JSOC.

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

Согласно мировой практике, создание системы мониторинга и реагирования на угрозы кибербезопасности может занять несколько лет, поэтому на период ее построения в НСПК было принято решение об использовании услуг ИБ-аутсорсинга. В качестве сервис-провайдера была выбрана российская компания Solar Security.

Я, честно сказать, порадовался, какой крупный проект. А потом, что-то мне показалось очень неправильным. Всем известно (да, и вендор этого не скрывает), что Solar строит свой SOC Solar inView и его аутсорсинговую версию JSOC на продуктах компании HP – ArcSight. Это, кстати единственный продукт из 4, который Solar не стал заявлять в реестр отечественного ПО (хотя мб и подали):

Все отечественные продукты Solar Security

Все отечественные продукты Solar Security

Т.е. это единственный не отечественный продукт в линейке компании. Я уже писал, что продажа услуг – легальный способ обхода ограничений на покупку иностранного ПО. Судя по новости, НСПК решил строить свою самую главную систему информационной безопасности на западном вендоре… И теперь, каждый сенсор ArcSight будет стоять на каждом ключевом узле НСПК, что бы передавать информацию в JSOC. Это просто особенности работы этой системы.

solar-jsoc-sec

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

Вероятная схема утечки данных из НСПК

Вероятная схема утечки данных из НСПК

Как минимум:

  • Настройки средств защиты;
  • Настройки сетевого оборудования;
  • Настройки серверов и рабочих станций;
  • Инциденты безопасности и многое другое.

Если предположить, что HP сотрудничает с Агентством национальной безопасности США, как и Cisco, то вся наша платежная система уже под колпаком.

Считайте меня параноиком, но я хотел бы задать вопрос – кто кого ввел в заблуждение, принимая решение ставить западное решение ArcSight под торговой маркой Solar Security?

В то время, когда основным драйвером для НСПК стало возвращение Крыма и попадание нашей страны под несправедливые санкции. Мы открываем всю нашу платежную информацию вероятному противнику… Фактически каждый житель России, теперь под колпаком у США. Так мало того, инфраструктура НСПК подвергается серьезному риску, если уже не взломана…. Все это крайне печально.

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

Всего вам доброго.

Собирательный портрет или игра в угадайку

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

geshtalt

Когда-то я работал в Утконосе, и моей задачей было ловить внутренних нарушителей. Т.к. я был молодым специалистом, то ловил я их в корпоративной сети и интернете. Если бы я справился, я бы подкачался и приобрел свирепый оскал, меня перевели бы на более ответственный фронт – склад.

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

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

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

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

По сути – это навешивание ярлыков (только не так, как это делает какая-нибудь оторванная от реалий соционика). Скорее это ближе к гештальтам (как законченной форме, а не гештальтпсихология, которая тоже под знаком ереси ходит). Если вы читали шпионские романы или даже интересовались историей спецслужб, то замечали, что все агенты имели прозвища (для конспирации). А эти прозвища, в свою очередь, часто были «говорящими» (теми самыми клише или гештальтами), слепком с личности человека. Да что далеко ходить — посмотрите на прозвища своих друзей.

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

Например, вчера я гулял с ребенком, и второй раз в жизни увидел папу и мальчика лет 7-8, они на детской площадке гоняли мячик друг с другом. Я предположил, что это «воскресный папа», потому что:

  1. Я их вижу второй раз. Оба раза в воскресные вечера.
  2. Они играют вдвоем и ребенок рад, значит, либо папа много работает, либо видятся они только на выходных.
  3. Папа плохо знает район, т.к. для их целей больше подошла бы коробка в 30 метрах, где вообще никого никогда не бывает, чем пяточек 3 на 4 метра.
  4. Папа делает это не часто (см. пункт 2). Если бы он делал это часто, сын бы бегал с друзьями, а папа сидел на лавочке и уперся бы в телефон.
  5. Папа был одет довольно легко, как раз для вождения машины. Вряд ли бы он стал так одеваться, выходя в достаточно прохладную погоду, даже если бы куда-нибудь потом ехал. Проще было дома переодеться.
  6. Сын был одет для долгой прогулки, а не для пинания мячика. Если он любит футбол, то оделся бы более спортивно. И так далее.

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

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

В личных (рабочих, дружеских и т.п.) отношениях есть только один принцип – относись так, как относятся к тебе. Ярлыки и классификации тут не помогут.

Всего вам доброго.

Аутсорсинг ИБ – будущее, которое может и не наступить

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

outsoursing2

Лирика для вхождения в тему

Как-то месяца два назад наткнулся в ленте новостей на статью «почему западные методики бизнеса не приживаются в России» или как-то так. Главный посыл: потому что у нас другой менталитет. А вот вывод был неправильный – «давайте менять менталитет».

Вся стратегия аутсорсинга (слово-то какое буржуинское :)) строится на том, что мы доверяем компании аутсорсеру. А если не доверяем, то сможем с нее взыскать убытки по договору через суд. Как вы понимаете, чтобы не допустить второго, наше доверие должно быть избирательным. Помочь ему в этом может множество факторов, но главный – репутация. И это первая проблема.

Вчера я упоминал круглый стол у Алексей Лукацкого на Infosec2013. Там Алексей впрямую заявил – «в России репутация стоит ноль». И я был шокирован, какое большое количество фанатов Алексея его поддержало. На BISA саммите в 2014 году я решил уточнить у Алексея, изменилось ли его мнение (не дословное цитирование):

— Нет. У нас в куче банков происходят утечки и кража денег, но все остается как есть.

— Хорошо. Но начнем с малого, есть же личная репутация, и…

— А и ее нет. Про меня такое говорят, устал читать.

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

У аутсорсинга нет репутации, а следовательно доверия к нему

Я затрону всего три грани, почему аутсорсинг — это не про нас:

  • со стороны заказчика;
  • со стороны рынка;
  • и со стороны продаж.

Почему аутсорсинг ИБ не нужен заказчику?

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

Во-первых, это очень дорого. Посмотрите материалы Solar с SOC форума, в каждой презентации у них есть слайд, где затраты на внедрение собственного SOC и аутсорсинг сходятся в районе 3 лет (парни без контактов – вы еще не оплатили прошлый счет за product placement :) ).

Окупаемость внедрения SOC

Т.е. дальше аутсорсинг будет только дороже. Вообще, нанять 1 специалиста на аутсорсинг на рынке стоит 3 ФОТ от стоимости собственного специалиста.

Это не говоря уже о том, что, если вы берете на аутсорсинг сложные системы (те же SOC), вы их банально не сможете амортизировать, а любой бухгалтер вам скажет, что амортизационные отчисления — один из главных источников модернизации. Для сложных систем срок амортизации варьируется от 3 до 7 лет. Т.е. и здесь не выгодно.

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

Я не хочу сказать, что безопасники – слуги. Но это наиболее близкая к владельцу структура, призванная его защищать от всего, от чего сможет. Если он не доверяет собственным безопасникам, то кому ж доверять? Скажем прямо, безопасники – это наиболее преданная и лояльная к организации структура. Да, преданность и лояльность можно купить. Ведь всегда в условиях войны можно было купить наемников. Но надо быть уверенным, что вас не кинут в трудную минуту. И тут опять всплывает вопрос репутации.

Рассмотрим разные ситуации взаимоотношений. Например, я. Любой человек, работающий со мной знает, что я человек слова, у меня есть несколько пунктиков на счет сроков и другие заморочки. Но если я с кем-то договорился, то слово назад не вертаю. Это отношения человек–человек.

В ситуации отношений человек-организация все примерно также. Правда, возрастает неопределенность в отношении организации.

А вот в ситуации организация-организация все катится в кромешный ад. По сути, эти отношения переворачиваются в организация (аутсорсер)-человек (заказчик), т.к. в Заказчике за привлечение аусорсера отвечает 1 человек, он принимает решение, контролирует и получает результат. Сами понимаете, что в данном случае заказчик будет в положении Алисы в стране чудес. Аутсорсер для него совсем не прозрачен (кто сомневается, можете как физическое лицо повзаимодействовать с любой государственной или коммерческой структурой по нетривиальному вопросу).

Кто эти люди? Кому они расскажут мои тайны? Уйдут ли через месяц работать к конкурентам? И еще тысяча вопросов. И, увы, все эти SLA, NDA, KPI и прочее не дают ответа. Закачаешься, какая информация внутри тусовки циркулирует.

Собственного сотрудника хотя бы обматерить можно. А Оператора Антона — иди еще найди, кто это.

Почему рынку не нужен аутсорсинг ИБ?

Тут уже не буду растекаться мыслью по древу. Чтобы аутсорсинг работал, должно быть множество компаний с определенной репутацией. Это на рынке телефонов могут быть пионеры, которые загребают все деньги. На рынке услуг все совсем иначе. Если нет альтернативы, то не понятно чего ожидать. Сейчас вот Solar продвигает аусорсинг SOCов. Молодцы. Но мне не с чем сравнить. Я не понимаю ни ценообразования, ни своих затрат, не могу оценить качество сервиса. Да, и банально могу не доверять другим организациям в таком тонком деле как управление инцидентами. Потому что глядя в окно, я вижу совсем иную картину. Почему Solar Security считает себя особенной? «Где ваши доказательства?» (с)

Поэтому понятно, почему Игорь Ляпунов (директор Solar) говорит: «Ответственность за информационную безопасность на заказчике, нельзя ее переложить на аутсорсера».

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

Почему аутсорсинг ИБ не продается?

Я обещал рассказать историю. Выполняю.

Жила была компания, оказывающая услуги по аутсорсингу. Взялись за дело они шибко, и скоро стали отличными специалистами в узкой области. Но потом уперлись головой в потолок (или дно, как посмотреть). Текущие их заказчики уже не покрывали их расходов, т.к. аутсорсинг услуг масштабируется линейно. Надо было искать новых. Решила наша компания развивать партнерскую сеть, стали они везде ездить и всех агитировать «продавайте нас!». Но не получилось, никто их продавать не захотел. История еще не закончилась, посмотрим, что будет.

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

outsoursing3

В этом случае аутсорсер рассчитывает в основном на свои продажные силы, а их всегда недостаточно. Ирония: аутсорсеру, чтобы продавать аутсорсинг, нужны продавцы на аутсорсинге в партнерах. :)

Куда не кинь, всюду клин. Аутсорсинг дорого, стремно и ненадежно. Печаль.

Управление инцидентами ИБ на основе SIEM-систем

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

Что же такое инцидент?

Процесс управления инцидентами сопряжен с некоторыми трудностями:
Четкое закрепление ролей в процессе. Если в подразделении владельца процесса роли закреплены достаточно четко, то в привлекаемых подразделениях всегда возникает вопрос: кто и как должен реагировать и какие действия совершать? Без этого оперативное реагирование на инцидент и его расследование будут затруднены.

Сбор данных из разных источников. Огромное множество средств защиты и целевых систем ведут собственные журналы в различных форматах. Возникает необходимость в просмотре всех этих источников, в проведении корреляции событий с возможностью построения вектора атаки.
Ограниченность ресурсов. Это ахиллесова пята большинства организаций. Ресурсы (кадровые и технологические) стоят денег, и если вопрос с кадровыми ресурсами можно решить автоматизацией процессов, то без необходимой инфраструктуры – никуда.
Данные препятствия значительны, но не смертельны. Любое из них может быть компенсировано различными организационными мероприятиями.

Данный термин в зависимости от методики определяется довольно широко. Поэтому остановимся на самом простом: инцидент – это любое событие, не являющееся частью нормального функционирования системы/сервиса/процесса. Как следует из определения, все, что не было заложено в логику работы информационной системы, является инцидентом. Сюда же относятся события, связанные с рисками информационной безопасности (потенциальные или свершившиеся).

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

Инцидентами информационной безопасности могут быть:

  • отказ в обслуживании сервисов, средств обработки информации, оборудования;
  • нарушение конфиденциальности и целостности ценной информации;
  • вредоносные программы и т.д.

Каждый инцидент может быть классифицирован по множеству признаков. Я использую следующие:

  • причина возникновения инцидента (достижение порогового значения, аппаратный сбой и т.п.);
  • объект воздействия инцидента (информационный актив, система или подсистема и т.п.);
  • критичность инцидента;
  • источник инцидента;
  • периодичность (уже происходил или случился впервые);
  • ущерб (денежное выражение свершения инцидента).

Процесс управления инцидентами

Так как инциденты наносят ущерб работоспособности системы (реальный или потенциальный), целесообразно организовать процесс управления ими. Он включает в себя (рис. 1):

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

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

  • возможность мониторинга целевых систем и средств защиты с организацией выделенного хранилища инцидентов и log-файлов;
  • расследование инцидентов;
  • возможность получения информации от подразделений (в первую очередь IТ) по произошедшим инцидентам с высокой важностью реагирования и предоставления информации;
  • полномочия по форс-мажорному исправлению последствий инцидентов с привлечением необходимых специалистов других подразделений;
  • возможность создания корректирующих мер.

Сложности реализации процесса управления инцидентами

Процесс управления инцидентами сопряжен с некоторыми трудностями:

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

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

Ограниченность ресурсов. Это ахиллесова пята большинства организаций. Ресурсы (кадровые и технологические) стоят денег, и если вопрос с кадровыми ресурсами можно решить автоматизацией процессов, то без необходимой инфраструктуры – никуда.

Данные препятствия значительны, но не смертельны. Любое из них может быть компенсировано различными организационными мероприятиями.

Автоматизация процесса управления инцидентами

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

Система управления событиями – это глубоко интегрированная с другими процессами система. Разумеется, большинство этапов можно сделать локальными, но тогда серьезно снизится эффективность автоматизации.

Ядром автоматизации является SIEM-система. Помимо джентльменского набора функций (сбор и анализ событий; ранжирование событий и инцидентов; корреляция полученных данных на предмет определения комплексных атак, а также атак, распределенных по времени; визуализация полученных данных в реальном времени и оповещение операторов системы об инцидентах и об элементах сети, вовлеченных в атаку) SIEM-система должна дополнительно уметь:

  • Подключать любые IP-системы и устройства. Если мы не можем направить поток событий в SIEM лишь потому, что у нас самописная система, дорого и трудно разрабатываются коннекторы или необходимо обращаться в штаб-квартиру на другом конце света, то зачем нужна такая система?
  • Подключать отечественные средства защиты. Учитывая специфику отечественной информационной безопасности, необходимо понимать, что немногие организации могут обойтись только западными вендорами.
  • Работать с Service Desk. SIEM должна уметь генерировать заявки об инцидентах и отслеживать их выполнение. Во-первых, это позволяет сократить время реагирования; во-вторых, вовремя необработанный инцидент – это тоже инцидент.
  • Инициировать управляющее воздействие. Необязательная, но крайне полезная функция. Существует много ситуаций, когда решение по инциденту должно быть произведено быстро. Например, изоляция рабочей станции от локальной сети организации путем «выключения» порта на маршрутизаторе для последующего разбирательства. Данная функция требует деликатного обращения, поэтому ее использование целесообразно после прохождения этапа решения ошибок 1-го и 2-го рода.
  • Организовывать инвентаризацию существующих и поиск новых информационных активов. Не существует статичных организаций, поэтому, если мы не имеем текущей картины существующих активов, наш процесс управления событиями будет иметь белые пятна, о которых он ничего не знает. Если карта активов хранится в SIEM-системе, она должна уметь поддерживать их в актуальном состоянии.

Необходимые документы

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

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

Дудко Дмитрий
Опубликовано: Журнал «Information Security/ Информационная безопасность» #3, 2014