TRANSACT16 Conference: Wrap-up

Successful show, awesome people, fun games!

transact 16Once again, TRANSACT16 was a remarkable conference! We met some great people, saw some awesome booths, attended some inspirational presentations, and had a blast with our robot laser tag game in Las Vegas.

If you attended, hopefully your experience was a success. If you managed to visit our booth, thanks for stopping by! (Tell us what you thought of our booth in the comments below!)

If you didn’t get a chance to get your burning data security questions answered at TRANSACT, please feel free to reach out to our data security experts who can help with your questions.
In addition to exhibiting, SecurityMetrics also sponsored this year’s TRANSACT golf tournament at Reflection Bay golf course, and the weather could not have been more beautiful.

Congratulations to those that won prizes and got to take home some neat swag, including Apple Watches, MisFits, and more!

Here are some of our favorite pictures from the show and golf tournament!
eta conference, SecurityMetrics
Having fun with the robots
Joe Durfey with his golf team 
electronic transaction association, SecurityMetrics
Getting interviewed by Marla from Mobile Marketing and Technology
TRANSACT16, SecurityMetrics
Getting ready to golf 

The best part is, we can’t wait to do it all again next year. See you at TRANSACT17 in Las Vegas on May 10-17 in 2017!
data security learning center, SecurityMetrics

Firewalls 101: 5 Things You Should Know

Check out these 5 firewall guidelines for PCI DSS Requirement 1 compliance

Mike Riesen, SecurityMetrics
By: Mike Riesen
Firewalls are one of the oldest computer security defenses that continue to remain a crucial foundation of network protection today. Because many aspects of data security start with firewalls, network firewalls comprise a huge part of the Payment Card Industry Data Security Standard (PCI DSS).

But simply installing a firewall on your organization’s network perimeter doesn’t make you compliant with the PCI DSS. A firewall must be correctly installed, updated, and maintained. Firewall rules must also be reviewed semiannually . . . a process most organizations have a difficult time with.

I’ve compiled five important tips that encompass PCI DSS Requirement 1’s main themes to help you accurately understand the basics behind some of the more complicated requirements. But before we dig in, let’s quickly cover some firewall basics.

Firewall basics

Network firewalls can be software or hardware technologies that provide a first line of defense to a network. Firewalls restrict incoming and outgoing network traffic through rules and criteria configured by the organization.

A hardware firewall, or perimeter firewall, is installed between an organization’s network and the Internet to protect the systems inside. A software firewall only protects the device it is installed on. Many computers come preinstalled with software firewalls, but for computers connecting to the cardholder data environment remotely, a personal firewall is required.

In summary, a hardware firewall protects environments from the outside world, and a software firewall protects a specific device from internal threats. For example, if an attacker tries to access your systems from the outside, your hardware firewall should block him. If a sales manager accidentally clicks on a phishing email scam, her computer’s software firewall should stop the malware from infecting the computer.

5 tips for meeting PCI DSS Requirement 1

Because they stand as an organization’s first line of defense, firewalls get a lot of attention from attackers. Most of the time, firewalls are riddled with configuration flaws, and aren’t accurately protecting systems that touch payment card data.

With over 20 PCI DSS sub-requirements outlining firewall specifics, your obligations can be overwhelming.

After you purchase a firewall that meets PCI DSS requirements, (SecurityMetrics Qualified Security Assessors (QSA) recommend network security firewalls by SonicWALL, Cisco, and Juniper) focus on the following five items to make the most of your firewall security strategy:

1. Spend time on (and revisit) configuration
Just because your business has a firewall, doesn’t mean it’s effective. Many businesses incorrectly treat network firewalls as plug-and-play technology. Instead, establish rules (or Access Control Lists) that dictate to the firewall what you trust into and leaving your network. Firewall rules typically allow you to whitelist, blacklist, or block certain websites or IP addresses.

