In recent years, the civil society community witnessed very positive changes in the way digital emergencies are addressed for NGOs, small media outlets, and other social groups: Better processes to grab information about incidents, the creation of helpdesks, and resources to make the Incident Response process more accessible, are some of the strategies we have nowadays to improve the effectiveness of digital security reactive processes. However, those advances are helpful after incidents occur. When looking for more comprehensive security strategies, we should also consider proactive measures to help avoid and reduce the impact, as well as quickly detect and react to the many threats our communities are vulnerable to.
So far, our community has concentrated its proactive strategy on digital security awareness raising, training, and ongoing support to enable activists, journalists, and other actors to protect themselves; however, amid the increasing digital threats and the fact that more complex attacks are targeting some groups, there should be more we can do.
As with many other areas in digital security, we can look towards the corporate and regulatory sectors to understand how those communities are addressing this proactive security issue. While their proposed solutions seem very comprehensive and usually effective, they assume three things that are common challenges in civil society: dedicated (and hopefully adequate) funding, in-house technical capacity to operate security solutions, and enough staff bandwidth to keep everything up to date and respond to the actual incidents.
Considering all of this, some middle-ground solutions have been proposed, piloted, or even implemented by members of our community. From less to more complex, some examples are:
Good old network firewalls
| Max complexity 🤓🤓⬜⬜⬜ | Min cost (excluding staff) 💸⬜⬜⬜⬜ | General added effectiveness 🔐⬜⬜⬜⬜ |
The idea is simple: between our internal networks and the Internet, we put a device that will watch incoming and outgoing communications and allow or deny them based on some rules. Over the years, these rules evolved from a static list of IP addresses considered dangerous to more sophisticated rules, including self-updating lists and concerning dynamic behavior. The range of use and implementation of firewalls is vast, and the possibilities depend greatly on the chosen solution, brand, cost, etc.
| The good: There is a lot of documentation and options to start implementing them, including open-source and free alternatives. Also, it will be easier to implement and manage if the organization’s work happens on the same physical premises. | The less good: They are primarily designed to protect physically delimited networks like offices, so if some of the work happens outside the covered networks, the protection network firewalls offer is lost unless we implement other solutions on top of them like Virtual Private Networks (VPNs), increasing the complexity of the implementation. Also, the organization should have the technical capacity to deploy and keep them and the rules updated. |
The verdict: This approach is more suitable for organizations working from the same physical location under the same network. Also, organization members should be widely informed about the connections being monitored and logged depending on the specific features of the firewall. Some free and open-source solutions are PfSense and Ufw.
VPNs and continuous traffic analysis
| Max complexity 🤓🤓🤓⬜⬜ | Min cost (excluding staff) 💸 💸 ⬜⬜⬜ | General added effectiveness 🔐 🔐 ⬜⬜⬜ |
Another addition to the growing security toolset during the last few years is the VPN, which is marketed in the Internet Freedom space mostly for its ability to help against technical censorship and network surveillance. Another (very specific) use case for VPNs involves deploying a VPN server that is also instrumentalized to analyze the traffic going through it like a firewall would (probably using an actual firewall solution), making it possible to capture and analyze the traffic of many geographically distributed and moving devices.
| The good: This solution is friendlier with decentralized setups, which are more common, especially after the pandemic, so connections can be monitored regardless of the networks or physical locations of the organization’s members, also making it suitable for people doing fieldwork. | The less good: Given that this solution includes the monitoring of all the connections made by a device, it raises concerns around privacy, especially considering the prevalence of BYOD (Bring Your Own Device), where the people managing the VPN server might be able of knowing all the content consumed on those devices, including sensitive information related to their personal lives. Another challenge is that specialized knowledge and infrastructure (like some terabytes of hard disk and a robust server if monitoring many devices) are required to deploy and maintain a solution like this. |
The verdict: This approach might be more suitable for devices used exclusively for work (like organization-issued devices) or during the research of potential infection of specific devices. In both cases, a strong process for informed consent should be put in place, informing what information will be harvested, who will have access to it, what will be done with it, and when and how it will be destroyed. Unfortunately, there are not a lot of extensively proven setups available to replicate, but if you are curious about this, you can research self-hosted VPN solutions and compatible firewall ones.
EDR/XDR solutions
| Max complexity 🤓🤓🤓🤓⬜ | Min cost (excluding staff) 💸 💸 💸 ⬜⬜ | General added effectiveness 🔐 🔐 🔐 🔐 ⬜ |
Endpoint Detection and Response (EDR) and eXtended Detection Response (XDR) solutions are one of the most wanted by organizations to manage their security strategy because, among other things, they let organizations be creative with threat detection rules without limiting ourselves to analyzing network traffic. For instance, we can scan downloaded files for viruses, check if certain system folders suffer suspicious changes, or if unexpected programs or processes disable security configurations. Another interesting feature of EDR and XDR solutions is that we can also tailor the response to detected threats. For instance, we can isolate devices from sensitive resources, terminate programs, delete files, and/or log specific information. Another key feature of these solutions is that they let organizations easily aggregate data from many devices to hunt for specific threats.
| The good: When well implemented, they can provide a good balance between catching real threats and respecting users’ privacy, especially considering BYOD. Also, there are promising free and open-source alternatives available. | The less good: Once configured for the first time, it is easy to think that the work is done, and it is also easy to forget to maintain the infrastructure and the rules, as well as analyze the data, which should be an integral part of the Incident Response and security management strategies to leverage the power of this kind of solution. |
The verdict: Using EDR/XDR could be a good strategy only for those organizations that have the technical capacity and bandwidth to operate more complex infrastructure and have the financial capacity to support the infrastructure (even deploying free versions will require staff time and a good server, and none of these are negligible costs). Two free alternatives worth exploring are Wazuh and Velociraptor.
In general
Regardless of the kind of solution we want to explore, if it relies on technology, we need to be prepared to train more local practitioners who can deal with the deployment, operation, and management of these tools. Also, given the amount of sensitive information they will manipulate, every implementation should be deployed considering high levels of security. Another critical skill will be knowing which solutions are more suitable for each case. Ideally, we will need more of this capacity inside organizations so they can own as much of their security infrastructure as possible; however, we can also foresee a model where trusted organizations can run these tools and “host” end-user organizations, a practice that, while is not ideal, can be valid under the right conditions.
Besides the requirements proposed above, we should check as an extended community (including the organizations we support) if we are ready to take this step, balancing all pros and cons, and acknowledging it will take a fair amount of time and a lot of support from all actors to reach this next level in the security of civil society organizations.
