In this day and age, there's a high risk of data vulnerability exploitation. However, Digital Samba's infrastructure ensures data security throughout its entire platform by applying multiple kinds of security measures. There are three main components that we use to enhance our platform security:
WebRTC is an HTML5 technology that makes media communication through websites possible.
WebRTC connections work by finding the most direct path between a client and a server, also known as peer-to-peer. These connections use Secure Real-Time Protocol (SRTP) to ensure privacy and security. SRTP is characterized by additional security measures, including message authentication, confidentiality, and replay protection. Therefore, if a WebRTC connection bypasses the end user's VPN, firewall, or NAT, the data is still encrypted by the WebRTC protocol layer encryption. This protocol and other security standards are agreed upon by the Internet Engineering Task Force (IETF). Any attempted peer-to-peer connections are strictly forbidden if companies that use WebRTC technology do not adhere to these standards.
SRTP also uses Datagram Transport Layer Security (DTLS), which focuses on generating encrypted keys as an extra layer of security when transferring data and establishing connections. When using this protocol, both sides agree on encryption keys, and they're transmitted directly from peer to peer on the media plane. Any transferred data will then be securely encrypted using a secret key for each connection. Either side will only be able to decrypt the data with the specific key.
Note: Please note that the IEFT only accepts DTLS as a valid form of key encryption. Other exchange protocols are not considered to be secure enough.
Thanks to WebRTC technology, we don't have to reinvent the wheel in terms of making websites secure when you are using Samba Live. Additionally, browsers have inherent security protocols already established by the World Wide Web Consortium (W3C), an organization dedicated to developing web standards.
Examples of browsers protecting users' security include:
- Granting explicit permissions, such as microphone, camera, and location requests
- Being unable to access devices from a non-encrypted website (without HTTPS)
- Protecting device information
Digital Samba Security Protocols: GDPR
GDPR compliance has become a cornerstone of Digital Samba's security protocols. Each department has different guidelines to observe. In the case of our Operations department, their focus turns to limiting or preventing data breaches and patching platform vulnerabilities if found.
Some areas our team touches upon which relate to GDPR and security are the following:
- Penetration testing: a simulated cyber-attack is carried out against Samba Live's infrastructure by our experts, attempting to identify old web servers that require replacement, known vulnerabilities, and other potential issues. The best outcome would—of course—be to not find any holes in our infrastructure. However, if any weaknesses are identified, penetration testing allows us to work on what needs to be fixed and avoid further complications.
Note: Penetration tests are run regularly to keep security protocols up to date.
- Server Security: to keep servers intact and safe, we use bumpers in our server OS. These are mechanisms that automatically update our servers with new security patches that are already built into our operating system. We also work with a known set of OS and software on each server, easily tracking content and identifying what needs to be monitored continuously.
- Access: providing access to sensitive data must be treated with caution. Server-side, we adopted iptables for each server type—a Linux firewall that can lock down any open ports that are unrelated to the service we provide. As for sysadmins, they utilize bastion servers, which provide a single point of entry and an added layer of protection. Bastion servers allow you to log in to only one server but still grant you access to all available servers. As an additional measure, we've implemented 30-minute timeouts. If you haven't been active on servers for 30 minutes, all logs will time out after this allotted time has passed to prevent others from accessing sensitive data.