Welcome to the Secure Software Design Specialization. My name is Al Glock and I'm the instructor for this course. Why am I teaching this? Let me give you a bit of my background. In addition to the basic courses we offer on Java and data structures, I teach computer organization and assembly language. Computer architecture and the software engineering series, of course, is at the University of Colorado, Colorado Springs. I consult for companies in the aerospace and defense business. Prior to teaching at UCCS, I worked for a large defense contractor in software development in management jobs. I have been a project manager in the venture capital funded private sector, and I have won several small business innovation research contracts. I spent 20 years in the United States Airforce both in the political science and engineering fields. I wrote software, particularly simulation software, in both fields. I have been involved in requirements and design phases of large government contracts. So in essence, I've seen large software development from both the government and the contractor sides. And in case you're interested, I wrote my first program in IBM 1401 assembly language when I was 15 years old. I think it added some numbers together. This specialization is as significant as it is amorphous. In many software development shops, designing security into the software is of huge importance. Nevertheless the boundaries of what constitutes secure design are unclear. Is it a matter of implementing a checklist of secure measures? Does it extend a threat analysis and mitigation? Does secure software design include broader areas such as system architecture? Does it extend into coding practices? Of course, there are more boundary pushing matters than these. Add to this, the fact that the threat is constantly changing. The bad guys are at least as clever and creative and motivated as the good guys. The fact that the threat landscape is constantly changing is hugely significant to us who are trying to produce secure software designs. What it means is that what is secure today may not be secure tomorrow. Later on I will discuss the stack overflow technique. This demonstration will show that insecure practices can be buried deep in the code. It will show that a lot of knowledge about machine design, assembly language instructions, and CPU architecture come into play to make the exploit work. In my experience it is very rare to have a person in any role in a software development effort who commands the breath and depth of knowledge. This means that a designer handling threats is no ordinary designer. The designer must be able to look at the software from multiple perspectives at a very macro level and the designer must also be able to understand the workings of the algorithms and the machine right down to the silicon. In the third section of the specialization, we'll take a look at Bitcoin and examine its security features. I'm sure that this will give you an appreciation for the wide range of capabilities and skills a good designer must have. But don't be dismayed, don't think that you have to be super human to design secure software. We'll talk about how secure software design is largely good software design. Design principles which are known for decades are effective mitigations for today's security concerns. It's just that the race to market for under the pressure of budget and schedule, a lot of these good design principles have been skipped. So we'll go back, talk about the basics. Admittedly, however, this is a necessary but in itself insufficient formula for software security. Here's a broad outline of what we're going to do. The Secure Software Design Specialization is composed of four courses. In this first course, we'll talk about the software development life cycle and how design fits into it. We'll look at design as an element of the software development life cycle. In fact, that is the purpose of this section of the course. In the second course, we'll look at design as an abstraction and see how that differs from what design does in the life cycle. In the third course, we'll look at design methods and tools. These will be conventional methods and tools, things that have been around for a long time but which can have an impact on security if understood and used properly. We'll conclude the third section with a look at Bitcoin, and how cleverly and intimately security is worked into the design. Finally in the fourth course we'll take a look at specific threats and mitigations of those threats. In summary, this first course in the Secure Software Design Specialization examines design as an element of the software development life cycle. The second course looks at design as an abstraction. The third course looks at design methods and tools, and the fourth course deals with threats and mitigations. In closing I would like to make clear that this course won't teach you checked lists. We're not going to say, do this and you'll be secure. Rather, what I want you to do is sensitize you to the dynamic nature of the threat landscape. And perhaps realize that designing software to be completely secure when run on any machine is virtually impossible. When you're faced with a software design challenge, I hope this course will have given you ways to think about your situation which will lead you to specific steps that will work to secure your software for the moment. Thanks for your time.
