CAll Us: +1 888-999-8231 Submit Ticket
How the Success of WordPress is Due to its Plugin Ecosystem

How the Success of WordPress is Due to its Plugin Ecosystem



WordPress’s plugin ecosystem is one of its greatest strengths. As we write, there are over 50,000 plugins in the official repository, a number that doesn’t include premium plugins and custom plugins created for individual WordPress sites. Plugins range in functionality from tiny interface tweaks to full-featured ecommerce applications, all taking advantage of the hooks and frameworks built into WordPress by its developers.
About a third of the web runs on WordPress — tens of millions of sites — so we’re used to statistics about WordPress involving big numbers. However, it’s worth taking a moment to think about what a staggering achievement the WordPress plugin ecosystem is and how many thousands of hours of developer time have been dedicated to creating plugins, the vast majority of which are free and open source.
When Matt Mullenweg started work on WordPress in 2003, it was by no means a certainty that there would be a plugin ecosystem. Many early blogging engines were not designed with a modular architecture. Towards the end of 2003, Ryan Boren joined the nascent WordPress project and his work led to the creation of the plugin system we know today.
Mullenweg created Blogtimes, one of the first useful plugins which is still in the plugin repository, although it was last updated 14 years ago. He also created Hello Dolly, which was bundled with WordPress installations to demonstrate how to build plugins.

What Makes Plugins So Powerful?

Plugins are powerful because they allow anyone to create a feature for WordPress without it having to be included in every WordPress site. WordPress’s history would be very different if every possible feature had to be included in WordPress Core. It would be bloated beyond recognition if even a tiny fraction of the features available as plugins were installed as part of the application, not least because it would lead to a horrendously complex interface.
Plugins serve a purpose beyond allowing WordPress to maintain a slimline application and a manageable user experience. The WordPress 5.0 release lists 12 lead developers and 423 contributors. That’s a lot for an open source project, and it’s challenging to organize so many people, especially when most contribute for free. However, a conservative estimate for the number of people working on plugins is hundreds of times the number working on WordPress itself.
For all practical purposes, it’s impossible to organize that many people to work on a monolithic application while hitting deadlines, maintaining security, and adhering to quality standards. Plugins can be developed independently of the core application, by organizations and individuals that manage themselves, that aren’t tied to the needs and release schedules of the main application, and that can create features that are useful to thousands but that aren’t a good use of the core developer’s time.
Without the plugin system, WordPress as we know it wouldn’t exist. It may not have existed at all in 2019, perhaps being remembered only by historians of content management systems. How many WordPress users are familiar with b2/cafelog, the CMS that WordPress replaced?
Thanks to its modularity and the dedication of thousands of developers, WordPress went from strength to strength and is today one of the most important pieces of software in the world.

Source link

What Is a PCI DSS Audit?

What Is a PCI DSS Audit?

Officially known as an annual PCI DSS assessment, this annual audit is required for Level 1 merchants and recently breached merchants to maintain PCI compliance. These assessments can only be performed by a qualified security assessor (QSA). Read on to learn what you, the merchant, should expect from the audit and how to prepare for it.

Top Reasons to Become PCI DSS Compliant

PCI DSS refers to Payment Card Industry Data Security Standards, and it is required for any store that accepts credit cards as payment. This applies both to stores that process credit cards, and stores that limit themselves to transmitting card data to third party payment gateways like PayPal and others. 

The case for “why PCI compliance” is two-fold:

  1. The five major credit card companies on the PCI Council (Visa, MasterCard, American Express, Discover, JCB) say it is.
  2. PCI-compliant merchants are more effective at protecting their customers’ data than merchants that are non-compliant. 

Or, as a third argument for the merchants unmoved by the first two: PCI DSS helps prevent breaches, and breaches cause downtime and lost revenue. 

For a more detailed breakdown of PCI compliance, see How Hostdedi Helps Your Store Stay PCI Compliant.

PCI DSS Risks

Only 29 percent of companies remain compliant a year after their initial validation because they pass once, then drift into complacency. pci storefront

Auditing is a required component of compliance for larger merchants, and it may be tempting to wonder about the consequences for non-compliance. Some might resent what they perceive as the credit card’s stranglehold on ecommerce. Others might just “have better things to do with my time, like run my business.” 

What’s the worst that could happen?

The short answer is non-compliant merchants can be fined, audited, breached, and suffer damage to their brand reputation. The longer answer is that PCI compliance is the beginning of security, not the end. It’s best to consider it as the “minimum acceptable standard” for securing your customers’ data.

How Much Does a PCI Audit Cost?

On average, a typical PCI audit for a smaller merchant costs about $15,000. This adds to other factors influencing PCI DSS certification cost, which usually relate to infrastructure and paying qualified personnel to apply and maintain best practices of data security. While this is not insignificant, the cost of ignoring compliance is far greater.

Beyond ethical concerns, failure to comply can result in:nexcess pci lock

  • Fines by credit card companies ranging between $5000—$100,000
  • Security breaches, which often involve downtime to resolve
  • Legal action by endangered customers and third parties
  • Damaged reputation and loss of consumer trust
  • Loss of revenue
  • Federal audits

How Does a PCI DSS Audit Work?