When no ACLs have been configured, everything is allowed into or out of the network. Rules are what give firewalls their security power, which is why they must constantly be maintained and updated to remain effective.

As you’re setting up your ACLs, remember that large rule lists will negatively impact your network’s performance. (This is why system administrators usually hate firewalls.) If you’re experiencing system bogs, or need help consolidating your giant rule set, you might benefit from security consulting with a QSA.

Learn how to correctly configure a simple firewall in 5 steps.

2. Document everything
A massive chunk of your PCI firewall compliance process should be spent recording what you’ve completed. Also known as documentation (and largely considered a pain by most people) this process is absolutely necessary for true PCI DSS compliance…and your own sanity.

Firewall documentation helps your team comprehend what has been done, what still needs to be done, and where the problems are in your environment. Ultimately, it keeps your security efforts organized. As a bonus to you, documentation will make next year’s job easier. After all, updating already existing documentation is much easier than starting from scratch.

The most important documentation pieces from PCI DSS requirement 1 include:
  • Network and cardholder data flow diagrams: As the PCI DSS states, “Often, seemingly insignificant paths to and from untrusted networks can provide unprotected pathways into key systems.” Without an accurate view into how your network is set up, you could overlook devices that need to be part of your firewall rule set. Network and cardholder data flow diagrams help identify the location of all network devices and how card data flows through each piece of the network. While analyzing these diagrams, you should be able to study exactly what areas must be protected, and the unnecessary services, protocols, and ports to disable. (Learn how to make a card flow diagram.)
  • Description of groups, roles, and responsibilities: By documenting who is involved in the firewall process, you ensure those assigned are aware of their responsibilities. According to the PCI DSS, “if roles and responsibilities are not formally assigned, devices could be left unmanaged.“
  • Business justification for allowed services, protocols, and ports: Compromise often occurs in areas that are unused, unpatched, and unmonitored. Ensure your firewall only allows the minimum amount of connections required for your business to operate. If you need any ports or services open for your business to function, the PCI DSS wants to know why, and how you’re going to protect against those open areas.
3. Restrict as much traffic as possible
An organization’s firewalls should be configured to protect the sensitive card data environment at all costs. The easiest way to do this is by restricting and controlling the flow of traffic as much as possible, specifically around the cardholder data environment.

Depending on how complex your environment is, you might require many firewalls to ensure all systems are separated correctly. The more control you have, the less chance an attacker has at getting through unprotected Internet connections. Don’t forget to consult your network diagram when considering firewall placement.

SEE ALSO: How Does Network Segmentation Affect PCI Scope?

The PCI DSS does a great job of listing how firewalls should ensure blockage of all unwanted traffic through segmentation and rule sets. Here are a few examples:
  • 1.2.1: Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment, and specifically deny all other traffic.
  • 1.3: Prohibit direct public access between the Internet and any system component in the cardholder data environment.
  • 1.3.7: Place system components that store cardholder data (such as a database) in an internal network zone, segregated from untrusted networks.

4. Protect new technology
One of the biggest challenges firewalls face is that an organization’s network perimeter is no longer well defined, due to new technology practices like BYOD and cloud storage. Because mobile devices aren’t enabled with firewalls, and because they aren’t policed by traditional perimeter firewalls, they can potentially become a huge risk.

That’s why the PCI DSS requires businesses to install personal network firewall software on mobile and other employee-owned devices that connect to the Internet and also access the network.

5. Monitor and tighten control
As stated earlier, network firewalls aren’t a plug-and-forget technology. No matter the size of your environment, things change over time. The firewall rules in play today will need to be perfected in a few months. That’s why PCI DSS requirements state organizations must review firewall and router rule sets at least every six months. While forcing you to ensure all cracks are still sealed, it also gives you the chance to revamp your firewall strategy.

Log management also plays a vital role in monitoring firewall security (and is yet another PCI DSS requirement). Logs keep track of both normal and potentially damaging user actions happening against a firewall and help prevent, detect, and minimize the impact of a data breach. If event log software is configured correctly, administrators can be alerted if firewall logs indicate an attack.

