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.

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.

Third-party risk management (TPRM) software and tools — also known as vendor risk management (VRM) — go beyond the general capabilities of risk management and governance, risk, and compliance (GRC) solutions with specialized onboarding, risk assessments, and due diligence for organizations working with third parties. Some TPRM tools also assess operational risks, but our focus here is on third-party security, privacy and compliance issues.

We’ll take an in-depth look at the top third-party risk management vendors and tools — followed by what buyers should consider before making a purchase.

• OneTrust: Best Overall
• Prevalent TPRM Platform: Best for Managed Vendor Risk Assessments
• Venminder: Best for Customer Support
• BitSight: Best for Vendor Intelligence Networking
• ProcessUnity TPRM: Best for Automated Vendor Management Workflows
• Archer: Best for SLA Management
• SecurityScorecard: Best for Intuitive User Experience
• Aravo for Third Party Management: Best for Customization
• Panorays: Best for Ease of Deployment
• Diligent ThirdPartyBond: Best for Reporting and Visualizations

Comparing the Top TPRM Software & Tools

OneTrust Third-Party Risk Management

Best Overall

A bonafide unicorn, OneTrust launched in 2016 to offer privacy management and marketing compliance solutions. To comply with a growing list of global regulations, the Atlanta-based compliance monitoring provider offers OneTrust Third-Party Risk Management (previously Vendorpedia) to help organizations evaluate customer, employee, and vendor data transfers. OneTrust offers privacy impact assessments, data inventory mapping, remediation actions, and recurring audits on a web-based portal. It is widely considered one of the best TPRM solutions for compliance-driven industries.

OneTrust TPRM’s highest user reviews cite its usability and accessibility, quality of technical support, and high-quality automation for vendor management. OneTrust is also one of the few TPRM solutions that offer a free trial option to users.

Key Features

• Workflow integration builder
• Unified third-party relationship inventory
• OneTrust Insights and Analytics engine
• Intelligent onboarding workflows
• Dynamic questionnaires

Pros

• Highly integrated with other OneTrust solutions and third-party data sources
• Offers AI auto-completion technology for faster questionnaire completion
• Workflows are highly configurable and follow intuitive if/then logic

Cons

• Some limitations to OneTrust’s risk mitigation features
• Limited risk scoring and advanced analytics capabilities
• Room for growth in native integrations

Pricing

Pricing for smaller businesses starts at $600 a month. Enterprise buyers will need to contact OneTrust for pricing information.

Prevalent TPRM Platform

Best for Managed Vendor Risk Assessments

Started in 2004, Prevalent is an IT consulting firm that specializes in governance, risk, infrastructure, and compliance technology. The company offers customers a suite of third-party risk management solutions through the Prevalent TPRM Platform; features include inherent risk scoring, offboarding and termination, and vendor risk assessment and monitoring. With Prevalent’s sourcing and selection, organizations can reduce cost, complexity, and exposure from the start by picking trusted vendors.

Prevalent’s highest reviews and ratings cite its ease of integration and deployment, profile management, and technical support. It is also one of the best options for buyers who are looking to move beyond TPRM software into fully managed services and strong customer support.

Key Features

• Automated risk assessment and continuous risk monitoring
• Automated assessment workflows and remediation management
• Vendor intelligence networks
• RFx Essentials for centralized distribution and management of RFPs and RFIs
• Inherent risk scoring with prescriptive guidance on corrective action and due diligence

Pros

• Users have real-time access to completed risk reports for thousands of companies through vendor intelligence networks
• Strong professional and managed services backbone
• Extensive connector marketplace for easier integration

Cons

• Only basic risk-scoring capabilities are available.
• Customization is limited at the customer level; most customization happens only through the vendor.
• The user interface is less intuitive than some competitors

Pricing

Pricing information is not transparently provided on the Prevalent site. Prospective buyers will need to contact the vendor directly for pricing information. Prevalent TPRM can also be found on AWS.

Venminder

Best for Customer Support

Venminder launched in 2003 as a SaaS vendor that streamlines third-party risk management. Venminder provides administrators with oversight and contract management frameworks, risk assessments, due diligence requirements, questionnaires, SLA management, and vendor onboarding. In Venminder Exchange, clients can access the platform’s repository for assessments of vendor security status, SOC reports, contracts, financials, business continuity and disaster recovery, and more.

Venminder’s highest reviews and ratings cite its quality of end-user training, profile management, and evaluation and contracting. New users are assigned a relationship manager for more hands-on onboarding. After onboarding, the company continues to offer extended support hours for customers with email, phone, and chat communication options.

Key Features

• Customizable risk assessments with templating and progress monitoring
• Automated, customizable questionnaires
• Oversight Management feature with vendor scorecard tracking
• Issue and SLA management
• Point-in-time risk profile creation

Pros

• Extensive library of free learning resources, webinars, infographics, etc.
• Unlimited user access is available in all plans
• With a la carte services and features, this solution is easy to scale and adjust to your business’s specific requirements

Cons

• Limited international presence and reach; works almost exclusively with North American clients
• Historically has mostly focused on finance clients; expertise and experience in other areas may be limited
• Mostly geared toward smaller business requirements

Pricing

Venminder is sold in two different pricing package formats: Professional and Enterprise. Beyond general software features, users also have the option to purchase control assessments and managed services on an a la carte basis. Specific pricing information is not transparently provided on the Venminder site. Prospective buyers will need to contact the vendor directly for pricing information. AWS quotes enterprise pricing, including all modules, at around $100,000.

BitSight Third-Party Risk Management

Best for Vendor Intelligence Networking

BitSight — known as a pioneer in the security ratings space — is a top provider of TPRM solutions. Using sophisticated algorithms and daily security ratings, BitSight Third-Party Risk Management and the Security Ratings Platform help organizations manage third-party risk. BitSight also integrates with other VRM tools like ServiceNow and ProcessUnity to offer users the best of the TPRM market.

BitSight’s highest reviews and ratings cite the timeliness of vendor response to product questions and patching cadence. The TPRM provider is known for its vendor intelligence network, with over 20,000 vendor profiles available to users.

Key Features

• Automated onboarding assessments
• Data-driven vendor response validation
• Real-time reporting
• Fourth-party product usage discovery
• Customizable workflows for vendor assessment prioritization

Pros

• BitSight integrates and works well with most other TPRM solutions
• Customers and non-customers alike have access to free cyber security reports
• Reporting is comprehensive and fairly easy to customize

Cons

• Limited peer community and forum opportunities
• Limited communication and access to customer support representatives
• It’s not easy to filter data results or update report results as issues in the network are resolved

Pricing

Pricing information is not transparently provided on the BitSight site. Prospective buyers will need to contact the vendor directly for pricing information. The only sources we could find cite starting pricing around $20,000 a year.

ProcessUnity Third-Party Risk Management

Best for Automated Vendor Management Workflows

ProcessUnity offers SaaS solutions for managing various components of governance, risk, and compliance (GRC). With ProcessUnity Third-Party Risk Management, organizations are empowered to assess, monitor, and conduct due diligence when working with business partners. Across vendor risk assessment processes, ProcessUnity’s solution can help identify, manage, and remediate issues. The tool also includes periodic vendor performance reviews to ensure the ongoing strength of the organization’s security posture.

ProcessUnity’s highest reviews and ratings cite timely support responses, product configurability, and added features. Users are particularly impressed with the automation that’s been added to the tool over time; automated critical workflows can be customized for assessment scoping, evidence collection, and other risk management processes.

Key Features

• Pre- and post-contract due diligence
• Third-party onboarding with sourcing and RFx support
• Risk domain screening
• Issue and vendor performance management with SLAs
• Automated assessment scoping and evidence collection

Pros

• Hands-on automations and no-code features make this tool highly customizable
• Reporting-As-A-Service feature translates report data in a way that all stakeholders can understand
• The solution supports the whole TPRM lifecycle, from sourcing to contract management

Cons

• Considered a fairly expensive TPRM solution
• Limited visualization features in reports
• Questionnaires could offer more features

Pricing

Pricing information is not transparently provided on the ProcessUnity site. Prospective buyers will need to contact the vendor directly for pricing information. The VRM Essential Edition for SMEs starts at $15,000.

Archer Third-Party Governance

Best for SLA Management

Archer Third-Party Governance — formerly part of RSA but now privately owned — is an enterprise-ready risk quantification software solution for aggregating risks and safeguarding organizations from disruption. Critical features for Archer include customizable controls and risk indicators, risk profile metrics, and advanced visualization tools to compare risk consequences.

Archer’s highest reviews and ratings cite its history and reporting, integration and deployment, and comprehensive management of third-party SLAs. Archer was previously owned by RSA but was acquired by private equity firm, Cinven, in April 2023.

Key Features

• Bowtie diagrams for risk and mitigation illustration
• Customizable risk reporting and monitoring
• Quantitative and qualitative risk analysis
• Desktop and mobile accessibility
• Customizable key risk indicators

Pros

• Designed with highly regulated industries in mind
• AI-powered features make it easier to quickly assess third-party asset risk
• Some of the best fourth-party risk management features in the market

Cons

• The solution works most effectively only when used with other Archer solutions
• The pricing and licensing model for Archer is somewhat complicated
• Frequent acquisitions and internal moves make it difficult to predict the long-term direction and stability of this solution

Pricing

Pricing information is not transparently provided on the Archer site. Prospective buyers will need to contact the vendor directly for pricing information, but the company says typical TPRM pricing is around $30,000 to $50,000.

SecurityScorecard Platform

Best for Intuitive User Experience

Considered a pioneer in the TPRM space, SecurityScorecard is a cybersecurity service provider with patented rating technology. Boasting over 1,000 organizations as clients and a million companies continuously rated by extension, SecurityScorecard has come a long way since its founding. Organizations can analyze their digital footprint and fill cybersecurity gaps with instant risk ratings mapped to vendor cybersecurity questionnaire responses.

The SecurityScorecard Platform’s highest reviews and ratings cite its ease of deployment, superior customer support, and capability of handling public-facing infrastructure risk. The layout of the tool and its central dashboard are easy to navigate, and its graphics make for some of the best TPRM visualizations in the market.

Key Features

• Continuous monitoring and global IP scanning
• Automated send-and-response for questionnaires
• Rule-based tools for cybersecurity responses
• Dashboarding for third- and fourth-party vendors
• Customizable scores, due dates, reminders, and alerts for vendors

Pros

• Strong user interface and visualization capabilities
• One of the few TPRM solutions that offer transparent pricing models for prospective buyers
• The free version of SecurityScorecard offers limited features to an unlimited number of users

Cons

• Limited risk mitigation and response features; the tool primarily focuses on detection
• Occasional lag in response times from customer support
• Somewhat limited reporting capabilities

Pricing

SecurityScorecard is available in four different plan options:

• Free: $0 per month for unlimited team members
• Pro: $400 per month, billed annually
• Business: $1,000 per month, billed annually
• Enterprise: Custom pricing

Aravo for Third Party Management

Best for Customization

Launched in 2000 to address the growing need for enterprise supplier management, Aravo now offers SaaS-based supplier information management (SIM) and TPRM technology. Aravo for Third Party Management enables users to better manage new vendor intake, risk assessment automation, and due diligence.

Aravo’s highest reviews and ratings cite its pricing and contract flexibility, its configurability, and the company’s expert consultations in vendor risk evaluation. Although the solution offers many preconfigured workflows, assessments, dashboards, and reports, it is also easy to configure these features according to an individual business’s needs.

Key Features

• Automated risk assessment and vendor onboarding
• Third-party risk scoring based on dynamic online surveys
• Self-service survey creation with Customer Defined Assessment
• Third-party intelligence networking
• Corrective action and issue tracking

Pros

• Aravo offers specialized features for anti-bribery, anti-corruption, data privacy, and infosec requirements
• Interactive customer experience is available through innovation exchange and customer community
• Aravo’s preconfigured apps and native content integration are robust and highly usable

Cons

• The company has mostly shifted away from TPRM development to focus on business resilience
• Many features are only available through third-party partnerships or add-ons that come at an additional cost
• The pricing model for Aravo is somewhat complicated

Pricing

Pricing information is not transparently provided on the Aravo site. Prospective buyers will need to contact the vendor directly for pricing information. Aravo is also available on Azure.

Panorays

Best for Ease of Deployment

Panorays is a cybersecurity solution that offers automated features for third-party risk management and remediation. The Panorays strategy brings together dynamic questionnaires for existing suppliers with attack surface assessments to give clients greater risk visibility. The tool is particularly capable of meeting compliance standards like GDPR and HIPAA.

Panorays’s highest reviews and ratings cite its ease of deployment and onboarding, its centralized management features, and its ongoing feature updates. It also has a modern and intuitive user interface and a strong commitment to hands-on customer support.

Key Features

• Pre-built template for vendor security questionnaires
• External attack surface monitoring and assessments
• Customizable remediation plans
• Out-of-the-box reporting
• Autocomplete responses for questionnaires

Pros

• The product is constantly evolving and the vendor is receptive to customer feedback; a strong development roadmap is in place
• Straightforward and consistent approach to automation
• Users have commented on the quality and consistency of customer support for planning, assessment, and software implementation

Cons

• Somewhat limited connectors and integration capabilities
• Reports could be improved, especially with more self-service elements
• Limited functionality in the asset scanning feature

Pricing

Panorays is available in five different plan options:

• Free: For up to five third-party one-time assessments
• Basic: For up to 50 third-party continuous assessments
• Premium: For up to 100 third-party continuous assessments
• Enterprise: For up to 250 third-party continuous assessments
• Enterprise+: For more than 250 third-party continuous assessments

