Personal tools
You are here: Home wikidblog Categories Information Security
« July 2008 »
Mo Tu We Th Fr Sa Su
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      
Recent comments
Re:Security and Oil admin Apr 25, 2008
Re:Security and Oil Paul feet Apr 24, 2008
Re:100% open source admin Apr 22, 2008
Re:100% open source Adam Apr 22, 2008
Re:Capital Gains Tax Rates and Entrepreneurs Lance Oct 23, 2007
 

Information Security

Up one level

WiKID Reviewed by SC Magazine

I'm pleased that WiKID was included in a review by SC Magazine. You can see the review online now.

The review process went pretty well, but I was frustrated by a couple of things. For example, they lost the CD of documentation. I really don't want to kill trees to print things that people mostly don't read, but we probably will from now on, just for reviewers ;). In all though, it was a very interesting process and I respect their goal of being more picky and less communicative than a typical customer would be.

I also recognize that WiKID's funky caps will always result in various mis-capitalizations until we have the heft and recognition to make it otherwise. You don't see many people writing about "Ibm" or "Rsa". :)

BTW: If you are interested in reviewing the WiKID Strong Authentication System, let me know - you can post comment or contact me at nowen -at - wikidsystems.com

The URL to Trackback this entry is:
http://www.wikidsystems.com/WiKIDBlog/12/tbping

Re: WiKID Reviewed by SC Magazine

Posted by Iang at Nov 04, 2005 08:41 AM
The link shows 404?

Re: WiKID Reviewed by SC Magazine

Posted by nowen at Nov 16, 2005 02:29 PM
Thanks! Fixed it.

Why you need strong authentication wiki

