SXSW Interactive is a “must attend” event for developers, designers, web marketers, and anyone else who does business online. Last year, almost 40,000 registered to attend, and 2011 is projected to be even bigger. The schedule reveals numerous opportunities for attendees to interact with the brightest minds in emerging technology. Networking events. Speaking events. Live music. A tradeshow. SXSW covers the whole gamut.

FireHost is vying for a speaker placement, and we need your help getting picked. If you’re planning to attend SXSW and have concerns about the security and integrity of your personal or corporate identity online, cast your vote for our presentation at Panelpicker.sxsw.com.

Our proposed topic answers the questions:

1. How is the security landscape changing online?
2. Is building a corporate blog on  and open source platform like WordPress safe?
3. How could some of the devastating hacks like TechCrunch have been avoided?
4. How do I find security vulnerabilities in my web application?
5. What role does secure web hosting play in keeping my site safe?
6. What are the most common developer mistakes that lead to cybercrime in open source?

Read the full synopsis and cast your vote at Panelpicker.sxsw.com.

We’ll see you in Austin.

Right away, many business owners, designers/developers, and IT professionals “got it” and signed up on the spot. We enjoy providing exemplary protection for our early adopters, but we won’t rest until the entire web hosting community understands that security, scalability, and affordability is for everyone, not just a select few.

Overall, the mission has been well received. As any “pioneer” would expect however, Secure Servers have been met with mixed reviews, particularly from die-hard dedicated hosting proponents.

In an effort admonish any remaining doubt from those who still have reservations about this new way, we created NoMoreDedicated.com. From here, you can:

• Watch real stories from real people told in their own words and decide if dedicated hosting is the best solution.
• Take our short, informative test to determine if dedicated hosting is right for your hosting needs.

Once you see the facts, we’re confident you’ll want to give Secure Servers a try, so we make it easy to do so.

• Secure Servers can be provisioning within 24 hours of validating  your order, and
• There is no lengthy hosting contract to which you must subscribe.

If you still have reservations, that’s fine. We respect your opinion and any doubts you may have about adopting a new way to protect your business. Even if you’re not ready to join the movement full stop like @The_Fenix_X, we request that you follow the movement that’s putting an end to overpriced, insecure, and inflexible dedicated hosting. Big change is on the horizon.

Follow: @NoMoreDedicated HashTag: #NMD

We encountered very cool technology and some impressive talent from around the world. We’re glad to have participated at the Silver Sponsor level because it gave us a chance to interact with most all of the attendees and participants on some level. Here are the highlights from the show:

• We met with several companies who are pioneering processes to ingest, analyze, and regurgitate quality information from TB’s of raw data stored remotely. Learning about these truly impressive database analytics projects helped us realize that significant change is on the horizon for advertising and medical industries.
• Jon Johns at O’Reilly invested a generous amount of time interacting with us. He helped shed light on the sense of purpose and spirit that embodies the open-source community. He’s a very passionate individual and really helped us embrace the foundational idea of open source – doing something as an individual or team that can change the world in degrees.
• We met a 12-year old webmaster.  How cool is that?
• Our booth looked GREAT. Our marketing team did a bang up job on the graphics and messaging.
• Our schwag (custom printed toilet paper and casino-quality playing cards) produced a reaction, and what more could you ask from inanimate objects?

Overall, it was a fun and rewarding show. The FireHost crew stayed insanely busy, but at the end of the day, we’d do OSCON again.

Last week, several members of the FireHost team made the long, arduous trip from Dallas to Austin for HostingCon 2010. Here’s the insiders perspective on the “who” and “what” from the event this year.

Meeting up with industry friends and partners was certainly the overall highlight of HostingCon 2010. Interfacing with our peers, competitors, and service providers was a great reminder of how many truly awesome people and companies exist in the hosting industry.

For Fun

The Planet‘s booth provided a very entertaining “assemble a Dell server as fast as you can” challenge. The whole spectacle got quite a bit of attention, and our very own Chris Hinkley was the fourth fastest assembler on the final day of the event. (Unfortunately, only 1st-3rd place received a prize, so the accomplishment will only live on in his mind.)

