Tuesday, October 23, 2012
Should Business Analysts capture more than functional requirements?
To the question of whether a business analyst should solely capture functional requirements, I scream emphatically NO! It is important to understand that if we want to build secure software, we information security professionals need to encourage business analysts to think beyond functional requirements and start focusing on proper methods in capturing security requirements as well.
Let's face it, if we know that the quality assurance process starts with analysis of business requirements in order to generate test cases, then why aren't we helping business analysts capture them?
As a participant in the Open Web Application Security Project (OWASP) and chapter leader in the Hartford CT area, I have been savage in helping more than just architects and developers understand the value proposition in making security visible. Awhile back, I held a meeting with the ISACA community in order to provide insights into better ways to audit web applications.
On Wednesday, October 24th 2012, I will be speaking at the Hartford Chapter of the International Institute of Business Analyts on capturing security requirements. It is my plan to talk about requirements around identity, provisioning, authorization and entitlements and of course privacy. I plan on talking about this in context of use-cases and threat modeling such that they can connect the concepts to something they are familiar with. I will conclude with an overview of the OWASP Risk Rating methodology such that the business analyst community can aid in properly priortizing security requirements relative to others.
I sometimes think I am alone in the wildnerness with my thoughts. I am hoping that a few bright people in the OWASP community will see the value proposition of bringing our sage wisdom to other communities and do their part in making security visible to all participants in the IT ecosystem...
| | View blog reactionsLet's face it, if we know that the quality assurance process starts with analysis of business requirements in order to generate test cases, then why aren't we helping business analysts capture them?
As a participant in the Open Web Application Security Project (OWASP) and chapter leader in the Hartford CT area, I have been savage in helping more than just architects and developers understand the value proposition in making security visible. Awhile back, I held a meeting with the ISACA community in order to provide insights into better ways to audit web applications.
On Wednesday, October 24th 2012, I will be speaking at the Hartford Chapter of the International Institute of Business Analyts on capturing security requirements. It is my plan to talk about requirements around identity, provisioning, authorization and entitlements and of course privacy. I plan on talking about this in context of use-cases and threat modeling such that they can connect the concepts to something they are familiar with. I will conclude with an overview of the OWASP Risk Rating methodology such that the business analyst community can aid in properly priortizing security requirements relative to others.
I sometimes think I am alone in the wildnerness with my thoughts. I am hoping that a few bright people in the OWASP community will see the value proposition of bringing our sage wisdom to other communities and do their part in making security visible to all participants in the IT ecosystem...
