Архив метки: информационная безопасность

Как прервать цепочку событий от угрозы до происшествия и обеспечить безопасность 24/7

Авторская версия

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

Если ответить отрицательно, то ваши потребности сразу потеряют актуальность на многие годы. Зачем давать деньги тем, кто не может ничего обеспечить 24/7? Берите пример с ИТ подразделений, у них все системы на пять девяток!

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

Куда не кинь, всюду клин. Давайте рассмотрим, как прервать цепочку реализации инцидента и приблизиться к заветным цифрам обеспечения безопасности 24/7. Для этого нам необходимо определиться с ключевыми элементами данной цепочки.

Активы

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

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

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

После ранжирования необходимо сделать отсечку, какие активы защищаем всеми силами, а какие «как получится». Например, все, что дороже 1 миллиона рублей, должно быть защищено.

Угрозы

Здесь и далее мы будем ставить знак равенства между угрозой и риском. Классическое определение риска гласит:

Риск (от лат. resecō — «отсекать», «сокращать» или др.-греч. ῥιζικόν — «опасность») — сочетание вероятности и последствий наступления неблагоприятных событий.

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

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

Зная наши активы, мы теперь можем составить карту угроз для каждого актива. Она может выглядеть, например, так:

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

  • финансовый интерес;
  • межличностные интересы;
  • доминантность.

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

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

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

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

Таким образом, мы точно узнаем цепочку событий от угрозы до инцидента:

Рисунок 1. Цепочка событий от угрозы до ущерба

Теперь давайте разберемся с тем, как ее прервать.

Обнаружение

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

Для обнаружения инцидентов необходимо выполнить ряд шагов:

  1. Заручиться поддержкой высшего руководства. Без осознания возможных потерь от ущерба и требуемых мер, все дальнейшие действия будут являться полумерами или будут полностью провалены. При общении с топ-менеджментом выгоднее всего опираться на финансовые показали (подробнее можно узнать в статье «Вопросы совокупной стоимости владения и эксплуатации комплексных систем безопасности» журнал «Системы безопасности», №1, 2021).
  2. Понимать, знать и закрепить нормальное (обычное) состояние актива. Если колеса должны лежать на складе, то в секции Е-21. Если база клиентов располагается в общей информационной сети, то доступ к ней должен иметь отдел продаж, бухгалтерия, ИТ-администраторы и безопасники.
  3. Принять меры физической защиты актива. Меры физической защиты должны завесить от ценности актива и угроз. Колеса можно положить в секцию Е-21 под замок, выдавать ключ под роспись и поставить видеонаблюдение.
  4. Принять организационные меры по защите актива. Должны быть приняты внутренние правила и регламенты по использованию актива, предоставлению доступа, списанию и уничтожению, и другим применимым действиям.
  5. Создать или дополнить штат службы безопасности необходимыми специалистами. Какие бы средства автоматизации вы не применяли, при недоборе в штатном расписании вы физически не сможете вовремя реагировать на инциденты.

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

  1. Штатное очное наблюдение. Если ваши ресурсы позволяют поставить возле каждого ценного актива охранника с пистолетом, то необходимо этим пользоваться. Или хотя бы разделить объект на контролируемые зоны и назначить ответственного за него.
  2. Использовать автоматизированные датчики контроля состояния актива и пространства вокруг него, в зависимости от его природы. Например, при обеспечении безопасности особенно ценных материальных активов можно хорошо себя показывает связка датчиков движения с видеонаблюдением или СКУДом. Для перемещаемых активов можно использовать RFID–метки, которые позволят не только быстро найти актив, но и следить за его перемещением.
  3. Использовать автоматизированные системы для наблюдения за контролируемыми зонами. Сюда относятся системы контроля пересечения периметра, видеонаблюдение, системы контроля доступа и т.п.
  4. Для информационных систем необходимы системы мониторинга и контроля пользователей. Сюда относятся средства защиты от несанкционированного доступа, системы защиты от утечек информации (DLP системы).
  5. Для объединения всех используемых методов крайне желательно создать ситуационные центр безопасности, куда будут подключены все системы обнаружения и безопасности. Это позволит штатному составу СБ работать с уже обработанной информацией, а не искать признаки инцидентов, тратя большое количество человеко-часов.

Предотвращение

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

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

Расследование

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

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

В заключение

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

Дудко Дмитрий для журнала «Системы безопасности» (№2, 2021).

По следам черного лебедя: о чем говорили ИБ-эксперты на конференции «Умные решения – умная страна»

Онлайн-конференция «Умные решения – умная страна: инновационные технологии для новой реальности», организатором которой выступила компания ЛАНИТ, была наполнена полезным и разнообразным контентом. Продолжаем делиться самым интересным (о выступлении всемирно известного футуролога Кьелла Нордстрема можно почитать здесь). 

Во второй день форума Technology Day прошла секция «Информационная безопасность», на которой руководители компаний и эксперты в области ИБ делились своим видением трендов, уже оказывающих или лишь начинающих оказывать свое влияние как на современный бизнес, так и на общественную жизнь в России. (Я тоже, кстати, рассказывал про оценку рисков информационной безопасности.) В этой статье я сделаю обзор выступлений на нашей секции. Важно отметить, что никакая статистика и анализ не уберегут от наступления событий, описанных Нассимом Талебом в его книге «Черный лебедь». Непредсказуемые события непрогнозируемых масштабов случаются, и 2020-й год стал наилучшим тому подтверждением.

