Chapter (1-2) CS443 Definitions

Computer security

A computer is secure when it does what it is supposed to do — and only what it is supposed to do. Simple to state, hard to verify, and increasingly beside the point.

Information security

The emphasis has shifted from the machine to the information it processes. Information is secure when it is protected from unauthorized access or alteration, and yet remains available to authorized people when they need it.

Information assurance

Not just protecting information, but knowing how much protection you have achieved. Assurance is the measurement layer on top of security — and it is the name of this course.

AT REST (Stored)

On disk, in a database, on backup tape, in object storage. Protected by encryption at rest, access control, and physical security.

IN USE (Processed)

Decrypted in memory while an application works on it. The hardest state to protect — and the one attackers increasingly target.

IN MOTION (Transferred)

Crossing a network between machines. Protected by transport encryption: TLS, VPNs, and the protocols we cover in Week 5 and Week 14.

UNSTRUCTURED (Individuals and small groups)

Short campaigns, few people, little money. Script kiddies running other people's exploits, up through people who can write their own.

STRUCTURED (Criminal organizations)

More planning, longer timelines, real financial backing, and possible corruption of or collusion with insiders. Crime online is organized the same way crime offline is.

HIGHLY STRUCTURED (Nation-states and terrorists)

Preparation measured in years, enormous funding, large organized teams. Targets include military forces and critical infrastructure.

INSIDE THE WALLS (Insiders)

More dangerous in many respects than outsiders: they already have access and knowledge, and they often know the security systems well enough to avoid detection.

COMMODITY (Viruses and worms)

The most common problem by sheer number — thousands created and released. Antivirus and patching eliminate most of it, and they are highly visible once released.

OFTEN OVERLOOKED (Everyone with physical access)

Custodial crews, contractors, partners, delivery staff. Physical access defeats most logical controls, as Chapter 8 will show.

Script kiddies (T1)

No ability to develop scripts or find new vulnerabilities. They run tools other people wrote against targets they did not choose carefully.

Exploit writers (T2)

Capable of writing scripts to exploit known vulnerabilities. Dangerous because known vulnerabilities stay unpatched for a long time.

Elite hackers (T3)

Highly technical individuals who discover new vulnerabilities and write the tools everyone below them uses.

Morris Worm, November 1988

the first worm to bring down a meaningful fraction of the Internet, and the reason CERT exists.

Kevin Mitnick, arrested February 1995

social engineering as much as technical skill; a preview of Chapter 4.

Melissa virus, March 1999

macro virus propagating through Outlook address books.

Code Red, 2001 and Slammer, 2003

worms that saturated networks within minutes of release.

Conficker, 2008–2009

millions of machines, and still found on unpatched systems years later.

U.S. electric power grid intrusions, 1997–2009

critical infrastructure as a standing target.

From 2009 onward the landscape changed: organized crime and nation-states arrived, pursuing two goals

deny you the use of your systems, or use your systems for financial gain, including theft of intellectual property and personally identifiable information.

Colonial Pipeline,

May 2021 A ransomware attack shut down the largest fuel pipeline on the U.S. East Coast, triggering panic buying and fuel shortages across several states. The entry point was not a zero-day. Attackers used a single leaked password, found in a dark-web credential dump, on a legacy VPN account that had no multi-factor authentication and had not been decommissioned

What made it possible

A password reused elsewhere and exposed in someone else's breach. An account nobody had retired. No second factor.

Specific Target vs Opportunistic

Minimizing possible avenues of attack

1. 1. Patch Everything

2. 2. Harden the system

3. 3. Repeat forever

Three approaches to Computer Security

• - Correctness

• - Isolation

• - Obfuscation

Correctness

Ensure the system is fully up to date, with every patch installed and proper controls in place. Secure software development, patching, and hardening.

Isolation

Protect the system from unauthorized use through access control, physical security, and cryptography. If they cannot reach it, they cannot exploit it.

Obfuscation

Make it difficult for an adversary to know when they have succeeded. Raises the attacker's workload — but note that this is not the same as security through obscurity.

Ethics

is a set of moral principles that guides behavior. Information security depends on trusting people to keep secrets whose disclosure would harm the organization — so trust is a foundational element of the people side of security.

Computer security

The methods used to make a single system secure. Addresses authentication and access control in broad terms.

Network security

Protecting multiple computers and devices that connect to one another — and controlling what crosses between them.

Information security / assurance

Places the focus of the security process on the data itself rather than the machinery. Assurance adds the availability of systems and information.

Cybersecurity

The umbrella term now used for the whole field: the availability of systems and information when we want them.

CIA of security

• - Confidentiality

• - Integrity

• - Availability

Confidentiality

Only individuals with the authority to view a piece of information may do so. Enforced by access control and cryptography.

Integrity

Concerns the generation and modification of data. Only authorized individuals should ever be able to create, change, or delete information.

Availability

The data — or the system itself — is available for use when the authorized user wants it. Denial of service is a security failure, not an operations problem.

Authentication

Ensures an individual is who they claim to be. Distinct from access control, which decides what they may then do.

