Module 1: Network Security Introduction

 Network Security Models

o Closed network Model
o Open Network Model
o CIA Model
 Vulnerabilities, Threats and Attacks
o Types of Vulnerabilities
o Technological Weakness
o Configuration Weakness
o Security Policy Weekness
o Types of Threats
 Basic Types of Attacks
o Reconnaissance
o Access
o DoS and DdoS
o Worms, Viruses and Trojan Horses
o Password Attacks
o Man in the Middle
o Social Engineering
 Managing Network Security
o Vulnerability Scanning
o Vulnerability Analysis
o Security Policy Identification

Explain with examples, Vulnerability, Threat and attacks.

Vulnerability:

Vulnerabilities in network security can be summed up as the “soft spots” that are present in
every network. The vulnerabilities are present in the network and individual devices that
make up the network.
  Networks are typically plagued by one or all of three
primary vulnerabilities or weaknesses:

i. Technology weaknesses

Technological Weaknesses Computer and network technologies have intrinsic security

weaknesses. These include TCP/IP protocol weaknesses, operating system weaknesses, and
network equipment weaknesses.

Weakness Description

TCP/IP protocol HTTP, FTP, and ICMP are inherently insecure. Simple Network
weaknesses Management Protocol (SNMP), Simple Mail Transfer Protocol
(SMTP), and SYN floods are related to the inherently insecure
structure upon which TCP was designed.

Operating The UNIX, Linux, Macintosh, Windows NT, 9x, 2K, XP, and OS/2
system Operating systems all have security problems that must be addressed.
weaknesses

ii. Configuration weaknesses.

Configuration Weaknesses Network administrators or network engineers need to learn what

the configuration weaknesses are and correctly configure their computing and network
devices to compensate.

Weakness How the Weakness Is Exploited

Unsecured user accounts User account information might be transmitted insecurely

across the network, exposing usernames and passwords to
snoopers.

System accounts with This common problem is the result ofpoorly selected and
 Weakness How the Weakness Is Exploited

easily guessed passwords easily guessed user passwords

iii. Security policy weaknesses

Security Policy Weaknesses Security policy weaknesses can create unforeseen security
threats. The network can pose security risks to the network if users do not follow the security
policy.

Weakness How the Weakness Is Exploited

Lack of written An unwritten policy cannot be consistently applied or enforced.

Security policy. Political battles and turf wars can make it difficult to implement a
Politics consistent security policy.

Lack of continuity Poorly chosen, easily cracked, or default passwords can allow
unauthorized access to the network.

Threats

The people eager, willing, and qualified to take advantage of each security weakness, and
they continually search for new exploits and weaknesses.

There are four primary classes of threats to network security

i. Unstructured threats:

 a. Unstructured threats consist of mostly inexperienced individuals using easily available
hacking tools such as shell scripts and password crackers.
 b. Even unstructured threats that are only executed with the intent of testing and challenging
a hacker’s skills can still do serious damage to a company.
ii. Structured threats:
a. Structured threats come from hackers who are more highly motivated and technically
competent.
b. These people know system vulnerabilities and can understand and develop exploit code
and scripts.
c. They understand, develop, and use sophisticated hacking techniques to penetrate
unsuspecting businesses. These groups are often involved with the major fraud and theft
cases reported to law enforcement agencies.
iii. External threats:

a. External threats can arise from individuals or organizations working outside of a company.
They do not have authorized access to the computer systems or network.
b. They work their way into a network mainly from the Internet or dialup access servers.
iv. Internal threats:

a. Internal threats occur when someone has authorized access to the network with either an
account on a server or physical access to the network.
b. According to the FBI, internal access and misuse account for 60 percent to 80 percent of
reported incidents.
Attacks

The threats use a variety of tools, scripts, and programs to launch attacks against networks
and network devices. Typically, the network devices under attack are the endpoints, such as
servers and desktops.

Four primary classes of attacks exist:

i. Reconnaissance

Reconnaissance is the unauthorized discovery and mapping of systems, services, or

vulnerabilities. It is also known as information gathering and, in most cases, it precedes an
actual access or denial-of-service (DoS) attack.

ii. Access

System access is the ability for an unauthorized intruder to gain access to a device for which
the intruder does not have an account or a password. Entering or accessing systems to which
one does not have authority to access usually involves running a hack, script, or tool that
exploits a known vulnerability of the system or application being attacked.

iii. Denial of service

Denial of service implies that an attacker disables or corrupts networks, systems, or services
with the intent to deny services to intended users. DoS attacks involve either crashing the
system or slowing it down to the point that it is unusable.

iv. Worms, viruses, and Trojan horses

a. A computer virus is a program that is loaded on your computer without your knowledge
and runs without your permission. A virus is designed to reproduce itself through legitimate
processes in computer programs and operating systems; therefore, a virus requires a host in
order to replicate.

b. The term, Trojan horse, is usually used to refer to a non-replicating malicious program
which is the main characteristic that distinguishes it from a virus. Trojan horses often appear
as e-mail attachments with enticing names that induce people to open them.

c. A worm is a small piece of software that uses security holes within networks to replicate
itself. The worm scans the network for another computer that has a specific security hole. It
copies itself to the new machine exploiting the security hole, and then starts replicating from
that system as well.

Vulnerabilities, Exploits, and Threats at a Glance

