In many large companies and even small ones, the application development staff and the security staff do not generally work together on a project team. The developers see themselves as architects and creators of an application, making sure it does what the customer wants.  The security folks often see themselves as more of a compliance role, testing code after it is developed and making sure it is protected on the network. Security also has the reputation of telling folks what they “can’t” do rather than helping the developers make good security decisions.

Unfortunately this scenario is very true in many companies. Code could be developed in a more secure fashion if the developers and security staff worked as a team rather than as adversaries. When developing code, you end up with both bugs and design flaws. Bugs can be caught in testing using a variety of software tools. Flaws in the design and architecture of an application are harder to identify and are responsible for 50 % of security defects.

By encouraging the team to include security in the initial design of the product and putting security first, many design flaws can be avoided. Gary McGraw and Jim DelGrosso of Cigital, Inc. believe adding an architecture risk analysis process has proven to be useful in finding and fixing flaws. They recommend starting the process with an architectural diagram.  With the architecture diagram in hand, they undertake three specialized analysis steps:

1) Known-attack analysis – Take a list of known attacks relevant to your architecture and go through them. Microsoft’s STRIDE approach (part of what they mistakenly call threat modeling) is a good example. STRIDE is an acronym for spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. That’s the Microsoft list.

2) System-specific attack analysis – focuses on exposing invalid assumptions, ferreting out ambiguity and finding new attacks based on how the system works.

3) Dependency analysis – has to do with determining how wobbly the tower of other software you are counting on to work turns out to be. Most of today’s software relies on the proper behavior of components and frameworks that someone else designed and built. What were their assumptions, and how do they impact your system? What will happen to your design if the frameworks misbehave?

If we’re going to solve the software security problem, we need to encourage architects, developers and security staff to work together as a team and they need to focus more attention on flaws.