One problem with the small office or colo environment is there are very few affordable solutions that can be used to monitor for authorized and unauthorized access.  To solve this problem, ZZ Servers has implemented a cabinet monitoring solution that is able to not only monitor for cabinet door entry but also has the ability to have temperature and humidity sensors (which we do not actually do in this initial proof of concept).

The cabinet door alarm is based on a teensy 2.0 USB device that uses digital inputs to determine if magnetic alarm door switches are open or closed and then monitor their status with any standard monitoring system through a USB connection to the Teensy device. The teensy can be ordered from PJRC for $16. The LED, Resistor and remaining components can be purchased from Jameco, Amazon, Home Depot, Radio Shack or any other similar store.

The teensy is connected through USB to a linux server in the cabinet that runs an application to query the status of each sensor. The teensy provides a +5V pin that will be connected to a 10k ohm resistor which is then connected to the GND with one connection to each of 4 input pins for the door sensor and an LED connected to interface 11.

The current design is for only 4 alarm switches; but there is no reason the other inputs can’t be used. If additional inputs are used then the associated firmware and software programs will need to be updated to reflect the number of interfaces.

This design also expects there to be a closed circuit on all monitored ports otherwise an alarm will be raised. A simple closed loop will work for any alarm switches not installed.

Once the circuit is assembled the firmware needs to be uploaded to the teensy. The firmware used is based on the arduino support for Teensy that can be downloaded.  The steps to setup the Teensy/Arduino development environment are found on the page and need to be followed to allow for proper aduino sketch to be built and loaded onto the teensy flash.

• Extract Arduino Software
• Install 49-teensy.rules in /etc/udev/rules.d (see below for contents of this file)
• Download & Run teensy duino installer. Examples/samples are not needed unless doing future development

Once the development tools are installed:

• Start the arduino IDE (found in arduino software extract)
• Connect the teensy usb interface
• Set board type to Teensy 2.0 (Tools/Board/Teensy 2.0)
• Load the code (below)
• Verify (checkbox in IDE) the code
• Upload (right arrow in IDE) the HEX firmware

Teensy Firmware:
The firmware has 3 main sections; the Header where the various variables are defined that are used within the program, The setup function which runs when the teensy is powered on (plugged into USB) and then the loop which is executed after setup executing the designed function.

When the teensy boots, it load the setup function which initializes the device allowing for INPUT_PULLUP functionality for the 4 pins used for the alarm. This creates the alert when the switch is opened. The setup then initializes the USB serial device at 38400 8n1 and configures the LED output PIN and makes sure the LED is off.

The loop function is the core of the firmware. This is the function that the teensy executes over and over. In this function the first thing to do is read each of the alarm interfaces and if there is an alert flag it so we can be sure to blink the LED. Next the loop will see if there are any requests on the serial port, which will come from the serial program further down in this post. If there is input from the serial interface, the loop confirms it is a valid request [1,2,3,4] and then prints back on the serial interface a simple message showing the status of the serial ports.

Finally the loop ends by running the BlinkLED function if there is an alarm otherwise if the LED is on be sure to turn it off.

The BlinkLED function works by using a nice variable type provided by the Teensy “elapsedMillis” which creates a timer that is used to trace the time since the variable was created. Using this variable if it has been one second (1000ms) then reset the timer and if the LED is on turn it off, otherwise turn it on.
zz_alarm0.ino

// Header Section
int ledPin =  11;
int ledon = 0;
int ALARM_1 = 1;
int ALERT_1 = 0;
int ALARM_2 = 2;
int ALERT_2 = 0;
int ALARM_3 = 3;
int ALERT_3 = 0;
int ALARM_4 = 4;
int ALERT_4 = 0;
int alarmnow = 0;
char alarmcheck = ' ';
elapsedMillis sinceAlarm;
//End Header Section

// The setup() method runs once, when the sketch starts
void setup()   {
     pinMode(ALARM_1, INPUT_PULLUP);
     pinMode(ALARM_2, INPUT_PULLUP);
     pinMode(ALARM_3, INPUT_PULLUP);
     pinMode(ALARM_4, INPUT_PULLUP);
     Serial.begin(38400);
     pinMode(ledPin, OUTPUT);
     digitalWrite(ledPin, LOW);
}

