Category Archives: Technology

rug salesmen

Why your IT vendor doesn’t want you to do a risk analysis

Did you ever have a feeling that your IT integrator was treating you like a couple of guys selling you a Persian rug?  “Take it now – it’s so beautfiful, just perfect for your living room, a steal  for only $10,000 and it’s on sale” and when you ask if it will last, they tell you “Why do you want it to last? Enjoy, use it in good health, wear it out quickly and come back to the store so that we can sell you Persian Rug 2012”.

I had a meeting with a long-time client today – I’ve developed some systems for them in the FDA regulatory and clinical trial management space. We met for lunch to discuss a new project which involved an extension to an existing multi-center study.

The question of disaster recovery planning and offsite backup came up and  they asked me what I thought about backing up their clinical trial data together with their office file backups taken by their outsourcing IT provider.

I said this is a very bad idea because while their IT contractor specializes in providing Microsoft Windows/Office support for small businesses, they just don’t have the know-how or security expertise for HIPAA compliant data storage.

In general, small business IT integrators are  behind the curve on data security, compliance, disaster recovery and application software security. Their job is to keep Microsoft SBS running smoothly and install anti-virus software, not mitigate data security and HIPAA compliance attacks. The typical SMB integrator mindset is dominated by the Microsoft monoculture, and I would not expect them to be able to analyze data security threats correctly.

Whenever I go somewhere – I’m always looking at things with a security perspective – open doors, windows – things that could be easily lifted. Who might be a threat. Storing clinical data with a bunch of Microsoft Office files is just too big a risk to take. The CEO accepted my recommendation to encrypt data on a secure, hardened virtual server instance in the cloud and monitor potential exposure to new emerging threats as their application and project portfolio evolves.

After lunch and getting back into the office, I realized that Risk analysis is a threat to IT vendors.

Not every security countermeasure is effective or even relevant for your company. This is definitely a threat to an IT vendor salesperson who must make quota.

I am a big proponent of putting vendor suggestions aside and taking some time to perform a business threat analysis (shameless plug for our business threat analysis services,  download our free white paper and learn more about Business Threat Modeling and security management). In a business threat  analysis you ignore technology for a week or 2 and systematically collect assets, threats, vulnerabilities …and THEN examine the cost-effective security countermeasures.

Your vendor wants to sell you a fancy $20,000 application security/database firewall, but it may turn out that your top vulnerability is from 10 contract field service engineers who shlep your company’s source code on their notebook computers. You can mitigate the risk of a stolen notebook by installing a simple security countermeasure – Free open-source disk encryption software for Windows Vista/XP, Mac OS X, and Linux.

Information security vendors often promote their backup/data loss prevention/data retention/application security products using a compliance boogeyman.

The marketing communications often reaches levels of the absurd as we can see in the following example:

NetClarity (which is a NAC appliance) claims that it provides “IT Compliance Automation” and that it “Generates regulatory compliance gap analysis and differential compliance reports” and “self-assessment, auditing and policy builder tools for Visa/Mastercard PCI, GLBA (sic), HIPAA, CFR21-FDA-11,SOX-404, EO13231 government and international (ISO270001/17799) compliance.”

A network access control appliance is hardly an appropriate tool for compliance gap analysis but asserting that a NAC appliance or Web application firewall automates SOX 404 compliance is absurd.

Sarbanes-Oxley Section 404, requires management and the external auditor to report on the adequacy of the company’s internal control over financial reporting. This means that a company has to audit, document and test important financial reporting manual and automated controls. I remember the CEO of a client a few years ago insisting that he would not accept any financial reports from his accounting department unless they were automatic output from the General Ledger system – he would not accept Excel spreadsheets from his controller, since he knew that the data could be massaged and fudged. If there was a bug in the GL or missing / incorrect postings he wanted to fix the problem not cut and paste it.

Appropriate, timely and accurate financial reporting has absolutely nothing to do with network access control.

But the best part is the piece on the NetClarity Web site that claims that their product will help “Deter auditors from finding and writing up IT Security flaws on your network”.

And I suppose this really proves my point best of all.

Information security vendors like NetClarity do not have any economic incentive to really reduce data security and compliance breaches that would reduce  sales, making it better business for them  (not for their customers) to sell ineffective products.

