Israeli Software

I've been following the Hannaford customer data security breach on and off and the lack of full-disclosure is impressive.

I would argue that Hannaford Brothers, their software vendors, the card associations and the Massachusetts State Government have all taken a " vendor-proprietary approach" (for lack of a better term).

In a vendor-proprietary approach, if a bug or security vulnerability is discovered in the system, the vendor does not admit that he has a problem.

This gives the vendor a number of perceived benefits - a) the vendor has time to fix the bug. b) it gives the vendor plausible-deniability that a bug ever existed c) it saves the vendor the embarrasment of admitting guilt and most importantly - it enables the vendor to sidestep liability for third-party damages and class-action suits.

• None of the POS/store backoffice vendors - Fujitsu, Retalix and Novell have made a statement, and why should they?

  No one thought to ask the vendors a straight talk question like - "What was the role of your software and systems configurations in the vulnerabilities exploited by the Hannaford attackers?"

• Hannaford was PCI DSS-compliance (as of Feb 2008) and now they're saying they need millions to really do the job right. An initial statement from the company that they had replaced all server hardware has since been reported as a reinstall of the operating systems and applications - since neither Hannaford nor their software vendors have been forthwith on this topic, we may never know.

• Hannaford has apparently succeeded in pulling the wool over everyone's eyes with their claim that spyware infected all the store servers and enabled "foreign" attackers to steal 4 million credit card numbers. I'm not the only one who finds this claim a little on the flimsy side - considering that back office servers are not connected to the public Internet.


• To date - Visa and the PCI DSS Forum have not issued a post-mortem of this customer data breach event in order to help other merchants improve their data security
  

Since sales haven't been affected - Hannaford and their suppliers might easily take a full-disclosure approach that would benefit the consumers with better and safer software and enhance their public reputation.

• Full-disclosure means that more eyeballs would be able to take a look at the software vulnerabilities, help Hannaford and their vendors do a more effective job with security countermeasures with their software and systems.


• Full-disclosure means that the right security countermeasures would be taken instead of knee-jerk public relations driven responses.
  
  Hannaford is closing the barn door after the horses have fled - by implementing security countermeasures that fit the last attack. They claim to be implementing HIDS - host based intrusion detection systems, yet an IDS is an almost worthless measure of preventing data theft; even assuming that a malicious outside attacker was involved (which is arguable...). You can bet that the next customer data breach at Hannaford will occur on a different attack vector not mitigated by any of the countermeasures they are implementing now.
  


• Full-disclosure means that other supermarket customers will be able to make better purchasing decisions
• Full-disclosure means that vendors will need to do a better job. With all the criticism of Microsoft, their products have gotten better only because of a full-disclosure policy of Windows security bugs. Unfortunately, Microsoft
  are still extremely vendor-proprietary and shutting down access to various parts of the operating system is not helping security - although it enables kernel developers to charge more money for their services.

By the way - what's happening with that Class Action Suit?

See my blog posts on the saga -

• Boss, I think someone stole our data
  
  
• The best way to protect customer data
  
  
• Threat modeling a retail network
  
  
• 4.2 million credit card numbers stolen
  

1. The problem with risk assessment systems today is that they don't really calculate risk

2. They're not easy to implement and they make you work hard.

3. Most systems try to satisfy compliance regulation. Asking a bunch of people how risky their part of the business process whether they care about it or not. They don't help people do their job better and don't help a business protect customer data more effectively.

4. Standard checklists don't necessarily help mitigate risk.
While checklist applications are important for the customer and the auditor in order to prove compliance - in fact a checklist doesn't help the customer find cost-effective security controls, respond to new threats or sustain a consistent level of security.

5. Self-assessments may actually be a threat to an effective risk assessment. since users can answer a self-guided questionnaire any way they feel like - a system that rolls up a bunch of arbitrary answers will give an arbitrary result.

Some of the things I'd like to see in a next generation risk management system:

Risk assessment should be an exercise in measurement and calculation - not questionnaires and reports.

