Архив метки: интеграторы

Как сделать стандарт за 10 дней (авторская версия)

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

Источник

Месяц до дня Х

2009 год в безопасности персональных данных, был годом предвкушения. Ходили упорные слухи, что 152-ФЗ «О персональных данных»., принятый в 2006 году вот-вот станет обязательным для исполнения. С момента принятия, рынку и операторам было дано время подготовиться к обязательному исполнению закона, и время подготовки истекало. 2010 год виделся годом большой работы, но закон вступил в окончательное действие лишь в 2011, но этого еще никто не знал (а потом еще пару лет не верили, что приняли)

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

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

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

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

Источник

Неделя до дня X

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

Забегая немного вперед, отвага заключалась в атаке «с шашками на танки» силами одного специалиста на такую масштабную работу. Уже значительно позже, я делал похожие работы возглавляя различные по численности группы (от 2 до 6 человек). И если уж говорить об оптимальной численности команды, то оптимальное количество людей 1-2 человека, не считая привлекаемых специалистов, вроде технических писателей. Из 5 подобных работы, 1-2 человека – это лучшее соотношение по производительности и достигаемому эффекту. Например, команда из 5 человек, подобную работу делала 9 месяцев.

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

Источник

1-3 день работы

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

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

Если не вдаваться в подробности, мне необходимо было описать три последовательные стадии защиты персональных данных:

  1. проведение обследования,
  2. составление модели угроз,
  3. создание комплекта организационно-регламентирующих документов.

Разумеется, я начал описывать с середины, что вылилось в большие проблемы на 7-10 дней.

Второй ошибкой было использование последовательного принципа написания документов. Это когда сначала титульный лист, потом оглавление, список сокращений, вводная часть и т.п. Это не работает, в определенный момент вы обязательно встанете в «креативный тупик», чаще всего он наступает на 3-5 разделе, когда вам понятно, откуда вы вышли и куда хотите прийти, но не понятно как.

Забавно получилось с сокращениями, которые сразу же были сделаны. Чтобы была хоть какая-то преемственность с текущей нормативной базой, я скопировал сокращения из документов регулятора, и там осталось сокращение «ТКУИ – технические каналы утечки информации», которое в тексте нигде не встречается.

Лайфхак: чтобы сделать список сокращений актуальным, во время написания применяйте три простых действия:

  1. Как только вам потребуется сделать сокращение, пишите в формате «(далее – )». Например, обязательное сокращение в тексте (далее – ОСТ).
  2. Держите открытым отдельный файл Exсel, куда заносите все сокращения (можно без расшифровки).
  3. Когда текст будет написан, ранжируете в экселе перечень от А до Я и смотрите количество, а в тексте поиском ищете вхождение «(далее – )». Если числа совпали, поздравляю – у вас актуальный перечень сокращений.

 

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

Результат: 1 файл объемом 20 страниц и несколько табличек в Exсel.

4-6 день работы

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

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

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

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

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

В общем случае:

  • результат;
  • методика достижения результата;
  • описание.

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

Уже гораздо позже я дополнил этот метод концепцией «улучшенного JPEG», которая говорит, что работа в зависимости от срока всегда должна быть готова на 100%, разница лишь в степени детализации. Если кто застал времена небыстрого интернета, то обычный JPG отображался по мере загрузки (тот самый последовательный способ написания документов) сверху вниз, а картинку JPEG загружал всю целиком и улучшал ее четкость.

Одна беда – применение концепции «улучшенного JPEG» в лоб не работает для сложных документов (по крайне мере у меня). При прямом применении вы в новом документе создаете разделы и пишете, о чем они, расширяя описание по мере проработки. В стандартах и хитрых методиках это не работает, с чем я столкнулся на следующем этапе.

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

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

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

На создание модели угроз ушло 5 дней, и я приступил ко второму документу.

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

Результат – готовая методика по моделям угроз плюс половина приложений.

7-9 день работы

Это было время эйфории, план в голове сложился, осталась чисто механическая работа – только и делай, что добавляй приложения и описывай грамотно. Беда пришла откуда не ждали, даже две.

Источник

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

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

С приобретением опыта я стал делать цветные заглушки. Ссылка на раздел 4, приложение 5 (отследить номер) и т.д.

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

На девятый день работы все было готово – два файла рекомендаций с приложениями. Оставалось доделать мелочи.

10 день работы

Доделав мелочи, я решил перечитать все еще раз – поправить ошибки, отловить мелкие косяки и т.п. И тут мне захотелось сделать свою работу еще лучше, чтобы было понятнее. Решил отразить в описании угроз информацию из итоговых таблиц (все эти «реализация угрозы является маловероятной»). Зачем? Почему? Вот, захотелось.

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

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