This raises an interesting question about information security business models – but that’s a topic best left to another post.


Tell your friends and colleagues about us. Thanks!
Share this

The importance of data collection in a risk assessment

A risk assessment of a business always starts with data collection. The end objective is identifying and then implementing a corrective action plan that will improve data security in a cost-effective way, that is the right fit for the business.

The question in any risk assessment is how do you get from point A (current state) to point B (cost effective security that is the right fit for your business).

The key to cost-effective security is data collection.  Let’s recall that compliance regulation like PCI DSS 2 and the certifiable information security management standard ISO 27001 are based on fixed control frameworks. It’s easy to turn the risk analysis exercise into a check this/check that exercise, which by definition, is not guaranteed to get you to point B since the standard was never designed for your business. This is where we see the difference between ISO 27001 and ISO 27002.

ISO/IEC 27002 is an advisory standard meant to be applied to any type and size of business according to the particular security risks they face.

ISO/IEC 27001 (Information technology – Security techniques – Information security management systems – Requirements) is a certifiable standard. ISO/IEC 27001 specifies a number of firm requirements for establishing, implementing, maintaining and improving an ISMS (information security management standard), and specifies a set of 133 information security controls. These controls are derived from and aligned with ISO/IEC 27002 – this enables a business to implement the security controls that fit their business,and help them prepare for formal certification to ISO 27001.

Let me explain the importance of data collection by telling a story.

After reading this article in the NY Times  An Annual Report on one mans life, I was reminded about a story I read about Rabbi Joseph Horowitz (the “Alter from Novardok”) (1849–1919), relating his practice of writing a daily report on his life.

One of the things I learned from the musical director of the JP Big Band, Eli Benacot, is the importance of knowing where you are really holding in terms of your musical capabilities.  Many musicians, it turns out, have the wrong self-perception of their capabilities.  Sometimes, one sees a professional musician who is convinced of his proficiency and even within an ensemble he (or she) is incapable of really hearing how poorly they actually play.

Many times we feel secure but are not, or don’t feel secure when we really are. For example – a company may feel secure behind a well-maintained firewall but if employees are bringing smart phones and flash drives to work, this is an attack vector which may result in a high level of data loss risk. On the other hand – some people are afraid of flying and would prefer to drive, when in fact, flying is much safer than driving.

After we collect the data and organize it in a clear way, we then have the ability to understand where we are really holding.  That is the first step to building the correct security portfolio.

So, let’s return to the Rabbi Joseph Horowitz, who wrote a daily and annual report on his life. Here is his insight to implementing change – certainly a startling approach for information technology professionals who are used to incremental, controlled change:

“Imagine this scenario: A person decides that he wants to kasher his kitchen. But he claims, ‘Changing my dishes all at once involves throwing out an entire set and buying a brand new one. That’s quite an expense at one time. I’ll go about the kashering step by step. Today I’ll throw out one plate and replace it with a new one, tomorrow with a second and the next day with a third.’

“Of course, once a new plate is mixed with the old ones, it becomes treife like the rest. To kasher a kitchen, one must throw out all of his old dishes at once.

“The same holds true in respect to changing one’s character traits or way of life. One must change them in an instant because there is no guarantee that the anxieties and pressures that deter him on any given day will not deter him the following day, too, since anxieties and pressures are never ending. ”

(Madreigat Ha’adam, Rav Yosef Yoizel Horowitz).


Tell your friends and colleagues about us. Thanks!
Share this

The emotional content of security

I think in the security space, we spend too much time on the business justification and functional part of security (reducing risk, detection data breach violations, complying with HIPAA,  writing secure Web 2.0 applications, securing cloud services, security information management etc…).

I think we’re ignoring the emotional content of security and I don’t necessarily mean FUD (fear uncertainty and doubt).

Perhaps it’s time to reconstruct market boundaries of the security industry.

At the beginning, there was the notion of “selling security with FUD“, starting with anti-virus and peaking in the early 90s with the outbreak of RPC worms on Wall Street. It was pretty easy to sell security with FUD tactics. Then we had 9/11.   You couldn’t frighten people anymore.   Security FUD doesn’t work when the customer thinks he might be killed by an Al Qaeda or Hamas or Fatah terrorist.