There are more devices connected to the internet than ever before. This is music to
an attacker's ears, as they make good use of machines like printers and cameras
which were never designed to ward off sophisticated invasions. It's led companies
and individuals alike to rethink how safe their networks are.

As the amount of these incidents rises, so does the way we need to classify the
dangers they pose to businesses and consumers alike. Three of the most common
terms thrown around when discussing cyber risks are vulnerabilities, exploits, and
threats. Here’s a breakdown of each and what they mean in terms of risk:

What Is a Vulnerability?
Mistakes happen, even in the process of building and coding technology. What’s left
behind from these mistakes is commonly referred to as a bug. While bugs aren’t
inherently harmful (except to the potential performance of the technology), many
can be taken advantage of by nefarious actors—these are known as vulnerabilities.
Vulnerabilities can be leveraged to force software to act in ways it’s not intended to,
such as gleaning information about the current security defenses in place.

Once a bug is determined to be a vulnerability, it is registered by MITRE as a  CVE,

or common vulnerability or exposure, and assigned a Common Vulnerability Scoring
System (CVSS) score to reflect the potential risk it could introduce to your
organization. This central listing of CVEs serves as a reference point
for vulnerability scanners.

Generally speaking, a vulnerability scanner will scan and compare your environment
against a vulnerability database, or a list of known vulnerabilities; the more
information the scanner has, the more accurate its performance. Once a team has a
report of the vulnerabilities, developers can use penetration testing as a means to
see where the weaknesses are, so the problem can be fixed and future mistakes
can be avoided. When employing frequent and consistent scanning, you'll start to
see common threads between the vulnerabilities for a better understanding of the
full system. Learn more about vulnerability management and scanning here.

Security Vulnerability Examples

A Security Vulnerability is a weakness, flaw, or error found within a security system

that has the potential to be leveraged by a threat agent in order to compromise a
secure network.

There are a number of Security Vulnerabilities, but some common examples are: 

 Broken Authentication: When authentication credentials are compromised, user

sessions and identities can be hijacked by malicious actors to pose as the original user. 
 SQL Injection: As one of the most prevalent security vulnerabilities, SQL injections
attempt to gain access to database content via malicious code injection. A successful
SQL injection can allow attackers to steal sensitive data, spoof identities, and participate
in a collection of other harmful activities.
 Cross-Site Scripting: Much like an SQL Injection, a Cross-site scripting (XSS) attack
also injects malicious code into a website. However, a Cross-site scripting attack targets
website users, rather than the actual website itself, which puts sensitive user information
at risk of theft.
 Cross-Site Request Forgery: A Cross-Site Request Forgery (CSRF) attack aims to
trick an authenticated user into performing an action that they do not intend to do. This,
paired with social engineering, can deceive users into accidentally providing a malicious
actor with personal data. 
 Security Misconfiguration: Any component of a security system that can be leveraged
by attackers due to a configuration error can be considered a “Security
Misconfiguration.” 
What Is an Exploit?
Exploitation is the next step in an attacker's playbook after finding a vulnerability.
Exploits are the means through which a vulnerability can be leveraged for malicious
activity by hackers; these include pieces of software, sequences of commands, or
even open-source exploit kits. 

What Is a Threat?

A threat refers to the hypothetical event wherein an attacker uses the vulnerability.

The threat itself will normally have an exploit involved, as it's a common way
hackers will make their move. A hacker may use multiple exploits at the same time
after assessing what will bring the most reward. While nothing disastrous may have
happened yet at this stage, it can give a security team or individual insight into
whether or not an action plan needs to be made regarding specific security
measures.

While it may seem like you’re constantly hearing about a new attack or cyber threat
in the world, these terms can help give further context to the stages and dangers
that security professionals deal with on a daily basis. So, what can you do to lower
your overall risk? For a  proactive approach, scan your environment for
vulnerabilities with a vulnerability management tool. To stay responsive to unwanted
activity, Security Information and Event Management (SIEM) is a systematic
process that can make it easier to control what's happening on your network. SIEM
tools can help companies set up strong, proactive defenses that work to fend off
threats, exploits, and vulnerabilities to keep their environment safe.

What is Vulnerability Management and Scanning?

Vulnerability management is the process of identifying, evaluating, treating, and

reporting on security vulnerabilities in systems and the software that runs on them.
This, implemented alongside with other security tactics, is vital for organizations to
prioritize possible threats and minimizing their "attack surface."

Security vulnerabilities, in turn, refer to technological weaknesses that allow

attackers to compromise a product and the information it holds. This process needs
to be performed continuously in order to keep up with new systems being added to
networks, changes that are made to systems, and the discovery of new
vulnerabilities over time.
Vulnerability management software can help automate this process. They’ll use
a vulnerability scanner  and sometimes endpoint agents to inventory a variety of
systems on a network and find vulnerabilities on them. Once vulnerabilities are
identified, the risk they pose needs to be evaluated in different contexts so
decisions can be made about how to best treat them. For example, vulnerability
validation can be an effective way to contextualize the real severity of a
vulnerability.

What is the difference between Vulnerability

Management and Vulnerability Assessment?

Generally, a Vulnerability Assessment  is a portion of the complete Vulnerability

Management system. Organizations will likely run multiple Vulnerability
Assessments to get more information on their Vulnerability Management action
plan.

The vulnerability management process can be broken

down into the following four steps:

 1) Identifying Vulnerabilities
 2) Evaluating Vulnerabilities
 3) Treating Vulnerabilities
 4) Reporting Vulnerabilities 
