As healthcare applications become more complex, their ability to manage sensitive information like patient data significantly improves. Many of these applications work over the internet, increasing the risk of data theft or exposure. It becomes important to perform security testing of the components implemented and identify the security vulnerabilities during the software development lifecycle.
Testing in the Scrum based model involves understanding of scope, architecture design, planning, coding, and functional testing. Security testing is performed before the release phase of the Software Development Lifecycle (SDLC), which increases testing costs and causes delays in product release. To manage this effectively, Agile Security Testing and ‘Shift-Left’ is gaining wider acceptance. The Agile Security Testing strategy should complement the agile development approach to achieve a stable qualitative build and have the right set of functionalities with a fair degree of security. Integrating security testing with the mainstream software development process has multiple benefits.
The key elements of Agile Security Testing in a Scrum-based software development model are:
1. In-Sprint Planning
During this phase, a security consultant understands the scope and security features required from the selected user stories. The consultant then creates test scenarios and identifies the testing toolset.
2. Secure Architecture Review
Working closely with the solution architect, the security tester initiates the architecture review of the product to provide security related features and implementation guidelines. The security tester also observes the existing features selected for security implementation, and focuses on basic principles like authentication, authorization, security of data in transit and at rest, audit logging, etc.
3. Static Code Review
Static Application Security Testing (SAST) is a white-box testing method where the application source code is reviewed for conditions which indicate presence of security vulnerabilities. SAST is performed using automated scanners (e.g., HP Micro Focus Fortify, IBM AppScan Source, CA Veracode, Checkmarx, etc.) and should support the programming languages and development frameworks in which the application is built.
SAST scanners have wide vulnerability coverage since they have access to source code and application inputs, including hidden inputs. Because of this, SAST may be prone to reporting false positives.
The static code review is the only available option during the initial stages of the sprint / release when there are no dynamic application modules available for testing. A complete scan of the source code is recommended when the code base is ready for testing before the release.
4. Dynamic Application Review
Dynamic Application Security Testing (DAST) is a black-box security testing method where application is tested from the UI in running state (from a hacker’s perspective). Security testers usually use DAST automated scanners (e.g., Acunetix, HP WebInspect, IBM AppScan, PortSwiger Burp, etc.) to access the application from outside and are mostly technology independent. Although easy to reproduce or identify vulnerabilities, DAST tools can test only vulnerabilities which send a response back to the scanner. DAST tools are prone to false negatives on missing vulnerabilities that don’t send any response back to the scanner.
Security testers then share the identified vulnerabilities along with proof of concept and mitigation options with developers.
5. End of Release Testing
The entire integrated application is available for testing and most vulnerabilities have already been identified and mitigated in previous sprints. Security testers can now perform penetration testing and automated tool-based scans to identify any remaining vulnerabilities. At the end of release testing, the team can focus on more sensitive features to verify that the product is secure. This phase includes several types of testing such as:
Implementing security testing in an agile fashion has several advantages in terms of cost and time saved by minimizing rework. The collaborative nature of agile models increases the development team’s awareness of security vulnerabilities and associated remediation plans, to ensure lesser vulnerabilities in the future.
Security testing at the time of release reveals fewer security vulnerabilities as compared to a continuous approach. The continuous approach necessitates the team to fix the issues and benefits from having the mitigation effort spread over the entire release, instead of a large and often expensive push at the end.