Contents in Detail

Cover Page

Title Page

Copyright Page

Dedication

About the Author

About the Technical Reviewer

CONTENTS IN DETAIL

ACKNOWLEDGMENTS

INTRODUCTION

Who Should Read This Book?

About This Book

1 WHAT IS INFORMATION SECURITY?

Defining Information Security

When Are You Secure?

Models for Discussing Security Issues

Attacks

Defense in Depth

Summary

Exercises

2 IDENTIFICATION AND AUTHENTICATION

Identification

Authentication

Common Identification and Authentication Methods

Summary

Exercises

3 AUTHORIZATION AND ACCESS CONTROLS

What Are Access Controls?

Implementing Access Controls

Access Control Models

Physical Access Controls

Summary

Exercises

4 AUDITING AND ACCOUNTABILITY

Accountability

Security Benefits of Accountability

Auditing ...

FOUNDATIONS OF INFORMATION SECURITY

A Straightforward Introduction

by Jason Andress

San Francisco

FOUNDATIONS OF INFORMATION SECURITY. Copyright © 2019 by Jason Andress.

All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system, without the prior written permission of the copyright owner and the publisher.

ISBN-10: 1-7185-0004-1ISBN-13: 978-1-7185-0004-4

Publisher: William PollockProduction Editor: Meg SneeringerCover Illustration: Rick ReeseDevelopmental Editor: Frances SauxTechnical Reviewer: Cliff JanzenCopyeditor: Kim WimpsettCompositor: Meg SneeringerProofreader: James FraleighIndexer: Beth Nauman-Montana

For information on distribution, translations, or bulk sales, please contact ...

Le meglio è l’inimico del bene.

—Voltaire

About the Author

Dr. Jason Andress is a seasoned security professional, security researcher, and technophile. He has been writing on security topics for over a decade, covering data security, network security, hardware security, penetration testing, and digital forensics, among others.

About the Technical Reviewer

Since the early days of Commodore PET and VIC-20, technology has been a constant companion (and sometimes an obsession!) to Cliff. He discovered his career passion when he moved into information security in 2008 after a decade of IT operations. Since that time, Cliff is grateful to have had the opportunity to work with and learn from some of the best people in the industry including Jason and the fine people at No Starch. Cliff spends a majority of the work day managing and mentoring a great team, but strives to stay technically relevant by tackling everything from security policy reviews to penetration testing. He feels lucky to have a career that is also his favourite hobby and a wife that supports him.

BRIEF CONTENTS

Acknowledgments

Introduction

Chapter 1: What Is Information Security?

Chapter 2: Identification and Authentication

Chapter 3: Authorization and Access Controls

Chapter 4: Auditing and Accountability

Chapter 5: Cryptography

Chapter 6: Compliance, Laws, and Regulations

Chapter 7: Operations Security

Chapter 8: Human Element Security

Chapter 9: Physical Security

Chapter 10: Network Security

Chapter 11: Operating System Security

Chapter 12: Mobile, Embedded, and Internet of Things Security

Chapter 13: Application Security

Chapter 14: Assessing Security

Notes

Index

CONTENTS IN DETAIL

ACKNOWLEDGMENTS

INTRODUCTION

Who Should Read This Book?

About This Book

1
WHAT IS INFORMATION SECURITY?

Defining Information Security

When Are You Secure?

Models for Discussing Security Issues

The Confidentiality, Integrity, and Availability Triad

The Parkerian Hexad

Attacks

Types of Attacks

Threats, Vulnerabilities, and Risk

Risk Management

Incident Response

Defense in Depth

Summary

Exercises

2
IDENTIFICATION AND AUTHENTICATION

Identification

Who We Claim to Be

Identity Verification

Falsifying Identification

Authentication

Factors

Multifactor Authentication

Mutual Authentication

Common Identification and Authentication Methods

Passwords

Biometrics

Hardware Tokens

Summary

Exercises

3
AUTHORIZATION AND ACCESS CONTROLS

What Are Access Controls?

Implementing Access Controls

Access Control Lists

Capabilities

Access Control Models

Discretionary Access Control

Mandatory Access Control

Rule-Based Access Control

Role-Based Access Control

Attribute-Based Access Control

Multilevel Access Control

Physical Access Controls

Summary

Exercises

4
AUDITING AND ACCOUNTABILITY

Accountability

Security Benefits of Accountability

Nonrepudiation

Deterrence

Intrusion Detection and Prevention

Admissibility of Records

Auditing

What Do You Audit?

Logging

Monitoring

Auditing with Assessments

Summary

Exercises

5
CRYPTOGRAPHY

The History of Cryptography

The Caesar Cipher

Cryptographic Machines

Kerckhoffs’s Principles

Modern Cryptographic Tools

Keyword Ciphers and One-Time Pads

Symmetric and Asymmetric Cryptography

Hash Functions

Digital Signatures

Certificates

Protecting Data at Rest, in Motion, and in Use

Protecting Data at Rest

Protecting Data in Motion

Protecting Data in Use

Summary

Exercises

6
COMPLIANCE, LAWS, AND REGULATIONS

What Is Compliance?

Types of Compliance

Consequences of Noncompliance

Achieving Compliance with Controls

Types of Controls

Key vs. Compensating Controls

Maintaining Compliance

Laws and Information Security

Government-Related Regulatory Compliance

Industry-Specific Regulatory Compliance

Laws Outside of the United States

Adopting Frameworks for Compliance

International Organization for Standardization

National Institute of Standards and Technology

Custom Frameworks

Compliance amid Technological Changes

Compliance in the Cloud

Compliance with Blockchain

Compliance with Cryptocurrencies

Summary

Exercises

7
OPERATIONS SECURITY

The Operations Security Process

Identification of Critical Information

Analysis of Threats

Analysis of Vulnerabilities

Assessment of Risks

Application of Countermeasures

Laws of Operations Security

First Law: Know the Threats

Second Law: Know What to Protect

Third Law: Protect the Information

Operations Security in Our Personal Lives

Origins of Operations Security

Sun Tzu

George Washington

Vietnam War

Business

Interagency OPSEC Support Staff

Summary

Exercises

8
HUMAN ELEMENT SECURITY

Gathering Information for Social Engineering Attacks

Human Intelligence

Open Source Intelligence

Other Kinds of Intelligence

Types of Social Engineering Attacks

Pretexting

Phishing

Tailgating

Building Security Awareness with Security Training Programs

Passwords

Social Engineering Training

Network Usage

Malware

Personal Equipment

Clean Desk Policies

Familiarity with Policy and Regulatory Knowledge

Summary

Exercises

9
PHYSICAL SECURITY

Identifying Physical Threats

Physical Security Controls

Deterrent Controls

Detective Controls

Preventive Controls

Using Physical Access Controls

Protecting People

Physical Concerns for People

Ensuring Safety

Evacuation

Administrative Controls

Protecting Data

Physical Concerns for Data

Accessibility of Data

Residual Data

Protecting Equipment

Physical Concerns for Equipment

Site Selection

Securing Access

Environmental Conditions

Summary

Exercises

10
NETWORK SECURITY

Protecting Networks

Designing Secure Networks

Using Firewalls

Implementing Network Intrusion Detection Systems

Protecting Network Traffic

Using Virtual Private Networks

Protecting Data over Wireless Networks

Using Secure Protocols

Network Security Tools

Wireless Protection Tools

Scanners

Packet Sniffers

Honeypots

Firewall Tools

Summary

Exercises

11
OPERATING SYSTEM SECURITY

Operating System Hardening

Remove All Unnecessary Software

Remove All Unessential Services

Alter Default Accounts

Apply the Principle of Least Privilege

Perform Updates

Turn On Logging and Auditing

Protecting Against Malware

Anti-malware Tools

Executable Space Protection

Software Firewalls and Host Intrusion Detection

Operating System Security Tools

Scanners

Vulnerability Assessment Tools

Exploit Frameworks

Summary

Exercises

12
MOBILE, EMBEDDED, AND INTERNET OF THINGS SECURITY

Mobile Security

Protecting Mobile Devices

Mobile Security Issues

Embedded Security

Where Embedded Devices Are Used

Embedded Device Security Issues

Internet of Things Security

What Is an IoT Device?

IoT Security Issues

Summary

Exercises

13
APPLICATION SECURITY

Software Development Vulnerabilities

Buffer Overflows

Race Conditions

Input Validation Attacks

Authentication Attacks

Authorization Attacks

Cryptographic Attacks

Web Security

Client-Side Attacks

Server-Side Attacks

Database Security

Protocol Issues

Unauthenticated Access

Arbitrary Code Execution

Privilege Escalation

Application Security Tools

Sniffers

Web Application Analysis Tools

Fuzzers

Summary

Exercises

14
ASSESSING SECURITY

Vulnerability Assessment

Mapping and Discovery

Scanning

Technological Challenges for Vulnerability Assessment

Penetration Testing

The Penetration Testing Process

Classifying Penetration Tests

Targets of Penetration Tests

Bug Bounty Programs

Technological Challenges for Penetration Testing

Does This Really Mean You’re Secure?

Realistic Testing

Can You Detect Your Own Attacks?

Secure Today Doesn’t Mean Secure Tomorrow

Fixing Security Holes Is Expensive

Summary

Exercises

NOTES

INDEX

ACKNOWLEDGMENTS

I want to thank my wife for bearing with me through another writing project, especially during my excessive complaining and foot dragging over (ahem) certain chapters <3.

I also want to thank the whole crew at No Starch Press for all their time and hard work in making this a better book. Without all the many rounds of editing, reviewing, and feedback, this book would have been a considerably less polished version of itself.

INTRODUCTION

When I was in school, I was faced with a choice between pursuing a concentration in either information security or software engineering. The software engineering courses had terribly boring-sounding titles, so information security it was. Little did I know what a twisted and winding path I’d embarked on.

Information security as a career can take you many different places. Over the years, I’ve dealt with large-scale malware outbreaks, collected forensic information for court cases, hunted for foreign hackers in computer systems, hacked into systems and applications (with permission!), pored over an astonishing amount of log data, implemented and maintained all manner of security tooling, authored many thousands of lines of code to fit square pegs into round holes, worked on open source projects, spoken at security conferences, taught classes, and written somewhere into the upper regions of hundreds of thousands of words on the topic of security.

This book surveys the information security field as a whole. It’s well-suited to anyone wondering what people mean when they use the term information security—or anyone interested in the field and wondering where to start. The chapters offer clear, nontechnical explanations of how information security works and how to apply these principles to your own career. It should help you learn about information security without making you consult a massive textbook. I’ll first cover the fundamental ideas, such as authentication and authorization, needed to understand the field’s key concepts, such as the principle of least privilege and various security models. I’ll then dive into a survey of real-world applications of these ideas in the areas of operations, human, physical, network, operating system, mobile, embedded, Internet of Things (IoT), and application security. I’ll finish up by looking at how to assess security.

Who Should Read This Book?

This book will be a valuable resource to beginning security professionals, as well as to network and system administrators. You should use the information provided to develop a better understanding of how you protect your information assets and defend against attacks, as well as how to apply these concepts systematically to make your environment more secure.

Those in management positions will find this information useful as well, because it should help you develop better overall security practices for your organizations. The concepts discussed in this book can be used to drive security projects and policies and to mitigate some of the issues discussed.

About This Book

This book is designed to take you through a foundational understanding of information security from the ground up, so it’s best read from start to finish. Throughout the book you will see numbered references to the Notes section at the end of the book, where you can find more information on some of these topics. Here’s what you’ll find in each chapter:

Chapter 1: What Is Information Security? Introduces some of the most basic concepts of information security, such as the confidentiality, integrity, and availability triad; basic concepts of risk; and controls to mitigate it.

Chapter 2: Identification and Authentication Covers the security principles of identification and authentication.

Chapter 3: Authorization and Access Controls Discusses the use of authorization and access controls, which are means of determining who or what can access your resources.

Chapter 4: Auditing and Accountability Explains the use of auditing and accountability for making sure you’re aware of what people are doing in your environment.

Chapter 5: Cryptography Covers the use of cryptography for protecting the confidentiality of your data.

Chapter 6: Compliance, Laws, and Regulations Outlines the laws and regulations relevant to information security and what it means to comply with them.

Chapter 7: Operations Security Covers operations security, which is the process you use to protect your information.

Chapter 8: Human Element Security Explores issues pertaining to the human element of information security, such as the tools and techniques that attackers use to con us and how to defend against them.

Chapter 9: Physical Security Discusses the physical aspects of information security.

Chapter 10: Network Security Examines how you might protect your networks from a variety of different angles, such as network design, security devices, and security tooling.

Chapter 11: Operating System Security Explores the strategies you can use for securing the operating system, such as hardening and patching, and the steps that you can take to do so.

Chapter 12: Mobile, Embedded, and Internet of Things Security Covers how to ensure security for mobile devices, embedded devices, and IoT devices.

Chapter 13: Application Security Considers the various methods for securing applications.

Chapter 14: Assessing Security Discusses tools such as scanning and penetration testing that you can use to suss out security issues in your hosts and applications.

Writing this book was an adventure for me, as always. I hope you enjoy the result and that your understanding of the world of information security expands. The security world can be an interesting and, at times, hair-raising field to work in. Welcome and good luck!

1WHAT IS INFORMATION SECURITY?

Today, many of us work with computers, play on computers at home, go to school online, buy goods from merchants on the internet, take our laptops to the coffee shop to read emails, use our smartphones to check our bank balances, and track our exercise with sensors on our wrists. In other words, computers are ubiquitous.

Although technology allows us to access a host of information with only a click of the mouse, it also poses major security risks. If the information on the systems used by our employers or our banks becomes exposed to an attacker, the consequences could be dire indeed. We could suddenly find the contents ...

2
IDENTIFICATION AND AUTHENTICATION

When you’re developing security measures, whether they’re specific mechanisms or entire infrastructures, identification and authentication are key concepts. In short, identification makes a claim about what someone or something is, and authentication establishes whether this claim is true. You can see such processes taking place daily in a wide variety of ways.

One common example of an identification and authentication transaction is the use of payment cards that require a personal identification number (PIN). When you swipe the magnetic strip on the card, you’re asserting that you’re the person indicated on the card. At this point, you’ve given your identification, but nothing more. When you’re prompted to enter the PIN associated with the card, you’re completing the authentication portion of the transaction, proving you’re the legitimate cardholder.

Some of the identification and authentication methods that we use daily are particularly fragile, meaning they depend largely on the honesty and diligence of those involved in the transaction. If you show your ID card to buy alcohol, for example, you’re asking people to trust that your ID is genuine and accurate; they can’t authenticate it unless they have access to the system that maintains the ID in question. We also depend on the competence of the person or system performing the authentication; they must be capable not only of performing the act of authentication but also of detecting false or fraudulent activity.

You can use several methods for identification and authentication, from requiring simple usernames and passwords to implementing purpose-built hardware tokens that serve to establish your identity in multiple ways. In this chapter, I’ll discuss several of these methods and explore their uses.

Identification

Identification, as you just learned, is simply an assertion of who we are. This may include who we claim to be as people, who a system claims to be over the network, or who the originating party of an email claims to be. You’ll see some methods for determining identity and examine how trustworthy those methods are.

Who We Claim to Be

Who we claim to be is a tenuous concept at best. We can identify ourselves by our full names, shortened versions of our names, nicknames, account numbers, usernames, ID cards, fingerprints, or DNA samples. Unfortunately, with a few exceptions, such methods of identification are not unique, and even some of the supposedly unique methods of identification, such as fingerprints, can be duplicated.

Who we claim to be can, in many cases, be subject to change. For instance, women often change their last names upon getting married. In addition, we can generally change logical forms of identification—such as account numbers or usernames—easily. Even physical identifiers, such as height, weight, skin color, and eye color, can change. One of the most crucial factors to realize is that a claim of identity alone is not enough.

Identity Verification

Identity verification is a step beyond identification, but it’s still a step short of authentication, which I’ll discuss in the next section. When you’re asked to show a driver’s license, Social Security card, birth certificate, or other similar form of identification, this is generally for identity verification, not authentication. It’s the rough equivalent of someone claiming the identity John Smith; you asking if the person is indeed John Smith and being satisfied with an answer of “Sure, I am” from the person (plus a little paperwork).

We can take the example a bit further and validate the form of identification (say, a passport) against a database holding an additional copy of the information that it contains, matching the photograph and physical specifications with the person standing in front of us. This may get us a bit closer to ensuring we’ve correctly identified the person, but it still doesn’t qualify as authentication; we may have validated the status of the ID itself, and we know that the person meets the general specifications of the person it was originally issued to, but we’ve taken no steps to prove that the person is really the right one. The more than we trend toward verification and away from authentication, the weaker our controls are.

Computer systems use identity verification, too. When you send an email, the identity you provide is taken to be true; the system rarely takes any additional steps to authenticate you. Such gaps in security contribute to the enormous amount of spam traffic, which Cisco’s Talos Intelligence Group estimated to have accounted for approximately 85 percent of all emails sent from mid-2017 to mid-2018.¹

Falsifying Identification

As I’ve discussed, methods of identification are subject to change. As such, they are also subject to falsification. Minors often use fake IDs to get into bars or nightclubs, while criminals and terrorists might use them for a variety of more nefarious tasks. You could use some methods of identification, such as birth certificates, to gain additional forms of identification, such as Social Security cards or driver’s licenses, thus strengthening a false identity.

Identity theft based on falsified information is a major concern today; identity thieves stole an estimated $16.8 billion from US consumers in 2017.² This type of attack is unfortunately common and easy to execute. Given a minimal amount of information—usually a name, address, and Social Security number are sufficient—it’s possible to impersonate someone just enough to be able to conduct a variety of transactions in their name, such as opening a line of credit. Such crimes occur because many activities lack authentication requirements. Although most people think identity verification is sufficient, verification is easy to circumvent by using falsified forms of identification.

Many of the same difficulties exist in computer systems and environments. For example, it’s entirely possible to send an email from a falsified email address. Spammers use this tactic on a regular basis. I’ll address such issues at greater length in Chapter 9.

Authentication

In information security, authentication is the set of methods used to establish whether a claim of identity is true. Note that authentication does not decide what the party being authenticated is permitted to do; this is a separate task, known as authorization. I’ll discuss authorization in Chapter 3.

Factors

There are several approaches to authentication: something you know, something you are, something you have, something you do, and where you are. These approaches are known as factors. When you’re attempting to authenticate a claim of identity, you’ll want to use as many factors as possible. The more factors you use, the more positive your results will be.

Something you know, a common authentication factor, includes passwords or PINs. However, this factor is somewhat weak, because if the information the factor depends on is exposed, your authentication method may no longer be unique.

Something you are is a factor based on the relatively unique physical attributes of an individual, often referred to as biometrics. Although biometrics can include simple attributes such as height, weight, hair color, or eye color, these aren’t usually distinctive enough to make very secure identifiers. Complex identifiers such as fingerprints, iris or retina patterns, or facial characteristics are more common. These are a bit stronger than, say, a password, because forging or stealing a copy of a physical identifier is somewhat more difficult, although not impossible. There is some question as to whether biometrics truly count as an authentication factor or whether they only constitute verification. I’ll discuss this again later in this chapter, when I cover biometrics in greater depth.

Something you have is a factor generally based on a physical possession, although it can extend into some logical concepts. Common examples are automatic teller machine (ATM) cards, state or federally issued identity cards, or software-based security tokens, as shown in Figure 2-1.³ Some institutions, such as banks, have begun to use access to logical devices, such as cell phones or email accounts, as methods of authentication, as well.

Figure 2-1: Sending a security token to a mobile phone is a common authentication method.

This factor can vary in strength depending on the implementation. If you wanted to use a security token sent to a device that doesn’t belong to you, you’d need to steal the device to falsify the authentication method. On the other hand, if the security token was sent to an email address, it would be much easier to intercept, and you’d have a measure of considerably less strength.

Something you do, sometimes considered a variation of something you are, is a factor based on the actions or behaviors of an individual. This may include an analysis of the individual’s gait or handwriting or of the time delay between keystrokes as he or she types a passphrase. These factors present a strong method of authentication and are difficult to falsify. They do, however, have the potential to incorrectly reject legitimate users at a higher rate than some of the other factors.

Where you are is a geographically based authentication factor. This factor operates differently than the other factors, as it requires a person to be present in a specific location. For example, when changing an ATM PIN, most banks will require you to go into a branch, at which point you will also be required to present your identification and account number. If the bank allowed the PIN to be reset online, an attacker could change your PIN remotely and proceed to clean out your account. Although potentially less useful than some of the other factors, this factor is difficult to counter without entirely subverting the system performing the authentication.

Multifactor Authentication

Multifactor authentication uses one or more of the factors discussed in the preceding section. When you’re using only two factors, this practice is also sometimes called two-factor authentication.

Let’s return to the ATM example because it illustrates multifactor authentication well. In this case, you use something you know (your PIN) and something you have (your ATM card). Your ATM card serves as both a factor for authentication and a form of identification. Another example of multifactor authentication is writing checks. In this case, you’re using something you have (the checks themselves) and something you do (signing them). Here, the two factors involved in writing a check are rather weak, so you sometimes see a third factor—a fingerprint—used with them.

Depending on the factors selected, you can assemble stronger or weaker multifactor authentication schemes particular to each situation. In some cases, although certain methods may be more difficult to defeat, they’re not practical to implement. For example, DNA makes for a strong method of authentication but isn’t practical in most situations. In Chapter 1, I said that your security should be proportional to what you’re protecting. You certainly could install iris scanners on every credit card terminal, but this would be expensive, impractical, and potentially upsetting to customers.

Mutual Authentication

Mutual authentication is an authentication mechanism in which both parties in a transaction authenticate each other. These parties are typically software-based. In the standard, one-way authentication process, the client authenticates to the server. In mutual authentication, not only does the client authenticate to the server, but the server authenticates to the client. Mutual authentication often relies on digital certificates, which I’ll discuss in Chapter 5. Briefly, both the client and the server would have a certificate to authenticate the other.

In cases where you don’t perform mutual authentication, you leave yourself open to impersonation attacks, often referred to as man-in-the-middle attacks. In a man-in-the-middle attack, the attacker inserts himself between the client and the server. The attacker then impersonates the server to the client and the client to the server, as shown in Figure 2-2, by circumventing the normal pattern of traffic and then intercepting and forwarding the traffic that would normally flow directly between the client and the server.

Figure 2-2: A man-in-the-middle attack

This is typically possible because the attacker needs to subvert or falsify authentication only from the client to the server. If you implement mutual authentication, this becomes a considerably more difficult attack because the attacker would have to falsify two different authentications.

You can also combine mutual authentication with multifactor authentication, although the latter generally takes place only on the client side. Multifactor authentication from the server back to the client would be not only technically challenging but also impractical in most environments because it would involve some technical heavy-lifting on the client side, potentially on the part of the user. You’d likely lose a significant amount of productivity.

Common Identification and Authentication Methods

I’ll conclude this discussion by exploring three common identification and authentication methods in detail: passwords, biometrics, and hardware tokens.

Passwords

Passwords are familiar to most us who use computers regularly. When combined with a username, a password will generally allow you access to a computer system, an application, a phone, or a similar device. Although they’re only a single factor of authentication, passwords can represent a relatively high level of security when constructed and implemented properly.

People often describe certain passwords as being strong, but a better descriptive term might be complex. If you construct a password that uses lowercase letters only and is eight characters long, you can use a password-cracking utility to crack it quickly, as discussed in Chapter 1. Adding character sets to the password makes it increasingly harder to figure out. If you use uppercase letters, lowercase letters, numbers, and symbols, you’ll end up with a password that is potentially more difficult to remember, such as $sU&qw!3, but much harder to crack.

