[soen321-f04] another look at CIA (Sep 19)[soen321-f04] another look at CIA (Sep 19) David K. Probst PROBST at vax2.concordia.ca Sun Sep 19 18:44:52 EDT 2004 Previous message: [soen321-f04] Fw: US-CERT Technical Cyber Security Alert TA04-260A -- Microsoft Windows JPEG component buffer overflow Next message: [soen321-f04] room change (Sep 21) Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] a second pass over CIA ______________________ We didn't smoothly reach an important punchline, viz., how threats are connected to security services, even though this is hardly rocket science. We also didn't sharply enough distinguish confidentiality and integrity. These terms have slightly different meanings depending on the _context_ (confidentiality of what? integrity of what?). Whether these two types of security service are distinct is orthogonal to the question whether one sevice in one context might have a dependence relation with another service in another context. Also, we are learning whether system examples must be explained in great detail to ensure that all students fully get them. In passing, we note that the combination of desired services makes up a policy, and mechanisms enforce the policy. All mechanisms rely on underlying (including especially trust) assumptions. 1) Confidentiality is the concealment (hiding) of information or resources. Access-control mechanisms, whether cryptographic, part of OS protection, or part of "network security", support confidentiality. We want to prevent unauthorized processes from accessing information. Now, how do resources enter in? Well, resource hiding is another important aspect of confidentiality. For example, a site may wish to conceal its configuration (who is connected to what? what are the internal IP addresses?) or the precise versions of the system software it is using. Example: When DARPA ran its mail server under NextOS back in the 1990s, it chose e-mail addresses of the form 'bparker at vax.darpa.mil' to fool hackers into trying to break into a VMS system. All the mechanisms that enforce confidentiality require supporting services from the system. This is similar to having security services rely on the kernel, among other agents, to supply correct data. Example of trusting the kernel: When process 123 opens file abc for reading, there is an access check using the ACL to determine if this operation is allowed. If it is, a capability to access file abc in read mode is placed in protected kernel space under process 123's name (it is a capability/file descriptor). Now, when process 123 asks the file system to perform a read, it merely refers the file system to the capability that is stored securely on its behalf. But, if bad guys can make copies of capabilities, process 456 might obtain a capability, say, for file def even though process 456 was never vetted for read permission by passing through an access check. The file system trusts that such things cannot happen. It seems natural to have some control over who can run which programs. It also seems natural to group this under confidentiality. But making this a second-class sense of confidentiality (a mere footnote as it were) will probably allow you to see the distinctions, and possible dependences, among the two more clearly. At least, in the beginning. 2) Integrity refers to the trustworthiness of data or resources (including programs), and is often phrased (or narrowly construed) as preventing unauthorized modification of data or resources (again, including programs). For data, this is straightforward, and we can easily distinguish data confidentiality from data integrity. Indeed, we can imagine scenarios where we enforce data integrity without enforcing data confidentiality and the reverse (although the reverse seems strange: what is the value of receiving a secret message if it may have been garbled). Now, for a program (or system), a loss of integrity means an unauthorized modification of the functionality of the program or system, so that it no longer behaves correctly (or as expected). Clearly, improper modification can be distinguished from stealing secrets, even for a program or system. The subtlety is that being able to distinguish confidentiality from integrity in a particular context does _not_ imply that there are no dependences between one of these things in one context and the other thing in a different context. Example: What happens to the confidentiality of your data if you lose the integrity of the cryptosystem that provides confidentiality by encrypting the data? Answer: it is no longer guaranteed. At all! Integrity mechanisms can be either prevention mechanisms or detection mechanisms. For example, adequate authentication and good access controls can be used, in some cases, to prevent integrity loss. (Authentication is the verification of a claim about identity). Another distinction between confidentiality and integrity is that we have assumption chains with integrity. A secret is either revealed or not, but integrity (in the sense of trustworthiness) can include: 1) the origin of the data, 2) the integrity during transmission, and 3) the integrity during storage. (Plus the trustworthiness of the process by which the data was generated in the first place). So integrity is sort of a double thing: the information wasn't modified and it was good information to begin with. Obviously, this applies equally well to programs. A _threat_ is a potential violation of security. Security services counter, or are countermeasures against, threats. Example: Confidentiality services guard against snooping (eavesdropping), which is in the threat class _disclosure_. Example: Integrity services guard against getting us to trust bad data, which is in the threat class _deception_, and if the modified data controls the operation of the system, integrity services can guard against the threats of _disruption_ (prevention of correct operation) and _usurpation_ (taking over control of the system). Availability services guard against threats of denial of service, which is a special form of usurpation. Assumptions and trust _____________________ Example: When deciding to export files to an NFS client, the NFS server trusts the NFS client to enforce file permissions. User-managed machines are not to be trusted because they have already been broken into (and might harbor malicious NFS clients that do not enforce file permissions). So, we must add a new mechanism, a piece of software called a _filter_ or _guard_. system-managed machine \ / NFS \ / \ / guard / \ / \ user-managed machine / \ "XFS" Here, the guard forwards only those requests to NFS that come from system-managed machines; all other requests are forwarded to "XFS", which takes a very suspicious view of the requesting host. We see that the NFS trust assumption has been _restored_ so that the operation of NFS is exactly what was originally planned for. Basic mantra ____________ If trust is well placed, any system can be made reasonably secure. If trust is misplaced, the system cannot be secure in any sense of the word. What objects can one trust or mistrust? Hosts, programs, applications, operating systems, users, ... Note: A compromise of one security service _may_ lead to a compromise of another security service, but this is not _necessarily_ the case (sometimes we can lose x without losing y). Previous message: [soen321-f04] Fw: US-CERT Technical Cyber Security Alert TA04-260A -- Microsoft Windows JPEG component buffer overflow Next message: [soen321-f04] room change (Sep 21) Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] More information about the soen321-f04 mailing list