The Trustwave booth’s theme for 2010 was “Knock Out High Prices”. Cool concept, and they actually had a boxing ring setup where attendees could hop in the ring and punch a guy with a “high prices” t-shirt. It drew a lot of attention, but very few people were brave enough to hop in to take a swing. So on the last day, Trustwave brought in some semi-pro wrestlers to help drive the message home.

On a More Serious Note

Security topics dominated many of the sessions and discussions. As well, “the cloud” in general was a hot topic. It seems industry-wide, multiple definitions of “cloud” exist, and compared to last year, even more interpretations have come to light. That’s somewhat counter intuitive since you’d expect a more concise explanation would emerge over time.

Collectively, our team walked away confident that FireHost is leading the secure web hosting pack, and we have a “golden opportunity” to help real businesses solve compliance challenges and achieve a higher level of security in general. We’re excited to be pioneering an affordable, scalable secure hosting solution for companies of all sizes.

All-in-all, HostingCon 2010 was a fantastic event. The relationships, the knowledge, the partnerships, the industry insight, and even the time spent “car pooling” was a valuable opportunity for team building.

See you in San Diego!

The process of determining how to commemorate this grand occasion was… entertaining (at least to us). So for your amusement, here are some of the ideas that didn’t make the cut:

• We could reveal our secret Secure Server sauce.
• We could raffle deprecated hardware for charity.
• We could post pictures from the company picnic.
• We could post pictures from AFTER the company picnic.
• We could give our semi-professional review of Inception.
• We could post high school yearbook pictures of our CEO.
• We could discuss the weather in Texas and Arizona. (It’s hot. End of discussion.)
• We could TP our competition with #NMD toilet paper, and post the photos.

We considered all of these (bad) ideas (and more), but in the end we determined the best use of this space might be creating a concise recap of all the other mediums by which our loyal blog readers can stay updated about FireHost’s initiatives, news, services, strides, and successes in the Secure Web Hosting marketplace.

On the Web

• FireHost Website
• NoMoreDedicated Website
• Revolution Blog by Chris Drake

In the News

• FireHost Newsroom

In Social Media

• Twitter.com/FireHost
• Twitter.com/NoMoreDedicated
• Facebook

For Support

• MyFireHost Customer Portal
• Knowledge Base

We invite you to explore each outlet and hope you can use and appreciate each one for it’s intended purpose. Please feel free to reach out to us via any medium any time the urge strikes.

In a recent interview, founders Jay Osterholt and Jeff Moore talked with WCPO-TV in Cincinnati about My Child’s Locket’s capabilities and the role Secure Web Hosting plays in protecting their clients’ identities.

We’re so proud to be protecting this and other businesses who need shelter from malicious hacker activity. Thanks for the trust.

The mandates for protecting cardholder data at rest seem rather straight forward, but taking them at face value could be a mistake. Many factors about your company’s or your client’s business determine how this requirement is followed.

3.1 – Store Only Necessary Cardholder Data; Store Cardholder for the Minimum Time Possible

Section 3.1 says to store only necessary cardholder data and to store it for the minimum time possible. Data storage requirements may vary depending upon the nature of your company’s or client’s business. For example, businesses that provide single use products, or a service offering that is only likely to be used one time should probably not store cardholder data at all, or at most for a very short period.

On the other hand, subscription- or recurring billing-based businesses are on the rise. Invoicing and charging customers “automatically” every month has become a common reality for millions of software as a service (SaaS) companies today. When you have repeat customers, the idea of having your customers resubmit payment details on a regular basis is not just inconvenient, it’s inconceivable. Therefore, businesses that cater to repeat customers have some special considerations to address, and because of the retention schedule, these companies go beyond the provisions of the standard to protect cardholder data when possible.

In either scenario, your company must develop and enforce a PAN disposal policy containing:
- A definition of what data is being stored;
- A definition of the time period for which this data is stored;
- A procedure for disposing of data after that time period has expired.

3.2 – Do Not Store Authentication Data

