Application & Cyber Security Blog

Colombia Emeralds and a Jewel of Denial

Last week I had the pleasure to attend and present at the Security Zone 2012 conference in Cali, Colombia. First of all, I have to say that the Colombian people I met were friendly, warm and gracious. Edgar Rojas and his team did a great job of putting on the conference and making us feel welcomed. My travel partner Bryon Indriago of Security Innovation, who manages Latin America for us and speaks Spanish, made getting around easy and fun. It was a great trip.

Wendy Nather of the 451 Group and I presented together at the conference with me filling in for our CEO Ed Adams. Wendy and I talked about several topics in application security ranging from secure SDLC and Agile, to WAFs, to metrics like time-to-fix a vulnerability, at the end asking ourselves if application security is actually getting better. We presented in a two-person panel format asking each other these questions. In planning for the presentation we discovered a mutual love of Star Trek, so we also looked at these topics by imagining the different perspectives that would be taken by Captains Kirk and Picard if they were responsible for application security. Kirk represented the more hands on, action oriented CISO while Picard acted as a proxy for a more planning and managing oriented strategic CISO. It was great fun, well received and I want to publically thank Wendy for being great to work with on this and doing such a great job in the presentation. She definitely carried us!

My time at the conference and the questions we received at the presentation definitely opened my eyes to the state of information security in Colombia. The meetings we had in Bogota prior to the conference time in Cali also helped. Colombian IT security people are as aware and advanced in their thinking as any I have met anywhere in the world. They are clearly taking IT security seriously. More specifically there are people there beginning to take Application Security seriously and making great strides which is as much as you can say about anywhere in the world. If you are interested in this and another perspective, also see Wendy’s conference wrap-up posted on the Security Zone site above.

The only bad thing that happened on the trip (well, aside from some flight delays) was the fact that when checking out of the hotel in Cali, American Express denied my charge. This made for a harrowing 20 minutes at 6am trying to make an 8am flight which was the only flight out to the US on my airline. Thank you very much to the Intercontinental for taking a card imprint and letting us go. They handled it well and made a happy customer. I have since made sure they were paid.

This denial was despite the fact that I dutifully called and informed AMEX of my trip, and that a hotel charge on the last day of the trip should not be suspicious. What should be an easy charge to clear ended up a false positive in the fraud monitoring system that will likely lose American Express a 30 year customer with a lot of charging left to do. Their customer support when I called to talk about this didn’t help either, and that used to be one of their strongest positives.

This whole incident happening on the heels of the presentation got me thinking about false positives and WAFs. Wendy pointed out in our presentation that a vast majority of WAFs are deployed in detect only mode, and this kind of false positive is exactly the reason. Denying service based on a false positive can be worse than the risk of a false negative or an unblocked attack. This is yet another rationale that when possible, the application needs to be secure in itself rather than using anomaly detection to guess at what might be an attack. The application can know what it expects and service legitimate requests while blocking things that fall outside of its parameters. WAFs do have their place as I discussed already, but a WAF or other filtering or proxying technology has to guess, and that can lead to bad things happening. Like losing customers because you have security (or fraud detection) driving business processes instead of the other way around.  

No WAFing Matter: Gartner's perplexing Analysis on Web Application Firewalls

In a recent TechTarget article, Gartner Analyst Ramon Krikken is cited talking about Web Application Firewalls (WAFs), Database Audit and Protection (DAP) and XML gateways as a lower cost ‘solution’ to the application security problem plaguing us today. He cites some nice work by WhiteHat Security on how bad the situation is, and basically says we should all give up on fixing software because it will take too long and cost too much. The claim that the solution is a WAF makes me want to cry. WAFs have their place, as we will discuss, but that is just a small part of the story.

While he is doing a service by raising the issue, he has a lot of work to do to understand the issues. To start with, he talks about the lack of research, and while we need more, there has been more than he is aware of and I will cite just some below.

Mr. Krikken’s approach mirrors the security immature organizations typical learning curve. This is something Security Innovation has discussed in our Application Security Maturity model from our research. Security often starts off with an overwhelming number of problems found by a scanner and generally an organization will throw its hands up or seek an alternative to dealing with the list. This is not unexpected. Imagine a magical bug finder scanning five years of untested development all at once and giving the software organization the results all at once. This is what happens with Static and Dynamic Security Analysis Tools (DAST, SAST) – years of development which ignored security being hit all at once. It should not be a surprise, but it often comes as one. Ultimately, as our Application Security Maturity model research shows, what happens is a curve somewhat similar in shape to something Gartner should know about – their Hype Cycle.