Источник

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

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

P.S. Краткая памятка для отважных

  1. Читай техническое задание.
  2. Не нарушай последовательность стадий работы.
  3. Внутри стадии двигайся от результата к методологии, а потом к определениям.
  4. Дополнять малое проще, чем сокращать большое.
  5. Занимайся оформлением в последнюю очередь.
  6. Ссылки внутри документа проставь на предпоследнем шаге.
  7. Удели время перепроверке.

Источник

P.S.S.

Вы прочитали неполиткорректную (авторскую) версию. Политкорректная версия размещена на Хабре.

Игроки рынка ИБ и таксисты

Надо сказать, я очень люблю наблюдать в динамике различные отрасли. Так, что бы лет 15-20 смотришь, а потом вспоминаешь – эка раньше было. В основном это что-нибудь совсем бытовое, например, таксисты. Думаю, каждый с ними сталкивался.

О, эти разбойники пассажирских перевозок. Раньше можно было просто поднять руку, и мог проехать хоть на мерседесе, хоть на скорой без пробок. Таксисты всегда были обманщиками, во всяком случае, те, кто занимался перевозками на периодической основе. На моей улице 3 остановки, на двух из них стоят частники и чего-то ждут. Лет пятнадцать назад, у них было море работы, до метро можно было доехать и за 50 рублей и за 300. Сейчас их бизнес подзахерел, но они все равно стоят, мб еще кого-то возят.

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

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

Надо сказать, что это стандартная практика – выбираешь 1 водилу, и мотаешься с ним. Помню я как-то из Мурманска в Полярные Зори 400 км ехал на такси, ехали часов 5 или 6, зимой в ночь. Так, этот же парень нас и забрал оттуда через два дня. Покатались хорошо.

И тут значит, разложили вещи, хотим покататься. Звоню. Говорит, я на вызове в другой части города. Ну, ладно. Через некоторое время еще раз попробовал. Опять тоже самое. Оказалось, в Петрозаводске все таксисты сидят на зарплате. Диспетчер принимает звонки и распределяет их водителю, а у него в свою очередь план, который он должен в смену выполнить. Я-то с таким не сталкивался, для меня таксист – свободный волк на охоте. Например, в Камышине – диспетчера сидят на небольшой зарплате на телефоне и просто сообщают «своим», где клиент – а водилы уже сами разбираются.

А тут значит – план. Но все цивильно, да ж карточкой платить можно.

И этой бы истории не было, если она не была обрамлена еще двумя фактами. Когда мы собирались уезжать из дома до вокзала, захотел вызвать такси к определенному времени. Яндекс-такси в этом не помог, т.к. у него можно максимум за 15 минут время поставить. Поставил Убер и заказал машину к назначенному времени. И, началось. Во-первых, он опоздал на 20 минут. Ехал откуда-то с Лосиноостровской. Во-вторых, врал, что едет к нам, хотя вез другого клиента. В-третьих, включил счетчик на подъезде к нам, и стартанули мы со 20 рублей. Я был уже мыслями в отпуске, не стал мандиться и просто поставил ему 3 звезды.

Второй случай произошел уже по приезде. Посмотрел, сколько стоит в Яндексе – выходило 500-600 рублей. Неспешно выхожу, вытаскивая чемоданы. Стоят два бомбилы, предлагая подвезти. Спрашиваю – сколько? О, это любимый вопрос бомбил в аэропортах и вокзалах. Есть целый спектр кидалова о невнятно сказанных суммах. Получил классический вопрос – сколько дашь? Говорю, 500 рублей. И получил волну ненависти, с общим посылом, что только заехать на площадь перед вокзалом стоит 300 рублей. И за каким хером ты тогда спрашивал, сколько я дам? Что бы поторговаться? Или что? Так и остались они стоять на пустой платформе, а я доехал за 550 рублей.

Таким образом можно выделить следующие виды таксистов:

  • Обычные таксисты. Чаще всего работают с диспетчером, но сами себе волки. Если ничего не остается, работают с Яндексом или Убером, которые их тираняткак хотят, но деваться некуда.
  • Зарплатники. Водители, на зарплате. Не прочь подзаработать, но диспетчер главнее.
  • Бомбилы. Грабящие людей на вокзалах и в аэропортах. Готовы целый день простоять, но меньше чем за 3 000 не поедут. Поджидающие людей неопытных, туристов и с временной потерей концентрации.

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

