A Successful SAST Tool Implementation
1 like1,394 views
The document discusses implementing a static application security testing (SAST) tool. It recommends starting with a central scanning model where a security team scans code and reports vulnerabilities. Over time, the organization can transition to a full software development lifecycle model where developers use the tool during coding. Key factors for a successful implementation include choosing the right scanning model, training users, and establishing processes for fixing and verifying issues. The document also provides tips on maximizing returns and reducing costs such as licensing the tool granularly and keeping deployment and training short.
A Successful SAST Tool Implementation
- 1. A successful SAST tool implementation By Assaf Pilo – Director of Sales and Marketing, Checkmarx [email protected], Jan 2012 The development world has come to realize that the way we build applications opens the door to hackers. We are starting to realize that it is the code itself that is enabling the attacks. It’s the responsibility of the development team to build software that is inherently impervious to attack. Catching and dealing with security defects earlier in the development lifecycle is much more economical than dealing with them once the applications have been deployed. Traditionally, the responsibility of security in development had been left to specialists who had their own tools to provide security guidance to development. This approach, while often effective had proved costly, and more importantly, did not easily integrate into a software team’s process. And there were technical problems: Current static analysis tools generated significant false positive results. This further exacerbated the problem by forcing teams to track down problems that do not actually exist. Recently there have been fundamental changes in the static security analysis tool arena. They are usability, efficiency and false positive reporting. These changes address the major issues that developers have shied away from the earlier tools: These next generation tools are designed to integrate with normal software engineering workflows, accurately report on security defects, and suggest techniques for repair that fit the engineer’s development and testing process. These tools, typified by CxEnterprise from Checkmarx, allow static analysis to integrate with the development teams IDEs and allow security analysis to take place as part of their normal iterative design, code, test, and analysis process. Integrating in this manner allows the users to solve real problems, and get smarter in the process. Users gain insight to what secure code looks like, and how to incorporate that knowledge into future activities. Once you have chosen a tool, you will be able to complete comprehensive code audits with minimum effort and fewer resources. In matter of minutes you can now scan for OWASP, SANS, CWE, PCI as well as other standards and regulations and discover security vulnerabilities. A common question among organizations that are considering implementing a SAST tool is how to plan and prepare a smooth implementation and be able to prevail over the expected obstacles. In order to do so, you should be able to answer these questions: Who should be the SAST tool owner in your organization? What type of license, and how many are needed for your organization? How should the licenses be distributed among the different roles and development teams? What resources are necessary in order to deploy the tool, and how long will it take? Which users should be trained, and what is the appropriate training level for each role? Scan methodology: o What scan model should be implemented? Central or full SDLC? o Who is responsible for scanning the projects? o Who is responsible for reviewing and fixing results? o How do you verify that the code has been fixed according to the findings? www.checkmarx.com
- 2. A successful SAST tool implementation By Assaf Pilo – Director of Sales and Marketing, Checkmarx [email protected], Jan 2012 Results: o How to avoid an overflow of results? o Classification and prioritization of results (company and specific projects). o Choosing the right scan presets (OWASP, SANS, PCI etc.). o Dealing with “false positives” (are they really false positives?). How can you increase the ROI and reduce the TCO? There are 2 main scanning models: i. Central Scanning Model – recommended for deployment phase #1 ii. Full SDLC Scanning Model – recommended for deployment phase #2 www.checkmarx.com
- 3. A successful SAST tool implementation By Assaf Pilo – Director of Sales and Marketing, Checkmarx [email protected], Jan 2012 Central Scanning is the best way to begin using a SAST tool. The main effort is in installing the system and training a few selected people, primarily the security team. Productivity is immediate, as the tool will begin producing audit reports soon after the installation is completed. A Central Scanning model can be implemented and used in 2 modes: i. The security engineer centrally scans the projects for all development units. ii. Automated scanning; scheduled scans and/or automated build scans. In a Central Scanning model, developers can review results either by using the tool’s IDE plug-in, client, or different report formats. It should be decided whether the developers receive raw results, or alternatively, after someone has reviewed, prioritized and forwarded a customized report for them. A few key elements are needed for successful central scanning: i. Rapid and effective deployment and training. It should take no longer than 3 days to fully install the system and train a handful of users. ii. Simple installation and connectivity – a SAST server which is IDE indifferent and platform independent, allows scanning different languages without installing and updating the different compilers. All that is needed for scanning is access to the source code repository. iii. Ability to scan non compiled code – allows simple scan setup, without the need to contact and communicate with the developing teams in order to obtain the different project components (DLL’s, JAR’s, libraries etc.). iv. User friendly UI – using the same UI for all the different languages makes life easier, especially if a web UI is used, in which case you do not need to install any client or change your end-users PC image. A web UI also permits the running of the tool from any operating system. v. Building an effective workflow which defines the organization’s security policy, best coding practices, scan schedules, remediation policy and responsibilities. There are different approaches to Central Scanning, but here are some of the recommended basics: Choose no more than 5-10 applications to scan for the first 2-3 months. You will find it easier to review and discuss the results (you should have plenty on your first scans) with the development teams or projects. Scan both projects and security issues, from high priority downward: o o High priority applications low priority High risk vulnerabilities presets medium threat low threat best coding Train the developers and make sure they are familiar with the scanned vulnerabilities, as well as with the tool and the way results are presented. After you have accumulated some mileage with your SAST tool in the Central Scanning model, it’s time to consider a Full SDLC, getting the development teams more involved in reviewing, and remediating the code. www.checkmarx.com
- 4. A successful SAST tool implementation By Assaf Pilo – Director of Sales and Marketing, Checkmarx [email protected], Jan 2012 The Full SDLC Scanning model clearly shows that your organization has matured and is taking responsibility by practicing secure coding throughout the coding stage. By scanning the code as it is being developed, the organization can expect some major benefits: i. Fixing fewer findings as the code is being developed. Once ready for release, projects will have fewer issues to fix in preparation for production. ii. By providing a SAST tool for developers to use, a steep learning curve is often achieved, as they tend to better understand the vulnerabilities and their causes, as well as how to avoid them in the future. iii. The majority of technical vulnerabilities can be easily detected and fixed during the coding stage. This results in fewer complex and business logic issues for regulatory audits or penetration testing (if practiced). Here are some of the recommended distributed scanning basics: Train the trainers; power users on each development team. Once they will have the knowledge, they will be able to run scans, review results and provide support to their respective teams. Train the developers and make sure they are comfortable with the scanned vulnerabilities, as well as with the tool and the way results are presented. Build a clear process and security policy, so that developers understand what is expected from them; when and what to scan, and what to do with the findings, etc. Gradually deploy the developers UI’s, adding a few teams at a time. Maximizing the ROI while reducing the TCO is extremely relevant in today’s economy. Some of the factors that should be taken into consideration are: i. Licensing costs – granular licensing model enabling low entry price ii. Infrastructure costs – standard hardware and 3rd party software iii. Deployment and training costs – just a few days to full production iv. Implementation costs – flexible and quick customization process v. Operational costs – less management and administration needed vi. Full SDLC – enablement due to non-required build and support of partial code scanning vii. Tool productivity – large number of scans per month, high precision and effective remediation Checkmarx experts have implemented hundreds of systems around the globe, experiencing a large variety of verticals, companies, development environments and organizational models. We are more than ready to share our experience with you and your company, so that you too can successfully deploy and use our SAST technology and improve your secure coding methodology. www.checkmarx.com