Онлайн-платформа конференции. Приветственное слово модератора секции «Информационная безопасность» Андрея Голова

Уроки 2020 года


«Крайне нетипичным» дипломатично назвал в своем докладе 2020 год Андрей Голов, генеральный директор компании «Код Безопасности». Шаг за шагом он проследил цепочку изменений, вызванных к жизни пандемией коронавируса. «Удаленка» разрушила привычный периметр безопасности корпоративной инфраструктуры, породив новые модели потребления ИТ-сервисов и, как следствие, значительно изменив ландшафт киберугроз. К вышеперечисленному добавился макроэкономический идеальный шторм, каскад государственных локдаунов и разрыв цепочек поставок.

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

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

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

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


Самым, пожалуй, «богатым на новые тренды» стал доклад Алексея Лукацкого, бизнес-консультанта по вопросам безопасности Cisco. Алексей выделил семь основных тенденций, касающихся кибербезопасности как непосредственно, так и в преломлении бизнеса.

  • Усиливается регуляторная нагрузка на эксплуатантов информационных систем и ужесточение ответственности за нарушения.
  • Самой важной метрикой в информационной безопасности становится время обнаружения атаки, а отчеты службы ИБ включают все больше метрик, связанных с бизнес-целями предприятия.
  • Невозможность обеспечить абсолютную защиту от угроз смещает фокус внимания служб ИБ с предотвращения атак на своевременное обнаружение и реагирование на них.
  • Самым слабым звеном любой системы безопасности остается человек. Число атак, связанных с социальным инжинирингом, будет только расти.
  • Количество событий безопасности в сложной системе ИБ превысило физические возможности специалистов по реагированию на них.
  • Злоумышленники все чаще атакуют не своих жертв напрямую, а их поставщиков ПО и оборудования.
  • Растет важность «безопасной разработки», предъявляющей новые требования к создателям программного кода на всех этапах его производства.

Кибербезопасность в эпоху цифровой трансформации


Мир погружается в «цифру», а неопределенность растет. Растет и число кибератак, несущих угрозу новой реальности. Николай Фокин, руководитель отдела информационной безопасности компании «ЛАНИТ-Интеграция», напомнил о том, что кибератаки входят в ТОП-5 глобальных угроз наряду с изменением климата, эпидемиями и природными катастрофами. К 2022 году, по оценке ВЭФ, ущерб мировой экономики от киберпреступлений может достичь $8 трлн.

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

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

Вывод Николая не внушает оптимизма: 90% компаний по-прежнему могут быть взломаны за несколько дней, а 77% бизнесов не имеет четкого плана реагирования на киберинциденты. Помочь в этой ситуации может только тотальный пересмотр всех политик ИБ, ужесточение контроля за средствами удаленного доступа, внедрение технологий многофакторной авторизации и программ обучения персонала правилам «цифровой гигиены».

Проект «Безопасность детей ХМАО-Югры в сети Интернет»


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

Более половины родителей признаются, что используют гаджеты, чтобы занять ребенка. Девять из десяти родителей прибегают к электронным устройствам в процессе обучения своих детей в возрасте 3-6 лет. Сделать эти процессы максимально безопасными призван проект-финалист премии IT Stars имени Георгия Генса «Безопасность детей ХМАО-Югры в сети Интернет».

Ханты-Мансийский автономный округ стал площадкой для эксперимента не случайно. Многие родители здесь работают вахтовым методом и зачастую не в состоянии контролировать время, проведенное ребенком в интернете, или характер потребляемого им контента. Помочь им в этом был призван специальный продукт Kaspersky Safe Kids.

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

Защита от несанкционированного доступа к инфраструктуре бизнеса


С распространением цифровизации бизнеса среди всех инструментов анализа информационной защищенности корпоративной инфраструктуры пентест выходит на первый план. Мурад Мустафаев, руководитель службы информационной безопасности компании «Онланта», и Дмитрий Донской, директор по развитию группы компаний «Эшелон», рассказали о том, как инсценировка преднамеренного взлома помогает объективно определить уровень защищенности компании, и привели живой пример.


Главным выводом эксперимента стало четкое понимание необходимости мониторинга всех ИБ-событий в реальном времени. Наилучшим способом добиться этого на сегодняшний день является использование SIEM-систем. Неудивительно, что подобным инструментам  уделено большое внимание в федеральном законе N 187-ФЗ, посвященном требованиям к защите критической информационной инфраструктуры.

Безопасность виртуальной облачной сети предприятия


Доклад Дмитрия Жечкова, менеджера по развитию бизнеса сетевой виртуализации и безопасности VMware в РФ и СНГ, был посвящен новым подходам к обеспечению информационной безопасности в условиях «новой нормальности». Параллельно с трендом цифровизации бизнеса и массовым переходом на удаленную работу сформировалось три основных потенциально уязвимых области в ИТ-инфраструктуре любого предприятия:

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

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


VMware уже пошла по этому пути, предлагая создавать безопасные цифровые экосистемы предприятий, основанные на решениях Workspace ONE, Carbon Black, NSX и CloudHealth.

Экономическая оценка рисков информационной безопасности


А теперь немного о моем выступлении. Я работаю руководителем отдела департамента информационной безопасности ЛАНИТ. Более восьми лет наша компания занимается консалтингом в сфере оценки рисков как информационной безопасности, так и более широких, связанных с функционированием бизнеса в целом. Созданная за это время карта рисков включает в себя 152 показателя, сведенные в девять групп:

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

