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 […]