cleanscape logo

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.

Cleanscape SAST for Fortran

Software Development Powerfully Simplified

Purpose of CASAF

CASAF is a vulnerability/threat detection tool for Fortran source code. This class of tool is known in the industry as SAST (Static Application Security Testing)

CASAF’s function is to detect Common Weakness Enumeration (CWE) vulnerabilities identified in two sources:

1. The Top 25 CWE weaknesses as enumerated in “2011 CWE/ SANS Top 25 Most Dangerous Software Errors” (http://cwe.mitre.org/top25/index.html). 

  1. The 14 CWE weaknesses identified by the NSA Center for Assured Software (CAS) report, “Static Analysis Tool Study – Methodology” (https://samate.nist.gov/BF/Enlightenment/CAS.html).
 

Since ‘Fortran’ does not appear in the CWE, Cleanscape interpreted each of the above CWE weaknesses for applicability in Fortran, developed executable test cases demonstrating the weakness, researched and documented real-world instances on the Web, and developed analysis countermeasures.

CASAF itself is hardened against cyber breaches. It self-repairs removal of analyses or analysis results, and can report such attempts in a confidential fashion to management (i.e., user is unaware her/his breach attempt was detected/reported).

Future releases will increase the number of vulnerabilities detected, continually refine individual analysis capability, improve performance, and enhance resistance/ reporting mechanisms to tampering.

Application

Until recently, Fortran code was “grandfathered” from being subjected to vulnerability analysis because

CASAF Advantages

1.    The only commercial vulnerability analyzer designed specifically for Fortran.

2.    CWE threats were carefully reviewed and the concepts they describe thoroughly interpreted to extend their relevance to Fortran.

3.    Detected threats are color coded using Homeland Security’s Advisory System: Severe = red, High = orange, Elevated = yellow, and Guarded = blue.

4.    The command line version is easy to operate, and output results are organized by severity, filtered of duplicates, and colored according to the above scheme.

5.    Both the filename/line# and actual code are displayed in the results.

6.    CASAF supplies return codes, which makes it useful for automated test procedures.

7.   Built-in safeguards prevent tampering and will report such attempts to management without alerting the user.

THEORY OF OPERATION

Background

CASAF tests for CWE and NSA-CAS vulnerabilities, referred to in this document as CWEs. Since the word “Fortran” does not appear in the originating documents, Cleanscape interpreted each CWE’s applicability to Fortran, web-researched real-world instances where they were indeed occurring, and extended the vulnerability definition to encompass Fortran-unique issues. We then created executable demonstration cases in Fortran, which then became the basis of, and test cases for, CASAF’s analysis subtests.

In deriving the CASAF solution, Cleanscape’s goal was to provide a tool to assist in human resolution for vulnerabilities which can have serious consequences. Our detection is quite focused (Red threat level tests) but also casts a wide net (as can be seen in the Blue threat level tests). We use heuristics to reduce false positives, and provide a means for users to filter false positives from their report after having reviewed (eyeballed) each such case.

In many cases, CASAF utilizes Fortran-lint’s (Flint’s) true parser technology to identify and isolate issues, or to data-mine Flint’s cross reference to ascertain variable usage relevant to CWEs. In other cases – for instance, where preprocessor data is involved – CASAF must scan raw source code before it is even input to the parser and before comments have been removed.

Organization

CASAF consists of an executive program and an ever-expanding list of CWE threat detection programs.

The executive program – named casaf or casaf.exe on Windows – runs a Flint error check on the Fortran source, amasses a large and diverse dataset, and configures a common workspace for all CWE tests to access. It then gathers all the CWE test results, sorts them, and eliminates duplicates. Finally, it color-codes and presents the results to the user.

The threats expressed in each CWE from Mitre’s document are encoded for detection in a single executable in the cwe subdirectory; for instance, the weaknesses described for CWE #676 are detected in program cwe676 or cwe676.exe.

The executive calls each test executable to satisfy the list supplied by the user (using the -T operand), and each test executable avails itself of the single workspace created by the executive.

In version 1.0, there are 37 CWE tests. Since a CWE generally has broad meaning, we created 163 unique subtests to address issues described in the CWEs. These 163 unique subtests are sequenced into 528 individual analyses to satisfy the requirements of those 37 top-level CWE tests.

Procedure

Process

CASAF tests a single Fortran sourcefile (known as the UUT = Unit Under Test). The actual number of files analyzed may be greater due to #include or INCLUDE statements, plus any additional files necessary to fulfill USE statements inside the UUT. Since CASAF opens these files automatically, include and module files should not be specified to CASAF – just a source file with standard Fortran file extension.

The UUT must compile without errors. In addition, to minimize false positives, CASAF also invokes Cleanscape Fortran-lint (Flint) to ensure there are no severe errors present in the code. If there are, CASAF will halt, and the next step would be to proceed with Flint static analysis and eliminate errors (warnings are OK) in the UUT and associated include or module files.

You tell CASAF if the UUT is standalone (-SA) or part of a
project (-P).

By being standalone, we mean there are no USE statements inside the UUT which would require modules from other files.

Otherwise, the UUT is part of a project and for analysis to be successful, the files containing the USEd modules must be brought into the analysis – an automatic process. To do that, CASAF needs to know the USE dependencies for the entire project, which is accomplished by using a special mode, invoked by running CASAF -G. This is only necessary when the project structure changes (e.g., files added or deleted) and provides USE dependencies so CASAF can add the necessary files – and only the necessary files – to the analysis.

Results​

Analysis results contain the subtest message, the filename/ line number of the “offending” line of code, the actual sourceline for quick reference, and the threat level. CASAF adopted Homeland Security’s Advisory System of color-coded threat levels: red, orange, yellow, and blue, and the output is literally in each of these colors on-screen.

These are not indicators of severity, but rather how closely the detected issue maps to the CWE vulnerability. Therefore, each analysis result should be treated as significant. The further down the threat scale, the “fuzzier” the threat potential becomes. To demonstrate, here are two examples – one Red, one Blue – from the subtest error description file casaf.err:

R1 Path traversal ‘../’ detected in OPEN
B18 Assess privilege escalation

We also provide an Internal category of issues, which can appear to the user as classic “unexpected internal error”, but in reality, is detecting an internal (insider) threat operating in/around the code. CASAF can surreptitiously notify designated management of the potential breach.

As regards internal threats, CASAF is hardened against deleting subtest messages or analysis results, and can notify management of possible tampering.

What Customers Are Saying

“Since vulnerability analysis for Fortran code has been mandated by our defense customer, CASAF is a welcome addition to the SAST space and positions favorably as an addition to our test software suite”

– Director of software quality, Fortune 500 defense contractor

“An innovative approach to SAST with a large number of vulnerability tests”

– Sr. software developer, Fortune 1000 aerospace contractor