Manual inspections & reviews

Human reviews that typically test the security implications of people, policies and process. Include inspection of technology decisions. Interviews and review of documentation.

Advantages:

• Requires no supporting technology
• Can be applied to a variety of situations
• Flexible
• Promotes teamwork
• Early in the SDLC

Disadvantages:

• Can be time consuming
• Supporting material not always available
• Requires significant human thought and skill to be effective

Threat Modeling

Develop a model, and use that in the design of the software to stop threats. Developed as early as possible in the SDLC.

Use a simple approach to develop the threat model. The OWASP Guide recommends the NIST 800-30 standard for risk assessment.

That approach involves (from the book):

• Decomposing the application – use a process of manual inspection to understand how the application works, its assets, functionality, and connectivity.
• Defining and classifying the assets – classify the assets into tangible and intangible assets and rank them according to business importance.
• Exploring potential vulnerabilities - whether technical, operational, or management.
• Exploring potential threats – develop a realistic view of potential attack vectors from an attacker’s perspective, by using threat scenarios and attack trees
• Creating mitigation strategies - develop migitating controls for each of the threts deemded to be realistic

Outputs a collection of lists and diagram.

Advantages:

• Practical attacker’s view of the system
• Flexible
• Early in the SDLC

Disadvantages:

• Relatively new technique
• Good threat models don’t automatically mean good software

Code Review

Modeling and analysis cannot detect all errors. Code review is to go straight to the source code and look for security vulnerabilities. There's no substitute for code review/looking at the source code when looking for vulnerabilities in web applications. Removes the guess work of black box testing.

Advantages:

• Completeness and effectiveness
• Accuracy
• Fast (for competent reviewers)

Disadvantages:

• Requires highly skilled security developers
• Can miss issues in compiled libraries
• Cannot detect run-time errors easily
• The source code actually deployed might differ from the one being analyzed

Penetration Testing

Penetration testing has been in use for many years. Also known as black box testing or ethical hacking. The point is to run the application remotely to try to find security vulnerabilites, without knowing the inner workings of the application. The tester acts as an attacker.

Advantages:

• Can be fast (and therefore cheap)
• Requires a relatively lower skill-set compared to source code review
• Tests the code that is actually being exposed

Disadvantages:

• Too late in the SDLC
• Front impact testing only

A balanced approah

You need to combine the methods. The book presents examples where one method alone does not find all security vulnerabilities.

Functional Security Requirements

Requirements that state expected functionality that can be validated through security tests, are referred to as 'positive requirements'.

Example of high-level security design requirements for authentication (examples of positive requirements):

• Protect user credentials and shared secrets in transit and in storage
• Mask any confidential data in display (e.g., passwords, accounts)
• Lock the user account after a certain number of failed log in attempts
• Do not show specific validation errors to the user as a result of a failed log on
• Only allow passwords that are alphanumeric, include special characters and six characters minimum length, to limit the attack surface
• Allow for password change functionality only to authenticated users by validating the old password, the new password, and the user answer to the challenge question, to prevent brute forcing of a password via password change.
• The password reset form should validate the user’s username and the user’s registered email before sending the temporary password to the user via email. The temporary password issued should be a one time password. A link to the password reset web page will be sent to the user. The password reset web page should validate the user temporary password, the new password, as well as the user answer to the challenge question.

Risk driven security requirements

'Negative requirements' are requirements that validate the application for unexpected behavior. Negative requirements can be difficult to test, as there is no expected behavior to look out for.

Example:

• The application should not allow for the data to be altered or destroyed
• The application should not be compromised or misused for unauthorized financial transactions by a malicious user.

Use cases are used to develop functional requirements for an application. Misues and abuse cases describes unintended and malicious use scenarios of the applications. These can be used to further develop requirements.

To derive security requirements from use and misuse cases, you can follow this step-by-step methodology:

1. Describe the functional scenario
2. Describe the negative scenario
3. Describe functional and negative scenarios with use and misuse case
4. Elicit the security requirements.

This figure shows graphical representation of the example from the guide:

2.3.1 What the brain does worse than the computer

There are many different human errors the security engineer should be aware of.

There's been and still is a lot of research on human error in regards to computer systems.

Types of errors:

• Capture errors: When an action has been done many times, it becomes practices. Through inattention you can repeat the practices action, even though you intended to do something else.
• Post-completion error: When you've completed your immediate goal, you are easily distracted from tidying-up actions, e.g. removing your bank card after a ATM withdrawal.
• Actions made based on rules are open to errors when the rules are wrong: A phishermen can make a target use the site by having the site use HTTPS, and starting URLs with the bank name.
• Mistakes done by people due to cognitive reasons - they simply don't understand the problem. IE7 had a anti-phishing toolbar that didn't stop phishing, because the team developing it didn't completely understand the problem.

2.3.2 Perceptual Bias and Behavioral Economics

Really just a page and a half with some introductory knowledge on behavioral economics. It mentions a few fields, and relates them to some facts about the human mind.

Wisdom from this section:

• We dislike losing 100 dollars more than we like the prospect of winning 100 dollars.
• Easily remembered data have more weight in mental processing
• We worry too much about unlikely events
• We have a constant underlying misconception about risk
• We are more afraid to lose something we have, than not making a gain of equivalent value
• We are more likely to go for something that's 'good enough', rather than work for something that's perfect: Most people go for the default system setup, as it wil be 'good enough'. This is a reason why security defaults matter.