Since we primarily handle transactions online, PCI DSS provisions 3.2.1 and 3.2.3, which deal with magnetic stripe data and PIN numbers, are less applicable to web application developers. However, storing card validation codes (also known as card verification values, or CVV) is also prohibited by this subset of requirement 3, and to that detail we must pay close attention.

Your merchant account provider may give you favorable rates if the CVV number is provided in a transaction. Therefore, many companies make the business decision to retrieve this number from customers submitting orders online. In reality, you’re merely using the number as it was intended – for validating card not present purchases.

If your business has subscription-based orders and recurring charges, you’ll need to work with your merchant account provider to determine your options.  For example, it may be possible to use a previous transaction’s payment method ID in lieu of storing and subsequently re-providing it each time the subscription installment is billed.

Portability is another “hot button” that keeps business owners and developers on the fence. Consider these risks:
- What if your payment processor goes out of business?
- What if a current system you use to bill your customers becomes interoperable?
- What if you are presented considerably more favorable rates with another processor?

In either case, the cardholder data must be migrated for business continuity. If you only have access to a masked PAN, expiration date, and reference ID, you’re out of luck and face requesting the payment card details from your customers again. This would be a costly and imperfect process, no doubt.

For these reasons and more, many businesses choose to store the data in its entirety. Just ensure you follow PCI DSS requirements and exceed the provisions when possible.

3.3-3.4 – Render Cardholder Data Useless to Malicious Parties While Upholding Usability Requirements

PAN must be masked. The PCI DSS standard states that the maximum amount of data you can display (either internally without a specific need defined in your security policy, or externally to the customer) is the first six and last four digits of the PAN.

Where possible, use the irreversible hashes in your application or site implementation, allowing you to verify a card number without storing the actual data. Hashes should be based on secure cryptography such as SHA-1 and should use either fixed or dynamic salts (salts are random bits used to improve encryption).

In most cases, this type of data storage is not possible. In cases where storing the cardholder data and maintaining its readability after cryptographic processes is a must it should be stored using encryption similar to what was described in a “Decoding PCI DSS Requirement 6: Develop and Maintain Secure Systems and Applications, a previous article here on Ecommerce Developer.

3.5-3.6 – Securing the Keys to the Castle: Encryption Key Management

The IT department will actively participate in key management, but developers are obviously an integral part of the process since we build, extend, and at the very minimum manage the application(s) that collects, encrypts, and stores PANs. In addition, developers will need to occasionally access the data to troubleshoot, test, or confirm web application integrity. Developers will want to refer to Decoding PCI DSS Requirement 4: Encrypting and Storing Credit Card Data, published previously here, for more information.

Summary

While the third requirement of the PCI DSS standard may seem fairly straightforward, there are also several pitfalls developers and integrators often encounter while engaging PCI compliance. Clearly defining your business’s needs prior to undertaking PCI compliance can be extremely helpful, especially with regards to requirement 3, where the nature of the data defines how business is conducted in an online arena.

A version of this article was published in eCommerce Developer on July 15, 2010.

• that security controls will only be as tight as consumers demand, and
• that things can be different (better) with your help.

We just want to get this “disclaimer” out of the way, here and now in the first paragraph before you have a chance to form an opinion about our suggestions. We’re not condoning the actions or otherwise diminishing the liability of these companies (or any company for that matter) who has caused consumers or businesses time, harm, and any other loss because of a breach and subsequent leak of personally identifiable information (PII). The spirit of this article is to create awareness of the risks and to help everyone reading (consumers and business owners) understand that taking steps toward prevention is a collaborative effort in which consumers and companies alike must embark to see results. And so with that…

Blippy’s Security Blip

Synopsis: Credit card numbers for a limited number of beta users leaked into Google search results.

Blippy’s responsibility: Breaking this down to the most simple terms, Blippy’s dev team should have secluded all test data into a non-production environment. Furthermore, per PCI guidelines for SDLC dictate that all sample data must be purged from all accounts prior to launching the production environment. If you’ve visited the Blippy website or signed up for an account however, you’ll notice that there is no mention of PCI compliance or a PCI compliance badge… anywhere.