After finding a bunch of security problems, ignoring them or trying external solutions, eventually the organization creeps back up the maturity curve to use a combination of approaches to address the problems in ways that are now well known. We’ve been through this before at the system level. IT and Security used to not work well together on patching and system configuration, and security tried Firewalls, IDS and IPS to solve the security problem of servers getting owned by malware and hackers. Finally, IT and Security realized that they had to work together and we are in a vastly different place with patching and secure configuration maturity. This is why the bad guys have moved to the next porous layer – the application. Yes, the situation at the application is bad now as Mr. Krikken points out, but the answer is not to give up and try a band-aid that won’t work. We’ve been down that road.

The rapid proliferation of mobile apps is cited, and then WAFs and XML gateways are called for in the article. Of course, WAFs and XML gateways do not address many mobile application security issues to begin with, so this doesn’t make much sense. Of course he also calls for using the framework and platform security features, which is part of the building security in model which he is claiming will not work – again, a contradiction. Then he asks for a device which is ‘faster, cheaper, and ultimately just as effective’ like a WAF to avoid the ‘unending cycle of developing, testing, and implementing software patches.’ Wendy Nather of 451 Group did a great job on 'effective’ so I’ll jump in on the rest.

Research was done by Aberdeen and Forrester starting in 2010 on this topic which I discussed in a two part blog series on Application Security ROI (gotta get back to that) which shows that building security in is actually the most cost effective approach. This is not a surprise either, as it’s well known that the earlier in the development cycle a bug is found or prevented, the cheaper it is. Security issues to developers are often just a special class of bugs. Bad requirements multiply into bad designs which multiply into bad implementations. A process which addresses the problem as early as possible can fix one requirement or design problem early which could spawn a plethora of security findings in QA or a scan after deployment.

As pointed out by Aberdeen there are three classic approaches to application security vulnerabilities. Secure at the Source (also called Building Security In by Mr. Krikken), Find and Fix, and Protect in Play. Mr.Krikken conflates the first two into one, which results in many of his misunderstandings. When a company goes up the security maturity ladder and begins to build security in, they get off the cycle of testing and patching, because they avoid many more of the problems in the first place. There’s your faster and cheaper. No extra box on the wire, no coding WAF rules, less audit findings, less scanner findings – faster and cheaper all around.

The three approaches have their place. Protect in Play, like with a WAF is necessary for legacy or third party applications where no source is available and no patch is forthcoming. It is also good as a temporary solution to keep a critical app up while Find and Fix is happening. But in the long run, when a company can get there (and it will take time and practice), secure at the source is better with application security just like it’s better with system patching and configuration.

That would have been a good ending, but there are two other things in the article that need to be addressed. Oddly, the argument against WAFs is what it means for PCI compliance. PCI specifically calls out WAFs as one of the two approaches it allows. See PCI DSS item 6.6. So even in the knock on using WAFs in the article is wrong.

Secondly, and this is a myth that really needs busting, is the performance hit from building security in. First of all, no matter how bad it could be, compared to proxying everything through a WAF choke point (even if that were possible, again see Wendy’s post), doing things at the source is going to be vastly better from a performance point of view. In addition, unless you are talking about things like encryption (which is either necessary or not regardless of performance) building security in consists of good coding practices which only have a minor impact on performance. It’s like arguing against checking for error results from function calls because of the performance hit. Sure, it takes a few instructions, but for quality purposes, it is necessary and in reality doesn’t cost much.

Security Innovation has real world experience in this area and we offer lots of educational information on secure software development. When a company is ready, secure at the source (or building security in or secure SDLC) works. It takes an investment to get there, but companies like Security Innovation can help, and it’s proven that it saves time and money. Many leading organizations, large and small, waterfall and agile, lean and, well everybody is lean these days, have found that using a secure SDLC helps build software securely from the beginning, and decide where find and fix and protect in play fit, this making intelligent, cost saving, compliance creating, problem avoiding, mature application security decisions. And that’s no WAFing matter.

Doing Application Security Training Right – Part One

Since Security Innovation is a provider of application security training, we often get asked for advice on how to build an application security training program. Tom started this topic recently here, and I will go into a little more depth.

While I have been with Security Innovation, I have watched a number of programs and have seen how they were rolled out, so I would like to share some observations about different types of programs, what has succeeded, and what we can learn from them.

