Securing your TAK environment involves many layers. If you have ever taken CompTIA Security Plus (Sec+) or any other Cybersecurity related course you will hear the CIA Triad referred to a lot. This is because the CIA Triad stands for Confidentiality, Integrity, and Availability and forms the basis for security practices. In its simplest of definitions the CIA Triad is defined as:

• Confidentiality is ensuring that authorized persons can access and modify data.
• Integrity is the data shall be in its original format and state and is not modified accidentally or maliciously.
• Availability is the data that is readily available by all authorized persons at any time.

Types of Security Controls

Within the security practice, there are three main security controls: Administrative, Technical, and Physical. The goal of any security control is to prevent or reduce the loss of information through exploitation or vulnerability. You will often hear mitigate or remediate regarding the safeguarding of information. To mitigate is to reduce, and remediate is to completely remove or resolve a vulnerability.

• Administrative Controls refer to the policies, procedures, or guidelines that provide a foundation of security practices to match your security goals. These include a user agreement form or acceptable use policy of information technologies for new employees or accounts. An additional part of administrative controls is the management and operational controls that are used to enforce and monitor the administrative controls. These controls are typically executed by personnel to help manage the security of the systems and risks.
• Technical Controls use technology and automation to mitigate or remediate vulnerabilities in the form of hardware or software. Technical controls are typically done by the system and not a person and differ from administrative controls. Think of antivirus or firewalls that are used to scan for threats and remediate them or firewalls that are implemented to mitigate a threat.
• Physical Controls are things that are meant to deter or prevent access to information or systems. This can be as simple as a fence around a compound, security cameras, and locked doors.

The core function of each security control is to prevent, detect, correct, deter or compensate. You should always want to try and prevent an incident from happening. Even if you can't prevent the incident you should want to detect it after it has occurred. Next, you should either correct the incident or deter the incident from happening again. Finally, if control can not be applied you can compensate by using an alternate control if feasible.

The most common practice in implementing security controls is a defense-in-depth method in which multiple layers of controls are applied. Each layer is supposed to provide a boundary of protection around the data you want to protect. In its simplest form, a defense-in-depth strategy will implement the following layers of protection: physical security, network security, endpoint security, application security, users, and then the data.

Now that I'm done feeling like I just taught a security class introduction, let's move on. 🤓

Securing the Boundary

One of the first things you will want to do if your TAK Server is forward facing or open to the internet is block access to your TAK Server and allow only required ports for use. Depending on your configuration your TAK Server may sit in a demilitarized zone (DMZ) or sit behind a firewall and require some port forwarding rules. Additionally, you can be protected by not only a firewall but an access control list (ACL) that sits on a network device somewhere within your network.

This is not an all-inclusive list but by default, these are the ports used for communications:

TCP/S = TLS/SSL TCP
NOTE: Unless annotated, most connections use a random source port to the target destination rather than a 1:1 mapping.  An example is a client connecting to TCP/8089 would leave the client using a port called an ephemeral port with a destination port of TCP/8089 to the server.

Using a Reverse Proxy for WebTAK

If you want to enable WebTAK for use outside of your network consider using a reverse proxy as a trusted host that sits between the connecting user and your protected TAK Server. What is a reverse proxy?

Using a DMZ or Firewall

A DMZ is a segmented part of your public network for hosting public-facing services. Depending on your physical or logical setup a DMZ can sit between two firewalls called a "dual firewall" or behind a single firewall on a small private network. What is a DMZ?

Another method outsize of a DMZ is using port forwarding or a destination network address translation to allow external traffic with a specific destination port or range to communicate within your internal network.

Consider using a VPN

A virtual private network (VPN) is pretty common these days and practice. A VPN creates a secure tunnel between you (the client) to the distant end (the server) so that unencrypted or encrypted traffic can pass without being intercepted. A VPN is a point-to-point connection between two devices. It is not to be confused with a proxy. A proxy sits between you and a distant end and establishes and passes traffic on your behalf. VPN vs a Proxy, what's the difference?

Securing the TAK Server

This is not limited to the logical security of your TAK Server but the physical security as well. Logical security involves implementing an operating system hardening strategy that is designed to secure and reduce attack vectors for threats.

OS Hardening

Various organizations offer security benchmarks and guides for securing the operating system. The Center for Internet Security is one such organization that offers this kind of service. For those in the federal government, you are probably very familiar with DISA Security Technical Implementation Guides (STIGS) or Security Resource Guides (SRG) which are mandatory for information systems. Before implementing any security benchmark or guide it is best to test this in a controlled lab environment before deploying this on a production system. Security benchmarks and guides are meant to secure a system and often implementing too strict of a policy can prevent access altogether.

Disabling the root user account

The most common account for a Linux system is the root account. This account, if compromised can severely degrade the system. Consider disabling the root user account and implementing a delegated superuser to perform common administrative tasks. Implement a least-privilege and access method with assigned system administrators and ensure appropriate technical and administrative controls are in place. Before you disable the root account you should verify that you are in the sudoers group. Depending on your distro this may be the wheel or admin group. To configure or determine which groups can execute sudo as root use the visudo command.

In the above, we can determine that the group wheel has access to sudo. Your distro may vary. Next, create a new user and then add them to this group and conduct some simple tests before we disable the root account.

# Create a new user
sudo useradd -aG wheel [username]

# Verify user groups
 sudo groups [username]