That’s because (arguably) Blippy isn’t governed by the payment card industry data security standard since they don’t directly collect or store credit card data. When the data leaked, all fingers pointed at Blippy (and rightfully so, I mean anyone who can read saw the cc numbers available in the statements associated with each user’s account.) The bigger problem however seems to be the fact that the issuing bank or credit card company allowed full, unencrypted, unmasked credit card numbers to be printed and/or stored on public statements.

Personal responsibility: Consider this. Participants in a clinical drug trial assume a large amount of risk by ingesting the pharmaceuticals under investigation. Wouldn’t a similar principle of risk apply when technology users participate in a beta, alpha, or electronic test of any kind?

Perhaps language in the warnings about unregulated pharmaceuticals is more ominous (or the risks more personal) prompting consumers take caution. Should commercial business ventures be more blatant about their warranties and have stronger indemnification policies so early adopters will think twice before signing on?

Consumers must realize that they are “swimming at their own risk” when participating in pre-releases of new, untested technologies. Blippy adopters who confidently linked bank accounts, retail payment card accounts, and credit card accounts to the service can’t be completely shocked when something goes awry with the system. Can they?

Bottom line: It is every business’ responsibility to take all measures possible to prevent problems like this from arising. It’s the consumer’s responsibility to perform due diligence and maintain our confidential information in higher regard and think twice before divulging information that could cause them harm.

(Life)lock Picked

Synopsis: Lifelock was built around the claim that subscribing to their service makes your identity “useless” in the hands of a malicious party. However, in reality, CEO Todd Davis’ identity has been successfully compromised ~13 times according to police records provided by Tempe, AZ PD.

Lifelock’s responsibility: The fact that Lifelock over promised in marketing and undelivered on service is not acceptable (and they’re paying a pretty penny to the FCC for that). Accurately representing your service offering and capabilities is a basic business rule that should not be breached, ever.

However, Mr. Davis published his social security number in million-point font on billboards and trucks and in TV ads, and he broadcast it repeatedly over the airwaves to instill confidence in prospective customers… If only 13 crimes came out of such a blatant misuse of PII (personally identifiable information), Lifelock and the general public should consider their service a success in our opinion. In everything, there is a “margin for error” and Lifelock’s margin seems pretty low.

Personal responsibility: Let’s be realistic. Procuring Lifelock’s service is like installing an alarm on your car or your home. It doesn’t prevent someone from smashing a window and coming it, but it does alert the proper authorities and squelch any wrongdoing as fast as possible. To some people, that peace of mind is worth the $10 fee Lifelock charges monthly.

You personally can not take a back seat to security, and you certainly shouldn’t blindly trust any service’s promise. You must remain a vigilant participant in protecting PII.

Bottom line: Reading their TOS, it doesn’t appear that Lifelock has lengthy contracts or unreasonable cancellation policies, so why is everyone sticking around? It must work. The wrong-doing that happened to Todd Davis suggests Lifelock doesn’t fulfill their service offering, but despite that, they still have a website. They still enroll new subscribers to their identity protection service. They still have an active customer base. So they must be doing SOMETHING right, right?

If the users are satisfied with the service “as is” (and Lifelock reports to have somewhere around 1.2MM subscribers), then the company will likely continue business as usual – at least as long as they can continue to defend their service offering… and keep up with the financial drain of defending their good name. Why? Because when it comes to advocating change for the better, votes from a consumer’s pocketbook are the ones that matter.

Egg on Your Face(book)

Synopsis: Facebook and Privacy have a sordid past. Most recently, the social networking community has made headlines for unauthorized dissemination of user data – phone numbers to be exact.

Facebook’s responsibility: Facebook and any company that handles confidential data is responsible for providing good, tight code and web application development in accordance with PCI’s standards – whether they accept credit cards or not – because PCI is one of the most stringent and specific sets of published guidelines.

Beyond that that, service organizations must provide sufficient warning about changes in privacy settings, opt-out procedures that are reasonably easy to invoke, and easily interpreted disclosures that don’t require a PhD or JD to comprehend.