2.3.3 Different Aspects of Mental Processing

• The mind is usually seen as one part 'cognitive' and one part 'affective'
• Fundamental attribution error: People often err trying to explain things with intentionality rather than situation.
  • Teaching possible victims about the gory details of the Internet, e.g. by telling them to parse URLs that are sent in an email that seemingly comes from a bank, will be of limited value if the user's get bewildered
  • Use security defaults, e.g. 'This bank does not send you emails' - remove the emotional element for the user
• Affect heuristic
  • By first asking an emotional question, you can get the user to answer the subsequent questions with their heart more than their head
  • Can be related to everything from risky behavior on porn sites to the use of celebrities in marketing
  • Cognitive overload also increases reliance on affect

2.3.4 Differences Between People

• Men and women experience and use UIs differently
• There's been quite the amount of research on how women uses websites
• Most software today is made mostly by men
• It's not difficult to believe that the trend we're seeing in design of UIs and products may also be relevant when it comes to security engineering

2.3.5 Social Psychology

The growth of social-networking systems will lead to peer pressure being used as a tool for deception. There are many examples of abuse of authority, peer pressure and pretexting from the real world, that we as engineers can learn from.

2.3.6 What the Brain Does Better Than the Computer

Humans are better at recognizing humans visually, and image recognition generally.

2.4.1 Difficulties with a Reliable Password Entry

A password can be too long and complex, which means that the user has difficulties entering it correctly. An urgent action protected by a password that's hard to enter, will have security implications.

2.4.2 Difficulties with Remembering the Password

Passwords can be hard to remember, which is a security risk. The problems related to remembering a password can be broken down to : Naive password choice, user abilities and training, design errors and operational failures.|

2.4.3 Naive Password Choice

To be able to remember their password, people choose words, names of their spouses or children, which is not that hard to find out. They also use complete words, which can be looked up in dictionaries. Engineers implemented password length requirements, and looked up password in dictionaries to see that it wasn't too easy but password quality enforcement is more complicated than that. After the rule that read 'at least six characters and at least one nonletters', Unix Secuirty reported that they built a file of the 20 most common female names plus a single digits, and tried them on several dozens machines. Of the 200 passwords, at least one was in use on the machines they tried. Daniel Klein ran a study where he gathered 25 000 encrypted Unix passwords and ran cracking software to break them, found that 21-25 % of the passwords could be guessed.

The requirement to change passwords regularly tends to backfire: Studies show that users either change the password until the password history is exhausted and they can use the password they want, or if it's a time limit on how often they can change it, they don't do it until an administrator helps them.

People are getting better at writing passwords, this shows the passwords retrieved from phishing sites. The most common password today isn't 'password', which it was before, but 'password1'.

2.4.4 User Abilities and Training

One can do a lot to protect passwords in e.g. a military or e-commerce environment, but you don't want to drive your customers away, and you can't order soldiers to do something they simply cannot do.

The author didn't find many relevant research articles on this, so he conducted an experiment himself, on first year computer science students. He asked three groups to create passwords after different rules. The conclusions he drew was:

• For users who follow instructions, passwords based on mnemonic phrases offer the best of both worlds. They are as easy to remember as naively selected passwords, and as hard to guess as random passwords.
• The problem then becomes one of user compliance. A significant number of users (perhaps a third of them) just don’t do what they’re told.

2.4.5 Social-Engineering Attacks

The biggest practical threat to passwords today, is that the user breaks the system security by giving the password to a third party, either willingly or as a result of deception. When it comes to deception, phishing (password fishing) has become a real problem.

2.4.6 Trusted Path

A trusted path refers to some means of being sure that you're logging into the system you think you're logging into, and that no one is eavesdropping. Instead of impersonating a police man to get a target's PIN, you place a false ATM in a shopping mall.

Skimmers are devices fitted over the front of real cash machines. These copy the card's data, and use a small camera to get the PIN.

2.4.7 Phishing Countermeasures

A large number of phishing countermeasures have been tried and proposed.

For banking, two-channel authentication seems to give the most bang for the buck.

2.4.8 The Future of Phishing

It's hard to predict the future, but the author does it anyway.

2.5.1 Can You Deny Service?

If you have some restriction that three wrong attempts closes off the account, won't a attack that floods the service with wrong login attempts bring down the service? What if this happens to a military system, right before an attack? No one can enter the systems, and everyone needs to be reactivated by an admin.

2.5.2 Protecting Oneself Or Others?

Make sure that if a user is hacked, that user cannot get the information of any other users.

2.5.3 Attacks on Password Entry

Password entry is usually badly protected.

2.5.4 Attacks on Password Storage

Passwords are often vulnerable when they are stored. You'll also need to protect login/registration logs.

3.3.1 Challenge and response (CAP)

Protocol for authorising engine start with an advanced key that also has RF:

writing $E$ for the engine controller, $T$ for the transponder in the car key, $K$ for the cryptographic key shared between the transponder and the engine controller, and $N$ for the random challenge, the protocol may look something like:

$$ E \rightarrow T: N$$ $$T \rightarrow \{ T, N\}_K $$

The random number that is generated cannot be generated completly at random, therefore it's possible to predict which value it has. Therefore this is not bulletproof.

