Choose an area of interest:
Search 

Choose an area of interest:

Byte of Success
Overexposing Our Data


August 2005 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 a 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 that we have with customer loyalty makes 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 (CyberTrust.com). While each layer of policy, technique, and device may still have a known relatively small risk, the aggregated threat is reduced to infinitesimal percentages. To accomplish these layers, a combination of physical access, policies and 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 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. (Breach.com), demonstrates the value of innovative thinking about the tools challenge that I just mentioned. Recently, I spoke with Marc Shinbrood, CEO 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 versus 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 and then using publicly and sometimes experiential or privately known techniques, confidential data is pried out. In addition, the hacker is often learning about 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 of likely Web site visitors requires a proactive prevention and ideally 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 that the device understands the sincerity of the traffic as well as its conformity to expectations. This also means that this is an ongoing process rather than a static configuratable device. Finally, this means that 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?

More Byte of Success articles

CHAIM YUDKOWSKY, CPA, CITP, is Director of IT for the American Israel Public Affairs Committee (AIPAC) based in Washington, DC. He is also president of Byte of Success Inc., a technology consulting company specializing in helping small and mid-size business grow using technology. He is available for both consultation and speaking. He may be reached at cyudkowsky@byteofsuccess.com

2005 SmartPros Ltd. All rights reserved.

Related Stories
 
 
Connecting With Technology: A New Device Finds Fun and Value in Networking

Procurement Process Out of Control

Building an Online Community: The BBS and More

  Related Courses
 
Professional Education Center


 
Would you recommend this article?
5 (yes, highly)
4
3
2
1 (no, not at all)
Comments:


 
 
About SmartPros | Accounting Products | Professional Education | Marketing Services | Consulting | Engineering Products | Contact Us
2009 SmartPros Ltd.