Step 1: Identifying Vulnerabilities

At the heart of a typical vulnerability management solution  is a vulnerability scanner.

The scan consists of four stages:

 Scan network-accessible systems by pinging them or sending them TCP/UDP packets

 Identify open ports and services running on scanned systems
 If possible, remotely log in to systems to gather detailed system information
 Correlate system information with known vulnerabilities

Vulnerability scanners are able to identify a variety of systems running on a

network, such as laptops and desktops, virtual and physical servers, databases,
firewalls, switches, printers, etc. Identified systems are probed for different
attributes: operating system, open ports, installed software, user accounts, file
system structure, system configurations, and more. This information is then used to
associate known vulnerabilities to scanned systems. In order to perform this
association, vulnerability scanners will use a vulnerability database that contains a
list of publicly known vulnerabilities.

Properly configuring vulnerability scans is an essential component of a vulnerability

management solution. Vulnerability scanners can sometimes disrupt the networks
and systems that they scan. If available network bandwidth becomes very limited
during an organization’s peak hours, then vulnerability scans should be scheduled
to run during off hours.

If some systems on a network become unstable or behave erratically when

scanned, they might need to be excluded from vulnerability scans, or the scans may
need to be fine-tuned to be less disruptive. Adaptive scanning  is a new approach to
further automating and streamlining vulnerability scans based on changes in a
network. For example, when a new system connects to a network for the first time, a
vulnerability scanner will scan just that system as soon as possible instead of
waiting for a weekly or monthly scan to start scanning that entire network.

Vulnerability scanners aren’t the only way to gather system vulnerability data
anymore, though. Endpoint agents allow vulnerability management solutions to
continuously gather vulnerability data from systems without performing network
scans. This helps organizations maintain up-to-date system vulnerability data
whether or not, for example, employees’ laptops are connected to the organization’s
network or an employee’s home network.

Regardless of how a vulnerability management solution gathers this data, it can be

used to create reports, metrics, and dashboards for a variety of audiences.

Step 2: Evaluating Vulnerabilities

After vulnerabilities are identified, they need to be evaluated so the risks posed by
them are dealt with appropriately and in accordance with an organization’s risk
management strategy. Vulnerability management solutions will provide different risk
ratings and scores for vulnerabilities, such as Common Vulnerability Scoring
System (CVSS) scores. These scores are helpful in telling organizations which
vulnerabilities they should focus on first, but the true risk posed by any given
vulnerability depends on some other factors beyond these out-of-the-box risk ratings
and scores.

Here are some examples of additional factors to consider when evaluating

vulnerabilities:

 Is this vulnerability a true or false positive?

 Could someone directly exploit this vulnerability from the Internet?
 How difficult is it to exploit this vulnerability?
 Is there known, published exploit code for this vulnerability?
 What would be the impact to the business if this vulnerability were exploited?
  Are there any other security controls in place that reduce the likelihood and/or impact of
this vulnerability being exploited?
 How old is the vulnerability/how long has it been on the network?

Like any security tool, vulnerability scanners aren’t perfect. Their vulnerability
detection false-positive rates, while low, are still greater than zero. Performing
vulnerability validation with penetration testing tools  and techniques helps weed out
false-positives so organizations can focus their attention on dealing with real
vulnerabilities. The results of vulnerability validation exercises or full-blown
penetration tests can often be an eye-opening experience for organizations that
thought they were secure enough or that the vulnerability wasn’t that risky.

Step 3: Treating Vulnerabilities

Once a vulnerability has been validated and deemed a risk, the next step is
prioritizing how to treat that vulnerability with original stakeholders to the business
or network. There are different ways to treat vulnerabilities, including:

 Remediation: Fully fixing or patching a vulnerability so it can’t be exploited. This is the

ideal treatment option that organizations strive for.
 Mitigation: Lessening the likelihood and/or impact of a vulnerability being exploited.
This is sometimes necessary when a proper fix or patch isn’t yet available for an
identified vulnerability. This option should ideally be used to buy time for an organization
to eventually remediate a vulnerability.
 Acceptance: Taking no action to fix or otherwise lessen the likelihood/impact of a
vulnerability being exploited. This is typically justified when a vulnerability is deemed a
low risk, and the cost of fixing the vulnerability is substantially greater than the cost
incurred by an organization if the vulnerability were to be exploited.

Vulnerability management solutions provide recommended remediation techniques

for vulnerabilities.  Occasionally a remediation recommendation isn’t the optimal
way to remediate a vulnerability; in those cases, the right remediation approach
needs to be determined by an organization’s security team, system owners, and
system administrators. Remediation can be as simple as applying a readily-
available software patch or as complex as replacing a fleet of physical servers
across an organization’s network.

When remediation activities are completed, it’s best to run another vulnerability
scan to confirm that the vulnerability has been fully resolved.

However, not all vulnerabilities need to be fixed. For example, if an organization’s

vulnerability scanner has identified vulnerabilities in Adobe Flash Player on their
computers, but they completely disabled Adobe Flash Player from being used in
web browsers and other client applications, then those vulnerabilities could be
considered sufficiently mitigated by a compensating control.

Attacks at 2 AM? We’ll handle it.

MDR with Active Response will detect and immediately stop threats on your behalf, whenever
they happen.
LEARN MORE
 

Step 4: Reporting vulnerabilities

Performing regular and continuous vulnerability assessments  enables organizations