Threat modeling can be a good way to calculate risk instead of leaving it up to your emotions.

The problem with most GRC (governance, risk and compliance) and ERM (enterprise risk management) systems today is that they don't calculate risk, they make you work hard and they're not that easy to use.

Take a simple (yet important) example of mitigating the threat of having your wife's jewelry being stolen.

For example, you have assets- expensive diamond jewelry stored at home.

Your asset has vulnerabilities - since you live on the ground floor and your friendly German Shepherd knows where the bedroom is and will happily show anyone around the house.

The key threat to the asset is that an attacker may break in through the ground floor windows. The countermeasures are bars for the windows, an alarm system and training your dog to be a bit less friendly around strangers with ski-masks.

Threat modeling is important for risk assessment since it enables you to prioritize the security countermeasures. A good threat modeling tool will help you easily build a threat model and manage the complex relationships between the different threat entities.

Last month - we had close to 2,000 downloads of our free risk assessment software based on threat modeling methodology -Practical Threat Analysis. The number has been growing steadily over the past few months and judging from user emails, I would interpret this as a trend that threat modeling is being used in increasingly wider application areas and not just during the software design phase.

Besides PTA, there is of course, the well-known Microsoft Threat Analysis & Modeling application, work done at Mitre Corporation and research performed by Cary McGraw and his team at Cigital.

As threat modeling becomes more and more common as a tool to calculate and mitigate risk, the need for standardization becomes more acute.

Rocky Heckman is developing and maintaining a Web site of standard Attack Patterns defined as "A series of repeatable steps that can be applied in a consistent and reliable manner to simulate an attack against a software system."

Standard attack patterns are useful not only for testing an application and discovering vulnerabilities, but of particular importance when used during the design and implementation stages of a system in order to mitigate threats that exploit known vulnerabilities.

Standard threat models are key in prioritizing countermeasures. While new threats materialize all the time, there are very few brand-new attack patterns. New threats based on old attack patterns can be mitigated with cost-effective countermeasures from the old threat model.

For example, counterfeiters might attempt to guess legitimate product serial numbers using a dictionary attack on an online customer service Web site in order to obtain bona-fide numbers and produce fake products that appears to be genuine. An effective countermeasure might be a serialization algorithm that makes dictionary attacks extremely difficult (and economically unfeasible) by use of very large, unpredictable collections of numbers. New threats may come along that attempt to discredit the company by phishing for personally identifiable information on the web site. The phishing threat that uses the same dictionary attack pattern, then inherits the same set of effective security countermeasures.

There is an extensive discussion thread on the Practical Threat Analysis Professional Forum

By now - I thought this was a FAQ but I've been asked the question a few times this week (including on LinkedIn) so I thought it was worth a post.

FOSS - Free Open Source applications run a huge gamut of maturity.

There are products like MySQL and Postgresql that are easily strong competitors to MSSQL and Oracle. There are business applications like SugarCRM and Compiere ERP that are mature, proven and used by many many users globally. Then there are projects that were done 5 years ago and the projects that are DOA. - Look in sourceforge for activity in the past few months - that is probably a good sign that the lights are on and someone is home.

There are 3 perspectives you need to consider:

1) As a business user
2) As a product developer
3) As a community contributor

1) As a business user - remember that there is no free lunch. It may be cheaper for your business to use Google Apps than qmail and Spam Assassin but it may be cheaper to hire a consultant to implement Compiere than Oracle Apps

2) As a product developer - FOSS has a great advantage but there is a catch - and that is the license - the license (BSD, MIT, Mozilla, Apache, GPL) is probably the most important thing both as a consumer of Open Source code and as a distributor of open source code. Read the fine print before you adopt a particular FOSS project into your product

3) As a community contributor - it's great - it's fun and you need to have a day job or someone to sponsor your work.

This posting is dedicated to all those VCs who were traumatized by their IT security investments. Here is an application of threat modeling in the pharmaceutical industry. Not Web applications. Not network security.

