Overview
This should be a part of a three-prong process. First, a FOSS/Non-Standard software request would funnel in either through procurement or via a Service Now request for approval following something along the lines of:
Infrastructure (integrations requirements) 
Security (Exploitable Code) Legal (Copyright Infringement) Help Desk (Desktop requirements) 
Installation if approved
The following outlines the process for reviewing requests submitted for the installation of applications, libraries, and modules (software) that is were developed by external parties. Security's role in the process is to determine the susceptibility of the software application to any identifiable exploitation and vulnerabilities.
The security review process involves two fundamental techniques: static analysis and dynamic analysis. The static analysis examines the software without actually running it. Dynamic analysis (also known as behavior analysis) executes the software in a controlled and monitored environment to observe its behavior. Performing static and dynamic analysis together helps identify the real intent and capabilities of the software and can provide a series of technical indicators which may not be achievable by Static analysis alone.
Static Analysis
The static analysis examines the software without viewing the actual code or instructions. It employs different publicly available sources to determine whether a file is malicious, has vulnerabilities, or is exploitable. The analysis utilizes the following Vulnerability Repository sites, providing the software's known name and any other metadata necessary to aid in the assessment.
Vulnerability Repository
For example:
Through this process, a request is submitted for Node.js for Serialize-to-js version 0.5.0 for a JavaScript-based application.
The analyst will first attempt to determine what is the latest version available of the requested software.
In this example, going to https://www.npmjs.com/package/serialize-to-js reveals that (at the time this was written) the current version is at 3.1.1.
Reviewing the business justification does not provide any details as to why that specific version is being requested. But before making the determination to deny or approve contingent upon using the latest version, the analyst attempts to determine if the newest version has any known vulnerabilities tied to it. The analyst goes to one of the repositories mentioned above databases for any reported vulnerabilities associated with the software.
The analyst notes that based on the version number, there are a few publicly known vulnerabilities.
Exploitation Database
The analyst continues the analysis by searching for any publicly available exploitation or proof of concept code. Similar to the vulnerability databases, the exploit databases provide a list of working or conceptual techniques, publicly known exploits, 0days, remote exploits, shellcode, etc. that could potentially be used to gain access or conduct any number of other nefarious acts against the organization.
Proof of Concept / Exploitation Code
Any working exploit that can be used against the requested software will be automatically denied by Security.
A working exploit is where a technique, a series of actions, and/or maliciously crafted code can be used against the software with little to no dependencies on exploiting other weaknesses of the software or supporting infrastructure (i.e., system, network, platform.) Whereas proof of concept (POC) are examples to demonstrate the vulnerability is not exploitable unto itself, often depending on a chain of additional vulnerabilities to have occurred before the PoC can actually be exploited. Reference the Decision Matrix (below) for the determining factors for denying or approving a request.
The analyst discovers during their research that this version of the software is susceptible to Remote Code Execution:
Dynamic Analysis
Next, the analyst may want to complete a dynamic analysis by running the software to observe its behavior, understand its functionality and identify technical indicators which can be used in detection signatures. Technical indicators revealed with fundamental dynamic analysis can include domain names, IP addresses, file path locations, registry keys, and additional files located on the system or network. Additionally, it will identify communication with potential attacker-controlled external servers for command and control (C2) purposes or attempt to download files. At this stage, it is essential to have a safe environment in which the analyst can run the malware and observe its behavior.
The analyst must have an account in order to utilize the majority of the online assessment tools.
Binary Executable Assessment
https://www.hybrid-analysis.com/ (CrowdStrike, Metadefender, and VirusTotal)
The analyst submits the software binary to an online independently maintained analysis tool such as hybrid-analysis.com. Online solutions such as hybrid-analysis.com and Intezer, is a multi-vector, cloud-based AI/ML platforms designed to analyze executable binaries, and applications against different attributes and vectors by monitoring their behavior. The analyst must have an account in order to utilize the majority of the online assessment tools.
The analyst must have an account in order to utilize the majority of the online assessment tools.
After the behavior analysis is completed, the analyst is given a score of 5% probability that the current version of Adobe Reader is malicious in nature.
Decision Matrix
The following table is used to support the decisions based on the factors identified in the process as outlined above.
Severity Status | Comments | Denied | Approved | Approved with Restrictions |
Critical | Zero Day - Exploit (tactics, techniques, code) is publicly identified |
|
|
|
High | Zero Day - Exploit (tactics, techniques, code) is not publicly identified |
|
|
|
Critical | Vulnerabilities in the current version have been publicly identified, and exploits (tactics, techniques, code) are also publicly available |
|
|
|
High | Vulnerabilities in the current version have been publicly identified; however exploits (tactics, techniques, code) does not currently exist |
|
|
|
High | No vulnerabilities in the current version have been publicly identified; however, exploits (tactics, techniques, code) are publicly available, and the current version does not address the exploits |
|
|
|
Low | No vulnerabilities in the current version have been publicly identified, and no known exploits (tactics, techniques, code) currently exists or publicly available |
|
|
|
High | Vulnerabilities have been identified in previous versions have been publicly identified, however, exploits (tactics, techniques, code) are publicly available, and the current version does not address the exploits |
|
|
|
Moderate | Vulnerabilities have been identified in previous versions have been publicly identified, and no known exploits (tactics, techniques, code) currently exists or publicly available |
|
|
Upgrade to the latest available version |
High | No vulnerabilities in the current version have been publicly identified; however previous versions have consistently been identified as having vulnerabilities and exploits (tactics, techniques, code) are publicly available |
|
|
|
Moderate | No vulnerabilities in the current version have been publicly identified; however previous versions have consistently been identified as having vulnerabilities, but no known exploits (tactics, techniques, code) are publicly available |
|
|
Upgrade to the latest available version |
No comments:
Post a Comment