Specific pricing information is not transparently provided on the Panorays site. Prospective buyers will need to contact the vendor directly for pricing information. Google Cloud quotes starting enterprise prices of $2,500 per supplier.

Diligent ThirdPartyBond

Best for Reporting and Visualizations

Diligent — previously known as Galvanize — offers top-tier software solutions for audit, risk, and compliance. With the ThirdPartyBond solution, organizations can access end-to-end third-party risk management with resources for vendor onboarding, automated evidence collection, and assessment surveys. ThirdPartyBond also tracks service level agreements (SLA), maintains updated intelligence feeds, and provides tangible reporting for senior management.

ThirdPartyBond’s highest reviews and ratings cite its responses to product questions, its ease of integration and deployment, and its overall efficiency. It also offers some of the best reporting and visualization capabilities, with granular drag-and-drop dashboards, interactive storyboards, and various pre-built reports.

Key Features

• Centralized inventory and bulk import of third parties
• Risk-based control assessments
• Reports driven by KPIs and KRIs
• SLA performance monitoring and contract management
• Adaptive vendor surveys and risk scoring

Pros

• Strong risk analytics are built into the platform
• Advanced machine learning algorithms are incorporated to predict control failures
• One of the few TPRM options that offer interactive storyboards with advanced data visualizations

Cons

• Limited customizability in the most recent version of Diligent’s TPRM solution
• Pricing can quickly get expensive for teams that need multiple out-of-the-box solutions from Diligent
• Most edits to Diligent features can only be completed through scripting, making it challenging for less-technical users

Pricing

Pricing information is not transparently provided on the Diligent site. Prospective buyers will need to contact the vendor directly for pricing information.

Why Do You Need Third-Party Risk Management?

Third-party risk management is necessary for many organizations because adopting any kind of new digital system — especially one from a third party — comes with inherent vulnerabilities, including threats of breach, data loss, noncompliance, and human error. Specialized TPRM tools automate many of the relationship management workflows and steps, making the effort of organizing, optimizing, and securing third-party relationships seamless and simpler for business continuity purposes.

While network infrastructure vulnerabilities have long been the responsibility of security and network professionals, supply chain vulnerabilities are a growing and prescient concern due to their upstream ripple effect. As third-party networks grow larger and third-party tools become more difficult to regulate and track, organizations must increasingly practice vigilance in safeguarding their privacy, operations, and reputation; a strong TPRM posture can help organizations stay on top of these growing security concerns.

8 Common Features of Third-Party Risk Management Software

Every third-party risk management software solution is a little bit different, especially if it’s offered as part of a security suite or managed services offering. However, regardless of which tool appeals to your team most, it’s important to look for the following features and capabilities:

• Self-service portals for suppliers and vendors to provide pertinent documentation and guidance for questionnaires and risk scoring
• User-friendly reports and visualizations that cover risk monitoring and risk exposure to inform action steps
• Processes and templates for supplier risk control, oversight, and risk assessments
• Continuous monitoring of vendor performance and changes to supplier risk status
• Third-party relationship guidance that includes structured steps to follow from sourcing to relationship termination
• Built-in compliance features for internal policies and external mandates for supplier risk; compliance features for finance, government, and other highly regulated sectors are ideal
• Quantitative and qualitative data to show progress in reducing third-party risk exposure
• Reports and visualizations that help the customer and third-party vendors quickly understand current issues and possible mitigation strategies

How to Choose a Third-Party Risk Management Tool

With so many features to consider and other factors that go into making a TPRM purchase, you need to drill down to what’s most important for your business’s risk management strategy. To choose the right third-party risk management tool for your business, be sure to ask organizational leaders and members of your cybersecurity team these kinds of questions:

• How will the solution improve the organization’s third-party risk exposure?
• How does the TPRM tool enable compliance reporting and operational management? 
• Is the tool compatible with the business’s specific compliance requirements?
• Does the vendor offer flexible pricing that can scale as third-party exposure grows? 
• Is this tool compatible with the organization’s budget?
• What training, deployment, and implementation support comes with this purchase?
• What integrations are compatible and/or configurable for use?
• What advanced features make this TPRM solution stand out?
• What do past and present customers of this TPRM solution say about the tool?
• Does this tool simplify the organization’s TPRM workflow?

Bottom Line: Third-Party Risk Management Tools

Even if your organization trusts and has thoroughly vetted the third-party vendors you partner with, your network becomes increasingly vulnerable to cyberattacks and noncompliance issues with each new partner you add and each new change they make to their own ecosystems. Especially with the rise of modern artificial intelligence (AI) and Internet of Things (IoT) technologies, it has become increasingly difficult to monitor and identify risk across all endpoints through traditional methods and tools.

Though third-party risk management software is a specialized kind of cybersecurity tool that won’t cover all of your network security requirements, TPRM solutions are an important component of overall network security strategy and tooling. Investing in a TPRM solution or service is one of the most effective ways to simultaneously manage your third-party relationships and the security and compliance standards to which you hold these partners.

Read next: 34 Most Common Types of Network Security Protections

This updates an August 2021 article by Sam Ingalls

The post 10 Best Third-Party Risk Management Software & Tools for 2023 appeared first on eSecurityPlanet.

Comments intended to guide understanding and use of this template will be enclosed in brackets “[…]” and the ‘company’ will be listed as [eSecurity Planet] throughout the document. When converting this template to a working policy, eliminate the bracketed sections and replace “[eSecurity Planet]” with the name of your organization.

This policy will reflect a generic IT infrastructure and needs. It can be modified as needed to reflect a specific company’s IT infrastructure and needs.

To use this template, copy and paste the website text or download the Microsoft Word Template below.

1. Overview

Security vulnerabilities enable attackers to compromise a resource or data. Vulnerabilities occur through product defects, misconfigurations, or gaps in security and IT systems.

Vulnerabilities consist of two categories: unplanned and planned. Unplanned vulnerabilities consist of zero-day vulnerabilities, misconfigurations, and other security mistakes. Planned vulnerabilities consist of known vulnerabilities that cannot, or will not, be fixed.

This vulnerability management policy defines the requirements for the [eSecurity Planet] IT and security teams to protect company resources from unacceptable risk from unknown and known vulnerabilities. This Vulnerability Management Policy:

• Outlines the expectations, requirements, basic procedures for:
  • Vulnerability Identification
  • Vulnerability Evaluation
  • Vulnerability Mitigation
  • Vulnerability Tracking
• Defines reports to verify compliance with this policy
• Provides penalties for failure to comply with this policy

[The purpose of this section is to introduce the reader to the policy purpose and what to expect later in the document. Policy defines what MUST be done, not HOW it must be done. IT and security managers need the flexibility to accomplish the goals within their resources as they see fit.]

2. Scope

This policy applies to all [eSecurity Planet] resources that connect to the organization’s network, provide connections between resources, provide security for resources, enable the organization’s mission, or host the organization’s data. The organization will maintain and track a formal list of resources within the scope of this policy as defined in Appendix I: IT Resource Asset List.

Vulnerability management relies on accurate lists of existing systems, software, connections, and security. The scope should be verified [as per the asset management policy / monthly / quarterly] to ensure all assets can be accurately assessed and tested for vulnerability identification.

Vulnerability scans may also need to be performed on websites and applications that are not owned and maintained by other departments. The IT Department will need to verify ownership of responsibility for each application and website to ensure no gaps in vulnerability management.

Although critical components of vulnerability management, Patch Management and Change Management will be covered separately in their own Policies.

[This is a generic version of the scope, which should define what will be monitored and tested for vulnerability identification. Organizations can make the scope as broad or as narrow as needed in the appendix. Broader is always better to control risks, but can be more costly.]

3. Vulnerability Management Policy & Procedure

A. Vulnerability Management Authority

[The Chief Information Security Officer (CISO) of eSecurity Planet] is designated as the Vulnerability Management Authority that holds the ultimate responsibility and authority to plan, execute, authorize, or delegate any and all sections of this patch management policy and procedure to internal resources or third-party tools or vendors.

While the Vulnerability Management Authority maintains ultimate responsibility, it is acknowledged that the [IT Security Department] will generally execute the Vulnerability Management Authority’s plans to comply with the Vulnerability Management Policy. The use of “IT Department” elsewhere in this policy refers to the Vulnerability Management Authority, the [IT Security Department], and delegated representatives.

The Vulnerability Management Authority also verifies and approves:

• Vulnerability Management Policy Scope
• Vulnerability priority
• Vulnerability and penetration testing
• Any maintenance downtime needed for changes or mitigations
• Any exceptions needed
• Vulnerability management reports
• Enforcement

[This section defines who needs to sign off on the budget and manage the vulnerability management process. It is best to use a title because people sometimes change and the policy should not need to be revised with every personnel change.]

B. Vulnerability Identification

The IT Department cannot assume that security is invulnerable. Testing must be performed to verify that resources have been installed, configured, integrated, and secured without error or gap in security. 

i. Active Vulnerability Detection

Vulnerability scans and penetration testing will be performed [quarterly] and after significant changes to resources to test for unknown vulnerabilities. High-risk systems containing high-value data or of high importance to operations will require [monthly] scanning.

Vulnerability scans may be automated and performed with commercial tools as long as the tools can test the specific potential vulnerabilities associated with the resource. Unauthenticated vulnerability scans should be conducted to view the systems from the perspective of an external hacker and authenticated vulnerability scans should be conducted to view systems from the perspective of a hacker with stolen credentials.

Specific vulnerability scans for specific vulnerabilities may be required on an ad hoc basis upon the discovery of specific vulnerabilities or zero-day threats. These scans should be conducted as needed and not constrained to the typical scanning schedule.

ii. Information and Threat Monitoring

In addition to testing, the IT Department will continuously monitor and scan a variety of sources to obtain information regarding the release of new attack methods and resource vulnerabilities. Updates and patches for resources fall within the scope of the patch management policy, but unpatched vulnerabilities must be addressed within the scope of this vulnerability management policy. Sources may include, but are not limited to: security mailing lists, vendor notifications, and websites.

iii. Third-Party Systems

The organization will likely require some integration with third party endpoints and systems, such as:

• Leased industrial control systems (elevator systems, fire control systems, etc.)
• Leased operations equipment
• Bring-your-own device (BYOD) equipment brought by employees, consultants, customers, and guests
• Cloud infrastructure jointly monitored and maintained between the cloud vendor and the organization

Vulnerability scans should include all accessible systems connected to the organization and may include these third-party systems. However, the vulnerabilities detected may be beyond the scope of internal resources for resolution. Formal agreements with corporate partners can define responsibilities between the parties for different types of vulnerabilities.

However, regardless of the official responsibility, the IT Department may need to prepare compensating controls to mitigate vulnerabilities. For example, the organization should perform continuous scanning using network access control or equivalent solutions to detect endpoints with vulnerabilities as they attempt to connect to the organization’s network and quarantine them.

iv. Documentation

The IT Department must design and document the vulnerability identification program by listing all of the scans, tests, and sources monitored for information. This should be made available as an appendix added to this policy and updated as required. The highest risk assets of the organization must be specifically listed and noted for which tests are performed to verify their status.

[While listing the types of scanning tools, penetration tests, and threat information sources may often be sufficient, adding a table of the top assets provides additional protection. Some organizations perform perfunctory scans using inexpensive tools without considering whether those tools actually test their most critical systems.]

When a vulnerability is identified, a ticket will be issued by the IT Department and the vulnerability will be tracked on a Vulnerability Management Tracking list.

[This section is designed to enforce vigilance and prompt recognition of available updates and patches. Best practices suggest that specific individuals be assigned the task of researching, locating, and verifying the source of updates and patches.]

C. Vulnerability Evaluation

Once vulnerabilities are identified, they must be verified and evaluated for their potential risk to the organization. The vulnerability should be verified using independent tools and personnel different from the detecting resource. In some cases, an active attempt to exploit the vulnerability may be required to verify the vulnerability or assess its risk.

The vulnerability will be evaluated based upon the following criteria:

• The Common Vulnerability Scoring System (CVSS) Score of the vulnerability (if available)
• The likelihood of the vulnerability being exploited
• Related or cascading vulnerabilities

The CVSS assigns vulnerabilities a score between 1 and 10. The CVSS version 3.0 ratings correspond to:

• 9.0 – 10.0 = Critical Severity
• 7.0 – 8.9 = High Severity
• 4.0 – 6.9 = Medium Severity
• 0.1 – 3.9 = Low Severity
• 0.0 = No Severity (Informational)

These scores do not suggest likelihood of exploitation, but do suggest a level of how much an attacker can affect a system or how much effort may be required. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) maintains a list of known exploited vulnerabilities that can be referenced to check for active exploitation.

Similarly, the IT Department needs to evaluate the current environment, the current IT architecture, and the nature of the vulnerability to determine the likelihood of exploitation, which should also be evaluated on a scale from 1 (low likelihood) to 10 (high likelihood). The likeliness of exploitation, where possible, should incorporate threat intelligence information on the exploitation of similar vulnerabilities to support the evaluation. Adding all three of these factors will create a value between 1 (low priority or no action needed) and 20 (urgent action needed) for the vulnerability to be mitigated.

[Many organizations do not prefer numerical rankings in their processes. The process of assigning values can be time consuming, especially in the early stages of adoption. However, numerical values help to communicate risk and urgency outside of the IT Department and facilitate reporting and compliance.]

When the vulnerability exposes other existing or new vulnerabilities, those related vulnerabilities should be noted. Related systems, software, and processes should also be noted for the vulnerability.

