We have difficulty in deciding when to ACCEPT a risk. Accepting risk has to be a business decision. Here are the steps:

0. Understand the nature of your business in order to determine the acceptable level of risk. An example is if you are an online merchant selling widgets, leakage of customer credit  card information is unacceptable.

1. Quantify the risk in terms of $$.

2. How much $$ the safeguard costs to mitigate the risk? - cost/benefit analysis.

3. Decide the course of action for your risk treatment - this is where you decide if you would accept the risk.

Real world is not always as simple as described in the above 3 steps.

Asset Value=AV

Exposure Factor=EF (% of loss in terms of AV if risk were to be realized)

Single Loss Expectancy (SLE):

SLE=AV*EF

Annualized Loss Expectancy (ALE):

ALE=SLE*ARO ( where ARO is Annualized Rate of Occurrence, say it occurs 0.5 times)

Annual Cost of the Safeguard (ACS)

Tangible Asset

1. If the ACS < ALE then it may not be wise to accept the risk.

2. If the ACS > ALE then it may be wise to accept the risk.

Intangible Asset

1. Brand name.

2. Employee morale and more..

Through research it has been found that a publicized breach of a company results in brand name damage which can affect the stock market capital negatively by 2-4%. Employee morale can affect productivity of employees. This can hurt the growth of the company. Attributing $$ figure for intangibles is a challenge. If you take the step of quantifying the risk it is not as difficult as you think.

Broken Windows  is an interesting theory put forth by  James Q. Wilson and George L. Kelling.

"Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it's unoccupied, perhaps become squatters or light fires inside. Or consider a sidewalk. Some litter accumulates. Soon, more litter accumulates. Eventually, people even start leaving bags of trash from take-out restaurants there or breaking into cars."

The above theory was effectively used by the New York law enforcement to reduce the crime in the 90's. Graffitis were cleaned up, subway turnstile jumpers were arrested. This sent a serious message about the law and order to the criminals and the potential criminals.

The same theory is applicable to the security land. If you fix highly visible simple security vulnerabilities (low hanging fruits) most likely you will not experience security incidents of invisible complex security vulnerabilties. Fixing smaller vulnerabilities will enhance your security posture in the eyes of the crackers.

As an example if you leave port 23 (telnet port) open on an external facing web site host, crackers are more likely to notice your lax attitude and will be motivated to poke around and break your system.

The biggest bang for your security bucks will come from fixing such lowly vulnerabilities and then moving further up the ladder.

Zero-day is a viral term. Zero-day vulnerability is an unknown vulnerability i.e. vulnerability that vendors and customers are not aware of on the day it is made public.

Let us play two scenarios. 1. As a software vendor what zero-day means to you. 2. As a software customer what zero day means to you.

1. As a vendor you can't always worry about unknown vulnerabilities, but what you can do is operate with due care. Penetration test your software before you ship it. You must have a clear policy of handling vulnerability around two areas:  Incident Management - How do you handle the vulnerability? starting from identification to remediation. Customer Communication - How do you notify customers about the vulnerability? if you find a vulnerability notify your customers and make a patch available in a reasonable amount of time - never keep the customers in dark.

2. As a customer you can't worry about the vulnerabilities that you don't even know, but what you can do is operate with due diligence. Before you purchase a software from a vendor  evaluate their security. When you buy a software include a clause about vulnerability disclosure. Pro-actively  track your vendor vulnerability bulletin. You need to have procedures for patch management - automate the patch management if it makes sense. Ensure that you have a good security posture for the company as a whole which means vulnerability of one software component does not pose threat to the whole enterprise.

Zero-day is about the unknown - you can't loose sleep over it. It is yet another vulnerability as long as you are prepared!

(I would like to thank Mike Fratto, mfratto@secureenterprisemag.com for providing me food for thought on zero-day)

There is an interesting thought provoking post by Alan Shimel about the state of security.

The Internet has evolved over the years. Internet which was originally  intended to be a document sharing tool has evolved to be a full blown ecommerce engine. If you wonder why Internet is not yet secure - you have to remember that the framework for the Internet was not built with ecommerce in mind!

The hackers of the yester years were more focused on displaying their skills because there was not much to gain from the Internet in terms of money - Internet was a repository of distributed documents.

The evolution of defenses against threats were driven primarily by ecommerce. Ecommerce needed  sensitive/private data to be moved over the Internet. The evolution of commerce Internet  provided an attractive target in the form of sensitive data to the hackers.

The hackers of today are less likely to do a wide scale distributed attacks because:

1. The defenses have evolved to protect distributed attacks in most cases.

2. Cyber-laws are stringent and they are not lenient as they used to be.

3. They are more likely to get caught.

4. There is no money to be made.

Hackers  are focused on refined attacks:

1. They are after private/sensitive data - one user at a time.

2. The sample space of excited, non-savvy, ignorant and exploitable users exploded with the explosive growth of Internet.

