Илья Медведовский
к.т.н., директор Digital Security

Александр Поляков
руководитель направления аудита ИБ,
руководитель исследовательского центра DSecRG,
QSA-аудитор Digital Security

Аннотация

Обеспечение безопасности корпоративных бизнес-приложений - это одна из важнейших задач современного бизнеса, но именно распространенные мифы и заблуждения, описанные в статье, являются наиболее опасными и могут привести для него к крайне неприятным последствиям.

Введение

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

Миф 1. Безопасность бизнес-приложений – это проблема производителя

Взгляд с точки зрения бизнеса:

Одно из главных заблуждений, которое активно насаждается интеграторами, состоит в том, что безопасность бизнес-приложений это, прежде всего, проблема разработчика. А раз так, то пусть он их сам и устраняет. Причем что любопытно, что когда речь идет об информационной системе в целом, состоящей из различных операционных систем, баз данных, приложений и т.д. – такого заблуждения нет. Видимо потому, что там много разных производителей и всем претензии не предъявишь. Плюс все понимают, что информационная система – это крайне сложный организм, который требует регулярного анализа защищенности и безопасность которого зависит от совокупности различных факторов. В случае же одной из систем управления предприятием или ключевого бизнес-приложения, когда производитель один, у бизнеса может возникнуть опасная иллюзия, что безопасность – это проблема производителя. С технической точки зрения, это утверждение вообще в корне неверно, а с точки зрения бизнеса, оно, по меньшей мере, крайне наивно и очень опасно, прежде всего, именно для бизнеса. С каких пор производитель несет ответственность за инциденты в области безопасности? Он продает лицензию на продукт и при этом не несет вообще никакой ответственности за любой ущерб, который может возникнуть при использовании клиентом его продукта. Соответственно, вся многолетняя практика развития отрасли разработки программного обеспечения говорит нам о том, что для производителя вопросы безопасности его продукта имеют второстепенное, если не третьестепенное значение (на первом плане всегда только функционал). Важно это учитывать особенно когда речь идет о таких специфичных и малоизученных хакерами продуктах как, например, ERP, CRM, SRM и других специализированных бизнес-приложениях. В любом случае, следует четко понимать, что безопасность приложения – это проблема бизнеса, никоим образом не имеющая отношения к производителю.

Взгляд с технической точки зрения:

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

Даже говоря о программных уязвимостях, нельзя не принимать во внимание то, что проблема выпуска обновлений – это проблема производителя, а проблема своевременной установки обновлений – это задача администратора; и решается она только правильной политикой установки обновлений, включающей в себя различные аспекты, такие как тестирование, согласование с руководством, возможность отката и прочие важные нюансы. Архитектурные уязвимости также могут быть виной как разработчиков (например, атака SMB relay в Windows), так и администраторов, к примеру, неправильное расположение компонентов ERP на сетевом уровне, позволяющее получать неавторизированный доступ в подсеть ERP и, как следствие, - перехват данных.

Миф 2. Бизнес-приложение является внутренним – значит у нас не может быть проблем из сети Интернет

Взгляд с точки зрения бизнеса:

Второй стойкий миф особенно присущ внутренним корпоративным системам класса ERP. Почему-то бизнес наивно полагает, что раз к ERP-системе не осуществляется доступ из сети Интернет, то она безопасна относительно возможных действий внешнего злоумышленника. Это опять же крайне наивно, бизнес уже давно вышел за рамки внутренней среды. Множеству приложений приходится постоянно интегрироваться как с удалёнными офисами через общедоступные сети, так и с другими компаниями посредством различных приложений по взаимоотношению с поставщиками, клиентами и партнёрами, расположенными в разных частях мира. В то же время они также должны иметь постоянный доступ к ресурсам компании – это очевидное требование эпохи глобализации современного бизнеса.

В результате, сегодня все разработчики систем класса ERP так или иначе предоставляют доступ к ERP-системе из сети Интернет. Примером этого может послужить платформа SAP ECC, в которой бизнес-процессы представлены как сервисы. Последствия этого шага с точки зрения безопасности в данном случае вполне очевидны.

Но даже если система не имеет связей с внешним миром, то не стоит забывать, что сегодня самым простым способом проникновения в корпоративную сеть является использование человеческого фактора (отправка пользователю письма с целью заманить его на злонамеренный сайт для последующей установки у него троянской программы), и бизнес об этом сегодня отлично знает. Однако при этом бизнес часто наивно полагает, что подобная атака предназначена только для проникновения в КИС компании и не имеет отношения к ERP, что является очень опасным заблуждением. Сегодня существуют специально разработанные сценарии таких атак, напрямую направленных, например, на SAP ERP, основанные на комбинации социальной инженерии и уязвимостей SAP, и бизнес должен отдавать себе отчет в уровне этой угрозы.

Взгляд с технической точки зрения:

Злоумышленники уже давно не пытаются проникнуть в сеть компании напрямую через пограничные маршрутизаторы. Гораздо проще атаковать пользователей, которые меньше защищены. Как уже говорилось, на данный момент существует множество способов, позволяющих получить доступ к ERP-системе, находящейся внутри предприятия. Они основаны на различных уязвимостях клиентских приложений. В ходе анализа защищенности клиентских компонентов бизнес-приложений различных производителей, таких как SAP, Oracle и других менее известных, были обнаружены уязвимости, позволяющие получить доступ к компьютерам сотрудников через сеть Интернет. Кроме того, никто не отменял различные схемы социальной инженерии, также позволяющие получить доступ в корпоративную систему компании.

