Best Practices for Vulnerability Scanning

Vulnerability management should be a priority in any organization’s information security program so that there’s an established approach for identifying and rating issues affecting in-scope systems in a given environment. Vulnerability scans are a main component of vulnerability management, allowing you to evaluate your systems, software, and infrastructure for unpatched holes and gaps in need of remediation. Let’s talk through some best practices for vulnerability scanning to help you protect your assets.

How Often Should You Perform Vulnerability Scanning?

The frequency of vulnerability scanning depends on a few factors: organizational changes, compliance standards, and security program goals. If your organization is looking to maintain a high level of security, vulnerability scanning needs to be added to your information security program. Vulnerability scans should be conducted after any major system, organization, or infrastructure change to ensure you’re aware of any security gaps. And, of course, to comply with various regulations, annual, quarterly, or monthly vulnerability scanning may be required as part of your  information security program.

Overall, an industry best practice is to perform vulnerability scanning at least once per quarter. Quarterly vulnerability scans tend to catch any major security holes that need to be assessed, but depending on your unique organizational needs, you may end up performing scans monthly or even weekly. The best way to assess vulnerability scanning frequency is to thoroughly understand your own security structure and the threats you face.

Framework Requirements for Vulnerability Scanning

On your compliance journey, you’ll realize many compliance standards include requirements for regular vulnerability scanning. Some standards require a higher frequency of vulnerability scanning than others, yet most include vulnerability management to some degree. You can expect to see requirements for vulnerability scanning from these industry compliance and regulatory standards:

  • ISO 27001: Requires quarterly external and internal vulnerability scans
  • HIPAA: Requires a thorough risk assessment and vulnerability process, which can be identified with vulnerability scanning
  • PCI DSS: Requires quarterly external and internal scans conducted by an ASV (Approved Scanning Vendor)
  • FISMA: Requires documentation and implementation of a vulnerability program to protect the availability, confidentiality, and integrity of IT systems
  • NIST: Requires either quarterly or monthly vulnerability scans depending on the particular NIST framework (8001-171, 800-53, etc.)

How to Perform Vulnerability Scanning

Vulnerability scans are often confused with penetration tests, however they serve different purposes in your information security program. Vulnerability scanning is an automated process designed to highlight issues on a wide range of systems at regular intervals. With vulnerability scans, you can discover issues such as missing patches and vulnerable software packages. Penetration testing, however, is performed in both manual and automated forms with a more targeted goal in mind. Understanding the difference and value of these two tools is important so that you can conduct vulnerability scanning with the right expectations.

Vulnerability scanning is conducted with a variety of tools, such as the tools found in OWASP’s list, that can scan systems for various security vulnerabilities. When you hire someone to conduct your vulnerability scans, you’re hiring someone to use a tool on your system. Sometimes, other auditing firms will charge high fees for “manual vulnerability management,” when in reality, they’re using an automated tool to scan your environment. Don’t be fooled into overpriced services that complete the same scan as any helpful vulnerability scanning tool does.

At KirkpatrickPrice, we pride ourselves on honesty and integrity. When you look to us to perform vulnerability scanning services, you’ll know our processes and tools upfront. You can expect a thorough scan of your networks, system, and equipment to detect and classify any vulnerabilities. Interested in learning more about our vulnerability scanning services? Contact us, today.

More Vulnerability Management Resources

Auditor Insights: Vulnerability Assessments vs Penetration Testing

PCI Requirement 11.2.2 – Perform Quarterly External Vulnerability Scans via an Appropriate Scanning Vendor

10 Ways to Conduct Patch Management

ISO 27001 Certification vs. ISO 27001 Audit: What’s the Difference?

Do you want to demonstrate your commitment to security to global business partners? An ISO 27001 report provides organizations with an evolving ISMS that can adapt to new challenges and validates your commitment to security. It can also help you prioritize your information security budget and resources based on risk, because ISO 27001 is customized for your environment and your specific risks. Undergoing an ISO 27001 audit is also a way to be proactive in your information security and compliance efforts, which could be just what you need to stay ahead in your industry. So, what does the ISO 27001 certification process look like and who can perform an ISO 27001 audit? What’s the difference between ISO 27001 certification and an ISO 27001 audit?

