eSecurity Planet may receive a commission from vendor links. Our recommendations are independent of any commissions, and we only recommend solutions we have personally used or researched and meet our standards for inclusion.

The powerful open-source tool Nmap scans the ports of network devices and probes website domains for known vulnerabilities. Since both internal security teams and malicious hackers can use Nmap, internal security teams should make sure to perform the scan first!

To become familiar with Nmap as a basic tool to detect basic vulnerabilities this article will cover:

• Getting Started with Nmap
• Nmap Vulnerability Scanning
• Vuln vs Vulners vs Vulscan
• How Do Attackers Use Nmap?
• Pros and Cons of Using Nmap
• Nmap Vulnerability Scanner Alternatives
• Bottom Line: Use Nmap for Inexpensive, Effective Vulnerability Scanning

Getting Started with Nmap

Nmap, or network map, provides open-source and free capabilities for auditing IT infrastructure, such as port scanning, host discovery, or device identification across a network. Both pen testers and threat actors use Nmap to collect information about their target, and Nmap has been recognized by CISA as an important free tool for network security.

Installing Nmap

Nmap began as a Linux utility, but it’s now available for all major operating systems, including Windows or macOS. Nmap comes pre-installed on several versions of Linux including Kali Linux. Other Linux systems users can use the command “apt-get install Nmap” to install it.

Users of all operating systems can download Nmap as well as the ZeNmap graphical user interface (GUI) front-end for Nmap. Those that prefer to use github can clone the official git repository using this command:

git clone https://github.com/Nmap/Nmap.git 

After installing Nmap, users can use the command line or ZeNmap to execute simple commands to map the local domain, scan ports on a host, and detect operating system versions running on hosts.

Many open source software packages have been infected with malware. To verify that the specific download of Nmap matches the intended contents, an organization can compare the download against the signature records maintained by Nmap.

Built-in Nmap Scripts

Running basic functions can be tedious. Users increase the capabilities of Nmap by running built-in Nmap scripts. These scripts should be periodically updated by running this command:

sudo Nmap --script-updatedb

An overview of basic commands and example scripts can be found in Nmap: Pen Testing Product Overview and Analysis.

Using Custom Nmap Scripts

Advanced users may prefer to combine multiple lines of instructions or more complex commands using the Python language and the Python-Nmap package.  Advanced users can also use the Nmap Scripting Engine (NSE) to enable network discovery, vulnerability detection (e.g., backdoor), and even specific exploits using the Lua programming language.  These scripts are .nse files and will typically contain comments for end users and code instructions for the machines.

Nmap Vulnerability Scanning

Nmap’s vulnerability scanning capabilities rely upon the vulnerability-detecting scripts categorized under “vuln” for vulnerability or custom scripts. Users can run built-in scripts individually or collectively using the “vuln” command. In addition, users can also download custom scripts such as Vulscan or Vulners.

As with any penetration testing or vulnerability scan, users must keep in mind that these invasive scans should only be performed with permission. Even scanning a system without permission could lead to attempts to impose fines or jail time depending upon the jurisdiction. For more information, a user can investigate regulations such as those found in the US (The Computer Fraud and Abuse Act), England (Computer Misuse Act 1990), India (Information Technology Act Sec. 43 and 66), Japan (The Act on the Prohibition of Unauthorised Computer Access), and many other countries.

Specific Nmap Vulnerability Scans

Nmap scripts contain well over 100 specific scans for vulnerabilities that can be run against domains or against specific host IP addresses. A comprehensive list of scanned vulnerabilities can be found on the Nmap website.

Application Scans: Run Nmap against a target domain (ex: esecurityplanet.com)  to check websites for vulnerabilities such as:

• http-csrf: Detect Cross-Site Request Forgery (CSRF) vulnerabilities by entering the command: Nmap -sV –script http-csrf <target domain>
• http-sherlock: Check if the “shellshock” vulnerability can be exploited in web applications by entering the command: Nmap -sV –script http-sherlock <target domain>

IT Host Scans: Run Nmap against a target IP address (ex: 166.96.06.4) to check for host vulnerabilities such as: 

• dns-update: Attempt to perform a dynamic domain name service (DNS) update without authentication by entering the command: Nmap -sU -p 53 –script=dns-update –script-args=dns-update.hostname=foo.example.com,dns-update.ip=192.0.2.1 <target IP address>
• smb-vuln-cve-2017-7494: Check if target IP address are vulnerable to the arbitrary shared library load vulnerability by using a script such as: Nmap –script smb-vuln-cve-2017-7494 -p 445 <target IP address>

Government advocated Nmap scripts will sometimes be released or promoted on official websites to help organizations address specific vulnerabilities. For example, the UK government maintains an open-source GitHub repository to help organizations scan networks for the Exim MTA vulnerability as part of the Scanning Made Easy project from the National Cyber Security Centre (NCSC) and its i100 industry partnership.

The repository provides a collection of officially promoted Nmap scripts to users, such as sysadmins, for detecting system vulnerabilities. The initial UK script focuses on the Exim message transfer agent (MTA) remote code execution vulnerabilities CVE-2020-28017 through CVE-2020-28026, also known as 21Nails.

The script contains information on:

• How it checks for the presence of the vulnerability
• Why the check is not intrusive
• Why there may be false positives and false negatives

How to Use Vuln

Nmap can scan a target domain or IP address for all vulnerabilities in the default script library for the “vuln” category with the appropriately named Vuln command:

sudo Nmap --script vuln <target domain or IP Address> -v

Note that the command may require “sudo” in Linux to run the command as a super user or as the Linux equivalent of an administrator. In most cases, elevated privileges will be required to run the more invasive and probing commands for Nmap. The -v, or verbosity, flag will provide extensive information about the tests run and their results.

Running these commands can be dangerous because of invasive and disruptive aspects of specific vulnerability scans. Instead of simply obtaining information, certain scans attempt to verify a vulnerability by attempting to exploit the vulnerability. In some cases, a successful exploitation will result in changes to the service or even crashing the service, website, or operating system.

A subset of the vulnerability scans can be performed using wildcards or asterisks (*) to run multiple scripts with similar names simultaneously. For example, adding the wildcard after the http command (http*) will run all vulnerability scans that start with “http” against a targeted domain.

When using any of the bulk scans, the results can become overwhelming and some users will want to exclude low CVSS score vulnerabilities. To only show vulnerabilities within a certain range add the following flag to the command where “x.x” is the CVSS score (ex: 6.5).

--script-args=mincvss=x.x

The complete command to exclude vulnerabilities below 6.5 would be:

Nmap --script vuln --script-args mincvss=6.5 <target>

Results of the scan can be exported in various file formats by adding flags followed by the file name in the command. This export will make it easier to share information or make the vulnerabilities available for other software.

Two common examples of the complete command are:

• XML File: Nmap –script vuln -oX file.xml <target>
• Browser Friendly XML File: Nmap –script vuln –webxml -oX file.xml <target>

Of course, the basic set of vulnerability scans may not be sufficient for some users because it only examines a limited, although important, set of vulnerabilities. Advanced users may download custom scripts such as Vulscan or Vulners to access a larger database of vulnerabilities.

How to Use Vulscan

To use the NSE script Vulscan, a user must first clone the software from the github repository using the git command:

sudo git clone https://github.com/scipag/vulscan

The user may need to make a soft link to the NSE scripts directory by executing the following command:

sudo ln -s pwd /scipag_vulscan /usr/share/Nmap/scripts/vulscan

In this case, /usr/share/Nmap/scripts/vulscan is the presumed directory for Nmap scripts on the user’s machine, but this directory may be adjusted as necessary. Once the directory is known to Nmap, Vulscan is available to be called by the –script flag to run additional vulnerability checks using the following syntax:

sudo Nmap -sV --script=vulscan/vulscan.nse <target IP address or host name>

Vulscan can be run to detect IT vulnerabilities against an IP address in the network or software vulnerabilities against a host name (ex: esecurityplanet.com). Vulscan will run non-invasive tests for all applicable vulnerabilities against the target. The results will display the port followed by limited information on the specific CVEs discovered.

How to Use Vulners

Vulners will typically be included in the standard Nmap NSE scripts, but a user can also clone the NSE script for Vulners from its github repository using the git command:

sudo git clone https://github.com/vulnersCom/Nmap-vulners.git /usr/share/Nmap/scripts/vulners

The file directory /usr/share/Nmap/scripts/vulscan is the presumed directory for Nmap scripts on the user’s machine, but this directory may be adjusted as necessary. Once cloned, Vulners is available to be called by the –script flag using the following syntax:

sudo Nmap -sV --script Nmap-vulners/vulners.nse <target host or IP address>

Users can target specific ports on an IP address by adding -p<#> (ex: -p80 to target port 80) at the end of the command line. The results will display the discovered CVEs and will link to the Vulners website for more information.

Vuln vs Vulners vs Vulscan

Vuln and Vulners are included in the basic NSE script database and will be updated when updating all scripts for Nmap. Vulscan is not included in the basic script set and must be downloaded and updated separately. 

Vulners sends common platform enumeration (CPE) information received from port scans to vulners.com using the site’s API to actively download the latest common vulnerabilities and exposures (CVE) information from the site’s database. Vulners also requires internet access to reach the external databases of vulnerabilities. 

This information sharing of vulnerabilities may not be appropriate for organizations deeply concerned about the secrecy of their environment. There is an option with Vulscan to use a local database, but this generally removes the advantage of using Vulscan’s fully updated database. 

Vuln and Vulscan do not send CPE information outside of the scanned organization and use locally stored vulnerability databases.

The advantage of sending the CPE information is that Vulners hosts a fully updated set of CVEs. Vuln only detects 150 top vulnerabilities for systems and Vulscan uses an offline copy of vulnerability databases.

Vuln can risk disruption because Vuln tests for the presence of some vulnerabilities by attempting to verify exploitation and disruption or corruption of that service. However, the active probing will increase confidence and reduce the chance of a false positive. 

Vulners and Vulscan avoid the risk of disruption because they do not attempt to verify or exploit vulnerabilities. The confidence in both of these tools depends upon the accuracy and precision of the detection capabilities of the specific version of Nmap. Both of these tools may also be confused by non-standard, custom, or patched builds of specific services, which may lead to more false positives.

Of the three tools, the Vuln category of scripts can immediately produce highly accurate scans for a limited set of important vulnerabilities. However, while the number of vulnerabilities is small, the in-depth probing of the vulnerability can take 3-4 times longer than Vulners or Vulscan.

While both of the manually downloaded vulnerability scanners will enjoy a much more extensive and robust selection of CVEs to detect, Vulners will typically be the most updated scan since IT teams may forget to manually update Vulscan databases. But for more secretive organizations that need to avoid releasing CPE information, Vulscan’s use of a local database may be the best choice among the Nmap options.

How Do Attackers Use Nmap?

Attackers use Nmap to scan large networks quickly by using raw IP packets to identify available hosts and services on the network and determine their vulnerabilities. Hackers and pen testers typically add specific options to cover their tracks.

Decoy scans add the -D option flag (Nmap -p 123 -D decoyIP targetIP), to hide the attacking IP address and send source-spoofed packets to the target in addition to the scanning machine packets. The additional packets make port scan detection harder for defenders.

Attackers can also run zombie scans, also known as idle scans. This side-channel attack attempts to send forged SYN packets to the target using the IP address of the “zombie” endpoint on the network. This method attempts to fool the intrusion detection system (IDS) into mistaking the innocent zombie computer for the attacker. A more thorough review of Nmap attacks can be found in the Nmap Ultimate Guide: Pentest Product Review and Analysis.

Do Host Systems Detect Nmap Scans?

SIEM tools, firewalls, and other defensive tools, can receive alerts from systems and the scanned system will log the successful TCP requests from the many Nmap port scans. More sophisticated IDS/IDP tools might also detect malformed TCP requests, such as the Nmap stealthy requests that do not complete a TCP connection. Disruptive scans that cause system or service failure will definitely be detected by systems as well as by affected users.

Pros and Cons of Using Nmap

Nmap provides powerful vulnerability capabilities and should be under consideration for use within most organizations. However, there are many reasons why Nmap is not used universally.

Pros: Reasons to Use Nmap

• Open source and free so great for hackers, students, and all organizations
• Quick scans provide a fast look at potential vulnerabilities
• Lightweight TCP scans do not consume enormous network bandwidth and can escape some network security tools
• A hacker preview for organizations checking their internal systems
• Scriptable scans enable an organization to create repeatable vulnerability scans usable by non-technical users and for hackers to embed Nmap commands and scans into malware

Cons: Reasons Not to Use Nmap

• Less user friendly than commercial tools with more advanced GUIs
• Easy to make mistakes with command line entries
• Lack of programmers in an organization’s IT staff to create custom scripts or understand Nmap scripts
• Less formal support than commercial tools
• Limited vulnerability scans through the basic vuln command

Nmap Vulnerability Scanner Alternatives

Nmap remains a popular tool among many, but it certainly is not the only vulnerability scanner available. Open-source vulnerability scanner options for applications include OSV-Scanner or OWASP Zed Attack Proxy (ZAP) and for infrastructure include CloudSploit or OpenVAS.

There are many commercially available vulnerability scanners as well. The best vulnerability scanners for applications or infrastructure include Invicti, Tenable.io, ManageEngine’s Vulnerability Manager Plus, as well as others listed below:

Bottom Line: Use Nmap for Inexpensive, Effective Vulnerability Scanning

Nmap provides a no-cost option to detect vulnerabilities, double-check the results of commercial vulnerability scanners, or provide an effective sneak peek at the way a hacker might view opportunities in the organization’s infrastructure. Everyone, even an organization selecting to use a commercial vulnerability scanner, should consider using Nmap as a vulnerability scanning tool in their arsenal.

Read next: 

• Top Vulnerability Management Tools
• The 8 Best Vulnerability Scanner Tools for 2023
• 10 Best Open-Source Vulnerability Assessment Tools for 2023
• Nmap: Pen Testing Product Overview and Analysis

This article was originally written by Julien Maury on February 8, 2022 and revised by Chad Kime on July 14, 2023.

The post How To Use Nmap for Vulnerability Scanning: Complete Tutorial appeared first on eSecurityPlanet.

While an organization can use one or the other as an effective tool to improve security, the most mature organizations use vulnerability scans in combination with penetration tests to maximize their security benefits. The table below summarizes the main points of this article. Each issue will be explored in depth before we arrive at recommendations based on our analysis.

To ensure a common frame of reference, let’s start with a recap of the basic definition for both concepts critical to network security.

What is a Vulnerability Scan?

A vulnerability scan, or vulscan, performs a systematic check of IT systems to look for known security holes. There are two types of vulnerability scans.

IT infrastructure vulnerability scans will be performed by IT or cybersecurity teams to inspect internal IT systems using admin-level permissions for known vulnerabilities in:

• Internal networking equipment, such as switches and routers
• File servers
• Network access storage (NAS) devices
• Individual computers
• Peripheral devices like printers and scanners
• Internet of Things (IoT) devices connected to the network, such as security cameras, TVs, etc.
• Critical applications and internal processes, such as Active Directory (AD); Domain Name System (DNS); and accounting, banking, or operations management software

Application or website vulnerability scans will be performed by development operations (DevOps) or development security operations (DevSecOps) programmers to scan software libraries, application programming interfaces (APIs), and supply chain components for known vulnerabilities.

What is a Penetration Test?

Penetration tests, or PenTests, probe systems for weaknesses to determine if they can be exploited. The common black box penetration test scans the external IT infrastructure of the organization such as firewalls, web servers, web applications, gateways, and VPN servers. These tests are performed without any advanced knowledge of its systems, but different penetration tests use credentials, test physical security, involve social engineering, phishing attacks, dropped USB drive attacks, test system volume capacity limits, and more.

Bounties can be considered a form of penetration testing that incentivises non-contracted ethical hackers with payment after finding a flaw instead of through a contract agreed upon in advance. However, bounties can be unpredictable and, while very useful, bounties should not be relied upon to replace formal penetration tests.

When to Use Vulnerability Scans and Pentests

The simplified justification to pick between vulscans and pentests can be expressed as:

• Vulnerability Scans: To scan infrastructure and discover known vulnerabilities
• Penetration Tests: To explore discovered vulnerabilities to verify if they can be exploited and what damage could result from the exploitation or to discover non-vulnerability exposures in key systems

To elaborate, vulnerability scans use commercial or open source tools that can be used by less experienced IT or security personnel to perform periodic, automated or on-demand testing. These tests can be performed quickly and inexpensively to detect known vulnerabilities.

However, vulnerability scanning tools cannot determine how easily the detected vulnerability can be exploited or how much damage can result from the exploitation of the vulnerability. Human expertise, often in the form of penetration testing, needs to be performed to verify the exploitability of the detected vulnerability and the extent of the potential damage.

Penetration testing can also discover additional flaws that might expose the organization to risk that cannot be detected by vulnerability scans. For example, pentests can discover weak passwords, gaps in security, or other security weaknesses that come from inadequate security architecture.

How to Use Vulnerability Scans and Pentests

Vulnerability scans are primarily tool-based, so a security team will often acquire and configure the tool for internal use. For organizations with more limited resources, vulnerability scanning can be included in the offerings of managed IT service providers (MSPs) and managed IT security service providers (MSSPs) or even through a vulnerability management as a service (VMaaS).

Penetration tests can be performed by internal teams who pick up breach and attack simulation (BAS) tools. However, internal teams can lack the expertise to thoroughly test systems and will be tempted by conflicts of interest to hide potential flaws in IT setup from management. Instead, organizations will typically engage third-party penetration testing vendors or MSSPs with pentesting expertise for the relevant assets to be tested (applications, websites, firewalls, containers, etc.).

Pentest vendors can retain experienced ethical hackers that the average organization cannot afford. These hackers use their experience to rapidly assess systems, target the most likely vulnerabilities to be exploited, and use hacking tools when needed.

