Department of Environmental Protection

STD-09061813.1.0 Page 1 of 16

Application Security Requirements

Purpose
This document provides developers, security managers and product evaluators the minimum security requirements that all applications deployed in the DEP enterprise environment must comply with.

Scope
An application is defined as a System or network-level routines and programs designed by (and for) system users and customers that support specific businessoriented processes, jobs, or functions. An application can be general in nature or specifically tailored to a single or limited number of functions. This standard applies to all applications deployed in the DEP enterprise environment, whether developed internally or by external vendors. This standard also applies to commercial off-the-shelf software products. The security requirements contained in this standard relate directly or indirectly to Application Development and/or Deployment. They originate from the DEP Directive 390: Information Resources Security Policies and Standards and best security practices.

Standard
Before being deployed in the DEP enterprise application environment, project teams must complete the security checklist requirements included in the Appendix of this standard. Project teams must submit the completed checklist to the DEP Information Security Manager for review and approval before deploying any application in the DEP enterprise environment. For DEP internally-developed Java software applications, existing standards for Java development enforce compliance with this standard. Therefore, it is not necessary to complete the required security checklist required by this standard.

Deviation from Use

Any deviation from this standard shall be documented in associated project and contract documentation. For contracts, deviation from standard shall be documented and approved by the DEP contract manager. For non-contract work, deviation from use shall be documented in the project plan/scope of work and approved by the project manager.

Appendix

Checklist: Security Requirements for Applications Approved by R. John Willmott, CIO __________6/18/09_____________ Approval Date

Page 2 of 16

Appendix Checklist: Security Requirements for Applications

Instructions: Complete the following checklist and submit to the DEP Information Security Manager for review and approval before deploying any application in the DEP enterprise application environment. Indicate if the application under evaluation meets, performs or complies with the intent of the given policy by stating Yes, No, or NA for each listed policy or statement. Attach comments to clarify statements as needed. Vendor Product or DEP application name: _______________________________________________________

Policy Source DEP 390

Security Category Access Control

Policy Statement Access to data files and programs will be limited to those individuals authorized to view, process, or maintain particular systems. The principles of least access, separation of functions, and need to know will be applied in the determination of user authorizations. A user will be allowed to manipulate data only in constrained ways, which are designed to preserve or ensure the integrity of the data and the process.

Specific Requirements Each user of an information resource that can be accessed by multiple users will be assigned a unique user identification code or username and password. Exceptions are authorized for: Public users of information resources or group users where such access is authorized; Situations where risk analysis demonstrates no need for individual accountability of users.

Question to Pose Developer Are unique identification codes and passwords provided by the multi-user application or system, such that only authorized users have access? For financial or other applications that may be susceptible to fraudulent activities, is there adequate separation of functions to ensure controlled execution? Are audit logs created by the application or system to ensure transactions are date/time stamped along

Yes/No/NA

Appendix Security Requirements Checklist Page 3 of 16

Policy Source

Security Category

Policy Statement For tasks that are susceptible to fraudulent activities or other unauthorized activity, owners will ensure adequate separation of functions for controlled execution. Evidence, such as signatures, will be required to show individual accountability for transaction origination, authorization, and approval for financial, critical or sensitive information. User identification will be authenticated before the system grants the user access to information available through that system. If transaction controls are required, the user identification code will be traceable to the user for the lifetime of the records and reports in which they appear.

Specific Requirements

Question to Pose Developer with who made the transaction?

Yes/No/NA

DEP 390

Access Control

DEP 390

Transaction Controls

Are users IDs and passwords used to authenticate authorized users before access to the appropriate level of access? For financial or other applications that may be susceptible to fraudulent activities, is there adequate separation of functions to ensure controlled execution? Are audit logs created by the application or system to ensure transactions are date/time stamped along

Appendix Security Requirements Checklist Page 4 of 16

Policy Source

Security Category

Policy Statement

Specific Requirements

Question to Pose Developer with who made the transaction?

Yes/No/NA

DEP390

