Keep it simple.
KISS is a design principle noted by U.S. Navy in 1960.
This is a good guideline whenever a problem needs to be solved. It also reflects the quality of solution.
- The simpler the systems, the easier they are to understand.
- The simpler the systems, the less likely they are to contain flaws.
Unless an entity is given explicit access to an object, it should be denied access to that object.That is, the default situation is denial of access.
For example, suppose you are writing a firewall policy.
- By default, the firewall should deny packets.
- The only exception should be allowing the packets satisfying a set of explicit conditions.
This approach is also called whitelisting.
Most file access systems work based on this principle. Also, virtually all
protected services on client/server systems work this way.
Every access must be monitored and controlled.
That is, there must be no way that can bypass the access control mechanism.
Care should be taken to ensure that the access control mechanism cannot be circumvented. For example:
- Sensitive information should be protected even during transit and in storage, which often requires data to be encrypted for complete mediation. If the information is unencrypted, the adversary may boot a different OS to circumvent file-system-based access control, or sniff traffic to circumvent access control imposed by a web application.
- Various injection attacks (e.g., buffer overflow attacks or SQL
injection attacks) will be successful if the system allows malicious data
to be injected, which implies the violation of the principle of complete
mediation.
To demonstrate the general idea behind an SQL injection attack using
sqlite. To install it, one can run the following commands in the terminal:sudo apt update sudo apt install sqlite
Now, let's start the sqlite with database filelogin.db.sqlite3 login.db
Let's create a simple tableAUTH_INFO:sqlite> CREATE TABLE AuthInfo( id TEXT, pwd TEXT );Now, we can add some entries in the table:sqlite> INSERT INTO AuthInfo VALUES ("choi", "pwdforchoi"); sqlite> INSERT INTO AuthInfo VALUES ("alice", "pwdforalice"); sqlite> INSERT INTO AuthInfo VALUES ("bob", "pwdforbob");
SELECT statements can be use to retrieve the entries from the table:sqlite> -- Use SELECT for lookup. Note that -- can be used for giving comments. sqlite> SELECT * from AuthInfo WHERE id = "choi"; choi|pwdforchoi sqlite> SELECT * from AuthInfo WHERE id = "choi" AND pwd = 'hmm...'; sqlite>
Consider the following toy authentication program based on the user id and password. The access control system will probably make a SQL query to the database.
Let's try to run the program:#!/usr/bin/python3 # auth.py import sqlite3 con = sqlite3.connect("login.db") s1 = input("id: ") s2 = input("pwd: ") query = f"SELECT * FROM AuthInfo WHERE id = '{s1}' AND pwd = '{s2}'" #print(query) cur = con.cursor() res = cur.execute(query) entry = res.fetchone() if entry: print("Access Granted") else: print("Access Denied!")$ python3 auth.py id: choi pwd: pwdforchoi Access Granted $ python3 auth.py id: choi pwd: hmm... SELECT * FROM AuthInfo WHERE id = 'choi' AND pwd = 'hmm...' Access Denied!
- Question: Suppose you don't know the password. Is there a way to
obtain "Access Granted" still?
Answer (drag your mouse):
id: choi' -- pwd: hmm...
- Question: Suppose you don't know the password. Is there a way to
obtain "Access Granted" still?
The security of a system should not depend on the obscurity of its protection mechanism.
The security of a system should not depend on potential adversaries being ignorant of its protection mechanism but rather on specific keys or passwords being kept in secret.
In cryptography, this is known as Kerckhoff's principle: a cryptosystem should be secure even if all aspects of the system except the keys being used are public knowledge.
As reverse engineering techniques continue to advance, it is unrealistic to consider binary code as a black box that divulges nothing about the inner workings of a program.
As another benefit, due to the decoupling of designs from keys, many reviewers can now examine the designs without security concern. This will provide independent confirmation of the design security.
A system should not grant permission based on a single condition.
A good example of this is multi-factor user authentication, which requires multiple techniques, say, using both password and smart card to authorize a user.
Another example is corporate purchasing.
- A line manager notifies the purchasing department.
- The purchasing department issues a purchase order.
- The store clerk records the arrival of the product.
- When receiving an invoice, the account clerk correlates it with the purchase order and issues a check.
Every process or user of the system should operate using the least
set of privileges necessary to perform the task.
For example, most office works do not need the privileges of installing new software on a corporate computer, creating new accounts or sniffing network traffic. These employees can do their jobs with fewer privileges, e.g., access to office applications and a directory to store data.
As another example, a web server's processes need not run with administrative privileges. They should run with the privileges of a less privileged user account.
Minimize the mechanisms shared by multiple users or programs.
Shared objects provide potential channels for information flow. Systems employing physical or logical separation reduce the risk from sharing.
Process isolation is one example. The memory contents of a process cannot be observed by the other processes, unless it is explicitly shared through the system calls. In a sense, the system minimizes the ways of sharing the memory --- only through the system calls.
As another example, sandboxing is the practice of isolating an application, a web browser, or a piece of code inside a safe environment. For example, a web browser sandbox lets you run browser applications in isolated environments, to block browser-based malware from spreading to the network.
As another example, in 2011, Lockheed-Martin relied not only on the security of RSA's product (SecurID), but also on the security of RSA's own IT infrastructure. Its trust in the security of RSA's own IT infrastructure was evidently misplaced; it was hacked.
Security mechanism should be easy to use.
If a protection mechanism is easy to use, it is unlikely to be avoided.
However, the more difficult a security mechanism is to use, the more likely it is that users will circumvent it to get their job done or will apply it incorrectly, thereby introducing new vulnerabilities.
Enforcing complex and difficult-to-remember passwords that need to be frequently changed for access to trivial resources, e.g., to use a white printer would be an example. Complex password requirements can also cause users to store the passwords in an unsafe manner so they don't have to remember them, such as using a sticky note or saving them in an unencrypted file.
|
Safety usability failures are estimated to kill about as many people as
road traffic accidents --- a few tens of thousands a year in the USA. The
most lethal medical devices are probably infusion pumps. This is used to
administer intravenous drugs and other fluids to patients in hospital. It
is often the case that an emergency room have equipment from different
vendors, all with different user interfaces.
If doctors and nurses press the wrong button, then the wrong dose gets administered, or the dose for an eight-hour transfusion --- patients die. |