Generalities are permitted when the list of affected systems is cumbersome, but specifics should be used where possible.  For example:

• A vulnerability in the firewall model used in all offices should be generalized as applicable to “all offices, systems, and processes within the organization”
• A vulnerability on a specific router on a specific network segment will specifically list:
  • Range of IP addresses affected
  • Affected people (ex: users in the Porto finance department)
  • Affected devices (ex: finance server, accounting, PCs in the finance department, local printers)
  • Notable or high-value affected processes or systems (ex: accounting systems, accounts payable, accounts receivable, etc.)

[This section outlines the evaluation criteria for estimating the potential risk to the organization. While a specific vulnerability may affect a specific system, the vulnerability needs the context of the other affected systems and processes to determine its potential impact to the organization.]

D. Vulnerability Priority

Multiple vulnerabilities may be identified in testing or upon the announcement of zero-day vulnerabilities. If necessary, the IT Department will determine the priority for mitigating these vulnerabilities in the context of other existing vulnerabilities using a hierarchy based upon:

• Evaluated Vulnerability Value determined during Vulnerability Evaluation (above)
• Risk Assessment Value of resources (data, system, process, etc.) affected by the vulnerability to the organization

Risk Assessment Value: [eSecurity Planet] uses risk analysis to create a Risk Assessment of internal systems that is recorded and updated in a Risk Register on a scale from 1 (low impact/value) to 10 (highest impact/value). However, a vulnerability may affect multiple systems, software, or processes so the risk value should reflect the total of all resources exposed or the highest exposed risk value, whichever is greater.

When the risk assessment score of 1 to 10 is combined with the vulnerability evaluation rating between 1 and 20, the vulnerability priority score will be generated between 2 (no action needed) and 30 (immediate action required). This prioritization will generally result in tiers of vulnerabilities to be addressed by the IT Department.

[This section assigns a priority to help determine which vulnerabilities should be addressed first in the vulnerability management process. Be careful that no one manipulates the exploitation risk and value of the asset as a matter of casual convenience to avoid dealing with the vulnerability or to pursue lower risk mitigations that cause less disruption or may be easier to implement.

This section references Risk Assessments and a Risk Register. Organizations of all sizes can and should produce a Risk Register. The risk register assesses the value of a resource and how large an impact on the organization may occur if that resource is impaired, becomes compromised, or fails.

Both direct and indirect risks should be considered. For example, a vulnerability in a wi-fi router firewall configuration may expose Windows 95 machines required to run manufacturing equipment. The risk of the exposed router also includes the risk of the exposed Windows 95 machines and subsequent operational risk of compromised manufacturing equipment.

If no Risk Register is in place, an organization will need to make a qualitative estimate of the value of the resource to the organization.]

E. Vulnerability Mitigation Guidelines

Once a vulnerability has been identified, evaluated, and prioritized, the mitigation to address the vulnerability must be designed, tested, prepared, scheduled, applied, verified, and tested.

i. Vulnerability Mitigation Design

The subcategory of patch management relies upon the application of commercially provided mitigations, or patches, to commercial products and is covered comprehensively in the Patch Management Policy. Broader vulnerability management will require more customization of settings, IT architecture adjustments, and the installation of additional security tools or controls.

Often, there will be several different ways to directly or indirectly mitigate the vulnerability. In many cases complete elimination of the vulnerability will be impossible because of the required cost or complexity of the required mitigation.

However, cost and difficulty may not be used as an excuse to ignore vulnerabilities. Temporary mitigations and partial mitigations (or compensating controls) must be designed, tested, and applied within the time frame appropriate for the level of risk.

Common mitigations include, but are not limited to:

• Deploy mitigating security control such as a new security tool (Firewall, etc.)
• Deploy patches
• Add multi-factor authentication to security controls
• Upgrade or replace vulnerable IT Resource
• Isolate and protect vulnerable IT Resource (network segmentation, disconnect wireless access, etc.)
• Remove or discontinue the use of the IT Resource
• Deploy configuration changes

Complex mitigations may require multiple compensating controls or multiple steps. For more complex mitigations, milestones should be developed to help check progress of implementation.

In some cases mitigation requires the implementation of technical controls that affect users, such as multi factor authentication (MFA). Training on these tools should be considered part of the mitigation design, although training will not generally need to be completed within the minimum vulnerability mitigation schedule timeframe (see below).

ii. Vulnerability Mitigation Testing

For high value resources, the IT Department may decide to test the mitigation in a test environment to check for possible business disruption or other issues. Mitigation that fails the testing process must be redesigned and retested.

[Testing mitigations in a test environment allows the IT Department to discover those issues in an environment that will not affect business processes. Not all organizations have the resources to perform testing for low value resources.]

iii. Vulnerability Mitigation Preparation

Not all mitigations will be applied successfully or without issue. In some cases a mitigation may render a system unusable or cause cascading problems to other IT systems or software. To prepare for this possibility, the IT Department must ensure that [the Disaster Recovery Policy has been executed prior to the Patch Management process.

At the very least]:

• A full system backup has been performed prior to the application of the update
• A full data backup has been performed prior to the application of the update

For unsuccessful mitigations that disrupt operations, the IT Department will attempt to roll back the system or software to a previous version to recover functionality. Systems that cannot be rolled back will need to be restored from backup or replaced promptly. In some cases the disruption may leave the system intact and require changes to the mitigation plan to restore operations. Such changes should be implemented as quickly as possible to limit disruption.

The IT Department may attempt multiple times to implement mitigations. For mitigations that cannot be successfully applied, the IT Department must follow the Exception and Mitigation process below.

[This section acknowledges that not all mitigations work as intended and the IT Department must prepare for that possibility before applying patches of any kind. We recommend referring to an established Disaster Recovery Policy that should cover backups and recovery systems in detail, but organizations without such a policy can delete that text and simply require backups to be performed.]

iv. Vulnerability Mitigation Schedule

Based upon the ranking in the vulnerability management list, the IT Department will be required to pursue mitigation:

• 20+: within [5] business days
• 14.0 – 20: within [10] business days
• 8.0 – 13.9: within [30] business days
• Vulnerabilities ranked below 8.0: within [90] days

[The turnaround time for addressing vulnerabilities depends upon the potential risk. Banks, hospitals, and other organizations with the possibility for high risk and impact to the organization may set the top tiers in hours (ie: 72 hours) instead of days.]

Vulnerability mitigation consists of security tools, settings adjustments, IT architecture changes, and other steps needed to lower the risk of a discovered vulnerability. 

Other factors affecting the Vulnerability Priority include:

• Mitigation measures required to address the vulnerability 
• The ability of potential mitigation measure or security control to address multiple vulnerabilities
• Potential business operations disruptions from required mitigation measures

Mitigation measures required to address the vulnerability can range from simple firewall port adjustments to complex installations of multiple new security tools and controls. In general, simple solutions will be preferred because of the cost of implementation and testing; however, the mitigation must adequately reduce the risk of the exposed vulnerability.

The complexity of the solution does not reduce the urgency to mitigate the vulnerability. However, if temporary measures may be applied to reduce the initial risk, the overall priority and rating of the vulnerability may be reevaluated.

A potential mitigation measure or security control that addresses multiple vulnerabilities may be prioritized at the discretion of the IT Department as long as the mitigation does not interfere with the deployment of more urgent vulnerability mitigations. Efficiency is important but does not outweigh the potential damages of exposed risks.

Potential business operations disruptions may occur because of required mitigation measures. Where possible, business operations should be avoided and minimized.

To avoid excessive disruption, these disruptive mitigations require Maintenance Windows need to be scheduled and approved in advance by the Vulnerability Management Authority, preferably with the consent of the appropriate business managers affected by the disruption.

To obtain approval, the IT Department must [issue a ticket / fill out a form / send an email] issued to the Patch Management Authority with the following information in a Maintenance Window request:

• Details regarding affected systems
• Details regarding the urgency of the vulnerability and risk 
• Preferred maintenance window and at least one alternative window
• Details regarding rollback procedures should the mitigation fail

For mitigations required in the absence of the Vulnerability Management Authority, the next available executive in the organization chart can approve the maintenance window.

Should an emergency mitigation need to be applied and no executive can authorize or propose a reasonable alternative maintenance window for the mitigation within the required time frame associated with the urgency of the vulnerability, the IT Department may proceed under the following conditions:

• Documented efforts to obtain approval
• Notify non-executive affected stakeholders (customers, employees, etc.) of the maintenance window
• Proceed with the mitigation without formal approval

It is acknowledged that emergency mitigations and maintenance disruptions may occasionally be required, but the IT Department should always minimize disruption.

[This formally written part of the patching process requires those responsible for implementing the mitigation to request a maintenance window for when the software update will cause downtime for users or systems in active use. However, it also prioritizes security over operations when operations executives are unable or unwilling to authorize downtime in a reasonable manner.

The exact rating system and urgency will be up to the organization. The schedule based upon priority should ensure prompt action on the most critical patches and updates on the most critical resources. The 30 day maximum for applying mitigations should prevent any system or software from being overlooked or ignored entirely or for updates to pile up.]

v. Vulnerability Mitigation Application

Vulnerability mitigation typically will require a manual process. The IT Department is expected to obtain and deploy sufficient resources to properly establish the mitigation within the expected time frame. When required, outsourced expertise may be obtained to implement mitigations of large scale or for high risk assets.

[This formally written part of the patching process requires those responsible for implementing the mitigation to deliver the mitigation on time, even if it may require hiring additional resources for implementation. This wording puts security at a higher priority than budget control, so this may need to be modified to fit the needs of the organization.]

vi. Vulnerability Mitigation Verification and Testing

Once the mitigation application completes, the IT Department should check that the mitigation works as expected and reduces the risk as intended. Penetration tests and vulnerability scans should be repeated to verify success or to identify and report on unsuccessful mitigations. Vulnerabilities that remain exposed must be addressed as required under Mitigation Tracking and Exceptions (Paragraph 3.F, below).

F. Mitigation Tracking and Exceptions

Mitigations do not always resolve vulnerabilities. In many cases the compensating controls introduced to mitigate a vulnerability shield the vulnerability behind additional layers of security without addressing the vulnerability directly.

All unresolved vulnerabilities and the associated mitigating controls will continue to be tracked and monitored for future potential vulnerabilities within the vulnerability management tracking list. Mitigated vulnerabilities should be reviewed on [a quarterly] basis to determine if more efficient mitigations may be deployed that could save time, maintenance expenses, or further reduce risk.

For patching or maintenance, any failed, disruptive, or unpatched systems become exceptions that become addressed as vulnerabilities under this policy. However, most failed or disruptive vulnerabilities will not remain exceptions. Failed or disruptive mitigations will be reworked and reintroduced into the vulnerability management process for resolution. On rare occasions, the combination of a low risk vulnerability and high cost of compensating controls may lead the organization to accept the risk of the specific vulnerability. These exceptions will need to be tracked and reported within the vulnerability list.

[Most organizations can perform a quarterly review as outlined in this document. However smaller organizations may only have resources for twice-annual or annual reviews and larger organizations may be more aggressive and want monthly or weekly reviews for high risk or high value systems.]

G. Vulnerability Management Reporting

The IT Department will issue [monthly] reports on patching and updating. The reports must include:

• Date(s) of last asset scan(s) and number of assets tracked
• The percent of systems actively tested for vulnerabilities and types of vulnerability scans and penetration tests used in the active testing
• The number of vulnerabilities detected in scanning
• The number of vulnerabilities remediated through mitigations classified by:
  • vulnerability risk
  • overall priority
  • time for resolution (in summary and in detail)
• The vulnerability scan or penetration test performed for each mitigation to verify proper implementation (note as pending if the testing is still in progress)
• The number of remaining vulnerabilities unmitigated
• Average time elapsed between vulnerability detection and mitigation by asset risk and value category
• The number of vulnerability exceptions added to the exception report
• The total number of vulnerabilities and mitigations within the vulnerability tracking list

[The IT Department must issue reports so that the organization can verify that the vulnerability management procedures are followed properly and that mitigations are implemented on a timely basis. Regular reports may eliminate the need for special reports for compliance.

The data in the report should also be used to help improve the vulnerability management process. For example, the number of vulnerability mitigations that result in help tickets can be used to determine if additional testing is needed before deployment.]

4. Audit Controls and Management

[eSecurity Planet] executives and auditors may request documented procedures and evidence of the vulnerability management practice on demand. Examples of documented procedures and evidence include:

• Approved Maintenance Window Requests
• Approved Exception Lists
• Full or partial exports of the vulnerability management tracking list or system
• Full or partial copies of vulnerability scans and penetration tests conducted to discover vulnerabilities or to verify mitigations
• Vulnerability Management Reports

[This section acknowledges occasional need of executives and auditors for off-schedule reporting on the Vulnerability Management processes. To verify Vulnerability Management reports, some auditors may also require system logs that confirm successful system or software updates.]

5. Enforcement

Employees found in intentional policy violation may be subject to disciplinary action, up to and including termination  The job performance of IT Department staff responsible for executing this policy will be evaluated based in part or in full on their ability to fulfill the expectations of this policy.

Regular inability of the IT Department to meet the requirements of this Vulnerability Management policy may be considered negligence and result in disciplinary action. Falsified reports or gross negligence in execution may be grounds for immediate termination or disciplinary action.

[For policies to be effective, there should be penalties for non-compliance. This document assumes that organizations that fail to meet the update standard due to lack of resources will not hold their IT Department accountable when overworked or overloaded. Organizations that apply unreasonable expectations will likely experience high IT Department turn-over and difficulty in retaining experienced or competent staff.]