Usually radnomness is done by combining many different streams of information in PCs, e.g. internet traffic and spikes in HDD spins. This is not possible in a car lock, and is solved by encrypting a counter using a special key which is kept inside the device and not used for any other purpose.

Other challenge-response protocols:

• HTTP Digest Authentication
  • Web server challenges by sending a client or proxy whom it shares a password with, a nonce.
  • Response consists of the hash of the nonce, the password and the requested URI.
  • E.g. used to authenticate users in SIP, the protocol for VOIP.
• Two-factor authentication (see image below)
  • User is given a device that looks like a calculator.
  • When the user wants to log onto a system the device works with (e.g. a bank) the system gives for example seven digits, which the user keys into the device., together with a PIN of e.g. four digits.
  • The device encrypts these digits using a secret key shared with the security system server, then displays the first, e.g. 7 digits, of the result. These digits are entered as the password to the system.

Written formally:

Formally, with $S$ for the server, $P$ for the password generator, $\text{PIN}$ for the user’s Personal Identification Number that bootstraps the password generator, $U$ for the user and $N$ for the random nonce:

Simpler version just has a device that generates some random number.

3.3.2 The MIG/man-in-in-the-Middle Attack

From the OWASP wiki

The man-in-the middle attack intercepts a communication between two systems. For example, in an http transaction the target is the TCP connection between client and server. Using different techniques, the attacker splits the original TCP connection into 2 new connections, one between the client and the attacker and the other between the attacker and the server, as shown in figure 1. Once the TCP connection is intercepted, the attacker acts as a proxy, being able to read, insert and modify the data in the intercepted communication.

3.3.3 Reflection Attacks

Where two clients uses the same protocol to authenticate each other:

1. Open a connection to the target, get a challenge
2. Open another another connection, pass that challenge back to the target
3. The target answers
4. Pass that answer to the original challenge

$$ F \rightarrow B:N$$ $$ B\rightarrow F:N $$ $$F\rightarrow B: \{N\}_k $$ $$B\rightarrow F: \{N\}_k $$

Can be solved with e.g.including the name of the client when connecting., e.g. $F \rightarrow B:N$ then $B \rightarrow F : \{B, N\}_K $

3.7.1 Basic Key Management

Simple authentication protocol with Alice and Bob, with Sam as the trusted third party (despite human names, these are not human principals):

1. Alice calls Sam and asks for a key for communicating with Bob
2. Sam returns two certificates to Alice: One for Alice and one for Bob.
3. Alice sends Bob the certificate that's meant for him
4. Alice and Bob decrypts their certificate with a trusted key they share with Sam.
5. Alice and Bob can send each other messages, encrypting/decrypting them with the certificate.

So called replay attacks are common with authentication protocols, so Sam usually includes a timestamp.

Exapnding the protocol with timestamps:

1. Alice calls Sam and tells Sam that she wants to talk to Bob.
2. Sam makes up a session key message, that consists of Alice's name, Bob's name and a key for them to use, and a timestamp.. Everything is encrypted under the key shared with Alice. Another copy is encrypted under the key he shares with Bob.
3. Sam gives both ciphertexts to Alice.
4. Alice encrypts the ciphertext meant for her, and passes the other one over to Bob.
5. Alice can now send the messages she wanted to send, encrypted using the key.

3.7.2 The Needham-Schroeder Protocol

Many modern key distribution protocols are derived from the The Needham-Schroeder Protocol, which kind of looks like the last one described in the previous section, except it uses nonces instead of timestamps:

1. $$A \rightarrow S: A, B, N_A$$
2. $$S \rightarrow A : \{ N_A , B, K_{AB}, \{ K_{AB}, A \}_{K_{BS}} \}_{K_{AS}}$$
3. $$A \rightarrow B: \{ K_{AB}, A \}_{K_{BS}}$$
4. $$ B \rightarrow A: \{ N_B \}_{K_{AB}} $$
5. $$A \rightarrow B: \{ N_B - 1 \}_{K_{AB}} $$

Here $A$ is Alice, $B$ is Bob and $S$ i Sam. Let's translate it to words:

1. Alice sends Sam her name, Bob's name and a Nonce from herself.
2. Sam responds by sending the same Nonce - which ensures that this is not a replay - , Bobs name, a common key ($K_{AB}$) Alice's name and the common key encrypted with Bob's key. ($\{ K_{AB}, A\}_{K_{BS}}$), which Alice can send to Bob. Everything is encrypted with Alice's key
3. Alice sends the certificate meant for Bob to him
4. Bob responds with a Nonce encrypted with the common key
5. Alice sends the Nonce minus 1 encrypted with the common key.

There 's a small problem with this protocol. Between step 2 and 3, Alice can have waited for a long time. For a year! Bob just has to assume that the key he receives is fresh. For many applications, this won't be a problem, but in many cases an opponent, Charlie, could get a hold of Alice's key and set up session keys with other principals. If/when Alice finds out her key is stolen, she has to contact Sam and make him contact everyone for whom she'd ever been issued a key, and tell them the old key is no longer valid. As she doesn't know who Charlie has contacted, she cannot tell them herself. Revocation is a problem: Sam has to keep logs of everything he has ever done.

The protocol was created in 1978. Then the point of these protocols was to keep the 'bad guys' out, but today we expect the users to be the enemy. The assumption for the protocol was that if all principals behave themselves, it remains sound.

