Code Auditor's Corner » Application Security

CSSLP Deconstructed Available for Download

Alexander Fry — Mon, 19 Apr 2010 11:29:21 +0000

I gave a presentation at ISSA-NOVA on January 21, 2010 entitled the “The CSSLP Deconstructed”. The slides provide an introduction for the new CSSLP credential and also :

describe each of the seven domains of the CSSLP
diagram the overlap of the CSSLP with other security certifications
discuss security certification in general, if you should pursue the CSSLP, and effective career management
review the The CSSLP Prep Guide
and discuss other topics such as software security risk, recent threats, and addressing risk for 3rd party software

The PowerPoint slide deck is available for download in the RESOURCES section on Strong Crypto.

OWASP Haiti Relief Effort

Alexander Fry — Fri, 22 Jan 2010 12:33:02 +0000

OWASP has created an “OWASP for Charities” project. They set up a secure and trusted way for those within the OWASP community to donate funds to help the people of Haiti. The following is the e-mail announcing the effort that was posted to the OWASP mailing list:

OWASP Members and Supporters,

OWASP was founded, and is supported as a non-profit organization, by a group of dedicated volunteers who believe that all applications should be secure and trusted. As our organization matures we have taken those beliefs broader, and have started setting up ways for our members to donate to the global community. Among these initiatives are:

OWASP has an active Kiva lending team who have donated $9,125.00 to date. http://www.kiva.org/community/viewTeam?team_id=522
OWASP in response to the need in Haiti has set up a secure and trusted way for those within the OWASP community to donate funds to help the people of Haiti. This allows our OWASP community to help another with a single global voice. 100% of the collected donations will be transferred directly to victims for disaster relief such as food and medical requirements. Please visit www.owasp.org and click the link for G33k-4-HAITI. In a time of crisis, OWASP can help those who are in great need. The OWASP community can help organize, support , and promote efforts outside of application security.

OWASP is well aware there is a movement for phishers to utilize this tragedy to get unsuspecting people to donate to a “cause” without having a legitimate business back end and ultimately funneling all the money directly into their own pockets. The OWASP community is uniquely qualified to help protect from this type of attack and educate about attacks as well.

As the world becomes more dependent on technology and particularly web applications, there are many who need protection who simply have no options to protect themselves. These include small companies, individuals, charities, and others. The OWASP community can help by connecting qualified, trusted resources willing to volunteer their time to those organizations which qualify. OWASP is setting up an outreach program, which will be under the name project name of OWASP for Charities.

We hope you will support OWASPs efforts to make a difference in any of the above ways. We are also open to suggestions in regards to where you feel the OWASP Community can be of service.

Regards,

Your OWASP Board

Seven Domains Of The CSSLP

Alexander Fry — Mon, 18 Jan 2010 17:34:00 +0000

Here are descriptions for the seven domains of the CSSLP for my presentation at ISSA-NOVA on January 21, 2010:

Secure Software Concepts – the fundamental knowledge for understanding the security implications of software development, and the mechanisms to impose security constraints on the behavior, use, and content of a software system. This includes security design and information assurance principles, risk management, software architectures, legal issues, standards, acquisition methods, information security and software maturity models.

Secure Software Requirements – the overall software specification should include both functional and nonfunctional requirements. The nonfunctional requirements of secure software address issues such as how the software application will: remain dependable under hostile operating conditions; resist compromise by an attacker through the exploitation of vulnerabilities or insertion of malicious code; and be resilient enough to recover quickly, containing damage to itself, data, resources, and external components on which it relies.

Secure Software Design – fundamental activities that approach the definition of the software from a security perspective in order to decrease the likelihood that the design specification will contain flaws. These activities include identifying and minimizing the software’s attack surface, performing threat modeling, and following security design principles.

Secure Software Implementation/Coding – software developers should follow secure coding best practices and standards, understand and avoid common vulnerabilities, implement countermeasures, and use tools and techniques such as static analysis and code review to avoid introducing flaws that can lead to security vulnerabilities.