to understand the speed and efficiency of their vulnerability management program
over time. Vulnerability management solutions typically have different options for
exporting and visualizing vulnerability scan data with a variety of customizable
reports and dashboards. Not only does this help IT teams easily understand which
remediation techniques will help them fix the most vulnerabilities with the least
amount of effort, or help security teams monitor vulnerability trends over time in
different parts of their network, but it also helps support organizations’ compliance
and regulatory requirements .

Staying Ahead of Attackers through Vulnerability Management

Threats and attackers are constantly changing, just as organizations are constantly
adding new mobile devices, cloud services, networks, and applications to their
environments. With every change comes the risk that a new hole has been opened
in your network, allowing attackers to slip in and walk out with your crown jewels.

Every time you get a new affiliate partner, employee, client or customer, you open
up your organization to new opportunities, but you’re also exposing it to new
threats. Protecting your organization from these threats requires a vulnerability
management solution that can keep up with and adapt to all of these changes.
Without that, attackers will always be one step ahead.

What is a vulnerability management program

framework?

Massive breaches have caused many companies to pursue stronger, more

proactive measures for managing vulnerabilities in their environments. Yet, as
corporate infrastructures have become more complex—encompassing the cloud and
spanning vast attack surfaces—businesses have found it more difficult to achieve
complete visibility into the rapidly proliferating vulnerabilities across their
ecosystems. Capitalizing on the opportunity, cybercriminals have learned how to
exploit chains of weaknesses in systems, applications, and people.

Vulnerability management programs address today’s modern cybersecurity

challenges by instituting a comprehensive and continuous process for identifying,
classifying, remediating, and mitigating vulnerabilities before attackers can take
advantage of them. At the heart of these vulnerability management programs is
often a vulnerability scanner that automatically assesses and understands risk
across an entire infrastructure, generating easy-to-understand reports that help
businesses properly and rapidly prioritize the vulnerabilities they must remediate or
mitigate.

The four steps of a vulnerability management program

A vulnerability scanner automates the vulnerability process, typically breaking it

down into the following four steps. It’s important to note that a good vulnerability
management process should continually scan for vulnerabilities as they are
introduced into the environment, as circumstances can quickly change.

1. Identifying vulnerabilities 

The first and most essential step in any vulnerability management process, of
course, is to bring to light all of the vulnerabilities that may exist across your
environment. A vulnerability scanner goes about this by scanning the full range of
accessible systems that exist—from laptops, desktops, and servers on to
databases, firewalls, switches, printers, and beyond.

From there, the vulnerability scanner identifies any open ports and services that are
running on those systems, logging in to those systems and gathering detailed
information where possible before correlating the information it obtains with known
vulnerabilities. This insight can be used to create reports, metrics, and dashboards
for a variety of audiences.

2. Evaluating vulnerabilities

Once you’ve identified all the vulnerabilities across your environment, you’ll need to
evaluate them in order to appropriately deal with the risks they pose according to
your organization’s risk management strategy. Different vulnerability management
solutions use different risk ratings and scores for vulnerabilities, but one commonly
referenced framework for new programs is the Common Vulnerability Scoring
System (CVSS).
Vulnerability scores can help organizations determine how to prioritize the
vulnerabilities they’ve discovered, it’s important to also consider other factors to
form a complete understanding of the true risk posed by any given vulnerability. It’s
also worth noting that vulnerability scanners can generate false positives in rare
instances, thus underscoring the necessity of including other considerations in
addition to risk scores at this stage of the process.

3. Treating vulnerabilities 

After you’ve prioritized the vulnerabilities that you’ve found, it’s important to
promptly treat them in collaboration with your original business or network
stakeholders. Depending on the vulnerability in question, treatment usually
proceeds according to one of the following three paths:

 Remediation: Fully fixing or patching a vulnerability so that it cannot be exploited, which

is usually the most preferable option whenever possible.
 Mitigation. When remediation can’t be accomplished, an organization may choose the
next best option of reducing the likelihood that a vulnerability will be exploited by
implementing compensating controls. This solution should be temporary, buying time for
an organization to eventually remediate the vulnerability.
 Acceptance. If a vulnerability is deemed low-risk or the cost of remediating it is much
greater than it would be if it were exploited, an organization may choose simply to take
no action to fix the vulnerability.

When determining specific treatment strategies, it is best for an organization’s

security team, system owners, and system administrators to come together and
determine the right remediation approach—whether that’s issuing a software patch
or refreshing a fleet of physical servers. Once remediation is considered complete,
it’s wise to run another vulnerability scan to make sure that the vulnerability has, in
fact, been effectively remediated or mitigated.

4. Reporting vulnerabilities 

Improving the speed and accuracy with which you detect and treat vulnerabilities is
essential to managing the risk that they represent, which is why many organizations
continually assess the efficacy of their vulnerability management program. They can
take advantage of the visual reporting capabilities found in vulnerability
management solutions for this purpose. Armed with the insights needed, IT teams
can identify which remediation techniques will help them fix the most vulnerabilities
with the least amount of effort. Security teams, for their part, can use this reporting
to monitor vulnerability trends over time and communicate their risk reduction
progress to leadership. Ideal solutions will include integrations with IT ticketing
systems and patching tools to accelerate the process of sharing information
between teams. This helps customers make meaningful progress toward reducing
their risk. Businesses can also use these assessments to fulfill their compliance and
regulatory requirements.
Four tips for a better vulnerability management
program

 Conduct comprehensive scans. While many businesses once found it sufficient to