У нас есть свои бомбилы. В основном это крупные интеграторы, которые «не хотят связываться с маленькими проектами». У них же большой штат дармоедов, и им непременно нужны проекты на десятки миллионов рублей. Вот, и сидят они в ожидании, когда что-нибудь такое свалиться. Сюда же относятся всякие крупные вендора с непомерным ценником за сомнительные функции, например, SAP. Но этот путь хиреет, т.к. ничего нового не появляется. Да, некоторым вендорам везет отхватить денег, но если копнуть ближе – 80% суммы там закупка иностранного железа с софтом.

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

Ну, а с обычными – все понятно. Это среднестатистические вендора и интеграторы. Как все. Где-то конкурс отожмут, где-то бочком пройдут. Работа кипит. Красота.

 

На этом все. До новых встреч.

«Быть PS». Про бонусы

Заканчивается декабрь, а, следовательно, и 4 квартал входит в заключительную стадию. А что происходит после закрытия календарного года? Правильно, нам должны бонус. О них и поговорим.

bonus

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

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

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

Так же надо понимать, что с бонусом вас всегда обманут. Некоторые компании до сих пор должны мне бонусы миллиона на 2. Основные способы тут следующие:

  • Невнятность формулы определения.
  • Труднодостижимые показатели.
  • Банальное кидалово.

Невнятные формулы

Тут все просто. Выбирается много компонентная формула, и ты целый год крутишься как уж на сковородке. Например, когда я работал в компании «АйТи» — мой бонус включал: выполнение квоты, оценку руководителя, оценку коллег и еще что-то.

При этом от выполнения плана бонус зависел лишь на 30%.

По факту, можно было получить 70% премии, не выполнив план. Разумеется, могли и ничего не заплатить, т.к. план-то не выполнен. Как раз перед моим приходом, формулу изменили: заменили индивидуальный план, на план отдела. Что повлекло за собой как плюсы, так и минусы. Например, можно было ничего не получить внеся наибольший вклад в квоту (у меня так было пару лет подряд).

Если у вас есть выбор, берите наиболее простые формулы. Например, процент от сделки. Например, в Leta IT инженерам платили 1-2%, начальники получали до 5% от сделки. Все просто и понятно. Правда, это все равно не делало бонус основным способом заработка у них. :)

 

Труднодостижимые показатели

Это, вообще, классический прием. Особенно распространен в западных вендорах. Вам дается большой фикс, всякие льготы, и план, который вы не выполните никогда. А еще над вами будет специальный начальник, который будет смотреть, что бы вы этот план не выполнили. Т.к. если вы его выполните на 100%, то получите офигенный бонус, а начальник пойдет на биржу труда. Поэтому ваше выполнение будет в районе 30-50%, вы будете что-то там получать, и будете бегать, как белка в колесе с наказом «ВЫПОЛНИ ПЛАН, НАКОНЕЦ!».

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

 

Банальное кидалово

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

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

Кстати, следствие из этого, что власть начальника простирается до момента, пока он вовремя платит.

Или рядом с нами был другой интегратор. Они к концу 2014 года – план все выполнили. Но, оказалось, что плану них был в долларах (вот, это поворот), а доллар – упал. А, следовательно, все их выполнение в рублях, на самом деле не выполнение. Следовательно, никакого плана. Красиво, а?

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

 

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

Кстати, поинтересуйтесь на собеседовании – когда платят бонусы по итогам года? Какова текущая задержка бонусов по компании? И все в таком духе. :)

И, еще раз, не рассчитывайте на бонус, как средство заработка.

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

Читать другие главы

«Быть PS». Как обманывают вендоры ИБ, и каково ваше место в данном обмане (+кейс)

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

fraud

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

Кстати, рекомендую освежить нашу дискуссию в «Открытой безопасности».

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

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

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

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

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

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

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

fraud_scheme

Как видно, основная коммуникация: Ответственный за проект – пресейл – продукт-менеджер.

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

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

В итоге вендор под лозунгом «главное ввязаться в войну, а там посмотрим», будет убеждать, что все будет в ажуре.

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

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

Пример

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

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

В ходе эксплуатации, оказалось, что «КонсультантПлюс» нагло наврал в своей рекламе, что у них есть требуемые документы. Если кому интересно, вот, скрин с их сайта:

consultant_ru2

В общей сложности у них выявилась недостача 3192 документов – 2008, 2011 и 2014 годов, которые вендор на голубом глазу предложил получить у дисти в частном порядке. Как видим, даже «самая полная база правовой информации», сделает все, что бы продать свой продукт.

Компенсировать затраты «КонсультантПлюс» отказался.

Такие дела. Берегите себя.

 

P.S. Кстати, оказалось, что у КонсультантПлюса – нет тикетной системы, вы никогда не узнаете, статус вашего обращения, если не будете названивать туда каждый день.

consultant_ru1

Темы битвы: почему не растут угрозы?

