Budget options to secure your Killer Applications
| 1. |
Periodic Vulnerability Scanning*
(Catch network and standard application level vulnerabilities) |
~$150 |
| 2. |
Periodic Application Scanning*
(Catch application level vulnerabilities like SQL injection, CSS etc.) |
~$500 |
| 3. |
Periodic Application Penetration Test*
(Comprehensively catch application level vulnerabilities like SQL injection, CSS etc. including business logic security flaws) |
~ $750 |
| 4. |
Periodic Security Code Review* (Replaces 2 & 3)
(More comprehensive than 2 & 3 and also catch accidental / deliberate Backdoors in your source code) |
~ $1000 |
| 5. |
Daily Website Malware Scanning
(Catch malware infections on the publicly accessible pages of your websites) |
~ $50 |
| 6. |
Developer Training* on Secure Coding Guidelines
(Reduce security bugs by educating developers) |
~ $500 |
| 7. |
Security Log Monitoring*
(Monitor your webservers, firewalls, routers etc. on a real time basis to catch and deflect security attacks as they happen) |
~ $1000 |
| Budgeting Guide | Per Month (US$) | ||
|---|---|---|---|
| Minimum Budget | → | Go for 1,2 | ~ $650 |
| Modest Budget | → | Go for 1,3,5,6 | ~ $1450 |
| Recommended Budget | → | Go for 1,4,5,6,7 | ~ $2700 |
* — 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
Why Application Owners love Security Code Reviews?
Transformation from SDLC to S2DLC 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 S2DLC 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.
Best Practices for Protecting Banking Sites
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.
How frequently should an Application be tested?
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:
- 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.
- 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.
- 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
Recent Entries
- Why Application Owners love Security Code Reviews?
- Best Practices for Protecting Banking Sites
- How frequently should an Application be tested?
- Plynt wins "Tomorrow's Technology Today" Award
- Lessons Learned in Managed Risk Services
- URLScan - First Line of Defense
- New Massachusetts Data Protection Standards, which states are next?
What we are reading...
Archives
- November 2009
- October 2009
- June 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- May 2008
- April 2008
- March 2008
- January 2008
- December 2007
- November 2007
- April 2007
- March 2007
- February 2007
- January 2007
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
- February 2006
- November 2005
- October 2005
- September 2005
- August 2005
- July 2005
- June 2005
- May 2005



