1 / 25

FIT3056 Secure and Trusted software systems

FIT3056 Secure and Trusted software systems. Le, P.D Faculty of Information Technology Monash University, Australia pdle@infotech.monash.edu.au. Acknowledgement. Most of the materials are prepared by me. Some slides are borrowed from other lecturers who previously taught this subject.

sorcha
Download Presentation

FIT3056 Secure and Trusted software systems

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. FIT3056 Secure and Trusted software systems Le, P.D Faculty of Information Technology Monash University, Australia pdle@infotech.monash.edu.au

  2. Acknowledgement • Most of the materials are prepared by me. Some slides are borrowed from other lecturers who previously taught this subject.

  3. Main objectives for this unit • Demonstrate the importance of developing secure software • Introduce various security threats, vulnerabilities and controls that need to be addressed during the development of secure and trusted software (systems) • Introduce secure programming principles and practices (for constructing secure and trusted software) • Motivate you as a software developer/security specialist to apply secure programming principles and practices in your projects • Gain knowledge of testing and verifying secure and trusted software.

  4. Important Information • Examination (3 hours): 60% • Two assignments (20% each). • You need to pass the assignments and exam to pass the subject. • Please let me know if you have difficulties with this subject asap. • Do not sit down and program. Work out the solution logically before you start your work. • Discuss with the lecturer and tutor how to learn this subject and start your assignments asap.

  5. Assignment Assessment • A submission that meets all the basic requirements but does not extend beyond this will receive a pass grade (P) • Some additional research or independent work may need to be demonstrated before a grade of C will be awarded • Grades of D or HD will be reserved for submissions that show a sound understanding and exceptional ability of students

  6. Outline of the subject • Introduction to software design and implementation and security. • Computer system software problems (vulnerabilities) and solutions (2 lectures) • Principles of secure software design and implementation (2 lectures) • Concurrent and distributed secure software • Building trusted software systems • Secure software testing and verification • Reading in Software Security and Trusted Systems • Revision

  7. Outline of lecture 1 • Structure of a program. • Fundamentals of software development. • Why software security is important? • Why is it necessary to develop secure and trusted software from the start? • What is the difference between an insecure piece of software and a secure one? • Some examples of good and bad code.

  8. Types of software • Operating systems and middleware • Stand-alone applications installed on a hard disk • An app that prints letters to bank customers • Qlock program (www.qlock.com - freeware) • Web-based applications • Run from a web server • Display in a web browser • Eg, web sites, web services • Mobile and wireless applications • PDA, mobile phone apps • Mobile agents • Software components • COTS – Commercial off-the-shelf • Open source

  9. Software development • A real world problem is specified • A logical answer is produced after a number of design steps with or without security in mind • A programming language is chosen to map the logical answer to a real one (a computer program). • The program is tested and put it in use

  10. Established areas of security Where software security fits? S/w that uses a db must connect to and interact with the db securely S/w runs on o/s and abides by its security rules Database security Software security Network security Operating System security Information Security S/w uses encryption to ensure data confidentiality, integrity and non-repudiation S/w sends/receives data across inherently insecure networks Borrowed this slide from other lecturers

  11. Ideas about computer programs • Program: - a static description of what you would like to happen (you describe what you would like to happen as an algorithm – the algorithm is then mapped into a sequence of statements of a programming language) • Process: - Is a program in execution. It is self-contained running program with its own address space - Is an active entity in the system which executes the algorithm (program).

  12. Programs & Processes • A program can become a process and the process can then spawn new processes to run the same or other programs. • Each process has its own unique address space (stack + global variable space + heap space) • If two processes are created from the same executable, they still have different address spaces. • A process is associated with a privilege.

  13. Processes (e.g.) • A process can clone itself using “fork” under UNIX, but that also creates a separate address space int x = 1; int pid; main() { pid = fork(); x = x + 1; } Create a new process Under Unix (who created this process is important – who wrote the code is not important – why?)

  14. Threads • A thread is a single sequential flow of execution within a process. • Threads in the same process share the same address space.

  15. Processes/Threads under OS - A process is represented by its code, data and the state of the machine registers, given in a descriptor. - A process can support many threads of control, and it has multiple stacks, one for each thread.

  16. Programming languages and security • Some programming language such as C (programming efficiency and code length are more important than security) or C++ (programming efficiency, code length and object-oriented programming features) are more important than security) were not designed for secure software development. • Other language such as Ada and Java was designed with some security considerations. • Some programming language you cannot enhance security much no matter how smart you are such as assembly language.

  17. What we need to know about programs before considering software security • Do we need programs which require no input or output? • Are there many programs which require input and/or output? • Are there programs running on the same computer? • Are there programs running on different computers connected by a network?

  18. What we need to know about programs before considering software security (con’t) • Are there programs which you can run with higher privileges than yours? • What does it mean by user-space processes and kernel-space processes? • Do you know how to build applications that can transmit confidential data for you on request? • Can you build applications that can provide you confidentiality and integrity over the communications?

  19. Why software security is important? • Compromised software can lead to: • Loss of productivity • Eg, DoS attacks, loss of data • Loss of trust • “It’s hard to build and easy to lose: a single violation of trust can destroy years of slowly accumulated credibility.” - Jakob Nielsen • Loss of money • Loss of business due to loss of trust or competitive advantage • Expense of fixing the damage • Expense of fixing security vulnerabilities

  20. Why is it important to develop secure and trusted software from the start? • Security is not a feature to be added at any time • Security as an after thought is bad • By then, time constrains prevent a through security testing and review • Reviewing existing code and fixing any bugs add extra time and costs to the development cycle • External security reviewers cannot guarantee that all bugs will be found and fixed, because they lack intimate understanding of the system • Automated tools can only pick up some known vulnerabilities and overlooking many others. • Production environments may not allow vulnerabilities to be discovered.

  21. Code, bugs and you – Who is the winner? • Software complexity is measured in lines of code, programming style, and programming language platform. • Some estimates that there is likely to have at least a bug per 100 lines of C code. • Typical operating systems such as your favourite Windows have few millions lines of code. • CERT statistics says that they discover roughly 5000 bugs per year, so it will take approximately 4 years to fix all the bugs in your favourite OS!. Then the new release gives you more bugs. When can you fix all of them?

  22. Evaluating trust in computer systems and software • Evaluation is a formal methodology and set of procedures used to measure the degree of trust that can be placed on a system • Empirical or qualitative evaluation are commonly used methods • The most popular evaluation schemes in use are: • The Orange Book • The Common Criteria • European ITSEC criteria (not discussed here) – (refer to the sources for further reading.)

  23. Microsoft’s Trustworthy Computing (eg.) • Microsoft’s 5-10 year vision to address security, privacy, and reliability issues • Increased investment in MS Research • Their goal is for the users to be able to say: • I can trust this product • I can trust this supplier • This product is secure, reliable, and my privacy is respected (can we have all those?)

  24. Goals of Trustworthy Computing (source:Trustworthy Computing: Microsoft White Paper http://download.microsoft.com/download/a/f/2/af22fd56-7f19-47aa-8167-4b1d73cd3c57/twc_mundie.doc)

  25. Security by Design before Software Development • Establish a security team • Require security training • Develop threat models during design • Adhere to design and coding guidelines • Regularly revise the guidelines • Develop regression tests for all previously fixed vulnerabilities. • Simplify the code and the security model • Perform penetration analysis before shipping

More Related