Avoid data breaches by adopting a Secure Development Lifecycle
The news is awash in security breach headlines—from Equifax to Cambridge Analytica and Facebook. Such crises shouldn’t be surprising, considering that many organizations regard data security an opt-in accessory rather than a mission-critical element that needs to be factored in from the initial stages of product development.
As evidenced by diving stock prices and record corporate reparations, these hacks come at an immense cost. Organizations with imprudent security practices risk losing everything. In this article, I’ll address some smart ways companies can make security a priority and avoid data breaches.
First, developers should adopt a security mindset during all stages of product development, a practice known as Secure Development Lifecycle (SDLC). At Devbridge, we adhere to SDLC, addressing security from the get-go and prioritizing it—even for clients with their own security teams.
After all, preventing a bug is always better than fixing one later on. According to Computer Business Review, “The Systems Sciences Institute at IBM has reported that the cost to fix a bug found during the implementation stage is approximately six times more expensive than one identified during design; the cost to fix an error found after product release is then four to five times as much as one uncovered during design, and up to 100 times more than one identified during the maintenance phase.”
Consider critical aspects
When defining product requirements, keep the following in mind:
- Transport protocol: Consider data link protocols for how (data) packets move from one node to another. According to PC Magazine, transport services are defined in layer 4 of the OSI (Open System Interconnection) model, an ISO standard for worldwide communications. This model defines a framework for implementing protocols in seven layers.
- User input data and session lengths: Look at how the system stores user data—both information users enter and metrics regarding the duration of their sessions. Will the system use this information and, if so, how?
- Data security (or information security): Examine measures barring unauthorized digital access and protecting data from corruption. These will likely include backups, data masking, data erasure, encryption, and authentication.
Automate a security workflow
To reduce security costs, implement a workflow—which can be used for both types of code analysis: static (scanning the source code) and dynamic (scanning the deployed testing version). This workflow should review code to find and fix bugs, with security scanners and analyzers searching for various types and reporting back to the development team. The simplified workflow of the processes can be laid out in the following bullet points. Honoring the open security community, we’re using OWASP suite as an example:
- Static code analysis. OWASP SonarQube perfectly integrates with the development of code and can be launched either from a continuous integration (CI) environment (such as TeamCity or Jenkins) or even from a local machine. Since the scan is attached to the build process, the development has no overhead cost. After a successful build, the scan results will populate automatically.
- Dynamic code analysis. The dynamic analysis tunes in for the deployed testing environment. OWASP Zap is a great tool to achieve integration since it can be used through API. When having the whole deployment chain, after the successful push to a testing environment, the call to the scanner can be made. The URL is passed as a parameter, and later on, the scanner outputs the results to your desired destination.
- Penetration test. When static and dynamic analyses run throughout the development of the product, the final touch is a penetration test. Following the OWASP Web application security checklist, the analysis is performed for the product. Since the automated scans look for low-hanging fruits, the manual test can focus more on the more in-depth logical tests. Usually, the problems exist under data validation, a different understanding of what is privacy-focused, and which API methods should be exposed. For these kinds of tests, manual review is encouraged.
At Devbridge, we then create reports with recommendations for clients to further improve security. Repeat the cycle whenever new features are introduced.
By implementing these strategies, companies can safeguard themselves against crippling data breaches and avoid being the subject of a disastrous headline.