6. Distribution

This policy is to be distributed to all [eSecurity Planet] executives and IT Department staff responsible for Patch Management Policy support and management.

[Anyone that will need to work on patch management (IT Department staff) or be affected by the policy (at least executives, but possibly other relevant employees) should receive this policy. Employees responsible for execution may need to formally acknowledge receipt.]

7. Policy Version

Version 1.0
Approval Date: 5/12/2023
Description: Initial Policy Drafted

[This section can also be made into a Policy Version History with a table of previous versions and approvals.]

8. Signatures

Approved By: ____________________________________________
[Patch Management Authority Signature]

Approved By: ____________________________________________
[CEO or other applicable Executive]

[A signature by the Patch Management Authority acknowledges the requirements of the policy and becomes a de facto pledge to meet the requirements. A signature by the CEO or other executive acknowledges that the policy meets the needs of the organization. The executive that signs should be senior enough that their signature will compel other departments to comply with the policy.]

Appendix

I. IT Resource Asset List

[As per the Asset Management Policy,] the asset list of the organization should cover all systems, software, firmware and devices of the organization. The asset list may also include devices outside of the control of the organization, but connected to the network such as BYOD, leased equipment with access, contractor’s equipment, etc.

Examples of resources on the asset list include, but are not limited to:

• Network equipment
  • Firewalls (and installed software, firmware, security features that require updates)
  • Network switches (and installed software, firmware)
  • Routers (and installed software, firmware)
• Servers (websites, application hosts, virtualization platforms, etc.) and installed operating system
• Installed operating system, installed software, firmware
  • Workstations
  • Tablets
  • Laptops
  • Cellular devices
• Internet of Things (IoT) and installed software and firmware
  • Voice over Internet Protocol (VoIP)
  • Security Cameras
  • Wi-Fi Connected TVs
  • Wi-Fi Printers
  • Network Printers
  • Storage Area Networks (SAN)
  • Voice-activated devices (Amazon Alexa, etc.)
  • [Heart monitors and other medical devices]
  • Solar panel systems
  • Door security badge-readers
• Operational Technology (OT) and Connected Infrastructure and installed software or firmware
  • 5G-connected conveyer belt
  • Connected HVAC equipment

The asset list should include:

• Type of asset (Server, PC, software, router, etc.)
• Device assigned owner (if a shared resource, the head of the associated department is the de facto assigned owner)
• Core OS, Firmware, or Software version
  [Note: tracking and maintaining specific versions can be useful, but burdensome for organizations using a manual tracking system.]
• Manual or automatic update?
• Updated by IT Department, automatic software update, third-party tool, or third-party service provider?
• Last updated
• Update successful (Y/N)
• Associated devices (i.e., for Adobe Acrobat software: installed on associated device: PC4362)

While the [IT Department] maintains responsibility for maintaining the asset list, department heads must inform the IT department about new assets (devices, installed software, etc.) deployed. Devices or software deployed without informing the IT department will be considered rogue devices and subject to blocking and removal.

The [IT Department] will conduct [continuous/monthly/daily/quarterly] scans of the IT environment to verify that the asset list remains current and to detect rogue devices or software.

The current asset list is stored:

[List the Asset database, Excel spreadsheet, asset management tool here.
Note: using an Excel spreadsheet can be vulnerable to accidental or intentional corruption or changes. A version-controlled Google Spreadsheet or an Excel file stored in OneDrive or Sharepoint would be better options.

Organizations should develop and maintain an Asset Management Policy. Development of the policy and an example asset list is beyond the scope of this sample document.BYOD devices should not be tracked in an asset list. The maintenance of BYOD devices should be enforced using network access control features or tools that check devices for minimally acceptable security profiles.]

The post Vulnerability Management Policy Template appeared first on eSecurityPlanet.

If your business collects personal and sensitive information, the risks and costs of a cyber attack or data breach are even higher, given the rise of data privacy regulations.

The cyber insurance market has been volatile in the last two years, as high-profile cyber attacks have caused premiums to soar and insurers to require clients to implement greater security controls in exchange for coverage. We cover more of these issues below, including tips on finding the best cyber insurance plan for your needs.

Top Cyber Insurance Companies List

There are many cyber insurance providers to choose from, but these five stand out in our analysis of the market.

• AmTrust Financial: Best Overall
• Chubb: Best for e-Commerce/Retail Businesses
• AIG: Best for Financial Institutions
• Beazley: Best for Healthcare Providers
• Hiscox: Best for Small Businesses

AmTrust Financial

Best Overall

AmTrust Cyber Insurance is designed to protect individuals and businesses from the financial and reputational losses associated with cyber attacks, data breaches, and other online threats. AmTrust has policies that cover a range of expenses associated with cyber incidents, including legal fees, public relations costs, forensic investigations, credit monitoring services, and even ransom payments. In addition, these policies may also provide coverage for business interruption losses and cyber extortion. That coverage can come at a cost, however, as AmTrust can be pricier than other insurers.

Pros

• Comprehensive coverage for a range of cyber risks caused by cyber incidents
• Customizable policies so businesses can tailor their policies to meet their specific needs
• Risk mitigation on financial risks associated with cyber incidents to give companies some peace of mind while running their business
• Cybersecurity experts to help your business in assessing unique cyber risks and developing a comprehensive risk management strategy tailored to a business’s specific needs

Cons

• Too expensive for small and mid-sized businesses (SMBs) with limited budgets
• Coverage limitations can impact coverage in certain situations. As with any insurance policy, there may be certain limitations and exclusions that are dependent on the level of coverage you choose to purchase.
• Deductibles may pose a challenge for businesses to cover expenses related to a cyber incident.
• Claim processing can be complex, especially for businesses without extensive experience dealing with insurance claims.

Pricing: To get a cyber insurance policy quote from AmTrust, visit amtrustfinancial.com/get-a-quote.

See the Top Cybersecurity Companies

Chubb Cyber Products

Best for e-Commerce and Retail Businesses

Chubb Cyber Products offers a range of cybersecurity policies you can choose from to meet your business’s needs. These include policies for SMBs as well as larger corporations. Policies can provide coverage for a range of cyber risks and threats and can be customized based on the level of risk and coverage your business desires. In addition to standard insurance policies, Chubb also offers specialized policies such as Cyber Enterprise Risk Management, which combines cyber insurance with risk consulting services to help you manage overall cyber risk. Innovative offerings, but prices can be higher than others.

Pros

• Comprehensive coverage that covers various types of cyber risks and threats
• Customizable policies can be tailored to meet your business’ specific needs and adjusted based on the needs of your business
• Risk management services help you manage and mitigate your business’s overall cyber risk, including incident response services
• Global coverage allows businesses with overseas branches to operate while still being covered by the same policy from the main headquarters

Cons

• Expensive policies price the company out of ranges for many small to medium-sized businesses. Although Chubb offers some of the most expansive coverage, the company is not looking into offering cheaper versions of their policies.
• Online assistance is not available so can’t get an instant chat with a company representative to get a preliminary quote for a policy.

Pricing: To get a cyber insurance policy quote from Chubb, you can request a quote or find an agent.

Also read: How to Create an Incident Response Plan

AIG

Best for FInancial Institutions

AIG is a global insurance company that offers cyber insurance particularly well suited for financial institutions, which face above-average risk because of their assets. AIG’s cyber insurance policies include coverage for first-party losses, such as business interruption and data restoration costs, as well as third-party liabilities, including fines and legal expenses.

Pros

• Strong financial stability so policyholders can be confident that AIG will be able to pay out claims if necessary
• Incident response services includes forensic investigation, legal support, public relations, and credit monitoring
• Expert claims team helps financial institutions and other clients navigate the claims process in event of a cyber attack so they can recover quickly
• CyberMatics is AIG’s program to help customers prioritize security improvements

Cons

• High premiums can be too much for smaller financial institutions and SMBs, making it difficult for some potential customers to justify the cost of coverage
• Complex policies can be difficult to understand and navigate, especially if you are not familiar with cyber insurance
• Limited customer service is the most common complaint of some customers, who say it is difficult for them to get in touch with AIG representatives when it comes to filing a claim or navigating their policy

Pricing: To get a cyber insurance policy quote from AIG, you can download an application on its cyber insurance page or find a broker.

Also read: Best Third-Party Risk Management (TPRM) Tools

Beazley

Best for Healthcare Providers

Beazley is a top provider of cyber insurance, particularly for healthcare providers in the U.S. Their cyber insurance policies are specially designed to address the unique risks faced by healthcare organizations, including Health Insurance Portability and Accountability Act (HIPAA) and Health Information Technology for Economic and Clinical Health (HITECH) violations, cyber extortions and data breaches.

Pros

• Regulatory compliance assistance helps healthcare providers comply with HIPAA and HITECH as well as help with fines and other penalties in the event of data breach
• Reputable and financially stable, which gives policyholders some added peace of mind
• Risk management services help healthcare providers and others identify and manage their cyber risks. This includes network security assessments, training programs, and other resources to help institutions prevent cyber attacks from happening.

Cons

• Limited availability in some countries and states because of regulations and laws regarding data protection and privacy

Pricing: To get a cyber insurance policy quote from Beazley, visit beazley.com/en-us/speak-underwriter.

Also read: Best Risk Management Software

Hiscox

Best for Freelancers and Small and Medium-Sized Businesses

Hiscox is an insurance and investment company that provides a diverse range of insurance products, including comprehensive cyber insurance coverage. Designed to meet the unique needs of freelancers and SMBs, Hiscox’s cyber insurance policies offer a wide range of premiums and coverage options tailored specifically for this market segment.

Pros

• Customizable coverage makes it easier for SMBs to tailor their policy according to their business needs. This includes the coverage costs of notifying customers and regulatory authorities, restoring data, and repairing damage to computer systems. These policies can also cover the costs of business interruption and reputational damage. In addition, Hiscox offers discounts on its products, making it easier for SMBs to get the most out of their policy.
• Holistic coverage protects SMBs and others against both the direct costs of a cyber attack (such as loss of income or business interruption) and the costs of lawsuits and regulatory fines resulting from a breach.
• Risk management services help SMBs prevent cyber attacks and reduce the likelihood of data breaches. These services can include cyber security assessments, employee training, and incident response planning.
• A mobile app makes it easier for policyholders to file a claim and make an initial assessment of their issues.

Cons

• Limited availability, as Hiscox is only available in 49 out of 50 states in the U.S. and doesn’t cover overseas business branches
• Reviews can be mixed, as some policyholders complain about customer service and the length of time agents can take to respond.
• Requires policyholders to work with other providers to get full business protection

Pricing: To get a cyber insurance policy quote from Hiscox, hiscox.com/small-business-insurance/cyber-security-insurance.

Why Do You Need Cyber Insurance?

Cyber attacks are becoming increasingly sophisticated and damaging, making cyber insurance an essential tool for businesses of all kinds. With customer and company-sensitive information often stored within reach of hackers, the risk of a cyber attack or data breach is only growing. By having a robust cyber insurance policy, your business can proactively manage these risks and ensure they have the necessary resources to recover quickly in the event of an attack. With the cost of an average data breach approaching $10 million in the U.S., according to IBM and Ponemon, cyber insurance is critically important for reducing financial risk.

In addition to providing protection in case of a cyber attack or data breach, cyber insurance policies can offer a range of services to help prevent such incidents from occurring. For example, some policies may include risk assessments, employee training programs, and access to cybersecurity experts who can advise on best practices and help implement security measures. And some partnerships between insurers and security vendors can result in better security at lower cost for policyholders.

Also read: What is Network Security? Definition, Threats & Protections

How Much Does Cyber Insurance Cost?

On average, small to medium-sized businesses pay around $1,500 annually for a $1,000,000 policy limit. However, larger companies or those with higher risk profiles may have to pay a higher premium for coverage. It’s important to note that investing in preventative measures such as regular employee training, strong access controls, and up-to-date security tools can help reduce the risk of a cyber attack and ultimately lower insurance costs over time.

The cost of a cyber insurance policy depends on a variety of factors specific to your business. Insurance companies consider factors such as the type of products or services that your business offers, business size, annual revenue, and the type of sensitive information collected. Additional considerations may include whether the business collects payments, and other relevant risk factors, such as the likelihood of a cyber attack against your particular industry

Also read: Main Targets of Ransomware Attacks & What They Look For

Calculating Cyber Insurance Requirements for Your Business

Determining the right level of cyber insurance coverage can be complicated, and insurance companies use several factors to calculate policy requirements for each business. Here are some factors that a potential insurer will examine to determine how much you need from a cyber insurance policy:

1. Business size: Larger businesses generally store more data and are at a higher risk of cyber attacks. If you own a large-scale business, you will likely require more coverage and a higher premium to adequately protect your business.
2. Industry type: Some industries, like healthcare and finance, handle sensitive data and are more vulnerable to cyber attacks. This may result in higher premiums and security requirements.
3. Risk profile: In addition to industry, insurance providers will evaluate your business’s specific risk profile, including the likelihood and potential impact of a cyber attack. Businesses with a higher risk profile will face higher premiums.
4. Security measures: The insurance provider will assess your business’s existing security measures such as firewalls, encryption, and employee training programs. Businesses with better security measures may be eligible for lower premiums.
5. Coverage limits: The amount of coverage a business needs will also affect the cost of the policy. Higher policy limits will generally result in higher premiums.
6. Claim history: A business’s past claims history will be taken into action when calculating the cost of a policy. If your business has had previous cyber security incidents or claims, you may face higher premiums.
7. Deductible: A higher deductible will result in a lower premium, while a lower deductible will result in a higher premium. The amount of the deductible, or the amount your business must pay before the insurance coverage kicks in, will also affect the cost of the policy.

