Patterns & Practices Security Focus
Hello and welcome to the UK patterns & practices security site. My name is Alex Mackman and I work for CM Group Ltd. I've been working with the patterns & practices team for the best part of 4 years, developing .NET security guidance. My objective for this site is to spotlight specific aspects of patterns & practices (p&p) security guidance and to provide additional insights about the guidance we have created. I'll be picking a different topic to discuss each month
.gif) | Alex MackmanHello and welcome to the UK patterns & practices security site. My name is Alex Mackman and I work for CM Group Ltd. I've been working with the patterns & practices team for the best part of 4 years, developing .NET security guidance. My objective for this site is to spotlight specific aspects of patterns & practices (p&p) security guidance and to provide additional insights about the guidance we have created. I'll be picking a different topic to discuss each month. |
Security Engineering
November 2005
In my initial post, I'm going to highlight the recently published p&p approach to security engineering. You can read more about it on MSDN. I'm also going to discuss "application security frames" which are incredibly useful when you start to perform security engineering activities. So why did I choose security engineering to discuss first? The bottom line is this - security is fundamentally about people and processes. I don't think that enough attention is paid to the fact that, without the right security engineering discipline embedded within your software development processes, you are going to have a really hard time building software that meets the security objectives of your business! This is true regardless of your technology and tool support.
What is security engineering?
Security engineering is all about integrating security into your lifecycle – into your methodologies and processes. Upfront security design, secure coding practices and testing for security must all be an integral part of your application development processes. Microsoft has demonstrated the incredible impact that adopting a process-based approach to security can have. Their own internal security push has reduced security defects across their software from between 50% to 60%. The p&p approach that we have created provides a set of actionable guidance and HowTos tailored for use by ISVs and organisations who develop their own line of business applications. So, if you care about security, you need to integrate security into your lifecycle. But how in practice do you do this? Let me start by emphasising a few really important points that underpin our approach:
Adopting security engineering doesn't require wholesale changes to your existing processes. We've designed our security engineering approach to specifically support incremental adoption. You can incorporate individual activities one at a time based on where you believe you will gain most benefit straight away. You can then phase in additional activities on subsequent projects. I should point out that identifying your security objectives should always be your number one priority. Then, the order of activity adoption will depend on the security objectives you have identified as well as any outstanding problems your process or application currently has.
We've not assumed that you have in-house security teams or access to dedicated security specialists. We have aimed the guidance squarely at developers and have provided actionable How To articles and walkthroughs to help you get started.
Many of the activities are iterative. It's important to realise that you should repeatedly perform specific activities throughout your lifecycle. A good example is threat modelling. To expect to be able to complete a useful threat model in one pass is unrealistic. Your threat model should be re-visited and enhanced throughout the lifecycle as you learn more about your design and implementation. You shouldn't get bogged down in documentation either! The threat model document is not what's most important. The list of threats and vulnerabilities that you need to care about is what matters most. Also, the team communication and additional understanding that you develop about your application are a real plus as this helps you make important engineering decisions about how you should design and/or implement your solution.
What are the activities?
So what are the security engineering activities that we advocate? I'll enumerate them here and you can read more about them on MSDN:
Identifying security objectives.
These represent your goals and constraints. They are usually things that affect the confidentiality, integrity and availability of your data and application. You might also have compliance requirements and regulations within your particular business sector to consider. Security objectives are key to allowing you to focus your security efforts in the right places.
Design guidelines for security.
To avoid many of the vulnerabilities introduced by poor design choices, your design activity should use proven design practices, patterns and principles.
- Threat Modelling.
Threat modelling helps you to understand and identify the threats and vulnerabilities relevant to your specific application scenario. Threat modelling brings structure to an otherwise unstructured approach to application security. Security architecture and design reviews for security.
The architecture and design review process analyses the architecture and design from a security perspective. It examines a number of aspects including deployment and infrastructure, overall application architecture and design, and each tier in the application. Security frames can really help you with this process. I'll talk about these a little more in a moment.
Security code reviews.
Security code reviews should be a continuous activity during the development and test phases of your application life cycle. You need to focus your security reviews and not be tempted to combine review types. For example I've seen many people attempting to identify security, performance and scalability issues all at the same time within a single code review. It's only by performing focussed code reviews that you'll gain the most benefit. We've created a HowTo to help you get started with security focussed code reviews and we've also provided some handy question lists to help.
Security testing.
Use a risk-based approach and use the output from the threat modelling activity to help establish the scope of your testing activities and define your test plans.
Security deployment reviews.
When your application is deployed, you need to be sure that weak or inappropriate configuration settings do not introduce security vulnerabilities. A good way to approach this problem is to walk through the security relevant configuration sections in your Web.config files.
What are application security frames?
So what about application security frames? We initially introduced security frames in the "Improving Web Application Security: Threats and Countermeasures" guide and have subsequently refined them in later guidance for different application types. A security frame is a pattern-based information model that defines a set of security-related categories specifically for the application type you are designing. These categories represent the areas where security mistakes are most often made. The great benefit of the security frames is that they define the areas where you need to focus your attention. For example, when you sit down to design a Web application, the areas you should care most about include input / data validation, authentication, authorisation, configuration management, sensitive data, cryptography, exception management, auditing and logging. These are the categories defined by the Web application security frame. We've used security frames to organise guidelines, to identify vulnerabilities that can arise if you make mistakes in each of these key areas and to organise common threats and attacks in relation to each category. They are also really useful to help you review the security of your application architecture and design. You can walk each category examining how your design addresses each area. This provides a repeatable, systematic approach and by analysing each category in the frame, you can be sure that you're analysing the key areas.
One final word about how we arrived at the final set of categories in the Web application security frame. They were initially defined with a lot of input from security experts who have examined and analysed the top security issues across many, many Web applications. They have subsequently been refined with input from Microsoft consultants, product support engineers, customers and Microsoft partners.
Conclusion
I'd encourage you to take a look at the security engineering site on MSDN and to start integrating security activities into your development lifecycle if you're not doing so already. Without the proper processes and without the right activities performed throughout your lifecycle, you'll find it very difficult to develop robust software solutions that meet the security objectives of your business. Remember that you can incrementally adopt security activities, the approach doesn't require wholesale changes to your existing processes and we've tailored the guidance around the activities, not for security experts, but for developers.
Until next time,
Alex
Additional Resources
For more information about patterns & practices security engineering activities, see:
.gif)