The ISO 27001 Certification Process

In order for your organization to become ISO 27001 certified, there are a few steps you’ll have to take. To get the ISO 27001 certification process started, we suggest undergoing a gap analysis to identify any potential vulnerabilities. From there, you’ll remediate the findings and then begin the audit, which is comprised of two stages.

Stage 1 Audit

During your Stage 1 audit, or the “Documentation Review” audit, an external auditor will review your organization’s prepared ISMS documentation to ensure that is compliant with the ISO 27001 requirements.

Stage 2 Audit

Once you’ve completed the Stage 1 audit, your external auditor will evaluate the fairness and suitability of your information security management, controls, and practices. If your external auditor deems your organization’s ISMS compliant with the ISO 27001 requirements, they will recommend you for certification. ISO 27001 certification is a separate process involved a certifying body.

Value of an ISO 27001 Audit Without Certification

Did you know that many organizations opt to undergo the ISO 27001 audit and not pursue certification? It’s true. You might now be wondering, “Why would you pursue an audit and not want to get the certification?” The bottom line is because certification is not required. Instead, if you decide to pursue an ISO 27001 audit without certification, you will still receive an ISO 27001 report to offer clients and stakeholders who need assurance of your ISMS’ effectiveness, and you only need to work with one firm for your ISO 27001 needs.

Who Can Perform ISO 27001 Audits?

While both internal and external auditors can use the ISO 27001 framework to perform the Stage 1 audit and assess an organization’s ability to meet their information security requirements, using an external auditor is always wise. Here’s why.

When you pursue an ISO 27001 certification, best practice is to hire one firm to perform the audit and a separate firm for the certification process. This process may seem tedious, but it instills independence so that conflict of interest is never a concern.

KirkpatrickPrice only offers ISO 27001 audits and consulting. Our firm is not a certifying body, so any quotes on our ISO 27001 services will never include certification. If you are considering working with a firm that offers both auditing and certification services or has a partnership with another organization in order to offer both, this is a red flag. It indicates a lack of integrity and a conflict of interest, which could have negative implications on your audit and certification.

Have questions getting started on your ISO 27001 audit journey? Contact us today, and we’ll get you started.

More ISO 27001 Resources

ISO 27001 FAQs: Information Security Management for Your Organization

Choosing Between SOC 2 and ISO 27001 Audits

Was the Gap Worth It?

3 FISMA Compliance Levels: Low, Moderate, High

What is FISMA?

The Federal Information Security Management Act (FISMA) is a piece of United States legislation, enacted as part of the Electronic Government Act of 2002. FISMA’s intent is to protect government information and assets from unauthorized access, use, disclosure, disruption, modification, or destruction of information and information systems. FISMA is the law; NIST Special Publication 800-53, Security Controls for Federal Information Systems and Organizations, is the standard that contains the individual security controls required to comply with FISMA.

In addition to this, NIST developed FIPS Publication 199, which explains the standards for categorizing information and information systems to comply with FISMA. According to FIPS 199, information and information systems are defined by three security objectives: confidentiality, integrity, and availability. Should there be a loss of confidentiality, integrity, and availability, organizations must determine the potential impact according to the three FISMA compliance levels: low impact, moderate impact, and high impact.

3 FISMA Compliance Levels

To decide which of the three FISMA compliance levels applies to your organization, you’ll need to determine whether the potential impact to your organization would be limited, serious, or severe. NIST defines the three levels FISMA compliance levels as low impact, moderate impact, and high impact.

Low Impact

Low impact indicates that the loss of confidentiality, integrity, or availability is expected to have a limited adverse effect on organizational operations, organizational assets, or individuals. Examples of low impact incidents include:

  • A breach that causes a degradation in mission capability to an extent and duration that the organization is able to perform its primary functions, but the effectiveness of the functions is noticeably reduced
  • A breach that results in minor damage to organizational assets
  • A breach that results in minor financial loss
  • A breach that results in minor harm to individuals

Moderate Impact

Moderate impact indicates that the loss of confidentiality, integrity, or availability is expected to have a serious adverse effect on organizational operations, organizational assets, or individuals. Examples of incidents with moderate impact include:

  • A breach that causes a significant degradation in mission capability to an extent and duration that the organization is able to perform its primary functions, but the effectiveness of the functions is significantly reduced
  • A breach that results in significant damage to organizational assets
  • A breach that results in significant financial loss
  • A breach that results in significant harm to individuals

