Продолжу как я тему с финансовым обоснованием приобретения решений по кибербезопасности, которую я начал в прошедшую пятницу. Все-таки в блоге присутствует слово «бизнес» и надо больше уделять ему внимания. После прочтения прошлой заметки могло сложиться впечатление, что такие расчеты очень просты. На самом деле это и так, и не так одновременно. Вспомните мою заметку двухлетней давности про оценку ущерба от DDoS-атак на сайт организации. Я там приводил пять уровней зрелости такой оценки, идею чего можно применить и к сегодняшней теме.
На первом уровне мы оцениваем экономию от применения MDM/UEM-решения и сравниваем ее со стоимостью лицензии на это решение. Легко автоматизируемая в Excel или даже считаемая на коленке задача. Но, очевидно, что она не учитывает целого ряда параметров. Например, достаточно глупо считать стоимость решения в лоб, так как мы забываем про такое понятие как совокупная стоимость владения (TCO), введенное Гартнером много лет назад и показывающее, во сколько реально обходится стоимость средства защиты информации (да и ИТ тоже). Эта стоимость владения складывается из прямых и косвенных затрат. К первым относятся:
- Капитальные затраты на программное обеспечение
- Капитальные затраты на аппаратное обеспечение
- Затраты на дополнительное программно-аппаратное обеспечение (базы данных, браузеры, системы резервирования и т.д.)
- Затраты на поддержку и обучение (командировочные расходы, звонки в службу поддержки, общение по e-mail)
- Затраты на управление (зарплата администраторов, реагирование на атаки, трафик Internet, модернизация)
- Затраты на внедрение
- Сопутствующие затраты (прокладка СКС, изменение топологии, перенастройка оборудования).
И прайсовая стоимость MDM/UEM-решения составляет всего 15-20% от всех затрат, которые мы понесем, внедряя решение. К косвенным затратам будут относиться непродуктивная работа пользователей, связанная с действиями «проб и ошибок» из-за отказа от чтения документации и обучения, а также простои и сбои системы защиты. То есть получается, что на MDM/UEM-решение мы должны потратить в 5-6 раз больше денег, чем это казалось изначально (это, кстати, хорошо объясняет, почему open source решения не бесплатны, а в эксплуатации часто обходятся даже дороже проприетарных и коммерческих продуктов).
Но и это еще не все, что нам нужно учесть при расчете стоимости решения по ИБ. Ведь мы можем попробовать ее снизить. Во-первых, никто не отменял скидки, которые можно выбить из вендора. Во-вторых, мы можем воспользоваться различными финансовыми схемами (в хорошем смысле) — кредитованием, лизингом, рассрочкой платежа и т.п., которые позволят перевести это все либо в операционные расходы, либо «сгладить» единовременность капитальные расходы за счет оплаты частями, за что спасибо скажет любой финансист. В-третьих, мы можем попробовать разместить систему управления в облаке, а то и выбрать MDM/UEM-решение, управляемое изначально из облака, что позволит нам сократить затраты на железо под систему управления, а также затраты на ее внедрение (нужно будет ее только настроить). В продвинутых с точки зрения технологий компаниях можно сократить затраты на установку агентов MDM/UEM на мобильные устройства, переложив эту задачу на самих пользователей, которым дана подробная инструкция (например, у нас в Cisco это сделано именно так). В конце концов, и управление самой системой можно отдать на аутсорсинг, если он окажется привлекательнее управления своими силами (сегодня, по данным IDC 12% компаний используют такую модель управления мобильными устройствами).
Но погружаться в детали надо не только с точки зрения стоимости системы защиты, но и с точки зрения экономии. В пятничном примере для MDM/UEM-решения был приведен расчет для компании из 2000 сотрудников и я исходил из того, что у каждого сотрудника по одному мобильному устройству. Но ведь это не так. Статистика говорит нам о том, что в среднем у офисного работника сегодня 3 мобильных устройства (смартфон, планшет и ноутбук). То есть экономию от внедрения MDM/UEM-решения мы уже можем спокойно умножать на три. Правда, это все-таки зависит не от «средней температуры по больнице», а от того, сколько мобильных устройств в пересчете на сотрудника именно в вашей компании (может ведь быть и так, что у вас не все сотрудники ходят с мобильными устройствами). Например, Forrester в одном из своих исследований приводил цифры, что 52% работников используют 3 и больше (!) мобильных устройств. Также мы можем учесть и количество мобильных приложений, с которыми работает сотрудник, и которые должны быть установлены и настроены, что тоже требует определенных временных и, как следствие, финансовых затрат. Работники 59% компаний по данным IDC используют от 3 до 5 мобильных приложений, у 15% их и того больше. Эти показатели тоже можно взять в расчет, что приведет к большей экономии, чем планировалось изначально.
Но MDM/UEM-решения не висят в воздухе — они неразрывно связаны с тем, ради чего вообще внедряются мобильные устройства. По статистике ITProPortal они увеличивают рабочий день сотрудника на 2 часа. Другая статистика (от Fliplet) говорит о том, что компании получают от «мобилизованных» работников дополнительных 240 часов в год (около одного «лишнего» часа в день), что может приводить к росту продуктивности и, как следствие, к росту доходов компании. По данным Samsung смартфоны увеличивают продуктивность работников на 34%. Эти, а также иные преимущества от мобильных устройств (рост эффективности коммуникаций, рост кросс-функционального взаимодействия, увеличение скорости принятия решений и т.п.), тоже должны браться в расчет при оценке экономики выбора MDM/UEM-решений, которые являются неотъемлемой частью любого проекта по корпоративной мобильности. Как вишенка на торте, мы еще можем сэкономить на мобильном Интернет-трафике, который далеко не всегда является в компаниях безлимитным.
Есть ли засада в таком подходе?
Да, конечно, куда уж без нее. Во-первых, вам придется забыть про безопасность, угрозы и compliance. Вы «продаете» решения, пользуясь иной мотивацией. А значит вам нужно получить исходные данные для расчетов, которых у вас нет. За ними придется идти на поклон к другим подразделениям, например, ИТ, чью работу среди прочего вы и планируете облегчать. А может вам удастся просто убедить ИТ в нужности MDM/UEM и они все сделают за вас, а вы получите в руки бразды управления защитными возможностями этих решений. Во-вторых, вам придется научиться общаться с бизнесом на языке, к которыми ИБшники не привыкли, а расширять зону комфорта (а не выходить из нее — это неправильный посыл) хотят далеко не все. В-третьих, такой расчет может показать, что экономических выгод от внедрения нет. Такое бывает. Например, проекты по ПДн или КИИ из этой области — выгод никаких, одни затраты. Или когда зарплата специалистов, чей труд вы хотите автоматизировать, невысока и средство автоматизации стоит гораздо больше. Тогда вы просто вернетесь к «любимым» страшилкам про угрозы и злобных регуляторов. Наконец, такие расчеты не универсальны. Это угрозы едины во всем мире, а требования законодательства — в рамках целого государства или отрасли (и можно взять уже готовые обоснования, сделанные кем-то еще). Экономические расчеты делаются под конкретную организацию и конкретное решение. И делать их нужно вам или нанятым консультантам (но на это тоже нужны деньги). Я ведь не зря использовал пример SafeMobile от НИИ СОКБ — возьми я любое другое MDM/UEM-решение (Meraki, Citrix, SAP, IBM, Microsoft, MobileIron, BlackBerry и т.п.) и расчеты могли бы оказаться совсем другими; как лучше, так и хуже.
В Фейсбуке под ссылкой на прошлую заметку мне написали, что пример с экономикой расчета MDM/UEM очень простой и надо показать что-то другое. Поэтому попробую показать аналогичные примеры, но для других средств защиты и уже в следующих заметках.
Сейчас модно применять количественную оценку риска, вместо качественной. Но работа с цифрами это тоже своеобразное жонглирование фактами. Въедливый «бизнес» быстро разнесет все показатели при большом желании. 5 часов на настройку мобильного места * на стоимость труда? А почему 5 часов, а не 3 или 2?
Атака вируса приведет к остановке конвейера на 1 сутки = стоимость продукции * время простоя. А почему именно на сутки? А почему вы просите защиту на все 10000 станций, а не чисто на конвейер? Атака на хотя-бы одну станцию заразит все остальное? Или не заразит? А если купим защиту то не заразит? Точно точно? Что? Какие такие зиродеи? То есть даже если купим вы не даёте гарантий? Что даже в пользовательском соглашении на защитное программное средство прописано, что они не несут ни за что ответственность? До свидания.
Так и торговля страхом тоже может быть отнесена к жонглированию. Почему вы меня пугаете угрозой шифровальщика, если мы с ней ни разу не сталкивались? Почему вы пугаете меня регулятором по КИИ, если они ни разу не приходили?
Чтобы бизнес не разнес показатели в пух и прах они должны быть честными? Почему 5 часов на настройку? Потому что это цифры от нас и от ИТ. Почему простой сутки? Потому что у нас уже было два кейса с простоем на полсуток и двое суток — мы усреднили. Почему просим на 10000 станций, а не только на конвейер? Вот тут крыть нечем кроме рассказа про kill chain на примерах из жизни или рассказывать про пронятые аналогии (вор сначала наблюдает за одним домом в коттеджном поселке, а потом обносит все). Ну и т.д. Дискуссия с руководством — это всегда дискуссия с неочевидным финалом. Использование одного обоснования снижает шансы по сравнению с использование двух-трех обоснований.