Keep in mind nearly all network firewalls have very limited logging space, so it’s important to set up a logging server and configure your firewall logs to go to that server.

The future of firewalls

It’s unknown if network firewalls will stand the test of time. They are the bedrock of most data security strategies, but their technology is over 30 years old. To stay up to speed with attackers, future firewall manufacturers must increase program speeds, support the cloud, be more customizable, and withstand new hacking methodologies.
For now, firewalls shouldn’t be your only line of defense.
Instead, they should act as a compliment to other security technologies and add yet another layer on an already robust security posture.

Mike Reisen is a Security Analyst and has been with SecurityMetrics for over 2 years, doing PCI DSS assessments. He is a graduate from the University of Utah, and has worked in the IT industry for over 15 years. 

PCI learning center, SecurityMetrics
Recording Your QIR: SecurityMetrics’ New QIR Feature

See how SecurityMetrics is helping merchants with VISA’s new QIR mandate. 

QIR integratorIn recent years, QIRs have become more important to businesses, particularly those that deal with card payments. Thanks to Visa’s new mandate that businesses must get their payment processing applications from a QIR by January 2017, it’s now becoming a big issue.

Here’s what you need to know about QIRs and how SecurityMetrics is addressing Visa’s mandate.

What is a QIR?

QIR Stands for Qualified Integrators and Resellers. These vendors are certified by the PCI DSS to correctly integrate payment applications. Integrators and resellers that want to become QIRs have to take a training course and an exam provided by the PCI Security Standards Council.

According to forensic reports many data breaches were the result of security protocol gaps in remote-access services used by integrators and resellers to provide monitoring and software support. These gaps create significant risk of payment data compromise. Having a QIR correctly integrate payment applications helps address this problem and helps businesses secure their data properly.
Boiled down, you need someone with proper training to integrate payment products from a security perspective.

How does the new VISA mandate affect QIRs and merchants? 

Come January 31 2017, merchants will be required to use QIRs for their payment applications. This is in response to the rising data breaches involving insecure payment applications, and improper set up of remote access. VISA now wants QIRs to be in charge of installing and configuring these payment applications.

SEE ALSO: Staying Compliant: Visa’s New Level 4 Requirements

QIR reseller What is SecurityMetrics doing with QIRs? 

In response to Visa’s new mandate, SecurityMetrics has added a new feature that allows users to document their QIR when filling out the self-assessment questionnaire (SAQ). This feature will record on your SAQ whether or not you’re using a QIR for your payment processes. The QIR data should only apply to applicable merchants, which depends on PCI scope.

To store your QIR data, sign into, access your SAQ and go to the “Card Acceptance Section.” Once you select your Payment Application, the page will ask you who installed the system.

You can now select the option that you got your payment application from a QIR. Once you do that, you then can fill out information on your QIR, including the name of the QIR, the integration date, and a location.

What sets SecurityMetrics apart is how we handle QIRs. If a merchant puts in an integrator who isn’t a QIR, we can tell them whether they aren’t in Visa’s list of QIRs.

Why did SecurityMetrics include this new feature? 

Even though Visa’s new requirement isn’t in place yet and won’t be until 2017, we’re gathering that data to make the transition smoother for our merchants and acquirers.

Getting your payment applications from a QIR is a great step to getting compliant and securing your data. SecurityMetrics has provided an easy way to validate that you are using a QIR for your payment methods.

Need help with data security? Talk to one of our consultants! 

data security learning center, SecurityMetrics
Badlock: Combatting the New Samba Vulnerability

New vulnerability could expose companies to man-in-the-middle attacks. 

By: Steve Snelgrove
On April 12, Badlock, a security bug in Windows and Samba was disclosed.  It was discovered by Stefan Metzmacher, a member of the international Samba Core Team.