3. They are less likely to be caught.

4. There is money to be made.

Mathematically an attack can be described as below:

Hacker > Defense + User_Awareness_Score (means hackers can carry out a successful attack)

Hacker <= Defense +  User_Awareness_Score (means hackers cannot carry out a successful attack)

If the User_Awareness_Score is high it fortifies the defense which makes it difficult for the hackers.

If the User_Awareness_Score is a -ve number which means the users are not aware of security - it brings down your defense.

Hackers of today have evolved, it is time for us security folks to drive the evolution of defenses along with the evolution of users.

It is pretty interesting news: EMC acquires Network Intelligence. Network Intelligence is a SIM (Security Information Management) company. Earlier EMC acquired RSA.

There was this buzz-phrase "Information  Lifecycle Management" that was touted by EMC earlier.

Does buying RSA/NI Et. Al. provide them a framework to add another adjective "secure" to Information Lifecycle Management?

Will "Secure Information Lifecycle Management" make business sense?

Probably it does, it is futuristic, time is of essence.

The goal of information security is not limited to securing information. This is akin to describing the job of police is limited to providing safety for people. The job of police is to enforce law and order so that the society functions harmoniously.

Information security is actually a part of risk management.  Then, what is risk management? Risk if realized exposes business to loss. The loss could be monetary, brand-image, customers and future revenue-stream. In risk management, the assets are identified, categorized and prioritized. The assets are tangible or intangible. The priority is based on the relative importance of the assets in the realm of the business. Risks that affect the asset are identified and the likelihood of the risks are quantified. Loss occurs if a risk is realized on the asset - the loss is estimated as a  % of the asset value.

The following actions can be taken on a risk:

Accept the risk - Say that it is ok if the risk were to occur.

Ignore the risk - Don't care whether the risk is realized or not.

Mitigate the risk - Put in safeguards in place to reduce the loss if risk were to occur. It is a common sense that the cost of safeguard should not exceed the cost of asset that it is protecting.

Transfer the risk - Buy an insurance policy for the risk.

It gives you the biggest bang for the buck if you look at information security from the perspective of risk management. If you do so, your security initiatives will be aligned along your business goals.

You need not buy the plethora of the security products out there just because the vendors are touting it. Defense in depth does not makes sense unless you understand what exactly you are protecting, what are the risks that affect it and how important it is to the business.

Holistic information security is risk management. Information security does not exist by itself.

Mike Rothman talks about the stuff that pisses him off. I think he has valuable tips for vendors and is worth a read. I have been following Mike's blog from inception, believe me - Mike is a credible guy and he thinks for customers.

It would be nice if vendors can focus on these items for their presentation:

Who are your customers? (understand who you are targeting)

Why do your customers care for your product?

What is your product?

How does it work?

Where can we buy it?

Finally, you can talk about your pedigree. This is selling product by its true merit.

The other day I heard the sad news about the death of Steve Irwin the Crocodile Hunter. When I heard the news through some one about his death, I was guessing that his death would have come from a wild crocodile or a venomous snake. I went online to find more about his death. I was flabbergasted to hear that his death came from an unexpected source a fish i.e. Stingray - a very freak accident indeed.

Is there a lesson from this for security professionals?

We can design mother of all controls to be ready for sophisticated threats - but security breach can happen from unexpected vectors.

It is a reminder that 100% security is impossible, but higher the security bar the safer it gets.

Software vendors are most likely to describe their software as very secure and meets all the compliance requirements. Is this a sufficient promise for you to consider the software secure enough to base your buying decision? How do you evaluate a software for security?

Software vendors are most likely to say things that make them look secure. If that is the case, how do you peel the layers of onion to get to the core? Here are some questions that can help you get there:

1. Does the vendor follow secure software development life cycle? What practices and tools do they use to accomplish this?

2. Does the vendor have well defined vulnerability management process? What is the typical cycle time to patch  vulnerabilities? How open are they to announce the vulnerabilities?

3. Do they communicate newly discovered vulnerabilities to the customers? Is there a vendor web site where customers can get such information? What is their track record in the past?

4. Are there third-party, open-source components in the software? Do they keep tab on vulnerabilities of these components?

5. Does the vendor train their developers in secure coding methodology? (This question will reveal a lot about the company's attitude about security)

6. Does the vendor conform to ISO 27001 or any other well recognized information security standard? What are the compliance requirements do they meet?

7. Does the vendor outsource/off-shore software development? If that is the case repeat questions 1 to 6 for the outsource/off-shore shop. (Remember, security is as strong as the weakest link!)

Software from various vendors can look alike don't be totally fooled just by the looks. Take an inside-out approach. How well the software framework is built determines the security of the software you buy.

If you are not satisfied with the vendor's security framework, say thank-you and move on to the next vendor. If you don't make vendors pay for bad security practice it is bad for your money's worth and moreover you are not providing an incentive for the vendors to improve.