This level of threat damage always stimulates a big business in countermeasure technologies. There are hundreds of products and methods from RFID tagging to nano-particles that are being proposed as solutions (not even risk mitigation) to the threat of drug counterfeiting. Most of these technologies are not cost-effective and can be easily sidestepped (to make a fake product, a counterfeiter only has to make it look real - he doesn't have to do the original research, development and manufacturing process).

Not surprisingly, because of the public health implications (how many men die from fake Viagra or women die from fake silicon breast implants), regulators like the FDA are stepping in. California is setting the gold standard like they did with consumer privacy protection - this time with a bill that would require a drug "e-Pedigree".

The California e-Pedigree law (SB 1370) specifies pharmaceutical product serialization which “require the pedigree to contain the drug's unique identification number established at the point of drug manufacture.”

When used through the supply chain, the e-Pedigree will help track and trace product, identify counterfeiters and enable consumers to authenticate the products they buy at the point of sale.

It's impossible for me to estimate how much e-Pedigree will eventually cost (it only becomes mandatory in California in 2011) but it's pretty clear that with all the packaging and information technology it's going to be a pretty steep price for the drug supply chain.

Instead of trying to solve an impossible problem, I decided to model a subset of the e-Pedigree. i.e. use of product serialization at the point of sale to the consumer in a pharmacy. My simple-minded threat model ignores supply chain integration and analyzes the risk associated consumers self-authenticating product.

The notion of having consumers call in a numeric token in order to authenticate a drug they purchased, was first proposed by Johnston, a researcher at Los Alamos Laboratories. There are commercial implementations, available from companies like Dintag and Algoril and Verify Brand. Dintag in particular appears to have the most complete implementation.

How does it work?

Pharmaceutical end user customers would be able to authenticate the validity of a random, ID number printed on packages via a simple Web search query similar to the Google search page. Other channels might also be used – for example: sending a text message with a cell phone or a making a phone call to an automated voice response service. Customers with cell phone cameras could send a picture of the label over the Web to the system, which would extract the ID number using OCR and return a text message to the consumer.

When used by consumers at the point of sale, or at home; product serialization becomes a relatively low-cost, low-tech way to authenticate a product, since there is no supply chain integration required and the large number of consumer eyeballs calling in tokens is free to the manufacturer. I believe that there is also a viral marketing effect as people tell their friends about the system.

I performed a threat analysis of the call-in numeric token method. In a later posting, I plan to publish the actual PTA threat model that was developed.

Don Dodge's post on Cloud Computing: Do You Really Want Your Data in the Cloud? has a great opening statement:

Reliability, scalability, security, and a host of other issues will prevent most businesses from moving their mission critical applications to hosted services or cloud based services. The risk of failure is too great.

Don Dodge is Director, Business Development at Microsoft. He handles Venture Capital relations and business development with start-up companies in the Boston area. His criticism of uptime problems at Amazon EC2, Typepad and Twitter are apparently ample proof for him that "most applications will not move to the Web".

I offer several points In rebuttal -

1) There are already a tremendous number of applications and data on the Web already - from SaaS offerings like Salesforce.com and Google Apps to big professional hosting companies like Verio and Rackspace.com and smaller guys like John Companies. Customers like IT services in the cloud because IT is not their core business and the service levels and performance they can get in the cloud is worth every penny of management attention. There is so much complexity involved in IT operations and security in today's fast-moving threat environment that any business is best served by focusing it's attention on it's own sales and not on data security.

2) There is more involved than data availability in the cloud - there are critical customer service and IT operations issues as well.

The level of information security, network management, server engineering, data integrity, backup services, operations and customer service at a hosted service is far beyond what virtually any business can afford to provide. Software Associates (our company) are professional systems developers with high levels of expertise in Linux and security and last year we migrated all our messaging to Google Apps - simply because our time is better spent on the business and not on maintaining Spam Assassin.

3) Convenience trumps security except in a small number of cases. Mr Dodge, since he works for Microsoft should know that consumers and most corporate business organizations prefer convenience to the headache of being on the bleeding edge of security.