Анализ более 3 тыс. инцидентов позволил нашей команде вывести общие закономерности, помогающие понять, какой экономический ущерб могут нанести те или иные нежелательные события. Так, к примеру, опыт ЛАНИТ показывает, что ущерб от инцидентов, связанных с нарушением или блокировкой деятельности бизнеса в результате хакерской атаки для компаний среднего размера, как правило, находится в диапазоне 0,5-10% годового оборота. Ущерб от кражи конфиденциальной информации может достигать 100% годового оборота. Причем чем меньше компания, тем уровень ущерба выше.


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

Видеозаписи докладов, а также презентации спикеров конференции «Умные решения — умная страна: Инновационные технологии для новой реальности», организованной компанией ЛАНИТ, доступны до 1 февраля 2021 года на платформе мероприятия. Вам понадобится заполнить простую форму для регистрации и в разделе «Библиотека IT-знаний» выбрать интересующий материал.

P.S. Оригинал записи

Проблемы внедрения ИБ в больших организациях

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

Источник

Характеристика объекта внедрения

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

На заводе работают порядка 16 000 человек на 5600 автоматизированных рабочих местах (АРМах). Инфраструктура расположена в двух ЦОДах плюс в мобильном ЦОДе. Итого 119 объектов/отделов на 15 площадках.

Состав внедряемых подсистем:

  • СЗИ от НСД плюс централизованное управление;
  • платы СДЗ плюс централизованное управление;
  • межсетевые экраны;
  • VPN-шлюзы;
  • система обнаружения вторжений;
  • анализ защищенности;
  • USB-токены;
  • SIEM-система;
  • антивирусная защита.

Вендоров называть не буду, чтобы не сочли за рекламу. Лучше расскажу про сроки. Начало работ — 15 июля 2019 года, окончание — 27 декабря 2019 года.

Специфика ИБ-внедрений

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

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

В рамках данного проекта мы должны были выполнить (сокращенный перечень):

  • постановление Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»;
  • приказ ФСТЭК России от 11.02.2013 № 17 «Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»;
  • приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»;
  • приказ ФСТЭК России от 28.02.2017 № 31 «Об утверждении Требований к обеспечению защиты информации, содержащейся в информационных системах управления производством, используемых организациями оборонно-промышленного комплекса»;
  • приказ ФСТЭК России от 29.05.2009 № 191 «Об утверждении Положения по защите информации при использовании оборудования с числовым программным управлением, предназначенного для обработки информации ограниченного доступа, не содержащей сведений, составляющих государственную тайну»;
  • приказ ФСБ России от 10.07.2014 № 378 «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности».

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

  • Система защиты должна была быть аттестована, а потом проверена регуляторами, что очевидным образом максимально повышает приоритет задаче: неукоснительное выполнение требований.
  • Требования прописаны в государственном контракте, и несмотря на то, что в данном списке есть неприменимые к заводу нормативно-правовые акты (НПА), их требования необходимо выполнять. 
  • Некоторые НПА предъявляют разные требования к одним и тем же элементам, а следовательно реализовывать их надо будет все. Т.е., если один НПА предъявляет минимальные требования, а другой – повышенные, реализовывать надо будет по максимуму.
  • В информационной безопасности, к сожалению, небольшой перечень решений, которые можно было бы применить. Так что если средство защиты не подходит к конкретной ИТ-архитектуре, то заменить его очень сложно, тем более в рамках четкого ТЗ по 44-ФЗ.
  • При отсутствии технической возможности выполнения требований, можно применить организационные мероприятия. Но это потребует огромного количества согласований и может растянуться на годы в такой огромной организации, как военный завод. А срок исполнения проекта ограничен.

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

  1. Четкие этапы внедрения новых мер.
  2. Сроки данных этапов.
  3. Ответственных за выполнение плана.
  4. Обязательное обучение сотрудников и ответственных.
  5. Быть принятым на уровне организации.

Источник

Чужой проект

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

Это породило две проблемы – в проекте была чужая спецификация, и сроки уже начали поджимать.

Чужая спецификация

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

Проблема крылась в другом: за строчкой в спецификации – 5600 СДЗ —  может скрываться внедрение на одной площадке, а может и по всей области (в итоге площадок оказалось 15). В данной строке не виден парк конечных станций, их распределение и готовность к внедрению.

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

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

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

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

Время внедрения

В связи с отказом от выполнения работ предыдущего поставщика сильно сократился срок внедрения. Первоначально планировалось все реализовать за 12 месяцев, но т.к. пришлось организовывать конкурс, его отыгрывать, проводить пресейльные мероприятия, согласовать и организовать подписание договора по 44-ФЗ с казначейским сопровождением, в чистом остатке на внедрение у нас оставалось менее 6 месяцев.

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

В идеале, это занимает 15 минут. При планировании же мы ориентировались на час работы. Итого 5600 трудо-часов. Применив нехитрые статистические методы, стало ясно, что на эту работу потребуется минимум 10 человек. Собственно, на этом работу можно было бы и закончить. Ни один интегратор в здравом уме не отправил бы 10 инженеров в командировку из Москвы на 3 месяца крутить компьютеры. Во-первых, это очень дорого и накладно, а, во-вторых, это верный способ этих инженеров потерять.

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