If you’re facing an upcoming audit, then you’re either a level 1 merchant with more than 6 million credit card transactions per year, or a merchant from lower PCI compliance levels (2–4) that suffered a recent data breach. Merchants on the lower PCI compliance levels (2The central goal of the audit find non-compliance, provide guidance on how to fix it, and verify you’ve addressed any and all issues. 

The first step is finding a Qualified Security Assessor (QSA) to perform the audit. Only QSAs are licensed to perform the audits, as these organizations are certified by the PCI council to understand their data security standards. 

The simplest way to find a QSA is by choosing one from the list on the PCI website. As with any service, it is usually wise to talk to a few, as not all are created equal. Never hire a company claiming to be a QSA if not present on the PCI list; these companies are either outsourcing your request, or planning to sell you other services. 

Once onsite, the auditor will assess multiple areas of your business. As you might expect, this includes your cardholder data environment (CDE), defined as any device, component, network, or application that stores, processes, or transmits cardholder data. It also includes your policies and procedures surrounding your use of these systems.

PCI Audit Requirements

  • Transparency and cooperation
  • Completed PCI audit checklist
  • Understanding of current PCI DSS
  • Your printed copy of your Report on Compliance (ROC) from the previous year
  • Evidence of quarterly scanning and penetration testing
  • Evidence of regular event log checks
  • Documentation on how you handle third party vulnerabilities

Remember: the role of the auditor is to prevent the compromise of cardholder data, not to punish your company. As long as you’re cooperative and vested, the auditor will explain where you need to improve and help you do it. To execute these changes efficiently, consider appointing a compliance leader within your organization. This individual takes responsibility for compliance efforts, but also should have the authority to compel change across your team.

9 Common PCI Mistakes Revealed by PCI Audits

nexcess data centerIf you care enough about PCI compliance to read this article, then you’re on the right track. Following are nine common mistakes for merchants undergoing audit, though your experience may vary according to your business needs and PCI compliance level. 

Hiring a PCI compliant hosting provider like Hostdedi will go a long way toward preventing these mistakes, but it’s not a magic bullet. Merchants must do their part as well, but most hosting providers can assist you in this task.

Reminder: CDE, or cardholder data environment, refers to any device, component, network, or application that stores, processes, or transmits cardholder data.

Unnecessary storage of credit card data 

As a general rule, you should take every reasonable step to avoid storing credit card data, and never store CVV numbers for any reason. Many merchants choose to store data to accelerate their customers’ checkout process without fully understanding the implications for compliance. Don’t be one of them.

Failure to separate the CDE network from rest the organization’s IT infrastructure

The key phrase to remember in PCI-compliance and access to cardholder data is “as-needed.” Make it your mantra. This applies more so to sub-networks within your organization. When applied to your network, it is known as “network segmentation,” though it usually applies to sub-networks within your organization. Sub-networks used for internal office communications should have no access—direct or indirect—to the sub-networks with access to the CDE.

Failure to restrict access to the CDE to only those employees that need it 

Once again, only employees needing access should have it. This refers both to physical access to areas housing devices within the CDE, but also permissions and passwords.

Insufficient training and security awareness

This extends to your team as well as yourself. If you employ a team, consider appointing someone as a Compliance Officer to take responsibility for training efforts, and give them enough authority to get the job done.

Weak password security policy

Passwords to any system within the CDE should be unique, complex, and never shared between employees. Password managers like LastPass, Zoho, 1Password, and many others are invaluable for safely generating and storing complex passwords. If your team isn’t using one, then it’s a red flag for your security practices. Two-factor authentication for any CDE system is likewise essential, whether Google Authenticator, Duo, or something similar.

Missing web application firewall (WAF) 

A web application firewall (WAF) identifies and interrupts malicious activity and exploits. Most merchants don’t use one in their infrastructure. You can pass a PCI assessment without, but it requires a code audit any time you make changes to your application (Magento, WordPress, and so on). Most hosting providers can provide a WAF solution, or you can use a cloud-based one, which will increase security and simplify PCI compliance.

Inadequate network activity logs 

A network log is a record of events, and is crucial for identifying and tracking the efforts of bad actors attempting to gain access. Again, if you’re a level 1 merchant that processes millions of credit card transactions per year, you’re an inviting target and likely have a network administrator in place. If you’re not a Level 1 merchant and you’re facing audit, then it means you were recently breached 

Missing or poorly configured firewalls and routers 

The security of a network firewall (not to be confused with web application firewall) or router is only as good as the person configuring it. Know your stuff or employ someone that does.

Unclear or outdated security incident response procedures 

Whether you use Magento, WooCommerce, or any other platform, you or your system administrator should take great pains to stay current on the latest vulnerabilities. Have a plan to respond to exploits when—not if, but when—they occur.

Don’t Wait for Your Audit to Get Started

As a final point, never forget that PCI compliance is an ongoing effort. Annual audits are only one component of compliance, but a proactive approach with upcoming changes to your CDE will often pay dividends. Engage your QSA about these changes well before they happen, as they can provide sage advice about maintaining compliance. 

 

For guidance with PCI compliance, contact our sales team between 9 a.m.–5 p.m. eastern time, Monday to Friday.  

Source link

Is the End Near for EV SSL Certificates?

Is the End Near for EV SSL Certificates?

Google, Firefox, and Apple certainly think so. Extended Validation (EV) SSLs are effectively being put out to pasture. Upcoming changes to Chrome and Firefox will soon remove the EV badge from their browsers, citing concerns with its diminished reputation for protecting consumers. 

Standard vs. EV SSL certificates

If you’re already familiar with SSL certificates and the difference between Standard and Extended Validation (EV) varieties, skip ahead to the Why Are Browsers Burying EV SSL Certificates? section. 

SSL certificates are digital certificates that authenticate the identity of a website and allow for secure transmission of credit card data, login credentials, and other sensitive information. Though many types are available, standard SSL certificates provide the padlock icon in most browsers, help make your site PCI-compliant, and are a good choice for most merchants. 

Gray SSL Padlock

In most browsers, sites without SSL certification receive the “Not Secure” label, and anyone clicking on it will read a dire warning. 

Not Secure SSL warning

Furthermore, most browsers also will warn the user before entering any credit card information. Even if they don’t notice the lock, it’s almost impossible to miss the alert upon checkout. This tends to have a chilling effect on most users’ buying experience.

SSL warning

EV SSL certificates attempt to enhance this authentication with a more rigorous (and expensive) validation process. The end result is the addition of the merchant’s established legal identity just to the left of the web address.

In theory, this provides an additional visual cue for consumers, which makes them feel safer and more likely to spend their money on the site. In practice, most consumers don’t notice the absence of a site’s “legal identity,” meaning the EV SSL certificate provide little value to anyone other than the organization selling it.

Why Are Browsers Burying EV SSL Certificates?

In cyber security circles, criticism of EV SSL is not new. The stated goals for EV SSL are 1) to make it harder for phishing scams to fake their online identity, and 2) make consumers feel more safe. Their argument is that EV SSLs are only marginally effective at #1, and utterly ineffective at #2. 

