1. 1 Steve Chenoweth Friday, 10/21/11 Week 7, Day 4 Right – Good or bad policy? – Asking the user what to do next! From http://remove- malware.net/how-to-remove-protection-system- security-alert/.http://remove- malware.net/how-to-remove-protection-system- security-alert/ CSSE 477 – More on Security Background – Malta updates its maritime security system. From http://www.maritimeterrorism.com/2008/03/05/malta-updates-its-maritime-security-system/ http://www.maritimeterrorism.com/2008/03/05/malta-updates-its-maritime-security-system/

2. 2 Today More on security – this  Show security results in class, work on term paper with team

3. 3 Review of Basics Security “quality” means engineering the software so that it continues to function correctly under malicious attack Security issues include: –Attack or threat –Confidentiality –Integrity –Assurance –Availability Review

4. 4 So secure systems have… Nonrepudiation –users can’t deny they did something Confidentiality –No unauthorized usage Integrity –Data and services delivered as intended Assurance –Parties are who they say they are Availability –Denial of service attacks won’t prevent services Auditing –System tracks activities so that they can be reconstructed Review

5. 5 Security tactics include From Ch 5 in Bass: –Resisting attacks –Detecting attacks –Recovering from an attack Under a wide variety of situations All these require careful planning and design –Security can’t be tacked on after a system is built Review

6. 6 Need to know common security threats Plan for these situations to occur Check for in design reviews, code reviews, and various levels of testing Security is a “knowledge intensive” area of endeavor

7. 7 Security problems – like bugs? Traditional non-security bugs -- Defined as non-conformance to a specification. –Security bugs are additional behavior that was not originally intended –System is doing what it is “supposed to do” Inspections tend to look for: –missing behavior and –incorrect behavior. –Neglect to look for undesirable side-effects

8. 8 Not so obvious issues – for any app How do you monitor for things like side effects you never expected? file writes, registry entries, extra network packets with unencrypted data, unauthorized access, privilege escalation, exploitation of incorrect error handling, sabotage via the app –like file corruption

9. 9 Obvious issues – in the large Systems never intended to be online – now have a web interface Systems never intended to be “services” now offered as service oriented architectures (SOAs) Servers communicating with weak authentication / encryption to other servers (like in procedure calls) Rapid deployment, to market of new products Growing size / complexity of exposed systems Security expertise not keeping up with software development –Security is not just the purview of “security people” Mobile devices give even more threat opportunities

10. 10 Important preventive practices Penetration testing – simulate errors in the app, etc. Run tests that involve disk errors, memory failures, and network problems Input filtering (block malicious input) –Access to objects depends on multiple conditions Defect removal filters –Check input at multiple places –Every access attempt must be checked Assume the most hostile environment –Assume an attack if uncertain Default to denying service Simple, understandable design Operate with fewest privileges –Minimize use of shared mechanisms

11. 11 Example best practice – deletion! Why study deletion? –Affects everybody: we all have private or security- critical information that needs to be deleted. –Lots of lore, not a lot of good academic research. –Most deleted files can be recovered! Even disk reformatting doesn’t fix that Delete doesn’t = shred –Browser cache, cookies and history also tend to last –License agreements, like for Flash, allow snooping How many of these agreements do you read carefully?

12. 12

13. 13 Things to do at every step…

14. 14 You should be able to design & audit security in a system Security Must Be a First Class Citizen - Integrated at Early and All Stages of the Lifecycle –Should be visible in UML Security Assured, Synchronized, Convenient Provide Automated Transition from Security Definitions to Security Enforcement Code Integration of Enforcement Code with Application

15. 15 Security Design Principles The Software Design Has Multiple Iterative Phases and The Security Features Should Be Incorporated and Adjusted During Each of and Among Those Phases The Security Assurance is Satisfied Relatively to the Period of Software Design The Security Incorporating Process Should Neither Counter the Intuition nor Decrease the Productivity of the Software Designer. Security Definition via a Unified Perspective that Collects Privileges into a Cohesive Abstraction