20 Ways MSPs Can Be Security Heroes

The role of an MSP is an important one. MSPs want to help their clients create and maintain a strong security posture – that’s why, as an MSP, your clients come to you with information security problems that need to be fixed, ranging from disaster recovery to risk assessment services. Who finds those problems? Auditors and pen testers. Who determines if those problems are risky gaps in the client’s security posture? Auditors and penetration testers. When your clients go through information security audits for the first time, they should also go through a gap analysis – a process that identifies any operational, reporting, and compliance gaps. Once an organization knows their gaps, they can begin the remediation process. That’s where you come in.

As an MSP, when you’re able to interpret gap analysis results, you can typically find more opportunities to grow your business with that client. How? By fixing the issues found during the gap analysis. Your clients walk away from audits and pen tests with information security problems that need to be fixed. Additionally, by encouraging your clients to undergo security testing and having a recommended vendor, you are seen as their trusted information security advisor. If you can speak from experience and have gone through an information security audit before, that’s even more valuable for your clients. They can trust your experience and be assured that you won’t bring more risk into their environment.

Clients trust you to cover their IT and information security needs – are you not serving them well by not being able to understand a gap analysis report or remediation plan? KirkpatrickPrice is here to educate and empower you to better serve your clients. Let’s take a look at 20 gaps that could be mitigated by the average MSP. Have more questions after reading? Contact us today and we’ll connect you with an expert on MSP services and partnerships.

Guide to 7 Types of Penetration Tests

Does Your Organization Need Penetration Testing?

Why does your technology and environment need penetration testing? Because every business has something to lose – and data is one of the most valuable assets that a hacker can gain. Whether through an application, device, or network, the data you are responsible for is at risk when you don’t verify the security measures protecting it. Whose job is on the line if your clients’ data (or your organization’s other assets) are compromised?

7 Types of Penetration Tests

Investing in penetration testing is one way to show clients, prospects, and competitors that you are willing to take every step necessary to safeguard the data that has been entrusted to you. In this guide, we’ll discuss seven types of penetration testing that can be done on different types of technology to discover which type could be implemented into your information security program, including…

  • Network Penetration Testing
  • Web Application Penetration Testing
  • Mobile Application Penetration Testing
  • Wireless Penetration Testing
  • API Penetration Testing
  • IoT Penetration Testing
  • Continuous Penetration Testing

This white paper also discusses the different stages of penetration testing used at KirkpatrickPrice, and how you can partner with KirkpatrickPrice to ensure the security of your organization.

Want the full guide?

Guide to PCI Policy Requirements

Introduction to the 12 PCI Requirements

The purpose of the PCI DSS is to ensure that all of that data that lives within the cardholder data environment (CDE) is protected and secured from theft or unauthorized use. If you are a merchant, service provider, or subservice provider who stores, processes, or transmits cardholder data, you are subject to comply with the PCI DSS but doing so may seem daunting. Why? Because the PCI DSS has almost 400 controls, 6 control objectives, and 12 major subject areas, and many organizations struggle with the documentation aspect of a PCI assessment. However, established best practice states, “If it’s not written down, it’s not happening.” Organizations need documented policies, procedures, and standards to control risks to business assets, but to also have a common understanding and language that creates consistency amongst your organization.

What Should a PCI Policy Include?

Depending on your unique services, industry, legal requirements, or other frameworks outside PCI that you must comply with, there will be various topics that your information security policies should cover. The PCI DSS does a good job, though, of outlining which policies you absolutely need to begin a baseline set of PCI-compliant policies. Some suggested topics that a PCI policy might include are…

  • Firewall Configuration Standards and Operational Procedures
  • Operational Procedures for Managing Firewalls
  • Operational Procedures for Managing Vendor Defaults and Other Security Parameters
  • Data Retention and Disposal Policies
  • CHD Storage and Protection Policies
  • Encryption Key Management Policies and Operational Procedures
  • Operational Procedures for Encrypting Transmissions of CHD
  • Anti-Virus and Malware Software Policies
  • Security Patch Installation Policies

You can a get full list of suggested topics by downloading this white paper, but please note that this list serves as an overview of what policies and procedures should be documented and implemented when pursing PCI compliance, and it is not an all-encompassing list. For more information on the specific details of what needs to be included in each policy or procedure, we encourage you to review the current PCI DSS or contact your QSA.