Popularity of Vulnerability Scans and Pentests

The relative popularity of vulnerability scans and penetration tests is quite interesting because the popularity among professionals is inverse to the actual usage and demand. Among IT and security professionals, vulnerability scans tend to be less popular than penetration tests because they are not as technologically interesting as hacking — it seems more like homework. However, vulnerability scans tend to be less invasive, less expensive, and easier to execute which makes them much more frequently used among organizations.

The popularity for penetration testing, also known as red team exercises, can be measured by the higher demand and number of classes and certifications devoted to red team techniques when compared to defensive blue team techniques. This popularity also is skewed by the reality that a penetration tester only needs to find one way in to be successful and a blue team defender needs to be skilled against every possible red team tactic. IT teams just don’t feel like they can win on defense, so hacking just seems like more fun.

However, penetration tests cost much more money and can be hard to scope and understand for an organization. These factors lead some organizations to focus on vulnerability scans for everyday needs and to avoid penetration testing unless required by a compliance standard.

Frequency of Vulnerability Scans and Pentests

Most organizations perform vulnerability scans at least quarterly, with additional scans performed after significant changes to IT infrastructure or application updates. More aggressive organizations can scan monthly, weekly, or even continuously. After mitigation of discovered vulnerabilities, a rescan or penetration test will be required to validate the fix.

Compliance standards often define the frequency of vulscans and pentests. The PCI Data Security Standard (PCI DSS) requires vulnerability testing to be conducted at least quarterly and after every significant change to IT infrastructure, security tools,  or applications. Recent research by Veracode finds that more frequent vulnerability scanning has reduced the typical number of vulnerabilities by two-thirds and decreased the time to fix vulnerabilities by more than 30%.

Many organizations never perform a penetration test, and of those that do, many only perform annual external penetration tests. More sophisticated organizations perform tests more frequently, such as 2-4 tests per year and also add pentests after significant infrastructure changes (especially for internet-accessible systems or after fixing previously discovered issues).

Are Vulnerability Scans or Pentests Internal or External?

Vulnerability scanning tools can be applied to external systems or even to systems that an organization does not control. However, vulnerability tools do not attempt to be stealthy and tend to be used primarily on internal systems.

Penetration tests tend to be performed on externally accessible assets from the point of view of a cyberattacker. However, penetration tests can also be performed internally without credentials to simulate attackers obtaining compromised low-access credentials (gray-box pentest) or with full credentials for more thorough testing (white-box pentest).

Also read: 7 Types of Penetration Testing: Guide to Pentest Methods & Types

Time Needed to Conduct Vulnerability Scans and Pentests

Vulnerability scans usually take a few hours, but the total time will vary greatly on the number of systems scanned and the type of systems scanned. Large systems can take days to complete a scan and vulscans can take only a few minutes for simple scans of a small office.

As with vulscans, penetration test durations will be highly variable and dependent on the number of systems tested and the type of pentests required. A typical test usually takes weeks to complete, but could take several months for comprehensive testing, especially for multi-national, multi-office organizations seeking social engineering, physical security tests, and other time-consuming pentests.

Do Vulnerability Scans and Pentests Generate False Positives?

Vulnerability scanning often will detect vulnerabilities that will be determined to be false positives. The scans may also locate true positives with negligible associated risk. Regardless, each vulnerability finding must be verified and either mitigated or flagged to be ignored.

Low-end pentests that only use off-the-shelf software will produce the same false positives that plague vulscans. Effective penetration tests usually generate zero false positives since the penetration testing results verifies exploitation risk by proving the hacker can access protected data or create operational disruption.

Naturally, after considering false positives, one must consider if false negatives are possible. Both forms of testing will only report on vulnerabilities found, but will not report that other assets pass without vulnerabilities. In the strict sense of the definition, no false negatives are generally produced, because neither testing procedure creates “all-clear” reports on systems on which no flaws were detected.

However, both forms of testing can overlook vulnerabilities. Vulnerability scans will always miss vulnerabilities not yet entered into their databases or on assets that are not scanned. Assets can be missed either because the tool is not capable of scanning an asset class (such as Kubernetes containers) or because the asset list simply was not updated prior to the scan.

Penetration tests tend to be narrow in scope and generally cannot test all systems or for all possible vulnerabilities. Even the most experienced pentester cannot know all possible vulnerabilities, and most organizations do not have the budget or time to test all possible systems. Pentesters make choices to focus on the most likely vulnerable systems and the most likely vulnerabilities.

Comprehensiveness of Vulnerability Scans and Pentests

Vulnerability scans target all applicable infrastructure and tend to only be limited by the scanning tool’s capabilities. Most can scan for tens of thousands of vulnerabilities, but a security team must also recognize that vulnerability tools can only scan for vulnerabilities that are known and already programmed into the scanner and on a device detected for scanning.

This limitation is neither unusual nor problematic as long as the security team recognizes that even scanned systems cannot be assumed to be vulnerability-free. The IT and security teams must also be sure to update the tool to scan all of the available assets so that no scannable asset is simply overlooked.

Many vulnerability scanners are also specialized by asset class. For example, some can only scan applications or websites and others can only scan Windows and macOS operating systems. Less common asset classes such as networking equipment, peripheral devices (printers, external hard drives, etc.), internet of things (IoT), industrial control systems (ICS), and industrial or operating technology (OT) often require specialized vulnerability scanning tools or manual investigation.

Penetration testing tends to be limited in scope due to budgets, time constraints, and tester capabilities. Pentests not only test known vulnerabilities, but can also discover unknown vulnerabilities, security gaps, and security weaknesses that technically are not vulnerabilities (just poor security architecture). However, while they may probe deeper than vulscans, pentests tend not to be as comprehensive and will be focused around the pentester’s expertise or the systems the organization can afford to test.

Minimum Requirement Vulnerability Scans and Pentests

The minimum level of vulnerability scanning is equivalent to patch management and examines traditional IT systems (servers, workstations, and laptops) for unpatched systems. For penetration tests, the minimum level tends to be external pentests on internet-accessible systems.

However, in both minimal cases, organizations must recognize that these minimum-requirement tests will likely leave the organization exposed to risk. Most organizations pursue minimum testing to minimize expenses, but even these minimums depend upon the specific compliance regulations.

However, this will likely be an evolving condition over the next few years. New York State already requires both penetration testing and vulnerability assessments for its financial institutions, and both PCI DSS and the National Institute of Standards and Technology (NIST) cybersecurity framework (800-115) have vulnerability scans as basic requirements.

Some vendors and consultants offer low-cost automated pentesting; however, these tests often prove ineffectual and produce similar results to vulnerability scans. These minimal approaches can catch easy-to-find and well-known vulnerabilities, but will not typically be rigorous enough to satisfy most compliance requirements.

Also read: What Is a Pentest Framework? Top 7 Frameworks Explained

Operations Disruptions from Vulnerability Scans and Pentests

Vulnerability scans probe each device port by port to test for known vulnerabilities, which can cause possible network bandwidth issues and even system instability. More sophisticated tests probe network equipment and check for misconfigurations, which will place even more demands on systems.

Most organizations schedule vulnerability scans for off-hours to minimize operations disruptions and may even exclude certain systems known to be sensitive to scanning. An organization with automated vulnerability scanning capabilities can also perform scans every time a new device is connected to the network; that also allows future vulnerability scans to be incremental and focus on specific vulnerabilities or devices that have not been scanned within the last month or quarter.

Penetration testing can also cause operations disruptions with certain types of tests. However, penetration testers will typically recognize how much disruption might be caused and can prepare the organization in advance for recovery. For disastrously disruptive tests that might cause data loss or full operations failure, an organization might create a test environment for hackers to probe so that a successful hack does not affect operations.

Penetration testing will often be thought of as an exercise to break into the systems to steal data. While valid, this definition ignores other forms of penetration testing such as volume capacity tests for infrastructure, such as when testing for distributed denial of service (DDoS) resilience.

How to Handle Overload From Vulnerability Scans and Pentests

Many organizations that need to perform vulnerability scans or penetration tests can become overwhelmed by the results because of resource constraints (budget, staffing, etc.).

With vulnerability scanning, overwhelm can often be controlled by ignoring known vulnerabilities or through filtering vulnerabilities using CVSS or risk-based ranking. Likewise, penetration testing overwhelm may be controlled by rolling or partial pentesting.

For example, vulscans of healthcare facilities notoriously find many issues, since many medical imaging devices run on operating systems that no longer receive updates (see Three Ways to Protect Unfixable Security Risks). Instead of producing the same list of vulnerabilities with each scan, the organization can exclude the devices with known vulnerabilities from regular scans to focus on fresh issues.

Scans also often overwhelm an organization with vulnerabilities with low Common Vulnerability Scoring System (CVSS) ratings that either cannot cause significant damage or are difficult to exploit. To avoid overload, an organization might choose to ignore scans below a selected ranking or to filter vulnerabilities in vulnerability management software to focus on high-priority vulnerabilities.

Risk-based filtering is similar to CVSS filtering, but instead of focusing on the vulnerability, the organization focuses on the importance of the asset and the likelihood of exploitation. For example, an organization might ignore a high-ranking data exfiltration vulnerability in a server that contains publicly available marketing materials in favor of focusing on a lower-ranking privilege escalation vulnerability in the credit card payment database due to the potential damage to the organization.

Penetration testing limitations will often focus on specific types of tests or specific systems in a given time period and leave other testing for later.

While organizations can use all of these techniques to limit scope and scale, they also need to recognize that such limitations might leave the organization exposed to potential attack via ignored systems or vulnerabilities.

Of course, service providers can provide another option for organizations that can obtain additional resources through outsourcing. A wide variety of MSPs, MSSPs, or even Vulnerability Management as a Service (VMaaS) providers can enable organizations to deal with overwhelm without remaining exposed to higher risk of attack.

Costs of Vulnerability Scans and Penetration Tests

Vulnerability scans tend to be moderate to low-cost options, with the expenditure primarily based on the cost of tools. However, organizations should also account for the time for IT or security teams to install, configure, maintain and use the tool as well as to analyze the results.

Penetration tests tend to be higher in cost because they typically require outside vendors with highly trained penetration testing professionals. Fortunately, pentest costs can be controlled by organizations through preparation and scope control.

Benefits of Vulnerability Scans and Penetration Tests

Vulnerability scans and penetration tests both provide high value to any organization.

Vulscans identify vulnerabilities to be validated, categorized, prioritized, and mitigated. Automated tools can allow for quick and continuous identification of systems and services at risk to help organizations reduce opportunities for attacker exploitation.

Penetration testing verifies if vulnerabilities can be exploited and checks for other security gaps that might risk data exploitation or system damage. Effective pentests help organizations further harden systems and minimize opportunities for malicious attackers to cause damage.

Bottom Line: For Best Results, Use Both Vulscans and Pentests

When an IT team struggles to keep up with its workload, vulnerability scans and penetration tests seem like more trouble than they’re worth, especially if there’s robust perimeter security in place. However, with a single bad click, an attacker could be inside the organization and exploiting any available weaknesses.

By using both vulscans and pentesting, an organization can catch more oversights, mistakes, and security gaps. Organizations that really want to avoid the headaches, risks, and consequences of a breach will run both penetration testing and vulnerability scanning on a regular basis. Given the high cost of a data breach, prevention is money well spent.

Further reading:

• The 8 Best Vulnerability Scanner Tools for 2023
• Top Open Source Penetration Testing Tools
• Best Patch Management Software & Tools
• Top Vulnerability Management Tools

The post Penetration Testing vs Vulnerability Scanning: What’s the Difference? appeared first on eSecurityPlanet.

An effective vulnerability management policy can help with the cyclical process of discovering and managing vulnerabilities found within IT hardware, software, and systems. A documented policy enables IT teams to create a trackable and repeatable process that meets the expectations of executives and conforms to compliance requirements.

This article helps organizations of all sizes to start the policy creation process with a fundamental overview and a downloadable template.

• Free Vulnerability Management Policy Template
• How to Create a Vulnerability Management Policy in 4 Steps
• Common Vulnerability Management Policy Sections
• Top 5 Vulnerability Management Policy Best Practices
• Top 6 Benefits of an Effective Vulnerability Management Policy
• Bottom Line: Adopt Vulnerability Management Policies Today to Gain Benefits

Free Vulnerability Management Policy Template

As both an example and a starting point, eSecurity Planet has developed a free vulnerability management policy template for organizations to download, modify to meet their needs, and use. Notes of explanation or how to use the template are enclosed [between brackets] and these sections should be removed from final drafts.

The sample patching policy contains many sections, but not all sections will be required for all organizations and others might require more details. See Common Vulnerability Management Policy Sections below for more details.

How to Create a Vulnerability Management Policy in 4 Steps

All security policies share the same four key steps to create a policy, and they are explored in detail in IT Security Policies: Importance, Best Practices, & Top Benefits. For a functional patch management policy, we summarized these steps as:

1. Determine the Vulnerability Management Policy: Determine the responsible parties, who or what is covered, basic processes, validation methods, and reports.
2. Verify the Vulnerability Management Policy: Formally check that basic policy developed in step 1 satisfies the complete needs of the organization and any compliance requirements.
3. Approve the Vulnerability Management Policy: Draft official language and circulate the policy for approval by affected stakeholders and executives.
4. Review and Modify the Vulnerability Management Policy: Periodically review the policy to ensure it remains updated and continues to satisfy the evolving needs of the organization.

Don’t know where to start? Write down the current practice. Most IT teams have at least an informal process for obtaining and applying updates and patches, even if they are not written down or monitored.

While updates and patching remain a subset of vulnerability management, it at least provides a starting point for a more comprehensive policy. If the organization already has processes for double-checking configurations for networking equipment or open ports for server firewalls, those can also be added and broadened into a more comprehensive policy that encompasses more IT systems.

Although the basics of all IT security policy creation remains the same, vulnerability management is a frequently regulated requirement and organizations will need to apply extra caution in verifying compliance requirements. Additionally, the organization may be forced or choose to comply with compliance frameworks (NIST, PCI DSS, etc.) and industry standards.  The policy development team needs to check these external regulations and revise any rule that does not meet the compliance requirements.

Some compliance standards will be broad and vague, others will be detailed or have specific requirements. For example, for the CIS Critical Security Controls, the requirements are broad:

• 7.1 Establish and Maintain a Vulnerability Management Process: Create and maintain a documented vulnerability management process for enterprise assets. Review and update documentation annually, or when significant enterprise changes occur that could impact this safeguard.
• 7.2 Establish and Maintain a Remediation Process: Establish and maintain a risk-based remediation strategy documented in a remediation process with monthly, or more frequent, reviews.

The CIS requirement specifies a need for the existence of a vulnerability management process, but does not specify the content or requirements for what might need to be included in the vulnerability management process or risk-based remediation strategy.

The credit card industry PCI DSS requirements will be more specific. For example, a restaurant chain may already have a patching process and policy that covers their computers. However, PCI DSS may require vulnerability scanning for a network, evaluation of point of sale (POS) terminals, and periodic penetration testing.

Practical limitations also apply. In the restaurant chain example above, perhaps the patch management tool managing the current patch management policy cannot scan for network vulnerabilities or for updates on the POS terminals. The current patching tool will need to be upgraded or complemented by a vulnerability management tool, a vulnerability management service, or a penetration testing service that can meet the PCI DSS regulatory requirements.

Common Vulnerability Management Policy Sections

In the most effective vulnerability management policies, there are required, recommended, and bonus (aka nice-to-have) sections.

Required Sections

These core sections should be part of every policy related to Vulnerability Management:

• Scope: What IT assets and systems are covered by the policy.
• Vulnerability Management Authority: Who is in charge and responsible for the vulnerability management policy and its execution.
• Vulnerability Identification: Determine the type of vulnerability scans, penetration tests, and other methods required to identify vulnerabilities for mitigation.
• Vulnerability Evaluation: How to verify, evaluate, and rank the severity of the discovered vulnerability.
• Vulnerability Priority: How to prioritize vulnerabilities in the context of the risk of the exposed assets.
• Vulnerability Mitigation Guidelines: Define the vulnerability mitigation process from mitigation design and testing, scheduling the mitigation, and verifying successful mitigation.
• Mitigation Tracking and Exceptions: Requirements for tracking new, ignored, and mitigated vulnerabilities.
• Vulnerability Management Reporting: How to measure success and compliance with vulnerability management with reports, plus how and what to report.

Recommended Sections

These sections help to flesh out the vulnerability management policy with additional rules to protect the organization and to help prepare the IT department:

• Asset List: A list of resources or links to asset lists to help define the scope of systems and software tracked for patching and updating.
• Audit Controls and Management: Outline what reports, logs, and information can satisfy internal and external auditors to track vulnerability management success and verify vulnerabilities have been successfully mitigated.
• Enforcement: Penalties that the IT department may incur for failure to execute the vulnerability management process.
• Distribution: Who must or should receive the vulnerability management policy.
• Policy Version: Tracking versions and approvals of the vulnerability management policy.

See Top IT Asset Management Tools for Security to discover the best ITAM software and their key features.

Bonus / Nice-to-Have Sections: These sections do not change the core elements of the vulnerability management policy, but can make the policy more usable or comprehensive.

• Overview: Sets expectations and goals for the policy.
• Definitions: Technical term and acronym definitions can be useful to help non-technical readers understand the policy; generic terms can be defined for clarity.
• Compliance Appendix: Copies or links to relevant compliance frameworks with which the organization must comply.

Top 5 Vulnerability Management Policy Best Practices

All security policies share the same five best practices to create a policy, and they are explored in detail in IT Security Policies: Importance, Best Practices, & Top Benefits. For a functional patch management policy, we summarize these steps as:

