APR: Security – Added Constraint

lock and chain

Last night I got some great feedback from the Austin on Rails guys who helped with the deployment technology for our project. I also got a bit of an education about website security. Based on that conversation, I’m adding a new constraint to our project – that it be secure.

Security Vision And Requirements

In line with our project scope and vision, and corporate goals, we are adding a security constraint for the product. We believe that having an un-hacked site is important to meeting these goals.

Further, I believe that users impicitly require that there be a level of confidence about the information that they find on the site – even with entirely user-generated content. Here’s a list of what I believe those expectations of trust might be – would love to know any others that people feel are important.

  • Users expect that their profile information can not be modified by other users.
  • Users expect that anything they create (an article, review, etc) should not be modifiable by others (at least without attribution and visibility into the changes).
  • Users expect that article “scores” are reflective of the individual scores. Further, I think users expect to have an understanding of how scores are computed, if not complete transparency (the score might not be a simple average).
  • Users expect that their private information be secure (e.g. encrypted password if present in database, application logs, etc)

Writing Security Requirements

Honestly, I’m not really certain how you would do this in a more significant site. Perhaps writing requirements around the terms of a service level agreement (SLA) or contract. We’ll talk about that more in a second. For this project, and certainly at this stage, I believe the requirement is “be prudent to the best of your knowledge about security.” That’s not a good requirement. But it is good enough for now.

How would you make a security requirement measurable and testable? Hackers just won a $10,000 prize for hacking into a macbook pro a couple weeks ago. We have no practical way to measure the effectiveness of a security requirement. “99% of all hacking attacks must fail” makes no sense – there’s a premise of a predefined amount of hacking activity.

Writing a security specification is the only thing we really can do – we can only intentionally prevent the types of exploits we know about. And for me right now, that’s not very much. And we can take a design approach / philosophy of deep security in building the product. But “Use design approach X” is not a requirement, it is a constraint.

Addressing Implicit Requirements

We can however, address the implicit requirements listed above. And we can address them with a series of specifications and design constraints:

  1. A user shall only be able to view their own private information.
  2. All content attributed to a user shall be created by that user.
  3. User passwords shall be encrypted whenever they are stored.

We can also address cross-site scripting (XSS), SQL-injection, and session-fixation attacks with the following:

  1. External content must be scrubbed for SQL injection attacks before using it in a database query.
  2. External content must be scrubbed for XSS attacks before displaying it to users.
  3. New sessions must be created whenever a user logs in.

These are the attacks that I know about and know how to prevent. If anyone knows of other attacks (and defenses) that we should incorporate, please let me know via email.

What About The Prototype?

I was able to get feedback on the initial prototype from the folks last night without exposing it to attack. I’ll be incorporating the above security measures before sharing the prototype with the public at large. I hope to get that done this week. Part of the challenge is designing tests that adequately validate the above.

  • Scott Sehlhorst

    Scott Sehlhorst is a product management and strategy consultant with over 30 years of experience in engineering, software development, and business. Scott founded Tyner Blain in 2005 to focus on helping companies, teams, and product managers build better products. Follow him on LinkedIn, and connect to see how Scott can help your organization.

5 thoughts on “APR: Security – Added Constraint

  1. 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.

  2. 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.

  3. 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.”

  4. 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?

  5. 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.

Leave a Reply to Nick Coster Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.