Title: Functional Category: Information Technology Services Issuing Department: Information Technology Services Code Number: xx.xxx.xx Effective Date: xx/xx/2014 1.0 PURPOSE 1.1 To appropriately manage the risks related to developing and maintaining secure systems and applications. 2.0 DEPARTMENTS / PERSONS AFFECTED 2.1 This policy applies to all Board employees and consultants/contractors with DFW with network access, who develop, support, or maintain systems and applications for the Board. 3.0 POLICY 3.1 All development and system maintenance activities shall be in compliance with: 3.1.1 All applicable Board policies 3.1.2 All applicable federal, state, and local laws, regulations and requirements 3.2 Development teams working on developing PCI applications shall develop in accordance with Payment Card Industry Data Security Standards (PCI DSS). 4.0 PROCEDURE Internal and 3 rd party development of proprietary software must utilize industry recognized best practices for software development. 4.1 Development Environments. There must be a separation between the production, development, and test environments. A test and/or development environment, separate from the production environment, must be used to test all new software (including patches). 4.1.1 Access controls must be in place to enforce the separation between the production and the development/test environments. 4.1.2 Separation of duties between personnel assigned to the test/development environments and those assigned to the production environment must be observed. 4.1.3 Sensitive production data (PCI, Personal Identifiable Information (PII), Sensitive Security Information (SSI), Electronic Protected Health Information (ephi)) will not be used for testing and development purposes without being sanitized. 4.1.4 All test data must be removed before a system goes into production. Similarly all custom test application accounts, user IDs and passwords used for testing must be removed from production code. 4.1.5 All code promotion to the production environment will be accomplished by the Systems Administration Team who provides a separation of duties with the Software Development and Maintenance Teams in performing this role. 4.1.6 All production systems must have a designated Owner and Custodian. 4.1.7 All production environments must have an access control system to restrict who can access the environment as well as restrict the privileges available to the Users. 4.1.8 Application Development Teams should not have full-time unlimited access to production applications. However, in the case that the development teams must provide support to critical applications after hours, their manager can grant them temporary access to a limited support account that they can use to troubleshoot Page 1 of 5
issues and support the application. There must be a separation of duties between the manager granting these temporary access rights and the individual who actually implements them, and the request by the manager must be documented. These temporary access rights must be revoked immediately following resolution of the application support issue. 4.1.9 All production systems must be assigned, at a minimum, a designated access control administrator (who is not a regular User on the system in question). 4.2 Change Management. 4.2.1 All changes related to implementation of security patches and software modifications to IT system components in production must be approved by the Change Management Board. In addition, they require: 4.2.1.1 Documented impact of change on Service Desk ticket and Project Deliverable Approval (PDA) form. 4.2.1.2 Approval by Data Steward 4.2.1.3 Functionality testing performed to verify that change does not adversely impact the security of the system 4.2.1.4 Documented backout/rollback plans (Service Desk ticket) 4.2.2 Under emergency situations, developers may assist in troubleshooting utilizing emergency IDs. All emergency changes must be documented using Emergency Change Control tickets and approved by the Change Management Board 4.3 Software Development Life-Cycle. All software developed in-house which runs in the production environment must be developed according to the Information Technology Services (ITS) System Development Lifecycle Methodology (SDLC). Security checks and control measures must be considered throughout the development life cycle: 4.3.1 Requirements Analysis. Developers must determine whether application requirements are inherently insecure and alert management of potential weakness. 4.3.2 Design. Application components must be planned in a manner consistent with data and network. 4.3.3 Development. Developers must consider all application vulnerabilities. 4.3.3.1 Develop software applications in accordance with PCI DSS (for example, secure authentication and logging), and based on industry best practices. 4.3.3.2 Incorporate information security measures throughout the software development life cycle. 4.3.3.3 Develop applications based on secure coding guidelines. Prevent common coding vulnerabilities including: 4.3.3.3.1 Injection flaws (particularly SQL injection, OS command injection, LDAP and XPath injection). Validate input to verify user data cannot modify meaning of commands and queues, use parameterized queries, etc. 4.3.3.3.2 Buffer overflow. Validate buffer boundaries and truncate input strings. 4.3.3.3.3 Insecure cryptographic storage for sensitive Personal Identifiable Information (PII), Sensitive Security Information (SSI), Electronic Protected Health Information (ephi), and Page 2 of 5
credit card information. Prevent cryptographic flaws for sensitive information. 4.3.3.3.4 Insecure communications related to sensitive data. Properly encrypt all authenticated and sensitive communications involving secure data. 4.3.3.3.5 Improper error handling. Do not leak information via error messages. 4.3.3.3.6 Cross-site scripting (XSS). Validate all parameters before inclusion, use context-sensitive escaping, etc. 4.3.3.3.7 Improper Access Control, such as insecure direct object references, failure to restrict URL access, and directory traversal. Properly authenticate users and sanitize input. Do not expose internal object references to users. 4.3.3.3.8 Cross-site request forgery (CSRF). Do not rely on authorization credentials and tokens automatically submitted by browsers. 4.3.3.3.9 Malicious File Execution. 4.3.3.3.10 Insecure direct object references. 4.3.4 Code Review. A second developer, other than the original author, must conduct code reviews of all new and changed software, specifically in an attempt to identify security issues. Appropriate corrections must be implemented. 4.3.5 Testing. In addition to functional and efficiency testing, all security features of the application must be tested. 4.3.6 Production. Implementation must not compromise security controls already in place, or introduce new vulnerabilities. 4.3.7 Maintenance. All future application maintenance must not compromise security controls already in place, or introduce new vulnerabilities. Any new code must be reviewed and tested as detailed above. 4.4 Web-based Applications. Additional care must be given to web-based applications as they pose threats. 4.4.1 Specifically the vulnerabilities described in Section 4.3.3.3 must be considered during the Code Review and Testing phases. 4.4.2 Whenever significant modifications have taken place, all web-based applications will be subjected to an application-specific penetration test by the Information Security Office. 4.4.3 In order to protect web-facing applications against web-based attacks, at least one of the following must be used: 4.4.3.1 At least annually or after significant change, have all custom code for web-facing applications reviewed by the Senior Information Security Manager. The application must be re-evaluated after the vulnerabilities are corrected. 4.4.3.2 Utilize a web application firewall which is able to protect at least against the OWASP top 10 vulnerabilities. 4.5 Cardholder Data Processing Applications. All custom applications dealing with the processing or retrieval of cardholder data must be designed in a manner which masks or Page 3 of 5
truncates the displayed credit card number. If cardholder data is to be masked only the first six or last four digits may remain displayed. 5.0 RESPONSIBILITIES 5.1 Department Head or Designee. Responsible for overall compliance and enforcement of this policy. 5.1.1 Manages the process required to identify, evaluate and accept, mitigate or avoid the risks associated with developing and maintaining secure applications. 5.1.2 Reviews and approves all new development requests and software maintenance requests before systems and applications are deployed in production. 5.1.3 Reviews periodically and updates Development and Maintenance of Secure Systems and Applications policy and procedures, as necessary. 5.2 Senior Information Security Manager. Responsible for identifying and maintaining the list of all Secure Systems and Applications in Production on an ongoing basis. 5.2.1 Identifies security risks, if any, as well as mitigation strategies to be deployed. 5.2.2 Performs scanning/auditing of secure applications periodically to ensure they comply with secure Application Development and Maintenance procedures. 6.0 DEFINITIONS 6.1 Department Head. Vice president or senior vice president of a department, or assistant vice president in those cases where the department is led by an assistant vice president. 6.2 Designee. Only employees in the Executive Salary structure/band (Assistant Vice President level position and above) may be appointed as designees. 6.3 Electronic Protected Health Information (ephi). As defined in Code of Federal Regulations 45 CFR 160.103, generally means individually identifiable health information that is transmitted or maintained in any electronic media. 6.4 LDAP. Lightweight Directory Access Protocol (LDAP) is an open, vendor-neutral industry standard application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) Network. LDAP injection is an attack used to exploit web based applications that construct LDAP statements based on user input. This could result in execution of arbitrary commands such as granting permissions to unauthorized queries and content modification in the LDAP tree. 6.5 OWASP. The Open Web Application Security Project is a worldwide not-for-profit charitable organization focused on improving the security of software. 6.6 Payment Card Industry Data Security Standard (PCI DSS). A worldwide information security standard defined by the Payment Card Industry Security Standards Council. Provides an actionable framework for developing a robust payment card data security process including prevention, detection and appropriate reaction to security incidents. 6.7 Personally identifiable information (PII). Per National Institute of Standards and Technology (NIST), PII is any information about an individual maintained by an agency, including (1) any information that can be used to distinguish or trace an individual s identity, such as name, social security number, date and place of birth, mother s maiden name, or biometric records; and (2) any other information that is linked to an individual, such as medical, educational, financial, and employment information. 6.8 PDA. Project Deliverable Approval (PDA) is a form used by the Board s ITS department to migrate code into test and production. Page 4 of 5
6.9 Sensitive Security Information (SSI). Information obtained or developed in the conduct of security activities, including research and development, the disclosure of which Department of Homeland Security/Transportation Security Administration has determined would, among other things, be detrimental to the security of transportation. 6.10 XPath. A query language for selecting nodes from an XML (Extensible Markup Language) document. XPath injection attacks occur when a web site uses user-supplied information to construct an XPath query for XML data. By sending malformed information into the web site, an attacker can find out how the XML data is structured, or access data that he/she may not normally have access to. 6.11 XSS. Cross-site scripting (XSS) is a type of computer security vulnerability found in Web Applications. XSS enables attackers to inject client-side script into Web pages viewed by other users. 7.0 RESOURCES / FORMS 7.1 OWASP (Open Web Application Security Project 7.2 PCI SSC Data Security Standards 7.3 PDA Form 7.4 Related Policies. 7.5 7.4.1 Data Classification Policy 7.4.2 Network and System Device Configuration Policy 8.0 REVISION HISTORY 8.1 09/25/2014 - IT. xxx.xx - Original document. APPROVED: Divisional Executive Vice President Executive Vice President, Administration and Diversity General Counsel Chief Executive Officer Page 5 of 5