Secure Computing

Internally-hosted Application Security Standards

Security Standards for Internally-hosted Applications and Systems

General

  1. Fully patched and vendor supported system software, including OS, database, web engine, and other enabling software. Also, ensure there is a process in place to always keep the system fully patched.
  2. Passwords are not hardcoded into application or stored with source code.
  3. Install and configure a virus protection solution so the server is protected and regularly updated. 
  4. Secure services and well known accounts (i.e., Administrator and guest) by either renaming the account or changing the default password. 
  5. For Windows systems ensure the hard drive format is NTFS.
  6. Remove any unnecessary protocols.
  7. Turn on auditing.

Web

Web Application Authentication

  1. SSL-enabled & the certificate are verifiable.
    - If the certificates are being used there should be a process to ensure that they are renewed in a timely manner (before expiration). 
    - Ensure there is a process for maintaining the certificate revocation lists. Also, ensure the responsibility for the certification process is known and published with contact information provided. 
  2. If the application is using SSL it must not use SSL v2 as that has known weaknesses. Disable SSL v2 and v1 on the server. See the Microsoft article on disabling weak SSL ciphers in IIS 5.0 and 6.0. http://support.microsoft.com/kb/241447/en-us.
  3. Authentication cookies are returned to the server.
  4. The user is sent to http’s’ (SSL) page *before* the password is entered.

Web site Architecture

  1. Web engine and database servers are on different hosts.
  2. Web site must not accept transactions if the certificate is invalid.
  3. Web site must employ web transaction logging as well as record logging.
  4. Configuration files and log files are kept in separate root-owned (or in the case of Microsoft, system-owned) file-systems.
  5. All data input is validated.
  6. Any CGIs or scripts are stored in a separate filesystem from the web engine.
  7. No URLs will accept variables from user input that "escape" the sticky session or allow users to access the records of another customer.
  8. Web sites will have some documented process (including an email or phone number) for people to report issues such as the site being hacked or problems with attached links.
  9. Web site content and links maintain appropriate professionalism and appropriateness. 
  10. Sites should be compatible with a variety of browsers, such as Netscape, Mozilla, Safari, Firefox and Microsoft Explorer. Such compatibility ensures that users are able to access the site when they cannot use their regular browser due to security vulnerabilities.

IIS

  1. Run the IIS Lockdown tool (if IIS less then v6).
  2. Is the URLScan tool going to be used (restricts the types of HTTP requests that IIS will process by blocking specific HTTP requests - http://www.microsoft.com/technet/security/tools/urlscan.mspx)?
  3. Remove IIS sample applications that are installed.
  4. Disable IIS parent paths.
  5. Uninstall the IIS Admin virtual folder.
  6. Do not use MSADC and Scripts virtual directories.
  7. Turn on IIS logging.
  8. Ensure any webserver does not perform another function (i.e., domain controller, etc).
  9. Disable weak SSL ciphers in IIS 5.0 and 6.0 (see Microsoft KB article http://support.microsoft.com/kb/241447/en-us).

Encryption

  1. Once an SSL session is established, all traffic between the user's web client and server is encrypted (it doesn't bounce out to an insecure session).
  2. Encryption must be done with strength of at least 128 bit. All lower levels of encryption should be disabled on the servers to ensure this minimum is kept.
  3. Where encryption is being used ensure that the encryption keys are not kept with the encrypted files or sent with them. When encryption keys are compromised then the data is being regarded as if it is not encrypted at all by many regulations and laws. 

Databases

SQL Server

  1. Take out the Administrators group from the Sysadmin role.
  2. Restrict the CmdExec role to Sysadmin only or make the xp_cmdshell disabled.
  3. Do not use a blank or simple password for the sa account.
  4. Do not allow the Guest account to have database access.
  5. Do not allow the Everyone group access to SQL Server registry keys.
  6. Do not make the SQL Server service accounts members of the local Administrators group.
  7. Try to use the SQL Server authentication mode of Windows to take advantage of the Active Directory, however if you can’t then use the Mixed mode. 
  8. Limit the number of Sysadmin role members.
  9. Ensure any WebServer does not perform another function (i.e., domain controller, etc).

MySQL Server

  1. The account root is created upon install with no password assigned. These are superuser accounts that can do anything. This means that the MySQL installation is unprotected until a password is assigned. 
    - On Windows, the root account allows connecting from the local host only. 
    - On Unix, both root accounts are for connections from the local host. 
  2. If you want to prevent clients from connecting as anonymous users without a password, you should either assign a password to each anonymous default accounts created or else remove the accounts.
    - Two anonymous are created with no password, so anyone can use them to connect to the MySQL server. 
    - On Windows, one anonymous account is for connections from the local host. It has no global privileges. (Before MySQL 5.1.16, it has all global privileges, just like the root accounts.) 
    - On Unix, both anonymous accounts are for connections from the local host. 

Default Oracle Accounts Whose Password should be changed

  • APPS Often used name for management or schema accounts for applications. In Oracle Applications it is a schema owner and has DBA-like privileges.
  • APPS_MRC A schema account from Oracle Applications. It has DBA-like privileges.
  • CTXSYS (Oracle Text/Intermedia Text/Context option) is an account with DBA privileges and therefor allows to read, change, and destroy all data in your database.
  • MDSYS Oracle Spatial administrator has DBA-like privileges. which allow to read, change and destroy all data in your database.
  • PO is an possibly account with DBA privileges, which allow to read, change, and destroy all data in your database.
  • PUBSUB An account with DBA privileges, which allow to read, change, and destroy all data in your database.
  • SAMPLE Possibly an account with DBA privileges, which allow to read, change, and destroy all data in your database.
  • SYS is Oracle's most powerful database management account. It allows to read, change and destroy all data in your database.
  • SYSMAN The management account for Oracle Enterprise Mananger. It is used as access to all databases that are managed by it. It might be possible to access data in your databases.
  • SYSTEM Oracles database management account. It allows to read, change and destroy all data in your database.
  • SYSOPER has fewer administrative privileges than SYS, but enough to perform basic operations such as startup, shutdown, mount, backup, archive, and recover.

Secure the Oracle Listener

Because the listener acts as the database gateway to the network, it is important to limit the risks from malicious intentions.

  1. Restrict the privileges of the listener, so that it cannot read or write files in the database or the Oracle server address space. This restriction prevents external procedure agents spawned by the listener (or procedures executed by such an agent) from inheriting the ability to do such reads or writes. 
    - The owner of this separate listener process should not be the owner that installed Oracle or executes the Oracle instance (such as ORACLE, the default owner).
  2. Secure administration by doing the following:
    - Protect the listener with a password.
    - Prevent online administration.
    - Use SSL when administering the listener.
    - Remove the external procedure configuration from the listener.ora file if you do not intend to use such procedures.
  3. Do not leave the Oracle Listener port 1521 open, allowing the database to connect to the Internet or the Internet to connect with the database.
  4. Prevent unauthorized administration of the Oracle Listener. Always establish a meaningful, well-formed password for the Oracle Listener, to prevent remote configuration of the Oracle Listener.