Tom Olzak

Posts Tagged ‘PCI DSS’

Blame the auditors: What a concept!

In Business Continuity, Data Security, Network Security, PCI DSS, Risk Management, Security Management on August 13, 2009 at 08:02

I have never thought of this.  After a breach, just blame the auditors.  Wait.  The reason I hadn’t thought of it is because passing a compliance audit IS NOT ASSURANCE OF SECURITY.  But some still don’t get it.

In an interview with CSO’s Bill Brenner, Heartland Payment Systems’ CEO, Robert Carr, blamed his QSA auditors for a recent (huge) breach.  Because they said his organization was PCI compliant, he felt secure.  Wow.  Security by checklist once again.

Rich Mogull, in an open letter to Carr, makes several excellent points about reliance on compliance instead of solid security practices.  He concludes his letter with,

But, based on your prior public statements and this interview, you appear to be shifting the blame to the card companies, your QSA, and the PCI Council. From what’s been released, your organization was breached using known attack techniques that were preventable using well-understood security controls.

As the senior corporate officer for Heartland, that responsibility was yours.

Source: An Open Letter to Robert Carr, CEO or Heartland Payment Systems, Rich Mogull, 12 August 2009

Rich’s letter is a good read, and it should be circulated widely among security professionals and senior executives. 

Among other things, this is another case where an organization is falling back on a completed checklist representing compliance with the PCI standard, a bare minimum set of security requirements.  But whether you are HIPAA, GLBA, or PCI compliant, checking off on recommended practices doesn’t equal security.

Each of us is responsible for placing compliance activities within the proper context: guidelines within a broader security program.  No regulatory or industry standards can protect our critical infrastructure or sensitive data.  Only an aware, thinking human who actually cares about security—and understands how standards apply within his or her unique environment—can do that.

System physical security should include mobile device asset management

In Access Controls, HIPAA, Physical Security, Piracy Legislation on May 27, 2009 at 21:43

Some organizations spend a lot of time worrying about administrative (policies) and logical (application and system electronic) access controls without much concern for physical security.  I don’t mean the kind of physical security where you make sure your data center is locked.  I mean the kind of security which allows you to track who has your resources and ensures your organization takes the right steps to quickly mitigate impact.

For example, it doesn’t make much sense to lock the data center when unencrypted, unmanaged mobile devices travel across the country.  The sensitive information stored safely in the data center might as well be in the lobby.  This might seem a basic principle, but many organizations still don’t get it.  Take the US Department of the Interior, for example.  According to a report completed last month by the department’s inspector general, Western Region,

…13 computers were missing and… nearly 20 percent of more than 2,500 computers sampled could not be specifically located.  Compounded by the Department’s lack of computer accountability, its absence of encryption requirements leaves the Department vulnerable to sensitive and personally identifiable information being lost, stolen, or misused.

Source: Evaluation of the Department of the Interior’s Accountability of Desktop and Laptop Computers and their Sensitive Data, U.S. Department of the Interior, Office of the Inspector General, 24 April 2009.

So the IG could verify the loss of 13 unencrypted computers, but about 500 were simply unaccounted for.  The reason? Several of the agencies within the department had no process to track computer inventory.  The following is from a related InternetWorld article:

Despite policies mandated by the Federal Information Systems Management Act and other regulations, including rules that say computers should not be left unattended in plain view and that organizations should establish policies to protect their systems from unauthorized access, the Department of the Interior doesn’t require that any hardware that costs less than $5,000 — that would cover most PCs — be tracked in an asset management system, and the current tracking system doesn’t have proper backing, according to the report.

Source: Department Of The Interior Can’t Locate Many PCs, J. Nicholas Hoover, InformationWeek, 27 April 2009

Most of us agree that encryption is a necessary part of any mobile device security strategy.  But why worry about tracking laptops?  Isn’t encryption enough to render the data on a lost or stolen laptop inaccessible?  Well, it depends.

Many organizations do not use strong passwords.  The reasons vary, including:

  • Users tend to write complex passwords down, leaving then easily accessible
  • Password reset calls constitute a high percentage of help desk calls, rising exponentially as password complexity increases

In other words, strong passwords are often seen as weaker and more costly to the business than simple passwords.  And password complexity tends to remain the same when an organization implements full disk encryption, raising concern about the real effectiveness of scrambling sensitive information.  The complexity of the password and the configuration of the login policy (i.e., history, failed login attempt, etc.) are factors in the strength of any encryption solution.  In any case, encryption solutions should be supplemented to some degree—depending on the organization—by a mobile device physical management process, including,

  • Mobile device assignment process which includes recording employee name and date of assignation
  • Clearly documented mobile device usage and protection policy signed by each employee before he or she receives a mobile device
  • Periodic, random verification that the assigned user still has physical control of the device
  • Strict employee termination process which includes receipt of assigned devices
  • Documented device end-of-life process, including
    • recording receipt of device
    • recording of device disposition, in accordance with the organization’s media sanitation and reuse policy
  • Tested and documented device loss process, including
    • process for reporting a mobile device lost or stolen
    • assessment of the probability of sensitive data breach and notification of affected individuals