The core failing in the “legal identity” tactic against phishing scams is the relative fluidity of those legal identities. The phrase itself is a misnomer, one that falsely invokes images of face-to-face authentication and triple-checked claims. As demonstrated by one industry professional, the methods of identity verification vary by state, with many ranging between “woefully inadequate” and “cursory.” A determined bad actor would have little trouble registering “Identity Verified” or some other devious “legal identity” to dupe unsuspecting consumers into feeling secure.

However, such efforts would likely be wasted, because the same experts claim most users simply fail to notice the presence or absence of the legal identity. Apple has alread removed the visual cue from Safari and Mojave  for this very reason. Recently, Chrome and Firefox announced their intent to follow suit, with the former stating: 

Users do not appear to make choices (such as not entering password or credit card information) when the UI is altered or removed, as would be necessary for EV UI to provide meaningful protection.

For Chrome, this takes effect on September 10. The change comes to Firefox on October 22. The legal identifier will still be available, but buried in the interface and only accessible to the determined clicks of a knowledgeable user. 

Despite the exaggerated claims of organizations eager to sell EV certificates, most users are content to see the padlock and not see any warnings at checkout, both of which are provided by other, less expensive SSL certificates.  

 

If you have questions about which SSL certificate is right for you, contact our sales team for assistance.

The post Is the End Near for EV SSL Certificates? appeared first on Hostdedi Blog.

Source link

How Hostdedi Helps Your Store Stay PCI Compliant

How Hostdedi Helps Your Store Stay PCI Compliant

Having a PCI compliant store requires the sustained efforts of both yourself and your hosting provider. Although there are no shortcuts, choosing a credible web hosting provider is an effective place to start. Even so, most PCI requirements can only be met by you, the merchant. Read on to learn more about the dividing line between host and merchant, and why it can be worthwhile to go beyond PCI for your customers.

 

What Is PCI?

nexcess locked safeIn ecommerce, PCI is shorthand for Payment Card Industry Data Security Standards (PCI DSS). Created in 2004, PCI DSS aim to help protect consumers and prevent credit card fraud. It is required for any organization that receives, processes, or stores credit card data of any of the five members of the PCI Security Council: VISA, MasterCard, American Express, Discover, and JCB.

The list of requirements is extensive, to put it mildly. The requirements span six categories, and each category is divided into several hundred specific requirements. Some fall exclusively under the domain of either merchants or hosting providers, while some extend to both. PCI compliance is also not a one-time requirement, as the Security Council makes periodic adjustments to address new threats to consumers.

Compliance is not a “one-and-done” event. It requires daily, weekly, monthly, and annual tasks to maintain compliance. There are 12 general requirements divided among six categories. For illustrative purposes, we’ve listed these same categories, but also included more specific requirements from within PCI DSS. 

6 Key Categories for PCI Compliance

Build and maintain a secure network. Install and maintain a firewall. Use unique, high-security passwords with special care to replace default passwords.

Protect cardholder data. Whenever possible, do not store cardholder data. If there is a business need to store cardholder data, then you must protect this data. Encrypt any data passed across public networks, including data passed between your shopping cart, your Web-hosting provider, and your customers.

Maintain a vulnerability management program. Use antivirus software and keep it up to date. Develop and maintain secure operating systems and payment applications. Ensure your antivirus software applications are compliant with your chosen card companies.

Implement strong access control measures. Access to cardholder data, both electronic and physical, should be on a need-to-know basis. Ensure those people with electronic access have a unique ID and password. Do not allow people to share login credentials. Educate yourself and your employees on data security, and specifically the PCI Data Security Standard (DSS).

Regularly monitor and test networks. Track and monitor all access to networks and cardholder data. Maintain a regular testing schedule for security systems and processes, including: firewalls, patches, web servers, email servers, and antivirus.

Maintain an information security policy. Establish a clear and thorough organizational data security policy. Disseminate and update this policy regularly.

PCI non-compliance can result in fines ranging between $5000—$100,000 per month, depending on the size of the offending organization, its severity, and other factors. Non-compliance can also result in legal action, security breaches, and lost revenue.

PCI Requirements for Hosting Providers 

nexcess monitoringIt is virtually impossible for the typical merchant to be PCI compliant without enlisting the services of a compliant hosting provider. Merchants that host their own websites must meet hosting provider requirements in addition to meeting those for merchants. Such a model works for massive enterprises like Amazon and WalMart, but few others. 

Following are some of the highlights of our systems and policies that uphold our status as a PCI compliant hosting provider. The term “cardholder data environment” refers to any system that stores, processes, or transmits credit card data as well as any system that has access to cardholder data environment itself.

We maintain a web application firewall (WAF), which monitors all connections between the cardholder data environment and other networks. ModSec prohibits public access to sensitive areas, identifies untrusted connections, and hides IP addresses and routing information from unauthorized parties. 

We apply industry-accepted configuration standards for all system components that address all known security vulnerabilities. This extends to our internal and external network, our operating systems, and hardware required to host web services.

We apply cryptography and security protocols that encrypt and protect cardholder data even when transmitted across public networks. SSL certificates and other trusted security keys are unilaterally enforced. Only modern TLS ciphers are permitted.

We restrict physical access to our data center with 24-hour security policies and a team trained to implement them. This includes, but is not limited to:

  • Video surveillance with 90-day footage history
  • Secured entry with at least two-factor authentication (PIN, access card) in most areas, and three-factor authentication (PIN, access card, thumbprint) in areas housing the cardholder data environment
  • Visible identification on all team members
  • Visitor policy that prevents unauthorized public access; authorized external individuals have access only to required areas and are escorted at all times 
  • Team members are given access to the cardholder data environment only if their role requires it
  • Restricted access to network jacks, wireless access points, gateways, networks, and other lines of communication

We track and monitor access to network resources and cardholder data, though it falls to clients to maintain logs and monitor logins for their own applications (Magento, WordPress, and so on).  

We regularly test our security systems and processes, and perform internal penetration testing at regular intervals as well as after any significant infrastructure upgrade. 

PCI Requirements for Merchants

Secure store with HostdediProperly implemented, PCI compliance helps merchants adhere to commonly accepted best practices of data security. Hosting with a PCI compliant provider is a solid first step, but becoming compliant still requires action on your part.