• Focus on What to Do, Not How: By focusing on goals and objectives, a policy can set standards while allowing the vulnerability management team the flexibility to determine the best solution to meet those goals and objectives.
• Make Policies Practical: The vulnerability management team needs to be able to understand and implement the policy.
• Right-size Policy Length: Too short and the policy may not have sufficient requirements to be verified; too long and the policies may become over prescriptive or hard to understand.
• Keep Policies Distinct: Overlapping policies can introduce conflicts or become more difficult to keep current.
• Make Policies Verifiable: Effective policies require reports that prove the policy is both in place and effective.

The eSecurity Planet template seeks to be more comprehensive than some organizations may need, so every organization should review the template and add or remove content to fit their needs.

Beyond the standard best practices, vulnerability management benefits from additional considerations. For example, to maintain practical policies, exhibits or additional reports can be used to provide details that may need to be changed more frequently than the policy itself. For example, in the sample template, the IT team is required to maintain a list of the types of vulnerability scanners used to detect potential vulnerabilities.

Although every organization should begin drafting policies based upon existing practices and capabilities, this can lead to a trap of preserving incomplete processes into written policies. The organization should carefully examine their environment and ensure the policy reflects their true needs.

For instance, an IT team of a hospital may use a commercial tool to conduct vulnerability scanning of their IT environment, but the tool may only scan PCs, network devices, and servers, which leaves an enormous range of healthtech devices unscanned for vulnerabilities. Their policy requirements should not reflect the limited devices currently scanned, but the full range of devices that need to be included in the vulnerability management process.

Top 6 Benefits of an Effective Vulnerability Management Policy

Organizations of all sizes tend to avoid the hassle of documentation because the task seems overwhelming, tedious, and constraining. However, any effective security policy delivers six key benefits:

• IT Hardening: Creating and reviewing a security policy forces the IT and security teams to evaluate and potentially improve security practices.
• Employment Defense: In the event of a breach, IT and security teams can be protected if they can show compliance with an executive-approved written policy.
• Executive & Board Member Peace of Mind: Plain-language reports required by effective policies can illustrate the security posture of the organization clearly to executives and the board.
• Litigation Protection: Breaches happen, but lawsuits and regulators will be less of an issue if the organization can provide reports and other evidence showing compliance with policies that encompass reasonable security efforts.
• Compliance Easy Button: When the policy encompasses the compliance requirements, policy-required reports will automatically be available for auditors.
• Improved Operational Efficiency and Resilience: Effective policies ensure stronger security postures, eliminate configuration issues, and decrease the opportunities of attackers causing operational disruptions.

Bottom Line: Adopt Vulnerability Management Policies Today to Gain Benefits

No policy will be perfect, but organizations should start developing a vulnerability management policy as soon as possible so they can begin to reap the benefits, such as IT hardening and simplified compliance. The adoption of any policy will be an iterative process, so get a good version 1.0 in place and be prepared to revise it to meet real-world conditions.

More information on Vulnerability Management and Related Topics:

• IT Security Policies: Importance, Best Practices, & Top Benefits
• Vulnerability Management as a Service (VMaaS): Ultimate Guide
• 12 Top Vulnerability Management Tools
• Top Vulnerability Management Tools
• Patch Management vs Vulnerability Management: What’s the Difference?

The post Free Vulnerability Management Policy Template (+ Examples) appeared first on eSecurityPlanet.

A patch management policy formalizes the fundamental IT requirement that all systems and software should be patched and updated in a timely manner with rules that explain the requirements for patching and updates, clear processes that can be followed, reported on, and confirmed, and standards that can be tested and verified.

This article can help organizations of all sizes start the process with a fundamental overview and a template:

• Free Patch Management Policy Template
• How to Create a Patch Management Policy in 4 Steps
• Common Patch Management Policy Sections
• Top 5 Patch Management Policy Best Practices
• Top 6 Benefits of an Effective Patch Management Policy
• Bottom Line: Patching Policies Promote Premium Processes

Free Patch Management Policy Template

To kick start any patch management policy development, eSecurity Planet has developed a template that can be downloaded and modified. Notes of explanation or how to use the template are enclosed [between brackets] and these sections should be removed from final drafts.

Access the Sample Patch Management Policy Template.

The sample patching policy contains many sections, but not all sections will be required for all organizations and others might require more details. See Common Patch Management Policy Segments below for more details.

How to Create a Patch Management Policy in 4 Steps

All security policies share the same four key steps to create a policy, and they are explored in detail in IT Security Policies: Importance, Best Practices, & Top Benefits. For a functional patch management policy, we summarized these steps as:

1. Determine the Patch Management Policy: Identify responsible parties, who or what is covered, basic processes, validation methods, and reports; these often will be based on the current practices.
2. Verify the Patch Management Policy: Formally check to ensure basic policy developed in step 1 satisfies the complete needs of the organization and any compliance requirements.
3. Approve the Patch Management Policy: Draft official language and circulate the policy for approval by affected stakeholders and executives.
4. Review and Modify the Patch Management Policy: Periodically review the policy to ensure it remains updated and continues to satisfy the evolving needs of the organization.

Although the basics remain the same, patch management is a frequently regulated requirement and organizations will need to apply extra caution in verifying compliance requirements. Any rule that does not meet compliance requirements should be adjusted.

For example, a fire department might apply patches quarterly in practice. However, they might find that their state’s cybersecurity requirements require monthly patching and will therefore need to change their patching frequency to monthly to comply.

Practical limitations also will be very important and the policy team should work with the patching team to test the rules. If the IT team cannot comply with standards and requirements with their current resources, should the organization adjust the rules or the resources?

In the fire department example above, perhaps the volunteer fireman who used to apply the patches in their spare time will need to be replaced or assisted by a patch management tool or service that can meet the monthly regulatory requirements.

Common Patch Management Policy Sections

When writing your patch management policy, consider the required, recommended, and bonus (aka nice-to-have) sections.

Required Policy Sections

These core sections should be part of every policy related to patch management:

• Scope: What assets are covered by the policy and how to identify software and devices to be covered.
• Patch Management Authority: Who is in charge and responsible for the patch management policy and its execution.
• Patching Priority: How to determine the priority of patches and the basis for that determination based on severity, risk, and other factors.
• Patch Scheduling: The length of time between the patch release and the organization’s installation based upon priority.
• Patch Management Preparation: Backups and other system preparation that needs to be in place in case a patch fails and systems need to be restored.
• Manual Patch Management: How to apply patches manually — especially for systems that require downtime for maintenance. Explain the process for scheduling and obtaining approval for business system downtime.
• How to Handle Exceptions: Some patches will fail, some will cause business disruption, and some will simply not be needed. Explain how to recover systems and track exceptions and the process for mitigations to protect open vulnerabilities.
• Patch and Update Reporting: How to measure success and compliance with patch management with reports, including how and what to report.

Recommended Policy Sections

These sections help to flesh out the patch management policy with additional rules to protect the organization and to help prepare the IT department:

• Asset List: A list of resources or links to asset lists to help define the scope of systems and software tracked for patching and updating.
• Patch and Update Acquisition: Outline where to obtain valid patches and updates.
• Patch Testing: Test environments or testing of patches to verify they work and do not affect other business systems.
• Automated Patching: Organizations often express a preference for automated patching processes to reduce patching delays and burdens for IT teams.
• Audit Controls and Management: Outline what reports, logs, and information can satisfy internal and external auditors to track patch management success and verify patches have been successfully applied.
• Enforcement: Penalties to the IT department for failure to execute the patch management process, penalties to employees that interfere with the patch management processes, and how to handle assets that do not comply with the patch management policy.
• Distribution: Who must or should receive the patch management policy.
• Policy Version: Tracking versions and approvals of the patch management policy.

Bonus / Nice-to-Have Policy Sections

These sections do not change the core elements of the patch management policy, but can make the policy more usable or comprehensive:

• Overview: sets expectations and goals for the policy.
• Compliance Appendix: Copies or links to relevant compliance frameworks with which the organization must comply.
• How to Deal With BYOD and personal equipment.

Top 5 Patch Management Policy Best Practices

All security policies share the same five best practices to create a policy, and they are explored in detail in IT Security Policies: Importance, Best Practices, & Top Benefits. For a functional patch management policy, we summarize these steps as:

• Focus on What to Do, Not How: By focusing on goals and objectives, a policy can set standards while allowing the patch management team the flexibility to determine the best solution to meet those goals and objectives.
• Make Policies Practical: The patch management team needs to be able to understand and implement the policy.
• Right-size Policy Length: Too short and the policy may not have sufficient requirements to be verified; too long and the policies may become over prescriptive or hard to understand.
• Keep Policies Distinct: Overlapping policies can introduce conflicts or become more difficult to keep current.
• Make Policies Verifiable: Effective policies require reports that prove the policy is both in place and effective.

The eSecurity Planet template seeks to be more comprehensive than some organizations may need,  so every organization should review the template and add or remove content to fit their needs.

Beyond the standard best practices, patch management benefits from additional considerations. For example, when making patch management policies practical, use existing resources such as the Common Vulnerability Scoring System (CVSS) to determine risk and prioritize patches, but balance those resources with consideration of the organization’s specific context.

For example, some organizations only patch vulnerabilities with a score of 7 or above. Yet these ratings only show the risk of the vulnerability and must also be combined with the likelihood of exploitation and the value of the asset to the organization.

A data exfiltration bug of 8.0 on the marketing web server that only contains publicly released documents shouldn’t have higher priority than a 6.5 remote code execution vulnerability on the server with the company’s Active Directory (AD) services. The impact to the organization of a fully compromised AD simply would be too great to risk even modest possibilities of exploitation.

As a special consideration for patch management, many organizations deploy automated tools. These solutions work well and should be used; however, they tend to focus on certain parts of the IT ecosystem such as operating systems and common software such as Microsoft Office or Adobe Acrobat.

Tools often lack comprehensive coverage of third-party applications, firmware, internet-of-things (IoT) devices, networking equipment, backup applications, and more. The policy should not rely upon the tools or a patch management service to determine the asset list for the patching policy. The IT department must ensure that all resources that need patches are tracked and patched, even when applying the patch is difficult or may require manual patching.

Top 6 Benefits of an Effective Patch Management Policy

Many organizations feel that their undocumented patch management processes will not be improved by taking the time to put them into writing. However, this attitude overlooks six key benefits to any security policy:

• IT Hardening: The process of creating or reviewing security policies forces the evaluation and potential improvement of security practices.
• Employment Defense: Compliance with an executive-approved written policy provides coverage for the IT and security team in the event of a breach.
• Executive and Board Member Peace of Mind: Executive stakeholders can easily understand the organization’s security posture from plain-language reports required by effective policies.
• Litigation Protection: Reports and other evidence showing compliance with policies that encompass reasonable security efforts can provide protection against lawsuits and regulators in the event of a breach.
• Compliance Easy Button: Policy-required reports will automatically be available for auditors if the policy already encompasses the compliance requirements.
• Improved Operational Efficiency and Resilience: Effective policies, especially patch management policies, can detect end-of-life assets and ensure the installation of the latest features for ease of use and capabilities.

Bottom Line: Patching Policies Promote Premium Processes

A good patch management policy can provide a helpful checklist to help create an efficient, and reliable patch management process. The reduced cybersecurity risk from the patching and the improved communication from the reports will improve overall business processes and executive confidence.

However, patching cannot solve all problems. Patch management does not cover whether or not an organization has the correct software in place for their needs or if the software settings are properly configured.

Patch management policies provide a helpful part of an overall cybersecurity program but need to be combined with other critical policies and strategies to ensure a resilient organization.

More information on Patch Management and Related Topics:

• IT Security Policies: Importance, Best Practices, & Top Benefits
• Patch Management Best Practices & Steps
• Patch Management vs Vulnerability Management: What’s the Difference?
• Is the Answer to Vulnerabilities Patch Management as a Service?
• Best Patch Management Service Providers

The post Patch Management Policy: Steps, Benefits and a Free Template appeared first on eSecurityPlanet.

Policies provide a foundation of directives, regulations, rules, and practices that define how each organization will manage, protect, and distribute information. Additionally, regulators often cite a lack of formal policies as negligence as well as cause for higher fines and punishments after a breach.

This article will explore IT security policies through the following topics:

• What Is the Ultimate Goal of an IT Security Policy?
• The Importance & Objectives of IT Security Policies
• 6 Top IT Security Policy Benefits
• 3 Types of Security Policies
• 5 Best Practices for Writing IT Security Policies
• How to Create a Security Policy in 4 Steps
• Bottom Line: Create Policies to Improve Focus

What Is the Ultimate Goal of an IT Security Policy?

The ultimate goal of an IT security policy is to provide a formalized set of rules and policies to benchmark the IT and cybersecurity posture of an organization. This benchmark can be used for a variety of purposes, but will most often be used to:

• Demonstrate that risks are controlled and managed
• Meet compliance obligations
• Measure quality and capabilities of controls and staff
• Mitigate liabilities in the event of a breach

The Importance & Core Objectives of IT Security Policies

The U.S. National Institute of Standards and Technology (NIST) published An Introduction to Information Security (NIST SP 800-12) that declares:

“Information security policy is defined as an aggregate of directives, regulations, rules, and practices that prescribes how an organization manages, protects, and distributes information.”

To organizations new to written policies, starting the process of developing security policies can be intimidating. Yet all organizations deploy security strategies that act as unwritten and unofficial strategies. The key disadvantage to these unwritten security strategies is that when they fail to protect the resources, the organization will struggle to prove to regulators and juries that the IT and security teams executed an appropriate and sufficient cybersecurity strategy.

Written policies, especially those that require regular reports, naturally generate the evidence of compliance. They also show a formal security strategy that has been approved by corporate management.

Most importantly, written policies enable key IT security objectives that will have a daily impact on the organization by formalizing IT security strategies, goals, and objectives; managing user behavior; and measuring IT security success.

Formalize IT Security Strategies, Goals, & Objectives

Written policies provide written instructions that can be used to show the intended strategy of the organization. Most strategies focus on the key objectives of information security:

• Confidentiality: Allow access to specific data only to the users that need access
• Integrity: Prevent accidental or unauthorized modification of data in storage or in transit
• Availability: Provide continual access to data and systems for legitimate users

However, not all existing practices will always be found to incorporate best practices or adequately address these key objectives. The process of developing a security policy helps the IT security team to reflect on and improve the current practices as they are forced to write them down and compare them against goals and compliance requirements.

The policy creation process also helps to align the IT security goals and objectives with those of the business as policy goes through review by non-technical executives affected by the policies. In the end, the organization should enjoy the benefits of a policy that provides formal strategies, goals, and objectives that enable business growth within the protection of validated IT security strategies.

Manage User Behavior

Policies provide rules for acceptable use, access, and penalties for non-compliance for users of all kinds, from guest users on the public Wi-Fi network to administrative access of data center servers. These written policies then guide the settings within identity and access management (IAM) or privileged access management (PAM) tools.

Of course, IAM and PAM tools can be established without written policies, but written policies ensure consistent rules applied across the organization. The formal policies also provide a standard that can be compared against practices to determine if the practices are sufficient and within compliance.

Measure IT Security Success

An effective policy sets clear expectations for the IT security team. Reports required by policies should show compliance with the policy and enable the IT security team to measure their success to meet the goals of the policy.

While employees always strive for success, falling short can also be used to justify increases in resources. For example, if reports required by the patch management policy show that the patching of critical updates takes longer than desired, the management can consider adding more resources or outsourcing some functions.

6 Top IT Security Policy Benefits

Organizations of all sizes tend to avoid the hassle of documentation because the task seems overwhelming, tedious, and constraining. However, an effective security policy delivers six key benefits: IT hardening, employment defense, executive and board member peace of mind, litigation protection, compliance easy button, and improved operational efficiency and resilience.

IT Hardening

Developing an effective security policy will naturally enable a security process that hardens the IT environment against attack. Although some might consider compliance the primary motivation for written policies, the process of creating the policy forces security teams to evaluate systems more rigorously and address issues that might be overlooked in day-to-day operations.

Employment Defense

Despite the best efforts of the IT team, people will still click on phishing links, zero-day vulnerabilities will still be discovered, and company resource constraints may require some vulnerabilities to remain exposed. Although compliance with security policies can reduce the risk, attacks may still succeed in damaging the organization.

In many cases, executives may initially look for a scapegoat to take the blame for an incident and IT or security teams often will be targeted. An IT or security team that can demonstrate compliance with an executive-approved security policy also shows that best efforts were made to prevent possible breaches. This documentation can protect employees against unfair treatment after a breach and protect their jobs.

Executive & Board Member Peace of Mind

Effective security policies require reports that can be shared with non-technical executives to enable confidence in the IT and security teams. Policies reduce technical details into numeric reports and easy-to-understand metrics that make the status of security processes understandable and accessible to non-technical executives.

Clear reports enable smooth communication with executives and the board of directors of an organization to help build confidence in the security posture of the organization. Such reports not only demonstrate that the organization considers information security a high priority, but also build confidence that can translate into improved support for additional resources.

Litigation Protection

In the event of a breach or successful cybersecurity attack, government agencies or stakeholders may attempt to pursue legal action against the organization. Fortunately, legal standards generally only require “reasonable efforts,” which can be supported with the documentation from an effective security policy and the reports that demonstrate the policies have been implemented.

Organizations without formal reporting and processes will need to scramble to figure out what documentation may be required to support past efforts and then hope they still have the archival logs or other data to create that documentation. Organizations with formal documentation and reporting will already have a significant portion of their evidence ready to present with minimal effort or business disruption.

Compliance Easy Button

An effective security policy should be designed to reflect the compliance requirements of the organization. Auditors always ask for written policies to help them easily understand the objectives of the organization and the type of evidence they can expect to receive.

