* — Recommended by PCI DSS.
Estimates are based on scopes we have seen amongst start up and mid size software companies with revenues less than $50M

Transformation from SDLC to S²DLC is on!

Some of the software companies I have interacted with are now getting really serious about security. They bake security into everything, bring in security architects, build around secure technologies, hire excellent pen-testers and code reviewers etc.; the whole nine yards to transform their SDLC process to a S²DLC process.

The Cut above the Rest; Showcase Security

But the companies that really get it leverage their security initiatives and derive business benefit from it. I think salesforce.com is a sterling example. They have a website dedicated to communicate with their customers on the security of their systems and the processes and certifications they maintain. Companies that get it will leverage and market their security programs and initiatives as a sign of maturity giving prospects a confidence in their solution and even an edge in the prospects mind where most of the battles are really fought. When prospects learn that their software vendors take security more seriously that they themselves do, then confidence in the security of your offering starts residing in the customers mind.

Security Code Reviews: Rises to the Occasion

Security Code Reviews certainly fall in the category of major confidence boosters. Technically speaking they are a great way to catch accidental back doors, malicious back doors and all the vulnerabilities that an application penetration test with the added advantage that your developers now will know exactly where the defective code lies.

Everybody’s Happy: Fix Code Faster for Less

Security Code Reviews makes fixing much quicker which application and business owners love. But the flip side always has been the cost of doing these comprehensive code reviews. The costs over the years have come down and today are pretty reasobale and comparable to what you would pay for an application penetration test. Certainly great news for all those application and business owners out there with PCI Compliance, due diligence questionnaires, demanding customer evaluators and aggressive sales guys to deal with.

Bottomline

Attn: Application Owners & Product Managers: Security Code Reviews are costing much less today and can get you an edge in the customers mind.

Terence Cornelius, one of our senior security consultants, has written an article on “Best Practices for Protecting Banking Sites” at the Bankers Online website.

Terence provides a 14-point checklist that banks can use to quickly ensure that their public facing websites are safe.

We are often asked how frequently an application should be tested for security. In this post, I’d like to discuss the criteria for determining the frequency of tests.

First, let’s review the benefits of doing periodic penetration tests:

1. New attacks are invented regularly. Jeremiah Grossman compiles a list of new attacks invented each year. He counted 70 new techniques in 2008, 83 in 2007 and 65 in 2006. That’s 15-20 new attack ideas each quarter. A periodic test keeps you current on all the latest attacks too.
2. New features (and bugs) are added regularly If your application adds new features regularly, then any of those new features could also introduce security holes. In our periodic tests, we’ve noticed that new holes are added almost every time new features are added. Periodic tests are useful to spot them.
3. There’s more focus on the residual holes This not-so-scientific graph shows the pattern of open vulnerabilities after repeated tests. This is what we’ve observed after our periodic tests, and suggests that developers fix tougher, residual holes after the easier ones are fixed.

Based on these observations, here’re the criteria we recommend for you to determine the ideal frequency for your security tests:

• Sensitivity of the data: If your application handles sensitive data like credit cards, you’re a more likely target for new attacks, so test the app more frequently.
• Criticality of the Application: If your application is business critical, it’s better to test it more frequently and reduces your risk.
• Frequency of changes: If your application adds new features or undergoes changes regularly, test it more frequently.

Most of the sensitive applications under our care are tested quarterly. The less sensitive ones are tested once in six months. The less sensitive ones with no changes are tested only annually.

Earlier Posts

• Plynt wins "Tomorrow's Technology Today" Award | 21 Apr 2009
• Lessons Learned in Managed Risk Services | 20 Apr 2009
• URLScan - First Line of Defense | 27 Mar 2009
• New Massachusetts Data Protection Standards, which states are next? | 05 Mar 2009
• OWASP Australia - Code Review Techniques | 26 Feb 2009