Disaster Recovery plan: Disaster recovery plan is also called as business continuity plan or business process continuity plan.
DRP: DRP stands for Disaster Recovery Planning should include information security, asset security, and financial security plans.
As part of disaster recovery, it is important to have a location
from which the recovery of a failed site can take place. This location
is known as a backup site. In the event of a disaster, your site is
recreated at the specified backup site and made available. Once the
failed site is recovered, the backup site will be reverted to its
previous status.
There are three different types of backup sites:
1. Cold backup sites
2. Warm backup sites
3. Hot backup sites
1. Cold site: Here the bare minimums, such as space and
furniture are available. Everything else need to be procured. The delay
going to a fully operational site could be very large in this case
2. Warm site: Here, most of the hardware is in place, and
probably you need to recover the site from off-site backup, and
configure. The site could be restored in a reasonable amount of time.
3. Hot site: A facility designed to provide immediate
availability in the event of a system or network failure. All the
systems are appropriately configured and working. Only thing that is
required is the restoration of latest backup.
Note that onsite backup is not a back up site.
Backup concepts: It is recommended to store the backup tapes
in a secure, physically distant location. This would take care of
unforeseen disasters like natural disasters, fire, or theft. It is also
important that the backup tapes are regularly verified for proper
recovery in a test server, even though recovery is not really required
at that time. Otherwise, it may so happen that you find a backup tape
corrupt when it is really required. The backup policy identifies the
methods used to archive electronic and paper file systems. This policy
works in conjunction with the information retention and storage
policies.
A properly managed tape backups should include the following:
Regular backups according to a pre-determined plan
Verifying the backup tapes for integrity
Labeling tapes properly for easy and unique identification
Storing tapes securely at off-site location
Destroying data on old tapes before disposing off the same
There are primarily three types of backups:
1. Full backup: Here all the data gets backed up. It usually
involves huge amounts of data for large systems, and may take hours to
complete. A full backup is preferred instead of incremental or
differential backups where it is feasible. However, when there is large
amount of data, full backup is done once in a while and incremental or
differential backups are done in between. A backup plan is usually put
in place prior to taking backup of data.
2. Differential backup: A differential backup includes all
the data that has changed since last full backup. The "differential
backup" that was taken earlier (after the "full backup" but before the
current "differential backup") becomes redundant. This is because all
changed data since last "full backup" gets backed up again.
3. Incremental backup: It includes all the data changed since
last incremental backup. Note that for data restoration the full backup
and all incremental backup tapes since last full backup are required.
The archive bit is set after each incremental backup. Incremental backup
is useful for backing up large amounts of data, as it backs up only the
changes files since previous incremental backup.
The risk management process can make the
unmanageable manageable, and can allow the project manager to operate on
what seems to be a disadvantage and turn it into an advantage. Let’s
see how:
1. Risk identification
It is not possible to solve a risk if you do not know it. There are many ways to identify risk.
One way is through brainstorming, a methodology which allows a group to examine a problem.
Another method is that of individual interviews. It consists of
finding people with relevant experience, so that it is possible to
gather information that will help the project manager identify the risk
and find a possible solution.
Imagining the current project and thinking about the many factors
that can go wrong is another technique. What can you do if a key team
member is sick? What can you do if the material does not arrive within
the defined deadline? Etc.
An aid in this phase is also to read the reports of similar past
projects, verifying the presence of any problems encountered during the
path, and see how these have been solved.
2. Risk analysis
The next step is to determine the likelihood that each of these risks will occur. This information should also be included in the risk register.
When evaluating the risks of a project, it is possible to proactively
address the situation. For example, potential discussions can be
avoided, regulatory problems can be solved, new legislation must be
known, etc.
Analyzing the risks is certainly difficult. There is never a limit to the information that can be collected in this sense.
Moreover, risks must be analyzed based on qualitative and
quantitative analyzes. This means, that you determine the risk factor
based on how it will potentially affect the project through a variety of
metrics.
3. Risk prioritization
Not all risks have the same level of severity. It is
therefore necessary to assess each risk in order to know which
resources will be gathered to resolve it, when and if it occurs.
Some risks will be more acceptable, others may even risk to completely stop the project, making the situation quite serious.
Having a long list of risks can be daunting, but the project manager can manage them simply by classifying the risks as high, medium or low.
With this perspective, the project manager can then start planning how and when these risks will be addressed.
Some risks require immediate attention; these are the risks that can derail the project.
Other risks are important, they probably won’t threaten the success of the project, but will delay it.
Then, there are those risks that have little or no impact on the program and the overall project budget.
Some of these low priority risks could be important, but not enough
to be urgently addressed. Indeed, they could be somehow ignored and also
time could delete them and improve the situation.
4. Assign an owner to the risk
All the hard work of identifying and assessing risks is useless unless the project manager assigns someone to oversee the risk.
Who is the person responsible for that risk that, if this were to happen, would take charge of its resolution?
This decision, in general, is up to the project manager who knows the
level of experience and training of each team member and is therefore
able to assess the most suitable person to face a particular risk.
It is certainly important to identify the risks, but if these are not
managed by a person in charge, the work will have been completely
useless and the project will not be adequately protected.
5. Respond to the risk
Now comes the moment, when all that has been planned must be put into practice.
For each identified risk, based on priority, a mitigation plan or strategy is created.
The project manager should deal with the risk owner in order to decide together which strategy to implement to resolve the risk.
6. Risk monitoring
Obviously, every strategy to respond to the risk is useless if it is not monitored in its success – or failure.
The risk owner is also responsible for monitoring the progress towards resolution.
But also the project manager needs to stay updated in order to get an
accurate picture of the overall progress and to identify and monitor
potential new risks that may arise from the new situation.
It is better to ensure that dedicated communication channels for risk management are organized, so that important elements and information are not lost.
Risk mitigation
After the risk has been identified and assessed, the project team develops a risk mitigation plan, ie a plan to reduce the impact of an unexpected event.
Here are the four ways to manage or mitigate a risk:
Risk avoidance
Risk acceptance and sharing
Risk mitigation
Risk transfer
Each of these mitigation techniques can be an effective tool to reduce individual risks and the risk profile of the project.
Let’s see these four techniques in detail.
1. Risk avoidance
This technique usually involves developing an alternative strategy that is more likely to succeed, but is usually linked to a higher cost.
A very common risk elimination technique is to use proven and
existing technologies rather than adopting new technologies, although
they could lead to better performance or lower costs.
A project team can choose a supplier with a proven track record
instead of a new supplier that offers significant price incentives;
this, in order to avoid the risk of working with a new supplier that is
not known whether it is reliable or not.
Eliminating a risk is definitely the best technique you can use. If the project manager can avoid it, surely he will not have negative impacts derived from it on the project.
2. Risk acceptance and sharing
This technique involves accepting the risk and collaborating with others in order to share responsibility for risky activities.
Many organizations working on international projects will reduce the
political, legal, and employment risks associated with international
projects by developing a joint venture with a company based in a
particular country, for example.
Partnering with another company to share the risk associated with a
part of the project is advantageous when the other company has
experience that the project team does not have. If a risk event occurs, the partner company absorbs all or part of the negative impact of the event.
3. Risk mitigation
Risk mitigation represents an investment in order to reduce the risk on a project.
On international projects, for example, companies will often buy a
guaranteed exchange rate in order to reduce the risk associated with
exchange rate fluctuations.
A project manager can hire an expert to review technical plans or
cost estimates on a project in order to increase confidence in that
plan.
Assigning high-risk management activities to highly qualified project personnel is another risk reduction method.
Experts who run a high-risk business can often anticipate problems and find solution.
4. Risk transfer
Risk transfer is a risk reduction method that shifts risk from the project to another party.
A classic example of risk transfer is the purchase of an insurance.
The risk is transferred from the project to the insurance company.
Purchasing an insurance is usually in areas beyond the control of the
project team. Weather, political unrest, and strikes are examples of
events that can have a significant impact on the project and that are
beyond the control of the project team.
Simply put, it is simply a matter of paying someone else to accept the risk.
Risk management may seem superfluous at the beginning of the project.
When a project manager is starting a new project, it is indeed
difficult to think about things that could go wrong, especially if he is
caught up in the initial enthusiasm.
It is essential to remember, however, that the development of a
management plan will – most likely – be useful later during the
development of the project.
This is why risk management must be considered an absolute priority from the start.
There are multiple instances where an organization works with another
organization as a third party and it can bring up a variety of security
issues. A third party is an entity that isn’t directly involved in
activities between two primary parties.
In many situations, it’s
appropriate to use a non-disclosure agreement (NDA) to ensure that third
parties understand their responsibilities. This can be a completely
separate agreement, but is more commonly embedded as a clause in a
contract with the third party.
In addition to NDAs, organizations often utilize different
interoperability agreements to identify various responsibilities. These
include ISAs, SLAs, MOUs, and BPAs.
Interconnection security agreement (ISA)
An
ISA specifies technical and security requirements for planning,
establishing, maintaining, and disconnecting a secure connection between
two or more entities. For example, it may stipulate certain types of
encryption for all data in transit.
Service level agreement (SLA)
An
SLA is an agreement between a company and a vendor that stipulates
performance expectations, such as minimum uptime and maximum downtime
levels. Organizations use SLAs when contracting services from service
providers such as Internet Service Providers (ISPs). Many SLAs include a
monetary penalty if the vendor is unable to meet the agreed-upon
expectations.
Memorandum of understanding (MOU)
An
MOU expresses an understanding between two or more parties indicating
their intention to work together toward a common goal. It is similar to
an SLA in that it defines the responsibilities of each of the parties.
However, it is less formal than an SLA and does not include monetary
penalties. Additionally, it doesn’t have strict guidelines in place to
protect sensitive data.
Many times, MOUs are used in conjunction with ISAs. National Institute of Standards and Technology (NIST) Special Publication (SP) 800-47, “Security Guide for Interconnecting Information Technology Systems,” includes more in-depth information on MOUs and ISAs.
Business partners agreement (BPA)
A
BPA is a written agreement that details the relationship between
business partners, including their obligations toward the partnership.
It typically identifies the shares of profits or losses each partner
will take, their responsibilities to each other, and what to do if a
partner chooses to leave the partnership. One of the primary benefits of
a BPA is that it can help settle conflicts when they arise.
Q. Your organization is considering storage of sensitive data in a
cloud provider. Your organization wants to ensure the data is encrypted
while at rest and while in transit. What type of interoperability
agreement can your organization use to ensure the data is encrypted
while in transit?
A. SLA
B. BPA
C. MOU
D. ISA
Answer. D is correct.
An interconnection security agreement (ISA) specifies technical and
security requirements for secure connections and can ensure data is
encrypted while in transit.
None of the other agreements address the connection.
Having a well-developed security posture is essential to any
business. Organizations should not assume the security of their
customers' data and instead must take proactive steps to ensure it
throughout the development process. Veracode provides powerful
cloud-based tools, including static and dynamic security analysis, to detect vulnerabilities and security flaws before attackers can take advantage of them.
One common threat to be wary of is spoofing, where an attacker fakes
an IP address or other identifier to gain access to sensitive data and
otherwise secure systems. According to a 2018 report by the Center for Applied Internet Data Analysis (CAIDA), there are close to 30,000 spoofing attacks per day.
What Is a Spoofing Attack?
Spoofing is when an attacker impersonates an authorized device or user to steal data, spread malware, or bypass access control systems.
There are many different types of spoofing, with three of the most common being:
IP address spoofing - Attacker sends packets over the network from a false IP address
ARP spoofing - Attacker links their MAC address to an authorized IP address already on the network
DNS spoofing - Attacker initiates a threat such as cache poisoning
to reroute traffic intended for a specific domain name traffic to a
different IP address
IP Address Spoofing Attacks
An IP (Internet Protocol) address is a unique number used to identify
a specific computer on a network. In IP address spoofing, attackers
manipulate the IP header so that the packet appears to be coming from a
legitimate source. This tricks the target machine into accepting
malicious code or giving attackers access to sensitive data.
IP address spoofing can be used to carry out a denial-of-service
attack. In this attack, attackers flood the network with more data than
it can handle by sending hundreds or thousands of IP packets from
multiple spoofed IP addresses. Alternatively, a specific machine's
address can be spoofed to send many packets to other machines on the
same network. Because machines automatically send responses when they
receive an IP packet, this results in the spoofed machine being knocked
offline.
Another way attackers use IP spoofing is to bypass authentication
that relies upon a device’s IP address. Systems designed to assume a
specific list of IP addresses is trustworthy can be tricked into
accepting connections from untrusted machines that spoof a trusted
machine’s IP address.
ARP Spoofing Attacks/ARP Cache Poisoning
ARP (Address Resolution Protocol) is used to identify legitimate
machines on a network by resolving IP addresses to a specific MAC (Media
Access Control) address. In ARP spoofing,
an attacker sends ARP packets to the network, which appear to be from
these legitimate devices. Because other machines on the network will
think the attacker is legitimate, they will gladly send data back, which
the attacker can use for other, more sophisticated attacks.
Successful ARP spoofing can be used to carry out:
Denial-of-service attacks, where networks or machines are flooded with bogus data and taken offline
Session hijacking, in which attackers exploit in-progress
authentication by legitimate users to gain unauthorized access to data
and devices
Man-in-the-middle attacks, where attackers impersonate multiple devices to steal data intended for legitimate devices
DNS Spoofing Attacks
In DNS spoofing, an attacker provides false information to the DNS
(Domain Name System) facility used by a given system, usually by
inserting incorrect information into the local DNS cache. When an
application needs to access a network resource by hostname, the system
looks up the correct IP address associated with that name by using a DNS
query to a DNS server that’s configured for the network. To reduce load
on that server, most systems cache the responses to DNS queries for a
time – so if an attacker is able to alter the contents of that cache,
they can trick applications into accessing an IP different from those
registered in the DNS system for a given hostname.
DNS server spoofing is often used to route web traffic to a server
under the attacker's control and deliver computer viruses, and other
malware onto users' machines, or to trick the user into supplying
sensitive information.
How to Prevent and Mitigate Spoofing Attacks
Spoofing attacks can have disastrous consequences, but there are ways to reduce their likelihood and prevent them altogether.
Employ Packet Filtering with Deep Packet Inspection
Packet filtering analyzes IP packets and blocks those with
conflicting source information. Because malicious packets will come from
outside the network despite what their headers say, this is a good way
to eliminate spoofed IP packets. Because attackers have developed
techniques for evading simple packet filters, most packet-filter systems
offer a DPI (Deep Packet Inspection) feature. DPI allows you to define
rules based on both the header and the content of network packets,
allowing you to filter out many kinds of IP spoofing attacks.
Authenticate users and systems
If devices on a network use only IP addresses for authentication, IP
spoofing can bypass the authentication control. Connections between
devices should be authenticated by the individual users or applications,
or by using authenticity systems such as mutual certificate auth,
IPSec, and domain authentication.
Use Spoofing Detection Software
Several programs help detect spoofing attacks, especially ARP
spoofing. Consider a tool like NetCut, Arp Monitor, or arpwatch for ARP
spoofing defense. These and other tools can inspect and certify
legitimate data before it is received by a target machine can
significantly lower the success of spoofing attacks.
Use Encrypted and Authenticated Protocols
Security experts have developed several secure communications protocols, including Transport Layer Security (TLS) (used by HTTPS and FTPS),
Internet Protocol Security (IPSec), and Secure Shell (SSH). When used
properly, these protocols authenticate the application or device to
which you’re connecting, and encrypt data in transit, reducing the
likelihood of a successful spoofing attack.
Security orchestration, automation, and response (SOAR) solutions help teams to enhance their security posture
and develop efficiency without overlooking critical security and IT
processes. This is achieved with the help of playbooks, which are a
built-in capability of SOAR solutions that carry out various tasks and
workflows based on rules, triggers, and events. Integrating SOAR into an
organization’s security operations center (SOC) can boost the overall
security efficiency and effectiveness by automating tasks, coordinating
alerts from multiple security devices, and providing playbooks for incident response.
SOAR solutions utilize varied playbooks to automate responses to
different kinds of threats without any manual intervention. These
playbooks ensure that the security processes are uniformly executed
throughout a company’s SOC.
SOAR Workflow Versus Playbook
While SOAR workflow is a collection of tasks in a playbook, sets of workflows are known as playbooks that allow SOAR platforms
to automatically take action when an incident occurs. Using SOAR
playbooks, security teams can handle alerts, create automated responses
for different incident types, and quickly resolve issues, more
effectively and consistently. With SOAR playbooks, security teams can
build workflows that require minimal to no human intervention. These
playbooks also facilitate the automated incident investigation, threat intelligence enrichment, incident actioning such as blocking of malicious indicators of compromise (IOCs), and automated threat data dissemination to security tools such as SIEMs, firewalls, threat intelligence platforms (TIPs), incident response platforms, and others.
Why are SOAR Playbooks Needed?
SOAR
playbooks enable security teams to expedite and streamline
time-consuming processes. Equipped with capabilities to integrate
security tools and establish seamless customizable workflows, these
playbooks allow security teams to automate mundane and repetitive tasks
while freeing human analysts for more important tasks dependent on human
intelligence and decision making. Nowadays, modern security playbooks
come with “holdable” features allowing them to integrate human decision
making with automation for highly critical security situations. With
considerable productivity gains and time savings across overall security
operations, security teams can move from overwhelmed to functioning at
maximum efficiency in no time.
SOAR Playbook Use Cases
Threat Intelligence Automation
Threat intelligence enrichment
is an important aspect of any incident or threat investigation process.
This enrichment process eliminates false positives and collects actionable intelligence for threat response and other security operations. SOAR playbooks automatically ingest and normalize indicators of compromise (IOCs)
from external and internal intelligence sources and enrich the
collected IOCs. Following the enrichment process, the playbooks can
automatically score the intel and prioritize the further response
steps.
Automated Incident Response
With
advanced threat contextualization, analysis, and SOAR playbooks,
security teams can have intel-driven responses to all security threats
and incidents. SOAR playbooks allow security teams to leverage the power
of automation to detect, analyze, enrich, and respond to threats at
machine speed. SOAR playbooks can also be used to block threat
indicators (IOCs) on Firewall, EDR, SIEM, and other tools.
Vulnerability Management
SOAR
playbooks enable security teams to instantaneously respond to
vulnerabilities by automatically applying or scheduling patches. SOAR
playbooks can also be used to ensure that security teams stay informed
about all the current vulnerabilities and that they successfully
evaluate the potential risk of every vulnerability in order to take
appropriate risk mitigation measures. Besides providing information to
the teams, SOAR playbooks can be employed to query a database of
vulnerabilities, active directories for asset information, or EDR tools
for events to collect additional information on vulnerabilities.
Improved Threat Hunting
With new vulnerabilities and attacks emerging constantly, threat hunting is becoming not only a challenge but a priority. Using SOAR playbooks, security teams can automate threat hunting
processes to identify suspicious domains, malware, and other
indicators, accelerating the hunting process and freeing themselves to
tackle critical challenges. With the help of SOAR playbooks, security
teams can move beyond alert fatigue, responding to incidents before the
moment of impact.
Automated Patching and Remediation
From notifications to remediation of threats, vulnerability management
processes can be orchestrated by integrating SOAR playbooks into a
company’s existing solutions. The playbooks automate actions to scan,
discover patches, validate remediation, and more, addressing critical
issues.
Phishing Email Investigations
Phishing has been one of the major attack vectors for data breaches. With the phishing incident response playbook,
security teams don’t need to manually investigate every URL,
attachment, or dubious request for sensitive information. A phishing incident response playbook allows security teams to focus on alleviating malicious content and training employees on phishing best practices.
To
quickly respond to phishing attacks, security teams can employ
automated phishing incident response playbooks. The automated phishing
incident response playbooks standardize the response process from
detection to blocking of the malicious indicators from where attacks are
sourced.
Malware Containment
With
the increasing risk of ransomware, spyware, viruses, and more, security
teams are grappling with a plethora of malicious programs. SOAR
playbooks can automatically investigate and contain malware before they spread and damage an organization’s network.
Employee Provisioning and Deprovisioning
Every
company should be able to quickly and effectively manage user
permissions in order to respond to a wide range of security threats.
However, it is a critical task and most organizations can’t keep up.
From provisioning and deprovisioning users to responding to incidents,
SOAR playbooks can put an end to the burden of manually handling user
accounts in diverse use cases.
Ease of Communication
When
alerts are received, SOAR playbooks trigger workflows, issuing help
desk tickets, initiating investigation and enrichment tasks, and so on.
The playbooks can be integrated with other workflow management solutions
to establish seamless communication between security, development, and
IT teams. Security teams can access central communication hubs to
improve visibility and efficiently coordinate processes.
Benefits of SOAR Playbooks
Standardized Processes
SOAR
solutions fill in for security analysts and relieve them of monotonous
tasks, and include these tasks in an overall process of handling any
incident. A good SOAR solution incorporates these tasks into playbooks that outlay the step-by-step incident response.
Streamlined Operations
Every aspect of SOAR playbooks contributes to simplify security operations. While security orchestration
aggregates data influx from multiple sources, security automation
controls low-priority alerts and incidents with the help of automated
playbooks.
Technology and Tools Integration
A
SOAR playbook can be integrated into products across various security
technologies such as cloud security, forensics, and malware analysis,
vulnerability and risk management, data enrichment, threat intelligence, incident response, and endpoint security among others. The integration of these technologies into a SOAR solution can be seamless.
Risk management is the practice of identifying, monitoring, and
limiting risks to a manageable level. It doesn’t eliminate risks, but
instead identifies methods to limit or mitigate them. The amount of risk
that remains after managing risk is residual risk.
Senior
management is ultimately responsible for residual risk—the amount of
risk that remains after mitigating risk. Management must choose a level
of acceptable risk based on the organization’s goals. They use a
variety of tools and metrics to identify the risks, and then decide what
resources (such as money, hardware, and time) to dedicate to manage the
risk.
Some of the common metrics they use are:
Mean time between failures (MTBF)
Mean time to failure (MTTF)
Mean time to recover (MTTR)
What is Failure?
These
metrics are important to understand when evaluating the failure rate of
critical business systems. Typically, a critical business system will
have multiple redundancies in place to ensure it stays operational even
after a fault occurs. In other words, critical systems can tolerate
faults without actually failing.
If a server has one hard drive, and the one hard drive fails, the server fails. This is a system failure.
However,
if a server has a redundant array of independent disks 6 (RAID- 6), and
one drive fails, the server continues to operate. This is not a system
failure.
Mean Time Between Failures (MTBF)
The mean time
between failures (MTBF) metric provides a measure of a system’s
reliability and is usually represented in hours. More specifically,
the MTBF identifies the average (the arithmetic mean) time between
failures.
Higher MTBF numbers indicate a higher reliability of a
product or system. Administrators and security experts attempt to
identify the MTBF for critical systems with a goal of predicting
potential outages.
Mean Time to Failure (MTTF)
The mean
time to failure (MTTF) is the length of time you can expect a device to
remain in operation before it fails. It is similar to MTBF, but the
primary difference is that “between” in the MTBF metric indicates you can repair the device after it fails.
In
contrast, the MTTF metric indicates that you will not be able to repair
a device after it fails. It is permanent. For example, the MTTF of a
power supply within a server indicates how long the power supply may
last before it fails and needs to be replaced.
Mean Time to Recover (MTTR)
The
mean time to recover (MTTR) identifies the average (the arithmetic
mean) time it takes to restore a failed system. In some cases, people
interpret MTTR as the mean time to repair, and both mean essentially the
same thing.
Organizations that have maintenance contracts, such
as service level agreements (SLEs), often specify the MTTR as a part of
the contract. The supplier agrees that it will, on average, restore a
failed system within the MTTR time.
The MTTR
does not provide a guarantee that the supplier will restore the system
within the MTTR every time. Sometimes it may take a little longer and
sometimes it may be a little quicker, with the average defined by the
MTTR.
MTBF, MTTF, MTTR Summary
As a short summary these metrics are:
Mean
time between failure (MTBF) – provides a measure of a system’s
reliability and identifies the average time between failures. It is
often used to predict potential outages with critical systems.
Mean
time to failure (MTTF) – the length of time you can expect a device to
remain in operation before it fails. It indicates failure is permanent,
while MTBF indicates it can be repaired.
Mean time to repair (MTTR) – the average time it takes to restore a failed system.
