21 июля 2014
Кому отвечать за безопасность бизнес-приложений: ИТ или ИБ?
Рустэм Хайретдинов,
CEO компании Appercut Security
Бизнес-приложения, к которым ради краткости термина в этой статье мы будем относить и ведомственные приложения государственных министерств и ведомств, являются сегодня ключевым инструментом управления организацией, извлечения прибыли или оказания государственных услуг. Простой приложения может привести к убыткам или потере прибыли на коммерческом предприятии или к невозможности оказывать услуги населению. Такие приложения обычно обрабатывают данные, оборот которых регулируется государством или общественными регуляторами (персональные данные, данные платежных карт, банковская, медицинская, коммерческая и другие виды тайн), а значит их утечка, которая может произойти из приложения, может также негативно отразиться на судьбе организации.
Поэтому часто возникает вопрос, вынесенный в название статьи – кто, служба ИТ или служба ИБ, отвечают за безопасность бизнес-приложений? В этом вопросе, как минимум, три термина требуют более точного определения.
«Безопасность». Традиционно в индустрии защиты приложений «безопасностью» считается защита данных от утечек. Руководства по защите приложений начинаются с рекомендаций по поиску уязвимостей, позволяющих похитить обрабатываемые данные, включая пользовательские. Поэтому в нынешней ситуации каким-то образом произошла подмена понятий – из всей классической «триады конфиденциальность-целостность-доступность» безопасники оставили себе только конфиденциальность, делегировав доступность разработчикам и службам ИТ, а целостность – службам внутреннего аудита. Однако в бизнес-приложениях конфиденциальность информации занимает далеко не первые места в рейтинге задач.
«Бизнес-приложения». Эти приложения разрабатываются для информационного обеспечения и автоматизации каких-то процессов деятельности организации. Мы встречаем бизнес-приложения на каждом шагу: это бухгалтерские системы, системы управления общими бизнес-функциями, такими как закупка, сбыт, маркетинг, управление кадрами и складскими запасами. Отраслевые системы автоматизируют основную, специфическую для каждой организации деятельность – конструкторские работы, производство, медицинские, финансовые или государственные услуги. К вспомогательным бизнес-системам можно отнести системы бюджетирования, отчетные системы, справочные системы, системы поддержки групповой работы и коммуникаций. Даже в самой маленькой компании или организации есть, как минимум, три приложения: бухгалтерия, система групповой работы (внутренний информационный ресурс) и интернет-сайт. Крупные компании пользуются десятками, а самые крупные – даже сотнями бизнес-систем. Зачастую эти приложения не являются независимыми: они обмениваются информацией друг с другом, результаты работы одного приложения являются исходными данными для другого. Так, например, интернет-сайт банка собирает данные потенциальных заемщиков и передает их скоринговой системе, которая помогает определить риски выдачи кредита конкретным кандидатам, которая передает отобранных добросовестных заемщиков уже в систему документооборота, та, в свою очередь, после заключения договора – в автоматизированную банковскую систему и т.д.
Откуда берутся бизнес-системы в организациях? Каждая успешная и эффективная организация имеет свои хитрости в процессах, поэтому от стандартных, «коробочных» бизнес-систем требуется немалая гибкость для того, чтобы уметь подстроиться под требования искушенного заказчика. Небольшой компании обычно достаточно стандартного функционала в коробочной или облачной бизнес-системе с базовыми настройками, особенно в хорошо структурированных процессах, типа логистики или управления складом. Однако с ростом бизнеса и погружением во все менее стандартизируемые процессы – управление требованиями к разрабатываемому продукту, управление разветвленной филиальной сетью с разными бизнес-функциями и т.п., а также с появлением некоторых организационных «ноу-хау», позволяющих оптимизировать процессы или лучше обслуживать клиентов, компания все больше нуждается в заказном решении. Большинство бизнес платформ большинства производителей: CRM, ERP, ABS, бухгалтерия, документооборот и пр. имеют возможность дорабатывать функционал на встроенном языке программирования. Как только в бизнес-системе появляются сторонние разработчики, создающие собственные программные модули, на основе базового функционала, ответственность за безопасность системы начинает размазываться между производителями платформы, разработчиками заказных модулей и администраторами системы.
Теперь вернемся к термину «безопасность». Бизнесу нужна не абсолютная, а эффективная безопасность, то есть та, обеспечение которой приводит к уменьшению рисков на сумму большую, чем сама стоит. И если посмотреть на безопасность бизнес-приложений с точки зрения эффективности, скорее всего, мы обнаружим, что обеспечение доступности данных зачастую гораздо приоритетнее их конфиденциальности. Когда и если еще хакеры найдут потенциальную уязвимость, научатся ее эксплуатировать, не проявив при этом себя и не насторожив службу информационной безопасности. А стабильность – она всегда «на виду». Поскольку бизнес-приложение обеспечивает функционирование конкретного бизнес-процесса, да еще, возможно, связанного с другими процессами, простой его в течение некоторого времени сделает такой процесс невыполнимым, что, скорее всего, приведет к убыткам и/или другим негативным последствиям. Представьте, что компания закупила товар, провела рекламную кампанию, привлекла в магазины огромное количество посетителей и … не смогла их обслужить, поскольку приложение на кассовых аппаратах перестало работать. Нет возможности пробить кассовый чек – нет возможности продавать: усилия всей кампании пошли насмарку.
А теперь давайте подумаем, из-за чего программа на кассовых аппаратах может перестать работать. Причин можно придумать множество – и вирусы, в том числе и написанные конкретно для этой задачи, и атака хакеров, в том числе и специально нанятых конкурентами или геополитическим противником, и саботаж обиженных (вариант – специально внедренных для этой операции) сотрудников. Но, скорее всего, это будет криво написанный запрос к базе данных, который намертво ее подвесит. Не правда ли, вы хотя бы раз слышали в ГИБДД, налоговой инспекции, БТИ, авиакассе, магазине и в других очень нужных вам местах фразу: «База висит, зайдите через полчаса (два часа, завтра)»?
Неправильно написанный запрос – чья зона ответственности? Точно не службы информационной безопасности: она честно занималась поиском уязвимостей и даже злонамеренных «закладок» с помощью специальных сканеров и привлечением специалистов исследовательских лабораторий, шифровала каналы и устанавливала антивирусы и межсетевые экраны. Возможно, эта служба даже нашла неустановленный вовремя патч на базовом бизнес-приложении и установила его. Служба информационных технологий тоже потрудилась на славу: она изо всех сил занималась обеспечением стабильности работы инфраструктуры: серверов, рабочих станций, операционных систем и другого базового служебного программного обеспечения, надежностью каналов и даже непрерывностью бизнеса. Она дублировала и «зеркалировала» ресурсы, делала резервные копии и многократно архивировала данные. Но система «упала» и бизнес понес убытки.
Казалось бы, очевидно: во всем виноват программист – это он написал плохую программную конструкцию. Но такой вывод не приносит удовлетворения: ни одна компания-разработчик не подписывается под компенсацией убытков от некорректной работы программы, почитайте лицензионное соглашение: «на свой страх и риск». Кто проверял работу этого программиста? Скорее всего, его начальник или коллега-тестер, у которых с программистом общие цели – побыстрее запустить «в продуктив» проект к конкретному сроку, на который рассчитывает бизнес. По всем организационным правилам, работу одной стороны не может аудировать другая сторона, мотивированная так же, как и проверяемая сторона: получается, что разработчик проверяет сам себя.
Думаете, ситуация смоделирована искусственно? Увы, недели не проходит, чтобы в каком-то банке не отвалился процессинг, интернет-банкинг иди служба ДБО для юридических лиц. Регулярно отказываются работать сайты государственных ведомств. Бывают, конечно, и взломы, и атаки на отказ в обслуживании на информационные ресурсы, но и они часто происходят на уровне приложений, то есть злоумышленники пользуются некорректными программными конструкциями, составленными разработчиками. Мало кто знает, что программистов на стороне заказчиков (то есть тех, для кого производство программного обеспечения – не бизнес) больше, чем в компаниях, которые зарабатывают производством программ. Больше «самописного» кода – больше ошибок, как гласит программистская мудрость.
Ситуация осложняется еще и тем, что довольно редко код бизнес-приложения можно зафиксировать надолго, хотя бы на несколько месяцев, чтобы изучать его вдумчиво – бизнес требует скорейшего внедрения функционала, который обеспечит прибыль от новой услуги или оптимизацию расходования ресурсов. Внешний бизнес-фон - конкуренты, государство, регуляторы, экономическая и политическая обстановка - в наши дни также меняется стремительно, так что вполне вероятно, что часть функций не успеют реализоваться в коде до того, как поступит команда писать их по-другому. При такой динамичной разработке вероятность получить в коде опасную программную конструкцию только увеличивается.
Но стороны, которая отвечала бы целиком за стабильность приложения, за соответствие «самописной» настройки приложения стандартам безопасной разработки, в большинстве компаний просто нет. ИБ отвечает за отсутствие уязвимостей, ИТ – за непротиворечивость настроек и работоспособную архитектуру. Полноценную службу приемки бизнес-приложений могут себе позволить всего несколько организаций в стране. По реализованным проектам контроля качества исходного кода бизнес-приложений можно увидеть, что службы ИТ, ИБ и разработчики перебрасывают такую задачу друг другу, как горячую картофелину: «это не мы – это они». Решить задачу «в лоб», как это делают разработчики тиражируемых программных решений, с помощью построения многоуровневого контроля каждого этапа разработки, не получается: придется вложить слишком большие ресурсы, которые с лихвой окупаются при тиражной разработке, но никогда не окупятся при разработке «для себя».
Но что-то делать надо. Вслед за закрытыми внутренними корпоративными системами в нашу жизнь пришли интерактивные интернет-системы, мобильные приложения. Не сегодня-завтра в корпоративные системы будут интегрированы бытовые приборы, автомобильные компьютеры и носимая электроника. Самописного и малоконтролируемого кода из года в год становится все больше и больше, а службы ИТ и ИБ все делят зоны ответственности. Если не заняться сообща работой над качеством исходного кода, мы получим вовсе не самоорганизующийся SkyNet, которым нас пугали фантасты. Для самоорганизации и уничтожения рода человеческого качество кода сегодня никудышнее. А вот внести в нашу жизнь и бизнес огромное количество сбоев такое качество приложений вполне себе способно.
