Policy 7230A - Department of Administration
Policy 7230A - Department of Administration Policy 7230A - Department of Administration
5.4. Application Protection The following are the Non-Mandatory Baselines that support the Application Protection section of the Default Security Requirements: 5.4.1. Apply Security Principles to Code Development To ensure that information systems offer the appropriate level of security with the greatest level of efficiency, Agencies should engineer controls into the solution during development: 5.4.1.a Standard Development Practices • Development processes should start with the creation and documentation of a secure Concept of Operations (ConOps). • Development processes should make use of documented and repeatable standards and processes. • Security training should be provided for the development team. • Quality management should be performed throughout the development process. • Code should be developed in a dedicated and secured environment. • Code should be stored in securely maintained repositories. 5.4.1.b Development Training Recommendations • Development training should address all standard development practices. 5.4.1.c Development Training Scheduling and Frequency • Secure code development training should be provided for all developers within 30 days of initial assignment of the individual to the development team. • Secure code development training should be provided thereafter for all developers on an at least annual basis. Where possible, team members will be trained together as a group. 5.4.1.d Quality Assurance • Code development quality assurance practices should focus on the following: o Cross-site scripting vulnerabilities. o Buffer overflows. o Race conditions. o Object model violations. o Poor user input validation. o Poor error handling. o Exposed security parameters. 14
o Passwords in the clear. o Violations of the stated security policy. 5.5. Maintain Records Agencies should capture documentation appropriate to all systems configuration processes: • Create and maintain a systems component and configuration inventory. • Document and retain copies of SDLC requirements. • Document and retain copies of all system implementation plans. 15
- Page 129 and 130: 4.3.2.2 Restrict Intra and Inter-Sy
- Page 131 and 132: 5.1.1.3 Actively Maintain Inventory
- Page 133 and 134: 5.1.3.3 Provide Implementation Docu
- Page 135 and 136: • Place all media in a locked con
- Page 137 and 138: 6. Systems Operation These Systems
- Page 139 and 140: 6.2. Integrity Operations The follo
- Page 141 and 142: 6.3.2. Perform Patch and Vulnerabil
- Page 143 and 144: 6.4. Maintain Records Agencies shou
- Page 145 and 146: 7.1.1.3 Require Authenticated Acces
- Page 147 and 148: 8. Incident Response These Incident
- Page 149 and 150: 8.1.2.2 Develop Supporting Strategi
- Page 151 and 152: 9. Contingency Planning No applicab
- Page 153 and 154: 10.1.1.2 Implement Physical Access
- Page 155 and 156: 11. Personnel Security These Person
- Page 157 and 158: • Review created accounts and ass
- Page 159 and 160: 11.2.4.3 Recover all Organizational
- Page 161 and 162: 12.1.1.3 Required Test and Validati
- Page 163 and 164: State of Kansas Non-Mandatory Basel
- Page 165 and 166: 6.2. Integrity Operations .........
- Page 167 and 168: Introduction This Non-Mandatory Bas
- Page 169 and 170: • High risk constitutes high like
- Page 171 and 172: 2.3. Maintain Records Agencies shou
- Page 173 and 174: 4. Access Control These Assessment
- Page 175 and 176: • Systems that have very high ris
- Page 177 and 178: 5.1.1.c System and Component Docume
- Page 179: 5.2. Systems Protection No applicab
- Page 183 and 184: o Penetration testing. o Password c
- Page 185 and 186: o The individuals to be notified. o
- Page 187 and 188: 7. Systems Audit These Systems Audi
- Page 189 and 190: eviewed weekly and every system and
- Page 191 and 192: 8.1.1.b IR Roles • IR Team Manage
- Page 193 and 194: 8.1.2.e IR Plan Update Scheduling a
- Page 195 and 196: 10. Physical Security These Physica
- Page 197 and 198: 10.2.1.b Power Delivery Specificati
- Page 199 and 200: 11. Personnel Security These Person
- Page 201 and 202: 11.2.2. Hire Employees in a Structu
5.4. Application Protection<br />
The following are the Non-Mandatory Baselines that support the Application<br />
Protection section <strong>of</strong> the Default Security Requirements:<br />
5.4.1. Apply Security Principles to Code Development<br />
To ensure that information systems <strong>of</strong>fer the appropriate level <strong>of</strong> security with<br />
the greatest level <strong>of</strong> efficiency, Agencies should engineer controls into the<br />
solution during development:<br />
5.4.1.a Standard Development Practices<br />
• Development processes should start with the creation and<br />
documentation <strong>of</strong> a secure Concept <strong>of</strong> Operations (ConOps).<br />
• Development processes should make use <strong>of</strong> documented and<br />
repeatable standards and processes.<br />
• Security training should be provided for the development<br />
team.<br />
• Quality management should be performed throughout the<br />
development process.<br />
• Code should be developed in a dedicated and secured<br />
environment.<br />
• Code should be stored in securely maintained repositories.<br />
5.4.1.b Development Training Recommendations<br />
• Development training should address all standard<br />
development practices.<br />
5.4.1.c Development Training Scheduling and Frequency<br />
• Secure code development training should be provided for all<br />
developers within 30 days <strong>of</strong> initial assignment <strong>of</strong> the<br />
individual to the development team.<br />
• Secure code development training should be provided<br />
thereafter for all developers on an at least annual basis.<br />
Where possible, team members will be trained together as a<br />
group.<br />
5.4.1.d Quality Assurance<br />
• Code development quality assurance practices should focus<br />
on the following:<br />
o Cross-site scripting vulnerabilities.<br />
o Buffer overflows.<br />
o Race conditions.<br />
o Object model violations.<br />
o Poor user input validation.<br />
o Poor error handling.<br />
o Exposed security parameters.<br />
14