Эх, давно не писал. Сильно скучал я по этому делу. Как вы знаете, меня рекрутировали за корзину печенья и банку варенья участвовать в Кибербитве. Неожиданно, я даже победил. Говорят, все любят андердогов и сравнивали меня с Исландией :)

before

Пара слов о мероприятии, в целом довольно интересно, но были свои минусы:

  1. Крайне мало времени на вопрос. Что является следствием большого количества вопросов, достаточно 3-4.
  2. Олег, не стоит менять тему за день до битвы. Уж не знаю, откуда там взялись роботы.
  3. Общее голосование, вместо раундового.
  4. крайне неудобно смотреть, нет чатика, не работает капча (!!) в форме вопросов.

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

Кстати, кто пропустил — полная версия:

Тема 1. Какой будет динамика роста внутренних угроз в ближайшее время?

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

По сути, роста внутренних угроз не происходит. Если взять классическую формулу риска, то в ней вообще нет угроз (и тем более уязвимостей), которыми мы так привыкли пугать директоров в СМИ и на конференциях. Классическая формула из ISO:

Величина риска = вероятность события * размер ущерба

где

Вероятность события = вероятность угрозы * величина уязвимости

сделав подстановку, получаем

Величина риска = вероятность угрозы *величина уязвимости* размер ущерба

Классическая схема рисков ИБ

Классическая схема рисков ИБ

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

При том, что под «вероятностью угрозы» здесь понимается likelihood (а не классическое probability), что тоже переводиться как вероятность, но характеризуется частотой реализации угрозы за определенный период времени. Крайне не надежная величина.

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

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

 

Говоря, нас – я говорю о группе под самоназванием «поИБэ». Это вендоры, интеграторы, заказчики, множество специалистов разных направлений. К коей я тоже себя отношу. Осознать, и открыто выразить свою принадлежность к некоей группе, неизбежно отрекаясь при этом от принадлежности ко многим другим группам, — не шутка. Мы (современные люди) принимаем такие решения ежеминутно.

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

Между тем с биологической точки зрения все эти утверждения одинаково верны. Вот несколько разных «мы», узаконенных современной биологической наукой. Мы многоклеточные. Мы эукариоты. Мы жгутиковые. Мы животные. Мы вторичноротые. Мы хордовые. Мы позвоночные. Мы челюстноротые. Мы четвероногие. Мы амниоты. Мы синапсиды. Мы млекопитающие. Мы плацентарные. Мы приматы. Мы обезьяны (или, что то же самое, антропоиды). Мы узконосые обезьяны. Мы человекообразные обезьяны, или гоминоиды (по-английски apes). Мы большие человекообразные обезьяны (great apes). Мы большие африканские человекообразные обезьяны (african great apes). Наконец, мы люди.

В наследство от наших предков и родичей, нам досталось три основные доминанты поведения (мотивов) (в порядке убывания):

  • еда
  • размножение
  • доминантность

(кстати, если вы адепт Пирамиды Маслоу – вам надо пересмотреть свои взгляды).

И именно это мы упустили, когда кинулись надувать наш пузырь страха. А теперь не понимаем, почему нас задвигают подальше. Посмотрим, как в связи с этим меняется наша картина ИБ рисков, на реальные риски.

Классическая схема риска

Классическая схема риска

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

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

Например, на данной битве было два мотивированных человека: Олег с точки зрения доминирования, и Дима с мотивом еды (победителя покормят на BISA Summit). Понятно, что при прочих равных Олег не будет тыкать Диме ручкой в глаз. В то время, как Диме отступать некуда.

Например, в нашей отрасли сейчас кризис. Увольнения, задержки зарплаты и т.п. Из наших вендоров и интеграторов уже вынесли все более-менее ценное. От клиентов, до листов рассылки для спама. Голодный человек обойдет наши CPB и глазом не моргнет. Тогда зачем мы?

В поИБэ мы ставим способ реализации во главу угла. Все наши ЧМУ пестрят действиями (например, Кража носителей информации или Установка ПО не связанного с исполнением служебных обязанностей), а субъектам уделяем 3 абзаца в модели нарушителей. Мы ставим DLP и не знаем, что ответить на вопрос заказчика – а от фотографирования экрана защищает?

Не даром, ни одно внедрение СЗИ не может обойтись без оргмер. Зачем ломать сложный пароль, если можно подсмотреть?

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

 

P.S. Уже стал известен мой оппонент по полуфиналу Эльман Бейбутов из Solar. Мой прогноз: мне надерут задницу. Ведь в Solar работает больше 100 человек. Но я буду биться.

Хотите это видеть? Поставьте напоминалку.

У Камина: 38 попугаев

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

fireplace_main