4) A more subtle point is the ability of an organization to stay on top of customer data and IP protection issues if they run their own server farm. Unless I am mistaken - none of the security breach events in the past 5 years happened at a managed service providers, SaaS operations or professional hosting. We're talking banks and large retail organizations here that constantly get stung by trusted insider attackers and malicious hackers.

There is actually a huge advantage in not storing your data inhouse - the exposure to trusted insiders is almost nill.

5) Microsoft makes great software and has aspirations to become a SaaS application provider. Although disappointing for Microsoft, their lack of success in this space is not surprising because IT in the cloud requires an entirely different skill set than developing and marketing great client/server software.

Cloud computing is an important tool for collaboration in the global developer community - all the more reason to reject callow remarks on the future of cloud computing from a Microsoft executive.

We have come here this evening to fulfill two obligations that we have to the American family. We are here to defend truth and we are here to avoid tragedy.

Man - that's good news - because I find the entire FUD+PR person+Security Vendor triangle to be very problematic.

I personally would like to see Truth in packaging applied to Security technology in particular and ICT in general.

Almost 42 years ago - The Fair packaging and Labeling Act (Truth in packaging) was signed by Lyndon Johnson. Quoting LBJ:

"This is a strong but simple law. It requires the manufacturer to tell the shopper clearly and understandably exactly what is in the package, who made it, how much it contains, how much it costs.

The housewife should not need a scale or a yardstick or a slide rule or computer when she shops. This law will eliminate that need. The housewife should not have to worry which is bigger--the full jumbo quart or the giant economy quart. This law will free her from that uncertainty and that problem. It will protect her from being shortchanged by slack filling where a box is made bigger than its contents.

This law is one weapon against high prices. It will mean that the American family will get full and fair value for every penny, dime, and dollar that that family spends."

Replace housewife with CEO and American family with business and you get my drift

Cratoni mountain bike helmet after crash.

This Sunday I went out for an easy 1 hour ride in the Ben Shemen forest not far from our home in Modiin. You don't have to get into the car, it's about a 15' ride to the entrance to the forest - and you then have an infinite variety of circuit trails, singles and cross-country rides of all levels of difficulty.

I chose a path I've ridden many times - from the entrance to the forest across from the Ligad office park into the Neot Kedumim Biblical Landscape Preserve and back. Coming back, down the first hill - I went up a small dirt ramp at the entrance to a path. The front wheel went up, I went over the ramp, flipped over in mid air and made a two point landing on my head and right shoulder.

It's one of those situations that happens in a split second - your brain registers that it is not going to end well, but it's too late. The next thing you know - you are flat on your side and picking dirt out of your ear, and looking for your glasses.

In my case, I got up and felt blood on my face and ear - I spent the next 15' looking for my glasses. Just as I found them - another rider came by and asked me if I was ok - to which I smiled and said - "of course not!". He gave me a Wet ones he had in his backpack from Turkish Airlines and I wiped down my face. We rode back to the exit from the forest together and I rode home. Oren from Kfar Oranim - you're a Good Samaritan man - thanks!

Got home, took a hot shower, soaped down the scrapes with antiseptic soap and iced the bruises. Went over to the doc in our local medical service (Kupat Holim Clalit). After a neurological exam and x ray he gave me a clean bill of health (no breaks, no concussions) and remarked that I was the third rider he'd seen that morning and by far the ugliest crash victim of the three.

I'm not going to post any pictures of myself after the crash - because this is a family blog and the pictures are too f-g scary.

I landed on my head, chipped a tooth, and 5 days later - still have a black eye and sore shoulder - my Cratoni Heli helmet saved my life.

To the good folks at the Cratoni factory in Germany - thank you.

In his Survey of current thinking, Malcolm Sparrow talks about how various public and private organizations are beginning to respond to threats in a more domain specific manner instead of following general regulatory dictates - for example in crime problems, or environmental issues, occupational hazards, or patterns of drug-smuggling.