If your store accepts credit cards as payment, it must be PCI compliant whether you store that data or not. Choosing a PCI Compliant web host is only the first step. Most credible web hosts can provide merchants with materials outlining their respective responsibilities upon request, but ultimately it is on merchants to understand and meet these requirements. 

Regrettably, there is no “one size fits all” checklist. Your specific responsibilities will vary according to your merchant level (1–4, with 1 being the highest), which is generally determined by the number of credit card transactions your store processes annually. 

The general process for most merchants is:

  1. Identify, understand, and implement the appropriate PCI DSS requirements. 
  2. Complete a Self Assessment Questionnaire (SAQ). The SAQ is a checklist outlining the requirements. Depending on your level, some or all of them will apply to you. Level 1 merchants have the most requirements; level 4, the least.
    Resist the temptation to simply “check every box” in the SAQ. Doing so endangers your customers and exposes your business to liability. The PCI stands to lose money from breaches, and in response may investigate your SAQ and AOC.
  3. Submit to a quarterly scan by an Approved Scanning Vendor (ASV), an independent, qualified authority that performs external vulnerability scans on your systems. 
  4. Complete the Attestation of Compliance (AOC), a document asserting that you are both eligible to perform and have in fact performed the SAQ to the best of your ability.
  5. If classified as a level 1 merchant, you must take additional steps, including an on-site assessment. 

If climbing the considerable hurdle of PCI compliance doesn’t appeal to you, you’re not alone. Your hosting provider can answer questions related to overlapping responsibility, and third party Qualified Security Assessors (QSAs) can help businesses run the PCI gauntlet (for a price). 

Even businesses offering only PayPal, Auth.net, and other payment services as payment options must be PCI compliant because those businesses must still transmit credit card data.

One universal component is the need to confirm that all of your service providers are PCI compliant. This includes your hosting provider, but also extends to payment processors, payment gateways, POS providers, and any other entities that touch your customers’ cardholder data. 

Some PCI Essentials for Merchants

  • Maintain PCI compliance. Compliance requires ongoing awareness and daily application. Tasks range between daily and annual, but all are recurring.
  • Don’t just check “Yes” to every question in the SAQ. Due diligence protects your business and your customers.
  • Know your code, or use a developer that does. Implement best practices of deployment using staging and dev sites without exception.
  • Establish a secure password policy. Use complex, unique passwords and never allow your staff to share login credentials or use default passwords.
  • Enable two-factor authentication for all of your internal users, and consider providing it as an option for customers logging in to your site.
  • Use a web application firewall (WAF). At Hostdedi, we provide one for all clients and it’s enabled by default.
  • Don’t just take your hosting provider’s word for it. Confirm they’re PCI Compliant and competent by asking for (and getting) their Attestation of Compliance (AOC).
  • Keep your applications and extensions current to the latest stable release, and actively monitor for new threats and versions.

Beyond PCI

If PCI compliance were enough, breaches of high-profile organizations would be far less common. Compliant should not mean complacent.

In reality, PCI compliance is “Cardholder Data Security 101.” It is the minimum acceptable standard and a reasonable introduction, but PCI is far from infallible. Credit card companies require compliance. Merchants adhering to PCI standards will be more effective at protecting consumers than businesses that just pay them lip service, but PCI compliance is only the first step. 

The very nature of PCI — a large, curated document updated only periodically — makes it vulnerable. Standards deemed sufficient in the “current” version are often exposed as inadequate. It can take months or even years for PCI to “catch up,” and bad actors are well aware of its limitations.

The best protection is knowledge. At Hostdedi, we have team members that specialize in web security who stay well-versed in the newest threats, breaches, and countermeasures. Many merchants may be reluctant to enlist the services of a security expert. At the very least, we recommend subscribing to security notifications for your ecommerce application and following at least one credible web security news source. Both sources react much faster than the PCI, and following them will help you “spot the smoke” before it becomes a fire. 

We’re on the List!

Don’t forget, we’re “On the List” of PCI compliant providers officially recognized by the Visa Global Registry. That means we’ve shown a continued commitment to reviewing and improving our security policies to match and exceed PCI compliance requirements. If you’re looking for a PCI compliant provider, hosting with Hostdedi means you’re hosting with an approved and recognized provider. Learn more about the PCI compliant hosting with Hostdedi. 

For guidance with PCI compliance, contact our sales team between 9 a.m.–5 p.m. eastern time, Monday to Friday.  

Source link

How Hostdedi Helps Your Store Stay PCI-Compliant

How Hostdedi Helps Your Store Stay PCI-Compliant

Having a PCI-compliant store requires the sustained efforts of both yourself and your hosting provider. Although there are no shortcuts, choosing a credible web hosting provider is an effective place to start. Even so, most PCI requirements can only be met by you, the merchant. Read on to learn more about the dividing line between host and merchant, and why it can be worthwhile to go beyond PCI for your customers.

 

What Is PCI?

nexcess locked safeIn ecommerce, PCI is shorthand for Payment Card Industry Data Security Standards (PCI DSS). Created in 2004, PCI DSS aim to help protect consumers and prevent credit card fraud. It is required for any organization that receives, processes, or stores credit card data of any of the five members of the PCI Security Council: VISA, MasterCard, American Express, Discover, and JCB.

The list of requirements is extensive, to put it mildly. The requirements span six categories, and each category is divided into several hundred specific requirements. Some fall exclusively under the domain of either merchants or hosting providers, while some extend to both. PCI compliance is also not a one-time requirement, as the Security Council makes periodic adjustments to address new threats to consumers.

Compliance is not a “one-and-done” event. It requires daily, weekly, monthly, and annual tasks to maintain compliance. There are 12 general requirements divided among six categories. For illustrative purposes, we’ve listed these same categories, but also included more specific requirements from within PCI DSS. 

6 Key Categories for PCI Compliance

Build and maintain a secure network. Install and maintain a firewall. Use unique, high-security passwords with special care to replace default passwords.

Protect cardholder data. Whenever possible, do not store cardholder data. If there is a business need to store cardholder data, then you must protect this data. Encrypt any data passed across public networks, including data passed between your shopping cart, your Web-hosting provider, and your customers.