И начнем мы со статьи «38 попугаев, или не все метрики одинаково полезны» Андрея Захарова, опубликованной на сайте Jet Info. Это корпоративный портал компании Инфорсистемы Джет. Выбрал я именно ее, так как тема измерений мне близка до глубины души. Начнем.

Оригинальный текст взят as is. Все права на оригинальный текст принадлежат их правообладателям.

 

38 попугаев, или не все метрики одинаково полезны

Сразу вопрос к названию: в оригинале было 38 попугаев и одно попугайское крылышко. Точность – добродетель любых измерений.

38_0

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

Да ладно. Можно списочек? И даже если так – вы решили добавить еще одну статью в эту «огромную кучу»?

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

Изменилось по сравнению с чем?

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

Вы в окно посмотрели? Или исследование проводили?

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

Специально в словарь заглянул. Самое ближайшее к данному определение:

   математический термин, обозначающий правило определения того или иного расстояния между любыми двумя точками (элементами) данного множества А.

Т.е. проблема в самом начале – в терминах. Метрика не функция, а «числовой показатель», который рассчитывается. А, вот, расчет может проводиться разными способами, в том числе и функцией. Зачем огород городить, вводя новые термины? Чем старые не угодили?

Для начала отметим, что практикуемые в компании методы управления ИБ значительно зависят от сложившегося в ней корпоративного управления.

Точно так. А почему множественное число? Автор у статьи один – Андрей Захаров. Или это коллективное мнение компании Джет? А вот от чего действительно зависит измерение ИБ – так это от уровня корпоративной зрелости.

Если принятие руководством управленческих решений основывается на качественном внутреннем анализе, то и спрос на Business Intelligence (BI) будет высок.

Оу-оу-оу. Мы вроде про безопасность тут, с чего BI ? Продукт плейсмент услуг компании Джет? :)

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

Что вы говорите. Надеюсь, дальше этот тезис будет раскрыт.

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

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

Что по этому поводу советуют эксперты?

По какому поводу? Вопрос-то не поставлен. Во всем тексте сверху нет ни одного знака вопроса.

Для ответа на этот вопрос обратимся к отраслевым стандартам. Пионер стандартизации в области информационной безопасности NIST выделяет 4 типа метрик: достижения целей, реализации (выполнения) процесса, результативности (эффективности) выполнения процесса и влияния на бизнес.

Рис. 1. Уровни зрелости метрик ИБ (по материалам NIST)

Рис. 1. Уровни зрелости метрик ИБ (по материалам NIST)

Руководящий документ NIST SP 800-55 Rev.1 был разработан почти 10 лет назад и до сих пор не потерял своей актуальности.

Пропущу шутку, почему статья не вышла 9-10 лет назад.

В нем хорошо отражена идея индикаторов: результативности (KPI), достижения цели (KGI) и риска (KRI).

Да, норм критерии. Немного избыточно, но ок.

Казалось бы, задача понятна, подходы хорошо известны,

А конкретней? Тут весь рынок ждет применения этих «известных подходов». Голословное утверждение.

однако практика показывает, что попытки самостоятельного внедрения системы метрик зачастую заканчиваются неудачей.

Ага, надо звать компанию Джет.

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

А почему об этом написано здесь, а не во введении, где вы говорили о «сложившемся типе корпоративного управления»? Но, правильно ли я понял, что Андрей утверждает, будто метрики «результативности (KPI), достижения цели (KGI) и риска (KRI)» применяются не на всех уровнях зрелости?

Поэтому совершенно бессмысленно конструировать, например, метрики эффективности, если оцениваемые процессы едва удалось документировать.

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

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

Как это, интересно, у них получилось?

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

Вот это поворот, сразу виден накал автоматизации. Опять продукт плейсмент? И какое это имеет отношение к теме статьи?

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

Не понятно, как вообще такое допустили? Если уровень ИБ высокий, значит там сидят не идиоты. Значит допустили идиоты, которые эту методику внедряли, а потом сразу автоматизировали, не проведя опытной эксплуатации.

И никакого вывода из примера. Печаль.

Начать с самого простого

Метрики достижения цели позволяют ответить на вопрос о том, были ли решены поставленные ИБ-задачи. Общие цели в области ИБ определены практически в каждой компании.

Не плохо бы пару примеров. Или Андрей считает, что за 10 лет с момента выхода этого NIST все с ним ознакомились?

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

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

*подавился чаем* В абзаце выше говорилось про решаемые ИБ-задачи, все это глобальные стратегические вещи. При чем тут оперативное управление? Или компания Джет считает, что метрика достижения цели – кинуть бумагу в шредер?

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

Следующий шаг