Then there was the “selling security as an enabler” play, sponsored by Gartner, ISACA and a bunch of other people.  This sort of made sense – but the number of real use cases where security actually enables new business (VPN, secure ecommerce sites) is rather limited and besides, the big IT vendors can build (or at least purport to build) security into their products. Educating customers on “security as a business enabler” is a wonderful example of how market education  pays off at the beginning of a new product life-cycle launch, but low or no benefits at all when the product has mainstreamed into general market acceptance and everyone is selling and buying.

A good example of a product that mainstreamed extremely quickly is the Apple iPad,  Now after CES  we have dozens of mobile tablets, Android tablets, Windows Mobile tablets, Ubuntu tablets alternatives of all shapes, sizes and qualities. No one is questioning that a tablet is a great thing – Apple already did the market education for the other vendors.

Market education of  CEOs to the business  advantages of data security is like motherhood and apple pie, it’s a good thing. Similar to the tablet PC case, however, this sort of market education has zero or low ROI – because the CEO has already decided to buy or not buy security based on what someone else said – whether its’ Perot Outsourcing services, IBM, Oracle or his golf-partner.

Consultants explaining to a CEO that security is a business enabler are selling the same security coolade as Oracle, IBM, ISACA and SAP. The only problem is that a security  consultant doesn’t sell a product, but bolt-on/after sale services – and generally doesn’t get compensated for his deep security insights over coffee.

Let’s note that the information security industry is an industry like most other industries:

  • They define their industry similarly, focusing on being the best.
  • They look at accepted strategic groups of buyer and market segments, for example CSOs and firewalls
  • They focus on the same buyer groups – e.g influencers (security officers, CIOs, analysts and thought leaders)
  • They define the scope of products similarly- data security, firewalls, DLP, software security assessments etc..
  • They focus on the same point in time and current competitive threats in formulating strategy; now it’s cloud, last year was DLP etc…

But there is one factor we are missing and that is emotion:

Does the security industry accept the functional/emotional orientation of their buyers?

I’m not sure.  And that – will be the topic for the next post

Tell your friends and colleagues about us. Thanks!
Share this

How to convert a web application to a multi-tenant SaaS solution

Of course, putting an application into a cloud data center is not enough. You have to think about application security, data security and compliance such as PCI DSS 2.0 or HIPAA if you are in the life science space.

But – in addition to cloud security, you need to make sure that your Web application is multi-tenant, i.e. that  you can support multiple customers in the same application, otherwise, the entire model is not going to scale very well.

You’ve built a single-tenant web-enabled application, but need to make it compatible with and effective in a cloud environment. What steps do you need to take to convert your application to a full-fledged, multi-tenant, cloud-ready SaaS application?

This article from IBM is a good checklist on How to convert a web application to a multi-tenant SaaS solution

Tell your friends and colleagues about us. Thanks!
Share this

Customer security with software security

If you are an IT person, this article may be a waste of your time. But – if you are in the business of making and delivering products with software inside – read on.

What threats really count for your business?
No question is more important for implementing an effective security and compliance program for your product development. The management, the software developers and security analysts cannot expect to mitigate risk effectively without knowing the sources and cost of threats to company products and the products’ users.

The prevailing IT security model predicates defense in depth of IT systems. The most common strategies are to mitigate external threats with network and application security products that are reactive countermeasures; blocking network ports and services, detecting known application exploits, or by blocking entry of malicious code to the network. Are any of these security countermeasures likely to be effective in the long-term for software applications and software-based appliances? Can attacks on a software product be neutralized with defensive means only? In other words, is there a “black-box” security solution for your products?

The answer is clearly no.

A reactive network defense tool such as a firewall cannot protect exploitation of software defects and an application firewall is no replacement for in-depth understanding of company-specific source code or product configuration vulnerabilities.
This paper presents a rigorous software development process for delivering secure software product starting with a simple notion – “buggy software is insecure software”.

By removing software defects we are in the best position to deliver secure software to our customers.

Download the full article Make your business secure by making your software secure

Tell your friends and colleagues about us. Thanks!
Share this

Securing Web services in the cloud

