secure software development rasool jalili & m.s. dousti dept. of computer engineering fall 2010

38
Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Upload: gilbert-mills

Post on 25-Dec-2015

217 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Secure Software Development

Rasool Jalili & M.S. Dousti

Dept. of Computer Engineering

Fall 2010

Page 2: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 2Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

In

• Name: Secure Software Development• Instructors: Rasool Jalili & M.S. Dousti• Prerequisites: Advanced Programming (40244), Software Engineering

(40474).– Suggested but NOT necessary: Database Design (40384).– Co-requisites: Data & Network Security (40442).

• Course Objectives: Upon completion of this course, students will be able to:1. Understand the basics of secure programming.2. Understand the most frequent programming errors leading to software vulnerabilities.3. Identify and analyze security problems in software.4. Understand and protect against security threats and software vulnerabilities.5. Effectively apply their knowledge to the construction of secure software systems.6. Make effective use of tools to assess software security.7. Understand the low-level features of the CPU, OS, and software.8. Ability to reverse engineer a given piece of software.

•  • Evaluation Methods (tentative):

1. Assignments: 40%2. Project: 30%3. Exam: 30% 

In the name of God ,the Compassionate, The Merciful

Page 3: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 3Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

– 1 Software Security– 2 Reverse Engineering– 3 Secure Coding

• References[1] Gary McGraw, Software Security: Building Security In.

Addison Wesley Professional, 2006.[2] Eldad Eilam, Reversing: Secrets of Reverse

Engineering. Wiley Publishing, Inc., 2005.[3] http://www.reversing.be/[4] http://www.tuts4you.com/[5] http://crackmes.de/[6] Michael Howard, David LeBlanc, and John Viega, 24

Deadly Sins of Software Security: Programming Flaws and How to Fix Them. McGraw Hill, 2010.

•  

Course Contents & Refs

Page 4: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 4Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

• Software: easy to criticize and hard to do.– The bigger the software, the more that is true.– Example: the more you say, the more you can be

criticized.– Software is as prone to mis-interpretation as is our

language!– Many things are now depends on software; life

without software in near future!

• Breaking something vs design and build an un-breakable

thing.• If a product does not have opponents, it does

not have security requirement.

Motivation

Page 5: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 5Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

• SW Security: the idea of engineering SW to continue functioning correctly under malicious attack.

– New?– Why important: – Received attention due to in-effectivity of reactive net-based security approaches such as FWs.

• Design flaws and implementation bugs Unacceptable security risks.

– Any apparently safe program, can shelter security holes.

• Network security market (estimation of $45B in 2003; Now:

….) + • Increase in reported incidents and increase in cyber-

crime Current solutions to security does not work clearly.

• The money spent for network security is not solving the security problems we MUST build better SW.

The Security Problem-1

Page 6: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 6Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

• A central & critical aspect of the CS problem, is the SW problem.

• SW implementations bugs & design flaws, promise to be with us for years.

• Malicious intruders can attack into systems by exploiting SW defects.

• Internet-based SWs are commonly and too easily exploited targets.

• Ever-increasing complexity and extensibility of SWs is just adding fuel to the fire.

• By any measure, security holes in SW are common and growing increasingly.

The Security Problem-2

Page 7: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 7Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

• Security of computer systems and networks quality and security of SW running on the connected machines.

• Internet-based CUSTOM applications using Web are a common target for attack!!

• More than half of the vulnerabilities are due to buffer overruns! an elementary class of bugs.

• Growing rate of SW vulnerabilities from 200 in 1995 to ~4000 in 2004.

Page 8: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 8Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

• SW security is about understanding SW produced security risks and how to manage them.

• Good SW security practice:– Thinking about security early in SW lifecycle,– Understanding the common problems (language-

based flaws), – designing for security,– Subjecting all SW artifacts to deep risk analysis and

test.

• As SW is everywhere, and business and society depends heavily on SW, and it is networked SW security is a necessity, not a luxury issue.

What SW Security is?

Page 9: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 9Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

• Why SW security is a bigger problem now:1- Connectivity: Growing connectivity increased both the number