Метрики реализации являются следующей ступенькой системы измерения и служат для определения того, в какой мере внедрен конкретный процесс.

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

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

Да, но не обязательно. Можно покупать фиды у Касперского.

В том случае, если он выполняется только для 70 систем из 100, можно говорить о 70% его реализации.

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

Этот тип метрики является относительным

Относительным между чем и чем?

и требует наличия установленных пороговых значений,

Как могут быть пороговые значения, если выше говорилось о 100% внедрения процесса? Получается, надо строить еще целый процесс по установке пороговых значений.

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

Вообще метрики — для руководства.

Входим во вкус

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

Т.е. к чуть-чуть беременным процессам у нас добавились конкретные показатели этой беременности. Я всю жизнь думал, что мы идем от частного к общему. Кстати, ISO тоже так построено.

К примеру, одна из целей процесса повышения осведомленности пользователей в области ИБ состоит в минимизации числа инцидентов, связанных с использованием методов социальной инженерии.

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

Если в результате обучения пользователей в 8 случаях из 10 они не поддаются на провокационные письма и звонки злоумышленников, можно сказать, что показатель результативности процесса (для этой цели) составляет 80%.

Вообще, при таком выстроенным процессе должно быть 11 из 10. К тому же, надо еще строить процесс оценки, что же в эти 20% инцидентов может попасть. А вдруг там андеррайтер в банке.

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

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

Наконец, добрались. Странно, что метрики эффективности не были перечислены в общем пуле выше. Хотя интереснее учитывать не стоимость ресурсов, а критичность активов, не накрытых процессами с 70% реализацией.

Зачастую они являются производными от метрик результативности.

Производными – это значит вытекают из показателей результативности? Т.е. если нам надо измерить общую площадь дома, мы на него смотрим, говорим – 1000 кв. м. А потом идем внутрь с рулеткой и мерим?

Метрики эффективности могут высчитываться по формуле результативность/стоимость,

А могут и не высчитываться. Хорошо бы еще примеров. Интересен также физический смысл данной формулы – мы % делим на деньги. Фактически мы получаем аналог скорости: сколько денег нужно, чтобы увеличить результативность на 1%. И что от чего теперь производное?

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

Постичь дзен

Наконец, последний тип метрик – метрики влияния на бизнес.

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

Он является самым сложным с точки зрения наполнения. Эти метрики отвечают на вопрос, в какой степени результаты конкретных мер обеспечения ИБ влияют на показатели бизнес-деятельности.

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

Бизнес как раз не интересуют доходы, «связанные с рисками». Его просто доходы интересуют. И, понятно, чем выше риск – тем больше потенциальный доход, любой тренер на Форексе вам скажет. Что такое «риск-ориентированные метрики»?

Отношение показателя результативности (эффективности)

Андрей, так в прошлой части вы сказали, что результативность и эффективность не одно и то же. Как вы собираетесь «скорость» опять делить на деньги?

конкретной меры ИБ к величине ожидаемых потерь (ALE) по защищаемому активу или процессу неплохая бизнес-метрика,

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

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

Завидую вашей невозмутимости. А вообще, риски — это зачастую единственное, до чего могут безопасники дотянуться. Риски не требуют капитальных затрат в со an и железо.

Другой путь выбрать несколько бизнес-целей, очевидным образом зависящих от успехов (или неудач) в области ИБ, и создать метрики на их основе.

Если в компании есть ИТ и от нее как-то зависит бизнес, то все бизнес цели зависят в конечном итоге от ИБ.

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

Так стандарту 10 лет, и тема уже изжеванная ;)

Рис. 2. Основные причины отсутствия бизнес-ориентированных метрик ИБ в западных компаниях (по данным Ponemon Institute)

Рис. 2. Основные причины отсутствия бизнес-ориентированных метрик ИБ в западных компаниях (по данным Ponemon Institute)

Кстати, а почему слайд на английском? Дедлайн перед сдачей материала? Ну, и текст можно было бы сделать покрупнее.

Для решения этой сложной задачи можно воспользоваться концепцией системы сбалансированных показателей (Balanced Scorecards, BSC). На рис. 3 приведен пример бизнес-ориентированных метрик ИБ, вписанных в систему ценностных перспектив BSC.

Рис. 3. Пример бизнес-ориентированных метрик ИБ

Рис. 3. Пример бизнес-ориентированных метрик ИБ

Для статьи норм так критерии. Правда, резанула глаз фраза «доля проектов и процессов с участием ИБ».

Разминка для ума

Рассмотрим использование системы метрик измерения эффективности ИБ на простом примере. Предположим, мы задались целью приобрести автомобиль.

Ну, не совсем корректно. Сразу смешались цели и процесс. Автомобиль рано или поздно будет куплен, а ИБ никогда не заканчивается.