Almost every SaaS (software as a service) is based on REST or XML Web services.  In this post, I’d like to provide a brief introduction to some typical threats and security countermeasures to protect Web services;

Malicious Attack on the message

The beauty of  HTTP Web Services is that traffic flows through port 80 and port 443 and it uses a human-readable format (XML or JSON). This is also the key vulnerability.  A typical IT / system administration approach that relies on protecting Web service providers with a firewall/IPS setup is not very effective.  We will explain why.

Firewalls do a good job of port monitoring and recognizing brute force malicious attack but are not good at being able to view the content of messages in order to detect and prevent more sophisticated security compromises. While most firewalls can recognize SOAP as well-formed HTTP traffic they cannot inspect the actual content of the SOAP message or JSON data. Web Services interfaces are much more complex than Web site interfaces which exchange HTML pages and forms. Web service interfaces are like software API’s and expose database functionality. In addition, an attacker has more information available to them. The message is often self-describing and clearly shows the data elements.

A Web service provider is a juicy, self-describing target.

Replay Attack
Similar to Denial of Service, replay attacks involve copying valid messages and repeatedly sending them to a service. Similar techniques for detecting and handling Denial of Service can be applied towards replay attacks. In some ways, replay attacks are easier to detect with Web Services because payload information is more readily available. With the right tools, patterns can be detected more easily even if the same or similar payload is being sent across multiple mediums like HTTP, HTTPS, SMTP, etc.

Buffer Overflow
An attacker can send a parameter that is longer than the program can handle, causing the service to crash or for the system to execute undesired code supplied by the attacker. A typical method of attack is to send an overly long request, for instance, a password with many more characters than expected. Similar to buffer overflow attacks; hackers often send malformed content to produce a similar effect. Sending in strings such as quotes, open parentheses and wildcards can often confuse a Web Service interface.

Dictionary Attack
Dictionary attacks are common where a hacker may either manually or programmatically guess passwords to gain entry into the system. Administrators should ensure that passwords are difficult to guess and are changed often.

Intrusion Detection of attacks by malicious outsiders
Proactively securing all of the possible misuses of Web Services is almost impossible. Security policies and strict access control management should help reduce the occurrence of intrusion. An IPS will detect anomalous attack behavior and if monitored may help the security team mitigate the threat.

Extrusion detection of attacks by trusted insiders
Attackers are usually thought to be outside of the organization. However, most security breaches occur from within the organization. With Web Services, more functionality is available to a more people. Access to confidential information or embezzlement of funds is just some of the possible internal security breaches that can be performed by employees or former employees. Because employees are the most familiar with internal systems, detection can be made extremely difficult. Unintentional compromises are also possible. If an interface is unsecured, an employee may accidentally access information that they are not intended to view. Since Firewalls are insufficient for data breach, we would require use of a DLP –  Data loss  prevention system such as Fidelis XPS or WebSense DLP.

Threat containment
Once a security breach is detected, being able to shut down systems and reject traffic from specific sources are important for handling a compromise.  A DLP system provides real-time detection, forensics recording and  the ability to drop traffic from specific IP source addresses in order to properly mitigate the threat.

Tell your friends and colleagues about us. Thanks!
Share this

DimDim acquired by

Got back from my Friday morning bike ride and popped open my Inbox. Lo and behold – exciting M&A news first thing in the day.

Dear Enterprise Customer::

As you may have already heard, Dimdim has been acquired by  We realize you may be wondering what this means for you.

While your Dimdim Enterprise service will remain fully operational during the life of your current contract, we will discontinue the service on the date the contract expires and will not be offering any renewals or extensions.

Pursuant to the Hosted Enterprise Agreement (the “Agreement”) between you (“You”) and Dimdim, Inc. (“Dimdim”) governing the provision and use of Dimdim’s Services (as defined under the Agreement), Dimdim is hereby exercising its option not to renew the Agreement after the expiration of the current term (either the Initial Term or current Renewal Term, as applicable, and referred to herein as the “Term”). For clarity, the Agreement shall not automatically renew nor may the Term be extended at Your request. Nothing herein is intended by Dimdim to diminish or waive the rights or obligations of either party under the Agreement until the expiration of the Term. Following the expiration of the Term, except for any confidentiality obligations under the Agreement that expressly survive termination of the Agreement, neither You nor Dimdim shall have any further rights or obligations of any kind under the Agreement, including the right to access or receive any Software, Services or Technical Support as defined therein.