// the loop() method runs over and over again, checking for events
void loop()   {
     alarmnow = 0;
     alarmcheck = ' ';

     ALERT_1 = digitalRead(ALARM_1);
     ALERT_2 = digitalRead(ALARM_2);
     ALERT_3 = digitalRead(ALARM_3);
     ALERT_4 = digitalRead(ALARM_4);

     if (ALERT_1 || ALERT_2 || ALERT_3 || ALERT_4) {
          alarmnow = 1;
     }

     if (Serial.available()) {
          alarmcheck = Serial.read();
     }

     switch (alarmcheck) {
          case '1':
               if (ALERT_1) {
                    Serial.println("1:1");
               } else {
                    Serial.println("1:0");
               }
               break;
          case '2':
               if (ALERT_2) {
                    Serial.println("2:1");
               } else {
                    Serial.println("2:0");
               }
               break;
          case '3':
               if (ALERT_3) {
                    Serial.println("3:1");
               } else {
                    Serial.println("3:0");
               }
               break;
          case '4':
               if (ALERT_4) {
                    Serial.println("4:1");
               } else {
                    Serial.println("4:0");
               }
               break;
          case ' ':
               break;
          default:
               Serial.println("X:1");
               break;
     }

     if (alarmnow) {
          BlinkLED();
     } else if (ledon) {
          digitalWrite(ledPin, LOW);
     }
}

void BlinkLED() {
     if (sinceAlarm >= 1000) {
          sinceAlarm = sinceAlarm - 1000;
          if (ledon) {
               ledon = 0;
               digitalWrite(ledPin, LOW);
          } else {
               ledon = 1;
               digitalWrite(ledPin, HIGH);
          }
     }
}

Once the firmware is loaded onto the teensy and all the switches are in place the linux system that will interface with the alarm needs to have a udev rule created that will allow the usbSerial interface to function.
Linux UDEV rules
/etc/udev/rules/49-teensy.rules

SUBSYSTEMS==”usb”, ATTRS{idVendor}==”16c0″, ATTRS{idProduct}==”04[789]?”, MODE:=”0666″ KERNEL==”ttyACM*”, ATTRS{idVendor}==”16c0″, ATTRS{idProduct}==”04[789]?”, SYMLINK+=”ttyUSB00%n”, MODE:=”0666″, ENV{ID_MM_DEVICE_IGNORE}=”1″

The host that connects to the ZZ-Teensy-Alarm needs to be able to query to the teensy on the USB Serial device to determine the status of any of the configured alarm switch inputs.  This is accomplished using a C program that will open the USB serial device presented by the teensy and write/read to the running firmware queries on port status.

The alarm-monitor application is a very simple C application. After initializing some variables it performs a quick check on the number of command line arguments, providing help and exiting if it is not correct. Next the application confirms that the query provided on the command line is a valid interface to query. Alarm-monitor then initializes the specified serial device to 38400 8n1 and writes out the query to the teensy serial device. Once the query is written the application will wait for a response for 10 seconds after which the appropriate response is sent back to the user.
Linux Command line zz-teensy-alarm query:
alarm-monitor.c

#include <string.h>
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <termios.h>
#include <time.h>
 
int main(int argc,char** argv)
{
        struct termios tio;
        struct termios stdio;
        time_t start,now;
        int diff;
        int tty_fd;
        fd_set rdset;
        struct flock fl;
 
        unsigned char c=' ';
 
        if (argc<3) {
          printf("%s /dev/ttyUSB000 [1|2|3|4]\n\n",argv[0]);
          exit(1);
        }
 
        switch (argv[2][0]) {
          case '1':
            break;
          case '2':
            break;
          case '3':
            break;
          case '4':
            break;
          default:
            printf("Can only query alarms 1, 2, 3 or 4\n\n");
            exit(1);
            break;
        }

        fl.l_type   = F_WRLCK;  /* F_RDLCK, F_WRLCK, F_UNLCK    */
        fl.l_whence = SEEK_SET; /* SEEK_SET, SEEK_CUR, SEEK_END */
        fl.l_start  = 0;        /* Offset from l_whence         */
        fl.l_len    = 0;        /* length, 0 = to EOF           */
        fl.l_pid    = getpid(); /* our PID                      */

        tty_fd=open(argv[1], O_RDWR | O_NONBLOCK);
        fcntl(tty_fd, F_SETLKW, &fl);

        memset(&tio,0,sizeof(tio));
        tio.c_iflag=0;
        tio.c_oflag=0;
        // 8n1, see termios.h for more information
        tio.c_cflag=CS8|CREAD|CLOCAL;           
        tio.c_lflag=0;
        tio.c_cc[VMIN]=1;
        tio.c_cc[VTIME]=5;
 
        cfsetospeed(&tio,B38400);            
        cfsetispeed(&tio,B38400);           
 
        tcsetattr(tty_fd,TCSANOW,&tio);
  
        write(tty_fd,argv[2],1);

        start = time(NULL);
        now = time(NULL);
        diff = (int)difftime(now,start);
        while ((c != '\n') && (diff < 10)) {
          if (read(tty_fd,&c,1)>0) {
            write(STDOUT_FILENO,&c,1);
          }
          now = time(NULL);
          diff = (int)difftime(now,start);
        }

        fl.l_type   = F_UNLCK;
        fcntl(tty_fd, F_SETLK, &fl);
        close(tty_fd);

        if (diff >= 10) {
          printf("X:X\n");
          exit(1);
        }
        exit(0);
}

