1 / 12

Security by Design

Security by Design. Thomas Zalonis Seth Gainey Neil C. Lee tgzalonis@gmail.com seth.rylan@gmail.com nclee@edisto.cofc.edu. Introduction :

pascha
Download Presentation

Security by Design

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. Security by Design Thomas Zalonis Seth Gainey Neil C. Lee tgzalonis@gmail.com seth.rylan@gmail.com nclee@edisto.cofc.edu

  2. Introduction: 1) As more and more aspects of the world become interconnected the range of possible security issues increases. 2) Increases in security issues leads to extra software functionality required to defend against them, which means added complexity and cost. 3) Trade offs between client requested functionality and security issues are made in order to reduce costs. 4) Our goal is to show that, in the long run, an integration of security with all phases of the development process would be more beneficial than treating security as a separate issue.

  3. Overview: 1) Background information: (e.g. What are security requirements? What is their current place in software development?) 2) A more specific explanation of our goal. 3) Present the justifications behind our argument by discussing the benefits of an integrated model. 4) Propose various ways that an integrated model may be achieved through the use of various tools, design strategies and improvements in education. 5) Conclusions and discussions.

  4. Background: 1) Security Requirements: “...non-functional constraints on the functional requirements of a system.” (Charles B. Haley et al.) 2) Current state of security requirements: An 'Ad hoc' process, where security issues are typically left out of the early development phases. (e.g. Requirements engineering, design and implementation)

  5. Argument: 1) Security should play an equal role in the requirements engineering process. 2) The merger of security requirements into requirements engineering would then cause security issues to propagate throughout the later development phases. (i.e. Design and implementation) 3) Added cost and complexity issues would be reduced in the long run by accounting for security early on instead of trying to add it later when design and implementation has already finished.

  6. Justification: • Increased reliance on technology • It’s a jungle out there • Consequences of poor security

  7. Ethical Considerations: • Privacy vs. Control • The Anatomy of a Worm • Case Study: Code Red • Old Rules and New Technology

  8. Mismanaging Risk • The Myth of Absolute Security • The Balance of Information Security • Security and Finance — The Cost of Avoidance • Security is not a feature

  9. Design Strategies and Techniques • Model Driven Security (MDS) • Aspect-Oriented Programming • Software Architecture Model (SAM)

  10. Tools • Eclipse-based tools • Jifclipse • SSVChecker • UML-based tools • UML with Mandatory Access Control • UMLsec extension • WriteOn

  11. Education • Integrate system-level issues into all programming courses. • Apply patterns at every stage of software development. • Use Honeynets as a teaching and research tool.

  12. Conclusion • Ignoring security concerns until the maintenance phase leads to greater risks and costly “fixes”. • There are tools and resources available to facilitate secure software design. • Security should be integrated into all phases of software development.

More Related