Уроки непроведенных изменений
Прошедшая эпидемия нашумевшего вируса-шифровальщика снова показала, что для обеспечения безопасности информационных систем недостаточно накупить различных инструментов и научиться ими пользоваться. Оказалось, даже лучшие решения не работают, если вы не следите за изменением своих информационных систем и не адаптируете системы безопасности под эти изменения. Безопасность — это не проект, это процесс.
Регулярно возникают коллизии, при которых в стандартных процессах встречаются противоречия, и кто-то должен их разрешать. Предположим, в каких-то продуктах обнаружена уязвимость и производитель программного обеспечения выпускает патч для ее закрытия. Сотрудник, ответственный за безопасность, настаивает на скорейшей установке патча: вслед за выпуском патча злоумышленники изучают его, понимают, как атаковать закрываемые уязвимости, и бросаются на поиски систем, на которые патч еще не установлен. Обычно на это уходит несколько дней, затем все информационные системы с незакрытыми уязвимостями становятся потенциальными жертвами злоумышленников.
Однако против спешки с установкой патча выступают несколько других служб. Первая — отвечающая за соответствие информационных систем требованиям регулятора. Не нарушит ли этот патч соответствие имеющимся требованиям? Патч должен пройти проверку регулятора, и только потом его можно устанавливать на системы, соответствующие специфическим регламентам регулятора. Сейчас регуляторы позволяют некоторые патчи устанавливать до сертификации, но в общем случае выбор «лучше быть защищенным или сертифицированным» все же существует.
Вторая служба, которая не спешит устанавливать патчи на информационную систему, — служба эксплуатации. Есть айтишное поверье «работает — не трогай». Никому не хочется проводить внеплановые изменения в настроенной и действующей системе. Никто не знает, как изменит функционирование информационной системы дополнительный модуль — сначала его надо протестировать, и даже после его установки на 5–10% компьютеров нельзя исключить проблему с масштабированием при размещении на всей системе. А потому для этой службы логично тянуть с установкой патча до какого-нибудь большого и планового обновления, чтобы протестировать все и сразу.
Все три службы выполняют свои задачи, имеют свои, случается, и противоречащие друг другу критерии успешной работы. Критерии их успешности сложились очень давно, когда обновления были прогнозируемыми и редкими. Сегодня мир изменился, ускорившись, а процессы остались такими же. Интуитивно понятно, что для разрешения коллизии кто-то должен стоять над ними всеми, выслушать все стороны и вынести решение — приняв все связанные с этим решением риски.
Безопасное управление изменениями
Похожие коллизии сегодня приходится постоянно разрешать не только во время экстренных обновлений, но и в периоды других регулярных изменений — в большинстве случаев это осложняется тем, что полновластных владельцев информационных систем нет, разные подразделения отвечают за отдельные их части.
Возьмем другой случай — заказная разработка бизнес-приложений. Бизнес требует функционал, который реализуют разработчики. ИТ-департамент предоставляет инфраструктуру под нужный функционал и нагрузку, а служба информационной безопасности тестирует их защищенность и затем обеспечивает защиту. Пока изменения происходят раз в полгода-год, существует разделение ответственности: одни разрабатывают, другие тестируют, третьи защищают, четвертые эксплуатируют. Так продолжалось много лет, пока изменения, необходимые бизнесу, не стали настолько быстрыми, что процесс перестал «сходиться». С переходом на Agile-методологию разработчики стали так часто выдавать новый функционал, что службы информационной безопасности не успевают его тестировать. Классический спринт идет две недели, пентест, если повезет — еще две, хотя чаще три недели. Что делают разработчики, пока тестеры решают, уязвим новый функционал или нет? Если пишут новый, то к моменту окончания пентеста его результаты становятся уже не нужными: они описывают старый функционал. Если просто ждут — кто им оплатит этот простой?
В результате несколько разных процессов, ранее легко уживавшихся между собой, начинают противоречить друг другу. Обычный инцидент: тестировщики нашли уязвимость в функционале — что делать? Исправлять? Но отдельных программистов на исправление нет, значит, устраняя старые ошибки, они не будут писать новый функционал. Кто оплатит задержку с выпуском функционала? Игнорировать и запускать в продуктив? Но тогда возможен взлом приложения, и кто будет отвечать за нанесенный ущерб? Останавливать обновление до исправления? Но кто тогда оплатит бизнесу издержки за то, что не будет осуществлена бизнес-функция, под которую уже могла начаться реклама или завезен товар на склад?
Однозначного ответа на эти вопросы нет. Все зависит от многих факторов — важности изменений и времени их жизни, ценности информации, которая может быть скомпрометирована, рисков взлома, наличия компенсирующих мер безопасности, инвестиций в офлайновые ресурсы, связанных с онлайн–системой, и многих других факторов, имеющих разную степень важности. Кто-то должен собрать воедино всю информацию, оценить и взвесить риски и принять окончательное решение. Только прежде надо проверить предоставленную информацию на ее соответствие реалиям.
Противоречащая мотивация к изменениям
Поскольку ни один из участников процесса не отвечает за процесс целиком, а только за его часть, то еще и преувеличивает риски или ценности, к которым имеет отношение и которые влияют на его мотивацию. Функциональщик, мотивированный на скорейший запуск функции, утверждает, что именно без этой функции не будет получен результат. Программист, для которого одним из критериев является качество реализации функции, уверен, что найденная в функции уязвимость – неэксплуатируемая, и требует неопровержимых доказательств возможности ее эксплуатации в реальных условиях, что усложняет и удорожает процесс тестирования. Сотрудник службы информационной безопасности убежден, что риск огромен: найденную безопасность злоумышленники немедленно обнаружат, обнаружив — тут же взломают, а взломав — нанесут огромный ущерб.
Хорошо бы верить в то, что все «преувеличивают» приблизительно одинаково, и работать с теми данными, которые есть. Но иногда это не так: бывает, нужно сдать действующую систему к конкретному сроку, и его никак нельзя перенести, например, к чемпионату мира по футболу. В таких случаях параметр времени становится мажорирующим — нельзя вообще не выпустить систему к мероприятию. И тогда выпускается уязвимый функционал с попытками осуществить защиту компенсирующими методами.
Бизнес-взгляд на изменения
Если раньше информационная безопасность была отдельной службой, то теперь из-за постоянных изменений она «вросла» в ИТ-системы, которые в свою очередь полностью пронизали все бизнес-процессы. ИТ-системы уже не отражают бизнес-процессы, как было еще совсем недавно, а во многом формируют их, поэтому сегодня безопасность ИТ-систем и есть безопасность бизнеса. ИТ-системы стали слишком важными, чтобы доверять их айтишникам. Безопасность перестала быть «вещью в себе», и ее теперь нельзя рассматривать в отрыве от бизнес-процессов, она превратилась в их неотъемлемую часть, или, как иногда говорят, «слой».
К сожалению, старая проектная модель взаимодействия различных участников процесса формулируется в позиции его руководителя, выражаемой фразой: «Я в этом ничего не понимаю, договоритесь между собой как-нибудь». Конечно, по каждому изменению, затрагивающему многие слои функционирования организации, их владельцы стремятся прийти к соглашению, но процесс договоров людей с противоположной мотивацией часто напоминает басню про лебедя, рака и щуку, с предсказуемым результатом для воза.
Есть ли выход? В последнее время в организациях стали появляться должности «цифровых директоров», полностью отвечающих за какой-то автоматизированный процесс — за интернет-банк или продажи через электронный магазин. Такие люди мотивированы на общую эффективность бизнес-процесса — на прибыльность, абсолютный рост, увеличение доли рынка или части электронных услуг в общем объеме услуг компании. И они имеют власть для того, чтобы принять взвешенное решение с учетом всех открывающихся возможностей и появляющихся рисков. Только такой человек способен взять на себя ответственность за рискованное решение, например, выпустить уязвимую функцию и реализовать с ее помощью товар с прибылью, превышающей вероятный ущерб от взлома, — подобного права нет ни у одного участника части процесса.
Концентрация ответственности на уровне выше, чем создание и изменение процесса, взгляд на безопасность информационной компании сверху, не со стороны функций и уязвимостей, а со стороны стратегических целей организации — вот, пожалуй, единственный способ разрешить противоречия, неразрешимые на уровне самого процесса.
Нетривиальное для ИТ-журнала утверждение, но с точки зрения бизнеса ущерб от остановки деятельности и расходы на восстановление данных могут оказаться меньше, чем миграция на менее уязвимые операционные системы. В большинстве случаев абсолютная безопасность не нужна, достаточно экономически эффективной безопасности, то есть стоимость потерь должна компенсироваться недоинвестициями в информационные технологии и информационную безопасность.
Что бы вам ни говорили айтишники и безопасники.
Опубликовано 05.07.2017