Maintain a vulnerability management program. Use antivirus software and keep it up to date. Develop and maintain secure operating systems and payment applications. Ensure your antivirus software applications are compliant with your chosen card companies.

Implement strong access control measures. Access to cardholder data, both electronic and physical, should be on a need-to-know basis. Ensure those people with electronic access have a unique ID and password. Do not allow people to share login credentials. Educate yourself and your employees on data security, and specifically the PCI Data Security Standard (DSS).

Regularly monitor and test networks. Track and monitor all access to networks and cardholder data. Maintain a regular testing schedule for security systems and processes, including: firewalls, patches, web servers, email servers, and antivirus.

Maintain an information security policy. Establish a clear and thorough organizational data security policy. Disseminate and update this policy regularly.

PCI non-compliance can result in fines ranging between $5000—$100,000 per month, depending on the size of the offending organization, its severity, and other factors. Non-compliance can also result in legal action, security breaches, and lost revenue.

PCI Requirements for Hosting Providers 

nexcess monitoringIt is virtually impossible for the typical merchant to be PCI compliant without enlisting the services of a compliant hosting provider. Merchants that host their own websites must meet hosting provider requirements in addition to meeting those for merchants. Such a model works for massive enterprises like Amazon and WalMart, but few others. 

Following are some of the highlights of our systems and policies that uphold our status as a PCI-compliant hosting provider. The term “cardholder data environment” refers to any system that stores, processes, or transmits credit card data as well as any system that has access to cardholder data environment itself.

We maintain a web application firewall (WAF), which monitors all connections between the cardholder data environment and other networks. ModSec prohibits public access to sensitive areas, identifies untrusted connections, and hides IP addresses and routing information from unauthorized parties. 

We apply industry-accepted configuration standards for all system components that address all known security vulnerabilities. This extends to our internal and external network, our operating systems, and hardware required to host web services.

We apply cryptography and security protocols that encrypt and protect cardholder data even when transmitted across public networks. SSL certificates and other trusted security keys are unilaterally enforced. Only modern TLS ciphers are permitted.

We restrict physical access to our data center with 24-hour security policies and a team trained to implement them. This includes, but is not limited to:

  • Video surveillance with 90-day footage history
  • Secured entry with at least two-factor authentication (PIN, access card) in most areas, and three-factor authentication (PIN, access card, thumbprint) in areas housing the cardholder data environment
  • Visible identification on all team members
  • Visitor policy that prevents unauthorized public access; authorized external individuals have access only to required areas and are escorted at all times 
  • Team members are given access to the cardholder data environment only if their role requires it
  • Restricted access to network jacks, wireless access points, gateways, networks, and other lines of communication

We track and monitor access to network resources and cardholder data, though it falls to clients to maintain logs and monitor logins for their own applications (Magento, WordPress, and so on).  

We regularly test our security systems and processes, and perform internal penetration testing at regular intervals as well as after any significant infrastructure upgrade. 

PCI Requirements for Merchants

Secure store with HostdediProperly implemented, PCI compliance helps merchants adhere to commonly accepted best practices of data security. Hosting with a PCI-compliant provider is a solid first step, but becoming compliant still requires action on your partt.

If your store accepts credit cards as payment, it must be PCI-compliant whether you store that data or not. Choosing a PCI-compliant web host is only the first step. Most credible web hosts can provide merchants with materials outlining their respective responsibilities upon request, but ultimately it is on merchants to understand and meet these requirements. 

Regrettably, there is no “one size fits all” checklist. Your specific responsibilities will vary according to your merchant level (1–4, with 1 being the highest), which is generally determined by the number of credit card transactions your store processes annually. 

The general process for most merchants is:

  1. Identify, understand, and implement the appropriate PCI DSS requirements. 
  2. Complete a Self Assessment Questionnaire (SAQ). The SAQ is a checklist outlining the requirements. Depending on your level, some or all of them will apply to you. Level 1 merchants have the most requirements; level 4, the least.
    Resist the temptation to simply “check every box” in the SAQ. Doing so endangers your customers and exposes your business to liability. The PCI stands to lose money from breaches, and in response may investigate your SAQ and AOC.
  3. Submit to a quarterly scan by an Approved Scanning Vendor (ASV), an independent, qualified authority that performs external vulnerability scans on your systems. 
  4. Complete the Attestation of Compliance (AOC), a document asserting that you are both eligible to perform and have in fact performed the SAQ to the best of your ability.
  5. If classified as a level 1 merchant, you must take additional steps, including an on-site assessment. 

If climbing the considerable hurdle of PCI compliance doesn’t appeal to you, you’re not alone. Your hosting provider can answer questions related to overlapping responsibility, and third party Qualified Security Assessors (QSAs) can help businesses run the PCI gauntlet (for a price). 

Even businesses offering only PayPal, Auth.net, and other payment services as payment options must be PCI-compliant because those businesses must still transmit credit card data.

One universal component is the need to confirm that all of your service providers are PCI-compliant. This includes your hosting provider, but also extends to payment processors, payment gateways, POS providers, and any other entities that touch your customers’ cardholder data. 

Some PCI Essentials for Merchants

  • Maintain PCI compliance. Compliance requires ongoing awareness and daily application. Tasks range between daily and annual, but all are recurring.
  • Don’t just check “Yes” to every question in the SAQ. Due diligence protects your business and your customers.
  • Know your code, or use a developer that does. Implement best practices of deployment using staging and dev sites without exception.
  • Establish a secure password policy. Use complex, unique passwords and never allow your staff to share login credentials or use default passwords.
  • Enable two-factor authentication for all of your internal users, and consider providing it as an option for customers logging in to your site.
  • Use a web application firewall (WAF). At Hostdedi, we provide one for all clients and it’s enabled by default.
  • Don’t just take your hosting provider’s word for it. Confirm they’re PCI-compliant and competent by asking for (and getting) their Attestation of Compliance (AOC).
  • Keep your applications and extensions current to the latest stable release, and actively monitor for new threats and versions.

Beyond PCI

If PCI compliance were enough, breaches of high-profile organizations would be far less common. Compliant should not mean complacent.