Попробуем сконструировать набор метрик, который поможет нам измерить успех этого мероприятия на всех его этапах.

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

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

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

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

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

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

В качестве заключения

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

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

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

 

 

Фух, вот и конец. Надеюсь, вам было интересно. Спасибо Андрею Зотову за интересный материал.

Я ставлю 4 полена из 5.

Увидимся, и всего вам доброго.

Итоги года и прогнозы на новый

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

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

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

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

Я, наконец, добрался делать собственный сайт. Попробовал быть блоггером, не пошло. В принципе формат меня устраивает – 1-2 поста в неделю, по часу на каждый. За это приходиться платить русским языком, но, думаю, вас это не сильно парит, иначе бы вы это не читали.

Я получил кучу подарков от друзей. И не смог выбрать самый лучший. У Кода Безопасности – самый богатый подгон, у C-Терры – самый уютный и ламповый, у Solar – самый оригинальный, у Intowatch – самый бодрящий. Спасибо всем, что не забываете.

Я вообще люблю Новый год. В это время все подводят итоги, которые крайне интересно читать. Когда выйдет топ от малваре, обязательно расскажу смешную историю с этим рейтингом. Также в это время все делают прогнозы. Из меня херовый прогнозист, все, что я говорю, чаще всего сбывается. Но это прогнозы на локальном масштабе. Это как разница между микроэкономикой и макроэкономикой. Последние ворочают какими-то бешеными показателями, геополитикой и глобальностью. Мне же понятен более простой уровень. Но это мало кому интересно, поэтому заделаю глобальный прогноз на рынок ИБ. 29 декабря 2016, посмотрим, что сбудется. :)

Прогноз на 2016 год по трендам информационной безопасности

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

Итоги года и прогнозы на новый (2016 не простой год)

  1. Аутсорсинг ИБ не взлетит в следующем году. Сорри, парни.
  2. Нас ждет 2 и более банкротств или серьезного обнищания среди крупных интеграторов и, как минимум, одного вендора.
  3. Будет еще одна волна сокращений. А если из кризиса выберемся к середине года, то и еще одна.
  4. ЗПД все также будет приносить денюжку. Стабильно, но не миллионы.
  5. Прорывами года станут таргетированные атаки (уже пора), АСУ ТП (уже почти) и SOC (поехали к первой станции). От наименее сильного к наиболее.
  6. Я сделаю еще десяток проектов, о которых буду рассказывать внукам.

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

Как м*даки убивают интеграторы по информационной безопасности

Скоро Новый год, время подведения итогов, время водораздела, время начинать все с начала. Для многих НГ является ключевой точкой. И сегодня у нас самая новогодняя тема – про собеседования, а еще вернее, как отличить хорошую компанию от плохой. Материал планировался как набор забавных историй из личной жизни. Увы, в нынешний кризис, с его веерными сокращениями — это может стать руководством к действию. Но начнем.

Как мудаки убивают интеграторы по информационной безопасности

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

Сам я работаю с 14 лет. Как-то я составлял перечень, кем работал (получал деньги), получилось:

  1. Курьер (3 года);
  2. Электро-монтер связи (3 месяца);
  3. Сисадмин (1 год);
  4. Бета-тестер игр (1 месяц);
  5. Разносчик газет (1 неделя);
  6. Уборщик/разнорабочий (полгода);
  7. Литературный негр (полгода);
  8. Офицер службы безопасности (2 года);
  9. Специалист (старший, ведущий) по ИБ (3 года);
  10. Преподаватель и лектор (2 года);
  11. Администратор/модератор форума (4 года);
  12. Начальник отдела консалтинга (1 год).
  13. Руководитель проектов по ИБ (5 лет).
  14. Антикризисный управляющий (8 месяцев).
  15. Бизнес-консультант (2 года).

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

Какое точно название документа?

Искал я как-то работу и забрел в интегратор Б. Захожу на собеседование, передо мной садятся двое, посмотрели резюме и спрашивают:

— Какие документы по ЗПД вы знаете?

— ФЗ, четверокнижие, РД.

— А назовите, как документы в четверокнижии называются.

— Полностью?

— Да.

— Иди нахуй (развернулся и ушел).

Мое знание наизусть названия документов не делает меня более лучшим или худшим специалистом. Когда мне потребуется — я полное название скопирую из Консультанта. Важно ведь понимание, правда? Если помните, еще совсем недавно на конференциях были люди, полностью проговаривающие названия ПП №687. Специалисту нет нужды помнить название, достаточно номера.

Или же чуваки набирают зубрил, которые знают лишь «учебник». Ну, они добились своего, через год они потеряли одного из крупнейших клиентов по безопасности и занимаются теперь ИТ-интеграцией. Сейчас у них 1,5 специалиста по ИБ.

