Why Buy One When You Can Have Two at Twice the Cost?

Monday 14 Sep 2009 by admin | No Comments
Filed under: Uncategorized Tags: , , ,

By Mark Weiner–Managing Partner, Reliant Security

In my last blog, “The PCI Blame Game,” I expressed surprise that technology providers have thus far escaped the controversy around PCI-DSS adoption. Now, I’d like to explore the failure of commercial security firms to address the PCI compliance problem with cost-effective and integrated solutions.

PCI is one of the largest mainstream business problems that the Information Security Profession must solve. At the same time, PCI for the “brick & mortar” merchant has been a boon to data security firms. Security product and consulting firms produce proprietary software, hardware and management tools with an eye toward selling one fancy security gizmo to augment the new mini data center that they hope to create in to each retail location. The expectation that merchants should happily buy an independent Wireless Intrusion Detection Device, Vulnerability Scanner or File Integrity Monitoring solution for each location demonstrates how little understanding these firms have of their customer’s PCI business problem, and exposes the inflated view they have of the value that their point solutions provide.

In the 1997 film “Contact,” starring Jody Foster, fictional defense industry kingpin S.R. Hadden gleefully quotes the first rule of government spending: “Why build one when you can have two at twice the cost?” The mainstream data security industry has marketed its solutions for PCI compliance with exactly this approach. Alternatively, merchants aim to build distribution channels and systems that scale efficiently across hundreds or thousands of locations. So it’s not surprising that a significant source of the gridlock surrounding PCI adoption is a mismatch between the way the security industry wants to sell and the way that merchants want to buy.

Gridlock

It is not difficult to understand why the retail community adopted its legendary thriftiness. For more than 100 years, retailers have hammered away at distribution costs with liberal use of technology. Unlike their other technology investments, the ones they make to comply with PCI provide limited ROI. From the merchant’s perspective, any investment lacking measurable ROI is tough to swallow. The products offered by traditional security companies, with their added overhead of systems integration cost, complex deployment models, operational overhead, software maintenance fees and proprietary hardware are simply out of reach.

The industry that provides information security products has come a long way from its obscure academic beginnings. The first information security professionals were mathematicians who worked for the military encrypting and deciphering transmission of messages across diverse media ranging from paper scrolls to radio waves. Information security as a distinct field from mathematics did not emerge until the advent of mainframe computers in the late 1960s. It is important to recognize that information security was, from the 1960s until the 1990s, almost entirely an academic field of study born in universities and research labs, and dominated by a handful of PHD-level researchers. Primarily the government and the growing financial services industry funded it. Popular open source security applications like NESSUS, NMAP, IPtables and SNORT were first written in the mid 1990s and released under public licenses because researchers had little profit motive, and there was no established market in which to sell them.

As Internet usage became widespread, protection of sensitive data became a mainstream business problem. Security companies entered the market with pricey gizmos designed to protect web-based transactions. IT companies had just finished a long shift toward software licenses vs. proprietary hardware. Consequently, security companies gravitated toward business models that were heavy on selling software-based features via licensing agreements. Integration of multi-vendor products into a robust set of security controls, such as the ones required by PCI, was left to users and consultants.

The PCI standard was developed around eCommerce requirements in 2002 and applied to the retail world around 2005, after data breaches at the point of sale became a significant problem. This is when the security industry missed a critical step. It could have focused its efforts around integration by providing open APIs, integrated management tools and bundled products that provided a layered defense. Instead, it stuck rigidly to existing business models, and ran expensive marketing campaigns assuming that merchants would buy their products if they understood their features, functions and benefits.

Today, the jury is in and the verdict is not good for anyone involved. PCI adoption lags, as retailers continue to search for cost-effective alternatives. Security product vendors have largely priced themselves out of the market, and are frustrated that sales of their products in the retail sector don’t meet expectations. And the PCI Blame Game rages on…

This state of “gridlock” is what prompted us to launch Reliant Security with a goal of decreasing the cost and complexity of compliance. We provide consulting and data security solutions with an emphasis on leveraging open source security tools and virtualization over commercially available software, to provide our clients with secure, cost-effective solutions.

In our experience, retail merchants don’t want encryption solutions so complex that they would take the world’s supercomputers an additional 100,000 years to decipher. Nor do they want Wireless Intrusion Prevention Systems capable of detecting and responding to intrusion attempts within milliseconds. It’s not that they don’t understand these solutions, but rather that most simply don’t care. What they do want is to comply with payment card security requirements so they retain their place amongst consumers and payment processors as legitimate users of the payment system.

Why can’t merchants afford to buy two fancy security gizmos at double the cost?
Because their retail locations, which have become the front line in the payment security war, need right solutions to protect themselves on terms that keep the defenders healthy. If we bankrupt merchants to protect the payment system, then we have not actually protected the system at all.

Defcon 17

Monday 10 Aug 2009 by eiwe | 1 Comment
Filed under: Uncategorized Tags: , , , ,

