Introduction to Security

What Is Security?

Security is prevention from harm:

• Personal security is the protection of a person’s livelihood.
• Information security (InfoSec) is the protection of information from being accessed, used, misused, modified, or destroyed by the wrong people.
• Computer Security (Cybersecurity) is information security in the world of digital assets (software, hardware, communication systems).
• Software Security is the study and application of writing robust software that is secure.

Note the relationship between these fields:

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.

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:

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:

• How do we know if a system is vulnerable?
• How do we defend (prevent vulnerabilities or make them harder to exploit)?
• How do we attack? (Because knowing this helps us defend—and besides, maybe sometimes, the attackers are the good people)
• How do we know if a system has been exploited / compromised / hacked / pwned?
• Can we prove a system immune from attacks?
• How might we even begin to enumerate all possible threats?
• Are systems actually secure? Or just more-or-less secure?
• How can we become secure software developers? Or security-minded developers?

Pillars of a Security Strategy

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

Planning

Building something? Prepare yourself!

• Know the threats, know the weaknesses, and capture them in a threat model.
• Design security in, at all levels, because (and these are words to live by) “Security is a concern, not a feature”
• Plan for defense, detection, mitigation, and recovery

The Mindset

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

The security mindset is concerned with:

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

...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.

Pragmatics

Watch the following video and note these takeaways: (1) Backdoors (lawful intercepts) get exploited by hackers, (2) Even with a huge list of mitigation strategies and tactics, it just takes one person to miss just one of the hundreds of checklist items to allow attackers in, (3) Stay current on your security patches and replace old vulnerable pieces of hardware constantly. If you are a user, (4) always use messaging systems with end-to-end encryption.

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:

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.

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 :

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

Sometimes you will see others:

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.

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:

• User and Supervisor (Kernel) modes on processors
• Memory protection (partially implemented in the processor instruction set architecture)

Operating System Level

The O.S. can provide:

• Per-user or per-group protections on files, processes, ports, and devices (which extend to processes as these are run by a certain user)
• Encryption of password files (using one-way hash functions and salts)
• A shadow password file scheme to make dictionary attacks harder. Here /etc/password is -rw-r--r-- root and holds everything but the passwords, while /etc/shadow is -r-------- root and has uids and passwords.

Network Level

Here you will see things like:

• Firewalls (allow packets through based on rules such as origin, type, size, port)
• Smart router software that can detect denial of service attempts and even check the content of packets looking for known malware patterns
• Implementation of protocols such as IPsec (at the network layer), SSL (at transport layer), secure ethernet and wireless security (at link layer), and PGP and friends (at application layer).
• Use of VPNs

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.

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:

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:

• Who creates the permission lists? Who can see these lists? Who can change them?
• Who is in charge of reviewing, auditing, and maintaining the permission lists?

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:

Henry Jiang has made an awesome map of the field:

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.

Some Nice Resources

Don’t miss:

• Tom Scott Security Videos on YouTube, great for beginners:
  • Hacking Websites with SQL Injection (2013-10-09)
  • Cracking Websites with Cross Site Scripting (2013-10-23)
  • Hashing Algorithms and Security (2013-11-08)
  • How NOT to Store Passwords! (2013-11-20)
  • Cross Site Request Forgery (2013-12-03)
  • The Attack That Could Disrupt The Whole Internet (2014-03-14)
  • Buffer Exploits and Buffer Overflows (2014-04-08)
  • How The Self-Retweeting Tweet Worked: Cross-Site Scripting (XSS) and Twitter (2014-06-11)
  • The Shellshock Bug In About Four Minutes (2014-09-25)
  • Why Electronic Voting is a BAD Idea (2014-12-18)
  • The Moonpig Bug (2015-01-06)
  • The Effective Power Bug (2015-05-29)
  • The Link That Can Crash Chrome (2015-09-22)
  • Man in the Middle Attacks & Superfish (2015-10-23)
  • Why The Government Shouldn't Break WhatsApp (2017-07-03)
  • The Lava Lamps That Help Keep The Internet Secure (2017-11-06)
  • How The Black Point Message Crashes Android Apps (2018-05-04)
  • The Two Generals’ Problem (2019-08-12)
  • Why Electronic Voting Is Still A Bad Idea (2019-12-09)
  • Why You Should Turn On Two Factor Authentication (2020-08-03)
  • ...and more