Другой популярный способ проникновения во внутреннюю сеть компании – это использование уязвимостей в публичных WEB-сервисах, которые предоставляются клиентам. Примерами таких приложений могут быть SRM и CRM системы. Как и в других WEB-приложениях, в их реализациях также присутствуют уязвимости, позволяющие не только получить административный доступ к самой системе или к документам других поставщиков (если рассматривать систему SRM), но и проникнуть внутрь компании из сети Интернет. Самое опасное, что для реализации данной атаки зачастую не обязательно иметь легитимные права пользователя в системе. Часто это может сделать любой злоумышленник.

Миф 3. Бизнес-приложения плохо изучены – значит нам ничего не грозит

Взгляд с точки зрения бизнеса:

Действительно бизнес-приложения часто располагаются внутри корпоративной сети и гораздо хуже изучены, чем общеизвестные и широко используемые ОС и базы данных. Бизнес на эту тему не задумывается по очевидным причинам, поэтому этот стойкий миф часто завладевает умами технических специалистов и, что самое печальное, самих разработчиков. Практика показывает, что и это совершенно логично с точки зрения бизнеса, т.к. в этом случае разработчики, полагая, что их система является внутренней (Миф 2), сложной и недоступной для изучения большинства хакеров, практически не обращают внимания на вопросы обеспечения безопасности. И это верно с точки зрения бизнеса, потому что безопасность в данном случае, с точки зрения разработчика, никак не влияет на продажи продукта и только увеличивает срок его разработки и конечную стоимость. В результате получается простой бизнес-вывод, который подтверждается практикой нашего исследовательского центра Digital Security Research Group (http://www.dsecrg.ru), специализирующегося именно на поиске уязвимостей в бизнес-приложениях. Этот очевидный вывод состоит в том, что безопасность бизнес-приложений, по определению, на несколько порядков ниже, чем безопасность типовых ОС (Windows, UNIX).

Взгляд с технической точки зрения:

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

В случае бизнес-приложений мы имеем дело с прямо противоположной ситуацией, когда системы в большинстве своём закрыты, а проверкой их безопасности, в лучшем случае, занимается сам производитель (что само по себе - редкость для российских компаний-разработчиков) или квалифицированный администратор. С одной стороны, это даёт некую иллюзию защищенности, так как злоумышленник не знает, как именно работают эти “закрытые системы” и, соответственно, не знает, как получить к ним неправомерный доступ. Но это мнение ошибочно, так как подход “Security through obscurity” (Безопасность, основанная на скрытии механизмов защиты) в корне не верен, и примеры тому повсеместны. Наша многолетняя практика наглядно подтвердила вышесказанное, показав, что за время работ по анализу защищённости различных специфичных бизнес-приложений, работающих как в банковской, так и в топливно-энергетической и в ритейл сферах, мы находили множество таких тривиальных и при этом крайне опасных брешей в архитектуре безопасности. Подобные уязвимости редко встречаются в публично доступных системах, которые постоянно подвергаются всестороннему анализу как специалистов по безопасности, так и хакеров.

Миф 4. Безопасность ERP – это матрица SOD. У нас есть SOD – у нас нет проблем с безопасностью.

Взгляд с точки зрения бизнеса:

Пожалуй, самый типовой и крайне опасный миф, который устоялся именно у представителей бизнеса, состоит в том, что между понятием безопасности ERP и наличием продуманной матрицы SOD ставится знак тождественного равенства. То есть, бизнес наивно полагает, что для обеспечения безопасности ERP системы достаточно пригласить консультанта, который разработает и внедрит матрицу SOD, и таким чудесным образом вся ERP-система сразу станет безопасной. Бизнесу такое заблуждение простительно, техническим специалистам – нет. Для бизнеса можно привести простую аналогию – разве установка правильных прав пользователей на контроллере домена является панацеей для безопасности информационной системы в целом? Очевидно, что нет. И для ERP это не менее очевидно. Бизнес должен очень четко понимать, что матрица SOD – это не более чем один из многих важных элементов обеспечения безопасности ERP-системы. В противном случае, ERP система с матрицей SOD будет напоминать дорогие стальные ворота с дорогой современной системой контроля доступа и видеонаблюдения, установленные в чистом поле. И мы здесь никоим образом не утрируем – это прямая аналогия печальных последствий для бизнеса данного мифа о панацее матрицы SOD.

Взгляд с технической точки зрения:

Говоря об уязвимостях бизнес-приложений, необходимо рассматривать различные уровни, на которых это приложение работает. К таким уровням относятся:

• Сетевой уровень
• Уровень операционной системы
• Уровень СУБД
• Уровень самого бизнес-приложения или ERP-системы
• Уровень дополнительных компонентов и Web-приложений
• Уровень клиентских компонентов ERP-системы

Недостатки хотя бы на одном из данных уровней могут привести к полной компрометации системы даже в случае идеально настроенной матрицы SOD. На сетевом уровне уязвимостью может являться отсутствие шифрования данных при передаче, на уровне ОС - отсутствие последних обновлений безопасности, на уровне СУБД – стандартные пароли и прочее. Таким образом, рассматривая безопасность бизнес-приложений, нужно рассматривать систему в комплексе.

Заключение

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

наверх