In addition to constructing strong passwords, you also need to practice good password hygiene. Don’t write your password down and post it under your keyboard or on your monitor; doing so completely defeats the purpose of having a password in the first place. Applications called password managers exist to help us manage all the logins and passwords we have for different accounts, some as locally installed software and others as web or mobile device applications. There are many arguments for and against such tools; some people think keeping all of your passwords in one place is a bad idea, but when used carefully, they can help you maintain good password hygiene.

Another common problem is the manual synchronization of passwords—in short, using the same password everywhere. If you use the same password for your email, for your login at work, and for your online knitting discussion forum, you’re putting the security of all the accounts in the hands of those system owners. If any one of them is compromised, all of your accounts become vulnerable; all an attacker needs to do to access the others is look up your account name on the internet to find your other accounts and log in using your default password. By the time the attacker gets into your email account, the game is over because an attacker can generally use it reset account credentials for any other accounts you have.

Biometrics

Although some biometric identifiers may be more difficult to falsify than others, this is only because of the limitations of today’s technology. At some point in the future, we’ll need to develop more robust biometric characteristics to measure or else stop using biometrics as an authentication mechanism.

Using Biometrics

Biometrics-equipped devices are becoming increasingly common and inexpensive. You can find a wide selection of them for less than $20. It pays to research such devices carefully before you depend on them for security, as some of the cheaper versions are easy to bypass.

You can use biometric systems in two ways. You can use them to verify the identity claim someone has put forth, as discussed earlier, or you can reverse the process and use biometrics as a method of identification. This process is commonly used by law enforcement agencies to identify the owner of fingerprints left on various objects. It can be a time-consuming effort, considering the sheer size of the fingerprint libraries held by such organizations. To use a biometric system in either manner, you need to put the user through some sort of enrollment process. Enrollment involves recording the user’s chosen biometric characteristic—for instance, making a copy of a fingerprint—and saving it in a system. Processing the characteristic may also include noting elements that appear at certain parts of the image, known as minutiae (Figure 2-3).

Figure 2-3: Biometric minutiae

You can use the minutiae later to match the characteristic to the user.

Characteristics of Biometric Factors

Biometric factors are defined by seven characteristics: universality, uniqueness, permanence, collectability, performance, acceptability, and circumvention.⁴

Universality means you should be able to find your chosen biometric characteristic in the majority of people you expect to enroll in the system. For instance, although you might be able to use a scar as an identifier, you can’t guarantee that everyone will have a scar. Even if you choose a common characteristic, such as a fingerprint, you should take into account the fact that some people may not have an index finger on their right hand and be prepared to compensate for this.

Uniqueness is a measure of how unique a characteristic is among individuals. For example, if you choose to use height or weight as a biometric identifier, you’d stand a good chance of finding several people in any given group who have the same height or weight. You should try to select characteristics with a high degree of uniqueness, such as DNA or iris patterns, but even these could be duplicated, whether intentionally or otherwise. For example, identical twins have the same DNA, and an attacker could replicate a fingerprint.

Permanence tests how well a characteristic resists change over time and with advancing age. If you choose a factor that can easily vary, such as height, weight, or hand geometry, you’ll eventually find yourself unable to authenticate a legitimate user. It’s better to use factors such as fingerprints, which are unlikely to change without deliberate action.

Collectability measures how easy it is to acquire a characteristic. Most commonly used biometrics, such as fingerprints, are relatively easy to acquire, which is one reason they are common. On the other hand, a DNA sample is more difficult to acquire because the user must provide a genetic sample to enroll and to authenticate again later.

Performance measures how well a given system functions based on factors such as speed, accuracy, and error rate. I’ll discuss the performance of biometric systems at greater length later in this section.

Acceptability is a measure of how acceptable the characteristic is to the users of the system. In general, systems that are slow, difficult to use, or awkward to use are less likely to be acceptable to the user.⁵ Systems that require users to remove their clothes, touch devices that have been repeatedly used by others, or provide tissue or bodily fluids are unlikely to have a high degree of acceptability.

Circumvention describes how easy it is to trick a system by using a falsified biometric identifier. The classic example of a circumvention attack against the fingerprint as a biometric identifier is the “gummy finger.” In this type of attack, a fingerprint is lifted from a surface and used to create a mold with which the attacker can cast a positive image of the fingerprint in gelatin. Some biometric systems have secondary features specifically designed to defeat such attacks by measuring skin temperature, pulse, or pupillary response.

Measuring Performance

There are many ways to measure the performance of a biometric system, but a few primary metrics are particularly important. The false acceptance rate (FAR) and false rejection rate (FRR) are two of these.⁶ FAR measures how often you accept a user who should be rejected. This is also called a false positive. FRR measures how often we reject a legitimate user and is sometimes called a false negative.

You want to avoid both of these situations in excess. You should aim for a balance between the two error types, referred to as an equal error rate (EER). If you plot both the FAR and the FRR on a graph, as I’ve done in Figure 2-4, the EER marks the point where the two lines intersect. We sometimes use EER as a measure of the accuracy of biometric systems.

Figure 2-4: The equal error rate is the intersection of the false acceptance rate and false rejection rate.

Flaws in Biometric Systems

Biometric systems are prone to several common issues. As I mentioned when discussing circumvention, it’s easy to forge some biometric identifiers. Moreover, once they’re forged, it’s hard to re-enroll a user in the system. For example, if you enroll a user with both index fingers and those fingerprints get compromised, you could remove these from the system and enroll two of their other fingers. However, if you’ve already enrolled all of their fingers in the system, you’d have no means of re-enrolling them using fingers at all. Depending on the system in question, you may be able to select a different set of minutiae for the same identifier, but this avoids the point of the discussion, which is that biometric identifiers are finite. This issue became tangible in 2015, when an attacker hacked the US Office of Personnel Management and stole the fingerprint records of 5.6 million federal employees holding security clearances.⁷

You also face possible privacy issues in the use of biometrics. When you’re enrolled in a biometric system, you’re essentially giving away a copy of the identifier, whether it’s a fingerprint, iris pattern, or DNA sample. Once such an item has been entered into a computer system, you have little, if any, control over what happens to it. We can hope that once you’re no longer associated with the institution in question, the institution would destroy such materials, but you have no way to guarantee this. Particularly in the case of DNA sampling, the repercussions of surrendering genetic material could affect you for the rest of your life.

Hardware Tokens

A standard hardware token (Figure 2-5) is a small device, typically in the general form factor (size and shape) of a credit card or keychain fob.⁸ The simplest hardware tokens look identical to universal serial bus (USB) flash drives and contain a certificate or unique identifier. They’re often called dongles. More complex hardware tokens incorporate liquid-crystal displays (LCDs), keypads for entering passwords, biometric readers, wireless devices, and additional features to enhance security.

Figure 2-5: A hardware token

Many hardware tokens contain an internal clock that generates a code based on the device’s unique identifier, an input PIN or password, and other potential factors. Usually, the code is output to a display on the token and changes on a regular basis, often every 30 seconds. The infrastructure used to keep track of these tokens can predict what the proper output will be at any given time in order to authenticate the user.

The simplest kind of hardware token represents only the something you have factor and is thus susceptible to theft and potential use by a knowledgeable criminal. Although these devices represent an increased level of security for the user’s accounts and aren’t generally useful without the associated account credentials, you do need to remember to safeguard them.

More sophisticated hardware tokens could represent the something you know or something you are factors, as well. They might require a PIN or fingerprint, which enhances the security of the device considerably; in addition to getting the hardware token, an attacker would need to either subvert the infrastructure that uses the device or extract the something you know or something you are factor from the legitimate owner of the device.

Summary

Identification is an assertion of the identity of some party, whether it be a person, process, system, or other entity. Identification is only a claim of identity; it doesn’t say anything about any privileges that might be associated with the identity.

Authentication is the process used to validate whether the claim of identity is correct. It’s different than verification, which is a much weaker way of testing someone’s identity.

When you perform authentication, you can use several factors. The main factors are something you know, something you are, something you have, something you do, and where you are. An authentication mechanism that includes more than one factor is known as multifactor authentication. Using multiple factors gives you a much stronger authentication mechanism than you might otherwise have.

The common set of tools used for authentication includes passwords, tokens, and biometric identifiers. Each of these has its own set of unique challenges that you will need to deal with when you are implementing them as part of your set of security controls.

In the next chapter, I’ll discuss the steps that take place after identification and authentication: authorization and access control.

Exercises

What is the difference between verification and authentication of an identity?

How do you measure the rate at which you fail to authenticate legitimate users in a biometric system?

What do you call the process in which the client authenticates to the server and the server authenticates to the client?

A key would be described as which type of authentication factor?

What biometric factor describes how well a characteristic resists change over time?

If you’re using an identity card as the basis for your authentication scheme, what steps might you add to the process to allow you to move to multifactor authentication?

If you’re using an eight-character password that contains only lowercase characters, would increasing the length to ten characters represent any significant increase in strength? Why or why not?

Name three reasons why an identity card alone might not make an ideal method of authentication.

What factors might you use when implementing a multifactor authentication scheme for users who are logging onto workstations that are in a secure environment and are used by more than one person?

If you’re developing a multifactor authentication system for an environment where you might find larger-than-average numbers of disabled or injured users, such as a hospital, which authentication factors might you want to use or avoid? Why?

3AUTHORIZATION AND ACCESS CONTROLS

After you’ve received a party’s claim of identity and established whether that claim is valid, as discussed in Chapter 2, you have to decide whether to allow the party access to your resources. You can achieve this with two main concepts: authorization and access control. Authorization is the process of determining exactly what an authenticated party can do. You typically implement authorization using access controls, which are the tools and systems you use to deny or allow access.

You can base access controls on physical attributes, sets of rules, lists of individuals or systems, or other, more complex factors. ...

4
AUDITING AND ACCOUNTABILITY

When you’ve successfully gone through the identification, authentication, and authorization processes (or even while you’re still completing them), you need to keep track of the activities taking place in your organization. Even after you’ve allowed a party access to your resources, you still need to ensure that they behave in accordance with your rules, particularly those relating to security, business conduct, and ethics. Essentially, you need to make sure you can hold users of your systems accountable (Figure 4-1).

Figure 4-1: You should always hold users accountable.

Holding someone accountable means making sure that person is responsible for their actions. This is particularly important now that most organizations house a great deal of information in digital form. If you don’t keep track of how people are accessing sensitive data stored digitally, you can suffer business losses, intellectual property theft, identity theft, and fraud. In addition, a data breach could have legal consequences for your organization. Some types of data—medical and financial, for example—are protected by law in several countries; in the United States, two such well-known laws are the Health Insurance Portability and Accountability Act of 1996, which protects medical information, and the Sarbanes–Oxley Act of 2002, which protects against corporate fraud.

Many of the measures you put in place to ensure accountability are examples of auditing, which is the process of reviewing an organization’s records or information. You perform audits to ensure that people comply with laws, policies, and other bodies of administrative control. Auditing can also prevent attacks, such as credit card companies recording and auditing the purchases you make through your account. If you decide to buy half a dozen laptops in one day, your unusual behavior might trigger an alert in the company’s monitoring system, and the company might temporarily freeze any purchases made with your card. In this chapter, you’ll learn about accountability in more detail and see how to use auditing to enforce it.

Accountability

To hold people accountable for their actions, you have to trace all activities in your environment back to their sources. That means you have to use identification, authentication, and authorization processes so you can know who a given event is associated with and what permissions allowed them to carry it out.

It’s easy to criticize accountability and its associated auditing tools. You could argue that implementing surveillance techniques is like having Big Brother watching over your shoulder. In some senses, this is true; if you monitor people excessively, you can create an unhealthy environment.

But you can also go too far in the other direction. If you don’t have sufficient controls in place to deter or prevent people from breaking your rules and abusing your resources, you’ll end up with security disasters. The “Equifax Breach” box covers an example of this.

THE EQUIFAX BREACH

In 2017, Equifax’s shareholders, board of directors, and auditors, as well as the US government, failed to hold Equifax accountable for protecting consumers’ personal and financial information. As a result, attackers stole data relating to 147 million Americans, and Equifax suffered very little in the way of consequences, aside from a brief dip in stock price. Although Equifax was brought to testify in front of Congress and lawmakers said they would enact new regulations because of the incident, Equifax has faced no consequences, and Congress has not passed any new laws on the matter.

The breach occurred when attackers exploited a vulnerability (designated as CVE-2017-5638) in Apache Struts2, a framework for developing Java applications for web use. This vulnerability allowed attackers to perform remote code execution (RCE) on the web servers in question, giving them a foothold in the Equifax environment. At the time of the attack, Equifax had a solution to the vulnerability but hadn’t implemented it yet.

Although Equifax has not publicly disclosed the exact details of the breach beyond the initial entry as of the fall of 2018, we can infer that, since attackers were able to breach an internet-facing server and access personally identifiable information belonging to Equifax customers, the system included significant lapses in security; Equifax might not have separated servers containing sensitive data, for example, or it might have used poor access controls, among other issues. (The US Government Accountability office released a report confirming these types of issues.¹)

Although outside agencies might often prompt accountability, the impetus to comply with these requirements must come from within your organization. For example, when a company experiences a breach in the United States, laws often require it to notify those whose information has been exposed. As of March 2018, all 50 US states now have breach disclosure laws.²

In many cases, however, few people outside the company know of the breaches until the company notifies those who are directly involved. You can certainly see why an organization might be tempted, in such a case, to not say anything about the incident. If you don’t comply with legal requirements, however, you’ll likely be discovered eventually. When that happens, you’ll face greater personal, business, and legal repercussions than if you had handled the situation properly in the first place.

Security Benefits of Accountability

When you hold people accountable, you can keep your environment secure in several ways: by enabling a principle called nonrepudiation, by deterring those who would otherwise misuse your resources, and by detecting and preventing intrusions. The processes you use to ensure accountability can also assist you in preparing materials for legal proceedings.

Nonrepudiation

The term nonrepudiation refers to a situation in which an individual is unable to successfully deny that they have made a statement or taken an action, generally because we have sufficient evidence that they did it. In information security settings, you can achieve nonrepudiation in a variety of ways. You may be able to produce proof of the activity directly from system or network logs or recover such proof through the use of digital forensic examination of the system or devices involved.

You may also be able to establish nonrepudiation using encryption technologies, like hash functions, to digitally sign a communication or a file. You’ll learn more about such methods in Chapter 5, which covers encryption. Another example is when a system digitally signs every email that is sent from it, making it impossible for someone to deny the fact that the email came from that system.

Deterrence

Accountability can also prove to be a great deterrent against misbehavior in your environments. If people are aware that you’re monitoring them and if you’ve communicated to them that there will be penalties for acting against the rules, individuals may think twice before straying outside the lines.

The key to deterrence lies in letting people know they will be held accountable for their actions. You typically achieve deterrence with the auditing and monitoring processes, both of which are discussed in the “Auditing” section of this chapter. If you don’t make your intentions clear, your deterrent will lose most of its strength.

For example, if, as part of your monitoring activities, you keep track of the badge access times that tell you when your employees pass in and out of your facility, you can validate this activity against the times they have submitted on their time card for each week to prevent your employees from falsifying their time card and defrauding the company for additional and undeserved pay. Since the employees are aware that this cross-checking takes place, they’re deterred from lying on their time cards. While this might seem intrusive, real companies often use such methods when they have large numbers of employees working specific shifts, like at technical support help desks.

Intrusion Detection and Prevention

When you audit information in your environment, you can detect and prevent intrusions in both the logical and physical sense. If you implement alerts based on unusual activities and regularly check the information you have recorded, you stand a much better chance of detecting attacks in progress and the precursors of future attacks.

Particularly in the logical realm, where attacks can take place in fractions of a second, you would also be wise to implement automated tools to monitor the system and alert you to any strange activity. You can divide such tools into two major categories: intrusion detection systems (IDSs) and intrusion prevention systems (IPSs).

An IDS is strictly a monitoring and alerting tool; it notifies you when an attack or other undesirable activity is taking place. An IPS, which often works from information sent by the IDS, can take action based on events happening in the environment. In response to an attack over the network, an IPS might refuse traffic from the source of the attack. Chapters 10 and 11 will discuss IDSs and IPSs at greater length.

Admissibility of Records

When you seek to introduce records into legal settings, you’re more likely to have them accepted when they’re produced by a regulated and consistent tracking system. For instance, if you plan to submit digital forensic evidence for use in a court case, you’ll likely have to provide a solid and documented chain of custody for the evidence in order for the court to accept it. That means you need to be able to track information such as the location of the evidence over time, how exactly it passed from one person to another, and how it was protected while it was stored.

Your accountability methods for evidence collection should create an unbroken chain of custody. If it doesn’t, your evidence will likely only be taken as hearsay, at best, considerably weakening your case.

Auditing

Auditing is a methodical examination and review of an organization’s records.³ In nearly any environment, from the lowest level of technology to the highest, you usually ensure that people remain accountable for their actions by using some kind of auditing.

One of the primary ways you can ensure accountability through technical means is by keeping accurate records of who did what and when they did it—and then checking those records. If you don’t have the ability to assess your activities over a period, you won’t be able to facilitate accountability on a large scale. Particularly in larger organizations, your capacity to audit directly equates to your ability to hold anyone accountable for anything.

You may also be bound by contractual or regulatory requirements that subject you to audits on some sort of recurring basis. In many cases, such audits are carried out by unrelated and independent third parties certified and authorized to perform such a task. Good examples of such audits are those mandated by the Sarbanes–Oxley Act, mentioned earlier, which ensures that companies report their financial results honestly.

What Do You Audit?

In the information security world, organizations commonly audit the factors that determine access to their various systems. For example, you might audit passwords, allowing you to enforce the policies dictating how to construct and use them. As discussed in Chapter 2, if you don’t construct passwords in a secure manner, an attacker can easily crack them. You should also verify how often users change their passwords. In many cases, systems can check password strength and manage password changes automatically, using functions within an operating system or other utilities. You’ll also have to audit those tools to ensure that they’re working properly.

Organizations often audit software licenses as well. The software you use should have a license that proves you obtained it legally. If an outside agency were to audit you and found that you were running large quantities of unlicensed software, the financial penalties could be severe. It is often best if you can find and correct such matters yourself before receiving a notification from an external company.

The Business Software Alliance (BSA) is one such company that works on behalf of software firms (Adobe or Microsoft, for instance). It regularly audits other organizations to ensure that they’re complying with software licensing. Legal settlements with the BSA can reach $250,000 per occurrence of unlicensed software,⁴ plus additional charges of up to $7,500 to pay BSA legal fees. The BSA also sweetens the pot for whistle-blowers by offering rewards of up to $1 million for reporting violations.⁵

Finally, organizations commonly audit internet usage, including websites its employees visit, instant messaging, email, and file transfers. In many cases, organizations have configured proxy servers to funnel all such traffic through just a few gateways, which allows them to log, scan, and potentially filter such traffic. Such tools can give you the ability to examine exactly how employees are using those resources, allowing you to act if you encounter misuse.

Logging

Before you can audit something, you have to create the records to review. Logging gives you a history of the activities that have taken place in an environment. You typically generate logs automatically in operating systems to keep track of the activities that take place on most computing, networking, and telecommunications equipment, as well as on the devices that incorporate or connect to a computer. Logging is a reactive tool; it allows you to view the record of an event after it has taken place. To immediately react to something taking place, you would need to use a tool like an IDS or IPS, which will be covered in detail in Chapter 10.

You typically configure logging mechanisms to record critical events only, but you could also log every action carried out by the system or software. You’d probably want to do this for troubleshooting purposes. A log might include records of events such as software errors, hardware failures, user logins or logouts, resource accesses, and tasks requiring increased privileges, depending on the logging settings and the system in question.

Generally, only system administrators can review logs. Usually, users of the system can’t modify them, except maybe to write to them. For instance, an application running under the context of a particular user will generally have permissions to write messages to system or application logs. Keep in mind that collecting logs without reviewing them is pointless. If you never review the content of the logs, you might as well have failed to collect them in the first place. It is important that you schedule a regular review of your logs to catch anything unusual in their contents.

You may also be asked, in the course of normal security duties, to analyze the contents of logs in relation to an incident or situation. In the case of investigations, incidents, and compliance checks, these types of activities often fall to security personnel. Reviewing logs can be a difficult task if the period in question is greater than a few days. Even searching the contents of a relatively simple log, such as that generated by a web proxy server, can mean sifting through enormous amounts of data. In such cases, custom scripts or even a tool such as grep (a UNIX and Linux tool for searching text) can help accomplish the task in a reasonable amount of time.

Monitoring

A subset of auditing, monitoring is observing information about an environment to discover undesirable conditions such as failures, resource shortages, and security issues, as well as trends that might signal the arrival of such conditions. Like logging, monitoring is largely a reactive activity; it takes action based on gathered data, typically from logs generated by various devices. Even when you’re trying to predict future events, you’re still relying on past data to do so.

When monitoring a system, you’re typically watching for specific kinds or patterns of data, such as increased resource usage on computers, unusual network latency (the time it takes a packet to get from one point to another on a network), certain types of attacks occurring repeatedly against servers with network interfaces that are exposed to the internet, traffic passing through your physical access controls at unusual times of day, and so on.

When you detect unusual levels of such activity, called the clipping level, your monitoring system might send an alert to a system administrator or physical security personnel, or it might trigger a more direct action, such as dropping traffic from a particular IP address, switching to a backup system for a critical server, or summoning law enforcement officials.

Auditing with Assessments

As mentioned, logging and monitoring are reactive measures. To assess the state of your systems more actively, you might use a kind of audit called assessments, which are tests that find and fix vulnerabilities before any attackers do. If you can conduct assessments successfully and on a recurring basis, you will considerably increase your security posture and stand a much better chance of resisting attacks. You can take two approaches to this: vulnerability assessments and penetration testing. While people often use these terms interchangeably, they are two distinct sets of activities.

Vulnerability assessments generally involve using vulnerability scanning tools, such as Qualys,⁶ shown in Figure 4-2, to locate weaknesses in an environment. Such tools generally work by scanning the target systems to discover open ports and then interrogating each open port to find out exactly which service is listening on it. Additionally, you may choose to provide credentials, if you have them, to allow a vulnerability scanner to authenticate to the device in question and collect considerably more detailed information, such as the specific software installed, the users on the system, and the information contained in or regarding files.

Figure 4-2: Qualys, a tool for vulnerability scanning

Given this information, the vulnerability assessment tool can then consult its database of vulnerability information to determine whether the system might contain any weaknesses. Although these databases tend to be thorough, new or uncommon attacks will often escape their notice.

Penetration testing takes the assessment process several steps further. When you conduct a penetration test, you mimic the techniques an actual attacker would use to breach a system. You may attempt to gather additional information on the target environment from users or other systems in the vicinity, exploit security flaws in web-based applications or web-connected databases, or conduct attacks through unpatched vulnerabilities in applications or operating systems.

You’ll learn more about assessing security at greater length in Chapter 14. As with any security measure that you can put in place, security assessments should be only a single component of your overall defensive strategy.

Summary

For nearly any action you might care to take, some system somewhere creates an associated audit record. Organizations regularly query and update your medical history, grades in school, purchases, and credit history, and they use this data to make decisions that can impact your life for better or worse.

When you allow others to access your business’s resources or personal information of a sensitive nature, you need to hold them accountable for what they do with the resources or information.

You go through the auditing process to hold people accountable and ensure that your environment is compliant with the laws, regulations, and policies that bind it. You may carry out a variety of auditing tasks, including logging, monitoring, and conducting assessments. Through these processes, you can both react to threats and actively prevent them.