15 июля 2019 года ГИП, руководитель проекта, три аналитика и три инженера из Москвы, 15 студентов-стажеров, руководитель ресурсного центра, его заместитель, бригадир стажеров и два представителя вендоров зашли на завод, чтобы начать работу.

Сложности согласования

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

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

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

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

Источник

Сложности коммуникации

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

По всем ключевым вопросам общение делилось на три стадии.

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

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

Способов закрепления договоренностей немного (в порядке убывания).

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

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

А на сегодня все, до новых встреч.

P.S. Оригинал статьи.

Инвентаризация рисков ИБ: нормативные, методические и практические аспекты

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

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

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

Можно украсть персональные данные сотрудников и клиентов – их можно продать или оформить множество потребительских кредитов.

Можно получить доступ к банк-клиенту.

Можно воровать вычислительные мощности на ваших серверах, например, чтобы майнить биткоины, разместить там свой сервер или просто рассылать спам.

Можно просто воровать ваш интернет.

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

Заранее посчитанные риски

Классическое определение риска гласит:

Риск (от лат. resecō — «отсекать», «сокращать» или др.-греч. ῥιζικόν — «опасность») — сочетание вероятности и последствий наступления неблагоприятных событий.

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

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

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

Или еще пример: известный расчет риска гибели в процессе авиапутешествия. Вероятность того, что пассажир, севший в самолет, погибнет в авиакатастрофе, составляет примерно 1/8 000 000. Таким образом, если пассажир будет садиться каждый день на случайный рейс, ему понадобится 21 000 лет, чтобы погибнуть.

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

Инвентаризация рисков

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

Идентификация рисков – это процесс (бесконечный процесс) определения факторов, событий, ситуаций, которые могут нанести ущерб.

Для успешной идентификации риска достаточно ответить на три простых вопроса:

  1. Какой будет ущерб?
  2. Какое событие/действие должно произойти, чтобы мы понесли ущерб?
  3. В отношении какого объекта должно произойти событие, чтобы мы понесли ущерб?

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

Объект риска

Объектом ущерба может выступать:

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

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

Действие риска

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

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

  1. Нарушение конфиденциальности – мы получаем ущерб от того, что что-то стало известно. Например, наша секретная формула стала известна конкурентам.
  2. Нарушение целостности – мы получаем ущерб от того, что наши данные неполны и/или изменены. Например, компьютерный вирус поменял все 0 на 9 в бухгалтерском отчете, что на один порядок увеличило налоговые выплаты.
  3. Нарушение доступности – мы получаем ущерб от того, что в определенный момент не получили доступ к нужной информации или услуге. Например, у нас не было доступа в интернет, чтобы выиграть очень важный аукцион, или мы вовремя не ответили на запрос контролирующих органов, потому что у нас свет отключили.

Источник действия – нарушитель

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

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

  • финансовый интерес;
  • межличностные интересы;
  • доминантность.

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

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

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

Теперь вы можете записать каждый риск примерно в таком виде:

Объект воздействия Нарушитель Действие Ущерб
1 Ноу-хау компании Сотрудники Кража Средний
2 Ноу-хау компании Конкуренты Кража Катастрофический
3 директор по ИТ и ИБ Техногенные факторы Пропажа информации с телефона владельца Катастрофический

Ущерб от риска

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

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

Методы инвентаризации рисков

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

Во многих отраслях и направлениях уже сформированы базы рисков, которые могут быть отнесены к тем или иным объектам. Например, в информационной безопасности можно воспользоваться Банком данных угроз безопасности информации ФСТЭК России. Каждый риск (угроза) имеет описание: объект, источник угрозы (нарушитель), описание (действие), последствия реализации угрозы (ущерб).

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

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

Второе множество методов идентификации рисков я называю «рабоче-крестьянскими» – они являются родственными методам «что если?» (самым ярким представителем которых является методология SWIFT). Данные методы требуют больше времени для определения рисков, но лишены недостатков стандартизированных методов, т.к. учитывают особенности конкретного объекта.

Заключение

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

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

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

3 декабря 2018 года, для журнала Connect WIT 2018 № 11-12

Как сделать стандарт за 10 дней. Часть вторая. Скучная

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

Слишком долгое вступление в тему

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

Шел 2008 год – лето, пятница. Я отпросился пораньше с работы, чтобы не стоять в пробках, и ехал на дачу по Дмитровскому шоссе в районе Яхромы. Было довольно плотненько, но терпимо. Меня останавливает инспектор ГИБДД, просит документы и заявляет, что я не пропустил пешехода. Я с ним не соглашаюсь.


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

Протокол? Какой протокол?

На суде выяснилось, что я подписал не протокол, а постановление.

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

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

Документы для информационной безопасности

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

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

Западная школа

Западная школа довольно свободно относится к названиям и содержанию документов. Самым ярким доказательством является серия стандартов – ISO 2700x, которую знает каждый безопасник.


В общем случае вся документация делится на четыре уровня.

  • Политики первого уровня – наиболее «водянистые» и «стратегические». Например, «Политика информационной безопасности ООО «Ромашка».
  • Политики второго уровня – конкретизируют определённые аспекты глобальной политики или конкретные процедуры. Например, «Политика антивирусной защиты».
  • Инструкции (третий уровень) – описывают конкретные обязанности сотрудников в рамках политики 2 уровня, например, «Инструкция системного администратора по антивирусной защите сегмента КСПД».
  • Записи (четвертый уровень) – все то, что не вошло в предыдущие три уровня. От настроек на конкретном сегменте до разбора инцидентов SIEM-системы.

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