The first thing I would say is that like many endeavors, one should start with defining the goals. In training there is usually either a compliance goal or a more general security goal - but a more general goal is often the result of or is partially motivated by regulation, compliance or risk.
If the goal is simply compliance, start with the place compliance is defined – audit. Find out what are the requirements to be considered in compliance and use that as at least a minimum standard. In most cases passing an exam is required to show auditors that training was completed and absorbed, in other cases a training report will do. In some cases training that truly covers application security will be required; in others, one class that goes over the compliance requirements at a high level is all that is required. Regardless, unless compliance is used as an opportunity to reduce risk as well as just check a compliance box, many will seek the minimum, and the auditor is the place to find it.

However, if the goal is to reduce risk or improve security, then there are a number of things to consider. Here are some of them:

• Is the management of the trainees on board?
• Who is going to be trained, and what is the current familiarity with application security?
• What is the context in which the training is being rolled out?
• Where are the people who will be trained
• When can the training be done, and when is it needed?
• Who will get each level of training (there are several models that can be used)?
• How will I deliver training?
• How will I evaluate training?
• How will I enable the trainees to take what they’ve learned and apply it completely and correctly?

I will start with the first question. It is absolutely essential that management is on board. I have seen several examples of security trying to do the right thing by acquiring course ware and then marketing it internally assuming they can get technical people interested in what they are. While I have seen several examples, I have never seen it work. If a developer (or tester, architect, etc.) is going to go learn something, in general they will go after new technologies and in the application world that is new languages, frameworks, algorithms, systems, etc. It is not security (except for an unusual few). To get them to take security training, management has to be on board and include improved application security in their goals. To make a training program a success, it has to be done in partnership with the application development ecosystem in the company, under an umbrella of support from management.

We will take on the rest of these questions in future blog posts on this topic.

Application Security in the Cloud – Dealing with aaS holes

As we all know, when you run things in the "Cloud" it’s "as-a-Service". There’s Software as a Service (SaaS), which started the terminology, Infrastructure as a Service (IaaS), Platforms as a Service (PaaS), etc. Therefore, it would stand to reason that security holes in your cloud deployments would have to be called aaS holes. If you are in the process of moving applications to the cloud, or deploying a cloud infrastructure (and who isn’t?) you are going to have to deal with a lot of aaS holes. This blog is here to help.

First, let’s talk about the types of aaS holes you are going to have to deal with. I’ll start with Engineering aaS holes. These are the problems caused by the fact that software is written by people with little training in application security. This is not their fault. Computer Science and Engineering programs, as well as the professional education that follows, focus on building software to do things – they do not address how that software can be abused and how to defend it.

Then there are the Sales aaS holes. Sales aaS holes are those caused by cloud service vendor’s infrastructure that does not do what their specifications say with respect to security or change after you contract with them. While you may have an SLA, a sort of no aaS holes rule for the services provided, liability is often limited to what you paid for the service while the cost of a breech can be far more.

Then you have your Product Management and Marketing aaS holes. These are caused by requirements of your applications and infrastructure that work against good security practice. The user experience is a primary factor that must be addressed when designing and building applications, but this and many other things can be used as an excuse to avoid security requirements, which if done properly can actually save time and money.

Last but not least, everybody has to deal with Management aaS holes. There are those caused by the lack of good systems management and monitoring which mean your application gets deployed on the wrong virtual image, in the wrong place or without the right configuration. Then there are those caused by a lack of security priority, process and information at the management level, leading to groups not having security goals, or poor coordination and execution on those goals.

There’s no doubt about it - when your applications move to the cloud, there’s a whole new world of aaS holes to deal with, so how do you do that? There are a series of steps you can take from small initial steps that will help to an entirely new way of doing things that will increase security and make you more efficient.

When building and deploying applications, the ultimate goal is to use a secure SDLC which will actually save you time and money. This addresses the PM and Marketing aaS holes with building security requirements in to the process. It addresses Sales and Management aaS holes with Threat Models, Attack Surface Analysis, and Deployment stage specification and activities that prevent and defend against aaS holes. Finally, it addresses Engineering aaS holes with secure design, coding and test practices as well as education and reference material on these.

The simple steps to start on the path to the goal of a secure SDLC start with an SDLC gap analysis and some training to get all parts of the process educated on the goal, the need and an understanding what has to be done to get there. From there, Threat Modeling and Attack Surface Analyses are low cost activities that will help you understand what you face and where you are facing it, as well as set some more concrete goals and non-goals. Your SDLC gap analysis will map out the steps from there that make the most sense for your situation.