scan servers and desktop computers on the enterprise network, today’s complex and
rapidly evolving IT environment requires a comprehensive approach. Your vulnerability
management program should provide visibility into your entire attack surface, including
the cloud, and automatically detect devices as they connect to your network for the first
time.
 Continually assess your vulnerabilities. Infrastructures and applications can change
on a daily and even hourly basis. For this reason, you must continually scan your
environment to make sure that you identify new vulnerabilities as early as possible.
Many vulnerability management solutions include endpoint agents and other integrations
that can provide you with a real-time view of vulnerabilities across your environment.
 Accelerate your processes. Introducing automation into the vulnerability management
process is essential to properly managing the modern risks your business faces at scale.
Human decisions play a critical role in every vulnerability management program, but
automation can help streamline the repetitive work that is done before and following
these key decision points.
 Address weaknesses in people, too. Vulnerabilities are not limited to technology; they
exist in the human element within an organization as well. Security teams must
collaborate with IT operations and application development groups to more quickly
identify and remediate vulnerabilities of all kinds. Meanwhile, user education and
simulations can increase your organization’s resilience to phishing and other social-
engineering attacks.

Businesses face growing risks as the attack surface continues to expand, increasing
the number of vulnerabilities for hackers to exploit. Vulnerability management
programs give companies a framework for managing these risks at scale, detecting
vulnerabilities across the entire environment with greater speed. Meanwhile,
analytics help organizations continually optimize the techniques they use for
remediation. With a strong vulnerability management program in place, businesses
can better address the risks they face not only today but well into the future.

What is patch management?

Patch management is the process of distributing and applying updates to software.

These patches are often necessary to correct errors (also referred to as
“vulnerabilities” or “bugs”) in the software. 

Common areas that will need patches include operating systems, applications, and
embedded systems (like network equipment). When a vulnerability is found after the
release of a piece of software, a patch can be used to fix it. Doing so helps ensure
that assets in your environment are not susceptible to exploitation. 

Why do we need patch management? 

Patch management is important for the following key reasons:

 Security: Patch management fixes vulnerabilities on your software and

applications that are susceptible to cyber-attacks, helping your organization
reduce its security risk. 

 System uptime: Patch management ensures your software and applications are

kept up-to-date and run smoothly, supporting system uptime.  

 Compliance: With the continued rise in cyber-attacks, organizations are often

required by regulatory bodies to maintain a certain level of compliance. Patch
management is a necessary piece of adhering to compliance standards. 

 Feature improvements: Patch management can go beyond software bug fixes

to also include feature/functionality updates. Patches can be critical to ensuring
that you have the latest and greatest that a product has to offer. 

How your organization benefits from an efficient patch

management program

Your company can benefit from patch management in a variety of ways:

 A more secure environment: When you’re regularly patching vulnerabilities,

you’re helping to manage and reduce the risk that exists in your environment.
This helps protect your organization from potential security breaches.

 Happy customers: If your organization sells a product or service that requires

customers to use your technology, you know how important it is that the
technology actually works. Patch management is the process of fixing software
bugs, which helps keep your systems up and running. 

 No unnecessary fines: If your organization is not patching and, therefore, not

meeting compliance standards, you could be hit with some monetary fines from
regulatory bodies. Successful patch management ensures that you are in
compliance. 
  Continued product innovation: You can implement patches to update your
technology with improved features and functionality. This can provide your
organization with a way to deploy your latest innovations to your software at
scale. 
The patch management process

It would be a poor strategy to just install new patches the second they become
available for all assets in your organization's inventory without considering the
impact. Instead, a more strategic approach should be taken. Patch management
should be implemented with a detailed, organizational process that is both cost-
effective and security-focused.  

Key steps to the patch management process include:

 Develop an up-to-date inventory of all your production systems: Whether

this be on a quarterly or monthly basis, this is the only way to truly monitor what
assets exist in your ecosystem. Through diligent asset management, you’ll have
an informed view of operating systems, version types, and IP addresses that
exist, along with their geographic locations and organizational “owners.” As a
general rule, the more frequently you maintain your asset inventory, the more
informed you're going to be.

 Devise a plan for standardizing systems and operating systems to the

same version type: Although difficult to execute on, standardizing your asset
inventory makes patching faster and more efficient. You’ll want to standardize
your assets down to a manageable number so that you can accelerate your
remediation process as new patches are released. This will help save both you
and technical teams time spent remediating.

 Make a list of all security controls that are in place within your
organization: Keep track of your firewalls, antivirus, and vulnerability
management tool. You’ll want to know where these are sitting, what they’re
protecting, and which assets are associated with them. 

 Compare reported vulnerabilities against your inventory: Using your

vulnerability management tool to assess which vulnerabilities exist for which
assets in your ecosystem is going to help you understand your security risk as an
organization. 

 Classify the risk: Through vulnerability management tools you can easily

manage which assets you consider to be critical to your organization and,
therefore, prioritize what needs to be remediated accordingly.

 TEST! Apply the patches to a representative sample of assets in your lab

environment. Stress test the machines to ensure that the patches will not cause
 issues in your production environment.

 Apply the patches: Once you’ve prioritized what needs to be remediated first,

