Q: How much development budget should be spent for security? A: 2%

Yesterday at the Software Quality Conference in Zurich, we gave a keynote about Measuring Security and discussed this very interesting topic from different points of view (attacker view, suit view, geek view, etc.). It was great to see that the Quality community has a very natural attitude to security and that many quality assurance concepts can be applied for measuring security aspects, too.

At the end of the talk, we were asked how much of the development budget should be spent for security. After a short pause for thinking, the answer was "2%". An interesting discussion followed. How many people have planned more, exactly or less (including 0) than 2%. Another category was a few people that simply did not know the security budget.

The beauty of defining such a budget for security lies in 2 (maybe more) things. First, you make people think whether they considered security in the development lifecycle at all. Second, you can gather some experience, see whether (in this case) 2% are enough and adjust the value according to your needs.

We'd be interested in your thoughts and your experiences regarding the big question "how much security is enough?".

SAP gets Hacker attention - Buffer Overflow Vulnerabilities

On July 6th, NGSSoftware released a set of security vulnerability advisories regarding several SAP enterprise software packages.

The same group stated earlier that it keeps 175 so-called 0-day vulnerabilities in enterprise applications of various vendors (Oracle, IBM, HP, Microsoft, Openbase, Real, Sybase, Ingres, Veritas, CA and Sun) under its pillow and they add more every week. Such 0-day vulnerabilities are flaws in software applications that are not yet fixed by the vendor, thus leaving the customers vulnerable to attacks until the vendor releases a patch.

Note that 0-day vulnerabilities are actively exploited by cybercriminals for one year until they become publicly known. This fact was found by Immunity, a company that buys newly found security vulnerabilities from their founders and sells fixes to Immunities customers.

There is even a fast growing market for security vulnerabilities. Recently we have seen a bidding platform, similar to Ebay, where people can sell and buy unreleased 0-day vulnerabilities for software applications.

Conclusion: it seems that complex business application frameworks as for example provided by IBM, Oracle, SAP and Software AG get more attention of security researchers as well as hackers. Professional attackers are out there that buy know-how about vulnerabilities. As business owner you should be prepared to take meaningful measures in advance.

Get in touch if you want to know more about how to protect your business applications.

How SAP adresses Cross Site Scripting

The Internet Crime Complaint Center has found that computer crimes caused a loss of almost 200 million US$ in 2006. Responsible vendors like SAP offer powerful technologies such as WebDynpro to protect your customized SAP installation against possible attacks. However, the key to success is that you as a SAP customer have to use SAP's security solutions and use them correctly. If you fail here, this might expose sensitive data of your SAP system to criminals that could severely harm your business.

The April-May-June issue of SAP Insider features an article of SAP's security expert Patrick Hildenbrand. Patrick gives a brief overview on some of the topics covered in our training, namely how to face the widespread Cross Site Scripting attacks (85% of all attacks against systems that use Web-based protocols are Cross Site Scripting attacks).

The Answer to the RFC (In)Security Hype: use SNC

Several people are analyzing SAP security. Particularly, Remote Function Calls (RFC) has been examined more extensively. In March 2007, a security analysis of the RFC implementation was presented at the Blackhat conference. It was labeled Attacking the Giants: Exploiting SAP Internals.

You could value this as another indication that SAP is getting more and more attention of security researchers and hackers. The analysis is extensive and shows several ways how RFC can be exploited (all security issues have been fixed by SAP before the paper was published).

So what? It has been known for years, that RFC isn't a security protocol. Actually, the authors also ackknowledge that in the accompanying paper; the most important sentence is that SAP customers should use Secure Network Communication (SNC), SAP's answer for securing RFC connections. This is analogous to HTTP which is usually protected by SSL.

There are many ways to get information about SAP Security and we strongly recommend to follow SAP's security recommendations. Learn more about SNC in the SAP NetWeaver Security Guide. General information about SAP Security can also be found in the SAP Developer Network (here) or in SAP's Security Forum.

Conclusion: the short answer to the RFC (In)Security hype is: use SNC!