What The Target Data Breach Tells Us About Credit Processing Flaws

Don’t let Target fool you; the breach of magnetic stripe information from 40 million U.S. credit and debit cards, including debit PINs protected with breakable encryption, is a very big deal. The company’s crisis response has focused on regaining consumer confidence by convincing people that they are protected against fraud. It’s a legal confidence game, one in which the entire retail and financial services industries conspire to instill a sense of security where there is none. They want you to believe that they have our backs and will protect us from fraud. Do so at your own peril.

I don’t know what irritates me more, that we as consumers are so gullible as to place much of our financial health in the hands of companies built solely to extract as much wealth as possible from us or that the credit card data breach was predicted, repeated, and completely avoidable. Ignorance rules on both sides, and the consumer bears the majority of the expense.

How I Learned to Stop Worrying about Security and Love Incremental Development

This is a follow-up to my previous post: Agile Development and Security in Government.

The security authorization processes that U.S. Government agencies implement to comply with guidelines defined by the National Institute of Standards and Technology (NIST) fail to support incremental development methodologies like agile and spiral. Instead, I argue that they promote "big-bang" system releases that are impractical in contemporary budgetary conditions and generally seem to fail more than they succeed. Agency Chief Information Officers (CIOs) can fix the problem, but only if they reinvent their authorization processes and redefine process responsibilities.

Like Dr. Strangelove's bomb, agency Information System Security Managers (ISSMs) generally discount the importance of incremental development to streamlining government. When I met with a security policy executive at one agency to discuss a reconciliation between my project's agile incremental management methodology and the agency's security process, she was none-too-pleased with the notion.

"Projects use agile to bypass security requirements. I will not allow that to happen."

Agile Development and Security in Government

All IT domains continue to make broad use of incremental system and software development methodologies to improve the efficiency of deploying projects small and large. Those methodologies are even extending beyond traditional development to include system integration and program management. When it comes to the U.S. Government, though, there is one aspect of oversight that is preventing managers from making effective use of incremental methodologies: Security. While project teams share some blame by often actively and explicitly discounting security objectives (in my direct experience), I submit that the lion's share of the blame should fall on Information System Security Officers (ISSOs) and Managers (ISSMs).

The National Institute of Standards and Technology (NIST) has also failed to execute its mission to be "responsible for developing information standards and guidelines" in what I would consider a timely and effective manner in relation to incremental development methodologies. But, agency Chief Information Officers (CIOs) can meet legacy NIST guidelines, certify systems developed under those methodologies, and even improve security of their agency system, without running afoul of NIST guidelines, if only they were willing (and able) to make some strategic changes in how they manage system security compliance activities.

The Critical Need for Liberal Arts in Security

"As we strive to create a more civil public discourse, a more adaptable and creative workforce, and a more secure nation, the humanities and social sciences are at the heart of the matter, the keeper of the republic - a source of national memory and civic vigor, cultural understanding and communication, individual fulfillment and the ideals we hold in common."

- The Heart of the Matter: The Humanities and Social Sciences for a vibrant, competitive, and secure nation; American Academy of Arts & Sciences; Retrieved on June 21, 2013 from http://www.amacad.org.

Security professionals often state that security is an art, not a science. This field demands a certain degree of finesse, elegance, imagination, creativity, and a find-grained understanding of technology. We characterize the act of securing assets and information as finding the right balance between people, process, and technology, the security triumvirate. Yet, look at any job posting in security over the past 15 years (about the duration of time that I've worked in the field), and you find this:

Education: Degree in Computer Science, Mathematics, or any comparable field.

Two-Step Verification (2SV) is not Two-Factor Authentication (2FA)

This week, Twitter became the most recent online service to move to 2-Step Verification (2SV). One high-profile intrusion recently sent stocks spiraling when an attacker posted false news of a White House bombing after gaining access to the Associated Press Twitter account (@AP) through a successful phishing attack. While Twitter had been reportedly working on a new authentication solution, the AP event likely accelerated those efforts.

Following Twitter's announcement, the media and supposed security industry pros once again continued to perpetuate confusion over what constitutes "Authentication" versus what constitutes "Verification." Bloggers over at CNET provide two fine examples of this confusion just yesterday in response to the Twitter news. First, at 2:44 PM PDT on May 23 (time stamped as of 5:00 AM PDT on May 24), Jason Cipriani posted, How to use Google Voice with two-step authentication. Shortly thereafter, at 5:29 PST (time stamped as of 5:00 AM PDT on May 24), Seth Rosenblatt posted, Two-factor authentication: What you need to know (FAQ). Jim Fenton, the Chief Security Officer for OneID, a company that doesn't even address either 2FA or 2SV, has the industry credentials to seem reputable, but fails to effectively convey the difference between the two methods in his recent posting, Two-factor authentication is a false sense of security.

Look around a little deeper at the companies that are implementing similar solutions, and the vocabulary remains a bit inconsistent. 

The (Mis)Perception of Safety

Yesterday, I was fascinated by the fact that my kids were so enthralled by the athleticism and spirit shown by the runners in the Boston Marathon that once they returned home from watching the race, they hosted their own "marathon" in our back yard, complete with number sheets taped to their shirts. They were oblivious to the tragedy that had occurred, innocence retained despite it's loss elsewhere. I tend to think my fascination humanizes me a little.

Being a security professional during catastrophic human events such as the Boston Marathon Bombing is a sobering position. At times manic with grief and disbelief, and at others a bit calculating and analytical, I can probably come off as standoffish at best, inhumane at worst. I accept the perception that others have of me but I would argue coming from a reasonable perspective is the best way to counter irrational acts of violence.

Cloud Computing Dangers: Just Forget About It

This is the final posting (Part 10) of the Case Study in Cloud Computing Dangers.

By the end May 15, Day 7 of our outgoing mail Denial-of-Service on Office 365, on May 15, 2012, everything returned to normal. I was thrilled to find my VA email address flooded with test messages from over the preceding week.

Relief. And then, nothing.

We received no update from Microsoft, no communication from senderbase.org/Cisco, no satisfactory closure of any help desk tickets. Nothing, except for business as usual.