Comments on: APR: Security – Added Constraint http://tynerblain.com/blog/2007/05/09/apr-security/ Software product success. Sat, 11 Feb 2012 22:57:16 +0000 hourly 1 http://wordpress.org/?v=3.0.4 By: Nick Coster http://tynerblain.com/blog/2007/05/09/apr-security/comment-page-1/#comment-199725 Nick Coster Tue, 20 Nov 2007 19:42:02 +0000 http://tynerblain.com/blog/2007/05/09/apr-security/#comment-199725 As long as the "positive" form is not open to misinterpretation this is not a problem, however since we have an existing lexicon for logic statements (NOT, AND, OR) we should employ them. This is particularly important for security and safety related requirements and provides very clear pass or fail criteria. I have used a tongue in cheek <a rel="nofollow" href="http://www.brainmates.com.au/?p=187" rel="nofollow"> example</a> to discuss this a serious issue with children’s toy manufacture and the failure of product management to clearly specify a safety requirement. As long as the “positive” form is not open to misinterpretation this is not a problem, however since we have an existing lexicon for logic statements (NOT, AND, OR) we should employ them. This is particularly important for security and safety related requirements and provides very clear pass or fail criteria.

I have used a tongue in cheek example to discuss this a serious issue with children’s toy manufacture and the failure of product management to clearly specify a safety requirement.

]]> By: Scott Sehlhorst http://tynerblain.com/blog/2007/05/09/apr-security/comment-page-1/#comment-196804 Scott Sehlhorst Mon, 19 Nov 2007 17:33:54 +0000 http://tynerblain.com/blog/2007/05/09/apr-security/#comment-196804 Nick, thanks for the awesome idea! Maybe we should word them in the positive, tho - "The system shall prevent the user from viewing the passwords..." I'm torn between "actor verb noun" form and "positive requirements" form. We have to pick one. "The user shall be prevented from" is a passive verb form - another "not great" solution. Any word-smiths have a suggestion? Nick, thanks for the awesome idea!

Maybe we should word them in the positive, tho – “The system shall prevent the user from viewing the passwords…”

I’m torn between “actor verb noun” form and “positive requirements” form. We have to pick one. “The user shall be prevented from” is a passive verb form – another “not great” solution.

Any word-smiths have a suggestion?

]]> By: Nick Coster http://tynerblain.com/blog/2007/05/09/apr-security/comment-page-1/#comment-195800 Nick Coster Mon, 19 Nov 2007 06:34:40 +0000 http://tynerblain.com/blog/2007/05/09/apr-security/#comment-195800 Another way of doing this is to create a "hacker" Persona and create a series of activities that the hacker (or cracker if you are a purist) cannot do. For example, if the user scenario is that admin privileges have been stolen: "The user (bob the hacker) SHALL NOT be able to view the passwords of other users if admin privileges are achieved." Another way of doing this is to create a “hacker” Persona and create a series of activities that the hacker (or cracker if you are a purist) cannot do.
For example, if the user scenario is that admin privileges have been stolen:
“The user (bob the hacker) SHALL NOT be able to view the passwords of other users if admin privileges are achieved.”

]]> By: Scott Sehlhorst http://tynerblain.com/blog/2007/05/09/apr-security/comment-page-1/#comment-95431 Scott Sehlhorst Thu, 10 May 2007 03:03:37 +0000 http://tynerblain.com/blog/2007/05/09/apr-security/#comment-95431 I like the visual of hiring hackers to pound on the system. I still struggle to think of a measurement or criterion that would be valid. Thanks for the well thought out ideas, as always. I like the visual of hiring hackers to pound on the system. I still struggle to think of a measurement or criterion that would be valid.

Thanks for the well thought out ideas, as always.

]]> By: Roger L. Cauvin http://tynerblain.com/blog/2007/05/09/apr-security/comment-page-1/#comment-95333 Roger L. Cauvin Wed, 09 May 2007 20:57:58 +0000 http://tynerblain.com/blog/2007/05/09/apr-security/#comment-95333 I like the distinctions you've drawn here among requirements, specifications, and design contraints. It's definitely not an easy task, but I wouldn't give up on specifying measurable security requirements. For example, take one of the statements: "Users expect that their profile information can not be modified by other users." What is the problem that users want to avoid? I don't have the answer, but interviewing (and digging deep with) a few prospective users might make the problem/goal more apparent and explicit. If the problem is as direct as unauthorized modification of profile information, then I suspect the requirement would consistent of profiling the types of people who might access the system and placing a limit on the probability (number of security compromises per unit time given a certain number of people with certain profiles maliciously attempting to access the system) that they could modify another user's profile information. In theory, you could test that the system meets these requirements by hiring people with those profiles to maliciously pound on the system. I like the distinctions you’ve drawn here among requirements, specifications, and design contraints.

It’s definitely not an easy task, but I wouldn’t give up on specifying measurable security requirements. For example, take one of the statements:

“Users expect that their profile information can not be modified by other users.”

What is the problem that users want to avoid? I don’t have the answer, but interviewing (and digging deep with) a few prospective users might make the problem/goal more apparent and explicit.

If the problem is as direct as unauthorized modification of profile information, then I suspect the requirement would consistent of profiling the types of people who might access the system and placing a limit on the probability (number of security compromises per unit time given a certain number of people with certain profiles maliciously attempting to access the system) that they could modify another user’s profile information. In theory, you could test that the system meets these requirements by hiring people with those profiles to maliciously pound on the system.

]]>