Personal responsibility: In recent news articles, media and some (we’ll call them) “common sense” advocates like Tom Scott are proposing that consumers who use web based systems have some responsibility for the purported exploitation. Facebook (and many open source social networks in general) get a bad wrap when data “leaks”, but in some cases (this one in particular), it’s because the information was volunteered by users, not because it was stolen by a malicious third party or mishandled by an irresponsible custodian.

Bottom line: The lesson here — don’t let your guard down EVER. If you engage in the web, you’re susceptible to it’s good and bad traits. Again, we’re not sticking up for any trusted entity who leaks PII, we’re simply suggesting that maintaining confidentiality over information you don’t want to be shared is a cooperative responsibility.

Conclusion

Our aim for this article is not to offer a legal perspective or constitutional posture, we simply want to open your eyes to how technology works, who controls it, and how some of these bad situations could have been avoided with “an ounce of prevention” as they say. Social networking should still be considered a “new, fun and hip” trend. Like parkour for example. Anyone who engages in such an extreme hobby is susceptible to risk. If you break your leg hopping from roof to roof, do you (and the media) blame the building owner?

While most of the contents of Requirement 6 are not technically difficult to achieve, maintaining the balance between an eCommerce organization’s business requirements, brand integrity, usability requirements, and security is challenging. It is the responsibility of the development team to weigh the best interests of the organization against its wish list, all while adhering to the best practices and requirements set forth in the PCI DSS standard to protect the organization and its customers.

Requirement 6 affects almost every aspect of the development process, from the planning stage to post-launch maintenance. Some of the provisions of Requirement 6 are very specific in nature and will vary depending on your deployment and development environment, and thus, this article will cover all of the general compliance guidelines.

System Configuration, Maintenance and Security

As with all of the PCI DSS requirements, it is important to consider all of the required accommodations early on and throughout the planning phase. The scope of Requirement 6 reaches beyond code to the configuration of the development and production environments as well as the administration of both.

This includes simple things, such as the requirement in Provision 6.1 that all systems (both production and development servers, as well as all developer workstations) have the latest security patches installed within 30 days of their release (or 90 days if your company’s policy requires roll-out testing); and that all security patches are tested against the vulnerability they fix prior to deployment in a production environment. Provisions 6.3.2-6.3.3 require that production and development environments be completely separate, and that a policy exists to provide a separation of duties, responsibilities and privileges between users with access to either system.

Additionally, specific system vulnerabilities may be addressed in code or as system configuration adjustments. The solution to each will be different for each configuration. Most PCI-certified vulnerability monitoring solutions will provide additional, detailed guidance for each specific instance discovered.

Considerations During Development

Requirement 6.3 and 6.5 are quite vague, but generally encompasses what are already considered best practices amongst developers. The PCI Security Standards Council recommends the Open Web Application Security Project Guide as a reference for community-accepted best practices in the architecture of your solution.

Requirement 6.3.1.1 and 6.5.1-6.5.10 specifically deal with the most common methods by which malicious attempts to compromise an application are made – namely SQL injection, cross-site scripting (XSS), cross-site request forgeries (CSRFs), and malicious file execution. It is simple enough to completely sanitize an HTTP request header, but often times the intended functionality is to post markup or script to a server (such as in a WYSIWYG editor). Writing custom exceptions for these specific instances without exposing yourself to potential risk is extremely labor intensive if done manually. In this scenario, the use of a web application firewall allows the developer to catch specific attempts, but generally be open and allow the web application firewall to catch suspicious HTTP traffic and create exceptions based on your applications’ functionality.

Once you’re ready to push your application to a production environment, you’ll need to follow requirements 6.3.1.2-6.3.1.5 which describe validation requirements of encrypted data storage and transmission, proper error handling, and role-based access controls (RBACs).

The requirements for data transmission and storage are discussed in depth in PCI DSS Requirement 4, which was covered in an earlier article. Once those encryption methods have been implemented, they must be reviewed and validated. In addition to encryption, Payment Account Number (PAN) data from a production system must never be present in a development environment, and all testing data must also be removed prior to deployment to production.