Обратимся же к отечественному опыту.

Отечественная школа

Имея такую впечатляющую историю и опыт поколений в разработке конструкторской документации (ЕСКД), было бы удивительно, если бы у нас не сложились свои традиции и понимание оформления документов. Если внимательно посмотреть тот же ГОСТ 34 серии, то можно с удивлением узнать, что он вполне логичен и даже удобен. Разве перед внедрением любой системы вы не разрабатываете верхнеуровневую структуру (эскизный проект), уточняя его все детальнее и детальнее (технический проект и рабочая документация)?

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

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

  1. Политика информационной безопасности,
  2. Регламент информационной безопасности,
  3. Положение об информационной безопасности?

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

Как вы лодку назовете, так она и поплывет

Остановимся на основных документах (если будем рассматривать все – это будет совсем нудно и неинтересно). Описанный ниже подход является основным в работе Департамента информационной безопасности в одном из подразделений ЛАНИТ.
 

Приказ

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

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

Основными отличительными чертами Приказа являются следующие:

  1. Вводится в действие генеральным директором, именно он имеет право распространять те или иные требования на всю организацию.
  2. Наличие команды. Например, внедрить политику информационной безопасности.
  3. Назначение ответственного. В приказе должен быть указан ответственный за выполнение сути приказа, например, в случае политики – директор по ИБ.
  4. Наличие сроков. Тут все очевидно. Например, доведение до сведения всех сотрудников Политики ИБ в течение 2-х дней.
  5. Наличие контролирующего. Эту часть часто забывают, но крайне желательно указать, за кем закрепляется контроль над исполнением сути приказа. Обычно он либо остается у генерального директора, либо передается ответственному.

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

Политика

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

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

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

Положение

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

Т.е. фактически Положение очень редко применяется к процессам, но будет весьма уместно в виде «Положение о Департаменте информационной безопасности».

Регламент

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

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

Инструкция

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

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

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

О том, как безопасники низвергли себя в пучину забвения

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

Многие евангелисты нашей отрасли любят сравнивать нас с западом. Говорят, все там лучше, давайте сдадим кучу тестов по американской нормативке, и называться вы будете CISO. Это так модно и звучит круто. У нас даже конференции появились (CISO FORUM), и всеми это воспринято как данность. Но давайте взглянем немного вглубь, к истокам.

Если обратиться к зарубежной экономической литературе, то можно там часто увидеть аббревиатуры: CEO, COO, CFO. Крутые слова, звучащие в точности по ТБС. Немного не понятно, то ли дело милые для нашего слуха: генеральный директор, главный инженер, главный бухгалтер, зав. складом. Но нас сделали падкими все «иностранческое», поэтому все эти CEO, CIO, CTO, CKO и т.д. активно стали распространятся. Они везде – в статьях, на визитках, конференциях. Ты кто? Я CEO клининговой компании. Матерь божья, ты бригадир! Не стесняйся этого!

Но пойдем дальше. В начале необходимо понять, что нельзя переносить эту организационную иерархию в нашу бизнес-среду. Вернее, некорректно проводить параллели и говорить CEO — это генеральный директор. Тем более, абсурдно расшифровывается аббревиатура CIO, как директор IT, начальник IT. Причем, не всегда корректно проводить параллели не только между CEO и генеральным директором, но и CEO американской и английской компании (там можно встретить Managing Director), не говоря уже о Европейских компаниях. Остановимся на американской терминологии.

Сразу хочется сказать, что строгих правил по поводу того, как кого называть «ТАМ» нет. Вы можете как угодно назвать себя и своих подчиненных. Этим американцы близки к нам. Но если они близки нам, так в чем же основное, «критическое» отличие, не позволяющее проводить параллели. Давайте кратко пройдемся.

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

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

«Если Ваш бухгалтер платит все налоги, то пусть получает зарплату в налоговой»

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

В то время как информация и человеческий капитал на Западе стали действительно основным бизнес-преимуществом, у нас эти понятия стали только объектом пристального внимания авторов статей. Как перевести Chief Knowledge Officer (CKO)? Причем проблема не в переводе, а в адаптации и понимании. Как бы вы его не перевели, этой должности не всегда есть место на наших предприятиях. А если и найти, то результат от деятельности это человека (отдела) вряд ли принесет ощутимые плоды.

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

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

Board of Directors — совет директоров, избираемый акционерами. Это контур управления компанией акционерами.

Chairman of the Board — Председатель совета директоров, избираемый из числа совета.

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

Данный уровень управления называется С-level, поскольку все названия должностей начинаются «Chief», то есть главный.

CEO (Chief Executive Officer) – должность, назначаемая советом директоров (если компания public companies). CEO может быть как приглашенным со «стороны», так и быть избранным из числа сотрудников компании. CEO осуществляет полное управление компанией и несет полную ответственность. Если компанию уличат в незаконных действиях — «сядет» именно CEO. CEO может быть по совместительству как председателем совета директоров, так и Президентом. Совмещение всех трех должностей говорит о неограниченной власти руководителя.

CFO (Chief Financial Officer) — должностное лицо, ответственное за финансы корпорации. Как правило, находится в подчинении CEO. Не редкость, когда CFO выбирается из числа совета директоров. Может называться как Treasurer (казначей) или Finance Director.

