Infosecurity Moscow 2009: Безопасность ERP

1 октября побывал на конференции, был соведущим круглого стола "Основные проблемы безопасности бизнес-приложений и ЕRP-систем". Фактически я всего лишь сказал вступительную речь и пытался выкрикивать комментарии на возникающие у аудитории вопросы. Речь моя, конечно, не слово в слово, приводится в конце данного поста. В двух словах она о том, что в случае ERP совсем недостаточно защитить ОС и приложение, закрыть все порты и поставить патчи и антивирус, - сама логика работы бизнес-приложения может содержать уязвимости и никакие технические контроли эти уязвимости не закроют. Причем эффект от закрытия уязвимостей бизнес-процессов несравненно больше, чем от закрытия технических, тогда как и те и другие стоят денег... Я проверил это на собственном опыте разбора случаев мошенничества с использованием информационных систем и нисколько в этом не сомневаюсь.
У меня вызывает улыбку тот факт что и та, единственная публикация, которую я нашел в Сети и общий ход круглого стола в итоге имели приоритет именно в сторону технических контролей, анализа технических уязвимостей, тогда как уязвимостям бизнес процессов был посвящен только один доклад по SOD-конфликтам. Вероятно, связано это с тем, что у нас есть хорошие технические специалисты и хорошие бизнес-менеджеры, а вот на белых шляп с пограничными знаниями - не хватает :-(. Надо работать над собой.

Мое вступительное слово.
Мы много говорим о безопасности системного ПО, сетевого оборудования и прочих инфраструктурных вещах. Согласен, что ИТ-инфрастуктура представляет собой фундамент построения любого, используемого в Компании, бизнес-приложения, а в случае низкого качества фундамента не стоит питать надежды на высокую надежность всего строения. Но, ситуация такова, что непосредственно бизнес-данные, защиту которых необходимо обеспечить, хранятся и обрабатываются именно в приложении, что, на мой взгляд, предъявляет к нему определенного рода требования по безопасности. О чем сегодня и пойдет речь.
Ни в коем случае не желаю унизить необходимость высокого уровня безопасности инфраструктурных систем (системного уровня), поскольку они выступают гарантом эффективной работы механизмов обеспечения безопасности бизнес-приложений (прикладного уровня).
Почему мы должны говорить о ERP?
1. Википедия: "В основе ERP-систем лежит принцип создания единого хранилища данных, содержащего всю корпоративную бизнес-информацию и обеспечивающего одновременный доступ к ней любого необходимого количества сотрудников предприятия, наделённых соответствующими полномочиями". Помимо того, что там ВСЕ данные, там работают ВСЕ сотрудники! Очевидно, что при таком положении вещей проблемы конфиденциальности, целостности и доступности стоят особенно остро.
2. ИТ - сервис бизнеса. Само по себе ИТ (в непрофильной компании) не нужно, так как не приносит дохода. Не нужны сети и корпоративные каталоги (MS Active Directory) сами по себе, они - лишь вспомогательные средства, необходимые для работы бизнес-приложений/ERP-систем. А именно они [бизнес-приложения] необходимы для эффективной работы бизнеса.
3. Исторически сложилось, что инфраструктурные системы защищены лучше, чем бизнес-приложения. Попробую подумать вслух почему:
- Инфр. системы используются практически всеми, тогда как бизнес-приложения - нет.
- Инфраструктурные системы могут использоваться в агрессивных средах (интернет), как следствие их безопасность - конкурентное преимущество; у бизнес-приложений основное - функциональность, и безопасность не является конкурентным преимуществом.
С т.з. ИТ-безопасности, факт, но бизнес-приложения защищены значительно хуже.
4. ERP-системы, будучи используемые бизнесом имеют еще одну немаловажную особенность, - уязвимости бизнес-процессов. Причем такие уязвимости не закрываются никакими техническими контролями. Аналогия здесь может быть такова: представьте, что у нас есть ограждение, которым мы гарантируем, что из-за заграждения невозможно проникновение. Техконтроли гарантируют, что забор достаточно прочен, чтобы его сломать, и высок, чтобы его перелезть, тогда как контроли бизнес-процессов должны гарантировать, что в заборе нет "легитимных" калиток/лазеек, чтобы он конструкционно был совершенен. Для обеспечения эффективной работы бизнес-процессов, исключая факты мошенничества, техконтроли не помогут, - и в этом, на мой взгляд, основная специфика бизнес-приложений в целом, и ERP в частности. Т.е., помимо того, что Система должна быть технически совершенной (чтобы хакеры не проникли в обход имеющихся механизмов ИБ), имеющиеся механизмы должны предоставлять возможность и быть настроены так, чтобы максимально снизить возможность мошенничества со стороны легитимных пользователей.

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

User Roles in SAP R/3

I’ve been reviewing a number of projects with SAP R/3 in a company I work for and found what seems to be a very big mistake in user rights planning and implementation. I raised this many times but still have no response from our ‘SAP gurus’, probably because their main task is to finish project and move on or maybe because they’re not experienced enough. I don’t know and it’s not my headache, but I think that the problem I’m going to explain is obvious.

The thing is that each project produces a number of roles, and authorizations (piece of privileges) are spread over these roles. During a test phase these roles are tested either by user without additional roles or by user with roles from the same project. I haven’t seen anybody testing roles from one project together with roles from different project. Unfortunately, SAP has weird system of authorizations – there are authorizations to access Objects, to perform Actions (transactions, programs) etc. So, to perform an action upon an object through specified transaction you have to have authorization for Action and for Object. To deny this action it’s enough not to have privileges for Action or for Object.

When a user has a number of roles, authorizations in these roles are added together, and in the end it’s possible for user to gain more capabilities than she should have. Maybe it is hard to understand, but it is really possible in SAP if you have, for example, authorization for Object in one role and authorization for Action in another.

We may significantly reduce the probability of such ‘authorization summation’ by adding each authorization into role manually but it’s very time-consuming. It’s much more easer to build role from menu or use other automated role-generation tools. If we were too lazy to create roles manually we could test all combination of roles to fix ‘authorization summation’ issue. But it would be very difficult!

Well, I see the only solution in this case – make one role for one user. I know this is not what SAP recommends (I attended "CA940: SAP R/3 Application Security Concept"), but in complicated environment where there are thousands of users and thousands of roles from different projects, to my mind, it is the only solution. This strategy can withstand the following common issues:

• authorization summation – you need to test only one role for one user;
• some employees do more than specified in their job description, and in this case you just add authorizations into one role for that user. To my mind, it’s more secure than add whole additional role never being tested in combination with others that user already has;
• you get more flexibility: if roles in project were developed in connection with organizational structure they wouldn’t fit when organization's structure changes. In "one role–one user" situation – just add new authorizations for users that changed their positions.

The only bad thing here – it is more difficult to quickly finish new projects…