Commercial relationships between businesses and 3rd-parties require the exchange of some types of sensitive information such as employee and customer details, access to the company's network and generally access to otherwise well-guarded IT assets. As a result, there is an inherent risk in the 3rd-party services as they create a venue of attack against the company's data and internal networks. These types of cybersecurity threats are known as supply-chain attacks.
To mitigate the exposure to 3rd-party risk, businesses must perform technical security due diligence. This is often done on paper with the help of a questionnaire. While this method is widely adopted, evidently it is prone to errors and misinformation as the answers in the questionnaire are taken at face-value and never checked. This proves to be a major problem for today's growing enterprises as the risk of 3rd-party security-related incidents is continuously increasing.
Getting Started
Technical 3rd-party due diligence is a necessary part of an effective 3rd-party risk management program. The process boils down to fingerprinting the 3rd-party public assets, identifying risks, such as compromised accounts, vulnerable software versions and exposed critical IT infrastructure, and making a decision based on the acquired information.
This is an extensive process which requires skill, access to a number of specialist tools and services and a method of aggregating data in a meaningful way. The SecApps Scout tool and its automated processes are particularly useful in such situations.
In this tutorial, we will step through performing a full technical 3rd-party assessment of a vendor to ensure they are a good fit for our business in terms of cybersecurity and IT operations.
Once the tool is up and you are authenticated you will see your existing 3rd-party recons in your dashboard. In this example, you can see that I've been quite active with recons spanning across many vendors, vulnerability disclosure programs and more.
Let's add a new Scout. Click on the PLUS (+) button and type in a name and a brief description. Both fields are optional but they are very useful to remind us what this test was for especially when you have more than 150 vendors as I do.
Next, we need to set up the brands and domains fields. The brand is one of many names the 3rd-party vendor associates with. This will be used for some fuzzy searches such as identifying their own 3rd-party vendor list, GitHub repositories for source-code storage and more. The domains field contains a number of associated domains. These domains will be searched to identify insecure publicly exposed web applications, insecure services, and publicly exposed databases.
You can also configure a schedule, in case you want to run this assessment continuously at predefined intervals and notification options such as email and slack channel URL. We will cover both of these later in this tutorial.
Notice we need very little information to get started.
Scout Executions
It is time to perform our first execution. Simply click on the Execute button. You will see a progress bar indicating the task progress through the various steps.
Each Scout Execution is a snapshot of the 3rd-party state at the time of the assessment. This is important because security regressions can occur randomly and while there might not be any interesting vulnerabilities today the situation could look significantly different tomorrow.
The test is completed and now we need to take a look at the results. Keep in mind that SecApps Scout comes with a number of automated features to warn you about some common misconfiguration and security issues such as identified compromised accounts, vulnerable software versions, etc. However, it is best to have a look at the relationship graph as well to get an overall sense of the 3rd-party security posture.
The questions that we need to ask ourselves are whether it feels that the 3rd-party did enough to secure their public assets. Can we spot misconfigured Jira, Confluence, Jenkins and other types of services? Do we see unprotected API endpoints? Can we find unprotected database services? All of this information is part of the graph.
In this example, we can see that our 3rd-party vendor has both GitHub and TravisCI accounts. Perhaps they are leaking credentials as part of their builds? It depends how far you want to push it.
A different part of the graph shows the various software types and versions currently in use. We can also see the most common HTTP response codes which could be indicative of abnormal behavior that should be flagged to our vendor.
In order to get more details about each individual node, simply click on the "Toggle Inspector" button from the toolbar.
For even deeper analysis you can select a number of nodes and open them (a process known as "Fork") into Recon for manual investigation and further transformations. Follow the GitHub Gist Recon tutorial to find out how to extract GitHub user Gists which could contain some sensitive details such as API keys, passwords and much more.
Pay attention to the screenshot above. The nodes that you can see are already compromised accounts for which there are passwords available on the DarkWeb. This, of course, is only here to demonstrate the risk and that particular 3rd-party has been notified and the risk remediated. Nevertheless, this is the kind of in-depth analysis we can perform to ensure that our business operates in a safe and secure environment.
Automation
While we can do a lot through manual efforts, when we deal with 200-300 vendors at the same time, it is best to automate as much as possible. Once the vendor is configured, all we have to do is turn on the SecApps Scout scheduling options. You can run tests daily, weekly on a monthly schedule. It is recommended to use either weekly or monthly but there are some circumstances, which may require daily snapshots as well. For example, you might want to monitor a vendor which is particularly sensitive and of a big risk to you and your business.
Once you define your schedule, you will receive a notification when change is detected, such as when new potentially vulnerable assets are identified. It is important to note that all of these tests are performed passively, without probing the 3rd-party's systems.
Conclusion
In this tutorial, we explored a method of performing technical 3rd-party risk assessments without relying on a questionnaire. While questionnaires should be still at the core of the process in order to satisfy audit requirements and various types of certification, at the end of the day what matters whether the 3rd-party you are dealing with is, in fact, secure and does not possess a risk to you and your business. The only way this can be done is to identify all 3rd-party assets and map them such that analysis can be performed visually and the relationship between different threat models can be established.
This process can be automated fully with the help of SecApps Scout.