By Eiwe Lingefors–Senior Security Engineer, Reliant Security

Every year, for the past 17 years, a slew of the brightest minds in the information security field descend upon Las Vegas for the Defcon hacker conference –the largest gathering of its kind anywhere in the world. This year, there were over 10,000 attendees. The presentations and content of the conference attract people from all living generations. Black, white and grey hats alike flock to Sin City to learn about a wide range of topics and meet peers from around the country and the world.

Having attended seven of these conferences (since Defcon 6) it has been an interesting experience watching it grow from more of an underground affair to what it is now.

The presentations at the conference range from tutorial to expert level and deal with a wide range of different topics related to all aspects of information security.

The most revealing presentation this year was one given by Moxie Marlinspike on the topic of SSL. This talk was also given at the sister conference of Defcon, the Black Hat Security Briefings which occurs right before Defcon at a different hotel in Las Vegas.

The talk exposes a fundamental flaw in the way SSL is implemented that affects nearly all web browsers. This flaw allows an attacker to obtain an SSL certificate for any chosen domain and bypass the automated verification checks due to an input validation bug. You can then use a man-in-the-middle attack to seamlessly inject this certificate and redirect the session traffic to a location of your choosing. All unbeknownst to the end user who believes his session is encrypted with a valid certificate.

I encourage you to view the entire presentation. Please click here for the full video and slides.

This was just one of many excellent talks. However, the conference is more than just presentations. Among other things, you can also spend your time learning or improving your hardware hacking skills, participate in the Open Capture the Flag contest where you complete various hacking objectives on a closed network, or learn about quantum mechanics (yes. really!).

Defcon continues to be one of the best, completely vendor neutral security conferences. It is packed full of great content that will teach, frighten and entertain you.

If you’ve ever considered going, or if this is your first time hearing about it, I encourage you to make an effort to go in 2010.

If you go and don’t like it, you can blame me.

The PCI Blame Game

Tuesday 21 Jul 2009 by jen | 1 Comment
Filed under: General Tags: , , , , , , , , ,

By Mark Weiner–Managing Partner, Reliant Security

In recent years, some have criticized the PCI standard as a failure. Pundits point to continued breaches of card data as evidence that the existing payment processing system should be replaced with a new, more secure one, and the standard abandoned. In an exercise I call the “PCI Blame Game,” blame is placed on various constituencies in the card-processing universe including the credit card brands, the merchant community, and card processors. But not only is the PCI Blame Game a futile exercise, it is harmful because it distracts from the important task of protecting the existing payment system.

The business problem

While there have been a number of well publicized issues with enforcement and implementation of the PCI standard, my opinion is that it represents the best available solution to a very thorny business problem—“how best to protect the successful and ubiquitous payment processing system that we all enjoy today with the understanding that is was never designed to operate in our interconnected world.”

ISO/IEC 7813 is the foundation

The logical foundation of the payment system is established in the ISO/IEC 7813 standard for payment cards. This standard, which includes specifications for magnetic stripe data, account numbers and verification values, was designed in the 1970s when the best standard for connecting card intake channels (POS systems, swipe terminals, etc.) with backend payment processing engines was a telephone line. At that time, there was no Internet, no TCP/IP stack and very few high-speed networks. To their credit, the architects of the payment system developed a set of standards that offered maximum scalability and redundancy based on the best technologies of their day. Things worked well and the system expanded throughout the 1980s and early 1990s.

THEN THE INTERNET HAPPENED and things really took off. No one; not the merchants, the processors, the card brands nor consumers, complained when the card processing system leveraged the limitless connectivity of the Internet to eliminate billions of dollars of transactional friction in our economy. Payment industry insiders made fortunes, and consumers benefited from the convenience, cost savings, and program rewards that came with the use of their payment cards.

The price we must pay

In my view, the current challenges with payment card data security are the price we must pay to enjoy the benefits of this aging, but highly effective system. As with any technology platform, the system can and should be improved with new technologies like “chip & pin” or smart cards, but this will take time and bring its own costs. In the meantime, the cost of implementing PCI, at least on a macro-economic scale, is small in comparison and makes sense for businesses and consumers. Unfortunately, the costs are not evenly distributed and this will be the subject of my next blog.

Change is difficult because of existing standards

Since the technology exists to implement a new logical foundation for electronic payments, what are we waiting for? The problem again boils down to the power of standards. An entire market has developed around the current ISO/IEC 7813 payment-processing framework. Getting an entire market to shift to a new standard is challenging–likely impossible–for the foreseeable future. Examples of how difficult a transition to new standards can be is evidenced by two antiquated standards that continue to dominate our lives and culture today – the English system of weights and measures and the Microsoft/Intel x86 (“WinTel”) standard of personal computing.

