Product Security Assessments (a.k.a. "ethical hacking")
By john.heimann on Sep 28, 2006
Hello. My name's Matt Moore and I run the Product Security Assessment Team here at Oracle; we strive to improve the security of Oracle's products in a variety of ways, mainly focusing on design and testing. I thought I'd make a quick blog post to introduce my team and explain what we do in some more detail.
We work with Product Development at pretty much every stage of the software development lifecycle, and we're usually working on many projects concurrently - we have a lot of products and developers!
Our first contact with a given team is usually at the design stage (although we often get involved in settings requirements even before this). We work with developers to review the designs for new components and features, allowing us to influence the security features and functionality of the product before even a single line of code is written. This is something my team really enjoys - we get to work with lots of really clever people and in the process we inevitably learn a whole load about cutting edge technologies. In the past year we've worked on everything from AJAX enabled web apps through to VOIP applications (I couldn't think of a product starting with a 'Z', but we probably have one somewhere...). This is also a great opportunity to work towards creating secure default configurations of our software for customers to use right out of the box.
Another core function of my team is actively working to break the security of new and existing products. We use a variety of techniques wherever appropriate - from code auditing through to manual testing. We're not just looking for implementation flaws like buffer overflows or sql injection bugs, but also for more subtle application logic errors. There are various outputs from these exercises in addition to simply finding and fixing security vulnerabilities. We work closely with the developers whose products we've broken to ensure that they understand the flaws and have found and fixed other, similar flaws in related areas of their products. Any lessons learned from these exercises are fed back into Oracle's Secure Coding Standards and used to improve our internal Developer Security training.
I also manage third party security assessments of our software. On occasion, where my team is too busy to assist a particular group we bring in trusted third parties to work with the teams directly.
We also work closely with Oracle's QA teams. We've found that in most cases they already have a whole raft of functional tests that with a few tweaks can be turned into security test suites. We've learnt a great deal about scaling our security testing from these QA teams, QA being a far more mature field of endeavor than security testing.
Developer Education is a key goal for our entire group, and guides the direction of everything else we do. Wherever possible, we try to analyze the root causes of a given problem, and work out what we can do to better ensure that all our developers have been given the right tools and training to avoid those types of problem in future.
Of course, all this is an ongoing process, and we're developing and refining our methodology on a constant basis. Hopefully, I'll be making regular blog posts in the near future with more detail about what we're doing and how we're doing it.