Schneier has a very interesting post on Information Security and Externalities.  Below is the highlight of the article:

"The software vendors have little economic incentive in churning out a secure product in the current marketplace. Holding a software liable (to an extent) for not making a secure product can not only force the software vendor to fix the problem but also provide economic incentive for the software vendor to make secure product."

I agree with Schneier's view of holding vendor liable for insecure software, but I believe that enacting such laws will be a pipedream. The big software vendors' lobby will always prevail. Moreover, such laws can can tilt the software playing field in favor of big software companies.  

One of the ways is for the customers to start demanding secure product which may be a possibility, but customers may have been locked into certain vendors for multitude of other reasons which Schneier addresses. The bottomline is customers are not in a position of power to make such demands.

"Any fractional incremental effort by software vendor to make the product secure is worth an effort since it can make a signficant reduction in cost of ownership for the customer."

Below is a mathematical representation (not the basis!) for the above statement for the curious:

Price = Initial Purchase Price of the Product $

Life = Life Cycle  Cost of the Product $ = Y*Price (expressed in terms of multiple of Price)

TCO = Total Cost of Ownership

TCO= Price + Life=Price + Y* Price ---> Equation 1

Assume if the vendor develops secure product, if the vendor has to spend twice as much to develop the secure product (that's probably the worst case impact on the cost structure and let's assume that the vendor passes all the cost to the customers by doubling the price).

TCO (secure)= 2*Price + x * (Y*Price) ---> Equation 2

Where is "x" is the cost reduction factor due to security.

If the TCO (secure) should be less than TCO, Equation 2 <= Equation 2

Y(1-x)>=1

Y>=1/(1-x)  [ x=0, => Y >=1,  TCO >=2*Price ]

                    [x=0.9 => Y>=10, TCO >= 11*Price ]

A change of variable x from 0 to 9 0.9 results in corresponding change in TCO from 2*Price to 11*Price.

Security manager often complain about the budget allocation to the security program. Is it true that senior management does not give a hoot about security? More likely than not the security manager has not communicated the value of the security program (Please. refer: Mike Rothman's Pragmatic CSO Section 4:Communicate  your Value).

1. Track metrics of the security program and announce it on a regular basis. Demonstrate continuous improvement.  Some examples of metrics are: Effectiveness of Anti-spam, Effectiveness of Anti-virus, Effectiveness of URL blocking Et. Al.

2. Post relevant security news item on the company Intranet portal on an ongoing basis.

3. Post security column on your company's newsletter on an ongoing basis.

4. Impart security awareness training to employees. Don't exclude contractors, have a customized version of training ready for them.

5. Provide employees with handouts on best information security practice.

6. When a user has a security related issue, treat this as an opportunity to educate the user about best security practice.

7. Last but not the least, communicate value of the security program for upper management in terms of competitive benchmarks, risk mitigation and compliance status.

Many of us have this notion that a web site that is accessible securely through https can be trusted. This is not true. Not all the sites that use https can be trusted. Nothing can stop fraudsters from setting up a https web site. Though https offers security it does not offer trust. Trust is a choice that the user has to make consciously. Here are some tips that help you to decide whether you can trust a web site by look at the https certificate.

1. On your web broswer, browse to the  https URL that you want to verify the trust, example https://www.amazon.com

2. Click on the lock icon on the lower right handside on the status bar of your web browser. This will open up a dialog box which gives “Certificate Information”.

There is a news item about a serious vulnerability in a popular software which generates a lot of buzz. Security community talks about how hackers have evolved in terms of their attack methodology and motive. Product vendors are blamed for their tardiness in response. The story repeats again ad infinitum. Am I excited to hear the story over and over again? No way! I am bored of repetitions.

Consider this scenario:  Hacker finds a vulnerability with a product  from a vendor.

Vendor has access to all the source codes. Vendor has the knowledge about the functional design, architecture, bugs, future roadmap Et. Al. Moreover, a vendor has the money and other valuable resources.

Hacker does not have access to the source code in most cases. Hacker does not have all the details about the functional design, architecture, bugs, future roadmap Et. Al. Pragmatically speaking, a hacker is trying to break into a blackbox with limited resources.

There is a clear information asymmetry between a vendor and a hacker. This information asymmetry is an excellent leverage for a vendor over a hacker. With this leverage and resources at a vendor's disposal, a vendor can do a lot more to prevent vulnerabilities in the shipped products than what is being currently done.

If a hacker finds a vulnerability in a product. I am more inclined to point finger at the vendor's sloppiness than heaping encomiums about the hacker's intelligence.

How about making it mandatory for a vendor to disclose the process employed to assure security in the vendor's product offerings? 

Security is mostly perceived as protecting information and the infrastructure that host information from hackers. In reality this is partly true. Security addresses concerns of confidentiality, integrity and availability (aka CIA triad) of your information infrastructure within the context of your business in a meaningful way.

Is CIA triad a meaningful goal to pursue? The answer depends on the company's context. Firstly, the line of business a company is in is the prime driver of the security program within the company (example: financial institution are more security savvy than others for a reason). Secondly, whether the company has enough resources (budget, people Et. Al.) to address security. Most importantly security strategy should align with your business strategy. Alignment of strategies itself does not justify your security investment. Security should enable your business else you will have an uphill battle to get your budget approved.

Recently, I heard an IT manager mention that they have a secure perimeter because they have a firewall. This is akin to saying that my house is secure because I have purchased a lock.  As an example of the right security mindset, deploying firewall should address the following concerns:

0. Have you picked the right firewall vendor?

1. How is the firewall configured?

2. How does it fit into the overall security framework?

3. How is the firewall architecture?

4. Is there a well defined process to maintain the access list on the firewall?

5. Who administers the firewall? Is there a backup admin?

6. Who monitors the firewall logs?

7. Is there a well defined documentation about the firewall, so that another firewall administrator can take over in case the primary administrator is unavailable?

8. Is the firewall being monitored for uptime, performance?

9. Is the firewall hardened for any known vulnerabilities?

10. What is the process of keeping the firewall software up to date?

I have highlighted firewall as an example. This can easily apply to IDS/IPS or any other security product implementation.

In summary, buying security product don't entitle security. Half baked security product implementation do not beget security either. Implementing security products holistically by addressing set of valid concerns is the right approach.

I have been following Mike Rothman's blog for over a year. I could clearly see through his narratives - a thought leader.

I was one of the fortunate people to get to review Mike's Pragmatic CSO book manuscript:

1. This book is a must have for any CSO.

2. Extremely practical approach of spearheading security initiative.

3. Teaches you to look at security from the business perspective.

You can buy this book at: http://www.pragmaticcso.com

Mike Rothman says: So what's next? The Pragmatic CSO community will launch in February. Not only will there be templates and forums focused on the book, but at long last I'll be publishing some Security Incite research for subscribers. I'll also be doing interviews and vendor "hot seat" podcasts on the site each month as well.

Pragmatic CSO Community fortifies the book offering with useful tactical security goodies. Mike's Pragmatic CSO offering is the manifestation of  his idenitity in the marketplace, compelling analytical writing style and his commitment to help you.  Read the Pragmatic CSO and learn the power of getting things done in security land.

Happy New Year to You All...

My good friend Alan has a very ninteresting podcast about security stories of 2006. Please check this out on his popular blog StillSecure, After All These Years.