The alarm_monitor application can be compiled with gcc:

gcc -o alarm_monitor alarm_monitor.c

alarm_monitor has 2 inputs, the first is the USB device of the ZZ-Teensy-Alarm, the 2nd is the port to be queried (1-4 is hard coded, any additional ports need to be expanded on for alarm_monitor.c and zz_alarm0.ino).

EX:

alarm_monitor /dev/ttyUSB000 1
1:0

Would query alarm switch 1 and as this example shows returns the alarm #:status where 0 is OK and 1 is switch open (alarm).

There is a 10 second timeout if ZZ-Teensy-Alarm device isn’t connected or if there are connectivity issues.  An error code of X:X is returned for any timeout and any query to ports other than 1,2,3,4 return invalid query.

Concept Assembly

The initial design was built using a breadboard and is pictured below:

ZZ Servers Teensy Cabinet Alarm Prototype

Once the design was tested a standard radio shack project box was acquired along with a few screw down termination jacks.  These were assembled into the following picture

ZZ Cabinet Alarm Prototype - Assembly

ZZ Cabinet Alarm Prototype - Assembly

The final configuration has the usb cable coming out one side, an led on one side and the screw on terminators ready to be connected to magnetic door switches.

ZZ Cabinet Alarm Prototype - Assembled

ZZ Cabinet Alarm Prototype - LED on

Zabbix Integration

Once the alarm is in place it needs to be monitored. Here at ZZ Servers we leverage Zabbix but any system such as Nagios could work as long as they can execute a script for input.

Zabbix monitoring can monitor the status of each door alarm through the configuration of UserParameters.  A full configuration will follow in a future post with templates for items / alerts but for now below is a sample UserParameter for each of the 4 configured alarm monitors:

/etc/zabbix/zabbix_agentd.conf

UserParameter=CB001.0001F,/usr/local/bin/alarm-monitor /dev/ttyUSB000 1|cut -d”:” -f 2
UserParameter=CB001.0001B,/usr/local/bin/alarm-monitor /dev/ttyUSB000 2|cut -d”:” -f 2
UserParameter=CB001.0002F,/usr/local/bin/alarm-monitor /dev/ttyUSB000 3|cut -d”:” -f 2
UserParameter=CB001.0002B,/usr/local/bin/alarm-monitor /dev/ttyUSB000 4|cut -d”:” -f 2

Details on how to configure the zabbix template including the appropriate items, triggers and alerts will be posted in my next blog post.

In the past, it was though Linux servers were safe from viruses but recently hackers have been taking advantage of this false sense of security. Some researchers point out that 70% of attacks on Linux honeypots were infected with a 6 year old virus (RST-B)* and used as command and control points for botnets.

ZZ Servers now offers affordable F-Prot anti-virus software for Windows, Linux, Exchange, BSD and Solaris. Protect your servers, desktops and critical infrastructure today. Contact ZZ Servers at 800-796-3574 or email support@zzservers.com to arrange for installation of anti-virus software today.

*RST-B is a backdoor malware runs on Linux/UNIX platforms and infects ELF files in the current and /bin directories. This Linux backdoor and virus compromises system security by allowing remote users to manipulate and access infected machines. If executed as root, it will start processes listening on two network interfaces which provide a remote root shell.

