2014-May-21
AC in pop culture:
Pitbull fans must exist but it’s impossible to find an explicit example.
2014-May-18
Linux tip: Install Helvetica and/or Helvetica Neue on your computer and some
websites will look better
2014-May-15
From a ratemyprofessors.com review of Mike Newman’s teaching:
‘Clearly LOVES math, makes tons of jokes; ie, someone asks how many questions
on the midterm and he replies “well… it’s an integer number”.’
2014-Jan-7
The following is a document I wrote in mid 2008.
I haven’t edited it, although I was tempted to since parts of it sound a bit
strange now.
Rather than improve on it, I’ll just clarify what it was attempting to say:
The connections between devices and/or agents have a finite set of security
properties which determine the options available to secure the assets involved.
These properties can be simply classified, providing a way to systematically
explore the space of security configurations.
I felt that the ideas in the document were a good summary of some facts about
computer security.
The culmination of my independent studies in computer security involved the
development of a system of detailed original models and axioms to describe
every aspect of the security state of digital systems by generalizing all the
disparate case-by-case knowledge I had compiled. I had heard of no similar
methods or structure from anywhere else because the vast majority of IT
security knowledge is in applied form for various technical domains. Indeed,
when work on this system concluded, I no longer needed to continue learning to
increase my understanding of computer security. While the concepts used apply
to security of all domains, it the models are optimized for computerized
resources. A summary of it follows.
The fundamental principles of security are authentication and authorization. An
asset is secure to the degree that the owner is willing to make it if these
properties are properly configured to function at that degree (or higher) and
understood by its owner to function at that degree (or lower). Security is
needed when access is to the asset is enabled. In the context of digital
security, in which the asset is a digital substance (hardware or software),
access is generally arbitrary usage, reading, and/or writing.
If one is to determine the optimal expenditure of funds on security, one must
first find the optimal system of security, on a per-asset or per-asset-group
basis. The asset involved will have one or more points of access
(security/trust chains, or simply chains). Each chain will have one or more
links, with the distinction between links depending on the granularity of the
analysis. The conceptual chain will “connect” the potential user to the asset
in question (with no regard for physical circumstances). Each link of the chain
involves an authentication/authorization process of which there are three
primary orders.
The first order is preventive, and akin to the wall and gate around a medieval
castle. This order provides access control at the site of the access in full
context of the asset’s execution environment. This is also the order at work in
file-access Access Control Lists (ACLs) in an operating system. The second is
pre-preventive, and akin to a security check before boarding an airplane. This
order is used by an intermediate system before the request arrives at the
destination, but strives to serve the same purpose as first order security. It
may be cheaper to implement, especially if one specialized device can be used
to serve many others. The principal drawback is that it must be aware of the
full system state of the destination device (asset) in order to rule on the
safety of the incoming request. This is often not the case in practice, but the
benefit in economy may outweigh the cost. The other main drawback to second
order security procedures is that even if enough information about the asset is
known at the time of access to make a ruling, there may not be enough to
“sanitize” the incoming request, or provide an effective, safe alternative to
the requested access, and may instead simply drop it; this would be unintended
in some circumstances. The third order, also called policy, involves a time
delay, the need for evidence, the tracking of identity, the requirement for
effective deterrence, a willing judiciary, and a cost-effective punishment
system. The costs involved with the use of this method in the digital world
dictate that its use tends to be primarily as a backup, although there have
been questions about the merits of its existence at all.
Each link in the security/trust chain will either provide access control on one
of the three levels, involve trusting an uncontrolled third party to determine
the security of the access, or do neither. In practical modeling, links of the
final option would likely only be included to illustrate failures of security.
All security systems in use in digital environments can be described using this
method. A web of chains can be used to illustrate trust relationships between
end devices and the role they play in the security chain of others. A potential
attacker would be presumed to use what would be perceived by him to be the
“weakest” chain, or sequence of connections of chains, that leads him to the
asset. Note that what is often derided as “security through obscurity” is often
quite secure indeed. For example, a file on an Internet-connected Web server
that is only meant to be accessible by a specific individual could possibly be
protected in a number of ways. Two of these are storing the file in a
password-protected folder, or putting the file in a hard-to-guess directory.
The latter is considered “security through obscurity”, but requires almost the
exact same security procedures to access as the former (except for the traffic
patterns created, types and permissions of log files stored, etc., none of
which are necessarily risks for a given situation). Ultimately, all chains from
the user to the asset need only one strong link, but combinations of the
different kinds are used in different domains. Possible examples of the system
in practice are numerous, a few follow (with thorough background).
An example of a simplistic security chain model illustrating the typical
protection used against XSS (cross-site scripting) attacks involves three
entities: the server hosting the vulnerable Web page, the attacker, and the
victim user. In a persistent XSS attack, the chain begins with a second order
link in between the attacker and the server. The server will inspect the input
sent to determine whether or not it will violate the user’s presumed (and
usually generalized) security policy. In the case of JavaScript malware, the
server checks to make sure none of the input could be executed (in the [likely]
context of the eventual Web page it will be rendered in) and either encodes it
to prevent this happening, or cancels the request if the check fails. Note that
this process may have to be looped to prevent some encoding bugs, until the
result is safe. The user then requests the Web page that the attacker’s input
is found in (the reason for the visit may be the result of the function of
another chain). Generally, the chain link here will be one of trust between the
user and server: the user trusts that the server (uncontrolled third party)
will not serve anything dangerous. If dynamic content does get served and
attempts to connect to a remote host other than the original server (subject to
a few loopholes and exceptions), the connection will be blocked. This is called
the Same Origin Policy (SOP). This requires the removal of functionality (and
the need for chains of security) for controlling this kind of execution access,
which could potentially be legitimate. However, the check involved in comparing
the server and the remote host is done using domain names. This causes problems
when the SOP (showing second-order characteristics) presumes it knows the way
in which requests are sent in the user’s network, and is known to have
weaknesses. The user’s understanding of his security state is fundamentally to
blame in this case. Note that the integrity of the network all devices are on
and other aspects of the scenario represent the need for additional security
chains, but are ignored as perfectly secure in this example.
The final link in the most common scenario for persistent XSS defense can be
the user’s disallowing of JavaScript altogether on a per-domain basis.
Essentially similar to the SOP, this involves overriding the trust in the
domain from the previous link, and in effect closes access (removes the need
for a security chain altogether, but at the cost of functionality) to
JavaScript-enabled Web sites that are not on the domain-allow list. A
non-persistent XSS would involve the user trusting or not trusting the
attacker’s sent link based on the information available (trust link) or using
security of some other kind. Note that links containing JavaScript in the query
string or post body may be legitimate. The link here would be one of either
possible first order security (if the script affects only client-side
functions) or trust (if the script accesses the server, where the user cannot
monitor). Note also that the protections described here are as fine-grained as
generally regarded to be feasible. A first order security link only on the part
of the client, combined with trust links based on the destination domain of
remote-connecting scripts would enable flexible cross-domain access. The
feasibility of this has been doubted (by Mark Russinovich for one) but by no
means disproved.
Further examples could be included (SQLi, encrypted/steganographed traffic in a
workplace)
