Building Battle-Hardened Defenders

Background and Introduction

To clarify any misconceptions, let’s begin with some definitions. Penetration testing is a well-known concept among tech professionals. It aims to identify as many vulnerabilities as possible, assess their exploitability to demonstrate real-world impact, and report them for remediation. Red Teaming, although sharing some similarities and overlap with penetration testing, has a distinct objective. Rather than uncovering all vulnerabilities, a red team engagement emulates a real-world attacker to evaluate the blue team’s (the defenders) ability to detect and respond to an attack. Although both terms are often mistakenly used synonymously, they each serve unique purposes in offensive security testing. In essence, penetration testing focuses on assessing defenses, while red teaming evaluates the defenders. We can identify weaknesses through red teaming and better prepare our defenders to face real-world threats.

How It Works

So, how do we run a red team engagement? There are two primary approaches to consider. The first mimics a real hacker’s strategy, starting with reconnaissance, selecting a target, and attempting to gain initial access to the network. This access is often achieved through a simulated phishing exercise, where the red teamer deceives a user into downloading and executing malicious code, granting the attacker network access. However, this process can take weeks, as it relies on the phishing attempt’s success.

The alternative approach is the assumed breach methodology, which presumes that an attacker has already infiltrated the network or gained initial access. In this scenario, the tester begins with existing network access. A common way to bridge the gap between these approaches is to run a phishing campaign simultaneously with the assumed breach, allowing the assessment of initial access and social engineering aspects without waiting for the phishing attempt to succeed before proceeding with the test.

What does the engagement entail? Most red team engagements utilize Mitre’s ATT&CK (pronounced “attack”) framework to emulate the tactics, techniques, and procedures (TTPs) of an attacker. We can use ATT&CK and the ATT&CK Navigator to model threats specific to certain hacker groups and industry-specific threats. Again, when red teaming, we try to emulate a real-world attacker as closely as possible, not enumerate all vulnerabilities. Since our goal is to test our defenses and our blue team, we heavily emphasize stealth and defense evasion. By doing so, we can identify gaps in our detection and response capabilities and better counteract those techniques for the future. Many TTPs can be automated using commercial tools such as cobalt strike or open-source tools such as Mitre Caldera. The red teamer will select a target within the organization and move through the TTPs to get there.

Blue teamers should practice what is known as defense in depth, meaning if one defense fails, there should be another layer of security to prevent the full attack from succeeding. So we evaluate the detection and response capabilities throughout each engagement phase. Suppose the red team successfully can move through various TTPs undetected, or with no response by the blue team. In that case, the red and blue teams will work together to identify the gaps that allowed them to go undetected and then improve upon them. Suppose the defenders successfully detect and prevent an attack. In that case, the red team can go back and try another method to evade the defenses of the blue team. This cycle could repeat in an infinite game of cat and mouse. The result should be a comprehensive report of the strengths and weaknesses in the detection and response capabilities of the organization. Once the red teamers are satisfied that they have done this, the engagement can conclude, and they select a new target and begin to plan another engagement.

How We Utilize Red Teaming at Ginkgo

At Ginkgo, our VAPT (Vulnerability Assessment and Penetration Testing) team adopts a comprehensive approach to vulnerability assessments that extends beyond traditional penetration testing. To maximize the effectiveness of our red team capabilities, we employ cyber-war games as a powerful tool. During these war games, we embrace a “purple team” approach, leveraging the strengths of both our red and blue teams. Through close collaboration, the red team strategically progresses while the blue team’s detection and response capabilities are continuously evaluated at each phase. These exercises serve as valuable learning experiences, enhancing the capabilities of our red and blue teams. This symbiotic relationship ensures that our offensive and defensive teams have a deep understanding of each other, fostering a strong and cohesive security infrastructure.

Conclusion

We can go beyond what a traditional penetration test includes through red teaming. While it is crucial to discover and patch vulnerabilities, it is often said that “prevention is ideal; detection is a must.” In the event that things slip through our systems, we must equip our blue team for early detection and response. While performing adversary emulation, we “battle harden” our blue team defenders. While blue teamers are guaranteed to see many threat attempts in their careers, they will never experience them all, especially in the wild. By mimicking the TTPs of our industry and organization’s most likely attack scenarios, we help prepare our defenders to detect and respond to real-world scenarios.

(Feature photo by Jachym Michal on Unsplash)

Going Passwordless – The Future of Authentication?

Background

Passwords are a nightmare! Username and password combinations have been the dominant form of authentication since the inception of the internet, but they have many issues, both technically and procedurally. According to the 2021 Verizon data breach investigations report, password-based attacks were responsible for over 80% of data breaches in 2020. Users have to remember dozens of passwords; which often leads users to create less secure passwords, jot them down in insecure locations (like sticky notes) or reuse the same password across multiple accounts. In many cases they can be cracked quite easily, and sometimes if a malicious attacker can obtain a password hash (a password’s cryptographic representation) they may not even need to crack it to gain unauthorized access to a user’s account. Perhaps worst of all, the security community has spent the better part of the last couple of decades giving users bad advice – as it turns out, substituting letters for special characters, numbers, and mixed cases has only resulted in passwords that are difficult for users to keep track of and still not secure against modern attacks. Aside from the obvious security issues, this also demands a lot of overhead with support teams having to do constant password resets and account unlocks. Gartner found that between 20%-50% of all helpdesk calls are for password resets. In reality, the internet and computing in general were not built with security in mind.