В другой компании моего будущего коллегу гоняли как на экзамене по ГОСТ 34. И сделали офер на 20% ниже, т.к. он не твердо его знал. В той компании сейчас тоже все не очень хорошо.

Любимый вопрос HR

Интересный вопрос, нужен ли HR при собеседовании на вакансии по ИБ? Вообще, HR должен оценить кандидата с человеческой точки зрения, выяснить мотивацию и передать непосредственному руководителю свое мнение (на втором собеседовании, если кандидат прошел первичный отбор).

Был я в интеграторе М. Собеседовал меня вновь назначенный директор департамента и HR. HR прыгала от нетерпения, чтобы ей разрешили задать «ее любимый» технический вопрос. Вопрос заключался – назовите все уровни модели OSI (и улыбается). Опять какой-то зубрильный вопрос.

Я смотрю на нее и спрашиваю: — Вы мое резюме читали?

— Читала.

— У вас возникают сомнения, что я это сделал?

— Нет.

— Так вот, за 4 года работы модель OSI мне ни разу не пригодилась. Я знаю 4 основных уровня (называю), где работают основные средства защиты. Позвоните мне, если надумаете.

В этом году компания обанкротилась.

Как мудаки убивают интеграторы по информационной безопасности

Хитрые схемы мотивации

Ходил я в интегратор Е. на инженерную должность. Практически все обговорили, пошел финально говорить с генеральным директором.

— Сколько хочешь?

— 60 т.р.

— Давай так, мы тебе платим 40 + бонус в конце года, те же 60 выйдут. Это у нас мотивация такая.

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

Я лучше знаю

Был я в интеграторе Л. К тому моменту уже заделал рекомендации минздрава и сделал кучу всего в ЗПД. Прихожу на собеседование к техническому директору. Обсуждаем ЗПД и методы безопасности. Пересказал проделанную работу. Получил в лоб:

— Посмотрим, что на это скажет прокуратора?

— Прокуратора, конечно, глобальный регулятор, но при чем тут она?

— Все эти согласования — хуйня.

Лично я не хочу работать в догматичной компании, не готовой меняться. По слухам, этот интегратор закроется 31 декабря.

К чему это я?

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

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

Мне вот, например, регулярно звонили кадровые агентства:

— Здравствуйте, у нас есть должность в крупном интеграторе.

-Каком?

— Не могу сказать.

— Понимаю. Знаете, я рынок неплохо знаю. Я не буду работать в интеграторах А, Б, Ц и Я.

— Спасибо, до свидания.

Надеюсь, с вами подобного не случится. Всего вам доброго.

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

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

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

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

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

Про тренды в информационной безопасности: SOC, ЗПД и т.п.

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

Сразу жбахну картинку.

Количество проектов за последние 6 лет

Количество проектов за последние 6 лет

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

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

Предлагал я весь спектр интеграторских услуг, но в итоге получилось следующее:

Разбивка проектов по типам работы

Разбивка проектов по типам работы

Сейчас пишу и вспоминаю, что еще делал pen- test, внедрял DLP и еще всякое разное, но уж как получилось. Как видно, персональные данные как стали трендом в 2009 году, так и не отпускают пальму первенства.

Количество проектов по защите персональных данных

Количество проектов по защите персональных данных

А вот в процентах тренд виден более явно:

Количество проектов в процентах по защите персональных данных

Количество проектов в процентах по защите персональных данных

И последняя диаграмма: разбиение по отраслям:

Количество проектов по отраслям

Количество проектов по отраслям

Что в итоге?

1. Персональные данные все еще тренд. Спасибо 242-ФЗ.

2. SOCи набирают популярность (надо похвалиться – я приложил руку к одному из крупнейших SOCов в Восточной Европе). Но ввиду масштабности проектов это могут потянуть не все интеграторы.

3. Анализ рисков – тема, о которой все говорят, но мало кто хочет за нее платить. Во всяком случае в отрыве от других работ. А с другими работами — это, скорее всего, с персональными данными.

4. Количество проектов мало влияет на выполнение квоты (но об этом как-нибудь в другой раз). С 2011 по 2014 – личное выполнение плана.

5. В основном ЗПД заказывают или те, кого обязали (госы), или те, кто под прицелом (образование, медицина).

Я знаю, в среде многих известных блоггеров принято ругать защиту персональных данных. Но надо понимать, что это хлеб всего интеграторского бизнеса по информационной безопасности (да и у заказчиков). В 2008 году я ставил CheckPoint и XSpider и выступал с презентациями, как круто аттестоваться по ISO 27001.

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