Комментарии 4
Я по работе иногда бываю в разных промышленных цехах, куда мы ставим оборудование и вижу множество "плейбуков", обычно их вешают возле систем - как правильно включить, выключить, обслуживать, что делать в случае аварии, и т.д. их любопытно полистать, да.
Но вот в случае данного поста не хватает примеров, кроме того вы вводите аббревиатуры типа SOC или BPMN, нигде не расшифровывая их (потому что значение их в контексте статьи для вас очевидно, но это далеко не для всех).
Обожаю канцелярит. Но так и не понял как инструкция превратилась в плейбук, каким термином описывается скоробей и ставится ли тут глаз. Другими словами я тоже видел много плохих инструкции и так надеялся увидеть в статье понятную с картинками!
***
Кстати! Недавно мыл руки, читал инструкцию по процессу [мытья рук на кафельной стене над умывальником] и пришла мысль про инструкцию по эксплуатации ПК.
1. Положите клавиатуру перед собой.
2. Возьмите мышку в правую руку. (Если вы левша то по согласованию с медиком и отделом ИТ можно использовать левую руку)
3. С помощью мыши и клавиатуры давайте ПК необходимые команды для получения результата.
4. Результаты наблюдайте на мониторе.
Примечание: с необходимыми командами можно ознакомится в Справке и на образовательных курсах. Необходимые результаты изложены в должностной инструкции.
А у процессов всегда должен быть владелец.
Откуда такое требование? В BPMN его нет. Кроме того, ваше понятие владельца, в действительности, – исполнитель. И тут вы спутали роль с её исполнителем, которых может быть много. А ещё есть роль архитектора процесса: отвечает за само определение, существование и эволюцию процесса. Скажем, при изменении в бизнесе и организации вопросы эволюции процессов решаются через архитектора, а не их исполнителей. Конечно, никто не запрещает, чтобы один и тот же сотрудник выполнял несколько ролей. Однако это чревато саботажем и борьбой за власть через уровень методики.
Дробление процессов на мелкие блоки с этой точки зрения удобнее – можно определить конкретное действие за конкретным человеком.
Тут сразу две методические ошибки: путаете способы представления и распределение действий по исполнителям. Способы представления равнозначны по содержанию и различаются только по целям представления. Это можно отлично понять в том же Sybase PowerDesigner: процесс можно сворачивать и разворачивать на диаграмме, можно переходить к диаграммам процесса.
Но как потом этого человека найти?
Распределение действий по исполнителям решается стандартной таблицей назначения ролей элементам оргструктуры (см. FEAF, DODAF и ZIFA, например). Элементами оргструктуры являются не только сотрудники, но и подразделения, и группы. Соответственно поиск делается по этой таблицы: ищется исполнитель по роли. Опять же, в Sybase PowerDesigner такая функциональность есть сразу. А в BPMN сразу предусмотрены роли и структуры, имеющие свой контекст исполнения, и методы их связывания с процессами. А чтобы процессы не были независимым чёрным ящиком, предусмотрены средства описания диалога между ними. Фактически, получается описание протокола работы через описание процессов и их диалога.
А что если кто-то из множества владельцев не захочет менять процесс в угоду кибербезопасности? Или не захочет работать в навязанных SLA?
Если это превратилось в вопрос удовлетворения чьих-то желаний, тогда поломался процесс конструирования, и ситуация вышла за рамки деловой и профессиональной. А именно: желаниям в нём не место, т.к это вопрос выбора действий, эффектов и последствий. А они вычислимы и образуют сложную систему, в которой игнорирование означает выбор умолчаний, которые, обычно, совсем не то, что требуется. Вот поэтому должна быть роль архитектора, и его привилегия, ответственность и обязанность – устанавливать исполнителям, что и как делать (т.е. методику). Его обязанность – просчитывать возможные последствия и эффекты при каких-либо действиях, исходя из требований. Поэтому сперва должны быть согласованные требования, а не тупо приоритет "в угоду безопасности" как вредительская попытка отменить остальные требования, которые должны быть удовлетворены, чтобы забота о безопасности вообще была целесообразна. Никакой исполнитель со своей колокольни с этим не справится ввиду недостатка сведений и вычислительной мощности его головы. Зато может указать на невыполнимость и иные проблемы при тестировании требований и процесса.
надо просто сделать каталог атомарных действий, из которых потом на месте собрать пазл для каждой конкретной компании
Это вообще про конструирование, а не BPMN в применении к вашей области деятельности. Суть подхода – создание библиотеки и повторное использование её функциональности. Атомарные или более комплексные действия – это типовой подход конструирования с использованием примитивов. Кроме того, давно есть масса фреймоворков для самых разных типовых процессов. На эту тему масса статей написана, рекомендаций выдано и стандартизаций проведено.
О чем статья? Для кого эта статья? Что мы в итоге хотим получить от статьи?
Прочитав статью до конца, я увидел следующие ответы: ни о чем; скорее всего для тех кто задумывается о SOC и еще не знает, что это и как; еще раз подчеркнуть боль о недооценке бумажной безопасности, которая направлаенна на упрощение именно практической работы (ну или либо это просто реклама бренда вначале года).
Если бы эта статья появлялась на стадии зарождения SOC, то тогда в этой статье имелся бы смысл, но сейчас тезисы, которые приведены в статье, являются правилом хорошего тона. Использование BPMN, графов, алгоритмических схем и т.п. распространено во многих организациях, в которых даже нет SOCов.
Я уверен, что у Солара множество Заказчиков и было бы интересно посмотреть хотя бы на статистику: реакция на инциденты у заказчиков в которых введены были плейбуки с "рисунками" до подключения к Солар в сравнении с теми у кого не был раньше введен такой подход. Либо пример описания сложного процесса в понятном и простом "рисунке" на А4 страничке.
Плейбук здорового человека: можно ли описать ИБ-процессы и никого не запутать