I am amazed at the number of organizations that continue to take either a lax, or too narrow approach in protecting information assets. I am certain that those of our legislators who understand the threats against our corporate assets and the individual’s identity would agree. Just look at some of the regulations that currently exist, Sarbanes Oxley, PCI DSS, Red Flags Rule, HIPAA, GLBA and you will begin to get where I’m going. Throw in the regulatory bodies FTC, SEC, FFIEC, and so on.

There are armies of resources now and a growing attitude for more legislation and governing bodies. This is purely reactionary and misguided when it comes to securing information assets. What is really missing in the equation is focus by the companies themselves who hold the intellectual property, sensitive consumer information, or infrastructures of national concern.

In general executive leadership does not understand the real and growing threats that their businesses face. There are literally thousands of attempts at their organization’s assets on a daily basis from, internal hackers, and externally sophisticated organized crime and espionage groups. Still none of this is on the average executives’ radar screen. Too often the media when they do speak on the topic doesn’t get it right as they are going for the sensational as opposed to the facts. We need to focus on the facts, as this is not a Sci-Fi drama, its real world.

Perhaps the government has gotten the attention of corporations in only the way it believes it can through regulation. However regulators don’t always do their job so various frauds and information thefts of identity, healthcare, credit, and other crimes continue to grow. In large part the regulation has pressed companies to focus on passing audits and not securing information assets. The two require markedly different approaches and levels of commitment. A complaint organization is not necessarily a secure one.

So when do most corporate leadership, principals, partners and other executives focus on information security? The all to often answer is, after the compromise. The approach then is ad hoc, reactionary, and an ill focused response to an information compromise. The loss occurred, the organization not prepared, preventative measures failed, the compromise not detected for an extended period of time, and now chances are there is little opportunity to fully recover at any cost. Information security breaches can cost an organization millions and high-profile public cases can run into the hundreds of millions of dollars.

Information Defense is often called in on incident response and forensic investigations. Many times long after the breach has occurred. We have seen “compliant” organizations suffer significant information losses. Again I want to stress that securing information assets and being complaint are not one and the same. Piecing together the facts in an investigation where a theft has occurred is difficult, costly and a lengthy process. Results are highly dependant on evidence that may no longer exist and are out of the control of the incident response and forensics team. While comprehensive information security programs, across people, process, and technology often form the basis for solid compliance solutions the converse is not true.

While security awareness can often arise from comprehensive steps taken to become compliant, without understanding at the most senior levels, and a corporate mandate accompanied by the resources to drive the necessary steps for information security the organization will be largely unsuccessful.

Engaging expert external resources such as Information Defense can bring the critical comprehensive experience and balance to the organization. Experts can help to balance compliance and security initiatives while help define and drive priorities and timelines to manage what can be enormous investments. Often outside resources can assist in engaging the executive team for sponsorship and drive the importance of following strong risk management practices and principles to support today’s information rich, connected, online present organizations.

See here for Managing your PCI Audit & Compliance blog part 1

By now your organization has chosen a Qualified Security Assessor (QSA) who will be performing PCI compliance assessments, but now when do you schedule the on site visit for the QSA? The answer is simple; once the organization is prepared. As discussed prior in Managing Your PCI Audit (Part 1), without appropriate preparation the PCI audit process can rapidly deteriorate.

Now this may seem shocking, but it is not unusual for some very large organizations, and smaller ones too, to not understand or have documented all of the ways in which the company accepts and processes credit card information.  For the purpose of this blog lets assume your company does know and has documented comprehensive credit card information flows throughout the network.  We will detail these requirements in a later blog.

From the large organization and data center to the mid level business, assigning the key participants for the PCI audit is crucial and must occur before scheduling the onsite review with your QSA.   Key stakeholders depending on the size and complexity of the company may include among others:

• Management
• Infrastructure Engineering
• Systems Administration
• Applications Development
• Information Security

Coordinating with the appropriate resources from the participating departments and discussing the upcoming PCI audit is key.  This includes making certain participants are informed of their roles, time requirements and availability requirements.  Once complete, it is time to reach out and schedule the QSA.

Request that your QSA send an itinerary and schedule one-week prior to arrival. This will help set schedules and necessary arrangements for your key personnel.  Depending on your company size and complexity the QSA may be onsite for a week or more.

Once onsite the QSA will want to schedule a meeting to coordinate activities, meet the key participants, layout the schedule, establish management rapport, and answer any questions.   It is important that your key participants are effective communicators and clear on their roles.  As the main point of contact for the organization you should plan on dedicating your time to participate in all QSA meetings and interviews.