In reality, PCI compliance is “Cardholder Data Security 101.” It is the minimum acceptable standard and a reasonable introduction, but PCI is far from infallible. Credit card companies require compliance. Merchants adhering to PCI standards will be more effective at protecting consumers than businesses that just pay them lip service, but PCI compliance is only the first step. 

The very nature of PCI — a large, curated document updated only periodically — makes it vulnerable. Standards deemed sufficient in the “current” version are often exposed as inadequate. It can take months or even years for PCI to “catch up,” and bad actors are well aware of its limitations.

The best protection is knowledge. At Hostdedi, we have team members that specialize in web security who stay well-versed in the newest threats, breaches, and countermeasures. Many merchants may be reluctant to enlist the services of a security expert. At the very least, we recommend subscribing to security notifications for your ecommerce application and following at least one credible web security news source. Both sources react much faster than the PCI, and following them will help you “spot the smoke” before it becomes a fire. 

We’re on the List!

Don’t forget, we’re “On the List” of PCI compliant providers officially recognized by the Visa Global Registry. That means we’ve shown a continued commitment to reviewing and improving our security policies to match and exceed PCI compliance requirements. If you’re looking for a PCI compliant provider, hosting with Hostdedi means you’re hosting with an approved and recognized provider. Learn more about the PCI compliant hosting with Hostdedi. 

For guidance with PCI compliance, contact our sales team between 9 a.m.–5 p.m. eastern time, Monday to Friday.  

Source link

Does Cloud Security Depend on Processor Security Vulnerabilities?

Does Cloud Security Depend on Processor Security Vulnerabilities?

Does Cloud Security Depend on Processor Security Vulnerabilities?Readers with long memories will recall the suspicion the cloud was greeted with when it was first introduced more than a decade ago. Site owners who managed their servers doubted that cloud vendors could do a better job, especially where security is concerned. Who knew what lurked beneath the virtualization layer? In subsequent years, as cloud platforms came to dominate the infrastructure hosting world, concerns about their security largely evaporated.

In 2019, most companies run most of their infrastructure in the cloud. The benefits of cloud infrastructure have proven immense for improving reliability, scalability, and cost-efficiency for everyone from boutique ecommerce retailers to the largest online stores. Cloud adoption has not resulted in widely exploited vulnerabilities. Servers are still hacked, and data is still leaked, but the exploited vulnerabilities are almost at the application or database layer, not at the virtualization layer or in the underlying physical hardware.

However, no platform is entirely secure, including the cloud. Last year, the Spectre and Meltdown vulnerabilities hit the headlines. Flaws in some CPUs allowed malicious users who could run code on a server to access sensitive information owned by other cloud users. This year, further vulnerabilities were discovered, including ZombieLoad, which could allow an attacker to steal data recently processed by a CPU.

All servers with affected processors are vulnerable to this type of attack, but because cloud platforms are shared computing environments, the risks are higher. A malicious user could exploit the vulnerability by running code in their cloud environment, accessing the information of other cloud users hosted on the same server.

Does this mean the cloud is no longer secure?

No. In fact, cloud platforms like the Hostdedi Cloud are still the most secure infrastructure hosting option. While processor vulnerabilities like ZombieLoad are a real problem for the hosting industry, cloud platforms are best placed to protect their users.

Cloud platforms have access to greater technical expertise. Building a secure cloud platform is not easy, and cloud platforms are not equally secure. However, we have staff developers and system administrators who have decades of experience with infrastructure security. They understand what the risks are and how to manage them. Few hosting clients have access to such breadth and depth of knowledge.

Patches are applied to all servers quickly. When news of the Spectre and Meltdown vulnerabilities broke, Hostdedi quickly patched its servers and released a blog article explaining what was happening. We follow the same procedure for all vulnerabilities that might impact our cloud hosting clients. Ecommerce retailers and other businesses running on owned servers cannot react with the same speed and agility.

Platforms like the Hostdedi Cloud are not secure by default; they are secure because engineers build and maintain them, constantly monitoring security threats and reacting accordingly. Our cloud platform is secure because security is our top priority. That’s not true of most businesses, which is why owned infrastructure tends to be less secure than cloud infrastructure. Bloggers want to blog and ecommerce retailers want to sell. But we’re obsessive about security, and that’s why our cloud platform is the secure hosting choice.

Posted in:
Security

Source link

Getting Started With File Permissions

Getting Started With File Permissions

Getting started with file permissionsFile permissions are an important aspect to consider for any website. This is even more important in a shared hosting environment, since neighboring clients can potentially read or write to your files if the permissions are configured incorrectly.

Even just the ability to read files can expose sensitive information from site configuration files, such as the credentials necessary to access your database. The ability to write or alter your files could allow others to use your site to run malicious code, spread malware, or perform any other number of unwanted activities, including vandalizing your site.

 

Why Are File Permissions Important?

While file permissions are important in any hosting environment, this article will be dealing specifically with current Hostdedi hosting environments. If file permissions are new to you, ask your service provider about best practices pertaining to your specific environment before making any changes.

Before attempting to set or alter permissions, you should first understand how they are represented on a typical web server.

Permissions are granted to three categories: user, group, and other. The user is the user on the system that owns the file. On Hostdedi systems, the group owner will typically be the user. On other hosts, you may have shared groups set up for the web server, FTP processes, and so on. In this context, “other” means absolutely any user having access to the system, including the group and owner.

 

What File Permissions Are There?

Each of the above categories can be granted three standard permissions: read, write, and execute.

The read permission allows a user to see the contents of the file. The write permission allows users to alter the contents of a file. The execute permission gives a user the ability to run a file if the file type is executable on the system, or can be run within a directory. This would not typically grant any special abilities on a normal image file.

The read, write, and execute permissions are typically represented in two forms. One form is the letters r (read), w (write), x (execute).

 

Octal Form File Permissions

The other form is known as an octal form, where 4 represents read, 2 represents write, and 1 represents execute.  

If more than one permission is being granted, the numbers are added together, with the numbers shown in the order, user–group–other. For example, permissions of 700 would mean the file owner (user) has read, write, and execute permissions, but the group and everyone else has no permissions. If the permissions were set to 600, the file owner would have read and write privileges (4+2), with all others having no permissions. 777 grants read, write, and execute access to all users.