The cost of a cyber insurance policy will depend on a variety of factors specific to your business in addition to what you want to be insured. It is important for you to work with a knowledgeable insurance provider to determine the appropriate coverage and premium to meet your business’s needs.

Selecting a Cyber Insurer

Cyber insurance policies can vary widely in terms of coverage, limits, and exclusions. It is important for you to carefully review and compare quotes to ensure that your business will have the coverage that meets your specific needs and risk profile. This may involve working with an insurance broker or consultant who specializes in cyber insurance to navigate the complex landscape of available options.

When selecting a cyber insurer, organizations should consider a number of different factors, including the financial stability of the vendor, the type of coverage provided (such as breaches, ransomware, DDoS attacks and regulatory compliance), and the cost. In addition, most of the vendors offer ancillary services designed to help protect against, prepare for, and respond to breaches. Partnerships with cybersecurity vendors can be another factor to consider.

If you already have an existing and satisfactory business relationship with an insurer who offers cyber insurance, they may be able to offer attractive rates by packaging cyber insurance with other types of insurance.

Other factors to consider when purchasing cyber insurance are:

• Knowledgeable underwriters: There have been many new entrants to the cyber insurance market over the last several years, with many hoping to take advantage of the fast-growing market and its opportunities. It’s important to work with a carrier who has a strong track record in the market, has shown a commitment over the long-term (some longevity), and can show strong financial stability.
• Quality of coverage: it’s important to know what is really being offered in your policy, and maybe even more important, what’s not. Companies need to look at policy exclusions to see what is being excluded.
• Claims handling: In-house claims expertise and an incident response team is a big plus. Many carriers outsource their claims handling to third parties, which may not be as familiar with the insurance product and, being one step removed, may be less likely to be a true partner for the insured.

Effective cyber risk management requires being prepared, taking all precautions possible to prevent an incident from occurring, but arguably most importantly, knowing how to respond when something happens, and having experts on hand in multiple fields of expertise to assist in claims.

Bottom Line: Cyber Insurance Companies

With the cost and sophistication of cyber attacks continually rising, it is imperative that businesses of all kinds protect their assets with robust cybersecurity controls and comprehensive cyber insurance. With a wide range of policies tailored to fit specific business needs, cyber insurance providers play a crucial role in mitigating potential threats, and they can also offer an easier way for companies to upgrade their cybersecurity controls.

Don’t wait for an attack to occur to take action. Protecting your business today will give it a better chance to survive a cyber attack,  will give you greater confidence and peace of mind.

See the Best Incident Response Tools and Services

This updates an April 2022 article by Drew Robb

The post Top 5 Cyber Insurance Companies for 2023 appeared first on eSecurityPlanet.

“I remember the first time we were asked for a SOC 2 report, which quickly became the minimum bar requirement in our industry for proof of an effective security program,” he said.

The process for creating the report was time-consuming, manual and costly. It was also a drag on the sales cycle, and then there was the need for maintaining compliance.

When Markowitz departed Portfolium after selling the company to Instructure, he teamed up with Daniel Marashalin and Troy Markowitz to launch Drata in the summer of 2020. The vision was to automate security and compliance across 14 frameworks, including SOC 2, ISO 27001, HIPAA and GDPR. This is all done with continuous control monitoring and evidence collection.

Growth has definitely been robust. There are currently more than 2,000 customers.

In early December, Drata announced its Series C funding for $200 million, led by ICONIQ Growth and GGV Capital. The valuation was set at $2 billion. Among the company’s investors have been tech luminaries such as Frank Slootman, CEO of Snowflake Computing, and Microsoft CEO Satya Nadella.

“And for Drata, fundraising has always been viewed as a tactic rather than a goal or outcome,” said Markowitz. “Our funding not only validates our execution to date, but also represents our continued efforts to expand our product capabilities and help us navigate this next stage of growth.”

GRC Market Defies Downturn

There are some powerful drivers for the compliance and security automation market. First of all, cybersecurity is becoming a “must have” for businesses and governments. The threat environment has become increasingly more challenging, especially with distributed environments. The move to remote work has only worsened the problems.

Just look at the case of Rackspace. The cloud computing services company was hit by a ransomware attack in early December that disrupted the mail servers for thousands of customers. The result is that Rackspace shares plunged by about a third. Lawyers have already filed a class action lawsuit.

The growing number of data privacy regulations has raised the potential consequences of cybersecurity breaches, spurring demand for GRC (governance, risk, and compliance) software. IDC expects GRC spending to hit $15 billion by 2025.

OneTrust is another company benefiting from the booming compliance market, rocketing to a $5.3 billion valuation in less than seven years and earning a top 10 ranking in our list of the top cybersecurity companies.

What’s more, the automated compliance and security software market is likely to benefit from slow growth or even a recession, as the technology can be a way to streamline operations and lower costs.

For example, when it comes to preparing for a cybersecurity audit, the evidence required is a major pain point for companies. In the case of Lemonade – an online insurance company – it spent over 200 hours on the process. But when using Drata, it took only a tenth of the time.

Given these growth drivers, VCs have been ramping up investments in the category. Here are a few other winners.

See the Top GRC Tools & Software

Laika

One growing use for compliance tools has been to speed up M&A deals.

“Having built tech companies, it became increasingly clear that compliance shortcomings were a roadblock to closing enterprise deals,” said Austin Ogilvie, who is the cofounder and co-CEO of Laika, a security and compliance automation platform company. “There were shortcomings like cybersecurity capabilities, lack of robust controls around access, resiliency, and recovery. They were costing me millions in delays and lost deals.”

Laika is certainly comprehensive. It provides not only advanced compliance automation, but there is also integrated auditing and penetration testing.

Laika is not just software; it also includes services. The company provides hands-on guidance for customers, such as with a dedicated Compliance Architect. “It’s really the humans behind the product that sets us apart,” said Ogilvie.

In early November, Laika announced its Series C funding for $50 million, which was led by Fin Capital. Other investors included J.P. Morgan Growth Equity Partners, Canapi, and ThirdPrime.

Sprinto

Security compliance tools can also be used to make sure that applications and systems run optimally.

“Security is largely about having the right operational processes and discipline in place,” said Girish Redekar, who is the CEO and cofounder of Sprinto.

That’s why his company’s platform integrates with many systems that cloud companies use daily, like CRM and code management systems. Sprinto checks to see if they are used with the highest levels of data security and business continuity.

The system also typically provides more value over time. For example, after you set up a framework for SOC 2, it makes it much easier to be successful with other areas like ISO27001 or GDPR.

“We are focused on liberating security compliance from confusion and making it accessible, affordable, and actionable through the smart application of technology,” said Redekar.

In early 2022, Sprinto announced its $10 million Series A funding, and the lead inventor was Elevation Capital. Other backers included Accel and Blume Ventures.

Strike Graph

For more than 20 years, Justin Beals has served as a Chief Technology Officer, data scientist, VP of Product and engineer. While at his last startup, he realized that he could turn security into a sales asset.

“My cofounder, Brian Bero, and I incubated Strike Graph at Madrona Venture Labs in early 2020 and launched later that year,” he said. “We were excited about the idea of empowering other organizations to not think of security activity as a cost center but as a revenue driver.”

A challenge for compliance automation is that no two companies are alike. Each has their own unique technology architecture and business processes.

This is why Beals has positioned Strike Graph as a security orchestration and measurement solution.

“Our customers can select the right set of controls from our database of 400+ security controls, integrate with thousands of cloud provider data elements according to their unique architecture, and successfully complete common security assessments from Penetration Tests to SOC 2 audits without engaging extemporaneous vendors,” he said.

In late 2021, Strike Graph announced its Series A funding for $8 million. The lead investor was Information Venture Partners.

Read next: Top Cybersecurity Startups to Watch

The post Automated Security and Compliance Attracts Venture Investors appeared first on eSecurityPlanet.

Since the inception of data forensics almost forty years ago, methods for investigating security events have given way to a market of vendors and tools offering digital forensics software (DFS).

While several open-source tools exist for disk and data capture, network analysis, and specific device forensics, a growing number of vendors are building off what’s publicly available. As cybercrime flourishes and evolves, organizations need a range of tools to defend against and investigate incidents.

This article looks at the top digital forensics and incident response (DFIR) software tools and what customers should consider when buying or acquiring such tools. We include several free and open-source tools here, but the emphasis is on commercially available and supported solutions and services.

Also see the Best Incident Response Tools and Software

Jump ahead to:

• Top Digital Forensics Tools
  • Paraben Corporation
  • The Sleuth Kit and Autopsy
  • OpenText
  • Magnet Forensics
  • CAINE
  • Kroll Computer Forensics
  • SANS SIFT
  • Exterro
  • Volatility
  • X-Ways
  • Cellebrite
  • ProDiscover
  • Wireshark
  • Xplico
  • LogRhythm
  • Global Digital Forensic
• Digital Forensics Trends: Data Migration, Speed & Zero Trust
• Considerations for Digital Forensics Software (DFS) Solutions
• Why Do You Need Digital Forensic Software?
• What Are Common DFS Product Capabilities?

Top Digital Forensics Tools

eSecurity Planet evaluated a great many vendors to come up with our list of the top digital forensics products, analyzing everything from product features to analyst and user opinions. These 16 products stood out in this important market.

Paraben Corporation

Paraben Corporation entered the cybersecurity marketplace in 1999, focused on digital forensics, risk assessment, and security solutions. Today, in a world with billions of devices, Paraben covers forensic investigations involving email, computers, smartphones, and Internet of Things (IoT) devices.

Key Differentiators

• The Paraben E3 Forensic Platform streamlines data from multiple sources.
• E3:Universal covers all devices, E3:DS is for mobile forensics, E3:P2C is for computer forensics, and E3:EMAIL for email.
• There are hash databases for filtering; viewers for files, hex, text, RTF, and emails; and automated embedded data detection (OLE).
• Paraben provides remote access with collection from machines and cloud storage.
• Paraben offers IoT support for brands like Xbox and Amazon Echo and cloud support for Google, Dropbox, and Slack.
• Users have the ability to work with multiple data sources together for analysis; can collect from a wide range of sources including computers, smartphones, IoT, and cloud to sort the data to logical categories; recover information; and search in multiple languages.
• Capabilities provided at a single price point with components such as cloud for computers and mobile are included.

Pricing: Monthly pricing is available for access to training courses, with a software license included. A free version is also available.

The Sleuth Kit and Autopsy

The Sleuth Kit (TSK) and Autopsy are popular open-source digital investigation tools. Sleuth Kit enables administrators to analyze file system data via a library of command-line tools for investigating disk images. Autopsy is its graphical user interface (GUI) and a digital forensics platform used in public and private computer system investigations to boost TSK’s abilities.

Key Differentiators

• TSK offers well-regarded and reviewed disk and data capture tools.
• Capabilities include timeline analysis, hash filtering, file and folder flagging, and multimedia extraction.
• Autopsy allows users to efficiently analyze hard drives and smartphones.
• Its plug-in architecture allows users to find add-on modules or develop custom modules in Java or Python.
• Sleuth Kit is a collection of command-line tools and a C library to analyze disk images and recover files.
• Commercial training, support, and custom development is available from Basis Technology.
• The core functionality of TSK is to analyze volume and file system data.
• The library can be incorporated into larger digital forensics tools, and the command-line tools can be directly used to find evidence.
• TSK is used by law enforcement, military, and corporate examiners to investigate what happened on a computer.
• TSK can be used to recover photos from a camera’s memory card.

Pricing: TSK and Autopsy are open source and free, but commercial support is available.

OpenText

Founded in 1991 in Waterloo, Ontario, OpenText offers enterprise content management, networking, automation, discovery, security, and analytics services. OpenText EnCase solutions include Endpoint Security (endpoint detection and response, or EDR), Endpoint Investigator (DFIR), Forensic, Mobile Investigator, and Advanced Detection. These solutions help with recovering of evidence from multiple device types and hard drives, automating the preparation of evidence, deep and triage analysis, and evidence collection and preservation.

Key Differentiators

• EnCase Forensic is court-proven in finding, decrypting, collecting, and preserving forensic data from a variety of devices, while ensuring evidence integrity and integrating with investigation workflows.
• EnCase can acquire evidence from a variety of sources and dig deep into each source to uncover potentially relevant information.
• Predefined or customized conditions and filters can quickly locate evidence.
• Evidence processing, integrated workflows, and flexible reporting are all features offered by EnCase.
• EnCase works across computers, laptops, and mobile devices to determine whether further investigation is warranted.
• The platform ranks evidence by importance.
• Real-time evaluation of evidence is provided.

Pricing: OpenText EnCase pricing is available upon request.

Magnet Forensics

Noticing that digital forensic tools used by law enforcement were insufficient, Canadian police officer Jad Saliba founded Magnet Forensics in 2011. The company offers digital forensic investigative tools to public and private organizations. Products include Magnet Axiom Cyber for incident response, Magnet Automate Enterprise, and Magnet Ignite for triage.

Key Differentiators