The SMB protocol was originally developed by Microsoft to enable various resource sharing and authentication features on local networks. For example, one use of the protocol is to allow several computers to share printers.

badlock, samba vulnerability
Samba is an open-source implementation of this protocol. With Samba, a Linux server can provide services and shared resources that both Linux and Windows computers can utilize.

Because both Microsoft’s and Samba’s protocol implementations are based on a common protocol conception, flaws in the underlying protocol will result in vulnerabilities in all implementation.

This is the case in the recently disclosed collection of vulnerabilities: Badlock.

What is Badlock? 

The researchers who worked on identifying these problems decided to give the collection of issues the name Badlock in order to promote awareness about these problems.

Badlock can be categorized as a man-in-the-middle attack or a denial of services attack.
  • Man-in-the-middle attacks: These attacks intercept and modify user permissions on files or directories. This attack could intercept DCE/RPC traffic between domain member and domain controller to impersonate the client and gain credentials. 
  • Denial of service attacks: These are attacks to make a machine or network unavailable to its intended users. Samba services are vulnerable to denial of service from an attacker with remote access connection to the Samba service.  
This vulnerability involves flaws in the coding and security protocol of the Samba application, potentially exposing these active directories that contain password data and other credentials. Hackers can gain access to the directories and get a lot of information about companies.

As a result, Badlock could potentially leave companies open to many types of cyber attacks, letting hackers get access to sensitive data.

Who is vulnerable? 

Many, if not most, versions of Windows and Linux operations systems may be vulnerable to Badlock.
The following Samba Applications running on Linux/Unix systems are vulnerable:
  • 3.6x
  • 4.0.x
  • 4.1.x
  • 4.2.0-4.2.9
  • 4.3.0-4.3.6
  • 4.4.0
The following supported editions of Windows are vulnerable:
  • Windows Vista
  • Windows Server 2008
  • Windows 7
  • Windows  Server 2008 R2
  • Windows 8.1
  • Windows Server 2012
  • Windows Server 2012 R2
  • Windows RT 8.1
  • Windows 10
To put it simply, any Samba server as a domain member is vulnerable to this flaw. Practically every version of Windows and Linux operations systems has this defect in the security component.
Microsoft vulnerability

What can you do? 

Since this vulnerability has been discovered, security patches have been developed that will secure

For a Samba service running on Linux/Unix systems, apply the patches provided by the Team and SerNet for Enterprise SAMBA/SAMBA+ immediately.

For Windows users, refer to Microsoft for patch details.

According to the current security industry, there’s no immediate need to panic. There were some fundamental problems identified with the protocol and its implementation, but so far, the risks at present are not rated very high. Mounting an attack is also fairly difficult since the attacker has to already have access to the network.

That being said, it’s recommended you take action quickly, should you be vulnerable.

Need help with data security? Talk with one of our consulting experts!

Steven Snelgrove (CISSP) has been a Security Analyst at SecurityMetrics for over 7 years. Since 1980, Snelgrove has worked in the computer and telecommunications industry, and has familiarity with programming, software engineering, and network security. His current responsibilities includes the manual assessment of web applications and corporate networks, conducting ethical hacking to analyze security architecture, and consulting with organizations to help remediate issues. Snelgrove received a degree in Computer Science from Brigham Young University, and holds a CISSP (Certified Information Systems Security Professional) certification. 

data security learning center, SecurityMetrics
System Hardening Standards: How to Comply with PCI Requirement 2.2

Five key steps to understand the system hardening requirement.  

David Page, SecurityMetrics
By: David Page
One of the most confusing Payment Card Industry Data Security Standard (PCI DSS) requirements is Requirement 2.2. It involves system hardening, which ensures system components are strengthened as much as possible before network implementation.

According to the PCI DSS, to comply with Requirement 2.2, merchants must “address all known security vulnerabilities and [be] consistent with industry-accepted system hardening standards.” Common industry-accepted standards that include specific weakness-correcting guidelines are published by the following organizations:
    PCI 2.2
  • Center for Internet Security (CIS)
  • International Organization for Standardization (ISO)
  • SysAdmin, Audit, Network, and Security (SANS) Institute
  • National Institute of Standards and Technology (NIST)
