This course we will explore the foundations of software security. We will consider important software vulnerabilities and attacks that exploit them -- such as buffer overflows, SQL injection, and session hijacking -- and we will consider defenses that prevent or mitigate these attacks, including advanced testing and program analysis techniques. Importantly, we take a "build security in" mentality, considering techniques at each phase of the development cycle that can be used to strengthen the security of software systems. Successful learners in this course typically have completed sophomore/junior-level undergraduate work in a technical field, have some familiarity with programming, ideally in C/C++ and one other "managed" program language (like ML or Java), and have prior exposure to algorithms. Students not familiar with these languages but with others can improve their skills through online web tutorials.
Avoiding Flaws with Principles
Loading...
En provenance du cours de University of Maryland, College Park
Software Security
701 notes
À partir de la leçon
SECURE SOFTWARE DEVELOPMENT
Designing and Building Secure Software
Rencontrer les enseignants
Michael HicksProfessor
Department of Computer Science
[SOUND]
Once we've determined our normal requirements and
our security requirements, we must design the software and we must implement it.
Defects could be introduced in either of these two activities.
Defects in the design are called flaws.
And defects in the implementation are called bugs.
The goal of the design phase from a security perspective is to avoid flaws.
Now, while a lot of security related focus is on
implementation bugs like buffer overruns.
Flaws are equally important.
According to security guru Gary McGraw in his book Software Security,
roughly half of security-relevant software defects are flaws, not bugs.
So getting the design right is extremely important.
What I've just said may make it seem like there's a crisp distinction between
the design and implementation of a piece of software.
But that's not entirely true, rather design and
implementation occur at many different levels of abstraction.
For example, at the highest level we're concerned about a system's main actors.
These might be elements like a web server, a database management system and
a client's browser.
Each running in it's own process and communicating with one another.
The choice of programming language to use or
framework is also a fairly high level design decision.
At the next level down we're concerned with the internal design of each of
these actors.
A web server is going to consist of many different functions and
objects, how should these be organized?
And how do they interact?
This is a question of design.
At the lowest level we must decide how to represent data structures.
How to implement a piece of functionality, for example, with one method or
three and so on.
When someone speaks generically about a software system's design he may be
speaking about any or all of these levels.
When speaking about it's implementation he might also be thinking about the lower
level or maybe the lower two.
However, we believe there is design happening at the lower levels and
the choices made there effect security.
So in speaking about design we mean all three levels, and
which in particular, should be clear from context.
The software design process aims to produce a software architecture according
to good principles and rules.
This is an iterative process.
We first put down our initial design.
And then we perform a risk based analysis of that design.
As a result, we may determine that the design needs to be improved.
And so, we apply our principles and rules and then improve until we are satisfied.
A principle is a high-level design goal with many possible manifestations.
While a rule is a specific practice that is consonant with sound design principles.
Now the difference between these two can be fuzzy,
just as the difference between design and implementation is fuzzy.
For example, there is often a principle underlying specific practices.
Principles may also sometimes overlap.
The software design phase tends to focus on principles for
avoiding flaws and less on rules which are more part of the implementation phase.
We can group our set of software design principles into three categories.
The first category is prevention.
These sorts of principles aim to eliminate software defects entirely.
For example, the Heartbleed bug would have been prevented by using
a type-safe langauge, like Java, which prevents outright buffer overflows.
The second category of principle is mitigation.
These principles aim to reduce the harm from exploitation of unknown defects.
That is, we can assume that some defects will escape our
elimination during the implementation phase.
But if we design our software in the right way, we may make it harder for
an adversary to exploit these defects in a way that's profitable to him.
As an example we could run each browser tab in a separate process.
So that exploitation of one tab does not yield access to
data that is stored in another tab because it is isolated by the process mechanism.
The third category of principle is detection and recovery.
The idea here is to identify and understand and
attack, potentially undoing its damage if we're able to recover.
As an example, we can perform monitoring of the execution of our program.
To try to decide whether an attack has taken place or
might be in the process of taking place.
And we could perform snapshotting of various stages of
our software's execution.
In order to revert to a snapshot if we discover later that an attack has
corrupted our system.
So now, without further ado, here are the core principles we have identified for
constructing secure software.
First, favor simplicity and
in particular use fail-safe defaults and do not expect expert users.
Next, trust with reluctance by employing a small, trusted computing base and
granting a component the least privilege it needs to get its work done.
Ensuring least,
least privilege may involve promoting privacy and compartmentalizing components.
Next, defend in depth.
Avoiding reliance on only one kind of defense.
The word depth also means depth of attention.
By employing community resources, such as hardened code and vetted designs.
Finally, monitor and trace to be able to detect and diagnose breaches.
Our principles are strongly influenced by a set of
principles put forth way back in 1975.
By Jerome Saltzer and Michael Schroeder in their paper,
Protection of Information in Computer Systems.
It's amazing to see how well these principles have kept up.
Despite systems, languages, applications all
being different today compared to what they were in 1975.
Here are the principles suggested in section one of the Saltzer and
Schroder paper.
Where those in green are identified as principles and
those in blue were considered by the authors as relevant.
But imperfect in their application to computer systems.
Comparing our principals to the classic ones, there is substantial overlap.
Some of the classic principles have been regrouped or
renamed and some expanded in scope.
We have added monitoring in support of forensics because successful attacks
are inevitable.
And you need a way to diagnose and improve on past failures.
Saltzer and Schroder may have been also concerned about this, but
in their paper were more focused on prevention.
Finally I have dropped their principle of complete mediation,
that states simply that all security relevent actions.
Must be mediated if policies on them are to be enforced.
I don't think of this as a design principle because all designs that
lack it are insecure by definition.
In that sense, it is a requirement, not a principle.
By comparison, a design could lack all the other principles and still be secure.
But achieving security with such a design would be very difficult and
would be very hard to maintain.
Okay.
Next we will dig into these different design principles, organized by category,
and starting with favor simplicity.
Explorer notre catalogue
Rejoignez-nous gratuitement et obtenez des recommendations, des mises à jour et des offres personnalisées.
Coursera propose un accès universel à la meilleure formation au monde,
en partenariat avec des universités et des organisations du plus haut niveau, pour proposer des cours en ligne.
© 2018 Coursera Inc. Tous droits réservés.