of attacks and ease of doing attacks.

– Things that used to happen offline now happen online.– Systems are become vulnerable to SW-based attacks

from distance sources.– Lunching automated attacks are now easy.– More SW systems exist to be attacked.– Attackers are now in your virtual doorstep.– Large enterprises have caught two bugs!:

• Web Services• Service Oriented Architecture (SOA)

– Legacy applications never intended to be internetworked, are becoming internetworked and published as service.

The Trinity of Trouble

Page 10: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 10Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

2- Extensibility: Degree to which systems have become extensible.

• Systems which accept updates or extensions, called mobile code in order to enhance and evolve the system functionality– E.g. the plug-in architecture of Web-browsers to

support viewing new file types.

• OSs support DLL device drivers and modules!• Extensibility of applications through scripting,

components, and applets; which is considered attractive from the economic point of view.

• Unfortunately, this nature harden to prevent SW vulnerabilities from slipping in as unwanted extension!

The Trinity of Trouble-2

Page 11: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 11Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

3- Complexity: uncontrolled growth of modern SW systems in terms of size and complexity.

– Our dependence on the proper functioning of the kernel!– The kernel itself consists of 10mls lines of code.– When systems becomes so large, bugs cannot be avoided.– Win XP is 40mls.– The defect rate tends to go up as the square rate of the code size.– Use of unsafe programming languages increase complexity.– In theory we can analyze and prove that a small program, but for ….– The number of lines of codes being developed are being increased, daily.– MORE LINES, MORE BUGS– Sometimes the code base grows while the code base appears to be small!

• Large base of code (.NET and JUEE platforms) underneath ur application.

– This get worst when u rely on:• Identity mngmnt & provisioning• XML• Application Servers• Databases

The Trinity of Trouble-3

Page 12: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 12Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

• SW security, is the process of designing, building, and testing software for security.

• The heart of computer security by

identifying and erasing problems in the software itself.

• SW security attempts to build software that can survive with attack proactively.

Security Problems in Software

Page 13: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 13Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

• Defect: Both implementation vulnerabilities and design vulnerabilities are defects.

• may lie inactive in software for years only to appear in a fielded system with major consequences.

Bugs and Flaws and Defects

Page 14: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 14Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

• Bug: A bug is an implementation-level software problem. Bugs may exist in code but never be executed.

• can be easily discovered and remedied. • Tools are effective in detecting some implementation

bugs, buffer overflow, simple race conditions.• almost 45% of all software security problems reported

to CERT were caused by buffer overflows. char x[12]; x[12] = '\0';array references in C start with 0!• Two main flavors of BO: those with stack-allocated

buffers and those with heap-allocated buffers. • Overflowing a stack-allocated buffer is the most

common.• using gets() to get (unbounded) input

void main() { char buf[1024]; gets(buf); }

Bug

Page 15: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 15Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

• A problem at a deeper level.• A flaw is certainly instantiated in software code,

but it is also present (or absent!) at the design level.

• No automated tech. to detect design-level flaws • manual risk-analysis processes may identify

flaws.• In practice, bugs and flaws are 50/50. • Removing bugs through code review will solve

only about half of the problem.• Microsoft reported > 50% of the problems the

company has uncovered during its ongoing security push are architectural in nature.

Flaw

Page 16: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 16Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

• Risk: Flaws and bugs lead to risk.

• Risks are not failures.

• Risks capture the probability that a flaw or a bug will impact the purpose of the software.

• Risk = probability * impact

Risk

Page 17: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 17Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

• Determining whether a defect is a flaw or a bug is difficult.• Security defects in software systems range from

– local implementation errors (gets) to – Inter-procedural interface errors (race condition) to – much higher design-level mistakes (error-handling).

• A broad range based on:– how much code must be considered to understand the

vulnerability, – how much detail regarding the execution environment must be

known to understand the vulnerability, and – whether a design-level description is best for determining a given

vulnerability is present

• Midrange vulnerabilities involve interactions among more than one location in code.

