AppSec at RSA Conference USA 2012

Last month I attended my first RSA Conference (USA 2012) as a participant — a real, full-time badge holder with access to all sessions and peer to peer gatherings. I had previously attended RSA with an Expo pass, which was an exercise in frustration… but this year, being able to attend sessions, the experience was much different.

From what I have seen, RSA is primarily a big money-making opportunity for companies, many whom employ subtle (or not-so-subtle) scare tactics to get other companies to spend money on IT infrastructure that will make their networks more secure. There is likely more to it than that, but I am not an InfoSec guy — I’m an AppSec guy, and that is a nut that the Expo folks have yet to — and may never — crack.

Application Security (AppSec) feels like the new kid on the block, potentially a growth field but also difficult to sell to. On the Expo floor I counted a scant 3 vendors — 3 out of hundreds — who had anything to do with AppSec, and for the most part that meant offering a static code analysis tool that focused on security. Some vendors offered developer education programs, but I could not name 10 vendors I talked to that I could offer me anything relevant to the problems I am interested in solving.

There is more to RSA than the Expo, however. The sessions pertaining to AppSec were very useful

Pros and Cons of Using the Google Web Toolkit

We have had a good rollout of an internal UI framework built using the Google Web Toolkit, and it is a good fit for us — but is it a good fit for everyone?

Ganeshsji Marwaha at the Ganesh blog posted “GWT – Pros and Cons” several months ago, a list which is has gotten some attention lately in the twitterverse and which rang true to me as I read it over.

With 22 Pros and 12 Cons, this list is a good place to start if you are considering using the GWT for one of your projects.

Among the reasons we use GWT:

“2. Even if you are not experienced in Java GUI development, the experience in working on server-side Java for years will come in handy while developing GWT apps”

We are a Java shop, and developing with Java from end-to-end is a huge productivity benefit.

“5. You can migrate from a typical web application to a GWT application iteratively. It is not an all or nothing proposition…”

We have a huge set of products which are built using other approaches, but we have been able to create new products using GWT while incrementally improving existing products with features developed for our new UI framework using GWT.

“14. You have the advantage of being able to use standard Java static code analyzers like FindBugs, CheckStyle, Detangler, PMD etc to monitor code and design quality. This is very important when you are working in a big team with varying experience.”

Static code analysis is a huge boon to quality in large organizations, and being able to run these tools on our UI code has been a big help. Certainly there is an effort needed to custom-tailor rules for GWT (for instance, to enforce specific use of GWT-RPC), but you can use the off-the-shelf rules to check the other Java UI code immediately.

These were large factors when we were deciding to use GWT instead of other toolkits.

Security Training: You Are Not A Special Snowflake

The trend in software security training is towards common, standardized training for developers, according to the software security firm Cigital.  This is contrast to the earlier days of security training which tended to be tailored for specific technology stacks and toolsets.

Per a recent Cigital blog post:

We’ve seen some significant changes in the Training part of the software security market. First, most firms have come to realize they are not a special snowflake when it comes to writing secure code. For years, the vast majority of firms felt that software security training had to be an exact, customized match for their skill levels, their technology stacks, their SDLC, their coding standards, and even their IDEs. It took a while for many firms to understand that the origin of their XSS and CSRF bugs, for example, was probably not their choice of IDE or SDLC, it was rather tied up in how their code was being attacked based on its design and implementation.

XSS issues are XSS issues, regardless of the nature of your application.  This is one reason projects like OWASP can provide standard cheat sheets and guidance regarding different vulnerabilities; ultimately, at the end of the day those of us writing web applications speak HTML and Javascript, and any attack which leverages those languages will affect us all.

Links:

• Software [In]Security: Software Security Training – trends in secure software training and the source of the above quote

The Art of Being Lazy

One of the things I have found I consistently do on the job, regardless of the nature of the work, is attempt to automate the repetitive manual tasks which are common in many environments.

Back in college, when I had a data entry temp job to pay the bills, one of my daily tasks was to take two computer-generated lists and cross off entries that the two lists had in common. This being the green-screen terminal days, opportunities for automation were scarce, but a recently installed Apple Macintosh with green-screen emulation software gave me my first venue for removing the mind-numbing task from my daily to-do list.

