Order Up: Establishing Scope and Objectives
To the people standing in line at their fast-food venue of choice, making their selection from the menu may be as simple as ordering Combo Number One, Two, Three or Four. Which one they’ll choose depends on how hungry they are, and which toppings and side items they prefer. Conducting an information security audit isn’t quite the same thing, but when it comes to assessing the network’s defenses, there’s no single approach that works for everyone, either.
The penetration test (pentest) is one of the most useful tools for evaluating network security. Essentially a simulated attack on the network, it’s a great way to find holes in the organization’s defenses in order to shore them up. But much like the variety of tastes and appetites represented in that line at the local burger joint (veggie burger, anyone?), each one is different. Getting the desired results comes down to knowing which combination to order.
Dine-In or Takeout? Information Gathering and Threat Modeling
To extend our food service analogy a bit, the testing standards for companies operating under regulatory control have something in common with the catering order for a working lunch: the requirements should be clearly established. One such example is the Payment Card Industry Data Security Standard (PCI DSS), in which the Cardholder Data Environment (CDE) is specifically included within the scope of the compliance guidelines.
Other frameworks may be less specific, but most will call out the need for internal and external pentests. Internal or infrastructure pentests are designed to mimic attacks from within. They can be used to identify insider threats, like disgruntled employees trying to cause mayhem, or to find vulnerabilities that could be exploited by an attacker to escalate or elevate their privileges and gain a larger foothold once the network has been infiltrated.
External pentesting addresses weaknesses in network architecture and open services that can be accessed from the public internet. It can identify applications that may be at risk of exploitation or theft, as well as hardware that could expose the network to malicious intrusion.
Securing data isn’t just a one-time deal, so identifying Advanced Persistent Threats (APTs) is an important part of the process. Whether it’s a focused effort to assess vulnerabilities in newly developed applications or recently purchased hardware, or a broad-spectrum evaluation of the entire organization’s risk posture, pentesting tailored to the network and its unique security environment is a vital component of ongoing threat assessment operations.
Fish With A Side Of Proprietary Secrets: Vulnerability Analysis
One potential threat that’s often overlooked is the vulnerability introduced by the Internet of Things (IoT). By definition, IoT devices must be connected to the Internet in some form or fashion in order to provide the access and automation they’re designed for. From digital assistants like Amazon Echo and Google Home to TVs, appliances, medical devices, and wearables, the very features that make these devices smart also make them susceptible to opportunistic attacks and infiltration of the systems they’re connected to.
An IoT pentest will target any such devices attached to the network to assess their vulnerabilities, some of which may come as a surprise even to highly security-conscious professionals. Who would’ve guessed that the automatic heat pump on a fish tank in the lobby could be used to steal company secrets by way of a Wi-Fi connection to the executive suite? (The hackers who infiltrated a casino, that’s who!)
How Would You Like That? Testing Methods
In terms of the tester’s awareness of and access to the systems being evaluated, there are three basic types of pentests. Setting aside the food metaphors for a moment, the different levels of access are categorized as black-, white- and gray-box testing.
Black-box testing creates scenarios that closely mimic infiltration pathways used by real-world adversaries, operating without firsthand knowledge of or access to the targeted systems. Testers are given no diagrams or other information about the organizational infrastructure and must create their own maps of the networks they attempt to breach. This approach is ideal for rapid and realistic assessment of a system’s external vulnerabilities, but it’s less useful for identifying internal threats.
At the opposite end of the spectrum is white-box (also known as auxiliary or logic-driven) testing, in which the tester has full access to — and intimate knowledge of — the network to be evaluated. While it’s a great way to get the full picture of an organization’s internal and external risk profile, the process of sifting through mountains of available data can be time-consuming.
Falling between the two extremes, gray-box testing simulates the unique threats of an attacker who gains longer-term access to the system. It balances the need to identify realistic penetration scenarios against the importance of seeking out insider threats that could be leveraged to launch ongoing attacks from within the hardened perimeter.
The Whole Enchilada — Red Team Exploitation
Red-Teaming is often referred to as removing the handcuffs from the consultant, allowing them free rein to break into the network in any way possible. Rather than focusing on a single engagement, Red-Teamers attempt to exploit the system the way real threat actors would, using a wide array of techniques, such as social-engineering, lock-picking, brute-forcing, and even spear phishing to gain access to usernames and passwords.
Red Teams can also investigate from a human resources standpoint, checking for flaws in the training procedures and management protocols affecting the security environment. A full-scale Red Team engagement is an intensive, multi-week event that tests the limits of network devices, endpoint security, physical security systems, employee training, and local user access controls.
Interested in partnering with a capable security consulting firm? Hit us up at AdaptForward.com