More on Holistic Security (and non-functional requirements)
See Brent's comments to my post on designing security into products towards the bottom.
As Brent says, "..making the security properties explicit, you can make sure they carry all the way to code." That's what's often missing, some up-front thought and explicit goals, which can have quite an influence on the code.
Like performance criteria, this is one of the mostly non-functional areas that deserve architectural consideration. The caveat is, like performance and other non-functional targets, you can rarely figure it all out ahead of time. But rather need to do some thinking early, develop and test theories, rinse and repeat. That's the only way you're going to get a clean implementation that meets the goals. It's also the only way you're going to get a deep enough understanding of the cost/benefit and opportunity costs involved to tease out the appropriate architectural decisions. For example, tying your product to some Public Key Infrastructure might sound great until you try it and figure out how complex it can become..
Then there's a quantitative issue of how much thinking you're going to do up front. BUFD methods would say all of it. Agility minded methods would say much less. I think there's a middle ground to be found for nearly all projects, lest you get painted into a corner.
Point is, this is an area you must set goals and be sure to keep them in the process throughout development.
As Brent says, "..making the security properties explicit, you can make sure they carry all the way to code." That's what's often missing, some up-front thought and explicit goals, which can have quite an influence on the code.
Like performance criteria, this is one of the mostly non-functional areas that deserve architectural consideration. The caveat is, like performance and other non-functional targets, you can rarely figure it all out ahead of time. But rather need to do some thinking early, develop and test theories, rinse and repeat. That's the only way you're going to get a clean implementation that meets the goals. It's also the only way you're going to get a deep enough understanding of the cost/benefit and opportunity costs involved to tease out the appropriate architectural decisions. For example, tying your product to some Public Key Infrastructure might sound great until you try it and figure out how complex it can become..
Then there's a quantitative issue of how much thinking you're going to do up front. BUFD methods would say all of it. Agility minded methods would say much less. I think there's a middle ground to be found for nearly all projects, lest you get painted into a corner.
Point is, this is an area you must set goals and be sure to keep them in the process throughout development.
posted by Steve at 9:57 AM
0 Comments:
Post a Comment
<< Home