3.7.3 Kerberos

Kerberos is a distributed access control system. It originated at MIT and is one of the standard authentication tools in Windows.

It uses two kinds of trusted third party, instead of just one: - An authentication server to wich users log on - Ticket granting server which gives them tickets allowing access to various resources, such as files.

This enables more scaleable access management.

It works as the following, $A$ is Alice , $B$ is a resource (e.g. a file), and $S$ is a ticket system. Alice has already logged in. $K_{AS}$ is a session key, $K_{AB}$ is a key, $T_S$ is a timestamp and $L$ is the liftetime of the key.

1. Alice asks for resoure $B$: $$A \rightarrow S : A, B $$
2. Server responds. Encrypts the response under key $K_{AS}$. Gets access to the content if she gets her answer right. Server gives her a ticket, and a version of the ticket that's readable to her:$$ S \rightarrow A: \{ T_S, L, K_{AB}, B , \{ T_S, L, K_{AB} , A \} _{K_{BS}} \}_{K_{AS}}$$
3. Verifies ticket by sending it to the resource, together with a timestamp for when she sent it:$$A \rightarrow B: \{ T_S, L, K_{AB} , A \} _{K_{BS}} , \{A, T_A\}_{K_{AB}}$$
4. Resource confirms that it's alive and that it managed to decrypt the ticket by returning the timestamp incremented.:$$B \rightarrow A: \{ T_A +1 \}_{K_{AB}} $$

Step 2 to 4 only happens if Alice is allowed ot access $B$.

This fixes the the vulnerability of Needham-Schroeder by introducing timestamps instead of random nonces. It introduces a new vulnerability: The clocks of the clients and servers might be out of sync. They might be descyned deliberately to coordinate a great attack.

3.7.4 Practical Key Management

Many of todays security protocols are similar to Kerberos, e.g. a protocol for ATMs, that'll be described in a later chapter.

There are more than challenges and concerns than those related to number of and validity of keys. The book also notes that things often go wrong as applications evolve.

A number of practical strategies:

• Public-key crypto, see chapter 5
• Dedicated cryptograhphic processors, see chapter on 'Tamper Restistance'
• Also see the chapter 'API Secuirty' (Not a part of the curriculum)

Getting security protocols right is very hard.

3.8.1 A Typical Smartcard Banking Protocol

This subsection presents an example of a protocol that there was found flaws in, even though it had been proved correct using formal methods.

The COPAC system was a electronic purse used by VISA in countries with poor telecommunications. It was the first financial system whose protocol suite was designed and verified using formal techniques (a variant of BAN logic). A similar protocol is used by Geldkarte in Germany, Moneo in France and Proton in Belgium.

Transactions takes place between the customer's and the merchant's smartcards. The customer gives an electronic check with two authentication codes on it. One of them can be checked by the network, and the other can be checked by the customer's bank.

Simplified it looks like this:

1. Customer and reatiler share a key $K$. The customer uses it to encrypt its account number $C$, and a customer transaction serial number $N_C$: $$C \rightarrow R: \{ C, N_C\}_K $$
2. The retiailer confirms its own account number $R$, and his own transactional serial number $N_R$, in addition to the information it just received from the customer.:$$R \rightarrow C: \{ R, N_R, C, N_C\}_K $$
3. The customer sends the electronic check $X$, and all the data already exchanged: $$C \rightarrow R: \{ C, N_C, R, N_R, X\}_K $$

3.8.2 The BAN logic

The underlying idea behind the BAN logic is that we believe that a message is authentic if it is encrypted with a relevant, key, and it is also fresh (generated during the current run of the protocol.).

Notation:

In this notation, the statements on the top are the conditions, and the one on the bottom is the result. There are a number of further rules to cover the more mechanical aspects of manipulation; for example, if A sees a statement then he sees its components provided he knows the necessary keys, and if part of a formula is known to be fresh, then the whole formula must be.

Based on exams (pre 2015) and the fact that the next section that uses the notation doesn't go into that much of a detail on how it is proved, it does not seem that it's important to know the notation and how to use it in this course.

3.8.3 Verifying the Payment Protcol

This section uses the BAN logic (the rules from the last section) to prove that the example protocol from section 3.8.1 is correct.

The section is not long (about a third of a page), and does not go into detail. It recommends reading the original paper if you're interested in more details. It gives a tip regarding BAN: Start with the desired result, and work backwards.

3.8.4 Limitation of Formal Verification

Problems with formal methods:

• External assumptions: E.g. assuming that a key isn't available to anyone who might use it in an unauthorized manner. Systems can have bugs. The real world is complex. Environments change.
• Idealization of the protocol: The protocol alone isn't responsible for the security. In the implementation there are many different applications, systems and hardware aspects that kick in.

These problems has introduced the idea of protocol robustness. It introduces robustness principles, e.g. interpretation of a protocol should depend ony on its content, not its context

4.2.1 Groups and Roles

Role-based access control (RBAC).The terms 'groups' and 'roles' are used interchangeably. The point with this access control is to assign users rolers/groups depending on their role and by that access level in the organization.

How this works depends on implementation, e.g. if one can be a part of multiple groups/have multiple roles

4.2.2 Access Control List

