Sep

24

Recently decided to take a secure Java coding course from SANS, partially because it’s good to brush up on the latest attacks, countermeasures and practices, but to be honest, mostly to log some CPEs for my CISSP certification. The course is part of the SANS Application Security (AppSec) curriculum. Here’s an overview of the course, and my review of it’s content.

The course is 4 days, and is taught in three different ways: live, via vLive (virtual classroom) and On Demand. I chose the On Demand option, which included the course books, a VMWare image with Linux and the software pre-loaded for the labs, and time-limited access (90 days) to the SANS training portal, where I could view pre-recorded sessions and take the quizzes. I ended up taking the course over the span of about 5 weeks, due to other commitments interrupting my progress. The focus of each day is as follows:

The quality and applicability of the content varies between excellent and “perhaps less relevant to the average developer”.

Day 1 covers lots of good material that a web developer should know:

Day 2 focuses on authentication and session management. This includes

Day 2’s relevance to modern application development, which is largely web-centric, is somewhat more mixed in my opinion. I’ve worked with web-based application development for nearly 20 years, and have never actually seen client-side certificates used. With the proliferation of lightweight IoC containers like Spring, it might be more useful to cover Spring Security rather than out-of-the-box JEE authorization. On the other hand, the material on session hijacking, fixation, and clickjacking were very relevant to the typcial web-based application developer.

Day 3 covers Java platform and API security, reviewing

In Day 3, the numeric data issues and precision topic seems out of place for a security course. Developers in the financial space, or those that require arbitrary precision arithmetic are used to the idea the can’t use Java’s primitive types or their wrappers if they want exact answers. The relevance of these to secure development is also tenuous.

Jar signing and the Java Security Manager is another topic that is relevant to security work, but in practice I have seldom seen this deployed in practice: theoretically interesting, but perhaps time would be better spent on another topic instead. The other content I found quite good.

Day 4 is given over to the Secure Software Development Lifecycle, Security Code Reviews and the Secure Development Challenge.

The SDLC content is light, consisting of only a few pages, mostly with links to various styles of secure coding SDLC. The Security Code Reviews section covers various types of automated tools that can be used to help identify defects. It also covers false positives, false negatives, and the consequent need for visual code inspection. The final part of the course is a lab exercise simulating a security code review and bug hunt.

In general, the course is more worthwhile than not. As noted above, some content’s relevance to the typical web-centric application developer is questionable, and some is tenuous. The lectures are generally good. The labs sometimes do not satisfy: in one example, the instructor does not provide an explanation of how to exploit a Javascript XSS vunerability, leaving the student wondering if they know exactly how the exploit works, and whether they have fixed it properly as a consequence.

The last word is that even as a security practitioner and developer with more than 26 years of experience, I learned some things I was doing wrong in my code, and how to fix them. That’s worth the cost of admission.


Comments

RSS feed | Trackback URI

Comments »

No comments yet.

Name (required)
E-mail (required - never shown publicly)
URI
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> in your comment.

Blogroll