I would like to point out that almost all QSA firms (an auditor) also offer PCI consulting (advisor).  This is however a very fine line to have one firm in both the role of advisor and auditor.  It is best to separate these functions obtaining a PCI consultant to advise your company on identifying the necessary actions to achieve compliance and a QSA to measure the organizations compliance.

A typical QSA itinerary might be as follows:

• Project kickoff meeting
• Network Diagram and CDE review
• Credit card flow review
• Key Personnel Interviews
• Supporting documentation review
• Remediation review

Always remember that while the QSA is providing the itinerary you the customer need to maintain control. Participating in all meetings and interviews will eliminate audits going off track and insure that each key participant is focused on their area of responsibility and expertise and maintain the scope as defined in the organizations pre-assessment meetings. I cannot stress enough that preparation, knowledge and management oversight are key to an effective and efficient audit.

In my next blog I will go into details an exactly what needs to be done around Network Diagrams, Credit Card Flow, and Documentation. Until then contact us here to see how we can advise your organization on reaching PCI Compliance.  See you soon!

FACTA added sections to the Federal Fair Credit Reporting Act intended primarily to help consumers fight the growing crime of identity theft.  In adopting FACTA, Congress recognized that consumers were unable to prevent identity theft and could only react long after the event had occurred.  In order to stop the fraud at its source businesses that offer credit need to address the events that signal a potential fraud.

Six agencies were involved in drafting the red flag rules: the Treasury Department’s Office of Thrift Supervision, Office of Comptroller of the Currency, Federal Deposit Insurance Corp., Federal Trade Commission, National Credit Union Administration and the Federal Reserve System. The Red Flags Rule identifies 26 “ Red Flags” which may be indicators of attempted fraud.

According to FTC statistics nearly 10 million people were victims of identity theft in 2008 in the US.   In the broadest sense identity theft is the act of someone assuming the identity of another individual to gain access to the victim’s personal resources.  Last year over 35 million known data records containing sensitive personally identifiable information (PII) were stolen.

While some perpetrators know their victims, having stolen their wallets, credit cards, checkbooks or other personal items, the vast majority of perpetrators do not.  Identity theft comes in many forms and most victims learn their fate long after the initial event occurs, often months to years after the fact.

Most data theft is primarily due to poor controls surrounding PII.  This can range from sensitive records being thrown in dumpsters to electronic records being improperly secured online and breached by hackers.

Personal resources accessed by data thieves may include use of credit cards, establishment of credit under the victims identity, access to utilities, healthcare benefits, banking, employment, loans, government benefits, and many other acts limited only by the imagination of the perpetrator.  The common element is the use of defrauded individuals persona to gain credit or access to established resources.

The Red Flags Rule applies to both financial institutions and creditors.   The definition of “creditor” is broad and includes businesses or organizations that regularly defer payment for goods or services or provide goods or services and bill customers later.  These companies may not traditionally be thought of as extending credit and include utility companies, health care providers, telecommunications companies, cable and satellite providers, and others, depending on how and when they collect payment for their services.

The Rule also defines a “creditor” as one who regularly grants loans, arranges for loans or the extension of credit, or makes credit decisions. Examples include finance companies, mortgage brokers, real estate agents, automobile dealers, and retailers that offer financing or help consumers get financing from others by processing credit applications.  Additionally, the definition includes anyone who regularly participates in the decision to extend, renew, or continue credit, including setting the terms of credit – for example, a third-party debt collector who regularly renegotiates the terms of a debt.

Organizations that are covered under the Red Flags Rule must create written plans that are reviewed and signed off by the organizations board of directors that:

• Create Policies and Procedures that Identify Red Flags Which Pertain to their Business
• Create Policies and Procedures that Detect the Identified Red Flags
• Create Policies and Procedures that define the Actions to be take when Red Flags are Detected
• Monitor changing Red Flags, Train Employees and Monitor 3rd party contractors

An appropriately designed and managed plan depending on the business may require considerable skill and effort.  Most organizations will do well to reach out to experts in designing their programs.  Is your organization subject to the Red Flags Rule?

Information Defense is prepared to assist in evaluating whether your organization is subject to the FTC ruling and assist in defining and developing the necessary steps to reach compliance.  Contact us here for further information.

PCI DSS compliance has now become a household name for security and IT departments worldwide, potentially having significant impact on those organizations that store or process credit cards. According to the PCI Security Standards Council “All merchants, whether small or large, need to be PCI compliant.”

