Управление программными активами, или лучше поздно, чем нигде

"- Ты ничего не понимаешь! Это последний писк моды!

- Странная тетка, эта ваша мода. Каждую неделю издает последний писк

и никак не сдохнет!"

Когда-то несколько лет назад автору материала пришлось столкнуться с таким модным ныне понятием как Software Assets Management (SAM). Перевод этого хитрого словосочетания на русский язык - предмет отдельных священных войн, распространенным вариантом является Управление программными активами. Изучался в ту пору стандарт ИСО 19770 аж целого 2006-го года, изучался и благополучно забылся по итогам изучения. И вот, год 2012 от Рождества Христова - на арену российской ИТ действительности выплывает SAM и отчаянные попытки ИТ и не очень ИТ организаций привести свою систему управления ПО в соответствие с этой методологией, организовать мир, дружбу и коммунизм. Весьма недурно это все описано, к примеру, здесь. Но все же большинство тех, кто гонится за SAM, делают это, очевидно, из чувства долга, стадного или еще какого-нибудь нехорошего чувства, а не ради дела. Почему? - стоит рассмотреть подробнее.

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

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

В-третьих, как это уже стало нормой в России, соответствие тем или иным стандартам и системам критериев воспринимается как декларация собственной непогрешимости. Следует помнить, что SAM - это всего лишь подход к эффективному управлению ИТ активами (существует также ITAM, Configuration Management ITSM и другие интересные методики организации, удовлетворяющие потребности грамотного управления ПО и АО в организации), а сертификация по SAM - не более чем способ подтвердить, что некая - пусть и немаловажная - часть ИТ деятельности в организации выполняется хорошо, с учетом мировых практик.

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

Проблема предмета, контекста и нюансов, или немного о сценариях риска

Дело был не так давно, когда автор сего озадачил себя разработкой достаточно понятной и идеалистически верной презентации по управлению рисками. Собственно, о рисках даже в этой ленте было уже сказано достаточно, да и вообще тема эта любима среди специалистов по безопасности, так что найти соответствующий материал в сети совсем не сложно. Но один взгляд показался достаточно интересным.
Речь пойдет о сценарно-ориентированном подходе (вольный перевод термина scenario-based risk-management). Один из наиболее полных и значимых методов, основанных на этом подходе, представлен в методологии компании ISACA (isaca.org) Risk IT Practioner's Guide.
Данный подход старается разрешить крайне распространенную среди аналитиков коллизию "риск-рисковое событие", которая заключается в том, что риск воспринимается как событие, хотя классическая трактовка риска - это состояние, характеризуемое наличием возможности нанесения ущерба (что включает в себя сразу несколько понятий: ущерб, вероятность реализации ущерба, угроза - так называемые факторы риска). Рисковое событие в таком случае должно рассматриваться как ситуация реализации риска. К сожалению, подобный подход многим представляется крайне сложным, поэтому многие методические документы по управлению рисками допускают подобную путаницу (например, ISO 31000 или COSO).
Risk IT Practioner's Guide предлагает использование в качестве характеристики риска, по сути своей, заменяющей рисковое событие (хотя, не отрицающей его), сценарий риска (или сценарий реализации риска). Под сценарием риска понимается совокупность событий, обстоятельств и действий, описывающих реализацию риска. То есть, строго говоря, сценарий риска - это набор рисковых событий, минимально достаточный для нанесения ущерба. На основе анализа сценариев, частоты их возникновения и значимости, формируется карта риска (risk map), которая наглядно определяет подверженность актива риску, потребности защиты (контроля) и иные эпические характеристики.
На этапе работы с подобной философией - иначе ее назвать язык не поворачивается - автор столкнулся с интересным материалом, который весьма доходчиво объясняет, что такое сценарий риска в современном, обывательском понимании (а ведь обывательское понимание технических сущностей является неотъемлемым условием правильного понимания руководством!!!).
Итак, гласит этот материал, представьте себе автомобильную покрышку. Она существует. Это сценарий риска? Возможно, хотя верится с трудом, но притянуть за уши риск, который может быть связан с данной ситуацией, можно.
Теперь представьте, что покрышка висит на веревке. Уже более рисковая ситуация, которая предполагает различные сценарии в данных обстоятельствах. Покрышка висит на веревке, привязанной к ветке дерева (народный американский метод формирования качелей во дворе - прим.). Покрышка висит на веревке, привязанной к ветке дерева, стоящего на краю обрыва. Покрышка висит на веревке, привязанной к ветке дерева, стоящего на краю обрыва, и веревка рвется. И так далее. Мысль ясна?
Данная трактовка напоминает старый неприличный анекдот про нюанс, однако, именно так наиболее верно воспринимается риск как состояние окружающей среды, достаточное для нанесения ущерба по тем или иным сценарием. Именно с учетом обстоятельств, которые эту среду формируют.
Следует заметить, что в данном методологическом материале также игнорируется вторая составляющая определения риска - понятие вероятности. Дело в том, что вероятность сама по себе является величиной прогнозной, то есть ориентированной на будущее. В то время, как опирается она на статистические данные о прошлом. Что в деле безопасности может сыграть злую шутку. В данном случае в качестве частотной характеристики выступает частота возникновения сценария риска (frequency), которая по крайней мере не предъявляет претензий к экстрасенсорным способностям эксперта, а позволяет сделать объективный вывод о риске пост-фактум.
В общем, рекомендуется ознакомиться с настоящим материалом, на мой взгляд, интересным с точки зрения классической теории управления рисками, и сделать свои выводы.