LOGIN MAIL

• PRESS ROOMPUBLIC AREA
• STUDENTSCANDIDATES
• CONTACT USFIND A CPA
• HELPADVERTISE
• SEARCH SITE
  
• 901 Dulaney Valley Road | Suite 710 | Towson MD 21204 | 800.782.2036

• January / February
• March / April
• May / June
• July / August
• September / October
  • Maryland approves new ethics CPE requirement
  • Leading by example
  • Volunteers take center stage at MACPA's Annual Meeting
  • 2005 Maryland tax laws: An overview
  • Political aide
  • Number of accounting majors grows for third straight year
  • Four keys to setting — and achieving — your goals
  • Overexposing our data
• November / December

Overexposing our data

NOTE: Chaim Yudkowsky, CPA, CITP, is an MACPA member, director of IT for the American Israel Public Affairs Committee (AIPAC) in Washington, D.C., and president of Byte of Success Inc., a technology consulting company specializing in helping small and mid-size business grow by using technology.

By Chaim Yudkowsky, CPA, CITP

40 million. 3.9 million. 1.4 million. 1.2 million.

These are the millions of American credit card numbers that have been exposed by the major credit card processing company CitiFinancial, DSW Shoes and Bank of America, respectively.

For most of us, these numbers are gargantuan. Still, our smaller size and the poorer leverage we have with customer loyalty make us more vulnerable to the risks and impact of such exposure or worst. Our ability to recover from such attacks could be hopeless.

Starting point

How do we overcome this growing barrier to online commerce and transact with confidence? What techniques should we embrace?

• The security onion. Creating a multi-layered cocoon of security around the data repository of our organization mitigates that risk, according to industry expert Dr. Peter Tippett of Cybertrust. While each layer of policy, technique and device may still have a known (though relatively small) risk, the aggregated threat is reduced to infinitesimal percentages. To accomplish these layers, a combination of physical access, policies, procedures and virtual access strategies must be implemented and religiously abided by.
• Learn and understand regulation. Simply studying past attacks and examining the rhetoric of the media about them is not enough. Following vendor and user reactions to attacks is too reactive and sometimes too late. Increasingly, legislators are entering the domain of defining the ground rules, expectations, disclosure and even penalties for exposing any data. This is happening at all levels; local, state and federal governments are being attentive to this problem. The poor coordination between them means that sometimes there must be responses for each level.
• The basics. Processes, even before considering digital storage and handling, should always be in place for safeguarding personal or financial information of customers, patients, prospects and more. Automation or the anonymity that it encourages should not an excuse for not establishing these best business practices inside an organization. Where the information is stored, who has access to it, how it is disposed of when no longer necessary and when it is disposed of are issues that are easy to overlook in a data center, but they can be more mishandled in the paper byproduct of the system. For some industries, these are mandated under the guise of broader concerns impacting that industry like HIPAA.
• Use tools. Evaluating and navigating the options is difficult and confusing for most of us. Our Web sites are already subject to the network infrastructure people, and coordinating their perspectives with those of sales, marketing, application development and outside vendors can sometimes lead to more Tower-of-Babel-like consequences then a secure solution. Still, there are many tools that can help mitigate unpleasant exposure outcomes for even the smallest company.

The digital protections

BreachGate, manufactured by Breach Security, Inc., demonstrates the value of innovative thinking about the tools challenge that I just mentioned. I recently spoke with CEO Marc Shinbrood about how his solution transforms an approach to commerce Web site security breaches.

The following ideas, presented during our conversation, expand most popular thinking on protecting the digital access from the public Internet to our private data.

• Network vs. application attacks. First, we must understand the nature of our vulnerabilities. Network attacks are like drag-net fishing for the easiest fish in the water. These have a lower likelihood of yielding the type of data defined as identity theft quality.
  
  In many cases, the real data sensitive to the public is used within Web applications. These applications usually must be specifically targeted; then, using publicly and sometimes experiential or privately known techniques, confidential data is pried out. In addition, the hacker is often learning how to get at that data through an iterative albeit sometimes innocent-looking process.
  
  Consider two scenarios. In one, a burglar tests all the front doors of a neighborhood to see if one is unlocked. In this instance, he does not know what treasures he may find in the forgetful owner's house. In the other instance, the burglar knows of jewelry that he has learned of using investigative techniques and is considering how to break into the house and make his way into an alarmed safe in the bedroom with all tools at his disposal. The second instance is more targeted and more challenging to protect against.
• The non-obtrusive device. As network architecture governance and network design function has increased the bureaucracy of adding equipment to many of our networks (especially the guts involved with our public Web sites), security devices must be non-obtrusive. This means that while the device is not in-line (requiring the standard approval processes to be added to the network), it must act and protect as if it were in-line.
• Forensics is not good enough. As many of us are learning as we transition from intrusion detection to intrusion prevention devices on our network, we cannot afford to wait for history. Active attempts at breaches must be shut down as they happen. In fact, today's growing legislation about notification of suspected penetrations that resulted in loss of private or identity-oriented information requires a proactive prevention and record-level recording of any exposure. This can limit the scope of liability and extent of mandated public notification.
• Learned behavior. Our applications that are facing the Web have predictable patterns of use. Like children taught to avoid strangers and educated as to what constitutes a stranger, an anti-breach device looks for anomalist behavior. This involves specificity of record layer analysis and exit control inspection (comparing the data traffic as it enters and as it leaves) to make sure the device understands the sincerity of the traffic as well as its conformity to expectations. This also means this is an ongoing process rather than a static configurable device.
• Finally, this means the device must have a reasonable starting pool of traffic to learn what is acceptable and what is not. Low-transaction-volume Web sites are not as likely to benefit from this type of technology.

Our Web sites are typically not as safe as they should be and not as well protected as we believe them to be. How safe are your online transactions? Said differently, would you disclose your personal confidential information to your own Web site, or do you know better than that?