Fulfilling a written policy that has already conformed to a compliance framework makes it easy for the organization to satisfy the regulatory requirements. The organization’s regular internal reports will naturally provide evidence of compliance without any additional effort or steps.

Improved Operational Efficiency & Resiliency

An effective portfolio of security policies can help the organization:

• Recognize end-of-life hardware and software for replacement
• Quickly recognize infrastructure under strain from attack, failure, or workload
• Verify settings and integration between systems
• Ensure resilience of systems to minimize downtime
• Ensure integrity and availability of data
• Document uptime for internal and customer service level agreements (SLAs)

The survival of the business depends upon uptime and protected assets. Formalized documentation of security processes provide an internal checklist to protect assets, maintain uptime, and minimize mistakes.

Written policies also help with IT personnel transitions by providing documentation of expectations and reports of past activity. These will combine to save time by helping new IT employees grasp the status and expectations of the organization with less training.

3 Types of Security Policies

When developing a comprehensive set of security policies, an organization can get lost in the details. The SANS institute alone provides templates for more than 60 different policies! These granular policies help a mature organization, but an organization just getting started needs a bit more focus.

The three types of policies defined by the National Institute of Standards and Technology (NIST) Special Publication 800-12 include program, issue-specific, and system-specific policies.

Program policies provide strategic, high-level guides of the overall information security program. These can be singular programs, such as this program policy for the University of Arizona, that provide an overview of the goals and objectives of the security program. These policies are intended to be evergreen and not require frequent updates, and often will reference other types of policies in an appendix that can be updated more frequently without requiring updates for the program policy itself. Program policies tend to be too vague to measure or verify. Other types of non-security program policies might include business continuity or risk management.

Issue-specific policies provide directed guides for specific components of the information security program, but at a level of abstraction that describes goals, objectives, and reporting requirements instead of naming specific tools, techniques, and settings. These policies need to be reviewed periodically to ensure they remain current in the face of organizational, technological, or compliance changes. Examples of issue-specific security policies include network security, password, endpoint, and encryption policies. Some issue-specific policies may fall under multiple program policies such as data backup (security, business continuity) or acceptable-use policies for employees (security, HR).

System-specific policies describe how issue-specific policies will be applied and enforced on specific systems. For example, how the network security, user access, vulnerability management, and change control policies might be enforced for a specific firewall or a classification of servers in a data center. These detailed policies will be enforced through settings on the devices or through centralized software that can manage the devices.

Common Issue-Specific Policies

For an organization beginning to implement security policies, the focus should start with relevant issue-specific policies. The specific key policies will depend upon the organization. Although many will start with access, network, endpoint, and password policies, these priorities reflect a traditional IT environment. A small virtual office of five stock brokers using Google Workspace might instead focus on policies for data security, data backup, and remote access policies to comply with SEC and FINRA requirements.

Here are 10 common issue-specific and related policies:

• Acceptable Use Policy (AUP)
  • Instructs the organization how end users are permitted to use IT systems and services (computers, networks, data, internet, email)
  • Related policies: security awareness training policy, executive and administrative access policy
• Access Policy
  • Instructs an organization how to classify, enforce, and manage access, authentication, and accounting of users across various system and data classifications
  • Related policies: physical access policy, system access policy, privileged access policy, remote access policy (may include remote desktop [RDP] or virtual private network [VPN] policies), password policy, identity and access management policy, multi-factor authentication (MFA) policy, vendor management policy
• Application Security Policy
  • Instructs an organization how to secure code development and the connections to other corporate resources
  • Related policies: application programming interface (API) security policy, database security policy, application development policy
• Cloud Security Policy
  • Instructs an organization how to secure access, data, networks, and applications on cloud-based resources
  • Related policies: cloud use policy, software as a service (SaaS) security policy, infrastructure as a service (IaaS) policy
• Data Management Policy
  • Instructs an organization on the retention, management, and security of different classifications of data
  • Related policies: data retention policy, insider threat protection policy, encryption and cryptography policy, information security policy, data and asset classification policy, regulated data policy
• Disaster Recovery Plan
  • Instructs an organization how to proceed with business recovery under various emergency circumstances
  • Related policies: Backups policy, redundancy policy, capacity planning policy, stress testing policy 
• Endpoint Security Policy
  • Instructs an organization how to secure access, data, and applications on user-accessed endpoints that connect to the organization’s network and other resources
  • Related policies: endpoint security policy, bring-your-own-device (BYOD) security policy, mobile device policy, server security policy, container security policy
• Incident Response and Monitoring Policy
  • Instructs and organization how to detect, identify, validate, track, mitigate, remediate, and manage potential security incidents
  • Related policies: log tracking and audit policy, attack-specific policies (ransomware, DDoS, etc.), data breach response policy
• Network Security Policy
  • Instructs an organization how to secure access, data flows, and monitor connections between users and data
  • Related policies: firewall security policy, network security policy, email protection and security policy, wireless network and guest access policy
• Vulnerability Management Policy
  • Instructs an organization how to locate, validate, prioritize, mitigate, and track vulnerabilities
  • Related policies: patch management policy, change management policy, vulnerability scanning policy, penetration test policy

5 Best Practices for Writing IT Security Policies

An organization can create an effective security policy by following five key best practices, focus on what to do rather than how, make policies practical, right-size policy length, keep policies distinct, and make policies verifiable.

Focus on What to Do, Not How

Technology changes so quickly that a policy will usually not be able to keep up with the technical details such as security tools and IT architecture specifics. When writing any IT-related policy, the policy should focus on the high-level goals, key deliverables, and compliance requirements.

The IT team will then use those requirements in combination with their budget and personnel constraints to develop an appropriate solution. Too many details either force the policy to be updated constantly or lock the IT team into obsolete tools, practices, or perspectives that may ultimately undermine instead of strengthening security. Where needed, exhibits or additional reports can be used to provide details that may need to be changed more frequently than the policy itself.

Some organizations will consider system-specific policies an exception that requires detailed descriptions of tools, settings, and allowed users. However, others keep system-specific policies at a high level and maintain specific work instructions that maintain the details. This is a matter of preference for the individual organization.

Make Policies Practical

Security policies won’t be successful if they do not work for the team responsible for the policy, are not understandable, or don’t fit the organization. In some cases, these objectives will come into conflict and the policy creating team will need to work with stakeholders to enable an effective balance.

Stakeholder-Friendly Policies

Stakeholder-friendly policies will be more readily adopted by IT and security teams responsible for implementing the policy or the users affected by them. When policies demand too many changes, impractical requirements, or exceed the resource constraints, the policies may be undermined, circumvented, or ignored.

To enable stakeholder friendly policies, don’t dramatically change practices or add unnecessary details and instructions. Unless required by compliance or best practices, build off of existing practices to enable rapid adoption by both affected users and the teams enforcing the policy.

Additionally, use titles instead of names and tool categories instead of specific security tool names. This prevents the need to change the policy for every tool change, personnel change, or outsourcing engagement.

Understandable Policies

Not all readers have English as their first language, especially in international companies attempting to standardize policies worldwide. When drafting policies, use simple language written plainly for both the non-technical and non-legal audience.

During the drafting process, the document should be distributed to executives, legal counsel, and key staff members responsible for implementing the policy. Any confusion, vagueness, or uncertainty should be addressed and eliminated before approving the policy.

Fit Organization Needs

Tools and processes must fit the true needs of the organization and should not be followed blindly or without thought. Although every organization should begin drafting policies based upon existing practices and capabilities, this can lead to a trap of preserving incomplete processes into written policies. The organization should carefully examine their environment and ensure the policy reflects their true needs.

For example, an IT team of a hospital may use a commercial tool to conduct vulnerability scanning of their IT environment, but the tool may only scan PCs, network devices, and servers, which leaves an enormous range of healthtech devices unscanned for vulnerabilities. Their policy requirements should not reflect the limited devices currently scanned, but the full range of devices that need to be included in the vulnerability management process.

Policies should also have minimal exceptions and those exceptions should be documented. If the C-suite executives insist on being exempted from the password policy, then they should also be prepared to justify that exemption in court once the company suffers a breach. Just like employees, senior management should understand, agree with, and be bound by security policies.

Right-Size Policy Length

Policies should be no longer and no shorter than needed. IT and security teams often favor shorter policies because the lack of defined requirements provide them with maximum flexibility for execution. However, the lack of defined requirements often leaves gaps in requirements or makes the policies hard to verify for management or compliance.

On the other hand, attorneys often feel compelled to lock down as many details as possible to make verification more simple and to clarify as many points as possible. Unfortunately, this often tends to lead to over-prescriptive requirements that lock an IT team into the requirements of the moment and leave little room for keeping up with a dynamic IT environment.

These opposing forces must be balanced. IT teams, executives, and attorneys must work together to enable a document with sufficient detail so that the IT team can clearly demonstrate compliance with the policy, but not so much detail the policy becomes a shackle on the vulnerability management process.

Keep Policies Distinct

Security and compliance teams will look for information in expected policies. For example, to look up policies regarding endpoint protection, most would first look for an overall security policy or a specific endpoint protection policy. To bury the information in a vulnerability management policy is unintuitive and may lead to confusion.

Security policy creation teams should also avoid the temptation to copy-paste elements from other existing policies, such as a password policy, into semi-related policies (remote access, endpoint protection, etc.) for completeness. Unless the documents are linked to enable automatic updates, the copied information will rapidly become out of date. Instead of inserting sections of the other existing policies, reference them as needed.

Policies should be individually comprehensive with minimal overlap. Overlap with other policies can lead to language conflicts, uncertainties, and gaps in compliance and security. In the event an organization decides to mix policies, an index or guide should be produced to help team members locate policy information rapidly.

Make Policies Verifiable

Vague policies with nebulous, undefined deliverables satisfy only the requirement to have a policy, not the requirement to have a useful one. Effective policies define the deliverables clearly so that the IT or security team will have no difficulty satisfying policy requirements.

The security process should be measurable and testable to prove compliance with the policy as well as any relevant compliance frameworks. Reporting requirements should document metrics for measurement, define needed evidence (log files, vulnerability scans, etc.), the frequency of reports, and who should receive the reports.

How to Create a Security Policy in 4 Steps

Organizations large and small can create a functional security policy by following four key steps: determine the security policy principles, verify the vulnerability management policy, approve the vulnerability management policy, and review and modify the vulnerability management policy.

Determine the Security Policy Principles

The person or team drafting the policy will first need to determine the critical rules and steps within the vulnerability management policy. For example, some fundamental questions to answer include:

• Who is responsible for the security process or standard?
• Which people, assets, or systems will be covered by the security process or standard?
• What are the security processes, standards, components, and priorities for each?
• How can the security process or standard be validated and verified?
• What reports are needed to establish and measure success and compliance for the security process or standard?

Don’t know where to start? Write down the current practice. Most IT teams have at least an informal process for nearly all security practices, even if they are not written down or monitored. This first draft can simply be notes. Formal paragraphs and language can come later after the basic principles have been outlined.

Verify the Security Policy

With the basic rules or principles in place, the policy development team should verify them against external requirements and practical limitations.

External Security Policy Requirements

Every organization faces general or specific regulations from international, federal, state, or local governments.  Additionally, the organization may be forced or choose to comply with compliance frameworks (NIST, PCI DSS, etc.) and industry standards.

Some compliance standards will be broad and vague, but others will be detailed or have specific requirements. The policy development team needs to check these external regulations and revise any rule that does not meet the compliance requirements.

Practical Security Policy Limitations

Most organizations have limited resources, and often idealized policies do not take these limitations into account. The security policy development team should test the proposed rules with the IT and security teams. If these teams cannot comply with standards and requirements with their current resources, the organization will need to adjust the rules or resources as necessary.

For example, when developing a patch management policy, the IT team may not have the ability to meet the patch management schedule requirements with the current tools and staffing resources. The organization will then need to consider adjusting the schedule (if allowed by compliance requirements) or adding additional resources (tool upgrades, staffing increases, outsourcing, etc.).

Approve the Security Policy

After verification of the proposed security policy rules, the rules need to be formalized and approved by the organization’s management. Now is the time where rough notes need to be revised into formal paragraphs, tables, and appendices.

Once drafted, pass the policy to corporate management and legal counsel for review and approval. The policy can be modified as required and the final draft should be signed by the executives of the organization to ratify and acknowledge the requirements.

Review & Modify the Security Policy

Even though the security policy is approved in step three, the organization, IT resources, and regulations will change over time. All policies should be living documents that evolve as the organization changes. and should be periodically reviewed and updated. Generally, policies will be reviewed on a fixed schedule (quarterly, annually, bi-annually, etc.); however, notable events such as dramatic changes to IT architecture, adopting significantly different security tools, or a security breach may merit off-schedule review.

Bottom Line: Create Policies to Improve Focus

Organizations tend to view formal paperwork as a burden, but effective IT security policies enable organizations to improve their security posture, spend less time on compliance, and to eliminate many worries. With current and effective policies, Large and small businesses, non-profit organizations, and even government entities can validate their presumed security posture and gain the confidence to focus on challenges more critical to their core mission. 

To read more about related topics, consider:

• Vulnerability Management Policy: Steps, Benefits, and a Free Template
• Patch Management Policy: Steps, Benefits, and a Free Template

The post IT Security Policy: Importance, Best Practices, & Top Benefits appeared first on eSecurityPlanet.

Either case presents challenges, but to maximize the value of a penetration test, the organization must balance cost savings with quality. A low-quality penetration test can be an enormous waste of money that leaves the organization unaware of exploitable vulnerabilities.

Use the links below to jump ahead to a specific topic of interest:

• Penetration Testing Value and Return on Investment
• Self-Administered Tests: Challenges and Maximizing Value
• Third-Party Vendor Tests: Challenges and Maximizing Value
• Criteria and Requirements for a Pentest Quote
• Cost Cutting Cautions
• Bottom Line: Execute a Penetration Test to Obtain Maximum Value

Penetration Testing Value and Return On Investment

The value of a penetration test will be different for every organization and will be based on the calculation of the return on investment (ROI). ROI compares the cost of the benefit against the cost of the investment, or in the case of penetration testing, the exploitation cost divided by the test cost:

ROI = Expected Cost of Exploitation / Cost of Penetration Test

Here, the expected cost of exploitation would be the cost of data breaches, business operations disruptions, and IT system damages from any potentially successful attack on the systems tested. This number will be different from organization to organization and system to system.

Consider the wide variance in the potential costs for the following examples:

• An hour of disrupted internet for a grade school on vacation
• An hour of disrupted internet for Amazon on Black Monday
• A data breach on a steel plant’s time card database (does not include employee information)
• A data breach from a drug researcher’s laboratory computer
• Command and control access to the one computer in a dry cleaning retail store
• Command and control access to a laptop belonging to the VP of finance for a fortune 500 company

The more valuable the company resources, the more investment that should be made in penetration testing — even if those tests result in no discoveries. Scott Lyons, CEO of Red Lion notes, “The value of any test is less about if the pentester can get into the system and much more about if the system can prove its value to the business in resilience, ability to protect the system, or ability to provide alerts to security teams.”

“The value of any test is less about if the pentester can get into the system and much more about if the system can prove its value”

– Scott Lyons, CEO of Red Lion

An organization might be tempted to use in-house IT teams to perform penetration testing to save money. In some cases this will be reasonable, and when in-house expertise is available, it should certainly be done to reduce the vulnerabilities before hiring outside expertise.

Yet, outside teams bring new perspectives, different experience, and specialties that can uncover overlooked vulnerabilities. Outside vendors should be engaged periodically and may even be required under some compliance standards such as for PCI DSS.

Self-Administered Tests: Challenges and Maximizing Value

Organizations seek to use internal resources for penetration testing because they assume that the testing will be less expensive. However, the inherent challenges of self-administered tests conceal hidden costs to the organization that can only be offset by careful considerations.

Self-Administered Test Challenges

The primary challenges to self-administered penetration tests consist of hidden costs, internal expertise recruiting challenges, internal expertise myopia, penetration tool selection, and conflicts of interest. Unless an organization addresses these issues, penetration tests will likely be of lower quality than desired.

Hidden Costs of Self-Administered Tests

Managers often pursue self-administered penetration tests because the employee costs are considered to be “paid for” by salaries. When comparing against the costs of external penetration tests, these managers will use a zero for internal penetration testers because they have no additional expenses.

However, while valid for cash flow, the perspective is short sighted. The costs should at least include the allocated salaries of the internal teams and also include opportunity costs of projects that must be sidelined.

For example, conducting a penetration test might prevent the team from working on IT improvements or security improvements, or even monitoring and responding to security threats. These delays can increase the risk to the organization which increases the potential for breaches and other damages.

Internal Expertise Recruiting Challenges

A profound shortage of IT and cybersecurity expertise continues to increase recruitment and retention costs for all organizations. Unfortunately, this leads to most internal IT and security teams being composed of generalists because the increased costs to obtain expertise in a specific area, such as penetration testing, cannot be justified unless the expert will be using their expertise full time. When does it ever make sense to use a $300 per hour resource to do a $100 per hour job?

However, this also means that when the time comes to apply expertise, the generalists will need to perform more research to understand tools, take longer to set up and conduct tests, and may even pursue tests that don’t make sense because they don’t recognize it. The lack of expertise creates expensive inefficiencies that cannot be anticipated or even measured without comparison to an expert performing the same task.

Generalists will make more mistakes, be unable to recognize mistakes, and lack familiarity with compliance and other special needs. An organization will not recognize the hidden costs of mistakes and non-compliance until it is too late.

Internal Expertise Myopia

Even the largest organizations with the resources to hire penetration testing expertise will only be able to hire experts in a few areas. These experts will deeply understand only their focus, which will lead to penetration testing myopia — they really know what they know but may not be familiar with techniques or vulnerabilities outside of their expertise.