COO (Chief Operating Officer) — должностное лицо ответственное за текущую деятельность предприятия. Инструменты оперативного менеджмента полностью находятся в распоряжении COO.

CIO (Chief Information Officer) — это корпоративный чиновник высшего уровня, ответственный за информацию. (Трактовка CIO как IT директора – это нонсенс. Если у Вас сломался компьютер, то обращаться к CIO вы можете с таким же успехом, как и к главному бухгалтеру). CIO находится в подчинении CFO или CEO. В западной иерархии CIO близок CKO. Это вызвано тем, что роль информации в последнее время становится главенствующей. Привет нам всем, мы уже 20 лет бьемся, чтобы это донести.

CTO (Chief Technical or Technology Officer) — роль данной должности меняется от специфики работы компании. В технологичных компаниях может подчиняться непосредственно CEO, в нетехнологичных подчиняется CIO. В компьютерных компаниях может быть представлен в лице CIO.

CKO (Сhief Knowledge Officer) — топ-менеджер, ответственный за максимизацию ценности компании, достигаемой через знания. Ответственный за нематериальные активы (ноу-хау, патенты). Все, что связано с интеллектуальным капиталом, находится в поле управления CKO.

Роль остальных понятна из их названия, поэтому просто расшифруем аббревиатуры:

  • CMO (Chief Marketing Officer)
  • CAO (Chief Analytics Officer)
  • CCO (Chief Communications Officer)
  • CDO (Chief Data Officer)
  • CNO (Chief Networking Officer)
  • CPO (Chief Process Officer)
  • CSO (Chief Security Officer)
  • CSO (Chief Strategy Officer)
  • CRO (Chief Risk Officer)
  • CCO (Chief Credit Officer)
  • CLO (Chief Legal Officer)

Как видим, никаких CISO тут нет. CISO – это менеджер следующей ступени, после С-level. Зачастую CISO подчинен CIO, что однозначно говорит о том, как «ТАМ» видят решение вопроса, кому должен подчиняться отдел ИБ. При чем это довольно незначительная часть, занимающаяся безопасностью информации, обрабатываемой автоматизированным способом. Небольшой отдельчик, обновляющий антивирусы. Что уж говорить – «как вы лодку назовете, так она и поплывет».

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

https://whatis.techtarget.com/reference/Roles-and-responsibilities-guide-What-does-a-CIO-do

В заключение хотелось бы сказать, что не надо слепо и бездумно копировать запад. В нашей современной среде безопасник находится на грани сфер CIO, CRO, CSO и CLO. А пока мы загоняем себя в рамки чуждой терминологии, мы все дальше будем от понимания нас бизнесом. Все вам хорошего.

От форума к видео – путь графомана

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

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

Форумы

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

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

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

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

Личный анонимный блог

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

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

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

В прошлом году после 15 лет работы я закрыл свой анонимный блог.

Профессиональные статьи на заказ

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

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

Если чувствуете в себе силы, можете попробовать.

Литературное негритянство

Если в статьях на заказ вы пишете на заданную тему, то, став литературным негром, вы еще и будете получать за это деньги. Литературный негр пишет под именем другого автора, заказчика работ. Обычно это внушительные по объему материалы, в моем случае это была книга по экономическому анализу (120 страниц А4)

Обычно данное явление распространено в сфере журналистики и других сферах, связанных со словом. В нашей ИТ сфере с этим все несколько хуже. Где и как вы найдете заказчика — тайна великая есть. Сам я на это подписался совершенно случайно, услышав разговор в коридоре. Денег тогда платили нормально – 2,5 моих зарплаты. Как сейчас с этим — не знаю.

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

Занятие на ваш выбор.

Корпоративное обучение

В определенный момент вас могут выдвинуть на проведение очных обучений ваших заказчиков. Вы что-то создали, и теперь должны обучить пользователей это использовать. Надо сказать, что штука это довольно обременительная, т.к. зачастую обучение происходит среди людей, далеких от ИТ и ИБ. Первым моим опытом было обучение всех школ Москвы основам защиты персональных данных. Тогда я объездил все округи, где в зале собиралось по 200-300 человек, где должен был рассказать, что теперь им работать придется больше, а платить им будут столько же. Один раз меня чуть не побили в СВАО.

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

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

Корпоративные выступления на конференциях

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

Каждому выступающему в самом начале надо решить следующие задачи:

  • Интересная тема (хотя бы не банальная);
  • Слайды. Это является отдельным искусством, о котором можно говорить долго и увлеченно.
  • Текст выступления. Его необходимо знать хотя бы в общих чертах, чтобы не читать без бумажки.
  • Тайминг. Неприятный факт, что можно и не успеть в отведенные 10-15 минут донести необходимую мысль, или наоборот быстро отстреляться и оставшееся время ждать вопросы от аудитории.
  • Внешний вид. Публичные выступления довольно требовательны к внешнему виду, хотя сейчас наметилась тенденция к упрощению, можно читать хоть в толстовке.

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

Интервью конференции

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

Здесь было все ужасно. Адреналин бьет через край, парализуя мозг. Через 5 лет все случилось ненамного лучше.

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

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

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

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

Эксперту тоже не сахар. Новости может быть 2 часа жизни, а вы уже должны мало того, что знать суть, так еще и охватить смежные области, часто сделать прогноз, и все это за 30-40 минут, т.к. материал пора публиковать. И, разумеется, желательно, чтобы ваше мнение было еще оригинальным. Один раз я 30 минут сидел в машине в Пушкино, написывая через смс свое крайне «компетентное мнение».

