1 / 15

CSSE 477 – More on Security

Learn about common security threats and best practices for protecting your system from malicious attacks. Understand the importance of security in the software development lifecycle and how to incorporate security measures at every stage.

stratton
Download Presentation

CSSE 477 – More on Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CSSE 477 – More on Security 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/. Background – Malta updates its maritime security system. From http://www.maritimeterrorism.com/2008/03/05/malta-updates-its-maritime-security-system/

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

  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. 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. 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. 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. 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. 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. 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. 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. 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. Things to do at every step…

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

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

More Related