For example, a network and firewall penetration testing expert will be unlikely to also have expertise to test web applications for SQL injection, or to understand internet-of-things (IoT) firmware hacking. While it is perfectly acceptable for this expert to handle internal penetration testing on the corporate network, it would be unfair and unreasonable to hold this expert responsible for testing other types of infrastructure.

Penetration Tool Selection 

Most organizations only have the resources to perform penetration tests periodically, so the cost of penetration tools will be spread out over a much smaller number of tests than a penetration testing firm. This may cause an organization to lean toward open source tools, but these tools tend to be more barebones and require more expertise or time to use. 

Most internal penetration testing teams lack the time to master and deploy a full range of network and application penetration testing tools. An organization will need to pick a limited set of tools that tend to enable testing on a subset of possible tests.

Conflicts of Interest 

The IT and DevOps staff created the environment, so will they be willing to honestly present that the IT resources or applications were deployed incorrectly? Will there be flaws hidden from management and secretly fixed? 

Another type of conflict appears when managers apply pressure to cut tests short and check-box validate the results either because of impatience, operations concerns, or a lack of devotion to a secure posture. Both conflicts of interest tend to be hidden and difficult to detect.

Self-Administered Penetration Test Considerations to Maximize Value

For many organizations, the challenges of self-administered penetration tests can make outsourcing penetration testing less expensive and more efficient in the long run. However, for those organizations pursuing self-administered penetration testing, the value of the tests can be maximized by alignment of testing with resources and careful planning.

Align Testing with Resources

To align testing with resources an organization will realistically match their expectations with the budget, security staffing, penetration testing tools, etc. This will be a moving target particularly sensitive to budget and security staff workload. An organization must not force staff to perform beyond their capabilities or it will drive conflicts of interest and myopia.

Careful Planning

Careful planning involves splitting up or rescheduling penetration testing to overcome resource constraints. Even when pursuing testing, make sure sufficient resources are available to maintain key cybersecurity functions (incident response, monitoring) and to make progress with key maintenance projects.

The most obvious example would be peak operations. During peak operations, the organization cannot tolerate downtime and most staff will be fully consumed with supporting the delivery of the organization’s product or service.

Also read:

• 9 Best Penetration Testing Tools
• 24 Top Open Source Penetration Testing Tools
• How to Implement a Penetration Testing Program in 10 Steps

Third-Party Vendor Tests: Challenges and Maximizing Value

Many organizations prefer to perform in-house penetration tests because of the challenges with third-party vendors. However, outsourcing to experts saves enormous time and overcomes IT expertise hiring constraints.

An organization can improve the value and reduce the cost of their penetration testing by executing IT fundamentals, adopting long-term contracts, prioritizing partial penetration tests, or performing rolling penetration tests.

Third-Party Vendor Test Challenges

When deciding to work with a third-party vendor, most organizations will be primarily concerned with confidentiality, cost uncertainty, and how to select a penetration testing vendor. Fortunately, to some degree, these issues present themselves with selecting any vendor (elevator maintenance, office cleaning, etc.), so purchasing can provide basic guidelines and the organization can focus on the penetration-testing-specific aspects of these issues.

Confidentiality

All organizations protect a variety of secrets such as proprietary technology, secret processes, personal identifiable information (PII), credit card information, and IT security details. Using a third-party penetration tester runs the risk of exposing those secrets through the hacking process.

While contracts provide a mechanism for legal consequences, the more important issue is trust. Organizations need to thoroughly investigate potential partners to verify a professional track record.

Cost Uncertainty

The cost of a penetration test can vary wildly. Although our research has determined an average penetration testing cost of $18,300, the range of pricing spans from several hundred dollars to $100,000. 

The difference in pricing relies upon key factors such as the number of systems tested, the experience of the penetration testers, the type of systems tested, the type of penetration test, and more. Buyers should expect to have several rounds of communication with the potential penetration testing vendors to lock down the details needed for clear and predictable pricing.

How to Select a Penetration Testing Vendor

Buyers also stress about trying to evaluate the expertise of penetration testers without expertise of their own. Fortunately, buyers have very clear options for evaluation that do not require expertise. 

References and penetration testing credentials provide an excellent starting point to evaluate a vendor’s history and qualifications. Buyers can then request proposals and sample reports to evaluate if these resources can be easily understood by both executives and the in-house cybersecurity team.

When trying to decide between a handful of highly qualified vendor candidates, the buyer can also pursue a test run where each vendor performs the same initial task. These evaluation options are explored in more detail in How Much Does Penetration Testing Cost? 11 Pricing Factors. 

Third-Party Vendor Tests: Maximizing Value

An organization may be well prepared to limit costs through careful control of the factors that affect penetration testing costs and still have many opportunities to further reduce penetration testing costs. Some techniques cut the costs of a test, such as executing IT fundamentals or long-term contracts. Other techniques control costs or enable low cost penetration tests such as prioritizing partial penetration tests or executing rolling penetration tests.

Execute IT Fundamentals

Penetration testers are much more expensive than internal IT teams and therefore should not be used to perform basic vulnerability scans or asset discovery. Yet many organizations fail to execute these fundamentals and waste money overpaying hacking experts to provide basic asset discovery and vulnerability discovery reports.

To save money on a penetration test, an organization’s IT and security teams should ensure the completion of IT fundamentals such as:

• Regular asset discovery to capture new or rogue devices
• Maintained and current inventory of IT infrastructure components, devices, and applications
• Track changes to IT infrastructure components
• Regular vulnerability scans to detect known vulnerabilities and misconfigurations
• Effective patch and vulnerability management to eliminate or mitigate known security risks rapidly
• Regular security education regarding phishing, social engineering, and other attacks targeting the organization’s employees

Long-Term Contracts

Long-term contracts, sometimes called managed penetration testing services, offer a term contract for a certain number of tests  or types of test for an extended time period. These contracts, often annual, can specify the specific penetration tests conducted or simply offer a number of tests to be performed per month. These contracts offer discounted rates in exchange for the committed spending.

An organization should definitely consider their long-term penetration pest needs. For example, compliance typically requires regular penetration tests, so a long-term contract can help control the costs. 

Similarly, a growing organization frequently adds new network infrastructure, makes significant modifications to its applications, or establishes new offices. Each of these events would merit a penetration test, so a long-term contract with controlled pricing ensures the company will not delay needed penetration tests because of budgetary issues or lengthy contract negotiations.

Organizations with lower resources can obtain a different type of long-term contract that uses a retainer fee for a limited number of tests at a negotiated price over a fixed time period — for example, eight network tests over a one-year period with an option for more tests at listed prices. The company can expand testing as needed without the commitment for a large number of monthly tests.

Prioritizing Partial Penetration Tests

If an organization cannot afford a penetration test of the full environment, partial testing can be an option to reduce costs. However, organizations will then be faced with the decision of how to define the subset of the environment to test.

Priority should be based on the risk profile of the business. For organizations without an effective risk management program, the organization should focus on the most valuable resources that are the most likely to be targeted by malicious hackers. 

Other factors that apply can be priorities to test:

• Publicly accessible IT infrastructure components
• Key security tools or controls protecting the most systems or protecting regulated or proprietary data
• Systems with known vulnerabilities to test the controls protecting them.

Rolling Penetration Tests

Instead of testing everything at once and incurring the huge bill, the organization can do rolling engagements of quarterly or monthly tests. This will be more easily applicable for testing discrete web applications than for complex websites and IT environments where the test scope can be more clearly defined. 

However, when testing a more complex environment, a pentester can always reach a defined milestone in the testing (certain number of IP addresses, certain number of applications, etc.) and provide the organization with a list of untested components for a website and assets or network segments for a network. The organization can then determine what will be in scope for the current test and delay testing other components for the future.

Criteria and Requirements for a Pentest Quote

To ensure clear and reliable pricing, buyers should also prepare clear criteria and requirements for the penetration test. To start, buyers can consider the factors that affect penetration test costs within the control of the organization. Then prepare guidelines for the penetration test company to enable faster and more accurate quotes, particularly for the following factors:

• Scale and Scope: the size of the organization to test, especially the number of IP addresses t, network segments, applications, and people (for social engineering) in scope
• Penetration Test Type: black box, gray box, or white box penetration testing
• Compliance Requirements: any tests or reports required to meet compliance standards (PCI DSS, HIPAA, etc.)
• System Type: types of systems to be tested, such as endpoints, mobile devices, applications, networks, databases, cloud infrastructure, etc. 
• Future Opportunities: disclose any needs for multi-month, multi-year penetration testing engagements
• Special Requirements: outline any needs for off-hour testing, physical security tests, social engineering, and similar special requirements
• Contract Type: disclose if the bid should be for a fixed cost bid or a time and materials bid

For larger engagements, a helpful aspect to consider is key performance indicators (KPI). An organization can define stages, KPIs, and intermediate status reports to check for progress and results during the penetration test. These intermediate status reports can determine if the testing should proceed or if the test should be paused so the organization can remediate problematic systems or make other accommodations. 

For example, for a large ecommerce website, the penetration testing team might be asked to report any dangerous vulnerabilities before attempting to verify them through active exploitation. If the pentest team reports that they might be able to erase data in the transaction database, the company will likely want a chance to create a test environment for the penetration test team to test the exploit rather than risk the production database.

Cost-Cutting Cautions

Some cost cutting options, such as executing IT fundamentals, strengthen the security profile of the organization. However, performing partial or rolling penetration tests to cut costs narrows the scope of the penetration testing, which risks exposing the organization to unknown vulnerabilities hidden in the excluded IT systems.

For example, an oil refinery may decide to focus on the IT systems of the main office building containing all employee computers and servers and exclude any devices or network segments running to the refinery or pumping facilities of the plant. This exclusion may prevent the penetration testing team from discovering rogue computers and industrial internet of things (IIoT) devices such as wi-fi enabled pump controls installed within the facility.

Every organization needs to temper their cost cutting against the possible risks. These risks can be minimized by ensuring that penetration testing will eventually be performed within an appropriate time period (quarterly, annually, etc.) on all company systems and network segments. 

Bottom Line: Execute a Penetration Test to Obtain Maximum Value

Although organizations might want to maximize their ROI from a penetration test, buyers must avoid delaying projects for incremental gains. In the end, execution of the penetration test delivers value and additional optimization will only leave unknown vulnerabilities exposed for exploitation by attackers.

Organizations need to move forward with the best option possible at the time the penetration test needs to be performed. During each test, the organization will gain improved security and experience that can be used to further refine and improve the ROI of future penetration tests.

For more reading on penetration testing, consider:

• Penetration Testing vs. Vulnerability Testing: An Important Difference
• Penetration Testing Phases & Steps Explained
• Businesses Secretly Pentest Partners as Supply Chain Fears Grow

The post How to Maximize the Value of Penetration Tests appeared first on eSecurityPlanet.

Additionally, each organization will have unique needs, and penetration testing companies will have varying levels of skills, so the range of penetration testing can start as low as a few hundred dollars and on the upper end can even exceed $100,000. This wide range can be confusing and frustrating for an organization trying to budget for a penetration test. However, this broad range can be narrowed and understood in the context of the factors that affect penetration costs.

This article will provide insight into penetration test pricing, 11 key factors affecting pricing, information needed for a penetration testing quote, and how to pick a penetration testing vendor. Use the links below to jump ahead to the topic of interest:

• Average Penetration Testing Costs
• 11 Key Factors That Affect Penetration Testing Costs
• Information Needed for a Penetration Test Quote
• How to Pick a Penetration Test Service Provider
• Bottom Line: Appropriate Penetration Testing Benefits Outweigh Costs

Average Penetration Testing Costs

Our average calculation of $18,300 comes from polling 10 different penetration testing information sources. Most sources are penetration testing companies; however, some IT purchasing advisory firms are included.

As noted in the introduction, these averages hide some variances in the types of testing:

These ballpark costs can be used to extrapolate the potential costs for an organization, but organizations need to also understand the inherent problems with this average pricing, standardized versus customized pricing, and biases in published pricing.

The Problem With Average Pricing

Average pricing can be misleading because penetration testing costs often use different units, or what is covered by a penetration test:

• A specific number of IP addresses
• The engagement based on an assumed company size
• A single scan
• A single application
• A single website, but all included web applications

The difference in coverage between these different coverages can lead to vastly different price ranges that may confuse inattentive readers. Buyers need to carefully review the details and not be misled by the numbers.

Standardized vs Customized Pricing

Some of the conflicts in average pricing come from differences of opinion between standardized and customized pricing. Some vendors will claim all pricing needs to be customized for the client and others will note that standardized pricing indicates a trustworthy vendor.

Both claims are incomplete unless one considers the fine print. Some standardized pricing relies upon standardized penetration tests with rigidly defined scopes. This testing limits the vulnerabilities tested or the number of IP addresses or applications scanned.

Customers certainly prefer the certainty of flat-rate, standardized pricing, but often overlook the reality that in addition to strictly limited tests the vendor typically also needs to embed contingency costs into the pricing. Standardized pricing can often be more expensive than customized pricing for the same work.

Either way, pricing is only one consideration. A buyer needs to read the fine print on published prices and statements of work to understand if the penetration tests will meet their needs.

See the Best Penetration Testing Tools

Biases in Published Pricing

Prices published on websites inevitably contain unintentional biases or misleading information to deliver specific marketing messages in favor of the vendor. A buyer needs to understand the motivation of the vendor to understand the context of the information.

For example, consider RSI, a well established penetration testing consultancy. Their website puts the cost of a “high quality, professional pen test” at $10,000-$30,000. This information serves two goals. First, it sets a high bar for costs for the customized pen testing RSI prefers to perform so customers can be prepared. Second, it positions any lower-cost penetration tests as low quality and unprofessional. In many cases this will be accurate, but not always.

On the other hand, consider Astra, a company offering standardized application testing. Their website publishes penetration test costs as low as $400 or $500 for some types of penetration scans. They even show “average penetration testing cost” for websites or apps to start at $2,500, cloud infrastructure to start at $600, and mobile apps to start at $1,500.

However, on each, Astro notes “per scan” without defining what is covered in the scan. Furthermore, they don’t indicate if the scan might include any human exploration that would qualify the “scan” as a penetration test instead of a vulnerability scan.

These lower prices suit Astra’s marketing needs because they also offer low cost scans starting at $199 per month and annual penetration testing costs starting at $1,199 per year. Astra’s objective is to satisfy budget-minded organizations with standardized scans and to gloss over that penetration testing requires active exploitation of vulnerabilities, not just scans. While they do publish a disclaimer that “the cost of mobile app pentesting and cloud penetration testing depends upon multiple factors,” a reader scanning the article can easily miss that information and only see the low prices in the bullet points and tables.

Specific penetration testing companies, such as ScienceSoft, may publish a “rough estimate” cost for projects such as $5,000 for “Black box penetration testing of a company’s business-critical web application and up to 10 IP addresses.” These costs are based on their specific experience and their expectations regarding the typical engagement. However, this cost estimate will certainly increase if the testing is required to be in-person in Tokyo (add significant travel costs) and one of the IP addresses is a Microsoft 365 domain (add risk and difficulty).

It is not exactly bait-and-switch for an organization to publish a price that is lower than the average price they charge. Unless the vendor publishes details, we can’t know the specifics.

A vendor may be accurately portraying the price for a specific type of test. A vendor may also be selecting a portion of the bill that will be paid and strategically omitting other normal charges that increase the expenses such as extra charges for reporting, travel, consulting, etc. In all fairness to vendors, there simply are too many factors and variables for a comprehensive and fully accurate price to be published that would match all of the different possible clients, needs, and circumstances.

Also read: Penetration Testing vs. Vulnerability Testing: An Important Difference

11 Key Factors That Affect Penetration Testing Costs

It can be difficult to create an average penetration test cost when there is no such thing as an average IT environment.

The size of an organization cannot even provide a guide since size does not relate to the value or even amount of data within the IT environment. For example, some multi-billion dollar industrial facilities have the equivalent IT environment of a small law office — and that law office might contain much more sensitive, regulated, and valuable data.

In general, the cost of a penetration test will be directly proportional to the number of hours that must be spent on preparing, executing, and documenting the penetration test. However, to figure out those hours, every pen tester and organization will need to consider the factors that affect those hours and the rates applied to those hours:

1. Scope & Scale
2. Penetration Test Type
3. Tester Experience
4. Compliance Requirements
5. System Type
6. Remediation and Retesting
7. Future Opportunities
8. Special Requirements
9. Contract Type
10. Vendor Type
11. Costs Beyond The Contract

Scope and Scale

The size of an organization and the number of systems in scope for testing will be a primary determining factor for costs. While other factors can adjust the rate per system or rate per hour, the scope and scale provides the multiplier that generally determines the bulk of the final charges.

Despite the rise in the number of penetration testing tools that can automate some penetration testing tasks, ultimately, any vulnerabilities located by automated tools should be tested for exploitation by a penetration tester.  Even when an automated tool may detect no vulnerabilities a hacker with specialized knowledge might use their experience to exploit the system, network, etc.

Scope is determined by:

Number of networks: The number of IP addresses, network segments, virtual networks, wide area networks (WAN), software-defined WAN (SD-WAN), and other networks to be explored and penetration tested.

Number of devices: The number of devices, applications, websites, virtual networks, physical networks, containers, internet of things (IoT), and other elements that may require testing will each consume some amount of time for both the automated tool as well as for the human assessor.

Number of applications: The number of mobile, web apps, and websites to be tested. This may also involve API testing, database testing, and supply chain testing depending upon the type of applications and determined scope.

Number of people: If an organization decides to pursue social engineering tests, the organization may be charged by the number of people in the organization (unless flat-rate or hourly charges are used).

Scope boundaries: The organization may determine that they need to narrow the scope of the test for financial, legal, or time considerations. While selecting 3 of 6 locations, or 4 of 12 applications easily come to mind, more significant scope boundaries would be excluding SaaS providers (ex: Salesforce, Slack, Microsoft 365, etc.) and third-party APIs from major vendors such as Google, SAP, Cisco, or CrowdStrike.