Выглядит это примерно вот так.

А еще бывает такая крутая штука, как «эксперт, решивший остаться неизвестным». Это когда мнение необходимо, но персонализировать его по каким-либо причинам нельзя. По самым горячим темам 2014-16 годов можно найти самые неожиданные мнения, особенно, если знать, кто «пожелал остаться неизвестным».

Профессиональные статьи со свободной темой

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

Если вы достигли этой точки – поздравляю, я до нее пока не добрался.

Личные выступления на конференциях

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

Личный профессиональный блог

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

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

Личный полу-профессиональный блог

Я поставил полу-профессиональный блог выше профессионального из-за более широкой сферы тем. Именно поэтому я перевел свой блог с прямых рельс информационной безопасности на более общие темы.

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

Если не боитесь, то это лучший из вариантов для удовлетворения своих потребностей в графоманстве.

Аудио-подкасты

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

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

Крутой формат, всегда с удовольствием участвовал, но проблема использования стоит во все поля.

Теледебаты

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

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

Новости

Прохождение всех предыдущих стадий у меня заняло 19 лет, с момента первых форумов и блогов. И вдруг каким-то чудом меня утвердили читать корпоративные новости. Приятная неожиданность быстро сменилась легкой тревогой на подготовке – новости надо было заучить. Это не рифмованные стихи, это пресс-релизы, а слово «гиперконвергентной» я теперь могу выговорить без запинки (и, надо сказать, записали мы эту новость быстрее всех).

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

https://www.facebook.com/LANIT.life/videos/1121716011342443/

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

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

А на сегодня все. До новых встреч.

Как кидали Страховую компанию

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

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

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

И потребовалось маленькой страховой компании приобрести антивирус. У нее уже был богоподобный Касперский, и все было хорошо, но внутренние регламенты предписывали наличие альтернативного антивируса. Причем строго конкретного.

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

И разверзлась благодать для вендора, была объявлена конкурсная процедура, и были собраны три предложения, и… А дальше неувязочка вышла.

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

У нашего вендора разбивка по ценам была до 50 штук (размер вымышлен), а на все, что больше 51 лицензии, надо было запрашивать цену. Из запрошенных цен получалось (цены с потолка, главное принцип):

  • 1 лицензия – 3000 рублей.
  • Если брать 50 штук, то 1 – 1000 рублей

Но нашей маленькой страховой компании требовалось 120 лицензий, и тут цена лицензии составила… 3000 рублей за штуку.

Что, почему? Маленькая страховая компания смотрела на калькулятор, на бумажке столбиком перепроверила, не могла она понять, почему при покупке 50 лицензий она заплатит 50 т.р., а при покупке 120 в три раза больше.

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

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

Такая история.

А где пруфы, Билли? Нам нужны пруфы

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

Думаете, я преувеличиваю? Давай рассмотрим свежий пример из нашей иб. Как вы знаете, главный эксперт отрасли – Алексей Лукацкий. Алексей человек широких взглядов и интересов. Особое внимание Алексей уделяет взаимоотношениям бизнеса и безопасников. О чем и пишет, в его понимании. Для иллюстрации своих тезисов Алексей рассказывает истории. Вот свежая.

SOC бесполезен, если он не может увязывать технические и бизнес-показатели

(оригинал)

…дзынь-дзынь-дзынь
— (Блин, ну кого еще в субботу в такую рань принесло? Почему я забыл включить «Не беспокоить» на телефоне?..)
— Да!
— Привет, Сергей! Это Иванов.
— Доброе утро, Степан Петрович! Что-то случилось?
— Да, случилось, Сергей! Вчера поздно закончился совет директоров. Мы стали получать меньше денег! Явно негативная динамика за последнюю неделю.

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

— Это плохо. А причем тут я? Я же отвечаю за кибербезопасность!

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

— У нас не работают системы!

Если знают что не работает, или из-за чего – живые люди так и говорят.

— А причем тут я-то? Это надо обсуждать с департаментом продаж или, на крайний случай, с айтишниками. Зачем ты звонишь мне?

Алексей, вы в своем же тексте нарушили иерархию разговора. Если в начале это Степан Петрович, то почему здесь «ты»? Почему в начале тогда не было «херли ты с утра звонишь? Что случилось?»

— Нет, ты не понял. У нас не работают системы и это из-за тебя; то есть твоих бойцов!
— Не может такого быть. Но давай я проверю и перезвоню через 15 минут!

…прошло 15 минут

— Степан Петрович, это Сергей! Я дернул дежурную смена нашего SOCа — у них все зеленое. Все индикаторы в норме и так уже недели две. Это не может быть из-за нас.

Так все-таки Степан Петрович. Все признаки того, что история выдумана. Впрочем, ничего плохого в этом нет, мысленные эксперименты нужный инструмент.

— Хорошо, Сергей. Давай в понедельник часиков в 7 приходи — будем разбираться!..

— Хорошо, Степан Петрович! Буду в 7 утра в понедельник. Хороших выходных.

…ту-ту-ту-ту…

Блин, ты уже в субботу позвонил. Если дело срочное и компания работает 24/7 (есть дежурные смены), почему всех не дернули в выходной на работу? Судя по всему, Степан Петрович тоже кому-то отчитывается, и его назначили главным по разбору ситуации. И это он должен в 9 утра отчитаться о причинах и принятых мерах. Поэтому Сергей сейчас поднимает свою пятую точку и весь свой отдел и мчит на работу, чтобы Степан Петрович владел всей информацией в понедельник утром.

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

