Once an Architecture is done, it’s time to review it to make sure it covers all aspects of the Threats and Risks that the Application needs to deal with. But how thoroughly the Architecture gets reviewed is based on the person that is doing the reviewing. How well I review the Architecture is different from how well a novice would review the Architecture. And that’s where Checklists come in.
Now I don’t want to give the impression that Checklists are the end-all and be-all when it comes to Architecture reviews. A lot of Security activities is simply a case of continuous improvement since there are always new techniques being found in the wild for attacking applications. But by updating Checklists that are used for reviewing Applications, you are able to raise the baseline checking that is done on the Architecture.
So, what checklists should you use? Well, the first thing to remember is that the entire SDL that you are following is driven by the initial Impact Assessment done in the Business Requirements stage. That means that you need to understand the level of security associated with the Application that is being reviewed. If it’s considered a low priority application, then the level of scrutiny that you put into the Architecture review doesn’t have to be as stringent as a mission critical application. The first step is to understand the level of security that the SDL process needs.
Next, remember that you don’t want to look at just the one phase of the Software Engineering process (Architecture design in this case) but, rather, take into consideration everything that has been done to date within the SDL. I’ve already mentioned the Impact Assessment done during the Business Requirements phase of the SDL. So what comes next? That’s right, what we’ve been talking about during the last two blogs: the Threat Model.
What came out of the Threat Model are the Threats and Risks that are associated with the Application and which the Architect needs to make sure are taken into consideration in the design. The Threat Model is where you get your first set of checks. If the Architecture doesn’t mitigate the actual Threats and Risks that were determined in the Threat Model, why even put together a Threat Model in the first place? The Threat Model creates the checklist that is specific to the Application under review and details the Business drivers that are the reason why we do the SDL in the first place.
Now, you’re probably saying “But what about some simple checklist that I can give everyone involved so that we can speed up the process?” Be careful! Just because some process is easy doesn’t make it the correct way in doing things. But say you never did a Threat Model and now you want to review an Application design. What checklist would you use?
Assuming you haven’t created a standardized checklist for your organization, there are a number of sources that you can go to in order to find recommended checklists. Some of them are:
- Eindhoven University of Technology = http://wwwis.win.tue.nl/2M390/rev_des.html (Note: This is probably the best Architecture Review checklist I’ve seen – most are focused on Code Review)
- Open Group = http://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/clists/sec.htm
- Microsoft’s Architecture and Design Review = http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/CL_ArchDes.asp?_r=1
- INTERPOL = http://www.interpol.int/Public/TechnologyCrime/CrimePrev/companyChecklist.asp (Note: This checklist includes organizational checks as well as Architecture)
Remember that you need to have a Process in place for the use of the Checklists. The process is what the Architecture Review is about. The Checklists only facilitate the Review, they don’t replace them. Plus, remember that you need to review the Architecture with an open imagination AFTER you use your Threat Model checklist and your Standard Checklist. There is always the chance that there is something missing from your checklists. But, by dealing with these areas, you should be able to make sure your Architecture is secure.