I have always thought that client-less Web conferencing was a great idea and DimDim was pretty good software, although the Open Source part of it turned out to be marketing spin (they never really stood behind the project).  Although the opportunity for leveraging an innovative Open Source project seems to have gone by the wayside, perhaps the acquisition opens a new space of business opportunities for Facebook style applications with Web conferencing and collaboration on the platform .

Time will tell.

Tell your friends and colleagues about us. Thanks!
Share this

Software security assessments

In a way, every software security assessment is an exercise in software development. The first step in the software security assessment project is requirements analysis. Requirements analysis is concerned with what the system (whether it be a “traditional” application or a rich Web 2.0 application for social networking) needs to do. This involves examining the requirements of the business itself, the users of the application against the backdrop of cost and engineering constraints such as throughput and response time when the application is deployed on a cloud computing platform.

Business Requirements

  • Business Requirements analysis – Describe the business and its it’s customers, suppliers and users, problems, issues and expectations. This is essential when developing a new application, but also crucial when you’’re making significant changes to an application. “Why” do you want to develop the software and “how much” is it going to cost? Is there a ROI (return on investment). Can your team develop and implement the product?
  • P.I.E – – Problems Issues and Expectations – Describe current problems and put the issues and expectations that users have in the current environment into separate categories. An expectation may be crucial to success of the project or it may be a “user satisfaction” feature that can be postponed to Revision 9.5
  • Causes and Consequences – Discuss causes of current system problems and their consequences. You will discover that a problem’s result is often a problem in it’s own right. You need to drill down to the root cause of the problem peeling away the symptoms.
  • Target system tasks – Discuss and observe users as they work with the software application. Remember that the important things are (a) how easy it is to install/start using a product (b) how fast it works and c) how intuitive is the UI. This is particularly relevant to Web-based applications, where the user experience will make or break the application.
  • System Design Alternatives Analysis – Very few systems are new. In alternatives analysis you will consider the strengths and weaknesses of existing approaches including not doing the project at all.

Software security requirements

A business requirements analysis is not enough to ensure that a system meets the real needs of its users or that it will ever succeed in the real world as a product. In fact, reducing a system specification to a set of required functions, without regard to how the functions are used or how they will be implemented in real hardware/software by real people is a guarantee for failure . The design of a new system or major change will usually involve the following steps:

  • Task Decomposition – Business requirements are broken down and mapped into software and hardware modules and features.
  • User stories– A “user story” corresponds to a feature of a system module. Stories are small, typically limited by an estimate to implement the software for a story by one programmer working for one week. The user story needs to stay in sync with the business requirements – and stay away from gold-plating.
  • Data Modeling – Data modeling describes the data elements in the assessed system and the relationships between the data elements. Done in parallel to developing the “user stories” and ensures that the data needed to do the job is on the model.
  • User Interface Design – The user interface needs to be considered at an early stage in the software security assessment cycle. Functional requirements are combined with the knowledge gathered about users and contexts of use to provide the most appropriate methods of interaction.
  • Incremental assessment by prototyping – Assess a little piece of the system with selected routines and a  UI.  Security assessment prototyping allows vulnerability hypotheses to be tested, with resulting feedback incorporated into an iterative process of software defect reduction. Early prototypes may be purely paper-based to test the design or using a the application to test the software in vitro.
Tell your friends and colleagues about us. Thanks!
Share this

The 7 deadly sins of software security

Companies spend millions on compliance, but proprietary assets are still getting ripped off by insiders and hackers who compromise buggy, poor-designed applications. Here are 7 software development mistakes you don’t want to make in 2011.

7. Don’t KISS

If my experience is any indication – the software industry as a whole is wasting hundreds of millions of dollars a year by not Keeping It Simple. For example, complex technologies like Java J2EE are not warranted for the majority of Web applications. In my experience PHP is simpler to program and maintain, and scales well at a reasonable price – witness the millions of Yahoo pages are served by PHP each day. Lack of KISS is the main reason for high-costs, late schedules, failed projects and unsecure software that no one can maintain. When a programmer uses a component and doesn’t know it works (see EJBQL and CMP 2.0) and has to shlep around a lot of piping (look at an Eclipse project for a 3 tier J2EE project) then the energies go into implementation instead of thinking about code threats. It’s sort of like Microsoft Powerpoint, where you spend 80% of your time in the application’s GUI instead thinking about and then just stating your message.

