Backtrack4 Final

Nema puno da se priča.
http://www.backtrack-linux.org/downloads/


Blogovi ::  m1k1



Povezani zapisi:

08-18-2010 4:18

The OWASP Top Ten and ESAPI – Final Summary

Ok, well now we’ve been through all the issues listed in the 2007 version of the Top Ten. The new 2010 version is very similar with a couple discrepancies. I may follow up on those couple of issues at a later time. Hopefully you’ve seen through all the articles in this series that ESAPI (specifically the Java version was used) was built to deal with quite a few real security issues that developers face today. This series has shown that ESAPI can be used in almost every instance to either partially or completely remediate a specific issue, and to do it properly. The ESAPI community is thriving, and good things are coming out frequently. New implementations of some controls are showing up. New people are joining. New issues are being tackled. Get involved with this community and make it better. Use the outstanding controls this group has kindly given away, and offer some of your own.

Hopefully this series has been helpful to you in moving closer to secure J2EE development by exposing you to ESAPI and all it has to offer. I’ll be moving on to different topics in the future. Hope you enjoyed this one!

As a reference, all the articles from the series are listed below for easy access.
——————
Part 1: The OWASP Top Ten and ESAPI
Part 2: The OWASP Top Ten and ESAPI – Part 2 – Cross Site Scripting (XSS)
Part 3: The OWASP Top Ten and ESAPI – Part 3 – Injection Flaws
Part 4: The OWASP Top Ten and ESAPI – Part 4 – Malicious File Execution
Part 5: The OWASP Top Ten and ESAPI – Part 5 – Insecure Direct Object Reference
Part 6: The OWASP Top Ten and ESAPI – Part 6 – Cross Site Request Forgery (CSRF)
Part 7: The OWASP Top Ten and ESAPI – Part 7 – Information Leakage and Improper Error Handling
Part 8: The OWASP Top Ten and ESAPI – Part 8 – Broken Authentication and Session Management
Part 9: The OWASP Top Ten and ESAPI – Part 9 – Insecure Cryptographic Storage
Part 10: The OWASP Top Ten and ESAPI – Part 10 – Insecure Communications
Part 11: The OWASP Top Ten and ESAPI – Part 11 – Failure to Restrict URL Access
——————

As a final note, I’d like to make a special request. If you have any requests for something you’d like to see here, an article on a specific topic involving J2EE web security, feel free to comment here or send me an email. My direct contact info is listed on the About page.

Technorati Tags: ESAPI, J2EE, Java, OWASP, Security

The OWASP Top Ten and ESAPI – Final Summary

Ok, well now we’ve been through all the issues listed in the 2007 version of the Top Ten. The new 2010 version is very similar with a couple discrepancies. I may follow up on those couple of issues at a later time. Hopefully you’ve seen through all the articles in this series that ESAPI (specifically the Java version was used) was built to deal with quite a few real security issues that developers face today. This series has shown that ESAPI can be used in almost every instance to either partially or completely remediate a specific issue, and to do it properly. The ESAPI community is thriving, and good things are coming out frequently. New implementations of some controls are showing up. New people are joining. New issues are being tackled. Get involved with this community and make it better. Use the outstanding controls this group has kindly given away, and offer some of your own.

Hopefully this series has been helpful to you in moving closer to secure J2EE development by exposing you to ESAPI and all it has to offer. I’ll be moving on to different topics in the future. Hope you enjoyed this one!

As a reference, all the articles from the series are listed below for easy access.
——————
Part 1: The OWASP Top Ten and ESAPI
Part 2: The OWASP Top Ten and ESAPI – Part 2 – Cross Site Scripting (XSS)
Part 3: The OWASP Top Ten and ESAPI – Part 3 – Injection Flaws
Part 4: The OWASP Top Ten and ESAPI – Part 4 – Malicious File Execution
Part 5: The OWASP Top Ten and ESAPI – Part 5 – Insecure Direct Object Reference
Part 6: The OWASP Top Ten and ESAPI – Part 6 – Cross Site Request Forgery (CSRF)
Part 7: The OWASP Top Ten and ESAPI – Part 7 – Information Leakage and Improper Error Handling
Part 8: The OWASP Top Ten and ESAPI – Part 8 – Broken Authentication and Session Management
Part 9: The OWASP Top Ten and ESAPI – Part 9 – Insecure Cryptographic Storage
Part 10: The OWASP Top Ten and ESAPI – Part 10 – Insecure Communications
Part 11: The OWASP Top Ten and ESAPI – Part 11 – Failure to Restrict URL Access
——————

As a final note, I’d like to make a special request. If you have any requests for something you’d like to see here, an article on a specific topic involving J2EE web security, feel free to comment here or send me an email. My direct contact info is listed on the About page.

Technorati Tags: ESAPI, J2EE, Java, OWASP, Security