High Impact

High impact indicates the loss of confidentiality, integrity, or availability is expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals. Examples include:

  • A breach that causes a severe degradation in mission capability to an extent and duration that the organization is not able to perform one or more of its primary functions
  • A breach that results in major damage to organizational assets
  • A breach that results in major financial loss
  • A breach that results in severe or catastrophic harm to individuals, involving loss of life or serious life-threatening injuries

Achieving FISMA Compliance

Determining which of the three FISMA compliance levels applies to your organization is the first step on your FISMA compliance journey. Once you determine your impact level as either low, moderate, or high, you can move on to deriving the information system impacted level in accordance with FIPS 200, and then finally, apply the appropriately tailored set of baseline security controls in NIST SP 800-53. This allows organizations to tailor the relevant security control baseline so that it more closely aligns with their mission and business requirements and environments of operation. Certification is achieved when an Authorization to Operate (ATO) is signed by a federal agency’s senior management official.

At KirkpatrickPrice, our senior-level experts can walk you through your FISMA compliance journey. If you’re eager to get started on your FISMA audit or if it’s just something on your radar, let KirkpatrickPrice help you get started. Contact us today.

More FISMA Resources

What Type of Compliance is Right for You? 10 Common Information Security Frameworks

Security Awareness Training Requirements: SOC 2, PCI, FISMA, and More

Compliance with PCI Requirements 9 and 12

The PCI DSS was developed by payment card brands to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. The PCI DSS consists of nearly 400 individual controls and is a critical part of staying in business for any merchant, service provider, or subservice provider who is involved in handling cardholder data. A PCI audit must be conducted by a QSA. As for the PCI audit itself, the number of requirements organizations have to comply with varies. In some cases, entities must meet all 12 PCI requirements, but the scope may determine that others only need to meet PCI Requirements 9 and 12. Why is that? It has to do with the physical security of cardholder data.

Who Must Be PCI Compliant?

According to the PCI SSC, “Any merchant that wants to process, store, or transmit credit card data is required to be PCI compliant.” However, for some organizations that only impact the physical security of cardholder data, like data centers or records management providers, only have to demonstrate compliance with PCI Requirements 9 and 12.

What is PCI Requirement 9?

PCI Requirement 9 states entities must restrict physical access to cardholder data. Complying with PCI Requirement 9 is critical to the physical security of your organization’s sensitive cardholder data. What would the consequences be if your organization had no physical access controls? No locks on the doors, no badge or identification system, no security guards, no receptionist? Without physical access controls, you give unauthorized persons a plethora of ways to potentially gain access to your facility and to steal, disable, disrupt, or destroy your critical systems and cardholder data.

What is PCI Requirement 12?

PCI Requirement 12 says that entities must maintain a policy that addresses information security for all personnel. Essentially, this requirement is centered around the management of your information security program, which stems from a strong information security policy that sets the tone and expectations for your employees.

Proper Scope Your PCI Audit

PCI defines scoping the identification of people, processes, and technologies that interact with or could otherwise impact the security of cardholder data. Knowing how to scope a PCI assessment is crucial to your organization’s compliance. Defining a correct scope is the first and most important step. Scoping is so vital that assessors should not even begin the assessment until they have fully determined the scope. So, how does your organization determine if an asset is in scope? Any people, process, or technology that stores, processes, or transmits cardholder data is considered to be within your cardholder data environment and in scope for your PCI assessment. If your people, processes, or technology has the ability to impact the security of account data and sensitive authentication data, then your organization needs to have the appropriate controls applied in the appropriate places.

Determining which requirements you need to include in your PCI audit can be confusing, but at KirkpatrickPrice, our Information Security Auditors thoroughly scope the project, allowing for the tedious process to become streamlined.

When you engage in a PCI audit with us, we’ll ask questions like…

  • Will more than one business entity be involved in the audit?
  • Which of your business services are included in the audit?
  • How many business applications are used to fulfill these services?
  • How many technology platforms support the business?
  • What third-party service providers have access to your confidential information?