In the next chapter, you’ll get an overview of the main cryptographic algorithms that serve as the backbone of today’s security systems.

Exercises

What is the benefit of logging?

Discuss the difference between authorization and accountability.

Describe nonrepudiation.

Name five items you might want to audit.

Why is accountability important when dealing with sensitive data?

Why might auditing your installed software be a good idea?

When dealing with legal or regulatory issues, why do you need accountability?

What is the difference between vulnerability assessment and penetration testing?

What impact can accountability have on the admissibility of evidence in court cases?

Given an environment containing servers that handle sensitive customer data, some of which are exposed to the internet, would you want to conduct a vulnerability assessment, a penetration test, or both? Why?

5CRYPTOGRAPHY

Cryptography, the science of protecting the confidentiality and integrity of data, is a key part of the vast set of transactions that take place over your devices daily. You use cryptography when you have conversations on your cell phones, check your email, buy things from online retailers, and file your taxes, among other activities. Without the ability to protect the information you send over such channels, your Internet-based activities would be much riskier.

In cryptography, encryption is the process of transforming readable data, called plaintext or cleartext, into an unreadable form, called ciphertext. Decryption is the process ...

6
COMPLIANCE, LAWS, AND REGULATIONS

In information security, external rules and regulations often govern your ability to collect information, pursue investigations, and monitor networks, among other activities. To comply with these rules, you can set requirements for protecting your organization, designing new systems and applications, deciding on how long to retain data, or encrypting or tokenizing sensitive data.

In this chapter, I’ll outline some rules that might affect your organization and discuss how to ensure compliance to them.

What Is Compliance?

Simply put, compliance is your adherence to the rules and regulations that govern the information you handle and the industry within which you operate.

A decade ago, most information security efforts followed only a few policies and a general mandate to keep attackers out. Regulations aimed at protecting data and consumers had loose definitions, and governing parties enforced them less strictly.

Today, laws and regulations are more stringent, in part because large breaches, such as the British Airways breach of 380,000 payment cards in August 2018,¹ put compliance issues under increased scrutiny. Modern regulations update and evolve constantly, creating a moving target for companies that need to comply with the rules.

In general, you measure compliance against the standard to which you’re adhering. In several industries, you may even have to comply with more than one set of rules. While you’ll rarely encounter contradictory sets of standards, you may find that they disagree on the specifics. For example, one set of compliance rules might specify a one-year retention period for server backups, while another might specify six months. When faced with these situations, you’ll likely find yourself adopting the strictest set of items across all compliance efforts, for the sake of simplicity.

Keep in mind that compliance isn’t the same thing as security. Even if you’ve put hundreds or thousands of hours toward complying with a specific set of rules and even if you’ve passed an audit, you may not be secure against attacks. You carry out compliance to meet the needs of specific third parties—namely, your customers or business partners, auditors, and the compliance bodies responsible for ensuring your compliance. Compliance fulfills a business need rather than any technical security need. Furthermore, you are “compliant” whenever these third parties are satisfied with your efforts—regardless of how well you’ve actually met the requirements. An organization will usually put their “best foot forward” when the inspector comes.

Types of Compliance

There are two main types of compliance: regulatory compliance and industry compliance.

Regulatory compliance is your adherence to the laws specific to the industry in which you’re operating. In almost every case, regulatory compliance involves cyclical audits and assessments to ensure that you’re carrying everything out according to specification. Preparing for these audits can be a valuable part of a compliance program, as they can both educate participants and provide opportunities to find and fix issues.

Industry compliance is adherence to regulations that aren’t mandated by law but that can nonetheless have severe impacts upon your ability to conduct business. For example, organizations that accept credit cards must typically comply with the Payment Card Industry Data Security Standard (PCI DSS), a set of rules created by a group of credit card issuers (including Visa, American Express, and Mastercard) for processing credit card transactions. The standard defines requirements for a security program, specific criteria for protecting data, and necessary security controls. Credit card issuers update the standard every few years to keep pace with current conditions and threats.

Although these credit card issuers can’t legally enforce compliance with their standards, their mandate certainly has teeth. Merchants processing credit card transactions based on cards from PCI members must submit to yearly assessments of their security practices. Organizations with low numbers of transactions can simply complete a self-assessment consisting of a short questionnaire. As the number of transactions grows, however, the requirements become progressively stringent, culminating in visits by specially certified external assessors, mandated penetration tests, requirements for internal and external vulnerability scanning, and a great deal of other measures.

Consequences of Noncompliance

Noncompliance can trigger a variety of consequences, depending on the set of regulations in question.

In the case of industry compliance, you may lose the privileges associated with being compliant. For instance, if you fail to comply with the PCI DSS regulations that govern processing credit card transactions and protecting associated data, you may face hefty fines or lose your merchant status and be unable to process further transactions. For a business that depends heavily on credit card transactions, such as a retail store, losing the ability to process credit cards could put them out of business.

In the case of regulatory compliance, you may face even stiffer penalties, including incarceration for violating the laws in question.

Achieving Compliance with Controls

To comply with standards and regulatory requirements, you will typically implement physical, administrative, and technical controls.

Types of Controls

Physical controls mitigate risks to physical security. Examples include fences, guards, cameras, locked doors, and so on. These controls typically physically prevent or deter unauthorized access to or through specific areas.

Administrative controls mitigate risks by implementing certain processes and procedures. Whenever you accept, avoid, or transfer risk, you’re likely using administrative controls because you’re putting processes, procedures, and standards in place to prevent your organization from hurting itself by taking on too much risk. You’ll also have to document your administrative controls by keeping records of policies, procedures, and standards you’ve put in place and providing evidence that your organization has followed them.

For example, almost every standard or regulation requires you to have an information security policy, which is a document that defines information security for an organization. To comply with this requirement, you must both put a policy in place and be able to prove that you’ve followed it with regular documentation. The day of the audit is not a good time to discover that you lack the documentation to show your policy in use. Proper documentation could include emails, tickets from your ticketing system, and files from investigations.

Technical controls manage risk using technical measures. You might mitigate risks by putting firewalls, intrusion detection systems, access control lists, and other technical measures in place to prevent attackers from getting into your systems.

None of these controls is sufficient by itself, but each contributes to the layered defense necessary to provide good security and meet requirements. Often, the regulations themselves stipulate certain controls. For instance, the PCI DSS requirements include a variety of specific controls that organizations must implement to comply with the standard. Also, keep in mind that your controls are only as good as your implementation of them. If you implement a control improperly, then you might be worse off than if you hadn’t implemented it at all, because you’ve created a false sense of security.

Key vs. Compensating Controls

In addition to distinguishing types of controls, you can divide your controls into two levels of importance. Key controls are the primary controls used to manage risk in your environment and have the following characteristics:

They provide a reasonable degree of assurance that the risk will be mitigated.

If the control fails, it is unlikely that another control could take over for it.

The failure of this control will affect an entire process.

What you consider a key control will vary based on your environment and the present risks, and you should always test key controls as part of compliance or audit efforts. An example of a key control might be the use of antivirus software on all systems processing payment card information in an environment.

Compensating controls are controls that replace impractical or unfeasible key controls. When you put a compensating control in place, you’ll likely have to explain to auditors how it will fulfill the intent and purpose of the control you’re replacing.

For example, although regulations may require you to run antivirus tools on all systems, certain systems might not have sufficient resources to run these utilities without adverse impacts. In this case, as a compensating control, you might use Linux operating systems, which are less susceptible to malware.

Maintaining Compliance

To maintain your compliance over time, you can cycle through the following set of activities, as shown in Figure 6-1: monitoring, reviewing, documenting, and reporting.

Figure 6-1: Maintaining compliance

Following each step in this process helps you maintain the health of your controls.

Monitoring

You must monitor your controls (and the data produced by or related to them) on an ongoing basis to determine whether they effectively mitigate or reduce risk. In the information security world, no news often just means no good news. Since your environment and technology might change, it’s important to check that your controls—especially your key controls—continue to play their intended role. Without such monitoring, your controls quickly stop being useful, possibly without your knowledge.

Reviewing

Controls need to undergo a periodic review to determine whether they’re still effective and meet the objectives for managing risk in your particular environment. As old risks evolve and new risks arise, you’ll need to make sure your controls still cover these risks appropriately, determine whether you need any new controls, or decide whether you should retire old controls.

Documenting

You should document the results of your reviews and carefully track any changes to a control’s environment. Documentation helps you evaluate trends and maybe even predict future control changes, which can allow you to forecast the resources you’ll need later.

Reporting

After monitoring, reviewing, and documenting the state of your controls, you must report the results to your leadership. This not only keeps them aware of the state of your controls and enables them to make informed decisions for the organization but also provides you with a means of requesting the staff and resources you need for these efforts.

Laws and Information Security

When it comes to information security, enforcing laws and regulations is often trickier than in cases of physical incidents. Matters such as attributing attacks to a particular party or assessing the damage resulting from an attack—which can be simple when they concern, say, the vandalism of a building—are made considerably more difficult in the world of information security.

Many laws and regulations developed in recent years seek to address these types of situations. Some of them leave gaps, while others overlap significantly. You’ll be measured against these laws when preparing for or being assessed for compliance. Let’s look at a few of them.

Government-Related Regulatory Compliance

In the United States, standards frequently form the basis for the laws and regulations that govern the behavior of the government and those who work closely with it. In the world of information security and compliance, these standards are often from the series of Special Publications (SPs) created by the US National Institute of Standards and Technology (NIST). While NIST is not itself a regulatory agency, the standards it produces have compliance requirements, generally through other government compliance standards based on NIST’s SPs (yes, this is somewhat convoluted). Security professionals often play a major role in making sure that an organization complies with these government-related standards.

WHAT IS NIST?

What is now called NIST was originally created in the early 1900s to develop standards for weights and measures and serve as a national laboratory. Over time, its mission has evolved to include promoting technology and innovation in the United States. NIST’s Special Publications have a significant impact on information security.

Two of the most common government compliance standards are the Federal Information Security Management Act (FISMA) and the Federal Risk and Authorization Management Program (FedRAMP), which are both based on NIST SP 800-53, “Security and Privacy Controls for Information Systems and Organizations.”

Federal Information Security Management Act

The Federal Information Security Management Act of 2002 applies to all US federal government agencies, all state agencies that administer federal programs (such as Medicare), and all private companies that support, sell to, or receive grant money from the federal government.

FISMA requires that an organization implement information security controls that use a risk-based approach—one that handles security by enumerating and compensating for specific risks.

After an organization passes an audit, the federal agency they’re working with grants it an authority to operate (ATO). Since the ATO is specific to each agency, a company working with ten different agencies must obtain ten different ATOs.

Federal Risk and Authorization Management Program

The Federal Risk and Authorization Management Program, established in 2011, defines rules for government agencies contracting with cloud providers.² This applies to both cloud platform providers, such as AWS and Azure, and companies providing software as a service (SaaS) tools that are based in the cloud. I’ll discuss this distinction later in this chapter.

Unlike FISMA, FedRAMP certification consists of a single ATO that allows an organization to do business with any number of federal agencies. Since the FedRAMP ATO is considerably broader, the requirements to obtain it are more stringent than FISMA’s. As of this writing, FedRAMP marketplace lists only 91 companies that possess an ATO.³

Industry-Specific Regulatory Compliance

Many regulatory compliance requirements pertain to a specific area of operation, such as the healthcare industry, public companies, and financial institutions. Let’s look at a few of these requirements.

Health Insurance Portability and Accountability Act

The Health Insurance Portability and Accountability Act (HIPAA) of 1996 protects the rights and data of patients in the US healthcare system. Security professionals should pay specific attention to Title II of HIPAA, which lays out requirements for safeguarding protected health information (PHI) and electronic protected health information (e-PHI). (You can generally interpret these as consisting of any portion of a patient’s medical records or medical transactions.) While HIPAA primarily applies to organizations involved in healthcare or health insurance, it may also apply in other odd cases, such as employers that self-insure.

HIPAA requires that you ensure the confidentiality, integrity, and availability of any information that you handle or store; protect this information from threats and unauthorized disclosures; and ensure that your workforce is compliant with all of its rules. This can be a tall order, especially in institutions that handle large amounts of PHI.

Sarbanes–Oxley Act

The Sarbanes–Oxley Act (SOX) of 2002 regulates financial data, operations, and assets for publicly held companies. The government-enacted SOX as a response to incidents of financial fraud among several large companies, most notably the Enron scandal of 2001, in which the public learned that the company had falsified years’ worth of financial reporting.⁴

Among other provisions, SOX places specific requirements on an organization’s electronic recordkeeping, including the integrity of records, retention periods for certain kinds of information, and methods of storing electronic communications. Security professionals often help design and implement systems impacted by SOX, so it pays for you to understand these regulations and your requirements under them.

Gramm–Leach–Bliley Act

The Gramm–Leach–Bliley Act (GLBA) of 1999 aims to protect information (such as personally identifiable information (PII), which is any data that can identify a specific person) and financial data belonging to customers of financial institutions. Interestingly, GLBA defines financial institution broadly to include “banks, savings and loans, credit unions, insurance companies and securities firms … some retailers and automobile dealers that collect and share personal information about consumers to whom they extend or arrange credit,” as well as businesses that use financial data to collect debts from customers.⁵

To comply with GLBA, you must secure every pertinent record against unauthorized access, track people’s access to these records, and notify customers when you share their information. Organizations must also have a documented information security plan in place and specifically have an overarching information security program to handle security for the organization.

Children’s Internet Protection Act

The Children’s Internet Protection Act (CIPA) of 2000 requires schools and libraries to prevent children from accessing obscene or harmful content over the Internet. CIPA requires these institutions to have policies and technical protection measures in place to block or filter such content. Additionally, these institutions must monitor the activities of minors and provide education regarding appropriate online behavior.

CIPA encourages institutions to adopt these standards not by imposing penalties for noncompliance but by providing cheap internet access for eligible institutions that choose to comply with them.

Children’s Online Privacy Protection Act

The Children’s Online Privacy Protection Act (COPPA) of 1988 protects the privacy of minors younger than 13 by restricting organizations from collecting their PII, requiring the organizations to post a privacy policy online, make reasonable efforts to obtain parental consent, and notify parents that information is being collected. Many companies choose to charge a small fee for accounts belonging to a minor as a way of verifying parental consent, while others refuse service to minors entirely.

COPPA is a bit of a hot potato in the information security world, as it requires organizations to judge the age of its users and provides for an even more restrictive class of PII for children if such data is to be collected, even by accident, both of which are difficult to execute with a high level of surety. In 2016, the mobile advertising company InMobi was fined $950,000 under COPPA for unknowingly tracking the location of minors younger than 13 with its advertising software.⁶ As you can see, compliance here can be difficult, even when organizations are honestly attempting to do so.

Family Educational Rights and Privacy Act

The Family Educational Rights and Privacy Act (FERPA) of 1974 protects students’ records. FERPA applies to student at all levels, and when students turn 18, the rights to these records shift from the parents to the students.

FERPA defines how institutions must handle student records to protect them and how people can view or share them. As schools now largely hold educational records in digital form, it’s not uncommon for a security professional to participate in incidents and design discussions, and to address general security issues when working at an institution that handles educational records.

Laws Outside of the United States

Foreign laws governing computing and data can differ greatly from US laws. If your organization operates internationally, you need to research the relevant laws in every country in which you plan to conduct business. You should also check for any treaties that regulate security practices and the exchange of information between those countries.

It pays to know ahead of time where you might encounter regulatory issues. For example, in one country, you might be able to gather log data containing a list of machines and associated usernames, cross-referenced with the owner’s employee number and email address. But in another country, collecting this data might be more difficult, or perhaps even illegal.

One example of an international regulation relevant to information security is the General Data Protection Regulation (GDPR), which the European Union enacted in 2018. GDPR covers data protection and privacy for all individuals in the European Union. The regulation applies to anyone collecting data about EU citizens, regardless of the country in which you’re working.

GDPR requires that organizations get consent before collecting people’s data, report data breaches, give individuals the right to access and remove collected data, and set specific guidelines for privacy and privacy programs. Given the broad applicability of GDPR, security and privacy programs all over the world had to adapt when this law came into effect, prompting a great many customer communications, new privacy-oriented banners on websites, and updates to many organizations’ policies.⁷

Adopting Frameworks for Compliance

In addition to the frameworks provided by specific regulations, it’s helpful to choose a framework for your overall compliance efforts. For example, if your organization is bound to comply with separate, unrelated regulations—HIPAA and PCI DSS, for example—you might want to choose a more overarching framework to guide the entire compliance effort and security program and then adjust it as needed for specific areas of compliance.

In this section, you’ll learn about some frameworks you can use. Choosing a well-known framework can also ease the path of an audit, as you’re able to give the auditor an idea of what to expect of your program and the specific controls that you’ve implemented.

International Organization for Standardization

The International Organization for Standardization (ISO) is a body first created in 1926 to set standards between nations. It has created more than 21,000 standards “covering almost every industry, from technology, to food safety, to agriculture and healthcare.”⁸

The ISO 27000 series that covers information security includes standards such as the following:

ISO/IEC 27000, “Information security management systems – Overview and vocabulary”

ISO/IEC 27001, “Information technology – Security Techniques – Information security management systems – Requirements”

ISO/IEC 27002, “Code of practice for information security controls”

This series of ISO standards, also referred to in the industry as ISO 27k, discusses information security management systems and is intended to help manage the security of the assets within your organization. These documents lay out best practices for managing risk, controls, privacy, technical issues, and a wide array of other specifics.

National Institute of Standards and Technology

A National Institute of Standards and Technology Special Publication provides guidelines for many topics in computing and technology, including risk management. Two of the commonly referenced publications in this area are SP 800-37, “Guide for Applying the Risk Management Framework to Federal Information Systems,” and SP 800-53, “Security and Privacy Controls for Federal Information Systems and Organizations.”

SP 800-37 lays out the risk management framework in the following six steps, which form the basis of many security programs:

Categorize Categorize the system based on the information it handles and the impact of exposing or losing such data.

Select Select controls based on the system’s categorization and any extenuating circumstances.

Implement Implement the controls and document the implementation.

Assess Assess the controls to ensure that they’re properly implemented and performing as expected.

Authorize Authorize or ban the use of the system based on the risk it faces and the controls implemented to mitigate that risk.

Monitor Monitor the controls to ensure that they continue to appropriately mitigate risk.

If you intend to select controls based on SP 800-37, you can find specific guidelines for that purpose in SP 800-53.

Custom Frameworks

You could always develop your own framework or modify an existing one, but you should think carefully before doing so. As you’ve just seen, plenty of frameworks for risk management already exist, all of which have undergone considerable review and testing. You probably shouldn’t try to reinvent the wheel here.

Compliance amid Technological Changes

Keeping up with technological change can provide challenges for both the bodies that enforce compliance and those who are attempting to achieve it. An excellent example of this is cloud computing, discussed in this section.

Before hosting data and applications in the cloud became a common technology trend, organizations generally owned their own servers and infrastructure and hosted them either internally or in a co-located data center. This presented a relatively black-and-white set of areas for who owned and was responsible for the security of these devices.

Now that entire companies exist almost entirely in the cloud, compliance efforts have shifted in an attempt to specifically cope with these situations; new policies might govern how to track and evaluate third-party security and compliance efforts, new regulations determine how to manage cloud data, and auditors ask entirely new questions, requiring evidence specific to these types of environments.

While most of the technology change is relatively gradual, allowing the security and compliance industries to slowly shift to keep pace with it, this is not always the case. Two relatively new and potentially disruptive technologies have the potential to cause further shift in compliance requirements for some industries: blockchain and cryptocurrencies.

Compliance in the Cloud

For organizations operating partially or entirely in the cloud, compliance can present an additional set of challenges. That’s because cloud offerings come in different models, each of which gives you a differing level of control over the environment. These models are infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS), as shown in Figure 6-2.

Figure 6-2: Cloud models

At a high level, IaaS provides you with access to virtual servers and storage. Examples include Google Cloud and Amazon Web Services. PaaS provides you with prebuilt servers, such as database or web servers, like Azure, and SaaS provides you with access to a specific application or application suite, as in the case of Google Apps.