Wobbly Security Frameworks are Often Fixed by Turning a Few Screws

In Risk Management, Security Management on May 15, 2009 at 14:00

As security management becomes more integrated into business processes, it’s commonly seen as closely related to risk management.  This is an accurate perspective, as security professionals position controls as ways to mitigate negative business events.  But risk seen in this way is often used as a monolithic tool used to hammer home reasons why executive management should spend more money on security.  Risk is actually an aggregate of many smaller factors which must be addressed if the business is to be adequately protected.  These smaller factors are often without cost in real dollars, and fixing them is a prerequisite for implementing more advanced controls.

Risk Defined

My take on risk is a little different from what you might be used to seeing.  I first start with a standard formulaic model and expand a little, as shown below.

Formula 

Threats are pretty easy to understand when viewed in terms of all the ways people, malware in the wild, and nature can ruin a perfectly peaceful afternoon.  We’ll cover vulnerabilities later.  Target Value is defined in terms of either it’s criticality to the business or its sensitivity.  Sensitive systems and data typically include intellectual property, PII, or ePHI.  Finally, Response is a measure of how well an organization can detect, identify, contain a threat and recover from a security incident.  As shown in the formula, the effectiveness of an organization’s response directly impacts its overall risk. 

This is all very interesting, and it should be pretty familiar to most of you.  But there is another way of looking at risk which helps identify fundamental weaknesses in a security framework.

The Layered Risk Model

The layered risk model is something I use to identify the small things I may have overlooked.  It’s important to fix all the little things, things which taken all together can lower the ROI gained from implementation of sophisticated layered controls. 

Layered Risk Model

In this diagram, risk is depicted as an aggregate of factors contained within four layers.  Each layer has its own level of risk, depending on how well elements within it are managed and what controls might be in place.  Although all are important, I’m focusing on the second layer (from the bottom) for the rest of this article.  For more information about the other risk factors, see A Practical Approach to Managing Information System Risk.

The Little Stuff

Since threats and vulnerabilities together comprise Probability of Occurrence, adjustment of either reduces the possibility of a successful attack.  We have little control over threats, so vulnerability management is our best option.  As you can see from this example, vulnerabilities exist in many forms.

In this particular model, I listed some basic security holes which I call the “little stuff.”  Little stuff in the sense each by itself may be a small vulnerability and is something which is easily addressed.  Together, however, they form a formidable vulnerability layer, easily exploitable by the right attacker.  They are also easily avoided by following fundamental security best practices. 

As the title of this piece infers, tightening a few screws–paying attention to the little stuff–can strengthen your overall control framework.  Once the wobbling ends, you can achieve a better understanding of actual gaps.

Fear, Trust, and Desire: Fertile ground for social engineers

In Business Continuity, Content Filtering, Cybercrime, Data Security, HIPAA, Network Security, PCI DSS, Risk Management on April 10, 2009 at 09:42

According to the recently released Microsoft Security Intelligence Report (2H2008), social engineering is taking the lead as the preferred method of network and end-user device malware infection.  Since operating system vulnerabilities are slowly disappearing and more organizations are implementing basic network controls, the easiest way to a target system is via the end-user.

Fear, Trust, and Desire (FTD)

According to the Microsoft SIR, users fall prey to social engineering attacks because of three common modes of human behavior: fear, trust, and desire.  As depicted in Figure 1, each of these behaviors is targeted by specially crafted attacks.

 

Figure 1 (Microsoft SIR)

Read the rest of this entry »

PCI DSS is a get out of jail free card

In Business Continuity, Cybercrime, Data Security, PCI DSS, Piracy Legislation, Risk Management on April 2, 2009 at 08:21

The problem with security standards is they often are a get out of jail free card for organizations which believe in doing only the bare minimum necessary to stay out of trouble.  Some standards, like the PCI DSS, add some value when protecting sensitive information, but they don’t go far enough.  They become something management can point to and say, “See.  We’re secure.”

Apparently it takes a congressional hearing to sort this out.

The PCI standard, long touted as one of the private sector’s best attempts to regulate itself on data security, is increasingly showing signs of coming apart at the seams.

At a hearing in the U.S. House of Representatives Wednesday, federal lawmakers and representatives of the retail industry challenged the effectiveness of the PCI rules, which are formally known as the Payment Card Industry Data Security Standard (PCI DSS). They claimed that the standard, which was created by the major credit card companies for use by all organizations that accept credit and debit card transactions, is overly complex and has done little thus far to stop payment-card data thefts and fraud.

Source: PCI security standard gets flayed at House hearing, Jaikumar Vijayan, Computerworld, 1 April 2009

No, Congress is certainly not the right body to control cybersecurity.  However, in this case I think they got it right by simply stating the obvious.

%d bloggers like this: