Course 5 overview

Hello, and welcome to Assets, Threats, and Vulnerabilities, the fifth course
in the Google Cybersecurity Certificate. You’re on an exciting journey!

By the end of this course, you’ll build an understanding of the wide range of
assets organizations must protect. You’ll explore many of the most common
security controls used to protect valuable assets from risk. You’ll also discover
the variety of ways assets are vulnerable to threats by adopting an attacker
mindset.

Certificate program progress

The Google Cybersecurity Certificate program has eight courses. Assets,

Threats, and Vulnerabilities is the fifth course.
1. Foundations of Cybersecurity — Explore the cybersecurity profession,
including significant events that led to the development of the cybersecurity
field and its continued importance to organizational operations. Learn about
entry-level cybersecurity roles and responsibilities.

2. Play It Safe: Manage Security Risks — Identify how cybersecurity

professionals use frameworks and controls to protect business operations,
and explore common cybersecurity tools.

3. Connect and Protect: Networks and Network Security — Gain an

understanding of network-level vulnerabilities and how to secure networks.

4. Tools of the Trade: Linux and SQL — Explore foundational computing skills,
including communicating with the Linux operating system through the
command line and querying databases with SQL.

5. Assets, Threats, and Vulnerabilities — (current course) Learn about the

importance of security controls and developing a threat actor mindset to
protect and defend an organization’s assets from various threats, risks, and
vulnerabilities.
6. Sound the Alarm: Detection and Response — Understand the incident
response lifecycle and practice using tools to detect and respond to
cybersecurity incidents.

7. Automate Cybersecurity Tasks with Python — Explore the Python

programming language and write code to automate cybersecurity tasks.

8. Put It to Work: Prepare for Cybersecurity Jobs — Learn about incident

classification, escalation, and ways to communicate with stakeholders. This
course closes out the program with tips on how to engage with the
cybersecurity community and prepare for your job search.

Course 5 content

Each course of this certificate program is broken into modules. You can
complete courses at your own pace, but the module breakdowns are designed
to help you finish the entire Google Cybersecurity Certificate in about six
months.

What’s to come? Here’s a quick overview of the skills you’ll learn in each
module of this course.

Module 1: Introduction to asset security

You will be introduced to how organizations determine what assets to protect.

You'll learn about the connection between managing risk and classifying
assets by exploring the unique challenge of securing physical and digital
assets. You'll also be introduced to the National Institute of Standards and
Technology (NIST) framework standards, guidelines, and best practices for
managing cybersecurity risk.

Module 2: Protect organizational assets

You will focus on security controls that protect organizational assets. You'll
explore how privacy impacts asset security and understand the role that
encryption plays in maintaining the privacy of digital assets. You'll also
explore how authentication and authorization systems help verify a user’s
identity.

Module 3: Vulnerabilities in systems

You will build an understanding of the vulnerability management process.

You'll learn about common vulnerabilities and develop an attacker mindset by
examining the ways vulnerabilities can become threats to asset security if
they are exploited.

Module 4: Threats to asset security

Finally, you will explore common types of threats to digital asset security.
You'll also examine the tools and techniques used by cybercriminals to target
assets. In addition, you'll be introduced to the threat modeling process and
learn ways security professionals stay ahead of security breaches.
 Understand risks, threats, and
vulnerabilities
When security events occur, you’ll need to work in close coordination with
others to address the problem. Doing so quickly requires clear communication
between you and your team to get the job done.

Previously, you learned about three foundational security terms:

 Risk: Anything that can impact the confidentiality, integrity, or availability of

an asset

 Threat: Any circumstance or event that can negatively impact assets

 Vulnerability: A weakness that can be exploited by a threat

These words tend to be used interchangeably in everyday life. But in security,

they are used to describe very specific concepts when responding to and
planning for security events. In this reading, you’ll identify what each term
represents and how they are related.

Security risk

Security plans are all about how an organization defines risk. However, this
definition can vary widely by organization. As you may recall, a risk is
anything that can impact the confidentiality, integrity, or availability of an
asset. Since organizations have particular assets that they value, they tend to
differ in how they interpret and approach risk.
 One way to interpret risk is to consider the potential effects that negative
events can have on a business. Another way to present this idea is with this
calculation:

Likelihood x Impact = Risk

For example, you risk being late when you drive a car to work. This negative
event is more likely to happen if you get a flat tire along the way. And the
impact could be serious, like losing your job. All these factors influence how
you approach commuting to work every day. The same is true for how
businesses handle security risks.

In general, we calculate risk in this field to help:

 Prevent costly and disruptive events

 Identify improvements that can be made to systems and processes

 Determine which risks can be tolerated

 Prioritize the critical assets that require attention

The business impact of a negative event will always depend on the asset and
the situation. Your primary focus as a security professional will be to focus on
the likelihood side of the equation by dealing with certain factors that increase
the odds of a problem.

Risk factors

As you’ll discover throughout this course, there are two broad risk factors that
you’ll be concerned with in the field:
 Threats

 Vulnerabilities

The risk of an asset being harmed or damaged depends greatly on whether a

threat takes advantage of vulnerabilities.

Let’s apply this to the risk of being late to work. A threat would be a nail
puncturing your tire, since tires are vulnerable to running over sharp objects.
In terms of security planning, you would want to reduce the likelihood of this
risk by driving on a clean road.

Categories of threat

Threats are circumstances or events that can negatively impact assets. There
are many different types of threats. However, they are commonly categorized
as two types: intentional and unintentional.

For example, an intentional threat might be a malicious hacker who gains

access to sensitive information by targeting a misconfigured application. An
unintentional threat might be an employee who holds the door open for an
unknown person and grants them access to a restricted area. Either one can
cause an event that must be responded to.

Categories of vulnerability

Vulnerabilities are weaknesses that can be exploited by threats. There’s a

wide range of vulnerabilities, but they can be grouped into two categories:
technical and human.
For example, a technical vulnerability can be misconfigured software that
might give an unauthorized person access to important data. A human
vulnerability can be a forgetful employee who loses their access card in a
parking lot. Either one can lead to risk.

Key takeaways

Risks, threats, and vulnerabilities have very specific meanings in security.

Knowing the relationship between them can help you build a strong
foundation as you grow essential skills and knowledge as a security analyst.
This can help you gain credibility in the industry by demonstrating that you
have working knowledge of the field. And it signals to your future colleagues
that you’re a member of the global security community.

Common classification requirements

Asset management is the process of tracking assets and the risks that affect
them. The idea behind this process is simple: you can only protect what you
know you have.

Previously, you learned that identifying, tracking, and classifying assets are all
important parts of asset management. In this reading, you’ll learn more about
 the purpose and benefits of asset classification, including common
classification levels.

Why asset management matters

Keeping assets safe requires a workable system that helps businesses operate
smoothly. Setting these systems up requires having detailed knowledge of the
assets in an environment. For example, a bank needs to have money available
each day to serve its customers. Equipment, devices, and processes need to be
in place to ensure that money is available and secure from unauthorized
access.

Organizations protect a variety of different assets. Some examples might

include:

 Digital assets such as customer data or financial records.

 Information systems that process data, like networks or software.

 Physical assets which can include facilities, equipment, or supplies.

 Intangible assets such as brand reputation or intellectual property.

Regardless of its type, every asset should be classified and accounted for. As
you may recall, asset classification is the practice of labeling assets based on
sensitivity and importance to an organization. Determining each of those two
factors varies, but the sensitivity and importance of an asset typically requires
knowing the following:
 What you have

 Where it is

 Who owns it, and

 How important it is

An organization that classifies its assets does so based on these

characteristics. Doing so helps them determine the sensitivity and value of an
asset.

Common asset classifications

Asset classification helps organizations implement an effective risk

management strategy. It also helps them prioritize security resources, reduce
IT costs, and stay in compliance with legal regulations.

The most common classification scheme is: restricted, confidential, internal-

only, and public.

 Restricted is the highest level. This category is reserved for incredibly

sensitive assets, like need-to-know information.

 Confidential refers to assets whose disclosure may lead to a significant

negative impact on an organization.

 Internal-only describes assets that are available to employees and business

partners.

 Public is the lowest level of classification. These assets have no negative

consequences to the organization if they’re released.
How this scheme is applied depends greatly on the characteristics of an asset.
It might surprise you to learn that identifying an asset’s owner is sometimes
the most complicated characteristic to determine.

Note: Although many organizations adopt this classification scheme, there can
be variability at the highest levels. For example, government organizations
label their most sensitive assets as confidential instead of restricted.

Challenges of classifying information

Identifying the owner of certain assets is straightforward, like the owner of a

building. Other types of assets can be trickier to identify. This is especially
true when it comes to information.

For example, a business might issue a laptop to one of its employees to allow
them to work remotely. You might assume the business is the asset owner in
this situation. But, what if the employee uses the laptop for personal matters,
like storing their photos?

Ownership is just one characteristic that makes classifying information a

challenge. Another concern is that information can have multiple classification
values at the same time. For example, consider a letter addressed to you in the
mail. The letter contains some public information that’s okay to share, like
your name. It also contains fairly confidential pieces of information that you’d
rather only be available to certain people, like your address. You’ll learn more
about how these challenges are addressed as you continue through the
program.

Key takeaways
Every business is different. Each business will have specific requirements to
address when devising their security strategy. Knowing why and how
businesses classify their assets is an important skill to have as a security
professional. Information is one of the most important assets in the world. As
a cybersecurity professional, you will be closely involved with protecting
information from damage, disclosure, and misuse. Recognizing the challenges
that businesses face classifying this type of asset is a key to helping them solve
their security needs.

The emergence of cloud security

One of the most significant technology developments this century has been
the emergence of cloud computing. The United Kingdom's National Cyber
Security Centre defines cloud computing as, “An on-demand, massively
scalable service, hosted on shared infrastructure, accessible via the internet.”

Earlier, you learned that most information is in the form of data, which is in a
constant state of change. In recent years, businesses started moving their data
to the cloud. The adoption of cloud-based services has complicated how
information is kept safe online. In this reading, you’ll learn about these
challenges and the opportunities they’ve created for security professionals.
 Soaring into the cloud

Starting an online business used to be a complicated and costly process. In

years past, companies had to build and maintain their own internal solutions
to operate in the digital marketplace. Now, it’s much easier for anyone to
participate because of the cloud.

The availability of cloud technologies has drastically changed how businesses

operate online. These new tools allow companies to scale and adapt quickly
while also lowering their costs. Despite these benefits, the shift to cloud-based
services has also introduced a range of new cybersecurity challenges that put
assets at risk.

Cloud-based services

The term cloud-based services refers to a variety of on demand or web-based

business solutions. Depending on a company’s needs and budget, services can
range from website hosting, to application development environments, to
entire back-end infrastructure.

There are three main categories of cloud-based services:

 Software as a service (SaaS)

 Platform as a service (PaaS)

 Infrastructure as a service (IaaS)

Software as a service (SaaS)

 SaaS refers to front-end applications that users access via a web browser. The
service providers host, manage, and maintain all of the back-end systems for
those applications. Common examples of SaaS services include applications
like Gmail™ email service, Slack, and Zoom software.

Platform as a service (PaaS)

PaaS refers to back-end application development tools that clients can access
online. Developers use these resources to write code and build, manage, and
deploy their own apps. Meanwhile, the cloud service providers host and
maintain the back-end hardware and software that the apps use to operate.
Some examples of PaaS services include Google App Engine™ platform,
Heroku®, and VMware Cloud Foundry.

Infrastructure as a service (IaaS)

IaaS customers are given remote access to a range of back-end systems that
are hosted by the cloud service provider. This includes data processing
servers, storage, networking resources, and more. Resources are commonly
licensed as needed, making it a cost-effective alternative to buying and
maintaining on premises.

Cloud-based services allow companies to connect with their customers,

employees, and business partners over the internet. Some of the largest
organizations in the world offer cloud-based services:

 Google Cloud Platform

 Microsoft Azure
 Cloud security

Shifting applications and infrastructure over to the cloud can make it easier to
operate an online business. It can also complicate keeping data private and
safe. Cloud security is a growing subfield of cybersecurity that specifically
focuses on the protection of data, applications, and infrastructure in the cloud.

In a traditional model, organizations had their entire IT infrastructure on

premises. Protecting those systems was entirely up to the internal security
team in that environment. These responsibilities are not so clearly defined
when part or all of an operational environment is in the cloud.

For example, a PaaS client pays to access the resources they need to build
their applications. So, it is reasonable to expect them to be responsible for
securing the apps they build. On the other hand, the responsibility for
maintaining the security of the servers they are accessing should belong to the
cloud service provider because there are other clients using the same systems.

In cloud security, this concept is known as the shared responsibility model.

Clients are commonly responsible for securing anything that is directly within
their control:

 Identity and access management

 Resource configuration

 Data handling

Note: The amount of responsibility that is delegated to a service provider

varies depending on the service being used: SaaS, PaaS, and IaaS.
 Cloud security challenges

All service providers do their best to deliver secure products to their

customers. Much of their success depends on preventing breaches and how
well they can protect sensitive information. However, since data is stored in
the cloud and accessed over the internet, several challenges arise:

 Misconfiguration is one of the biggest concerns. Customers of cloud-based

services are responsible for configuring their own security environment.
Oftentimes, they use out-of-the-box configurations that fail to address their
specific security objectives.

 Cloud-native breaches are more likely to occur due to misconfigured

services.

 Monitoring access might be difficult depending on the client and level of

service.

 Meeting regulatory standards is also a concern, particularly in industries

that are required by law to follow specific requirements such as HIPAA, PCI
DSS, and GDPR.

Many other challenges exist besides these. As more businesses adopt cloud-
based services, there’s a growing need for cloud security professionals to meet
a growing number of risks. Burning Glass, a leading labor market analytics
firm, ranks cloud security among the most in-demand skills in cybersecurity.

Key takeaways
 So much of the global marketplace has shifted to cloud-based services. Cloud
technology is still new, resulting in the emergence of new security models and
a range of security challenges. And it’s likely that other concerns might arise
as more businesses become reliant on the cloud. Being familiar with the cloud
and the different services that are available is an important step towards
supporting any organizations efforts to protect information online.

Resources for more information

Cloud security is one of the fastest growing subfields of cybersecurity. There

are a variety of resources available online to learn more about this specialized
topic.

 The U.K.’s National Cyber Security Centre has a detailed guide for choosing,
using, and deploying cloud services securely based on the shared
responsibility model.

 The Cloud Security Alliance® is an organization dedicated to creating secure

cloud environments. They offer access to cloud security-specific research,
certification, and products to users with a paid membership.

 CompTIA Cloud+ is a certificate program designed to teach you the

foundational skills needed to become a cloud security specialist.
Security guidelines in action
Organizations often face an overwhelming amount of risk. Developing a
security plan from the beginning that addresses all risk can be challenging.
This makes security frameworks a useful option.

Previously, you learned about the NIST Cybersecurity Framework (CSF). A

major benefit of the CSF is that it's flexible and can be applied to any industry.
In this reading, you’ll explore how the NIST CSF can be implemented.

Origins of the framework

Originally released in 2014, NIST developed the Cybersecurity Framework to

protect critical infrastructure in the United States. NIST was selected to
develop the CSF because they are an unbiased source of scientific data and
practices. NIST eventually adapted the CSF to fit the needs of businesses in the
public and private sector. Their goal was to make the framework more
flexible, making it easier to adopt for small businesses or anyone else that
might lack the resources to develop their own security plans.

Components of the CSF

As you might recall, the framework consists of three main components: the
core, tiers, and profiles. In the following sections, you'll learn more about each
of these CSF components.

Core
The CSF core is a set of desired cybersecurity outcomes that help
organizations customize their security plan. It consists of six functions, or
parts: Identify, Protect, Detect, Respond, Recover, and Govern. These functions
are commonly used as an informative reference to help organizations identify
their most important assets and protect those assets with appropriate
safeguards. The CSF core is also used to understand ways to detect attacks and
develop response and recovery plans should an attack happen.

Previously, the core consisted of just five functions. Govern was added in
February of 2024 to emphasize the importance of leadership and decision-
making when it comes to managing cybersecurity risks.

Tiers

The CSF tiers are a way of measuring the sophistication of an organization's

cybersecurity program. CSF tiers are measured on a scale of 1 to 4. Tier 1 is
the lowest score, indicating that a limited set of security controls have been
implemented. Overall, CSF tiers are used to assess an organization's security
posture and identify areas for improvement.

Profiles

The CSF profiles are pre-made templates of the NIST CSF that are developed
by a team of industry experts. CSF profiles are tailored to address the specific
risks of an organization or industry. They are used to help organizations
develop a baseline for their cybersecurity plans, or as a way of comparing
their current cybersecurity posture to a specific industry standard.
Note: The core, tiers, and profiles were each designed to help any business
improve their security operations. Although there are only three components,
the entire framework consists of a complex system of subcategories and
processes.

Implementing the CSF

As you might recall, compliance is an important concept in security.

Compliance is the process of adhering to internal standards and external
regulations. In other words, compliance is a way of measuring how well an
organization is protecting their assets. The NIST Cybersecurity Framework
(CSF) is a voluntary framework that consists of standards, guidelines, and
best practices to manage cybersecurity risk. Organizations may choose to use
the CSF to achieve compliance with a variety of regulations.

Note: Regulations are rules that must be followed, while frameworks are
resources you can choose to use.

Since its creation, many businesses have used the NIST CSF. However, CSF can
be a challenge to implement due to its high level of detail. It can also be tough
to find where the framework fits in. For example, some businesses have
established security plans, making it unclear how CSF can benefit them.
Alternatively, some businesses might be in the early stages of building their
plans and need a place to start.

In any scenario, the U.S. Cybersecurity and Infrastructure Security Agency

(CISA) provides detailed guidance that any organization can use to implement
the CSF. This is a quick overview and summary of their recommendations:
 Create a current profile of the security operations and outline the specific
needs of your business.

 Perform a risk assessment to identify which of your current operations are

meeting business and regulatory standards.

 Analyze and prioritize existing gaps in security operations that place the
businesses assets at risk.

 Implement a plan of action to achieve your organization’s goals and

objectives.

Pro tip: Always consider current risk, threat, and vulnerability trends when
using the NIST CSF.

You can learn more about implementing the CSF in this report by CISA that
outlines how the framework was applied in the commercial facilities sector.

Industries embracing the CSF

The NIST CSF has continued to evolve since its introduction in 2014. Its design
is influenced by the standards and best practices of some of the largest
companies in the world.

A benefit of the framework is that it aligns with the security practices of many
organizations across the global economy. It also helps with regulatory
compliance that might be shared by business partners.

Key takeaways
The NIST CSF is a flexible resource that organizations may choose to use to
assess and improve their security posture. It's a useful framework that
combines the security best practices of industries around the world.
Implementing the CSF can be a challenge for any organization. The CSF can
help business meet regulatory compliance requirements to avoid financial and
reputational risks.

Principle of least privilege

Security controls are essential to keeping sensitive data private and safe. One
of the most common controls is the principle of least privilege, also referred to
as PoLP or least privilege. The principle of least privilege is a security
concept in which a user is only granted the minimum level of access and
authorization required to complete a task or function.

Least privilege is a fundamental security control that supports the

confidentiality, integrity, and availability (CIA) triad of information. In this
reading, you'll learn how the principle of least privilege reduces risk, how it's
commonly implemented, and why it should be routinely audited.

Limiting access reduces risk

Every business needs to plan for the risk of data theft, misuse, or abuse.
Implementing the principle of least privilege can greatly reduce the risk of
costly incidents like data breaches by:
 Limiting access to sensitive information

 Reducing the chances of accidental data modification, tampering, or loss

 Supporting system monitoring and administration

Least privilege greatly reduces the likelihood of a successful attack by

connecting specific resources to specific users and placing limits on what they
can do. It's an important security control that should be applied to any asset.
Clearly defining who or what your users are is usually the first step of
implementing least privilege effectively.

Note: Least privilege is closely related to another fundamental security

principle, the separation of duties—a security concept that divides tasks and
responsibilities among different users to prevent giving a single user complete
control over critical business functions. You'll learn more about separation of
duties in a different reading about identity and access management.

Determining access and authorization

To implement least privilege, access and authorization must be determined

first. There are two questions to ask to do so:

 Who is the user?

 How much access do they need to a specific resource?

Determining who the user is usually straightforward. A user can refer to a

person, like a customer, an employee, or a vendor. It can also refer to a device
or software that's connected to your business network. In general, every user
 should have their own account. Accounts are typically stored and managed
within an organization's directory service.

These are the most common types of user accounts:

 Guest accounts are provided to external users who need to access an internal
network, like customers, clients, contractors, or business partners.

 User accounts are assigned to staff based on their job duties.

 Service accounts are granted to applications or software that needs to

interact with other software on the network.

 Privileged accounts have elevated permissions or administrative access.

It's best practice to determine a baseline access level for each account type
before implementing least privilege. However, the appropriate access level
can change from one moment to the next. For example, a customer support
representative should only have access to your information while they are
helping you. Your data should then become inaccessible when the support
agent starts working with another customer and they are no longer actively
assisting you. Least privilege can only reduce risk if user accounts are
routinely and consistently monitored.

Pro tip: Passwords play an important role when implementing the principle
of least privilege. Even if user accounts are assigned appropriately, an
insecure password can compromise your systems.

Auditing account privileges

 Setting up the right user accounts and assigning them the appropriate
privileges is a helpful first step. Periodically auditing those accounts is a key
part of keeping your company’s systems secure.

There are three common approaches to auditing user accounts:

 Usage audits

 Privilege audits

 Account change audits

As a security professional, you might be involved with any of these processes.

Usage audits

When conducting a usage audit, the security team will review which resources
each account is accessing and what the user is doing with the resource. Usage
audits can help determine whether users are acting in accordance with an
organization’s security policies. They can also help identify whether a user has
permissions that can be revoked because they are no longer being used.

Privilege audits

Users tend to accumulate more access privileges than they need over time, an
issue known as privilege creep. This might occur if an employee receives a
promotion or switches teams and their job duties change. Privilege audits
assess whether a user's role is in alignment with the resources they have
access to.

Account change audits

Account directory services keep records and logs associated with each user.
Changes to an account are usually saved and can be used to audit the directory
for suspicious activity, like multiple attempts to change an account password.
Performing account change audits helps to ensure that all account changes are
made by authorized users.

Note: Most directory services can be configured to alert system

administrators of suspicious activity.

Key takeaways

The principle of least privilege is a security control that can reduce the risk of
unauthorized access to sensitive information and resources. Setting up and
configuring user accounts with the right levels of access and authorization is
an important step toward implementing least privilege. Auditing user
accounts and revoking unnecessary access rights is an important practice that
helps to maintain the confidentiality, integrity, and availability of information.
 data lifecycle
Organizations of all sizes handle a large amount of data that must be kept
private. You learned that data can be vulnerable whether it is at rest, in use, or
in transit. Regardless of the state it is in, information should be kept private by
limiting access and authorization.

In security, data vulnerabilities are often mapped in a model known as the

data lifecycle. Each stage of the data lifecycle plays an important role in the
security controls that are put in place to maintain the CIA triad of information.
In this reading, you will learn about the data lifecycle, the plans that
determine how data is protected, and the specific types of data that require
extra attention.

The data lifecycle

The data lifecycle is an important model that security teams consider when
protecting information. It influences how they set policies that align with
business objectives. It also plays an important role in the technologies security
teams use to make information accessible.

In general, the data lifecycle has five stages. Each describe how data flows
through an organization from the moment it is created until it is no longer
useful:

 Collect

 Store

 Use
 Archive

 Destroy

Protecting information at each stage of this process describes the need to keep
it accessible and recoverable should something go wrong.

Data governance

Businesses handle massive amounts of data every day. New information is

constantly being collected from internal and external sources. A structured
approach to managing all of this data is the best way to keep it private and
secure.

Data governance is a set of processes that define how an organization

manages information. Governance often includes policies that specify how to
keep data private, accurate, available, and secure throughout its lifecycle.
 Effective data governance is a collaborative activity that relies on people. Data
governance policies commonly categorize individuals into a specific role:

 Data owner: the person that decides who can access, edit, use, or destroy
their information.

 Data custodian: anyone or anything that's responsible for the safe handling,
transport, and storage of information.

 Data steward: the person or group that maintains and implements data
governance policies set by an organization.

Businesses store, move, and transform data using a wide range of IT systems.
Data governance policies often assign accountability to data owners,
custodians, and stewards.

Note: As a data custodian, you will primarily be responsible for maintaining

security and privacy rules for your organization.

Protecting data at every stage

Most security plans include a specific policy that outlines how information
will be managed across an organization. This is known as a data governance
policy. These documents clearly define procedures that should be followed to
participate in keeping data safe. They place limits on who or what can access
data. Security professionals are important participants in data governance. As
a data custodian, you will be responsible for ensuring that data isn’t damaged,
stolen, or misused.

Legally protected information

 Data is more than just a bunch of 1s and 0s being processed by a computer.
Data can represent someone's personal thoughts, actions, and choices. It can
represent a purchase, a sensitive medical decision, and everything in between.
For this reason, data owners should be the ones deciding whether or not to
share their data. As a security professional, protecting a person's data privacy
decisions must always be respected.

Securing data can be challenging. In large part, that's because data owners
generate more data than they can manage. As a result, data custodians and
stewards sometimes lack direct, explicit instructions on how they should
handle specific types of data. Governments and other regulatory agencies have
bridged this gap by creating rules that specify the types of information that
organizations must protect by default:

 PII is any information used to infer an individual's identity. Personally

identifiable information, or PII, refers to information that can be used to
contact or locate someone.

 PHI stands for protected health information. In the U.S., it is regulated by the
Health Insurance Portability and Accountability Act (HIPAA), which defines
PHI as “information that relates to the past, present, or future physical or
mental health or condition of an individual.” In the EU, PHI has a similar
definition but it is regulated by the General Data Protection Regulation
(GDPR).

 SPII is a specific type of PII that falls under stricter handling guidelines. The S
stands for sensitive, meaning this is a type of personally identifiable
information that should only be accessed on a need-to-know basis, such as a
bank account number or login credentials.

Overall, it's important to protect all types of personal information from

unauthorized use and disclosure.

Key takeaways

Keeping information private has never been so important. Many organizations

have data governance policies that outline how they plan to protect sensitive
information. As a data custodian, you will play a key role in keeping
information accessible and safe throughout its lifecycle. There are various
types of information and controls that you’ll encounter in the field. As you
continue through this course, you’ll learn more about major security controls
that keep data private.

Information privacy: Regulations and

compliance
Security and privacy have a close relationship. As you may recall, people have
the right to control how their personal data is collected and used.
 Organizations also have a responsibility to protect the information they are
collecting from being compromised or misused. As a security professional, you
will be highly involved in these efforts.

Previously, you learned how regulations and compliance reduce security risk.
To review, refer to the reading about how security controls, frameworks, and
compliance regulations are used together to manage security and minimize
risk. In this reading, you will learn how information privacy regulations affect
data handling practices. You'll also learn about some of the most influential
security regulations in the world.

Information security vs. information privacy

Security and privacy are two terms that often get used interchangeably
outside of this field. Although the two concepts are connected, they represent
specific functions:

 Information privacy refers to the protection of unauthorized access and

distribution of data.
 Information security (InfoSec) refers to the practice of keeping data in all
states away from unauthorized users.

The key difference: Privacy is about providing people with control over their
personal information and how it's shared. Security is about protecting
people’s choices and keeping their information safe from potential threats.

For example, a retail company might want to collect specific kinds of personal
information about its customers for marketing purposes, like their age,
gender, and location. How this private information will be used should be
disclosed to customers before it's collected. In addition, customers should be
given an option to opt-out if they decide not to share their data.

Once the company obtains consent to collect personal information, it might

implement specific security controls in place to protect that private data from
unauthorized access, use, or disclosure. The company should also have
security controls in place to respect the privacy of all stakeholders and anyone
who chose to opt-out.

Note: Privacy and security are both essential for maintaining customer trust
and brand reputation.

Why privacy matters in security

Data privacy and protection are topics that started gaining a lot of attention in
the late 1990s. At that time, tech companies suddenly went from processing
people’s data to storing and using it for business purposes. For example, if a
user searched for a product online, companies began storing and sharing
access to information about that user’s search history with other companies.
Businesses were then able to deliver personalized shopping experiences to
the user for free.

Eventually this practice led to a global conversation about whether these

organizations had the right to collect and share someone’s private data.
Additionally, the issue of data security became a greater concern; the more
organizations collected data, the more vulnerable it was to being abused,
misused, or stolen.
 Many organizations became more concerned about the issues of data privacy.
Businesses became more transparent about how they were collecting, storing,
and using information. They also began implementing more security
measures to protect people's data privacy. However, without clear rules in
place, protections were inconsistently applied.

Note: The more data is collected, stored, and used, the more vulnerable it is to
breaches and threats.

Notable privacy regulations

Businesses are required to abide by certain laws to operate. As you might

recall, regulations are rules set by a government or another authority to
control the way something is done. Privacy regulations in particular exist to
protect a user from having their information collected, used, or shared
without their consent. Regulations may also describe the security measures
that need to be in place to keep private information away from threats.

Three of the most influential industry regulations that every security

professional should know about are:

 General Data Protection Regulation (GDPR)

 Payment Card Industry Data Security Standard (PCI DSS)
 Health Insurance Portability and Accountability Act (HIPAA)

GDPR

GDPR is a set of rules and regulations developed by the European Union (EU)
that puts data owners in total control of their personal information. Under
GDPR, types of personal information include a person's name, address, phone
number, financial information, and medical information.

The GDPR applies to any business that handles the data of EU citizens or
residents, regardless of where that business operates. For example, a US based
company that handles the data of EU visitors to their website is subject to the
GDPRs provisions.

PCI DSS

PCI DSS is a set of security standards formed by major organizations in the

financial industry. This regulation aims to secure credit and debit card
transactions against data theft and fraud.

HIPAA

HIPAA is a U.S. law that requires the protection of sensitive patient health
information. HIPAA prohibits the disclosure of a person's medical information
without their knowledge and consent.

Note: These regulations influence data handling at many organizations

around the world even though they were developed by specific nations.

Several other security and privacy compliance laws exist. Which ones your
organization needs to follow will depend on the industry and the area of
authority. Regardless of the circumstances, regulatory compliance is
important to every business.

Security assessments and audits

 Businesses should comply with important regulations in their industry. Doing
so validates that they have met a minimum level of security while also
demonstrating their dedication to maintaining data privacy.

Meeting compliance standards is usually a continual, two-part process of

security audits and assessments:

 A security audit is a review of an organization's security controls, policies,

and procedures against a set of expectations.
 A security assessment is a check to determine how resilient current security
implementations are against threats.

For example, if a regulation states that multi-factor authentication (MFA)

must be enabled for all administrator accounts, an audit might be conducted
to check those user accounts for compliance. After the audit, the internal team
might perform a security assessment that determines many users are using
weak passwords. Based on their assessment, the team could decide to enable
MFA on all user accounts to improve their overall security posture.

Note: Compliance with legal regulations, such as GDPR, can be determined

during audits.

As a security analyst, you are likely to be involved with security audits and
assessments in the field. Businesses usually perform security audits less
frequently, approximately once per year. Security audits may be performed
both internally and externally by different third-party groups.

In contrast, security assessments are usually performed more frequently,

about every three-to-six months. Security assessments are typically
performed by internal employees, often as preparation for a security audit.
 Both evaluations are incredibly important ways to ensure that your systems
are effectively protecting everyone's privacy.

Key takeaways

A growing number of businesses are making it a priority to protect and

govern the use of sensitive data to maintain customer trust. Security
professionals should think about data and the need for privacy in these terms.
Organizations commonly use security assessments and audits to evaluate gaps
in their security plans. While it is possible to overlook or delay addressing the
results of an assessment, doing so can have serious business consequences,
such as fines or data breaches.

Symmetric and asymmetric

encryption
Previously, you learned these terms:

 Encryption: the process of converting data from a readable format to an

encoded format
 Public key infrastructure (PKI): an encryption framework that secures the
exchange of online information
 Cipher: an algorithm that encrypts information

All digital information deserves to be kept private, safe, and secure.

Encryption is one key to doing that! It is useful for transforming information
into a form that unintended recipients cannot understand. In this reading,
you’ll compare symmetric and asymmetric encryption and learn about some
well-known algorithms for each.

Types of encryption

There are two main types of encryption:

 Symmetric encryption is the use of a single secret key to exchange

information. Because it uses one key for encryption and decryption, the
sender and receiver must know the secret key to lock or unlock the cipher.
 Asymmetric encryption is the use of a public and private key pair for
encryption and decryption of data. It uses two separate keys: a public key and
a private key. The public key is used to encrypt data, and the private key
decrypts it. The private key is only given to users with authorized access.

The importance of key length

Ciphers are vulnerable to brute force attacks, which use a trial and error
process to discover private information. This tactic is the digital equivalent of
trying every number in a combination lock trying to find the right one. In
modern encryption, longer key lengths are considered to be more secure.
 Longer key lengths mean more possibilities that an attacker needs to try to
unlock a cipher.

One drawback to having long encryption keys is slower processing times.

Although short key lengths are generally less secure, they’re much faster to
compute. Providing fast data communication online while keeping
information safe is a delicate balancing act.

Approved algorithms

Many web applications use a combination of symmetric and asymmetric

encryption. This is how they balance user experience with safeguarding
information. As an analyst, you should be aware of the most widely-used
algorithms.

Symmetric algorithms

 Triple DES (3DES) is known as a block cipher because of the way it converts
plaintext into ciphertext in “blocks.” Its origins trace back to the Data
Encryption Standard (DES), which was developed in the early 1970s. DES was
one of the earliest symmetric encryption algorithms that generated 64-bit
keys, although only 56 bits are used for encryption. A bit is the smallest unit of
data measurement on a computer. As you might imagine, Triple DES generates
keys that are three times as long. Triple DES applies the DES algorithm three
times, using three different 56-bit keys. This results in an effective key length
of 168 bits. Despite the longer keys, many organizations are moving away
from using Triple DES due to limitations on the amount of data that can be
 encrypted. However, Triple DES is likely to remain in use for backwards
compatibility purposes.
 Advanced Encryption Standard (AES) is one of the most secure symmetric
algorithms today. AES generates keys that are 128, 192, or 256 bits.
Cryptographic keys of this size are considered to be safe from brute force
attacks. It’s estimated that brute forcing an AES 128-bit key could take a
modern computer billions of years!

Asymmetric algorithms

 Rivest Shamir Adleman (RSA) is named after its three creators who developed
it while at the Massachusetts Institute of Technology (MIT). RSA is one of the
first asymmetric encryption algorithms that produces a public and private key
pair. Asymmetric algorithms like RSA produce even longer key lengths. In
part, this is due to the fact that these functions are creating two keys. RSA key
sizes are 1,024, 2,048, or 4,096 bits. RSA is mainly used to protect highly
sensitive data.
 Digital Signature Algorithm (DSA) is a standard asymmetric algorithm that
was introduced by NIST in the early 1990s. DSA also generates key lengths of
2,048 bits. This algorithm is widely used today as a complement to RSA in
public key infrastructure.

Generating keys

These algorithms must be implemented when an organization chooses one to

protect their data. One way this is done is using OpenSSL, which is an open-
source command line tool that can be used to generate public and private
keys. OpenSSL is commonly used by computers to verify digital certificates
that are exchanged as part of public key infrastructure.

Note: OpenSSL is just one option. There are various others available that can
generate keys with any of these common algorithms.

In early 2014, OpenSSL disclosed a vulnerability, known as the Heartbleed

bug, that exposed sensitive data in the memory of websites and applications.
Although unpatched versions of OpenSSL are still available, the Heartbleed
bug was patched later that year (2014). Many businesses today use the secure
versions of OpenSSL to generate public and private keys, demonstrating the
importance of using up-to-date software.

Obscurity is not security

In the world of cryptography, a cipher must be proven to be unbreakable

before claiming that it is secure. According to Kerckhoff’s principle,
cryptography should be designed in such a way that all the details of an
algorithm—except for the private key—should be knowable without
sacrificing its security. For example, you can access all the details about how
AES encryption works online and yet it is still unbreakable.

Occasionally, organizations implement their own, custom encryption

algorithms. There have been instances where those secret cryptographic
systems have been quickly cracked after being made public.

Pro tip: A cryptographic system should not be considered secure if it requires

secrecy around how it works.
Encryption is everywhere

Companies use both symmetric and asymmetric encryption. They often work
as a team, balancing security with user experience.

For example, websites tend to use asymmetric encryption to secure small

blocks of data that are important. Usernames and passwords are often
secured with asymmetric encryption while processing login requests. Once a
user gains access, the rest of their web session often switches to using
symmetric encryption for its speed.

Using data encryption like this is increasingly required by law. Regulations

like the Federal Information Processing Standards (FIPS 140-3) and the
General Data Protection Regulation (GDPR) outline how data should be
collected, used, and handled. Achieving compliance with either regulation is
critical to demonstrating to business partners and governments that customer
data is handled responsibly.

Key takeaways

Knowing the basics of encryption is important for all security professionals.

Symmetric encryption relies on a single secret key to protect data. On the
other hand, asymmetric uses a public and private key pair. Their encryption
algorithms create different key sizes. Both types of encryption are used to
meet compliance regulations and protect data online.
Activity
overview
Previously, you learned about cryptography and how encryption and
decryption can be used to secure information online. You were also
introduced to the Caesar cipher, one of the earliest cryptographic algorithms
used to protect people’s privacy.

As a security analyst, it’s important that you understand the role of encryption
to secure data online and that you’re familiar with the right security controls
to do so.

In this lab activity, you’ll be guided through some basic cryptographic

activities using Linux commands to decrypt files and reveal hidden messages.

Scenario
In this scenario, all of the files in your home directory have been encrypted.
You’ll need to use Linux commands to break the Caesar cipher and decrypt the
files so that you can read the hidden messages they contain.

Here’s how you’ll do this task: First, you’ll explore the contents of the home
directory and read the contents of a file. Next, you’ll find a hidden file and
decrypt the Caesar cipher it contains. Finally, you’ll decrypt the encrypted
data file to recover your data and reveal the hidden message.

OK, it's time to decrypt some messages in Linux!

Note: The lab starts with you logged in as user analyst, with your home
directory, /home/analyst, as the current working directory.Disclaimer: For
optimal performance and compatibility, it is recommended to use
either Google Chrome or Mozilla Firefox browsers while accessing the labs.

Start your lab

You'll need to start the lab before you can access the materials. To do this,
click the green “Start Lab” button at the top of the screen.
After you click the Start Lab button, you will see a shell, where you will be
performing further steps in the lab. You should have a shell like this:

When you have completed all the tasks, refer to the End your Lab section that
follows the tasks for information on how to end your lab.

Task 1. Read the contents of a file

The lab starts in your home directory, /home/analyst, as the current working
directory.

In this task, you need to explore the contents of your home directory and read
the contents of a file to get further instructions.

1. Use the ls command to list the files in the current working directory.
The command to complete this step:

ls /home/analyst
Copied!
content_copy
Two files, Q1.encrypted and README.txt, and a subdirectory, caesar, are
listed:

Q1.encrypted README.txt caesar

The README.txt file contains an important message with instructions you
need to follow.

2. Use the cat command to list the contents of the README.txt file.
The command to complete this step:

cat README.txt
Copied!
content_copy
This will display the following output:

Hello,
All of your data has been encrypted. To recover your data, you will need to
solve a cipher. To get started look for a hidden file in the caesar subdirectory.
The message in the README.txt file advises that the caesar subdirectory
contains a hidden file.

In the next task, you’ll need to find the hidden file and solve the Caesar cipher
that protects it. The file contains instructions on how to recover your data.
Click Check my progress to verify that you have completed this task correctly.

Read the contents of a file

Check my progress

Task 2. Find a hidden file

In this task, you need to find a hidden file in your home directory and decrypt
the Caesar cipher it contains. This task will enable you to complete the next
task.

1. First, use the cd command to change to the caesar subdirectory of your

home directory:
cd caesar
Copied!
content_copy
2. Use the ls -a command to list all files, including hidden files, in your
home directory.
The command to complete this step:

ls -a
Copied!
content_copy
This will display the following output:
. .. .leftShift3
Hidden files in Linux can be identified by their name starting with a period (.).

3. Use the cat command to list the contents of the .leftShift3 file.
The command to complete this step:

cat .leftShift3
Copied!
content_copy
The message in the .leftShift3 file appears to be scrambled. This is because the
data has been encrypted using a Caesar cipher. This cipher can be solved by
shifting each alphabet character to the left or right by a fixed number of
spaces. In this example, the shift is three letters to the left. Thus "d" stands for
"a", and "e" stands for "b".

4. You can decrypt the Caesar cipher in the .leftshift3 file by using the
following command:
cat .leftShift3 | tr "d-za-cD-ZA-C" "a-zA-Z"
Copied!
content_copy
Note: The tr command translates text from one set of characters to another,
using a mapping. The first parameter to the tr command represents the input set
of characters, and the second represents the output set of characters. Hence, if
you provide parameters “abcd” and “pqrs”, and the input string to
the tr command is “ac”, the output string will be “pr".
This will display the following output:

In order to recover your files you will need to enter the following command:
openssl aes-256-cbc -pbkdf2 -a -d -in Q1.encrypted -out Q1.recovered -k
ettubrute
In this case, the command tr "d-za-cD-ZA-C" "a-zA-Z" translates all the
lowercase and uppercase letters in the alphabet back to their original position.
The first character set, indicated by "d-za-cD-ZA-C", is translated to the second
character set, which is "a-zA-Z".

Note: The output provides you with the command you need to solve the next
task!
You don’t need to copy the command revealed in the output. It will be provided
in the next task.
5. Now, return to your home directory before completing the next task:
cd ~
Copied!
content_copy
Click Check my progress to verify that you have completed this task correctly.

Find a hidden file

Check my progress

Task 3. Decrypt a file

Now that you have solved the Caesar cipher, in this task you need to use the
command revealed in .leftshift3 to decrypt a file and recover your data so you
can read the message it contains.

1. Use the exact command revealed in the previous task to decrypt the
encrypted file:
openssl aes-256-cbc -pbkdf2 -a -d -in Q1.encrypted -out Q1.recovered -k
ettubrute
Copied!
content_copy
Although you don't need to memorize this command, to help you better
understand the syntax used, let's break it down.

In this instance, the openssl command reverses the encryption of the file with
a secure symmetric cipher, as indicated by AES-256-CBC. The -pbkdf2 option
is used to add extra security to the key, and -a indicates the desired encoding
for the output. The -d indicates decrypting, while -in specifies the input file
and -out specifies the output file. The -k specifies the password, which in this
example is ettubrute.

2. Use the ls command to list the contents of your current working

directory again.
The command to complete this step:

ls
Copied!
content_copy
 The new file Q1.recovered in the directory listing is the decrypted file and
contains a message.

3. Use the cat command to list the contents of the Q1.recovered file.
The command to complete this step:

cat Q1.recovered
Copied!
content_copy
This will display the following output:

If you are able to read this, then you have successfully decrypted the classic
cipher text. You recovered the encryption key that was used to encrypt this
file. Great work!
Click Check my progress to verify that you have completed this task correctly.

Decrypt a file

Check my progress

Conclusion

Great work! You now have practical experience in using basic Linux Bash shell
commands to

 list hidden files,

 decrypt a Caesar cipher, and
 decrypt an encrypted file.
This is an important milestone on your journey towards understanding
encryption and decryption.

Exemplar: Decrypt an encrypted a

message
Activity overview

Previously, you learned about cryptography and how encryption and

decryption can be used to secure information online. You were also
introduced to the Caesar cipher, one of the earliest cryptographic algorithms
used to protect people’s privacy.

As a security analyst, it’s important that you understand the role of encryption
to secure data online and that you’re familiar with the right security controls
to do so.

In this lab activity, you’ll be guided through some basic cryptographic

activities using Linux commands to decrypt files and reveal hidden messages.

This exemplar is a walkthrough of the previous Qwiklab activity, including

detailed instructions and solutions. You may use this exemplar if you were
unable to complete the lab and/or you need extra guidance in competing lab
 tasks. You may also refer to this exemplar to prepare for the graded quiz in
this module.

Scenario

In this scenario, all of the files in your home directory have been encrypted.
You’ll need to use Linux commands to break the Caesar cipher and decrypt the
files so that you can read the hidden messages they contain.

Here’s how you’ll do this task: First, you’ll explore the contents of the home
directory and read the contents of a file. Next, you’ll find a hidden file and
decrypt the Caesar cipher it contains. Finally, you’ll decrypt the encrypted
data file to recover your data and reveal the hidden message.

OK, it's time to decrypt some messages in Linux!

Note: The lab starts with you logged in as user analyst, with your home
directory, /home/analyst, as the current working directory.

Task 1. Read the contents of a file

The lab starts in your home directory, /home/analyst, as the current working
directory.

In this task, you need to explore the contents of your home directory and read
the contents of a file to get further instructions.

1. Use the ls command to list the files in the current working directory.

The command to complete this step:

1
ls /home/analyst

Two files, Q1.encrypted and README.txt, and a subdirectory, caesar, are

listed:

1
Q1.encrypted README.txt caesar

The README.txt file contains an important message with instructions you

need to follow.

2. Use the cat command to list the contents of the README.txt file.

The command to complete this step:

1
cat README.txt

This will display the following output:

 2
All of your data has been encrypted. To recover your data, you will need to sol
ve a cipher. To get started look for a hidden file in the caesar subdirectory.

The message in the README.txt file advises that the caesar subdirectory
contains a hidden file.

In the next task, you’ll need to find the hidden file and solve the Caesar cipher
that protects it. The file contains instructions on how to recover your data.

Task 2. Find a hidden file

In this task, you need to find a hidden file in your home directory and decrypt
the Caesar cipher it contains. This task will enable you to complete the next
task.

1. First, use the cd command to change to the caesar subdirectory of your home
directory:
1
cd caesar
2. Use the ls -a command to list all files, including hidden files, in your home
directory.

The command to complete this step:

1
ls -a

This will display the following output:

1
. .. .leftShift3

Hidden files in Linux can be identified by their name starting with a period (.).

3. Use the cat command to list the contents of the .leftShift3 file.

The command to complete this step:

1
cat .leftShift3
The message in the .leftShift3 file appears to be scrambled. This is because
the data has been encrypted using a Caesar cipher. This cipher can be solved
by shifting each alphabet character to the left or right by a fixed number of
spaces. In this example, the shift is three letters to the left. Thus "d" stands for
"a", and "e" stands for "b".

4. You can decrypt the Caesar cipher in the .leftshift3 file by using the
following command:

1
cat .leftShift3 | tr "d-za-cD-ZA-C" "a-zA-Z"

Note: The tr command translates text from one set of characters to another,
using a mapping. The first parameter to the tr command represents the input
set of characters, and the second represents the output set of characters. Hence,
if you provide parameters “abcd” and “pqrs”, and the input string to
the tr command is “ac”, the output string will be “pr".

This will display the following output:

1
2
3
In order to recover your files you will need to enter the following command:
openssl aes-256-cbc -pbkdf2 -a -d -in Q1.encrypted -out Q1.recovered -k ettub
rute

In this case, the command tr "d-za-cD-ZA-C" "a-zA-Z" translates all the

lowercase and uppercase letters in the alphabet back to their original position.
The first character set, indicated by "d-za-cD-ZA-C", is translated to the
second character set, which is "a-zA-Z".

Note: The output provides you with the command you need to solve the next
task!

You don’t need to copy the command revealed in the output. It will be provided
in the next task.

5. Now, return to your home directory before completing the next task:

1
cd ~

Task 3. Decrypt a file

 Now that you have solved the Caesar cipher, in this task you need to use the
command revealed in .leftshift3 to decrypt a file and recover your data so you
can read the message it contains.

1. Use the exact command revealed in the previous task to decrypt the encrypted
file:
1
openssl aes-256-cbc -pbkdf2 -a -d -in Q1.encrypted -out Q1.recovered -k ettub
rute

Although you don't need to memorize this command, to help you better
understand the syntax used, let's break it down.

In this instance, the openssl command reverses the encryption of the file with
a secure symmetric cipher, as indicated by AES-256-CBC. The -pbkdf2 option
is used to add extra security to the key, and -a indicates the desired encoding
for the output. The -d indicates decrypting, while -in specifies the input file
and -out specifies the output file. The -k specifies the password, which in this
example is ettubrute.

2. Use the ls command to list the contents of your current working directory
again.

The command to complete this step:

1
 ls

The new file Q1.recovered in the directory listing is the decrypted file and
contains a message.

3. Use the cat command to list the contents of the Q1.recovered file.

The command to complete this step:

1
cat Q1.recovered

This will display the following output:

Conclusion

Great work! You now have practical experience in using basic Linux Bash shell
commands to

 list hidden files,

 decrypt a Caesar cipher, and

 decrypt an encrypted file.

This is an important milestone on your journey towards understanding
encryption and decryption.

The evolution of hash functions

Hash functions are important controls that are part of every company's
security strategy. Hashing is widely used for authentication and non-
repudiation, the concept that the authenticity of information can’t be denied.

Previously, you learned that hash functions are algorithms that produce a
code that can't be decrypted. Hash functions convert information into a
unique value that can then be used to determine its integrity. In this reading,
you’ll learn about the origins of hash functions and how they’ve changed over
time.

Origins of hashing
Hash functions have been around since the early days of computing. They
were originally created as a way to quickly search for data. Since the
beginning, these algorithms have been designed to represent data of any size
as small, fixed-size values, or digests. Using a hash table, which is a data
structure that's used to store and reference hash values, these small values
became a more secure and efficient way for computers to reference data.

One of the earliest hash functions is Message Digest 5, more commonly known
as MD5. Professor Ronald Rivest of the Massachusetts Institute of Technology
(MIT) developed MD5 in the early 1990s as a way to verify that a file sent over
a network matched its source file.

Whether it’s used to convert a single email or the source code of an

application, MD5 works by converting data into a 128-bit value. You might
recall that a bit is the smallest unit of data measurement on a computer. Bits
can either be a 0 or 1. In a computer, bits represent user input in a way that
computers can interpret. In a hash table, this appears as a string of 32
characters. Altering anything in the source file generates an entirely new hash
value.

Generally, the longer the hash value, the more secure it is. It wasn’t long after
MD5's creation that security practitioners discovered 128-bit digests resulted
in a major vulnerability.

Here is an example of how plaintext gets turned into hash values:

Hash collisions

One of the flaws in MD5 happens to be a characteristic of all hash functions.

Hash algorithms map any input, regardless of its length, into a fixed-size value
of letters and numbers. What’s the problem with that? Although there are an
infinite amount of possible inputs, there’s only a finite set of available outputs!

MD5 values are limited to 32 characters in length. Due to the limited output
size, the algorithm is considered to be vulnerable to hash collision, an
instance when different inputs produce the same hash value. Because hashes
are used for authentication, a hash collision is similar to copying someone’s
identity. Attackers can carry out collision attacks to fraudulently impersonate
authentic data.

Next-generation hashing

To avoid the risk of hash collisions, functions that generated longer values
were needed. MD5's shortcomings gave way to a new group of functions
known as the Secure Hashing Algorithms, or SHAs.

The National Institute of Standards and Technology (NIST) approves each of

these algorithms. Numbers besides each SHA function indicate the size of its
 hash value in bits. Except for SHA-1, which produces a 160-bit digest, these
algorithms are considered to be collision-resistant. However, that doesn’t
make them invulnerable to other exploits.

Five functions make up the SHA family of algorithms:

 SHA-1

 SHA-224

 SHA-256

 SHA-384

 SHA-512

Secure password storage

Passwords are typically stored in a database where they are mapped to a

username. The server receives a request for authentication that contains the
credentials supplied by the user. It then looks up the username in the
database and compares it with the password that was provided and verifies
that it matches before granting them access.

This is a safe system unless an attacker gains access to the user database. If
passwords are stored in plaintext, then an attacker can steal that information
and use it to access company resources. Hashing adds an additional layer of
security. Because hash values can't be reversed, an attacker would not be able
to steal someone's login credentials if they managed to gain access to the
database.
Rainbow tables

A rainbow table is a file of pre-generated hash values and their associated

plaintext. They’re like dictionaries of weak passwords. Attackers capable of
obtaining an organization’s password database can use a rainbow table to
compare them against all possible values.

Adding some “salt”

Functions with larger digests are less vulnerable to collision and rainbow
table attacks. But as you’re learning, no security control is perfect.

Salting is an additional safeguard that's used to strengthen hash functions. A

salt is a random string of characters that's added to data before it's hashed.
The additional characters produce a more unique hash value, making salted
data resilient to rainbow table attacks.

For example, a database containing passwords might have several hashed

entries for the password "password." If those passwords were all salted, each
entry would be completely different. That means an attacker using a rainbow
table would be unable to find matching values for "password" in the database.
For this reason, salting has become increasingly common when storing
passwords and other types of sensitive data. The length and uniqueness of a
salt is important. Similar to hash values, the longer and more complex a salt is,
the harder it is to crack.

Key takeaways

Security professionals often use hashing as a tool to validate the integrity of

program files, documents, and other types of data. Another way it’s used is to
reduce the chances of a data breach. As you’ve learned, not all hashing
functions provide the same level of protection. Rainbow table attacks are
more likely to work against algorithms that generate shorter keys, like MD5.
Many small- and medium-sized businesses still rely on MD5 to secure
sensitive data. Knowing about alternative algorithms and salting better
prepares you to make impactful security recommendations.

Activity overview
As a security analyst, you’ll need to implement security controls to protect
organizations against a range of threats.

That’s where hashing comes in. Previously, you learned that a hash function is
an algorithm that produces a code that can’t be decrypted. Hash functions are
used to uniquely identify the contents of a file so that you can check whether it
has been modified. This code provides a unique identifier known as a hash
value or digest.

For example, a malicious program may mimic an original program. If one code
line is different from the original program, it produces a different hash value.
Security teams can then identify the malicious program and work to mitigate
the risk.

Many tools are available to compare hashes for various scenarios. But for a
security analyst it’s important to know how to manually compare hashes.

In this lab activity, we’ll create hash values for two files and use Linux
commands to manually examine the differences.

Scenario

In this scenario, you need to investigate whether two files are identical or
different.
Here’s how you'll do this task: First, you’ll display the contents of two files
and create hashes for each file. Next, you’ll examine the hashes and compare
them.

Let’s hash some files!

Note: The lab starts with your user account, called analyst, already logged in to
the Bash shell. This means you can start the tasks as soon as you click the Start
Lab button.Disclaimer: For optimal performance and compatibility, it is
recommended to use either Google Chrome or Mozilla Firefox browsers
while accessing the labs.

Start your lab

You'll need to start the lab before you can access the materials. To do this,
click the green “Start Lab” button at the top of the screen.

After you click the Start Lab button, you will see a shell, where you will be
performing further steps in the lab. You should have a shell like this:
When you have completed all the tasks, refer to the End your Lab section that
follows the tasks for information on how to end your lab.

Task 1. Generate hashes for files

The lab starts in your home directory, /home/analyst, as the current working
directory. This directory contains two files file1.txt and file2.txt, which contain
same data.

In this task, you need to display the contents of each of these files. You’ll then
generate a hash value for each of these files and send the values to new files,
which you’ll use to examine the differences in these values later.

1. Use the ls command to list the contents of the directory.

The command to complete this step:

ls
Copied!
content_copy
Two files, file1.txt and file2.txt, are listed.

2. Use the cat command to display the contents of the file1.txt file:
cat file1.txt
Copied!
content_copy
Note: If you enter a command incorrectly and it fails to return to the command-
line prompt, you can press CTRL+C to stop the process and force the shell to
return to the command-line prompt.
3. Use the cat command to display the contents of the file2.txt file:
cat file2.txt
Copied!
content_copy
4. Review the output of the two file contents:
5. analyst@4fb6d613b6b0:-$ cat file1.txt
6. X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-
TEST-FILE!$H+H*
7. analyst@4fb6d613b6b0:-$ cat file2.txt
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-
TEST-FILE!$H+H*
Do the contents of the two files appear identical when you use the cat
command?
Yes
No
Submit
Answer: Yes. The contents of the two files appear identical when you use
the cat command to display the file contents.

Although the contents of both files appear identical when you use
the cat command, you need to generate the hash for each file to determine if
the files are actually different.

5. Use the sha256sum command to generate the hash of the file1.txt file:
sha256sum file1.txt
Copied!
content_copy
You now need to follow the same step for the file2.txt file.

6. Use the sha256sum command to generate the hash of the file2.txt file:
sha256sum file2.txt
Copied!
content_copy
7. Review the generated hashes of the contents of the two files:
8. analyst@4fb6d613b6b0:-$ sha256sum file1.txt
9. 131f95c51cc819465fa1797f6ccacf9d494aaaff46fa3eac73ae63ffbdfd82
67 file1.txt
10. analyst@4fb6d613b6b0:-$ sha256sum file2.txt
2558ba9a4cad1e69804ce03aa2a029526179a91a5e38cb723320e83af9
ca017b file2.txt
Do both files produce the same generated hash value?
Yes
No
Submit
Answer: No. The generated hash value for file1.txt is different from the
generated hash value for file2.txt, which indicates that the file contents are not
identical.

Click Check my progress to verify that you have completed this task correctly.

Generate hashes for files

Check my progress

Task 2. Compare hashes

In this task, you’ll write the hashes to two separate files and then compare
them to find the difference.

1. Use the sha256sum command to generate the hash of the file1.txt file,
and send the output to a new file called file1hash:
sha256sum file1.txt >> file1hash
Copied!
content_copy
You now need to complete the same step for the file2.txt file.
 2. Use the sha256sum command to generate the hash of the file2.txt file,
and send the output to a new file called file2hash:
sha256sum file2.txt >> file2hash
Copied!
content_copy
Now, you should have two hashes written to separate files. The first hash was
written to the file1hash file, and the second hash was written to
the file2hash file.

You can manually display and compare the differences.

3. Use the cat command to display the hash values in

the file1hash and file2hash files.
The command to complete this step:

cat file1hash
cat file2hash
Copied!
content_copy
4. Inspect the output and note the difference in the hash values.
Note: Although the content in file1.txt and file2.txt previously appeared
identical, the hashes written to the file1hash and file2hash files
are completely different.
Now, you can use the cmp command to compare the two files byte by byte. If a
difference is found, the command reports the byte and line number where the
first difference is found.
 5. Use the cmp command to highlight the differences in
the file1hash and file2hash files:
cmp file1hash file2hash
Copied!
content_copy
6. Review the output, which reports the first difference between the two
files:
analyst@4fb6d613b6b0:-$ cmp file1hash file2hash
file1hash file2hash differ: char1, line 1
Note: The output of the cmp command indicates that the hashes differ at the
first character in the first line.
Based on the hash values, is file1.txt different from file2.txt?
Yes
No
Submit
Answer: Yes, the contents of the two files are different because the hash
values of each file are different.

Click Check my progress to verify that you have completed this task correctly.

Compare hashes

Check my progress
 Conclusion

Great work!

You practiced how to

 compute hashes using sha256sum,

 display hashes using the cat command, and
 compare hashes using the cmp command.
These are valuable tools you can use to validate data integrity as you
contribute to the control of your organization’s security.

Exemplar: Create hash values

Activity overview

As a security analyst, you’ll need to implement security controls to protect

organizations against a range of threats.

That’s where hashing comes in. Previously, you learned that a hash function is
an algorithm that produces a code that can’t be decrypted. Hash functions are
used to uniquely identify the contents of a file so that you can check whether it
has been modified. This code provides a unique identifier known as a hash
value or digest.

For example, a malicious program may mimic an original program. If one code
line is different from the original program, it produces a different hash value.
Security teams can then identify the malicious program and work to mitigate
the risk.

Many tools are available to compare hashes for various scenarios. But for a
security analyst it’s important to know how to manually compare hashes.

In this lab activity, we’ll create hash values for two files and use Linux
commands to manually examine the differences.

This exemplar is a walkthrough of the previous Qwiklab activity, including

detailed instructions and solutions. You may use this exemplar if you were
unable to complete the lab and/or you need extra guidance in competing lab
tasks. You may also refer to this exemplar to prepare for the graded quiz in
this module.

Scenario

In this scenario, you need to investigate whether two files are identical or
different.

Here’s how you'll do this task: First, you’ll display the contents of two files
and create hashes for each file. Next, you’ll examine the hashes and compare
them.

Let’s hash some files!

 Note: The lab starts with your user account, called analyst, already logged in to
the Bash shell. This means you can start the tasks as soon as you click the Start
Lab button.

Task 1. Generate hashes for files

The lab starts in your home directory, /home/analyst, as the current working
directory. This directory contains two files file1.txt and file2.txt, which
contain same data.

In this task, you need to display the contents of each of these files. You’ll then
generate a hash value for each of these files and send the values to new files,
which you’ll use to examine the differences in these values later.

1. Use the ls command to list the contents of the directory.

The command to complete this step:

1
ls

Two files, file1.txt and file2.txt, are listed.

2. Use the cat command to display the contents of the file1.txt file:
Note: If you enter a command incorrectly and it fails to return to the command-
line prompt, you can press CTRL+C to stop the process and force the shell to
return to the command-line prompt.

3. Use the cat command to display the contents of the file2.txt file:

1
cat file2.txt

4. Review the output of the two file contents:

2
3
4
1
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-
FILE!$H+H*
analyst@4fb6d613b6b0:-$ cat file2.txt
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-
FILE!$H+H*
analyst@4fb6d613b6b0:-$ cat file1.txt
Do the contents of the two files appear identical when you use the cat
command?

Answer: Yes. The contents of the two files appear identical when you use
the cat command to display the file contents.

Although the contents of both files appear identical when you use
the cat command, you need to generate the hash for each file to determine if
the files are actually different.

5. Use the sha256sum command to generate the hash of the file1.txt file:

1
sha256sum file1.txt

You now need to follow the same step for the file2.txt file.

6. Use the sha256sum command to generate the hash of the file2.txt file:

1
sha256sum file2.txt

7. Review the generated hashes of the contents of the two files:

 1
2
3
4
analyst@4fb6d613b6b0:-$ sha256sum file1.txt
131f95c51cc819465fa1797f6ccacf9d494aaaff46fa3eac73ae63ffbdfd8267 file
1.txt
analyst@4fb6d613b6b0:-$ sha256sum file2.txt
2558ba9a4cad1e69804ce03aa2a029526179a91a5e38cb723320e83af9ca017
b file2.txt

Do both files produce the same generated hash value?

Answer: No. The generated hash value for file1.txt is different from the
generated hash value for file2.txt, which indicates that the file contents are
not identical.

Task 2. Compare hashes

In this task, you’ll write the hashes to two separate files and then compare
them to find the difference.

1. Use the sha256sum command to generate the hash of the file1.txt file, and
send the output to a new file called file1hash:
1
sha256sum file1.txt >> file1hash

You now need to complete the same step for the file2.txt file.

2. Use the sha256sum command to generate the hash of the file2.txt file, and
send the output to a new file called file2hash:

1
sha256sum file2.txt >> file2hash

Now, you should have two hashes written to separate files. The first hash was
written to the file1hash file, and the second hash was written to
the file2hash file.

You can manually display and compare the differences.

3. Use the cat command to display the hash values in

the file1hash and file2hash files.

The command to complete this step:

1
2
cat file1hash
cat file2hash

4. Inspect the output and note the difference in the hash values.

Note: Although the content in file1.txt and file2.txt previously appeared

identical, the hashes written to the file1hash and file2hash files
are completely different.

Now, you can use the cmp command to compare the two files byte by byte. If a
difference is found, the command reports the byte and line number where the
first difference is found.

5. Use the cmp command to highlight the differences in

the file1hash and file2hash files:

1
cmp file1hash file2hash

6. Review the output, which reports the first difference between the two files:

1
2
analyst@4fb6d613b6b0:-$ cmp file1hash file2hash
 file1hash file2hash differ: char1, line 1

Note: The output of the cmp command indicates that the hashes differ at the
first character in the first line.

Based on the hash values, is file1.txt different from file2.txt?

Answer: Yes, the contents of the two files are different because the hash
values of each file are different.

Conclusion

Great work!

You practiced how to

 compute hashes using sha256sum,

 display hashes using the cat command, and

 compare hashes using the cmp command.

These are valuable tools you can use to validate data integrity as you
contribute to the control of your organization’s security.
 The rise of SSO and MFA
Most companies help keep their data safely locked up behind authentication
systems. Usernames and passwords are the keys that unlock information for
most organizations. But are those credentials enough? Information security
often focuses on managing a user's access of, and authorization to,
information.

Previously, you learned about the three factors of authentication: knowledge,

ownership, and characteristic. Single sign-on (SSO) and multi-factor
authentication (MFA) are two technologies that have become popular for
implementing these authentication factors. In this reading, you’ll learn how
these technologies work and why companies are adopting them.

A better approach to authentication

Single sign-on (SSO) is a technology that combines several different logins

into one. More companies are turning to SSO as a solution to their
authentication needs for three reasons:

1. SSO improves the user experience by eliminating the number of usernames

and passwords people have to remember.

2. Companies can lower costs by streamlining how they manage connected

services.

3. SSO improves overall security by reducing the number of access points

attackers can target.
This technology became available in the mid-1990s as a way to combat
password fatigue, which refers to people’s tendency to reuse passwords across
services. Remembering many different passwords can be a challenge, but
using the same password repeatedly is a major security risk. SSO solves this
dilemma by shifting the burden of authentication away from the user.

How SSO works

SSO works by automating how trust is established between a user and a

service provider. Rather than placing the responsibility on an employee or
customer, SSO solutions use trusted third-parties to prove that a user is who
they claim to be. This is done through the exchange of encrypted access tokens
between the identity provider and the service provider.

Similar to other kinds of digital information, these access tokens are

exchanged using specific protocols. SSO implementations commonly rely on
two different authentication protocols: LDAP and SAML. LDAP, which stands
for Lightweight Directory Access Protocol, is mostly used to transmit
information on-premises; SAML, which stands for Security Assertion Markup
Language, is mostly used to transmit information off-premises, like in the
cloud.

Note: LDAP and SAML protocols are often used together.

Here's an example of how SSO can connect a user to multiple applications with
one access token:
Limitations of SSO

Usernames and passwords alone are not always the most secure way of
protecting sensitive information. SSO provides useful benefits, but there’s still
the risk associated with using one form of authentication. For example, a lost
or stolen password could expose information across multiple services.
Thankfully, there’s a solution to this problem.

MFA to the rescue

Multi-factor authentication (MFA) requires a user to verify their identity in

two or more ways to access a system or network. In a sense, MFA is similar to
using an ATM to withdraw money from your bank account. First, you insert a
debit card into the machine as one form of identification. Then, you enter your
PIN number as a second form of identification. Combined, both steps, or
factors, are used to verify your identity before authorizing you to access the
account.
 Strengthening authentication

MFA builds on the benefits of SSO. It works by having users prove that they
are who they claim to be. The user must provide two factors (2FA) or three
factors (3FA) to authenticate their identification. The MFA process asks users
to provide these proofs, such as:

 Something a user knows: most commonly a username and password

 Something a user has: normally received from a service provider, like a one-
time passcode (OTP) sent via SMS

 Something a user is: refers to physical characteristics of a user, like their

fingerprints or facial scans

Requiring multiple forms of identification is an effective security measure,

especially in cloud environments. It can be difficult for businesses in the cloud
to ensure that the users remotely accessing their systems are not threat
actors. MFA can reduce the risk of authenticating the wrong users by
requiring forms of identification that are difficult to imitate or brute force.

Key takeaways
 Implementing both SSO and MFA security controls improves security without
sacrificing the user experience. Relying on passwords alone is a serious
vulnerability. Implementing SSO means fewer points of entry, but that’s not
enough. Combining SSO and MFA can be an effective way to protect
information, so that users have a streamlined experience while unauthorized
people are kept away from important information.

Identity and access management

Security is more than simply combining processes and technologies to protect
assets. Instead, security is about ensuring that these processes and
technologies are creating a secure environment that supports a defense
strategy. A key to doing this is implementing two fundamental security
principles that limit access to organizational resources:

 The principle of least privilege in which a user is only granted the minimum
level of access and authorization required to complete a task or function.
 Separation of duties, which is the principle that users should not be given
levels of authorization that would allow them to misuse a system.

Both principles typically support each other. For example, according to least
privilege, a person who needs permission to approve purchases from the IT
department shouldn't have the permission to approve purchases from every
department. Likewise, according to separation of duties, the person who can
approve purchases from the IT department should be different from the
person who can input new purchases.

In other words, least privilege limits the access that an individual receives,
while separation of duties divides responsibilities among multiple people to
prevent any one person from having too much control.

Note: Separation of duties is sometimes referred to as segregation of duties.

Previously, you learned about the authentication, authorization, and

accounting (AAA) framework. Many businesses used this model to implement
these two security principles and manage user access. In this reading, you’ll
learn about the other major framework for managing user access, identity and
access management (IAM). You will learn about the similarities between AAA
and IAM and how they're commonly implemented.

Identity and access management (IAM)

As organizations become more reliant on technology, regulatory agencies

have put more pressure on them to demonstrate that they’re doing everything
they can to prevent threats. Identity and access management (IAM) is a
collection of processes and technologies that helps organizations manage
digital identities in their environment. Both AAA and IAM systems are
designed to authenticate users, determine their access privileges, and track
their activities within a system.
 Either model used by your organization is more than a single, clearly defined
system. They each consist of a collection of security controls that ensure the
right user is granted access to the right resources at the right time and for the
right reasons. Each of those four factors is determined by your organization's
policies and processes.

Note: A user can either be a person, a device, or software.

Authenticating users

To ensure the right user is attempting to access a resource requires some

form of proof that the user is who they claim to be. In a video on
authentication controls, you learned that there are a few factors that can be
used to authenticate a user:

 Knowledge, or something the user knows

 Ownership, or something the user possesses
 Characteristic, or something the user is

Authentication is mainly verified with login credentials. Single sign-on (SSO),

a technology that combines several different logins into one, and multi-factor
authentication (MFA), a security measure that requires a user to verify their
identity in two or more ways to access a system or network, are other tools
that organizations use to authenticate individuals and systems.

Pro tip: Another way to remember this authentication model is: something
you know, something you have, and something you are.

User provisioning
 Back-end systems need to be able to verify whether the information provided
by a user is accurate. To accomplish this, users must be properly provisioned.
User provisioning is the process of creating and maintaining a user's digital
identity. For example, a college might create a new user account when a new
instructor is hired. The new account will be configured to provide access to
instructor-only resources while they are teaching. Security analysts are
routinely involved with provisioning users and their access privileges.

Pro tip: Another role analysts have in IAM is to deprovision users. This is an
important practice that removes a user's access rights when they should no
longer have them.

Granting authorization

If the right user has been authenticated, the network should ensure the right
resources are made available. There are three common frameworks that
organizations use to handle this step of IAM:

 Mandatory access control (MAC)

 Discretionary access control (DAC)
 Role-based access control (RBAC)
Mandatory Access Control (MAC)

MAC is the strictest of the three frameworks. Authorization in this model is

based on a strict need-to-know basis. Access to information must be granted
manually by a central authority or system administrator. For example, MAC is
commonly applied in law enforcement, military, and other government
agencies where users must request access through a chain of command. MAC
is also known as non-discretionary control because access isn’t given at the
discretion of the data owner.
Discretionary Access Control (DAC)

DAC is typically applied when a data owner decides appropriate levels of

access. One example of DAC is when the owner of a Google Drive folder shares
editor, viewer, or commentor access with someone else.
Role-Based Access Control (RBAC)

RBAC is used when authorization is determined by a user's role within an

organization. For example, a user in the marketing department may have
access to user analytics but not network administration.

Access control technologies

Users often experience authentication and authorization as a single, seamless

experience. In large part, that’s due to access control technologies that are
configured to work together. These tools offer the speed and automation
needed by administrators to monitor and modify access rights. They also
decrease errors and potential risks.
An organization's IT department sometimes develops and maintains
customized access control technologies on their own. A typical IAM or AAA
system consists of a user directory, a set of tools for managing data in that
directory, an authorization system, and an auditing system. Some
organizations create custom systems to tailor them to their security needs.
However, building an in-house solution comes at a steep cost of time and
other resources.

Instead, many organizations opt to license third-party solutions that offer a

suite of tools that enable them to quickly secure their information systems.
Keep in mind, security is about more than combining a bunch of tools. It’s
always important to configure these technologies so they can help to provide
a secure environment.

Key takeaways

Controlling access requires a collection of systems and tools. IAM and AAA are
common frameworks for implementing least privilege and separation of
duties. As a security analyst, you might be responsible for user provisioning
and collaborating with other IAM or AAA teams. Having familiarity with these
models is valuable for helping organizations achieve their security objectives.
They each ensure that the right user is granted access to the right resources at
the right time and for the right reasons.

Resources for more information

The identity and access management industry is growing at a rapid pace. As

with other domains in security, it’s important to stay informed.
 IDPro© is a professional organization dedicated to sharing essential IAM
industry knowledge.

Vulnerabilities of CI/CD
Protect Your Software Pipeline: CI/CD Security

Building upon your understanding of vulnerability management, this reading

focuses on a critical area of modern software development: CI/CD pipelines.
Just as organizations regularly assess their systems for weaknesses, CI/CD
pipelines, which automate the software release process, also require rigorous
vulnerability management. This reading will explore the specific
vulnerabilities within CI/CD pipelines and how to apply vulnerability
management principles to secure them, ensuring a robust and safe software
delivery process.

Continuous Integration, Continuous Delivery, and Continuous Deployment

(CI/CD) pipelines are essential for modern software development. They help
teams deliver software faster and more efficiently. But, like any powerful tool,
CI/CD pipelines can also introduce security risks if not properly managed.
In this guide, you’ll explore common vulnerabilities in CI/CD pipelines. You’ll
learn why securing these pipelines is crucial and how to integrate security
practices to build a robust and secure software development process. By
understanding these vulnerabilities and implementing best practices, you can
transform your CI/CD pipeline into a key component of your cybersecurity
strategy.

What is CI/CD and Why Does it Matter?

CI/CD automates the entire software release process, from code creation to
deployment. This automation is what enables modern development teams to
be agile and respond quickly to user needs. Let's break down the key parts:

Continuous Integration (CI): Building a Solid Foundation

Continuous Integration (CI) is all about frequently merging code changes

from different developers into a central location. This triggers automated
processes like building the software and running tests. CI catches problems
through an automated process: every time code is integrated, the system
automatically builds and tests it. This immediate feedback loop reveals
integration problems as soon as they occur. CI helps catch integration
problems early, leading to higher quality code. Think of it as the foundation of
the pipeline.

Continuous Delivery (CD): Ready to Release

Continuous Delivery means your code is always ready to be released to

users. After passing automated tests, code is automatically deployed to a
 staging environment (a practice environment) or prepared for final release.
Typically, a manual approval step is still needed before going live to
production, which provides a control point.

Continuous Deployment (CD): Fully Automated Releases

Continuous Deployment automates the entire release process. Changes that

pass all automated checks are automatically deployed directly to the live
production environment, with no manual approval. This is all about speed and
efficiency.

Security Benefits of Continuous Delivery and Deployment

You might be wondering how security fits into all this automation. The good
news is that Continuous Delivery and Deployment can actually enhance
security. CD allows you to build security checks right into your deployment
pipeline. This ensures that only thoroughly vetted software versions are
released.

These automated security checks can include:

 Dynamic Application Security Testing (DAST): Automated tests that find

vulnerabilities in running applications in realistic staging environments.
 Security Compliance Checks: Automated checks that ensure software meets
your organization’s security rules and policies.
 Infrastructure Security Validations: Checks that make sure the systems
hosting your software are secure.

Why a secure CI/CD Pipelines is Non-Negotiable

To grasp the power of CI/CD is vital. Pipeline protection is not optional; it is

essential. Consider these points:

 Secure Automation: CI/CD automates repetitive tasks: building, testing,

deploying. When automation is implemented securely, this reduces errors
from manual work, speeds processes, and importantly, reduces human errors
that create vulnerabilities. However, insecure automation automates the
introduction of vulnerabilities at scale.
 Improved Code Quality Via Security Checks: Automated tests in CI/CD
rigorously check code before release. Crucially, this includes automated
security tests. This leads to fewer bugs and security weaknesses in final
software, but only if security tests integrate effectively within the pipeline.
 Faster Time to Market for Security Updates: CI/CD accelerates releases.
This enables faster delivery of new features, bug fixes, and security updates,
improving response time to both user needs and security threats. This rapid
deployment of security updates is a significant security advantage of a well-
secured CI/CD pipeline.
 Enhanced Collaboration and Feedback with Safety Focus: CI/CD
encourages collaboration between development, security, testing, and
operations teams. Quick feedback loops aid identification and resolution of
 vulnerabilities early in development. This collaborative environment is
essential to build security into the pipeline and address vulnerabilities
proactively.
 Reduced Risk: Frequent, smaller releases, a result of CI/CD, are less risky
than large, infrequent releases. If issues arise (including security issues),
pinpointing and fixing the problem becomes easier. This also applies to
security vulnerabilities; smaller, frequent releases limit the potential impact
of a security flaw introduced in any single release, provided security
monitoring and testing remain continuous.

In essence, CI/CD is the engine of modern agile software development. It

allows for reliable, efficient, and responsive software delivery. However, an
unsecured CI/CD pipeline can become a major entry point for vulnerabilities.

Common CI/CD Pipeline Vulnerabilities: What to Watch Out For

Knowing the benefits of CI/CD is only half the battle. You also need to
understand the potential security weaknesses. Here are some common
vulnerabilities to be aware of:

Insecure Dependencies: Risks from Third-Party Code

CI/CD pipelines often use many third-party libraries and components. If these
components have known vulnerabilities (Common Vulnerabilities and
Exposures, or CVEs), those vulnerabilities can be unknowingly added to your
application during the automated build process.

Action Step: Regularly scan and update your dependencies. Make sure you’re
using secure versions of all external components.
Misconfigured Permissions: Controlling Access

Weak access controls in CI/CD tools, code repositories, and related systems
are a significant vulnerability. Unauthorized access can allow attackers to
modify code, pipeline configurations, or inject malicious content.

Action Step: Implement strong access management using Role-Based Access

Control (RBAC). Ensure only authorized individuals can access and change
critical pipeline elements.

Lack of Automated Security Testing: Missing Critical Checks

Failing to include automated security testing in your CI/CD pipeline is a

serious error. Without tools like SAST and DAST, you are almost guaranteed to
release software full of vulnerabilities that will go undetected until after it's
live, leading to significantly higher costs and effort to fix..

Action Step: Integrate automated security testing (SAST and DAST) into your
CI/CD pipeline. This should be a core part of your secure CI/CD strategy.

Exposed Secrets: Protecting Sensitive Information

Hardcoding sensitive data like API keys, passwords, and tokens directly into
code or pipeline settings is a serious security mistake. If exposed, these
secrets can lead to major security breaches.

Action Step: Never hardcode secrets. Use secure vaults or dedicated secrets
management tools to store and manage sensitive information. Enforce this
practice across your team.
 Unsecured Build Environments: Protecting the Pipeline Infrastructure

The CI/CD environment itself (the servers and systems that run your pipeline)
needs to be secure. If this environment is vulnerable, attackers can
compromise it to alter builds, inject malicious code, or steal sensitive data.

Action Step: Harden your build environments. Use secure containers or

virtual machines to minimize the risk of a compromised pipeline.

Building a Secure CI/CD Pipeline: Defense in Depth

To proactively address these vulnerabilities, a layered security approach is

key. Here are essential best practices for your CI/CD security strategy:

 Integrate Security from the Start: Embrace DevSecOps: Adopt a

DevSecOps mindset. This means building security into every stage of
development, from planning to deployment and beyond. This naturally
includes embedding security checks into your CI/CD pipeline.
 Implement Strong Access Controls: Use strict permission policies based on
the principle of least privilege. Only grant necessary access to code, pipeline
settings, and deployment configurations. Use tools like Multi-Factor
Authentication (MFA) and Role-Based Access Control (RBAC) to secure your
CI/CD environment.
 Automate Security Testing Everywhere: Make automated security scans
and tests a fundamental part of your build and deployment process. Tools like
SAST, Software Composition Analysis (SCA), and DAST are not optional extras
– they are essential for a secure CI/CD pipeline so you can catch
vulnerabilities early.
 Keep Dependencies Updated: Maintain a current inventory of all third-party
dependencies, libraries, and CI/CD plugins. Regularly update these
components to patch security vulnerabilities (CVEs). Tools like Dependabot
and Snyk can automate dependency management.
 Secure Secrets Management: Never hardcode sensitive information in your
code or pipeline configurations. Require the use of dedicated secrets
management tools like HashiCorp Vault or AWS Secrets Manager. Securely
store, access, and rotate secrets throughout the CI/CD process.

Conclusion: Secure CI/CD – Secure Software

By proactively addressing these common vulnerabilities and implementing

security best practices in your CI/CD pipeline, your software teams can build
and release applications with a significantly stronger security posture. A
secure CI/CD foundation is crucial for minimizing security risks and building a
more resilient overall security strategy for your applications and
infrastructure.

Key takeaways

The essence of securing your CI/CD pipeline is to bring robust security to your
software release process, enabling engineers to develop, test, and deploy code
with confidence and resilience against threats. By building security into your
CI/CD, you empower your team to release features, improvements, and
critical security updates rapidly and reliably, ensuring software is not only
delivered efficiently but also with the highest level of security, proactively
protecting your organization and your customers.
 Resources:

1. DevSecOps Using GitHub Actions: Building Secure CI/CD Pipelines.

https://medium.com/@rahulsharan512/devsecops-using-github-actions-
building-secure-ci-cd-pipelines-5b6d59acab32
2. 6 Steps for Success with CI/CD Securing Hardening.
https://spectralops.io/blog/ci-cd-security-hardening/
3. GitLab CI/CD - Hands-On Lab: Securing Scanning.
https://handbook.gitlab.com/handbook/customer-success/professional-
services-engineering/education-services/gitlabcicdhandsonlab9/
4. How can you stay current with the latest problem solving techniques in Cloud
Computing as a manager. https://www.linkedin.com/advice/1/how-can-you-
stay-current-latest-problem-solving-msk5e