Software and Proprietary Code Control

Contracts for programming work by outside personnel will indicate ownership of all rights to the software and associated documentation. Contracts with vendors of licensed or proprietary software will clearly define the limits of use of the software. Information exempted from Government-in-the-Sunshine or Public Records Laws should be kept confidential using appropriate security measures including in part: Passwords, permissions, access/user IDs, transaction controls, firewalls, and encryption; Avoiding the transmission of confidential information via IT Resources, unless encrypted

During the initial application needs phase, has it been determined who will own the finished application? Is it documented?

DEP 390

Confidentiality

Data which is exempted from disclosure under the Freedom of Information Act Public Law 93-502) or whose disclosure is forbidden by the Privacy Act (Public Law 93-579) will not be transmitted over the Internet unless encrypted (Florida Statutes 815 and 119.07). Note: Logon IDs and passwords are classified as sensitive information as per the Data Security Policy (STO-2002-85-9). No state computer or subnet that is accessible via the

Will the application create, store, transmit, or present confidential or sensitive data? If so, what means will be used to prevent unauthorized access? How will it be transmitted securely? How will it be stored securely?

Appendix Security Requirements Checklist Page 5 of 16

Policy Source

Security Category

Policy Statement

Specific Requirements Internet shall store private or sensitive information without the use of firewalls or some other means to protect the information.

Question to Pose Developer

Yes/No/NA

DEP 390

Confidentiality

A sufficient history of transactions will be maintained for each session involving access to critical or confidential information to permit an audit of the system by tracing the activities of individuals through the system.

In addition to system start-up and shutdown times, transaction history journals for critical or confidential information should log the following at a minimum: Update transactions, Date, time of activity, User identification, Sign-on and sign-off activity, and Confidential display transactions.

How will application transactions be recorded/logged to permit auditing? When will these transactions be made available or readable by authorized staff?

DEP 390

Password Control

Passwords must never be encrypted when electronically stored or if e-mailed; never clear text.

DEP 390

Password Control

Strong passwords will be used and shall have these minimum characteristics:

Does the application generate passwords or otherwise store them in a database or file? If so, are they encrypted? Are they transmitted encrypted? Does the application requiring a password use a system or method that ensures a minimum strong

Appendix Security Requirements Checklist Page 6 of 16

Policy Source

Security Category

Policy Statement Have a length of 7 or more alphanumeric characters for Windows based systems, 8 or more for Unix based systems Contain both upper and lower case characters (e.g. a-z, A-Z) Have digits and punctuation characters as well as letters (e.g. 0-9,!@#$%^&*(){}[] :;<>?,./) Are not words in any language, slang, dialect, or jargon All user-level passwords (e.g., email, desktop computer, etc.) must be changed at least every 90 days.

Specific Requirements

Question to Pose Developer password is required by the user?

Yes/No/NA

DEP 390

Password Control

*may only apply at user level, not application level.

DEP 390

Password Control

Passwords shall be treated as sensitive confidential information and shall not be shared with anyone. Passwords must not be stored in readable format on any system. Application developers must ensure their programs contain

DEP 390

Password Control Password Control

Does the application expire passwords within 90 days or uses a system whereby users must changes passwords within this period? Are passwords handled as sensitive confidential by encrypting during collection, storage, or transmission? Are passwords stored encrypted? Does the application allow role management to ensure

DEP 390

Appendix Security Requirements Checklist Page 7 of 16

Policy Source

Security Category

Policy Statement the following security precautions: 1) Should support authentication of individual users, not groups 2) Should not store passwords in clear text or in any easily reversible form 3) Should provide for some sort of role management, such that one user can take over the functions of another without having to know the others password Controls will be established to ensure the accuracy and completeness of data. User management will ensure data comes from the appropriate source for the intended use. The owner will establish controls commensurate with the value of information being maintained in the system.

Specific Requirements

Question to Pose Developer authorized staff can obtain access without knowing the others password for the purpose of data recovery or system maintenance? Does the application ensure that authentication is at the user level, not group level, to ensure accountability by user?