Access Control List (ACL, pronounced 'ackle'). It's simply a list that describes the access level to a resource for each user. It's the natural choice when users manage their own file security. Suitable where access control is data-oriented. Less suitable when there's a large user base that's constantly changing, or when user's want to delegate access for periods of time. Changing access controls for a user is tedious.

4.2.3 Unix Operating System Security

Unix and Linux systems have rwxattributes for the owner, the group and the world. The ACL usually also has a flag that the shows that the resource is a directory, d. It then flags for world, group and owner respectively + the name of the owner and the group, e.g. : drwxrwxrwx Alice Accounts Alice is the owner, and Accounts is the group.

In Unix systems the kernel runs as supervisor (root). All programs runs as users. Root can do anything he wants to. The sysadmin has access to the root users. This means that it's hard to make a audit trail that the sysadmin cannot modify, which means that a user has a hard time defending himself if he is falsely accused with tinkering with a file.

Another problem with ACL's is that the only contain names of users, not of programs, so that there is no way to implement so called access triplets, that is triplets like (user, program , file). Instead Unix-based systems provides you the method set-user-id - suidfile attribute. The owner of some program, can mark it as suid, which lets the user run the program as its owner, rather than as the user.

Users are often lazy, and just let's software run as suid root, which means it can do absolutlely anything. This leads to security holes.

4.2.4 Apple's OS/X

Apple OSX is based on the Free BSD version of Unix, running on the Mach kernel. The BSD layer provides memory protection: In this OS an application cannot access system memory unless running with advanced permissions.

At file system level, OS/X is almost a standard Unix. Standard installation has the root-account disabled.

4.2.5 Windows - Basic Architecture

The access control in Windows is largely based on ACLs since Windows NT. The protection in Windows NT was much like Unix, and was inspired by Unix.

Windows has these added permission attributes:

• Take ownership
• Change permissions
• Delete

They can apply to both users and groups. An attribute in Windows isn't simply true/false, it can have multiple values:

• Access Denied (false, not allowed)
• Access Allowed (true, allowed)
• SystemAudit

If the AccessDenied flag is encountered in an ACL for a relevant user or group, not access is allowed regardless of any AccessAllowed-flags.

The benefit of the syntax is that everyday configuration doesn't have to be done with full admin priileges (but this is rarely done in practice.).

Another advantage is that users and resources can be partioned up into domains. Each domain can have it's distinct administrator(s).

There are problems with designing Windows security architectures in very large organizations; such as naming issues (Chap. 6), domains which scale badly with increased number of users, and that users in other domains can not be administrators.

4.2.6 Capabilities

One can also store a access control matrix by rows. These are then called capabilities.

The strengths and weaknesses are more or less the opposite of ACLs. Runtime security checks are more efficent, and you can delegate a right with much less difficulty than with ACL. E.g. Bob can show his capability, and delegate it to David 'David can read this file from 9 to 11 am, signed Bob.' Changing a file's status can be more tricky; it's difficult to find out who has access.

There were experimental implementations in the 1970s, and today we use public key certificates for this purpose.

4.2.7 Windows - Added Features

Many systems has combines capabilities with ACL, but the most important application is in Windows. It was added with Wndows 2000, together with Kerberos which has already been mentioned..

• A user or group can be either whitelisted or blacklisted by means of profiles. Security policy is set by groups rather than the system as a whole.
• Groups are defined within the object-oriented database Active Directory (AD). It has all users, groups, machines etc, within a hierarchical namespace. Indexed. Can search for anything on any attribute.
• It also introduced the possibility of using public/private keys by implementing the protocol TLS

Vista also introduced that

• The kernel is closed off to developers
• The User Account Control (UAC) replaces the default admin privilege with user defaults instead.

If you log in as a administrator in Vista or later, you get a user and an admin token. The user tokens starts explorer.exe, which is the parent process for all user processes. This means that a admin can browse the web and get malware, without having to worry that it can do administrative actions. Any admin task prompts for a password.

The book then goes on to list many reasons why UAC in Vista is more effective in theory than in practice.

4.2.8 Middleware

Systems don't operate on one machine alone. There are usually more systems involved, e.g. a database system. These will also have access control.

4.2.9 Sandboxing and Proof-Carrying Code

The software sandbox was introduced by Sun with Java in the 1990s, and was another way of implementing access control. The idea is simply to run possibly unsafe code, e.g. one of the old Java webapplets, in its own environment; in a sandbox.. It is done with the JVM.

An alternative to sandboxing is proof-carrying code: Code must carry proof that it doesn't do anything that contravenes the local security policy. A short program checks the proof supplied by the code The overhead of the JVM is removed.

4.2.10 Virtualization

Computers has become advanced, and you can partion resources. A single physical computer can have multiple virtual machines, that each has its own OS, and is completely separate from others, and the host computer.

4.2.11 Trusted Computing

Proposal to add a chip, a Trusted Platfrom Module (TPM) chip, to computers, that could authenticate them. Could be used for e.g. DRM. TPM is available for disk encryption, e.g. with 'BitLocker'.

4.4.4 Why So Many Things Go Wrong

• Large products are buggy
• Kernel bloat
• Developers make their programs run as root

4.4.5 Remedies

• Some classes of vulnerabilities can be fixed with automatic tools, e.g. stack overwriting attacks.
• There's a need for more effort in design, coding and testing.
• Architecture matters.
• Programs should only have as much privilege as they need. This is called the principle of least privilege.
• The default configuration and the easiest way of doing things, should be safe.