Want to get the full guide to PCI Policy Requirements?

Quickstart to Information Security Policies for Startups

Why Startups Need to Make Information Security Policies a Priority

No matter what industry they’re in, startups are especially susceptible to cybersecurity attacks. This is largely due to financial reasons, as startups are far less likely to have the capital needed to implement robust information security management programs. Moreover, often times, startups neglect to place an emphasis on information security from the start because of a lack of understanding of the threats their industry is faced with. But here’s what all startups must realize: robust documentation of information security policies, standards, and procedures is one of the hallmarks of an effective information security management program – and it doesn’t have to be a daunting task to create them. With the right partner, you can create and implement a robust information security policy for your organization and help ensure the security and success of your startup. So, what should an information security policy for a startup include?

Information Security Policy Checklist for Startups

Depending on the industry your startup is in and the legal requirements and/or frameworks that you must comply with, there will be various topics that your information security policies should cover. Considering this, we’ve come up with a checklist of 15 recommended topics that information security policies should include. Please note that this checklist serves as a baseline overview of what policies should be included by a new information security program, and if your organization has to meet other compliance standards, such as SOC 2 or HIPAA, there will be additional requirements or topics that need to be included. A few such topics you might include in your information security policy are…

  • Risk Assessment Standards and Procedures: How often do you perform a risk assessment? Who is responsible for performing a risk assessment? Who communicates the findings of a risk assessment? What is done with the risk assessment findings?
  • Acceptable Use Policy: What constitutes acceptable use within your organization? Does this apply to both company-owned devices and/or bring-your-own-device policies? How do you monitor your acceptable use policy?
  • Monitoring and Logging Policies, Standards, and Procedures: What procedures are in place for monitoring and logging? Who is responsible for keeping logs up to date? Who is responsible for communicating anomalies found in logs?
  • Incident Response Procedures: What procedures are in place in the event of a natural or man-made disaster? What personnel are responsible for implementing your Incident Response Plan? Is your Incident Response team trained regularly with real-life simulated events? How is your Incident Response Plan updated to ensure that it is current based on your risks and needs?
  • Personnel Security Policies, Procedures, and Standards: What procedures are used to hire, train, and retain employees? How are employees trained on company policies and procedures? Do employees undergo security awareness training on a regular basis? If so, how frequently?

Want the full checklist?

7 Deadly Sins of a HITRUST CSF Assessment

 7 Deadly Sins of HITRUST

At KirkpatrickPrice, we’ve worked with clients of all sizes – from startups to enterprise-level organizations. By working with so many organizations of varying sizes and industries, we’ve been able to identify seven primary pitfalls that make for a challenging audit environment, all of which represent initial difficulties that often lead to a failed or very drawn out HITRUST validated assessment attempts. In recognizing how significant these pitfalls are, our firm has designed our engagements to address these early and often over the course of the assessment, raising red flags whenever one is discovered. The following seven deadly sins of HITRUST, while in no particular order, are all of primary significance to the audit as a whole and occur with roughly the same frequency. To begin, let’s look at one of the biggest misconceptions about HITRUST.

Does HITRUST Certification Represent Equivalent Work Effort to Other Framework?

While HITRUST encompasses many of the key components of these frameworks, each assessment has its own approach and purpose. ISO tests best practices. FISMA tests against standards. SOC 2 tests against risk thresholds and company procedures. Every single engagement has its own caveats and assessor instructions. After all, if they were all the same, we’d all do the same assessment, right? Since they are not the same assessment, we assess against standards that target what we need to express to our clients and represent within the competitive scope of our business.

At is core, HITRUST is a risk-based, prescriptive audit that is designed to test systems’ infrastructure against an external risk threshold and company maturity. Nothing else is quite like it, from what the assessed organization is expected to do, to the role of the assessor, to the role of HITRUST as a certifying body. Especially in an organization’s first year, HITRUST should be approached from a position of education and understanding: no matter what you know, you likely don’t quite know all of the things you need to know to be successful within the HITRUST framework.

Ultimately, while HITRUSST can be used to assess compliance with other frameworks, the converse is not true.

Want the full list of HITRUST misconceptions?