As you can see, moving applications into the cloud means dealing with aaS holes. Butt, with the right help from a company like Security Innovation, and a little patience and perseverance, dealing with aaS holes can be a lot less painful than you think.

Application Security ROI – The Two Towers

In my first entry on Application Security ROI, I promised to delve into three areas of Application Security ROI a little more deeply. In this entry, which will now have to be the second of a trilogy given the title and my propensity to eat six times a day and grow hair on my feet, I will talk about the first, and least intuitive of these – how Application Security can make development projects more predictable and efficient. This predictability, and especially efficiency, is where the return on investment comes from. Without a Secure SDLC, Security becomes a gate throwing up roadblocks that seem incomprehensible and random to project teams, usually at the worst possible time. This seems like a trip through Moria, and often results in a process of recriminations followed by negotiations, with the outcome to nobody’s liking. Since the teams are not in synch on the goals and approach to application security, unpredictability and inefficiency ensues as resources are wasted going back and forth.

On the other hand, if the Two Towers of the application development team and the Security group can work together in a Secure SDLC rather than fighting a war between good and evil (each side believing it’s good), this can be avoided. Working together in a Secure SDLC means taking actions all throughout a project's lifecycle to create and meet common goals. Security can participate in setting Security Requirements and Threat Modeling at the early stages of the process, work with the team on refining them as the project continues, and then act as a consultant or even perform some security validation during the testing phase. Finally, in deployment, Security will have set requirements of the infrastructure for secure deployment of the application without interfering with its functionality. How does this result in ROI? Several ways:

1. When each part of the team works from common Security Requirements (and explicit non-requirements), only those elements which are necessary need be built, tested and deployed, saving time and money vs. a broad generalized set of requirements.
2. A Threat Model provides detail on the dangers to the application which informs the design, development and testing efforts, resulting in specific, effective mitigations.
3. These items not only inform the development, but they clarify requirements for design as well as provide clear guidelines for what must be tested, and what need not be, saving time and money during both these efforts
4. Secure code is good code. Many of the requirements for securing code such as not trusting input, and careful memory, pointer, error and integer handling, result in avoiding both security vulnerabilities and functional bugs saving expensive fixing and retesting time during the QA cycle.

You don’t have to take my word for it. This was also found by Forrester in the study I referred to in the first entry in this series. See especially Figure 9, Table 5, and the discussion around them. By the way, this may look like waterfall, but the same can work in Agile processes as well.

Now that you know that applying Application Security processes can save time and money, how do you go about creating your own fellowship between Security and Development? Training will be required so everybody understands the process and principals. Security Innovation can also help with a gap analysis of your process and a detailed roadmap on the steps to take to get to where you need to go, throwing your old inefficiencies into Mount Doom, destroying them forever.

How Threat Modeling Saved My Life

There’s been a joke in the software industry that goes something like this:

If automotive technology had kept pace with Silicon Valley, motorists could buy a V-32 engine that goes 10,000 m.p.h. or a 30-pound car that gets 1,000 miles to the gallon — either one at a sticker price of less than $ 50. Detroit's response: "OK. But who would want a car that crashes twice a day?"

It became urban legend that an exchange like this actually happened between Bill Gates and an auto industry executive, either the head of GM or a Ford family member. Interestingly, the item “you’d have to press the start button to shut off the engine” has actually happened in some cars.

The joke makes the point about how different the focus of software engineering can be from the focus of building cars or bridges. In software it’s all about functionality and performance over reliability and security because the implications of an application failing are actually, in many cases, much less severe than those of a car crash or a bridge failure. Sadly, the functionality, performance or time to market often makes a fair business trade-off given customer expectations of software.

In a car, engineers invest more time and cost to address failure or abuse modes and model them so the car can be designed to protect occupants. That picture at the top of this post is my car. It was hit hard as I pulled out from a parallel parking space, and in all likelihood the side curtain airbag saved me from a nasty bang of my head to the left side window. It may be an exaggeration that it saved my life, but thinking how a collision from the side could make the driver’s head hit the side window caused engineers to come up with the mitigation of a side curtain airbag and that certainly made my day!

In application security, this process of thinking about attacks to the application and their mitigations is called Threat Modeling.

Threat modeling is one of the key SDL activities that drive many of the other downstream processes in a security conscious software development lifecycle. Thinking about how the application will and will not be attacked allows the designers, architects, developers and testers to address those cases while not wasting time and money on those that are not relevant.