While the security requirements are the same for all covered organizations, the method of proving compliance depends on the number and value of annual credit card transactions. For merchants processing more than 6 million transactions a year, this means an on-site audit by a Qualified Security Assessor (QSA). For more information on PCI DSS please visit https://www.pcisecuritystandards.org.

For many organizations the term “PCI Audit” seems to be shrouded in mystery. Having facilitated many PCI audits for large organizations, I have probably been asked every question imaginable in regards to PCI. What exactly is involved? What is my Cardholder Data Environment? How much information must I provide?

As an adviser I have always tried to impress upon my clients the need to understand and proactively manage the PCI Audit process, and in particular to be prepared for onsite interviews by the QSAs. Many of the staff members that the auditor will be interviewing (e.g. office PC users, call center operators, systems administrators) may view the auditor; either as an adversary, from whom as much information should be withheld as possible, or as a friend, to whom all information should be provided when requested. In fact, neither of these positions is appropriate and both can lead to trouble for the organization being audited.

Proactive PCI Audit management is the cornerstone to a successful audit process. While many businesses simply do not have the time, staff, or trained personnel to prepare for all aspects of a PCI audit, I recommend finding qualified external resources to help the organization down this path. It is important to remember that while most QSAs are reasonable and professional organizations they are not employees and maintain significantly different roles, responsibilities, and organizational insight.

Managing the PCI audit carefully will help reduce time, costs, and operational impacts to the organization. At a minimum audit management will refine the scope and keep answers to audit questions on point. Keys to a successful audit and meaningful results are to appropriately prepare staff, set expectations, and sharpen scope. Expert resources to manage the process can add significant benefit to the organization and potentially reduce the cost of compliance.

The PCI audit process consists of many areas, however we will be focusing on the “on-site Interview” portion. The first step in the onsite interview is preparation. Once you have chosen your QSA find out exactly when the auditor will be on site, what activities the auditor will be conducting, and what documentation they will require. Knowing all of this will help you to understand exactly what level of detail the auditor is looking for, as well as which team members will be asked to take part in onsite interviews. Make sure to schedule the auditor’s on-site presence when there is the minimum impact on your business operations.

PCI audits may become less effective and minimally productive due to a lack of preparation on the client side. Inappropriate preparations may lead to a host of issues including the over exposure of information, withholding or attempts to hide information by well intended but ill advised staff, or as well as inaccurate and or inconsistent answers.   Theses issues among others can cause significant problems and expense down the road for the organization under audit. Preparing each staff member before the onsite meeting is vital to a successful, efficient, and effective audit.

Some examples of staff interview preparation includes understanding exactly what is meant by “Cardholder Data Environment” and what this actually means to the organization. The organization and the auditor must agree on the scope prior to the commencement of the audit. Only information directly related to the CDE should be provided in interviews. Auditors should be expected to provide their interview questions for review beforehand, comply with an interview schedule, and should not interview additional staff members who may confuse the issues or provide inappropriate answers. It is the responsibility of the individual managing the audit process to ensure the interview is on topic, within scope, and with the appropriate staff.

My next blog I will cover actual questions that have been asked as well as the proper way to answer them. I will also dive deeper into the audit process.  Until then please contact us here to learn more about how we can assist your organization to manage the compliance process.

See my next blog post here – Managing Your PCI Audit & Compliance part 2 – preparing for the QSA visit.

To understand why this is so, let’s look way back through the mists of time to a different epoch, to the early nineties when Bruce Springsteen was still making hits, Grunge was hitting its stride, and some of us dedicated ourselves to the crazy antics of those kids in Beverly Hills.  Before the early nineties, when I deployed my first corporate “Internet” connection and “firewall” (router with an ACL), few corporations had Internet connectivity.  What connectivity there was generally consisted of some point-to-point leased line connectivity; perhaps some dedicated frame relay, X.25, microwave, satellite links and often banks of modems for dialup.  The vast majority of these connections were internal to the organization, generally connecting remote facilities together, occasionally for special business partner connectivity, and for support staff and remote access by at-home workers.  Generally there was no service provided to the general public, everyone who connected to us was a known entity.  Those connections to outside entities were dedicated to special application, often simple messages, such as automated re-ordering from a MRP system between customer and suppler.  All the connected sites were considered trusted; there were no concepts like DMZ.

