Secure Product Lifecycle
Table of Content
Developing a secure product in a secure way touches every aspect of IT Security. This starts with defining security requirements and ends with a secure decommissioning of the product.
In this course, we will provide an overview of all elements of a secure product life cycle and dive deeper into selected topics. In particular, we will discuss
- Secure development process
- Security requirements management
- Risk analysis and threat modeling
- Security Architecture and System Design
- Security Mechanisms design
- Security Testing & Vulnerability Assessment
- Security Evaluation & Certification
- Secure Market Surveillance
- Secure Guidance and Release
- Secure Updates in the Field
- EOL: Secure Decommissioning
A secure product lifecycle is a key factor in designing, developing and maintaining a secure product. How can we make sure that nothing goes wrong during the development process? How can we make sure that the product stays secure once used in the field? Before we even begin with the development of a product, we must have a clear view of the security requirements to make sure that we address them accordingly during later phases. Once we know what we need to protect, we need to understand against what we must protect. Analyzing security risks and modeling threats is the basis for choosing the right security features and their implementations.
Now that we have done our homework, we can start designing and implementing the product. How can we be sure that security requirements have been fulfilled, that threats have been addressed accordingly and that the implementation is bullet proof? By making sure that security testing and vulnerability assessment is an integral part of the lifecycle. Once the product is ready for release and we are sure that it is secure, how can we prove it to others? By asking someone else to evaluate what we did. There are several international standards how to perform evaluations which lead to an official certificate that an independent third party is attesting your product is secure (to a certain level). How can customers and the certification body be sure that what is sold is the same what was tested. There is a need for surveilling the market.
Finally, the product is ready and gets released and sold to thousands of customers. Have we methods in place to check whether what we build, what was tested, what was certified and what was released and sold is all the same? Do we provide to customers everything they need to install and use the device in a secure way, without requiring a PhD?
Although, we considered all the above, there is nothing you can do to make a product 100% secure, but we can make sure that we address discovered issues and vulnerabilities quickly. We can make sure that updates are delivered in a secure way and that customers are aware of it.
Sadly, nothing is used forever, not even secure products. There comes the time where its life ends. When this time comes, we need to make sure that it is properly decommissioned. Making sure all secrets are erased, all customer data is removed so that it can rest in peace…
…and we can start developing a new product where a secure lifecycle is a key factor in…
All lectures and exercises are conducted virtually this year. Lectures take place in Microsoft Teams. Exercises take place in Discord.
You can watch online contents live. For most contents, recordings will be available afterwards. Send us an email if you need access to the recording.
You will receive the relevant URLs by email, so please monitor your inbox.
|01.10.2020||12:15-13:45||Introduction and overview||Tomislav Nad|
|08.10.2020||12:15-13:45||Secure development life cycle, Security requirements||Tomislav Nad|
|15.10.2020||12:15-13:45||Risk analysis and threat modelling||Raphael Spreitzer|
|22.10.2020||12:15-13:45||Security architecture, design and mechanisms||Tomislav Nad|
|29.10.2020||12:15-13:45||Security testing, evaluation and certification, part 1, part 2||Christoph Herbst, Wolfgang Krupp|
|05.11.2020||12:15-13:45||Security testing: penetration testing, Web||Peter Aufner|
|12.11.2020||12:15-13:45||Security testing: penetration testing, Mobile App||Mathis Hesse|
|19.11.2020||12:15-13:45||Security testing: penetration testing, IoT||David Bidner, Hannes Gross|
|26.11.2020||12:15-13:45||Security testing: fuzzing||Raphael Spreitzer|
|03.12.2020||12:15-13:45||Security testing: implementation attacks||Hannes Gross, Tobias Wagner|
|10.12.2020||12:15-13:45||Security guidance and release,
Secure updates in the field
|Wolfgang Krupp, Christian Hanser|
|17.12.2020||12:15-13:45||Secure market surveillance, Secure decommissioning||Christoph Herbst, Tomislav Nad|
|14.10.2020||13:15-1400||Exercise 1: risk analysis and threat modelling — Exercise||28.10.2020|
|04.11.2020||13:15-1400||Exercise 2: security architecture and design — Exercise||18.11.2020|
|25.11.2020||13:15-1400||Exercise 3: security test plan — Exercise||16.12.2020|
|07.01.2021||13:15-1400||Exercise 4: security testing||20.01.2021|
There will be a written exam for the VO.
Due to ongoing lockdown, we will change the mode for the exam.
We opted for the following mode:
- Oral exam conducted on our Discord server: SPL -> #exam-lobby-2020
- You will require a webcam and microphone. Please also bring an ID-card (Studierendenausweis).
- Oral exam will consist of 6 questions
- There will be 6 examiner (VO’s lecturers), each one focusing on a specific topic and asking 1 question
- You have 5 minutes per question. After the 5 minutes, you move forward to the next examiner and the next topic.
- In total, your exam will take 5×6=30 minutes, plus a few extra organisational minutes.
- You will be asked to select your individual starting timeslot.
- Please arrive in the Discord exam lobby about 10 minutes beforehand so that you can test your technical setup.
If you have any questions don’t hesitate to contact firstname.lastname@example.org directly.
There are four exercises. The KU will be graded based on the submitted results, short presentation followed by an exercise interview.