Assessing a New App Infrastructure

Computerworld - For several months, my company has been upgrading to Oracle 11i. This is no trivial task, since we have dozens of critical revenue-generating applications that depend upon a successful upgrade and migration. A couple of weeks ago, the applications were ready to go live, and it was time for me to conduct a security assessment and mitigate any critical issues.
Oracle 11i provides for an Internet-based application infrastructure. Previously, we had to use mainly client-based applications. That was always a problem, because it required each user to download and install the software he needed. Many users ended up with a dozen or so applications on their workstations, leading to performance problems and troubles when there were upgrades or patches.
Now we will have a single Web-based interface into the various modules users may need. A user in the finance department, for example, can click on a link that will take him to the accounts receivable, general ledger or accounts payable applications, assuming he has access clearance. Other employees will be able to enter expense reports or procure equipment from a single browser window.
Of course, new deployments always require an assessment. In this case, this is even more critical, since vulnerabilities are typically more prevalent in Web-based applications.
Our practice is to divide our assessments into three core areas: architecture, system and application.
As part of the architecture audit, we typically obtain all network diagrams, flowcharts, firewall rules, lists of administrators and accounts, and so on. We then take a rule-of-least-privilege approach. For example, when we understand how each application interacts with other areas of the infrastructure, we ensure that firewall rules allow for nothing more or less than the proper operation. We then look at the manner in which privileged accounts are identified, managed and audited, making sure that users are configured with the appropriate permissions according to function.
Next is the system audit. This entails running a variety of commercial and open-source tools against each system to ensure that they're installed without deviation from our security baseline and that administrators haven't made modifications that might leave a system vulnerable. For example, administrators sometimes create a ".rhosts" file in their home directory and place a "+" in that file. The .rhosts file allows the admin to connect to the server with utilities such as rlogin without supplying a password, but a "+" in that file lets anyone connect to the server without a password. It's convenient for the admin, but it's a security no-no. Just prior to going live,