1. Doh! securityin cloud and mobile apps http://www.flickr.com/photos/johanl/4934459020

2. What does “Security” encompass? • One viewpoint: NIST FIPS 199http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf • Confidentiality • Integrity • Availability I’ll abbreviate these as CY, IY, AY in lecture, and ++ will mean “can improve”, e.g., CY++, and -- will mean “can threaten”

3. Confidentiality (CY) • “Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information” • This is the primary linkage between security and data privacy laws and regulations such as HIPAA • Example of a threat: packet sniffing (CY--)

4. Integrity (IY) • “Guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity” • How critical is it that data not be altered? • Loss of confidentiality is NOT synonymous with loss of integrity • Example of a threat: trick server into deleting data (IY--)

5. Availability (AY) • “Ensuring timely and reliable access to and use of information” • How much would people complain if they couldn’t get to certain information? That tells you whether availability is important. • Can be assessed using Business Impact Analysis (BIA) • Example of a threat: denial of service attack (AY--)

6. Key security principlescourtesy of Open Web Application Security Project • Secure by design • Use a positive security model • Keep security simple • Defense in depth • Fail securely • Secure defaults • Trust no one • Run with least privilege • Don’t trust services • Don’t trust infrastructure • Avoid security by obscurity • Detect intrusions https://www.owasp.org/index.php/Main_Page

7. Secure by design == think about security up front • Common mistake: create app, “add security” afterward • E.g., create application and then slap on some authentication afterward • Sometimes this messed up approach can CY++ • But does little for IY and nothing for AY • This is a main area where the common strategy "improve quality as go you go along" is not good.

8. Use a positive security model • Don’t think in terms of preventing bad stuff; instead, think in terms of only allowing good • Example: • Always ensure that a user must be logged in and authorized before showing data, modifying data, or otherwise using substantial server resources (CY++, IY++, AY++) • Always validate all inputs (including cookies) (CY++, IY++)

9. Keep security simple • Minimize everything. Examples: • Only have one screen for logging in. • Only have a single class that checks authorization. • Only implement functionality that is needed (minimize attack surface) • Only store data that are needed. • Simplicity makes it easier to verify that your application protects CY, IY, AY • And data not saved cannot be stolen (CY++) • And functionality not created requires no resources (AY++)

10. Defense in depth • Try to make each component (or layer) secure, independent of other components • Very difficult, especially to do in a simple way • Examples: • Encrypt all private data in the datastore (so even if it is somehow stolen, it is nearly useless, CY++)

11. Fail securely • Suppose that the code related to security is broken; ensure that security still remains! • Example: • If you’re checking authorization by querying the datastore, and the datastore crashes, do not let users access resources (CY++, IY++, AY++)

12. Secure defaults • Each new user’s default configuration should be secure by default. • Examples: • By default, user must type password in every time but has option to “remember me” (CY++, IY++) • By default, all data are stored in encrypted format but user has option to export data to CSV (CY++) • By default, user must by a token to use service but you can give away some free tokens (AY++)

13. Trust no one • So now you’re thinking about security up front instead of trying to put it in after the fact • But it’s still not enough, because what you’re thinking about isn’t all that matters • You need other peoples’ help when creating apps • Whose components will you be using? • What were those people thinking?

14. Run with least privilege • What if somebody slipped in some evil code (or you have a bug)? Minimize harm by running with the lowest privilege needed • Mainly relevant on platforms such as EC2 and Azure where your code can “run as” a user • Example: • If a service only needs to access database, not files, then don’t run as a user account that has permission to read or write files (CY++, IY++)

15. Don’t trust services • Try to avoid passing sensitive data to services (or components) created by other people • Example: • Suppose there is a service that can create maps with annotated pushpins. It has two APIs. • Pass all data (latitudes, longitudes, annotations); it generates a map • Pass one location and a map size (lat, long, size); it returns a map where you can overlay pushpins • The second API is probably more secure (CY++) • But maybe AY-- (if the second option is failure-prone)

16. Don’t trust infrastructure • Assume that your cloud platform provider can see all your data and modify all your code; plan for the worst. • Examples: • Host all sensitive data and computation on your own server; use the cloud for non-sensitive but computation-intensive tasks (CY++, IY++, AY--) • Extreme solution: client encrypts all data before sending to server; all computation happens on client; only server use is storage (CY++, IY++)

17. Avoid security by obscurity • Assume that somebody will eventually see your code; don’t depend on the secrecy of your code to protect security • Examples: • Do not store passwords in source code; instead, store them hashed or type in during installation • Do not have “secret URLs” that enable anybody to do evil things if they know the URL

18. Detect intrusions • Assume you will get hacked; plan to detect it and respond • Examples: • Have a task monitor datastore and alert if data magically disappear, so you can restore from backups (IY++, AY++) • Log all logins and source internet addresses so that you can detect unusual logins and can deactivate accounts if needed (CY++, IY++, AY++)

19. There is SO much more to learn.Resources for further reading • Store hashed passwords, not clear text Refer to lecture in unit 2 for the necessary code, and/or to these sites… http://www.codinghorror.com/blog/2007/09/youre-probably-storing-passwords-incorrectly.html http://yorickpeterse.com/articles/use-bcrypt-fool http://www.mindrot.org/projects/jBCrypt/ • Common security mistakes in web apps http://coding.smashingmagazine.com/2010/10/18/common-security-mistakes-in-web-applications/ http://www.dayasolusi.com/articles/general/128-software-development-avoid-these-10-common-web-based-application-security-mistakes

20. Key security principlescourtesy of Open Web Application Security Project • Secure by design • Use a positive security model • Keep security simple • Defense in depth • Fail securely • Secure defaults • Trust no one • Run with least privilege • Don’t trust services • Don’t trust infrastructure • Avoid security by obscurity • Detect intrusions https://www.owasp.org/index.php/Main_Page