• Design-level vulnerabilities: – requires great expertise.– not only hard to find but particularly hard to find automatically.

The Range of Defects

Page 18: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 18Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

• The idea that software is a major problem in computer security is fairly new.

• “software security” is preferred over “application security”:

• application security: different things to different people.

• protection of software after it's already built!!

• The most effective way to protect software? SW or App Security?

Application Security?

Page 19: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 19Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

• software security is building secure software:• designing software to be secure; • making sure that software is secure; • and educating

– software developers, – architects, and – users

about how to build security in.

Application Security-2

Page 20: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 20Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

– is about protecting software and the systems that software runs, only after development.

– Critical Issues:• sandboxing code (as Java Virtual Machine), • protecting against malicious code, • locking down executables, • monitoring programs as they run (especially

their input), • enforcing the software-use policy with

technology, and • dealing with extensible systems

Application Security-3

Page 21: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 21Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

• Follows from a network-centric approach to security; using standard approaches, such as "penetrate and patch" and input filtering (blocking malicious input), and

• generally providing value in a reactive way.• Based on finding and fixing known security problems

after they've been exploited in fielded systems.• E.g. stopping buffer overflow attacks by observing

HTTP traffic as it arrives over port 80!• Focus on "application" code ignores the bigger picture.

“software security.”• An application development project: involves systems

people, network people, the architecture group, and a whole bevy of application developers; NOT Security People!

Application Security-4

Page 22: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 22Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

• Application security testing products as a solution for insecure software!

• May help to diagnose and find the problem, but no help to fix it.

• treat software applications as "black boxes”.• too simple.• finding and removing bugs once the code is

done.• Attackers take software apart, determine

how it works, and make it misbehave by doing what users are not supposed to do!!

Application Security Testing Tools

Page 23: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 23Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

• Application security testing tools are "badness-ometers,“• Major weakness with application security testing tools is their

focus on input over port 80.• However;1- input to modern applications: SSL, environment variables,

outside libraries, distributed components, and so on.2 Beyond program input, • architectural soundness, • data security, • access control,….• The only good use for application security tools is testing

commercial off-the-shelf software.

• Fixing the problems they expose requires building better software!

Badness-ometers

Page 24: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 24Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

• In most corporations, security is under the hands of the infrastructure people who set up and maintain firewalls, IDSs, and AV (all reactive tech.)

• these people are operators, not builders.• their approach is to move standard security

techniques "down" to the desktop and application levels.

• In the short run, we clearly/urgently must make progress on both fronts.

• In the long run, we must figure out ways to build easier-to-defend code. Software security is about helping builders do a better job so that operators end up with an easier job.

Software Security and Operations

Page 25: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 25Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

• Security Has Come a Long Way…– Security was the exclusive domain of guns, dogs, and concrete not too

many years ago.– is the Information Age, all things security have changed radically.– Yet computer security remains a relative newcomer.– computer security confronted its first major shift: The trusted machine was

connected to untrusted machines, not necessarily under the control of operations people

• Security Has not Come Very Far …– The notion of "defending the perimeter," adapted from the physical

security of castles and fortresses, requires the existence of a perimeter.– Computer security has come to rely too heavily on a perimeter defense

mentality, and the attackers have already changed their invasion routes. – The perimeter image makes sense if you take the view that the trusted

inside machines need to be protected from the untrusted machines outside.

– Problem: perimeter is outdated, and too simple to work. – Today's Web-based systems are highly distributed and involve explicit

connection with machines that having different degrees of trust. – Reactive technologies, such as firewalls that attempt to protect "the

system" from the "outside," – don't work in all cases!

Secutiry vs SW

Page 26: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 26Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

• SWS is an ongoing activity; requires a cultural shift.

• no magic tool or just-add-water process that will result in secure software; takes work.

• Good news: any organization that is developing software, regardless of its methodology (if any!), can make straightforward, positive progress.

• The three pillars of software security are:– applied risk management, – software security touchpoints, and – knowledge

• applying the three pillars in a gradual, evolutionary manner can result in a reasonable, cost-effective software security program.

