Add Brainstorming and Setup activity

README.md

@@ -1,21 +1,20 @@
-# Security Project Description
+# Service Security Project Description
 
-## Project overview
-We will go through the process of developing a secure application that:
-- securely stores sensitive user data
-- authorizes actions by credentialed users
-- securely shares resources between users
-- provides ethical terms and conditions of use
+We will be creating an interesting and technically sound design of a security application.
+Follow the activities below as the semester progresses.
+
+*Please note that activities are subject to change!*
 
 ## Weekly breakdown of the semester project:
-- [A: Basic File Store API](descriptions/010_filestore_api.md)
-- [B: Relational Databases and API Testing](descriptions/020_db_testing.md)
-- [C: Database Hardening: DB Vulnerabilities and Encryption](descriptions/030_db_hardening.md)
-- [D: Secure User Accounts: Passwords and Associations](descriptions/040_secure_accounts.md)
-- [E: Deployed API + Interface Client](descriptions/050_interface_client.md)
-- [F: Token Based Authentication](descriptions/060_token_authentication.md)
-- [G: Form Validation and SSL Enforcement](descriptions/070_validation_ssl.md)
-- [H: Token Based Authorization](descriptions/080_token_authorization.md)
-- [I: OAuth Protocol and Single-Table Inheritance](descriptions/090_oauth_protocol.md)
-- [J: Signed Apps and XSS Prevention](descriptions/100_distributed_security.md)
-- [K: Final Presentations](descriptions/110_final_presentation.md)
+- [A: Brainstorming and Setup](descriptions/005_brainstorm_setup.md)
+- [B: Basic File Store API](descriptions/010_filestore_api.md)
+- [C: Relational Databases and API Testing](descriptions/020_db_testing.md)
+- [D: Database Hardening: DB Vulnerabilities and Encryption](descriptions/030_db_hardening.md)
+- [E: Secure User Accounts: Passwords and Associations](descriptions/040_secure_accounts.md)
+- [F: Deployed API + Interface Client](descriptions/050_interface_client.md)
+- [G: Token Based Authentication](descriptions/060_token_authentication.md)
+- [H: Form Validation and SSL Enforcement](descriptions/070_validation_ssl.md)
+- [I: Token Based Authorization](descriptions/080_token_authorization.md)
+- [J: OAuth Protocol and Single-Table Inheritance](descriptions/090_oauth_protocol.md)
+- [K: Signed Apps and XSS Prevention](descriptions/100_distributed_security.md)
+- [L: Final Presentations](descriptions/110_final_presentation.md)

descriptions/005_brainstorm_setup.md

@@ -0,0 +1,49 @@
+## Brainstorming and Team setup
+
+### Setup
+
+Please organize the following resources for your team.
+
+Team Google Spreadsheet
+- see class website for access to Google spreadsheet of all teams
+- add required information for your team
+
+Github Organization
+- create a Github organization for your team
+- add all teammates to organization
+- all repos for this project must be owned by your Github organization
+
+### Brainstorm
+
+Brainstorm ideas for your project with your group. Please add your ideas to our shared Google Spreadsheet for teams.
+
+#### Theme
+The *topic* of your service should generally follow these ideas:
+- security is its *primary* feature (e.g., secure storage/transfer/communication/etc.)
+- should solve some real security problem, or makes a security issue easier to deal with
+
+#### Functionality
+The *functionality* of your service should include the following:
+- authenticates credentialed users
+- securely stores sensitive user data in a database
+- securely shares resources between authorized users
+- provides ethical terms and conditions of use
+
+#### Examples:
+Here are some *examples* from previous semesters:
+- File Sharer: users can upload and share confidential files with others
+- URL Shortener: users can shorten URLs, track analytics, and share info with others
+- Pixel Tracker: users can create a tracking pixel to embed in emails, web pages, etc.
+- Secure Messenger: users can chat with others, using encrypted messaging
+- Secure Config File Share: developers can store and exchange secure credentials and tokens for projects
+
+#### Novelty
+Its fine your idea already exists as a service today, but try to add a *new spin* to it.
+
+Here are some examples of how to modify an existing service idea:
+- makes it harder for the service provider (you) to snoop on data (i.e., end-to-end encryption)
+- offers automatic transfer of rights (e.g., friends-of-friends-of-friends get automatic authorization to resources)
+- offers web + command line access (e.g., file upload/download)
+- integrates with modern security tools (e.g., PGP, Keybase)
+- adds security trail to identify abuses (e.g., picture watermarks, text manipulations)
+- stored resources (e.g., shortened URLs) expire after time