PaaS gives you some level of control, and SaaS gives you little or none. Conversely, IaaS requires you to adopt a greater level of responsibility, PaaS requires you to adopt some level of responsibility, and SaaS requires you to adopt very little of it. To quote from Spider-Man, “With great power comes great responsibility.” (The attribution of this quote is a bit tricky, but I can credit Stan Lee in “Amazing Fantasy #15” with relative safety.)

The choice of which of these types of services to use is a matter of balancing your need for flexibility and configurability with how easy the service should be to use. If you want to send a simple email and be done, it would be logical for you to use a tool like Gmail (SaaS) to do so. It would not make very much sense, in this case, for you to build and configure a virtual server, install and configure mail server software on it (IaaS), and then send your email.

Who Owns the Risk?

In each cloud model, the cloud provider must take responsibility for the portions of the environment that the users can’t control. That means that, in some cases, you’ll be responsible for securing your data directly; in other cases, you’ll be responsible for ensuring that the services you’re using secure it appropriately.

In IaaS environments, the cloud provider owns the risks related to the networks and servers on which the virtual infrastructure exists. In other words, it’s responsible for securing and maintaining the hosts (the servers that run the virtual machines), the storage arrays on which the customer’s storage volumes reside, and the networks used by the hosts, among other components. Because IaaS gives you a large amount of control over the environment and how it is configured, it requires you to adopt a greater level of responsibility.

In PaaS environments, the cloud customers access the servers directly, but they can’t access the infrastructure that runs those servers. In this case, the cloud provider assumes responsibility for the security of that infrastructure, including tasks such as patching the operating system, configuring the servers, backing up the servers, and maintaining storage volumes.

In SaaS environments, customers probably won’t be able to make changes to the infrastructure or servers at all, which means the cloud provider is responsible for them entirely. Customers might still be responsible for the data they input into the environment, but not for the security of the environment itself.

Audit and Assessment Rights

Your contract with the cloud provider generally stipulates your right to audit and assess the security of the cloud environment. In many cases, the service allows customers to audit and assess the environment within certain specific bounds. For instance, it might stipulate how and when you can ask the provider for an audit by your internal audit team or a third-party audit company. These limits are reasonable, since responding to each audit request takes a lot of work. The provider might also respond to audit requests by providing the result of an annual external audit conducted expressly for the purposes of responding to requests such as these.

If you hope to directly assess the security of a cloud provider, perhaps with a penetration test (which I’ll discuss in depth in Chapter 14), you might meet resistance. Many providers deny such requests outright or allow penetration tests only under very specific and tightly restricted conditions. This is also understandable for many of the same reasons that they might limit audits. Additionally, active security testing often impacts the infrastructure, platform, or application being tested, and the provider might experience service issues as a result.

Technology Challenges

Cloud services pose technological challenges related to compliance because they’re shared resources. If you’re using cloud resources on the same host server as another company, that company’s lack of security could easily impact the security of your systems, as well.

Risks increase in cloud services that the provider manages more closely, such as SaaS, because you share a larger portion of the environment with other customers. You may have data intermingled with that of other customers in the same database, with only the application logic keeping your data apart from theirs.

In an IaaS service, on the other hand, although you’re sharing some of the same server resources to host virtual machines and some of the same storage space, a sharp divide exists between your resources and the resources of others.

Compliance with Blockchain

Blockchain is a distributed and uneditable digital ledger. Transactions are recorded to the ledger as a block, and each block is attached to the previous block in the chain by a one-way mathematical handshake (similar to a hash, as discussed in Chapter 5). Each participant has a copy of the blockchain, and the consensus of 51 percent of participants defines the accepted chain (generally the longest chain).

In security terms, blockchain promises a strong form of integrity. When you record something to blockchain, you can, with a high degree of certainty, say that it wasn’t altered when you look at it later. For example, Walmart uses this technology to track the path of its food products from the supplier with which they originate to the stores that will sell them to customers.⁹

When it comes to compliance, it’s important to create controls that demonstrate an understanding of how blockchain works. For example, people often cite the use of blockchain as an indelible record that you can write to something and never be concerned with that data being altered. Unfortunately, this is true only under certain conditions. You can force consensus on blockchain by controlling 51 percent of the participants, at which point you can write whatever you like to it. Some companies have even gone as far as to promote “private” blockchains, which really amounts to just using encryption to ensure the integrity of the data. Someone trying to regulate blockchain should understand what drawbacks there may be in using it; if you rush from one hot new technology to the next, you may be putting in place controls that are, in actuality, only security theater.

Compliance with Cryptocurrencies

A cryptocurrency is a form of digital currency often based on the use of blockchain. Cryptocurrencies are unquestionably a disruptive technology. The first cryptocurrency, Bitcoin, appeared in 2009 and has enjoyed a wild variance in value between now and then.

Bitcoin generates currency through the same means it uses to keep the underlying blockchain functioning. To attach each block in the Bitcoin to the chain, as discussed, it needs to be verified with a mathematical handshake. This function requires some level of computing power from all of those participating in the blockchain, and as an incentive, those who participate are rewarded with a Bitcoin. This process of generating new Bitcoins is known as Bitcoin mining.

In February 2019, Gerald Cotton, the founder of Quadriga (which at the time was the largest cryptocurrency exchange in Canada), reportedly perished suddenly. Cotton, a security-minded fellow, maintained the entire exchange from offline accounts stored on his highly encrypted laptop. Upon his death, the entirety of the approximately $190 million in cryptocurrency held by the exchange across 115,000 clients vanished into thin air as his laptop became inaccessible. As of this writing, the exact circumstances surrounding this incident are still under investigation, although there are rumors that the incident involved some sort of chicanery.

As an organization, you are likely bound by a number of laws and regulations that govern financial transactions, as well as those that define the rules for investors and reporting to them. The use of cryptocurrency in business at all is still a gray area, although many businesses do so. It is all but certain, however, that you would, as an organization, be unable to shrug off a multimillion-dollar loss due to a cryptocurrency technology failure without serious repercussions from a legal and regulatory perspective.

Summary

In this chapter, I discussed the laws and regulations relevant to information security and what it means to comply with them. A great number of these are pertinent to computing, and they can vary heavily from one country to the next. Businesses might face both regulatory compliance and industry compliance, which they typically maintain by implementing controls.

I also talked about compliance in newer technologies, such as cloud computing and blockchain, which present additional challenges for those attempting to regulate them.

Exercises

Select one of the US laws applicable to computing covered in this chapter and summarize its main stipulations.

Why might a compliance audit be a positive occurrence?

What type of data is COPPA concerned with?

How do compliance and security relate to each other?

What issues might make conducting an international information security program difficult?

Which NIST Special Publication forms the basis for FISMA and FedRAMP?

Why are industry regulations, such as PCI DSS, important?

What are the potential impacts of being out of compliance?

What set of ISO standards might be useful for an information security program?

What two items are an indicator of which sets of compliance standards your company might fall under?

7OPERATIONS SECURITY

Known in military and government circles as OPSEC, operations security is a process you use to protect your information. Although we’ve discussed certain elements of operations security previously, such as using encryption to protect data, the entire operations security process encompasses much more.

Operations security involves not only putting security measures in place but also identifying what exactly you need to protect and what to protect it against. If you jump directly to implementing protections, you might fail to direct your efforts toward the most critical information. Moreover, when putting security measures in ...

8
HUMAN ELEMENT SECURITY

In information security, we refer to people as the “weak link” of security programs. Regardless of the security measures you set, you have little control over your employees who might click dangerous links, send sensitive information via unprotected channels, hand over passwords, or post important data in conspicuous places.

Worse yet, attackers can take advantage of these tendencies to conduct social engineering attacks that manipulate people to gain information or access to facilities. These attacks usually rely on the willingness of people to help others, particularly when faced with someone who appears to be in distress, someone intimidating (such as a high-up manager), or someone who seems familiar.

That said, you can take measures to protect your organization from these attacks by setting appropriate policies and teaching your employees to recognize danger. In this chapter, you’ll learn about the kind of data attackers might collect, several types of social engineering attacks, and how to set up an effective security training program to inform your staff.

Gathering Information for Social Engineering Attacks

To protect your organization, you’ll need to know how social engineers collect data. People can gather information about individuals and organizations more quickly today than ever before. A staggering wealth of information exists in online databases, public records, and social media sites, and in many cases, this data is free for the taking. Many people post detailed personal information regarding their day-to-day activities for the entire world to see.

Once an attacker collects information about internal processes, people, or systems, they can use it to conduct sophisticated attacks. If an attacker called a company and flat-out asked for a report containing sensitive sales data, the person on the other end would likely refuse. On the other hand, if an attacker used social engineering techniques by calling in a panicked voice and asked for a copy of the latest TPS-13 report from the sales directory on the SalesCom server because they have a meeting with Mr. Kurosawa in 15 minutes and their laptop just crashed, they’re more likely to succeed. (This is a social engineering attack known as pretexting. I’ll discuss it in more detail later in this chapter.)

It’s worth knowing what kind of information attackers might use in cases such as the one just discussed. When protecting people and commercial organizations, you should look at two primary sources of information: human intelligence and open source intelligence.

Human Intelligence

A chief tool for military and law enforcement organizations across the world, human intelligence (HUMINT) is data gathered by talking to people. HUMINT data might include personal observations, people’s schedules, sensitive information, or any of a number of other similar items. You can collect HUMINT with hostile techniques such as torture or by tricking participants with subtle scams. Security professionals focus on the latter.

For example, you might use HUMINT as the basis for conducting other social engineering attacks. You could observe the traffic going in and out of an office building and notice that the office receives frequent package deliveries and that a shift change happens at 8 AM every morning, causing many people to enter and exit the building at the same time. You’d have a much better chance of entering the facility in an unauthorized manner during this busy time, while dressed in a familiar delivery uniform.

Open Source Intelligence

Open source intelligence (OSINT) is information collected from publicly available sources, such as job postings and public records. This publicly available data can reveal an enormous amount of useful data, including the technologies in use in a particular organization, the organization’s structures, and the specific names of people and their positions. OSINT is one of the primary sources of information on which to base social engineering attacks.

Résumés and Job Postings

In résumés, you might find work histories, skill sets, and hobbies, which an attacker can use to set up social engineering attacks based on the target’s skills or interests. In job listings, companies often expose information that they would otherwise consider sensitive, including office and data center locations, network or security infrastructure details, and the software in use. Recruiters might consider it necessary to post this information for the hiring process, but attackers can also use it to plan attacks or add focus to future surveillance efforts.

For example, if you collect information about a company and determine it runs Windows servers in its cloud hosting environment and uses CompanyX antivirus software, you’ve just dramatically reduced the number of variables you must consider when planning attacks against the company. If you collect additional information about the location and members of their information security team, you might also be able to predict the skill level and timing of any responses to your attack, making your attack more effective.

Social Media

Attackers can easily collect OSINT using social media tools, such as Facebook and Twitter, by following someone’s activities, finding their friends and other social contacts, and even tracking their physical location. They can use this information to monitor people or take more direct action, such as blackmail. In many cases, younger people tend to document questionable activities more willingly and may provide a richer source for this type of information.

Attempts to manipulate the outcome of the 2016 US presidential election provide an example of how attackers can take advantage of social media tools. In the months preceding the election, the Russian-based company Internet Research Agency purchased approximately 3,500 Facebook ads intended to incite tensions among targeted groups of voters by touching on themes such as race, policing, and immigration. In February 2018, a US federal grand jury indicted 13 Russians working for Internet Research Agency for these activities.¹ This is a classic example of social engineering, which I’ll discuss in detail later in this chapter.

Public Records

Public records can provide a wealth of information about a target, including evidence of mortgages, marriages, divorces, legal proceedings, and parking tickets. Attackers often use this data to conduct additional searches and locate even more information.

What exactly constitutes a public record can vary based on the geographical location of the record and the agency that holds it. In the United States, the laws in each state differ, so information that you may access legally in one state may be illegal in another.

Google Hacking

Google and other search engines are an excellent resource for information gathering, particularly when attackers make use of advanced search operators, such as the following:

site Limits results to a specific site (site:nostarch.com)

filetype Limits results to a specific file type (filetype:pdf)

intext Finds pages containing a words or words (intext:security)

inurl Finds pages containing a word or words in the URL (inurl:security)

You can combine these operators into a single search to retrieve specific results. For instance, entering site:nostarch.com intext:andress security into a search should return the publisher’s page for this book, as shown in Figure 8-1.

Figure 8-1: Google search operators at work

The Google Hacking Database (https://www.exploit-db.com/google-hacking-database/), shown in Figure 8-2, contains canned Google searches that make use of advanced search operators to find specific vulnerabilities or security issues, such as files that contain passwords or vulnerable configurations and services.

Figure 8-2: The Google Hacking Database

Not only does this provide a set of preassembled searches that you can click easily, but it also demonstrates some of the more complex ways that you can use search operators. For example, the bottom search in Figure 8-2 shows you a combination of three different operators (inurl:, intext:, and ext:). You could easily switch out the terms to repurpose the search for your own use.

File Metadata

Metadata is the data about data found in almost any file that can reveal not only mundane information such as timestamps and file statistics but also more interesting data such as usernames, server names, network file paths, and deleted or updated information. File metadata provides data for searches, sorting, file processing, and so on, and it generally isn’t immediately visible to users. Many professional forensic tools, such as EnCase (https://www.guidancesoftware.com/encase-forensic/), have specific features to quickly and easily recover these data types in forensic investigations.

Image and video file metadata, called EXIF data, includes information such as the camera settings and hardware. You can view and edit EXIF data with ExifTool (https://www.sno.phy.queensu.ca/~phil/exiftool/), a great cross-platform tool that works with a wide variety of file types. Especially in document files that have been around for a while and edited by multiple people, the amount of metadata that they contain may surprise you. Try downloading and using it to analyze a few documents or image files.

Image files produced by devices containing Global Positioning System (GPS) information might also contain location coordinates; many smartphones embed users’ location information into image files if they’ve enabled the location setting on the camera, which means uploading these images to the internet could leak sensitive data.

A multitude of tools exist to assist with information gathering from OSINT (and other) sources. Two of the more common and well-known among these tools are Shodan and Maltego.

Shodan

Shodan, shown in Figure 8-3, is a web-based search engine that looks for information saved on internet-connected devices.

Figure 8-3: Shodan

Shodan allows you to search for specific information, such as particular hardware, software, or open ports. For example, if you knew of a vulnerable version of a specific File Transfer Protocol (FTP) service, you could ask Shodan for a list of all its instances in its database. Likewise, you could ask Shodan for everything that it knows about a domain or server and instantly see where specific vulnerabilities might be present.

Maltego

Maltego (https://www.paterva.com/), shown in Figure 8-4, is an intelligence-gathering tool that uses relationships between particular points of data, called transforms, to discover information related to information that you already have.

Figure 8-4: Maltego

For example, you might start by giving Maltego a website’s domain name and then use a transform to find names and email addresses listed on the website. From these names and email addresses, you could find other addresses and names based on the same mail format elsewhere on the internet. You could also find the server Internet Protocol (IP) addresses that host the domain and then find other domains hosted on the same server.

Maltego displays the results of your search on a graph that shows the links between each of the items discovered. You can use the graph to conduct additional searches on specific items by clicking them and selecting a new transform.

Other Kinds of Intelligence

OSINT and HUMINT are by no means the only kinds of intelligence you can gather. You may also see references to these other types:

Geospatial intelligence (GEOINT) Geographical information, typically from satellites.

Measurement and signature intelligence (MASINT) Measurement and signature data from sensors, such as optical or weather readers. MASINT contains some sensor-specific kinds of intelligence, such as RADINT, or information collected from radar.

Signals intelligence (SIGINT) Data gathered by intercepting signals between people or systems. You may also see this called communications intelligence (COMINT) when referring to communications between people and electronic intelligence (ELINT) when referring to communications between systems.

Technical intelligence (TECHINT) Intelligence about equipment, technology, and weapons, often collected with the purpose of developing countermeasures.

Financial intelligence (FININT) Data about the financial dealings and transactions of companies and individuals, often acquired from financial institutions.

Cyber intelligence/Digital network intelligence (CYBINT/DNINT) Intelligence gathered from computer systems and networks.

Most other types of intelligence will fit into one of these categories.

Types of Social Engineering Attacks

This section discusses some of the social engineering attacks a person could conduct with the information gathered in the previous section.

Pretexting

In pretexting, attackers use information they’ve gathered to assume the guise of a manager, customer, reporter, co-worker’s family member, or other trusted person. Using a fake identity, they create believable scenarios that convince their targets to give up sensitive information or perform actions they wouldn’t normally do for strangers.

An attacker could use pretexting in face-to-face encounters or over some communication medium. Direct interactions require a heightened level of attention to details such as body language, while indirect encounters, such as those conducted over the phone or through email, require a stronger focus on verbal mannerisms. Both types require good communication and psychological skills, specialized knowledge, and a quick mind.

Pretexting gives social engineers an advantage. For example, if the social engineer can drop names, provide details about the organization, and give the target sufficient cause to believe that they’re entitled to the information or access for which they’re asking—or, for that matter, that they already have it—their chances of success increase substantially.

Phishing

Phishing is a social engineering technique in which an attacker uses electronic communications such as email, texting, or phone calls to collect the target’s personal information or install malware on their system, often by convincing the target to click a malicious link.

The fake sites used in web-based phishing attacks typically resemble well-known websites, such as banking, social media, or shopping sites. Some look obviously fake, with poor imitations of the company’s logo and terrible grammar, while others are extremely difficult to distinguish from the legitimate page. Fortunately, many browsers have improved security in recent years and now render phishing attacks more difficult by showing warnings like the one in Figure 8-5.

Figure 8-5: A phishing warning

Even without these warnings, however, most phishing attacks fail unless the target has an account on the site being faked; someone who doesn’t have a MyBank bank account won’t fall for a phishing attack that redirects to a fake MyBank bank website. Even if the target does have an account, people have become more cautious of unsolicited emails from their banks or other websites. In general, phishing attacks rely on a lack of attention to detail on the recipient’s part, and their rate of success remains low.

To achieve higher rates of success, attackers may turn to spear phishing, or targeted attacks against specific companies, organizations, or people. A spear phishing attack requires advanced reconnaissance so that the message appears to come from someone the target would trust, such as human resources staff, a manager, the corporate IT support team, a peer, or a friend.

While a normal phishing attacks might appear clumsy and poorly constructed, aimed at tricking a small percentage of a large pool of recipients, spear phishing attacks take the opposite approach. For example, spear attackers typically send clean emails containing the expected logos, graphics, and signature block, and they’ll disguise any malicious links present. If the attack exists to steal credentials for a site or service, the attacker may even use the freshly stolen credentials to log the target into the real site, leaving no error message or broken session to clue them in that something strange took place.

Tailgating

Physical tailgating, or piggybacking, is the act of following someone through an access control point, such as secure door, instead of using the credentials, badge, or key normally needed to enter. The authorized person may let you in intentionally or accidentally.

Tailgating happens in almost any place that uses technical access controls, partly because of the carelessness of authorized users and partly because most people tend to avoid confrontation. A few tricks of equipment, such as knowing which props to use, and the use of psychology to allow attackers to play on the sympathies of others will aid them in their tailgating efforts.

FURTHER RESOURCES ON SOCIAL ENGINEERING

Visit Chris Hadnagy’s website https://www.social-engineer.com/ and his excellent book Social Engineering: The Science of Human Hacking for more information about social engineering. Hadnagy goes into much greater depth than I do here about what social engineering attacks can do.

Building Security Awareness with Security Training Programs

To protect your organization, you’ll have to build security awareness in your users by instituting a security training program. These programs often consist of instructor-led or computer-based lessons conducted during the new-employee onboarding process, followed up with mandatory quizzes. You might also repeat the training at regular intervals so the employee retains the information.

This section outlines some of the topics you should typically cover in these training programs.

Passwords

Although you can use technical tools to make sure users choose strong passwords, you can’t easily control what users will do with those passwords. An employee could write their password down and stick it to the underside of their keyboard, for example, or share it with other users for convenience’s sake.

Another kind of harmful behavior is using the same password for multiple accounts. Even if you force a user to create a strong password on a given system in the workplace, the user might manually synchronize all other systems in the organization to the same password (including their virtual private network credentials allowing external access to the organization’s networks) and then proceed to go home and do the same with their internet forum credentials, email, and online gaming passwords to make their life easier. Unfortunately, if an attacker compromises the password database for their forum and publishes the user’s email address and decrypted password, the attacker gains access to a disturbing amount of information—possibly including instructions for connecting to the company VPN that the user emailed to their home address.

Poor password hygiene is, unfortunately, a difficult problem to solve by technical means, and education is one of the best ways of tackling it. You should push users to create strong passwords even when they’re not directly forced to do so, tell them not to leave or record their passwords where they might easily be compromised, and ask them not to use the same password repeatedly across multiple systems or applications.

Social Engineering Training

Training users to recognize and respond to social engineering attacks can be an incredibly arduous task because such attacks take advantage of our behavioral norms and tendencies. Thankfully, public awareness about phishing emails and fraud in general has grown.

Broadly, you should teach your users to be suspicious of anything that seems unusual, including atypical requests or emails in their inboxes and strangers in their working environments, even when these occurrences seem wrapped in a layer of normalcy.

Ask people to trust but verify when faced with even the slightest doubt. Your users may flood your security operations center with calls and emails, but at least they won’t wire thousands of dollars to someone in a foreign country claiming to be the company vice president who was mugged while on a sales trip and is in dire need of funds to return home.

Network Usage

You should discuss proper network usage with your users. As I’ll cover in Chapter 10, people today have access to a variety of networks, both wired and wireless, from relatively restricted ones in the workplace to wide-open networks in homes, coffee shops, and airports.

An uneducated user might assume that connecting a laptop to the network in a conference room at work is the same as connecting to the wireless network in a hotel, which is also the same as connecting to a network in an airport. Generally, people treat accessing networks in the same way they treat accessing any utility, like the power provided by a wall outlet or the light given off by a lamp; they expect it to be there and to function as expected. Beyond this, most people don’t think too much about the risks present.

You should guide users toward behaviors that will protect the enterprise network. That means you shouldn’t typically allow foreign devices to connect to it. Users need to know they can’t allow vendors to plug in a device in a conference room and that they shouldn’t connect their iPads to the production network, for example. You should instead provide a proper alternative network that outside devices can use, like a guest wireless network, and make sure that users know how to connect to it, as well as the parameters within which they can use it.

Also, you should restrict the use of corporate resources on outside networks, a problem that has bitten many organizations badly over time. If you load your laptop with sensitive data and then connect to the network at the local coffee shop or hotel, you may accidentally share this data with everyone else on the network.

An easy technical solution to this problem is to implement a VPN that allows users to access the corporate network. You should configure the VPN client to automatically connect the device to the VPN whenever it finds itself on a foreign network. Additionally, you should teach your users to avoid connecting devices containing sensitive information to insecure networks.

Malware

Educating users about malware generally involves teaching them not to indiscriminately click things. While they’re surfing the web, opening email attachments, navigating social networks, and using smartphones, they should look out for the following common red flags:

Email attachments from people they don’t know

Email attachments containing file types that are potentially executable and could contain malware, such as EXE, ZIP, and PDF

Web links using shortened URLs such as http://bit.ly/ (if in doubt, they can verify the destination of shortened URLs with tools like https://linkexpander.com/ or http://unshorten.me/)

Web links with names that differ slightly from those you expect (myco.org instead of myco.com, for example)

Smartphone applications from nonofficial download sites

Pirated software

If you instill a healthy sense of paranoia in your users, they’ll call your help desk or security team to ask questions before immediately clicking suspicious links.

Personal Equipment

You should set rules for when and how employees can use personal equipment in the workplace. Typically, you might allow them to use it at the border of the organization’s network; that means you’d let them bring their laptops to work and attach them to a guest wireless network but not to the same network as the company’s production systems.

You should also be sure to communicate that these policies apply to devices such as vendor laptops or mobile devices that can connect to networks.

Clean Desk Policies

A clean desk policy states that sensitive information shouldn’t be left unattended on a desk for any significant period of time, such as overnight or during a lunch break. When introducing such a policy, you should also discuss how to properly dispose of sensitive data stored on physical media, such as paper or tape, by using shred bins, data destruction services, and media shredders.

Familiarity with Policy and Regulatory Knowledge

Last, but certainly not least, if you expect your users to follow the rules, you need to communicate them effectively. You probably won’t actually educate them if you just send an email to all users containing a link to a lengthy policy and then have them attest to having read it. Instead, you might try condensing the most critical part of your policy into a kind of crib notes or highlights reel to make sure users retain the key points.

Also, if you’re creating a training presentation, you can try to make it more engaging. For instance, if you have an hour allotted to conducting security awareness training for newly hired employees, you might shorten your lecture portion to 30 minutes and then spend the second half of the time conducting an interactive quiz show–style game on the material you just covered. Once you’ve added an element of competition by dividing the class into teams and adding an incentive (such as prizes for the winners), you’ll have created a more interesting environment.

You can also get your users’ attention with posters, giveaways of pens or coffee mugs, and newsletters. If you present the information through repeated and varied avenues, you’re more likely to educate users in the long term.

Summary

In this chapter, you explored a variety of issues concerning the human element of information security: the security issues that you can’t address by technical means alone. Whether because of mere carelessness or targeted social engineering attacks, the people who staff your organizations pose a security challenge that you can’t directly address with technical controls.

I discussed types of social engineering attacks, and you saw how attackers put these techniques to use to solicit information or coerce unauthorized actions from people in your organizations. I also covered how to build security awareness and training programs. Common issues to discuss with users include protecting passwords, recognizing social engineering attacks and malware, using networks and personal equipment safely, and adhering to a clean desk policy. If you make your security awareness and training programs engaging, this information is more likely to stick with users over time.

Exercises

Why are people the weak link in a security program?

Define tailgating. Why is it a problem?

How can you more effectively reach users in your security awareness and training efforts?

Why shouldn’t you allow employees to attach personal equipment to your organization’s network?

How might you train users to recognize phishing email attacks?

Why is it important not to use the same password for all your accounts?

What is pretexting?

Why might using the wireless network in a hotel with a corporate laptop be dangerous?

Why might clicking a shortened URL from a service such as bit.ly be dangerous?

Why is it important to use strong passwords?

9PHYSICAL SECURITY

In this chapter, I’ll discuss physical security, which is the set of security measures that we put in place to protect our people, equipment, and facilities. In most places, you’ll find physical security measures such as locks, fences, cameras, guards, and lighting. In higher-security environments, you might also notice iris scanners, mantraps (an access control that requires you to step through two locking doors to enter a building, similar to a phone booth with two entrances), or identification badges equipped to store certificates.

Physical security involves the protection of three main categories of assets: people, equipment, ...

10
NETWORK SECURITY

A computer network is a group of computers or other devices that are connected to facilitate the sharing of resources. You likely depend on a variety of networks to function daily. Networks control and enable modern automobiles, airplanes, medical devices, refrigerators, and countless other devices. Networks provide the ability for you to communicate, navigate road systems, go to school, play games, watch TV, and listen to music. Without a secure and stable system of networks, many of the daily conveniences that you enjoy would be made considerably more difficult to interact with or just fail to function entirely.

Your networks may face threats from attackers; they may also suffer from misconfigurations of their infrastructure or network-enabled devices, or even from simple outages. Most of the world is network dependent, so losing network connectivity and the services it provides can suffocate you. At worst, it can devastate your business.

In January 2017, civil unrest in Cameroon reached a high point when large-scale protests erupted over the dominance of French in a country where both French and English are official languages. In what appears to have been an attempt to rein in the protestors, the government deliberately disconnected large, primarily English-speaking areas of the country from the global networks that comprise the internet. These regions remained offline for 93 days before the government restored access.¹ These types of outages can have wide-reaching impacts across industries, disrupting medical care, communications, employment, education, shopping, and many other aspects of people’s lives.

Although the situation in Cameroon may be an extreme example, smaller network outages and other malfunctions cause serious impacts all over the world every day. Some of these problems may result from technical issues. Others may result from the specific distributed denial-of-service (DDoS) attacks (DoS attacks that originate from many distributed sources) I’ll discuss in this chapter, or from temporary causes entirely unknown to the network users.

This chapter will cover the infrastructure and devices you can put in place to secure your networks and the methods you can use to protect the network traffic itself. You’ll also learn about tools that can help verify your security.

Protecting Networks

You can use two methods to protect your networks and network resources. One option is to design your networks securely by laying them out so they’re resistant to attack or technical mishap. You can also implement a variety of devices, such as firewalls and intrusion detection systems, in and around your networks.

Designing Secure Networks

By designing your networks properly, you can prevent some attacks entirely, mitigate others, and, when you fail, fail in a graceful way.

One strategy for reducing the impact of attacks is network segmentation. When you segment a network, you divide it into multiple smaller networks called subnets. You can control the flow of traffic between subnets, allowing or disallowing it based on a variety of factors or even blocking the flow of traffic entirely if necessary. Properly segmented networks can boost network performance by containing certain traffic to the portions of the network that need to see it, and they can help you localize technical network issues. Additionally, network segmentation can prevent unauthorized network traffic or attacks from reaching particularly sensitive portions of the network.

You can also secure your networks by funneling traffic through choke points, or locations where you can inspect, filter, and control the traffic. The choke points might be the routers that move traffic from one subnet to another, the firewalls that filter traffic through your networks or portions of your networks, or the application proxies that filter the traffic for applications such as web or email. I’ll discuss some of these devices at greater length in the next section of this chapter.

Creating redundancies when designing your networks can also help mitigate issues. Certain technical failures or attacks may render portions of your technology—including networks, network infrastructure devices, or border devices such as firewalls—unusable. For example, if one of your border devices is subjected to a DDoS attack, you can’t do much to stop it. You can, however, switch to a different internet connection or route traffic through a different device until you can come to a longer-term solution.

Using Firewalls

A firewall is a mechanism for maintaining control over the traffic that flows in and out of networks. One of the first papers to discuss the idea was “Simple and Flexible Datagram Access Controls,” written in 1989 by Jeffrey Mogul,² then at Digital Equipment Corporation. In 1992, Digital Equipment Corporation created first commercial firewall, the DEC SEAL.³

You typically place firewalls at points where the level of trust changes, like the border between an internal network and the internet, as shown in Figure 10-1. You may also install a firewall on your internal network to prevent unauthorized users from accessing network traffic of a sensitive nature.

Figure 10-1: Firewall placement

Many of the firewalls in use today work by examining the packets (blocks of data) moving through the network to determine which ones it should allow in or out. They base their decision on a variety of factors. For example, they might allow or disallow traffic depending on the protocol being used to let web and email traffic pass but block everything else. I’ll go over the types of firewalls in this section.

Packet Filtering

In packet filtering, one of the oldest and simplest firewall technologies, the firewall looks at the contents of each packet in the traffic individually and either allows or disallows it based on the source and destination IP addresses, the port number, and the protocol being used.

Since the packet filtering firewall examines each packet individually and not in concert with the rest of the packets making up the traffic, an attacker could slip attacks through this type of firewall by sending attack traffic that spans more than one packet. To find these, you need to employ more complex methods of detection.

Stateful Packet Inspection

Stateful packet inspection firewalls, or stateful firewalls, function on the same general principle as packet filtering firewalls, but they can keep track of the traffic at a granular level. While a packet filtering firewall examines an individual packet out of context, a stateful firewall can watch the traffic over a given connection. A connection is defined by the source and destination IP addresses, the ports being used, and the already existing network traffic.

A stateful firewall uses a state table to keep track of the connection state (the normal sequence of traffic) and allows traffic that is part of a new or already established connection only. This can help to prevent some intentionally disruptive attack traffic that doesn’t resemble a proper and expected connection. Most stateful firewalls can also function as packet filtering firewalls, and they often combine the two forms of filtering. In addition to packet filtering features, stateful firewalls might also identify and track the traffic related to a user-initiated connection to a website, and they’ll know when the connection has been closed, meaning no further legitimate traffic would be present.

Deep Packet Inspection

Deep packet inspection firewalls add yet another layer of intelligence to your firewall capabilities because they can analyze the actual content of the traffic that flows through them. While packet filtering firewalls and stateful firewalls can look at only the structure of the network traffic to filter out attacks and undesirable content, deep packet inspection firewalls can reassemble the contents of the traffic to see what it will deliver to the application for which it’s destined.

To use an analogy, when you ship a package, the parcel carrier will look at the size and shape of the package, how much it weighs, how it’s wrapped, and the sending and destination addresses. This is generally what packet filter firewalls and stateful firewalls do. In deep packet inspection, the parcel carrier would do all of this as well as open the package, inspect its contents, and then make a judgment about whether to ship it.

Although this technology has great promise for blocking many attacks, it also raises privacy concerns. In theory, someone in control of a deep packet inspection device could read every one of your email messages, see every web page exactly as you saw it, and easily listen in on your instant messaging conversations.

Proxy Servers

Proxy servers are special kinds of firewall that pertain specifically to applications. These servers provide security and performance features, generally for an application, such as mail or web browsing. Proxy servers can provide a layer of security for the devices behind them by serving as choke points, and they allow you to log the traffic that goes through them for later inspection. They are a single source for requests.

Many companies rely on proxy servers to keep spam from reaching their users’ email accounts and lowering productivity, to keep employees from visiting websites that might have objectionable material, and to filter out traffic that might indicate the presence of malware.

DMZs

A demilitarized zone (DMZ) is a layer of protection that separates a device from the rest of a network. You accomplish this by using multiple layers of firewalls, as shown in Figure 10-2. In this case, the internet-facing firewall might allow traffic through to a web server sitting in the DMZ, but the internal firewall would not allow traffic from the internet through to the internal servers.

Figure 10-2: A DMZ

The DMZ creates a zone that allows public-facing servers to be accessed from the outside while both providing a measure of protection for them and restricting traffic from those servers from penetrating the more sensitive portions of your network. This helps to prevent the scenario where attackers compromise your public-facing servers and use them to attack the other servers behind them.

Implementing Network Intrusion Detection Systems

Intrusion detection systems (IDS) are hardware or software tools that monitor networks, hosts, or applications for unauthorized activity. You can classify IDS based on the way they detect attacks: signature-based detection and anomaly-based detection.

Signature-based IDS work like most antivirus systems. They maintain a database of the signatures that might signal an attack and compare incoming traffic to those signatures. In general, this method works well—except when an attack is new or has been specifically constructed to not match existing attack signatures. One of the large drawbacks to this method is that if you don’t have a signature for the attack, you may not see it at all. In addition to this, the attacker crafting the traffic may have access to the same IDS tools you’re using and may be able to test the attack against them to specifically avoid your security measures.

Anomaly-based IDS typically work by determining the normal kinds of traffic and activity taking place on the network. They then measure the present traffic against this baseline in order to detect patterns that aren’t present in the traffic normally. This method can detect new attacks, or attacks that have been deliberately assembled to avoid IDS, very well. On the other hand, it may produce a larger number of false positives than a signature-based IDS because it might flag legitimate activity that causes unusual traffic patterns or spikes in traffic.

You can, of course, install an IDS that uses both the signature-based and anomaly-based methods, giving you some of the advantages of each type of detection. This would detect attacks more reliably, although it would perhaps operate a bit more slowly and cause a lag in detection.

You typically attach a network IDS to a location where it can monitor the traffic going by, but you need to place them carefully so the quantity of data to examine won’t overloaded it. Putting a network IDS behind another filtering device, such as a firewall, can eliminate some of the obviously unwanted traffic.

Since network IDS typically examine a large amount of traffic, they can generally do only a relatively cursory inspection of it, and they may miss some types of attacks, especially those that are specifically crafted to pass through such inspections. Packet crafting attacks use packets of traffic that carry attacks or malicious code but are designed to avoid detection by IDS, firewalls, and other similar devices.

Protecting Network Traffic

In addition to protecting your networks from intrusion, you need to separately protect the traffic that flows over them. When you send data over networks that aren’t secure or trusted, an eavesdropper can glean a large amount of information from what you send. If you use applications or protocols that don’t encrypt the information they’re sending, you may end up giving away your login credentials, credit card numbers, banking information, and other data to anyone who happens to be listening.

Attackers can intercept data from both wired and wireless networks, often with little effort, depending on the design of the network. But although insecure networks are a security problem, they’re not an insurmountable one, if you have the right tools.

Using Virtual Private Networks

Virtual private networks (VPNs) can help you send sensitive traffic over insecure networks. Often called a tunnel, a VPN connection is an encrypted connection between two points. You usually create the connection using a VPN client application on one end and a device called a VPN concentrator on the other end—a client and server, in simple terms. The client uses the VPN client application to authenticate to the VPN concentrator, usually over the internet. Once you’ve established a connection, all traffic exchanged from the network interface connected to the VPN flows through the encrypted VPN tunnel.

VPNs can allow remote workers to access the internal resources of their organization; in that case, the worker’s device acts as though it were connected directly to the organization’s internal network.

You could also use VPNs to protect or anonymize the traffic you’re sending over untrusted connections. Companies such as StrongVPN (https://strongvpn.com/) sell their services to the public for exactly such purposes. You might use these to keep your internet service provider from logging the contents of your traffic, stop people on the same network from eavesdropping on your activity, or obscure your geographical location and bypass location-oriented blocking. People who use peer-to-peer (P2P) file-sharing services to share pirated media sometimes hide their traffic and IP addresses with VPNs.

Protecting Data over Wireless Networks

If you use wireless networks to send your data, you face several specific security risks. Today, a wide variety of places provide free wireless internet access. In general, public wireless networks are set up without a password or encryption of any kind—measures you’d normally put in place to protect the confidentiality of the traffic flowing over the network. Even in cases where accessing a network does require a password, like in a hotel, everyone else connected to the hotel’s network could potentially see your data. The present record for the range of an unamplified 802.11 wireless connection is about 238 miles.⁴

In addition, it’s possible for someone to attach wireless devices to your network without your knowledge. Unauthorized wireless access points, commonly known as rogue access points, present a serious security issue. For example, if you worked in an area that banned wireless connections, such as a secure government facility, an enterprising individual could decide to bring in an access point of his own and install it under his desk to provide wireless access to a nearby outdoor smoking area. Although he might have good intentions, his simple action might have invalidated an entire set of carefully planned network security measures.

If the rogue access point were set up with poor security or no security at all, the well-intentioned access point installer would provide anyone within range with an easy path directly into the network that bypassed any border security in place. It’s possible that a network IDS might pick up the activity from the rogue access point, but you can’t guarantee that it will. A better solution to finding rogue equipment is to carefully document the legitimate devices that are part of the wireless network infrastructure and regularly scan for additional devices using a tool such as Kismet, which I’ll discuss later in this chapter.

When it comes to the legitimate and authorized devices on your network, your chief method of protecting the traffic that flows through them is with encryption. You can separate the encryption used by 802.11 wireless devices—the most common family of wireless network devices—into two major categories: Wired Equivalent Privacy (WEP) and Wi-Fi Protected Access (WPA, WPA2, and WPA3). WPA3 is the current standard. Compared to the other common encryption types, WPA3 makes it easier to set up client devices and offers stronger encryption, improving protections against brute-force attacks and eavesdropping.⁵

Using Secure Protocols

One of the simplest and easiest ways you can protect your data is by using secure protocols. Many of the more common and older protocols, such as File Transfer Protocol (FTP) for transferring files, Telnet for interacting with remote machines, and Post Office Protocol (POP) for retrieving email, handle data insecurely. Such protocols often send sensitive information, such as logins and passwords, in cleartext (unencrypted data) over the network. Anyone listening on the network can pick up the traffic from such protocols and easily glean the sensitive information.

Many insecure protocols have secure equivalents, as I’ll discuss at greater length in Chapter 13. In brief, you can often find a secure protocol for the type of traffic you want to carry. Instead of operating over the command line with Telnet, you can use Secure Shell (SSH), and instead of transferring files with FTP, you can use Secure File Transfer Protocol (SFTP), which is based on SSH.

SSH is a handy protocol for securing communications because you can send many types of traffic over it. You can use it for file transfers and terminal access, as mentioned, and to secure traffic in a variety of other situations, such as when connecting to a remote desktop, communicating over a VPN, and mounting remote file systems.

Network Security Tools

You can use a broad variety of tools to improve your network security. Attackers rely on many of the same tools to penetrate networks, so by using them to locate security holes in your networks, you can preemptively keep the attackers out.

An enormous number of security tools are on the market today, and many of them are free or have free alternatives. Many run on Linux operating systems and can be a bit difficult to configure. Fortunately, you can use these tools without having to set them up by installing one of the Security Live CD distributions, which are versions of Linux that come with all the tools preconfigured. One of the better-known distributions is Kali, available for download at https://www.kali.org/.

As I discussed in earlier chapters, the key to assessing vulnerabilities is to conduct assessments thoroughly and regularly enough that you can find the holes before the attackers do. If you perform penetration testing only on an occasional and shallow basis, you’ll likely not catch all the issues present in your environment. Additionally, as you update, add, or remove the various network hardware devices and the software running on them, the vulnerabilities present in your environment will change. It’s also worth noting that most of the tools you’re likely to use will be capable of finding only known issues. New or unpublished attacks or vulnerabilities, commonly known as zero-day attacks, can still take you by surprise.

Wireless Protection Tools

As I discussed earlier in the chapter, attackers who can access your network via a wireless device could bypass all your carefully planned security measures. If you don’t take steps to protect against unauthorized wireless devices, such as rogue access points, you could allow a large hole in your network security and never know it.

You can use several tools to detect wireless devices. One of the best-known tools for detecting such devices is called Kismet. It runs on Linux and macOS and can also be found on the Kali distribution. Penetration testers commonly use Kismet to detect wireless access points and can find them even when they’re well-hidden.

Other tools enable you to break through the different kinds of encryption in use on wireless networks. A few of the more common ones, for cracking WEP, WPA, and WPA2, include coWPAtty and Aircrack-NG.

Scanners

Scanners, mainstays of the security testing and assessment industry, are hardware or software tools that enable you to interrogate devices and networks for information. You can divide scanners into two main categories: port scanners and vulnerability scanners. These types sometimes overlap, depending on the specific tool.

In network security, people tend to use scanners as tools for discovering the networks and systems in an environment. One of the more famous port scanners is a free tool called Nmap, short for network mapper. Although generally considered a port scanner, Nmap can also search for hosts on a network, identify the operating systems those hosts are running, and detect the versions of the services running on any open ports.

Packet Sniffers

A network or protocol analyzer, also known as a packet sniffer or just plain sniffer, is a tool that can intercept (or sniff) traffic on a network. The sniffer listens for any traffic that your computer or device’s network interface can see, whether you were intended to receive it or not.

NOTE

Sniffer (with a capital S) is a registered trademark of NetScout (previously Network General Corporation). I use the term sniffer in the generic sense in this book.

To use a sniffer, you have to place it on the network in a position that allows you to see the traffic you’d like to sniff. In most modern networks, the traffic is segmented in such a way that you’ll likely not be able to see much of it at all (other than the traffic you generate from your own machine). That means you’ll likely need to gain access to one of the higher-level network switches and may need to use specialized equipment or configurations to access your target traffic.

A classic sniffer invented in the 1980s, Tcpdump, is a command-line tool. It has a few other key features, such as the ability to filter traffic. Tcpdump runs only on UNIX-like operating systems, but Windows systems can run a version of the tool called WinDump.

Previously known as Ethereal, Wireshark is a fully featured sniffer capable of intercepting traffic from a wide variety of wired and wireless sources. It has a graphical interface, shown in Figure 10-3, and includes many filtering, sorting, and analysis tools. It’s one of the more popular sniffers on the market today.

Figure 10-3: Wireshark

You can also use Kismet, a tool discussed earlier in this chapter, to sniff from wireless networks.

Packet sniffers also come in hardware form, such as the OptiView Portable Network Analyzer from Fluke Networks. Although well-equipped portable analyzers such as this may provide benefits, such as increased capture capacity and capabilities, they’re often expensive, well beyond the budget of the average network or security professional.

Honeypots

A somewhat controversial tool in the network security arsenal, a honeypot is a system that can detect, monitor, and sometimes tamper with the activities of an attacker. You configure them to deliberately display fake vulnerabilities or materials that would make the system attractive to an attacker, such as an intentionally insecure service, an outdated and unpatched operating system, or a network share named “top-secret UFO documents.”

When attackers access the system, the honeypot monitors their activity without their knowledge. You might set up a honeypot to provide an early warning system for a corporation, to discover an attacker’s methods, or as an intentional target to monitor the activities of malware in the wild.

You can also expand honeypots into larger structures by creating networks of them, called honeynets. A honeynet connects multiple honeypots with varying configurations and vulnerabilities, generally with some sort of centralized instrumentation for monitoring all the honeypots on the network. Honeynets can be particularly useful for understanding malware activity on a large scale since you can reproduce a variety of operating systems and vulnerabilities.

An excellent resource for more information on honeypots and honeynets is the Honeynet Project at https://www.honeynet.org/. The Honeynet Project provides access to a variety of resources, including software, the results of research, and numerous papers on the subject.

Firewall Tools

In your kit of network tools, you may also find it useful to include tools that can map the topology of firewalls and help you locate vulnerabilities in them. Scapy (https://github.com/secdev/scapy/) is a well-known and useful tool for such efforts. It can construct specially crafted Internet Control Message Protocol (ICMP) packets that evade some of the normal measures put in place to prevent you from seeing the devices that are behind a firewall and may allow you to enumerate some of them. You can also script Scapy’s abilities to manipulate network traffic and test how firewalls and IDS respond, which could give you an idea of the rules on which they’re operating.

You could use some of the other tools I’ve discussed in this section to test the security of your firewalls, as well. You can use port and vulnerability scanners to look at them from the outside to find any ports that are unexpectedly open or any services running on your open ports that are vulnerable to known attacks. You can also use sniffers to examine the traffic that is entering and leaving firewalls, presuming that you can get such a tool in place in a network location that will enable you to see the traffic.

Summary

When you protect your networks, you should do so from a variety of angles. You should use secure network design to ensure that you’ve properly segmented your networks, that you have choke points to monitor and control traffic, and that you create redundancies where you need them. You should also implement security devices such as firewalls and IDS to protect yourself both inside and outside the networks.

In addition to protecting the networks themselves, you also need to protect your network traffic. To do this, you can use VPNs to secure your connections when using untrusted networks, implement security measures specific to wireless networks, and apply secure protocols.

A variety of security tools can help you keep your networks secure. When working with wireless networks, you can use Kismet. You can also listen in on network traffic with Wireshark or Tcpdump, scan for devices on your networks with Nmap, and test your firewalls using Scapy and other similar utilities. You can also place devices called honeypots on your networks specifically to attract the attention of attackers and then study them and their tools.

Exercises

For what might you use the tool Kismet?

Explain the concept of segmentation.

What are the three main types of wireless encryption?

What tool might you use to scan for devices on a network?

Which tools can you use to sniff traffic on a wireless network?

Why would you use a honeypot?

Explain the difference between signature and anomaly detection in IDS.

What would you use if you needed to send sensitive data over an untrusted network?

What would you use a DMZ to protect?

What is the difference between a stateful firewall and a deep packet inspection firewall?

11OPERATING SYSTEM SECURITY

When you seek to protect your data, processes, and applications against concerted attacks, you’re likely to find weaknesses on the operating system that hosts all of these. The operating system is the software that supports the basic functionality of the device. The primary operating systems in current use are several varieties of Linux and the server and desktop operating systems offered by Microsoft and Apple. If you don’t take care to protect your operating systems, you have no basis for getting to a strong security footing.

You can mitigate threats to the operating system in several ways. One of the easiest methods ...

12
MOBILE, EMBEDDED, AND INTERNET OF THINGS SECURITY

So far, I’ve assumed that you’ll be protecting information contained on traditional desktop or laptop computers. However, you’ll also find vulnerable devices in your pockets, heating and air conditioning systems, security systems, hospital rooms, cars, and a dizzying array of other places. That’s why your security program should include mobile devices, Internet of Things devices, and embedded devices. Internet of Things devices, such as cameras or medical devices, are any internet-connected devices that don’t run a full desktop operating system. Embedded devices are computers that run inside some other device, such as the controller in a car. These technologies are often small and go unnoticed, but they densely litter our world.

In many cases, people overlook security concerns related to these devices because the devices are either ubiquitous, such as smartphones, or rarely thought about, such as medical devices. However, when they’re compromised, the consequences can range from embarrassing to fatal. If attackers compromise these systems, they could steal our photo libraries, cause rolling power outages that black out half the country, or increase the dosage on our insulin pumps to issue a fatal dose.

Each of the areas I’ll discuss in this chapter has its own specific security issues, some of which resemble those discussed in other chapters and some of which are entirely unique.

Mobile Security

As mobile devices become more prevalent, they also grow increasingly vulnerable to security issues. These devices have powerful hardware resources and capabilities, and they’re generally connected to some kind of network at all times. They move in and out of environments with regularity and store and transmit data without notice—and don’t necessarily comply with the basic security measures considered normal on standard, nonmobile computers.

Mobile devices include smartphones and tablets most likely running iOS or Android operating systems, as well as a variety of head-mounted devices and smartwatches. People use mobile devices to send and receive email, surf the web, edit documents, play videos or games, and listen to music—in short, most of the same functions as nonmobile computers.

The line between mobile devices and computers has become considerably blurred. On the one hand, some of our smartphones rival the processing power and storage capacity of computers and have similarly capable operating systems. On the other hand, some computers, like small ultrabooks and devices such as the Raspberry Pi, run on minimal hardware and use little power. Some even run mobile operating systems, such as Android. Since distinguishing between these devices becomes a question of design philosophy rather than physical capability, we should treat them the same from a security perspective.

Protecting Mobile Devices

That said, people protect mobile devices in a few specific ways. Usually, businesses will use both software and some sort of policy to maintain mobile device security.

Mobile Device Management

Many devices used in organizational environments have well-established sets of tools and features allowing you to centrally manage them. Being centrally managed means that these devices are under the control of one main system that maintains them. Central management lets you automatically patch vulnerabilities and upgrade software, force users to change their passwords at regular intervals, regulate and track installed software, and adjust a device’s settings to a standard dictated by a particular policy.

For mobile devices, you can generally accomplish these tasks through an external management solution, a category referred to as mobile device management, enterprise mobility management, or unified endpoint management, depending on slight differences in features and vendors’ preferences. Over time, these solutions have expanded to include desktop and server operating systems.

The exact architecture of a management solution will vary from one vendor to another, but most use an agent (a piece of software) on the mobile device to enforce a certain configuration on the device. These agents typically regulate access to a business’s resources, such as email, calendaring, or network resources, and can discontinue a client’s access if it becomes noncompliant, if the device is stolen, or if the user’s employment is terminated. Additionally, many management solutions let you remotely wipe a device, either completely or just corporate data, or disable it entirely.

As the distinction between mobile and nonmobile devices becomes narrower, vendors of management solutions have begun to support some traditionally nonmobile devices, allowing you to remotely manage both mobile and nonmobile devices using the same tools and techniques.

Deployment Models

Most organizations have a bring-your-own-device (BYOD) policy regulating the use of personal and corporate devices in the workplace. The policy might allow only corporate-owned devices to interact with enterprise resources, personal devices only, or something in between.

Allowing only corporate-owned mobile devices can make it easier for the organization to centrally manage them. Using a mobile device management solution, you might ban the use of personal email and file-sharing apps, for instance, and disable a user’s ability to install non-business-related apps. You can also force users to install updates or security patches and change their password regularly, leading to a more secure mobile environment. We typically call corporate-owned mobile devices either corporate-owned business only (COBO) or corporate-owned personally enabled (COPE), depending on whether you can use them for personal reasons or not.

If, on the other hand, you allow personal devices only and don’t manage them with mobile device management, you won’t have many of these capabilities. Certain tools also provide some additional security functionality, such as allowing you to delete data remotely without actively monitoring them, but a savvy technical user may be able to subvert such measures. While a small organization with minimal resources might use this method to administer a complex mobile infrastructure, this probably wouldn’t be optimal for a large enterprise.

Many organizations allow a mix of personal and corporate-owned devices and sometimes restrict some of the personal devices’ capabilities. You could allow the more secure and trusted devices access to a greater set of resources, while still letting people access basic services, such as email, on their personal devices, providing they agree to have these devices managed by a management tool and accept a reasonable set of security features.

Mobile Security Issues

Mobile devices face several specific security issues. While this section is by no means exhaustive, it outlines some of the more common areas of risk.

The Baseband Operating System

Every modern mobile device contains an operating system underneath the one you can see, called the baseband operating system. This tiny operating system runs on its own processor and generally handles the phone’s hardware, like radios, universal serial bus (USB) ports, and global positioning system (GPS). The type of baseband operating system varies based on the processor it runs on, and the operating systems are generally proprietary to the manufacturer of the device. This lack of standardization, coupled with infrequent device updates (I’ll return to this momentarily), can cause vulnerabilities that last for years, often for the life of the device.

Given that the baseband operating systems work outside the view of the device’s “normal” operating system, attackers can use them to carry out a variety of attacks. For example, in October 2018, attackers spied on US President Trump’s cell phones via the Signaling System No. 7 (SS7) protocol¹ used by the baseband operating system and cell phone carriers for routing calls and text messages, among other things. The SS7 protocol was developed in 1975, in an era where security was not a design goal.

Unfortunately, short of an update from the device manufacturers, you can’t do much to directly fix these vulnerabilities other than putting additional controls in place to compensate for them, such as additional encryption or application segmentation on the device.

Jailbreaking

Jailbreaking, or rooting, a mobile device means modifying it to remove restrictions that the device manufacturer placed on it. You typically do this to open normally inaccessible features, such as administrative access, and to install apps the device vendor hasn’t approved.

Typically, you accomplish a jailbreak by conducting a series of exploits to bypass the security features of the device. For the jailbreak to persist through a reboot, you often have to disable these security features or patch the files on the device to remove them entirely. Mobile devices typically have many layers of security in place, and a persistent jailbreak typically requires punching a permanent hole all the way through to the kernel that is the core of the operating system. This, of course, leaves the device open to malicious apps and outside attacks.

When vendors release new operating systems, they include fixes to patch the holes that allowed the last jailbreak to take place. The jailbreak developers then start working on a new generation of jailbreaks as the vendor releases the next beta version of its operating system, and the cycle continues.

To stop jailbreaking on a device, you could attach it to an external management solution, which installs its own apps to provide additional security layers. Some might be able to prevent jailbreaking entirely or at least alert you about attempts to jailbreak the device. Mobile anti-malware apps may provide a measure of protection as well.

Malicious Apps

Malicious apps can compromise the security of mobile devices. Mobile apps often request a great number of privileges when they’re installed; often, they can access sensitive information, log into other apps, read email, and use the network connection.

You might think you’re safe if you use an unjailbroken device and download apps from the standard operating system app store, but this isn’t the case. The measures that vendors put in place to keep malicious apps out of their stores are by no means foolproof. In January 2018, researchers from RiskIQ analyzed thousands of apps in the Apple and Google app stores and found hundreds of malicious cryptocurrency apps designed to steal coins from users.²

Worse still are apps designed especially for jailbroken devices, sourced from the shadowy back alleys of the internet. While the normal vendor app stores have security measures in place and at least some level of vetting for the apps in them, these back-alley apps have no such protections. They could do nearly anything in the background, out of site of the user interface, and you’d have no way of knowing at all.

To protect against malicious apps, you should stick to the standard app stores and avoid jailbroken devices. Apps from Apple’s app store are typically more secure than those from others because Apple has a higher standard for the apps it accepts. You could also use an anti-malware app for additional protection.

Updates (or Lack Thereof)

Lastly, updates to mobile devices and their apps can cause major security problems—specifically when they don’t happen.

People depend on the device manufacturer to issue updates to the primary and baseband operating systems, but these updates don’t always occur in a timely manner, or at all. Typically, a manufacturer will update a device consistently for two or three years and then release new updates infrequently, or never again, because it’s more profitable to sell you a new device than keep older ones up-to-date.

Apple devices tend to fare slightly better than most, but even Apple’s updates become less frequent after a few years. Google, with its looser licensing of the Android operating system, typically leaves updates up to the device’s manufacturer, so the experience there can vary. Additionally, the descriptions of device updates often lack specific details, so smaller updates, such as those to fix specific security issues, may be difficult to learn more about.

App updates can also be problematic. Aside from the apps the device shipped with, you have no guarantee at all that an app’s creator will update the app or fix security issues, especially when it comes to smaller apps.

You can, to a certain extent, manage the update issue yourself. By carefully selecting devices from vendors that have better track records for updates over time, you can keep these devices safer for longer. Currently, devices from Apple and those sold directly by Google receive more frequent updates and operating system upgrades. For apps, the same holds relatively true—apps from larger vendors have a higher likelihood of being updated over time.

Embedded Security

An embedded device is a computer contained inside in another device that typically performs a single function. Embedded devices include everything from the computer controlling the car wash you drove through the other day to the insulin pump keeping a diabetic person healthy. Even the drivers inside some newer LED flashlights are tiny embedded devices. These devices surround us, and you’d have to go to great extremes to avoid them.

Where Embedded Devices Are Used

I’ve talked a little bit already about where embedded devices can be found. Now let’s look at some of the more common use cases for them.

Industrial Control Systems

Industrial control systems and supervisory control and data acquisition systems commonly use embedded devices. An industrial control system is any system controlling an industrial process. A supervisory control and data acquisition system is a kind of industrial control system that specifically monitors and controls systems over long distances, often those related to utilities and other infrastructure.³

These systems control our water systems, nuclear power plants, oil pipelines, and a variety of other critical infrastructure. If an attacker took control of or tampered with them, the effects could reach into the physical world. Triton, discussed in the previous chapter, targeted industrial control systems. The Stuxnet virus in 2007 is another excellent example of the impact of attacks against these types of systems. Believed to have been a joint project of the US and Israeli governments, Stuxnet specifically targeted the systems controlling Iran’s facilities for enriching uranium.⁴ The virus tampered with the controls of the centrifuges used in the facility, causing the rotors in them to spin faster, wobbling the centrifuges until they failed. At the same time, the virus prevented the sensors detecting this activity from communicating with the safety systems that would have prevented this unusual activity.⁵

While these devices ostensibly have high levels of security, much of it is security through obscurity, a concept I’ve discussed in previous chapters. Industrial control systems often run on proprietary real-time operating systems (RTOSs), similar to the baseband operating systems used in mobile devices, and have many of the same security issues, for many of the same reasons.

Frequently, these devices operate on air-gapped networks, which have no direct network connections to the outside. The Iranian control systems that Stuxnet attacked operated on just this type of network, and this didn’t save them from infection. You can bypass these controls with an infected USB drive so long as the facility’s staff lacks security education.

Medical Devices

Medical devices containing embedded systems can include anything from the vital signs monitors in hospitals to the pacemakers and insulin pumps directly attached to people. Like industrial control systems, these devices commonly run RTOSs, with either minimal user interfaces or specialized interface devices required to communicate with them.

Though the cardiac device implanted in your chest to keep your heart on track may not seem like a computer with the same set of security needs as the one on your desk, it is, in fact, more closely related than might make you comfortable. In October 2018, the US Food and Drug Administration (FDA) issued a warning for patients and doctors using the Medtronic Cardiac Implantable Electrophysiology Device, a kind of pacemaker.⁶ The FDA found that the programmer for the device didn’t communicate securely with the manufacturer when downloading updates, potentially leaving an opening for attackers to manipulate the settings of the programmer or the device itself, including sending it modified firmware.

Such an attack could be deadly. Unfortunately, just as with other devices, lack of standardization across the industry and, to some extent, the secretive and proprietary nature of these devices leads to less secure products than the battle-hardened desktop operating systems and apps we all use regularly. These devices don’t have anywhere near the number of users that the more popular operating systems have, and they aren’t as easily accessible for casual poking and prodding by attackers and security researchers. You can think of them as the delicate hothouse orchids of the operating system world.

Cars

Cars can have as many as 70 embedded devices communicating over a network to run a vehicle. The network on which these devices communicate is called a controller area network bus. First developed in the early 1980s, the controller area network (CAN) bus has seen several revisions since, as vehicles have grown more complex and computerized.

For example, a car’s airbag system makes use of the CAN bus, as crash sensors all over the car watch for impacts and communicate these events across the network to the airbag control system. The airbag control system might also ask the car’s occupant detection system which seats in the car are occupied and whether the occupant is of a safe size before deploying the airbags.

Car hacking began to heat up in the security industry a few years ago, thanks to the research of Charlie Miller and Chris Valasek, among others. Miller and Valasek succeeded in remotely controlling a hacked Jeep Cherokee. They caused it to accelerate, disabled the brakes, and even took control of the steering wheel, terrifying the reporter from Wired who was behind the wheel at the time, despite the reporter knowing what was going on.⁷

Clearly, the consequences of such attacks can be dire. Cars surround us every time we leave the house, and it takes only a single issue like this to put many people in danger.

For a much more in-depth discussion of the CAN bus and associated devices, their security, and how to hack them, I recommend The Car Hacker’s Handbook by Craig Smith, which goes into a lot of technical depth I don’t have the space to cover here.

Embedded Device Security Issues

Embedded devices face a few specific security issues, which I’ll discuss further in this section.

Upgrading Embedded Devices

The process of upgrading embedded devices can pose an interesting set of challenges. In many cases, you can’t upgrade embedded devices at all, or if you can, it’s often difficult to do so. Since these devices aren’t typically networked, you generally can’t update them automatically.

You can update some devices, such as the pacemakers discussed earlier, with a specialized external device designed to communicate with them, but this can have its challenges also. You probably can’t completely reset an embedded device or take it in for service if you have an issue, like you can with smartphones or desktop computers. In the case of a pacemaker, you likely wouldn’t even want to frequently update the software controlling it, as the impact of a bad update could be heartbreaking (literally).

As for the hardware, engineers typically expect any embedded hardware to last the lifetime of the device it’s part of. (There are a few exceptions to this, such as the devices in industrial control systems, which typically have the support necessary to be replaced.) Short of a safety recall or a warranty repair of the larger device containing it, you’re unlikely to find many options for upgrading. To protect against this vulnerability, you should be sure to keep the hardware that depends on the embedded systems up-to-date, at least to the point that the manufacturer can still repair it, although it may be costly to do so.

Physical Impacts

Not only do embedded devices often lack the necessary protections, but a compromised embedded device can have huge impacts. Earlier, I discussed the cases of the hacked Jeep and the uranium centrifuges in Iran. Those could be the tip of the iceberg. Many devices might impact human safety, even though some industries, such as those related to vehicles, medical devices, and industrial control systems, have begun to harden their embedded systems against deliberate attacks. Because of the prevalence of such systems, there are many potential targets.

Adding to the device-specific and industry-specific issues, governments could use security issues involving embedded devices in nation-state attacks. Stuxnet was the first public example of this. As embedded devices control our power, heat, water, sanitation, food production, and countless other systems, they become likely targets when disagreements between nations escalate.

Recently, both vendors and governments have started to pay more attention to these devices. Many companies, such as SANS (https://ics.sans.org/), now offer security training for industrial control systems that used to be very specialized.

Unfortunately, you can’t do much to protect the physical world from the impacts of embedded devices, short of updates or fixes from the manufacturer. In some cases, you can try to fit a compensating control of some type to a specific situation, such as adding intervening layers of security, such as a firewall, to protect the device.

Internet of Things Security

Internet of Things (IoT) devices are prevalent, and they’re becoming more so—gradually creeping into our toasters, refrigerators, and other appliances so that we can reach them from the internet. With this, of course, comes a host of security issues.

What Is an IoT Device?

In 1999, Kevin Ashton coined the term Internet of Things while working with the Auto-ID Center.⁸ The term referred what he saw as the increasing need to provide network connectivity to track and connect a wide variety of parts and devices. Today, we use the term to refer to any device with an internet connection that doesn’t run a full desktop operating system.

The term is broad, and since the world of IoT is still a bit of a frontier, many of the concepts and ideas related to it are open to interpretation. Let’s talk briefly about a few of the more common IoT devices.

Printers

Although common, network printers often go unnoticed in offices and homes. We often treat them as something along the lines of a toaster, when in reality, they’re complex devices with operating systems like any other computer, capable of communicating on one or more networks, and with plenty of starting places for an attacker to attempt to gain a foothold. Printers generally use an RTOS on a small embedded device, which drives the printer hardware. Hewlett-Packard LaserJet printers run LynxOS operating systems.⁹ These devices listen on a variety of ports and run common services, such as FTP, Telnet, SSH, and HTTP/HTTPS, along with several services peculiar to printing devices. Additionally, they’ll typically have both wired and wireless network adapters. Printers also commonly come equipped with a reasonable amount of memory and storage to support the large print jobs sent to them.

While attacks on these devices are not terribly common, they do occasionally succumb to vulnerabilities. One of the more recent ones, the KRACK vulnerability, can allow attackers to eavesdrop on traffic sent wirelessly to one of these devices and to access sensitive documents.¹⁰

Surveillance Cameras

Networked surveillance cameras, another common type of device, are frequently full of vulnerabilities. Some vendors develop and maintain their camera models well, but others don’t. You can put together a networked camera simply by running a few services on a lightweight platform (often Linux) at a low price. Certain manufacturers create these devices with little testing, developing their product by modifying the source code of other projects.

These devices often have simple default administrative credentials, backdoors enabling unauthorized use of the device, or hordes of security vulnerabilities and misconfigurations. Malware can easily take advantage of them to conduct attacks against other devices or to serve as an entry into deeper parts of the environment.

Physical Security Devices

Physical security devices include tools such as smart locks, which connect to a network (often Bluetooth or Bluetooth Low-Energy) and allow you to open and close a lock through a mobile app or other software.

Smart locks save you the inconvenience of having to carry around a key or remember a combination. In some cases, simply bringing your mobile device within range of the lock will open the lock; you don’t have to take any direct action at all. As you might expect, this doesn’t always help the security of the device.

In July 2018, the company Pen Test Partners undertook research on the Tapplock (https://tapplock.com/) smart padlock, which you open through a mobile app. The company discovered that the unlock code sent to the device was static and replayable, meaning that, even without the associated app, you could just tell the device to unlock directly via Bluetooth and it would do so. They also learned that the unlock code relied on the MAC address broadcast by the device and could be easily calculated by an attacker.¹¹ To add insult to injury, another researcher discovered vulnerabilities in the API behind the Tapplock that allowed attackers to attach any lock to their account, retrieve the physical location where the app last unlocked the lock, and unlock the lock via the app.¹²

If you try to make every device into an IoT device, you’ll likely face vulnerabilities such as these. Although you gain convenience from the smart lock, putting a device like a lock behind an open API literally accessible to anyone with a computer on the internet causes serious vulnerabilities. Even when you put a great deal of effort into strong security, there will always be vulnerabilities present and someone will always be there to exploit them.

THE DIFFERENCE BETWEEN EMBEDDED AND IOT DEVICES

The line between an embedded device and an Internet of Things device is a bit of a fuzzy one, and people often disagree about the definitions of each. There are, however, a few relatively high-level differences.

Embedded devices generally aren’t designed for regular interactions with a person. Both devices are often wrapped up inside another device, which may have a user interface of some kind, but the embedded one usually hides behind the scenes, and it tends to have simpler interfaces that allow you to turn it on or off or make adjustments to its settings.

Also, embedded devices aren’t typically connected to the internet, although some embedded devices, such as the embedded devices found in cars, are connected to internal networks. Some people might argue that providing an embedded device with an internet connection would move it into the IoT device category.

IoT Security Issues

IoT devices, of course, face several specific security issues stemming from their network connections.

Lack of Transparency

Often, you won’t know exactly what your IoT devices are doing. Although they have limited user interfaces, they typically contain similar sets of features as your mobile device and desktop computer. When your IoT device is idling on the network, it could be communicating with anyone. You won’t always be able to tell if it’s doing something unusual or unexpected.

Unless you put specific instrumentation in place to discover what these devices are doing, you don’t really have any way of answering those questions. An advanced user might be able to log into a command line interface on the device and interrogate it slightly further, but you might not be able to glean much additional information aside from tidbits of data from the file system and logs.

One way of discovering what exactly an IoT device is doing is to connect the device to a virtual private network to isolate the device (making its traffic easier to distinguish) and force it to communicate through a monitorable choke point and then use a tool such as mitmproxy (https://mitmproxy.org/) to eavesdrop on it and see who exactly the device is trying to talk to and what data is being sent or received. You can find this tool and accompanying scripts in the Data-Life project on GitHub (https://github.com/abcnews/data-life/). If the device is sufficiently chatty on the network, you’ll have to sift through many results to identify the devices on the other end of the connection. You can expect to see most IoT devices communicating with a variety of other devices under normal operation. They might, for example, ask for updates from the vendor, talk to APIs, and check the time against time servers.

Everything Is an IoT Device

All sorts of appliances now ship with “smart” capabilities and network connectivity of some variety. Even lightbulbs and exercise machines talk to the internet. As I’ve discussed, devices have their own specific security failings, but they also face issues that arise from just having such a large mass of devices on the internet.

In October 2016, an enormous distributed denial-of-service (DDoS) attack left massive swaths of the internet unusable, including services from large providers such as Amazon Web Services, Twitter, Netflix, and CNN. These outages stemmed from DDoS attacks against Dyn, the company controlling many of the root DNS servers forming the infrastructure of the internet. The attack against these servers had a rate of 1.2 terabytes per second, at the time the largest DDoS attack ever witnessed, and came from more than 100,000 devices, almost all of which were IoT devices.¹³

The attack was possible because malware called Mirai recruited vulnerable IoT devices into a botnet (a network of compromised systems) and made them accessible for the controllers of the botnet to use for DDoS attacks. The malware didn’t perform a complex attack; it simply looked for devices on the network and attempted to access them using their default administrative password.

Of course, users could have prevented this problem by changing the administrative password when they first configured the device, but unfortunately, users rarely do so. When wireless access points first became common, they faced similar issues. Manufacturers will likely resolve this vulnerability the same way they resolved the vulnerabilities in the wireless access points: by shipping devices in a secure state by default.

Outdated Devices

In addition to the large number of vulnerable devices on the market, the many old devices on the market cause security problems. IoT devices of some variety have existed for about 20 years now. Even if no insecure devices left any factory starting today, these old devices could remain in operation for at least the next decade.

It’s not easy to add security measures to older devices. You could update the firmware to patch holes in certain devices, but this would require performing updates, which most devices don’t automatically download. The many nontechnical people with IoT devices in their homes are unlikely to understand both why these devices need to be updated and how to do so.

Summary

In this chapter, I discussed mobile devices, embedded devices, and IoT devices. Each of these categories faces a particular set of potential security issues, which you can mitigate to varying extents.

When it comes to mobile devices, the baseboard operating system, jailbreaking, and malicious apps can threaten your security. However, you can take certain steps to manage mobile devices and, to a certain extent, control how people use them, particularly in corporate environments. Embedded devices, which are present in many critical systems, have the potential to cause physical impacts well beyond the device itself, while IoT devices, or devices with a network connection, are particularly difficult to monitor and secure.

From a security perspective, these devices are just as important as traditional computers, even if they’re rarely considered.

Exercises

What is the difference between an embedded device and a mobile device?

What does the baseband operating system in a mobile device do?

How can embedded devices impact the physical world?

What did the Mirai botnet do?

What is the difference between a supervisory control and data acquisition system and an industrial control system?

What are the dangers of jailbreaking a mobile device?

What problems might you see when updating embedded devices?

What is the difference between an embedded device and an IoT device?

What common types of network connectivity might you see in an IoT device?

What solutions might you use to prevent a mobile device from being jailbroken?

13APPLICATION SECURITY

In Chapters 10 and 11, I discussed the importance of keeping your networks and operating systems secure. Part of keeping attackers from interacting with your networks and subverting your operating system security is ensuring the security of your applications.

In December 2013, the Target Corporation, a retailer operating more than 1,800 stores throughout the United States, reported a breach of customer data that included 40 million customer names, card numbers, card expiration dates, and card security codes.¹ A month later, Target announced that an additional 70 million customers had had their personal data breached.²

14
ASSESSING SECURITY

Once you’ve put your security measures in place, you need to make sure they’re actually protecting your assets. As discussed in Chapter 6, complying with laws and regulations doesn’t actually mean you’re secure. Since that’s the case, how can you assess the true level of your security? You have two primary vehicles for doing so: vulnerability assessment and penetration testing. In this chapter, I’ll discuss these two methods.

Vulnerability Assessment

A vulnerability assessment is a process that uses a specially designed tool to scan for vulnerabilities. Two common vulnerability assessment tools are Qualys and Nessus. To create these tools, vendors must do a great deal of legwork to catalog vulnerabilities, determine which platforms and applications the vulnerabilities apply to, and classify them by severity. The vendors will also often provide additional information along with them about the potential impact of the vulnerabilities, how to fix them, and so on.

Because of the work that goes into keeping them up-to-date, some of these tools can be rather expensive. Since vulnerabilities are in a constant state of flux, vendors need to constantly keep up with changes to the vulnerabilities, patches being issued for them, new variants that appear, and a dizzying array of other factors in flux. Without these constant updates, these tools will quickly fall out of usefulness and be unable to detect new vulnerabilities or provide accurate information.

Ultimately, the results of a vulnerability assessment will give you only one bit of information about whether you’re secure—namely, it will tell you whether there are specific known vulnerabilities existing on each of your hosts.

Conducting a vulnerability assessment takes several steps, outlined in this section.

Mapping and Discovery

To be able to scan for vulnerabilities, you need to know what devices you have in your environments. Typically, you conduct scans against groups or ranges of hosts, which change over time. If you don’t have some method of keeping your lists of hosts up-to-date, you’ll get incomplete scan results, or you may scan the wrong hosts entirely. This can be a particular issue with hosts in the cloud, which I’ll come back to later in this chapter.

Mapping Environments

Start your vulnerability scanning efforts by creating a map of your environment that shows you what devices are present in your network. Most vulnerability scanning tools let you directly create such a map; otherwise, you can import host information from tools built specifically for this purpose, such as Nmap (https://nmap.org/).

Often, tools create these maps by interrogating every single IP address in the network range you’re building a map for. For large network ranges, this can take a long time—perhaps more time than it will take for a host to appear and disappear again. For example, a class A internal network, commonly recognizable by having IP addresses in the 10.0.0.0 to 10.255.255.255 range, can hold more than 16 million IP addresses. Another common internal network scheme, a class B network, which commonly uses IPs that look like 192.168.0.0, can hold more than 65,000 hosts. It’s not uncommon for an environment to use a class A and several class B networks for segmentation purposes. Since most tools take a second or two per IP to interrogate each address while discovering hosts, you’ll be at it for a quite a while.

Performing these discovery scans can also be stressful to your network infrastructure if you’re not careful to do so slowly. While mapping a network, it’s entirely possible to overload network devices, such as routers and switches, to the point they become nonresponsive.

Discovering New Hosts

In addition to mapping to figure out what’s there in the first place, you also need to keep your lists of hosts up-to-date. If you know the locations of any new devices on your networks, you can look in those specific places, but you may miss some hosts if they’re not where you expect them to be—particularly if they’ve been placed somewhere odd in order to hide them.

You can actively or passively discover new hosts. Active discovery involves a process similar to the one used to map the network in the first place: you go IP by IP and interrogate each to see whether anything responds. This has many of the same limitations mapping does, but you could restrict these updates to portions of the network you know to contain devices, in the interest of being able to get through a network range more quickly and at shorter intervals.

You can also use passive scanning techniques to discover devices on the network. This often involves placing a device at network choke points, such as routers or switches, to eavesdrop on the traffic flowing through your infrastructure. In this way, you’ll automatically discover devices as they talk on the network and can automatically add them to your lists of hosts to scan.

Scanning

Once you know what hosts you have, you can scan them for vulnerabilities. There are a few different types of scans you can conduct, as well as different methods you can use for each.

Unauthenticated Scans

A basic vulnerability scan of a host is typically an external and unauthenticated scan. These types of scans don’t require any credentials for the host you’re scanning or any access other than network connectivity to the host in question. This allows you to conduct the scan against almost any device. Depending on the settings of the scan, it will often show you what ports are open on the host in question, reveal the banner information for the services listening on those ports, and guess at the applications and operating systems in use, based on the other information gathered.

Authenticated Scans

You can also perform authenticated scans against hosts. An authenticated scan is one that is conducted using a valid set of credentials, generally administrative, for the system being scanned. Having credentials to log into a host will often let you collect internal information, such as what software is installed, the contents of configuration files, the permissions on files and directories, the vulnerability patches that the system needs but doesn’t currently have, and other information. This gives you a considerably more thorough view of the device and its potential vulnerabilities than you can see from the outside, generating a considerably more accurate picture of the security of the device.

However, authenticated scans require you to keep your authentication credentials current, both on the vulnerability scanning tool end and on the hosts themselves. Some of the checks will also require administrative access to the device, and some system owners may be reluctant to give you credentials with this broad level of access.

Agented Scans

Agented scans can provide a means to get around some of the downsides of authenticated scans. An agent is a small piece of software installed on each host. The software runs as though it were a user on the system, so it’s authenticated, but it doesn’t require you to maintain a separate set of credentials on the device or in the vulnerability scanning tool.

Another benefit of using agents is that hosts configured with them typically report to the management devices on their own, thus removing some of the need to search for the devices individually on your networks. While it doesn’t remove the need entirely, because some devices, such as network appliances, may not be able to run an agent, it should ease your burden quite a bit, as most or all the devices you expect to be present should identify themselves automatically.

Application Scanning

Some tools allow you to scan specific applications. For example, many well-developed scanners exist solely for scanning web applications. These types of scans are specific to web technologies and vulnerabilities and can search considerably more deeply in the application for issues than a scanner intended strictly for hosts would be able to find. You will often find web application scanners to be one of the more deeply developed application vulnerability scanners, and indeed there are many scanners that exist for this purpose alone. One common such scanner is Burp Suite (https://portswigger.net/burp/), mentioned in Chapter 13, which is a highly capable tool for both automated and manual testing of web applications.

Technological Challenges for Vulnerability Assessment

You’ll likely run across a great number of technological challenges that will make it harder for you to instantiate and maintain vulnerability scanners. A few of the most common and frequent stumbling blocks are related to cloud and virtualization technologies.

The Cloud

Resources in the cloud put a bit of a twist in the tasks, processes, and technologies discussed here. As mentioned in Chapter 6, cloud providers may have some specific rules in place for what you can and can’t do in their environments, and this can change from one cloud provider to the next.

When it comes to vulnerability scanning, some vendors may not want you to scan devices in their environments at all, particularly if they’re using certain cloud deployment models. In most infrastructure as a service (IaaS) models, you’ll likely be able to scan within certain boundaries and according to certain rules. In platform as a service (PaaS) environments, vendors may restrict you to scanning with agents, as the infrastructure itself probably won’t be visible to you. In software as a service (SaaS) environments, the provider probably won’t want you to scan at all.

Another consideration for cloud scanning is the fluctuating nature of the environment. Even in the case of an IaaS platform, the devices and IPs may change frequently behind the scenes, and you may accidentally find yourself scanning devices or networks no longer belonging to you. The traffic generated by external vulnerability scanning from an unknown entity is virtually indistinguishable from attack traffic, so you shouldn’t accidentally point these tools at another company’s resources without appropriate permission.

Containers

Another common and potentially problematic feature of cloud and virtualized environments is the container. A container is an entirely self-contained and ready-to-run virtualized instance, specifically designed to allow easy scaling up and down of portions of the environment seeing variable levels of load. For instance, your web server farm may see little load in the middle of the night and scale down to a few containers, as that’s all they need to keep things running at that hour. In the middle of the day, the server farm may scale up to hundreds of instances and then scale up and down over the course of the day according to load.

As containers may exist one second and be gone the next, they don’t work well with vulnerabilities scans on a schedule of any kind. Containers often require specialized vulnerability scanning tools to assess them for vulnerabilities.

Penetration Testing

Some people assume that vulnerability scanning is the same thing as penetration testing. While a penetration tester might use the results from a vulnerability scan, these are two different sets of activities, each with their own processes.

Penetration testing, also referred to as pentesting or ethical hacking, is the process of testing a system for vulnerabilities that an attacker could exploit. Penetration testing is a much more in-depth process than vulnerability scanning, and it’s often done manually. While a vulnerability assessment may get you part of the way to assessing your security, it won’t get you all the way there.

The goal of penetration testing is to find the holes in your security so you can fix them before attackers discover them. Penetration testers use the same tools and techniques as genuinely hostile hackers (called black hat hackers) do. But unlike black hat hackers, penetration testers have permission to conduct these activities, which means that a penetration test conducted against your own systems would, in every sense, be considered an act of cybercrime if directed against the assets of another company without their authorization.

You’ll often see a penetration testing team referred to as a red team, a term of military origin. The red team plays the part of the attacker when evaluating the security of your systems as realistically as they can while keeping the test safe and reasonable.

The Penetration Testing Process

Penetration testing follows a relatively standard process: scoping, reconnaissance, discovery, exploitation, and reporting, as shown in Figure 14-1.

Figure 14-1: The penetration testing process

Although some descriptions of the penetration testing process might use slightly different terminology or contain more or fewer steps, the general concepts will almost always be the same.

Scoping

Before you can conduct a penetration test against anything, you need to know what it is you’re testing against. The scope of your penetration test may be very open, such as “all assets of MyCompany,” or it may list only individual IP addresses you can test against.

Also, the organization might restrict your testing to test or quality assurance (QA) environments only to prevent impacts on production systems. While penetration testers generally won’t use intentionally damaging attacks, their tools and techniques could always have unforeseen side effects.

An organization might also provide rules of engagement as part of their scoping discussion. These rules may specify times of day in which testing must take place, procedures testers should follow if they uncover a severe vulnerability, and so on. These rules will vary greatly depending on the environment being tested and the specific organization.

Reconnaissance

Reconnaissance, or recon, is the research you conduct before attempting any attacks against a target. This can involve searching the internet for information about the target environment or company, looking through job listings for mentions of specific technologies, researching some technology you know the company to be using, and so on. Recon is often, but not always, a passive activity and falls just short of directing tools against the target environment.

Discovery

The discovery phase of the penetration test begins the active testing stage. Here, you’d likely run your vulnerability assessment tools, if you didn’t already do so, and go over the results. In this step, you’d look for open ports and services on hosts to detect any running services that could be vulnerable to attack. Based on what you find here, you might conduct additional research and recon based on specific information you collected.

Exploitation

This phase involves attempting to exploit the vulnerabilities you detected in the earlier stages. This may include attacking vulnerabilities in the environment or even chaining multiple vulnerabilities together to penetrate deeper into the environment. Again, what you find here may prompt additional research and recon as you gain new information about the target or new targets become available.

Reporting

The last phase of penetration testing is reporting. Here, you carefully document what you discovered and what exact steps you need to reproduce the attacks you successfully carried out.

This step illustrates one of the key differences between vulnerability assessment and penetration testing. While vulnerability assessment may produce a potential list of vulnerabilities in the environment, the tools can’t guarantee that an attacker will actually be able to exploit them. In penetration testing, the tester will report only the issues that resulted in an actionable attack against the system or have a high chance of being exploited.

Classifying Penetration Tests

You can classify penetration tests in several different ways. When testing, you can approach the test with differing levels of knowledge about the environment, from different starting places, or with different teams conducting specific portions of the test.

Black Box, White Box, and Gray Box

You’ll often see penetration tests referred to as some color or level of opacity. This refers to the level of information the tester is provided with regarding the environment being tested.

In black-box testing, the tester has no knowledge of the environment other than the testing scope. This closely simulates a real-world attack, as presumably an outside attacker would start from this same place.

White-box testing gives the tester all the information about the environment available. This likely includes a list of all hosts, what software is in use, source code for applications and websites, and so on. While this isn’t a realistic attack because an attacker likely wouldn’t have access to all this information, it allows the tester to be considerably more thorough and potentially turn up issues that would have otherwise gone undiscovered.

Gray-box testing is a hybrid of the two testing types already mentioned. Here, the attacker is given some inside information about the environment, but not as much as they’d get if they were conducting a white-box test. This is one of the more common types of penetration test.

Internal vs. External

Penetration tests might also be called internal or external, which can have two different interpretations. Internal and external might refer to the kinds of access the tester is granted to the environment being tested. For example, if you give the testers access to the environment from the internet-facing portions of it only, you might call this an external pentest. Conversely, if the testers are on the same network as the environment, either physically or via a virtual private network (VPN) connection, you might call this an internal test. In this case, internal testing would probably provide a greater level of access to the environment because the testers would begin their tests inside some layers of security.

Internal and external might also indicate what kind of person or team is conducting the penetration test. External testing might refer to a third-party testing company hired to perform the pentest, while internal testing would likely refer to a penetration testing team working for your organization.

Targets of Penetration Tests

Penetration tests sometimes target specific technologies or environments, such as web applications, networks, or hardware. I’ll discuss these in depth in this section.

Network Penetration Testing

Although the term network penetration testing might sound like it would apply to tests of specific network devices, such as routers or switches, it’s often used as an overarching penetration testing term for the broad testing of hosts for vulnerabilities, issues specific to web applications, and even employees who might be vulnerable to social engineering attacks.

Network penetration tests tend to have broad scopes but often take place in limited time frames (also called being time boxed) and therefore tend to be a bit shallower than a specifically focused test because the testers might not have the time to dig into everything in the testing scope. This is one of the more common types of testing.

Application Penetration Testing

Application penetration testing, the other common type of testing, focuses directly on an application or application environment. Application testing generally involves a more specialized set of tools and skills on the part of the tester than those necessary for network penetration testing and is more focused. It can involve two differing approaches: static analysis and dynamic analysis.

Static analysis involves directly analyzing the application source code and resources. For instance, the tester might pore through the code, looking for issues such as logic errors or vulnerabilities that exist due to the specific lines of code and libraries in use. To perform static analysis, the tester must have a strong development background and grasp of the languages used.

Dynamic analysis involves testing the application while it’s in operation—in other words, testing the compiled binary form or the running web application. While this doesn’t give the tester the same insight into the code that static analysis does, it more closely resembles real attacks against the application.

Web application testing is common because of how often organizations use web applications and how often attackers are likely to target them. Mobile and desktop applications are also frequent targets for specific application testing, more often through static analysis techniques. These applications can make particularly easy targets for attackers, because large portions of applications and their resources sit on devices that the tester can control.

Physical Penetration Testing

Physical penetration testing involves directly testing physical security measures by, for example, picking locks or bypassing alarm systems. Like application testing, this kind of testing also requires a particular set of tools and skills to test well. It’s also one of the less common kinds of test, because many organizations are more concerned with hackers penetrating their systems than they are with someone picking the lock on their office doors.

Testers often conduct physical penetration testing in conjunction with other penetration testing or to aid other testing. For example, if an attacker can get into a facility and enter a locked network closet, they may be able to plug a device into the network and leave it behind, which then allows them to perform attacks from the network itself without needing to be present.

As with any other type of penetration testing, you’ll generally carry out physical penetration testing within a particular scope and with a specific goal in mind, whether you aim to get access to a data center or office or to plug your hostile device into the network.

Social Engineering Testing

Social engineering penetration testing uses the same techniques discussed in Chapter 8 and also often takes place in conjunction with other tests. Social engineering tests are so effective that the testers almost always succeed, and so many organizations refuse to allow them. To keep them from succeeding, the workplace generally needs careful preparation and good education (or they need to be paranoid).

Social engineering tests frequently involve phishing attacks, which are easy to set up and deliver to large numbers of employees. Impersonating employees and attempting to gain unauthorized access to facilities or resources are also common strategies. External audit teams often simply walk in the door of a secured area right behind someone without using a badge (remember that this is called tailgating). Once they’ve done this, they can bring a rogue piece of equipment into a building and leave it behind, as mentioned in the previous section. Many people won’t ask questions about the “IT guy” who is plugging in and setting up a computer at an empty desk.

Hardware Testing

Hardware testing is a slightly more unusual kind of penetration test. It typically occurs in organizations that manufacture hardware devices, such as network gear, TVs, or IoT devices, which often make for fertile ground for penetration testers since many of their interfaces are inaccessible to common users and not terribly secure. In addition to testing the device, penetration testers often test the firmware on the device, associated mobile applications, and application program interfaces (APIs) the devices use to communicate with their associated servers.

You’ll likely discover specific information about the hardware in the reconnaissance and discovery phases. This step might involve taking the device apart and looking at the markings on the components and chips inside. It’s also often possible to find manufacturer specifications, which will sometimes let you access the hardware in ways the device manufacturer didn’t intend.

Hardware devices are typically equipped with Universal Asynchronous Receiver/Transmitter (UART) or Joint Test Action Group (JTAG) debug ports, which are accessible on the circuit boards after you open the device. These will often provide terminal access to the device, in many cases without any sort of authentication, and you can use them to manipulate the device.

The discovery phase for hardware devices can be slightly more involved as well. Testers may investigate the firmware of the device itself, perhaps after dumping a copy of it from flash storage chips internal to the device, or they may test a module or application controlling the device or even an associated web application. The software portions of these devices can be quite complex to investigate, as they consist of the entire operating systems and all the applications running the device. Some devices, such as smartphones, may even have multiple layers of operating systems and software.

Bug Bounty Programs

In the last few years, many organizations have taken to using bug bounty programs as a kind of penetration testing. These follow essentially the same rules and process as a regular penetration test, with a slight twist.

In a bug bounty program, an organization offers rewards to people who discover vulnerabilities in their resources. The “bounties” typically vary based on the severity of the issues uncovered. They can range from an expression of thanks or a T-shirt to hundreds of thousands of dollars. As an example, in January 2018, Google paid a Chinese security researcher US $112,000 for a bug found in its Pixel smartphones.¹

The organizations with bounty programs allow anyone to test within the scope they’ve set, and they pay the tester who finds a specific issue first according to the specified bounty. Allowing anyone in the world to hack your systems at any time might sound like a terrible idea, but these programs have enjoyed a high level of success. The risk is partly mitigated by the fact that the organizations are typically careful to spell out specific scopes for their programs, and they’ll pay bounties only for issues reported within the scope specified. As a result, there typically isn’t much of an incentive to conduct attacks outside of this—say, just for “joyriding.”

Plenty of platforms manage bug bounty programs on behalf of other companies. Some of the better-known bug bounty platforms are HackerOne (https://www.hackerone.com/), Bugcrowd (https://www.bugcrowd.com/), and Synack (https://www.synack.com/). These platforms also make it easy for those wanting to participate in the programs to see what bounties are out there and what the scope and rewards are for each company.

Technological Challenges for Penetration Testing

Like for vulnerability analysis, technical challenges exist for penetration tests, which face many of the same issues.

The Cloud

The cloud also presents issues for penetration testing. One of the larger issues is that cloud providers generally don’t like testers attacking their cloud infrastructure at will. Cloud providers run a tight ship from a resource perspective and don’t tend to like surprise activities that use large amounts of their resources. Cloud providers will often require you to formally request permission to penetration test and conduct the test within a specific schedule, from known IP addresses, if they allow testing at all. Testers willy-nilly conducting attacks against cloud services will likely find their traffic blocked or, worse, the authorities involved.

Finding Skilled Testers

It’s also often difficult to find skilled penetration testers. The difference between a highly skilled and experienced tester and a novice is huge in terms of the results you can expect. An unskilled tester may not get much further than reviewing the results the vulnerability scanning tool spit out, which will likely contain unverified false positives and miss major issues.

Getting a report from a penetration testing team with few results is often less a ringing endorsement for your amazingly tight security than a reflection of the skill level of the team doing the testing. Penetration testing skills take time and experience to develop, but penetration tests are in high demand. As a consequence, you may encounter tests conducted by testers who have no business doing so unsupervised.

Does This Really Mean You’re Secure?

After you’ve assessed your vulnerabilities, conducted your penetration tests, and fixed all of your resulting issues and findings, are you really secure? Will the evil black hat hackers scrabble at the slick icy walls of your impenetrable security and then slink off, tails betwixt their legs? Well, probably not. There are a few caveats to everything I’ve discussed, and there’s no such thing as being perfectly secure.

Realistic Testing

To get accurate results about your security, you need to perform realistic testing. That means you should conduct vulnerability assessments and penetration tests without impeding them or skewing the results. This is a taller order than it sounds like.

Rules of Engagement

When you set your rules of engagement for testing, they need to closely adhere to the conditions under which an outside attack would take place. The whole point of this exercise is to emulate what attackers do so you can do it first and fix what you find. If you set rules of engagement to artificially increase the level of your security, you’re not doing yourself any favors. For instance, if you set a rule of engagement specifying no chaining of attacks (performing multiple attacks one after the other to penetrate more deeply), you’ve stopped short of exactly what an attacker would do to gain entry to the deeper portions of the environment.

Scope

For similar reasons, it’s important to set a realistic scope. Yes, you must make sure that your tests don’t impact production environments or degrade levels of service for customers, but organizations often use factors such as these as excuses to set an artificially narrow scope. If you’re testing in a retail environment, for instance, and set the systems holding payment card data out of scope, you’ve just scoped out the exact thing attackers are trying to access.

In cases when you’re making scoping decisions to protect production assets, you may be better off setting up a specific environment mirroring your production environment to test with impunity.

Testing Environment

If you’re using a test environment for scanning or testing purposes, you should make sure it matches the production environment as close as possible. It is all too common for organizations to set up idealized, thoroughly patched, and well-secured environments for a penetration test, without taking any of the same measures in the actual production environment. Setting up a Potemkin village of an environment like this works counter to what you’re trying to accomplish by performing these kinds of assessments and tests in the first place.

In these situations, it’s often helpful to operate in a cloud environment. In many cases, you can exactly replicate an entire environment consisting of cloud-based hosts and infrastructure in its own segmented area, allowing you to test an environment that’s identical to the production environment and then tear it down once you no longer need it.

Can You Detect Your Own Attacks?

Another way you can evaluate your level of security is to carefully watch your everyday security tools and alerting systems while running vulnerability tools and penetration tests. If you’re correctly assessing your security, these activities should be almost indistinguishable from actual attacks. If you don’t notice your testing taking place, you probably won’t see the actual attacks coming in either. In many cases, penetration testers won’t be as stealthy as attackers, so they should be even easier to catch.

The Blue Team and the Purple Team

Earlier in the chapter, we referred to penetration testers as the red team. The opposite of the red team is the blue team, tasked with defending the organization and catching the red team. The blue team should participate in the other side of the penetration test just as much as the red team is attacking. While you may not want to actively block attacks coming from the red team (interfering with testing is a bit of a religious discussion, as it can potentially taint the test results), you should definitely record and document the evidence of their activities. You should have evidence of every attack the red team gets through, or at least understand how it avoided your attention, so you can fix your security. The results of a penetration test make an excellent basis for requesting an additional budget for resources or tooling to cover these gaps.

You may also hear people talk about purple teams, which form the bridge between red teams and blue teams and help to ensure that both operate as efficiently as possible. In environments with small security teams, purple teams may also play the part of both the red team and the blue team at the same time.

Instrumentation

To catch penetration testers in the act, you must have appropriate instrumentation in place. If you don’t have intrusion detection systems and firewalls you can use to watch for unusual traffic, anti-malware and file integrity monitoring (FIM) tools on systems, and so on, you’ll have no source of data to watch for these kinds of attacks. The exact mix of tools that are reasonable to have in place will vary with your environment and security budget, but you can do a lot with a little if you need to do so.

At the least, you should run some of the many open source tools that function on minimal hardware and are possible to put in place with an extremely low expenditure. For example, the Security Onion distribution can get data from host intrusion detection, network intrusion detection, full-time packet capture, logs, session data, and transaction data—all on a shoestring budget.²

FIM TOOLS

FIM tools are used to monitor the integrity of the application and operating system files on a particular machine. Typically, you’d use FIMs to monitor only sensitive files, such as those that define configurations for the operating system or applications or hold particularly sensitive data. Once the file changes, an alert might notify someone of the changes, or in some cases, the file may automatically be reverted to its original state. FIM tools need to be carefully tuned, as they can produce a great deal of alerting “noise” if improperly configured.

Alerting

Also, of critical importance is proper alerting from your tools. You need to have good alerting so that you know when you’ve caught the testers. You don’t want your tools muttering to themselves in the corner, completely ignored by the blue team. With proper alerting, you can respond to an attack or penetration test in close to real time.

You also need to be careful about the alerts you send. If you send too many alerts, particularly if they’re false alarms, your blue team will start to ignore the alerts entirely. The common phrase for this, borrowed from the healthcare industry, is alert fatigue.³ The answer to this is to carefully send actionable alerts (those that prompt a specific response) and to send as few alerts as possible.

Secure Today Doesn’t Mean Secure Tomorrow

It’s important to understand vulnerability assessments and penetration tests are a snapshot from a single point in time. Secure once doesn’t mean secure always. You must iterate these processes regularly to maintain the usefulness of the information they produce.

Your Changing Attack Surface

An attack surface is the sum of all the points that an attacker can use to interact with your environment. It is your web servers, mail servers, hosted cloud systems, salespeople with laptops in hotel rooms, internal source code posted to public GitHub repositories, and hundreds of other similar issues. As your attack surface is composed of so many moving parts, it’s in a constant state of flux. Your vulnerability assessment from a month ago or your penetration test from last year is probably no longer completely accurate—hence the need to update these at some regular interval.

Attackers Change, Too

Attackers are constantly evolving their attacks and tools, also. There are far more attackers than there are defenders, and many of the attackers have a direct monetary incentive to update their tools and techniques. Furthermore, attack tools are often sold to other hackers at a handsome profit. An entire cybercrime industry rides on keeping their tools current, at least as much as, if not more, than the security tool industry depends on defenders.

Putting in a security layer and expecting it to be just as solid and effective as the day it was installed years later is a bad bet. To cope with attackers changing, you need to change also. This cat-and-mouse game has driven the security industry for years and will continue to do so.

Technology Updates Under You

To make matters worse, your technology can change under you (and you may not even be aware of it). Many of the operating systems, mobile applications, cloud services, security tools, and code libraries you make use of regularly receive updates by those who create and maintain them. The operating system in your smart TV may have updated in the middle of last night, exposing you to attacks from the internet. It may be updated again tomorrow to fix the issue, and you probably won’t know it then either.

You may find some of the security issues generated by updates during testing, or you may never know they existed at all. The best you can do in order to fend off this type of issue is to put multiple layers of security controls in place.

Fixing Security Holes Is Expensive

Finally, fixing holes in your security is expensive. It’s expensive in terms of resources, the cost of purchasing and updating your security controls, and the development efforts needed to fix insecure code in your applications and websites. More often than you’d like to think, an organization will fail to prioritize security over business priorities. You might go to a great deal of effort to catalog vulnerabilities and write up penetration testing findings only to be told the critical issue you found won’t be taken care of until some other work gets done. This happens often in the security world, and you’ll likely find a way to put another control in place or fill the gap with a security tool. Things won’t always be perfect, but you must still do what you can to make your organization secure.

Summary

In this chapter, I discussed vulnerability assessments and the tools you can use to suss out security issues in your hosts and applications. I also talked about how vulnerability assessments differ from penetration tests and why you should conduct both.

I covered penetration testing, the process of conducting one, and several of the specialized subareas of penetration testing, such as web application and hardware testing. I also talked about the challenges inherent in conducting penetration testing against cloud and virtualized environments.

Finally, I talked about whether you’re really secure after going through all of the effort of vulnerability assessment and penetration testing and what it means to catch yourself testing (or not). Vulnerability assessment and penetration testing are representations of a point in time, meaning you must keep iterating over these to keep your data current.

Exercises

What methods can you use to detect new hosts in your environments?

What benefits does an agent provide when vulnerability scanning?

What challenges are there in vulnerability scanning for containers?

How is penetration testing different from vulnerability assessment?

How is a red team different from a blue team?

Why is scoping important for a penetration test?

What are the differences between static and dynamic analysis?

How is a bug bounty program different than a penetration test?

What impact does the environment on which you test have on your test results?

What is alert fatigue?

NOTES

A large portion of the articles and references in this list are freely available online through the links noted.

Chapter 1

1. Federal Information Security Modernization Act of 2002, 44 U.S.C. §3542.

2. Spafford, Eugene. “Quotable Spaf.” Updated June 7, 2018. https://spaf.cerias.purdue.edu/quotes.html.

3. Parker, Donn B. Fighting Computer Crime. Hoboken, NJ: Wiley, 1998.

4. Munroe, Randall. “Password Strength.” xkcd: A Webcomic of Romance, Sarcasm, Math, and Language, accessed July 2, 2019. https://xkcd.com/936/.

Chapter 2

1. Cisco, Talos Intelligence Group. “Email & Spam Data.” Accessed July 2, 2019. https://www.talosintelligence.com/reputation_center/email_rep.

2. Pascual, Al, Kyle Marchini, and Sarah Miller. “2018 Identity Fraud: Fraud ...

INDEX

Numbers

3DES, 70

A

access controls

access control lists (ACLs), 38–43

implementation of, 37–43

models, 43–48

overview, 35–37

physical access controls, 48–50, 124–125

accountability, 52–55

active discovery, 193

address space layout randomization (ASLR), 151–152

Adleman, Leonard, 71

administrative controls, 14, 81, 127

Advanced Encryption Standard (AES), 70, 178

agented scans, 194

air-gapped networks, 165

alerting, 204

AMD, 152

anomaly detection, 138, 151

anti-malware tools, 151

Apple, 163

applications. See also software

mobile devices, 163

overview, 173–174

penetration testing (pentesting) of, 198–199

scanning, 194

tools for, 184–188

arbitrary code execution, 183

The Art of War (Sun Tzu), 102

Ashton, Kevin, 167

assessments, 57–58

asset identification, 11

associated risk, 10. See also risks

asymmetric key cryptography, 70–71. See also cryptography

attacks

attack surfaces, 146

denial-of-service (DoS) attacks, 5

types of, 8–10

attribute-based access control (ABAC), 45

auditing, 52, 55–58, 150

authenticated scans, 193–194

authentication

attacks, 177, 183

methods of, 25–33

overview, 7, 23–24, 25–28

authority to operate (ATO), 84

authorization. See also access controls

attacks, 177

vs. authentication, 25

overview, 35

automobiles, 165–166

availability

and confidentiality, integrity, and availability (CIA) triad, 5

interruption attacks, 9

Parkerian hexad and, 7

B

baseband operating systems, 162

Bell–LaPadula model, 46

Biba model, 47

biometrics, 26, 29–32

Bitcoin, 92

black-box testing, 197

black hat hackers, 195

blackholing, 40

blockchain, 91–92

block ciphers, 69–70

block mode, 69

blue teams, 203

botnets, 170

bounds checking, 175

breaches, 100

Brewer and Nash Model, 47–48

bring-your-own-device (BYOD) policies, 161

browsers, 179

brute forcing, 68

buffer overflows, 151–152, 175

bug bounty programs, 200–201

Bugcrowd, 201

bugs, 130

Burp Suite, 187–188, 194

business competition, 103

business continuity planning (BCP), 122

Business Software Alliance (BSA), 56

C

Caesar cipher, 62

cameras, 168

Cameroon, 134

capabilities, 42–43

CAPTCHAs, 45

The Car Hacker’s Handbook (Smith), 166

cars, 165–166

central management, 159–161

certificate authority, 73

certificates, 73–74

chain of custody, 55

Children’s Internet Protection Act (CIPA) (2000), 86

Children’s Online Privacy Protection Act (COPPA) (1988), 86

Chinese Wall model, 47–48

choke points, 134, 169, 193

Cisco, 25

class A and class B internal networks, 192

clean desk policies, 119

cleartext, 61

clickjacking, 42, 178–179

client-side attacks, 41, 178–179

cloud computing, 89–91, 194–195, 201

code, 183

collision, 72

compensating controls, 82

competitive intelligence and competitive counterintelligence, 103

Competitive Strategy: Techniques for Analyzing Industries and Competitors (Porter), 103

compliance. See also laws and regulations

controls for achieving, 81–82

frameworks for, 87–89

maintaining, 82–83

overview, 79–81

technological changes and, 89–92

confidentiality, 5, 7

confidentiality, integrity, and availability (CIA) triad, 4–6, 8

configuration files, 180

confused deputy problem, 41

containers, 195

controller area network (CAN) bus, 165–166

controls, 14

corporate-owned business only (COBO) and corporate-owned personally enabled (COPE) mobile devices, 161

Cotton, Gerald, 92

countermeasures, 98

critical information assets, 96

cross-site request forgery (CSRF), 41–42, 178–179

cross-site scripting (XSS), 178

cryptocurrencies, 92, 163

cryptography

algorithms, 61–66

asymmetric key cryptography, 70–71

attacks, 178

elliptic curve cryptography (ECC), 71

history of, 62–66

keyless cryptography, 71–72

overview, 61

symmetric key cryptography, 68–69

tools for, 67–74

uses of, 74–77

cyber intelligence/digital network intelligence (CYBINT/DNINT), 114

D

data

protection of, 127–129

at rest and in motion, 9, 74–77

storage of, 7, 128–129

databases, 181–184

Data-Life project, 169

deep packet inspection firewalls, 136

default accounts, 148–149

defense in depth strategy, 17–20

demilitarized zones (DMZs), 137

denial-of-service (DoS) attacks, 5

DES, 69–70

detective controls, 123–124

deterrence, 54

deterrent controls, 123

Diffie, Whitfield, 70

digital certificates, 73–74

digital network intelligence (DNINT), 114

digital signatures, 72–73

directory traversal attacks, 180

disaster recovery planning (DRP), 122

disclosure, alteration, and denial (DAD), 5. See also confidentiality, integrity, and availability (CIA) triad

discretionary access control (DAC) model, 43

distributed denial-of-service (DDoS) attacks, 170

DMZs (demilitarized zones), 137

dongles, 32

dynamic analysis, 199

E

Ecole de Guerre Economique (Economic Warfare School), 103

electronic intelligence (ELINT), 114

electronic protected health information (e-PHI), 85

elliptic curve cryptography (ECC), 71

embedded devices, 164–167, 169

encryption, 61, 70, 178

energy anomalies, 125

Enhanced Virus Protection, 152

Enigma machine, 64–65

enterprise mobility management, 161

environmental attributes, 45

equal error rates (EERs), 31

Equifax, 53

equipment, 129–132

EtherApe, 185

Ethereal, 142

ethical hacking, 195–200

evacuations, 126–127

executable space protection, 151–152

Execute Disable (XD) bit, 152

EXIF data, 111–112

exploit frameworks, 156

F

fabrication attacks, 10

Facebook, 109

factors, 26–27

false acceptance rates (FARs) and false rejection rates (FRRs), 31

falsified information, 25

Family Educational Rights and Privacy Act (FERPA) (1974), 86

Fazio Mechanical, 174

Federal Information Security Management Act (FISMA) (2002), 4, 84

Federal Risk and Authorization Management Program (FedRAMP), 85

Fighting Computer Crime (Parker), 6, 122

file metadata, 111

file system ACLs, 38–39

FIM (file integrity monitoring) tools, 203–204

financial intelligence (FININT), 114

fingerprints, 29–30. See also biometrics

firewalls, 135–137, 143–144, 152–153

flash media, 128

forensic investigations, 111

format string attacks, 176

frequency analysis, 67

FTP (File Transfer Protocol), 140

full disk encryption, 75

fuzzers, 188

G

General Data Protection Regulation (GDPR) (2018), 87

geospatial intelligence (GEOINT), 113

GitHub, 169

Global Positioning System (GPS) information, 112

Google, 110–111, 163, 200

Gramm–Leach–Bliley Act (GLBA) (1999), 86

gray-box testing, 198

Greenbone, 155

group permissions, 39

H

Haase, Kurt, 99

HackerOne, 201

hard-coded passwords, 177

hardware devices, 200

hardware tokens, 32–33

hash functions, 71–72

Health Insurance Portability and Accountability Act (HIPAA) (1996), 4, 52, 85

Hellman, Martin, 70

heuristics, 151

honeypots and honeynets, 143

hosts, 193

human intelligence (HUMINT), 108

I

IaaS (infrastructure as a service) environments, 89–91, 195

identification, 23–33

identity thieves, 25

impact, 11

impersonation attacks, 27–28

incident response process, 15–17

industrial control systems, 164–165

industrial espionage, 103

industry compliance, 80–81. See also compliance

information security policies, 81–82

infrastructure as a service (IaaS) environments, 89–91, 195

input validation attacks, 176, 180

integrity, 5, 7

Intel, 152

Interagency OPSEC Support Staff (IOSS), 104

interception attacks, 8

International Organization for Standardization (ISO), 88

Internet of Things (IoT) devices, 159, 167–170

Internet Protocol (IP) addresses, 40

Internet Protocol Security (IPsec), 76

interruption attacks, 9

intrusion detection systems (IDSs)

accountability and, 54–55

implementation of, 138

operating systems and, 152–153

intrusion prevention systems (IPSs), 54–55

IOSS (Interagency OPSEC Support Staff), 104

IP addresses, 40

J

jailbreaking, 162–163

Java Virtual Machine (JVM), 37

Jefferson Disk, 62–64

job listings, 109

Joint Test Action Group (JTAG) debug ports, 200

K

Kali, 141

Kerckhoffs, Auguste, 66

key controls, 82

key exchange, 68

keyless cryptography, 71–72

keys, 61

keyword ciphers, 67

Kismet, 141, 143

KRACK vulnerability, 168

L

laws and regulations. See also compliance

Children’s Internet Protection Act (CIPA) (2000), 86

Children’s Online Privacy Protection Act (COPPA) (1988), 86

familiarity with, 119

Family Educational Rights and Privacy Act (FERPA) (1974), 86

Federal Information Security Management Act (FISMA) (2002), 4

General Data Protection Regulation (GDPR) (2018), 87

Gramm–Leach–Bliley Act (GLBA) (1999), 86

Health Insurance Portability and Accountability Act (HIPAA) (1996), 4, 52, 85

international, 87

overview, 4

Sarbanes–Oxley Act (SOX) (2002), 52, 55, 85

Linux operating systems, 141, 149, 185

logging, 56–57, 150

logical controls, 14

M

magnetic media, 127–129

malicious apps, 163

Maltego, 113

malware, 118, 151–153, 170

mandatory access control (MAC) model, 43

man-in-the-middle attacks, 27–28

mapping environments, 192

measurement and signature intelligence (MASINT), 113

Media Access Control addresses, 40

medical devices, 165

metadata, 111

Metasploit framework, 155

Microsoft, 149

Miller, Barton, 188

Miller, Charlie, 166

minutiae, 29–30

Mirai botnet, 170

mitmproxy, 169

mobile devices, 160–164

modification attacks, 9

Mogul, Jeffrey, 135

monitoring, 57

multifactor authentication, 27

multilevel access control models, 45–48

mutual authentication, 27

N

National Institute of Standards and Technology (NIST), 84, 88

National Security Agency (NSA), 11

Nessus, 191

networks

access control lists (ACLs), 39–41

air-gapped networks, 165

class A and class B internal networks, 192

Internet of Things (IoT) devices on, 167–168

overview, 133–134

penetration testing of, 198

protection of, 134–138

security tools, 140–144

segmentation, 134

tools for, 140–144

usage, 117–118

virtual private network (VPN) connections, 76, 118, 139

wireless networks, 139–141

NIST (National Institute of Standards and Technology), 84, 88

Nmap, 141, 147–148, 153–155, 192

noncompliance, 81. See also compliance

nonmobile devices, 161

nonrepudiation, 7, 54, 73

NoScript, 179

O

one-time pads, 67–68

one-way problems, 66

open source intelligence (OSINT), 108–113

OpenVAS, 155–156

operating systems

malware and, 151–153

operating system hardening, 146–150

overview, 145–146

tools for, 153–156

operations security (OPSEC)

laws of, 99–100

origins of, 101–104

overview, 95–98

personal data and, 100–101

optical media, 128

OWASP Zed Attack Proxy (ZAP), 186

P

PaaS (platform as a service) environments, 89–91, 195

packets, 135–136, 138

packet sniffers, 142–143

Parker, Donn, 6–8, 122

Parkerian hexad, 6–8, 12

passive scanning, 193

passwords

authentication attacks and, 177

defense in depth strategy, 18

overview, 28–29

password managers, 29

security training programs and, 116–117

Payment Card Industry Data Security Standard (PCI DSS), 4, 80

penetration testing (pentesting), 19, 58, 195–201

people, protection of, 125–127

permissions, 38–40

personal equipment, 118

phishing, 114–115

physical controls

compliance and, 81

overview, 14, 48–50

types of, 122–125

physical penetration testing, 199

physical security

data, 75, 127–129

devices, 168

equipment, 129–132

overview, 121–122

people, 125–127

threats, 122

plaintext, 61

platform as a service (PaaS) environments, 89–91, 195

Porter, Michael E., 103

ports, 40–41

port scanners, 141, 147–148, 153–155

possession, 7

Post Office Protocol (POP), 140

pretexting, 114

Pretty Good Privacy (PGP), 71

preventive controls, 124

principle of least privilege, 43–44, 149

printers, 167

Privacy Rights Clearinghouse, 100

privilege escalation attacks, 183–184

protected health information (PHI), 85

protocols

FTP (File Transfer Protocol), 140

Internet Protocol (IP) addresses, 40

Internet Protocol Security (IPsec), 76

Post Office Protocol (POP), 140

Secure File Transfer Protocol (SFTP), 140

Secure Sockets Layer (SSL) protocol, 71

Signaling System No. 7 (SS7) protocol, 162

vulnerabilities and, 182

proxy servers, 137

public key infrastructure (PKI), 74

public records, 109–110

public wireless networks, 139–141

Purple Dragon, 103

purple teams, 203

Q

Quadriga, 92

Qualys, 58, 191

R

race conditions, 175–176

RAID arrays, 128

reactive tools, 56–57

Reagan, Ronald, 104

real-time operating systems (RTOSs), 164–165

red teams, 196

redundant arrays of inexpensive disks (RAID), 128

regulations. See laws and regulations

regulatory compliance, 80–81. See also compliance

remote code executions (RCEs), 53, 183

residual data, 129

resource attributes, 45

résumés, 109

risk-based approach, 84

risks. See also operations security (OPSEC)

assessment of, 13, 98

management processes, 11

mitigation of, 14

overview, 10

Rivest, Ron, 71

Rivest-Shamir-Adleman (RSA) algorithm, 71, 178

rogue access points, 139–140

role-based access control (RBAC) model, 44

ROT13 cipher, 62

rule-based access control, 44

rules of engagement, 196, 201

S

SaaS (software as a service) environments, 89–91

safety of people, 126

sandboxes, 37

Sarbanes–Oxley Act (SOX) (2002), 52, 55, 85

SaverSpy, 100

scanners, 141, 153–155, 193–194. See also vulnerabilities

Scapy, 143

SCIP (Strategic and Competitive Intelligence Professionals), 103

scoping, 196

Secure File Transfer Protocol (SFTP), 140

secure protocols, 140

Secure Shell (SSH), 140

Secure Sockets Layer (SSL) protocol, 71

security through obscurity strategy, 65

segmentation, 134

server-side attacks, 179–181

services, 147–148

SFTP (Secure File Transfer Protocol), 140

Shamir, Adi, 71

Shannon, Claude, 66

shifts, 67–68

Shodan, 100, 112

Signaling System No. 7 (SS7) protocol, 162

signals intelligence (SIGINT), 114

signature-based IDS, 138

“Simple and Flexible Datagram Access Controls” (Mogul), 135

smart devices, 159, 167–170

smart locks, 168

sniffers, 142–143, 184–185

Snowden, Edward, 76

social engineering attacks

information for, 108–114

overview, 107–108

penetration testing (pentesting) and, 199–200

security training programs and, 117

types of, 114–116

social media, 101, 109

sockets, 41

software. See also applications

databases, 181–184

extraneous, 146–147, 181

licenses, 56

vulnerabilities, 174–178

web applications, 178–181

software as a service (SaaS) environments, 89–91

Spafford, Eugene, 2

spear phishing, 115

Special Publications (SPs), 84, 88

spidering, 186

SQL injection, 184

SSH (Secure Shell), 140

stateful packet inspection firewalls, 136

static analysis, 199

Strategic and Competitive Intelligence Professionals (SCIP), 103

stream ciphers, 69

StrongVPN, 139

Stuxnet virus, 164

subject attributes, 45

subnets, 134

substitution ciphers, 62

Sun Tzu, 102

supervisory control and data acquisition systems, 164

surveillance cameras, 168

symmetric key cryptography, 68–69. See also cryptography

Synack, 201

T

tailgating, 48–49, 116, 200

Talos Intelligence Group, 25

Tapplock, 168

Target Corporation, 173–174

Tcpdump, 142

technical controls, 14, 82

technical intelligence (TECHINT), 114

technological changes

compliance and, 89–92

data storage and, 128

Internet of Things (IoT) devices and, 170

vulnerability assessments and, 204–205

threats. See also operations security (OPSEC)

analysis of, 97

identification of, 12, 122

overview, 10

tokens, 42–43

Triton, 151, 164

trust but verify, 117, 187

two-factor authentication, 27

U

unauthenticated scans, 193

unified endpoint management, 161

Universal Asynchronous Receiver/Transmitter (UART) debug ports, 200

UNIX operating systems, 149

updates

browsers, 179

embedded devices, 166

mobile devices, 163–164

operating systems, 150

user interface redressing, 42

US National Institute of Standards and Technology (NIST), 84

US National Security Agency (NSA), 11

utility, 7

V

Valasek, Chris, 166

validation, 176, 180

vehicles, 165–166

Vietnam War, 103

VPN (virtual private network) connections, 76, 118, 139

vulnerabilities. See also operations security (OPSEC)

assessment of, 12–13, 58, 97, 155–156, 191–195

overview, 10

protocols and, 182

scanners, 141, 153–155, 193–194

software development, 174–178

W

Washington, George, 102

web applications, 178–181

white-box testing, 197–198

Wi-Fi Protected Access (WPA, WPA2, and WPA3), 140

Wired Equivalent Privacy (WEP), 140

wireless networks, 139–140, 141

Wireshark, 142, 184–185

X

XD bit, 152

XSS (cross-site scripting), 178

Z

ZAP (Zed Attack Proxy), 186

zero-day attacks, 141

Foundations of Information Security is set in New Baskerville, Futura, and Dogma.

RESOURCES

Visit https://nostarch.com/foundationsinfosec/ for errata and more information.

More no-nonsense books from NO STARCH PRESS

REAL-WORLD BUG HUNTING

A Field Guide to Web Hacking

by PETER YAWORSKI

JULY 2019, 264 PP., $39.95

ISBN 978-1-59327-861-8

BLACK HAT PYTHON

Python Programming for Hackers and Pentesters

by JUSTIN SEITZ

DECEMBER 2014, 192 PP., $34.95

ISBN 978-1-59327-590-7

PRACTICAL PACKET ANALYSIS, 3RD EDITION

Using Wireshark to Solve Real-World Network Problems

by CHRIS SANDERS

APRIL 2017, 368 PP., $49.95

ISBN 978-1-59327-802-1

SERIOUS CRYPTOGRAPHY

A Practical Introduction to Modern Encryption

by JEAN-PHILIPPE AUMASSON

NOVEMBER 2017, 312 PP., $49.95

ISBN 978-1-59327-826-7

PRACTICAL MALWARE ANALYSIS

The Hands-On Guide to Dissecting Malicious Software

by MICHAEL SIKORSKI and ANDREW HONIG

FEBRUARY 2012, 800 PP., $59.95

ISBN 978-1-59327-290-6

LINUX BASICS FOR HACKERS

Getting Started with Networking, Scripting, and Security in Kali

by OCCUPYTHEWEB

DECEMBER 2018, 248 PP., $34.95

ISBN 978-1-59327-855-7

PHONE:
800.420.7240 OR
415.863.9900

EMAIL:
SALES@NOSTARCH.COM

WEB:
WWW.NOSTARCH.COM

Begin your journey into the dynamic and rewarding field of information security

In this survey of the information-security fundamentals, best-selling author Jason Andress covers the basics of a wide variety of topics, from authentication and authorization to maintaining confidentiality and performing penetration testing.

Using real-world security breaches as examples, Foundations of Information Security explores operations security, network design, operating system hardening and patching, and mobile device security, as well as tools for assessing the security of hosts and applications.

You’ll also learn the basics of:

Multifactor authentication ...