What is your target?
This can be either the hardest, or easiest, phase of launching a security engagement. Depending on the sector, operational decisions, and product/solution, you will find varying levels of attack surfaces at different companies. Some with obvious risk, others with little to none. Consider the following:
Company A:
The company is a consumer electronics retailer that does not actually store any PII data about its users beyond first name, last name, and email. It relies on a third party vendor service to process credit card payments on its eCommerce store and therefore doesn’t need to be PCI compliant.
Company B:
A software vendor that doesn’t offer a SaaS solution but strictly on-prem or self-hosted cloud deployments. It doesn’t store any customer data aside from logs but they use a service for those logs and have therefore transferred that risk.
Company C:
A national healthcare provider with millions of records of patient data stored across a heterogenous landscape of enterprise IT databases and directories.
Every company will face different threats and will need to manage their risk appropriately. Unfortunately not every risk can be addressed and thus, picking a target for your security assessment needs to be impactful. This means that just because you have the approval to test a legacy system that exists in a siloed network in some back office because you know it has vulnerabilities doesn’t mean it’s the best use of your resources.
Picking the right target is actually an exercise in holistic org-level threat modeling. In order to maximize the ratio of value-to-resource-usage in your favor you have to strike a delicate balance between impact, resource-cost, and approval.
First step is to take a bird’s eye few of the company’s products, services, and enterprise IT landscape and triage based on Confidentiality, Integrity, and Availability. Questions to ask which may help guide your decision tree are:
- If it went down tomorrow what would happen to the company?
- Would it impact revenue?
- Would it result in the unauthorized disclosure of sensitive data?
- Would it damage the brand name recognition?
- Would employees be put at risk?
Once you’ve taken inventory and stratified your targets based on impact, you can further distill this list based on two more key factors: resource cost and approval.
You may have a juicy target in mind to attack but if the attack surface would require 100% of your team’s attention for two weeks that may exceed the threshold. Depending on the resources at your disposal, that may or may not leave your infosec team unavailable to respond to an incident (should one arise) or perform their other daily responsibilities.
Lastly, you have to get approval which rests on company leadership’s buy-in, legal’s buy-in, and the system owner’s buy-in. If you select a critical target which has no redundancy in place then you risk bringing that asset down during your engagement. Think of a lone VPN or AD- yes they are most likely crucial to daily operations but if you bring either of them down you could break any number of business functions. For instance, stopping your contracts department from completing the redlines for that PO that’s due by the end of the quarter, or prevent remote employees from connecting in to the network and accessing network shares, or break all the apps leveraging group-based access control, etc…
Finally, you’ve selected a target that is impactful, offers a reasonable attack surface, approved by stakeholders, and critical BUT not too critical. The Goldilocks of targets if you will.
Is it penetration test or is it an adversary emulation?
Adversary emulation is an ideal for testing defense capabilities at your organization by operationalizing the defense data that is being consumed by your EDR, SOAR, and SIEM platforms. Part of adversary emulation is for testing the organization’s network perimeter defenses and finding entry points. The other part is measuring Blue’s mean-time-to detection, response, and mitigation which rely heavily on things like detection and alert logic within your security stack.
Penetration testing is usually aimed at targeting a specific enterprise IT asset, service, product, or even just feature of a product. Unlike adversary emulation, it less about identifying cyber kill chains and attack paths that can land an attacker a foothold in the organization’s internal network, and more focused on identifying critical vulnerabilities in the organization’s offerings. Put simply, In the former case, the victim is the organization. In the latter, the victim is the organization’s clients/customers.
What is value are you selling to the business owner?
Business owners more often than not, will not see the value of having their stuff broken up front. Consequently, you will need to come prepared with a value proposition. “But wait I’m just a security engineer! Not a sales rep, why do I have to bother with this?” The hard truth is that security will always be at odds with an organization’s budget and resources. Even worse, since you are bound to discover something that is not compliant or best practice, it can potentially push deadlines back making developers and other engineers feel…bitter. This means you are already fighting an uphill battle and so you have to put your sales hat on.
The trick here is to avoid what we in the industry call “professional finger-pointing”. When you and your team discover vulns it’s not the goal to gloat about it. Remember, a system owner is effectively inviting you to point out flaws in their work. That’s a big deal. So the best tactic to use when approaching an individual with this assessment is to describe it as a value-add for them, not the company. You want to convey that, by inviting you into their world they will look good to their upper management because they are taking the initiative to be proactive about security and putting security before their own pride. This is the type of message that their boss, and their boss’s boss will see and that that makes them look good for that end-of-year bonus.
Statistically this usually does the trick but there will be engineers who still safe-gaurd their work from the probing eyes of security. If this is the case, you can typically fall back on “well this ask came from leadership so you have to…” It’s not graceful and may leave the system owner salty but as long as you produce a solid deliverable and commend the system owner’s work all along the way, as much as possible, you have a decent shot at them warming up to you. It’s important to illustrate that you’re not their to add friction, but to simply be “just another step” in the Secure Development Lifecycle.
What are the team’s key objectives?
This might seem trivial: find vulns and pop shells right? Yes, it’s not a trick question. The point of this section is to simply remind you to think in terms of business impact. Not just technical objectives like benchmarking against OWASP ASVS Controls. For instance, if you have a web app that provides a subscription service what are some goals an attacker might have in mind:
- Take over another user’s account
- Access another user’s content
- Obtain access to Personally Identifiable Information (PII)
- Bypass paywalls to obtain services or features for free
- Abuse internal promo codes used in Dev/Test to gain discounts
What is the team’s methodology and strategy for achieving objectives?
Accomplishing these goals can a little subjective since ultimately, what it boils down to is what yields results. If following your intuition and going down rabbit holes is what nets the best results then by all means, do that. If you’re someone who likes a little structure and objective-oriented approach then select a framework to benchmark against such as the aforementioned OWASP ASVS v4.2 (latest at the time of this article).
If you’ve ever taken a look at the OWASP ASVS framework you’ll know that it provide application developers and application owners a framework with which to assess the degree of trust that can be placed in their Web applications. It is broken out into chapters, sections, and requirements that cover a scope of domains that can be used as a guide for penetration testers to hunt for vulnerabilities. This is extremely valuable come time for your report and you need to show not only an objective approach to your testing, but also measurable, empirical, results to leadership.
Moreover, the process of following a framework like this makes it much easier to conduct an assessment in a team-oriented environment because you and your colleagues can methodically choose which controls are even relevant to the asset in question, and assign the testing of these controls to the appropriate team member.
Take for instance a content-delivery web application the sole purpose of which is to upload video clips, share them, and suggest creators to your feed. The OWASP v4.2 5.5.2 control states:
“Verify that the application correctly restricts XML parsers to only use only the most restrictive configuration possible and to ensure that unsafe features such as resolving external entities are disabled to prevent XXE”
A control like this may have no pertinence to the application under testing and therefore doesn’t need to be considered when assigning controls to colleagues or operators. Alternatively, it could be extremely relevant to an application where user data is POSTed to a form in XML in a Java based application. In this case you may want to assign testing of this control to an operator with more experience in this area.
Having this structured approach can provide value in more ways than but ultimately it is what separates a lone-wolf pentest from an enterprise-sponsored team-oriented engagement. It is imperative to think about the deliverable because at the end of the day, if you have no findings for your client, you will need to demonstrate what you did to prove you weren’t just sitting on your hands the whole time.