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.
Threat Modeling, or Architectural Risk Analysis
Loading...
來自 University of Maryland, College Park 的課程
Software Security
660 個評分
從本節課中
SECURE SOFTWARE DEVELOPMENT
Designing and Building Secure Software
與講師見面
Michael HicksProfessor
Department of Computer Science
[SOUND]
To decide how to secure your software,
you have to understand what kind of adversary you're securing it against.
To do so, you should make an explicit threat model for the system.
A threat model defines the adversary's assumed powers in terms of how they
could be used to attack your system.
It's extremely important that this definition characterizes reality.
Otherwise you may needlessly defend against attacks that are unlikely to
happen or you'll fail to defend against those attacks that will.
A threat model is thus critically important because it
makes plain what you are up against.
Even if the idea of an attacker is vague you can undoubtedly do some things to
secure your system.
But you are unlikely to put together a coherent defense.
Making the attacking threat explicit makes it far more likely that you'll have all of
your defenses aligned to a common purpose.
All of this is part of architectural risk analysis.
Which is the process of assessing the risk of a security failure based on
the likelihood and cost of various attacks.
And doing what you can to minimize that risk.
So now let's consider a few example threat models.
The first, and simplest, is that of a network user.
A network user is an anonymous user that can connect to the service via network.
What happens if such a user were malicious, that is, an attacker?
Well, the user could measure the size and timing of requests and
responses to and from the service.
The user could run parallel sessions, for example, masquerading as
multiple users and interleaving their messages in various ways.
The attacker could provide malformed inputs or malformed messages.
And the attacker could drop or send extra messages.
Such an attacker, simply a network user,
can perpetrate many attacks that we have seen so far, including SQL injection,
cross site scripting, cross site request forgery, buffer overruns,
perhaps by using return-oriented programming payloads, and many others.
The second sort of attacker that we'll look at is the snooping user.
This is an internet user on the same network as other users of some service.
For example someone connected to an unencrypted wi-fi network at
a coffee shop.
Such a user has the same capabilities as a network user, but
in addition, can read or measure other's messages.
Intercept, duplicate, and modify those messages.
And as a result, formulate the following attacks.
Such an attacker could hijack another user's session by
reading the session key out of their communications and then using it.
The attacker could also violate privacy by reading unencrypted information that's
exchanged between that user and the service.
The attacker may even be able to learn something from encrypted communications
by inferring properties based on the size or frequency of messages.
Finally the attacker may be able to deny service by, for
example, intercepting messages from a user but then throwing them away,
rather than delivering them to the service as intended.
As a final example threat model, let's consider the co-located user.
This an internet user on the same machine as other other users of some service.
This could happen by having malware installed on a user's machine,
for example.
Such a co-located user can addition.
Such a co-located user can, in addition to all the capabilities we've already seen.
Read or write the user's files, for
example, reading cookies or writing those cookies, and even read memory.
The attacker may be able to snoop key presses and other events.
The attacker could read or write the user's display, for example,
to spoof the users web browser to simulate an encrypted communication,
when in fact none is taking place.
As an example attack, a co-located user can steal a password.
For example, by snooping the key presses as the user types in
their password when logging on to a secure website.
Once you have your threat model defined,
you can work out how you will respond to the threat.
Different threat models will elicit different responses.
For example, when considering a network-only attacker,
which can communicate with your system but
do nothing else, you can be sure that your communications are safe.
And as such, there's no need to encrypt messages.
The adversary can always see his own messages and
by assumption, he cannot see the messages of other users.
This is the sort of threat model that the old telnet remote login
program considered.
It assumed that one user might attempt to masquerade as another user and so
passwords for authentication were required.
But it did not assume that one user might snoop the traffic of another user, and
thereby steal her password.
In some settings, this might be a reasonable assumption, but today,
with wi-fi and mobile networks the standard, it's probably not safe to
assume that attackers cannot observe others' message traffic.
Which gets back to the point that your threat model must match reality to
be useful.
A snooping attacker is a more likely threat.
And in this case, you should use encryption to protect your data.
The encryption could be deployed at the link layer by using encrypted
wi-fi like WPA2.
At the network layer using IPsec, or at the application layer using SSL or
something similar.
Note that you might want to distinguish between an attacker that can snoop
traffic, as opposed to one that can intercept and change traffic.
Encryption may not be sufficient for such an attacker.
Now a co-located attacker is the most powerful threat and
thus the most difficult to defend against.
But such an attacker is real.
Some banks assume that users connecting to their sites are doing so
from machines with malware installed.
As such, the attacker who controls the malware.
Can use the user's id and
password, perhaps by capturing keystrokes that the user is typing.
One way to defend against such snooping is to provide users with
a separate device that is involved in the authentication process, but is not
connected to the computer, and therefore not under the purview of the malware.
We assume that this device is not compromised,
even though the computer might be.
We'll look more closely at authentication troubles a bit later.
Now, just to, just to reiterate.
A poorly chosen model, will result in poor security.
In particular, assumptions you make on what an attacker can not do.
Are potential weaknesses if in fact the attacker does not
have the assumed limitation.
As I mentioned a moment ago, assuming that attackers cannot snoop messages on
a network is probably a bad idea.
But beyond this, there are other poor assumptions that you could make.
For example, people mistakenly think that cryptography hides communications as
if they were being carried by a pipe that completely hides its contents.
In fact, the attacker can still see individual messages, and their metadata
such as the source and destination, and features like message length.
Prior work has shown that this information is sufficient to
identify user interactions that produce particular messages, and
this can result in lost privacy.
People also sometimes fail to consider that adversaries can
measure the timing and other features of a communication.
In some cases such measurements are sufficient to infer secret
information like cryptographic keys.
Given these failures,
what steps should you take to ensure your threat model is realistic?
First, you can use other threat models as a starting point,
when their systems are similar to yours.
Second, you can stay informed about the state of the art in
cybersecurity attacks and attack patterns.
And you can then apply your knowledge to the system you are building
to assess whether new attacks are a real threat.
Finally, allow your threat model to evolve as you design your system.
Challenge assumptions in your design.
What capabilities must an attacker have to defeat defense mechanisms that
you're thinking of using?
How likely is an attacker to have these capabilities?
How will you know that?
And what would be the cost of a failure?
You may decide that a strong attacker is unlikely, but that the consequences
are high enough that you should defend against that attacker anyway.
And this is the essence of risk assessment.
Taking into account the potential costs of building a system,
the cost of a successful breach, and weighing the likelihood of each.