Error handling is generally simple, but is often overlooked. Disabling error output (PHP/Java/Python) or disabling .NET’s debug mode will prevent the disclosure of potentially sensitive information in your code. This should also include validation that tracing is disabled in compiled applications (Flash/.NET), and as a best practice, it is recommended that you use custom error pages wherever possible.

In addition to validating all of these items within the scope of your application, you must also ensure that all external endpoints (including third-party APIs) meet your application’s own requirements. For the purposes of PCI compliance, any third-party API or provider with which you integrate is included in the scope of your audit. Partnering with a vendor who is already PCI compliant can help reduce the number of questions an auditor may have.

Development Review and Procedural Guidelines

Code reviews are an important part of development for many reasons, but PCI DSS requires them to ensure that all code is properly implemented when separate teams or programmers collaborate on implementation of a security objective, but also as a measure to ensure that no developer has intentionally integrated security flaws or “back doors” into the code base.

It is also required that developers review all newly discovered vulnerabilities and assess their impact, applying security patches or code modification as appropriate. Using a PCI-certified vulnerability monitoring partner to perform scans on your network and applications not only simplifies the process of identifying known vulnerabilities, but it also ensures that you’re scanning for all of the latest known attacks, including 0-day vulnerabilities. Scanning, whether automated or manual, is required by provision 6.6.

Throughout the entire process, Requirement 6.4 outlines the need for change management procedures. These procedures must be part of your development and production-launch policies, and should include:

• Documentation—documenting the changes made both in functionality and in code, possible implications of these changes and their effect on other components of the application/network.
• Management Approval—a hierarchy must be established as part of this policy and changes then must be approved, once proper documentation is supplied, prior to launching the changes from the development environment to staging, and then from staging to the production environment.
• Testing—all code must be thoroughly tested, not only for its resilience against hacking attempts, but for the overall health of the application. Buffer runs, memory leaks, overflows, and other performance related issues can also cause severe security vulnerabilities. Items that may have previously been regarded as acceptable risk to usability or performance may not pass a PCI audit because of the risk they pose to security.
• Back Out Procedures—sometimes significant changes to the application and/or database schema, while not completely irreversible, may be difficult to revert. For every change that is documented, a reversal procedure must also be documented.

Conclusion

The provisions of PCI DSS Requirement 6 vary from being very specific to being very vague, or very cumbersome to relatively simple to implement. The requirement outlines the use of best practices throughout the planning, development, and maintenance phases of your application. You can use many options and methods to meet the provisions of this requirement, and each specific deployment will have its own set of quirks. In this article, I’ve outlined the several portions of Requirement 6 in the hope that it will point you in the right direction when you’re developing for eCommerce.

Resources

• PCI DSS
• Navigating PCI DSS: Understanding the Intent of the Requirements, v1.2
• Glossary of Terms used in the PCI Standard
• Automated, Continuous Vulnerability Monitoring
• Web Application Firewall and Other Application Protections

A version of this article was published in eCommerce Developer on June 24, 2010.

Security risks increase when your business moves outside of the safety net of your main workplace. Mobile executives carry sensitive data around with them, and often times open it up to vulnerabilities just for the sake of convenience.

It all seems perfectly innocent. Connecting to wireless Internet in your hotel room, or syncing up to free wi-fi in a restaurant just to get a little work done. Convenient? Yes. Necessary? Sometimes. Is working remotely a down trending habit? Absolutely not. And so, we must learn (and educate our workforce) about how to work remotely more safely.

Protecting your mobile workforce is essential to protecting your business. And it can be accomplished (or at least done more successfully) by following a few simple tips to help keep your business safe from hackers, no matter where you go:

Stay Off the Free, Open Wireless

More and more public places are providing free, or shared wireless Internet. These open networks are dangerous. They’re risky for personal communications, but they are absolutely not suitable for conducting business without protection.

When jumping on public shared wireless connections, it’s essential to do so using a secure VPN connection with the latest encryption methods. This will funnel all your online activities (email, surfing, chat, etc) through this secure connection so prying eyes can’t see what you’re doing. Several companies offer this service but we’ve heard good things about Anonymizer.