I was able to spend a good 1/2 an hour with the now new customer and help them understand how our approach meets the intent of PCI and is not focused only on trying to “make the sale.”  However, for those that we do not know what questions to ask of a hosting provider I have started a new project where I will be “shopping” for a new hosting provider and will post the communications I have with them, along with some additional comments on what their answers would mean to me if I was in my QSA role evaluating their solutions.  I will keep the communications anonymous to prevent any liability issues, but feel free to use any of the questions or comments I have when discussing hosting solutions with any providers you may be examining; and feel free to use my questions against us when you call and ask about PCI or Compliant based hosting with ZZ Servers.

With that in mind, here is the first discussion with a decent data-center with multiple data-centers fully owned and operated by their staff in the northern midwest.  I have highlighted items that caused me to be concerned about their understanding of PCI and what it takes for merchants or service providers to be hosted with managed PCI solutions.  Please note, anyone can take a rack of hardware and managed / deploy it in a compliant manor.  But that is not what these hosting providers are selling.  They are selling compliant solutions, leading customers who do not fully undersand the requirements to think they are meeting all of the requirements.

***Chat Information*You are now chatting with ‘Paul’
*Paul: *Greetings, my name is Paul. Welcome to <HOSTING PROVIDER> Sales. With
whom am I speaking? How may I be of assistance?
*you: *Hello, i saw your VPS servers have a $50/mo PCI certification?
what does that provide? Does that mean i’ll be compliant? do i need
anything else? does that include my scanning, pen test,
internal/external? log monitoring?
*you: *hello?
*Paul: *Hello, sorry about that
*Paul: *the PCI certification will include all scans for your server to
be entirely compliant
– This is common, many people belive that if you get your ASV scanning & answer questionairre you are compliant..if it was only that simple
*you: *so it is only the scans?
*you: *not the rest of the compliance needs?
*you: *internal & external scans then?
*Paul: *it covers all services needed
*you: *external logging/monitoring, firewalls, IDS, 2 factor remote
access, pen-testing (internal/eternal), asv scanning & internal scanning
(& other stuff i can’t remember atm)??
*Paul: *Yes, it is the complete service
– how can he say it’s scanning, then a complete service? At this point I really believe the sales guy does not know what he is selling
*you: *applicatoin & network penetration testing? how do you have that
for $50/mo? the best quote I have from a professional pen-testing
company is 5000/year
*Paul: *let me double check
*Paul: *yes, it does, I have confirmed
– confirmed? if you can’t tell by now that I am asking questions above his knowledge level; why not conference in someone who knows the answer..
– Many hosting providers want you to email or fill in a form so they can manage their response, if they can’t answer your quetions at all hours
– then are you sure they can manage your compliance needs at any hour?? Get them to bring the expert on the phone while you are asking questions!
*you: *interesting, do you have a detailed whitepaper or pdf on the
complete services offereed?
*you: *and i assume i’ll have to get more than 1 server
*Paul: *No, you can have PCIC with one server
– big big red flag!! If you are only using paypal/google for payments then yes this is right but if you are not then the requirement for “single use” is pretty important
*you: *and that includes firewalls too right? do i have a dedicated
rfc1918 address space?
*you: *you can?
*you: *how do you satisfy the “single purpose” requirement?
*you: *where a server can not be a web & database server
*Paul: *we do not require a cluster for pcic
– I wasn’t asking about a cluster. This is a typical issue, the sales team is use to selling hosting of servers but does not understand PCI. I guess they have not had
– any PCI training (which you merchants & service providers are required to have annually)
*you: *you do not, but PCI requires that
*you: *pci has something somewhere that requires each server have a
single function
*you: *do you have any documentation? or details about what is included
in your PCI services?
*Paul: *I do not have a detailed outline, but I know these are the
standards we follow
– Another warning…PCI is documentation heavy, if they do not have documentation, have they really done all thats required?
*Paul:
*https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml
*you: *yes i am familiar with that
*you: *our QSA has ingrained tht into us
*you: *i was just curious because some of your answers do not jibe with
what the PCI-DSS requires
*you: *ok i think i have enough for now; thank you for your time
*you: *Have a great night..oh one last question; where are your
data-centers located?
*Paul: *My pleasure, they are in <LOCATION>
*you: *any other geographic areas?
*Paul: *they are all located in <ONE LOCATION>
*you: *thank you have a great night
*you: *oh one other questoin
*you: *what technology do you use for your remote 2 factor auth & vpn
technology?
*you: *rsa/certificates/?
*Paul: *The only vendors I have info on at the moment are control scan,
security metrics, trustkeeper, and clone systems
*you: *so it’s not included w/the pci service?
*you: *it’s a 3rd party vendor we have to engage?
*Paul: *Send me an email to <SALES-EMAIL> and I will find out for sure
– Remember earlier they said it included all required services? Again, lack of documentation & training lead me to think they just do not know what the requirements are or what they are selling
*you: *ok thank you, have a great night/morning

