This is a guest post from Brian Mizelle, a managing principal at Cigital.

Today, Microsoft announced the launching of its SDL Pro Network. Cigital is proud to be part of this pilot offering, and pleased to continue to take the message (and the delivery) of software security to the market. As a network of independent software security professionals, the SDL Pro Network will collectively take our best of breed experiences and work collaboratively to develop unified service offerings around Microsoft’s SDL methodology.

At Cigital we are proud of our extensive experience running more than six large-scale enterprise software security initiatives spanning customers in financial services, independent software vendors, and embedded systems. We have trained several thousand developers, architects and executives on the fundamentals of software security. We have rolled out tools and best practices for many of our best customers. We have helped to grow the software security market from its infancy. Cigital is the largest and most experienced software security services provider in the world, and we look forward to continuing our market leadership through our partnership with Microsoft.

The number of firms delivering software security services is small and forms a tightly knit community, including companies of varying sizes, experience and areas of expertise. As a group, we have all read and embraced the three top software security methodologies, including CLASP from OWASP, the Touchpoints from our own CTO Dr. Gary McGraw, and of course, Microsoft’s SDL. Regardless of what flavor of methodology our customers subscribe to, we all share the common goal of educating and delivering services that protect our clients’ assets and good name through better software security. Collaborative efforts that bring together the best minds in the business can only help improve what we do with our own customers and broaden our thoughts on the subject.

Kudos to Microsoft for pulling the SDL Pro Network together. Our clients will all benefit from the experience…stay tuned to this space for more.