# Set user password
sudo passwd [username]

#! Logout and login with new user
# Execute simple sudo command EXAMPLE: sudo ip address

#! Disable the root account
sudo passwd -l root

Modifying the host firewall

One of the things we covered in building our TAK Server is modifying the host firewall firewall-cmd to allow required ports. Using the table referenced in securing the boundary configure your application firewall to allow only the required traffic. If you would like to add additional security by allowing only trusted networks you can modify the command to something similar to this:

# Create a new zone for the TAK Server
firewall-cmd --new-zone=takserver-access --permanent

# Allow 192.168.0.0/24 as a trusted network only
sudo firewall-cmd --zone=takserver-access --add-source=192.168.0.0/24 --permanent

# Allow 8089/tcp
sudo firewall-cmd --zone=takserver-access --add-port 8089/tcp --permanent

# Allow 8443/tcp
sudo firewall-cmd --zone=takserver-access --add-port 8443/tcp --permanent

# Apply new firewall configuration
sudo firewall-cmd reload

This example will create a new zone for TAK Server connections to allow only clients connecting from 192.168.0.0/24 and using the TCP ports 8089, and 8443. This method can be very administrative; however, if your using a VPN with assigned IP Addresses this can be applied to only allow VPN-connected clients and an internal LAN segment as well.

Implement SSH key-based authentication

If you're using managing your TAK Server using password authentication with SSH you may want to consider using an SSH key-based authentication method. This method creates key pairs that consist of a public and private key. The private key is maintained by the client while the associated public key can be shared with many target systems. Additionally, the private key can be encrypted on the disk with a passphrase to decrypt. Generate and copy SSH keys to Servers.

Change the default SSH port

The most common way to manage your TAK Server is by using SSH. The default port for SSH (22/TCP) is well-known and a common attack vector for hackers. Changing this from the default to a non-standard port will decrease the chances that an attacker could gain access to the system. Additionally, if you have disabled the root account uncomment #permitRootLogin from yes to no.

# Edit the sshd_config
sudo vi /etc/ssh/sshd_config

# Restart the sshd service
sudo systemctl restart sshd

Certificate Passwords

For god's sake change the default certificate password! This is probably the most well-known password in the whole TAK ecosystem. If you're using data packages in your enrollment environment consider moving to a certificate auto-enrollment authentication backend as well. This way the only password shared is the public certificate password and the client password is randomly generated. If you have already set up your TAK Server and haven't changed that default password you can still modify the cert-metadata.sh file which will apply the password for any soft-certificate generations. Make note of this when you troubleshoot in the future when you're potentially working with older certificates.

TAK Server Client Certificates

If you're using the TAK Server as your certificate authority (CA) and you're manually making client certificates you will have a directory that is full of private information such as certificate signing requests (CSR) and private keys (.key). These files should be moved to an offline location to protect your clients and from an attacker using these certificates to act as imposters in your network. The only files required in that directory are your CA files such as truststore-*.jks, the .key to the associated CAs, and any other files generated during the setup for example. All client certificate files should be offloaded until they are needed for revocation or renewal.

Securing TAK Clients

Ensuring that your TAK Clients are secured is a guaranteed way that your TAK environment will be secure. It just takes one client to compromise the entire network. Ensuring that the host is secure can ensure your environment is secure. This doesn't always take into account the human aspect of things as insider threat is always a consideration. When securing our TAK Clients consider using a defense-in-depth approach. Reference OS Hardening covered earlier on how to secure your TAK clients.

Host-based firewall

With any good network, you should have an established baseline of what communications happen within your network. Using the table referenced in securing the boundary configure your application firewall to allow only the required traffic.

End-User Device (EUD) Encryption

It's very common these days to find devices with a trusted platform module (TPM) that allows for device encryption and security. If you run a Windows operating system you are probably familiar with BitLocker. Linux offers full disk encryption (FDE) but does not confuse that with Linux secure boot which is used to verify malicious code is not present based on the kernel that the user has installed. For android mobile devices encryption can be set in the device settings. Older android phones had to do this manually; however, most devices come out of the box with encryption enabled. Similar to android iPhone devices can have encryption enabled via the settings as well.

Mobile Device Manager (MDM)

If you have the ability, securing your mobile TAK Clients (ATAK/iTAK) using a mobile device manager (MDM) will allow you to lock down features and capabilities that could pose a threat if a device were lost, stolen, or compromised. The best option is to have an online MDM which is globally accessible so the mobile device can always "call home" to get the latest security configuration and ensures that a software baseline is established. With an MDM you have the option to remote wipe a device as long as it can communicate to the MDM or implement a wipe on multiple password entries. If you mark a device as lost this will enable the GPS feature if the device battery is not dead. You can also upload files to target devices. For example, if you need to distribute a mission package to multiple devices you can select the target devices and upload the mission package to a secure folder within the device.

There are multiple MDM software vendors to choose from that offer various capabilities and features. Each MDM vendor may offer a free trial or offer limited enterprise features with a free version. It's best to find the MDM that meets your needs and budget and that you're comfortable with.

Conclusion

As stated in the beginning, this is not meant to be a definitive guide on how to secure your TAK environment but a reference to get you started. Every organization will have its own security policies and practices but if you're thinking of hosting your own public TAK Server you should consider some security best practices in your deployment. Implementing security is not a bolt-on but it should be burned into the entire process from start to finish.