Очень странный вопрос мне на днях озвучили. Оказывается есть следующая проблема: компании покупают сложные решения безопасности (такие как SIEM, DLP, IDM и т.п.) и затем эти решения "не приживаются", вплоть до полного неиспользования... что с этим делать?
На мой взгляд здесь нарушена причинно-следственная связь. Используемые технические решения - это всего лишь инструменты и они не должны быть первичны. Правильная последовательность событий такая, что сначала у меня есть цели и задачи, есть боль которую я хочу утолить. Затем, чтобы бороться с этой болью эффективно, я должен ее понять как можно глубже. Понимание даст мне пути решения этой проблемы, они же - пути достижения целей и решения задач. Эти пути выражаются рядом мероприятий часть из которых может быть реализована организационными мерами, а часть - техническими.
Ну, действительно, сначала у меня должна появиться бизнес-задача - вырыть траншею, а уже затем я должен придумать инструменты решения этой задачи: мотивированные землекопы, модель их совместной работы, лопата штыковая, лопата совковая, лом, бур для сверления отверстий в земле, насос Малыш и т.п. Если я исхожу из инструмента, скажем у меня есть только совковая лопата, и я думаю, что мне надо бы вырыть траншею, то моя задача может быть и не решена вовсе, так как особенности грунта (анализ ситуации показал) таковы, что мне нужна не совковая лопата, а штыковая, а, кроме этого, еще нужен лом (допустим, зима) или насос Малыш (допустим, близко грунтовые воды и после полуметра глубины мне ее надо постоянно откачивать). Мы, как правило, осознаем эту простую причинно-следственную связь в бытовых ситуациях: сначала люди понимают, что им надо повесить полку на стену, затем идут покупают перфоратор со ударные сверлами нужного диаметра, - но почему-то делаем наоборот в задачах ИТ и ИБ, приобретая решения не понимая цели, про запас.
Несмотря на то, что все мое прошлое в подавляющем своем большинстве - техническая практика, опыт показывает, что при построении стройной системы эффективных (т.е. они дешевы и приводят к желаемому результату) контролей для достижения какой-либо бизнес-цели, доля технических контролей - невелика, а организационные меры, зачастую, более эффективны. Возможно, это связано с тем, что так или иначе корень многих проблем - человек/пользователь, а с людьми неэффективно работать техническими мерами. Отмеченные выше решения безопасности попадают в категорию как раз технических контролей. Помимо того, что они покрывают только часть проблемы, эффективность они могут показывать только тогда, когда появились как инструмент достижения какой-то бизенс-цели, а не просто так, потому что продажник-маркетолог убедил вас в необходимости наличия такого решения.
Причина низкой эффективности решений, появившихся не в результате анализа бизнес-задач (как инструмент решения этих задач), еще и в том, что эти коробочные продукты исходят из какой-то "стандартной"/типовой среды применения, которая может сильно отличаться от вашей. Это связано с тем, что у каждого своя корпоративная культура, профессионализм, понятие об этике, да и вообще, люди везде разные. Поясню. Одну и ту же задачу я могу решить миллионом способов, каждый из которых будет иметь свои преимущества и недостатки, но в зависимости от способа мне будут нужны/не нужны разные инструменты. Допустим, проблему контроля утечки я могу решить с помощью технического решения DLP (оставим за рамками рассмотрения ее техническую эффективность в борьбе с мотивированным злоумышленником) и работой моего мониторинга, который глазами/скриптами будет находить в логах инсайдеров, что-то сливающих. В этом случае мне нужно техническое решение. С другой стороны, я ту же проблему могу решить продвинутым повышением осведомленности и развить в трудовом коллективе не только высочайшую лояльность к компании, но и мотивировать их быть бдительными и сообщать мне о всех подозрительных фактах, сливать всех инсайдеров, что-то типа ДНД. В этому случае я работаю уже агентурными методами, и DLP - не краеугольный камень моего контроля утечек, может, вообще не нужна. Конечно, наибольшую эффективность покажет комбинация различных методов, а поэтому, исходя из анализа бизнес-цели и бизнес-задач, я могу получить разные требования к техническому решению и технические решения мне могут потребоваться разные, не те, что предлагаются на рынке.
Именно поэтому сначала мы должны анализировать цели/задачи/проблемы, потом подбирать под них контроли/мероприятия/решения, часть из которых будет закрываться техническими инструментами. И только в этом случае, когда вы идете от бизнес-цели, от бизнес-процесса ваши инструменты не будут простаивать.
Но, к сожалению, наша действительность такова, что многие уже натыкали решения, которые простаивают. В этом случае действовать нужно также: никогда не поздно провести анализ своих бизнес-целей, более того, такой анализ полезно делать регулярно. Только в рамках этого анализа учитывать, то обстоятельство, что уже есть какие-то технические решения, которые было бы неплохо использовать. В таком подходе есть подводный камень - риск увлечься техническими мерами, скатиться в придумывание ситуаций использования имеющихся технических средств, что, с учетом отмеченной мною выше низкой эффективности исключительно технических инструментов, приведет к неправильным приоритетам при разработке системы контролей для достижения поставленных бизнес-целей, результатом чего станет либо неэффективное расходование ресурсов, либо вовсе недостижение бизнес-целей.
Не торопитесь покупать и ставить все подряд, сначала поймите свои цели.
На мой взгляд здесь нарушена причинно-следственная связь. Используемые технические решения - это всего лишь инструменты и они не должны быть первичны. Правильная последовательность событий такая, что сначала у меня есть цели и задачи, есть боль которую я хочу утолить. Затем, чтобы бороться с этой болью эффективно, я должен ее понять как можно глубже. Понимание даст мне пути решения этой проблемы, они же - пути достижения целей и решения задач. Эти пути выражаются рядом мероприятий часть из которых может быть реализована организационными мерами, а часть - техническими.
Ну, действительно, сначала у меня должна появиться бизнес-задача - вырыть траншею, а уже затем я должен придумать инструменты решения этой задачи: мотивированные землекопы, модель их совместной работы, лопата штыковая, лопата совковая, лом, бур для сверления отверстий в земле, насос Малыш и т.п. Если я исхожу из инструмента, скажем у меня есть только совковая лопата, и я думаю, что мне надо бы вырыть траншею, то моя задача может быть и не решена вовсе, так как особенности грунта (анализ ситуации показал) таковы, что мне нужна не совковая лопата, а штыковая, а, кроме этого, еще нужен лом (допустим, зима) или насос Малыш (допустим, близко грунтовые воды и после полуметра глубины мне ее надо постоянно откачивать). Мы, как правило, осознаем эту простую причинно-следственную связь в бытовых ситуациях: сначала люди понимают, что им надо повесить полку на стену, затем идут покупают перфоратор со ударные сверлами нужного диаметра, - но почему-то делаем наоборот в задачах ИТ и ИБ, приобретая решения не понимая цели, про запас.
Несмотря на то, что все мое прошлое в подавляющем своем большинстве - техническая практика, опыт показывает, что при построении стройной системы эффективных (т.е. они дешевы и приводят к желаемому результату) контролей для достижения какой-либо бизнес-цели, доля технических контролей - невелика, а организационные меры, зачастую, более эффективны. Возможно, это связано с тем, что так или иначе корень многих проблем - человек/пользователь, а с людьми неэффективно работать техническими мерами. Отмеченные выше решения безопасности попадают в категорию как раз технических контролей. Помимо того, что они покрывают только часть проблемы, эффективность они могут показывать только тогда, когда появились как инструмент достижения какой-то бизенс-цели, а не просто так, потому что продажник-маркетолог убедил вас в необходимости наличия такого решения.
Причина низкой эффективности решений, появившихся не в результате анализа бизнес-задач (как инструмент решения этих задач), еще и в том, что эти коробочные продукты исходят из какой-то "стандартной"/типовой среды применения, которая может сильно отличаться от вашей. Это связано с тем, что у каждого своя корпоративная культура, профессионализм, понятие об этике, да и вообще, люди везде разные. Поясню. Одну и ту же задачу я могу решить миллионом способов, каждый из которых будет иметь свои преимущества и недостатки, но в зависимости от способа мне будут нужны/не нужны разные инструменты. Допустим, проблему контроля утечки я могу решить с помощью технического решения DLP (оставим за рамками рассмотрения ее техническую эффективность в борьбе с мотивированным злоумышленником) и работой моего мониторинга, который глазами/скриптами будет находить в логах инсайдеров, что-то сливающих. В этом случае мне нужно техническое решение. С другой стороны, я ту же проблему могу решить продвинутым повышением осведомленности и развить в трудовом коллективе не только высочайшую лояльность к компании, но и мотивировать их быть бдительными и сообщать мне о всех подозрительных фактах, сливать всех инсайдеров, что-то типа ДНД. В этому случае я работаю уже агентурными методами, и DLP - не краеугольный камень моего контроля утечек, может, вообще не нужна. Конечно, наибольшую эффективность покажет комбинация различных методов, а поэтому, исходя из анализа бизнес-цели и бизнес-задач, я могу получить разные требования к техническому решению и технические решения мне могут потребоваться разные, не те, что предлагаются на рынке.
Именно поэтому сначала мы должны анализировать цели/задачи/проблемы, потом подбирать под них контроли/мероприятия/решения, часть из которых будет закрываться техническими инструментами. И только в этом случае, когда вы идете от бизнес-цели, от бизнес-процесса ваши инструменты не будут простаивать.
Но, к сожалению, наша действительность такова, что многие уже натыкали решения, которые простаивают. В этом случае действовать нужно также: никогда не поздно провести анализ своих бизнес-целей, более того, такой анализ полезно делать регулярно. Только в рамках этого анализа учитывать, то обстоятельство, что уже есть какие-то технические решения, которые было бы неплохо использовать. В таком подходе есть подводный камень - риск увлечься техническими мерами, скатиться в придумывание ситуаций использования имеющихся технических средств, что, с учетом отмеченной мною выше низкой эффективности исключительно технических инструментов, приведет к неправильным приоритетам при разработке системы контролей для достижения поставленных бизнес-целей, результатом чего станет либо неэффективное расходование ресурсов, либо вовсе недостижение бизнес-целей.
Не торопитесь покупать и ставить все подряд, сначала поймите свои цели.
2 comments:
О том же, но по другому: внедряя новое решение нужно заранее продумывать цепочку люди/процесс/технологии. Имея только один из компонентов (чаще всего технологии) невозможно добиться эффективности от внедрения. Более того, в подавляющем большинстве случаев люди/процесс должны быть внедрены в первую очередь, поскольку они позволяют лучше понимать требования к технологии, и к тому же служат основой для бизнес обоснования проекта внедрения технологии. Как весьма абстрактный пример, вот у нас есть процесс, вот его результаты (обнаружено # инцидентов, предотвращено # инцидентов, спасено # щеночков из горящих домов и пр.), вот есть технология которая улучшит/убыстрит процесс и/или сделает его эффективнее, освободит # человек на другие нужды - и разговор получается совершенно другим.
Отличное дополнение, спасибо.
Но я немного о другом. Вы о том, что когда вы уже выбрали какое-либо мероприятие, то для его реализации нужно подумать о людях-процессах-технологиях.
А я пытался рассказать о том, что прежде чем реализовывать какие-то мероприятия надо осознать бизнес-цель всей этой деятельности. Конкретное техническое решение (SIEM, DLP, IDM, фаервол, IPS и т.п.) - это одно из возможных мероприятий, которое, в результате осознания цели может быть вообще не нужно, или не нужно в том, стандартном/тповом виде, что предлагает рынок.
Post a Comment