• Magnet Forensics now has more than 4,000 customers in over 100 countries.
• Magnet supports every digital evidence source, not just Linux and Windows OS.
• Magnet Axiom Cyber incident response is used to perform remote acquisitions and recover and analyze evidence from computers, the cloud, and mobile devices.
• Magnet Automate Enterprise is an automation solution used to simultaneously collect and process evidence from multiple endpoints in the wake of a security incident.
• Magnet Ignite performs fast, remote scans and initial analysis of endpoints as a triage action.
• Magnet Forensics performs remote acquisitions of Mac, Windows, and Linux endpoints, even when they aren’t connected to company networks.
• Data can be recovered from apps such as Microsoft Office 365 and Slack as well as storage services like Amazon Web Services and Microsoft Azure.
• All evidence is brought into one location where security teams can analyze it.
• Evidence can simultaneously be recovered and processed from multiple endpoints.
• SIEM (security information and event management) and EDR tools are integrated into workflows and a digital investigation can automatically be triggered when a threat is detected.

Pricing: Magnet doesn’t provide pricing, but free trials are available.

CAINE

The Computer-Aided Investigative Environment (CAINE) is an Italian open-source Ubuntu- and Linux-based distribution for digital forensic purposes. CAINE integrates with existing Windows, Linux, and Unix systems security tools.

Key Differentiators

• CAINE provides automatic extraction of timelines from RAM (random access memory).
• It is an interoperable environment that supports the digital investigator during the four phases of the digital investigation.
• All block devices are blocked in read-only mode.
• CAINE can be used with a GUI named Unblock, which is present on CAINE’s desktop.
• CAINE assures that all disks are protected against accidental writing operations.
• If the user needs to write a disk, it can be unlocked.

Pricing: CAINE is open source and thus free.

Kroll Computer Forensics

Kroll’s computer forensics services and experts ensure that no digital evidence is overlooked and assist at any stage of an investigation or litigation, regardless of the number or location of data sources.

Key Differentiators

• Physical and digital evidence is examined to uncover what did or did not happen, using a combination of computer forensic expertise and traditional investigative techniques.
• Defensible methodologies and solutions are available to identify and preserve electronic data.
• Regardless of the volume and complexity of collection needs, Kroll gathers data for electronic investigation and forensic analysis or forensic discovery.
• Whether data was deleted or manipulated on purpose or by accident, Kroll analyzes the digital clues left behind to uncover critical information.
• Experts are available on call to serve as an expert witness or special master.

Pricing: Available upon request.

SANS SIFT

SIFT Workstation is a collection of free and open-source incident response and forensic tools to perform digital forensic examinations. Offering an array of free and open-source DFIR solutions, the SIFT Workstation provides various options for deployment including virtual machine (VM), native installation on Ubuntu, or installation on Windows via a Linux subsystem.

Key Differentiators

• Developed by the SANS Institute in 2007, SIFT works on 64-bit OS, automatically updates the software with the latest forensic tools and techniques, and is a memory optimizer.
• SIFT Workstation is continually updated and has over 125,000 downloads.
• SIFT Workstation is used as part of SANS Institute training on incident response, network forensics, and cyber threat intelligence.
• It can analyze file systems, network evidence, memory images, and more.
• Support is available for NTFS, ISO9660 CD, HFS, and FAT.
• SIFT Workstation has been upgraded to improve memory utilization.
• There is cross compatibility between Linux and Windows systems.

Pricing: Available for free from SANS.

Exterro

Hailing from Portland, Oregon, Exterro launched in 2004 and specialized in workflow-driven software and governance, risk, and compliance (GRC) solutions. While all of our picks inherently support organizations’ needs to maintain compliance, Exterro is especially valuable to assist in-house legal teams, streamline compliance processes, and control risks.

Exterro offers products across e-discovery, privacy, risk management, and digital forensics. Known for its forensics-focused products dubbed FTK, its capabilities include Mac and mobile data investigations, remote agent endpoint collection, scalable DPE (data processing environment), and automated workflows.

Key Differentiators

• Exterro’s operations are SOC 2 Type 2 certified and FedRAMP authorized.
• Products are split into FTK Imager, FTK Lab, FTK Central, FTK Enterprise, and FTK Connect (previously known as API-specific solutions).
• The overall Exterro FTK Forensic Toolkit has been used in digital forensics for over 30 years for repeatable, reliable investigations.
• All FTK solutions feature fast data processing, including for mobile data extractions.
• Exterro provides remote endpoint investigation, triage, collection, and remediation.
• Unlimited DPE scalability is available to meet heavy demand.
• Exterro requires minimal training.
• Exterro is a web-based, collaborative platform to centralize forensic evidence.
• Automation is available for workflow tasks and orchestration with SIEM and SOAR (security orchestration, automation, and response) platforms.
• Examiners can perform a rapid risk assessment of a suspected compromised endpoint — even if it is disconnected from the VPN network — by previewing the live contents of an off-network endpoint before performing a time-consuming collection.
• Integration with cybersecurity platforms, such as Palo Alto Cortex XSOAR, allows users to capture and preserve endpoint data immediately upon detection of a possible threat.
• No API (application programming interface) or Python scripting is required.

Pricing: FTK Imager is free; quote available upon request for other Exterro FTK solutions.

 Volatility

Volatility is a command-line memory analysis and forensics tool for extracting artifacts from memory dumps. Volatility Workbench is free, open-source, and runs in Windows. This forensics framework for incident response and malware analysis is written in Python and supports Microsoft Windows, Mac OS X, and Linux.

Key Differentiators

• There is no need to install a Python script interpreter.
• Memory forensics technology enables investigators to analyze runtime states using RAM data.
• Knowledge of operating system (OS) internals, malicious code, and anomalies is used to enhance its tools.
• Embedded API can be used for lookups of PTE (page table entry) flags.
• Volatility has support for kernel address space layout randomization (KASLR).
• There is an automated execution of a failure command after multiple failed starts.
• In 2020, the Volatility Foundation released a complete rewrite of the framework known as Volatility 3 to address technical and performance challenges associated with the original code base released in 2007.

Pricing: The Volatility framework is free and open source.

X-Ways

X-Ways Forensics is a work environment for computer forensic examiners. Known for not being resource-hungry, yet speedy, it is based on the WinHex hex and disk editor and offers additional disk and data capture software, cloning, imaging, and other tools.

Key Differentiators

• X-Ways is portable and runs off of a USB stick on any given Windows system without installation if desired.
• X-Ways downloads and installs within seconds.
• Computer forensic examiners are enabled to share data and collaborate with investigators that use X-Ways Investigator.
• X-Ways runs under Windows XP/2003/Vista/2008/7/8/8.1/2012/10/2016/2019/11, 32-bit/64-bit, and standard/PE/FE.
• Automatic detection of lost or deleted partitions is made.
• Read partitioning is available for file system structures inside .dd image files.
• X-Ways provides analysis of remote computers.
• X-Ways can access disk and RAID configurations and detect NTFS (new technology file systems) and ADS (alternate data streams).
• There are templates to view and edit binary data.
• X-Ways offers built-in interpretation of JBOD, RAID 0, RAID 5, RAID 5EE, and RAID 6 systems, Linux software RAIDs, Windows dynamic disks, and LVM2.
• Native support is available for FAT12, FAT16, FAT32, exFAT, TFAT, NTFS, Ext2, Ext3, Ext4, Next3, CDFS/ISO9660/Joliet, and UDF.

Pricing: X-Ways publishes its prices and claims a pricing advantage over competitors.

Cellebrite

Started in 1999 in Israel, Cellebrite specializes in mobile device forensics for law enforcement and enterprises that need to collect, review, analyze, or manage device data. The Digital Intelligence Investigative Platform helps unify the investigative life cycle and preserve digital evidence.

Key Differentiators

• Cellebrite Universal Forensic Extraction Device (UFED) can extract physical and logical data.
• Recovery methods include exclusive bootloaders, automatic EDL (emergency download) capability, and smart ADB (Android Debug Bridge).
• Cellebrite can provide analysis on Windows and Mac.
• Users can find internet history, downloads, recent searches, top sites, locations, media, messages, recycle bin, USB connections, and more.
• AI-assisted picture and video categorization, filtering, and support for whole disk encryption are available features.
• Cellebrite shows the timeline of an event and reveals the real story behind each case.
• Cellebrite is designed to scale and sift through large datasets.
• Cellebrite creates customized, court-ready reports.
• The platform exports findings easily.

Pricing: Available upon request.

ProDiscover

ProDiscover launched in 2001 to help public and private organizations solve digital crimes. As of 2021, the India-based provider works in over 70 countries with more than 400 clients, including the NIST, NASA, and Wells Fargo. ProDiscover Forensics captures evidence from computer systems for use in forensic investigation to collect, preserve, filter, and analyze evidence.

Key Differentiators

• ProDiscover offers three products that prioritize computer forensics, incident response, electronic discovery, and corporate policy compliance investigations.
• ProDiscover locates data on a computer disk as well as protecting evidence and creating reports.
• EXIF data can be extracted from JPEG files.
• Copies of suspicious disks can be made.
• Support is available for VMware to run captured images.
• ProDiscover supports Windows, Mac, and Linux file systems.
• Evidentiary reports can be prepared and presented in court.
• ProDiscover previews and images disks.
• Memory forensics is available.
• ProDiscover offers text search with multilingual capabilities.
• ProDiscover includes cloud, social media, Web, and email investigation.

Pricing: Available upon request.

Wireshark

First developed in 1998, Wireshark does forensic investigation and analysis of network packets and conducts testing and troubleshooting of networks. This includes inspection of hundreds of protocols in a three-pane packet browser that encapsulates data structures.

Key Differentiators

• Wireshark is multi-platform compatible, running on Windows, Linus, macOS, Solaris, FreeBSD, and NetBSD.
• Network analysis is available with VoIP (voice over Internet Protocol) analysis.
• Wireshark can capture files compressed with gzip and export outputs to XML, CSV, or plain text.
• Users can see what’s happening on a network.
• Live capture and offline analysis are available.
• Captured network data can be browsed via a GUI, or via the teletypewriter (TTY)-mode TShark utility.
• Wireshark can read and write many different capture file formats: tcpdump (libpcap), Pcap NG, Catapult DCT2000, Cisco Secure IDS iplog, Microsoft Network Monitor, Network General Sniffer (compressed and uncompressed), Sniffer Pro, and NetXray, Network Instruments Observer, NetScreen snoop, Novell LANalyzer, RADCOM WAN/LAN Analyzer, Shomiti/Finisar Surveyor, Tektronix K12xx, Visual Networks Visual UpTime, and WildPackets EtherPeek/TokenPeek/AiroPeek.
• Decryption support is available, including IPsec, ISAKMP, Kerberos, SNMPv3, SSL/TLS, WEP, and WPA/WPA2.

Pricing: Wireshark is free and open source and boasts an active user community, but commercial training is also available.

Xplico

Created in 2007, Xplico is a network forensics analysis tool that restructures data via a packet sniffer. It specializes in port independent protocol identification (PIPI) to reconstruct application data to identify its protocols. Available as a free and open-source tool, Xplico’s primary objective is to extract application data from an internet traffic capture.

Key Differentiators

• Xplico supports HTTP, IMAP, POP, SMTP, IPv6, and more.
• Xplico creates XML files that identify the flows and pcap (inputs file) contained in each data structure reassembled.
• Multithreading is possible.
• There are no data entry limits.
• Xplico can execute reserve DNS (Domain Name System) lookup from DNS pack.
• Xplico provides output data and information in SQLite database or Mysql database and/or files.
• All data reassembled by Xplico has an associated XML file that uniquely identifies it.
• Realtime elaboration.
• TCP (Transmission Control Protocol) reassembly with ACK (acknowledgement) verification is available for any packet or soft ACK verification.
• Reverse DNS lookup from DNS packages is contained in the input files, not from an external DNS server.

Pricing: Xplico is free and open source.

LogRhythm

LogRhythm is best known for SIEM, threat intelligence, and UEBA (user and entity behavior analytics). Started in 2003 out of Boulder, Colorado, the company includes network forensics via a feature known as NetMon, but the company has been refocusing its forensics efforts as part of its network detection and response (NDR) and endpoint monitoring solutions.

Key Differentiators

• LogRhythm aggregates packet capture and derived metadata, preserves the log data, and uses network forensic sensors to fill in the gaps.
• LogRhythm measures mean time to respond (MTTR).
• Dashboards are able to identify threats.
• LogRhythm offers application recognition of over 3,000 applications and metadata for visibility into network sessions.
• Script-based deep packet analytics (DPA) is available for real-time detection.
• LogRhythm provides session-based full packet capture.
• LogRhythm offers Layer 4–7 analysis with application ID.
• SmartCapture selective packet capture is available.
• Automation actions can obtain sessions through packet capture and future case analysis.

Pricing: Available upon request, but you may still be able to obtain NetMon Freemium.

Global Digital Forensic

Global Digital Forensics has been involved in computer forensic analysis and litigation support for over two decades. It offers a range of forensic services covering all digital devices. Founded in 1992, GDF also provides e-discovery services, penetration testing, and breach response services.

Key Differentiators

• Global Digital Forensics has its own labs as well as a global network of responders, allowing it to perform forensic analysis for virtually anything in any environment.
• GDF provides expert computer witness testimony in cases.
• Features include investigative tools for computers, email, mobile devices, social networks, and disk drives.
• Data retrieval and recovery services are available.
• GDF provides forensic readiness assessments.
• GPS and smartphone tracking, internet history analysis, image recovery and authentication, and chip-off analysis are available.
• GDF offers recovery of data from all devices, from mainframes to smartphones.
• Users can find evidence in log files and video.

Pricing: Available upon request.

Digital Forensics Trends: Data Migration, Speed & Zero Trust

The data forensics market has changed a lot since our last update more than a year ago, and can be summed up with two words: speed and security.

Lee Proctor of Paraben says data is being migrated in order to make it more accessible and nearer at hand for the forensic tools that are used to investigate it.