Seems to me that the industry is trading off simpler, reliable and secure programming for fashion and features (J2EE,XP…)

6. Mismanage software development

The classic The Mythical Man-Month, written 20 years ago said that projects based on per-unit “man-months” usually dont work due to the unique nature of software development. The difference in productivity between the best programmer and an average guy is 100x. This means that 5 nwe college grads are inferior to solid programmer who knows what she’s doing. You are always better off with a few talented programmers than a large cast of average developers, a) because of individual productivity differentials and b) because smaller groups are always more effective.

This general observation is relevant to our case since the average developer construes O/S security with applying patches and application security with having an application firewall. Truth be told, it only takes one page of best practices for a Web application programmer not to allow SQL injection, long URLs, arbitrarily long input strings or directory traversal.

5. Take a wrong turn with outsourcing

Don’t outsource something just because it’s too hard to understand or you’re in a rush to market. A server clustering system offered by a major vendor was ported a while back to Linux by a team in India. The Indian market was booming and job loyalty was low, like Israel and Silicon Valley in the 90’s. In addition, due to transportation and cultural issues the work day was a fixed 8 hours not a “finish before you go home/never break the build” philosophy. The software was ported and is being delivered to customers with cryptic documentation, patch on patch on patch, multiple options to perform the same function (only one of which may be right, so the customer has to guess because documentation is unclear) and brittle functionality – a small change in configuration files can break the cluster.

Brittleness and poor documentation force the user to rely on strict manual operational procedures which depend on people which creates operational vulnerability.

4. Promote or hire the wrong people

I could write a book about this one. One common case is the excellent technologist who is promoted (desiring the job) into a managerial spot. He doesn’t have the people skills, won’t admit failure and can’t visualize going back to his old programmer slot. Another common case is hiring an ex-military guy to run a young engineering team. Six months later after the team has quit, your CEO will realize that you can’t hand orders to programmers like soldiers and you can’t flirt with the lady engineers and ask them to fetch the boss coffee.

The people who manage the teams have to have the art of software building and people building.

3. Decide based on religious beliefs

I know a company that decided on Open Source and Linux, going with a leading commercial distribution and a large systems integrator believing that the combination of Open Source and big-name vendors would guarantee success. The integrator’s skill set was primarily Windows, the distro vendor could care less about the fundamental flaws in the client’s design,and the company didnt have enough inhouse know-how of tool chain and Linux and couldn’t properly audit the progress and assess the problems of his contractor. Fortunately the project failed. I hate to think what would have happened if they would have succeeded in shipping the product – a SOHO security appliance with a Web interface for remote configuration.

The project spec must fit the system requirements; dont convert the system requirements to your religious beliefs.

2. Ignore internal system threats

Sales people know that sometimes their biggest competitors in closing a deal with a customer are people inside the company. For developers, this means that the programmer and her boss need to do a threat analysis from day 1 on the system taking into account backdoors, possible misuse, hard-coded parameters that can be forgotten or hacked later on and so forth. Temporary ftp servers for file transfer turn into permanent arrangements and vulnerability.

The team has to think about who will install, integrate and maintain the system even before considering operational issues.

1. Permit weak passwords

Threats such as worms get top PR but dont miss a basic IT mistake: weak authentication or bad passwords. Common password vulnerabilities include weak passwords (birthdays),publicly displayed passwords on Post-its, and Intranet and administrator passwords that the whole company knows. At my last company, people thought I had a great memory while in truth, just by working with the person; I could quickly and correctly guess the password to their workstation or servers. Later, after the team delivers the software, an external system integrator is often involved for installation at customer sites.

It is the responsibility of the developers to ensure that the system integrator will NOT be able to install the file transfer process between the AS400 and the billing system with anonymous ftp. I’m a fan of passphrases, I think they’re easier to remember and harder to crack but at the end of the day, passwords or passphrases need to be treated like cash. If you must, write them down on a piece of paper and save it your wallet. Dont store them on your Palm or save a file called system_passwords.xls in the MyDocuments folder of a PC in the computer room.