Т.е. Степан Петрович генеральный директор… Сергей на него компромат что ли имеет или родственник, что он ему тыкает?

Проверки всех ключевых показателей ничего не дали — доступность торговой Интернет-площадки была в пределах допустимого — 99,9%. Число мошеннических транзакций нулевое. Угроз e-mail тоже было немного — 0,02% и все были отбиты на шлюзе. IPS, NGFW, анализ Netflow, контроль доступа… Все в зеленых зонах. Что же случилось?..

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

— (А может это Миша, наш дорогой CIO, решил поквитаться за прошлый раз, когда я обвинил его в том, что вся сеть легла из-за него, а не из-за накрывшей нас эпидемии вредоноса? А может  это Васильна взхъелась из-за того, что мы ей перекрыли доступа на сайт знакомств? Ну а фигли, хоть и финдир, а надо соблюдать политики. С чего они вообще решили, что это мы виноваты и почему SOC за сотни миллионов рублей ничего не видит?)

Потому что надо было его покупать у Cisco?

…прошло два дня…
В понедельник к обеду выяснилось следующее:

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

Вот это поворот. Т.е. основной бизнес компании происходит в интернете. Ключевая площадка хостится в компании (ни резервной площадки, ни балансировки нагрузки). Чем же можно заниматься, что на твоей торговой площадке могут за одну сделку сделать 27% дохода? Наверно, ты что-то продаешь. А т.к. ты тратишь «сотни миллионов» на SOC, продаешь ты через электронную площадку много и товар твой нужный.

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

Система защиты e-mail посчитала за спам рассылки маркетингового департамента и клиенты перестали получать предложения с последующим снижением покупательской реакции. 12 тысяч сообщений «выброшено в пропасть» — покупательская активность снизилась.

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

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

Ну, и мерить покупательскую активность по почтовым рассылкам – это верх бизнес-показателей. Алексей, вы сами-то рассылки читаете от многочисленных банков, клиник и магазинов, что вам валятся в ящик? Там конвертируемость ниже 1%.

Антифрод не увидел ни одной мошеннической транзакции. Да и откуда? Стоящий на периметре WAF отсек 3% клиентов, даже не дав им разместить заказ.

Чего? Т.е. если WAF отсек, то инциденты должны быть на нем. Опять же вопрос – как принимали систему? Почему отсек? Что это за бизнес, где одна сделка приносит 27% дохода, бегают физики с заказами и соки на миллионы? Интернет-магазин? Не похоже.

Понятно, что Алексей хотел проиллюстрировать как можно больше средств защиты, но получился конь в вакууме. Почему не написано, в чем была аномалия входа этих 3%?

Последней каплей стало внедрение скрипта, который высвечивал перед каждым посетителем сайта уведомление с прокруткой о необходимости получения согласия на обработку персональных данных в соответствие с ФЗ-152 и GDPR, с полным разъяснением всех последствий от осознанного принятия клиентом всех условий предоставления ПДн компании. Анализ показал, что время, за которое клиент теперь стал доходить до процесса заказа увеличилось на 47 секунд, что привело к оттоку еще 11% покупателей.

Рукалицо. Алексей, какие 47 секунд? Моя бабушка, освоившая социальные сети, кликает на галочку секунд за 15. Если у нас GDPR, то мы в тренде со всем интернетом, которые тоже добавили подобную информацию. Получается, что пользователи, зайдя на сайт, уже привыкли к этому в других местах и просто не читают.

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

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

Прискорбно то, что Алексей делает это постоянно. Началось все с «зарабатывающего 10 млн долларов любителя порно», где не хватало самой малости – конкретики.

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

Реальную историю от вымысла отличает ряд вещей (если мы не можем назвать ФИО, должность, организацию):

  1. Очертить сферу применения. В фантазии Алексея выше не понятно, что это за бизнес. Понамешано все в кучу. То, что актуально для ритейла, неактуально для телекома.
  2. Очертить взаимодействующие стороны. Что Степан Петрович генеральный директор, мы узнали под конец. А почему мы подставили какого-то Мишу, мы так и не узнаем.
  3. Очертить проблему. «Получаем меньше денег» — это не проблема, как бы Алексею не хотелось. Это следствие (кстати, очень полезно различать, если вы хотите говорить с бизнесом). А вот причины этого могут быть всякие разные. У нас могла банально дебиторка вырасти, просто задерживают оплату. И еще миллион причин.
  4. Описать последствия. Ну, тут все понятно.
  5. Описать решение (по желанию).
  6. Уж точно надо указывать подсистемы, которые не справились.
  7. Можно указывать вендоров и конкретные решения, которые справились.

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

А на сегодня все, до новых встреч.

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

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

Источник

Месяц до дня Х

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

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

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

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

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

Источник

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

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

Забегая немного вперед, отвага заключалась в атаке «с шашками на танки» силами одного специалиста на такую масштабную работу. Уже значительно позже я делал похожие работы, возглавляя различные по численности группы (от 2 до 6 человек). И если уж говорить об оптимальной численности команды, то оптимальное количество людей 1-2 человека, не считая привлекаемых специалистов, вроде технических писателей. 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.

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

P.S.S.S.

Вторая часть