Who Should Comply with PCI Requirements 9 and 12?

Companies who only handle credit card information in a physical way means that they only need to be evaluated on that level, which would be physical security (PCI Requirement 9) and information security policies (PCI Requirement 12). In situations like this, all other requirements would be outsourced.

Whether you’re expected to comply with all 12 requirements or you’re only pursuing a PCI Requirements 9 and 12 audit because you’re focused on physical security, KirkpatrickPrice is here to make the PCI audit journey easier. Let’s find some time to talk today to see how we can partner together to get your compliance goals achieved.

More PCI DSS Resources

Most Common PCI Gaps

4 Reasons to Start a PCI Audit Right Now

How Do I Find a QSA For My PCI Audit?

What are the 4 Levels of PCI Compliance?

Does your business collect, use, store, process, or transmit payment cardholder information? If so, it’s likely that you’ve heard of the Payment Card Industry Data Security Standard, or PCI DSS. If you haven’t, the PCI DSS is a standard created by major credit card companies, such as Visa, Mastercard, Discovery, American Express, and JCB to establish specific requirements that merchants and service providers must adhere to in order to protect payment cardholder data.

This is a robust standard and ensuring PCI compliance is no small task, especially because the framework applies to companies that vary vastly in size and processing capabilities. This is why, when first establishing strategies for implementing and maintaining PCI compliance, your organization needs to understand the in’s and out’s of the framework, including what constitutes a merchant, the four levels of PCI compliance, and how the four PCI levels impact compliance. Let’s take a look.

What is a Merchant?

The Payment Card Industry Security Standard Council (PCI SSC) defines a merchant as, “A merchant is defined as any entity that accepts payment cards bearing the logos of any of the five members of PCI SSC (American Express, Discover, JCB, MasterCard or Visa) as payment for goods and/or services.” Does your business fall under this definition? If so, PCI compliance is required and you must determine your PCI compliance level.

The 4 Levels of PCI Compliance

Because not every businesses processes the same amount of card payments per year and each has a different level of risk for data breaches and security incidents, the PCI SSC created four PCI compliance levels that are determined by the merchant type.

  • PCI Merchant Level 1: Merchants with over 6 million transactions a year, across all channels, or any merchant that has had a data breach
  • PCI Merchant Level 2: Merchants with between 1 million and 6 million transactions annually, across all channels
  • PCI Merchant Level 3: Merchants with between 20,000 and 1 million online transactions annually
  • PCI Merchant Level 4: Merchants with fewer than 20,000 online transactions a year or any merchant processing up to 1 million regular transactions per year

How do the 4 Levels Impact Compliance?

Depending on which of the four levels of PCI compliance your organization falls under, your compliance journey can vary. Take the following scenarios, for example.

  • If your organization is considered a PCI Merchant Level 1, you’ll be required to undergo annual, third-party audits to verify compliance and go through an annual network scan by an approved scanning vendor (ASV). PCI Merchant Level 1 organizations must receive an annual Attestation of Compliance (AoC) as well as a Report on Compliance (RoC).
  • If your organization is considered to be a PCI Merchant Level 2, 3, or 4, you’ll need to conduct the PCI DSS Self-Assessment Questionnaire (SAQ), as well as go through quarterly network scans with an ASV.
  • If your organization is deemed a PCI Merchant Level 3 but falls victim to a data breach that impacts cardholder information, Visa can opt to penalize you by making you also responsible for meeting the requirements of another level, such as PCI Merchant Level 1.

Meeting PCI Compliance

No matter which of the 4 levels of PCI compliance your business falls into or what type of merchant you are, maintaining PCI compliance needs to be a top priority. This is why KirkpatrickPrice developed a streamlined audit process that partners you with senior-level, expert Information Security Auditors who are QSAs that can guide you during your PCI compliance journey. Whether you are completing the full audit, have questions about figuring out how to fill out your SAQ, or if you’re looking for an expert penetration tester to perform your required quarterly scanning, we can help. Let’s talk today about your PCI compliance goals and how we can partner together to achieve them.

More PCI  Compliance Resources

PCI Demystified

Beginner’s Guide to PCI Compliance

Overdue on New PCI Penetration Testing Requirements? What You Need to Know About PCI Requirement 11.3.4.1