4.4.6 Environmental Creep

Environmental change undermines a security model also when it comes to access control. The section lists examples.

5.2.4 One-Way Functions

In the nineteenth century they introduced code books that was a block cipher, which mapped words or phrases or fixed-length groups of letters or numbers. Then rotor machines came, which produced very long sequences of pseudorandom numbers and combined them with the plaintext to get a ciphertext.

Banks further developed the code books, by adding code groups together into numbers called test keys. (with today's terms: A hash value or message authentication code). This lead to one-way functions: The test key did not contain enough information so that you could recover a message from a test value.

5.2.5 Asymmetric Primitives

An example of a asymmetric cryptosystem is the public/private-key system. There are pre-computer examples of this.

5.3.1 Random Functions - Hash Functions

A random function accepts an input string of any length, and outputs a random string of fixed length, e.g. $n$ bits long. They are one-way, a cryptographic hash functions. A hash is often known as a message digest.

Properties of random functions:

• They are one-way
• The output does not give any information at all about any part of the input
• For pseudorandom functions with sufficiently long outputs it's hard to find collisions. If a hash function hashes an $n$-bit number, then there are $2^n$ possible hash values. An attacker will have to compute about a square root of that before he or she can find a match, that is $2^{n/2}$

The Birthday Theorem:

The birthday theorem gets its name from the following problem. A maths teacher asks a typical class of 30 pupils what they think is the probability that two of them have the same birthday. Most pupils will intuitively think it’s unlikely, and the maths teacher then asks the pupils to state their birthdays one after another. As the result seems unlikely to most people, it’s also known as the ‘birthday paradox’. The odds of a match exceed 50% once 23 pupils have been called.

5.3.2 Random Generators - Stream Ciphers

It is also known as a keystream generator. It is also a random function, but unlike the hash function it has a short input and a long output. At a conceptual level, it is common to think about the random generator as a random oracle whose input length is fixed while the output is a very long stream of bits, known as a keystream.

Can be used to protect the confidentiality of backup data. Enter a key, get a keystream, XOR it with your data and save that.

A problem with the keystream generators is that we want to prevent that keystreams are used more than once.

5.3.2 Random permutations - Block ciphers

A random function that's invertible. The input is plaintext, and the output is a ciphertext. Both are of fixed size.

A block cipher is a keyed family of pseudorandom permutations. For each key, we have a single permutation which is independent of all the others.

$$ C = \{M\}_K $$

Attacks:

• Known plaintext attack: Opponent is given a number of randomly chosen inputs and onputs corresponding to a target key.
• Chosen plaintext attack: Opponent is allowed ot put a certain number of plaintext queries and get the corresponding ciphertexts.
• Chosen ciphertext attack: Opponent can make a number of ciphertext queries.
• Chosen plaintext/ciphertext: Opponet can make queries of either type.
• Related key attack: Queries that will be answered using keys related to the target key $K$, e.g. $K+1$ or $K+2$.

The objective of the attacker is to either deduce the answer to a query he hasn't already made (forgery attack), or recover the key (key recovery attack).

5.3.4 Public Key Encryption and Trapdoor One-Way Permutations

One key is available to everyone, so everyone can encrypt anything. The other key is private, and only the owner can decrypt the messages. This means a user can put his public key online, so that people can send him private messages that only he can encrypt. This is quite safe, if the private key is safe.

The trapdoor one-way permutation is a common way of implementing this. The computation is easy, but can only be reveresd if you know the trapdoor, e.g. a secret/privType 20ate key.

We give a function a random input $R$, which then produces $KR$ as the public key, and $KR^{-1}$ as the private key.

1. Given $KR$, it is impossible to compute neither $R$ or $KR^{-1}$
2. We have an encrypt function, $\{...\}$. If you apply that to a message $M$, using $KR$, you get a ciphertext $C=\{M\}_{KR}$
3. There is a decryption function that can reproduce M: $M = \{C\}_{KR^{-1}}$

5.3.5 Digital Signatures

A signature on a message can only created by one person, but checked by everyone. It is for instance used for checking that an update is really from the manufacturer.

A signature scheme is either deterministic or randomized. The first will always give the same signature for the same message, while the other will always give a different result. Randomized signatures are more like handwritten ones. A signature scheme may or may not support message recovery. If it's allowed, then given a signature, anyone can recover the message on which it was generated. If it does not allow message recovery, then the verifier has to guess the message before it can verify.

Formally it can be described as the following: It has a keypair generation function which given some random input $R$, will return two keys: A private one $\sigma R $, and a public one, $VR$.

1. You cannot compute the private key $\sigma R $ with $VR$
2. There is a digital signature function: $\text{Sig}_{\sigma R}(M) $
3. There is a signature verification function, given the signature $\text{Sig}_{\sigma R}(M) $ and $VR$ will output true or false

5.4.1 SP-Networks

Claude Shannon suggested in the 1940's that if you combine substitution with transposition repeatedly, you get strong ciphers.

He said that ciphers have confusion and diffusion. Unknown key values will confuse an attacker when looking at some plaintext symbol while diffusion means spreading the plaintext information through the cipher.

The earliest block ciphers were simple networks whcih combined substitution and permutation circuits. They are called SP-Networks.

This one has 16- inputs. SP-networks consist of substitution-boxes (S-boxes), each of can been seen as a lookup table containing some permutation of the numbers 0 to 15.

Three things need to be done to make such a design secure:

1. the cipher needs to be ‘‘wide’’ enough
2. it needs to have enough rounds, and
3. the S-boxes need to be suitably chosen.

5.4.2 The Advanced Encryption Standard (AES)

AES aka Rijndael after its inventors Rijmen and Daemn. It acts on 128-bit bloks, and can use a key of 128, 192 or 256 bits in length. It is an SP-network.

5.4.3 Feistel Ciphers

Feistel ciphers has a ladder structure. Input is split into two blocks (right and left). A round function $f_1$ of the left half is computed, and is combined with the right half using XOR. Then the right half computes with $f_2$ and combined with the left half, and so on. Finally, if the number of rounds is even, the left and right half are swapped.

To decrypt, we use our round functions in the reverse order. The function does not have to be invertible. Therefore we are less constrainted in trying to choose a round function with good diffusion and confusion properties.

Notation for Feistel ciphers is:

$$ \Psi (f, g, h)$$ where $f$, $g,$ and $h$ are successive round functions.

'

8.3.1 Classifications and Clearances

Describes the classification system in NATO from WWII, how it has evolved and also a few details on the system of the UK. The general idea the section tries to convey is that it's complicated, that people are vetted and given a clearance such that in any of the systems they can only read documents with a clearance at their level or below their level.

8.3.2 Information Flow Control

The BLP model aka Bell-LaPadula model of comuter security was formulated in 1973, in the context of the classification of government data. It is also known as multilevel security, and the systems that implement the model is multilevel secure (MLS), that is they are MLS systems.

The model enforces two properties:

• Simple security property aka no read up (NRU): No process may read data at a higher level.
• No write down(NWD) aka the *-property (read "star"-property): No process can write data to a lower level. This includes copying and moving data.

The point being that a program that sneaks in, e.g. a trojan, cannot automatically read data that's above it's clearance: Processes can really just operate within their own level of clearance.

The model has some elaboration, e.g. a trusted subject, someone who can set classifications. The book doesn't want to complicate the model with this and other details.

It's hard to implement in practice. The trusted computing base of the kernel in the OS grows large. In the 90's and later visualization has become better, and you can implement it using separate virtual machines and pumps which the book will explain later.

8.3.3 The Standard Criticisms of Bell-LaPadula

Cristisim from John McLean and his System Z lead to the introduction of the tranquility property.

• Strong tranquility: Security labels never change during system operation
• Weak tranquility: Labels never change in such a way as to violate a defined security policy.

Another problem with BLP and other mandatory access control systems, is that most of them need some kind of trusted subject, that can break the security policy. E.g. a trusted text processor that can be used to bring a document down a level. BLP is silent on how to protect such an application.

8.3.4 Alternative Formulations

MLS properties have been expressed in other ways than BLP.

• Noninterference: High actions have no effect on what the low levels can see.
• Nondeductability: The idea is to try and prove that Low cannot deduce anything with 100% certainty about High's input. Low can see High's actions, just not understand them.
• Generalized Noninterference: -
• Restrictiveness: Further restrictions on the trace of where the alteration of the high-level outputs can take place.
• The Harrison-Ruzzo-Ullman -model: Tackles the problem on how to deal with deletion and creation of files. Operates on access matrices, and verifies whether there is a sequence of instructions which causes an access right to leak somewhere that it wasn't before. More expressive than BLP, but also more complex.
• Compartmented Mode Workstation (CMW) policy: Attempts to model classification of information using floating labels. Was unsuccessful.
• Type enforcement model: Assigns subjects to domains, and objects ot types. Matrices defines permitted domain-domain and domain-type interactions. Used in the popular mandatory access control system SELinux.
• Role-based access control: (RBAC): Access depends not on usernames, but their function.

8.3.5 The Biba Model and Vista

The Biba model deals with integrity alone and ignores confidentiality. The key observation is that confidentiality and integrity are in some sense dual concepts — confidentiality is a constraint on who can read a message, while integrity is a constraint on who can write or alter it.

The section also describes the MLS of Windows Vista.

8.4.4 The NRL Pump

A pump is simply a one-way data transfer device that allows secure one-way information flow.

The US Naval Research Labratory (NRL) developed one with cheap COTS components.

8.5.1 Vista

Essentially uses the Biba model.

Everything has a integrity-level label. Can also be extended with a 'crude Biba model', with no read up, and no execute up.

8.5.2 Linux

SELinux and Red Hat are similar to vista in that the immediate goal of the new mandatory access control mechanisms is also to limit the effects of a compromise.

SELinux is based on the Flask security architecture, which separates policy and enforcement mechanisms.

8.5.3 Virtualization

You can use VMWare or Xen to provide multiple virtual machines at different levels. NSA has produced a hardened version of VMware, called NetTop. This is optimized for running several VMs with Windows, on top of an SELinux platform.

8.5.4 Embedded Systems

The one-way information flow of many embedded systems, e.g. a electricity monitor system, can be implemented using mandatory access controls. Embedded systems in use in the military does this.

8.6.6 Other Practical Problems

MLS systems are hard and expensive to build:

1. They are built in a small volume, and has high standards for documentation, robustness etc.
2. MLS systems has idiosyncratic admin tools
3. Apps have to be rewritten/modified to run on MLS OSs
4. Processors are upgraded automatically when they see new labels. That means the files that the processors use have to do the same. New files default to the highest label belonging to any possible input. This leads to a chronic tendency to overclassification.
5. It is often inconvenient to deal with 'bind write-up', that is when a Low application sends data to a High one. BLP prevents acknowledgements being sent. Therefore that information vanishes.
6. Data classification can get complex.
7. Some system components has to read and write on all levels, e.g. memory management
8. MLS systems prevent both undesired and desired things from happening, e.g. efficient ways of enabling data to be downgraded from High to Low.

9.2.1 Compartmentation and the Lattice Model

Codewords imply some extra policies and a extra clearance level. For example there was the codeword 'Ultra' for the Enigma machine for the Allies during WWII. The Ultra clearance had many extra security policies tied to it, e.g. Churchill was delivered Ultra summaries in a special box that only he had the key to, but not his staff.

These codewords was the pre-computer way of expressing access control groups. It can be dealt with with a variant of Bell-LaPadula (BLP) called the lattice model. A lattice is a mathematical structure in which any two objects can be in a dominance relation, e.g. $A>B $ or $A<B$. The objects would be a classification and a codeword. Let's say we have a codeword 'Crypto', and a clearance 'Top Secret'. The person with a 'Top Secret' clearance has access to 'Top Secret' and 'Secret' documents. Let's say a document is 'Secret Crypto'. If the person does not have the 'Crypto' clearance in addition to 'Top Secret', he cannot access that document.

BLP and lattice are essentially equivalent, and were developed at the same time.

9.2.2 The Chinese Wall

The model originally comes from finance, but has a wider use. Different firms are in competition with each other, and their clients may also be in competition with each other. A usual rule is that if you work for some company $X$ in sector $Y$, the you cannot work for any other companies in that sector $Y$ for a fixed period of time $t$. The Chinese Wall model has a mix of free choice, and mandatory access control. When the employee $e$ can choose any company from $Y$, but once the decision is done, the actions in section $Y$ are constrained. This introduces the concept of separaton of duty in access control.

The model can be expressed with two properties (from the book):

We write for each object $c$; $y(c)$ for $c$'s company , $x(c)$ for $c$'s conflict of interest class, then:

• The simple security property: Subject $s$ has access to $c$ if and only if, for all $c'$ which $s$ can read, either $ y(c) \notin x(c')$ or $y(c) = y(c') $
• The *-property: subject $s$ can write to $c$ only if $s$ cannot read any $c'$ with $x(c') \neq \emptyset $ and $y(c) \neq y(c')$

9.2.3 The BMA Model

Today the health care sector spends more money than the military on multilateral systems. It's the most instructive and important example of these kinds of systems. It's important because of healthcare privacy and safety.

The British Medical Association (BMA) hired the author to device a policy for safety and privacy of clinical information.

9.2.4 Current Privacy Issues

In the UK the politicans once decided to have one central database with medical records. The section describes through different examples how the aggregation issue will haunt the developers during design and operation. The problems also relates to other kinds of systems, e.g. for the police.

9.3.1 Basic Problems of Inference Control in Medicine

Even though names etc. are removed when data is moved to research databases, you can still identify people, e.g. by linking clinical episodes and birthdays.

To solve this, the organization that pays doctors etc. under the Medicare in the US, has three databases for patients: One with the complete records used for billing. There's beneficiary-encrypted records, where only names and social security numbers are obscured. Finally there are public access records, where all personal data is removed, Patients are only identified as e.g ' white female aged 70-74 living in Vermont'. Researchers has still found that patients can be identified by combing the data with other public-access databases, and commercial databases.

Technology used for stripping personal information from data is called Privacy Enhancing Technology (PET) Anonymisation is harder and more fragile than it seems. Companies and people who relies on it may suffer serious consequences.

This section really just presents a lot of examples that represents problems with privacy.

9.3.2 Other Applications of Inference Control

The inference control problem has been seriously studied in the context of census data. This problem is somewhat simpler than the medical record problem, as the data is more restricted when it comes to sensitive content.

If you have a great database of census data, the privacy control comes in with restrictions on what queries can be done to the database. Queries where you add circumstantial information to defeat averaging and other controls, are known as trackers.

9.3.3 The Theory of Inference Control

Sensitive statistics are statistics that meet some criteria. The goal of inference control is that a characteristic formula 's'(a database query) query set of records does not include any sensitive statistics.

Protection of sensitive data is said to be precise if a set of statistics $D$ is so that $D = P'$, where, $P$ is the set that is sensitive and must be protected, and $P'$ is the complement of $P$.

Each section describes some inference control:

9.3.4 Limitations of Generic Approaches

As with any protection technology, statistical security can only be evaluated in a particular environment and against a particular threat model. Whether it is adequate or not depends to an even greater extent than usual on the details of the application.

Then it describes some limitations with how some real world applications and problems are e.g. from the medical world.

9.3.5 The Value of Imperfect Protection

De-identification is hard, so the best way to solve the inference control problem, is to completely avoid it, by recruiting volunteers or having people opt-in.

Some kinds of security mechanism may be worse than useless if they can be compromised.

E.g. weak encryption.

The main threat to databases of personal information is mission creep Wikipedia says that is:

Mission creep is the expansion of a project or mission beyond its original goals, often after initial successes.