In this post, we’re continuing our One on One with Visual Studio conversation from May 26 with Canadian Developer Security MVP Steve Syfuhs, The Basics of Securing Applications. If you’ve just joined us, the conversation builds on the previous post, so check that out (links below) and then join us back here. If you’ve already read the previous post, welcome!
Part 1: Development Security Basics
Part 2: Vulnerabilities
Part 4: Secure Architecture (This Post)
In this session of our conversation, The Basics of Securing Applications, Steve provides us with great architectural guidance. As usual, when it comes to architecture, there is a lot to cover, and as such, today’s discussion is a bit longer, but, on the other hand, the security of your application is a big deal and doing it architecturally correct is worth the up front investment.
Steve, back to you.
Absolutely!
Before you start to build an application you need to start with it’s design. Previously, I stated that bugs that are introduced at this stage of the process are the most expensive to fix throughout the lifetime of the project. It is this reason that we need to have a good foundation for security, otherwise it'll be expensive (not to mention a pain) to fix. Keep in mind this isn't an agile vs. the world discussion because no matter what at some point you still need to have a design of the application.
Before we can design an application, we need to know that there are two basic types of code/modules:
That which is security related; e.g. authentication, crypto, etc.
That which is not security related (but should still be secure nonetheless); e.g. CRUD operations.
They can be described as privileged or unprivileged.
Privileged
Whenever a piece of code is written that deals with things like authentication or cryptography, we have be very careful with it because it should be part of the secure foundation of the application. Privileged code is the authoritative core of the application. Careless design here will render your application highly vulnerable. Needless to say, we don't want that. We want a foundation we can trust. So, we have three options:
Don't write secure code, and be plagued with potential security vulnerabilities. Less cost, but you cover the risk.
Write secure code, test it, have it verified by an outside source. More cost, you still cover the risk.
Make someone else write the secure code. Range of cost, but you don't cover the risk.
Read more: Canadian Solution Developer
Posts
0 comments:
Post a Comment