As an alternative, Verizon, Sprint, AT&T, and others have mobile broadband services available for a reasonable monthly subscription. Spring for the mobile Internet access card. It’s a small expense for what you get in exchange – the ability to conduct business more securely outside the office.

Bonus Tip – turn off your wireless connection at all times when not in use so you are 100 percent sure about when you are connected to the Internet. If you’ve previously connected to default network names (like Linksys) then anytime that network name reappears at another location, you will be automatically connected to the network opening you up for risks.

Let Hardware Do the Hard Part

We’re joined at the hip to our laptops, mobile devices, iPads, and other mobile gadgets. These crafty handheld devices help us work more effectively, and their processing capabilities and compatibilities increase every day. There’s no turning back from the convenience they provide, and believe me, we wouldn’t want to because the benefits in most cases far outweigh the risk.

Next time you’re packing for a trip, or just to work remotely for the day, think twice about your hardware requirements.

• Use a “travel only” laptop. A stripped down version of your of your regular workhorse but with limited history and minimal applications installed. Of course, passwords and all the “conveniences” of your regular machine won’t be readily available, but do you really need it all when you’re on the road? For some trips, perhaps, but always weigh the risks against the convenience.
• Use Web access rather than physical software for email when possible. Obviously, this is more convenient if you subscribe to the “travel only” laptop model. Either way, take pause to consider all the confidential information that may be stored on your physical machine’s email software if it fell into the wrong hands.
• Clear browser history every time you close Safari, FireFox, Chrome, etc. If anything, this will make it more difficult for cyber thieves to retrace your steps.
• Don’t store documents, presentations, spreadsheets, PDFs, etc, locally. Always connect to your designated location on an approved network and put your information there. The goal is to make your physical hardware as useless as possible. This way, if your laptop goes missing, none of the important information goes with it.
• Don’t store or “remember” passwords, type them in every time unless you want to give unlimited free passes to cyber criminals.
• Don’t leave home without “lojack-like” software, such as Computrace, that can wipe the contents of your mobile device. This provides an extra layer of protection in case your phone or laptop falls into the wrong hands.
• Anti-virus software can be installed on most laptops. There are several reputable virtual security companies that provide reliable service, but in a pinch you can download a free version that is better than nothing, as they say.

Pull the Fire Alarm

Two-factor authentication (aka 2FA or “the fire alarm”) provides an additional layer of protection and awareness for user systems. It’s incredibly simple, affordable, and effective, so there’s no excuse to not have this service for your users 100 percent of the time, but it can easily be enabled for users on the road.

It works like this: When (stolen or legitimate) credentials are successfully entered into a login prompt, the “fire alarm” software places a phone call to the authorized user to 1) alert the authorized user that a designated system is being accessed and to 2) retrieve a secret pin and complete the authentication. With this service enabled, attempted security breaches can be identified quickly, snuffing our suspicious activity before a full-blown crisis ensues.

Watch Your Back, Jack

Your coffee cup is empty, so you grab your wallet and ask the nice person next to you to “watch” your laptop while you go refuel. For an experienced cyber criminal, it takes just second to grab some data off of your computer, phone, or tablet. And lesser skilled (however not necessarily less malicious) hackers could just grab your goods and run. Thieves are everywhere and they park themselves in places where people work for this very purpose.

The coffee shop isn’t the only crime scene. Airports, car rental shuttle, hotels, and the back seat of your car are equally susceptible to theft. Check your bags at every turn. Make sure you’ve got the correct luggage and account for all your personal and professional belongings. Report any stolen items to the police and your IT staff at once.

Be Responsible. Your Business Depends on It.

Anytime you’re doing business on the road without security in place, you’re open for business, but for the wrong customers. You wouldn’t take your customers’ money and let it hang out of your pockets for anyone to grab would you? By leaving data access points open to hackers, you’re essentially doing just that.

Be conscious of how easy it is for hackers to take your company’s valuable information. Take the time to ensure that your company, and your customers’ data, is always protected and accountable, no matter where you are in the world.

A version of this article appeared in eCommerce Times on June 22, 2010.