So I can highly recommend two things: (1) A car with side curtain airbags and (2) An SDL for you software development process that includes threat modeling and education on it. Security Innovation can help you with the second, you car company should provide you the first.

Application Security "ROI" - Talking Business

Every so often in my career someone new to security comes along whose is from a different industry, or who is, well, new to all fields, and comes up with a great idea that goes something like this: People don’t buy anything unless they have to or it has an ROI. What if we showed the ROI for security instead of just the argument of how it makes them compliant or reduces risk? That will make justifying our product easy. Then, and I swear I’ve heard this several times in several companies, they say – you see security doesn’t just reduce risk, it enables blah, where blah is something like internet use or e-commerce, or, more recently adoption of cloud or mobile. Then, the soliloquy continues, we can justify the security ROI as the ROI of being able to do blah. And then they’ll smile, because they just showed us security geeks that they know business!

Well, let me make something perfectly clear. Security is a cost. It does not enable anything. Criminals impede the ‘blah’ from above making an appropriate level of security a condition of doing business. Banks don’t have safes to enable banking. If all people could be trusted, all the money would be in a nice, organized inexpensive closet – without a lock. That would enable banking. Security budgets should be the minimum to achieve the security posture required. More security would be nice, but if there’s money for that more sales, marketing, or product, is always nicer. We should do the security we need plus the things in security that reduce cost. Full stop.

So, then, how do we justify Application Security? It’s the two reasons we use justify all security – it’s required to be compliant and for a minimum acceptable level of risk, and it reduces cost. On the compliance and risk side, there is ample evidence that successful attacks are focused on the application these days, both commons ones and so-called Advanced Persistent Threats (APTs). Most prescriptive compliance requirements that cover applications call for best practice process, education, and the use of scanning tools, including PCI (see control 6), NIST 800-53 (see control SA-8 among others), SANS 20 Critical Controls (see control 7) and many others.

On the cost side it gets more interesting. Application Security practice including SDLC, developer training, and the use of coding standards can make projects more efficient, reduce vulnerability management costs and reduce compliance costs. In future blogs I will go into these topics individually to show the application risks and compliance requirements as well as the cost reductions. Some of this information can be found in two separate independent analyst reports done on the subject by Aberdeen and Forrester, and made available by Microsoft. These are a good place to start. They are:

• Aberdeen ‘Security and the Software Development Lifecycle: Secure at the Source’
• Forrester ‘State of Application Security’

These are the business arguments for spending (let’s not hide it with the word ‘investing’) peoples’ time, money and other resources on improving Application Security SDLC, knowledge and tool sets.

Putting Your Code in an MRI – You Still Need a Doctor

I recently had an MRI, and, being a security geek, it got me thinking about scanning and application security. They checked my brain out, and despite some people’s expectation, found one there. Luckily there was no big problem with the brain they found, but I am following up with a neurologist. My general practitioner has to have a specialist look at it, understand the real problem, and recommend the treatment. But, since it’s a specialist, I have to wait a while to get an appointment. I am sure it’s a familiar story to any of you who have dealt with the American medical system.

This can be instructive in helping to think about what actually needs to happen when rolling out static analysis tool. You cannot have an MRI system do anything useful without a series of specialists with education, training and experience to do several things. First, you have to know when to apply the technology, which in my case was my GP ordering the test based on my symptoms. Then you need to know how to actually run the MRI, which was a very nice Radiologist. Then someone has to review the results, and decide what has to be done about it, which in this case is the Neurologist. All of these are limited, expensive resources with specialized education, practical training, and experience in their field. In addition there is a process in place and each of these people exchange information with each other about me and perform their specific role in the process.

In too many cases, with code scanners, an organization will buy one without putting in place the education, training, process and expertise to use it. This is like buying an MRI, sticking your head in, and expecting to be able to figure out how to best use it and interpret the images. You need education and training on when and how to run the tool, and then the knowledge and training to deal with the results. You also need a process so that all the proper steps are followed and nothing falls between the cracks. Here are some tips I have learned from others in the industry:

