Digital White Papers

October 2013 Risks and Rewards

publication of the International Legal Technology Association

Issue link: https://epubs.iltanet.org/i/192213

Contents of this Issue

Navigation

Page 42 of 46

FIVE STEPS TO BUILT-IN XXXX SOFTWARE SECURITY network compartmentalization, followed by disabling of SMTP, HTTP and other services on the test system, and finally Active Directory controls. The QA team also needs to ensure production data are guarded safely before being used in tests (e.g., if a tester forgets to disable the application-level email service and an email message gets generated to the customer, the second layer of SMTP disablement will ensure the message does not get delivered). SECURITY IN THE SOFTWARE DEVELOPMENT LIFE CYCLE The security scanning process must run in the context of the existing development cycle. Staying within the existing process allows for higher visibility of security defects and makes it easier for the team to address and fix defects with existing familiar processes. Some key areas are: Security Defects: Security flaws should be entered as regular defects in the product team's defect tracking system using the same defect severity rankings as the rest of the product feature defects. A defect's severity can carry over directly from the risk framework, or it can be mapped to existing defects. For example, if the risk framework has a "security flaw" categorization of very high and high severity as a must-fix for the project, while the project team has a "feature defect" categorization of very high with high severity as a must-fix prior to customer release, then a straight one-to-one mapping can exist. Very high defects noted from the security scanning system get entered in the product defect system as very high as well. The Security Scan Process: From a development perspective, the static scan, runtime scan and the penetration test all work hand-in-hand. If the static scans and runtime scans are done regularly and the defects are fixed, the chance a penetration test will uncover a major flaw is reduced. Typically, the team would upload the code to scan and analyze the results during the first sprint cycle. The defects would be fixed and tested in the next sprint cycle. In sprint three, the code would be uploaded again to verify the previous fixes and tests for defects in new code. The cycle would repeat again beginning with sprint four. Project Milestones: Finally, the security requirements should be reflected in the project delivery gates and milestones. Security can be treated similarly to other non-feature activities such as performance, upgrade, etc. SECURITY IS BEST BUILT IN RATHER THAN TESTED OUT Security should never be an afterthought. Start at the beginning; build in security right from the getgo, and test it throughout the life of your project. SECURITY SCANNING IN THE AGILE WORLD George Viegas is the Director of Regular Sprints Beta Static Scan ✓ Static Scan ✓ Static Scan ✓ Runtime Scan ✓ Automated Static Scan ✓ Automated Static Scan ✓ Runtime Scan ✓ Static Scan ✓ Runtime Scan ✓ Penetration Test (Optional) Architect Review Analyze Upload Code Static Scan Process Team Review Team Fix Defect(s) Hardening Sprint/Release Information Security at Thomson Reuters ELITE and has a passion for proactive and preventive approaches to information security. Prior to this position, George spent many years building the antimalware infrastructure for the security response team at Symantec Corporation. George can be contacted at george.viegas@thomsonreuters.com.

Articles in this issue

Links on this page

Archives of this issue

view archives of Digital White Papers - October 2013 Risks and Rewards