What should you do?

The software development environment of 20 years ago is radically different today. Development tools are free, hardware is almost free (think about those $100k Sun Enterprise 450 boxes and $500 Sun Ethernet NICS) and programming talent is a global resource. Its so easy to do things today but thats precisely the problem.
A development team can do but there is no replacement for a program/team manager that manages and directs the team away from the mistakes consistently.

Tell your friends and colleagues about us. Thanks!
Share this

Small business data security

Here are 7 steps to protecting your small business’s data and and intellectual property in 2011 in the era of the Obama Presidency and rising government regulation.

Some of these steps are about not drinking consultant coolade (like Step # 1- Do not be tempted into an expensive business process mapping project) and others are adopting best practices that work for big business (like Step #5 – Monitor your business partners)

Most of all, the 7 steps are about thinking through the threats and potential damage.

Step # 1- Do not be tempted into an expensive business process mapping exercise
Many consultants tell businesses that they must perform a detailed business process analysis and build data flow diagrams of data and business processes. This is an expensive task to execute and extremely difficult to maintain that can require large quantity of billable hours. That’s why they tell you to map data flows. The added value of knowing data flows between your business, your suppliers and customers is arguable. Just skip it.

Step #2 – Do not punch a compliance check list
There is no point in taking a non-value-added process and spending money on it just because the government tells you to. My maternal grandmother, who spoke fluent Yiddish would yell at us: ” grosse augen” (literally big eyes) when we would pile too much food on our plates. Yes, US publicly traded companies are subject to multiple regulations. Yes, retailers that  store and processes PII (personally identifiable data)  have to deal with PCI DSS 2.0, California State Privacy Law etc. But looking at all the corporate governance and compliance violations, it’s clear that government regulation has not made America more competitive nor better managed.  It’s more important for you to think about how much your business assets are worth and how you might get attacked than to punch a compliance check list.

Step #3 – Protecting your intellectual property doesn’t have to be expensive
If you have intellectual property, for example, proprietary mechanical designs in Autocad of machines that you build and maintain, schedule a 1 hour meeting with your accountant  and discuss how much the designs are worth to the business in dollars. In general, the value of any digital, reputational, physical or operational asset to your business can be established fairly quickly  in dollar terms by you and your accountant – in terms of replacement cost, impact on sales and operational costs.  If you store any of those designs on computers, you can get free open-source disk encryption software for Windows 7/Vista/XP, Mac OS X, and Linux. That way if there is a break-in and the computer is stolen, or if you lose your notebook on an airport conveyor belt, the data will be worthless to the thief.

Step #4 – Do not store Personally identifiable information or credit cards
I know it’s convenient to have the names, phone numbers and credit card numbers of customers but the absolutely worst thing you can do is to store that data. VISA has it right. Don’t store credit cards and magnetic strip data. It will not help you sell more anyway, you can use Paypal online or simply ask for the credit card at the cash register.  Get on Facebook and tell your customers how secure you are because you don’t store their personal data.

Step #5 – Don’t be afraid of your own employees, but do monitor your business partners
Despite the hype on trusted insiders, most data loss is from business partners. Write a non-disclosure agreement with your business partners and trust them, and audit their compliance at least once a year with a face-to-face interview.

Step #6 – Do annual security awareness training but keep it short and sweet
Awareness is great but like Andy Grove said – “A little fear in the workplace is not necassarily a bad thing”. Have your employees and contractors read, understand and sign a 1 page procedure for information security.

Step #7 – Don’t automatically buy whatever your IT consultant is selling
By now – you are getting into a security mindset.  Thinking about asset value, attacks and cost-effective security countermeasures like encryption. Download the free risk assessment software and get a feel for your value at risk.  After you’ve done some practical threat analysis of your business risk exposure you will be in an excellent position to talk with your IT consultant. While most companies don’t like to talk about data theft issues, we have found it invaluable to talk to colleagues in your market and get a sense of what they have done and how well the controls perform.

Tell your friends and colleagues about us. Thanks!
Share this