And as cyber criminals continue to increase the frequency and severity of their attacks, enterprises will look to augment that need for speed by incorporating automation into their digital forensic and incident response workflows.

“The risks from both internal and external threats have only intensified with the shift to hybrid and remote work models,” said Adam Belsher, CEO of Magnet Forensics. “The success of a cybersecurity strategy now lies both with the individual employee and the environment created to protect them. Employees are being exposed to more threat vectors than they ever have because they’re using their own devices and more third-party apps. One error from one individual can expose an enterprise’s entire network to serious harm.”

Getting forensic evidence into the hands of investigators as fast as possible is the key to bringing cyber criminals to justice. Fast processing is a must, especially for mobile device data.

At least 70% of law enforcement investigations and a rising number of civil cases involve mobile data. Frontline officers must be able to extract, process, and parse mobile evidence quickly to then pass it to an analyst for review, all while preserving the chain of custody.

“To date, investigators have attempted to overcome these issues by manually processing data or passing data between multiple forensic platforms, but it’s a slow and cumbersome process that has seen case backlogs grow and increased the risk of data loss or compromise,” said Harsh Behl, director of product management at Exterro. “Having one collaborative platform where all types of device data can be collected, processed, and reviewed is the best way to streamline this workflow.”

Conducting internal investigations within zero trust

More and more organizations are allowing their employees to work from home indefinitely. This has introduced a greater reliance on a secure VPN network and zero-trust architecture. But IT and human resources (HR) teams must still be able to conduct internal investigations, such as the forensic collection of evidence relating to suspicious endpoint activity or a rogue employee.

“Being able to conduct incident response and carry out an endpoint triage remotely means the investigator does not need to physically be present to collate the evidence, resulting in a speedier response, which is vital in cases where malware can have time to propagate,” said Behl. “By examining data off the network, it can ensure the data is isolated and comply with the demands of a zero-trust infrastructure, which requires all access to be authenticated.”

Buying Considerations for Digital Forensics Software (DFS) Solutions

Now that you know the top digital forensics vendors, here’s what’s most important in evaluating DFS solutions.

• How will the solution improve your digital forensics capabilities?
• What types of devices and file formats does the product support?
• Does the software come with a user-friendly interface or training for staff?
• What integrations and plugins are compatible or can be configured for use?
• What advanced analytic features make the solution stand out?

The following sections touch on the importance of DFS capabilities and trends in the DFS market.

Why Do You Need Digital Forensic Software?

You need digital forensics software (DFS) because it plays a crucial role in a comprehensive cybersecurity infrastructure. Vulnerabilities are an inherent part of digital systems, and there’s no shortage of security incidents.

While a security information and event manager (SIEM) and endpoint detection and response (EDR) can offer real-time logging, alert, and defensive capabilities, DFS specializes in investigating IT systems in the context of security events. Digital forensics is often lumped together with incident response efforts – as the combined solution is known as digital forensics and incident response (DFIR).

What Are Common DFS Product Capabilities?

Some key features of digital forensics tools include:

• Advanced data and metadata searches and filtering
• Automatic report generation
• Bit-by-bit copies and disk cloning
• Bookmarking of files and sectors
• Evidence preservation using hashes
• File recovery for hidden and deleted data
• Forensically sound evidence acquisition
• Hash and password cracking
• Image creation and mounting for supporting various formats
• Live and remote acquisition of evidence
• RAM and paging file analysis
• Registry analysis tools
• Write blocking

Read next: Best Risk Management Software

This post was created by Sam Ingalls on Aug. 14, 2021 and updated by Drew Robb on Oct. 6, 2022, and Paul Shread on Jan. 19, 2023.

The post 16 Best Digital Forensics Tools & Software in 2023 appeared first on eSecurityPlanet.

Comments intended to guide understanding and use of this patch management policy template will be enclosed in brackets “[…]” and the ‘company’ will be listed as [eSecurity Planet] throughout the document. When converting this template to a working policy, eliminate the bracketed sections and replace “[eSecurity Planet]” with “YourCompanyName.”

This policy will reflect a generic IT infrastructure and needs. It can be modified as needed to reflect a specific company’s IT infrastructure and needs.

To use this template, copy and paste the website text or download the Microsoft Word Template below.

[eSecurity Planet (or your company name here)] Patch Management Policy

1. Overview

Vendors regularly deliver feature updates, correct malfunctions, and issue security patches to improve the performance and eliminate security vulnerabilities in their products. Prompt adoption of these updates protects against threats and potentially improves the experience for users and can improve productivity for the organization.

Unpatched resources expose users, data, and other company resources to unacceptable risk. This Patch Management Policy:

• Outlines the expectations, requirements, basic procedures to maintain [eSecurity Planet] systems and software
• Defines reports to verify compliance with this policy
• Provides penalties for failure to comply with this policy.

[The purpose of this section is to introduce the reader to the policy purpose and what to expect later in the document. Policy defines what MUST be done, but not HOW it must be done. IT managers need the flexibility to accomplish the goals within their resources as they see fit.]

Learn more about patch management policy

2. Scope

This policy applies to all [eSecurity Planet] resources that connect to the organization’s network, enable the organization’s mission, or host the organization’s data. The organization will maintain and track a formal list of resources within the scope of this policy as defined in as defined in Appendix I: IT Resource Asset List of our downloadable template.

Patch management relies upon accurate lists of existing systems and software for updates. The scope should be verified [as per the asset management policy / monthly / quarterly] to ensure all assets can be accurately assessed for patching and updating.

[This is the most aggressive version of the scope. Some organizations do not attempt to update or monitor their employee’s devices connected to the network or ignore Internet of Things (IoT) devices. While this is risky, some organizations tacitly accept these risks for simplicity or because of resource constraints (budget, IT staff, time, etc.).

Scope should define what will be monitored for updating and patching. If the IT department will only patch operating systems for servers and endpoints, then edit the scope to say that – and accept the risks for the unmonitored systems.]

3. Patch Management Policy & Procedure

A. Patch Management Authority

[The Chief Information Officer (CIO) of eSecurity Planet] is designated as the Patch Management Authority that holds the ultimate responsibility and authority to plan, execute, authorize, or delegate any and all sections of this patch management policy and procedure to internal resources or third-party tools or vendors.

While the Patch Management Authority maintains ultimate responsibility, it is acknowledged that the [IT Department] will generally execute the Patch Management Authority’s plans to comply with the Patch Management Policy. The use of IT Department elsewhere in this policy refers to the Patch Management Authority, the [IT Department], and delegated representatives.

The Patch Management Authority also verifies and approves:

• Patch Management Policy Scope
• Patching priority
• Patching testing and approval
• Any maintenance downtime needed for applying patches and updates
• Any mitigations or exceptions needed
• Patch management reports
• Enforcement

[This section defines who needs to sign off on the budget and manage the patch management process. It is best to use a title because people sometimes change and the policy should not need to be revised with every personnel change.]

B. Patch and Update Acquisition

The IT Department will continuously monitor and scan a variety of sources to obtain information regarding the release of updates and patches for all assets within the scope of this policy. Sources may include, but are not limited to: security mailing lists, vendor notifications, and websites.

When a patch or update becomes available, the IT Department will find and verify the validity of the source prior to downloading the update. The preferred method is to obtain patches directly from the source vendor (company or organization that developed the resource for which the update was released) or from a service provider that obtains updates directly from the source vendor.

Patches and updates from other sources must be scrutinized and tested carefully prior to their introduction into the organization’s environment.

[This section is designed to enforce vigilance and prompt recognition of available updates and patches. Best practices suggest that specific individuals be assigned the task of researching, locating, and verifying the source of updates and patches.]

C. Patching Priority

Multiple patches and updates may become available simultaneously. If necessary, the IT Department will determine the priority for patching and updates and create a hierarchy based upon:

• The Common Vulnerability Scoring System (CVSS) Score of the patched vulnerability
• The risk value of the asset
• The likelihood of exploitation

The CVSS assigns vulnerabilities a score between 1 and 10. The CVSS version 3.0 ratings correspond to:

• 9.0 – 10.0 = Critical Severity
• 7.0 – 8.9 = High Severity
• 4.0 – 6.9 = Medium Severity
• 0.1 – 3.9 = Low Severity
• 0.0 = No Severity (Informational)

These scores do not suggest likelihood of exploitation, but do suggest a level of how much an attacker can affect a system or how much effort may be required. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) maintains a list of known exploited vulnerabilities that can be referenced to check for active exploitation.

[eSecurity Planet] uses risk analysis to create a Risk Assessment of internal systems that is recorded and updated in a Risk Register on a scale from 1 (low impact/value) to 10 (highest impact/value). Similarly, the IT Department needs to evaluate the current environment, the current IT architecture, and the nature of the vulnerability to determine the likelihood of exploitation, which should also be evaluated on a scale from 1 (low likelihood) to 10 (high likelihood). Adding all three of these factors will create a value between 2 (low priority or no action needed) and 30 (urgent action needed) for the patch to be applied.

When outsourcing to a service provider or using a patching tool, some patching will be performed automatically and no patching priority may be necessary. Patching priority will be required for updates and patches that:

• Require resource shut-down for maintenance
• Conflict with other patches and updates
• Cause problems with other systems or business processes

The manual patching queue may contain older, less urgent patches. New patches released should replace outdated patches in the queue. The replacement patch can take the same priority as the old patch or be re-prioritized at the IT Department’s discretion.

[This section assigns a priority to help determine which patches should be applied first in the patch management process. Weighting patch priority by CVSS tends to be the most common method used for prioritization and some organizations strictly use that method.

The value to the company and the likelihood of exploitation should also be considered when determining a priority. Still, be careful that no one manipulates the exploitation risk and value of the asset as a matter of casual convenience to avoid dealing with the update.

Managed patching services and tools will likely use CVSS values because they are tangible and neither the service nor the tool generally has visibility into asset values to the organization.

This section references Risk Assessments and a Risk Register. Organizations of all sizes can and should produce a Risk Register. The risk register assesses the value of a resource and how large an impact on the organization may occur if that resource is impaired, becomes compromised, or fails. If no Risk Register is in place an organization will need to make a qualitative estimate of the value of the resource to the organization.]

D. Patching and Update Schedule

Based upon the patching priority rating of 2 to 30 the IT Department will be required to apply the patch:

• 24.0 – 30: within [7] days of patch release
• 18.0 – 23.9: within [14] days of patch release
• Security patches below 18.0: within [30] days of release

Non-security patches (upgrades and bug fixes) shall be applied on a normal maintenance schedule as defined by normal systems maintenance and support operating procedures, but not to exceed [90] days. Lower-rated patches and updates can be applied along with higher priority patches or updates upon the discretion of the IT Department.

For example:

• A non-critical software bug fix rated 8.4 can be installed simultaneously along with other vulnerability fixes rated 25.3 and 28.0.
• A non-critical feature upgrade to a router rated 15.4 may be delayed in installation because the IT Department may need to work on manually updating 50+ routers for a 13.0 rated security vulnerability and the upgrades cannot be performed simultaneously.

In practice servers and endpoints will be patched monthly, with expedited patching for critical vulnerabilities, especially where there is a publicly disclosed method of attack. Security updates for all systems must be installed and systems rebooted (if needed) within the required timeframes.

[The exact rating system and urgency will be up to the organization. The schedule based upon priority should ensure prompt action on the most critical patches and updates on the most critical resources. The 90 day maximum for applying upgrades and patches should prevent any system or software from being overlooked or ignored entirely or for updates to pile up.]

E. Patching Guidelines

Once a patch has been obtained and prioritized, the following steps should be followed.

i. Patch Testing

For high value resources, the IT Department may decide to test the patch in a test environment to check for possible business disruption or other issues. Patches that fail the testing process may be excluded from the patching process so long as the IT Department follows the Exception and Mitigation process (See Paragraph 3.F, below).

[Third-party vendors and patch management services or tools will test patches in generic environments. However, unintended consequences may be experienced for specific IT architectures or dependent systems.

Testing patches in a test environment allows the IT Department to discover those issues in an environment that will not affect business processes. Not all organizations have the resources to perform patch testing and patch testing for low value resources may not be a cost-effective use of time or resources.]

ii. Patches Management Preparation

Not all patches will be applied successfully or without issue. In some cases a patch may render a device unusable or cause cascading problems to other IT systems or software. To prepare for this possibility, the IT Department must ensure that [the Disaster Recovery Policy has been executed prior to the Patch Management process.

At the very least]:

• A full system backup has been performed prior to the application of the update
• A full data backup has been performed prior to the application of the update

For firmware updates to critical systems (routers, servers, etc.), a backup system may be required to be in place should the firmware update render the original device non-functional.

For unsuccessful updates, the IT Department will attempt to roll back the system or software to a previous version to recover functionality. Systems that cannot be rolled back will need to be restored from backup or replaced promptly.

The IT department may attempt multiple times to apply patches and updates. For patches or updates that cannot be successfully applied, the IT Department must follow the Exception and Mitigation process below.

[This section acknowledges that not all patches work as intended and the IT Department must prepare for that possibility before applying patches of any kind. We recommend referring to an established Disaster Recovery Policy that should cover backups and recovery systems in detail, but organizations without such a policy can delete that text and simply require backups to be performed.]

iii. Automated Patch and Update Management

Many vendors enable automated patching procedures for their individual applications. Additionally, there are a number of third-party tools and service providers to assist in the patch management process.

Where practical and possible, the IT Department should use appropriate options to automate the patch management process. Automated services can relieve the potential burden from the IT Department and enable prompt application of patches throughout the IT environment without delay.