Penetration Test Type

The type of penetration test will affect the number of hours required for testing and may incur additional expenses. Organizations should be familiar with the types of testing to understand how it may affect the quote.

Automated Tool Scans

Some vendors provide low-cost “penetration tests” using automated software that might only cost several hundred dollars per penetration test. However, this type of testing is more of a vulnerability scan instead of a penetration test. These scans list potential vulnerabilities without exploring the issue further by using hacking techniques to verify if the vulnerability can be exploited to extract data, disrupt operations, or enable future attacks.

This type of test may be suitable for minimum-quality check-box certification, and only the smallest organizations with the smallest potential damages should even consider these scans. Scan-only penetration tests often cannot satisfy the definition of a penetration test, do not provide the organization with a true test of their systems, and are unlikely to provide protection against future lawsuits in the event of a breach.

Professional Penetration Tests

Types of professional penetration tests are covered in more detail in What Is Penetration Testing? Complete Guide & Steps, but in short the three categories of penetration tests include:

• Black Box tests simulate hackers who know nothing of the network and do not have any access
• Gray Box tests simulate hackers that have some knowledge and access through social engineering, compromised credentials, etc.
• White Box tests provide the penetration testers with full access and require them to check all systems

Black Box tests can naturally limit the scope of a penetration test because systems and network segments that the penetration testers cannot reach will be out of scope. However, the time needed to bypass corporate network security systems (Ex: firewalls, intrusion protection systems) can be significant and an organization will need to decide if that type of testing is a priority.

It is possible to develop a hybrid test that starts off with a time-limited Black Box test to locate any easily discoverable vulnerabilities. Then the penetration test can shift to a  Gray or White Box test of specific systems.

Some sources claim that White Box testing is the least expensive test because penetration testing teams do not have to defeat network security defenses. In some cases this will be true, but in other cases White Box testing can be the most expensive because of the unlimited scope.

For example, testing a simple network of 25 desktop computers will be less expensive than a black box test of the network. On the other hand, checking the source code, APIs, database connections, and integration of 25 applications embedded into a website will be more time consuming than a black box test that might only be able to access one application.

Tester Experience

The experience of the tester will sometimes be reflected in the hourly rate. More experienced testers will tend to be more expensive, yet, counterintuitively, selecting the more expensive option can also save money. Less experienced testers may cost less per hour, but may spend more hours setting up tools or attempting unproductive attacks that a more experienced tester would be able to avoid.

On the other hand, why spend extra for expertise when a less skilled tester can do the job just as well? For organizations with small, simple networks, a less experienced and low-cost tester may be sufficient.

More experienced testers will always insist that the length of time the company has been performing penetration tests will be of utmost importance. However, an experienced company might send inexperienced testers to perform the work, so be sure to obtain the credentials for penetration testers themselves.

A buyer also needs to explore the experience of the vendor with regards to their penetration testing needs. Although penetration testing specialists may maintain a broad variety of experts, generalist IT security vendors or individual consultants will specialize in penetration tests for either network security or application security and might be unable to perform both at the same level of expertise.

Also read: Network Protection: How to Secure a Network

Compliance Requirements

Some regulations may require specific testing of specific systems, using specific techniques, or specifically certified vendors. For example, the Payment Card Industry Data Security Standard (PCI DSS) began to require that organizations accepting payment cards use PCI Security Council Approved Scanning Vendors to conduct required third-party penetration tests.

In some cases required scans may lead to the development of specific testing scenarios to check for compliance with that specific standard. Organizations required to comply with a standard (Ex: HIPAA, ISO 27001, GDPR, SOC 2, etc.) will need to verify that their vendor can perform the necessary tests and provide the necessary reports to meet compliance requirements.

System Type

What the penetration test needs to explore matters. Testing a website with embedded apps, connected databases, and attached infrastructure can be very different from testing a hybrid environment of wireless networks, local data centers, cloud data centers, and SD-WAN connected users.

Different skills and tools are needed for penetration testers to attack networks, mobile apps, website apps, websites, databases, cloud infrastructure, virtual networks, Kubernetes clusters, and SaaS tools. While the number of systems will remain the primary cost driver, the type of system may determine the rate for the testers.

Remediation and Retesting

After a penetration tester discovers and verifies a vulnerability, the organization will need to remediate the issue. In many cases, organizations will want their current IT vendors to remediate issues and use the penetration testing vendor to test the remediation.

In other cases, the penetration testing vendor will be asked to perform remediation since they found, exploited, and demonstrated expertise with the vulnerability in the IT technology. However, some consider asking a penetration testing company to check their own remediation efforts to be a conflict of interest.

Any remediated vulnerability will need to be scanned and tested again to prove the validity of the remediation. Complex remediation retests or a high number of remediations retested can increase overall penetration testing costs. Fortunately, in many cases, remediation retesting will not be a significant cost factor.

See the Top Vulnerability Management Tools

Future Opportunities

Many penetration testing contracts will be for 1-3 year engagements with periodic testing on a monthly or quarterly basis. This type of arrangement can allow the penetration testing vendor to offer discounts based on the prospect of ongoing work, which makes both revenue and expenses predictable.

As the penetration testing company becomes more familiar with the organization’s infrastructure, their attacking teams will be able to move faster in penetration testing to reach changed or new systems. However, this experience can prevent black box testing because of too much familiarity with the customer’s systems, and the penetration testers may fail to look at the systems with fresh eyes. Organizations often will seek to change penetration testing vendors after 3 years to see if fresh perspectives will discover new vulnerabilities.

Special Requirements

An organization can always increase costs with special requests and unusual requirements. For example, off-hours testing, onsite requirements, physical security tests, observations of processes, and social engineering can significantly affect the overall costs for a penetration test.

Off-hours testing: If an organization wants to minimize disruption, it may require penetration testing at night or during weekends to minimize disrupting normal employee activities. Of course, this may lead to extra charges or increased pen testing rates for the activities outside of normal business hours.

Onsite requirements: Offsite remote testing will be limited to IT attacks on IT systems and remote social engineering attacks (phone calls, phishing emails, etc.). In-person or onsite testing will incur travel expenses, but can provide a more robust range of attacks for both IT and other systems (physical security, etc.).

Observation of processes: Sensitive data regulations, such as HIPAA, may require a penetration team to evaluate the physical environment to ensure that no unauthorized person can observe regulated data. For example, a pen tester may be required to enter a hospital and observe the employee computer monitors to ensure no HIPAA data can be seen by patients or visitors.

Physical security test: Some penetration tests can be required to test on-site physical security systems such as security guards, door locks, alarm systems, and security cameras. These tests can require a completely different skill set with different rates and related risks such as physical damage to facilities (broken windows, locks, etc.).

Social engineering: Social engineering tests attempt to trick employees into revealing secrets that can be exploited to gain access to systems, disrupt operations, or steal data. Many organizations are used to the phishing simulation of employee cybersecurity training tools, but social engineering can go much further.

“Social engineering is the art of exploring human stupidity – and there is no patch for human stupidity,” explains Scott Lyons, CEO of penetration testing firm Red Lion. “Only 2% of successful attacks are on systems. 98% are through the vector of social engineering (phishing, personal interactions, USB drive drops, etc.).”

Most employees are not stupid, yet even the smartest employee can have stupid moments that lead to a breach. Social engineering can help identify key mistakes and identify mitigating controls to prevent exploitation.

Common examples of social engineering from a penetration test beyond typical phishing emails include: dropping malware-loaded USB drives in the employee parking lot, calling employees with fake IT calls, or sending someone in person to attempt to trick an employee into making a mistake. Social engineering can be controversial. On the one hand, it can be expensive to conduct and it can embarrass employees. On the other hand, it can be very successful and provide real-world experience for the organization.

Contract Type

Vendors can offer two types of contracts for limited engagements: fixed cost or time and materials (T&M). Companies like fixed cost contracts because of the cost certainty, but keep in mind that the vendor will need to add additional padding to account for likely scope creep and unexpected contingencies.

In many cases, a fixed cost contract will be higher in cost when compared to T&M contracts. In either case, the contract will likely detail specific penetration testing covered by the contract and what circumstances will require additional charges outside the scope of the contract.

Buyers can often work with vendors to create long term contracts that cover rolling tests or multi-year terms.

Vendor Type

When selecting a vendor, an organization will need to consider two key aspects: specialist versus generalist and vendor size. These aspects play a key role in determining the fit of the vendor with the organization and their requirements for the penetration test.

Specialist versus generalist

In selecting a vendor based on this aspect, the organization needs to select a fit within the spectrum that includes penetration test specialists at one end and IT generalists capable of conducting penetration tests at the other. Within the spectrum are vendors that broaden their range a bit to include compliance as well as penetration testing.

Companies may be tempted to stay in their comfort zone and contract with their IT generalist to also conduct penetration tests. Organizations should avoid using the same vendor that installed or remediated IT systems for two reasons.

First, the organization likely used their penetration testing capabilities to check the proper installation of the current environment and are unlikely to locate any additional vulnerabilities. Second, they have a conflict of interest since any discovered vulnerability suggests improper installation of IT systems and there is a possibility the vendor will look to hide some embarrassing discoveries.

The focus of a compliance or penetration testing specialist in their field typically leads to enhanced expertise and an ability to test the organization’s systems with more rigor than a generalist. However, while these rules of thumb tend to be accurate, a newer penetration testing company with little experience will not be as capable as a large IT vendor with a full-time, experienced penetration testing staff.

Vendor size

In general, the larger the vendor, the higher the cost of the penetration test, but some specialists can have higher rates due to their expertise. The more critical factor for vendor size is the fit with the organization’s needs.

For example, a boutique penetration testing company of three specialists located in Boston may be very skilled and capable. However, if the customer is a large multinational bank that requires physical examinations of 120 branch offices in 30 countries conducted in a three-month period, the boutique firm simply will not be large enough to complete the task in time.

An organization may need to pick a vendor that matches them with regards to size and location of offices, especially for time-sensitive tests. Organizations also may favor a vendor of a larger size, assuming that the larger organization will also have a larger capacity to absorb financial terms and liabilities.

For example, that large multinational bank may also require an invoice at the end of each month and payment terms of 60 days, which effectively delays payments for 90 days. A smaller boutique firm may not have the cash flow to wait 90 days for payment. Similarly, in the event of a lawsuit, the boutique firm may not have sufficient assets for the bank to obtain suitable compensation for potential damages.

Costs Beyond the Contract

The first ten factors in this list affect the pricing of the contract. However, many organizations overlook and fail to budget for the costs beyond the contract: internal IT team labor costs, internal IT team capability tests, test environments, and penetration test damages.

Internal IT Team Labor Costs

When conducting a penetration test, the internal IT team will consume time responding to, preparing for, or recovering from the penetration test activities. White and gray box penetration testing will be more time-consuming because credentials, IP address lists, network diagrams, and other supporting materials will need to be prepared for the penetration test team.

Internal IT Team Capability Tests

When performing a penetration test, there are two options for how to involve the internal IT security team: With warning or without warning.

Warning the security team will lead the security team to spend extra time preparing for a penetration test which will increase both their abilities and internal costs related to the penetration test. However, warning the staff provides key advantages.

First, it will increase the ability of the IT security staff overall. Second, it will ensure sufficient staff will be available in the event that the penetration testing team disrupts a key operations system, such as a payment processing server. Lastly, a test conducted without warning might result in an unhappy and embarrassed security team.

Despite the benefits of providing warning, some organizations perform penetration tests without warning to gain an accurate assessment of the organization’s current abilities. A surprise test accurately simulates an attack and the IT security team’s ability to detect, triage, counter, and remediate attacks based on their current capabilities, tools, and IT system status.

An effective way to avoid the negative consequences of a surprise penetration test is to conduct the test in phases. Initially, conduct a black box test and see what the attackers can find.

If key systems could be jeopardized, the attackers can provide notice to the organization and schedule a secondary phase to exploit the discovered vulnerability when the IT team can be on hand and prepared to deal with the consequences of a successful exploitation. Shifting to a phase with warned IT staff will minimize embarrassment and operations disruption.

Test Environments

An organization may want to protect their operations from disruption and conduct penetration tests within a developmental or test environment. For example, a large ecommerce site could not tolerate the lost sales from downtime if the penetration testing crashes the product database. However, when establishing a test environment, an organization also needs to ensure that they will budget for the additional resources to create, secure, and maintain that test environment.

Penetration Test Damages

A penetration testing team will require the company to hold the penetration testing company harmless for damages and other costs related to a successful penetration test. While these costs will not be predictable, a contingency budget should be prepared for possible damages. This can range from the costs of replacing broken windows from a successful physical penetration test to the intangible lost business costs related to the disruption of an ecommerce website.

Information Needed for a Penetration Test Quote

To aid a vendor in generating informative and useful quotes, a buyer will need to prepare estimates or define key factors such as:

• Scale and Scope
• Penetration Test Type
• Compliance Requirements
• System Type
• Future Opportunities
• Special Requirements
• Contract Type

Additional preparation might be useful to extract more value from the penetration test or reduce costs.

How to Pick a Penetration Test Service Provider

When selecting a penetration testing vendor, organizations can become overwhelmed trying to look past the claims of the vendor to determine actual capabilities. Even with fully verified claims, an organization may find it difficult to distinguish between comparable vendors. The buyer must judge the capabilities of the vendor, measure experience, determine trustworthiness, and determine fit in the buying process.

References: A primary method is to check references, although a vendor will certainly hand-pick happy customers. Be sure to ask those happy customers about a time when the vendor made a mistake or delivered bad news and how the vendor handled it. With medium to large engagements, mistakes will happen and how a vendor handles problems can be quite informative.

Understandable proposals: Buyers should examine the proposed plan for the penetration test and how the company presents it. Is the plan easy to understand? Comprehensive? Does the plan match the company’s needs? Beware of promises of rates or turnaround times too good to be true.

Can the vendor explain the penetration test methods clearly? The best experts can explain difficult concepts in simple terms without trying to blind the audience with a flood of acronyms.

Credentials: Also ask for the credentials and certifications of the penetration testers performing the work. Vendor credentials for tools are okay, but nowhere near as rigorous a qualification as an Offensive Security Certified Professional (OSCP).

Sample reports: If possible obtain anonymized or sample penetration test reports to judge the potential final work product. The reports should present clear findings that are easy enough to understand at a high level for non-technical executives and in detail for the IT and security teams performing remediation. Beware of vendors that provide reports that contain company names and IP addresses — perhaps your proprietary data will be on the next sample report handed out by that vendor.

Test runs: When in doubt, engage the top prospects in trial test runs. Many vendors will accept a trial engagement with a retainer fee and initial requirements.

Often these will be black box engagements where the vendor will be asked to explore and report on the company’s main IP address. The buyer can then use real penetration testing to explore the capabilities of the vendor as they execute the phases of penetration testing, the clarity of their communication, and the fit with the organization.

Bottom Line: Penetration Testing Costs

Any professional penetration testing expense will be worth it. Every vulnerability located offsets potentially much larger costs of a breach. Even a report of ‘no findings’ provides invaluable peace of mind and evidence that the organization has exercised reasonable effort in defending their IT environment and critical data.

Companies that do not perform their own penetration tests will be less prepared for attackers, and may be unpleasantly surprised if one of their partners performs a supply chain penetration test and finds the organization lacking. In either of these cases, the organization may lose significant business or suffer harm.

No matter the confidence of the organization in their IT security, only a rigorous penetration test can validate that confidence. Confidence without validation may be arrogance waiting for a rude awakening.

Further reading:

• How to Implement a Penetration Testing Program in 10 Steps
• 24 Top Open Source Penetration Testing Tools
• Vulnerability Management as a Service (VMaaS): Ultimate Guide

The post How Much Does Penetration Testing Cost? 11 Pricing Factors appeared first on eSecurityPlanet.

This article explores:

• What Is Email Security
• Best Options to Secure Business Email
• Email Security Best Practices
• How Email Security Blocks Threats
• Bottom Line: Email Security

What Is Email Security

Email security is a concept that protects email accounts, servers, and communications from unauthorized access, data loss, or compromise. Email security consists of the policies, tools, and services deployed to protect against threats specific to email such as spam, phishing attacks, malware-infested attachments, impersonation, and email interception.

Microsoft estimates that 94% of cyberattacks begin with a malicious email — a horrific statistic that can be dramatically reduced by adopting email security standards, tools, and services. Cybercriminals target email because it is an easy entry point and a single misguided click can potentially enable access to an entire organization. Cybercriminals use email to deliver a host of attacks such as business email compromise (BEC) attacks, malware delivery, and credentials harvesting.

Email security solutions help to:

• Protect an organization’s brand and reputation by flagging spoofing emails trying to impersonate the brand
• Protect an organization’s bottom line by limiting the devastating recovery costs, business disruption losses, business reputation damages, and forensic investigation costs associated with a successful attack
• Enhance productivity by limiting potential disruptions to operations and downtime because of a cyberattack
• Ensure compliance with data protection laws such as the General Data Protection Regulation (GDPR) and avoid the legal fees and regulatory fines associated with the breach of regulated data

Key Features for Email Security

Different email security protocols, tools and services provide both critical and nice-to-have features to secure email. 

Critical features provide the base requirements of email security. Every organization should look for solutions that include:

• Antivirus and basic threat detection looks for and neutralizes known malware signatures within emails 
• Anti-spam filters unwanted email bulk emails and spam messages
• Attachment analysis examines attachments for malicious or suspicious links and malware to disarm potentially malicious content 
• Authentication systems evaluate the validity of senders using DMARC and other email protocols
• Reputation analysis analyzes the message header data and sender IP addresses to compare against IP and mail servers lists of known threat actors
• URL filtering provides uniform resource locator (URL) reputation analysis and some tools can even scan websites for malicious links, content, and attachments