Nonrepudiation

The ability to verify that a message was sent and received, and that the sender can be identified and verified — so the sender cannot credibly deny having sent it. Digital signatures, in Week 4, are how this is achieved.

Auditability

Whether a control can be verified to be functioning properly. A control nobody can check is a control nobody should trust — this is the assurance half of information assurance.

Operational Model

Protection = Prevention + (Detection + Response)

Govern, Identity, Protect

Detect, Respond, Recover

Session management

The activities that establish and maintain a communication channel between two parties. An application authenticates once and ascribes subsequent activity to that user. Sessions preserve state across otherwise stateless web requests and are identified by an ID known to both sides — which is exactly why session hijacking, in Week 13, works.

Exception management

Managing changes to normal processing. An important consideration during software development: the system must handle conditions outside normal policy limits and either recover, or fail and be recovered by separate action. Often nontechnical in nature.

Configuration management

The design and operation of elements that ensure the proper functional environment of a system. Key to correct IT operation, and the foundation for the baselines in Chapter 14.

Four approaches an organization can take

Host security and network security

Least priviledge

A subject — user, application, or process — should have only the rights and privileges necessary to perform its task, with no additional permissions. Limiting an object's privilege limits the harm it can cause. Trust relationships should be created for specific reasons, and the security context an application runs in should be no larger than the duties it performs.

Separation of privilege

A protection mechanism should use more than one piece of information to make an access decision. Applied to people, this is separation of duties: more than one individual must be involved. It applies to physical environments as much as to networks and hosts.

The cost of it

Separation of privilege buys checks and balances and charges you in time and money — two people where one would do, and the delay that comes with coordinating them. That cost is why it gets quietly abandoned, and why fraud investigations so often find it was.

Fail-safe defaults

When something fails, it should fail into a safe state. In practice this means default deny: deny access by default and grant it only where explicit permission exists. The operational term is implicit deny, and it applies to both authorization and access. The alternative — allow unless a specific rule forbids — fails open, and every rule you forget becomes a hole.

Economy of mechanism

Always use the simple solution when one is available. The protection mechanism should be small and simple, because small and simple is what can actually be reviewed. The everyday application is the number of services allowed to run: eliminate or disable every nonessential service and protocol.

Complete mediation

Each and every request should be verified. Caching the result of the first permission check improves performance and opens the door to permission errors — the user whose access was revoked but whose cached decision says otherwise. It also means ensuring that every operation goes through the protection mechanism, with no side doors around it.

Open design

The protection of an object should not rely on the secrecy of the protection mechanism itself. Long proven in cryptographic circles: we open our systems to third-party analysis precisely to establish that they work.

Kerckhoffs's principle

A 19th-century French cryptographer's rule: a cryptosystem should be secure even if everything about it except the key is public knowledge. Rely on a changeable secret; make the rest of the design public and open to review. Shannon's Maxim restates it — "the enemy knows the system."

Security through obscurity

Least common mechanism

Mechanisms used to access resources should be dedicated, not shared. Sharing allows crossover between channels and a protection failure — sensitive information leaking between subjects through the shared mechanism. Sandboxing, virtual machines, and separately instantiated shared libraries all exist to reduce what is held in common.

Psychological acceptability

Users have to accept the security measure. If a control is perceived as an impediment to the work someone is responsible for, the natural consequence is that they bypass it. This is routinely overlooked by security professionals focused on the technical threat, and it is the reason so many well-designed controls fail in the field.

Defense in dept

Use multiple, different defensive mechanisms so that a failure in one does not become a failure of the whole. Also called layered security. The point is not more defenses — it is defenses with different points of failure. Networks should be built the same way: perimeter, segment, host, application, data.

Diversity of defense

Complements layering by making the layers dissimilar. If an attacker knows how to get through one kind of system, a different kind may still stop them. A car has a door lock, an ignition lock, and an alarm — three unlike mechanisms. Using firewalls from different vendors is the same idea, at the cost of complexity and expertise.

Where diversity fails

Systems of the same type share the inherent weaknesses of the technology. Systems configured by the same people are probably configured with the same mistakes. And many "different" products share code lineage — nobody writes a TCP/IP stack from scratch. Diversity you did not verify is diversity you do not have.

Access control is not authentication

Three factors

Group policy

Defines for a group of users the applicable operating system and application settings and permissions. Managing people one at a time does not scale; groups are how access control survives contact with an organization of any size.

Password policy

Passwords remain the most common authentication mechanism, so the policy around them matters more than any single password does. A password policy should address how users select passwords, how frequently they must be changed, and how passwords are distributed.

A caution

Note the tension with the previous slides: a policy that mandates frequent changes is following the textbook and contradicting the evidence. Policy is a design artifact, and it is subject to the same principles as any other control.

Two families of models

(Confidentiality) Bell-LaPadula: no read up, no write down

(Confidentiality) Brewer-Nash: the Chinese Wall

(Integrity) Biba: no write up, no read down

(Integrity) Clark-Wilson: well-formed transactions