What happened in the Twitch Breach…
And four principles for securing your organization’s information including your source code and supply chain
Twitch, a popular live video streaming service, was breached last week. Last Wednesday, an anonymous individual published a file online containing the entirety of twitch.tv’s source code, information about twitch’s internal services and development tools, penetration testing reports and tools, and payouts to prominent Twitch streamers. The source of the leak is currently believed to be an internal Git server.
In the wake of such an event, you might think: How do I prevent such an event from happening? How do I protect my code and development tools from being leaked? How do I ensure my development teams have the knowledge to own and secure their application and its environment? It is still unclear how the Twitch breach originated, so we cannot pinpoint exactly how Twitch could have prevented the breach. But there are security principles every development and IT team can follow to reduce the risks of a damaging breach.
Principle One: Zero Trust
The first principle that’s going to help here is zero trust.
Successful cyberattacks often start at the “network perimeter”. The network perimeter refers to public-facing machines exposed to people outside an organization’s network, like public web servers or even public cloud services. These machines are usually the heaviest guarded against attacks: they are protected by firewalls and monitored for suspicious activities.
Machines that don’t sit on the network perimeter are often treated differently. Because they are, in theory, only reachable by trusted machines on the internal network, security is often less of a consideration. Sensitive data and functionality are often accessible by trusted internal machines without additional security controls.
But if an internal machine was compromised, this “trusted machine” can quickly allow attackers to exploit other machines on the network. For instance, if an attacker can takeover a public facing web server, they will then be able to send requests on behalf of a server to access sensitive data and functionalities of other machines.
The zero trust principle means not to trust devices by default. Instead, sensitive services should authenticate devices and users regardless of where they are located.
Principle Two: Least Privilege
Another good way to limit the damage caused by breaches or vulnerabilities is to implement the principle of least privilege. The principle of least privilege means that applications and processes should only be granted the privileges they need to complete their tasks. For example, when an application requires only read access to a file, it should not be granted any write or execute permissions.
If an attacker hijacks an application that runs with high privileges, the attacker can gain its permissions. We often see web servers running as the root user. This is a terrible idea, as an attacker who compromises the web server will then gain root access to that machine. You should grant applications precisely the permissions that they need instead. This will lower your risks of complete system compromise during an attack.
Principle Three: Logging and Monitoring
Cyber attacks do not happen within a few hours or even a few days. Attackers often need time to explore the network and construct suitable strategies to fully exploit the system and steal the data it contains. The longer an attacker is able to access the system without detection, the more likely the attacker would find a way to exploit the system, steal data, and cause extensive damage to the application and its users. That’s why it’s essential to have a logging and monitoring system capable of detecting malicious activity as soon as possible.
You need a logging system that looks out for abnormal usage patterns. You can log events such as input validation failures, authentication and authorization success and failures, application errors, and any other events that deal with sensitive functionality like payment, account settings, and so on. Over time, you will be able to understand what normal usage of your services looks like, and detect suspicious activity that could be an attack. This will give you insight into the malicious activities going on in your network.
That brings us to the second part of the equation. Once you set up logging and monitoring, make sure that you have an effective alert system in place in case of a security incident. After all, a monitoring system is only useful if its results could be delivered in time and to the right people. This way, your team can resolve the incident as soon as possible and limit the damage to your systems.
Principle Four: Assume Breach
All of the principles mentioned here come back to a simple idea: assume breach. To assume breach means that you acknowledge that an attack might happen, even if you defend your organization well. You should, therefore, protect your data, applications, and machines from potential threats currently lurking in your network.
Besides adopting the concepts of zero trust, the principle of least privilege, logging and monitoring, here are a few more things to do to best protect yourself against malicious actors.
First, study how attackers can break into your network. Understanding how attackers can break into your organization, or having an “adversary mindset” is a massive asset in your security arsenal. Knowing how your adversaries might act can help you act accordingly.
For instance, the top entry points for attackers are phishing and social engineering, and application vulnerabilities. Understanding this, you can use tactics like anti-phishing training and multi-factor authentication to lower the risks of social engineering. You can also use application security tools, like SAST, DAST, and SCA, to make sure that an application vulnerability does not become an opportunity to break into your network. A good SAST tool can help you secure your applications by catching vulnerabilities before they enter your codebase. Dev-centric tools that integrate with your CI/CD, like ShiftLeft CORE, can be easily run daily or at each pull request, so that you can focus on releasing innovative software.
You should also prepare for security incidents with regular security employee training and creating reliable backups for all important data.
While we don’t yet know the specifics of the Twitch breach, this is a good opportunity to make sure your organization is following the basics of good security practices. To sum up, here are a few principles to help you secure your data and machines: zero trust, least privilege, logging and monitoring, and assume breach.
What happened in the Twitch Breach… was originally published in ShiftLeft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
*** This is a Security Bloggers Network syndicated blog from ShiftLeft Blog - Medium authored by Vickie Li. Read the original post at: https://blog.shiftleft.io/what-happened-in-the-twitch-breach-a90abd8811dc?source=rss----86a4f941c7da---4