The IT Department must ensure that all patch management preparation (See Section 3.E.ii above) has been completed successfully prior to allowing any automated processes to proceed.

It is acknowledged that firmware, IT appliances (routers, etc.), and software vendors may require manual patching and updating. Vendors and tools used for automated patching should explicitly list what they do and do not cover for patching and updating and the asset list should reflect which items require manual updates.

iv. Manual Patch Management

Some patches and updates (especially firmware) will require a manual process. For updates that do not disrupt business processes the IT Department may apply the patch at their discretion within the allocated time given the urgency of the patch and update.

Some patches may require the shutdown of critical business systems. To avoid excessive disruption, these Maintenance Windows need to be scheduled and approved in advance by the Patch Management Authority, preferable with the consent of the appropriate business managers affected by the disruption.

To obtain approval, the IT Department must [issue a ticket / fill out a form / send an email] issued to the Patch Management Authority with the following information in a Maintenance Window request:

• Details regarding affected systems
• Details regarding the urgency of the patch and risk 
• Preferred maintenance window and at least one alternative window
• Details regarding rollback procedures should the patch fail

For emergency patches required in the absence of the Patch Management Authority, the next available executive in the organization chart can approve the maintenance window.

Should an emergency patch need to be applied and no executive can or is willing to authorize the patch in a reasonable timeframe given the urgency of the patch, the IT Department may document their efforts to obtain approval and apply the patch or update without formal approval. It is acknowledged that emergency patches and maintenance disruptions may occasionally be required, but the IT Department should always minimize disruption.

[This formally written part of the patching process requires those responsible for implementing the patch to request a maintenance window for when the software update will cause downtime for users or systems in active use.]

v. Patch Verification and Testing

Once the patching and updating process completes, the IT Department should check that the patches applied successfully or report and fix unsuccessful patches. The IT Department should also verify that vulnerabilities addressed by the patch have indeed been mitigated or eliminated by the patch.

Vulnerabilities that remain exposed must be addressed as required under Exceptions and Mitigations (Paragraph 3.F, below).

F. Exceptions & Mitigations

Exceptions can occur in the patching and updating process. These exceptions will be categorized as:

1. Failed Patches: Patches and updates that fail to install correctly
2. Disruptive Patches: Patches and updates that will cause unacceptable business disruption if installed
3. Unneeded Patches: Non-security patches or updates that enable or fix unneeded or unwanted features
4. Unpatched Vulnerability: Some assets may also have vulnerabilities that remain unpatched by vendors for various reasons (end of life, vendor out of business, etc.)

All categories must be recorded into an exceptions list. Unneeded patches will simply be recorded and checked [quarterly] to ensure they remain unneeded.

Failed, Disruptive, and Unpatched Vulnerabilities will require mitigation. The IT Department will develop and propose appropriate mitigation measures to limit the risk and potential damage of the unpatched vulnerability to the organization. Each mitigation plan must be approved by the Patch Management Authority and include:

• Details regarding affected systems
• Details regarding the urgency of the unpatched vulnerability
• Details regarding the mitigation and how it addresses the unpatched vulnerability 
• Preferred deployment window and at least one alternative window. Note if any business systems will need to be taken down to implement the mitigation.

The mitigation and exception list will be reviewed on a [quarterly] basis to determine:

• If patches have been released so the mitigation may be discontinued
• If assets should be or have been retired or replaced so mitigation may be discontinued
• If any mitigations may be improved in any way

The Patch Management Authority must approve the [quarterly] review of the mitigation and exception list.

[If a patch cannot be applied, a different approach to mitigating the risk must instead be developed and approved in writing. Most organizations can perform a quarterly review as outlined in this document. However smaller organizations may only have resources for twice-annual or annual reviews and larger organizations may be more aggressive and want monthly or weekly reviews.]

G. Patch & Update Reporting

The IT Department will issue [monthly] reports on patching and updating. The monthly reports must include:

• Date of last asset scan and number of assets tracked
• The percent of systems covered by automated patch management
• The percent of systems monitored for patching
• The number of patches vendors issued or the organization acquired in the period
• The number of patches in the period that failed quality checks
• The number of patches that failed to install correctly
• The number of patches that resulted in incident tickets 
• The number of successful patch implementations vs # of unsuccessful patches
• Average time elapsed between patch availability and deployment by CSV rating and by asset risk or value category
• The number of exceptions added to the exception report
• The total number of exceptions on the exception report

[The IT Department must issue reports so that the organization can verify that the patch management procedures are followed properly and that patches and updates are made on a timely basis. Regular reports may eliminate the need for special reports for compliance.

The data in the report should also be used to help improve the patch management process. For example, the number of patches that result in tickets can be used to determine if additional patch testing is needed or if the current testing needs improvement.

More mature organizations may also use regular vulnerability testing and pen testing to verify patches have been properly installed. These testing reports can be added to the regular patch and update reports.]

4. Audit Controls and Management

[eSecurity Planet] executives and auditors may request documented procedures and evidence of the patch management practice on-demand. Examples documented procedures and evidence include:

• Approved Maintenance Window Requests
• Approved Exception Lists
• System updates and patch logs for all major system and utility categories
• Logs should include system ID, date patched, patch status, exception, and reason for exception
• Demonstrated infrastructure supporting enterprise patch management across systems, applications, and devices
• Patch Management Reports

[This section acknowledges occasional needs for executives and auditors to need off-schedule reporting on the Patch Management processes. To verify Patch Management reports, some auditors may also require system logs that confirm successful system or software updates.]

5. Enforcement

Employees found in intentional policy violation may be subject to disciplinary action, up to and including termination  The job performance of IT Department staff responsible for executing this policy will be evaluated based in part or in full on their ability to fulfill the expectations of this policy.

Regular inability of the IT Department to meet the requirements of this Patch Management policy may be considered negligence and result in disciplinary action. Falsified reports or gross negligence in execution may be grounds for immediate termination or disciplinary action.

Devices containing operating systems, software, and firmware that do not comply with patching requirements should be excluded from accessing resources critical in value or function and should be limited to DMZ or segregated network sections.

[For policies to be effective, there should be penalties for non-compliance. Although briefly mentioned here, a Network Security Policy should explicitly determine how and what non-compliant devices may access within the organization.

This document assumes that organizations that fail to meet the update standard due to lack of resources will not hold their IT Department accountable when overworked or overloaded. Organizations that apply unreasonable expectations will likely experience high IT Department turn-over and difficulty in retaining experienced or competent staff.]

6. Distribution

This policy is to be distributed to all [eSecurity Planet] executives and IT Department staff responsible for Patch Management Policy support and management.

[Anyone that will need to work on patch management (IT Department staff) or be affected by the policy (at least executives, but possibly other relevant employees) should receive this policy. Employees responsible for execution may need to formally acknowledge receipt.]

7. Policy Version

Version 1.0

Approval Date: 11/15/2022

Description: Initial Policy Drafted

[This section can also be made into a Policy Version History with a table of previous versions and approvals.]

8. Signatures

Approved By: ____________________________________________

[Patch Management Authority Signature]

Approved By: ____________________________________________

[CEO or other applicable Executive]

[A signature by the Patch Management Authority acknowledges the requirements of the policy and becomes a de facto pledge to meet the requirements. A signature by the CEO or other executive acknowledges that the policy meets the needs of the organization. The executive that signs should be senior enough that their signature will compel other departments to comply with the policy.]

Appendix

I. IT Resource Asset List

[As per the Asset Management Policy,] the asset list of the organization should cover all systems, software, firmware and devices of the organization. The asset list may also include devices outside of the control of the organization, but connected to the network such as BYOD, leased equipment with access, contractor’s equipment, etc.

Examples of resources on the asset list include, but are not limited to:

• Network equipment
  • Firewalls (and installed software, firmware, security features that require updates)
  • Network switches (and installed software, firmware)
  • Routers (and installed software, firmware)
• Servers (websites, application hosts, virtualization platforms, etc.) and installed operating system
• stalled operating system, installed software, firmware)
  • Workstations
  • Tablets
  • Laptops
  • Cellular devices 
• Internet of Things (IoT) and installed software and firmware
  • Voice over Internet Phones (VoIP)
  • Security Cameras
  • Wi-Fi Connected TVs
  • Wi-Fi Printers
  • Network Printers
  • Storage Array Networks (SAN)
  • Voice-activated devices (Amazon Alexa, etc.)
  • [Heart monitors and other medical devices]
  • Solar panel systems
  • Door security badge-readers
• Operational Technology (OT) and Connected Infrastructure and installed software or firmware
  • 5G-connected conveyer belt
  • Connected HVAC equipment

The asset list should include:

• Type of asset (Server, PC, software, router, etc.)
• Device assigned owner (if a shared resource, the head of the associated department is the defacto assigned owner)
• Core OS, Firmware, or Software version
  [Note: tracking and maintaining specific versions can be useful, but burdensome for organizations using a manual tracking system.]  
• Manual or automatic update?  
• Updated by IT Department, automatic software update, third-party tool, or third-party service provider?
• Last updated
• Update successful (Y/N)
• Associated devices (IE. for Adobe Acrobat software: installed on associated device: PC4362)

While the [IT Department] maintains responsibility for maintaining the asset list, department heads must inform the IT department about new assets (devices, installed software, etc.) deployed. Devices or software deployed without informing the IT department will be considered rogue devices and subject to blocking and removal.

The [IT Department] will conduct [continuous/monthly/daily/quarterly] scans of the IT environment to verify that the asset list remains current and to detect rogue devices or software. 

The current asset list is stored:

[List the Asset database, Excel spreadsheet, asset management tool here.
Note: using an excel spreadsheet can be vulnerable to accidental or intentional corruption or changes. A version controlled Google Spreadsheet or an Excel file stored in OneDrive or Sharepoint would be better options.

Organizations should develop and maintain an Asset Management Policy. Development of the policy and an example asset list is beyond the scope of this sample document.

BYOD devices should not be tracked in an asset list. The maintenance of BYOD devices should be enforced using network access control features or tools that check devices for minimally accepted security profiles.]

The post Sample Patch Management Policy Template appeared first on eSecurityPlanet.

United States Attorney Stephanie M. Hinds said in a statement that technology companies that collect and store vast amounts of user data must protect that data and alert customers and authorities if it’s stolen.

“Sullivan affirmatively worked to hide the data breach from the Federal Trade Commission and took steps to prevent the hackers from being caught,” Hinds said. “We will not tolerate concealment of important information from the public by corporate executives more interested in protecting their reputation and that of their employers than in protecting users.”

FBI Special Agent in Charge Robert K. Tripp added, “The message in today’s guilty verdict is clear: companies storing their customers’ data have a responsibility to protect that data and do the right thing when breaches occur.”

Also read: New SEC Cybersecurity Rules Could Affect Private Companies Too

Ransom Payments and Cover Up

Sullivan was hired as Uber’s chief security officer in April 2015, soon after the company disclosed to the FTC that it had been hacked the previous year. The following month, the FTC served Uber with a Civil Investigative Demand, requiring extensive information about any other unauthorized data access, as well as information on Uber’s data security program and practices.

Sullivan played a central role in Uber’s response, testifying under oath in November 2016.

However, soon after testifying, Sullivan learned that Uber had been breached again, exposing 57 million users’ information, including 600,000 driver’s license numbers. The hackers in this case demanded a ransom.

Sullivan didn’t handle the news well, but he should have known better: he’s a former Assistant U.S. Attorney and was a founding member of the Computer Hacking and Intellectual Property unit of the U.S. Attorney’s Office for the Northern District of California.

Rather than notifying the FTC, Sullivan told a subordinate not to “let this get out,” that information about the breach needed to be “tightly controlled,” and that to anyone outside Uber’s security group, “this investigation does not exist.” He continued to conceal the breach both from the FTC and from Uber’s own lawyers as Uber paid the hackers $100,000 in Bitcoin in exchange for NDAs promising not to reveal the breach.

When Dara Khosrowshahi took over as Uber’s new CEO in August 2017, the U.S. government statement said Sullivan continued to lie to Khosrowshahi and to the company’s lawyers about the specifics of the hack. It wasn’t until November 2017 that Uber’s new leadership determined the facts and finally disclosed the breach publicly.

Sullivan, who is currently free on bond, faces up to eight years in prison. His sentencing date hasn’t yet been set.

See the Top Governance, Risk & Compliance (GRC) tools

What CSOs Should Do

ImmuniWeb founder Ilia Kolochenko said the case is part of a broader global trend of holding cybersecurity executives accountable for breaches at their companies. “In the future, we will likely see more CISOs, DPOs and board members civilly liable or even face criminal prosecution for security or privacy incidents,” he said. “Many countries have already implemented – by the virtue of statutory or case law – personal accountability of executives for data breaches.”

In response, Kolochenko said, there are several steps executives need to take. “Cybersecurity executives should urgently ascertain that their employment contracts address such vital issues as coverage of legal fees in case of a civil lawsuit or prosecution in relation to their professional responsibilities, as well as a guarantee that their employer will not sue them – as victimized companies may also sue their own executives in case of security incidents,” he said.

“Finally, cybersecurity executives should be always prepared to demonstrate a systemized, continually improved and comprehensive data protection and privacy strategy, as well as solid evidence of regular and coherent implementation thereof,” he added.Such requirements are also at the heart of data privacy laws like GDPR, making them a compliance need too (see Security Compliance & Data Privacy Regulations).

The post Uber Guilty Verdict Raises Security Stakes for CSOs appeared first on eSecurityPlanet.