Lessons Learned from a Major Hack: Part 2

Once we understand what happened and how, it is now time to learn from it and build a plan to remedy it and ensure such scenarios cannot happen in the future. You know the saying, “Fool me once...”

However, in this case, we know that this very company was allegedly hacked a couple of years ago and ended up paying a ransom to the hacker to delete the stolen data and “keep it quiet”; but based on what occurred, it looks like they did not learn from this and still need to review their security posture and engineering cultural failures.

How Did This Happen?

Security posture is made up of many critical components – including network, hardware, software suite, policies, data, and people – that all combined deliver an overall status of an organization’s cybersecurity readiness. As organizations transition to the cloud to decentralize their 

infrastructure and make it available globally to all their employees, no matter where they are and what type of device they use, it is time to implement a Zero Trust architecture, whose motto is “never trust, always authenticate”, where no user, device, or app is considered “secured” just because it is known and/or within a predefined secure perimeter, but instead should be constantly verified. When considering security, it is always advisable to prepare for the worst and expect the unknown. 

From a technical perspective, this is achieved using a combination of advanced security features, like Zero Trust Network Access (ZTNA), Multi-Factor Authentication (MFA), and Risk-based authentication (RBA) to name a few.

Part 1. Improve MFA

Multi-Factor Authentication (MFA) is a great security mechanism that organizations must implement as part of any Zero Trust architecture. However, it is not the magic key to perfect security and still has its few weaknesses that can be exploited. Security is larger than just one solution, so other security mechanisms should be implemented in combination with MFA to strengthen it even more.

Hardware Security Keys

One option is to use hardware security keys, which are small devices used in the multifactor authentication process to verify access and strengthen security on accounts. Employees need to physically plug them into their computers, mobile device USB port, or connect them to their mobile device wirelessly using Bluetooth when authenticating, to prove their identity before they can access specific resources on the internal network. For example, when connecting to a corporate website, their browser would issue a challenge to the hardware security key, such as specific information about the resource, like domain name. The key would then cryptographically sign and allow the challenge, logging the employee into the service.

Some corporations reported blocking similar attacks, thanks to the use of said keys, as part of their MFA process. One of the pros is that physical tokens cannot be phished, unlike software tokens such as SMS or Push Notifications. Some of the cons are the additional cost and possible inconvenience for the employees, who would need to carry an extra piece of hardware with them, similar to using an RSA hardware key to authenticate with a Virtual Private Network (VPN). This part might be hard to “sell” to the employees, who are used to having everything more and more conveniently digitized.

Number Matching

Another important improvement to MFA, offered by many Identity and Access Management (IAM) providers, is number matching. During the MFA authentication process, employees will see a complementary number that they will need to punch into the corporate authenticator app on their mobile device before they can complete said process and be able to access services.

This makes the MFA process much more robust against social engineering attacks, as the hacker would need to have access to both the employees’ credentials AND one of his MFA-registered devices, to access the push notification and enter the exact matching number.

Protect your Privileged Accounts

A privileged user is someone trusted enough to have administrative access to a company’s critical system, often referred to as “super admin” or “root” (especially in the Unix world). Such users can pretty much do anything on said systems, from creating to deleting user accounts, mailboxes, documents, data, etc. as well as starting or stopping business services, including internal communication systems. Therefore, it is important (and too often overlooked) to control and monitor such accounts the same way as any other account; it is a security principle to never completely trust anyone or anything unconditionally. Such accounts could fall into the wrong hands or be used incorrectly by the right ones, either accidently or intentionally, and the impact can be catastrophic.

To avoid that, a Privileged Access Management (PAM) solution should be implemented. It offers the possibility to authorize/control and monitor/audit, in real-time, all privileged user accounts on all relevant back-end systems. This helps reduce the risks and vulnerabilities produced by human mistakes or negligence, as well as possible misuse by impersonation from a malicious actor.

Following the security “Principle of Least Privilege” – which defines that a user should always be given only the minimum privileges required to complete a specific task on a specific system – PAM would protect privileged accounts and critical systems by, for example:

• Granting privileges only to the systems employees are authorized to access
• Granting such access when needed and revoking it after a certain time (e.g., enough to complete a specific task)
• Preventing them from using local system password, but rather their own account with required permissions
• Centrally managing, monitoring, and auditing these privileges accounts and their access to critical systems

Implement Data Loss Prevention (DLP)

Contact

Find out more regarding ISEC7´s Services and Solutions.