Introduction to Security

Let’s get started with security in general, and introduce the big themes of computer security.

Unit Goals

To develop a sense of what the big questions are in the field of computer security (a.k.a. cybersecurity) and to gain a little vocabulary surrounding the goals and techniques for “doing security.”

What Is Security?

Security is prevention from harm:

Note the relationship between these fields:

Personal security (people)
Information security (data)
Computer security (systems)
Software security (code)

An information system is secure if users are unable to force it do things it was not intended to do, such as: divulge confidential information, modify or erase protected data, or fail to work because it is too slow or has crashed.

Correctness is concerned with a system always doing what it should; security is concerned with a system never doing what it shouldn’t. Depending on how we specify what exactly the correct behavior is, the terms may overlap, but the emphasis sure is different! The former focuses on use cases and the latter on misuse cases.

Correctness

Always does what it should

(considers use cases)

Security

Never does what it shouldn’t

(considers abuse cases)

Whether we are securing people, products, or organizations, security is about asset protection. That which you are protecting your assets against are called threats. Assets can be:

Tangible Assets

People, buildings, equipment

Intangible Assets

Code, data, intellectual property, service availability, reputation

Exercise: What other kinds of assets should be protected?
Exercise: (Philosophical) Is money tangible or intangible?
Exercise: Discuss the following claims. How much truth is there to each?
  • “Security is at odds with convenience”
  • “Security is at odds with liberty, freedom, or privacy”
  • “There is a difference between being secure and just feeling secure”

How Do We “Do Security”?

In order to build and maintain secure systems, we have questions to consider, strategies to employ, and a mindset to enter.

Philosophical Questions

Start with some deep thoughts:

Pillars of a Security Strategy

We should be able to deploy knowledge and tools from each of these areas:

Prevention

The construction of systems immune to attack

Detection

Alarms for intruders, performance degradation, malware, weird traffic patterns, fraud, and similar things

Reaction

Readiness to implement a disaster recovery plan, perform repairs, replace assets, and so on

Planning

Building something? Prepare yourself!

The Mindset

There is a mindset to security, much like that of a QA engineer.

The standard QA joke   joke

The security mindset is concerned with:

Simple Architectures

The more complex a system, the easier it is to attack

Pristine Source Code

Most incidents are due to sloppy code

Layers of Trust

Avoid single points of failure, defend in depth

There may also be certain ways of looking at the world like:

Every input to your program is a potential threat

...but in a well-layered system, there will some inputs you can trust. Wariness is not necessarily the same as paranoia.

Story Time

There was once this e-commerce company that did not check the bounds on the quantity field in the order, so customers figured out they could order a negative number of units of a product and ... (story continues in class)

You may be tempted to think of your users as your friends. They are also your adversaries.

But what about people in your organization? Should they be just given access to everything behind the firewall? No! Malicious insiders do exist! But even if everyone is good, maybe their machines were compromised with malware. Maybe they made a typo that wiped out data.

Then again, pragmatism and context is important too. Security is often in opposition to convenience. Think about context.

Thinking Like An Attacker

Threats are everywhere. But what kind of threats are there? What can attackers do? Understanding threats and thinking like an attacker is crucial to a good defense. Here is a very incomplete list, but it gets you started:

TypeWhat it isExamples
Eavesdropping Tapping in to a communication line Stealing info such as company secrets, military plans, credit card numbers, keys, credentials, or PII (personally identifiable information) such as SSNs, birthdates, family members, medical information
Spoofing Modifying data in transit Making it look like the sender said something they didn’t; replacing the source IP address to make it look like a packet came from somewhere else; changing a purchase shipping address to the attacker’s secret PO Box
Denial of Service Making information unavailable to users that need it. Preventing data from getting to its intended target by rerouting packets in a network; flooding a network host or router with so many packets that nothing effectively gets through; forcing a program to perform a nasty long-running computation or generate a massive amount of data; causing a program to fill up its filesystem
Breaking In Loading and executing malicious code on a victim machine or process Updating or deleting data; installing a key logger to record everything the victim does and send to another server that collects stolen data; having the host join a botnet; opening a remote shell
Exercise: Malware can enter a machine in a number of ways; two common methods are viruses and worms. Find out the difference between a virus and a worm.

