Sunday, February 12, 2017

Must Have Data-Driven Software Defense Strategy to Identify Vulnerable Code


“Security mitigation planning is the process of developing options and actions to enhance experience and reduce threats to the project objectives.”  Although Security Bulletins and Exploitability Indexes help customers to assess potential risks but these reactive measures are not enough. With every security mitigation shipped there is an investment associated to increase the cost to exploit the same vulnerability. Hence, root cause analysis of vulnerability plays a vital role in defining a security mitigation, this is where data analytics on historical vulnerability reports and evaluation of Exploits/POCs/Zero Days becomes critical.
In this talk I will elaborate Multi-Level Exploit Analysis process; organizations must have and use before planning any security mitigation in application code or custom memory managers. These strategies are well thought of and are manifestation of suggestions from chief organizations such as Microsoft. Incorporating this strategy is a great value addition and following actions can help organizations and individuals significantly reduce the risk they face from Zero day exploits.

Keywords:  Multi-Level Exploit Analysis, Vulnerability Analysis, Data Analytics on Security Mitigation, Data-Driven Strategy, Mitigation Progress Monitoring
Must Have Data-Driven Software Defense Strategy to Identify Vulnerable Code:
Security is always relative to the information and services being protected, the skills and resources of adversaries, and the costs of potential assurance remedies via mitigation technique. In Modern era where the profit motive underlies most malicious exploitation activity, effective risk management becomes fundamental. Although 99% of the bugs are caught using functional, Blackbox testing and advanced techniques such as fuzzing and static code analysis, it is this 1% which are difficult to discover for testers and extremely valuable for exploits.

 

Multi-Dimensional Exploit Analysis:

At Blackhat 2016 (USA), Microsoft Presented Data-Driven Software Defense Process illustrating an overview on what strategy organizations should use to identify root cause and perform data analytics on historical data.


 

Security Mitigation Planning, Implementation and Progress Monitoring:

Security mitigation planning, implementation, and monitoring has been represented below in fig.i is a manifestation of Data-Driven Software Defense Process as a flow diagram.



 Exploit Identification is extremely important, involves collecting:
1.     Crashes reported collected by Platforms using:
a.     Microsoft WER (Windows Error Reporting)
b.     Apple BugReport
c.     Mozilla Crash-Stats
d.     Google Error Reporting
2.     Threat Intelligence Report from Security Partners
a.     Responsibly disclosed security incidences/researches
b.     Zero day exploits
c.     Open Source/Social Media


b.    Exploit Impact:
Exploit Impact is the crucial Step where we perform the following activities:
1.     Bucketizing similar crashes to form a list of unique crash stacks and number of crashes observed in the live application state to remove duplicity.
crash_data_table:
bucket_id
crash_stack
crash_count

2.     Collating responsibly disclosed security incidences/researches and Zero day exploits to assign vulnerability type, criticality.
exploit_data_table:
exploit_id
vulnerability_type
stack_trace
criticality

Now that we have the raw-data collated for real-time crashes observed on the application and historical data on responsibly disclosed security incidences we can now work on making sense out of this data. The next steps can be:
1.     After manual evaluation and filtering, list of all vulnerable APIs reported can be collated into one table with exploit_id associated and bucket_id(s) to define susceptibility of an API. Crashing_api_table:
api_id
api_name
exploit_ids
bucket_ids
Possible Scenarios can be summarized into these three primary cases in Figures i,ii,iii:

 
fig(i): describes point of intersection between bucket crash stack and exploit crash stack trace

Figure(ii): describes point of deviation between bucket crash stack and exploit crash stack trace



Figure(iiI): describes point of conjunction between bucket crash stack and exploit crash stack trace

c.     Exploit Criticality:
Criticality for every security incidence reported depends on the type of vulnerability and area impacted by it, unless it’s not a Zero day which needs to get fixed and shipped immediately, and now that we have the health status of every crashing API for every mitigation the decisions become easier with
Crashing_api_table:
api_id
api_name
exploit_ids
bucket_ids
build_id

Priority = Function(Sum_of_all_priorities(exploit_id(s)), crash_count(bucket_id(s)) and,
Vulnerability Popularity Trend in the market shared as research by Threat Intelligence organization.
d.    Security Mitigation:
Mitigation will depend on what strategy to follow and is an organizational decision on how to tackle a type of exploit and what possible measures can be introduced to increase the cost of an attack.

e.     Mitigation Impact & Tracking:

For every mitigation shipped into the market there is an investment associated to increase the cost of generating another exploit in the same code using advanced approaches as described earlier. Thus impact of a mitigation becomes vital to evaluate the quality of the mitigation shipped into the market. Impact of a mitigation starts internally when all the reported security incidences become inoperable followed by tracking new crashes and incidences reported for an api_id inside Crashing_api_table for the latest build(build_id) in the market.