1. Start with people and process, not the tool. An SDLC gap analysis is a good way to start. Make sure everyone agrees on the requirement and is committed to following through on their piece of implementing the changes needed.
2. Commit time and resources to education and training. These are not synonyms. Education is getting general knowledge awareness about application security, process, and how the tool will fit in. Training is specific knowledge that is applied to using the tool and then prioritizing and fixing what is found. Doctors go to school, and then do internships.
3. Take an iterative, problem solving approach. Security vulnerabilities in applications, like bugs, are going to happen. How they are handled and learned from will determine whether you reduce them in the future or get stuck on a treadmill with the same problems over and over.
4. The scanner is a tool, not an end. It is part of the overall process of producing an application. You cannot scan security in any more than you can test quality in. Application security depends on the knowledge and practices used by all parts of the application development process and how the inputs to the tool are produced, when and how the tool is run, and how the outputs from the tool used.

Run two scans and call me in the morning. Everything will be fine.

Secure and Agile – Can They Go Together?

Agile has become a religion among some in the development community, and that is not an issue that I will address here - I am not that brave. However, since Agile has become so prevalent, I do want to talk about a related issue, and that’s what happens to application security and SDL activities in an Agile environment. After all, SDL is modeled on the traditional software lifecycle activities and maps to a ‘waterfall’ process, so can we develop applications securely AND with an Agile process?

My answer, like any good technical person is the ever hedging ‘it depends.’ Agile process requires a unique type of team discipline and tends to hold a magnifying mirror to both the good and bad of a company’s approach. The things an organization does well can be done even better in Agile, and the things an organization is bad at can be exacerbated by Agile. For example, let’s take Product Management. If you were not good at understanding the customer for writing requirements, you will be no better at understanding the customer for writing user stories, and since user stories require a deeper role-based understanding, you will probably be worse.

Applying this to application security, if your approach to security is haphazard and the appropriate processes and education are not in place, you will absolutely get worse in Agile. User stories, backlogs, scrums and sprints have a way of sharpening focus on manageable top priority items at the expense of others, and if security is not a high enough priority, it will fall by the wayside. On the other hand, if you are threat modeling, attack surface minimizing and turning that into secure requirements, architecture and design, all of these activities can be mapped into the Agile process. If your developers are educated in defensive coding and you have input validation libraries and other good security systems in place, all these can be effectively used and are less likely to be forgotten in short, focused sprints.

Here are a couple of good places to start when thinking about Agile security:

1. At the high level, Adrian Lane of Securosis did this presentation on the topic that I like and sums up recommendations nicely.
2. At a more detailed level, Microsoft has published material mapping SDL activities to Agile processes in MSDN Magazine and in the MSDN Library. 

Finally, whether you are Agile or not, developer education and reference tools are essential. At some point, an engineer is actually sitting at a computer writing code, and that is one thing that that doesn’t change no matter how the process is managed.

Application Security Is Not A Tool, Developers Aren't Either – Notes From RSA '11

I spent last week at this year’s RSA Conference in San Francisco with a new look at it from a pure Application Security perspective, and specifically one of education for application developers. I left the conference with a sense of optimism about where we are headed.  Application security improvement is not about a tool (although tools must play their part); it’s about people, process, respect for the developer and a shared goal. I am glad to see this being talked about more and more and even happening in practice.

This is neither new, my idea, nor unknown, but it is still amazing how many stories there are of a scanner of some sort being rolled out with little else. Inevitably a big report of vulnerabilities is handed over to a development team without context but with the demand they be fixed. And inevitably, either nothing is done, or just enough is done to appease auditors and other compliance gods without any improvement in security.

Some examples from my experience at the show where this is changing:

• John Sapp gave a great talk entitled Innovation in Application Security. He explained how he approached the problem by building a process, including a model of a federated relationship with the business units that operates according to their needs under a framework that allows feedback about improvements steps and measured results to shared management.
• Two different meetings with large organizations, one a Security Innovation customer, one not, that built well thought-out training programs for developers to roll out static analysis. The training included secure application development as well as hands on applied use of the tool that was being rolled out. 
• Meetings with several vendors in the vulnerability management space that all saw the expressed need for developer education as it relates to their scanning offerings. 
• Meetings with several vendors in the security education and certification space all seeing the need to do more specifically for application developers.  
• This article, which Bill Brenner of CSO Magazine wrote about the Rugged Software Initiative get-together, a meeting which I did not attend.

This all adds up to good news. Many different people and organizations are coming to the same conclusion – that we in security need to work in partnership with those doing application development to facilitate their work. This will provide maximum security gain with minimum pain and produce measurable results. That like us, application developers care about what they do, have pride in their work, and do their job well. The poor state of application security is not due to laziness or stupidity, but rather a lack of security built into their process and goals, and a dearth of specific security education related to the job they have. This is what has to change, and I see across the industry signs that it is.