Archive for the Application Security Category

Application Security Industry: 2008 Report Card

Posted in Application Security with tags , on November 6, 2008 by Matthew Flick

I have had many discussions this year regarding the future of the application security industry and even more about its current state. It’s interesting how people of such varying backgrounds will have similarly varying views; this short article is designed to capture those views and hopefully drive some productive discussion as a result.

Where are we now? Should be a simple question, right? Let me summarize in three main categories:

Maturity – Purists aside, “Application Security” today means the security of web applications and related things, such as web services. Application Security started to grow up as older information security areas–like network security and vulnerability management–matured quite well. I am quite sure it seemed at the time a great idea to port the mature security ideas and technologies over to the application security world. However, as usual we have learned the hard way that the proverbial square peg does not fit into a round hole. Result? Application Security is in the early stages of being adopted into organization’s information security programs. **Golf Clap**

Technology – I remember from childhood riding long distances (>1000 miles) with my family of five in a compact car to visit the in-laws. Of the many shortcuts we tried using our trusted 10-year old map, I remember one that ended with a missing bridge over the Mississippi River. The recent development of app sec tools eerily reminds me of this trip: choosing the wrong path and driving insistently down that path until you end up with very wet socks. Luckily for my family the car brakes worked…unfortunately I don’t see anyone trying to even find the app sec technology brakes.
So who is driving us down the wrong path, and why is it the wrong path? The typical response would be the vendors, but I disagree. Runtime scanners, source code scanners, application layer firewalls–they all perform as designed (in most circumstances). The problem lies in how these tools are sold and used as a method to secure the vulnerable applications. To a slightly lesser degree is the nearly insurmountable problem of these security tools keeping pace with the fast growing arena of application technology and subsequent vulnerabilities. Both of these problems illustrate why organizations needs to focus more on the root cause of the vulnerabilities rather than on the detection and prevention of attack vectors. The unfortunate fact is that application security technologies can not—and may never be able to—keep pace with vulnerability and attack research. This is the wrong path. This is why we need to hit the brakes and find a better route.

Approach – Is that light? Are we in a tunnel? Yes and no. The application security world has witnessed several of its citizens make wonderful presentations on why we need to…**drumroll**…incorporate security into the SDLC! Or at least it was witnessed by the five of us not watching the more exciting and entertaining presentations on the latest and greatest XSS and CSRF attacks. Whereas this statement of incorporating security into the world of development is theoretically valid, when put into practice the wheels tend to fall off (or in worse cases, explode). After assessing so many different environments and working with clients to build practical and effective application security programs, I’ve all but killed the nerdy theorist inside of me. The old “one size fits all” adage really starts to become annoying!
I am not arguing the approach nor will I espouse a new theory of my own–remember I said it is valid. Instead I will just note that we are, as an industry, still at the theoretical stage. At least I can cross off “job security” from my list of worries.

Where are we going? If the first half of this post was not depressing enough for you, go back and read it again more thoroughly. Then read on. Here is a sampling of quotes I collected this past year on the question of where the application security industry will be in 3-5 years:

“More of the same. New technology maybe, same attacks against both the new and old technology.” –security consultant

“I don’t think much will change. With Flash and AJAX growing there will be new opportunities there, but not much else will be different.” –application security manager

“SaaS is the future of app sec. The tools are quickly getting smart enough to attack application business logic and will revolutionize the industry.” –vendor marketing guru (shocker)

“More companies will realize application security is something they have to deal with.” –security guy

Job security…oh right, I already crossed that off. Is this the best we can do? Inch our way further down the wrong path? Marginally better tools, more of the same attacks against current technology, and bigger budgets for the same insufficient solutions? I cannot be the only one thinking that this is a problem. Sadly, I have to somewhat agree with the comments above. In dealing with people from all sides of the aisle, it does appear that the application security community is settled comfortably with the status quo. With the massive increase in application security spending over the last few years, can anyone blame them? That being said, maybe I am the only one plotting and scheming of a better way…and maybe that’s not such a bad thing.

Development Double Agent

Posted in Application Security with tags , on November 4, 2008 by Matthew Flick

Of the many ideas floating around the application security industry lately, there is one often overlooked but very effective approach: spying. Too often security personnel will look at developers as improperly educated code jocks, akin to Hollywood’s portrayal of “hackers” in the 1990s. Similarly, developers see the security analyst as an idealistic zealot with no concept of how things are in the  “real world.” So the goal is to bridge the gap between the security and development groups. That bridge is a trusted developer that has a technical understanding of application security issues.

Who should be the bridge? There is no perfect answer to this question, so I’ll give some analysis of your options.

  1. Current Developer – By promoting–or at least elevating–a trusted senior developer to the position of “Security-Development Bridge”, an organization can expect near seamless transition from vulnerability detection to resolution (assuming the recommendations below are implemented properly). As a developer, the individual will understand the unique demands and expectations that the business pushes on its developers. With the appropriate training, the individual can also help to translate vulnerability findings into development remediation plans. With insider information, this double agent could also help the Security group better understand how the development group implements their recommendations. The related personal growth and resume enhancement is similarly a great opportunity for the developer in question. This should be considered your best option.
  2. Current Security Analyst – This would not be considered a bad option if an organization is building a new application security program or just getting their feet wet. The window of opportunity for the Security group to successfully plant someone inside Development group is small, but possible. Any pre-existing resentment or prior disagreements may end the initiative before it starts, regardless of whether the individual analyst was directly involved. Of course prior development experience is highly recommended, as is detailed training on the organization’s SDLC and related policies and procedures. Being a current employee of the organization will allow the individual to immediately focus on learning how to best fulfill the role rather than laboring through the on-boarding process.
  3. Experienced Outsider – If option 1 and 2 are not possible or preferred, an organization may have to look outside its doors to fill the role. All of the recommendations and rules of experience and group interaction described above apply here as well. Depending on the amount of ongoing development, the role is likely to be a full-time position, although providing hands-on assistance to developers may be possible and help to build trust.
  4. Outsourcing – Despite being in a position to benefit from a long-term staffing opportunity, I generally do not recommend outsourcing the double agent position. It may be more difficult to build trust amongst the developer ranks for a true outsider. Alternatively, a consultant could be in a particularly effective position to build a tunnel if a wall separates the Security and Development groups. Organizations and individuals alike are often more willing to trust an experienced and knowledgeable third party than their enemies across the cube wall.

How should we build this bridge? Similar to nearly all other security initiatives, there should be support from management. I doubt the upper echelon of most organizations will want or need to involve themselves in such minor details, but at least the heads of the Security and Development groups need to fully support the plan and its details. Some other suggestions:

  • The Security and Development groups must very clearly define the role and responsibilities of their new agent.
  • As indicated by the title of this article, the double agent should be organizationally placed in the Development group. This can help to build trust amongst the developers and improve the application security program where it typically struggles most: remediation.
  • Encourage or initiate teamwork. A friendly group lunch, happy hour, or other event could very easily improve the ROI of the double agent initiative. Yes–when in doubt, add food!
Follow

Get every new post delivered to your Inbox.