Solving the Problem: The Three Pillars

Page 27: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 27Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

• No discussion about security (and SWS) is complete without considering risk management.

• a distinction between – the application of risk analysis at the architectural

level (threat modeling or security design analysis) and – the notion of tracking and mitigating risk as a full

lifecycle activity.

• an overall approach to risk management as a philosophy is also important.

• Risk Management Framework (RMF).• The basic idea is to identify, rank, track, and

understand software security risk as the touchpoints are applied throughout the SDLC.

Pillar I: Applied Risk Management

Page 28: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 28Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

• SWS is not security software.• Adding features such as SSL does not present a

complete solution to the security problem. • SWS is a system-wide issue that takes into account both

security mechanisms (sa access control) and design for security (sa robust design that makes software attacks difficult).

• security is an evolving property of a software system – as you can't test quality into a piece of software, you can't

spray paint security features onto a design and expect it to become secure

– need to build security in.

• Most approaches in practice today:– training for developers, testers, and architects; – analysis and auditing of software artifacts; and – security engineering.

Pillar II: Software Security Touchpoints

Page 29: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 29Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

SWS

Page 30: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 30Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

• These best practices first appeared as a set in 2004 in IEEE Security & Privacy magazine [McGraw 2004].

• Since then, they have been adopted by the U.S. government in the National Cyber Security Task Force report [Davis et al. 2004], by Cigital, by the U.S. Department of Homeland Security, and by Ernst and Young.

• can be applied regardless of the base software process.• as diverse as the waterfall, (RUP), (XP), Agile, and any number

of other processes involve the creation of a common set of software artifacts (the most common artifact being code).

• you can create your own Secure Development Lifecycle (SDL) by adapting your existing SDLC to include the touchpoints.

• You already know how to build software; what you may need to learn is how to build secure software.

Page 31: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 31Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

• Bill Gates memo of January 2002 and the importance of building secure software to the future of Microsoft.

• Microsoft has spent more than $300 million (and more than 2000 worker days) on its SWS.

• On the people front, Microsoft is training every developer, tester, and program manager in basic techniques of building secure products.

• Microsoft's development process has been enhanced to make security a critical factor in design, coding, and testing of every product.

• Risk analysis, code review, and security testing all have their place in the new process.

Microsoft's Trustworthy Computing Initiative

Page 32: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 32Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

• From: Bill Gates• Sent: Tuesday, January 15, 2002 2:22 PM• To: Microsoft and Subsidiaries: All FTE• Subject: Trustworthy computing• Every few years I have sent out a memo talking about the highest priority for Microsoft. Two years ago, it was the kickoff of our .NET strategy. Before that, it was several memos about the importance of the Internet to our future

and the ways we could make the Internet truly useful for people. Over the last year it has become clear that ensuring .NET as a platform for Trustworthy Computing is more important than any other part of our work. If we don't do this, people simply won't be willingor ableto take advantage of all the other great work we do. Trustworthy Computing is the highest priority for all the work we are doing. We must lead the industry to a whole new level of Trustworthiness in computing.

• When we started work on Microsoft .NET more than two years ago, we set a new direction for the companyand articulated a new way to think about our software. Rather than developing standalone applications and Web sites, today we're moving towards smart clients with rich user interfaces interacting with Web services. We're driving the XML Web services standards so that systems from all vendors can share information, while working to make Windows the best client and server for this new era.

• There is a lot of excitement about what this architecture makes possible. It allows the dreams about e-business that have been hyped over the last few years to become a reality. It enables people to collaborate in new ways, including how they read, communicate, share annotations, analyze information and meet.

• However, even more important than any of these new capabilities is the fact that it is designed from the ground up to deliver Trustworthy Computing. What I mean by this is that customers will always be able to rely on these

systems to be available and to secure their information. Trustworthy Computing is computing that is as available, reliable and secure as electricity, water services and telephony.

