“Build Security in DNA”, BSI for short, is a software development practice with security built into the development process. As its name suggests, various security practices are incorporated into each stage of the software development lifecycle from an early stage; thus, security is built in, rather than treated as an afterthought. By introducing these practices early and reviewing them throughout the development lifecycle, the team considers security and receives feedback on it earlier and more frequently. This gives the team more time and options to address this feedback and prevent security problems.
The diagram below illustrates a BSI implementation. We include security as a part of the Agile development process, and incrementally build and evolve security measures into our products in each iteration.
By adding various security practices to our software development lifecycle, feedback channels of security risks increase, feedback period of security problems decrease, and therefore, security problems can be fed back immediately for continuous improvement. With threat modeling introduced in the analysis process, certain potential security issues can be avoided before they even arise.
In partnership with Clinton Health Access Initiatives (CHAI), we built the Electronic Stock Management System (ESMS), an Android tablet app that connects to the open source medical logistics platform, OpenLMIS, to provide better access to medicines for patients across Mozambique. The ESMS has two main objectives. The first is to reduce the workload of health workers by providing a user-friendly digital solution and automatic calculations for forms. The second is to collect timely and accurate stock data and generate reports to assist the Ministry of Health to plan, allocate and distribute drugs to facilities.
Security issues in the system could affect timeliness of medicine delivery to health facilities, thereby delaying treatment for patients; which is why keeping the system secure is one of the most important endeavors of the project team.
We know that BSI can help improve the security of software in early phases and ensure security issues are addressed gracefully. Let’s look at a few examples from the project we did for CHAI in Mozambique using OpenLMIS. The project is now in its second phase, where most features were already complete when BSI was adopted. Based on this situation, we have prioritized all activities in BSI and the following were done first.
One of the key ideas of BSI is that security is not solely the responsibility of an external InfoSec team or a security consultant, but rather something that everyone in the delivery team should have knowledge about. We conducted a one-day training workshop on the Open Web Application Security Project (OWASP)'s top 10 security issues. Thoughtworks' security consultants ran the training with content targeted to different roles in the team: developers, quality analysts and business analysts. Here are the issues we introduced to the attendees.
|A2||Broken Authentication and Session Management|
|A3||Cross-Site Scripting (XSS)|
|A4||Insecure Direct Object References|
|A6||Sensitive Data Exposure|
|A7||Missing Function-Level Access Control|
|A8||Cross-Site Request Forgery (CSRF)|
|A9||Using Components With Known Vulnerabilities|
|A10||Unvalidated Redirects and Forwards|
During the workshop, the security consultant explained the definition, concept, theory, behavior and preventive solution for each of these issues, then demonstrated these with examples so that the attendees could see the impact. The session also included practice content for the attendees to use, including tools such as OWASP ZAP and Burp Suite to experience how to investigate the issue. The training was a good preparation for the BSI practice at the development stage.
Security function test is an example of something we should build into our verification activities; they are stories relevant to visible security functions, such as authentication and authorization (log in/out, forgot password, user management etc). The team should include security function tests as part of the QA process. Based on the concepts and tools introduced and discussed during the training/workshop, the team along with the security consultant conducted security function tests that covered user access control, session expiry and other such areas. Those tests were conducted manually and automated tests against those scenarios were added to ensure future changes won’t bring the same issues back.
From the collective experiences shared, we found that there were issues in some of the most frequently used features of the application, such as the session not being invalidated after a user logs out, or non-admin users being able to view content intended for admin users only.
The issues discovered were recorded into Mingle (the chosen project management tool for the team). With help from the security consultant, they were prioritized alongside other tasks by impact, complexity, effort required to fix etc.
Later on, depending on their ranking in the priority list, the issues were picked up and fixed by team members, creating a closed loop of issue detection and elimination.
A penetration test is used for analysis of a system to identify weaknesses, technical flaws, or vulnerabilities. It involves examining a system from the perspective of an attacker, understanding what can compromise the security of the system. The security consultant works with quality analysts to go through all use cases to identify findings. With this effort, a few more issues may be found. For example, the login function might be susceptible to brute force attack, or pages could be attacked by submitting large amounts of data to cause a denial-of-service attack. Similar to the security function test activity, actions are taken to mitigate/fix these issues.
Based on secure programming principles and guidelines introduced by the security consultant, we perform manual security code review. The modules to be focused on are authentication/authorization, logging, password protection, etc. All findings are recorded and tracked by tech cards or bug cards in Mingle. The team then prioritizes the cards and takes appropriate actions to remove or mitigate the issues; for example, if we found that the password was stored with a hash algorithm but a salt has not been adopted, the team creates a tech card and assigns it a high priority so that the issue is fixed first in next iteration.
Security is a critical concern that every software application must consider and include from the start. It is of vital importance especially at a time when most enterprise-level software is connected to the Internet. This is a trend that will surely continue and will only result in more security risks, generally due to an increase in targets to attack. Insufficient security protection during the development phase will cause a negative impact on the project.
Generally security issues are found late in the penetration tests or even after the application is put online. This takes a long time for an issue to be found, reported and fixed.
If security issues are found very late and the software architecture has already been chosen and implemented, it is often laborious to change the architecture to correct the root cause of the issue.
BSI can be used to improve the security of software during the development phase itself. It is aimed at ensuring that the software is secure before release, in both business and technology aspects, by adding various security practices in its development process.
There is no absolute security, so ensuring security via BSI does not guarantee that a system is completely secure. However, for software systems which serve more complex businesses and become bigger, the secure software development process of BSI will surely reduce security risks at the source, greatly lowering the possibility of hacker attacks and significantly decreasing the loss caused by security problems after the system has been put into operation.
For more information on BSI, visit https://www.buildsecurityin.net.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.