start patching to actually reduce the risk in your environment. More advanced
vulnerability management tools also offer the ability to automate the time-
consuming parts of the patching process. Consider rolling the patches out to
batches of assets; although you already tested in your lab environment (you did
do that right!?) there may still be unexpected results in production. Dip a few toes
in before jumping in all the way to make there won’t be any widespread issues.

 Track your progress: Reassess your assets to ensure patching was

successful. 
Patch management best practices

Some best practices to keep in mind when implementing patch management

include: 

 Set clear expectations and hold teams accountable: Leveraging

organizational agreements, such as service-level agreements, can keep teams in
check, and ensure that the work of reducing risk is actually being done.

 Work collaboratively with technical teams to ensure a common

language: Security teams often refer to software errors as a “risk,” whereas
IT/DevOps teams may use the term “patch.” Making sure that everyone is on the
same page and recognizes the importance of patching is key to a successful
patch management process. 

 Establish a disaster recovery process: In case your patch management

process does fail and causes issues, it’s always a good idea to have a backup
plan.  
Attacks at 2 AM? We’ll handle it.
MDR with Active Response will detect and immediately stop threats on your behalf,
whenever they happen.
LEARN MORE
 
Embedding patch management into your vulnerability
management efforts

Patch management is a vital part of every vulnerability management program.

However, having a consistent approach to patch management doesn’t always mean
slapping a fix on everything in sight. When a vulnerability is identified, you
essentially have three options:
  Install a patch for the vulnerability, if available, to fix the issue.

 Implement compensating controls so the vulnerability is mitigated without being

fully patched. This route is common when a proper fix or patch is not yet
available, and can be used to buy time before eventual remediation.

 Accept the risk posed by that vulnerability and do nothing.

It’s up to organizations to decide which option is best for them in specific situations,
though patching is the ideal treatment to ultimately strive for.

The terms “patch management” and “vulnerability management” are sometimes

used interchangeably, but it is important to understand the difference. Though both
strategies aim to mitigate risk, patch management (the process of managing
software updates) is limited in scope. To gain a deeper understanding of your
environment and make informed, impactful decisions, you need to move to a more
holistic approach through vulnerability management. Vulnerability management  is a
continuous process of identifying, prioritizing, remediating, and reporting on security
vulnerabilities in systems and the software that runs on them.

Patch management is a critical component of vulnerability management, but it’s just

one piece of the puzzle. To successfully embed patch management into your
vulnerability management program , the following steps should be implemented:

 Establish asset management. Your ability to reduce risk is only as good as the
visibility you have into your environment. An asset management solution helps
you gain a full understanding of the assets you have and the vulnerabilities
associated with each asset. With that knowledge, you are equipped to prioritize
vulnerabilities, remediate issues, and communicate effectively with stakeholders.
 Prioritize vulnerabilities. With limited time and resources and an ever-changing
threat landscape, it’s unrealistic to think that you can fix every vulnerability as
soon as it appears. Consequently, prioritization is one of the most critical aspects
of vulnerability management.
 Remediate vulnerabilities to reduce risk. Identifying and prioritizing
vulnerabilities is important, but you’re not actually reducing risk unless you’re
remediating the issues.
 Measure the success of your vulnerability management program. No matter
how many fancy features a vulnerability management solution has, it’s only worth
the investment if it meets your organization’s unique needs and adds value for
you and your team. To determine if you’re achieving a good ROI—and justify the
purchase to senior leadership—you’ll have to determine how to measure
success.
 Develop partnerships and support. When something goes wrong, you want to
know you have a team of people you can rely on to help troubleshoot.
What is Incident Response?

When a security team detects a threat, it’s essential organizations are ready for
what comes next. That requires having a tightly coordinated incident response plan
(IRP) and sequence of actions and events assigned to specific stakeholders on a
dedicated incident response team. Some businesses may have their own in-house
team, some may outsource their incident response services , while others might take
a hybrid approach where they outsource technical analysis but manage the rest of
the IRP in-house. Either way, this team should have trained and planned for these
incident response events well before any trouble rears its head. 

A well-coordinated incident response effort should always include:

 High-level incident management and coordination

 Technical analysis of the incident
 Incident scoping to determine who or what was affected
 Crisis communications to make sure information is released in a
coordinated and beneficial manner
 Legal response to determine any implications and prepare any needed
response or action
 Remediation and mitigation recommendations and actions to ensure a
smooth recovery

Organization-Wide Preparation

An organization’s incident response team should include people in positions beyond

security and IT. Stakeholders from legal, corporate communications, human
resources, and more should also be involved in the preparation and execution of
any incident response activity. 

Preparation is key  to allow for fast action when minutes matter. It’s not ideal to wait
until a situation becomes a full-fledged escalated incident to start chasing down and
educating stakeholders. Major players should know their responsibilities well ahead
of time so that they only need the signal to jump into action. To help ensure team
members are trained and empowered enough to take the right actions, at the right
time, teams should conduct non-technical tabletop exercises and full breach
simulations to run through the technical and non-technical processes. 

Know Your Key Players

When preparing for incident response, having the right people on the team is
crucial. Every business has its own unique needs, but it’s recommended for
organizations to identify specific individuals or teams for the following core
functions: 

 Incident management: This central role requires extensive technical knowledge

and prior experience in management and incident response. The person in this
role acts as an overall project manager to oversee technical task completion, as
well as information gathering for all involved stakeholders.
 Enterprise incident investigation: This is where the challenges of working at