One such example would be Amazon EC2.  In a recent discussion at amazonwebservices.com forum and slashdot.org users were discussing a desire to move to Amazon EC2 and maintain PCI compliance.  While not surprising, at least there was a concrete answer to were Amazon stands with regards to its role in its customer’s compliance.  In an email from Taimur Rashid, an account manager at Amazon Web Services, he states “We do not and will not provide a written agreement attesting compliance and assuming responsibility for cardholder data.”

PCI requires all merchants maintain a written agreement between the merchant and service provider that outlines responsibility for cardholder data.  “Requirement 12.8.2 Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess.” Without this simple agreement, you cannot be compliant.

In addition to not allowing a written agreement, Amazon also will not allow on site audits required for Level 1 and now Level 2 merchants.  Cindy S from Amazon Web Services states “If you have a data breach, you automatically need to become level 1 compliant which requires on-site auditing; that is something we cannot extend to our customers.”

Based on the 2 statements above, Amazon EC2/S3 is currently not capable of providing the level of service required for PCI compliance on any level.  If you are a merchant and require PCI compliance, avoid the cloud and find a reputable service provider which specializes in PCI compliance such as GSI, Rackspace or ZZ Servers.

Merchant levels and Compliance Validation Requirements

Merchant Types

The “SAQ” is a self-validation tool for merchants and service providers who are not required to do on-site assessments for PCI DSS compliance. The SAQ includes a series of yes-or-no questions for compliance. If an answer is no, the organization must state the future remediation date and associated actions. In order to align more closely with merchants and their compliance validation process, the SAQ was revised and now allows for flexibility based on the complexity of a particular merchant’s or service provider’s business situation (see chart below). The SAQ validation type does not correlate to the merchant classification or risk level.

Service Provider Levels

Service providers are organizations that process, store, or transmit cardholder data on behalf of clients, merchants, or other service providers. Service provider levels are defined as:

By using the charts above, you should be able to easily determine your level and validation type. Knowing this details will go a long way in guiding you through your compliance but it is important to partner with other qualified businesses for your service. ZZ Servers provides PCI focused hosted infrastructure designed for PCI compliance and includes many of controls and measures required for your business infrastructure to be fully compliant.

This breech at Batteries.com shows that a merchant does not need to be large like Heartland to be targeted by hackers.

For more information regarding this breech, visit the Batteries.com security and fraud prevention page.

Many on-line fax services send received faxes by unencrypted email with cleartext (TIFF/JPG or PDF) attachments which are not PCI compliant. One reason for this is PCI clearly states that credit card numbers are not to be emailed in clear-text, they must be encrypted. A fax converted to PDF & emailed is not encrypted and if done that way then both the service provider and the receiver are non-compliant.  During an audit you can’t say you didn’t know, you signed up for the service knowing you were going to receive card numbers.

So, how do you receive credit card payments by fax? The first step is get a phone line w/a $50 fax machine from your local office supplier and come up with a security policy for how to secure the fax machine and incoming faxes. This is cheaper and easier to deal with than trying to make some digital systems PCI compliant. The fax needs to be classified as confidential and handled how your data retention policy dictates, assuming your retention policy is PCI compliant. An example would be a secured fax machine in accounting or other area set aside for receiving secure faxes. Additionally faxes containing credit card numbers need to be stored or archived properly and when disposed of, it needs to again follow your data retention policy and be securely destroyed (cross cut / incinerate, whatever:).

If your company is receiving card data on behalf of your customers, you are liable for all the paths it takes to get to you. Claiming you didn’t know or that it’s out of your hands is not enough when there are secure solutions. Don’t use a fax service unless they can send encrypted emails and securely purge the fax data when sent; otherwise get a real fax machine & secure it and instruct those who have access what it may contain and how to handle it appropriately, and yes training for your employees is a PCI requirement.

In the end, you will find a phone line with $50 fax from your local office supplier is cheaper and easier to deal with than trying to make some digital systems PCI compliant.

