Application Design Guidelines

• Introduction
• Application Development Lifecycle
• Application Design Considerations
• Firewall Considerations
• System Considerations
• Auditing/Logging Considerations
• Security Model Considerations
• Source Code Retention

Introduction

Security can be achieved through many methods. This document is intended to provide guidelines for application development from a security perspective. Developers are expected to utilize this document when preparing for each phase of the application development life and the Security Design Review (SRD) document.

At the K&J in our client / server environment, there are several ways to access data – applications; ODBC enabled programs and utilities (e.g. MS Access, MS Excel, etc.); SQL+; and Unix / telnet sessions. With this in mind, it is impossible for applications to provide total security for data. As such, the fundamental or rudimentary security of data must be based on the security provided by the database. Applications can further restrict, control access to the data, or provide advanced editing functions not available or utilized at the database level.

Application Development Life Cycle

Security should be considered at every step of the application development life cycle and the Security Administrator should be contacted for assistance.

Initiation – During Initiation, basic security aspects should be developed. A sensitivity assessment should be performed during this phase. The following are sample questions that should be answered:

1. What is the potential harm that can occur though error, unauthorized disclosure or modification (both intentional and unintentional) or unavailability of the data or system?
2. Are their any regulatory requirements for security, such as FCRA, SEC, ACH, etc?
3. Are their particular threats that make the data or systems vulnerable, such as running on a Web server?

1. Determining security features, assurances, and operational practices – giving consideration to laws, policy, standards, guidelines, functional needs, and cost-benefit.
2. Incorporating these security requirements into design specifications.
3. Acquiring the system and related security activities – this includes design review, documenting new requirements, confirming operational changes, confirming interaction with current systems, and the preparation of test documentation (define and document systems test and acceptance test procedures).

1. Install or enable security controls.
2. Security testing – penetration and functional testing.
3. Security Certification – formal testing by an independent (other than the developer) reviewer. The results are used to support the next step of accreditation.
4. Accreditation – the formal authorization by the accrediting (management) official for system operation and an explicit acceptance of known risks.

1. Performing periodic backups, conducting training sessions, maintaining user administration and access privileges.
2. Operational assurance – the process of reviewing an operational system to ensure the security controls function correctly and effectively.
3. Perform periodic re-accreditation.

Application Design Considerations

There are two basic methods for applications to access data, described below. First, an application may log a user directly into a database. From an auditing perspective, this is the preferred method. Secondly, an application logs into the database using a common system ID, on behalf of the user.

1. The application logs a user directly into the database.

Advantages

• The database knows the user based on the users ID.
• Auditing features of the database can be used.
• User privileges can be reported directly from the database.

Disadvantages

User will have access (e.g. MS Access, ODBC, etc.) to data outside of the application. This is of concern; particularly if the application provides advanced editing functions.

2. The applications logs into the database using a common system ID. Prior to this, the application may validate a user by logging with the user’s ID and password, then switches control to the common system ID.

Advantages

• User cannot access the data outside of the application (e.g. MS Access); hence user cannot make changes directly to the database.

Disadvantages

• The database cannot track the user because the application is using a common system ID. All database usage appears to come from the common system ID.
• Database auditing is useless for identifying specific users.
• Requires the application to provide auditing / logging.
• The common system ID must have the maximum security privileges (select, insert, update, and delete) allowable for the tables used in the application. This makes the common system ID vulnerable and a security issue.
• Multiple developers may know the password to this powerful ID.
• Expiring password (see below) may cause an application to cease running.

Expiring passwords is another application design consideration. After a specific time period, systems and databases will expire passwords. All applications must be designed to accommodate the expiration of passwords.

Firewall Considerations

If an application runs on a Web Server, special requirements may require coordination with Technical Services. For example, the application may need to be configured with a specific IP port number, allowing the firewall to pass data through the firewall.

System Considerations

Changes to system configurations may need to be coordinated with Technical Services. As with firewalls, systems may need to listen for specific IP ports. When a system receives a packet with an incorrect IP port, the system should drop the packet. Also, Auditing and logging should be considered when performing system capacity planning.

Auditing / Logging Considerations

Through the sensitivity assessment in the Initiation phase, a list of items to be audited or logged should be developed. The data access method used by the application will dictate whether the database or the application performs the auditing / logging function. Auditing and logging should be considered when performing system capacity planning.

Security Model Considerations

Roles are created in the database to provide groups of users the appropriate access to the database. Database roles are assigned to users. Specific access (select, insert, update, and delete) privileges are granted to roles. Developers or business managers must provide the relative information about the relationship of the roles, tables, and privileges. The Security Administrator builds the Security Model from this information.

For example, the FINANCIAL_ONLY_SELECT role has SELECT privileges on all of the financial tables, (tables that begins with tyyyy, where "t" is the insurance type and yyyy is the year of capture). Any user assigned to this role will have SELECT privileges to the financial tables.

Source Code Retention

All application source code is an important and vital K&J asset. In order to protect this asset, all application source code, scripts, etc. must be stored in PVCS Version Manager.