Note: This unit version is currently being edited and is subject to change!
COMP5617: Empirical Security Analysis and Engineering (2017 - Semester 2)
|Unit:||COMP5617: Empirical Security Analysis and Engineering (6 CP)|
|Faculty/School:||School of Information Technologies|
Dr Holz, Ralph
|Session options:||Semester 2|
|Versions for this Unit:|
|Site(s) for this Unit:|
|Brief Handbook Description:||This unit will present the lessons from recent research and from case studies of practice to bring students the skills to assess and improve the security of deployed systems. A particular focus is on data-driven approaches to collect operational data about a system's security. We explore deployment issues at local and global scale, e.g. for X.509, DNS, and BGP, and also take human factors explicitly into account. As a result, students will learn to put building blocks of security together in a sound way, to arrive at engineering solutions that are empirically verifiable, functional, and secure against realistic threats. As Dan Geer once famously said: "Any security technology whose effectiveness can't be empirically determined is indistinguishable from blind luck."|
|Assumed Knowledge:||ELEC5616 OR INFO2315. Good programming skills in Go, Python or C; skills to learn a new language if required. A reasonable technical orientation and basic networking knowledge is required. Students should bring the mathematical skills to understand cryptography; the unit will introduce the functional principles as background. Prior exposure to security is helpful, but not a pre-requisite.|
|Additional Notes:||In 2017 semester 2, we are going to use the Go programming language, which is why we require a background in either Python or C for students who do not know Go yet. Students are encouraged to familiarise themselves with Go: https://golang.org/.|
Dr Holz, Ralph
Attributes listed here represent the key course goals (see Course Map tab) designated for this unit. The list below describes how these attributes are developed through practice in the unit. See Learning Outcomes and Assessment tabs for details of how these attributes are assessed.
|Attribute Development Method||Attribute Developed|
|Demonstrated by modelling the empirical security measurements as part of the practical assignment||Design (Level 3)|
|Lectures and tutorials on Internet service engineering and security analysis concepts; practical assignment on security engineering||Engineering/IT Specialisation (Level 4)|
|Prescribed readings and case study paper; conducing an empirical security analysis||Maths/Science Methods and Tools (Level 4)|
|Case study paper||Information Seeking (Level 4)|
|Through lectures on security engineering, privacy-preserving security measures and usability of security practices||Professional Conduct (Level 3)|
For explanation of attributes and levels see Engineering & IT Graduate Outcomes Table.
Learning outcomes are the key abilities and knowledge that will be assessed in this unit. They are listed according to the course goal supported by each. See Assessment Tab for details how each outcome is assessed.Professional Conduct (Level 3)
The late penalty for all practical exercises is 20% of the awarded mark per day late; maximum 5 days late (after that: 0 credits).
The security analysis and engineering concepts will be assessed in a 2 hour written final exam in the examination period.
Students must get 40% in the final exam to pass the unit, regardless of the sum of individual marks.
There may be statistically defensible moderation when combining the marks from each component to ensure consistency of marking between markers, and alignment of final grades with unit outcomes.
|Assessment Feedback:||Feedback on the progress of the projects will be given throughout the semester in the tutorial after the lecture.|
|Policies & Procedures:||IMPORTANT: School policy relating to Academic Dishonesty and Plagiarism.
In assessing a piece of submitted work, the School of IT may reproduce it entirely, may provide a copy to another member of faculty, and/or to an external plagiarism checking service or in-house computer program and may also maintain a copy of the assignment for future checking purposes and/or allow an external service to do so.
See the policies page of the faculty website at http://sydney.edu.au/engineering/student-policies/ for information regarding university policies and local provisions and procedures within the Faculty of Engineering and Information Technologies.
Note: Students are expected to have a personal copy of all books listed.
Note: References are provided for guidance purposes only. Students are advised to consult these books in the university library. Purchase is not required.
|Online Course Content:||On the unit`s eLearning site (Blackboard), there will be available the lecture slides, readings, lab handouts and any background information.|
Note that the "Weeks" referred to in this Schedule are those of the official university semester calendar https://web.timetable.usyd.edu.au/calendar.jsp
• Unit organisation
• Intro: security engineering
• Threat modelling
Lecture: Building block: Crypto
• Functional overview: symmetric and public-key cryptography
• Case study: the proliferation of weak keys in the wild
• Measurement of cipher deployment
Short assignment starts: modelling/measurement task
Lecture: Building block: protocols
• Functional overview: security protocols in the Internet stack
• Introduction: scanning and monitoring to determine deployment security
• Real-world trust anchors: hierarchical PKIs, flat PKIs
What goes wrong in deployment: Internet protocol use
• Deployment of TLS and X.509 as the security backbone of the Internet
• Successful subversion, lessons learnt
• Mistakes in deployment, lessons learnt
|Assessment Due: Modelling Empirical Security Measurements|
Lecture: Data-driven modern defences
• The notary principle
• Append-only auditable logs
• Cross-validation and monitoring to achieve better security
Long assignment starts: security measurement/scan
Lecture: Naming and security
• Naming systems
• DNSSEC extensions
• Deployment issues
Internet routing security
• The insecurity of global routing: threat model and effects
• BGPSec and RPKI
• Measurement-based defences: BGP threat detection
Lecture: The WWW: the Achilles heel of deployment
• Attack surface in deployment
• Engineering a secure Web application
• Case study: Websockets, WebRTC
Lecture: Usable security
• Security vs. usability trade-offs
• User psychology
• Case study: passwords (CRAM/SCRAM, best practices)
Short assignment starts: case study/paper
|Assessment Due: Security Measurement / Scan Task|
Guest lecture: Real-world security: the world of finances (TBC)
This is a placeholder as the lecture in wk 10 falls on public holiday - currently looking for a solution for this.
Lecture: Special topic: Privacy-preserving technologies
• Engineering for anonymity/pseudonymity
• Anonymity and censorship evasion
• Deniable communication: OTR
Lecture: Alternative 1: Guest lecture on Real-World security: the world of finances
Special topic: Censorship and network interference
• Network interference and forms of censorship
• Measurement of censorship and interference
|Assessment Due: Case Study / Paper|
Lecture: Review of unit
• Discussion of final exam
|Exam Period||Assessment Due: Final Examination|
The following is a list of courses which have added this Unit to their structure.
This unit contributes to the achievement of the following course goals:
|Professional Conduct (Level 3)||Yes||24%|
|Information Seeking (Level 4)||Yes||0%|
|Maths/Science Methods and Tools (Level 4)||Yes||28.5%|
|Engineering/IT Specialisation (Level 4)||Yes||32%|
|Design (Level 3)||Yes||15.5%|
These goals are selected from Engineering & IT Graduate Outcomes Table which defines overall goals for courses where this unit is primarily offered. See Engineering & IT Graduate Outcomes Table for details of the attributes and levels to be developed in the course as a whole. Percentage figures alongside each course goal provide a rough indication of their relative weighting in assessment for this unit. Note that not all goals are necessarily part of assessment. Some may be more about practice activity. See Learning outcomes for details of what is assessed in relation to each goal and Assessment for details of how the outcome is assessed. See Attributes for details of practice provided for each goal.