The AppSec How-To: Choosing a SAST Tool

Transcription

1 The AppSec Hw-T: Chsing a SAST Tl Surce Cde Analysis Made Easy GIVEN THE WIDE RANGE OF SOURCE CODE ANALYSIS TOOLS, SECURITY PROFESSIONALS, AUDITORS AND DEVELOPERS ALIKE ARE FACED WITH THE QUESTION: Hw t assess a Static Applicatin Security Testing (SAST) tl fr deplyment? Chsing the right tl requires different cnsideratins during each stage f the SAST tl evaluatin prcess. Evaluatin Preparatin The fllwing qualifiers are required prir t testing the SAST tl in rder t set initial expectatins: 1. List f languages. Ensure that the SAST tl supprts the languages in the develpment envirnment. 2. Access t surce and binary files. Sme SAST tls run nly n the surce cde files (pre-cmpilatin scanning), while thers run n the binaries (pst-cmpilatin scanning). As ppsed t scanning n the surce cde, pst-cmpilatin scanning requires all prject dependences in rder t run the scan. 3. Deplyment. Cnfirm the SAST tl supprts the preferred mde f peratin - n premise r n-demand. 4. Parties within the rganizatin respnsible fr cde security. Define hw cde security is managed within the rganizatin. Fr example, ne rganizatin might prefer having a dedicated team such as cde auditrs r an applicatin security team which prvides the security services t the rganizatin. While anther rganizatin might decide that each develpment team has an individual respnsible fr the security. Each f these management mdels influences the SAST tl architectural setup- including licenses, deplyment and tl s usage. 1

2 Surce Cde Analysis Made Easy STAGE 1 Installatin Ease f installatin during this step includes: 1. Resurces. Evaluate whether installatin f the SAST tl is manual r autmated. If manual, cnsider whether installatin requires specialized knwledge as well as the number f installatin man-hurs. 2. Scalability. Client sftware installatin requires develper dwn-time during installatin and additinal installatin time per endpint. A centrally-managed installatin is a ne-time nly prcess where additinal servers can be added withut the need fr system duplicatin. 3. Licenses. Sme licensing schemes are distributed where each endpint requires its wn license. In ther cases, the license is centrally-managed and is n a per-user basis, eliminating the need fr multiple licenses. STAGE 2 Set-up Tw measuring factrs need t be cnsidered: 1. Effrt and cmplexity Simplicity. Scanning verhead shuld be kept t a minimum. Scanning surce cde shuld nt require the user t perfrm excessive peratins t start running the tl. Scaling t ther languages. Adding a new language shuld be seamless t the envirnment and shuld nt entail a new scanning setup t supprt the language. 2. Time Scanning regardless f the SAST tl - takes time. The pint here is t cnsider the SAST features, r the different scanning methds, that the SAST tl prvides t speed up the scanning prcess. Fr example, being able t scan prtins f the cde is particularly helpful when there are lts f develpers and cde t scan. 2

3 STAGE 3 Scan capabilities Surce Cde Analysis Made Easy Scanning capabilities include: 1. Range f supprted languages. The SAST tl shuld nt merely supprt the current develpment languages (as specified when qualifying the tl). It shuld als supprt emerging technlgies as these may prve t be significant in the lng run. Fr example, mbile r updated develpment languages (e.g Andrid, Objective C, Ruby n Rails). 2. Range f supprted framewrks. Supprting the develpment s framewrk allws the SAST tl t identify cding vulnerabilities, as well as t eliminate any false reprting that results frm nt recgnizing the framewrk. 3. Multiple scans. The ability t run simultaneus scans r supprt multi-chaining, multi-threading r multi-cre prcessing envirnments. 4. Vulnerability cverage. There are different classes f vulnerabilities that the SAST tl shuld address: Technical security vulnerabilities. Detectin f cmmn vulnerabilities as identified by different industry standards such as OWASP Tp 10, SANS and CWE. Since the vulnerability taxnmy and ratings differ by each SAST vendr, it is necessary t receive frm each SAST vendr their list and nrmalize them ne against the ther fr a true vulnerability cverage cmparisn. Business lgic flaws. These include authenticatin by-passing mechanisms, as well as backdrs in the applicatin. Best cding practices. Fr example, errr handling, elements usage and race cnditins. 5. Result accuracy. T ensure the accuracy f the results, the tl shuld scan and its utput cmpared against a test applicatin fr which the results are knwn a-priri. One such cmmn test bed is OWASP s WebGat prject. Hwever, the real test shuld be against an in-huse applicatin- unknwn t the tl t prevent the tl frm being tuned in advanced t the testing envirnment. Result accuracy is measured by: Amunt f True Psitives (TPs). The percentage f results that have been crrectly identified as actual vulnerabilities. Amunt f False Psitives (FPs). Althugh there is n such SAST tl tday that will utput a ttally FP-free scan, the ideal is t achieve a minimal amunt up until a handful f these. 6. Custmizability. The ability t adapt the scan results t the specific sftware framewrks and business lgic f the rganizatin. Each rganizatin uses its' wn framewrk fr accessing databases and sanitizing input data and s the SAST tl must be custmizable t the prprietary cde. This capability als eliminates false psitives that ccur due t the custm cde and the rganizatin s business lgic. 3