HP (finally) Acquires Fortify

One of the great things about Twitter and iChat are their ability to fuel the rumor mill. The back-office chatter for the last couple of months, both within and outside Securosis, has been the rumor of HP buying Fortify Software. So we weren't surprised when HP announced this morning that they are acquiring Fortify Software for an "undisclosed sum." Well, not publicly disclosed anyway. In our best KGB voice, "ve have vays to make dem talk." And talk they did.

If you are not up to speed on Fortify, the core of their offering is "white box" application testing software. This basically means they automate several aspects of code scanning. But their business model is built on both products and services for secure software development processes as a whole; not only to help detect defects, but also modify the process to prevent poor coding practices while integrating into the tools used to track development projects. More recently they have announced some products geared for cloud deployments (who hasn't?) with their Fortify360 and Fortify on Demand products, designed to address possible weaknesses in network addressing and platform trust. New businesses aside, the white box testing products and services account for a bulk of the revenue.

Fortify was one of the early players in this market, and as such they focused on the high end of the large enterprise market. Thus, Fortify was subject to the vagaries of large dollar enterprise sales cycles, meaning from what we heard Fortify's revenues were a tad lumpy and unpredictable, with sales down a bit over the last couple of quarters. Of course, being private we can't publicly substantiate this, but we believe it to be true. To be clear, this is not an indicator of product quality issues or lack of a viable market; variations in Fortify's numbers have more to do with their sales process than the market's perceived value for white box testing or product. Gary McGraw's timely post on the Software Security Market reinforces this, and is a fair indication that there is growing need for security testing software and services. Regardless of individual vendor numbers (which are less than precise), the market as a whole is trending upwards, but probably not at the rate we'd all like to see given the criticality of developing secure software.

The criticisms I most often hear about Fortify focus on their pricing and recommended development methodology; both introduce unneeded complexity from being completely geared towards large enterprises. From an analyst perspective my criticisms of Fortify have also been the skew to enterprise totally made their offerings a non-starter for mid-market companies, where a lot of web applications get developed and an even more pressing need to white box testing exists. The processes and methodologies Fortify recommends may appeal to enterprises, but the maturity model and development lifecycles just don't resonate outside the Fortune 500. The analysts that will not be named have placed Fortify's product offering far in the lead for both innovation and effectiveness, but from my experience Fortify faces stiffer competition than these analysts would have you believe. In fact, depending upon the market segment and what problem need to be solved, there are equally compelling products.

That said, those comments lose relevance now that the product is under the stewardship of HP. Over the past few years, HP has made significant investments to build a full suite of application security solutions and now has the ability to package the needed application scanning pieces along with the rest of the tools and product integration features that enterprise software clients demand. Fortify's static analysis, assessment and processes are far more compelling when coupled with HP's black box testing and back office testing, problem tracking ad application delivery (Mercury). Oh, and HP's sales force is in a much better position to close the large enterprises where Fortify's product excels. And yes, that means Fortify is a really good fit for HP, and further solidifies its secure code strategy.

So what does this mean to existing Fortify customers? In the short term I don't think there will many changes to the product. The "Hybrid 2.0" vision that was spelled out in February 2010 is a good indicator that for the first couple of quarters the security product suites will merge without significant changes to functionality. Where the changes will come are the steps necessary to compete with IBM and the recent acquisition of Ounce labs; meaning there will be tighter integration with both problem tracking systems and some features tuned for IBM development platforms. It means that the pricing model will be cleaned up and aggressive discounts will be provided. And it means some short term instability with service as invariably there are disruptions to staff, training and new division of responsibilities.

But both IBM and HP will remain focused on large enterprise clients, which is good for those customers who demand a fully integrated, process driven software testing suite. It's natural to mesh the security testing features into existing QA and development tools, with IBM and HP uniquely positioned to take advantage of their existing platforms. Their push to dominate the high end of the market leaves huge opportunities for the entire mid market, who have been prolific in their adoption of web application technologies. The good news is there is plenty of room for Veracode, Coverity, Klocwork and Parasoft to gear their products to these customers and increase sales. The bad news is that these vendors will need to add dynamic testing to current static testing capabilities if they don't already have the capability, continue to innovate their way out of HP and IBM's shadow, and address platform support and ease of use issues that remain hurdles for the mid market. You are just not going to get very far if your software requires significant investment in professional services to be effective.

As far as acquisition price goes, the rumor mill had the purchase price anywhere from $200 million on the low end, to $270 MM on the high end. With estimated Fortify revenus in the $35-$50M range, that's a pretty healthy multiple, especially in a buyer's market. Despite the volatility of Fortify's revenues, an established presence in enterprise sales makes a strong case that a higher multiple is warranted. Moreover, the sales teams were already heavily collaborating, which likely helped make a better case as to why HP couldn't afford to lose this deal to someone else.

HP (finally) Acquires Fortify

One of the great things about Twitter and iChat are their ability to fuel the rumor mill. The back-office chatter for the last couple of months, both within and outside Securosis, has been the rumor of HP buying Fortify Software. So we weren't surprised when HP announced this morning that they are acquiring Fortify Software for an "undisclosed sum." Well, not publicly disclosed anyway. In our best KGB voice, "ve have vays to make dem talk." And talk they did.

If you are not up to speed on Fortify, the core of their offering is "white box" application testing software. This basically means they automate several aspects of code scanning. But their business model is built on both products and services for secure software development processes as a whole; not only to help detect defects, but also modify the process to prevent poor coding practices while integrating into the tools used to track development projects. More recently they have announced some products geared for cloud deployments (who hasn't?) with their Fortify360 and Fortify on Demand products, designed to address possible weaknesses in network addressing and platform trust. New businesses aside, the white box testing products and services account for a bulk of the revenue.

Fortify was one of the early players in this market, and as such they focused on the high end of the large enterprise market. Thus, Fortify was subject to the vagaries of large dollar enterprise sales cycles, meaning from what we heard Fortify's revenues were a tad lumpy and unpredictable, with sales down a bit over the last couple of quarters. Of course, being private we can't publicly substantiate this, but we believe it to be true. To be clear, this is not an indicator of product quality issues or lack of a viable market; variations in Fortify's numbers have more to do with their sales process than the market's perceived value for white box testing or product. Gary McGraw's timely post on the Software Security Market reinforces this, and is a fair indication that there is growing need for security testing software and services. Regardless of individual vendor numbers (which are less than precise), the market as a whole is trending upwards, but probably not at the rate we'd all like to see given the criticality of developing secure software.

The criticisms I most often hear about Fortify focus on their pricing and recommended development methodology; both introduce unneeded complexity from being completely geared towards large enterprises. From an analyst perspective my criticisms of Fortify have also been the skew to enterprise totally made their offerings a non-starter for mid-market companies, where a lot of web applications get developed and an even more pressing need to white box testing exists. The processes and methodologies Fortify recommends may appeal to enterprises, but the maturity model and development lifecycles just don't resonate outside the Fortune 500. The analysts that will not be named have placed Fortify's product offering far in the lead for both innovation and effectiveness, but from my experience Fortify faces stiffer competition than these analysts would have you believe. In fact, depending upon the market segment and what problem need to be solved, there are equally compelling products.

That said, those comments lose relevance now that the product is under the stewardship of HP. Over the past few years, HP has made significant investments to build a full suite of application security solutions and now has the ability to package the needed application scanning pieces along with the rest of the tools and product integration features that enterprise software clients demand. Fortify's static analysis, assessment and processes are far more compelling when coupled with HP's black box testing and back office testing, problem tracking ad application delivery (Mercury). Oh, and HP's sales force is in a much better position to close the large enterprises where Fortify's product excels. And yes, that means Fortify is a really good fit for HP, and further solidifies its secure code strategy.

So what does this mean to existing Fortify customers? In the short term I don't think there will many changes to the product. The "Hybrid 2.0" vision that was spelled out in February 2010 is a good indicator that for the first couple of quarters the security product suites will merge without significant changes to functionality. Where the changes will come are the steps necessary to compete with IBM and the recent acquisition of Ounce labs; meaning there will be tighter integration with both problem tracking systems and some features tuned for IBM development platforms. It means that the pricing model will be cleaned up and aggressive discounts will be provided. And it means some short term instability with service as invariably there are disruptions to staff, training and new division of responsibilities.

But both IBM and HP will remain focused on large enterprise clients, which is good for those customers who demand a fully integrated, process driven software testing suite. It's natural to mesh the security testing features into existing QA and development tools, with IBM and HP uniquely positioned to take advantage of their existing platforms. Their push to dominate the high end of the market leaves huge opportunities for the entire mid market, who have been prolific in their adoption of web application technologies. The good news is there is plenty of room for Veracode, Coverity, Klocwork and Parasoft to gear their products to these customers and increase sales. The bad news is that these vendors will need to add dynamic testing to current static testing capabilities if they don't already have the capability, continue to innovate their way out of HP and IBM's shadow, and address platform support and ease of use issues that remain hurdles for the mid market. You are just not going to get very far if your software requires significant investment in professional services to be effective.

As far as acquisition price goes, the rumor mill had the purchase price anywhere from $200 million on the low end, to $270 MM on the high end. With estimated Fortify revenus in the $35-$50M range, that's a pretty healthy multiple, especially in a buyer's market. Despite the volatility of Fortify's revenues, an established presence in enterprise sales makes a strong case that a higher multiple is warranted. Moreover, the sales teams were already heavily collaborating, which likely helped make a better case as to why HP couldn't afford to lose this deal to someone else.