Skip to content

Commit 0a312c5

Browse files
authored
Merge pull request #26 from SystemsApproach/llp
CIA triad
2 parents 500b8ed + a7d59be commit 0a312c5

File tree

1 file changed

+57
-54
lines changed

1 file changed

+57
-54
lines changed

principles.rst

Lines changed: 57 additions & 54 deletions
Original file line numberDiff line numberDiff line change
@@ -16,16 +16,16 @@ principles that can be applied to help us meet them.
1616
2.1 Security Requirements
1717
----------------------------
1818

19-
The first requirement that comes to mind when thinking about sending
20-
data across a shared network is likely to be *confidentiality*. As
21-
noted in Chapter 1, there are many ways that an adversary might gain
22-
access to data in transit through a network. Confidentiality is the
23-
ability to prevent data from being read by anyone other than its
24-
intended recipient. This, for example, is what is required to prevent
25-
your credit card details being exposed when you enter then on a
26-
website.
27-
28-
Related to the confidentiality of data is *traffic
19+
The first major requirement that comes to mind when thinking about
20+
sending data across a shared network is likely to be
21+
*confidentiality*. As noted in Chapter 1, there are many ways that an
22+
adversary might gain access to data in transit through a
23+
network. Confidentiality is the ability to prevent data from being
24+
read by anyone other than its intended recipient. This, for example,
25+
is what is required to prevent your credit card details being exposed
26+
when you enter then on a website.
27+
28+
Closely related to the confidentiality of data is *traffic
2929
confidentiality*. This is the idea that we don't want an adversary to
3030
be able to determine where or to whom we are sending traffic, or in
3131
what quantity. This presents some distinct challenges from data
@@ -34,50 +34,53 @@ but they generally must look at packet headers, which contain
3434
destination information, to determine where to
3535
send traffic.
3636

37-
An equally important requirement in many cases is
38-
*authentication*. This is the ability to verify that an item of data
39-
was sent by the entity that claimed to have sent it. In the example of
40-
e-commerce, this is what allows us to know we are connected to, say,
41-
the website of the vendor we wish to patronize and not handing over
42-
our credit card to some impostor.
43-
44-
Closely related to authentication is *integrity*. It is important not only that
45-
we know who we are talking to, but that we can verify
46-
that the data sent across our connection has not been modified by some
47-
adversary in transit.
48-
49-
The preceding requirements also suggest that we must have a concept of
50-
*identity*. That is, we need a system by which the entities involved
51-
in communication, often called *principals*, can be securely
52-
identified. As we discuss later, this problem is harder to solve
53-
than it might first appear. How can we know that a website we are
54-
communicating with actually represents the business with whom we wish
55-
to communicate? Or how does a banking system know that the person
56-
behind a particular request is actually the account holder?
57-
58-
Just as we are concerned that an adversary might access our data in
59-
transit to eavesdrop on or modify it, we also need to be concerned
60-
about *replay attacks* in which data is captured and then
61-
retransmitted at some later time. For example, we would want to
62-
protect against an attack in which an item added to a shopping cart
63-
was repeatedly added again by an attacker. Thus it is a common
64-
requirement to have some form of *replay prevention*.
65-
66-
A common requirement in computer system security is *access control*:
67-
the ability to limit who has access to a system and what operations
68-
they may perform on it. This applies not only to end systems but to
69-
network devices such as routers and infrastructure components such
70-
as name servers.
71-
72-
Finally, it is important that networks and the systems attached to
73-
them can be protected against *denial-of-service* (DoS) attacks. The
74-
Morris Worm was an early example of an unintentional DoS attack: as
75-
the worm spread to more and more computers, and reinfected computers
76-
on which it was already present, the resources consumed by the worm
77-
rendered those computers unable to function. Networks provide a means
78-
by which data can be amplified by replication, allowing large volumes
79-
of traffic to be sent to the target of a DoS attack; thus it has
80-
become necessary to develop means to mitigate such attacks.
37+
The second major requirement is *integrity*, which means having
38+
confidence that the information we're receiving is trustworthy, and
39+
for example, has not been modified by some adversary while in
40+
transit. Assuring integrity is multi-faceted, involving far more than
41+
"in transit" adversaries.
42+
43+
For example, we need to be able to verify that an item of data was
44+
sent by the entity that claimed to have sent it. This is called
45+
*authentication*, and in the example of e-commerce, this is what
46+
allows us to know we are connected to, say, the website of the vendor
47+
we wish to patronize and not handing over our credit card to some
48+
impostor.
49+
50+
To authenticate a party we're communicating with, in turn, suggests
51+
that we must have a concept of *identity*. That is, we need a system
52+
by which the entities involved in communication, often called
53+
*principals*, can be securely identified. As we discuss later, this
54+
problem is harder to solve than it might first appear. How can we know
55+
that a website we are communicating with actually represents the
56+
business with whom we wish to communicate? Or how does a banking
57+
system know that the person behind a particular request is actually
58+
the account holder?
59+
60+
Message integrity means not only being concerned that an adversary might
61+
modify our data in transit, but we also need to be concerned about
62+
*replay attacks*, in which data is captured and then retransmitted at
63+
some later time. For example, we would want to protect against an
64+
attack in which an item added to a shopping cart was repeatedly added
65+
again by an attacker. Thus it is a common requirement to have some
66+
form of *replay prevention*.
67+
68+
Another related requirement in computer system security is *access
69+
control*, the ability to limit who has access to a system and what
70+
operations they may perform on it. This applies not only to end
71+
systems but to network devices such as routers and infrastructure
72+
components such as name servers.
73+
74+
The final major requirement is *availability*, which is usually taken
75+
to mean that networks and the systems attached to them must be
76+
protected against *denial-of-service* (DoS) attacks. The Morris Worm
77+
was an early example of an unintentional DoS attack: as the worm
78+
spread to more and more computers, and reinfected computers on which
79+
it was already present, the resources consumed by the worm rendered
80+
those computers unable to function. Networks provide a means by which
81+
data can be amplified by replication, allowing large volumes of
82+
traffic to be sent to the target of a DoS attack; thus it has become
83+
necessary to develop means to mitigate such attacks.
8184

8285
2.2 Broader System Requirements
8386
-------------------------------------

0 commit comments

Comments
 (0)