• Today, in the developed world, we do not worry about electricity and water services being available. With telephony, we rely both on its availability and its security for conducting highly confidential business transactions without worrying that information about who we call or what we say will be compromised. Computing falls well short of this, ranging from the individual user who isn't willing to add a new application because it might destabilize their system, to a corporation that moves slowly to embrace e-business because today's platforms don't make the grade.

• The events of last yearf rom September's terrorist attacks to a number of malicious and highly publicized computer virusesreminded every one of us how important it is to ensure the integrity and security of our critical infrastructure, whether it's the airlines or computer systems.

• Computing is already an important part of many people's lives. Within ten years, it will be an integral and indispensable part of almost everything we do. Microsoft and the computer industry will only succeed in that world if CIOs, consumers and everyone else see that Microsoft has created a platform for Trustworthy Computing.

• Every week there are reports of newly discovered security problems in all kinds of software, from individual applications and services to Windows, Linux, Unix and other platforms. We have done a great job of having teams work around the clock to deliver security fixes for any problems that arise. Our responsiveness has been unmatchedbut as an industry leader we can and must do better. Our new design approaches need to dramatically reduce the number of such issues that come up in the software that Microsoft, its partners and its customers create. We need to make it automatic for customers to get the benefits of these fixes. Eventually, our software should be so fundamentally secure that customers never even worry about it.

• No Trustworthy Computing platform exists today. It is only in the context of the basic redesign we have done around .NET that we can achieve this. The key design decisions we made around .NET include the advances we need to deliver on this vision. Visual Studio .NET is the first multi-language tool that is optimized for the creation of secure code, so it is a key foundation element.

• I've spent the past few months working with Craig Mundie's group and others across the company to define what achieving Trustworthy Computing will entail, and to focus our efforts on building trust into every one of our products and services. Key aspects include:

• Availability: Our products should always be available when our customers need them. System outages should become a thing of the past because of a software architecture that supports redundancy and automatic recovery. Self-management should allow for service resumption without user intervention in almost every case.

• Security: The data our software and services store on behalf of our customers should be protected from harm and used or modified only in appropriate ways. Security models should be easy for developers to understand and build into their applications.

• Privacy: Users should be in control of how their data is used. Policies for information use should be clear to the user. Users should be in control of when and if they receive information to make best use of their time. It should be easy for users to specify appropriate use of their information including controlling the use of email they send.

• Trustworthiness is a much broader concept than security, and winning our customers' trust involves more than just fixing bugs and achieving "five-nines" availability. It's a fundamental challenge that spans the entire computing ecosystem, from individual chips all the way to global Internet services. It's about smart software, services and industry-wide cooperation.

• There are many changes Microsoft needs to make as a company to ensure and keep our customers' trust at every levelfrom the way we develop software, to our support efforts, to our operational and business practices. As software has become ever more complex, interdependent and interconnected, our reputation as a company has in turn become more vulnerable. Flaws in a single Microsoft product, service or policy not only affect the quality of our platform and services overall, but also our customers' view of us as a company.

• In recent months, we've stepped up programs and services that help us create better software and increase security for our customers. Last fall, we launched the Strategic Technology Protection Program, making software like IIS and Windows .NET Server secure by default, and educating our customers on how to getand staysecure. The error-reporting features built into Office XP and Windows XP are giving us a clear view of how to raise the level of reliability. The Office team is focused on training and processes that will anticipate and prevent security problems. In December, the Visual Studio .NET team conducted a comprehensive review of every aspect of their product for potential security issues. We will be conducting similarly intensive reviews in the Windows division and throughout the company in the coming months.

• At the same time, we're in the process of training all our developers in the latest secure coding techniques. We've also published books like Writing Secure Code, by Michael Howard and David LeBlanc, which gives all developers the tools they need to build secure software from the ground up. In addition, we must have even more highly trained sales, service and support people, along with offerings such as security assessments and broad security solutions. I encourage everyone at Microsoft to look at what we've done so far and think about how they can contribute.

• But we need to go much further.• In the past, we've made our software and services more compelling for users by adding new features and functionality, and by making our platform richly extensible. We've done a terrific job at that, but all those great features