an enterprise can vary from smaller counterparts. A large breach at a large
organization requires leveraging technologies to assist in forensics across hosts
(even remote ones) so that the team can find indicators of compromise, as well
as potential scope, as quickly as possible.
 Technical analysis: These roles require technical know-how, and it's best to
have analysts on the team who specialize in specific areas, such as malware
analysis, forensics analysis, event log analysis, and network analysis. Any
information these analysts find should be shared with the rest of the incident
response team.
 Incident scoping: What was the extent of the breach? That's a crucial question
any incident response team will need to know. The answer to this question may
change over the course of the incident response and investigation, especially as
technical analysis continues.
 Crisis communications: Sharing the findings of the investigation, as well as the
scope and potential outcomes, will need to happen both internally and externally.
An experienced crisis communications team should communicate the right
details to the right audiences. Their responsibilities may include breach
notifications, regulatory notifications, employee and/or victim notifications, and
press briefings if needed.
 Legal, human resources, and regulatory concerns: If a breach has
any regulatory or compliance considerations, it’s important to have someone on
the team with knowledge of how to navigate disclosure requirements or work with
law enforcement groups, such as a government representative. For teams that
do not have in-house expertise for these requirements, specialized legal
expertise on retainer is a worthwhile investment.
 Executive decision making: Any breach can potentially affect an organization's
public image and financial standing, which is why executive leadership should
always be involved. There will be crucial decision points over the course of an
incident response and investigation, and the team will need executive input on
how to proceed at these crucial junctures.
 Reporting and remediation: While working on incident response, it is important
to document everything. With this information, teams should be able to piece
together an entire story for the breach: what the attackers did, when and how
they did it, and what they managed to compromise. This will make it possible to
create a detailed response plan for remediation and mitigation recommendations
 to recover from the breach, and hopefully help the organization defend against
any future attacks that are similar in nature.
The Post-Mortem

After successfully responding to an incident, it's not time to rest just yet. The
incident response team should conduct a post-mortem to learn from the experience
—both to fine tune their incident response program specifically, and also to retune
their security program overall. What worked, what didn't work, and what could work
better or faster? There's no better teacher than experience, so it’ll be important to
glean as many lessons as possible from responding to a real incident.

What is an Incident Response Plan?

An incident response plan delineates what steps need to be taken, and by whom,
when a breach or security crisis occurs in an organization. A robust response plan
should empower teams to leap into action and mitigate damage as quickly as
possible. Emergency responders go through regular training simulations and
process checks, so when a situation arises they know how to act almost by muscle
memory. Information security teams would be wise to follow their example: When an
emergency occurs, you don’t want to waste time figuring out incident response
processes and procedures while precious minutes are ticking away. Having a plan
in place becomes paramount.

No one enjoys a crisis, but when it comes to incident response it pays to be

prepared. Minutes count when a network has been infiltrated or data has been
breached, and waiting to figure out processes in the heat of the moment will likely
result in confusion, and worse still, slower overall response times to the incident
itself.

To prevent this from happening to your organization, your incident response team
should have a carefully mapped incident response plan, rehearsed regularly for a
variety of possible scenarios with all stakeholders included across a variety of roles.
After all, when a security incident occurs, it’s not just technical teams that need to
act; non-technical resources—such as legal and communications—as well as
outside parties will need to be involved, especially if you partner with a security
service provider.

What’s In a Robust Incident Response Plan?

There’s a great deal of groundwork that can be done ahead of time to reduce
complexity and risk during an emergency. An incident response plan should include:

 Buy-in from key organizational stakeholders: When a crisis hits, your team

needs to know they have the support from key stakeholders to act quickly. Make
sure C-level executives and other stakeholders fully buy in to the response plan,
give it their support, and empower the incident response team to act quickly and
confidently during a crisis.
 Clearly defined roles, responsibilities, and processes: The last thing your
team needs is to be figuring out who owns what and trying to track that person
down. Every element of incident response, from the technical to the non-
technical, should have a named stakeholder attached to it with clear
responsibilities outlined. People in these roles should have the expertise to carry
out what’s expected of them (this is not the time to test your most junior team
members). In addition, each incident response role should know exactly what
processes they’re accountable for and what’s expected of them when an incident
occurs, from determining the initial scope of the breach all the way to crisis
communications. If there’s any ambiguity in the plan about who owns what, it
may well be forgotten during a crisis.  
 Technologies and partnerships to enable quick action: When running your
incident response drills, make sure you have every tool in the toolbox you need
to respond quickly and effectively. You will likely find some areas have large
gaps, and others have some wiggle room to improve; where possible, make sure
you have the internal technologies and tools available to your teams to do their
jobs efficiently, making the most of automation where possible.

The key here is “quick.” If you don’t have the internal expertise or resources to
conduct a quick response, or your toolset isn’t giving you the information as quickly
as you need it, then you may want to look into external incident response
services to help address these gaps and speed up your incident response times.
(Make sure to include this external team in any drills you conduct!)

Attacks at 2 AM? We’ll handle it.

MDR with Active Response will detect and immediately stop threats on your behalf,
whenever they happen.
LEARN MORE
 
External Incident Response Services

If you need some support with your incident response plan, external providers can
help address strategic and tactical gaps by:

 Developing robust security programs: If you’re unsure whether your incident

detection program covers all possible contingencies relevant to your
 organization, an incident response service can help you improve your readiness
to incidents and breaches.
 Conducting tabletop exercises: Put your internal incident response team