Then came the Internet, web sites, services aimed at the unwashed masses of Internet connected pubic.  Providing services to those entities who were completely unknown to us.  Cheswick and Bellovin’s landmark work “Firewalls and Internet Security” (Addison-Wesley , 1994) documented and cemented the concepts of the Internet perimeter, DMZ networks, and the placement of firewalls.  This work and the thinking of the time followed the paradigm of “us vs. them”.  This was probably appropriate for the time, back then many corporate network infrastructures did have something that could approximate a perimeter, a point or set of points on the network on one side of which all network connections were trusted, on the other side of which they weren’t.  That often amounted to the Internet on the outside and everything else on the inside.  But times changed, and the perimeter has slowly blurred to the point, in many organizations, where it simply doesn’t exist any longer.  How did that happen?  Let’s consider some of the services and connectivity most corporations now provide on their networks.

One of the biggest drivers for the blurring of the perimeter is the use of VPN technology.  For site-to-site VPN this essentially connects two remote networks into one.  In many cases this is easier to secure as a control can be applied to the single point of connection.  Client VPN is a different story.  Often provided for remote workers, ROHO/SOHO, remote and after hours technical support, vendor access, this provides a direct network connection between a remote workstation and one or more systems on the corporate network.  Due to the way it proliferates, it becomes much harder to control, as it has to be done on a host by host basis.  However as a corporation you generally have very little control over the machines at the other end of the connection.  For example unless you are providing workstations with locked down images you have only a modicum of control, and even then it isn’t fool proof.  How do you prevent remote workstations transmitting virus or worm code?  What about remote tunneling where the remote workstation acts as a router for other Internet traffic?  What if the remote machine is part of a Botnet or is otherwise “owned” and has remote command and control software on it?  Finally there is the issue of management of the remote users.  If this is for vendor support, does everyone at the vendor have a single username/password?  How do you get plugged into the vendor HR processes to manage account and passwords when there is turn over?

Even worse than VPN is the “Reverse VPN” type of service by vendors like GoToMyPC where individual internal users can setup their workstation on the internal network to make outbound connections which are then used to command and control the internal machine.  These services have all the same problems as with VPN, and this is even harder to control.  Even a proxy won’t work if the data stream is HTTP compliant.  Some you may be able to control with IP address filters, but not all and especially the deliberately malicious ones.  Try Googling “reverse www shell” sometime if you need something to keep you awake at night.  Various browser based, virus, and other exploits deliver remote command and control software that makes outbound connections.

Infrastructure and the deployment of applications and services can also blur the perimeter.  For example systems in a DMZ network that can make inbound connections to networks of higher trust levels can provide a route inbound for malicious traffic.  Consider how your DMZ application layer systems access back end databases.  Or how webmail machines are accessed (Outlook Web Access is a huge offender).  Another huge offender is Blackberry Enterprise Server.  This remotely accessible system, which has had numerous issues in the past, and which can provide remote access capability to mobile computers (Blackberries) is frequently on an internal trusted network.  Wireless networks can extend your internal network a mile or more depending on your equipment and the use of remote login services over the Internet potentially extends your corporate network across the globe.

There are many more examples of the blurring of the perimeter, hopefully these few have at least conveyed the message that focusing on securing the perimeter, while important, is not the complete solution.  A good exercise to determine if you might be relying on perimeter security too much is to print out your network diagrams, point at a system and say “That machine is compromised, now what?” Or ask yourself what happens when a vendor’s network is compromised and they connect to yours.   Remember (gratuitous Matrix reference) “Do not try and secure the perimeter.  That’s impossible.  Instead… only try to realize the truth….There is no perimeter”.

There is a pervasive, and fallacious, belief that the Internet is some sort of wild middle-ages like kingdom full of marauding Huns and Visigoths but that once we are behind the fortress walls (firewall) all is peace and safety.  Nothing could be further from the truth.  In fact as I often tell clients, your corporate network is less secure than the Internet.

To understand what I’m talking about it’s important to stop thinking in terms of the castle walls and the barbarians outside (although perhaps it’s not such a bad analogy in that as many castles fell from treachery and internal attacks as from direct assault).  It’s important to stop assuming that anyone connected to our internal network, e.g. our employees and possibly vendors, are trustworthy.  Recent studies have shown that a high percentage of IT workers (effectively the holders of the crown jewels in many companies) regularly access data inappropriately and that all types of staff members regularly steal data when they move on to another job and the news is full of stories of DMV, bank, or hospital workers selling personal information.

Frankly, there isn’t a company in existence that doesn’t have at least one disgruntled employee.  A rogue in the user community is bad enough, but when that employee is a system or database administrator it can be fatal.  Even if you are that one company where everybody is happy, studies have shown humans are incredibly creative in circumventing security controls they feel are onerous, and that might open the door to real attacks.  Then there are browser based attacks, some of which can provide an external attacker full command and control access to workstations on your internal network.  I will leave the issues of VPN and partner/vendor connections to another discussion, but these things can significantly blur the distinction between what is inside your castle walls and what is not.  The upshot is, even the devices plugged into your own network must be considered potentially suspect.