I have come across a number of sites across the Internet that discuss why strong authentication is a good idea and many go into good detail (such as http://mongers.org/authentication , but I haven't ever seen a broad discussion of the reasons why in one place.

As noted in the previous post, you get a lot of benefits by deploying two-factor authentication, but what are they?

I figured the best way to get a comprehensive analysis was to create a Wiki and let the good folks of the Internet do the work for me. I have gotten it off to a start, but I'm sure there is plenty to add.

Presenting the The Why You Need Strong Authentication wiki. Please contribute! (and let me know if there are problems ;)

The URL to Trackback this entry is:
http://www.wikidsystems.com/WiKIDBlog/17/tbping

InfoSec Economics article on Security Pipeline

There's an interesting article on Security Pipeline about the economics of information security. The article discusses why ROI is a poor measure, echoing my first post. But it misses out on a key point: that investing in security reduces your weighted average cost of capital and that you must include the cost of capital in your investment analysis.


Here are some tid-bits:


  • "Furthermore, the accounting-based notion of ROI doesn't take into account that great chestnut of economic theory, the "time value" of money."

  • True enough.


  • "Which brings us to NPV. To consider an investment's real worth over time, the discounted totals of all the expected savings are subtracted from the costs associated with the investment over time (also discounted). What's left is the NPV. The fundamental insight of NPV is that the later the costs savings from not suffering cybercrimes, the less the cost savings add up to. At the same time, the sooner the investment in cybersecurity, the more it costs."

  • Again, true


  • "Say a company needs additional security and figures the cost savings (benefits) to be derived from the extra security will be the same for different security options--different firewall configurations, for instance. In this case, it makes sense to choose the configuration that costs the least. However, in comparing costs of the various options, it's the present value of the costs that should be the key concern. Consider two options, each with a total cost of $400,000, in absolute terms over two years. Option A would cost $300,000 at the end of the first year (due to a large capital outlay the first year) and $100,000 at the end of the second year. Option B, on the other hand, would cost $200,000 at the end of each of the two years. Obviously, Option A is more costly when accounting for the time value of money, so Option B is preferable. Now, assuming a 10 percent discount rate, Option A would cost $355,372 and Option B would cost $347,107. And if the present value of the benefits happened to be $350,000, Option B is the only option that would be justified on economic grounds, because it would have a positive NPV of $2,893, whereas Option A would have a $5,372 negative NPV."

  • A pretty good description of the time value of money, but why choose 10%? If the discount rate is the same on each option, then Option B is the best one. But what if Option B was unproven or your staff was unfamiliar with managing that configuration, you should assign it more risk. If you assign Option B a discount rate of just 2.5% higher - 25% more risky - then Option A is the best deal.


    I have posted some thoughts on determining an appropriate cost of capital for information security projects. I think confusion over measuring NPV and the like is holding back deployment of security technologies like strong authentication. CSOs don't realize that using strong authentication will reduce the discount rate used to measure the NPV of your remote access.

    The URL to Trackback this entry is:
    http://www.wikidsystems.com/WiKIDBlog/23/tbping

    HSBC issues warning to 180,000 regarding a security breach

    The WSJ Online is reporting that HSBC has issued warnings to 180,000 of it's customers that a security breach may have resulted in their data being compromised.

    The HSBC letter, which was sent to cardholders last week, reads in part: "A national retailer's computer system has had a security breach and your credit card account number may be among those that were compromised." It was signed by "GM Cardmember Services" and noted that HSBC issues the card and provides administrative and processing services for it. The letter went on to say that "we are unaware of any fraudulent activity on your account."

    Kudos to HSBC:

    While banks also are required to report breaches that occur in-house or at financial-service providers with whom they do business, HSBC technically wasn't required to notify GM MasterCard holders because the breach in question occurred at a separate retailer, not within the bank or the credit-card company.

    The WSJ says the US Retailer is Polo Ralph Lauren.

    I've spoken to a couple of auditors recently that had been doing a fair bit of work for processors and merchants. Both said that Visa recently eased the requirements. I believe they have eased the requirement for strong authentication. It will be interesting to see if the retailer in question passed the CISP compliance and if use of strong authentication would have prevented the attack, as it would have in the case of the LexisNexis breach

    The URL to Trackback this entry is:
    http://www.wikidsystems.com/WiKIDBlog/28/tbping

    Not Bad for a Cubicle on Strong Authentication

    Not Bad for a Cubicle has a post on strong authentication - more blogging driven by Bruce Schneier's posts. It's well balanced and insightful.

    As I see it, the core of the problem is that Identity is not actually tied to me as a person–it’s tied to data in various databases. That’s not necessarily a Bad Thing. Sure, it’s argued that Biometrics would solve that problem but I’m actually not very comfortable with that solution. The unintended consequence here becomes that if we ever actually succeed in tying Identity to its owner, then we can no longer decouple it in the situations where we’d like privacy or anonymity. Yet another example of “Security is a Trade-Off.”

    I couldn't agree more here and I would argue that people will develop personas or 'nynms' or other mechanisms to keep information compartmentalized. I use my hotmail account for certain things, gmail for lists and my popmail accounts for other things.

    Each authentication mechanism has costs, attacks, and risks associated with it. Passwords (something you know) can be forgotten or stolen without your knowing it, but are easily changed. Biometrics (Something you are) can be extremely difficult to forge but cannot be changed on-demand (but can change over time), fail due to injury (how do you read a fingerprint through a band-aid?) or in the worst case, cost you that finger. Number-generators and private crypto keys (something you have) raise the bar significantly for compromising account but can be lost or stolen, are difficult to support or change, and are generally not shared between different authenticating entities.

    I would make a distiction here between symmetric, shared-secret systems such as SecurID which are difficult to support (and also hard to do securely in software) and asymmetric publc key cryptography like WiKID Strong Authentication where it is easy to implement and maintain and it is easy to share between authenticating entities securely.

    Suggesting two-factor authentication as a cure for Identity Theft Fraud-by-Impersonation is attempting to fit a technology solution to a systemic problem, which is what I think Schneier has been trying to get at all along.

    I don't think anyone is suggesting that strong authentication is the cure for all the risks out there - not even me ;). Protecting personal information with two-factor authentication would make stealing identity information harder. Using one-time passwords would solve the problem of people using the same passwords everywhere. What Scheier said though was:

    Two-factor authentication is a long-overdue solution to the problem of passwords. I welcome its increasing popularity, but identity theft and bank fraud are not results of password problems; they stem from poorly authenticated transactions. The sooner people realize that, the sooner they'll stop advocating stronger authentication measures and the sooner security will actually improve.

    I continue to be amazed at this. Isn't it clear from what he's saying: If you want to have better authentication for transactions, use strong authentication for the transactions!

    If banks and credit card companies required a one-time password everytime a transaction occurred would that make it extremely difficult to process a fraudulent transaction - especially if combined with a user-friendly server validation process. An attacker would have to piggy-back on a valid session via a trojan and fool the user into entering the one-time passcode for the fraudulent transaction.

    Think of it this way: How secure is the ATM Network vs. the credit card network? The ATM system is two-factor. You have to steal both the card and the PIN to get cash. With credit cards, you only have to steal the number. I wonder what the value of stolen ATM card numbers are on the black market vs. the value of a stolen credit card?

    The URL to Trackback this entry is:
    http://www.wikidsystems.com/WiKIDBlog/29/tbping

    Tower Group pushes Two-factor Authentication for Online Banking


    Clearly, we need to do a better job of promoting WiKID.



    The Tower Group just issued new research titled: ONLINE BANKING REQUIRES STRONGER AUTHENTICATION METHODS TO COMBAT MORE ADVANCED FORMS OF FRAUD



    Highlights of the research include:
    Many desktop computers are highly-vulnerable to attacks from malicious software, which can be downloaded to a PC without the consumer's knowledge. Using these 'malware' payloads, fraudsters can gain access to personal information through a variety of methods - from logging an individual's keystrokes on the computer when they sign in to their online banking site, to remotely taking control of the user's entire PC.
    "Single-factor" authentication, typically a username plus password, remains the most widespread approach for accessing online banking sites. While easy to use and administer, it cannot combat more advanced forms of fraud. As usernames and passwords become the weak link, the traditional single-factor approach will become an entirely deficient means of online banking authentication.
    "Two-factor" authentication offers a vast improvement in security. One example involves providing consumers with a hardware "token" that generates a random number to be entered along with his or her password. However, most large consumer banks have been fearful that convenience-oriented consumers will reject the additional burden of physical tokens, or will be overwhelmed by devices from multiple institutions.


    WiKID solves many of the issues with standard hardware tokens. First, convenience. WiKID runs on the PC (or a wireless device making it easy to cut-and-paste the one-time passcodes. The client can be protected in a PKS12 store for security. Still, because the PIN is stored on the server, stealing the private key is no different than stealing an ATM card - you don't have enough. As a convenience to the administrator, we can automate the initial validation process.



    Further, WiKID running on the PC is capable of validating the SSL certificate of the targeted website before getting the one-time passcode. This elimates man-in-the-middle attacks such as DNS-cache poisoning.



    WiKID also solves the problem of multiple "devices from multiple institutions". Because we use public key cryptography, a single WiKID client can support multiple WiKID servers across multiple enterprises. Instead of having multiple key fobs, you would have one WiKID client with multiple public keys! (In addition, you can have multiple WiKID client assigned to a single username, so you can have one client running on your Windows, Mac, Linux desktop and another on your Blackberry.



    If more people had WiKID clients, then more financial institutions would be interested in securing their online banking systems with WiKID. Yet, people don't need a WiKID client unless they have something to log into using two-factor authentication! Classic chicken and egg. We're planning on doing something about this soon. Keep an eye here.


    The URL to Trackback this entry is:
    http://www.wikidsystems.com/WiKIDBlog/30/tbping

    Including Annual Average Loss Expectancy in NPV analysis of information security investments

    People ask me what I do on a blog, like they expect that I tell people about my bowel movements or something. I tell them that it gives me an outlet to proselytize about two-factor authentication, post things that don't belong on a corporate marketing site and throw up half-baked thoughts without the pressure of writing a full-blown white paper. This post is goes under the last category.

    I have posted about information security and ROI and why ROI is a poor measure for everthing. I suggested that using a risk-adjusted cap rate rate is a much better idea. I even suggested a way to doctor up a cap rate to compensate for information security risks. In a discussion some time ago on Security-basics, a poster brought up ALE as a good solution too. I've been chewing on ALE and want to discuss using it in an NPV calculation to see what comes to mind and see if it generates some discussion.

    I believe that most enterprises under invest in security because it can be hard to justify certain expenses. I believe that enterprises unknowingly accept greater risk than is acceptable given their projected returns. AALE is an interesting concept because it promises to put a number on that risk. I had trouble coming up with numbers I felt comfortable with for projected losses. I think the costs are under-reported, in general. I think that IT pros will have to come up with their own numbers. For my example, I used some costs from the CSI/FBI survey. While only about half of the companies reported financial costs for attacks, I think the offer a good, averaged base number.

    Theft of Proprietary Information $11,460,000.00
    System Penetration $901,500.00
    Unauthorized Access $4,278,205.00
    Total $16,639,705.00
    Number of respondents: 269
    Average per year $61,857.64

    While these numbers have some basis in reality, I then used a VPN example that I completely made up: A new remote access solution that costs $100,000 saves $10,000 per month in remote access dial up costs and increased productivity. The ROI is good, the payback 10 months. What about NPV? Assuming the firms weight-average cost of capital is 8%, here is the base scenario NPV:

    Investment: $100,000
    Interest Rate: 8%
    Period: 36 months
    Savings: $10,000
    NPV: $15,899.93

    All good so far. But as an IT professional, you know there is an increased risk with the new system. If you subtract a AALE from your savings, what happens to NPV? I used the $61,857 number from the CSI report without adjustment – divided by 12 months. I figured that only half reported and they averaged it out already – plus these are only a portion of the actual potential problems. The survey doesn't break out the costs so it's hard to tell how accurate they are. Your mileage may vary.

    Investment: $100,000
    Interest Rate: 8%
    Period: 36 months
    Savings: $10,000-5,154.80=$4845.20
    NPV: ($40,025.83)

    Ouch, we went big time negative! You can do some sensitivity analysis around these figures now. You can apply you own expectations of loss. If you have high value intellectual property or if you are in a highly targeted industry - or if you have highly uncooperative employees, you might raise your numbers. Or you can hypothesize what investing in information security systems that will reduce the likelihood of a successful attack.

    I'd be interested in better ALE numbers and how they might be calculated by a company, if anyone has such data or can point me to it.

    The URL to Trackback this entry is:
    http://www.wikidsystems.com/WiKIDBlog/37/tbping

    Re: Including Annual Average Loss Expectancy in NPV analysis of information security investments

    Posted by DM at May 18, 2005 07:39 PM
    Okay, I am so not following your math. Could you explain how you got the NPV numbers in a little more detail, to us non-finance folks? Thanks

    -DM

    Emergent Bits of Security

    Posted by Emergent Chaos at Mar 22, 2007 08:17 AM
    Nick Owen has a post about Net Present Value and Annual Average Loss Expectancy. If you think security is all about vulns and 0day, you probably don't need to read this post, and your boss is going to keep...

    Loss Expectancy in NPV calculations

    Posted by Financial Cryptography at Mar 22, 2007 08:17 AM
    Mr WiKiD does some hypothetical calculations to show that using some security solutions could cause more costs than benefits, as everything you add to your systems increases your chances or loss. Is that right? Yes, any defence comes with its...

    Gonzo Bankers Predict the end of online banking

    First, what a great site. Clearly, these guys agree with my philosphy that if you're not having fun, the money probably isn't worth it:


  • We are not the folks who borrow your watch to tell you what time it is - instead, we simply peer over at your wrist when you're not looking.
  • We never use silly words like "paradigm" and "mission statement" - we prefer more pragmatic terms like "revolutionary mental model" and "envisioned future state."

  • The Gonzo Banking team suggests that banks are not doing enough to protect their customers:

    B of A’s position was that their security had “done its job” and they could not be held responsible for their customer’s inability to adequately protect his computer and the information it contained. Banking customers across the country reacted negatively to the news that funds in their accounts were not being protected. “If I loose my checkbook, or have it stolen, my bank will stand behind me and protect my funds. Why doesn’t this apply to every method of accessing my accounts?”

    They offer some strategies to minimize the risks involved in online banking:

  • Do not allow transfers to external accounts.
  • Allow external transfers, but only to registered accounts.
  • Set limits on how much can be transferred outside the bank in a given day.
  • Requiring a normal range of payments to be specified for each vendor can reasonably protect bill payment.
  • Pressure your Internet banking product vendor to implement fraud detection software.
  • All sensitive information inside the network and all information on files sent outside the facility will be encrypted.


    These are noteworthy, but seem to be generated solely from a banker's risk management perspective. What about applying technology to solve some of these issues? As I have stated before, financial transactions can be validated or "signed" using a one-time password system. Perhaps there is a happy middle ground where riskier transactions require two factor authentication, while low-risk repititive transactions do not.


    If the Gonzo Bankers are concerned about the cost of two factor authentication, they should reconsider. With software-based two-factor tokens like WiKID, the cost would be far less than either hardware tokens or even passwords.


  • The URL to Trackback this entry is:
    http://www.wikidsystems.com/WiKIDBlog/38/tbping