How these attacks are carried out will be covered later. Right now we’re just introducing bigger themes.

Don’t forget about non-technical dimensions

Phishing is a problem too—Humans can fall for lots of stuff. Know what else is a problem? Malicious insiders.

Hackermann comic

XKCD security

Exercise: How if at all would technical and nontechnical controls be implemented to combat outside phishing attempts versus malicious insiders?
Don’t get caught up in security features

Your design and implementation should have requirements such as “only allow authorized users to access this resource“ and NOT “Make a login screen” or “Use SHA-512” or “Make sure the password has non-alphanumeric characters”.

“It is the night of March 25, 1854, and the Swedish Öst-Götha Bank is soon to be robbed. The military corporal and former farmer Nils Strid walks silently up to the bank together with his companion, the blacksmith Lars Ekström....The bank has invested in high-quality locks for the vault—more or less impossible to pick. But for blacksmith Lars it is not a big job to splinter the hinges and open the vault door backward.” [Secure By Design, Section 1.1.1.]

Attributes

It is helpful to describe attributes of a secure system. This gives you a model for structuring your security strategy. The big three are sometimes called CIA, for confidentiality, integrity, and availability :

AttributeWhat it isSome Techniques
ConfidentialityPreventing data from being disclosed (leaked) to the wrong people, either accidentally or by malicious eavesdroppersEncryption (both at rest and in transit), User authentication (passwords, passphrases, tokens with cryptographic digital signatures), User authorization (roles and permissions)
IntegrityPreventing data from being accidentally or maliciously modified or corrupted (or if there is tampering, to know that it happened)Message Authentication Codes (MACs), CRCs, Checksums, Secure programming practices
AvailabilityServices must always be accessible and up as much as possible.Monitoring, Fault tolerance (e.g., secure software practices such as bounding numbers), Restore/restart, Scaling (scale-out so attackers cannot block all paths), Upstream filtering

For more on CIA, you can read this short introductory article.

Exercise: Describe a scenario in which Accountability and Integrity are required but Confidentiality is not.
Exercise: Lack of availability is not just caused by a denial of service attack, but can occur by poor coding techniques and bugs, such as starvation and deadlock, race conditions, infinite loops, inefficient algorithms, not freeing memory or resources. What other types of software problems could cause lack of availability?

Sometimes you will see others:

AttributeWhat it isSome Techniques
AccountabilityTracing actions back to the person that performed themLogs
Non-repudiationThe impossibility of someone denying they carried out an actionTrusted third parties such as Certificate Authorities
Exercise: Is non-repudiation even possible?
Exercise: Research the notion of Plausible Deniability and its applications in cryptography and programming.

Security is System-Wide

There is no one security module in a system. Just like correctness is a concern at all levels, so is security! There’s a quote that says “Security is a concern, not a feature”

It is an important quote.

Security is a concern, not a feature.

Again, security is not a feature that you can add on at the end of a project. It is a concern that must be addressed at every level of the system.

Hardware Level

At this level you will find:

Operating System Level

The O.S. can provide:

Network Level

Here you will see things like:

Application Level

Applications should have security in their design (authentication, authorization, permissions, roles, etc.) and should implement range checks, disallow weak passwords, and handle password-reset properly. They might even expire passwords and support security questions, but these two things are very controversial.

Exercise: Why are password expiration and security questions controversial? What are the downsides? Do those organizations that use these things even bother to mitigate the downsides?

Programmers should be aware of as many known categories of vulnerabilities as possible and know how to avoid them. There are zillions of known vulnerabilities; some are generic, some are related to C programming (pointers, etc.) and some specific to webapps, such as the OWASP Top Ten (But don’t just focus on the top 10, focus on all of them.)