At the time I did not know I would make a habit out of being lazy* in this way, but here at GT Nexus I find myself extolling the virtues of Larry Wall-style laziness to whomever will listen.

Continuous integration systems are only tenuously related to my duties as a Software Architect, but they help us all be lazy (which leads to better productivity) and we have been improving our systems consistently over the past year. Static code checkers have been part of our build cycle for years, and we constantly try to improve and tune them to automate our bug detection before our code reaches our testers.  If we need to change a collection of files, scripting — I tend to use Groovy, but there are many options available — is the only way to make it happen. All these efforts pay big dividends over time.

Every day we are doing more to automate our work, whether it is in regard to testing, code review, or development. If I can find a way to automate good design, I will evangelize that as well.

What are your favorite automation tools? Do you do whatever you can to be as lazy as possible?

 

 

* “We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris.” – LarryWall.  Find more here.

Congratulations to ZeroTurnaround for JRebel Award Win

JRebel is a tool which has saved us uncountable* hours of development time by allowing us to skip the step where we restart our Weblogic servers to test a new feature as we develop it.

The word about JRebel has apparently gotten out, because the developer behind it, ZeroTurnaround, has recently won the 2011 innovation award from JAX awards.

As an early adoptor and frequent user of their flagship product, I am happy to see them take the award home. If you have not had a chance to integrate JRebel into your server-side Java development process, I recommend you try it out.

Links:

Award posting: 
http://www.zeroturnaround.com/blog/jrebel-the-most-innovative-java-technology-of-2011/

 

 

* They are counted on a per-developer basis, but I do not have the totals for our entire company.

Reflecting on GWT’s Growing Pains

In a blog post reflecting on his time at Google, Dhanji R. Prasanna mentioned in passing that some internal Google projects, including the Google Web Toolkit, were maintained by engineers having no connection to the folks who used them to build shipping products.

Specifically:

“And new projects like GWT, Closure and MegaStore are sluggish, overengineered Leviathans compared to fast, elegant tools like jQuery and mongoDB. Designed by engineers in a vacuum, rather than by developers who have need of tools.”

While I do not work for Google and cannot comment on the actual goings-on inside those teams, from what I see from the outside Dhanji was right on the money for the Google Web Toolkit.

I say “was”, because I believe that the Google Web Toolkit team was focused on delivering more theoretical, and less practical, extensions to the toolkit before Google Wave launched. The Google Wave team wrote their wave client using GWT, and in the process I believe they pushed the GWT team past their comfort zone.  When Google IO 2009 – the venue for the launch of Google Wave – arrived, the GWT team announced GWT v2.0, a huge improvement over previous GWT releases.

Google IO 2011: All About Android (and Chrome)

This year’s Google IO conference in San Francisco was pretty amazing: there were some great announcements, like Android@Home, the Ice Cream Sandwich release of Android, Chromebooks, and more. In some ways the number of announcements (many more come to mind, like the Google Music service) was overwhelming.

On the GWT front, however, things were a little more sparse. Only 4 presentations were what I would call “pure GWT”, although some other sessions, such as “Chrome Developer Tools,” were quite useful as well.

There were no Ray Ryan “Best Practices for Architecting GWT Modules” moments, but that may have more to do with GWT maturing as a platform than any lack of innovation on the part of the GWT team. One team member, I forget who, alluded to this when they explained that in the past the team was driving hard to get the basic Java to Javascript compilation working properly for all platforms; now they are working to implement neat new features from the HTML 5 spec (insofar as they are nailed down) and improving the framework.

My impression is that GWT is undergoing a transition similar to what happened to Java when it went from v1.2 to v1.3.  Version 1.2 (or just “Java 2″) saw a huge improvement in the capabilities and basic language structure of Java, whereas v1.3 added features around the corners and continued the maturation of the platform.  (I must confess that I cannot remember any specific improvements with 1.3, although I must have been excited about them at the time.)

It was reassuring to know that the GWT team is growing, and Google continues to have confidence in it. One related announcement at the conference was that the browser-based version of Angry Birds was written using GWT. No doubt that will be the highest-profile use of GWT anywhere!

In the coming days I will post some specific reflections and notes from the conference, so stay tuned.