Yes/No/NA

DEP 390

Data Integrity

Examples of controls are: parity checks, control totals, selected field verification, time stamps and sequence numbering, reconcile data submitted against data processed and returned, batch log of data submitted for processing, and encryption of stored data. Examples of controls are:

Are controls established to ensure the integrity of data entered by authorized users is obtained, transmitted, and stored?

DEP390

Transaction

Owners will establish

What transaction controls

Appendix Security Requirements Checklist Page 8 of 16

Policy Source

Security Category Controls

Policy Statement transaction controls commensurate with the value of information being maintained in the system.

Specific Requirements

Question to Pose Developer are in place to ensure information is controlled commensurate with its value? If related to financial data, are transactions recorded, along with the user identification, in order to track responsibility of each transaction?

Yes/No/NA

design, implementation, operation, maintenance and use of system acting as a check upon each other; access rights to data and programs based on specific job requirements of users as well as data processing organizations; separation of responsibilities to prevent a single individual from violating the protection mechanisms of the system; not allowing information processing personnel to originate or authenticate transactions; separate responsibilities of development, testing, and maintenance; and restrict programmers and analysts from having unlimited access to programs and data files used for production runs.

Appendix Security Requirements Checklist Page 9 of 16

Policy Source DEP390

Security Category Testing

Policy Statement

Specific Requirements

Question to Pose Developer

Yes/No/NA

DEP390

Testing Controls

DEP390

General Application Security

The test environment will be kept either physically or logically separate from the production environment. Copies of production data will not be used for testing unless the data has been desensitized or unless all personnel involved in testing is otherwise authorized access to the data. All program changes will be approved before implementation to determine whether they have been authorized, tested, and documented Network access to an application containing critical or confidential data, and data sharing between applications, will be as authorized by the application owners and will require user authentication validation. The owner of applications containing non-critical or non-confidential data will likewise establish criteria for access and user validation,

Are the application development, testing, and production environments separated?

Are change management processes established to ensure program changes are tested and approved before production? Are only authorized users allowed access through proper validation, to the application containing critical or confidential data?

Appendix Security Requirements Checklist Page 10 of 16

Policy Source

Security Category

Policy Statement particularly on systems authorized for public use. While in transit, information which is confidential or information which in and of itself is sufficient to authorize disbursement of state funds will be encrypted if pending stations, receiving station, terminals, and relay points are not all under positive state control, or if any are operated by or accessible to personnel who have not been authorized access to the information, except under the following conditions: The requirement to transfer such information has been validated and cannot be satisfied with information, which has been desensitized. The Department Head has documented his acceptance of the risks of not encrypting the information based on evaluation of a risk analysis, which evaluates the costs of encryption against exposures.

Specific Requirements

Question to Pose Developer

Yes/No/NA

DEP390

Encryption

Compliance with the STO Encryption Policy is mandatory for all agencies. DEP must determine if it has data which requires the protection dictated here.

Does the application involve the collection, transmission, or storage of confidential information or state fund disbursements data? If so, is the data encrypted such that only authorized users are allowed access?

Appendix Security Requirements Checklist Page 11 of 16

Policy Source

Security Category

Policy Statement

Specific Requirements

Question to Pose Developer

Yes/No/NA

Best Practice

Encryption

Best Practice

Encryption

Best Practice

Encryption

DEP390

Data Backup

The need for encryption will be determined based on risk analysis. Activities that store or transmit sensitive information may require encryption to ensure that the information remains confidential. These activities might be part of a mainframe client/server application, sending information via the Internet, or the protection of an individuals e-mail and personal files at the desktop. Encrypt information placed on an external public network (e.g. Internet) if confidential or sensitive, or required by Federal regulations on consumer privacy. The same applies for Intranets when information should not be viewed by the general computer user. An individual user must use approved encryption products and processes for sending encrypted mail, protection desktop files, etc. Data and software essential to the continued operation of

If the application will handle confidential /sensitive information, are there provisions to ensure the information is first encrypted?