Merchants can use and research other resources as well, such as the following:
  • Information Assurance Support Environment (IASE)
  • VMware environments

System Hardening (PCI 2.2) Vs. Patching (PCI 6.2)

System hardening is not the same as software patching, though the two processes complement each other.
System hardening should occur any time you introduce a new system, application, appliance, or any other device into an environment. A hardening process establishes a baseline of system functionality and security.

The goal of hardening a system is to remove any unnecessary functionality and to configure what is left in a secure manner.  Every application, service, driver, feature, and setting installed or enabled on a system can introduce vulnerabilities.

Once a system is hardened and deployed into an environment, it’s critical to maintain its level of security through proactively updating or patching it to mitigate new vulnerabilities and weaknesses that are discovered.  The hardening process should then be updated to include these new patches or software versions in the baseline configuration, so that the next time a similar system is deployed, old vulnerabilities are not re-introduced into your environment.

5 Steps to Comply With PCI Requirement 2.2

There are five steps you should follow to comply with PCI 2.2, which can more easily be understood through the analogy of building and protecting a home.

Fences, gates, and other such layers may protect your home on the outside, but system hardening is the act of making the home itself (the bricks, siding, doors, and everything inside) as strong as possible.

Many falsely believe firewalls and data security software layers are enough to protect systems and to comply with system hardening requirements. In reality, system hardening is all about locking, protecting, and strengthening components of the actual system, not protecting it by adding new security software and hardware.

1) Understand you’re not safe right out of the box
Plenty of system administrators have never thought about system hardening. They probably think, ”We just installed our system . . . why would it have a problem already?”
Say you hire a builder to construct a home. Would you assume your homebuilder changes the locks on every home he builds? What if he installs the same lock on every home because he assumes you’ll rekey it once you move in?

In the same way you shouldn’t rely 100% on your builder to secure your home, you shouldn’t expect your system to be 100% secure when you pull it out of the box. Windows, Linux, and other operating systems don’t come pre-hardened. It’s your job to figure out how to make them safe, and it’s going to take work on your part.

A lot of merchants assume system hardening is part of a POS installer’s job. Most of the time, it’s not. If the installer does take on that responsibility, they’re probably not doing it correctly because they don’t understand the PCI DSS.

When installing a new POS system, the PCI Council recommends hiring a PCI DSS Qualified Integrated Reseller (QIR) because they’ve gone through training to understand system hardening and other PCI DSS qualifications.

SEE ALSO: Recording Your QIR: SecurityMetrics’ New QIR Feature

2) Get help
Unless you’re a homebuilder or architect, there are likely aspects about safe home construction you don’t understand. Luckily, builders rely on industry-accepted guidelines when building, and understand how to prevent common structural weaknesses.

For example, the home design you choose may have lots of windows, which may weaken the structure. Builders have guidelines on how to correctly frame out windows to ensure they won’t be a point of weakness.

Similarly, there are guidelines created by organizations (see above bullet points) that help system administrators understand the common holes in operating systems and environments they want to integrate.

Available online, these comprehensive instructions outline the most critical steps to secure your system from attacks. The guidelines usually list vulnerability descriptions, procedures to remediate vulnerabilities, online references to learn more about the vulnerability, and other specific configurations on how to harden that particular part of the system.

3) Prepare for research
If I built a home, I might want a three-car garage and five extra windows upstairs. You may wish to replace standard lighting with grand chandeliers and add a giant front door instead.

Just as each home is different, each system environment is modified to fit your organization’s specific needs. You may want to run a specific OS version, a newer web server, or use a free database application.

Because every environment is unique, there usually isn’t a simple how-to document that fits your specific needs. This means system hardening, and compliance with Requirement 2.2, will require a fair amount of research and discovery time on your part.