One special, helpful permission, is the setgid permission. Using this on a directory will cause any file created in the directory to inherit the same group as the parent directory. There are other special permissions, as well as access control lists that can be applied to files and folders beyond the user, group, and other categories, but they are outside the scope of this article.  

 

Hostdedi File Permission Defaults

Current Hostdedi systems run the Apache web server as a separate user, so directories typically need “other” execute permission. This allows Apache to operate on the contents of the directories.

Apache needs read access for any .htaccess files used by your site, and read access to static files like CSS, JS, and image files. These permissions allow Apache to read and transmit files to the end client requesting them. All PHP files will be executed by your system user using PHP-FPM, and should typically only have permissions granted to the user.

Since PHP processes and application run as your user on the system, these files typically only need to be accessible by your user.

To summarize general permission settings for securing a web application:

  • Directories should be 711, which allow your user full access and allow the web service access to the directories to read static files.
  • PHP files and application configuration files should have permissions of 600, which allows only your user access.
  • Image files and static site assets such as CSS, JS, font files, and so on need permissions of 644, which allows Apache to serve these as expected without receiving a 403 or forbidden response.

 

Checking File Permissions

Two easy ways to check file permissions are with the stat and ll commands.

Issuing the stat command on a file does show much more information that simply the permissions, but on the first line that starts with Access: will show the permissions in both numerical and alphabetic forms. The stat below shows the permissions as 0660 or -rw-rw—- . Which would be user and group having read and write access but all others having not access.

 

  $ stat file.xyz 
  File: `file.xyz'
  Size: 0          Blocks: 0          IO Block: 4096 regular empty file
  Device: 807h/2055d Inode: 524917      Links: 1
  Access: (0660/-rw-rw----)  Uid: (1337/uzer) Gid: (1337/uzer)
  Access: 2018-07-19 15:01:42.000000000 -0400
  Modify: 2017-04-04 08:36:53.000000000 -0400
  Change: 2018-07-19 15:01:42.891553118 -0400



Using the ll command you will only receive the alphabetic form of the permissions, output from the same file above looks like the content below when using ll.

 

  ll file.xyz 
  -rw-rw---- 1 uzer uzer 0 Apr  4 2017 file.xyz

 

Setting File Permissions

The chmod command is used to change permissions, it accepts the permissions in several formats. Below we are changing the permissions to 600 for the file.xyz file.

 

  chmod 600 file.xyz

 

To express this in the non numeric way, we would use the command below. This would set it so the user has read and write access.

 

  chmod u+rw file.xyz

 

To add permissions so a user group can have read and write access, you would use the following syntax.

 

  chmod ug+rw file.xyz

 

Bulk File Permission Changes With the Chmod Command

Changing the permissions on a large number of files at once can be done by using the -r or recursive flag with the chmod command. You can also use the find command, in conjunction with the chmod command, to select certain files or file types and adjust their permissions.

An easy way to help secure file permissions across your site is to run the following commands from your web application root directory.

First we set all directory permissions to 711.

 

  find . -type d -exec chmod 711 {} ;

 

You may want to use the setgid on the directories, this would be set on all directories with the following command.

 

  find . -type d -exec chmod 2711 {} ;

 

Then we set all file permissions to 644 so your user has read and write access and your group and others have read access. This will allow Apache to access and serve static site files.

 

  find . -type f -exec chmod 644 {} ;

 

We would then want to go through and tighten security on all PHP files so only your user has access to them.

 

  find . -type f -name “*.php” -exec chmod 600 {} ;

 

After doing the above, you would want to manually change the permissions with chmod on any sensitive site files without the .php extension to 600. For something like Magento 1.X with a local.xml configuration file, the command would be the following, run from your web application root:

 

  chmod 600 app/etc/local.xml 

 

Application Specific Configuration Files

Below are some notable application-specific configuration files that should use 600 permissions exclusively. For additional security, some of the below applications also recommend moving directories containing configuration files outside of the website’s document root. If your application has been modified, some of these files may be in a different location, or there may be additional sensitive configuration files. When in doubt, contact your web host or development team.  

Magento 1.X

app/etc/local.xml

Magento 2.x

app/etc/env.php

WordPress

wp-config.php

Drupal

sites/default/settings.php

ExpressionEngine

system/expressionengine/config/config.php

Craft

craft/config/db.php

Posted in:
Linux, Security

Source link

The Dangers Of Exposed Git Repos

The Dangers Of Exposed Git Repos

The Dangers Of Exposed Git ReposStoring Git’s repository directory – the .git directory – in a publicly accessible area of a website may expose sensitive information that bad actors can use to steal data or compromise the site.

Git is a version control system and a major part of many development workflows. WordPress and Magento developers use Git to version control code and to collaborate on its development. Git itself is secure, but developers can cause security issues if they aren’t careful where version controlled code is stored.

In a recent survey of many millions of domains, security researcher Vladimír Smitka shows just how prevalent this misuse of Git is. After scanning more than 230 million domains, Smitka discovered 40,000 WordPress sites, 4,000 WooCommerce sites, and 2,000 with exposed .git directories.

Why Are Exposed Git Directories Bad For Security?

The .git folder contains records of every change made to a site’s code. That information is useful to bad actors looking for clues about vulnerabilities in the site. Information about how code is structured, which libraries are used and their versions, API endpoints, and other details about the site can be used by bad actors to develop a plan of attack. Ordinarily, this information is difficult to find, but an exposed .git repo makes life much easier for bad actors.

This situation is made worse if developers version control sensitive information such as database passwords and API keys. Sensitive data should never be stored in version control systems that are accessible to the public – in fact, they should not be stored in version control at all. Unfortunately, many developers do store sensitive information in Git repositories. If they also have .git in their web server’s public directory, the whole world can access them.

Does Your Site Serve A Git Repository To Visitors?

As Smitka points out, the straightforward method for finding a .git repository often doesn’t work. If a developer tries to visit https://example.com/.git they may receive a 403 error even if there is an exposed repository. The error is caused by a missing index.html file and configuration that denies directory listing.

However, a bad actor could visit https://example.com/.git/HEAD and, with a little trouble, access the sensitive information they want.

Mitigating The Problem

The best solution is the simplest. Don’t put sensitive data in Git repositories. Don’t keep .git in directories that are served by your web server. If you have decided that you need to keep version control information in a directory that would by default be publicly accessible, you can block access with a rule in the site’s .htaccess file.

There are various ways to block access to the .git directory, but Smitka has created a simple .htaccess rule that works well for Apache 2.4:

<Directory ~ "/.(?!well-known/)">
 Require all denied
</Directory>

This rule blocks access to all dot directories except .well-known, which is often used to provide site metadata to web clients. You will find a version suitable for Apache 2.2 here.

Posted in:
Security

Source link

eCommerce Login Attempts Are Almost Always Fraudulent

eCommerce Login Attempts Are Almost Always Fraudulent

Nine out of ten eCommerce login attempts are fraudulent. That is the key finding of an investigation of credential stuffing by Shape Security, a provider of online fraud prevention. Credential stuffing involves the use of stolen credentials to log in to customer accounts to buy products and take advantage of credit arrangements.

Online retailers are more likely to be targeted by credential stuffing because it is common for shoppers to reuse the same credentials on different sites and because automating the eCommerce login process is straightforward compared to banks and other potential targets.

Credential stuffing starts with leaked usernames and passwords. Last year, over 2.3 billion username and password pairs were leaked by online services. Most of the leaked credentials came from Yahoo, which repeatedly exposed the credentials of billions of users. Tens of millions of credentials were leaked from poorly secured forums, databases, and servers. Millions more were leaked in phishing and malware attacks against users.

The usernames and passwords are gathered by criminals and used to make login attempts on eCommerce stores, banks, and social media accounts. The most sophisticated credential stuffing operations create bespoke login scripts that operate from dozens of locations.

The scripts make millions of login attempts with the leaked credentials on tens of thousands of stores. Shoppers use the same email address and password combination on multiple sites, so the leaked credentials can be used to successfully authenticate on many sites and eCommerce stores.

The criminals’ “conversion rates” are quite low: the best credential stuffers successfully authenticate on less than one percent of accounts, but credential stuffing generates significant revenue because credential stuffing is a high-volume, low-cost operation.

Once they have access, the criminals can steal user data, consume gift card balances, and place large fraudulent orders using stored or stolen credit card numbers. It is estimated that credential stuffing costs the US economy in excess of $5 billion per year.

Preventing Credential Stuffing

It is relatively easy to stop credential stuffing from a technological perspective. Implementing two-factor authentication on shopper accounts would be completely effective. Increasing the complexity of the login process would make it more difficult for criminals to automate attacks.

But neither of those methods appeal to eCommerce merchants because they have the unwanted side effect of reducing conversions. The eCommerce industry is incentivized to make it easier for shoppers to authenticate, not more difficult.

Alternatives include IP blacklists, which can be successful against less sophisticated attackers that don’t have access to large networks of proxy servers. Blacklisting is less effective against more sophisticated operations that use paid proxying services and botnets.

Credential stuffing is likely to remain a problem for as long as we use username and password combinations for authentication. Advanced authentication systems such as FIDO 2 are the most likely long-term solution because they provide simple and secure logins without shared secrets.

Posted in:
Security

Source link

Google Chrome Displays Insecure Warning On All HTTP Pages

Google Chrome Displays Insecure Warning On All HTTP Pages

Google AnalyticsOn July 24th, Google released Chrome 68, which will mark insecure any page loaded over an HTTP connection. The long-planned move means that any site that doesn’t have an SSL certificate that enables it to use HTTPS will be prominently marked as insecure in the browser’s search bar.

HTTP Security Setting

HTTPS is a secure version of HTTP, the protocol used to send data over the internet. With HTTP, data is sent in the clear: it can be intercepted and read by third parties in what is known as a man-in-the-middle attack.

HTTPS connections use SSL certificates to encrypt the data and validate the identity of the server sending it. Data traveling over an HTTPS connection can’t be intercepted and read by a man in the middle.

Historically, HTTPS was used on eCommerce stores and other sites that receive or transmit sensitive data. In the last few years, Google and security experts have encouraged much wider adoption, arguing that every site should be protected by HTTPS.

Chrome will now display warnings for every page that is not loaded over an HTTPS connection. That’s important for sites that don’t use HTTPS because most users are unlikely to understand exactly what is insecure about them.

The History Of Google’s Push For HTTPS Everywhere

Google has been gradually moving Chrome in this direction for the last several years. Pages were once marked as secure if they used HTTPS. Pages that didn’t were displayed with no message. Last year, Chrome began to display warnings on HTTP sites when the browser was in incognito mode or when the user was asked to enter information. From this month, Chrome will display a “secure” notice for HTTPS pages and an “insecure” notice for HTTP pages.

In September, Google will go a step further and remove the “secure” notification for HTTPS sites. And in October the warning on HTTP pages will change from a neutral color to a noticeable red.

In addition to encouraging sites by warning users in the browser, Google also gives sites with HTTPS a boost in search engine results. All else being equal, a page delivered over an HTTPS connection will rank higher than an HTTP page.

The State Of HTTPS

HTTPS adoption has skyrocketed in recent years. Eighty-four percent of sites loaded by Google Chrome use HTTPS. So do 83 of the top-100 sites. But a large number of smaller sites do not have an SSL certificate and they are likely to be hardest hit by the new warnings.

HTTPS is a good thing. It keeps users and hosting clients safe. Adding an SSL certificate to a site was once complex and expensive. That’s no longer the case. At Hostdedi, many of our WordPress, WooCommerce, and Magento hosting accounts include a free standard SSL certificate and we’re happy to help eCommerce retailers and site owners add a premium or extended validation SSL certificate to their site.

It’s likely that SSL will become ubiquitous in the near future. HTTPS is required by modern web technology like HTTP2 and Service Workers, which are the foundation of Progressive Web Apps. Magento is working on PWA solutions for eCommerce and developers have just started work on a feature plugin that will make WordPress and WooCommerce PWA-friendly.

If you would like more information about implementing SSL on your website or eCommerce store, our support team is waiting to hear from you.

Posted in:
Security

Source link