APR: Security – Added Constraint

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.