Configuration Guides
 
Library All Configuration Guides

Common

Customer Create/Edit Receipt Customisation Emailing Receipts Statement Customisation

Purchasing/Stock

Purchase Order Customisation Send Purchase Orders Cabinet Identification Shelf Labels

Sales Processing

Capturing Return Reasons Capturing Courier Tags Payment Types

Infrequent

Using Memberships Creating Agency Stores

Advanced

Using QR Codes Custom User Interfaces Automatic Loading

Setup

Managing Lanes Installing Lanes Network Security Enabling HTTPS Automatic Updates System Backups Securing your Systems
Barcode Scanners Customer Displays Public Product List Scales
Email Accounts Websites
Pre Install Planning Creating a Franchise

Multi Retailer

Auto Setup

Addin Options

Multiple Departments Xero Accounting Stock Sync

Securing your Servers and Systems

Attacks on your infrastructure is a common part of business today. You need to consider how to protect yourself against a variety of attacks. Most of the advice on this page is general in nature and can apply to your entire environment not just Fieldpine applications.

Advice on this page is general in nature. You should engage a security consultant if you have concerns or questions.

Opinion - Designing for Attacks

When designing and considering your security you are basically screwed. No matter how high, strong and robust the walls you put up are, attackers will eventually get in. This does not imply you shouldn't try to protect yourself, rather think if an attacker is inside your network, what can they see and do.

Any vendor that says they are 100% secure should be treated with caution. In recent times high end cloud vendors have been penetrated, enterprise grade firewalls comprimised and attack code distributed by legitimate channels. Some of the attack methods are mind blowingly smart. Often attackers are inside networks for a long time before being detected. Any vendor that claims to be totally secure is probably not aware of being attacked, or simply hasn't been in anyones crosshairs yet.

Try and think along the lines of what you would do if you came to work today and everything was infected and your data leaked from all technology vendors .

I'm using Fieldpine Online (web Pos), aren't I safe?
To some extent yes, but there are still attack channels, especially if you have connections to other systems. Using any cloud solution does not solve security issues, it simply moves the responsibilty to that vendor

I'm using HTTPS/SSL, so I'm safe?
Security certificates only encrypt and protect data in flight across the internet, protecting against interception of those packets. Think of it like all your mail is encrypted, anyone reading your mail in transit is blocked. SSL does not provide any proof of who is using the information.

Some Antivirus vendors also install high level certificates that give them access to some network data. Some networks have intermediate proxy caches. This gets complex fast, but SSL is only part of the answer, not a complete solution.

I don't have any network ports open on my firewall
That's great, but is not complete protection. You can still be attacked by whats called drive by attacks (where legitimate web browsing takes you to attack sites, often without your knowledge) and supply chain attacks where valid programs on your computer pull in attack code in error after being tricked.

Security Quick Primer

There is a lot of discussion and news stories into security. Reports of exploits in the media often sound devistating. The following is a laymans guide to the security landscape

  • The majority of the volume of attacks is driven by what is nicknamed 'script kiddies'. These attackers run programs that exploit known issues trying to get into your system. In general you should be aiming to block all these attackers
  • At the higher end, professional organisations (both criminal and state funded) spend time crafting specific attacks against individual targets. While you are unlikely to be able to afford to protect yourself against these attacks, they are generally focused on larger or attractive players. The tech these organisations create typically filters down to script kiddies in time
  • A zero day attack leverages a way of breaking into systems that has not been seen before. The problem with these attacks is they often bypass existing controls and checks.

Suggested Steps

Internet Router

General steps, not Fieldpine specific

  1. Change the password for the router admin account from the supplied default. Or put one on if it does not have one. You can make this password reasonably long and random. For many stores consider placing this password on a sticker on the router itself so it doesnt get lost. Any attacker physically able to access your router has already broken your security
  2. Consider disabling any 'internet' configuration options that permit you to access the router configuration remotely. Internet providers sometimes have an alternative channel into your router and are not typically impacted by this being disabled.
  3. If you router offers a seperate "guest" network mode, consider using this for staff accesss from personal devices rather than joining your store WiFi freely. Allowing them into your network basically means you need to consider their device security as well.

PosGreen and PosService

  1. Ensure that users running PosGreen do not have administrator rights. For 99% of retailers the Pos does not require admin rights (except for support purposes)
  2. If you are running PosService, consider moving this run under an account other than Local Admin. Like PosGreen it does not strictly require admin rights. If you change the account used for PosService, you need to change Gds/GlobalData to use the same account if present on the same computer.

    Technically, Fieldpine register names in the "Global" namespace so that applications can share resources. The programs will fall back to "Local" if global is unavailable, but this means all users must be within the same namespace.

  3. Inside stores, consider using a different physical computer for 'day to day use' such as email, web browsing etc rather than using the computer that runs Fieldpine.

Opening Firewalls Ports for inbound traffic

  1. If possible, we suggest using a Cloudflare tunnel to provide inbound access as this hides your origin IP address. Can you open the tunnel at certain times only? Is access really needed at 4am on a Sunday?
  2. Do NOT operate your ports without any form of security. Have a username/password as a minimum.
  3. Tie your inbound requests to specific IP addresses if possible, although this isnt always practical and may need ongoing adjustment
  4. Enable Geo based restrictions to block requests from non approved countries. If you are located in Portugal, do you need to allow connections from users in North or South America?

    FYI, the top 5 countries attacking fieldpine servers (in alphabetical order) are:

    • China
    • Netherlands
    • Russia
    • Ukraine
    • United States

Data Considerations

  1. If you are interfacing to other systems they often want to receive "all customers" as an extract. Think carefully about this, while easier for software developers you just increased your attack surface (number of places you can be attacked) and added another supplier.

    • Do they really need "all"? Would last 3 months be sufficient?
    • Do they need all columns of data? Fieldpine can hold a wide variety of details, you should only provide information they have a valid need to access; which is often a tenet of many privacy laws as well
    • Fieldpine applications include some advanced controls that might not be present in other supplier systems. For example, we place velocity controls on some API calls to constrain data flow

  2. Do your own backups. Even if using Cloud solutions. If you are using NAS (network storage), periodically take backups to devices that are not network connected. Ransomware attackers have been known to corrupt backups for a period of time before locking you out.
  3. Do NOT store credit card information inside Fieldpine. We do not provide fields to hold this data as it requires higher levels of PCI/DSS compliance. If you do need to store information like this consider breaking it into 2 or more pieces; store half in one place and the other half somewhere else such as a locked notebook, then attackers need access to both halfs. (agreed, one half is still useful, but less useful than everything)