won't matter unless customers trust our software. So now, when we face a choice between adding features and resolving security issues, we need to choose security. Our products should emphasize security right out of the box, and we must constantly refine and improve that security as threats evolve. A good example of this is the changes we made in Outlook to avoid email borne viruses. If we discover a risk that a feature could compromise someone's privacy, that problem gets solved first. If there is any way we can better protect important data and minimize downtime, we should focus on this. These principles should apply at every stage of the development cycle of every kind of software we create, from operating systems and desktop applications to global Web services.

• Going forward, we must develop technologies and policies that help businesses better manage ever larger networks of PCs, servers and other intelligent devices, knowing that their critical business systems are safe from harm. Systems will have to become self-managing and inherently resilient. We need to prepare now for the kind of software that will make this happen, and we must be the kind of company that people can rely on to deliver it.

• This priority touches on all the software work we do. By delivering on Trustworthy Computing, customers will get dramatically more value out of our advances than they have in the past. The challenge here is one that Microsoft is uniquely suited to solve.

Bill’s Note

Page 33: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 33Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

• One of the critical challenges facing software security is the lack of experienced practitioners

• knowledge management and training play a central role. • Pillar III involves gathering, encapsulating, and sharing security

knowledge that can be used to provide a solid foundation for software security practices.

• Software security knowledge can be organized into seven knowledge catalogs (principles, guidelines, rules, vulnerabilities, exploits, attack patterns, and historical risks)

• grouped into three knowledge categories (prescriptive knowledge, diagnostic knowledge, and historical knowledge).

• can be applied at various stages throughout the entire SDLC.• One effective way to apply such knowledge is through the use

of software security touchpoints. Figure 1-12.• During the Windows security push in February and March 2002,

Microsoft provided basic awareness training to all of its developers.

Pillar III: Knowledge

Page 34: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 34Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

رکن 3: دانش

مقدمه و آشنایی با اصول طراحی امن

آشنایی با معماری ریزپردانده و زبان اسمبلی

آشنایی با خطاهای مهلک کد نویسی

رمز نگاری و کاربرد آن در توسعة نرم افزار امن

نیاز به امنیت در نرم افزارامنیت نرم افزار، امنیت سیستم

امنیت و نقش آن در فرآیند تولید نرم افزار

102 از 34

Page 35: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 35Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

• Designers of modern systems must take security into account proactively.

• Bad software lies at the heart of a majority of computer security problems.

• Software defects come in two flavors design-level flaws and implementation bugs.

• To address both kinds of defects, we must build better software and design more secure systems from the ground up.

• It is much cheaper to prevent than to repair helps to justify investment up front.

• An the end, prevention technology and assurance best practices may be the only way to go.

• If we are to build systems that can be properly operated, we must involve the builders of systems in security. This starts with education.

• Don't forget that software security is not just about building security functionality and integrating security features! Coders are likely to ask, "If I use [this API], is it good enough?

• Good Question: “What attacks would have serious impact and are worth avoiding for this module?"

The Rise of Security Engineering

Page 36: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 36Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

• the only way to begin to secure our computing infrastructure is to enlist everyone:– Builders must practice security engineering, – Operations people must continue to architect reasonable

networks, defend them, and keep them up.– Administrators must understand the distributed nature

of modern systems and begin to practice the principle of least privilege.

– Users must understand that software can be secure so that they can take their business to software providers who share their values.

– Executives must understand how early investment in security design.

• The most important people to enlist for near-term progress in computer security are the builders.

Software Security Is Everyone's Job

Page 37: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 37Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

2

Page 38: Secure Software Development Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

Software Security 38Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010

رکن 2:

نقاط

تماس

مقدمه و آشنایی با اصول طراحی امن

آشنایی با معماری ریزپردانده و زبان اسمبلی

آشنایی با خطاهای مهلک کد نویسی

رمز نگاری و کاربرد آن در توسعة نرم افزار امن

نیاز به امنیت در نرم افزارامنیت نرم افزار، امنیت سیستم

امنیت و نقش آن در فرآیند تولید نرم افزار

102 از 38