"What’s odd, when you look at this new pattern of behavior, is that there does not seem to be a well-established language for it. Different professions have quite different vocabularies. In the police profession it’s called “problem-oriented policing.”

I don't know why this seems odd to a university researcher whose past research has focused on regulatory practice - since regulatory compliance is responsible to a large degree for mindless risk management.

Why?

Compliance regulations provide general guidelines and checklists of risk controls companies must do. In the case of Sarbox, a general statement (404) has required interpretations which developed into a $100BN franchise for accounting firms and technology companies. When you use a big regulatory stick with an organization you send a message that improving risk understanding is a non-value-added activity since the business objective is compliance and not understanding root causes of why senior executives steal.

However all is not lost.

An excellent methodology exists for understanding the root cause of risk. The methodology is called threat modeling. Threat modeling is a mature methodology with implementations from Microsoft and groups like PTA (Practical Threat Analysis) Technologies.

In threat modeling exercises - analysts and business decision makers use a model of assets, vulnerabilities of assets, threats (that attack by exploiting vulnerabilities) and countermeasures (that mitigate threats). The beauty of threat modeling is that it is a common language that any person working in an organization can understand.

You can download the free risk assessment tool PTA Professional - we'd be happy to hear if you also think that threat modeling is a useful tool for risk assessment.

He who will not risk cannot win. John Paul Jones, 1791

This week, the Israeli business daily Globes reported that the recent fall in the shekel-dollar exchange rate has resulted in an increase in dollar terms in salaries of Israeli high-tech employees. Figures released by global business consulting firm Radford reveal that the salary earned by a software engineer in Israel is close to the customary salary in the US. The survey, which covered 550 companies in 80 countries, reveals that a software engineer in Israel earns a total of $68,000 a year. For the sake of comparison, a high-tech employee in the US earns a total of $76,000 a year, and a software engineer in Russia earns $17,993 a year. In countries in East Asia, the preferred location for outsourcing, the average salary is a quarter of what it is in Israel. Software engineers in China earn $19,457 a year, and in India they earn $14,240 a year. (Globes 23.06).

Reports I'm hearing from colleagues at the big technology employers like NDS and Comverse tell me that poor designs and low levels of software engineering expertise are runner-ups to great lunches and high salaries.

There is a sense of entitlement to Israeli high-tech workers that comes from having enough disposable income, a reasonably interesting job and a fairly clueless boss that is even more interested than you in job security.

As a security and compliance professional - I can tell you that with enough security controls you can make the risk go away - if you're concerned about trusted insider theft - you can take away email and Web access and make your employees pledge allegiance 5 times a day like in Catch-22. There will be no threats of malware or data breaches but then again - that kind of setup will pretty much guarantee that your customers won't get service and your company won't win records for engineering excellence.

With high salaries and low creativity - Israel doesn't have a compelling value proposition with places like China and India.

Andy Grove once wrote - "a little fear in the work place is not necessarily a bad thing". Maybe the time has come to reduce salaries and place the emphasis on risk-taking, creativity and software excellence before the Chinese eat our business for lunch.

Unlike an ERP system, enterprise risk is not a deterministic business process that can be planned and managed.

A central task in risk management is estimating dollar value of risk.

This is a indeed a tough problem; increasing numbers of security analysts from corporate security groups at companies like Cisco, Intel, Microsoft, Seagate and groups of independent security and compliance analysts who participate in the Practical Threat Analysis Professional Forum and The Control Policy Group are turning to practical threat analysis to help calculate risk in a premeditated way.

Threat modeling is based on the notion that any system or organization has assets of value worth protecting, these assets have certain vulnerabilities, internal or external threats that exploit these vulnerabilities in order to cause damage to the assets, and appropriate countermeasures exist that mitigate the threats.

With threat modeling, you make future risk scenarios vivid, tangible, and measurable in dollar terms, countering the tendency to ignore threats and do nothing. Threat modeling gives you and your employees a practical language of assets, threats, vulnerabilities and countermeasures.

Here are 6 rules for effective threat modeling -