You may recall that in the 1970s the U.S. tried to convert to the metric system. This conversion made sense since it is used by far more people globally than the English system. The government forced schools to teach children about the new system, and spent millions of dollars promoting it to consumers and businesses. But the English system proved to be too ubiquitous in our society, and conversion to the metric system never happened.

My other example is the aging WinTel standard for personal computing that was developed in the 1980s. The standard still dominates nearly 90% of the world’s personal computers despite the existence of superior technologies such as Macintosh. Like the payment system, the WinTel standard was not designed for the interconnected world of 2009 and suffers significant security issues. It continues to be retrofitted and patched to deal with security vulnerabilities its designers could never have imagined. Only now, with the advent of free operating systems like Linux, are we starting to see cracks in the foundation of Windows dominance. But they are just cracks, mind you!

The existing payment system is here to stay

Back to the payment system–it too is ubiquitous and has bought huge benefits to business and consumers. It too is showing signs of age. Tens of millions of swipe terminals have been deployed to service it, and nearly every business in the country touches it. The credit card pocket in my wallet was designed around it. The current payment system is entrenched; so don’t count on changing it anytime soon. Like it or not, we are stuck with this system, and with the challenge of securing it. It is the price we pay for the benefits we get from continuing to use it. Playing the PCI Blame Game is a useless exercise; a bit like blaming all criminal activity on the U.S. government because the Federal Reserve prints the money that criminals attempt to steal.

Next…

In my next blog, I will explore why the costs of protecting the card system appear so unevenly distributed. Also, I will look at data security technology providers—a community that has managed thus far to skirt the swirling controversy around PCI.

Open security or why we blog…

Friday 26 Jun 2009 by jen | No Comments
Filed under: General Tags: , , , , ,

By Richard Newman–Managing Partner, Reliant Security

When throwing ideas around about how we could better raise awareness about our company, Reliant Security, starting a blog where we share information and opinions with the world quickly rose to the top of the list.  In July 2009 the act of blogging isn’t a new concept, but we think it is an important thing for us to do.  After all, our company is driven by an open systems philosophy.  For us, the best way to secure a system is by transparently using techniques and controls that are comprehensive, identifiable, and understood by all.  For some, transparency and security may seem at odds with each other.  One leg of the famous infosec C.I.A. triad – Confidentiality, Integrity, and Availability – is confidentiality, or the practice of protecting information (i.e. secrets) from unauthorized disclosure.  Much of security, naturally,  has to do with keeping secrets.  Organizations that are steeped in security (for example, the other CIA – Central Intelligence Agency) are anything but open or transparent.  They keep their secrets very secret, and often the methods and technology they use to protect them.

Does secrecy make a system more secure?

There is significant debate as to whether or not secrecy makes an organization or system more secure.  By design, secrecy makes the transmission of information more difficult.  Unfortunately, this also affects those who are intended to have access to the data in question.  In government we have seen examples where two agencies that should be cooperating with each other have a hard time doing so due to both security technology and an overall culture of secrecy.  In the mainstream technology world this debate can be seen in discussions about open source systems versus closed solutions relative to security.  Open source is open and transparent with the technologies and actual code used to secure them out there for anyone to review.  Closed systems, like Microsoft Windows, don’t have this characteristic.   The implementation of controls might be described by a vendor, but not with the same transparency that is an implicit aspect of open source.  Additionally when a vulnerability is discovered by a closed systems vendor, they sometimes elect to keep it secret until a patch is made available.   Closed source vendors are often the best positioned to discover vulnerabilities not only because of the information they gather through their support organizations but because of the R&D they do on their own systems supported by access to the underlying code.  There have been some great discussions as to whether or not open source is inherently more secure than closed systems.  To read more on this see blog posts by David A. Wheeler, and Bill Vass of Sun Microystems.

We are in the open source camp…

Reliant Security is firmly in the open source camp.  The company’s core solutions are based on the notion that open source provides a lower cost, and often a more effective alternative to traditional closed source security solutions for dealing with complex compliance requirements.  We work in a space where the security solutions we help our clients implement are subject detailed scrutiny because of the requirements for outside audit that comes from compliance mandates such as PCI.  “Security through obscurity” isn’t an option for us.  Audit guidelines require that we both provide detailed design information and use industry standard solutions.  It makes sense for us to engage in a policy of full disclosure with our clients and provide them with detailed information as to where our solutions come from, how they are developed, and how they work. In fact, the GPL, BSD and other open source licenses we use require us to provide our clients with full source code.  I guess you could call this “open security.”  As a commercial business whose purpose is to make money, we do have to take steps to protect our intellectual property, but secrecy isn’t an option. Instead, we count on two things:

  1. Our clients and competitors would have a difficult time re-inventing our architecture from scratch – even if provided with all of the open source code
  2. We have a process patent on the overall design

Still, we rely on the open source community for many aspects of our solutions and take the trouble to contribute back.  This blog is going to be another way for us to do that.  We are encouraging everyone at Reliant Security to post information here that the community at large will find both interesting and useful.  Enjoy!