Steps Forward

The security community has spent years trying to rectify mistakes of their own as well as those of computer scientists and engineers from days of old. We’ve made a lot of great strides in that time, but there are many hurdles to jump through still. Re-educating users to create more secure passwords is a logical choice. We now know that length is the most important factor for security in a password and are shifting more towards the term “passphrase” rather than “password.” A short 4-word phrase with spaces that means something to the user, but may otherwise sound nonsensical, is both easy for a user to remember and extremely difficult to be guessed by a computer as demonstrated by this popular XKCD comic.

While this is a seemingly good solution, as the saying goes, “old habits die hard.” Undoing the damage we’ve done via poor education is challenging at best, and technical enforcement of a password policy that supports this is somewhere between extremely difficult and impossible.

Password managers such as LastPass help somewhat in this regard. With a password manager, a user only needs to know one password to access their password manager’s “vault” which then generates secure passwords, stores them, and auto-fills them across websites. The problem here is somewhat the same as the latter – it’s a habit change. Encouraging users to use a password manager is somewhat easier since it provides some convenience to them as well, but it is still a small learning curve and some people just don’t like change. Even if users do adopt a password manager, there is little to stop them from storing the same insecure passwords within it.

Another significant improvement has been the increased use of single sign-on (SSO.) Like a password manager SSO allows the user to only have to remember a single password, but rather than auto-filling, an SSO service serves as the identity provider (IDP) and authenticates to the application without using an individual password for each specific application.

Perhaps the most significant improvement that we’ve made is the increased enforcement of multifactor authentication (MFA.) That is taking adding an additional authentication factor on top of the first factor, typically being a password. Common factors include something you know (passwords, security questions, etc.), something you have (an authenticator app on your phone, a hardware token, SMS-based code, etc.), and something you are (biometrics.) The benefit here is that even if a user’s password is compromised they can not use it without access to the second factor. MFA should always be enforced in conjunction with secure passwords, password managers, and SSO. Still, even with MFA enabled an attacker can often deduce whether they have obtained or guessed the correct password. Since many tend to reuse passwords between multiple accounts, an attacker could use this information to gain access to another service where MFA isn’t enabled or supported.

What’s Next

The information security community has brought password security a long way, but despite our best efforts we have failed to stop poor password practices and passwords are still, by a large margin, the number one vector exploited by attackers. So the next logical step? We stop using them. Yes, you read that correctly. One of the most modern approaches to this problem is the passwordless authentication model.

You may be wondering how this works. In the traditional model of MFA discussed above, passwords are typically the first authentication factor, but they don’t have to be. In a passwordless model we opt for a different factor – the device you are logging in from. A passwordless authentication service cryptographically ties a user and their trusted device together. When the user goes to login from their device, they will no longer be prompted for a password. Instead the user is redirected to an agent installed on the device; which automatically checks that the user and device match up with who they say they are, and then signs them into the app.

So does this mean all of our prior efforts go to waste? Not at all; in fact, for this model to actually be more secure, it needs to be paired with additional security measures. MFA is especially important. In addition to being on a trusted device, a user must be able to authenticate themselves another way, ideally with something convenient such as a fingerprint or a push notification on their phone. Passwordless authentication also works best in conjunction with SSO either by being built into the SSO solution, as is the case with Okta device trust, or with an additional 3rd party IDP such as Beyond Identity.

This offers us a lot of additional security benefits. Most importantly the issue mentioned above, that passwords are the number one attack vector, goes away. With no passwords, we can significantly reduce our attack surface and in doing so, when implemented properly apps and services can be accessed only by that user on their known and trusted devices. This also gives us the ability to run checks to make sure devices are secured, by measures such as antivirus and encryption, before allowing them to be trusted to authenticate a user at all.

Is all of this practical? It is — in fact, we’re doing it here at Ginkgo today! While we haven’t shifted entirely to passwordless, our employees can opt-in to this model at any time. Users who have gone passwordless are happy with the added convenience, security is happy with the reduced attack surface, and our help desk is happy to have fewer password resets and account unlocks to do. Passwordless authentication is still quite new. “Passwordless” doesn’t exactly equate to “password-free”, the device you trust for example will still need to be authenticated in some way, for most desktop operating systems that means a password. For the most part, passwordless authentication only extends to enterprise applications as consumer products generally don’t let you change your authentication method. This is where password managers still come in handy. But, overall the reduction in the use of passwords significantly mitigates many of the most common cyber attacks.

(Feature photo by Towfiqu Barbhuiya on Unsplash)