This is Part 6 of a 'How-To' effort to compile a list of tools (free and commercial) that can help IT administrators comply with SANS’ Security Controls. A summary of previous posts
- Part 1 - we looked at Inventory of Authorized and Unauthorized Devices.
- Part 2 - we looked at Inventory of Authorized and Unauthorized Software.
- Part 3 - we looked at Secure Configurations.
- Part 4 - we looked at Continuous Vulnerability Assessment and Remediation.
- Part 5 we took on Malware Defenses.
Now we are going to take on Application Security.
6-1 - For all acquired application software, check that the version you are using is still supported by the vendor. If not, update to the most current version and install all relevant patches and vendor security recommendations.
Free Tools
- Spiceworks - Though not a notifier for versioning, it does detect software versions, and you can build reports using this information, and auto email reports on a schedule, it can help.
- Secunia - Free online tool that can be downloaded for personal use to detect and update out-of-date software.
- AppUpdater - Small list of supported software, but updating can be automated without interaction. Supports Windows, Linux, Mac, and lots more features.
Commercial Tools
- Secunia - Enterprise grade software compliance suite
- See tools listed in control 3-2
6-2 - Protect web applications by deploying web application firewalls (WAFs) that inspect all traffic flowing to the web application for common web application attacks, including but not limited to cross-site scripting, SQL injection, command injection, and directory traversal attacks.
Tools
This is similar to the antivirus schpeel I gave in the previous article. Many antivirus programs take advantage of a layer 7 firewall. I'll let you research, but can point you to a very informative article also published by SANS titled, "Application Firewalls: Don’t Forget About Layer 7"
6-3 - For in-house developed software, ensure that explicit error checking is performed and documented for all input, including for size, data type, and acceptable ranges or formats.
This is more of a process than a tool. But if you know of any tools, let me know.
6-4 - Test in-house-developed and third-party-procured web applications for common security weaknesses using automated remote web application scanners prior to deployment, whenever updates are made to the application, and on a regular recurring basis.
Free Tools
- OpenVAS - An open source vulnerability scanner that can be configured to scan web applications for things like XSS (among others).
- Metasploit - A tool for the everyday pen-tester and security enthusiast.
- OWASP has published a list of tools (Free and Commercial), so without further ado...
6-5 - Do not display system error messages to end-users (output sanitation).
More of a process per application.
6-6 - Maintain separate environments for production and non-production systems.
This is more of a process than a tool. Essentially, you must create both a physical and a logical divide between your production systems and dev environment. I have always done this via VLANs, keeping the Dev VLANs completely off the production networks. Also, many people are of the mindset of adding the dev environment as sub-domains of your production domains. DON'T DO THIS. I have been successful at gaining access to higher domains from sub domains by exploiting a Kerberos weakness known as "forging a golden ticket". Complete separation, with an implicit block on your network firewall. That being said, I do allow explicit production traffic to enter the dev environments.
6-7 - Test in-house-developed web and other application software for coding errors and potential vulnerabilities prior to deployment using automated static code analysis software, as well as manual testing and inspection. In particular, input validation and output encoding routines of application software should be reviewed and tested.
More of a process than tool set. Though, certainly there are tools for QA members that can aid in software testing, I have no experience with any of them.
6-8 - For acquired application software, examine the product security process of the vendor (history of vulnerabilities, customer notification, patching/remediation) as part of the overall enterprise risk management process.
Again, more of a process than a tool.
6-9 - For applications that rely on a database, use standard hardening configuration templates. All systems that are part of critical business processes should also be tested.
Free Tools
- STIGs Currently, there are STIGs for MSSQL and Oracle, but the same concepts of these two platforms can be applied to other DB vendors.
6-10 - Ensure that all software development personnel receive training in writing secure code for their specific development environment.
This all comes down to training and who you hire, unfortunately :blush:
6-11 - For in-house developed applications, ensure that development artifacts (sample data and scripts; unused libraries, components, debug code; or tools) are not included in the deployed software, or accessible in the production environment.
I have seen in house tools that scan in house code, but do not know of any free or commercial.
About the Author:
Rich Johnson is currently a Systems Security Administrator with 15 years of professional experience working in IT (more if you count the years programming in Basic on the Commodore 64 and repairing Nintendo consoles as a child). Rich has a bachelor degree in Information Technology, but feels his real knowledge has been gained through hands on experience, exploring security tools, and attending various security conventions. Rich currently resides in Utah and is probably learning some new interesting thing at this moment.
