Definitions
Many of the terms used in security engineering are straightforward, but some are misleading or even controversial. There are more detailed definitions of technical terms in the relevant chapters, which you can find using the index. In this section, I’ll try to point out where the main problems lie.
The first thing we need to clarify is what we mean by system. In practice, this can denote:
1.a product or component, such as a cryptographic protocol, a smartcard or the hardware of a PC;
2.a collection of the above plus an operating system, communications and other things that go to make up an organization’s infrastructure;
3.the above plus one or more applications (media player, browser, word processor, accounts / payroll package, and so on);
4.any or all of the above plus IT staff;
5.any or all of the above plus internal users and management;
6.any or all of the above plus customers and other external users.
Confusion between the above definitions is a fertile source of errors and vulnerabilities. Broadly speaking, the vendor and evaluator communities focus on the first (and occasionally) the second of them, while a business will focus on the sixth (and occasionally the fifth). We will come across many examples of systems that were advertised or even certified as secure because the hardware was, but that broke badly when a particular application was run, or when the equipment was used in a way the designers didn’t anticipate. Ignoring the human components, and thus neglecting usability issues, is one of the largest causes of security failure. So we will generally use definition 6; when we take a more restrictive view, it should be clear from the context.
The next set of problems comes from lack of clarity about who the players are and what they are trying to prove. In the literature on security and cryptology, it’s a convention that principals in security protocols are identified by names chosen with (usually) successive initial letters— much like hurricanes — and so we see lots of statements such as ‘Alice authenticates herself to Bob’. This makes things much more readable, but often at the expense of precision. Do we mean that Alice proves to Bob that her name actually is Alice, or that she proves she’s got a particular credential? Do we mean that the authentication is done by Alice the human being, or by a smartcard or software tool acting as Alice’s agent? In that case, are we sure it’s Alice, and not perhaps Cherie to whom Alice lent her card, or David who stole her card, or Eve who hacked her PC?
By a subject I will mean a physical person (human, ET, . . .), in any role including that of an operator, principal or victim. By a person, I will mean either a physical person or a legal person such as a company or government1.
A principal is an entity that participates in a security system. This entity can be a subject, a person, a role, or a piece of equipment such as a PC, smartcard, or card reader terminal. A principal can also be a communications channel (which might be a port number, or a crypto key, depending on the circumstance). A principal can also be a compound of other principals; examples are a group (Alice or Bob), a conjunction (Alice and Bob acting together), a compound role (Alice acting as Bob’s manager) and a delegation (Bob acting for Alice in her absence). Beware that groups and roles are not the same. By a group I will mean a set of principals, while a role is a set of functions assumed by different persons in succession (such as ‘the officer of the watch on the USS Nimitz’ or ‘the president for the time being of the Icelandic Medical Association’). A principal may considered at more than one level of abstraction: e.g. ‘Bob acting for Alice in her absence’ might mean ‘Bob’s smartcard representing Bob who is acting for Alice in her absence’ or even ‘Bob operating Alice’s smartcard in her absence’. When we have to consider more detail, I’ll be more specific.
The meaning of the word identity is controversial. When we have to be careful, I will use it to mean a correspondence between the names of two principals signifying that they refer to the same person or equipment. For example, it may be important to know that the Bob in ‘Alice acting as Bob’s manager’ is the same as the Bob in ‘Bob acting as Charlie’s manager’ and in ‘Bob as branch manager signing a bank draft jointly with David’. Often, identity is abused to mean simply ‘name’, an abuse entrenched by such phrases as ‘user identity’ and ‘citizen’s identity card’. Where there is no possibility of being ambiguous, I’ll sometimes lapse into this vernacular usage in order to avoid pomposity.
The definitions of trust and trustworthy are often confused. The following example illustrates the difference: if an NSA employee is observed in a toilet stall at Baltimore Washington International airport selling key material to a Chinese diplomat, then (assuming his operation was not authorized) we can describe him as ‘trusted but not trustworthy’. Hereafter, we’ll use the NSA definition that a trusted system or component is one whose failure can break the security policy, while a trustworthy system or component is one that won’t fail.
Beware, though, that there are many alternative definitions of trust. A UK military view stresses auditability and fail-secure properties: a trusted systems element is one ‘whose integrity cannot be assured by external observation of its behavior whilst in operation’. Other definitions often have to do with whether a particular system is approved by authority: a trusted system might be ‘a system which won’t get me fired if it gets hacked on my watch’ or even ‘a system which we can insure’. I won’t use either of these definitions. When we mean a system which isn’t failure-evident, or an approved system, or an insured system, I’ll say so.
The definition of confidentiality versus privacy versus secrecy opens another can of worms. These terms clearly overlap, but equally clearly are not exactly the same. If my neighbor cuts down some ivy at our common fence with the result that his kids can look into my garden and tease my dogs, it’s not my confidentiality that has been invaded. And the duty to keep quiet about the affairs of a former employer is a duty of confidence, not of privacy.
The way I’ll use these words is as follows.
Secrecy is a technical term which refers to the effect of the mechanisms used to limit the number of principals who can access information, such as cryptography or computer access controls. Confidentiality involves an obligation to protect some other person’s or organization’s secrets if you know them. Privacy is the ability and/or right to protect your personal information and extends to the ability and/or right to prevent invasions of your personal space (the exact definition of which varies quite sharply from one country to another). Privacy can extend to families but not to legal persons such as corporations. For example, hospital patients have a right to privacy, and in order to uphold this right the doctors, nurses and other staff have a duty of confidence towards their patients. The hospital has no right of privacy in respect of its business dealings but those employees who are privy to them may have a duty of confidence. In short, privacy is secrecy for the benefit of the individual while confidentiality is secrecy for the benefit of the organization.
There is a further complexity in that it’s often not sufficient to protect data, such as the contents of messages; we also have to protect metadata, such as logs of who spoke to whom. For example, many countries have laws making the treatment of sexually transmitted diseases secret, and yet if a private eye could find out that you were exchanging encrypted messages with an STD clinic, he might well draw the conclusion that you were being treated there. (A famous model in Britain recently won a privacy lawsuit against a tabloid newspaper which printed a photograph of her leaving a meeting of Narcotics Anonymous.) So anonymity can be just as important a factor in privacy (or confidentiality) as secrecy. To make things even more complex, some writers refer to what we’ve called secrecy as message content confidentiality and to what we’ve called anonymity as message source (or destination) confidentiality. In general, anonymity is hard. It’s difficult to be anonymous on your own; you usually need a crowd to hide in. Also, our legal codes are not designed to support anonymity: it’s much easier for the police to get itemized billing information from the phone company, which tells them who called whom, than it is to get an actual wiretap. (And it’s often very useful.)
The meanings of authenticity and integrity can also vary subtly. In the academic literature on security protocols, authenticity means integrity plus freshness: you have established that you are speaking to a genuine principal, not a replay of previous messages. We have a similar idea in banking protocols. In a country whose banking laws state that checks are no longer valid after six months, a seven month old uncashed check has integrity (assuming it’s not been altered) but is no longer valid. The military usage tends to be that authenticity applies to the identity of principals and orders they give, while integrity applies to stored data. Thus we can talk about the integrity of a database of electronic warfare threats (it’s not been corrupted, whether by the other side or by Murphy) but the authenticity of a general’s orders (which has an overlap with the academic usage). However, there are some strange usages. For example, one can talk about an authentic copy of a deceptive order given by the other side’s electronic warfare people; here the authenticity refers to the act of copying and storage. Similarly, a police crime scene officer will talk about preserving the integrity of a forged check, by placing it in an evidence bag.
The last matter I’ll clarify here is the terminology which describes what we’re trying to achieve. A vulnerability is a property of a system or its environment which, in conjunction with an internal or external threat, can lead to a security failure, which is a breach of the system’s security policy. By security policy I will mean a succinct statement of a system’s protection strategy (for example, ‘each credit must be matched by an equal and opposite debit, and all transactions over $1,000 must be authorized by two managers’). A security target is a more detailed specification which sets out the means by which a security policy will be implemented in a particular product —encryption and digital signature mechanisms, access controls, audit logs and so on — and which will be used as the yardstick to evaluate whether the designers and implementers have done a proper job. Between these two levels you may find a protection profile which is like a security target except written in a sufficiently device-independent way to allow comparative evaluations among different products and different versions of the same product. I’ll elaborate on security policies, security targets and protection profiles in later chapters. In general, the word protection will mean a property such as confidentiality or integrity, defined in a sufficiently abstract way for us to reason about it in the context of general systems rather than specific implementations.
Summary
There is a lot of terminological confusion in security engineering, much of which is due to the element of conflict. ‘Security’ is a terribly overloaded word, which often means quite incompatible things to different people.
To a corporation, it might mean the ability to monitor all employees’ email and web browsing; to the employees, it might mean being able to use email and the web without being monitored. As time goes on, and security mechanisms are used more and more by the people who control a system’s design to gain some commercial advantage over the other people who use it, we can expect conflicts, confusion and the deceptive use of language to increase.
One is reminded of a passage from Lewis Carroll:
‘‘When I use a word,’’ Humpty Dumpty said, in a rather scornful tone, ‘‘it means just what I choose it to mean— neither more nor less.’’ ‘‘The question is,’’ said Alice, ‘‘whether you can make words mean so many different things.’’ ‘‘The question is,’’ said Humpty Dumpty, ‘‘which is to be master — that’s all.’’ The security engineer should develop sensitivity to the different nuances of meaning that common words acquire in different applications, and to be able to formalize what the security policy and target actually are. That may sometimes be inconvenient for clients who wish to get away with something, but, in general, robust security design requires that the protection goals are made explicit.
Click Here to Purchase this Book