[This a guest post by Cigital's Troy Jones, written in reference to episode 25 of The Silver Bullet Security Podcast, an interview with Jon Swartz.]

Gary,

Listening to your podcast with Jon Swartz today, you briefly mentioned Ralph Nader a couple of times. You said almost in jest, that “… we need a Ralph Nader for Security.??? This got me thinking about a recent brownbag you gave on Software Security, where you mentioned that clients have implied needs for security but may not explicitly state their needs. I think the concept of implied need for software security and what Nader did to impact auto safety are entirely related.

Back in the 60’s people expected that the cars they bought were “safe???. Safety was not a marketing angle used by the car companies, and people did not shop around for the safest cars, but no one would buy an “unsafe??? car. They just trusted and expected that the big auto makers had already thought about safety and “built it in??? because no reputable car manufacturer would sell an “unsafe??? car, would they?

It was not until Ralph Nader wrote “Unsafe at any Speed??? that people began to question the safety of the cars they bought. When it became apparent that Detroit was selling them unsafe cars, the public outcry (not the book itself) prompted congress to act to enable novel new safety standards like seatbelts, bumpers that actually worked, and eventually crumple zones and air bags. So, people had an implied need for auto safety, but did not express that need until they became educated to the fact that they were not safe. Then they expressed their newfound need for safety to the politicians and also voted with their pocket books, buying safer cars. When consumers were provided with valid safety evaluations, from Consumer Reports and the National Highway Traffic Safety Commission, they changed their buying habits. Auto manufacturers (eventually) changed their approach in response. After years of fighting increasingly stringent safety regulations, they now compete to be able to advertise that their minivan has the highest safety rating.

So, what does all this have to do with software security? One point is that “safe??? is relative term. You are safe if you feel safe. It is hard or impossible to know if you are actually safe but it is easy to have your illusion of safety shattered by hard facts. Your average consumer today may be oblivious or vaguely concerned about software security, but they don’t have the information necessary to make discriminating choices about what software to use or buy and to stay away from. There is no Internet Highway Safety Commission and no ratings to refer to. Without this information, people are unable to express their implicit needs. They are driving metaphorical Corvairs and they don’t even know it.

Another point is that safety and security are both relative. The worst Yugoslavian POS manufactured today is probably much safer than any car rolling off the Detroit auto lines in 1965. It is conceivable that 50 years from now people will look back and wonder how we survived without collision avoiding auto-pilots in our cars! People’s expectations for “safety??? evolve over time and hopefully their actual safety improves as cars are better engineered, but there is no endpoint- no “safety finish line???. I think this analogy applies to “Software Security???. Software should get more secure over time if security is considered an important goal, but software will never be 100% secure. Good for job security but bad for everyone who depends on software to work securely.

A third point is that the initial reaction to unsafe autos was to build safer highways. Wide-open, straight, and fast highways seemed to be more cost effective than engineering better automobiles. It was not until highway traffic deaths began to skyrocket that everyone realized how effective automobiles are at killing the occupants involved in an accident at 75 MPH with no seat belts. The same approach has been taken on the internet. Bigger pipes and better firewalls should take care of the problem. No need to design and build more secure software! But the common folk will eventually realize that building a super information highway to their most confidential data has lots of unintended negative consequences, especially when it is so easy for the crooks to get past the vigilant but not-too-bright night watchman.

The last point I would make is that it took a fairly long time and a number of contributing factors for something to be done about auto safety. While Nader’s book was certainly a catalyst, it was not the “Auto Safety Pearl Harbor???. He merely recognized and assembled the information in a concise format that allowed people to understand and take action against a problem that had been growing worse for a long time. My guess is that the same will be true for software security. There will not be a “Software Security Pearl Harbor???. But through your continued evangelizing, through books like Jon Swartz’s “Zero Day Threat??? and by their own negative experiences, people will eventually realize that something has to change and will demand action from software vendors, perhaps increased regulation from Congress, and maybe even a rating system to identify the worst offenders and the most secure software available so that they can make better choices. I am convinced that attitudes will begin to change soon, as the current rate of increase in cyber-crime has us on a trajectory to reach 1% of total GDP with 4 years. If that happens, it will definitely get the attention of quite a few people and may drive the expression of latent needs for software security.

We’re pleased to have a guest blogger for this Justice League entry. Michael Cohen is a Senior Security Consultant at Cigital where he is responsible for leading, assessing, architecting and implementing secure software for Fortune 500 companies. Michael also works with Cigital teams on enterprise-wide security solutions intended to improve an organization’s security posture and help them meet audit and regulatory requirements. Michael just gave a talk to the Washington, DC IASA chapter that was well received, and is now the subject of this entry:

When I hear software architects talk about the architecture they’ve crafted to depict the various structures and behaviors of a system, they point out interesting techniques they’ve applied that best convey how the system should work and be put together. An architect’s enthusiasm for the little details reveals a great sense of accomplishment and creativity, but most of all good architecture conveys sorely needed information in order to help those who develop, test and maintain the system. Sharing the tips and tricks gathered from the field is what helps our community move forward to building better software. A classic example of this is the Design Patterns book written by the Gang of Four.

Not too long ago I was also sharing my ideas on architecture and security at a local IASA chapter here in Washington, DC. The group was a crowd of like-minded architects who work for large Fortune 500 companies, government agencies, and promising local startups. My topic was pragmatic secure architecture. The basic idea was to look at some real ways to incorporate security into architecture using Cigital’s risk management and threat modeling practices. You can find the slides for my presentation here.

For the uninitiated, threat modeling is a way of depicting where threats (think malicious people, attackers, and so on) can touch a software architecture and how they may be able to exploit critical assets using various attack patterns. Threat modeling is valuable for determining an architecture’s security posture. In addition, identifying risks in user requirements and business goals, and tying those risks to a threat model results in a map of how design flaws impact the system, its users and the overall business. Threat models coupled with identified high-level risks are a great way to get other stakeholders involved with security decisions. And mind you, these are stakeholders who would otherwise be unable to contribute and supply critical feedback.

The attendees at the chapter meeting were glad they attended the presentation and heard something worthwhile that they could use in their daily architectural activities. Many people brought up interesting points about how to best protect critical assets, what a real risk to a system is, and what is considered a good enough mitigation. What I found particularly interesting was how threat modeling provided a way for everyone to contribute interesting ideas about where security vulnerabilities may exist and how they could be mitigated (which, if you think about it, is the entire point of threat models).

I encourage any architect to share their ideas on building a better architecture with their peers, whether it be at a local organization or at a conference. As a senior security consultant at Cigital, I like to take shared ideas and mold them into my own unique way of thinking about the world. The best results come when I can apply new ideas to my daily activities as I help our customers assess and create more secure software.

… On an entirely separate note, McGraw still owes me money. I’m watching you, Gary.

Technorati Tags: software architecture, software quality, software security, touchpoints