4 Surce Cde Analysis Made Easy 7. Ability t aggregate scans. Aggregatin allws all the scans f the prject t be displayed as a whle. STAGE 4 Results Management Scan results need t be presented in a clear manner t enable cnvenient and quick fixing. 1. Results analysis and management tls. Results analysis shuld prvide the user with the relevant security intelligence and tls t remediate flaws in virtually zer-time. Vulnerability flw. Visibility int the cde flw dwn t the exact line f the vulnerable cde helps develpers t understand the vulnerability flw and its meaning. Best fix lcatins. Optimal vulnerability remediatin can be presented in textual r visual frmats. Fr example, the ability t pinpint the precise vulnerability which- if fixed-eliminates all vulnerabilities that depend n that particular cde flaw. Tagging and filtering capabilities. Users shuld be able t grup results accrding t plicies, and priritize results frm highly imprtant t un-explitable. Further, the tls shuld prvide the ability t filter ut results as in the case f a test directry. Ability t track prjects. The scan tl shuld be able t keep the status f vulnerabilities between scans fr tracking purpses. Scan cmparisn. The SAST tl shuld enable the cmparisn f results frm ne scan t anther t mnitr the state f vulnerabilities. 2. Reprts. The tl shuld prvide multiple layers f reprting. Dashbard. Prvides a typical executive summary sectin with a high-level verview f the state f the applicatin s cde. Reprts per plicy. The ability t cnfigure a reprt t present nly relevant infrmatin. Fr example, PCI. STAGE 5 Integratin int the SDLC There are bth lgical and technlgical aspects when integrating surce cde analysis within the Sftware Develpment Life Cycle (SDLC): 1. SDLC mdel. Measurements include: Early-stage scanning. Scanning early supprts SDLC s fundamental cncept f fixing cde flaws including security vulnerabilities - as early as pssible within the develpment prcess. Varius SAST tls prvide the ability t scan cde prir t cde cmpilatin, r befre the cde s check-in. 4

5 Surce Cde Analysis Made Easy Supprt fr secure Agile develpment and Cntinuus Deplyment envirnments. Agile and Cntinuus Deplyment (aka DevOps) mandate that scanning must be dne within minutes, and cannt tlerate any latency due t excessive prcessing, scanning verhead and fixing. Accrdingly, the SAST tl shuld enable the develpers t perfrm ad-hc scanning frm within their develpment envirnments. Rescanning. Rescanning a prject shuld nt require the redundant scanning f files previusly analyzed. Fr example, SAST tls with incremental scanning features scan nly the cde and its dependencies that were mdified frm the previus scan. 2. SDLC tls. The SAST tl shuld be able t incrprate, as-if naturally, within the enterprise systems withut requiring extra tuning r cnfiguratin. The pint here is nt nly t save develper time but als making security part f the develpment prcess. Suggested integratin pints include: Develpment envirnment. The SAST tl needs t seamlessly fit int the develpment envirnment regardless f language and cmpiler versins. This als includes integratin within the IDE-develpment tl (e.g. Visual Studi, Eclipse, IntelliJ). Build management tls. e.g. TeamCity, Bamb, Jenkins, Maven and Ant. Surce-cde repsitries. e.g. GIT, SVN, TFS, Mercurial, ClearCase. Several SAST tls can run within the surce cde repsitry, withut even requiring a build management system. Bug-tracking system. The SAST tl shuld be able t inject results f the scan int bug tracking systems t priritize vulnerability fixing accrding t release schedule, time t fix, vulnerability impact, and hw it fits with ther tasks. STAGE 6 Respnsiveness and Supprt f Vendr Last but nt least, a SAST purchase is an nging prcess. Just like any tl, there may be questins regarding its usage, best practices and f curse, custmizability aspects. Cnsider the fllwing services frm the vendr: - Implementatin f custmized SAST queries (aka rules) and plicies fr yur prprietary cde - Engineer supprt and training fr the SAST tl users - Accunt manager t accmpany yur rganizatin thrughut the lifetime f the SAST tl - Availability and respnsiveness t inquiries thrughut the lifetime f the SAST tl 5