| Articles Home |
ERP Testing ERP Business Analysts ERP Contracting ERP Data Migration ERP Reasons to Get One ERP Forces Changes in Business Rules ERP One ERP is the same as any other ERP ERP Security is OXYMORON ERP The Whole is Bigger than the Parts
Here is a short article on what to do about ERP security if you have to administer a system, application or database associated with an ERP. Just because I look at Baan today does not mean that PeopleSoft or SAP or any ERP is any better. I am just using Baan as an example.
Security in Baan installed on Unix is laughable. The rest of the ERP products have the same problems. All of Baan's security effort is concentrated in a layer of application code that controls access to "screens", the Baan forms user interface. And it is a huge pain to setup and administer. But it is easy to bypass if you have the installs I have seen done by Baan employees and third party contractors from the "big five minus one". I will look at a single massive problem that can easily deny service. In Baan the file system is wide open. Most files are read-write group. Application code, config files, temporary files, everything. All users belong to that group. This means that Baan's security is so bad that the integrity of the whole system is wide open to disruption by the users of the system by inadvertently typing in simple user commands. So the problem can be defined as "How can a user accidentally hit the file system and destroy it." A constraint on corrective action is that immediate change of file privileges will break the ERP application with high probability. Changing file privileges will be a long analysis and testing process. In this example I will do the obvious. How do users usually change files? Telnet, SSH, Shell access, ftp, some sorts of application access. In ERPs the application access usually includes a shell interface to the OS and an "ad hoc query" interface that can sometimes punch through to the file system. So the first corrective action is get with the system administrators to secure the application host. It is quickest and easiest way to a bit of security. And least amount of configuration management. Shut down any services that allow users on the application host. Telnet, the "r" services not used (rlogin, remote shell, etc), ftp, things on ports that are left on by default, you know the drill. TCP wrap whatever is left with user/host restrictions, as there will always be some lame services used by the ERP and other stuff. Good sys admins have already done this. At the same time have the ERP application administrator remove any shell access privileges the users can get through the application client. All the ERP's can grant some type of shell access to the application host through the client. No doubt it is even the default user setup in many situations. The next thing the ERP application administrator should do is remove "ad hoc query" privileges from users through the application client for the same reasons above. The added risk factors of "ad hoc query" are performance problems from user "developing" database queries on the production environment. The easy part is done. To better protect the ERP application, especially Baan, file system privileges must be changed. For Baan, much of the file access problem can be fixed by "chmod g-w" on most of the application files outside of the configuration files and temporary files. Of course, there is much analysis and testing involved to make sure the file privilege changes do not destroy the ERP application. There are tedious exceptions that must be handled one by one. One exception is the "ad hoc query" function in Baan. Typically some poor user thinks the entire company will not function if he can't join every table to every other table in the database and effect a denial of service attack with his ad hoc query. But the queries are written to files in the heart of the Baan application files. Whatever. So by tracing file change dates you find out what few directories and files those are, put the group write back on them to shut him up. So now you are secure from some poor user mistakenly typing in "rm *" and taking out the whole Baan application. Except for the poor schmoe with the ad hoc query privileges. But now you know whose ERP sessions to kill if there are any performance problems. Real security against a determined hacker is another thing all together. This article only tries to keep ERP users from accidentally destroying the system.