Due to the way the Internet is constructed, how traffic is routed, and the vast amount of data flowing, it is practically impossible to just “jack in” midstream somewhere in Internet-land and capture a specific communication or even communication to or from a particular host or network.  Even if the malicious Visigoth is an employee of an ISP or backbone carrier this task would be momentous.   Not so on your typical corporate network.  Hubbed networks, which send all traffic to all ports, are obviously bad, although most of these have been replaced.  However, most corporate networks have at most two security levels (DMZ and Internal) and a few VLANs on a shared switched fabric.  There are plenty of attacks against switches ranging from the crude, simply turning switches into hubs, to more sophisticated attacks that can pin point specific hosts and even connections and use moderately sophisticated (but still point and click) tools to intercept, monitor, or even insert commands and data into the communication.  These tools and techniques make every RJ45 in the office a potential place to sniff or modify data.  Even SSL may not be safe.

Now consider detection of malicious activity and response to it.  Most ISPs, and certainly all the major ones, have monitoring in place for large scale malicious traffic.  Anomalous traffic is watched carefully, and information is regularly exchanged with other carriers to enable threat updating and management of the bad guys.  Wide scale malicious traffic can be blocked, slowed, rerouted or otherwise dealt with based on pre-established protocol and leveraging pre-established relationships with law enforcement, other ISPs, and the security community.   These organizations have well developed and tested incident response plans, team members have been trained, and tools are provided.

Many businesses however do very little effective monitoring of anomalous traffic on the network.  At best there is a poorly placed and implemented umbrella IDS sensor.  Following the “barbarian at the gate” mentality this is typically located at the Internet or DMZ boundary, where it wouldn’t catch any internal issues anyway, and configured so that it becomes ineffective, a noise generator, and is eventually ignored.  While many excellent sources of monitoring data exist in the infrastructure, including logs from switches, routers, servers, and applications, they generally aren’t collected centrally or analyzed except possibly for performance and troubleshooting purposes.  In many cases they don’t ever leave the device that generated them, placing them directly at risk of modification by any attacker.  Without detection, incident response becomes almost moot.  But many businesses have no Incident Response Plan, or what they have is boilerplate, untested, and out of date.  Teams have not been established, or are poorly trained and have no dedicated tools.  What I find fascinating is that many of these organizations have solid, well tested and documented disaster recovery plans.  When I ask my clients to pull out their DR plan and lay it alongside their Incident Response plan the differences are clear.  When was the last time a DR test went perfectly after a major system or network change?  So why would you expect an untested Incident Response plan to be effective without testing and training.

So next time you hear about the big bad Internet and the swarming masses of attackers, start considering how many are on your corporate network.

Essentially it goes like this.  In 2004 BJ’s Wholesale Club’s ineffective information risk management lead them to first, store customer credit card data that they should not have been storing, and secondly not provide even a modicum of security around it.  Apparently the data was stored unencrypted, with default passwords, and limited or no monitoring.  All of which allowed the customer credit card data to be stolen.

BJ’s settled charges with the FTC “that it failed to provide adequate security for its customer data” in 2005.  BJ’s also recorded $10 million in related costs.  In addition to the $10 million, under terms of the settlement BJ’s will implement a comprehensive information security program and be subject to third-party audits every other year for the next two decades.

PSECU, a card issuer who suffered $100,000 loss reissuing suing cards to its effected members, sued BJ’s and Fifth Third Bank in 2005. The credit union lost at the district court.  The new ruling reverses the district court ruling and will allow Pennsylvania State Employees to continue with their case against BJ’s and Fifth Third Bank.  The ruling found that even though the credit union was not a direct party to the contracts between VISA, BJ’s, and Fifth Third, it has third party beneficiary rights.

I can understand PSECU suing BJ’s.  After all it was BJ’s inadequate security that led directly to PSECU’s loss.  However PSECU is claiming 5/3 bore some responsibility for inadequately training BJ’s staff.  It is completely beyond me why this is 5/3rds responsibility.  Nevertheless, this ruling could have far reaching consequences in the payment card industry by effectively making card processors responsible for the sins of their merchants.  It could possibly lead to changes in the PCI-DSS standards, to processor-required training programs, have insurance impacts, or even force processors into effectively “policing” the PCI compliance and information risk management practices of their merchants.

It will be interesting to see how the suit finally turns out.