descriptions/010_filestore_api.md

@@ -1,8 +1,8 @@
-## A. Basic File Store API
+## Basic File Store API
 
 This week your team will create the beginnings of an API to perform your service
 
-1. Create a basic API based on the project we saw in class [(see the `0_filestore_api` branch of the in-class demo app)](https://github.com/ISS-Security/configshare/tree/0_filestore_api)
+1. Create a basic API based on the project we saw in class (see the `0_filestore_api` branch of the in-class demo app)
   - **Do NOT clone or fork from the class demo project!**
   - Create the appropriate resource class for your project in the `models/` folder
   - Create an appropriately named Sinatra-based API class in `app.rb`

descriptions/020_db_testing.md

@@ -1,4 +1,4 @@
-## B. Database and Testing
+## Database and Testing
 
 We will start addressing some of the security issues we found by adding a database to our application and writing tests for it. You can refer to the [`db_testing` branch of the demo code we saw in class](https://github.com/ISS-Security/configshare/tree/1_db_testing).
 

descriptions/030_db_hardening.md

@@ -1,4 +1,4 @@
-## C. Database Hardening
+## Database Hardening
 
 Using a database solves many of our security problems and also introduces new problems. This week we will advance our database driven system by preventing common vulnerabilities and introducing encryption. See the [`db_hardening` branch of our demo code](https://github.com/ISS-Security/configshare/tree/2-db_hardening).
 

descriptions/040_secure_accounts.md

@@ -1,4 +1,4 @@
-## D. Secure User Accounts
+## Secure User Accounts
 
 Allowing user accounts creates many complexities in our design. Let's try to create and integrate secure accounts for users into our database design. See the [`secure_accounts` branch of our demo code](https://github.com/ISS-Security/configshare/tree/3-secure_accounts).
 

descriptions/050_interface_client.md

@@ -1,4 +1,4 @@
-# E. Deployed API and Interface Client
+# Deployed API and Interface Client
 
 This week are are deploying our APIs into live production and building up our interface as a web client application. We are interested in seeing if we can get users to login for now! Take a look at the latest code at:
   - [Deployed API](https://github.com/ISS-Security/configshare)

descriptions/060_token_authentication.md

@@ -1,4 +1,4 @@
-# F. Token Based Authentication
+# Token Based Authentication
 
 This week we will use tokens (JWT) in our authentication process. You'll see that tokens allow us to securely store information about the state of the session on the client's side. See the latest version of our [application side code](https://github.com/ISS-Security/configshare-app/tree/2-token_authentication).
 

descriptions/070_validation_ssl.md

@@ -1,4 +1,4 @@
-# G. Validated Form Input and Enforce SSL
+# Validated Form Input and Enforce SSL
 
 This week we are validating user input coming from web forms, and enforcing
 SSL connections between essential parts of our architecture. Take a look at the

descriptions/080_token_authorization.md

@@ -1,4 +1,4 @@
-# H. Token Based Authorization
+# Token Based Authorization
 
 This week will implement the beginnings of authorization, and we will use tokens once again. Note that all the critical authorization decisions will be done on the API side. Thus, the API must create and send an encrypted token that must be returned by client applications on every request.
 

descriptions/090_oauth_protocol.md

@@ -1,4 +1,4 @@
-# I. Single Sign-On Using OAuth an Single Table Inheritance
+# Single Sign-On Using OAuth an Single Table Inheritance
 
 This week we will implement single sign-on (SSO) to allow users to login using their Github credentials. But first, we must setup our database (API) to handle two types of accounts: regular accounts (Account) and SSO accounts (SSOaccount).