One of the largest and possibly most hard hitting change is how the the certification process is placing an increasing amount of scrutiny on level 3 and 4 merchants. If you process credit cards and have not received any notification from your merchant bank regarding PCI DSS compliance, you will soon.

I will not attempt to cover all of the details of the new standard but will say if your company handles any cardholder data, it is important to get your infrastructure into compliance with PCI DSS.

PCI DSS 1.2 specifies 12 requirements for compliance, organized into 6 logically related groups, which are called “control objectives.”

The control objectives and their requirements are:

• Build and Maintain a Secure Network
  1. Requirement 1: Install and maintain a firewall configuration to protect cardholder data
  2. Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
• Protect Cardholder Data
  1. Requirement 3: Protect stored cardholder data
  2. Requirement 4: Encrypt transmission of cardholder data across open, public networks
• Maintain a Vulnerability Management Program
  1. Requirement 5: Use and regularly update anti-virus software
  2. Requirement 6: Develop and maintain secure systems and applications
• Implement Strong Access Control Measures
  1. Requirement 7: Restrict access to cardholder data by business need-to-know
  2. Requirement 8: Assign a unique ID to each person with computer access
  3. Requirement 9: Restrict physical access to cardholder data
• Regularly Monitor and Test Networks
  1. Requirement 10: Track and monitor all access to network resources and cardholder data
  2. Requirement 11: Regularly test security systems and processes
• Maintain an Information Security Policy
  1. Requirement 12: Maintain a policy that addresses information security

Each control objective contains additional details on what is required to meet the objective and requires a detailed study to fully understand them and their impact on your existing infrastructure. Smaller companies have the option to use a self-certification questionnaire but even this can be difficult and time consuming.

ZZ Servers has fully qualified security assessors and partnerships with PCI ASV/QSA’s for all levels PCI certification, required security scans and full level 1 PCI audit validation. Contact us today so we can can assist with your adaption of PCI DSS in your environment and ensure your full compliance with these comprehensive regulations. Let us help you prepare and prevent the damaging costs of a data breach.

Peter Zendzian
Managing Partner
ZZ Servers, LLC
www.zzservers.com
800-796-3574

One of the most valuable commodities in this day and age is your own personal information. The more we make purchases over the Internet or over the phone, in other words: not in person, the more important that information becomes.

However, as security breaches receive more coverage and are more well known to the public, trust in the current security measures is coming into question, and the need for stronger security and standardized tools and controls became necessary.

Enter the PCI DSS, or Payment Card Industry Data Security Standard. This was created by the five major credit card companies as a guideline to help merchants and other companies implement the necessary hardware, software, and other procedures to guard sensitive credit card and personal information.

The encouragement to achieve PCI compliance comes in a couple different forms: benefits and mandates. The mandates are the requirements of PCI compliance, and attached to them are some very strict and specific penalties. These could include fines as high as $500,000 per incident, and the loss of the ability to accept credit cards at all.

On the other hand, there are a number of PCI compliance benefits that should be as much of an incentive, if not more so, than the penalties. It merely requires a proactive understanding of the long term benefits of compliance. Some of these benefits, you will find, are somewhat more intangible than others, but that doesn’t make them any less valuable.

The first and most obvious benefit of PCI compliance is a simple matter of trust. What if your company was the one that recently suffered a major security breach? What if you had to live with the stigma of “the company that lost thousands of credit card number”? Could you ever live it down? Could you survive the fallout?

A giant company may be able to weather the storm (as has been seen in some recent cases), but most companies need to focus on building lasting trust from the beginning. Being PCI compliant can help you achieve this.

More tangibly, merchants who are PCI compliant are offered protection from the fines if you should happen to be breached. If you are compliant at the time you suffer an attack, you can have a sort of safe harbor.

At the moment, these “carrots and sticks”, or mandates and benefits, are assumed to be enough to encourage merchants to gain PCI compliance. But if it turns out, in fact, to not be enough, the PCI Security Standards Council will likely change the measures of encouragement. The reason for these measures is that trust is the only thing that will propel the online industry forward. If customers lose their trust in the system, they will find alternate methods to do business.

It is a difficult thing in the naturally competitive environment of online business to consider something as nebulous as “the greater good”, but in a world where personal information is so valuable, creating an environment where that information is utterly secure should be a top priority.

Andy Eliason is a writer for Main10, Inc. If you’d like to learn more about PCI compliance, or how to become PCI DSS compliant, visit Braintree Payment Solutions today and find out what they have to offer.