Nice-to-have features provide additional security features at a cost that may be out of reach for some organizations:

• Account takeover protection attempts to detect and block attackers from obtaining credentials and accessing a user’s account to send spam, malware, BEC, or other types of attacks
• Advanced threat detection scans files for malicious code or other patterns associated with malicious threats beyond signature analysis
• Behavior analytics examine the content of emails and the behavior of users to detect unusual behavior that may indicate insider threats or compromised accounts
• Content analysis analyzes the text of the email for urgency terms or other words and phrases associated with phishing or BEC attacks
• Data encryption secures mail communications from interception by cybercriminals or from unintended recipients reading the message
• Data loss protection (DLP) technologies check outgoing emails for content or attachments that may include proprietary or regulated data to flag or even block intentional or accidental insider threat activities 
• Image and content control capabilities can scan attached or embedded images or content to block malware 
• Integrated threat protection can provide unified protection across apps, devices, email, identities, data, and cloud workloads
• Sandboxing provides detonation capabilities for malicious links and attachments within a controlled environment

Best Options to Secure Business Email

Email security may be critical, but every organization faces unique budget constraints, threat profiles, risk profiles, and labor capabilities. These aspects will define the type of tools, services, and protocols that the organization can realistically adopt to protect emails against threats.

Organizations typically select a combination of the following options to suit their email security needs. In some cases, the options will have overlapping capabilities, but redundancy isn’t typically a bad thing for security. Organizations seeking to bolster their email security should examine several options with features that fill in gaps in their current capabilities.

We will present these options in two categories: a priority tier and an advanced capability tier. Smaller organizations need to start with priority options and then adopt more advanced options as they grow and their needs and resources develop. We will cover main tool categories, but keep in mind that specialty tools exist for specialty roles such as attachment inspection that will often be features of more sophisticated tools.

The priority tier includes:

• Email authentication protocols
• Email security tools
• Next generation firewalls and unified threat management
• Secure access service edge
• Secure email gateway or secure web gateway

The advanced capability tier includes sandboxing, encryption, and secure browsers that can provide additional layers of protection for more sophisticated needs. 

The more sophisticated a solution, the more it tends to require expertise to install, configure, manage, and maintain. Organizations can offload some expertise requirements to managed IT service providers (MSPs) or managed IT security service providers (MSSPs). Keep in mind that each category also contains a spectrum of basic-to-advanced tools and capabilities and that service providers can often offer advanced capabilities to smaller organizations through service bundles.

Priority Tier to Improve Email Security

When starting out, organizations should focus on adopting these fundamental email security options. These options provide the basic security features needed for fundamental email security and often will offer options to even upgrade to more advanced security as well.

Email Authentication Protocols: SPF, DKIM, DMARC

The three mutually-reinforcing email authentication protocols, Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication Reporting and Conformance (DMARC) verify the authenticity of emails. Enforcing these protocols will block spam, help identify spoofing emails, and help with reputation analysis for security tools.

It is very affordable for an organization to enable their security tools and web servers to check for and enforce these protocols. It can be time consuming to establish these protocols on an organization’s DNS servers, but doing so will provide two key benefits. First, the protocols improve the reputation of an organization which boosts the deliverability of marketing emails. Second, email servers and security tools can use the protocols to flag emails that try to spoof the organization’s domain and brand.

The smallest organizations may not have the resources to establish these protocols. However, adoption of these protocols should be a priority for growing organizations and is already a federal requirement since 2018 as part of the Department of Homeland Security (DHS) 18-01 binding operational directive.

Email Security Tool

A number of tools present themselves as email security tools to protect local email applications and email servers. These tools are generally good options for smaller organizations with a limited number of on-prem email servers. More advanced versions of these tools can be installed on the cloud to extend their reach and puts them in direct competition with other cloud-based solutions (see below)..

An organization can select from a spectrum of tools from inexpensive and basic tools to robust, feature rich, and expensive tools. Email security tools offer features that screen emails for malicious content using antivirus, anti-spam, DNS, attachment, and other analytics. More advanced tools may include additional options such as threat feeds, sandboxing, and AI-enhanced analytics.

Next Generation Firewalls and Unified Threat Management Systems

Firewalls with advanced capabilities can typically perform application-layer packet inspection that allows for the tool to screen emails for malicious links, spam, and malicious attachments. Both Next Generation Firewalls (NGFW) and Unified Threat Management (UTM) tools will have some capabilities, but an organization will need to check the specific tools under consideration to check both the specific features available and how the tool will integrate with the existing security stack and IT environment.

As with email security tools, advanced firewalls tend to be placed at the edge of local networks and thus are more appropriate for protecting a small number of local email servers. For larger or geographically diverse organizations, cloud-based firewall-as-a-service (FWaaS) may provide more cost-effective and unified protection.

Secure Access Service Edge

Secure Access Service Edge (SASE) tools, also called security service edge (SSE) solutions, control access outside of the corporate network and tend to be cloud-based. Some tools only control access, but other tools also will incorporate secure web gateway (SWG) and firewall capabilities that permit the tools to detect and block spam as well as malicious websites and attachments. SASE solutions provide good solutions for large and geographically diverse organizations looking for centralized control and protection.

Secure Email Gateway or Secure Web Gateway 

Secure email gateway (SEG) or secure web gateway (SWG) solutions provide dedicated solutions to screen emails and website traffic. These tools scan attachments, check for malicious links, and can incorporate blacklists to block known-malicious domains. These tools can also include DLP capabilities to block insiders from intentionally or accidentally leaking sensitive information.

SEGs will focus more specifically on protecting email systems, particularly on-premises email servers, and SWGs may be better to protect SaaS environments. Both options can be installed locally to protect local email servers or in the cloud to enable broader coverage.

Advanced Email Security Capabilities Tier

Organizations with more sophisticated needs or more resources may consider additional capabilities to provide additional layers of security for email. Some of these capabilities will be obtained through specific, specialized tools, but others will be obtained through more advanced features or add-ons to tools listed in the priority tier above.

Email Sandboxing

The delivery of malware through email remains a high concern, even for organizations deploying layers of email security to prevent malware delivery. Attackers can modify code too easily and develop new types of attack too quickly for most IT security teams to put all of their faith in anti-malware solutions. 

Many email security solutions now provide sandboxing capabilities to enable security teams to launch attachments in a safer environment. However, while these capabilities can improve confidence in attachment analysis, IT security teams must also be aware that some malware will attempt to detect sandboxing environments to prevent analysis.

Encrypted email

Despite many advancements in email tools, the email format itself remains a text-based protocol. Many email tools will enable the encrypted delivery of emails, but some of these encryption options will be undone if the sending email server detects a receiving email server that may not support the option. For more ensured protection against the interception of emails, organizations can adopt an email encryption solution.

Secure Browser

A secure browser, also known as browser isolation, creates a sandboxed environment on the endpoint device. Within this sandboxed environment, the user can perform their normal business activities with less concern about malware and malicious attachments. If the user accidentally launches malware, the malware will affect the sandboxed environment and allow the user to simply close the sandbox with a greatly reduced risk for a long-term effect on the local endpoint or network.

Threat Feed

Attackers constantly develop new attacks and methods and new vulnerabilities are discovered regularly. Threat feeds provide security teams with the latest news and can be integrated with security tools to update malware signature files more frequently and provide indicators of compromise used by advanced analytics to detect new malware in action.

Email Security Best Practices

Ultimately, the point of any security is to reduce risk for the organization. Email security should fit into a broader security strategy to reduce the risks of attack on an organization and the related risks of data breaches, operational disruption, and financial loss.

The best practices for email security reflect these overarching risk reduction requirements of an organization. Although we will provide best practices for a generic organization, every manager with IT, security, and risk responsibilities must modify these best practices to fit the context of their specific needs. For example, even a very small stock broker will have US Security and Exchange Commission (SEC) or Financial Industry Regulatory Authority (FINRA) regulatory requirements for email security, monitoring, and retention.

Good, Better, and Best Security Best Practices

The Good, Better and Best levels of email security best practices reflect the adoption of increasing levels of sophistication and capabilities in the adoption of formal email policies, layers of email security, employee email security training, use of email for high-risk functions, and the related security stack.

Good Email Security Best Practices: 

• Adopt a written email security policy
• Enable security options in email software 
• Use at least one priority tier email security tool (email security tool, advanced firewall, SASE, or secure gateway) with basic functionality to reduce spam and inspect email and attachments for malware
• Have a basic security stack that includes hardened IT infrastructure and protected endpoints

Better Email Security Best Practices:

• Adopt a written email security policy and use it actively to measure success for email security through regular reports
• Enable security options in email software 
• Enable email authentication (SPF, DKIM, DMARC)
• Use at least one priority tier email security tool (email security tool, advanced firewall, SASE, or secure gateway) or multiple security tools that deliver stronger capabilities to reduce spam, inspect email and attachments for malware, and perform URL filtering
• Have an email security tool with capabilities for at least one advanced tier email security function (sandboxing, encrypted email, secure browser, threat feed) to protect against attacks
• Perform basic annual employee security training to reduce risk
• Limit your use of email for high-risk functions (financial transactions, regulated data exchange, etc.)
• Purchase a hardened security stack that includes DNS security, encryption at rest, hardened IT infrastructure, multi-factor authentication, and protected endpoints.

Best Email Security Best Practices:

• Adopt a written email security policy and use it actively to measure success for email security through regular reports that reflect risk reduction
• Enable security options in email software 
• Email authentication (SPF, DKIM, DMARC) enabled
• Use a robust priority tier email security tool or tools (email security tool, advanced firewall, SASE, or secure gateway) implemented with strong capabilities to reduce spam, inspect email and attachments for malware, perform URL filtering, perform reputation analysis, and several nice-to-have features such as behavioral analytics, advanced threat detection, or sandboxing
• Have an email security tool with capabilities for one or more advanced tier email security function (sandboxing, encrypted email, secure browser, threat feed) to protect against attacks
• Conduct regular employee security training to create a security-focused organization
• Highly restrict or block the use of email for high-risk functions (financial transactions, regulated data exchange, etc.)
• Have a robust security stack that provides a full spectrum of overlapping protection 

To understand the context of these best practices, we’ll explain the formal email policy, multilayered email security, employee security training, email use for high-risk functions, and related security stack in more detail.

Formal Email Policy

Organizations should have two types of formal email policies. A corporate email use policy for employees and an email security policy for the IT or IT security team.

Most organizations already have a corporate email use policy developed by the HR department to ensure that employees are aware of their responsibilities when using company email, guidelines on personal usage of corporate email, use of personal emails accounts, email use on corporate and personal devices. These policies also typically cover email retention, attachment guidance (permitted file types, file sizes), prohibited email content, regulated or confidential data in emails, and corporate monitoring of employee emails for compliance and other purposes. 

Many organizations have email security strategies in place, but without any written documentation or formalized reports that would help an IT security team to prove the implementation and ongoing functionality of an acceptable level of email security. A written email security policy for IT security formalizes the risk reduction expectations, minimum acceptable security features, and reporting requirements. 

Both types of email policies provide protections and penalties. As long as employees and IT teams conform to the requirements of the email policy, the organization and the employee will be protected in the event of a security incident or breach. However, both policies should also provide for penalties and processes to investigate employees and IT staff who actively undermine or simply choose not to comply with the security policies.

Employee Security Training

No security software is 100% effective or immune from breaches. Employee training can provide basic security skills for employees to use to avoid becoming victim to email attacks. 

Simple rules that should be taught include:

• Never click on links in emails received from unknown sources
• Never open attachments from unknown sources. If an unexpected attachment is received from a known sender, an employee should call the sender to verify the contents of the attachment before opening
• Never follow links to financial institutions contained within emails. Instead, type the address directly into a browser or use a search engine to locate the financial institution’s official websites
• Always consult a senior manager before transferring money on instructions in an email. Business email compromise scams often instill a sense of urgency and imply that the sender is out of phone contact but a wire transfer must be carried out immediately without telling other staff members for “reasons of confidentiality”
• Never connect to the corporate email system from a public Wi-Fi spot without using a VPN to ensure that the link is secure

Many organizations use third-party cybersecurity training programs to help minimize the risk of human error and ensure that employees understand the importance of email security.

Email Use for High-Risk Functions

Email can be difficult to secure and email servers can even undo some security features, such as encryption, if the receiving email server indicates that it cannot support the feature. High risk processes and transactions should be moved to systems with stronger authentication and security functions.

For example, the following processes should not be conducted via email and should only be performed using secured websites or applications after verifying the user’s identity:

• Requesting patient data (regulated by HIPAA)
• Obtaining credit card numbers (regulated by PCI DSS)
• Authorizing financial transactions (at least over a certain dollar amount)
• Authorizing payments to employees or vendors
• Delivering the results of medical exams or tests (regulated by HIPAA)

Related Security Stack

Email security cannot operate alone to protect an organization. Email security must fit into a security stack of related and overlapping network security controls that limit the impact of breached email security such as data loss protection, DNS security, data encryption, hardened IT infrastructure, identity and access management (IAM), multi factor authentication, and protecting endpoints.

Data Loss Protection

Data loss protection (DLP) monitors the use and movement of important or regulated data. Corporate secrets, personal identifying information (PII), personal health information, and other regulated information can be detected, monitored, or even blocked from inclusion in emails, chat applications, or file-sharing applications.

Email tools can offer limited capability DLP that focuses on the use of protected data in email. However, a more robust DLP solution will include many other applications outside of email to deliver more general protection.

DNS Security

DNS security involves two key aspects: the investigation of URLs and domains within emails, and protecting the corporate DNS from attack and corruption. Many email security programs will perform basic DNS security such as checking URLs against a blacklist of known-malicious websites. The email security programs should be further enhanced by tools and techniques applied to protect corporate DNS.

Encryption At Rest

Malicious emails, especially modern ransomware, use data exfiltration programs to steal data from local and network hard drives. The adoption of encryption at rest will limit the access and availability of data stolen from such attacks and provide an additional defense should email security fail.

Harden IT Infrastructure

Default installations of firewalls, networking equipment, server operating systems, and local operating systems will not block any protocols or ports to allow for maximum utility. Unfortunately, maximum utility also means maximum security risk.

Organizations should disable unneeded protocols, block unused ports, and enable options for improved security across the IT infrastructure. These hardening techniques limit the ability of successful email attacks to expand across the organization.

Identity and Access Management

Identity and access management (IAM) hardens the organization with regards to access by enabling an organization to apply the principle of least privilege access to limit unnecessary access by specific users and user groups. Effective use of IAM will limit the ability of attackers to use stolen credentials or compromised devices to expand an attack against the organization.

Multi-factor Authentication

Compromised credentials stolen from a phishing campaign can be quite dangerous. However, the adoption of two-factor (2FA) and multi-factor authentication (MFA) provides additional barriers for an attacker to navigate.

Protecting endpoints

A breached email security will often result in an attack on the end user’s computer. A strong antivirus or endpoint detection and response (EDR) solution protects the local machine against infection or even isolates a compromised local machine to protect the network.

How Email Security Blocks Threats

Email can contain a wide variety of potential threats including business email compromise, data exfiltration, impersonation, malware, and phishing and spam emails. Deploying various email security tools can detect, contain, or even block these threats using a variety of techniques and features.

Business Email Compromise

Business email compromise (BEC) attacks are a subcategory of phishing or impersonation attacks that attempt to impersonate trusted business partners or employees in order to trick the organization into sending products or cash payments to the attacker. Email security can block this type of attack because they:

• Use DMARC email authentication to catch discrepancies between the From field shown to email recipients and the From field in the header
• Analyze email sender reputation (URL, Domain)
• Apply text sentiment analysis looking for suspicious text trends such as urgency (reply now) or secrecy (do not contact others for verification)

Data Exfiltration

Data exfiltration occurs with the unapproved transfer of data from an organization. Email security tools use data loss prevention (DLP) technology to identify and track proprietary or regulated data within email text or attachments.

Most DLP programs will have a limited number of default detections such as US social security numbers and credit card numbers. Organizations may have to define other information for the DLP to track and monitor.

Impersonation

Attackers try to fake the “from” fields in emails to impersonate a trusted person or brand. Impersonation, also known as spoofing, lends credibility to phishing and can be accomplished through misleading graphics, text, and look-alike domains (ex: m1cr0s0ft.com). 

Email security tools can catch impersonation attempts because they:

• Use SPF email authentication to verify if the sending domain is an authorized email sending address (for spoofed domains)
• Use DMARC email authentication to catch discrepancies between the From field shown to email recipients and the From field in the header
• Analyze email sender reputation (URL, Domain)
• Apply text sentiment analysis looking for suspicious text trends such as urgency (reply now) or secrecy (do not contact others for verification)

Malware

Common types of malware include viruses, worms, ransomware, and spyware and email attacks will often attempt to disguise malware as PDF files or within compressed files (.zip, etc.). Email security tools detect malware using one of several features:

• Antivirus signature comparison against known malware
• Analysis of email sender reputation (URL, Domain)
• Open attachments in sandboxes to verify file contents
• Advanced malware detection by checking file content for malicious or suspicious programming

Phishing & Spam

Phishing attacks are a malicious subcategory of spam emails that can also include spear phishing, vishing, and whaling. The main difference between the phishing and spam is if the links and attachments of the unwanted email lead to malicious websites.

Email security tools detect phishing and spam emails because they:

• Use DMARC email authentication to catch discrepancies between the From field shown to email recipients and the From field in the header
• Analyze email sender reputation (URL, Domain)
• Analyze URLs and websites linked in the email for malicious code or credential stealing tactics using advanced malware detection capabilities 
• Appy text sentiment analysis looking for suspicious text trends such as urgency (reply now) or secrecy (do not contact others for verification)