• Low Level’s YouTube channel, with dozens of videos on cybersecurity.
• OWASP. Make sure to browse some of their projects, some of the attacks they’ve documented, and some of their Cheat Sheets.
• CERT. Find an amazing wealth of information here.
• CVE (Common Vulnerabilities and Exposures). Over a hundred thousand on this list.
• CWE (Common Weakness Enumeration). Another big list.
• Hacksplaining (A fun way to learn. Great content.)
• Cloudflare Learning Center (Sorry for the “product placement” but this is a really good resource).
• A Secure Coding Tutorial (this one has ads too).
• Security course at Hacker101.com
• If you like StackExchange sites, there is Cryptography and Information Security, among others, with some great Q & A.
• A collection of links to 50 resources.

Recall Practice

Here are some questions useful for your spaced repetition learning. Many of the answers are not found on this page. Some will have popped up in lecture. Others will require you to do your own research.

1. Security is about the protection of ________________.
   Assets
2. The term cybersecurity is a synonym for ________________.
   Computer Security
3. Correctness is related to security in that the correctness is concerned with ensuring a system always ________________ and security is concerned with ensuring a system never ________________.
   (Always) does what it is supposed to
   (Never) does what it is not supposed to
4. Correctness involves testing ________________cases while security involves testing ________________ cases.
   Use
   Misuse (or Abuse)
5. What do we call the things we protect our assets from?
   Threats
6. A security strategy should encompass: (1) prevention, (2) ________________, and (3) ________________.
   Detection
   Reaction
7. What should be created in the early stages of planning a system so that security is properly address throughout the software life cycle?
   A threat model
8. “Security is a ________________, not a ________________.”
   Concern
   Feature
9. Every input to a program is a ________________.
   Potential threat
10. Name three aspects of a security mindset.
    Simple architectures
    Pristine source code
    Layers of trust
    (Other answers are possible)
11. What are some high level goals that attackers may have?
    Eavesdropping, spoofing, denial of service, breaking in.
    Were you just going to give the one word answer “profit”?
12. What kinds of security issues are not under the realm of software security?
    Hardware security
    Physical security (locks)
    Human factors (susceptibility to bribes, threats, and phishing)
13. What happened on March 25, 1854 to the Öst-Götha Bank in Sweden?
    It was robbed because a blacksmith was able to remove the vault hinges, despite there being high quality locks on the vault
14. The statement “The system must have a login screen” is a terrible security requirement. What should be said instead?
    Only authenticated users may perform all operations
15. What is CIA in software security?
    Confidentiality, Integrity, Availability
16. A successful compromise of confidentiality causes a system to do what?
    Divulge information the attacker should not have
17. A successful compromise of integrity causes what to happen?
    Important data to be modified or deleted, or malicious content (malware, bots) to be added
18. A successful compromise of availability causes a system to do what?
    Slow to a crawl, fail to respond to all requests, or crash
19. What is the difference between authentication and authorization?
    Authentication is ensuring someone is who they say they are
    Authorization is ensuring someone has the permission to do something
20. What is non-repudiation?
    The impossibility of someone denying that they performed an action
21. What kind of security features can the hardware provide?
    It can allow certain machine instructions to take place only in kernel mode (not user mode) so regular users can not execute harmful commands.
    It can set read/write/execute permissions on memory blocks, so for example attackers can not inject code into memory and then run it.
22. What kind of security features can the operating system provide?
    It can protect certain resources (files, processes, memory blocks, devices) so they can only be accessed by certain users
23. What kind of security features can the network services provide?
    Firewalls, anti-virus, packet filtering, encryption at different layers
24. What are some human factors in security?
    Malicious insiders, susceptibility to bribes, susceptibility to trickery
25. What is the difference between a threat and an exploit?
    A threat is something that could happen; an exploit is the actual execution of an attack that compromises confidentiality, integrity, or availability. You might also see the term “exploit” for the code or data itself that carries out the attack, though that is more properly referred to as the “payload”.
26. How do people usually distinguish the terms bug and flaw?
    A bug is a programming mistake that is generally easy to fix; a flaw is a problem in the design
27. What is a risk?
    A measure of how bad things could be

Summary