Secure software development is a fascinating field. There are two main themes here. (1) You may be surprised how far careful design, particularly the understanding of your domain, goes in prevention. (2) You have to consider security at every level of the software lifecycle:

DuringYou might
Requirements DefinitionMisstate or omit permissions and roles, or fail to capture any number of security requirements
Architecture and DesignIncorrectly specify security zones and boundaries, or simply produce designs with logic errors
ProgrammingIntroduce bugs (surprise), especially those that create technical vulnerabilities
Code ReviewsMiss a vulnerability
TestingMiss a vulnerability
DeploymentUse the wrong configuration script or environment variables
MaintenanceIntroduce a regression (a flaw that was not there before)

Here’s a little step-by-step guide that elaborates just a little bit more.

The Human Level

Be wary about phishing and other personal scams. People can pretend to be someone else (misrepresentation) and just ask you for credentials or even money. These may incidentally use a network but can also happen over other communication channels, including face-to-face.

And don’t give network analyzer tools (like packet filters, packet sniffers, tcpdump and others) to non-trusted folks.

More generally, within an organization:

You should even be careful about the rights you give even to trusted people, because their machines may be compromised (be running malware)!

Areas of Study

If you like to divide up a field into chunks for studying, here’s a somewhat arbitrary and very rough start, identifying three areas:

SECURITY ARCHITECTURE
(outside the code)		 SOFTWARE SECURITY
(inside the code)
Defense, intrusion and malware detection; Auditing; Firewalls and similar things; Forensics; Anti-virus software; Configuring security groups, VPNs, zones, and so on; Security protocols such as IPsec and others; Management, governance, compliance, ethical, and legal issues; Enterprise cyberoperations; Privacy. The practice of secure software development (at all levels: requirements, analysis, design, coding, code reviews, testing, deployment, maintenance); Knowledge of known vulnerabilities and strategies and tactics to mitigate them.
MATHEMATICAL FOUNDATIONS
Cryptology = Cryptography + Cryptanalysis; How to prevent eavesdropping; How to ensure the integrity of messages; Digital signatures; Symmetric vs. asymmetric cryptography; Secure distribution of keys.

Henry Jiang has made an awesome map of the field:

henry-jiang-cybersecurity-domains.png

You can find an extension of the diagram here.

Vocabulary

It is helpful to agree on some basic vocabulary up front. Let’s start with six basic terms:

Defect
A problem that causes a program to be incorrect or insecure. Can be a “bug” (programming problem that is easy to fix) or “flaw” (more of a design problem)
Vulnerability
A defect that can be targeted by (exploited by) an attacker to do the bad things (e.g., weak passwords, no passwords, unchecked array bounds).
Exploit
Code or data crafted by the adversary that causes the bad things to happen (generally injected into the victim machine through a vulnerability)
Threat
(1) The potential attacks themselves, e.g., certain kinds of exploits, (2) Your adversaries (people).
Risk
A measure of how bad things can be, i.e., the probability of a problem occurring times the severity of its impact
Failure
The occurrence of a program not doing what it was supposed to do.

The adversary wants to find vulnerabilities and exploit them. The system designers want to prevent vulnerabilities or at least make them really hard to exploit if they do get through the design, implementation, review, testing, and deployment safety protocols. The goal is to design and implement the software so that no vulnerabilities are introduced.

There are hundreds more terms you will be learning. To get a feel for more terms, browse the NICCS glossary.

Exercise: Find 20 interesting terms at the NICCS Glossary that look interesting, and write down their definitions. Consider making flash cards and testing yourself.

Some Nice Resources

Don’t miss:

Summary

We’ve covered:

  • Key ideas and vocabulary
  • Characteristics of secure systems
  • Security attributes
  • How security is applied at different levels of a system
  • Topics in the study of security
  • Where to find more information