through their paces with threat simulation exercises conducted by an outside
service to verify your team’s readiness.
 Conducting compromise and/or breach readiness assessments: An external
incident response team can assess the current state of your organization’s
environment and security processes, and identify any potential risks or gaps.
 Providing immediate breach remediation: If you suspect you’re being
breached and need immediate help, an external incident response service can
jump into action to help stop further damage.
 Offering incident response retainers: A retainer with an incident response
service makes sure that your teams are as aligned as possible and that the
external team is ready to go should the worst occur. Many retainers will include
several of the services named above, and they will often guarantee a certain
service level agreement on their response times.

It may sound repetitive, but the worst time to prepare for a breach really is after one
has occurred. Having a robust incident response plan in place—and ensuring it has
been communicated to all stakeholders—is the best way to prepare for this worst-
case scenario.  

What is Threat Detection?

Threat detection is the practice of analyzing the entirety of a security ecosystem to

identify any malicious activity that could compromise the network. If a threat is
detected, then mitigation efforts must be enacted to properly neutralize the threat
before it can exploit any present vulnerabilities.

Getting breached is a nightmare scenario, and most organizations that prioritize

their information will put smart people and technologies to work as a defensive
barrier against anyone who might try to cause trouble. But security is an
ongoing process—not a guarantee.

Within the context of an organization's security program, the concept of "threat

detection" is multifaceted. Even the best security programs must plan for worst-case
scenarios, when someone or something has slipped past their defensive and
preventative technologies and becomes a threat.
When it comes to detecting and mitigating threats, speed is crucial. Security
programs must be able to detect threats quickly and efficiently so attackers don’t
have enough time to root around in sensitive data. A business’s defensive programs
can ideally stop a majority of threats, because often they've been seen before—
meaning they should know how to fight them. These threats are considered "known"
threats. However, there are additional “unknown” threats that an organization aims
to detect. This means the organization hasn't encountered them before, perhaps
because the attacker is using brand-new methods or technologies.

Known threats can sometimes slip past even the best defensive measures, which is
why most security organizations actively look for both known and unknown threats
in their environment. So how can an organization try to detect both known and
unknown threats?

There are several methods available in the defender's arsenal that can help:

Leveraging Threat Intelligence

Threat intelligence is a way of looking at signature data from previously seen

attacks and comparing it to enterprise data to identify threats. This makes it
particularly effective at detecting known threats, but not unknown. Threat
intelligence is frequently used to great effect in Security Information and Event
Management (SIEM), antivirus, Intrusion Detection System (IDS), and web proxy
technologies.

Analyzing User and Attacker Behavior Analytics

With user behavior analytics, an organization is able to gain a baseline

understanding of what normal behavior for an employee would be: what kind of data
they access, what times they log on, and where they are physically located, for
example. That way, a sudden outlier in behavior—such as a 2 a.m. logon in
Shanghai from someone who usually works from 9 to 5 in New York and doesn’t
travel for business—stands out as unusual behavior and something a security
analyst may need to investigate.

With attacker behavior analytics, there's no "baseline" of activity to compare

information to; instead, small, seemingly unrelated activities detected on the
network over time may in fact be breadcrumbs of activity that an attacker leaves
behind. It takes both technology and the human mind to put these pieces together,
but they can help form a picture of what an attacker may be up to within an
organization's network.

Setting Intruder Traps

Some targets are just too tempting for an attacker to pass up. Security teams know
this, so they set traps in hopes that an attacker will take the bait. Within the context
of an organization's network, an intruder trap could include a honeypot target that
may seem to house network services—especially appealing to an attacker, or
“honey credentials” that appear to have user privileges an attacker would need in
order to gain access to sensitive systems or data. When an attacker goes after this
bait, it triggers an alert so the security team know there is suspicious activity in the
network that should be investigated. Learn more about the different types of
deception technology.

Conducting Threat Hunts

Instead of waiting for a threat to appear in the organization's network, a threat hunt
enables security analysts to actively go out into their own network, endpoints, and
security technology to look for threats or attackers that may be lurking as-yet
undetected. This is an advanced technique generally performed by veteran security
and threat analysts.

Ideally, a well-developed security threat detection program should include all of the
above tactics, amongst others, to monitor the security of the organization's
employees, data, and critical assets.

 
Threat Detection Requires a Two-Pronged Approach

Threat detection requires both a human element, as well as a technical element.

The human element includes security analysts who analyze trends, patterns in data,
behaviors, and reports, as well as those who can determine if anomalous data
indicates a potential threat or a false alarm.

But threat detection technology also plays a key part in the detection process.

There's no magic bullet in threat detection—no single tool that will do the job.
Instead, a combination of tools acts as a net across the entirely of an organization's
network, from end to end, to try and capture threats before they become a serious
problem.

A robust threat detection program should employ:

 Security event threat detection technology to aggregate data from events

across the network, including authentication, network access, and logs from
critical systems.
 Network threat detection technology to understand traffic patterns on the
network and monitor traffic within and between trusted networks, as well as to the
internet.
  Endpoint threat detection technology to provide detailed information about
possibly malicious events on user machines, as well as any behavioral or
forensic information to aid in investigating threats.

By employing a combination of these defensive methods, you’ll be increasing your

chances of detecting and mitigating a threat quickly and efficiently. Security is a
continuous process, and nothing is guaranteed. It’ll be up to you and the resources
and processes you put in place to keep your business as secure as possible.