Cloud Broadcasting - Going Deeper into Security

In the previous Cloud Broadcasting article, we looked at the business case for public clouds. In this article, we delve further into Cloud Born systems and go deeper into cloud security.

Cloud security is a partnership between the cloud service provider (CSP) and the broadcaster, a breach in one will almost certainly result in a break of the other. CSP’s have an obligation to stop intruders from accessing servers and protecting processes and data, and users have an obligation to stop intruders from gaining access to their software.

IT Managers despair with password security and is the Achilles heel of any system, but the frustrating part is IT Managers can easily deliver authentication systems that are very secure. They can force complex passwords, make users regularly change passwords and have n-lockout systems. However, this is usually frowned upon by users who see complex security as an unnecessary inconvenience and hindrance to their work.

Two Factor Authentication

And they do have a point. But with ease of accessibility and use comes potential compromise of security. It’s often left to the CEO to negotiate a path between protecting the system and providing ease of use. Recent advances in two-factor-authentication make this easier but it still has its limitations. When logging in a user will enter their username and password in the usual way, the software then sends an authentication code to the users’ mobile phone so they can enter it after the password, if the number is correct they will be allowed in. Travelling employees with poor mobile phone coverage find this a difficult system to deal with.

Traditional methods of operation work on the principle of providing an employee with a laptop or desktop computer installed with software such as word processors, spreadsheets, email and even high end graphics programs. Logging on gives users access to large parts of the filesystem through file servers. Granular rights controls help but they get complicated very quickly, especially when we start sharing files.

Reliable security is often achievable at the expense of ease of use

Reliable security is often achievable at the expense of ease of use

This opens two areas of vulnerability, firstly a potential hacker can quickly gain access to the corporate filesystem by installing malware and viruses, and secondly, if a laptop is stolen, the thief can easily gain access to the system.

Stop Hackers Storing Files

Public cloud Software-as-a-Service (SAAS) solutions provide a remedy to this. Desktop and laptop computers no longer need to be powerful as the software is accessed through an internet browser, files are stored in the cloud and high demand processing takes place in the cloud too, resulting in the user’s computer needing much less memory and hard disk resource. If a hacker cannot store files on a laptop or desktop it’s much more difficult for them to gain access to the network file system.

Malicious hackers often try to gain access to a system through unpublished services running on IP ports. For example, TELNET, a command line utility to interrogate a server, listens on IP port 23.

{stash:related_topics}

VPC to the Rescue

Cloud systems such as AWS protect servers using their Virtual Private Cloud (VPC) allowing IT Managers to logically isolate individual servers and groups of servers. A range of IP addresses can be defined with subnet masks, route tables and network gateways. IP ports are opened so a specific service can be defined, and all other ports are blocked by default.

Network changes are made quickly and on the fly. VPC would be configured to allow ports 80 (HTTP) and 443 (HTTPS) for normal web server-client operation. When the software team need to update a system or software file they would probably use TELNET with SSH. From the AWS terminal, they would change the VPC network configuration so that it opened the TELNET port, they would make changes through TELNET and then close port 23, resulting in the TELNET session closing if they had not already logged out. The system would once again be secure allowing only HTTP and HTTPS traffic access to the server.

Amazon Web Services provides easy to manage network security

Amazon Web Services provides easy to manage network security

If the web server needed to communicate with a database server, the server would use unreserved ports and these would need to be opened. Cloud providers such as AWS further enhance their network security by providing public and private facing systems. The public facing system would restrict access to HTTP and HTTPS ports, or TELNET/SSL for maintenance, and the private facing system would allow access to other servers within the system domain such as the database and video processing.

Master Account Access

Another area of potential vulnerability is the cloud provider’s master software interface to the corporate cloud infrastructure. From a technical perspective, this is very secure as they generally rely on complex passwords and two factor authentications. Once a user is logged into the cloud portal they can cause all kinds of damage, from deleting servers to reconfiguring network systems.

System configuration is often left to Dev-Ops engineers, the members of a team who bridge the technology and communication gap between the software developers and the day-to-day users. In the past Dev-Ops generally report to the Head of Software (HoS), who in turn would often report to the Chief Engineer in broadcast stations. However, the lines of demarcation are becoming blurred and this reporting structure is not always respected, quite often the HoS now reports directly to the CEO.

Test Accounts Become Master Accounts

When a cloud infrastructure is first established a master-account is created. The credentials consist of an email address and password. It’s not unusual for a well intending member of the team to set up the master-account using their own personal email address for test purposes prior to integration, and as cloud slowly migrates into the business this test-account becomes the master-account.

CEO’s must be proactive in understanding the control Dev-Ops and the HoS has over their cloud broadcast system. They must understand how the logon credentials are stored. Who has them? Where are they? How can the CEO instruct somebody else to use them? The software team will have the best interests of the business at heart, but they are not always best placed to make decisions affecting the wider business, a responsibility that falls solely at the feet of the CEO.

You might also like...

Designing IP Broadcast Systems - The Book

Designing IP Broadcast Systems is another massive body of research driven work - with over 27,000 words in 18 articles, in a free 84 page eBook. It provides extensive insight into the technology and engineering methodology required to create practical IP based broadcast…

Demands On Production With HDR & WCG

The adoption of HDR requires adjustments in workflow that place different requirements on both people and technology, especially when multiple formats are required simultaneously.

If It Ain’t Broke Still Fix It: Part 2 - Security

The old broadcasting adage: ‘if it ain’t broke don’t fix it’ is no longer relevant and potentially highly dangerous, especially when we consider the security implications of not updating software and operating systems.

Standards: Part 21 - The MPEG, AES & Other Containers

Here we discuss how raw essence data needs to be serialized so it can be stored in media container files. We also describe the various media container file formats and their evolution.

NDI For Broadcast: Part 3 – Bridging The Gap

This third and for now, final part of our mini-series exploring NDI and its place in broadcast infrastructure moves on to a trio of tools released with NDI 5.0 which are all aimed at facilitating remote and collaborative workflows; NDI Audio,…