Bottom Line: Email Security

Email security tools are available in a wide spectrum and variety that can meet the varied needs of an equally wide spectrum of organizations. As each organization grows, it will need to regularly check if their existing email security solution continues to satisfy the current needs of the organization now and for the next few quarters. If additional capabilities are needed, organizations should explore their options and adopt new tools before an attacker can exploit any gaps.

For additional insight into email security tools, consider reading:

• What Is DMARC Email Security Technology?
• 9 Best Next-Generation Firewall (NGFW) Solutions for 2023
• 8 Top Unified Threat Management (UTM) Software & Hardware Vendors
• Firewalls as a Service (FWaaS): The Future of Network Firewalls?
• Top Secure Access Service Edge (SASE) Providers
• Top Secure Email Gateway Solutions
• 9 Best Secure Web Gateway Vendors

This article was originally written and published by Paul Rubens on March 13, 2018 and updated by Chad Kime on June 8, 2023.

The post How to Improve Email Security for Enterprises & Businesses appeared first on eSecurityPlanet.

This article will explore how this works in more detail:

• Ransomware & Phishing — a Toxic Combination
• How DMARC Counters Phishing & Ransomware
• Bottom Line: Adopt DMARC as an Essential Part of Email Security

Ransomware & Phishing — a Toxic Combination

Ransomware attacks accounted for approximately one out of every five cyber crimes in 2022 even as the number of ransomware attacks dropped by 23% compared to 2021. However, the impact of ransomware continues to grow as ransoms increase and attackers increase the magnitude of their overall threat with the addition of data exfiltration, extortion, and distributed denial of service (DDoS) attacks.

The costs of ransomware attacks can be massive, including downtime, data loss, business reputation damage, recovery expenses, forensic investigation expenses, and significant psychological damages for the teams. Ransomware depends upon phishing for the majority of ransomware attacks, yet phishing also delivers other types of attacks. Phishing, in turn, often depends upon email spoofing to trick users into falling for the phishing attack.

Ransomware Depends on Phishing

A ransomware attack can spring from a single email, and phishing provides the most common entry point for ransomware. However, in most cases, clicking on a bad phishing link does not launch ransomware. Attacks that do launch immediately can usually only encrypt the computer for the phishing victim, which limits the ransom-earning potential. More insidious, news-worthy, and revenue generating ransomware attacks need widespread access to the organization for maximum impact.

To achieve the broader goal, 63% of phishing attacks seek to compromise credentials. By stealing credentials, the ransomware gang can then infiltrate the network, expand access, and attack the organization as a whole.

Other Phishing-Delivered Attacks

Although ransomware makes headlines because of their highly disruptive and obvious impact, phishing attacks can deliver a number of other highly harmful attacks such as business email compromise (BEC), credentials harvesting, keyloggers, remote access trojans (RATs), cryptojacking malware, and other spyware. RATs tend to be the malware of choice because they offer the flexibility of future attack options and the hackers can also resell their access to ransomware-as-a-service providers, cryptocurrency mining groups, bot farms, and more.

Phishing Depends on Spoofing

Spammers send an estimated 3.4 billion emails every day, and Google blocks around 100 million phishing emails daily. Attackers use phishing to perform 47% of the attacks against North and South American organizations, 43% of the attacks against Asian organizations, and 42% of the attacks against European organizations. Microsoft even estimates that 94% of cyberattacks begin with a malicious email.

Yet no one clicks on an unconvincing email. Most people will be tricked by emails that appear to be legitimate and sent by a familiar brand. LinkedIn, Microsoft, Adobe, and Google are top brands used in broad phishing attacks, but smaller brands will also be used in more targeted attacks.

It’s not so difficult to fake an email. Attackers forge the “From” address to target victims with a fraudulent, “spoofed” email that appears to be from a legitimate sender.

For example, perhaps an administrator at the law firm of GenericContracts.com clicks on a phishing link and the attackers scope out the firm. The attackers may find the firm too small to be worth a ransom attack but also realize that the firm does local work for dozens of larger corporations.

The ransomware attackers may choose to spoof the GenericContracts.com domain and send phishing emails to the stolen contact names for those larger corporations with “Overdue Invoice” PDF files laden with malware. With an existing working relationship with GenericContractors.com, the corporate clients are more likely to click on the phishing emails and enable future ransomware attacks.

How DMARC Works to Stop Ransomware

Fortunately, DMARC provides a way to stop email using fake “From” addresses and reduce spoofing email attacks. DMARC provides email authentication not only to validate official emails but also to invalidate imposter emails by enhancing other email authentication standards.

How Email Authentication Works

DMARC is published with an organization’s Domain Name Service (DNS) and depends on the prior establishment of two other email authentication standards. The Sender Policy Framework (SPF) lists all domains authorized to send emails on behalf of the organization. The DomainKeys Identified Mail (DKIM) standard enables an organization to digitally sign emails from their domain using public key cryptography to verify that an email is delivered unaltered.

DMARC builds on SPF and DKIM to:

• Check for alignment, or consistency, between the “from” field in the body of the email and the SPF and DKIM domains
• Instruct the email server how to handle (ignore, quarantine, or discard) emails that fail SPF, DKIM, or DMARC checks

DMARC Alignment Example

Extending the example above, hackers may forge a fake email spoofing the accounts payable department of GenericContracts.com in the “From” field of the text the reader can see. However, the email itself will be sent from their own domain of SpammyPhishing.com, which shows up only in the header of the email (normally hidden from the reader).

However, if GenericContract.com deployed an effective DMARC policy, their clients’ email server would perform a DMARC check. The DMARC check would fail the email for being sent from a non-authorized domain and for having misalignment (or non-matching) header and email “From” fields. The receiving email server would be notified that the spoofed emails are fraudulent and likely send the impersonating email to the SPAM folder or even discard them.

Additionally, GenericContracts.com would receive a report from their clients’ emails servers that detail the campaign of phishing emails from SpammyPhishing.com. GenericContracts can then proactively warn customers about the phishing attack, search for their data breach, and report SpammyPhishing.com as a malicious URL.

How to Use DMARC

Security specialists recommend using DMARC to help protect against ransomware attacks as an essential email security tool. While DMARC primarily protects other organizations receiving emails attempting to impersonate the organization, DMARC makes the task of spoofing emails significantly more complicated for hackers and helps preserve the organization’s brand image.

Of course, it’s not the ultimate protection, as there are many other techniques hackers can deploy. Additionally, organizations need to enforce DMARC on their email receiving servers to perform the DMARC check. However, every protection deployed adds an additional layer of defense, and deploying DMARC also adds other benefits to the organization, such as improving the delivery of marketing emails.

Bottom Line: Adopt DMARC as an Essential Part of Email Security

DMARC can be challenging to configure correctly; however, it provides powerful email protection against spoofing, phishing, and related attacks such as ransomware. Organizations need to adopt DMARC to protect themselves and others against spoofing attacks and to help erode the threat of spam, which accounted for 48% of all emails sent in 2022.

For further reading on tools to secure email:

• How to Improve Email Security for Enterprises and Businesses
• 9 Best Next-Generation Firewall (NGFW) Solutions for 2023
• Top Secure Access Service Edge (SASE) Providers
• Top Secure Email Gateway Solutions

This article was originally written and published by Julien Maury on September 21, 2021 and updated by Chad Kime on June 6, 2023.

The post How DMARC Can Protect Against Phishing & Ransomware appeared first on eSecurityPlanet.

This article provides details to help an organization establish a robust DMARC policy with detailed information on:

• Troubleshooting DMARC
• Common Reasons Why DMARC Fails
  • Common DMARC Mistakes
  • Insufficient Resources
  • Failure to Escalate DMARC Settings
• Bottom Line: DMARC Enforcement Reduces Phishing

Troubleshooting DMARC

Troubleshooting and deploying a correctly formatted Domain-based Message Authentication, Reporting and Conformance (DMARC) policy will require precision and time. Fortunately, there are many resources available from the DMARC.org website, email vendors, and even full-service DMARC vendors to help IT teams with the process.

General Troubleshooting Process

When attempting to fix a DMARC policy after initial setup, organizations will run into various issues. Basic DMARC requirements help to define the best practices for troubleshooting, which include:

1. Verify and Check SPF, DKIM, and DMARC policies in detail
2. Deploy DMARC in monitoring mode (p=none)
3. Check DMARC report for several weeks to identify legitimate email sources suffering rejection
4. Resolve rejection issues by updating the appropriate policy (SPF, DKIM, DMARC, or email vendor settings)
5. Once legitimate email issues have been resolved
   1. Gradually enforce DMARC to ‘p=quarantine’ or ‘p=reject’
   2. Check for new rejection issues
   3. Repeat steps until all sending domains are verified, enforced, and fully protected
6. Periodically check reports for IP address changes or new domain conflicts to be resolved or spoofing sites to report or block

Vendor-Specific DMARC Troubleshooting Guides

Most DMARC settings do not rely upon the specific email vendor, but some details may be vendor specific — especially with regard to DNS deployment, DMARC activation, and troubleshooting. Fortunately, most email vendors also provide guides or tutorials.

Microsoft 365 and Gmail provide tutorials and specialized instructions for properly configuring DMARC policies for their email customers. Similarly, smaller vendors such as Twillio’s SendGrid will publish their own troubleshooting guides, so IT teams will need to check with their email and DNS providers for specific information.

Specialized DMARC Vendors

Harried IT teams without resources may not have time to study the requirements or troubleshoot the processes. For these organizations, specialized DMARC vendors can be an effective solution to save time and money.

Seth Blank, CTO of Valimail and co-chair of the DMARC Working Group, suggested, “To evaluate a platform’s ability to help you reach enforcement, assess its user experience, automation and customization.” Organizations should also verify that these potential vendors can service the full spectrum of policies (SPF, DKIM, DMARC) and can explain how they might address common issues such as SPF lookup limits.

Common Reasons Why DMARC Deployment Fails

DMARC deployment can fail for a host of reasons. Initially, an organization may make mistakes with their DMARC record that causes DMARC checks to fail. Once the DMARC record is corrected, the organization may find many emails suffering DMARC rejection which requires another round of troubleshooting.

Beyond the technical issues, DMARC can also fail due to insufficient resources dedicated to supporting DMARC or even by not escalating the DMARC settings. An IT team must work with other stakeholders in the organization to stress the importance of DMARC and overcome these obstacles.

Common DMARC Mistakes

Text files are small and simple; however, simplicity also means that small mistakes can create big problems. The DMARC working group publishes a list of common problems with DMARC records that includes detailed issues, and we will cover the major categories here.

Invalid DNS Records

Incorrectly published DMARC, DKIM, and SPF records with extra text or incorrect text will invalidate the records.  These issues can stem from several different types of errors, including:

Wildcard records include wildcard characters or the addition of extra text that might invalidate the record such as: 

• SPF records using the IP address: ip4: 201.5.YY.ZZZ (instead of numbers)
• Incomplete DKIM public encryption keys
• Random text or comments inserted into the record such as “Please contact your registrations service provider…” or or “***” or “This domain’s zone has been disabled”
• Domain or vendor owner inserting names into the text file

Not following directions can be similar to wildcard records because it includes extra text; however, in this case it typically will be instructions for content that have remained in the file such as “descriptive text” in the following sample: “_dmarc.fromage.XXXXXXXX.fr descriptive text v=DMARC1; p=reject;…”

Common formatting errors avoid wildcard and extra text issues but create problems in other ways such as:

• Order of elements: “v=DMARC1” must come first and be listed in all capital letters so both “p=none; v=DMARC1; rua=mailto:…” and “v=dmarc1;P=Reject;…” will cause errors
• Forgetting variable tags or proper syntax such as writing
  • “DMARC1” instead of “v=DMARC1”
  • “rua=email@…” instead of “rua=mailto:email@…”
• Forgetting semicolon (;) separators or using the wrong separator between variables such as with “v=DMARC1 p=none…” or “v=DMARC1:p=none…” instead of “v=DMARC1;p=none…”
• Permitted, but potentially problematic formatting such as
  • Using capital letters other than for DMARC1 such as “V=DMARC1;P=NONE…” instead of “v=DMARC1;p=none…”
  • Unneeded spaces such as with the extra space before “mailto” in “rua= mailto:email@…” instead of “rua=mailto:email@…”

Typos and extra characters will often sneak into a DNS record because of copy-paste errors or even specific DNS requirements. For example, some DNS servers require semicolon characters to be escaped using a backslash (\) character and the file may be found with too many (\\) backslashes or forward slash (/) characters used by accident.

Bad record content is listed separately by dmarc.org, but it has a lot in common with typos and formatting errors. For example, instead of using one of the three permitted values for the “p” tag (none, quarantine, reject), the record may use incorrect (“blocked” or “monitor”) or mispelled (“quarintine”) values.

Overlooked Subdomains

When creating SPF files, an organization will be limited to 10 DNS query lookups. Often this means larger organizations will have multiple SPF files and will segregate out specific subdomains for separate SPF records.

However, when the organization creates their DMARC record, the organization may focus exclusively on the top level domain (EX: SampleOrganization.com) and may overlook their subdomains (EX: ITNotifications.SampleOrganization.com or SalesEmails.SampleOrganization.com).

Unless explicitly handled separately, the DMARC policy deployed on the top-level domain automatically trickles down to subdomains.  Overlooking subdomains that require separate handling may unintentionally block legitimate emails originating from servers on those subdomains.

Overlooked DMARC Updates

All DNS records, including DMARC, require updates as organizations evolve. For example, an organization will switch the IP addresses for email servers  as they upgrade or transition to the cloud. Each IP address change requires an update to the filed policy.

Similarly, companies send email campaigns from a variety of third-party vendors for marketing (HubSpot, Mailchimp, etc.), sales (Salesforce, etc.), surveys (SurveyMonkey, etc.), accounting (Quickbooks, etc.), and help desks (Zendesk, etc.). As they adopt new vendors or these vendors change their email infrastructure, again, DMARC, SPF, and DKIM will require updates to keep up with the changes and avoid blocking legitimate emails.

DMARC Rejections

When implementing DMARC, organizations start with ‘p=none’ to avoid rejecting improperly configured but legitimate emails. The three most common ways legitimate emails will be rejected include:

• Failure to set up DKIM Signatures for email vendors — this leads to a mismatch between the sender (Gmail, Microsoft 365, etc.) and the DMARC domain
• Failure to whitelist third-party senders with DNS providers — these providers sign emails with their domain by default, which causes a mismatch
• Forwarding entities altering body and headers — resenders, gateways, and malware scanning solutions will intercept the email and then forward it on. The forwarding replaces the sender IP address, which causes a DMARC mismatch

The first two issues can be managed by correctly establishing DKIM signatures for email vendors and correctly whitelisting third-party senders with DNS providers. Unfortunately, there isn’t much that can be done with the third issue unless the organization can contact or control the forwarding email servers.

In addition to the three most common issues, an organization can also run into issues with SPF and DKIM alignment. DMARC alignment seeks to prevent spoofing of the “header from” address by matching:

• The “header from” domain name and the “MFROM” domain name used during an SPF check
• The “header from” domain name with the “d=domain name” in the DKIM signature

Often, third-party email senders cause issues by using their own “MFROM” domain.  This may pass SPF or DKIM, but not alignment. This issue will require coordination with the vendor to properly adjust the SPF, DKIM, and DMARC files.

Insufficient Resources

Smaller organizations always struggle with time-intensive IT issues. Seth Blank admitted, “Frankly, setting up DMARC is complicated, which accounts for the gap between policies and policies at enforcement.”

Insufficient Staffing

Despite the simplicity of the specific technologies, the regular maintenance to keep SPF, DKIM and DMARC current can be difficult to keep up with for large companies with dedicated teams. For small organizations with small IT teams, the maintenance can be nearly impossible.

“DMARC is an intricate standard reliant on two additional email standards, SPF and DKIM. Both of these standards would be strenuous to configure on their own. Smaller companies without an IT department to dedicate to DMARC do not have the resources to implement these records together,” said Blank.

Insufficient Tools

The DMARC aggregate and forensic reports sent from the receiving email service providers include crucial email ecosystem information, but the machine-readable files will not be intuitive or easy to read for humans.  Additionally, for even moderately-sized organizations the sheer volume of reports received can overwhelm an organization attempting to manually collate and parse the information in a meaningful way. Fortunately, many different DMARC reporting tools can be obtained to enable rapid and meaningful analysis of DMARC tools.

Failure to Escalate DMARC Settings

The most significant issue with DMARC stems from organizations failing to escalate their DMARC settings. Whether out of fear of blocking legitimate emails or simply because implementing teams overlook escalation, failure to switch from p=none to a more rigorous policy undermines the effectiveness of DMARC.

Unless an organization sets an enforcement policy to “quarantine” or “reject,” even emails recognized as fraudulent will still be allowed to pass through to inboxes. Without the more restrictive enforcement policy, organizations place an unnecessary burden on email security applications and increase the likelihood of a phishing attack successfully impersonating a brand.

“A policy not configured to ‘quarantine’ or ‘reject’ fraudulent actors is like a bouncer who checks IDs and lets everyone in regardless of age,” said Blank. “DMARC enforcement should be the first level of protection … Other network security measures, like AI-based monitoring, can be valuable, but validating IDs shows you who is trying to get access.”

Bottom Line: DMARC Enforcement Reduces Phishing

If every organization deployed DMARC with full enforcement, spoofed emails would be dramatically reduced and phishing emails would become much less effective. While not all email attacks can be stopped, reducing credible spoofing attacks will dramatically reduce the burden on our email security tools as well as the number of phishing victims for our organization and every other recipient. It is time to protect your brand, defend against BEC, and reduce SPAM globally with full deployment of SPF, DKIM, and DMARC.

The post Why DMARC Is Failing: 3 Issues With DMARC appeared first on eSecurityPlanet.