You must spend the time researching and finding guidelines that pertain to each specific part of your environment, and then combine the applicable pieces to form your own standard.
4. Harden your systems
Everyone knows that building a home is hard work. There are lots of details to worry about, it takes months (sometimes years), and not everything goes exactly as planned.

Similarly, hardening your systems takes a lot of detailed work and tweaking. For example, some guidelines can require you to:
  • Disable a certain port
  • Stop a service
  • Remove a feature of the OS
  • Uninstall software
Most guidelines also involve changing or turning off default settings and removing unnecessary features or applications. For example, HP computers used to come with customer service software preinstalled that automatically reported all events back to headquarters. I’m sure you can imagine the security implications of this, which is why security guidelines for HP computers recommended removing it from the system entirely.

It’s important to perform testing throughout the hardening process to ensure business-critical or required functionality isn’t impacted.

Here are some key examples from the PCI DSS that state specifically how you’re supposed to harden your systems. Pay attention to these two examples, as they are common PCI 2.2 compliance problems:

system hardening standardsExample 1: Ensure servers don’t have more than one primary function 
It is common in many small retail chains I’ve audited to have web browsing, email, and Microsoft Office capabilities available on the same back-office workstation running their POS server. This is not compliant with PCI 2.2! By integrating a POS server with a workstation used for day-to-day operations, these merchants put uncontrolled functions on the same server as their most secret and important cardholder data.

If this sounds like your business, reconfigure your network to separate these functions. (You may find it useful to read a bit more about network segmentation.)

Example 2: Remove unnecessary services and functionality
This portion of Requirement 2.2 is kind of like preparing a racecar. To race, only items that make the car go fast are needed. Backseats, radio, and anything else that adds weight to the car is stripped.

By ensuring only necessary services, protocols, and applications are enabled, a business reduces the risk of an attacker compromising a vulnerability to get into a system.

An easy way to remove unnecessary functionality is by going through each running service in a system’s task manager and asking, “Do I really need this?” If not, disable it. A lot of tasks running on your system are required for the system to function, but don’t ever assume. If you don’t recognize it, look it up!

5. Document your hardened systems
If you changed some things on your original house blueprint, and 10 years down the road want to remodel, the best way to remember exactly what you did is to refer to the changes on the blueprint. It’s going to be risky to knock out that kitchen wall if your remodeler doesn’t have correct information from the blueprint telling him or her what is inside the wall.

Documentation is key to system hardening. It’s important to keep track of why you chose certain hardening standards and the hardening checklists you’ve completed.

Here are three reasons why:
  • PCI auditors: After you ensure all system hardening guidelines are met, you may be asked to convince others (PCI auditors) that you did a good job. Your auditor wants to know and see that you did your research, and have applied appropriate settings for each system.
  • New hires: If you leave a company, how will the new IT director know exactly what you did to harden the organization’s systems? Documentation helps drop the breadcrumbs for replacements to understand what’s already been done with the system.
  • Yourself: If you decide to change an aspect of your environment and already have the documentation for existing systems, you’ve cut out hours of time-consuming research.

There’s No Easy Button

There is no easy button for the PCI DSS, and especially for PCI Requirement 2.2. There aren’t magic tools to harden your system automatically. There is no master checklist that applies to every system or application out there. Creating an effective hardening standard can be a research-heavy project.  Luckily, there is a lot of information available in the form of industry-standard guidelines that can help you know where to start.

The time and resources involved in system hardening are well-spent. Creating and applying appropriate hardening standards in your environment will go a long way toward securing the data that is so critical to your business .

If you need assistance with system hardening, I recommend talking to IT security consultants who are well equipped with both PCI DSS experience and IT proficiency.

David Page is a Qualified Security Assessor and has been working at SecurityMetrics for 2 and a half years. He has over 18 years experience in network and system engineering, design, and security.

PCI learning center, SecurityMetrics