Secure Software Testing – activities for evaluating a software application in a runtime environment that most closely resembles its production environment. Many testing activities require the application to be functionally complete and follow standards and methodologies such as ISO 9126, the SSE-CMM, and the Open Source Security Testing Methodology Manual (OSSTMM). Security testing should assess the security properties and behaviors of the software application as it interacts with external entities and as its own components interact with each other. An analysis of test results forms the basis for assessing risk and means of remediation.

Software Acceptance – ensuring that the software is ready to be released. This involves pre-release or pre-deployment activities such as generating test data that shows that all prescribed tests have been executed and accepted; and post-release activities such as an independent review of the software conducted by a third-party or by an independent security team of the organization.

Software Deployment/Operations/Maintenance/Disposal – maintaining information assurance during installation, deployment, operation, maintenance, and disposal of secure software systems.

Tools Are No Silver Bullet

Alexander Fry — Wed, 09 Dec 2009 22:53:23 +0000

People sometimes ask me how effective and where to apply a software security tool so I thought I would publish a few ideas on the subject. First, there are so silver bullet solutions for application security; tools play a role, but most tools have a greater impact if used earlier in the software development lifecycle. That is, if you use a static analysis tool in the software construction phase, running a dynamic analysis tool in the verification phase should tell you that you did a pretty good job fixing known problems. And testing your application in the deployment phase will provide some additional assurance that you are somewhat protected against emerging risks. But every time your application requires maintenance, it goes back to the construction phase, and should go through the same software assurance process before being re-deployed. If you have public-facing applications, legacy applications, and applications that have already had security issues, i.e., compromises, then maybe a Web application firewall should be part of your arsenal, but it does not address the root cause of the problem. A Web application firewall is a tourniquet for an application that has existing security issues or is high risk and can not defend itself. If the application was designed securely, built securely, and maintained securely, then it should be self-defending, and therefore, not require a Web application firewall.

Next, how about a legacy application that does not implement proper authentication or validation. Sure, you could integrate a security API like ESAPI, but what about using a framework that already has those capabilities built-in and instructing the developers on the best practices for using them? The best practices and mechanisms to build secure software should be part of the core software development frameworks and libraries and implemented as part of a standard software engineering process. Also, an organization should specify which frameworks are acceptable. If a framework does not provide capabilities to build secure software, it should not be used. Let’s go one step further and take applications that come under regulations like FISMA or PCI. All Web applications that are Moderate or High baseline should use a managed language such as .NET or Java and any additional frameworks or APIs should provide the developer with the tools to secure the applications. Oftentimes, automated static analysis tools only understand common software development frameworks and libraries. If you use bleeding edge or unsupported frameworks, or interpreted languages, your application may not be understood by automated static analysis tools, and can only be properly secured by a security-knowledgeable developer or application security expert. That is a poor model for continuous monitoring and maintenance.

Application security tools should be used by those people who best understand the application and how to write code. When an information security professional, who does not have a software development background, runs a Web application vulnerability scanner and turns up a ton of potential vulnerabilities, he/she has a hard time determining which results are false positives or true positives. Likewise, if a static analysis tool turns up several hits on an application’s source code, the best person to interpret the results is the software developer who wrote the application and has been trained in application security. The domain expertise is with the developers – the tools should be driven down to the developer level. Just like IDEs have plugins for unit testing, they should have plugins for static analysis, and that includes security. That is why compilers have flags for common errors, including security problems; so that the developers know that they must fix the problems in order to pass GO. More on this later.

Welcome To the Code Auditor’s Corner Blog

Alexander Fry — Wed, 30 Sep 2009 16:20:52 +0000

The Code Auditor’s Corner is a place to discuss the security issues that I typically encounter while auditing software applications. I also want to share my philosophy on how security should be approached in software development, and many other topics including:

the attacker’s perspective
auditing source code
tools and techniques to facilitate secure programming
software security education and training
the csslp credential
traceability of security requirements to design
security testing
security vulnerabilities in different programming languages
choosing the right architectural frameworks for your programming project
Web applications, Web services, and other software applications

Stay tuned!