Examples of such information is HR data, health related data on individuals, audit trails/logs, security event data, passwords, etc.

If the application contains or presents confidential information, is it encrypted to ensure only authorized users can access it?

May apply to application development?

If encryption is required, do the methods and tools used for encryption follow the established standards? Are backup procedures and schedules

The information owner will determine what information

Appendix Security Requirements Checklist Page 12 of 16

Policy Source

Security Category

Policy Statement critical agency functions will be backed up. The security controls over the backup resources will be as stringent as the protection required of the primary resources All critical information resource functions crucial to the continuity of governmental operations should have written and cost-effective disaster recovery plans to provide for the prompt and effective recovery of these critical functions after a disaster has occurred. The owner will establish appropriate information security controls for new hardware systems. Each phase of systems acquisition will incorporate corresponding development or assurances of security and appropriate controls relating to security, development and documentation. Computer security needs must be addressed as part of the Information Systems Development Methodology

Specific Requirements must be backed up, in what form, and how often, in consultation with BIS

Question to Pose Developer incorporated into the planning, based on the value of the information?

Yes/No/NA

DEP390

Disaster Recovery / business resumption

A backup recovery plan for each application should exist as part of the agency overall COOP business recovery plan.

Are backup tapes scheduled and recovery plans drafted specific to the needs of the application such that it could be fully recovered and brought back into production?

DEP 390

Hardware System Acquisitions

If new hardware systems are bought to support the application, are all security configurations set and adequate on the system, to ensure hosted applications are not compromised?

DEP 390

Application Development

Is application security addressed throughout the ISDM process?

Appendix Security Requirements Checklist Page 13 of 16

Policy Source

Security Category

Policy Statement (ISDM) when developing new or making modifications to existing applications if the system or data affected by these applications must be protected from accidental or malicious access, use, modification, destruction, or disclosure. Ensuring the privacy, confidentiality, security, and integrity of the data to the satisfaction of the audience and legal authorities. Systems designed to hold applications or other services must have virus protection.

Specific Requirements

Question to Pose Developer

Yes/No/NA

Best Practice

Data Content

DEP 390

Virus Protection

DEP 390

Security Training

Best

Audit Features

Personnel responsible for information technology resources must be aware of the Information Security policies and must be knowledgeable about effective security practices for the technical environment under their control. Audit Features are enabled.

When new development requires services and other computer hardware, the owner must ensure virus protection is applied and maintained to the hosting system. Application users must be knowledgeable of their security responsibilities, based on the level of access given, etc.

Does the application host have virus protection?

Are application users trained on their security responsibilities as it relates to the use of the application?

Related to applications

Appendix Security Requirements Checklist Page 14 of 16

Policy Source Practices

Security Category

Policy Statement The audit log captures the following: repeated failed login attempts, unusual processes run by users, unauthorized attempts to access restricted files, processes that are run at unexpected times, processes that terminate prematurely, unusual processes, unexpected shutdowns, and unexpected reboots. Administrators Account is locked out after 3 bad logon attempts.

Specific Requirements

Question to Pose Developer

Yes/No/NA

Best Practices

Administrator Accounts

An application has an administrator account. Those accounts should lock out after 5 failed logins, to prevent brute force attempts to obtain access.

Do applications limit admin accounts to five failed log ins?

Best Practices

User Accounts

The user is locked out after 3 bad logon attempts.

Do applications that require access control limit a users failed attempts to 3 and lock out?

Documentation and business justification for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure. Examples of insecure services, protocols, or ports include but are not limited to FTP, Telnet, POP3, IMAP, and SNMP. Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks.

Appendix Security Requirements Checklist Page 15 of 16

Ensure that all system components and software are protected from known vulnerabilities by having the latest vendorsupplied security patches installed. Install critical security patches within one month of release. Establish an access control system for system components with multiple users that restricts access based on a users need to know, and is set to deny all unless specifically allowed.

Appendix Security Requirements Checklist Page 16 of 16