Open source projects in social sector undergo security testing when they deal with a largish entity like government, who have security standards for what they will run in their data centre. Having gone through security testing for three projects now - Bahmni, Gunak and Avni, we see that there are many commonalities in the process, testing, issue types, and their resolution. These two write-ups (this is first) is aimed to help anyone going through such process. In this we discuss considerations for planning for security testing. That is, imagine when you have a software and the customer wants it to take it through security audit - for clearance.
Following are the main topics that one needs to think-about and plan for
- Scope of testing
- Server environment in which the testing will be done
- Process - from testing start to closing all the issues
- Preparedness for negotiation on the resolution of the issues
Scope of testing
Usually the scope of testing may be clear i.e. involving everything. But it maybe useful to work backwards from production environment to make a list of components that may be in/out of scope. This is quite useful in the following scenarios:
- You have an open source project with multiple components and not everything may be used in the project/implementation in question. For example in the Bahmni deployment we were worked on - Odoo and PACS was not used, so those go out of scope.
- You may have replaceable components. We use Cognito and S3 for our own hosting of Avni, but the customer's deployment may use open source equivalents like Keycloak and Minio. This is of course assuming that your product allows for such switching.
- There are components that need not be made available publicly. For example - you may be using a BI tool that falls here because it is meant to be used by customer internally. If possible then you may want to restrict its usage behind VPN for select users - hence taking it out of scope.
- The platforms that are configurable like Avni per customer, then one can define the scope of testing for the features relevant to that customer.
In case of software platforms the above decisions should be reflected in the deployed system. If the deployed system doesn't reflect the scope of testing - then it will like cause a lot of communication issues and perhaps wasted effort for both the teams.
This process should also help bring out questions like - look we are using Power BI but that is not something we can do anything about, so should it be even part of the testing? If such a component is not part of the testing then how should we one go about certifying them, requires discussion.
Isolate important systems from the blast radius
In social sector open source projects, funds are scarce and the temptation maybe to use one of the existing deployments to perform security testing on. But this may create bigger problems. It is important to setup the security test environment in such a way that there are no important systems in its blast radius.
About blast radius
When offering one's system for security testing, one must be pessimistic. For example - one should assume, whether likely or not, that the security testing team can find a SQL injection attack and execute any SQL on your database. Even if it is remotely possible for them to do this, then you must setup your security test environment to protect other important system from such an event. It may be important to consider the shared development environments as production environment of as well. If shared development environments are corrupted they can result in loss of days/weeks of productivity for entire team.
It would be ideal if you have an automated process and backups for setting up an environment as it is quite likely that your security testing team may come back to you to "reset" their test environment so that they can resume testing - since they have broken something and made the system un-testable.
Practical issues that I have seen happening here is that the security team can do is:
- change the super-admin password and doesn't remember it
- has deleted data/tables (including the base/user data)
Process
The team that is going for first/second time for security testing may have certain perceptions of the complete security testing process. The team that does security testing - does it daily. Their process is very clear to them. There is usually and naturally large process understanding mismatch between these two teams.
It is much better for the software team to get into as much detail as possible, right in the beginning to understand the process. The questions you can ask:
- How many rounds of testing will there be?
- How it will be reported - severity/priority/versions?
- How issues will be tracked?
- This can be done quite poorly. The issues can end being all over emails, PDF, and excel files. It is better to agree on a shared editable document (like Google Doc) for error reporting.
- The open source software teams must avoid putting up these issues in public domain or in open issue tracking system - since to avoid making the job easier for the exploiter and to not make your customer's nervous.
Negotiation
This is quite important part of security testing and issue fixing projects. While there are standards but application of standards has to be negotiated. This is because:
- There are less nuances in the standard. The standard is based on the idea that all applications are the same and must adhere to the same standard irrespective of the number of users, type of usage, and the criticality of the data. While some issues like SQL injection, unprotected URLs are non-negotiable, but how much importance should be placed on social engineering attacks, rogue user, can vary.
- While all the parties may want fix all the security issues, but there may not be time or resources available to fix all everything.
That is why relationships, consulting skills, negotiation approach, and above all collaborative process - matters a lot in such projects. It is in software team's interest to explain that issues or resources and time may come up even before security testing starts - as many a times the customer may also be going through this process for the first time.
In the next 1 or 2 article we will discuss the common (90%) of the issues that get reported and technical approach to solve them (in similar stack as ours).
Published On: 05 September 2023
Author: Vivek Singh
Logo credit: Raj Agarwal, https://www.canva.com/p/templates/EAE-T26xHMo-internet-security-logo/